Remediate feature-review HIGH: report the Supply run outcome after Push to Calendar #141

Merged

approver_agent merged 4 commits from task/push-supply-outcome_e75db0f0-817f-4eef-84b2-266e793c018a into feature/3a88c1fd-6c9a-4e70-b6b1-a8880dd4ac82-shopping-list-and-supply-archive 2026-10-08 14:50:39 -04:00

Conversation 7 Commits 4 Files Changed 6

+529 -29

4 Commits

Author	SHA1	Message	Date
dev_agentandClaude Opus 5.5	d917a40fa2	Settle a push's unmade Supply run however the shopping list is made ... Only the Plan's own "Make the shopping list" settled a push whose Supply run was not made. Making the list on the Supply run screen, through the same generate endpoint, left the push in the mutation cache, so coming back to the Plan still said the Supply run couldn't be made and offered to make it again, although the list existed (F17-R3). The settlement now lives in useGenerateSupplyRun, which both screens use: onMutate notes the week's pushes sent so far (settleUnmadePushes) and onSuccess removes those whose Supply run was not made. A failed attempt leaves them shown. usePushToCalendar's settle, the Plan-only path, is gone. Tests: the list made on the Supply run screen is no longer said to be unmade on the Plan, a failure there still is, and the success-after-navigation test now checks the push is kept while the week is left and removed once made, so settlement is observed apart from the week sweep. Maestro task e75db0f0-817f-4eef-84b2-266e793c018a. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:36:25 -04:00
dev_agentandClaude Opus 5.5	445750cecb	Keep a push's unmade Supply run across week navigation ... A push whose Supply run was not made was swept from the mutation cache as soon as another week was shown. If the household pressed "Make the shopping list" and moved to another week while it was being made, and making it then failed, coming back showed neither the failure nor a way to make the list: the week was left on Calendar with no shopping list (F17-R2). keepWeekMutations now keeps a week's latest push whose Supply run was not made whatever week is shown. It goes only when the list is made (settle), or when a push, draft or swap of that week sends a new push or resets it; an earlier push replaced by a later one is still swept as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 14:14:52 -04:00
dev_agentandClaude Opus 5.5	c589c02cdc	Settle a push's failed Supply run once the shopping list is made ... A push whose Supply run could not be made stays in the mutation cache, so leaving the Plan still shows the failure on coming back. Making the shopping list from that failure was only remembered while the Plan stayed mounted: after visiting the Supply run and coming back, the Plan said again that the list could not be made and offered to make it (F17-R1). usePushToCalendar now has settle, which removes the push shown from the mutation cache. The Plan calls it once the generate request succeeds, through mutateAsync, so it is settled even if the Plan was left while the list was being made. A push never followed by a made list is kept as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 13:54:32 -04:00
dev_agentandClaude Opus 5.5	9616941b73	Report the Supply run outcome after Push to Calendar ... The push client parsed only the plan from POST /plans/{weekStart}/push-calendar and dropped supply_run, so a Supply run that was not made was shown as a successful push (F17-01). Parse supply_run as the server sends it and tell the household every outcome on the Plan: made, left as it was in the Supply archive, or not made, with its recovery: push again for plan_changed (reading the edited plan again first), or make the shopping list again through the existing generate endpoint for supply_run_failed. A push whose Supply run failed stays in the mutation cache like a failed push, so leaving the week before it settles still shows it on coming back. Read the week's Supply run again when the push answers, using the Supply run screen's supplyRunKey, so a cached 404 or the earlier list is not shown for the freshness window (F17-02). Maestro task e75db0f0-817f-4eef-84b2-266e793c018a. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 13:36:13 -04:00