File the class #12020 repaired: a termination contract met by a trimming transport

[gunbai-bot]

Scope changed after #12020 landed. This PR is now one ledger row and no behaviour change.

I was dispatched to repair test.claim.mtcollins1_census_image_local_wet.the_rendered_program_runs_and_its_output_parses_by_real_execution, red on main and refusing the merge queue for #11829. While I was verifying, #12020 landed the same diagnosis and a better repair. The blocker is fixed on main; nothing here fixes it. My claim-side repair is dropped — this branch now differs from main by a single new file.

What both sessions found

Neither the world nor the rendering moved — the reader did.

#11987 gave host_capture_bind the rule "only newline-terminated lines are evidence", grounded: the capture is bound while the host is still writing it over serial, and boot 23 had a half-written workload-write-rc= fragment. Independently, extdeps.shell.exec Exec.RunArgv captures through retained_utf8_lossy_trimmed() → .trim_end(), correct for its own consumers. The trim deletes the newline the program really wrote after its envelope END marker; the binder correctly declines to read an unterminated final line; a program that finished writing binds HostCaptureOpen. Exactly one of the module's seven identities refused because production and the six siblings all feed the binder Filesystem.Read bytes, which keep the newline.

I confirmed this in-session before #12020 appeared: control on main's tree, 7 scheduled / 7 terminals, 6 PASS and FAIL on exactly the identity the floor names.

Why my repair is dropped

I had the claim render to a real file via console_device and read it back with Filesystem.Read — the production medium. That works and keeps every red, and it is the worse repair: it leaves host_capture_bind still inferring a fact about the writer from the bytes. #12020 declares it instead — HostCaptureText = HostCaptureLiveStream | HostCaptureCompletedTranscript on the binder's input, one scan, host_capture_bind unchanged for existing consumers. That is the earliest boundary that could not be justified (DESIGN §6b), and a live stream cut mid-line is byte-indistinguishable from a trimmed transcript, so the reader was never entitled to guess. Two structures answering one question is the §3 fork; theirs is landed and correct, so mine goes.

What this PR keeps

#12020 filed no recurring_failure_mode row, and DESIGN §4b makes that an obligation for every newly discovered error class. This adds gunbc.recurring_failure_mode.a_termination_contract_is_met_by_a_trimming_transport, written around the repair that actually landed:

• the class, its recognition rule, and why it is quiet (the reader's arm is plausible — "still being written" is what you'd expect of a live capture)
• the generalizing defect: liveness was inferred from the bytes, which cannot carry it
• host_capture_bind: a completed transcript has no unterminated fragment (repairs the wet-lane regression from #11987) #12020 as the repair, cited by symbol, with why the binder input is the right link
• my own claim-side repair recorded as the rejected alternative, because it is the tempting one and it passes its own controls — validation standing where construction was available
• rung: silent wrongness at the composition → structurally guaranteed for this reader by host_capture_bind: a completed transcript has no unterminated fragment (repairs the wet-lane regression from #11987) #12020; not impossible, since both arms wrap a bare String so mislabelling still has a constructor
• next-rung trigger at capability grain, and explicitly not satisfied by host_capture_bind: a completed transcript has no unterminated fragment (repairs the wet-lane regression from #11987) #12020: a captured-text carrier that declares what its transport normalized, reaching every termination-contracted reader — a trigger naming only this binder would be satisfied while the next such reader is still fed a normalized stream
• boundaries against its three nearest neighbours in the ledger

Membership is the directory, so no roster edit and no projection regen. Row resolves with 0 blocking errors.

Two receipts worth keeping: the class was caught only because one claim over the route happened to be a wall, in a lane that was itself fail-open at the time — and two sessions reached the same chain independently, so the cost was in noticing it existed, not in explaining it.

🤖 Generated with Claude Code