Reporting a saved meal when sharing fails

Start with what the cook confirmed#

Completing a recipe does not tell the app that every listed ingredient is now gone. Brimfox asks for confirmed ingredient actions and defaults each pantry action to Keep. A Remove action names a pantry item; if that item is not found within the permitted pantry, the service records a skipped update rather than substituting another item.

An accepted Remove soft-deletes the pantry item. This is an explicit item-level decision, not quantity deduction calculated from the recipe. Keeping that distinction in the request prevents a meal record from becoming an unsupported estimate of the cupboard.

Commit within the right household#

Laravel resolves the requested household and checks membership before entering the write transaction. Pantry lookups then stay inside the selected household or personal scope. Personal-pantry queries exclude shared-household items, and unrelated household access is rejected.

The transaction saves the confirmed pantry changes, cook session, cooking memory and applicable family feedback together. These are the records that describe the completed meal. Creating a post and requesting public review are outside that transaction.

Keep the first success when the next request fails#

The Flutter controller stores the returned completion before it creates a cooking post. A public-review submission is another request after that. If either follow-up fails, the controller can still say that the cooked memory was saved and identify the sharing problem separately.

A single generic failure would lose this distinction and could encourage someone to repeat a meal that is already recorded. The endpoint accepts a user-scoped replay key, but the controller currently makes a new key on each invocation. Re-entering the client flow is therefore not the same as replaying the original completion.

Test the gaps between requests#

The existing API test definitions cover membership, pantry scope, confirmed changes and replay behavior. They describe checks at the completion endpoint, not proof that every client retry preserves one logical action.

The next useful cases start with a completion that has committed, then fail the post or review request. They should check the message shown to the cook, which records remain saved and whether retrying carries the original completion identity. No API or client test was run for this review.