docs(pm-dispatch,os-dev): 串行接力一夜沉淀的六条缺口补进 SKILL —— 接力模式、锚点措辞、裁决传播扫描、停摆纠偏、飞行中重叠、预期红停放 (#5441)

[os-zhuang]

Fixes #5441

2026-08-04/05 夜 spec 车道以串行接力连落 10 个 PR(#5304 → #5306 → #5308 → #5318 → #5319 → #5321 → #5314 → #5312 → #5323 → #5365),其中六个情形是现行 SKILL 没有覆盖、全靠现场即兴的。按 issue 注明的落点章节逐条插入,六条落点之外未动任何段落。

前提核验(基于合并后的 origin/main,HEAD = 0285f7f)

issue 提醒 SKILL.md 今日已两改(#5453 三轴 / #5468 域表),章节位置有位移 —— 已基于合并后文本施工。六条全部确认缺失:

缺口	落点(当前文本)	缺失证据
1 串行接力	第 7 步「入队与落地」平行小节	grep 接力 零命中;A/B 两条只写单 PR 流程
2 锚点措辞	「入队与落地 A」	grep baseRev 零命中;authorable-surface 仅 1 命中(A 的八条路径清单)
3 裁决传播	第 5 步派发词 + 第 7 步 review	grep 裁决传播 / INVALID_FILTER 均零命中
4 停摆纠偏	第 6 步 Collect subagent 半边	grep 停摆 零命中;原文只有「死掉 / 输出畸形算 blocked」
5 飞行中重叠	第 5 步 same-day churn 姊妹段	grep 飞行中 零命中;在飞 5 处全属域车道的批次选择,非在飞预警
6 预期红停放	「入队与落地 B」	grep 预期红 零命中;notes 2 只覆盖 flaky 的偶然红

第 2 条的措辞逐条对着代码核过,不是照抄 issue:

• packages/spec/scripts/build-schemas.ts 的 verifyCommittedSurfaceBase() 文档注释与实现只查两件事 —— baseRev 是 origin/main 的祖先(merge-base --is-ancestor)、keys 与该 commit 的 surface 逐行一致(compareAnchorKeys)。没有任何地方要求 baseRev == merge-base。
• 「允许滞后」有硬证据:锚点写入处是 const drifted = ... JSON.stringify(committed.doc.keys) !== JSON.stringify(anchor.keys),且 if (drifted && !CHECK) 才写 —— 即只在 keys 漂移时才推进 baseRev;同处注释写着 "Staleness is NOT an error"。PR fix(spec): #4650 删除闸门改用树内基线锚点,按 SHA 钉住的离线消费者构建不再硬失败 (#5235) #5304 的正文同样写明「滞后是合法的,不是错误 …… --check 只证明它真实(authentic),不要求它最新(current)」。
• os-regen 驱动指示的 gen:schema 在 merge 未 commit 时运行,会把 authorable-surface 锚点倒退回旧 merge-base —— 生成器写入、门全绿、静默撤销 main 的锚点推进 #5370 / gen:schema rmSync 整个 json-schema/ 会顺手抹掉 gen:openapi 的产物,rest 的 openapi 路由测试随后 503 假红——check:generated 原地跑 build-schemas 也触发 #5371 两单已核实存在且开放(os-regen 驱动指示的 gen:schema 在 merge 未 commit 时运行,会把 authorable-surface 锚点倒退回旧 merge-base —— 生成器写入、门全绿、静默撤销 main 的锚点推进 #5370 bug/pm:queue,gen:schema rmSync 整个 json-schema/ 会顺手抹掉 gen:openapi 的产物,rest 的 openapi 路由测试随后 503 假红——check:generated 原地跑 build-schemas 也触发 #5371 finding),文中仅引用、明确写「⛔ 不要在接力单里顺手实现」。

其余案例编号也已核实:10 个 PR 全在 main 上;#5365 的合并 diff 确实同时改了 packages/rest/src/analytics-filter-refusal-envelope.test.ts(+87)与 service-analytics 层,正是第 3 条「消费层各有拷贝」的实证;INVALID_FILTER 在 objectql / rest 十余个文件里有拷贝。

改动内容

.claude/skills/pm-dispatch/SKILL.md(+135)

1. 新小节「串行接力 —— 同碰生成物的多个 PR,一次只放行一个」(紧随「入队与落地」,同级):三条 —— 每棒一整圈且 auto-merge 由 PM 挂 / dev 永不碰(ready 与 auto-merge 顺序不可反,且每棒各走一次,不是整链一次);相邻棒同文件交接语义而非文本(fix(spec): app 表单摘掉八个已退役的墓碑键输入,#3786 对账门改判「真实可授权面」(#5280) #5318/feat(spec)!: ViewItemSchema 拆成授权门 + wire 变体,并让 wire 的开放递归生效 (#5074) #5319 同动 metadata-form-zod-reconciliation.test.ts,取一边会「各自绿、合起来错」);两棒散文互锁由 PM 在两侧指派分工(fix(driver-mongodb): 空 $and/$or/$not 归约成布尔单位元,非 filter 节点先响亮拒收 (#5239) #5323 ↔ fix(service-analytics): 空 $and/$or 按布尔单位元归约,两个编译器对齐五后端,四条进一致性表 (#5322) #5365、fix(service-analytics)!: 作者的 where 也 NULL-safe —— $not 下推守卫、{$not:{}} 为零行、{} 析取项吸收 $or (#5325) #5335 的 pin 块),否则两边都动或都不动,两种结果在 CI 上都是绿的。
2. 「入队与落地 A」补锚点断言措辞 + 四步序第 3 步补「先 commit 掉这次 merge,再整体重生成」。四步序这处不是加脚注而是直接改正:照原文在 MERGE 状态下重生成就会踩 os-regen 驱动指示的 gen:schema 在 merge 未 commit 时运行,会把 authorable-surface 锚点倒退回旧 merge-base —— 生成器写入、门全绿、静默撤销 main 的锚点推进 #5370,留着注解等于自留「声明与执行不一致」。
3. 第 5 步派发词补「裁决传播 = 全仓 pin 扫描」:一轮翻完 + 翻 pin 必须保留承重(断言新语义的实质,无效形状的拒收断言原样保留)。两条写成一体:少了后半条,「全仓翻完」会退化成「全仓删干净」。
4. 第 7 步 review 补一条:实施裁决的 PR 要按错误码 grep 消费层,确认旧立场无残留、且无效形状的拒收断言仍在。
5. 第 6 步 Collect 补停摆纠偏:watcher 永不触发(完成通知本身即意味无存活子任务);中途状态即停摆信号,立即恢复、⛔ 不等静默阈值;第三次视为不可靠,改走「Handing off an interrupted dev」。
6. 第 5 步 same-day churn 补姊妹段「飞行中重叠」:每轮读 git log origin/main 时对每个在飞 dispatch 做「新落地 PR × 在飞文件面」相交判断,相交即预警(四条内容);并点明它与 Operational notes 8 的分工 —— notes 8 是 PM 替自己入队前复查,这条是替别人在飞的 agent 复查。
7. 「入队与落地 B」补预期红停放:draft 停放 + 签名级预期红清单 + 解除条件;新签名才是真问题(fix(service-analytics): 空 $and/$or 按布尔单位元归约,两个编译器对齐五后端,四条进一致性表 (#5322) #5365 的 REST 红即由此识别)。写明它是 notes 2 在故意红上的对偶。

.claude/agents/os-dev.md(+11) —— 第 4 条的生产端半边(PD #12:生产端修复优于 PM 端补救):资源纪律新增第 6 条「前台跑完,不要把验证挂到后台等唤醒」,并区分出唯一合法的长等待是第 1 条的 flock 排队。

⚠️ 给 #5484 的提示:本 PR 在 os-dev.md 的资源纪律里加了 11 行,os-dev.md:263 的字节自扫正则(#5484 的目标行)已下移到 :274,内容一字未动。按内容 grep,不要按行号。

未动的两处(刻意)

• skills/objectstack-pm-dispatch/SKILL.md(已发布镜像):那是面向客户的泛化版本(有 Quickstart / Configuration,没有「入队与落地」这类本仓专属小节),六条里的案例编号与本仓 issue 号对它无意义。沿用 docs(pm-dispatch,os-dev): 决策分析轴由两条扩为三条 —— 补「实际业务需求」轴与创业聚焦原则 (#5130) #5453 的先例(「已发布目录里的镜像本次刻意未动,那是发布内容,另单处理」)。
• os-dev.md 的字节自扫正则:os-dev.md 的「自扫」正则比门禁本身还窄:#5460 把 DEL 纳入扫描面后,那条指令会给出假绿 #5484 的活,已单独排队。

⚠️ changeset:改用 skip-changeset 标签,与派发口径不同 —— 请复核

派发口径要求「空 frontmatter changeset,先例 .changeset/pm-dispatch-three-axis-decision-frame.md」。该先例已被今日更晚合入的 #5467(修 #5292)改判,现行 Check Changeset 门禁的失败文案原文:

2. It releases nothing (.github/, .claude/, docs/, content/, examples/, tests-only, and the like) → apply the skip-changeset label. PREFERRED
3. An empty-frontmatter changeset also satisfies this gate and stays legal — but it is a LAST RESORT … Unlike the label it is a REAL INPUT to changesets/action: when every pending changeset is empty, the action … prints "All changesets are empty; not creating PR" … no version PR, no publish, and the Release run still goes GREEN. That is 空 changeset 会静默卡死已 version 的发布:Release run 全绿,但 npm 和 Docker 什么都没发(17.0.0-rc.2 现在就卡着) #4898, which silently stalled 17.0.0-rc.2. It also buys you nothing the label does not: an empty changeset names no package, so its body reaches no CHANGELOG.

门禁文案逐字点名 .claude/ 属路由 2。本 PR 因此走标签路线(已挂 skip-changeset)。这正是 SKILL 第 5 步「same-day churn」讲的那件事发生在派发口径本身上:先例来自 #5453,而 #5467 在其后落地。若维护者/PM 仍要求那份 in-repo 散文记录,一条空 changeset 即可补上(说一声就加),但按门禁的说法它下游不到任何 CHANGELOG。

验证

.claude/ 的实际读者只有两个门(其余两个的 ROOTS 不含 .claude/,如实说明,不冒充覆盖):

$ node scripts/check-nul-bytes.mjs --self-test
✓ check-nul-bytes --self-test: 48 assertions over a temp git repo (real scan() path)
$ node scripts/check-nul-bytes.mjs
check-nul-bytes: OK (scanned 5461 tracked text file(s); skipped 5 binary, 1 non-regular;
no raw ASCII control bytes).                                              EXIT=0

$ node scripts/check-doc-authoring.mjs --self-test
✓ check-doc-authoring self-test: scope wiring (.claude and the live docs/ corpus in,
  .claude/worktrees and docs/{audits,handoff,plans} out), detection, and the dead-root
  hard error … all hold.
$ node scripts/check-doc-authoring.mjs
✓ doc authoring guard: 362 files clean — no bare metadata literals.       EXIT=0

不覆盖 .claude/ 但一并跑过、确认无回归:

$ node scripts/check-role-word.mjs        # ROOTS = ['content/docs', 'skills']
check-role-word: OK (43 baselined file(s), no new occurrences).           EXIT=0
$ pnpm -s check:docs-audit-scope          # 只看 content/docs/
✓ docs-accuracy-audit scope is in sync with content/docs/: 178 hand-written doc(s).
✓ release-owned pages are in scope and read-only: 9 page(s) … review-only.  EXIT=0

字节纪律自扫(超出门禁扫描面,含 #5460 加入的 DEL):

$ grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' .claude/skills/pm-dispatch/SKILL.md \
    .claude/agents/os-dev.md
（零命中,exit 1）

没有测试可加,如实说明:改动是两份 .claude/ 内部 agent 协议散文,不含任何可执行代码路径;packages/spec 的 check:skill-docs / check:skill-refs 生成链的 SKILLS_DIR 指向仓根 skills/(已核 build-skill-docs.ts:28、build-skill-references.ts:34),读不到 .claude/,所以没有生成物需要重生成。pnpm test / pnpm typecheck 对本 diff 无信息量,未跑 —— 报告里不拿它们充作证据。

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01GX3sL71LFq8m2usg6VqTSE

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 5, 2026 2:32pm

[os-zhuang]

自查补两条(已推,head a8cdd24a8)

开 PR 后自己复核新增散文的每处交叉引用与每个数字,抓到两处并改正 —— 记在这里,免得 review 时再花一遍:

1. fc30c1922:交叉引用方向写反。 停摆纠偏第三条写「re-dispatch … under "Handing off an interrupted dev" below」,而该小节是第 5 步的子节(SKILL.md:839),新增段落在第 6 步(:923)—— 「below」会把读者指向第 6 步之后的 Cloud mode 段。改为「in step 5」。同段内对 cloud-mode ~2h 阈值的「below」是对的(那段确实在下面),保留。

2. a8cdd24a8:issue 正文的时间戳与仓内记录不符,改用可核验值。 issue 第 5 条写「#5335 在 00:0xZ 合入」。两个独立读数都不支持:

GitHub API  PR #5335 .merged_at        = 2026-08-04T23:49:44Z
main 上 squash 提交 1792384e8 committer = 2026-08-04T23:44:11+00:00

差了约 15 分钟且跨了整点。散文里那句原样照抄会写进一个仓里查不到的钟点,所以改写成「起飞后 32 分钟合入(merged_at 2026-08-04T23:49:44Z)」—— 把不可核验的钟点换成可核验的时间差 + 权威字段名。起飞时刻 23:17Z 沿用 issue 的记述(仓内无产物可核,且它不是这段的承重点:承重的是「起飞之后 main 又落了一个相交 PR」这个事实)。

顺带一条支持性证据:#5335 自己的 PR body 明写「⛔ #5322($and: [] / $or: [] 空组合子)—— 独立裁定,本单只加用例把它钉在抛错这一侧」,正是新增第 1 条第 3 款「两棒散文互锁 / pin 块占位交接」的实证,不是转述。

两次改动都重跑过读 .claude/ 的两个门(check-nul-bytes、check-doc-authoring)与超出门禁扫描面的字节自扫,均绿。

---

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 31016486579 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Temporal Conformance (live PG + MySQL) — 失败步骤: Run the non-SQL temporal backends under the skewed process zone

  �[90mstderr�[2m | src/sql-driver-unique-tenancy.test.ts�[2m > �[22m�[2mSqlDriver unique × tenancy (#3696)�[2m > �[22m�[2mretires a legacy global unique index and replaces it with the composite
  �[90mstderr�[2m | src/sql-driver-unique-tenancy.test.ts�[2m > �[22m�[2mSqlDriver unique × tenancy (#3696)�[2m > �[22m�[2mretires the legacy `uniq_<table>_<col>` index left by the drift rebuild path
  �[90mstderr�[2m | src/sql-driver-unique-tenancy.test.ts�[2m > �[22m�[2mSqlDriver unique × tenancy (#3696)�[2m > �[22m�[2mbare-composite tightening + duplicate pre-flight (ADR-0120 D4)�[2m > �[22m�[2ma
  �[90mstderr�[2m | src/sql-driver-unique-tenancy.test.ts�[2m > �[22m�[2mSqlDriver unique × tenancy (#3696)�[2m > �[22m�[2mbare-composite tightening + duplicate pre-flight (ADR-0120 D4)�[2m > �[22m�[2mB
  �[22m�[39m[schema-drift] product: cannot tighten 'uniq_product_organization_id_code' as UNIQUE (COALESCE(organization_id, '__global__'), code) — existing rows already violate the NULL-safe unique cons
  �[90mstderr�[2m | src/sql-driver-unique-tenancy.test.ts�[2m > �[22m�[2mSqlDriver unique × tenancy (#3696)�[2m > �[22m�[2mbare-composite tightening + duplicate pre-flight (ADR-0120 D4)�[2m > �[22m�[2mB
  �[22m�[39m[schema-drift] REFUSING to rebuild 'uniq_product_organization_id_code' on 'product' as a NULL-safe unique — 1 duplicate group(s) violate it (e.g. organization_id="__global__", code="DUP" × 2
  

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 11 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 在其他 PR 的同类评论里搜同名测试；出现过 ⇒ flaky 实锤，开 issue 修/隔离那条测试。修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)