docs(pm-dispatch): repo-class governance split, md-content review fork, and the standing 5-card adjudication flow (#12443)

* docs(pm-dispatch): adopt repo classes with the amended governance split

Multi-lane repos (objectstack, objectui) keep central triage as the sole
producer of domain:*/type/grading; single-lane repos (cloud, objectos,
hotcrm, www.objectos.ai, future repos by default) self-triage the
conflict-free mechanical duties only. Registration becomes a checklist
with a standing-seat admission criterion. The auto-adjudication channel
is retained, hard-gated on the measured serving tier; adjudication and
cross-repo skills work sit with the skills seat in the maintainer-driven
5-card batch flow. Cross-repo dedupe stays central; single-lane decision
cards queue in the objectstack inbox.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JANH3y7qe3MD8aLaLXci8N

* docs(pm-dispatch): md-content review fork and the standing 5-card batch flow

A skills-lane PR whose diff contains any .md file keeps the governed
draft/human-merge ending; a code-only skills-lane PR is self-reviewed by
the seat at the contract-review tier and landed directly. The 2026-08-26
decision-batch flow is written in as the standing adjudication process:
batches of five, business-angle explanation, concrete options, four-axis
analysis, one-line batch reply, atomic post-ruling execution.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JANH3y7qe3MD8aLaLXci8N

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude[bot]

.claude/skills/pm-dispatch/SKILL.md

@@ -184,15 +184,15 @@ fire 一轮烟测,判据取**GitHub 上的产出**;③ 每 fire 一轮:读座位
 
 ## 多仓协调(五条规则)
 
-产品横跨三仓,依赖方向固定:`objectstack`(后端;`packages/spec` 是唯一契约)→ `objectui`(前端,构
-建产物经 `pnpm objectui:refresh` 回流)与 `cloud`。链外两仓不入依赖链:分诊照扫(分诊座位保持五
-仓唯
-一),各归同名 `repo:*` 执行座位,纪律即规则 4 姊妹仓执行座位一套(⛔ 此处不另抄)。第四仓
-`objectos`
-(纯文档与站点,执行已自 `domain:devx` 迁出):座位由维护者 2026-08-18 开设(「objectos 是新开的项目
-经理,是不是少了座位帖。」);无 changeset 流、无 `packages/`;合并队列 + required `build` + `merge_group` 已上线 —— 派发预期照实设,⛔ 不要求不存在的机制。
-第五仓 `hotcrm`(样板工程:元数据开发的 CRM 示例应用):收卡判据、宪章原文与边界全在
-`references/lanes/hotcrm.md`。
+产品依赖方向固定:`objectstack`(后端;`packages/spec` 是唯一契约)→ `objectui`(前端,构建产物经
+`pnpm objectui:refresh` 回流)与 `cloud`。**仓分两类**(维护者 2026-08-26 裁定;原话与 skills/决裁归
+席见「升级与决策」):**多车道仓** `objectstack`、`objectui` —— 中央分诊是 `domain:*`/type/定级
+的唯一生产者;**单车道仓** `cloud`、`objectos`、`hotcrm`、`www.objectos.ai`(未来新仓默认此类)——
+其 `repo:*` 席自理无冲突的机械三务(自扫 sweep、自打 `type`、自做 `finding` 首触定级),⛔ 不产
+`domain:*`,决策卡默认入 objectstack 收件箱;跨仓查重/shadow 检查恒归中央(全仓视图不可下放)。
+**新仓登记是一张清单**:座位贴、标签、类别归属、门禁盘点;准入判据一句 —— 这个仓
+真的需要常设席位吗。逐仓事实照实设(objectos 无 changeset 流、无 `packages/`,合并队列已上线;
+hotcrm 收卡判据与宪章见 `references/lanes/hotcrm.md`)。
 **objectui 卡按修复落点分流三流**(维护者 2026-08-21 裁定,`domain:ui` 唯一新增标签,命名定稿原
 话:「按 domain:ui 定稿」):`domain:devx`(工程面)/`domain:spec`(契约面)跨仓归各自车道,其余 —— 发
 布库与 apps —— `domain:ui` 归 objectui 执行席;症状位置不改流向,docs 随所记录的面走,落点不
@@ -223,25 +223,17 @@ devx@objectui;触发即规则 4 预登记的拆分条件),各席独立座位贴
 3. **联动杂事立单,不靠记忆。** 已验收 PR 的产物流向另一仓时,由**接受那个 PR 的执行座
    位**立即
    在消费仓立后续单(带 `Blocked-by:`);`domain:*` 仍由分诊补。
