2 Commits (b7584bd0c233895ee6d9d83dca36018be7584731)

Author	SHA1	Message	Date
Strycher	b7584bd0c2	chore(#352): generate drift code in CI instead of committing it ... Replaces the stopgap (53f87f5) that committed lib/storage/drift/offband_database.g.dart to green CI. Restores the repo's "generated files are not committed" convention: - dropped the .gitignore negation; the .g.dart is gitignored + untracked (git rm --cached, working copy kept) - added `dart run build_runner build --delete-conflicting-outputs` immediately after `flutter pub get` in every Dart job: flutter_dart (analyze), build.yml (all 6), release-signed (android-signed), deploy-web (before build_pipe) - keeps the drift_dev 2.34.0 / drift 2.34.2 / build_runner ^2.15.1 pins from the stopgap for deterministic generation Verified locally on the bench toolchain (3.44.1): deleted the working .g.dart, ran build_runner from scratch (regenerated cleanly), confirmed the generated file passes `dart format --set-exit-if-changed` and full `flutter analyze --fatal-infos --fatal-warnings` is clean with the file generated (not tracked). For #335 / PR #348. Agent: SapphireCompass (session 8d755b5e)	20 hours ago
Strycher	83c965ef44	feat(#339): deploy web client to offband.app via Cloudflare Pages ... Publishes the Flutter web client. offband.org stays the Hugo marketing site in OffbandMesh/offband-site, a separate Pages project, untouched. push to main -> --branch=main -> production -> offband.app push to dev -> --branch=dev -> dev tier -> dev.offband.app Direct upload only. Cloudflare's dashboard "Connect to Git" must not be enabled for this project; it would create a second git-integrated project racing this workflow. Matches how offband-site deploys. Because direct-upload projects cannot configure production branch controls in the Cloudflare dashboard, the "never auto-deploy arbitrary branches to prod" requirement from #122 is enforced by the workflow's trigger list instead. That is the safety mechanism, and it is better placed here than in dashboard state: reviewable and version controlled. Builds via build_pipe rather than a plain `flutter build web`, because build_pipe appends ?v=<version> to the bootstrap and manifest files. Without it, browsers serve stale bundles after a deploy. Two fixes folded in: - pubspec.yaml build_pipe build_command did not pass --dart-define-from-file, so a deployed site would have shipped a dead GIF picker even though #331 wired the key into build.yml. The deploy path and the CI path used different build commands. - Retired the inherited zjs81 Workers deploy: removed deploy.yml and wrangler.toml (which targeted THEIR account's "meshcore" project) and dropped the now-dead `deploy` script from package.json. A root wrangler.toml carrying Workers config can also interfere with `wrangler pages deploy`. Verified locally by running the real build with the bench toolchain: build_pipe accepts the new flag, cache busting is applied (flutter_bootstrap.js?v=e2019703...), output is 46 files with a 10.2 MB largest asset (Pages limits are 25 MiB per asset and 20000 files), and the Giphy key is confirmed compiled into main.dart.js. Not verifiable locally: whether the repo's CLOUDFLARE_API_TOKEN carries Pages:Edit scope. The workstation token is DNS-only and 403s on the Pages API. A 403 on first deploy would indicate wrong scope; it fails safely. Part of epic #312, plan #321 (Phase 4).	1 day ago