2 Commits

Author	SHA1	Message	Date
Krzysztof kuhy Rudnicki	55fade1e15	Let the desktop provision its sync account from the wrapper ... Same change todo just took, for the same reason: app/'s desktop target is a Flutter web build in a Chrome --app window, so FlutterSecureStorage resolves to the web backend (AES-encrypted localStorage, keyed inside the browser profile). Nothing outside the page can write that store — `secret-tool` targets libsecret, which only a Linux embedder build would read, and a Dart CLI cannot even import flutter_secure_storage, since it is a Flutter plugin that fails to resolve on the VM. Both verified rather than assumed. The wrapper is the one process that can read the filesystem and serve the page, which is exactly why it already holds the GitHub token instead of the browser (see github_proxy.dart). So the sync account now arrives the same way: loadAccount() falls back to GET /sync-account when the store is empty and persists the result, making the route a one-shot provisioning step rather than a standing dependency. It reads ~/.config/crdt-sync/{firebase.json,password} — the same pair `diet_guard sync` already uses — so the machine keeps one source of truth. Off unless CRDT_SYNC_SERVE_ACCOUNT is set, and 404 (not 403) when disabled so a probe cannot tell the route exists. On Android there is no wrapper: the request simply fails and loadAccount() returns null exactly as before. clearAccount() writes an opt-out marker the fallback checks, so Disconnect cannot be silently undone by the next launch re-adopting the account. 518 tests, analyzer clean, pre-commit clean. Pinned to crdt_sync_dart-v0.8.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0177xwzcpfpWG2qca8Mr39q9	2026-08-09 21:41:08 +02:00
Krzysztof kuhy Rudnicki	da0b54d886	Sync meals and the food bank through Firebase, mirroring to GitHub ... The largest consumer moves last on purpose: diet_guard was 71% of all sync traffic, and both its surfaces (the PC timer and the phone app) share one prefix, so they move together. Firebase becomes the primary backend when it is set up, with GitHub kept as a mirror so a device that has not moved yet still converges. An unconfigured device keeps syncing exactly as before, which is also the rollback. Revision tracking is new here. The PC hand-rolled its own pull-merge-push instead of calling sync_log, so it had none: every tick re-downloaded every peer's whole food log -- hundreds of KB, 96 times a day -- and re-pushed its own regardless of change. It now reads one small revision map first, skips any peer whose hash is unchanged, and suppresses a no-op push. Every sub-sync (log, budget, food bank, manual bank) takes the client as a parameter, so one swap covers all four. The app could not have reached Firebase at all: nothing called saveAccount(), so loadAccount() always returned null and openFirebase() always returned null. Settings now has a Firebase section that stores the account in the OS keystore and signs in immediately, so a typo surfaces on the screen where it can be fixed rather than as a silently failed background sync hours later. The email and password never touch the repo -- it is public. Platform reaches now degrade instead of failing: an unavailable keystore or application-support directory costs one tick of extra traffic, where before it would have taken sync down entirely. Caught by `on Object` rather than `on Exception`, because an uninitialised binding raises an Error. Verified end to end against the real database, not just in tests: a live PC sync merged 57 days / 339 entries and put 221 KB of food log plus 97 food-bank records into Firebase; a second unchanged tick issued zero pushes; and the Dart client signed in and read back all 339 meals and 97 foods, then completed a push / publish-revision / suppress-no-op round trip under a throwaway prefix. diet_guard: 618 tests at 100% branch coverage. diet_guard_app: 477 tests. Two assertions moved from 4 pushes to 5 -- the extra one is this device's revision, published after the log so a peer can never cache "seen rev X" against a log it never received. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SJ9sxEw3ymzXNjL7SHNpJc	2026-08-05 08:35:21 +02:00