-4. **纵向拆分:一个分诊 PM + N 个执行 PM,一人一车道双射**(维护者 2026-08-05 拍板;2026-08-16 裁
-   定分诊统一收归一座)。分诊座位**五仓唯一**(仓单即多仓协调首段的五仓):全部 backlog 的
-   分诊/
-   定级/路由/type 由它一座生产,只扫/分类/打标签/拆分/查重/转仓,⛔ 永不认领、永不派发、
-   永不写代
-   码。执行座位信任标签、只在本车道认领,误标**不自行改**、挂 `pm:retriage` + 异议评论同
-   笔;姊妹仓 `repo:*` 座位收窄为**
-   执行座位**(在本仓认领/派发/复核/落地,同一套执行座位纪律,⛔ 不产 `domain:*`/type/定
-   级;skills
-   车道 finding 自分诊例外照旧)。**拆分触发条件预登记**:单轮时长逼近 fire 周期,或某仓在
-   优先级
-   全序下持续断粮 ⇒ 按仓拆回多席 —— 扩容是记录在案的出口,不是重设计。⛔ 借调已删
-   除:突发积压调
-   频率或 `batch`,持续积压拆域走 PR。**维护者直派通道**(2026-08-10 常设授权):维护者当面指挥
-   的 PM 会话直接路由,审计评论逐字引用授权指令,只对明示指挥的卡成立。分诊空缺时会话
-   型执行 PM 可
-   **代扫**(只做分诊动作,不跨车道认领,座位贴注明),座位有主立即停止 —— 两个分类生产
-   者并存,单
-   一生产者的保障当场归零。
+4. **纵向拆分:一个分诊 PM + N 个执行 PM,一人一车道双射**(维护者 2026-08-05 拍板;2026-08-16 裁定
+   分诊统一收归一座)。分诊座位**唯一**:多车道仓 backlog 的分诊/定级/路由/type 由它一座生
+   产,只扫/分类/打标签/拆分/查重/转仓,⛔ 永不认领、永不派发、永不写代码。执行座位信
+   任标签、只在本车道认领,误标**不自行改**、挂 `pm:retriage` + 异议评论同笔;单车道仓
+   `repo:*` 席 = 执行座位 + 机械三务自理(类别与三务见首段;skills 车道 finding 自分诊例外照
+   旧)。**拆分触发条件预登记**:单轮时长逼近 fire 周期,或某仓在优先级全序下持续断粮 ⇒
+   按仓拆回多席 —— 扩容是记录在案的出口,不是重设计。⛔ 借调已删除:突发积压调频率
+   或 `batch`,持续积压拆域走 PR。**维护者直派通道**(2026-08-10 常设授权):维护者当面指挥的 PM
+   会话直接路由,审计评论逐字引用授权指令,只对明示指挥的卡成立。多车道仓分诊空缺时
+   会话型执行 PM 可**代扫**(只做分诊动作,不跨车道认领,座位贴注明),座位有主立即停止
+   —— 双生产者并存即失守。
 5. **一块板,不设第二跟踪器(one board, no second tracker)。** pm 标签就是状态机;org Project 只是维
    护者的聚合视图,权威层坚持 issue 正文 + REST。
 
@@ -342,10 +334,12 @@ skills,类似分诊」)—— 贴内指针指向其车道文件,升级走技能
 
 ## 分诊座位职责
 
