Filed unassigned from the #8344 measurement (PR #8359). Observation-class: narrow trigger, no silent loss, and it is already visible to the author locally. Recording it because #8344's answer depends on it and nothing writes it down today.
What was measured
#8344 asked what the merge queue's driver-less, server-side rebuild does to the two unsharded ADR-0087 projections. Full method, inputs and table are in PR #8359. The part that belongs here is a by-product:
Every case in which those projections conflict server-side, packages/spec/src/migrations/registry.ts conflicts too — and it conflicts in the driver-registered local clone as well, because it is deliberately NOT_DRIVER_MANAGED.
two entries in flight, adjacent in registry id sort order:
driverless (queue) CONFLICT protocol-upgrade-guide.md + spec-changes.json + registry.ts
driver ON (local) CONFLICT registry.ts
one existing entry between them:
driverless (queue) clean, and the check: gates pass on the un-regenerated result
Trigger is exactly gap 0 — nothing between the two ids. One existing entry between them is already enough to merge clean.
Why it is worth a note rather than a fix
#7297 split entries/ one file per entry and removed the collision at the source. registry.ts is the generated concatenation of that directory, and it is still a single committed file, so the collision reappears in the artifact whenever the two entries land adjacent in the sorted output. entries/README.md argues "conflict-free by construction"; that is true of the sources and not of the file they generate.
Two things keep this from being urgent, and both are measured rather than assumed:
- It is not silent. The local driver defers the two projections but leaves
registry.ts conflicted, so the author sees the collision before pushing — unlike the set-semantics hazard entries/README.md describes, where a dropped entry produces no error anywhere.
- It is narrow. Adjacency in id sort order, among 68 semantic entries in the current major, with two registrations in flight at once.
What a fix would have to be
Not sharding the projections — PR #8359 measures that as buying back zero ejections while this file still conflicts. The options are to shard registry.ts itself the way the three hottest artifacts already are, or to stop committing it, and both are larger calls than this finding justifies on its own. #6957's ruling kept the generated projections in version control on purpose, so "stop committing it" runs against a live decision.
Related: #8344, PR #8359, #7297, #6957, #7464 (the same question asked of conversions/registry.ts).
Generated by Claude Code
Filed unassigned from the #8344 measurement (PR #8359). Observation-class: narrow trigger, no silent loss, and it is already visible to the author locally. Recording it because #8344's answer depends on it and nothing writes it down today.
What was measured
#8344 asked what the merge queue's driver-less, server-side rebuild does to the two unsharded ADR-0087 projections. Full method, inputs and table are in PR #8359. The part that belongs here is a by-product:
Every case in which those projections conflict server-side,
packages/spec/src/migrations/registry.tsconflicts too — and it conflicts in the driver-registered local clone as well, because it is deliberatelyNOT_DRIVER_MANAGED.Trigger is exactly gap 0 — nothing between the two ids. One existing entry between them is already enough to merge clean.
Why it is worth a note rather than a fix
#7297 split
entries/one file per entry and removed the collision at the source.registry.tsis the generated concatenation of that directory, and it is still a single committed file, so the collision reappears in the artifact whenever the two entries land adjacent in the sorted output.entries/README.mdargues "conflict-free by construction"; that is true of the sources and not of the file they generate.Two things keep this from being urgent, and both are measured rather than assumed:
registry.tsconflicted, so the author sees the collision before pushing — unlike the set-semantics hazardentries/README.mddescribes, where a dropped entry produces no error anywhere.What a fix would have to be
Not sharding the projections — PR #8359 measures that as buying back zero ejections while this file still conflicts. The options are to shard
registry.tsitself the way the three hottest artifacts already are, or to stop committing it, and both are larger calls than this finding justifies on its own. #6957's ruling kept the generated projections in version control on purpose, so "stop committing it" runs against a live decision.Related: #8344, PR #8359, #7297, #6957, #7464 (the same question asked of
conversions/registry.ts).Generated by Claude Code