Every feature branch appends to the end of roadmap-3.0.yaml, so each merge conflicts all the others

[avrabe]

Structural friction, measured over one loop session rather than guessed at. Not urgent, but it compounds with parallelism and it has a cheap fix.

What happens

artifacts/roadmap-3.0.yaml is a single 1600-line file, and a new feature is added by appending a block to the end. So every feature branch edits the same final lines.

The result, from this session:

• 6 PRs open at once, five of which add a FEAT.
• Merging FEAT-076 (#132, #133): the release machinery stops failing silently #134 immediately put FEAT-077 (#123): two-tier function identity — unique stripped name, else raw name marked build-local #137 and FEAT-078 (#116): wasmtime 45 → 47 — four of five advisory ignores go stale #138 into CONFLICTING.
• Each needed a rebase and a hand-resolved conflict whose entire content was "both sides appended a different, valid block to the same position."
• FEAT-079 (#121): every havoc'd region records a gap — close the laundering hole #139, Wire the dev V-model's right side: VER-001..015 verification backlinks (15/21 verified, 6 honestly open) #140 and FEAT-080 (#141): CI actually runs the analyzer's tests, plus a guard that keeps it that way #142 will hit the same thing as each earlier one lands.

That is O(n²) conflict resolutions for n parallel branches, none of which represent a real disagreement about anything.

It compounds with the id race

Artifact ids come from the same shared namespace with no reservation mechanism. In this session a subagent branching from main picked FEAT-076 because it was genuinely free on main — while another open PR had already claimed it. That cost a rename (FEAT-076 → FEAT-077) and made the subsequent rebase harder, because the rebase replays the pre-rename commit and lands the rename on the conflict boundary.

So one file gives two independent failure modes for parallel work:

	mechanism	caught by
append collision	same end-of-file position	git, at merge — noisy but safe
id collision	no id reservation	nothing, until both land — rivet validate only sees it after the second merge

The second is the dangerous one: it is silent until it isn't.

Cheap fixes, roughly in order of effort

1. Split by release. artifacts/roadmap-v3.2.yaml, -v3.3.yaml, -v3.4.yaml. rivet already loads artifacts/*.yaml, so this is a pure file move. Branches targeting different releases stop touching the same file at all — which is most of them.
2. One file per feature for new work (artifacts/features/FEAT-081.yaml). Eliminates append collisions entirely, at the cost of more files.
3. An id-reservation check — a CI step that fails if any artifact id in the PR already exists on main. Cheap, and it converts the silent failure into a loud one. Worth doing regardless of 1 or 2.

(3) is the one I would do first even if the file is never split, because it addresses the failure mode git cannot see.

Not a rivet bug

rivet handles multi-file artifact sets fine; this is entirely a repo layout choice that was reasonable when work was serial and stops being reasonable under parallel branches. Filing here rather than upstream.

[avrabe]

Fix (1) is now measured, not just proposed. A merge into main just ran the experiment for free.

After merging #138, with five PRs open:

PR	touches roadmap-3.0.yaml	mergeable
#139	yes	CONFLICTING
#142	yes	CONFLICTING
#145	no — roadmap-v3.5.yaml	MERGEABLE
#146	no — roadmap-v3.2.6.yaml	MERGEABLE
#147	no — claims.yaml + docs	MERGEABLE

3 of 3 separate-file PRs survived the merge; 0 of 2 appending PRs did. Clean split, no exceptions.

That is the whole of fix (1) demonstrated on live branches rather than argued: rivet already globs artifacts/*.yaml, so putting a release's features in their own file is a pure move that removes the collision entirely. The three PRs above were written that way deliberately after this issue was filed, and they are the control group.

Running total for the session: four hand-resolved conflicts on roadmap-3.0.yaml, every one of them "both sides appended a different valid block to the same position", plus one where the boundary cut mid-expression and produced a non-compiling merge until I caught it.

Fix (3) — the id-reservation check — is still the one I would do first regardless, because it addresses the failure git cannot see. This experiment only covers the noisy half.