-(执行座位 ⛔ 跳过本节动作 —— 读到标签当既成事实。)本节全部职责**对五仓统一执
-行**(仓单与出处见「多仓协调」首段与规则 4):sweep、首触定级、发版板(objectos、hotcrm 无发
-版板,跳过)、查重/shadow 检查与代裁通道逐仓各跑一遍;
-**代裁权限唯一归本座位**,任何执行座位(含姊妹仓 `repo:*`)⛔ 不代裁。
+(执行座位 ⛔ 跳过本节动作 —— 读到标签当既成事实。)职责按仓类执行(类别
+见「多仓协调」首段):sweep 与首触定级只对多车道仓(单车道仓机械三务自理);发版板(无板仓
+跳过)、查重/shadow 检查与代裁通道全仓照跑。**代裁通道保留、档位硬门**(维护者 2026-08-26
+裁定,原话:「代裁通道如果是 fable 可以代裁,其他接受你的建议」):仅当运行席**实测服役模
+型** = `claude-fable-5`(降档保险丝机器读数,⛔ 永不凭自述)才可代裁;通道只在分诊 Routine(钉
+档)或 skills 席上运行,其余执行座位 ⛔ 不代裁;2026-08-12 置信门其余条件全部照旧。
 **工具加载纪律(fire 开局)**:互斥检查/自退判断只按名加载所需工具 —— `ToolSearch` 用
 `select:mcp__github__list_issues,mcp__github__issue_read` 形式,判定「本轮有活」之后才加载其余;⛔ 开
 局不做泛关键词 ToolSearch(一次注入全家桶 schema —— 分诊席 2026-08-20 自测:空转轮 ~12 万
@@ -356,14 +350,14 @@ token,~8 万是这张门票);可验判据:空转轮 ~4 万以内。只约束分
 2026-08-20:「每次都需要 四仓全量 open issue 盘点 … 吗?建议分诊多久执行一次」→「立卡」)**:小
 时轮以 `since` 窗口读增量 —— 锚 = 座位贴上一份收班简报的时间戳(互斥守卫同一读数,零
 新状态;标签写入刷新 `updated_at`,窗口锚在简报而非上次 fire,漏 fire 积压自动入窗);每日一
-fire 跑四仓全量对账并归集日频职责;选层按 fire 时刻 ⛔ 不用计数器(fresh session 无计数
+fire 跑全仓全量对账并归集日频职责;选层按 fire 时刻 ⛔ 不用计数器(fresh session 无计数
 器);简报写明本轮跑的层(下轮读者靠它知道窗口盖了什么)。从不更新的卡不入窗是设计:它
 上次变更时已被扫过,老化欠账归半状态巡查不归小时轮(`since` 读法与成本对价见 runbook)。
 
 **Backlog sweep(常设职责,不等请求)。** 每轮扫任一析取命中的卡:① 全裸(无`pm:*`、
-无 `needs-user-decision`、无 `domain:*`);② 有 `pm:queue` 无 `domain:*`(**凡有车道标签的仓皆扫**,
-今日为主仓与 objectui —— 三流拆分见多仓协调;豁免仅余真无车道标签的仓 cloud、objectos,该
-形状在那里才是队列卡常态);③ 有 `domain:*` 无 pm-state。②③ 只取 `updated_at`
+无 `needs-user-decision`、无 `domain:*`);② 有 `pm:queue` 无 `domain:*`(仅多车道仓 —— 三流拆分
+见多仓协调;单车道仓无 `domain:*` 是队列卡常态,自扫归其席);③ 有 `domain:*` 无 pm-state。②③
+只取 `updated_at`
 早于 ~2 分钟的卡且不是可选项 —— 半标注卡是协议自己按设计生产的(一次标签写入即把
 老卡打成半标
 注),只带路由或状态机其一的卡对两个视图同时不可见。排除:`tracking`、`status:parked`(其正常
@@ -404,7 +398,7 @@ sanitizer 截断的卡不
 扫必烂),新卡即时打、存量卡下次碰到补。读者三个:代裁路由(`Feature` 机械落人工地板,`Bug`/
 `Task` 才是代裁候选)、发版板缺陷扫描(`type:Bug is:open`)、普通队列 Bug 优先平手判据。
 
