摘要
基于强模型 PM 视角，对组织治理体系进行了 32 次模拟运行测试（覆盖产品仓/治理仓/支撑仓共 11 个仓库）。PM 平均置信度 4.8/10，仅 9% 场景可达可执行水平（≥8/10），38% 场景严重困惑需人工介入。
核心发现：治理意图设计优秀，但从「理解」到「行动」的最后一公里存在大量断裂。
测试设计
| 类别 |
Run 数 |
覆盖仓库 |
| 产品仓进入 |
12 |
AI_Web_School, Shorts_Director, Script_Writer, mutual, QW_Arena1 |
| 治理仓进入 |
10 |
.github, CI-Workflows, archive, template-service |
| 支撑仓进入 |
6 |
arbiter, holdout, cnb-bridge |
| 跨仓操作 |
4 |
CNB 派单, ADR 归档, drift-check, 红队审计 |
置信度分布
| 区间 |
Run 数 |
占比 |
| 8-10（可执行） |
3 |
9% |
| 5-7（有疑虑但能推进） |
14 |
44% |
| 3-4（严重困惑） |
12 |
38% |
| 1-2（无法执行） |
3 |
9% |
致命问题（P0，阻断级）
1. docs/pm/PLAYBOOK.md 不存在（11 次引用落空）
GOVERNANCE.yaml、AGENTS.md、archive/runs/README.md 共 11 次引用「见 PLAYBOOK §X」，但文件 404。PM 入职第三步直接断链。
建议：创建该文件，至少覆盖入职三步、C1 发起路径、spec 位置规则、drift-check 命令。
2. Spec 位置歧义（9 次困惑）
治理 specs 在 .github/specs/IR-XXXX/，但产品 feature specs 位置无明确规则。PM 不知道在哪个仓库创建、是否需要 C1。
建议：一行规则——「产品 feature specs 在 <repo>/specs/<IR-NNNN>/；治理 specs 在 .github/specs/IR-XXXX/。」
3. g060 引导悖论（8 次困惑）
specs/*/suite/** 被 g060 锁定，仅 owner + verifier-app 可写。但 PM/agent 创建第一个 spec 的 suite/ 时就会被锁挡下。
建议：说明初始 spec+suite 创建由谁执行（owner? spec-author workflow?），g060 何时开始生效。
4. C1「本地 drift-check 预检」无命令（8 次困惑）
C1 要求 drift-check 本地预检，但 template-service 无 make drift-check，CI-Workflows 无 Makefile，脚本需要 org admin PAT + jq + pyyaml。
建议：提供非 admin 只读模式的 drift-check 降级脚本，或在 .github 仓 Makefile 添加 drift-check 目标。
5. Card 流程 vs 治理变更流程冲突（7 次困惑）
入口协议「无卡不开工」，C1 流程说「PR+ADR+owner-merge」——治理变更是否需要 card？PM 主动发起治理变更时无入口。
建议：明确「治理变更不需要 card，走 C1 流程即可」。
严重问题（P1，1-2 周修复）
| # |
问题 |
频次 |
| 6 |
PM persona vs App 硬规则边界不明（PM 能否改 .github/workflows/） |
6 |
| 7 |
Spec PR 红测试 vs 绿色门禁矛盾（gate 能否容忍红测试） |
6 |
| 8 |
conductor/arbiter 触发方式不明（ghcb 无此子命令） |
5 |
| 9 |
C1 vs C3 分类歧义（.github 仓根部文件归属） |
5 |
| 10 |
run report 义务不在被分配仓的 AGENTS.md 中 |
5 |
| 11 |
C2 validate 门退役的实际含义 |
4 |
| 12 |
语言策略多语言仓未定义 |
4 |
中等问题（P2，1-2 月修复）
- ADR 编号归属与存储位置（archive/adr/ 但 INDEX 更新流程不明）
make gates-pr 在 CI-Workflows 不存在- org-gate 修改后无法在合并前测试（required workflow 跳过自身仓）
- ruleset pin 更新机制无文档
- CNB "ledger" 一词多义（work-inbox / butler-ledger / metering）
- holdout canary drill 无单页 runbook
- talk repo 404（CNB 执行面不可达）
- butler-ledger 当前 401 故障
- "retire ADR" 操作未定义（ADR 三态无 retired）
- 租约「卡住」无人工升级流程
PM 实际能跑通的路径
| 场景 |
置信度 |
| CI-Workflows 添加新 workflow |
8/10 |
| AI_Web_School 创建 IR |
8/10 |
| template-service C1 判定（分类） |
9/10 |
核心发现：PM 对「治理意图」的理解远高于对「执行路径」的理解。GOVERNANCE.yaml 的 intent/verify 模型在认知层面成功，但从「理解」到「做」的最后一公里断裂。
根因总结
- 文档引用链断裂 — 被引用的核心文件不存在
- 两套入口协议未整合 — agent card 流程 vs PM spec 流程
- 治理变更的「发起端」缺失 — 所有文档假设已有 card/spec/PR
- 产品仓与治理仓距离过远 — 需要跨 3-4 个 repo 拼凑路径
- 执行层工具缺失 — drift-check 命令、dr 降级模式、本地 Makefile
建议修复优先级
P0（立即）
P1（1-2 周）
P2（1-2 月）
附件
详细 32 次 run 报告（含每次的具体困惑点、假设、置信度评分）已存档于本次审计会话。如需展开某个具体问题的修复方案，可拆分新卡。
摘要
基于强模型 PM 视角，对组织治理体系进行了 32 次模拟运行测试（覆盖产品仓/治理仓/支撑仓共 11 个仓库）。PM 平均置信度 4.8/10，仅 9% 场景可达可执行水平（≥8/10），38% 场景严重困惑需人工介入。
核心发现：治理意图设计优秀，但从「理解」到「行动」的最后一公里存在大量断裂。
测试设计
置信度分布
致命问题（P0，阻断级）
1. docs/pm/PLAYBOOK.md 不存在（11 次引用落空）
GOVERNANCE.yaml、AGENTS.md、archive/runs/README.md 共 11 次引用「见 PLAYBOOK §X」，但文件 404。PM 入职第三步直接断链。
建议：创建该文件，至少覆盖入职三步、C1 发起路径、spec 位置规则、drift-check 命令。
2. Spec 位置歧义（9 次困惑）
治理 specs 在
.github/specs/IR-XXXX/，但产品 feature specs 位置无明确规则。PM 不知道在哪个仓库创建、是否需要 C1。建议：一行规则——「产品 feature specs 在
<repo>/specs/<IR-NNNN>/；治理 specs 在.github/specs/IR-XXXX/。」3. g060 引导悖论（8 次困惑）
specs/*/suite/**被 g060 锁定，仅 owner + verifier-app 可写。但 PM/agent 创建第一个 spec 的 suite/ 时就会被锁挡下。建议：说明初始 spec+suite 创建由谁执行（owner? spec-author workflow?），g060 何时开始生效。
4. C1「本地 drift-check 预检」无命令（8 次困惑）
C1 要求 drift-check 本地预检，但 template-service 无
make drift-check，CI-Workflows 无 Makefile，脚本需要 org admin PAT + jq + pyyaml。建议：提供非 admin 只读模式的 drift-check 降级脚本，或在 .github 仓 Makefile 添加 drift-check 目标。
5. Card 流程 vs 治理变更流程冲突（7 次困惑）
入口协议「无卡不开工」，C1 流程说「PR+ADR+owner-merge」——治理变更是否需要 card？PM 主动发起治理变更时无入口。
建议：明确「治理变更不需要 card，走 C1 流程即可」。
严重问题（P1，1-2 周修复）
中等问题（P2，1-2 月修复）
make gates-pr在 CI-Workflows 不存在PM 实际能跑通的路径
核心发现：PM 对「治理意图」的理解远高于对「执行路径」的理解。GOVERNANCE.yaml 的 intent/verify 模型在认知层面成功，但从「理解」到「做」的最后一公里断裂。
根因总结
建议修复优先级
P0（立即）
docs/pm/PLAYBOOK.mdP1（1-2 周）
P2（1-2 月）
附件
详细 32 次 run 报告（含每次的具体困惑点、假设、置信度评分）已存档于本次审计会话。如需展开某个具体问题的修复方案，可拆分新卡。