Skip to content

migrations/registry.ts still text-merges: two ADR-0087 entries with adjacent ids conflict server-side, which is the residue #7297's source sharding could not reach #8360

Description

@os-zhuang

Restart-when: closed #7464 (decide both registries in one design), or a second adjacent-id registry.ts conflict is measured ejecting a PR from the merge queue

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


Generated by Claude Code

Activity

  1. added theissue type on Aug 13, 2026
  2. hotlong commented on Aug 13, 2026

    @hotlong
    Contributor

    Concentrated findings round (maintainer-directed, 2026-08-13): HELD (finding + domain:spec-tooling unchanged). Type: Task.

    Why held: the card's own measurements argue it — the trigger is narrow (adjacent ids among 68 entries, two registrations in flight), the failure is loud (author sees the conflict locally before pushing; not the silent-loss class), and both candidate fixes (shard registry.ts like the three hottest artifacts, or stop committing it) are bigger calls than the finding justifies, the second running against the live keep-generated-in-VCS ruling (#6957).

    Named restart conditions: ① a second measured adjacent-id conflict actually ejecting a PR from the queue (frequency evidence changes the cost side); ② #7464 (the same question on conversions/registry.ts) being taken up — decide both registries in one design rather than twice; ③ any ruling revisiting #6957. Until one fires, this stays a written-down fact, which is what the filer asked it to be.


    Generated by Claude Code

  3. hotlong commented on Aug 13, 2026

    @hotlong
    Contributor

    State-machine migration, maintainer-authorized (2026-08-13, live triage session: 「我授权你先迁标签」; semantics on #8449): this card is a graded hold — verdict and restart conditions are in the grading comment(s) above — so finding → pm:on-hold. Verdict, restart conditions, domain unchanged.


    Generated by Claude Code

  4. os-zhuang commented on Aug 17, 2026

    @os-zhuang
    ContributorAuthor

    Daily executable-criteria batch (triage seat): Restart-when: leg 1 is now void, not fired — #7464 closed not_planned (2026-08-10), so the "decide both registries in one design" event can no longer occur. Leg 2 (a second adjacent-id registry.ts conflict measured ejecting a PR from the merge queue) remains the sole exit and is still a live, observable condition. Hold stands.


    Generated by Claude Code

  5. os-zhuang commented on Aug 19, 2026

    @os-zhuang
    ContributorAuthor

    Hold-condition rewrite (triage seat, session session_014qTKTqjme5Fp5BH9iRmy6t, on-hold weak-hit audit): the body's leg 1 (closed #7464) was dead on arrival — #7464 closed not_planned on 2026-08-10, 2.7 days BEFORE this condition was written, so the leg is literally true while its intent ("decide both registries in one design") never happened and cannot. The 2026-08-17 triage note already declared it void; this comment makes the rewritten condition the operative one. The hold itself stands.

    Restart-when: a second adjacent-id packages/spec/src/migrations/registry.ts conflict is measured ejecting a PR from the merge queue, or a new open issue re-poses #7464's conversions/registry per-entry-split question, or #6957's keep-generated-in-VCS ruling is revisited

    (The #6957 leg restores the third trigger the 2026-08-13 grading comment named but the body omitted.)


    Generated by Claude Code

  6. claude commented on Aug 24, 2026

    @claude
    Contributor

    on-hold criteria round (triage seat, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): the recorded restart condition "closed #7464 (decide both registries in one design)" is formally hit — #7464 is closed — but it closed not_planned, so the joint-design event the condition actually meant never happened. Not releasing on a letter-of-the-condition hit that contradicts its intent. Rewriting the line to the surviving alternative:

    Restart-when: a second adjacent-id registry.ts conflict is measured ejecting a PR from the merge queue

    (The first alternative is retired with #7464's not_planned closure; if a joint registry design is ever re-opened, that card should name this one.)


    Generated by Claude Code

  7. os-steve commented on Sep 21, 2026

    @os-steve
    Collaborator

    关闭(维护者指令,skills 席 2 代执行;裁决 #202 B)— 2026-09-21T03:43Z

    出处三件(SKILL.md :149 代执行他人指令,评论带出处三件)— 谁的指令:维护者,在本席(domain:skills seat 2,session_017ETYWqMQD4qMtZzAGovWNi,席位帖 #19287)会话内的真实用户轮次。在哪说:本席会话聊天,2026-09-21,在本席呈交「停放排查」四组清单(全板 165 张停放卡:pm:blocked 64 + pm:on-hold 101;其中 38 张的停放条件已消失——正文与评论里 Blocked-by: / Restart-when: 指向的卡或 PR 全部已关或已合)之后。原话(逐字,⛔ 未翻译、未润色):「还有哪些应该解除停放的你一起排查一下」;对四组清单:「同意」。

    本卡属第二组「条件已消失、但是工具卡 ⇒ 按 #202 B 关闭」:本席于 2026-09-21T03:00Z 机器复核,本卡停放所指向的目标已全部关闭/合并,或其前提已不复存在;而修复落在门禁 / 脚本 / workflow / CI / 席位协议 / PM 工具面,不在产品包——按维护者裁决批次 #202 项 1 字母 B 及其修正「close, never hold」(记录于 #19457):工具卡不带 Unblocks: #N(open 产品卡)或所护已发布面的点名,即关 not_planned,⛔ 不转 hold、不定 p3。

    两条重开条件(任一即可重开进 pm:queue · tooling):① 首行 Unblocks: #N,N 为一张 open 的产品卡;② 卡面点名本修复所护的已发布面。卡上已有的测量与分析原样保留,供重开时续用。


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions