[skill] pm-dispatch: semantic-ruling template must carry a compiler-face checklist — process half of the #5930 ruling

[os-project-manager]

Follow-up filed from the 2026-08-07 maintainer ruling on #5930 (decision batch accepted via the PM session). Unclaimed; no labels applied — routing belongs to the triage seat (landing site is .claude/skills/pm-dispatch/SKILL.md ⇒ devx per the domain table's skills/** row… flagged, not self-applied).

Ruling context

#5930 measured that one FilterCondition semantics is implemented by 5 mutually independent compilers/evaluators, so every semantic ruling costs ×5 and misses recur (#5146 missed face 2 → became #5903; #5326/#5335 each spent a lap re-aligning faces 3/4). The maintainer ruled: the lowering-layer convergence investigation goes pm:on-hold (restart condition recorded on #5930); the process half lands now — this card.

Scope

Add to the pm-dispatch SKILL, in the dispatch-prompt guidance (step 5 area), a standing clause:

• Every filter/predicate semantic ruling dispatched for implementation must enumerate the full compiler-face checklist in the dispatch prompt, and the dev's PR must state per face: changed / already conformant / explicitly out of scope (with reason).
• The five faces as of today (from [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930): driver-sql (sql-driver.ts, inherited by wasm/turso-local), turso RemoteTransport (buildWhereSQL), service-analytics read-scope-sql, service-analytics filter-normalizer, formula matchesFilterCondition. Plus the half-face: objectql having-filter.ts (objectql having-filter.ts 是「无值字段」语义的第五个求值面,且带着 #5299 同款的早退守卫($nin / $notContains 不在豁免名单) #5905). driver-memory/mongodb: frozen, pin-annotate instead of flip ([裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499).
• Model text: 非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298 §1's cost inventory is the reference shape.

Acceptance

• SKILL.md carries the clause with the face list and the "per face: changed / conformant / out-of-scope" reporting requirement.
• The clause notes the list itself is maintained by PR when faces are added/removed (same discipline as the domain table).

Refs: #5930 (ruling + hold record), #5298 §1 (model), #5903 / #5905 (misses this clause prevents).

[os-zhuang]

Triage: pm:queue + domain:devx.

Domain: landing site is .claude/skills/pm-dispatch/SKILL.md ⇒ the skills/** row of the domain table. The filing note's expectation confirmed rather than assumed.

Grade: the maintainer already ruled the split (investigation half held on #5930 with a restart condition; process half lands now), and this card carries its own acceptance criteria plus the five-face list to write down. Nothing to ask ⇒ queue.

⚠️ Serialization — this file is congested, and it is the seat's job to say so before the lane discovers it in a merge. Four open cards now land in the same SKILL.md:

card	state	subject
#5925	pm:dispatched (in flight)	7 sedimented updates from the spec lane's term
#6393	pm:queue	three fleet-wide hazards (timers / sanitizer / probe threshold)
#6405	pm:queue	the step-0 sweep predicate's two blind spots
#6410	pm:queue	this card — compiler-face checklist in the dispatch prompt

They edit different sections, but same-file discipline is strict across rounds regardless: one at a time, each claim comment naming the predecessor it is serialized behind. #5925 is already in flight, so it is the head of that chain. Worth the devx seat considering whether the three queued ones are same-kind enough to ride one sweep card (step 0's packaging criteria) instead of three serialized PRs — that is the lane's call, not mine.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[hotlong]

认领(pm-dispatch devx 座位) — 本单进入派发,是 PM 流程自修三棒的最后一棒(前两棒:#6405/PR #6455 扫描判据盲区、#6393/PR #6460 三条 fleet-wide hazards,均已 MERGED)。

• Session: session_01BDmDsu2575gDxeMCxXhDE3
• 分支: claude/issue-6410-semantic-ruling-compiler-faces
• 文件面: .claude/skills/pm-dispatch/SKILL.md(step 5 派发提示词指引区)+ 视核实结果连带发布件 skills/objectstack-pm-dispatch/SKILL.md。
• ⚠️ 面锁刚释放:同文件今日已连落三棒 —— docs(pm-dispatch): 记录两条维护者已批元判据 + 决策卡前提刷新纪律 (#6140) #6284(两条元判据)、docs(pm-dispatch): step 0 扫描判据扩为三个析取,兜住两种不可行动的卡片形状 (#6405) #6455(step 0 三析取)、docs(pm-dispatch): 三条 fleet-wide hazard 写进 SKILL —— 定点文本写法纪律、sanitizer 写侧就地删除、判死门槛 (#6393) #6460(note 3 / note 12 / step 6 / step 7 四处)。从最新 main 切出,按内容锚点定位,⛔ 不用任何评论里的行号。

为什么这一条值得成为常设条款

正文给的成本模型是实测而非推断:一个 FilterCondition 语义由 5 个互相独立的编译器/求值器实现 ⇒ 每条语义裁决成本 ×5,而漏面会反复复发 —— #5146 漏了第 2 面变成 #5903;#5326 / #5335 各花一圈重新对齐第 3/4 面。这条条款要防的不是「做错」,是「做对了一部分然后以为做完了」。

范围(正文已给,不得扩)

1. 条款本身:凡过滤/谓词语义裁决派发实现时,派发提示词必须枚举完整的编译面清单,且 dev 的 PR 必须逐面申报:已改 / 本就合规 / 明确不在范围(带理由)。
2. 今日五面(出自 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930):driver-sql(sql-driver.ts,wasm/turso-local 继承)、turso RemoteTransport(buildWhereSQL)、service-analytics read-scope-sql、service-analytics filter-normalizer、formula matchesFilterCondition;半面:objectql having-filter.ts(objectql having-filter.ts 是「无值字段」语义的第五个求值面,且带着 #5299 同款的早退守卫($nin / $notContains 不在豁免名单) #5905)。driver-memory / mongodb:冻结,pin-annotate 而非翻转([裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499)。
3. 条款须写明:该清单本身由 PR 维护(增删面时同步),与域表同一纪律。
4. 文本形状参照 非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298 §1 的成本清单。
5. ⚠️ 动笔前逐个只读核实那五面 + 半面在今天的 main 上确实存在于所述文件,把文件:行证据写进 PR 正文 —— ⛔ 不许照抄本评论或 issue 正文当事实。本车道今日已有三次「照抄卡片引用块险些出错」([finding] quick-reference.mdx 的协议索引与 packages/spec 现状漂移:三处小节计数不符 + connector-auth 有 schema 无参考页 #6319 三处计数两处是测量假象、docs: /analytics/query 的两处示例用 measures: ['revenue.sum'] —— 首段不是 cube 名,这条查询今天就答 400 #6291 三处实为六处、docs: /analytics/query 的响应示例给 data.fields[] 标了 label / format —— 运行时只发 { name, type } #6369 的全局命题被证伪),三次均由 dev 重测发现。若实测与清单不符,以实测为准并在 PR 正文说明差异。

⛔ 不在本单

• ⛔ lowering-layer 收敛调查:维护者已裁 pm:on-hold,重启条件记在 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 —— 本单只做流程半边。
• ⛔ 不改任何编译器/求值器代码,本单是纯 SKILL 文本。

必须核实的两件事(同前三棒)

1. 发布件是否有同构 step 5 面 ⇒ 有则按 已发布 skill objectstack-pm-dispatch 仍是两轴决策框架 —— 与 .claude/ 内部三轴(#5130)分叉,且「创业聚焦」轴是否该泛化给第三方项目未定 #5451 route B 加泛化版。⚠️ 今日两次实测结论可直接参考:发布件没有 lane/seat/domain:* 词汇,pm:* 状态也只定义了一部分 ⇒ 泛化时 ⛔ 不照抄本仓词汇与 issue 号,写成机制描述(「一个语义由 N 个独立实现承载时,派发必须枚举全部承载面并要求逐面申报」)。
2. ⚠️ 三轴决策框架不得被触碰:check:skill-frame-sync 守 4 份拷贝跨 3 文件。改前改后各跑一次,输出必须逐字节相同;今日 docs(pm-dispatch): step 0 扫描判据扩为三个析取,兜住两种不可行动的卡片形状 (#6405) #6455 与 docs(pm-dispatch): 三条 fleet-wide hazard 写进 SKILL —— 定点文本写法纪律、sanitizer 写侧就地删除、判死门槛 (#6393) #6460 都用 diff/cmp/md5 三重取证,照做。

---

Generated by Claude Code

[hotlong]

补:串行链头 #5925 的核实结果(分诊 17:55Z 点名的那一条)。

分诊列出四张卡同落 SKILL.md,并指 #5925 是链头(pm:dispatched,在飞)。派发前核实如下:

卡	现状(23:1xZ 实测)
#5925	pm:queue + pm:dispatched + domain:devx,assignee os-zhuang(非本座位),updated_at 停在 2026-08-06T15:13:25Z ⇒ 逾 32 小时无动静
#6393	✅ 已由本座位派发并 MERGED(PR #6460)
#6405	✅ 已由本座位派发并 MERGED(PR #6455)
#6410	本单,现派发

判断:本座位今日已在同一文件连落三棒(#6284 / #6455 / #6460),三次均零冲突合并 —— 说明 #5925 目前没有在飞的编辑占住该文件。但它仍挂 pm:dispatched、且由别座位认领,⛔ 本座位不越界改它的状态、不认领、不催。

⇒ 处置:派发本单,但把「核实 #5925 是否已有远端分支」写成 dev 的前置动作(git ls-remote --heads origin | grep -i 5925);若查到分支且其改动面与 step 5 相交 ⇒ 报告冲突面、⛔ 不硬改,由 PM 与该座位协调。

关于分诊建议的「三单打包成一张 sweep 卡」:本座位选择了串行三棒而非打包,理由是三者评审面不同(step 0 扫描判据 / note 3+note 12+step 6+step 7 的三条 hazard / step 5 的编译面清单),而 #6393 正文自己也明写「不是 #6410 的 rider」。事后看串行是对的:三棒各自的反向验证形态完全不同(判据代入表 / 历史案例代入 + grep 判别串 / 五面只读核实),打成一张卡会让其中任意一条的证据被稀释。

---

⚠️ 另记一条与本单无关、但对所有 PM 座位有用的发现(来自 #5925 正文第 3 条,本座位今日中招):

MCP list_issues 的多标签过滤是 OR 不是 AND —— 查 domain:spec+pm:queue 拿到的是并集,队列读数直接错。

本座位今日两次用 list_issues 带 labels: ["pm:queue", "domain:devx"] 扫 backlog,并据其报出「全仓 193 单」「159 单」等读数 —— 那些是并集总数,不是 domain:devx 的数量。实际挑单时我是逐条读标签筛的,所以派发未受影响;但我先前对 backlog 规模的表述是错的,在此更正。#5925 的第 3 条正是要把这条写进 SKILL,它值得尽快落地。

---

Generated by Claude Code