agentic-tdd

# 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`](https://github.com/reticlehq/reticle/blob/main/skills/install-and-verify/SKILL.md) 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: ``` reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "allOf", predicates: [ { kind: "net", method:...