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>
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>
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>
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>
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>
/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>
dev_agentandClaude Opus 5.5
orchestrator-agent