ADR 0034 (proposed): a test defends a decision

how-we-build 5 already says that if a document states a rule about the
mesh, it says how the rule is verified — an unenforced rule being
indistinguishable from a wrong one, and costing more because people
believe it. That has never been applied to decisions, and a decision
record states the same kind of claim.

The gap was found by review: the lab reached 2,128 lines with 1,072
untested and no stated rule broken, because there is no testing posture in
how-we-build at all. Every decision the lab embodies was verified by hand
and none of it survives the terminal it ran in — which is
04-ISSUES/005 in miniature, coverage assumed rather than checked.

Rejected a coverage percentage: it measures how much code a test touched,
not whether anything important is defended, and would have been satisfied
by testing the parser harder while the hypervisor integration stayed
unasserted.

Rejected test-driven development as a hard rule, and not because it is
wrong in general. Half this implementation was discovery — that the
hypervisor CLI reads a definition from stdin and hangs, that it assigns a
MAC without recording it, that a stock image's networking flushes a static
address. A test written first against undiscovered behaviour asserts a
guess.

So: structure and logic tested first, behaviour against a real system
tested alongside, mocking the boundary forbidden, and a blocking gate as
the definition of done. A test names the decision it defends, which is what
makes the pairing checkable — a decision without one can be found rather
than noticed.

Stated as proposed rather than adopted: 6 requires review by someone who
is not the proposer. Records 0001-0033 predate it and are not retroactively
invalid, but each should acquire a test or an explicit note that it cannot
have one, and until then the rule is aspirational for them — which is the
state 5 warns about, recorded rather than hidden.

00-META/how-we-build.md

@@ -152,6 +152,26 @@ finds one names the evidence required and returns the work.
 The reason is the mesh's most consistent failure shape: a green result proves transport, not
 effect. Absence reads as success unless something looked.
 
+### A test defends a decision
+
+*Proposed — [ADR 0034](../02-DECISIONS/0034-a-test-defends-a-decision.md), pending review.*
+
+The rule above applies to prose. It applies to **decisions** too: a decision record states
+something that must be true, and a test asserts it. A decision with no test is one that will
+quietly stop being true, and nobody will learn that from a document.
+
+- Structure and logic — what is accepted, what is refused, how a value is derived — is tested
+  **first**, because the behaviour is knowable before the code.
+- Behaviour against a real system is tested **alongside**, because it is discovered rather than
+  known.
+- **Mocking the boundary is forbidden.** A test that fakes the system under integration asserts
+  that the fake behaves as expected.
+- **The gate is blocking.** Green is the definition of done; a change that has not run its tests
+  is not finished, whatever the diff looks like.
+
+Not test-driven development as a blanket rule — a test written first against undiscovered
+behaviour asserts a guess. The obligation is that every decision has a defender.
+
 ### Search the record before forming a hypothesis
 
 The first action on any error message, failing service or unexpected behaviour is to search the