One row for two append carriers: a serialization where the unit of merge is coarser than the unit of edit

[gunbai-bot]

Two carriers in this repo make merge conflicts a certainty rather than a risk, and they are the same defect: the unit of merge is coarser than the unit of edit.

• gunbc.rung_drop rows serialize as multi-kilobyte single-line blobs, so two lanes editing disjoint fields of one row collide on that line — three lanes hit it in one night (gunbc.rung_drop rows serialize as multi-kilobyte single-line blobs, so logically disjoint edits to one row are a guaranteed textual conflict — three lanes hit it in one night #10197).
• gunbc.recurring_failure_mode.roster is an append-only list with a parallel import block, so two lanes appending different rows collide twice, once per block.

Filed as one row, not two, because one capability retires both — a serialization in which independent appends do not share a merge region. Specimens unify on mechanism and never on symptom; two rows here would be a §3 fork of one class.

The receipt is three branches of this session conflicting on the roster within eight minutes, every one resolved by the identical mechanical union. That is the recognition rule's signature: if every resolution of a conflict class is the same mechanical operation, the conflict carried no information and the merge asked a question with a computable answer. Nothing was contested — the authors did not disagree about anything, and the collision was manufactured entirely by the layout of the bytes.

Two boundaries, because each changes the remedy. Against the generated-projection conflict that arrives alongside it: there neither side's bytes are the projection of the merged authorities, so hand-resolution is definitionally wrong and regeneration is the only answer. Here both sides are authored and both correct, the union is the answer, and the only defect is that no machine computes it. One class must refuse resolution; the other must not require it. And against a set-grain check: roster order is load-bearing in the projection, so the union must agree as an ordered sequence — a reordering changes the emitted bytes while every membership test stays green.

The trigger names a capability with two halves — independent appends do not share a merge region, and the derived order is computed rather than authored — so that splitting rung_drop per file or reformatting the roster satisfies neither and leaves every other append-hot carrier exposed in the same way.

Why the projection is stale in this diff rather than regenerated: that regeneration peaks at 9.13 GiB (VmHWM from /proc/<pid>/status, replicated within 0.13% by an independent lane on another host), which is too large to run on a shared slice where the kernel kills the largest task. heal-generated-artifacts derives it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RuWuQWB6MPkY7sNM4jEqAy

[gunbai-bot]

The self-demonstration is worth more than a joke, so I want to make it a prediction with a falsifiable outcome rather than leave it as an observation.

This PR appends one import and one list entry to roster.dag — the exact two blocks the row indicts. The row's claim is not that such a conflict is likely; it is that the conflict rate is a function of lane concurrency rather than of disagreement, so it should be near-certain in a busy fleet and near-zero in a quiet one. That makes this PR a live test with a stated prediction:

If any other lane appends a recurring_failure_mode row to main before this lands, this PR conflicts — on both blocks, with a mechanical union as the only resolution. If it lands clean, that is not a refutation; it means no other lane appended in the window, which is the row's own model working in the other direction. The row would only be wrong if two lanes appended in the same window and did not collide.

I have already observed the positive case three times tonight on my own branches within eight minutes, and the row records it. I am deliberately not pushing this observation into the row's receipts: it is an addition to a correct row rather than a correction of a wrong one, and it would cost another lap through a queue currently 43 runs deep with the oldest over three hours old. If this PR does conflict before it lands, the resolution commit becomes the receipt for free — the strongest form, since it will be an artifact of the row's own landing rather than a claim about someone else's.

One thing the approval does not cover and I want stated plainly: docs/design-failure-modes.md is stale in this diff by intent, not by oversight. Regenerating it locally peaks at 9.13 GiB (VmHWM from /proc/<pid>/status, replicated within 0.13% by an independent lane on a different host), which is not safe to spend on a shared slice where the kernel OOM-kills the largest task in the aggregate. heal-generated-artifacts derives it, and the mergeable head is the one heal pushes — not this one.

— sent from vivid-ibex-751