| name | build-to-spec |
| description | The core implementation discipline — claim ONE requirement, make the minimal change that satisfies its acceptance test, run the test, verify, release. Use this every time you implement a requirement: it is the inner loop. Trigger it whenever you are about to write code, and especially when you feel the pull to fix a nearby thing, refactor "while you're here", or tweak a test that's in your way. |
build-to-spec
This is the implementation discipline at the heart of the loop. A requirement is a closed
question with a test for an answer. Your job is to make that one test pass with the
smallest change that honestly does so — then verify and release. Nothing more. The whole
architecture (one requirement at a time, a small local model, independently verifiable
changes) depends on this staying small.
The discipline
- Claim one requirement. Exactly one, via
rtmx-loop. Its acceptance test is your
whole scope.
- Read the test first. The linked test is the spec made concrete. Understand what it
actually checks before writing a line — that tells you the minimal change.
- Make the minimal change. Smallest diff that makes the test pass for the right
reason. No adjacent refactors, no speculative abstraction, no "I'll also fix…".
- Run the test, then
rtmx verify. Local run for the fast loop; verify is the
authoritative close that writes status back.
- Release and move on. Done means closed-by-verify and released — not "looks done".
The acceptance test is the contract
The test is ground truth, not an obstacle. If a test is in your way, you do not edit it
to make your change pass — that inverts the entire trust model, where humans own the bar
and the machine clears it. Two honest outcomes only: make your code satisfy the test, or if
the test is genuinely wrong, fix the spec — flag it for a human, change the requirement
and its criteria deliberately, never quietly weaken the assertion to game a green.
Don't expand scope
Scope is narrowed on purpose so a ~4B-active model can succeed and so every change is
reviewable in isolation. Expanding scope — bundling two requirements, refactoring beyond
the diff, gold-plating — defeats both. If you discover real adjacent work, it is a new
requirement for rtmx (human-gated via decomposition), not extra cargo on this one.
Example
Claim HARNESS-002 ("malformed tool call is detected + retried, not crashed"). Read
harness/toolcall_test: it feeds a bad call and expects a retry, not a panic. Minimal
change: wrap the decode, classify malformed-call, route to the existing retry path. You
notice the harness adapter could be refactored — leave it; not this requirement. Run the
test (green), rtmx verify (closed, written back), release. One small, reviewable diff.