-**路由即分诊的技术判断,永不升级「哪个仓?」。** 读五仓代码定落点;跨仓的按contract-first
+**路由即分诊的技术判断,永不升级「哪个仓?」。** 读全仓代码定落点;跨仓的按contract-first
 拆分;父单已有子结构的,父单队列标签即可(sub-issue 自动成为候选),分诊逐个展开路由、补
 `Blocked-by:`
 排序,父单是协调节点**永不派发**。每张留一条英文审计评
@@ -461,14 +455,11 @@ sanitizer 截断的卡不
   扩大接受集或公开面**?扩大 ⇒ 功能新增/协议变化 ⇒ 人工;接受集不变、拉回已声明契
   约(declared =
   enforced 的恢复)⇒ bug/整理 ⇒ 代裁车道。
-- **置信门(全部成立才可代裁)**:① 四棱同向(全指向同一选项,任何分裂即升级);②不在人工
-  地板上
-  ;③ 不收窄、不推翻任何既有维护者裁决;④ 执行是**否决窗口不是许可门**—— 裁定 →
-  一次标签写入
-  换 `needs-user-decision` 为工作态 → 卡上贴四棱块 + 结论 + `auto-adjudicated` 标记 → 轮次报
-  告设**代裁清单**专节(聚合漂移的刹车);⑤ 代裁分析跑在 `claude-fable-5`(与维护者手工流程
-  同档),达档认定与未达处置同复审链降档保险丝(机器读数为准;未达 ⇒ 本 fire 代裁整体跳
-  过、卡原样留在决策箱走维护者路径,恒安全)。
+- **置信门(全部成立才可代裁)**:① 四棱同向(全指向同一选项,任何分裂即升级);② 不在人工
+  地板上;③ 不收窄、不推翻任何既有维护者裁决;④ 执行是**否决窗口不是许可门**——
+  裁定 → 一次标签写入换 `needs-user-decision` 为工作态 → 卡上贴四棱块 + 结论 +
+  `auto-adjudicated` 标记 → 轮次报告设**代裁清单**专节(聚合漂移的刹车);⑤ 本节首段的档位
+  硬门达标(未达 ⇒ 本 fire 代裁整体跳过、卡原样留在决策箱走维护者路径,恒安全)。
 - **回翻条款**:代裁卡实施中发现契约终究要动 ⇒ dev 停手,卡回`needs-user-decision` —— 报告
   分叉,⛔ 永不静默重裁。
 - **请示纪律(维护者 2026-08-25:「不要不停的弹出来让我确认,很浪费时间」)**:①方向性授权(
@@ -769,10 +760,14 @@ os-zhuang 审核。我的手机github 应该会收到推送消息吧」;当日
 维护者确认「推送到了」;推送通道仅此一条,同日裁定:「只有需要我审核的pr 推给我。」)—— 「等人
 合」清单从此活在 GitHub 的 Review-requested 队列,合并自动消项。**能请审则请审;PR 作者身份即 os-zhuang 的席位,请审必失败**(GitHub 拒绝向 PR 作者请审,author-identity 422)—— 改为把 PR **assign 给 os-zhuang** 替代通知,并在轮次报告点名说明走了 assignee 兜底;④ 轮次报
 告单列「awaiting a human merge」(「等人来合」与「被忘了」在 GitHub 上长得一模一样)。混
