Caravana — Points & In-Store Redemption Platform

What matters here isn't that meetings happened — it's what got decided and dropped. The points bonus stayed a manual capture on purpose, so as not to invent a rule the client hadn't settled on. The daily cutoff went through three values before landing on 5 PM local. Finding ambiguities early is the actual job of this phase.

Built in Claude Design and clickable before a line of production code existed. That meant engineering never argued about visuals — a written rule (design is approved, only fix what's broken) prevented redesigning under pressure. Honest limitation: the mockup used fake data; it was a visual reference, not a behavior spec.

One commit per step, prompts as a complete file, a "report and continue" protocol, an explicit list of commands requiring one-time authorization, mandatory backups before destructive edits, raw evidence for every claim, concurrency tests run in parallel (never sequentially), and a green test suite updated in the same commit that adds a screen.

The changes the client asked for were about reports and visibility — not business logic. That's a signal the requirements phase worked.

Training material came from the system's failure modes, not a feature list — train people on what's most likely to be misread.

First real activation with zero failures, tablet usage confirmed directly in the server logs.

A unique phone number, an idempotency key, and a database constraint guaranteeing exactly one activation in progress system-wide. A code-level check gets raced by two near-simultaneous requests; a database UNIQUE constraint doesn't. Row locks are always acquired in the same order (inventory before balance), with retry on cross-lock — reversing that order is the textbook deadlock recipe.

Not with the HTTP attempt. Generating it when the button is tapped means a retry after a store-WiFi timeout produces a new key — and charges twice, in exactly the scenario this defense was built for.

The redemption record is written as the transaction's first statement, before balance or inventory. When the unique key collides, the response is HTTP 200 with the original redemption — an error there would make the screen retry with a fresh key, and that's where the double charge happens.

Never with the database engine's own date functions — the DB server had no named time zone catalog loaded and failed silently. The real bug this avoided: with the site in UTC, the day cut over at 6 PM Mexico time instead of 5 PM.

An activation's status is derived from stored facts, never written as loose text. The old column that stored status as text now shows values that no longer match reality.

Opening stock freezes at the day's first movement, not at activation time — merchandise still being loaded in is setup, not operation. The day's report freezes at close and never recalculates — a later correction can't silently change a number the client already received as final.

An audit row or queued email disappear cleanly on rollback; the actual email send and file writes happen outside it. A logging failure never aborts the business operation.

Outside the public folder, served with an HMAC token and expiration, so report links open with one click from a spreadsheet without a guessable URL. The redirect is attack-surface reduction, not the security boundary — the real boundary is the server's rejection at the endpoint level, written that way as a comment in the code.

They execute whenever the floor app checks the day's status — the only point in the system where a request is actually guaranteed.

So an administrator with the catalog screen open doesn't overwrite, with an absolute value, redemptions made on the floor in the meantime.

A kill switch that needs no deploy, an hourly cap under the shared server's limit, and SPF/DKIM/DMARC aligned.

Mounts production's real files over React and a real DOM, logs in with simulated real user events, and fails the run on any React Hooks warning — not just on errors.