MealQuest

Author	SHA1	Message	Date
dev_agentandClaude Opus 5.5	3a1884de38	Keep week mutations bounded for the query client's lifetime, not Plan's CI / ci (pull_request) Successful in 4m25s Details CI / ci (push) Successful in 4m21s Details The cleanup of settled swaps and pushes was subscribed only while a Draft board was mounted, so one that settled after the household left Plan stayed in the mutation cache with gcTime Infinity. keepWeekMutations is now installed once on the query client's own mutation cache and never removed; the hooks only mark which week is shown. Pending ones, and those an earlier pending one needs, are still kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 02:28:01 -04:00
dev_agentandClaude Opus 5.5	5c8484cfb8	Collect settled week mutations when they settle, not only on a week change CI / ci (push) Successful in 4m22s Details CI / ci (pull_request) Successful in 4m23s Details The shared cleanup of swap and push mutations also runs whenever one of its kind settles, so an entry that settles while another week is shown is no longer kept indefinitely under gcTime: Infinity. Pending mutations, and the settled ones of a week that still has one pending, are never removed; a left week's latest mutation, when it failed, stays until another week is shown so coming straight back still shows the failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 02:07:05 -04:00
dev_agentandClaude Opus 5.5	8a02e04110	Keep Push closed over a cached plan; bound kept week mutations CI / ci (push) Successful in 4m21s Details CI / ci (pull_request) Successful in 4m21s Details A plan_changed reread answered from the service worker's cache left the old plan shown with Push and Retry open. Push now needs a plan read from the server (Plan.cached, set from cacheFallbackHeader), and the push failure's Retry reads the plan again while the plan shown is cached. Settled swaps and pushes were kept for every week ever touched. When a week is shown, the settled ones of every other week with none pending are now removed; pending ones still survive leaving the week and coming back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 01:45:33 -04:00
dev_agentandClaude Opus 5.5	f77960ad05	Keep a week's pending push across leaving the week and coming back CI / ci (pull_request) Successful in 4m25s Details CI / ci (push) Successful in 4m21s Details A push to Calendar now lives in the query client's mutation cache, keyed by week, as a swap does, instead of in the Draft board's own useMutation. A board remounted by leaving the week and coming back therefore still sees a push pending, including one held open by the plan_changed reread, and keeps Push and Retry disabled until that read lands. The reread now refetches the week's plan even while it is not shown, so a return finds the changed plan in the cache rather than the stale one. Tests leave the week and come back with the reread held open (no second POST; the changed plan, then Retry, push once), and let the reread land while the week is left (the board returns on the changed plan). Task: 677261bc-1a7c-4d96-b8f9-7601caf2186d Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 01:23:01 -04:00
dev_agentandClaude Opus 5.5	cc8a08aadc	Hold a plan_changed push until the changed plan is shown; announce reconnect CI / ci (push) Successful in 4m21s Details CI / ci (pull_request) Successful in 4m25s Details A push refused with plan_changed now stays pending until the plan has been read again, so Push and Retry stay disabled until the changed plan is on screen and nothing unreviewed can be pushed. A test holds that read back and checks that no second push is sent meanwhile, and that Retry pushes once it lands. The reconnect banner's reason and required action are now an alert, as ErrorBanner's message is, so a calendar request that turns the screen to reconnect required is announced. Task: 677261bc-1a7c-4d96-b8f9-7601caf2186d Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 01:03:40 -04:00
dev_agentandClaude Opus 5.5	2b5350bd62	Add the Google Calendar settings screen and wire Push to Calendar (Feature 16) CI / ci (push) Successful in 4m26s Details CI / ci (pull_request) Successful in 4m16s Details /settings/calendar now shows the Google Calendar connection: "Connect Google Calendar" (a full-page navigation to the connect endpoint) when not connected; "Connected · {calendar}" in teal-800 with a picker of the writable calendars, saved on choice, and Disconnect behind a confirmation when connected; and a grape banner with Reconnect, no picker, when Google has refused the grant. The settings list's Google Calendar row reads the same connection instead of the placeholder endpoint. The plan screens' "Looks good — push to Calendar" and "Push to Calendar" buttons now POST /api/v1/plans/{weekStart}/push-calendar, showing progress and storing the synced plan the server answers with. Failures only the settings can fix (google_reconnect_required, no_calendar, not_connected, calendar_unavailable) link to /settings/calendar; plan_changed reads the plan again; any other failure offers Retry. The mobile Draft board shows the existing sync status line under its push button. Maestro task 677261bc-1a7c-4d96-b8f9-7601caf2186d. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 00:44:58 -04:00

Compare commits

Diff Content Not Available