Loomworks — standing note: the mechanism that makes something safe in one dimension hides the failure in another — v0.1

Version. 0.1 Date. 2026-08-07 Author. Claude Code (CR-2026-178 execution session). Operator: Marvin Percival. Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. Origin. Two defects found within one day of each other, in unrelated subsystems, with the same shape. Reads with. standing-notes/loomworks-standing-note-spend-context-built-at-the-gate-v0_1 (the first instance); inspection-briefs/loomworks-b32-findings-v0_1; the walk audit's W-2 and its correction note.

The principle

A mechanism introduced to make something safe along one dimension will often hide failures along another — and the hiding is invisible precisely because the mechanism is working correctly.

This is not a claim that safety mechanisms are bad. Both mechanisms below are correct and should stay. The point is narrower and more useful: when you add one, ask what it now prevents you from seeing, and put the answer in writing next to it.

The two instances

1. Test isolation blinded the suite to uncallable routes (B-27 / B-30)

conftest overrides get_llm_client_with_engagement_fallback with a stub so tests never reach a real Anthropic client. Correct, and necessary for a hermetic suite.

But that dependency is path-scoped — it declares engagement_id: UUID = Path(...). A route that reaches it without an {engagement_id} segment is uncallable from birth and 422s every request. The stub has no Path(...) parameter, so under override the very thing that breaks the route is absent. The route answers 200 in tests and 422 in production.

Measured during CR-2026-178, not assumed. A throwaway route carrying that shape was mounted on the real app. A dependency-graph check flagged it instantly; a request-based test against the same route in the same run received HTTP 200.

POST /me/engagements/create-from-conversation shipped in exactly that state and 422'd every caller from the day it was mounted. The engine's own comment recorded the cause plainly: "test suites never saw it because conftest overrides that dependency."

2. Unit coverage of the gate blinded the suite to unmetered spend (CR-2026-177)

test_phase_64_room_gate.py calls gated_room_complete directly with room="manifestation" and passes. Correct, and it proved the gate itself worked.

But preview_manifestation accepted a spend context and never forwarded it, so nothing ever reached the gate on that path. Every Manifestation LLM call ran unmetered, and the route's 402 handler was unreachable. A green gate test says the gate works; it never says anything arrives at it.

The common shape

| | B-30 | CR-2026-177 | |---|---|---| | Mechanism | dependency override (hermetic tests) | direct unit test of the gate | | What it secures | no live API calls in the suite | the gate's own logic is correct | | What it hides | the dependency that makes a route uncallable | that nothing reaches the gate | | Failure direction | open — route looks fine in tests | open — feature works, charge missing | | Why unnoticed | the mechanism was working as designed | the mechanism was working as designed |

Both fail open. Neither produced a red test, an error, or a log line. In both cases the evidence of correctness — a passing test — was generated by the same machinery that suppressed the evidence of failure.

How to apply

When you stub, override, or fake something, write down what that substitution now makes invisible. A stub is a claim that the real thing does not matter for this test. That claim is often true and occasionally load-bearing; the docstring is where it gets checked.
Prefer checks that inspect structure over checks that exercise behaviour, when the defect lives in the wiring. The route guard reads the resolved dependency graph rather than issuing requests, because the graph is the one vantage point the override does not reach. Structure-checks are also the ones most likely to be "simplified" into behaviour-checks later by someone who does not know why — so say why, in the test.
A unit test of a component is not evidence that anything calls it. Where a component is a gate, a guard, or a check, the load-bearing test is the one proving it is reached from the real entry point. Test the seam, not only the part.
Prefer failures that fail closed. Where a mechanism can fail open — a dropped spend, an unreachable handler, a route that never runs — that specific direction needs its own explicit test, because nothing else will notice.
Two instances is a class. These were found a day apart in unrelated subsystems by unrelated investigations. Treat the pattern as present elsewhere and unfound rather than as two coincidences.

Why this is recorded as its own note

The spend-context note records a design rule: build the context at the gate so it cannot be dropped. This note records an epistemic one: what a green suite is and is not evidence of. They generalise in different directions from the same finding, and collapsing them would lose the second — which is the one that transfers to subsystems with no spend context and no routes at all.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — standing note: safety mechanisms that blind — v0.1 — 2026-08-07