File the failure class #10560 repaired: a field carried on arms where it has no meaning

[gunbai-bot]

#10560 repaired a real defect and never rostered its class, so nothing carries the recognition rule for the next carrier that has the same shape.

The class

A carrier is a record whose fields are computed independently, and one field is meaningful on only some of the situations the carrier represents. A record has no arms, so that field must be given a value even where it denotes nothing — the author supplies whatever the type admits, and the resulting pairing is a claim nobody made and nothing refuses.

The receipt (review 57275, #10560)

gunbc.cli_wire.CliWireResponse was { write: TerminalWriteProjection, exit: ProcessExit }. A projection that refused could therefore be paired with ExitSuccess, so a verb printed nothing and reported success — fail-open at the output boundary, where an operator's only signal is the exit status. Reachable, not theoretical: a commit message is an unrestricted String on CommitLogRow and is rendered directly into a log row, so an ESC byte makes project_terminal_write refuse while the read answered fine.

The defence of the record is a true sentence about a neighbouring question, which is why this shape survives review. Bytes and exit status genuinely are two facts — a refused repository must print its diagnostic and exit nonzero. What does not follow is that the exit is independent of whether there are bytes at all. "The exit is not derivable from what the bytes say" and "the exit is unconstrained by whether there are bytes" are different claims; the first is true and the second is false.

Why its own row and not an origin on a neighbour

• Against subject_and_its_digest_as_independent_parameters: there the two fields are a value and a summary of it, and the repair is derivation at the point the value is obtained. Here they are independent facts, one only defined when the other exists; no derivation joins them.
• Against kind_carried_but_its_fields_stay_optional, the dual, cross-cited in both directions: there an arm needs a field the carrier does not guarantee and the repair requires it; here an arm carries a field it must not have and the repair deletes it. Same law — a carrier's field set belongs to its arms — read from opposite ends. Filing either under the other would make one identity a nickname for both, and their recognition rules and repairs differ.

Recognition rule

Asked of the carrier, not of any call site: for every field of a record, enumerate the situations the record represents and name what the field means in each. A situation whose honest answer is "nothing" is an arm the record is missing, and the value currently supplied there is a fabrication with a type. The tell that survives longest is a field whose only defensible value on some situation is a neutral-looking one — success, zero, empty — because that is the value a reader who sorts, thresholds or branches on the field reads as a measurement rather than as an absence.

Rung

The cli_wire instance reached structural impossibility, so what is enrolled here is the class, not a stall: CliWireUnprintable has no exit field to set to success, and there is no check to run because there is nothing to check. The next-rung trigger for the corpus population is stated as a capability — a census that, per record carrier, resolves the situations its producers can be in and refuses a field unconstrained on one of them. That is the same fold kind_carried_but_its_fields_stay_optional names from its end, and neither row retires until it can ask both directions.

docs/design-failure-modes.md is a generated projection and is deliberately not regenerated here; heal-generated-artifacts derives it. (The local gate cannot run on this tree at all — src/v2/lens/module_graph.dag fails to resolve on current main, unrelated to this change.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQ4iThiZ1B9LPB9ePr8qa9