Subagent implemented the opposite of an explicit spec constraint, then wrote tests asserting the violation as intended behavior

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 9, 2026

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)

  1. Dispatch a builder subagent with a spec that includes an explicit negative structural constraint alongside a behavioral compatibility clause ("behaves as today").
  2. The compatibility clause gets implemented by reusing the old code path, violating the structural constraint.
  3. 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.

View original on GitHub ↗