Release corrections round 2: offline onboarding lockout and stale candidates after rename #103

Merged

approver_agent merged 3 commits from task/release-corrections-2_4fd737b2-fdcb-48ad-858a-ecdd95595e0c into dev 2026-10-07 00:14:33 -04:00

Conversation 3 Commits 3 Files Changed 8

+368 -50

3 Commits

Author	SHA1	Message	Date
dev_agentandClaude Opus 5.5	8d8a5480b9	Keep candidates found at a rename's revision when clearing offers ... A candidate search that read a dinner after its rename committed could store fresh offers that the rename's own clear then dropped, so a valid candidate for the renamed dinner was refused with a 400. clearOffers now takes the revision below which offers are stale: a rename passes its committed revision, so it drops only offers and in-flight searches from earlier revisions, while grounding by hand and archiving pass math.MaxInt64 and clear everything as before. A search finishing late at an earlier revision no longer replaces offers already found at a later one. Fixes MQ-103-02. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 00:05:30 -04:00
dev_agentandClaude Opus 5.5	e07628638e	Bind candidate offers to the dinner's grounding revision ... MQ-103-01: offers were bound only to the normalized name and cleared only when it changed, so "Chicken curry" -> "Quick Chicken curry" kept the old candidates live, and a search finishing after renames A -> B -> A committed (before either cleared offers) stored candidates that matched A again. Every actual name edit now raises grounding_revision and clears the dinner's offers. Each offer set records the revision its search read, and a candidate grounds the dinner only while the dinner is still at that revision; GroundDinner already requires the observed revision, so a rename between the check and the write is a conflict. A pending dinner renamed keeps getting a job at its new revision; recipe_url is still cleared only when the normalized name changes. Tests: a same-normalized-name rename refuses the old candidate and attaches no recipe; an in-flight search finishing between the A -> B -> A commits and their offer clearing stores candidates that are refused. Both fail against 3c0a7fd. Maestro task: 4fd737b2-fdcb-48ad-858a-ecdd95595e0c Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:53:31 -04:00
dev_agentandClaude Opus 5.5	3c0a7fd398	Fix offline onboarding lockout and stale candidates after rename ... MQ-98-04: the household settings read that OnboardingGate makes before every page now runs with networkMode 'always', like /me. After the browser emits an offline event it fails into the saved pages instead of pausing on the loading screen. A test emits a real offline event before /me fails. MQ-98-05: renaming a dinner now clears its candidate offers and makes a running candidate search stale, and an offer is bound to the normalized name it was searched for, so a candidate offered before a rename cannot ground the renamed dinner. Regression tests cover a pending dinner renamed after candidates were offered, and a rename during a running search. Maestro task: 4fd737b2-fdcb-48ad-858a-ecdd95595e0c Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 23:36:31 -04:00