1
2026-06-08 6a3005dcd03089561de45c9742d816c023f65309
全局规范.md
@@ -256,7 +256,7 @@
3. 开发 AI:按目标体系绑定 `dev/<target>-dev/`、`dev/<target>-dev/test/`、`dev-doc/<target>-doc/` 写权限;不默认拥有所有开发子目录写权限。
4. 实验员:`exp-doc/`、`exp-data/` 写权限。
5. 案例分析员:`ana-doc/`、`ana-data/` 写权限。
6. 审核员:主写对应审计报告;如审计问题需要跨轮跟踪,只在问题记录中写索引或关联,不直接改被审计产物。
6. 审核员:主写对应审计报告;如审计问题需要跨轮跟踪,只在问题记录中写索引或关联;可维护自己审核职责对应的本地审核 / 审计规范,但不默认改被审计产物或被审体系执行规范。
所有 AI 默认拥有项目内所有文件的读权限。
@@ -293,6 +293,7 @@
3. 写审计报告。
4. 在需要跨轮跟踪时写问题记录索引或关联。
5. 要求执行者补证据、修复或重跑。
6. 维护自己审核职责对应的本地审核 / 审计规范文档,例如 `实验审计规范.md`、`案例审核规范.md`、`开发审计规范.md`、`需求审核规范.md`。该权限只用于审核流程、审计口径和阻断标准维护,不得削弱全局规范、全局项目规范或 common 体系硬约束。
审核员默认不得:
@@ -300,8 +301,11 @@
2. 直接替执行者修改业务主表。
3. 用自己的补丁掩盖执行问题。
4. 把边角料问题升级成阻断问题。
5. 以审核员身份直接修改被审体系执行规范、事项设计 / 计划、执行日志、结果包或正式主产物;例如实验审核员不默认修改 `实验规范.md`,案例审核员不默认修改 `案例分析规范.md`。
如果审核员必须临时修复工具脚本,应明确标记为“审计辅助脚本”,不能冒充执行方正式产物。
如果确实需要修改被审体系执行规范,应创建独立的规范维护事项,或在 `项目配置清单.md` 中额外授予体系维护员 / 规范维护员角色;修改必须记录原因、影响范围、证据路径和复审入口,重大改动应由项目管理员或另一个审核员确认。
## 7. 项目根目录 `项目规范.md` 规范
@@ -599,7 +603,7 @@
2. 项目体系和开发体系默认随项目创建;其他体系由项目管理员按需启用。
3. 启用体系后,项目必须遵守 common 规范和本地规范;开发体系在未创建具体目标开发工作区前,先遵守 common/dev-doc 全局开发规范。
4. 正式文档必须有职责、引用、记录方式和目录入口;非文档产物必须能通过 manifest、索引或日志追溯。
5. 权限跟角色走,审核员不直接改被审计产物。
5. 权限跟角色走,审核员可维护对应本地审核 / 审计规范,但不直接改被审计产物或被审体系执行规范。
6. 开发体系绑定目标体系,代码放 `dev/<target>-dev/`,目标代码文档和方案附件放 `dev-doc/<target>-doc/`;正式开发账本统一放 `dev-doc/` 根目录。
7. 所有正式事项必须有目标、过程、结果和审计证据链。
8. 审核抓真问题,不吹毛求疵,不层层加码。