From bf157a136d9b08c14b4da2997dc5a03b1a1af33d Mon Sep 17 00:00:00 2001
From: Cai <cai@nbcai.cc>
Date: Mon, 07 Sep 2026 12:59:24 +0800
Subject: [PATCH] docs: update governance and operations guidance

---
 common/project-doc/项目规范.md |   95 +++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 90 insertions(+), 5 deletions(-)

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 533947b..faea2d6 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"
@@ -44,6 +44,20 @@
 9. 项目规范只记录项目特化内容，不重复抄写全局规范和体系规范。
 10. 项目级管理动作必须有日志和审计入口。
 11. 项目内具体事项必须能追到项目目标和启用体系。
+12. 当 `mb-ms-doc` 作为工作区管理根目录时，工作区内的业务子项目目录应以 `project-` 开头；每个业务子项目应拥有独立 Git 仓库，不加入 `mb-ms-doc` 仓库管理。
+
+### 2.1 业务子项目目录与 Git 边界
+
+`mb-ms-doc` 仓库保存全局规范、体系模板、公共文档和管理根目录规则，不直接管理具体业务子项目的版本历史。
+
+工作区内的业务子项目按以下口径管理：
+
+1. 业务子项目目录建议统一使用 `project-<name>` 命名，便于管理根目录 `.gitignore` 排除和人工识别。
+2. 每个业务子项目应在自身项目根目录内初始化独立 Git 仓库。
+3. 业务子项目不得作为普通文件加入 `mb-ms-doc` 仓库提交。
+4. `mb-ms-doc` 根仓库应排除 `project-*` 业务子项目目录。
+5. 如果历史项目、示例项目或特殊项目暂时不满足 `project-*` 命名，应在项目总览、项目配置清单或项目变更记录中说明原因和 Git 管理边界。
+6. 项目管理员创建新项目时，应同步确认项目目录名、独立 Git 仓库、远端地址、提交身份和管理根目录排除规则。
 
 ## 3. 核心流程
 
@@ -90,13 +104,14 @@
 事项来源 / 聊天要求 / 上游文档
 -> 写入项目事项总纲，说明背景、目标、边界、当前状态
 -> 拆分到项目事项计划，明确负责人、步骤、输入、输出、验收方式
--> 项目事项计划审计，检查计划是否合理、是否对齐来源聊天和项目目标
+-> 判断事项风险与复杂度
+-> 普通、可逆、项目内事项直接执行；实质高风险或复杂事项才做计划审计
 -> 执行事项
 -> 在项目执行日志记录关键节点、关键输入、关键输出、偏离和当前状态
 -> 必要时写项目变更记录
--> 项目事项执行审计，检查执行是否按计划完成、证据链是否闭合
+-> 普通事项由请求者或安排者验收；实质阶段门才做独立执行审计
 -> 如审计发现问题，主记录写项目事项审计报告；如非审计人员发现问题，主记录写项目问题记录
--> 修复后复审
+-> 同一轮问题一次给全，合并修复后做一次必要复审
 -> 结论回写到项目事项总纲和项目事项计划
 -> 事项完成 / 暂停 / 取消
 ```
@@ -105,10 +120,11 @@
 
 1. 项目事项开始前，必须能在项目事项总纲中找到背景、目标和关键来源聊天记录或上游路径。
 2. 项目事项执行前，必须能在项目事项计划中找到拆分步骤、输入输出、验收方式和来源聊天记录。
-3. 项目事项计划必须先审计，审核员要判断计划是否合理，是否能满足事项目标，是否和来源聊天记录一致；计划审计未通过，不得进入执行。
+3. 普通、可逆、项目内 L0/L1 事项不要求实施前独立计划审计；涉及权限扩张、不可逆外部写入、凭据、破坏性数据操作、正式发布、跨项目/跨控制面或重大结论的事项，才要求在执行前通过相应独立审核。
 4. 项目事项执行中，关键节点必须写入项目执行日志。
-5. 项目事项结束前，必须做执行审计；执行审计未通过，不得标记完成。
+5. 普通事项完成后由请求者或安排者做功能/结果验收即可；需要独立审核的事项，审核应集中在实质阶段门，不做逐动作、逐文件或逐尝试复核。
 6. 如果事项改变了项目目标、边界、角色、目录、体系启用状态或关键规范，必须同时进入项目变更流程。
+7. 同一已登记事项内的普通修复和重跑不要求新建逐次 A001；确需授权时，优先使用项目级事项、时间窗或阶段范围合同。
 
 ### 3.3 项目变更流程
 
@@ -198,6 +214,42 @@
 ```
 
 项目级问题只记录项目治理问题。具体需求、代码、实验、案例分析问题，优先记录到对应体系的问题文档；如果这些问题影响项目级目录、权限、目标或体系启用，再同步登记项目级问题或变更。
