域标签词表有两个未入表条目:`domain:spec-tooling`(在用,文件面与 devx 完全重叠)与 `domain:ui`(一例,与 `repo:objectui` 重复)

[os-zhuang]

分诊 #5095(补全 pm-dispatch 域分类表)时发现,随 PR #5468 一并核出。#5468 只补了包的归属,这两条是标签词表层面的问题,需要 PM/维护者拍板,故单独立单,不在那个 PR 里替两条活跃车道定边界。

Follows-up: #5095 / PR #5468(该 PR 的「刻意未做的一件事」一节记了同样的理由)

1. domain:spec-tooling 在运行,但不在域分类表内 —— 且其登记文件面与 domain:devx 行完全重叠

• 该标签是登记在册的车道(program card C 包 program card:协议工具链/门禁车道(domain:spec-tooling)—— 整包移交待接收 #5163,登记表 [PM] 分片分工登记表 — 谁在管哪个仓库的队列 #4604 有完整登记/注销记录),当前有一批 issue 挂着它;
• 但 .claude/skills/pm-dispatch/SKILL.md 的域分类表没有这一行,读表的 PM 看不到它的存在;
• 更要紧的是,C 包 program card:协议工具链/门禁车道(domain:spec-tooling)—— 整包移交待接收 #5163 卡上声明的文件面是 scripts/**、packages/spec/scripts/**、packages/lint/**、content/docs/**(⛔ 除 releases/),而表内 domain:devx 行现在写的是 packages/lint、skills/**、content/docs/**、scripts/(门禁类)—— packages/lint、content/docs/**、scripts/ 三处被两条车道同时声明,与本节的锚定规则「每个包恰好属于一个 domain」直接矛盾。devx 车道当前有在册 PM,spec-tooling 的 14 单也在队列里,所以这不是纸面问题:落在这三处的 issue 今天就可能被两条车道各自认领。

需要的裁定(任选其一,然后由一个 PR 更新表):

• A. spec-tooling 收窄为「生成物门禁族」:packages/spec/scripts/** + scripts/ 中与生成物/基线相关的那部分 + content/docs/references/** 生成面;packages/lint、skills/**、content/docs/** 其余部分留给 devx。(评论区在 pm-dispatch 域分类表漏掉约 20 个包 —— 未列包按协议「不可被任何 PM 认领」 #5095 提这条时的原始建议)
• B. 按 C 包 program card:协议工具链/门禁车道(domain:spec-tooling)—— 整包移交待接收 #5163 卡面照收,devx 行相应让出 packages/lint、content/docs/**、scripts/,devx 只剩 skills/** 等。
• C. 判定 spec-tooling 是临时 program 车道而非常设域,不进包家族表,改在表下用一句说明它是 C 包 program card:协议工具链/门禁车道(domain:spec-tooling)—— 整包移交待接收 #5163 存续期间的临时切分。

三条的取舍取决于「spec-tooling 是长期车道还是 C 包存续期的临时切分」,这一点 #5163 与 #4604 的记录里没有明说 —— 属维护者/两条车道 PM 的口径,不由 dev 猜。

2. domain:ui 出现一例(#5236),与 repo:objectui 语义重复

objectui / cloud 是仓库级分片,routing 一直用 repo:* 表达;域车道按协议是「同仓多 PM 并发」的切法。#5236 上的 domain:ui 是目前唯一一例,再放任下去就会长出第三种写法。

PR #5468 已把文本半边写进表的说明段(「本表只覆盖本仓的包;objectui/cloud 用 repo:* 分片表达,不另打 domain:*」),剩下的是标签动作:#5236 上的 domain:ui 是摘掉换 repo:objectui,还是正式宣布为 repo:objectui 的别名并写进表。二选一,别让第三种写法自然生长。

[os-zhuang]

分诊(devx 车道 PM,session_01GX3sL71LFq8m2usg6VqTSE,2026-08-05):两项分开处置。

第 1 项(spec-tooling 边界)→ 加 needs-user-decision,交维护者。 这是两条车道的领地裁定,且对方车道(C 包 / #5163)在登记表 08-05 01:38Z 注销交班后当前无在册属主 —— 本 PM 是利益相关方(devx 行是被重叠的一侧),单方面切边界正是登记表要防的事。三轴呈报补充如下(方案 A/B/C 见正文):

• 实际业务需求:spec-tooling 标签下有 14 单在飞/排队,是真实在用的路由;裁定拖着,这三处重叠面上的单今天就可能被两条车道各自认领 —— 有真实拉动,不是纸面整洁。
• 项目长远合理性:建议 A(spec-tooling 收窄为生成物门禁族:packages/spec/scripts/** + scripts/ 生成物/基线部分 + references/** 生成面)。A 是唯一让两边各拿一段可判定文件面、且不动 devx 既有认领的切法;B 整体搬走一条在册车道的领地;C 把在用标签留在表外,复现 pm-dispatch 域分类表漏掉约 20 个包 —— 未列包按协议「不可被任何 PM 认领」 #5095 刚修掉的死角。若维护者判定 spec-tooling 是 C 包存续期的临时车道,则 A+C 组合(收窄定义 + 表下注明临时性与到期回收条件)最诚实。
• 防 AI 犯错:边界未定的表行 = 消费侧靠临场判断消化的模糊位,即本仓禁止的 lenient-consumer 形状;任一裁定都优于现状。

第 2 项(domain:ui)→ 本 PM 直接执行,否决窗口。 按 PR #5468 已合入的表文(objectui/cloud 用 repo:*,不另打 domain:*):#5236 摘 domain:ui,其 repo:objectui 已在、语义完整,不设别名 —— 一种写法,不留第三种。已执行。

---

Generated by Claude Code

[os-zhuang]

同族观察两条,来自 #5472 的施工现场(不另立单,归挂本单)

实施 #5472(PR #5522,协调模型改版)时在同一片区域看到两条与本单同族的事实,按「查重先行、归挂已排队父题」的纪律记在这里,不开新 issue:

1. .claude/skills/pm-dispatch/SKILL.md 的 one-time setup 块从不创建任何 domain:* 标签。 它只创建 pm:queue / pm:dispatched / needs-user-decision / pm:on-hold / pm:blocked / finding / pm:epic 与 repo:*。而同文件的 label discipline 规定「未打标签的 issue 任何 PM 都不得认领」,#5472 落地后 domain:* 更进一步成为分诊座位唯一生产的机器判据 —— 也就是说这套词表现在是承重的,却没有任何一处可执行文本负责把它创建出来,现存的几个域标签都是历史上手工点出来的。这正好解释了本单发现的两个未入表条目:表与实际标签集没有任何机械对账,两边各自漂移。修法与本单同一处(词表 ↔ 表 ↔ 创建脚本三者对齐),因此归挂而不是另立。

2. #5472 的 engine 拆分会给这份对账再加两个新条目 + 一次存量迁移。 PR #5522 已把 SKILL 域表里的 domain:engine 拆为 domain:engine-core(objectql / metadata* / platform-objects / core / formula / plugin-pinyin-search)与 domain:drivers(plugins/driver-* 四个),表下写明了迁移纪律:两个新标签需创建、存量 domain:engine 的 open issue 由分诊座位按落点改标、清零后删除旧标签。本单若要做词表对账,建议等 #5522 落地后一次做完(否则要对账两遍),或反过来把两个新标签一并纳入本单的对账清单。

参考:domain:spec-tooling 与 devx 的文件面重叠、domain:ui 与 repo:objectui 的重复,在双射模型下比旧协议更贵 —— 旧协议里一个多余标签只是噪音,新协议里它是一个看起来有主、实际无人在座的车道(SKILL 现文:「一个仍在流通的旧标签就是一个无主车道」)。

会话:session_01N3uGFF8teXbpgtbEJ1aYXu(os-dev,#5472)

---

Generated by Claude Code