implement

Implement

Turn a story plus a contract into working, tested code. The discipline is simple and non-negotiable: the test comes first, and "done" means the suite is green — not "it should work."

Recite this — verbatim, as the first thing in your first response

Build mantra:

1. Read the contract first. The acceptance criteria are the spec, not my memory of the chat.
2. Red before green. Write the test that fails for the right reason, then make it pass.
3. The contract is sacred. I do not change an agreed API without flagging it loudly.
4. Done means the suite is green. I run it before I say the word "done."

Then begin.

When NOT to use

• No acceptance criteria exist yet. Route to sprint-planning — you have nothing to verify against.
• No contract / unclear design for anything touching multiple modules. Route to architecture-decision.
• You're chasing a bug, not building a story. That's debug-mantra.

Required inputs — refuse without these

• The story's acceptance criteria (from docs/backlog.md).
• The contract for anything cross-boundary (from docs/architecture.md).

If you're building a frontend against a backend that doesn't exist yet, that's fine — mock to the contract and say so. If you're building against a contract that doesn't exist, stop.

Workflow — in order, do not skip ahead

1. Restate the definition of done

In one or two lines: which acceptance criteria this change satisfies. If you can't map your work to a criterion, you're building the wrong thing.

2. Red — write the failing test

• Write the test that encodes the acceptance criterion. Run it. Watch it fail for the reason you expect (not a typo, not a missing import).
• A test that passes before you've written the code is testing nothing.

3. Green — make it pass

• Smallest change that turns the test green. Resist building for imagined future needs (YAGNI).
• Handle the failure paths the criteria name — validation, errors, empty/null, boundaries.

4. Refactor on green

• Now that it's green, clean it: naming, duplication, structure. The test is your safety net for the cleanup.

5. Run the whole suite before claiming done

• Run lint + the full test suite via the shell. Don't run only your new test — you might have broken a neighbour.
• If anything's red, you're not done. Fix or revert.

Parallel build note

Frontend and backend can be built at the same time only because the contract is fixed. If you discover the contract is wrong or incomplete while building:

1. Stop. Do not quietly implement a different shape.
2. Flag it: state what's wrong and what you propose.
3. Get the contract updated (architecture-decision) before continuing. Both sides must move together.

Output

• Working code + its tests, committed in small, self-consistent steps.
• A short handoff note: which criteria are now met, which endpoints/components are ready, suite status (e.g. "47 passing, 0 failing"). This is what qa-verify and scrutinize pick up.

Hand-offs

• Code done + green → scrutinize reviews it before merge.
• Code done → qa-verify checks it against acceptance criteria adversarially.
• Build surfaces a defect in existing code → debug-mantra.
• Contract needs to change → back to architecture-decision.

Rules

• Test first. Always. No production code without a failing test that justifies it. If you wrote the code first, delete it, write the test, and watch it fail before bringing the code back.
• Never claim "done" without running the full suite. "It should pass" is not "it passes." Run it.
• Never silently change an agreed contract. Flag, propose, get it updated. A frontend and backend drifting apart in silence is the most expensive bug in this loop.
• YAGNI. Build for the criteria in front of you, not the feature you imagine next sprint.
• Small commits that each work. A commit that doesn't build is noise in the history.