From 2e75602f50514a2d90b77099bc079189a849b3b0 Mon Sep 17 00:00:00 2001
From: Cai <cai@nbcai.cc>
Date: Sun, 02 Aug 2026 17:33:57 +0800
Subject: [PATCH] docs: update shared governance guidance

---
 common/project-doc/项目规范.md        |   14 +++++++++-----
 common/ai-workplace/AI工作空间创建指南.md |   10 ++++++++++
 全局规范.md                           |   14 ++++++++++++++
 3 files changed, 33 insertions(+), 5 deletions(-)

diff --git "a/common/ai-workplace/AI\345\267\245\344\275\234\347\251\272\351\227\264\345\210\233\345\273\272\346\214\207\345\215\227.md" "b/common/ai-workplace/AI\345\267\245\344\275\234\347\251\272\351\227\264\345\210\233\345\273\272\346\214\207\345\215\227.md"
index d24261d..66cb76d 100644
--- "a/common/ai-workplace/AI\345\267\245\344\275\234\347\251\272\351\227\264\345\210\233\345\273\272\346\214\207\345\215\227.md"
+++ "b/common/ai-workplace/AI\345\267\245\344\275\234\347\251\272\351\227\264\345\210\233\345\273\272\346\214\207\345\215\227.md"
@@ -311,6 +311,14 @@
 6. MB-X 消息和角色窗口只展示摘要、关键行、文件路径、证据入口、结论和期望动作，不复制大段正文。
 7. 处理 context window full 时，不得未经确认直接创建新 thread；应先备份、摘要、裁剪、记录审计并尝试原 thread 恢复。
 
+## 8.1 Codex 客户端原生任务通信
+
+1. 运行于 Codex 客户端且原生任务工具可用时，角色间通信默认使用 `list_threads`、`read_thread`、`send_message_to_thread` 和 `wait_threads`。
+2. 正式交接使用 `<codex_native_handoff>`，明确来源/目标任务与角色、`reply_thread_id`、唯一 `handoff_id`、范围、证据、状态和期望动作。
+3. 原生发送成功只代表 `dispatch_accepted`；observed 和 completed 必须分别由目标独立 turn/cursor 和明确终态证明。
+4. 同一 handoff 单目标、单次发送；不得因等待、超时或状态不确定而重发、改投、Queue、Steer 或创建 A002。
+5. `mbx send`、`mbx interaction route`、`mbx inbox` 和旧 route/inbox/session 文件链只保留为无原生工具环境下的兼容路径，且必须由人类或管理角色明确启用，不得自动回退。
+
 ## 9. 审核边界
 
 如果本 AI 是审核员：
@@ -392,6 +400,7 @@
 13. 是否写清 `项目问题反馈.md` 的入口和边界：只反馈重大协作问题，不替代正式审计报告、问题记录或执行日志。
 14. 是否说明 `项目问题反馈.md` 的写法参考 `common/ai-workplace/项目问题反馈范本.md`。
 15. 是否引用 `common/ai-workplace/AI技能使用规范.md`，并写清技能显式声明、状态变更记录、消息交互和失败越权处理口径。
+16. 如果角色运行于 Codex 客户端，是否把原生任务通信写成默认路径，并明确 `dispatch_accepted != observed != completed`、单目标单次发送和不得自动回退旧 MB-X inbox/route。
 
 组合角色还必须按角色类型做专项校验：
 
@@ -422,6 +431,7 @@
 5. 项目执行日志和项目变更记录已记录影响。
 6. 未启用体系没有被越权写入正式权限。
 7. 目标开发工作区没有被误创建成第二套开发体系。
+8. Codex 角色首次阅读即可说清原生任务发现、核验、发送、等待和终态判定方法；生成的工作说明与会话启动提示不得把 `mbx send/inbox` 写成 Codex 环境默认路径。
 
 ## 7. 变更影响说明
 
diff --git "a/common/project-doc/\351\241\271\347\233\256\350\247\204\350\214\203.md" "b/common/project-doc/\351\241\271\347\233\256\350\247\204\350\214\203.md"
index b132aa7..4e0ec45 100644
--- "a/common/project-doc/\351\241\271\347\233\256\350\247\204\350\214\203.md"
+++ "b/common/project-doc/\351\241\271\347\233\256\350\247\204\350\214\203.md"
@@ -104,13 +104,14 @@
 事项来源 / 聊天要求 / 上游文档
 -> 写入项目事项总纲，说明背景、目标、边界、当前状态
 -> 拆分到项目事项计划，明确负责人、步骤、输入、输出、验收方式
--> 项目事项计划审计，检查计划是否合理、是否对齐来源聊天和项目目标
+-> 判断事项风险与复杂度
+-> 普通、可逆、项目内事项直接执行；实质高风险或复杂事项才做计划审计
 -> 执行事项
 -> 在项目执行日志记录关键节点、关键输入、关键输出、偏离和当前状态
 -> 必要时写项目变更记录
