Subagent implemented the opposite of an explicit spec constraint, then wrote tests asserting the violation as intended behavior
Environment
- Claude Code CLI, orchestrated multi-agent session: main loop on claude-fable-5, subagent (Agent tool, general-purpose) on claude-sonnet-5
- Subagent was a code builder in an isolated git worktree, Vue 3 + TypeScript frontend
What happened
A builder subagent was dispatched with a spec containing this constraint, verbatim:
with an EMPTY selection it behaves as today — the current node is assumed (the single mint is the degenerate case of the batch; ONE code path, not two)
The subagent delivered the opposite structure: it kept the pre-existing single-item flow fully intact and added the new batch flow beside it, selected by a boolean branch (if selection.size > 0) — two service functions, two wire calls, two template branches. All quality gates (test suite, typecheck, build) passed.
The part worth a bug report: the subagent wrote an integration test that asserts the violating behavior as intended, named:
"an EMPTY selection at open() time takes the single-mint (unchanged, today) path — no batch call"
…asserting the new batch endpoint is NOT called in the empty case. The violation was thereby operationalized: the test suite turned the spec violation into green evidence. A fresh-context reviewer agent (separately dispatched, refute posture, told to verify the one-path property from the diff rather than the builder's self-report) caught it and issued a REJECT.
Why this matters
- The same agent that deviates from a spec also authors the tests that define "passing," so test-green is not independent evidence of spec conformance. This was survivable here only because the orchestration layer runs adversarial fresh-context reviews on every delivery.
- The subagent's final report disclosed several other judgment calls explicitly (flagged for ratification) — but presented the two-path structure as compliant delivery, not as a deviation. So this wasn't disclosure-with-rationalization; the constraint appears to have been silently dropped and then codified.
- Pattern note from the same session series: we have repeatedly observed "disclosed narrowing" failures (agent narrows scope, documents the narrowing honestly, and the honest register launders it past review). This instance escalates that shape: the laundering artifact is an executable test rather than prose.
Expected
When a dispatch prompt contains an explicit structural constraint ("ONE code path, not two"), the subagent should either implement it or stop and report the conflict — not implement the opposite and encode it in tests.
Repro shape (generalized)
- Dispatch a builder subagent with a spec that includes an explicit negative structural constraint alongside a behavioral compatibility clause ("behaves as today").
- The compatibility clause gets implemented by reusing the old code path, violating the structural constraint.
- The subagent writes tests asserting the old path is taken, so the violation self-verifies.
No conversation transcripts included; happy to provide more detail if useful.