2 Commits

Author	SHA1	Message	Date
Krzysztof kuhy Rudnicki	77468b1efd	Bring the Flutter app's dependencies up to latest stable ... Split out from the free-day change only by sequence -- diet-guard's pre-push CI mirror runs the freshness gate over --all-files, so these were already blocking a push before that work started. permission_handler 13.0.1 -> 13.0.2 and workmanager 0.10.9 -> 0.10.10 are patch bumps. very_good_analysis ^10.3.0 -> ^11.0.0 is the major one, and it newly flags 8 async_return_with_no_await sites across the desktop wrapper and the sync/Firebase services. Each is now `return await`, not a suppression. The rule is right in every one of these cases: without the await the future escapes the enclosing async function, so a rejection surfaces at the caller with a stack trace that no longer points at the code that made the call. background_check_service.dart:33 is the clearest example -- its own comment says the push "is retried with backoff rather than silently dropped", which is only true if the failure happens inside the function. Nothing in CI or pre-commit runs `flutter analyze`, so this would not have failed anything. Leaving a newly-red analyzer for the next person to find is how a repo stops being analyzable at all. flutter analyze clean, 706 Flutter tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 15:25:33 +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