-合 diff 一条命中就分叉,⛔ 不按比例判;要拆就让 dev 单独开 PR;已入队才读到本条 ⇒ 撤回只
-有
-转 draft。路径面干净的才转 ready → 入队(队列是唯一被认可的落地路径,⛔ 永不队列
-外 `--auto` 合并)。**入队资格 = PR 上每一个 check 全绿,⛔ 不是 required 子集** —— required 集是
+合 diff 一条命中就分叉,⛔ 不按比例判;要拆就让 dev 单独开 PR;已入队才读到本条 ⇒ 撤回
+只有转 draft。**skills 车道自有 PR 再按 diff 内容分流**(维护者 2026-08-26 裁定,原话:「skills 中的
+pr，只有包含md文件时需要推给我审核，其他代码文件你直接自己审核。」):diff 含任一 `.md` 文件 ⇒
+上述终局四件套照旧;纯代码面(`scripts/pm/` 工具、`.claude/` hooks/workflows/settings、`skills/**` 非
+md 产物)⇒ skills 席按契约复审档自审(清单不减)后直接落地(ready → 入队),⛔ 不推维护者;分
+流只及 skills 车道自有 PR,其它车道 governed 面照旧。路径面干净的才转 ready → 入队
+(队列是唯一被认可的落地路径,⛔ 永不队列外 `--auto` 合并)。**入队资格 = PR 上每一个 check
+全绿,⛔ 不是 required 子集** —— required 集是
 队列强制的地板,不是 PM 放行的门槛;非必查门的红要么是真缺陷要么是坏门,两者都归 PM 入
 队前处置(实测:一张 required 全绿、非必查类型门与一个测试分片红着的 PR 经队列落地,该仓
 main 红了约一小时,逐 PR 连环红到 fix-forward 才止)。本段只适用本循环派发的 dev PR;PM 自己的
@@ -928,7 +923,7 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
 卡面块是落卡与升级的
 必备件**(四棱维护者 2026-08-11 接受;标准块 2026-08-18 裁定「同意」;同裁定的摘要视图/批量决
 裁通道已退
-役,墓碑与原话见「回批入口」;收件箱由维护者定期与 AI
+役,墓碑与原话见「常设决裁流程」;收件箱由维护者定期与 AI
 讨论消化,⛔ 不 assign 推送 —— 维护者 2026-08-19 裁定:「我感觉决策卡推给我太麻烦了,我需要和ai讨论才能判断,这个还是维
 持之前的样子。我会定期和ai讨论。」),每张 `needs-user-decision` 卡落卡即带、⛔
 不留待维护者到场再补。**四维分析从业务的角度写**(2026-08-20 裁)—— 落卡分析模板、写法
@@ -944,10 +939,15 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
 指向它,队列其余照常消化,⛔ 永不整席等答复。`AskUserQuestion` 只是**在场加速器**:仅当维护
 者在本会话
 ~30 分钟内有过人类输入才可发,每问必带推荐项,被 Skip 或长挂即转卡通道 ⛔ 不重弹 ——
-卡先于弹窗存在,弹窗怎么死盘面都诚实。**回批入口**:维护者说「处理决策卡」= 当轮扫全
-部 open
-决策卡批量呈报清积压,即上句「定期和ai讨论」的常规触发词,⛔ 不复活已退役的汇总
-issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么用」)。
+卡先于弹窗存在,弹窗怎么死盘面都诚实。
+**常设决裁流程:决裁与跨仓 skills/指令面工作统一归 skills 席,维护者驱动的人工流**(维护者
+2026-08-26 两裁,原话:「skills 和决裁的问题,还是由skills席统一人工处理,我会要求你处理某个仓的skills
+和决裁。」;「决裁流程今天这样很好，决策卡5张一组，从业务的角度给我具体解释，说明可选项，并进行四维
+分析。应该写入技能。」):维护者说「处理决策卡」即入口;每批 ≤5 张按优先序
+呈报,每卡业务角度具体解释 + 选项与真实代价 + 四维分析 + 一个推荐;一行回批
+(「1A 2B …」;「X, 但…」= 附带条件随执行落地)即全链执行,裁后四件原子执行不再请示;
+批间新到滚入下批,收件箱清零才收工 —— 批序与细则见 `references/decision-analysis.md`;
+⛔ 不复活已退役的汇总 issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么用」)。
 
 ## 护栏(Guardrails,有约束力)
 
