Coding Agent Brief With Done-Check

Act as a careful senior software engineer working inside my codebase.

Task: Add a discount code field to the checkout page. When a customer enters a valid code, the order total should drop by the code's percentage. Invalid or expired codes should show a clear error message under the field without clearing the basket.

Context: A small online shop built with Node.js, Express and React. Checkout lives in src/pages/Checkout.jsx and the pricing logic is in server/pricing.js. Discount codes are stored in the codes table of a Postgres database. We use Jest for tests and Prettier for formatting.

Steps:
1. Before changing any code, write a short plan: the files you expect to touch, the order of changes, and any risks. Wait for my approval if the task touches more than three files.
2. Make the changes in small steps, keeping to the existing code style.
3. Run this exact command to prove the work is finished: npm test -- --testPathPattern=checkout && npm run lint
4. If the command fails, read the error, fix the cause, and run it again. Do not claim success until it passes.
5. Do not edit anything outside the scope of the task.

Output:
- The plan (before any edits).
- A list of files changed, with one line on each.
- The done-check command and its final result, pasted exactly.
- Anything you were unsure about or left undone.

# Plan (no edits made yet) I haven't opened the repo yet, so this plan rests on your description. The first step after approval is to read the files below and correct anything I've guessed wrong. ## Files I expect to touch 1. **`server/pricing.js`**: add `applyDiscount(subtotal, code)` and a lookup that validates the code against the `codes` table. It rejects unknown codes and codes past their expiry date. The percentage comes from the DB and is never trusted from the client. 2. **Checkout API route** (probably `server/routes/checkout.js` or wherever the order total is computed; I'll confirm its name): accept an optional `code` and return the discounted total or a structured error such as `{ error: "expired" | "invalid" }`. 3. **`src/pages/Checkout.jsx`**: add the code input and an "Apply" button, show the discounted total, and render the error message under the field. The basket state stays untouched on failure. 4. **Tests** (`checkout.test.js` or similar, matching `--testPathPattern=checkout`): valid code, invalid code, expired code, and basket preserved after a failure. 5. **Possibly a stylesheet**, only if the existing error-message styling can't be reused. This is more than three files, so **I'll wait for your approval before editing.** ## Order of changes 1. Read `Checkout.jsx`, `pricing.js`, the checkout route, existing tests, and the `codes` table schema (column names for percentage and expiry). 2. Write failing Jest tests for the pricing and route behaviour. 3. Implement the pricing logic, then the route. 4. Build the UI field and error display. 5. Run Prettier on the touched files only. 6. Run the done-check: `npm test -- --testPathPattern=checkout && npm run lint`. If it fails, I fix the cause and rerun. ## Risks and open questions - **Schema unknown**: I need to confirm the `codes` columns (percentage, `expires_at`, maybe `active` or usage limits). If a migration is needed, that's another file and I'll flag it first. - **Server-side authority**: the final charged total must be recomputed on the server at order submission, not just in the UI. Otherwise the discount could be spoofed or lost at payment. - **Rounding**: I'll check how `pricing.js` handles money (integer cents vs. floats) and follow it. - **Case sensitivity and whitespace**: I'll assume codes are case-insensitive and trimmed. Tell me if that's wrong. - **Stacking and limits**: I'm assuming one code per order and no usage limits unless the table has them. - **Test DB**: I need to see whether existing tests mock the DB or use a real one, and I'll follow that. - **Percentage bounds**: a code over 100% or below 0% should be rejected defensively. ## Questions for you 1. Are the column names for percentage and expiry something you can tell me, or should I read the schema or migrations? 2. Is it fine to add a migration if the table lacks something we need? Reply with approval (and any answers) and I'll start. I'll report the changed files and paste the done-check output exactly, with nothing claimed until it passes.