BUILDWITHZACH — SAMPLE APP REPAIR REVIEW
Prepared October 17, 2026. Synthetic teaching example, not a client engagement.

USER JOURNEY
A sample customer submits a project request, then returns to read it.

REPRODUCED FAILURE
POST returned 201, but a separate GET returned an empty array. The handler
returned the request object without storing it. The apparent save was only
the response displayed by the first request.

REPAIR IN THE DOWNLOADABLE FIXTURE
Write the synthetic record to a temporary file, rename it into place and
acknowledge only after that write completes. Start a second server against
the file and compare the complete returned record with the original input.

ACCEPTANCE EVIDENCE
Run node --test app-repair-proof.mjs. The first case demonstrates the failure;
the second asserts persistence across server restart. Another case checks
an absent test session (401), the record owner (200) and another client (403).

SCOPE LIMIT
This local fixture does not establish Lovable/Supabase behaviour, production
database durability, crash recovery, real user authentication or compliance.
A customer review would need the actual code, environment and failure.

DECISION EXAMPLE
Repair when the relevant flow and data model can support the acceptance
criteria. Consider a selective rewrite when one boundary cannot. A full
rebuild requires evidence of a broader constraint, not just a preference
for a different framework.

WHAT A REAL WRITTEN SCOPE SHOULD NAME
Affected journey and version; reproduction; expected result; proposed change;
exclusions; verification; rollback; repository and account ownership; fees,
timing and support agreed before implementation.