@@ -962,10 +962,9 @@ issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么
   陷上报。
 - **Governed 面由维护者人工合并,合并即审核记录**(三裁一脉:2026-08-08「adr 只能由维护者自己确
   认,人工合并,ai 不得擅自合并」;2026-08-11「所有 skills 的更新和adr 类似,需要人工审核」;
-  2026-08-18 对「人工合并即人工审核,事后审计代替事前门」整包:「同意。」)。面 = ACCEPT 路
-  径分叉
-  的统一定义,禁令三条与离队出口同见该节;事后防线 = 审计清单,维护者不认识的条目 = 席
-  位违规,立案回滚。
+  2026-08-18 对「人工合并即人工审核,事后审计代替事前门」整包:「同意。」)。面 = ACCEPT
+  路径分叉的统一定义;skills 车道纯代码 PR 的 md-content 分流、禁令三条与离队出口同见该节;
+  事后防线 = 审计清单,维护者不认识的条目 = 席位违规,立案回滚。
 - **决定属于维护者:永不代维护者回答产品/架构问题**(唯一例外:分诊职责里已裁的代裁车
   道,边界恰
   与其置信门重合,不得更宽);**永不派发 assignee 是别人的 issue;永不派发带 `needs-user-decision`

.claude/skills/pm-dispatch/references/decision-analysis.md

@@ -1,22 +1,23 @@
 # 决策分析写法 —— 四维从业务角度写
 
-出处(维护者 2026-08-20 裁定,逐字,未译):「四维分析应该从业务的角度写我才好判断」。范例
-实测一
-行:同一问题,实现视角的分析让维护者追问「给我从业务的角度具体解释」,业务视角版当场
-裁决 —— 一次
-追问 vs 当场可裁,就是本指引的全部理由。
+出处(维护者 2026-08-20 裁定,逐字,未译):「四维分析应该从业务的角度写我才好判断」。
 
 ## 适用面(边界)
 
 - 只约束 **`needs-user-decision` 卡与决策箱讨论**的四维分析;内部工具卡(dev 派发用)的四维照
   旧,不强加行业类比。四条轴本身不变,轴定义与绑定句在主文件「升级与决策」。
 - 只适用新记录,存量分析 ⛔ 不回改(new-records-only,与四维中文化同款先例)。
 
+## 常设决裁批流程(2026-08-26 裁;裁决原话与归席见主文件「升级与决策」)
+
+- 每批 ≤5 张,批序:在飞被阻塞 > 运营阻塞 > 用户可见 > 结构性;每卡 = 六项写法 + 四棱块;
+  回批一行式「1A 2B …」,「X, 但…」= 附带条件随执行落地;裁后四件原子执行不再请示,
+  一口气跑完;批间新入箱的卡滚入下一批,收件箱读数为零才收工。
+
 ## 落卡分析模板(主文件「落卡/升级流程」②的 references 细则;中文,2026-08-19 裁)
 
-段落骨架:背景 / 带 re-check 命令的前提 / 具体问题 / 选项 / 推荐 / 相关单与 PR;标签就是维护
-者的
-收件箱,答复后按四件录裁。正文六项写法要求:
+段落骨架:背景 / 带 re-check 命令的前提 / 具体问题 / 选项 / 推荐 / 相关单与 PR;录裁与状态
+转换归主文件「落卡/升级流程」③。正文六项写法要求:
 
 1. **一句话问题**:开头一句话说清冲突是什么,不带实现名词 —— 写「三家公司住一个数据库,管理员打
    开权限管理,三个页面全空」,不写「organization_id = NULL 的行是什么,两个互相矛盾的答案都已落地」。
@@ -27,8 +28,7 @@
 4. **四轴从业务立场论证**:每轴的论据是客户/产品/事故后果,机制只作括号补
    充;「防 AI 犯错」轴写清
    出错时**谁看到什么**(响亮拒绝 vs 静默泄露)。
-5. **推荐 + 回退 + 置信缺口**:荐一项、给回退项、明说本分析看不见什么;结尾给低摩擦裁决格式(「回
-   一个字母即可;或『C,但 X』= 自动落到 B」)。
+5. **推荐 + 回退 + 置信缺口**:荐一项、给回退项、明说本分析看不见什么;格式见批流程。
 6. **裁后执行段**:「裁后我会怎么执行(你不用管)」—— 让维护者只裁方向不背执行。
 
 ## 四棱卡面块固定形状(落卡即带,⛔ 不留待维护者到场再补)