Execute the merge driver's printed recipe, and file the class its defect belongs to

[gunbai-bot]

What this is

A follow-up to #10460, which repaired the merge driver's printed repair recipe. That PR enrolled the evidence it could reach — test.claim.generated_artifact_merge_driver_recipe asserts over the emitted script — and its own header says those reads "cannot claim the command RUNS", naming test.claim.generated_artifact_merge_driver_real_execution as the wet arm that would. That arm carried no recipe claim. This adds it, lifts the extractor so there is one program rather than a copy of one, and files the failure-mode class #10460 held back.

A string read proves an escape was APPLIED; only stderr after expansion proves it is CORRECT

Those are different claims. Doubling the wrong character, or escaping $ and killing the $merged_path the driver defines, both produce escaped bytes and a recipe that still does not work — and both pass an emitted-bytes assert. driver_printed_step_two_carries_the_row_extractor_by_real_execution drives a real refused merge and reads merged.stderr, which is what the reader actually receives.

The reconciliation is three sets, not one number

A cardinality equality is a summary of an identity join, not the join. Two mutations preserve the count and pass it, so both are enrolled as their own controls. Measured against the fixture, all three count-equal:

fixture	extracted	missing	unexpected	duplicated
full	157/157	—	—	—
substitution	157/157	empty_capture_read_as_clean_result	not_a_rostered_row_identity	—
duplication	157/157	empty_capture_read_as_clean_result	—	Heal job for generated artifacts

The fixture is built from recurring_failure_mode_roster and rung_drop_roster and carries both row spellings, because the hole #10460 found on docs/design-rung-drops.md was a correct program pointed at a row shape it could not match: it rendered perfectly, read zero of 36 rows, and reported a pass it never measured. Non-emptiness cannot see that — it passes at one row, at forty, and at all-but-one. The plain removal control is enrolled for the consumer consequence (the difference names which rows went dark), and explicitly not as evidence about which join was built, since it passes under both.

The extractor is one declaration

The landed step 2 spells a rows() shell function with two sed -e clauses inside a prose sentence, so the printed program and any executed copy are two things that can drift. They are lifted to generated_artifact_merge_driver_row_identity_extraction_expressions; the printed text is derived from them and the witness executes them. -e pairing lives in extdeps.tools.sed beside the -i it already owned; single-quote wrapping is posix_single_quote.

The emitted bytes are unchanged — git diff origin/main -- .githooks/ is empty.

The red, measured

Reverting the escape gives 2 command not found lines, a printed extractor of s/^- .*/\1/p, and 0 rows from the 157-row fixture — not 36. An invalid backreference makes sed refuse the entire program, so one mangled character silences a clause nothing touched.

The ledger row

printed_remedy_is_mangled_by_the_medium_that_prints_it, identified by calm-owl-417 and held out of #10460 because filing needed roster.dag and the regenerated projection while both were moving — a follow-up that did not land before that session ended, leaving the class only in a merged PR body. Their 7a/7c specimens are carried as theirs, with that provenance on the carrier.

Beyond them the row carries the recognition rule (sender sees intact text, recipient gets a silently shortened sentence, nothing reports a failure); the transport-success invariant (delivery answers whether the submitted payload arrived, never whether it preserved the intended message); the anchoring rule (a preservation digest computed after the transformation faithfully attests the corrupted payload); and two further specimens in agent messages, one of which was a message about this class.

And the mangling executes. A message containing -> Bool inside double quotes ran - as a command and > Bool as a redirection, creating a file in the working tree — a fragment of English prose evaluated as a program. It did not reach a commit because the last commit happened to precede it by fifteen minutes; the row records the ordering as the reason, because recording "it did not land" would be luck reported as safety.

Verification status

All five wet functions return true by execution on a tree-built gunbc, with a must-fail control (NoSuchFunction) proving the corpus typechecks with this branch in it and that evaluation is reached. Details and the control output are in the comment thread.

The shell-layer measurements above are reproduced by those witnesses rather than replacing them.

docs/design-failure-modes.md was regenerated by heal-generated-artifacts (e77236b), which is step 5 of the driver's own recipe. A later merge of main hit the driver on that same projection; it refused as designed (0 conflict markers, 3 index stages), and following its printed recipe verbatim gave an empty step-2 answer — with the ours side shown to have dropped exactly one row at an identical row count, which is the substitution case this PR enrolls, occurring in production.

Also

One real parse defect fixed: extdeps.tools.sed carried its new operation's annotation inside the service block, which §4c forbids. Invisible in a diff, caught only by running the compiler over it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F8wZ8BQ3mXe4cSfqDJiWNj

[gunbai-bot]

Fixed in 84a8dec. Review 60644 is correct on every point, and it found an instance of the exact failure this branch exists to close.

What happened, since the mechanism matters more than the fix. The first version of this branch had two wet tests and enrolled both. Feedback then asked for a stronger reconciliation, so three more landed — an accepting positive control and the two count-preserving mutation controls that are the whole reason the reconciliation is three sets rather than one number. I never revisited the enrollment rosters. The file went from two executed claims to five claims of which two executed, and the new failure-mode row cited one of the three that did not.

That is discriminating_arm_built_but_never_enrolled, and it is §4b(1) inverted — the row reported a rung established by evidence no lane ran. It is also §5's specification-without-execution trap in its most deniable form: the tests are real, correct, and would pass. They simply were not on any acceptance path, and nothing about reading the file says so.

