Connecting recipes to the way a household cooks.

THE WORK

The project.

Brimfox connects the decision about what to cook with what happens after the meal. Recipes sit alongside the ingredients in a personal or shared pantry, usable substitutions and notes about what worked. The Flutter app presents that cooking flow, while a modular Laravel backend owns the records and checks which household the person can act for.

Completing a meal is a concrete part of that connection. The cook confirms which pantry items to keep or remove; Laravel saves those changes with the cook session, cooking memory and applicable family feedback in one transaction. A recipe quantity is not treated as permission to deduct stock. Posts and public-review submissions happen afterward, so the app can explain that the meal was saved even when sharing it failed.

Recipe explanations have their own path. Laravel builds context from the recipe detail, checks its cache, calls the PHP provider and validates the result before returning or falling back. Brimfox AI Core contains separate Python ranking and explanation-checking endpoints, plus the Laravel client needed to reach them, but this product response does not call them yet. The newer service-planning screens are also a local-data prototype, separate from the implemented cooking-completion flow.

ATTEMPTS & CORRECTIONS

What changed along the way.

1. 01Giving Brimfox one type family without one weight everywhere

   At first

   The earlier brand specification paired an editorial display face with a separate sans-serif face for text and controls. The approved V4 onboarding reference established a different direction with one bundled Montserrat family.

   What needed to change

   Later screens needed to follow the new reference, not carry forward the old pairing. They also needed more than a blanket font replacement: copying the onboarding title's heavy weight would flatten the differences between headings, body copy and controls.

   My direction

   I required one app font with no per-screen family overrides, then clarified that later screens must follow their own reference weights rather than repeat the onboarding screen's heavy display treatment.

   The change

   I made BrimfoxSans the app-wide family and centralized the text roles in BrimfoxTypography. The follow-up rule kept that family fixed while making the screen reference and semantic role determine each weight.

   The result

   The Flutter manifest bundles BrimfoxSans with explicit Montserrat weight files, and the active screen contract requires both shared roles and reference-specific weights. This records a change in the design rules; it does not describe a font defect observed in production or complete visual acceptance of every screen.

2. 02Showing a substitution without counting it as usable21 June 2026

   At first

   The recipe engine treated any catalog substitution available in the pantry as covering a missing ingredient. Recipe details and shopping gaps followed the same rule.

   What needed to change

   Introducing a 'not recommended' tier made availability and usability different questions. If the old coverage rule remained, an entry displayed as a warning could still raise the recipe score and make a missing ingredient appear covered.

   The change

   The June change added the new tier alongside a usable-substitution filter. Suggestions, recipe details and shopping gaps now exclude that tier from coverage while retaining the full substitution entry for the reader to inspect.

   The result

   The test definitions keep the suggestion at 'missing one' and the recipe detail at 'cannot make after substitutions', while both still show the warning entry. They were not rerun here. The tier and filtering arrived together; this is a matching-rule change, not evidence of a previously shipped defect or food-safety verification.

IMPLEMENTATION

Design choices.

1. Keep is the default pantry action. Remove requires an explicit item identifier within the permitted pantry and soft-deletes that item; finishing a recipe does not silently infer how much stock remains.
2. The meal record and confirmed pantry changes commit together, while sharing is a follow-up. That keeps a failed post from undoing a completed meal, but requires the interface to distinguish saved work from an unsuccessful later request.
3. Replay belongs to a user and a key, backed by a database uniqueness constraint. Flutter currently creates a fresh key for each invocation, so the server's replay support does not make the entire client sequence exactly-once.
4. An explanation is not a prerequisite for recording a meal. Laravel owns its validation and fallback today; using the Python helper will require a real caller, an enablement check and a decision about how each helper outcome affects the response.

HOW IT FITS TOGETHER

Architecture.

• Flutter controllers work through typed repositories and authenticated Laravel endpoints. A completion request names the recipe and pantry scope, then supplies a bounded list of ingredient actions the cook has confirmed.
• Laravel resolves household membership before writing and limits pantry lookups to that household or the user's personal pantry. The transaction groups pantry soft-deletes, the cook session, cooking memory and applicable family feedback so those records commit together.
• The completion endpoint can replay a saved result using a user-scoped idempotency key. The controller then makes separate requests for a cooking post and, when requested, public review, retaining the completion result if a later request fails.
• Explanation generation starts from user-scoped recipe detail and proceeds through context construction, cache lookup, provider generation and output validation. Its configured fallback is independent of the transaction that records a cooked meal.
• The linked Brimfox AI Core package exposes FastAPI helpers and has a Laravel HTTP client, but no caller connects it to the current recipe response. The service-planning interface similarly remains local-data work rather than an established backend workflow.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app