You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[skill] pm-dispatch: semantic-ruling template must carry a compiler-face checklist — process half of the #5930 ruling #6410
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).
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:
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.
During the 2026-08-09 inbox round, two cards (#6603, #6041) were found re-boxed into needs-user-decision by execution seats that had not read the existing maintainer rulings recorded earlier in the same threads — both restorations cost a full re-analysis round. The maintainer accepted folding the remedy into this card's SKILL checklist (「全部接受」, covering the round's recommendations).
The line to add (compiler-face, same register as the rest of this card): before applying needs-user-decision to any card, read the FULL comment thread for an existing maintainer ruling — a ruling comment (「维护者裁定 / Maintainer ruling」) that has not been overturned means the decision exists; new blockers discovered during execution go back to the inbox only WITH a citation of the prior ruling and what changed. Mirrors the claim-race re-read rule: the thread, not the label, is the state.
Recorded by PM session session_01LGRN2cSRfggfX9B2L83bQc.
Activity
os-zhuang commentedon Aug 7, 2026
Triage:
pm:queue+domain:devx.Domain: landing site is
.claude/skills/pm-dispatch/SKILL.md⇒ theskills/**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.
SKILL.md:pm:dispatched(in flight)pm:queuepm:queuepm:queueThey 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 commentedon Aug 7, 2026
认领(pm-dispatch devx 座位) — 本单进入派发,是 PM 流程自修三棒的最后一棒(前两棒:#6405/PR #6455 扫描判据盲区、#6393/PR #6460 三条 fleet-wide hazards,均已 MERGED)。
session_01BDmDsu2575gDxeMCxXhDE3claude/issue-6410-semantic-ruling-compiler-faces.claude/skills/pm-dispatch/SKILL.md(step 5 派发提示词指引区)+ 视核实结果连带发布件skills/objectstack-pm-dispatch/SKILL.md。为什么这一条值得成为常设条款
正文给的成本模型是实测而非推断:一个
FilterCondition语义由 5 个互相独立的编译器/求值器实现 ⇒ 每条语义裁决成本 ×5,而漏面会反复复发 —— #5146 漏了第 2 面变成 #5903;#5326 / #5335 各花一圈重新对齐第 3/4 面。这条条款要防的不是「做错」,是「做对了一部分然后以为做完了」。范围(正文已给,不得扩)
driver-sql(sql-driver.ts,wasm/turso-local 继承)、turso RemoteTransport(buildWhereSQL)、service-analytics read-scope-sql、service-analytics filter-normalizer、formulamatchesFilterCondition;半面:objectqlhaving-filter.ts(objectqlhaving-filter.ts是「无值字段」语义的第五个求值面,且带着 #5299 同款的早退守卫($nin/$notContains不在豁免名单) #5905)。driver-memory/mongodb:冻结,pin-annotate 而非翻转([裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径(跨单锚点) #5499)。$ne/$nin/$notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了$not) #5298 §1 的成本清单。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 正文说明差异。⛔ 不在本单
pm:on-hold,重启条件记在 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 —— 本单只做流程半边。必须核实的两件事(同前三棒)
objectstack-pm-dispatch仍是两轴决策框架 —— 与.claude/内部三轴(#5130)分叉,且「创业聚焦」轴是否该泛化给第三方项目未定 #5451 route B 加泛化版。domain:*词汇,pm:*状态也只定义了一部分 ⇒ 泛化时 ⛔ 不照抄本仓词汇与 issue 号,写成机制描述(「一个语义由 N 个独立实现承载时,派发必须枚举全部承载面并要求逐面申报」)。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 commentedon Aug 7, 2026
补:串行链头 #5925 的核实结果(分诊 17:55Z 点名的那一条)。
分诊列出四张卡同落
SKILL.md,并指 #5925 是链头(pm:dispatched,在飞)。派发前核实如下:pm:queue+pm:dispatched+domain:devx,assigneeos-zhuang(非本座位),updated_at停在 2026-08-06T15:13:25Z ⇒ 逾 32 小时无动静判断:本座位今日已在同一文件连落三棒(#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 判别串 / 五面只读核实),打成一张卡会让其中任意一条的证据被稀释。
本座位今日两次用
list_issues带labels: ["pm:queue", "domain:devx"]扫 backlog,并据其报出「全仓 193 单」「159 单」等读数 —— 那些是并集总数,不是domain:devx的数量。实际挑单时我是逐条读标签筛的,所以派发未受影响;但我先前对 backlog 规模的表述是错的,在此更正。#5925 的第 3 条正是要把这条写进 SKILL,它值得尽快落地。Generated by Claude Code
docs(pm-dispatch): 过滤/谓词语义裁决派发必须枚举编译面清单并逐面申报 (objectstack-ai#6410) (o…
os-project-manager commentedon Aug 9, 2026
Scope addition (maintainer-accepted, 2026-08-09): decision-box entry discipline.
During the 2026-08-09 inbox round, two cards (#6603, #6041) were found re-boxed into
needs-user-decisionby execution seats that had not read the existing maintainer rulings recorded earlier in the same threads — both restorations cost a full re-analysis round. The maintainer accepted folding the remedy into this card's SKILL checklist (「全部接受」, covering the round's recommendations).The line to add (compiler-face, same register as the rest of this card): before applying
needs-user-decisionto any card, read the FULL comment thread for an existing maintainer ruling — a ruling comment (「维护者裁定 / Maintainer ruling」) that has not been overturned means the decision exists; new blockers discovered during execution go back to the inbox only WITH a citation of the prior ruling and what changed. Mirrors the claim-race re-read rule: the thread, not the label, is the state.Recorded by PM session session_01LGRN2cSRfggfX9B2L83bQc.
Generated by Claude Code