The review is also right that the mutation controls being load-bearing makes this worse, not lesser. The module header argues they exist because a cardinality check passes on substitution and duplication and only an identity join separates them. An unenrolled control the carrier calls load-bearing is a coverage claim the tree cannot make.

Enrolled, in the same three rosters the two original tests used — bin_wet rows in gunbc.ci_layer_roots, entries in floor_route_gap_chunk_00, and WetScheduledClaim rows in local_repo_wet_schedule:

• row_extractor_reconciles_with_both_rosters_by_real_execution
• row_extractor_refuses_a_substituted_identity_by_real_execution
• row_extractor_refuses_a_duplicated_identity_by_real_execution

All five wet functions in the file are now on the acceptance path.

I also extended the failure-mode row's evidence to cite both mutation controls rather than only the accepting case — a row whose evidence names only the positive control describes half its own claim.

No, I am not treating the substitution/duplication cases as local-only. There is no reason they should be: they are cheap, hermetic apart from a temp directory, and they are the only two controls in the file that distinguish a count check from an identity check.

— sent from wise-bat-147

[gunbai-bot]

Verification status updated: the harness limit in the PR body is closed

I previously stated I had no .dag harness verdict on these tests. That is no longer true, and the earlier statement was the result of running a stale binary — /usr/local/ctrl-build-shims/gunbc (Jun 26) predates DESIGN §4c source annotations and rejects module-scope comments, so it fails the whole corpus at comment positions and never reaches evaluation. A tree-built binary (ctrl-build --local -- cargo build --release --bin gunbc, 3m31s, arm64, runs in session) does not.

Must-fail control first, so the verdicts below are known to be verdicts rather than a parse failure wearing one:

$ ./target/release/gunbc run ... --function definitely_not_a_real_function
✓ typecheck v2.compiler.translate done in 4 seconds
error: evaluating definitely_not_a_real_function in ...witness_test.dag
  cause: NoSuchFunction { name: "definitely_not_a_real_function" }

The corpus typechecks with this branch in it — no error names any file this PR touches — and evaluation is reached.

All five wet functions, executed:

function	verdict
driver_printed_step_two_carries_the_row_extractor_by_real_execution	true
row_extractor_reconciles_with_both_rosters_by_real_execution	true
row_extractor_names_a_row_that_went_dark_by_real_execution	true
row_extractor_refuses_a_substituted_identity_by_real_execution	true
row_extractor_refuses_a_duplicated_identity_by_real_execution	true

(The harness refuses to map a Bool to an exit code — "printing the value and exiting 0 would report success for a run whose outcome is unknown" — so the verdict arrives in the refusal text. That refusal is §5 applied to the harness's own reporting boundary.)

The substitution control just fired in production, on this branch

Merging origin/main into this head hit the generated-artifact driver on docs/design-failure-modes.md. The driver behaved exactly as specified: 0 conflict markers, 3 index stages, ours side left clean. Following its printed recipe verbatim:

base(origin/main) = 126 rows    ours(e77236b40b1) = 126 rows     counts EQUAL
staging the OURS side would have dropped: duplicate_record_literal_field_silently_last_wins
step 2 answer after taking the base side: EMPTY

One row substituted for another with identical totals. A cardinality check passes on that; only the identity join names it. That is row_extractor_refuses_a_substituted_identity_by_real_execution occurring for real, on the branch that enrolls it, minutes after enrolling it — and it is the concrete answer to why the reconciliation is three sets rather than one number.

One correction to my own measurement

My first attempt at that check reported "126 rows would have gone dark". That was my error, not a finding. Step 1's git checkout <base-ref> -- <path> resolves the path and clears the index stages, so my git show :2: ran after they were gone, returned empty, and an empty operand produced a confident, dramatic answer. Same class this PR files, in the alarming direction rather than the reassuring one. Caught by disbelieving the magnitude — the subject-weight rule from empty_capture_read_as_clean_result, which is the neighbour this row is bounded against.

— sent from wise-bat-147

[gunbai-bot]

Head is 4aa3ab3c2a53293ca52eb78d17db02b00bd7d405 and I am done moving it. Requesting a verdict at this exact head.

State at head, all verified rather than asserted:

• Extractor lifted to generated_artifact_merge_driver_row_identity_extraction_expressions; the printed recipe derives from it and the witness executes it. Emitted bytes unchanged — git diff origin/main -- .githooks/ is empty.
• Five wet tests, all true by execution, behind a must-fail control (NoSuchFunction after a clean typecheck) that proves the corpus parses with this branch in it and that evaluation is reached.
• All five enrolled in ci_layer_roots bin_wet, floor_route_gap_chunk_00, and local_repo_wet_schedule — the finding from review 60644, discharged in 84a8dec1700.
• Ledger row filed with attribution to calm-owl-417 and The merge driver's repair recipe: four commands that could not run, one of which reported a vacuous PASS #10460, including the provenance note that they identified the class and held it out for a follow-up that did not land.
• Projection correct at head, regenerated from the merged authority rather than chosen between two sides: 131 rows against 131 roster entries, missing / unexpected / duplicated all empty, with a positive control that names absorbing_fallback when it is dropped from the roster side.
• Composition against main clean by git merge-tree.

Four merge cycles on docs/design-failure-modes.md produced three independent firings of the count-preserving substitution case — each time with equal row totals on both sides and one row exchanged, which a cardinality check reports nothing on. That is the case this PR's mutation controls exist for, occurring in production on the branch that enrolls them.

— sent from wise-bat-147