+
+### 3.6 AI 工作空间问题反馈与反复返修升级
+
+每个 AI 工作空间中的 `项目问题反馈.md` 是该 AI 向项目管理员反馈重大协作问题的私有入口。
+
+它服务于项目治理，不替代正式审计报告、项目问题记录、体系问题记录或执行日志。
+
+适合写入：
+
+1. 角色权限、工作空间、体系入口、流程边界不清，已经影响项目或体系推进。
+2. 同一事项或同类问题多轮返修后仍重复出现，通常大于等于 3 次。
+3. 审核员判断需要项目管理员介入协调、收口口径、调整角色、调整流程或暂停扩展。
+4. AI 首次阅读工作说明、项目配置清单或体系规范后，发现职责/权限/入口存在影响执行的重大不清楚。
+
+审核员发现被审事项存在问题时，仍必须先把正式审计结论写入对应审计报告。  
+如果同一问题经过多轮返修仍重复出现，审核员应额外在自己工作空间的 `项目问题反馈.md` 追加一条反复返修问题反馈。
+
+反复返修问题反馈必须尽量记录清楚：
+
+1. 关联事项 ID。
+2. 关联计划 ID 或设计 ID。
+3. 关联执行日志 ID。
+4. 关联审计报告 ID。
+5. 问题发生步骤。
+6. 反复次数。
+7. 已要求修复内容。
+8. 为什么判断为反复问题。
+9. 影响范围。
+10. 关联证据路径。
+11. 建议项目管理员介入方式。
+12. 修复建议。该字段必填，至少给出下一步应怎么收敛。
+13. 是否需要完整方案。如果问题复杂、反复难修或涉及多模块/多流程，应标记为“是”。
+14. 完整方案路径。需要完整方案时填写，例如代码修复方案、流程整改方案或专项收敛方案路径。
+15. 方案摘要。需要完整方案时，摘要说明方案核心动作、责任边界和验收方式。
+
+`项目问题反馈.md` 的写法参考 `common/ai-workplace/项目问题反馈范本.md`，但不要求逐字复制范本。项目文件只要保留关键字段、记录边界和 append 写法即可。
 
 ## 4. 核心文档
 
@@ -345,6 +397,39 @@
 
 ## 7. 项目审计边界
 
+### 7.1 事项级整体审核原则
+
+审核员审核事项时，必须以事项为基本单元，而不是以单个步骤、单个文件或单个输出为基本单元。
+
+事项单元以对应体系总纲文档中的一个目标 / 事项条目为准。审核员应围绕该事项整体检查：
+
+1. 目标是否清楚。
+2. 设计 / 计划是否能支撑目标。
+3. 执行日志是否覆盖关键节点。
+4. 关键输入、关键输出、关键数据和关键产物是否可追踪。
+5. 结论是否回写。
+6. 问题是否闭环。
+
+如果审核过程中发现关键节点、关键数据、关键产物或关键证据链缺失，应作为审计问题反馈。
+
+审核员不得把不影响事项目标、结论、关键证据链或下游使用的边角料问题升级为阻断问题；不得通过拆分步骤审计的方式层层加码。
+
+审核员应在一轮中返回完整的实质问题集合。除非修订引入新的实质风险，不得围绕同一边界连续制造单点 supplemental 审核、权限存在性审核或逐尝试审核。
+
+在不同体系中，事项单元对应如下：
+
+| 体系 | 审核事项单元 |
+|---|---|
+| 项目体系 | `项目事项总纲.md` 中的一个项目事项 |
+| 需求体系 | `需求总纲.md` 中的一个需求目标或需求事项 |
+| 开发体系 | `开发事项总纲.md` 中的一个开发事项 |
+| 实验体系 | `实验总纲.md` 中的一个实验目标或实验事项 |
+| 案例分析体系 | `案例总纲.md` 中的一个案例目标或案例事项 |
+| 数据体系 | 数据体系总纲或数据事项账本中的一个数据目标或数据事项 |
+| 运维体系 | `运维事项总纲.md` 中的一个运维事项或一次事故处置 |
+
+### 7.2 项目级审计边界
+
 项目级审计重点看：
 
 1. 项目是否有清晰目标和边界。

--
Gitblit v1.9.3