Red, green, refactor: against the running app

Unit tests drive the units. They cannot say "clicking Deploy posts to /api/deploy, moves the store to deploying, and shows the banner": that outcome only exists when the whole app runs. So the loop stalls exactly where the interesting bugs are, and the agent falls back to writing code and hoping.

This runs the same discipline one level up, using Reticle to drive the real app. Not installed? RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init, then the install-and-verify skill.

Why this is TDD and not just testing afterwards

The whole value of test-first is that the oracle is written while you still do not know the answer. An expectation written after seeing the result can always be adjusted into agreeing with whatever happened, and an agent is especially good at that adjustment. It will find a reading of the output under which the code it just wrote is correct.

reticle_act_and_wait({ ref, action, until }) enforces the order structurally: until is an argument to the action, so the consequence is named before the action runs. That is the red-green loop, made unfakeable.

1. RED: write the expectation, watch it fail

Before you write the feature, state what the app must do: