A roster whose additive merge resolution does not compile: one-line rows on the two design ledgers

[briansrls]

What this changes

gunbc.recurring_failure_mode and gunbc.rung_drop carry one row per class / per declared drop, and every lane that finds one appends a row. Both authored their rows as multi-line record blocks ending in a suffix every other row also ends in — evidence: [], / } on the first, } alone on the second.

A three-way merge never includes a shared suffix in the conflict region. Measured with git merge-file against dag/gunbc/recurring_failure_mode.dag at merge base d0009ca531, two synthetic lanes each appending one row: the region opens at both lanes' data line and closes after their authored: line, leaving ONE tail below the markers for TWO half-blocks above them. The purely additive resolution — delete the markers, keep both sides, which is the correct resolution when two lanes named two independent classes — gives the first row's closing lines to the second.

This makes each row one line. A one-line row has no tail to lose: the only suffix a merge can factor out of the region is the blank separator between rows, which carries nothing, so both sides of every region are whole declarations and the additive resolution is total. Re-measured in the same lab after the transform: confirmed.

The property generalises past these two carriers: what makes the additive resolution total is that the growth surface's unit has no tail below its last authored field, which is a shape fact about the row, not a fact about failure modes or rung drops.

The discriminating pair (same instrument, one arm before and one after)

Both against a gunbc built from source at d0009ca531:

arm	input	result
RED	byte-exact mis-resolved pre-fix file	module index refused: 1 unparseable .dag source(s) / dag/gunbc/recurring_failure_mode.dag:65912-65913: expected expression, found Eq, exit 1
GREEN	same two-lane git merge-file, same additive resolution, against the post-fix carrier	parses, evaluates, and both appended rows render in the projected ledger

The merge still conflicts after the fix — that is correct and unchanged, two lanes did touch one append point. What changes is that both sides of the region are now whole declarations, so resolving it additively loses nothing.

Rung, stated honestly

This is not structural, and the annotation says so where the next appender will read it. The population carries no severable tail, but the shape is not enforced — no lens covers row shape on these carriers — so one hand-authored multi-line row restores the two-line tail and the whole geometry. The invalid state stays writable: mechanically preventable at best. Next-rung trigger, named as the capability: a row-shape obligation decided for every declaration of a growth-surface type rather than observed on the rows that happen to exist. v2.std.decl_index data_decl_type_facts already reads a declared type per declaration; what is missing is a producer carrying each declaration's source extent, sufficient to refuse a multi-line row of such a type at authoring time. Until that exists the shape is a convention held by review and by that paragraph.

What this does NOT claim

The reported class was that a severed row survives as a structurally broken declaration under which the natural check (declared names vs. rostered names) still passes, because both lists stay complete. That half does not survive measurement. The byte-exact resolved file, through a gunbc built from source at d0009ca531:

module index refused: 1 unparseable .dag source(s)
  dag/gunbc/recurring_failure_mode.dag:65912-65913: expected expression, found Eq
exit 1

All three loss states were run, and the set is complete — the two-line tail can be cut three ways and every one is loud: losing both lines and losing } alone are parse refusals at the module index (expected expression, found Eq, a data keyword in record-field position); losing evidence: [], alone is a resolve refusal (missing required field 'evidence' in literal of type 'RecurringFailureMode'). Nothing silent was found in that set.

The executing route is claim_executor phase 1, the .dag parse sweep over ["src/v1", "dag", "src/v2"] on required lane witnesses — the first phase in the job, nothing upstream can abort before it, and a parse error becomes a phase failure. So this class is loud and fail-closed today, and no wall is owed. A brace-balance or name-join check written here would be the §4b decoration: permanently green, because the only corpus it could fire on is one the compiler already refuses.

What is real is the cost, not silent wrongness — a load-bearing authority whose every integration lands a conflict whose natural resolution does not compile, hand-repaired each time. That is what this removes.

Also here

One new row, merge_region_excludes_shared_tail, carrying the recognition rule (for a carrier two lanes append to, ask what suffix the appended units SHARE) and the correction above, per §4b's "every newly discovered error class files or updates one row".

Oracle

The identity / subject / declared / authored strings are carried byte-for-byte; the only projection change is the one new row's sentence and its index entry. DESIGN.md and docs/design-ledgers.md regenerated from the transformed authorities via generated_artifact_gate main_wet (exit 0, 35 artifacts written). The projection diff is 1 added line and 0 deleted lines in each — the new row's index entry and its sentence. Every pre-existing projected byte is unchanged, which is the oracle; the string-extraction equality alone would only have proved the inputs match.

Annotations: no row in either file carried a leading annotation block, so the fold never had to move one. The only §4c blocks in these modules attach to the module head and, in gunbc.rung_drop, to standing_rung_drops — none of them to a transformed declaration. Both files' module-head blocks gain a paragraph recording why the row shape is one line.

Out of scope, deliberately

The conflict pressure — two flat append points mean any two lanes appending collide — is untouched. Removing that is a carrier question (per-row files, as extdeps/vendor/ does), and it would still leave the roster as one shared append point. Its own change, not a side effect of this repair.

The pressure, now dated rather than argued

This branch was conflicted by unrelated lanes twice on 2026-09-01, on a PR whose whole subject is that this file conflicts by construction:

when	what landed on main	conflicted paths
earlier	#9902 appended one recurring_failure_mode row	dag/gunbc/recurring_failure_mode.dag, docs/design-ledgers.md
later	#9906 grew state_space_conflation.authored (2370 → 4766 chars); #9910, #9883, #9904 also landed	same two paths

Neither lane was working on this PR's subject, and neither edit disagreed with anything here — #9902 appended a row, #9906 extended a different row's sentence. That is textual contention at the file's two flat append points standing in for semantic contention that does not exist, which is exactly what the "Out of scope" section below names and deliberately does not fix. The count is extendable: every future integration of this branch adds a row to this table.

Each resolution was verified at identity grain against both parents rather than by inspecting a clean-looking diff — every identity present in either parent present in the result (set difference both directions, not counts), declared ∖ rostered and rostered ∖ declared both empty, and every row's authored bytes present verbatim in the regenerated ledger.

[briansrls]

APPROVE ruling at exact head 4b710358a3e94f8acd7366038f6e1ccd84cc6a01. GitHub cannot register the connected PR-author identity's own formal approval, so this comment records the exact-head adjudication.

The two post-approval deltas close without a new blocker.

ae861f9397 removes the inflated construction claim from both carrier annotations and states the actual boundary: the one-line population exists, but row shape is unenforced and a multi-line declaration remains writable. The next-rung trigger is named at capability grain—the missing declaration-source-extent producer sufficient to decide and refuse multi-line declarations of a growth-surface type. The complete tail-loss set is now measured rather than inferred: both lines lost = PARSE refusal, closing brace lost = PARSE refusal, evidence field lost = RESOLVE refusal. That supports the decision not to add a permanently decorative downstream check.

4b710358a3 supplies the real two-sided witness previously owed. Its parents are the corrected PR side ae861f9397 and main 1fc2dec1ea, where #9902 independently appended mitigation_injected_where_judgment_declined to the same growth surface. The result preserves the main row and roster entry over the PR parent with no deletion, preserves the PR row over the main parent, and regenerates the projections as the union: 31 declared rows, 31 rostered identities, empty join differences. This is the requested live union-preservation witness, not a synthetic substitute.

The limit is held correctly: one successful live merge corroborates the repair but does not enforce the row shape or raise its rung. Run 33481728337 is green on this exact SHA—five successful jobs, with only the unrelated qualification battery skipped—and the PR is mergeable.

No blocking concern found. Nothing further is owed for this PR.

[briansrls]

APPROVE ruling at exact head e2f896f03fb3126ac695626aed444e4047c08d19. GitHub cannot register the connected PR-author identity's own formal approval, so this comment records the exact-head adjudication.

This head is a merge-only advance from the previously approved 4b710358a3, with second parent 03890cbcc0. The PR-relative surface remains the same four paths and the substantive change remains the one-line carrier shape, its honestly stated mechanically-preventable rung, and the new failure-mode row.

The live conflict is admissibly resolved: main's expanded state_space_conflation.authored content is retained under the branch's one-line declaration shape, and the generated ledger is regenerated rather than byte-resolved. The reported bidirectional parent-union census closes the only material merge risk: every parent identity survives, no foreign identity appears, the declared/rostered join is empty both ways, and the regenerated projection retains every main-authored row byte-for-byte.

Exact-head workflow run 33500077335 succeeded, including both required lanes, Rust tests/clippy, fabric evidence, and the aggregate check; the PR is mergeable.

One evidence classification: the fixed-point receipt whose referenced_at remains 4b710358a3 is not exact-e2f896f03f fixed-point evidence and is not counted in this approval. It does not block this PR: the branch-relative diff contains no stage0 seed change, and the exact-head required first-generation regen phase is green. The discovered chained-flag/wrapper-exit defect is real and must not be inherited by BT-0's bootstrap recipe, but it is not a defect in #9898.

No blocking concern found. Nothing further is owed at this head.