--> 项目事项执行审计，检查执行是否按计划完成、证据链是否闭合
+-> 普通事项由请求者或安排者验收；实质阶段门才做独立执行审计
 -> 如审计发现问题，主记录写项目事项审计报告；如非审计人员发现问题，主记录写项目问题记录
--> 修复后复审
+-> 同一轮问题一次给全，合并修复后做一次必要复审
 -> 结论回写到项目事项总纲和项目事项计划
 -> 事项完成 / 暂停 / 取消
 ```
@@ -119,10 +120,11 @@
 
 1. 项目事项开始前，必须能在项目事项总纲中找到背景、目标和关键来源聊天记录或上游路径。
 2. 项目事项执行前，必须能在项目事项计划中找到拆分步骤、输入输出、验收方式和来源聊天记录。
-3. 项目事项计划必须先审计，审核员要判断计划是否合理，是否能满足事项目标，是否和来源聊天记录一致；计划审计未通过，不得进入执行。
+3. 普通、可逆、项目内 L0/L1 事项不要求实施前独立计划审计；涉及权限扩张、不可逆外部写入、凭据、破坏性数据操作、正式发布、跨项目/跨控制面或重大结论的事项，才要求在执行前通过相应独立审核。
 4. 项目事项执行中，关键节点必须写入项目执行日志。
-5. 项目事项结束前，必须做执行审计；执行审计未通过，不得标记完成。
+5. 普通事项完成后由请求者或安排者做功能/结果验收即可；需要独立审核的事项，审核应集中在实质阶段门，不做逐动作、逐文件或逐尝试复核。
 6. 如果事项改变了项目目标、边界、角色、目录、体系启用状态或关键规范，必须同时进入项目变更流程。
+7. 同一已登记事项内的普通修复和重跑不要求新建逐次 A001；确需授权时，优先使用项目级事项、时间窗或阶段范围合同。
 
 ### 3.3 项目变更流程
 
@@ -412,6 +414,8 @@
 
 审核员不得把不影响事项目标、结论、关键证据链或下游使用的边角料问题升级为阻断问题；不得通过拆分步骤审计的方式层层加码。
 
+审核员应在一轮中返回完整的实质问题集合。除非修订引入新的实质风险，不得围绕同一边界连续制造单点 supplemental 审核、权限存在性审核或逐尝试审核。
+
 在不同体系中，事项单元对应如下：
 
 | 体系 | 审核事项单元 |
diff --git "a/\345\205\250\345\261\200\350\247\204\350\214\203.md" "b/\345\205\250\345\261\200\350\247\204\350\214\203.md"
index a2f8f7d..3783e8f 100644
--- "a/\345\205\250\345\261\200\350\247\204\350\214\203.md"
+++ "b/\345\205\250\345\261\200\350\247\204\350\214\203.md"
@@ -387,6 +387,18 @@
 
 临时事项一旦被后续引用、进入交付、影响结论或被纳入正式结果，必须补齐为正式事项证据链。
 
+## 9.5 实用优先与最小充分治理
+
+MB-X 默认遵循“实用、快速落地、小步快跑、避免过度设计”。治理的作用是保护目标、边界和关键证据，不是证明每一个动作都再次获得许可。
+
+1. 先做满足当前目标的最小可用闭环；没有真实需求、失败证据或容量压力，不提前设计复杂扩展机制。
+2. 项目内普通、可逆、可验证的文档、代码、测试、下载、文件整理、工具操作和角色日常工作，在已登记事项与角色范围内直接执行并普通验收，不做逐动作、逐文件、逐命令、逐尝试审批。
+3. 默认使用语义验收。字节级冻结仅用于外部原始证据、正式证据包或 manifest、签名/JCS 协议、合规材料、数据库回执以及明确要求不可变的接口契约。
+4. 独立审核只放在会实质影响目标、结论、权限边界、安全、不可逆外部状态或正式发布的阶段门。风险提高审核强度，不改变“职责就近、项目内决定由项目角色作出”的归属。
+5. 同一轮审核应一次返回完整的实质问题集合；修复方做一次合并修订，再做一次必要复核。不得为证明“上一次审核存在”而增加元审核，也不得把一个问题拆成连续多轮授权链。
+6. 可修复的普通错误允许在同一事项内修正并重跑；只有越界、不可逆副作用、凭据暴露、访问控制、数据破坏或状态不确定时才停止并升级。
+7. 旧流程与旧失败历史保持可追溯，但新事项按本原则执行；不得因历史上曾使用逐次授权而自动沿用。
+
 ## 10. 审核规范
 
 审核的目标是发现真问题，不是制造流程负担。
@@ -409,6 +421,8 @@
 4. 非核心可读性建议。
 5. 不影响主流程的诊断项缺失。
 
+审核员还必须遵守最小充分原则：普通事项由请求者或安排者验收即可；需要独立审核时，以完整事项或实质阶段门为单位，一次给全问题，不逐文件、逐步骤、逐尝试重复审核。
+
 审核复杂事项时，可以拆分审计步骤，也可以使用 subagent，但必须由主审核员整合判断，不得直接转发未经复核的碎片结论。
 
 ## 11. 真 Bug 和问题归因规范

--
Gitblit v1.9.3