| | |
|---|
| | | |
|---|
| | | ## 3. 体系插件原则 |
|---|
| | | |
|---|
| | | `common/` 下的需求体系、开发体系、实验体系、数据体系、案例分析体系，都是体系插件。项目体系和开发体系是项目创建时默认自带的基础体系；其他体系由项目管理员按需启用。 |
|---|
| | | `common/` 下的需求体系、开发体系、实验体系、数据体系、案例分析体系、运维体系，都是体系插件。项目体系和开发体系是项目创建时默认自带的基础体系；其他体系由项目管理员按需启用。 |
|---|
| | | |
|---|
| | | 默认口径： |
|---|
| | | |
|---|
| | | 1. `common/` 是全局能力库。 |
|---|
| | | 2. 项目创建时默认启用项目体系和开发体系。 |
|---|
| | | 3. 项目管理员决定是否额外启用需求、实验、案例分析、数据等体系。 |
|---|
| | | 3. 项目管理员决定是否额外启用需求、实验、案例分析、数据、运维等体系。 |
|---|
| | | 4. 未启用的非默认体系，不对项目产生执行义务。 |
|---|
| | | 5. 启用某个体系后，项目必须创建对应目录、入口文档和本地规范。开发体系是例外：一个项目只有一套开发体系账本和本地开发规范，项目创建时默认创建 `dev/`、`dev-doc/` 根目录；创建具体目标开发工作区时，只创建 `dev/<target>-dev/` 和 `dev-doc/<target>-doc/` 目标代码文档区，不再复制第二套开发规范或开发账本。 |
|---|
| | | 6. 启用后，项目必须同时遵守 `common` 全局体系规范和项目本地体系规范。开发体系在未创建具体目标开发工作区前，先遵守 `common/dev-doc` 全局开发规范。 |
|---|
| | |
|---|
| | | 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 默认拥有项目内所有文件的读权限。 |
|---|
| | | |
|---|
| | |
|---|
| | | 3. 写审计报告。 |
|---|
| | | 4. 在需要跨轮跟踪时写问题记录索引或关联。 |
|---|
| | | 5. 要求执行者补证据、修复或重跑。 |
|---|
| | | 6. 维护自己审核职责对应的本地审核 / 审计规范文档，例如 `实验审计规范.md`、`案例审核规范.md`、`开发审计规范.md`、`需求审核规范.md`。该权限只用于审核流程、审计口径和阻断标准维护，不得削弱全局规范、全局项目规范或 common 体系硬约束。 |
|---|
| | | |
|---|
| | | 审核员默认不得： |
|---|
| | | |
|---|
| | |
|---|
| | | 2. 直接替执行者修改业务主表。 |
|---|
| | | 3. 用自己的补丁掩盖执行问题。 |
|---|
| | | 4. 把边角料问题升级成阻断问题。 |
|---|
| | | 5. 以审核员身份直接修改被审体系执行规范、事项设计 / 计划、执行日志、结果包或正式主产物；例如实验审核员不默认修改 `实验规范.md`，案例审核员不默认修改 `案例分析规范.md`。 |
|---|
| | | |
|---|
| | | 如果审核员必须临时修复工具脚本，应明确标记为“审计辅助脚本”，不能冒充执行方正式产物。 |
|---|
| | | |
|---|
| | | 如果确实需要修改被审体系执行规范，应创建独立的规范维护事项，或在 `项目配置清单.md` 中额外授予体系维护员 / 规范维护员角色；修改必须记录原因、影响范围、证据路径和复审入口，重大改动应由项目管理员或另一个审核员确认。 |
|---|
| | | |
|---|
| | | ## 7. 项目根目录 `项目规范.md` 规范 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 临时事项一旦被后续引用、进入交付、影响结论或被纳入正式结果，必须补齐为正式事项证据链。 |
|---|
| | | |
|---|
| | | ## 9.5 实用优先与最小充分治理 |
|---|
| | | |
|---|
| | | MB-X 默认遵循“实用、快速落地、小步快跑、避免过度设计”。治理的作用是保护目标、边界和关键证据，不是证明每一个动作都再次获得许可。 |
|---|
| | | |
|---|
| | | 1. 先做满足当前目标的最小可用闭环；没有真实需求、失败证据或容量压力，不提前设计复杂扩展机制。 |
|---|
| | | 2. 项目内普通、可逆、可验证的文档、代码、测试、下载、文件整理、工具操作和角色日常工作，在已登记事项与角色范围内直接执行并普通验收，不做逐动作、逐文件、逐命令、逐尝试审批。 |
|---|
| | | 3. 默认使用语义验收。字节级冻结仅用于外部原始证据、正式证据包或 manifest、签名/JCS 协议、合规材料、数据库回执以及明确要求不可变的接口契约。 |
|---|
| | | 4. 独立审核只放在会实质影响目标、结论、权限边界、安全、不可逆外部状态或正式发布的阶段门。风险提高审核强度，不改变“职责就近、项目内决定由项目角色作出”的归属。 |
|---|
| | | 5. 同一轮审核应一次返回完整的实质问题集合；修复方做一次合并修订，再做一次必要复核。不得为证明“上一次审核存在”而增加元审核，也不得把一个问题拆成连续多轮授权链。 |
|---|
| | | 6. 可修复的普通错误允许在同一事项内修正并重跑；只有越界、不可逆副作用、凭据暴露、访问控制、数据破坏或状态不确定时才停止并升级。 |
|---|
| | | 7. 旧流程与旧失败历史保持可追溯，但新事项按本原则执行；不得因历史上曾使用逐次授权而自动沿用。 |
|---|
| | | |
|---|
| | | ## 10. 审核规范 |
|---|
| | | |
|---|
| | | 审核的目标是发现真问题，不是制造流程负担。 |
|---|
| | |
|---|
| | | 3. 低影响格式问题。 |
|---|
| | | 4. 非核心可读性建议。 |
|---|
| | | 5. 不影响主流程的诊断项缺失。 |
|---|
| | | |
|---|
| | | 审核员还必须遵守最小充分原则：普通事项由请求者或安排者验收即可；需要独立审核时，以完整事项或实质阶段门为单位，一次给全问题，不逐文件、逐步骤、逐尝试重复审核。 |
|---|
| | | |
|---|
| | | 审核复杂事项时，可以拆分审计步骤，也可以使用 subagent，但必须由主审核员整合判断，不得直接转发未经复核的碎片结论。 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 半成品、空壳文件、失败包不得被下游当成正式完成产物。 |
|---|
| | | |
|---|
| | | ## 17. 汇报规范 |
|---|
| | | ## 17. Codex 会话上下文保护规范 |
|---|
| | | |
|---|
| | | 角色窗口处理任务时，必须遵守“主体内容落文档，窗口只展示摘要和证据入口”的原则。 |
|---|
| | | |
|---|
| | | 禁止将大文件、大目录、大量搜索结果、批量日志或批量图片内容直接回显到 Codex 会话窗口。 |
|---|
| | | |
|---|
| | | 具体要求： |
|---|
| | | |
|---|
| | | 1. 不得直接使用 `Get-Content -Raw` 将大文件完整输出到窗口。 |
|---|
| | | 2. `rg`、`Select-String`、日志检索、代码检索等操作必须限制输出行数；如需全量结果，应写入 `tmp/`、readout 文件、证据包、审计附件或正式结果文档。 |
|---|
| | | 3. 不得对大目录执行无上限递归列表并直接回显；目录扫描结果应输出到文件，只在窗口展示摘要、数量、关键路径和异常项。 |
|---|
| | | 4. 图片证据优先记录图片路径、manifest、缩略图或抽样结果；避免批量 `view_image` 把大图片载荷写入会话历史。 |
|---|
| | | 5. 大结果应写入 `tmp/`、evidence package、readout 文件、审计附件或正式结果文档。 |
|---|
| | | 6. 角色窗口和 MB-X 消息只展示摘要、关键行、文件路径、证据入口、结论和期望动作，不复制大段正文。 |
|---|
| | | 7. 处理 `context window full` 或上下文耗尽时，不得未经确认直接创建新 thread；应优先执行备份、摘要、裁剪、审计记录和原 thread 恢复。 |
|---|
| | | |
|---|
| | | ## 18. 汇报规范 |
|---|
| | | |
|---|
| | | 对用户汇报时，默认先说结论。 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 不得把“代码能跑”“测试通过”“summary 好看”直接说成“事项通过”。 |
|---|
| | | |
|---|
| | | ## 18. 禁止事项 |
|---|
| | | ## 19. 禁止事项 |
|---|
| | | |
|---|
| | | 禁止： |
|---|
| | | |
|---|
| | |
|---|
| | | 9. 不记录来源聊天就开始执行复杂事项。 |
|---|
| | | 10. 问题未复验就关闭。 |
|---|
| | | |
|---|
| | | ## 19. 变更规则 |
|---|
| | | ## 20. 变更规则 |
|---|
| | | |
|---|
| | | 修改本文件时必须遵守： |
|---|
| | | |
|---|
| | |
|---|
| | | 4. 不得因为某个项目的临时问题，把全局规范改得过重。 |
|---|
| | | 5. 如果只是执行者个人失误，不应上升成全局硬规则。 |
|---|
| | | |
|---|
| | | ## 20. 当前核心口径摘要 |
|---|
| | | ## 21. 当前核心口径摘要 |
|---|
| | | |
|---|
| | | 1. 体系是插件，用不用由项目管理员决定。 |
|---|
| | | 2. 项目体系和开发体系默认随项目创建；其他体系由项目管理员按需启用。 |
|---|
| | | 3. 启用体系后，项目必须遵守 common 规范和本地规范；开发体系在未创建具体目标开发工作区前，先遵守 common/dev-doc 全局开发规范。 |
|---|
| | | 4. 正式文档必须有职责、引用、记录方式和目录入口；非文档产物必须能通过 manifest、索引或日志追溯。 |
|---|
| | | 5. 权限跟角色走，审核员不直接改被审计产物。 |
|---|
| | | 5. 权限跟角色走，审核员可维护对应本地审核 / 审计规范，但不直接改被审计产物或被审体系执行规范。 |
|---|
| | | 6. 开发体系绑定目标体系，代码放 `dev/<target>-dev/`，目标代码文档和方案附件放 `dev-doc/<target>-doc/`；正式开发账本统一放 `dev-doc/` 根目录。 |
|---|
| | | 7. 所有正式事项必须有目标、过程、结果和审计证据链。 |
|---|
| | | 8. 审核抓真问题，不吹毛求疵，不层层加码。 |
|---|
| | |
|---|
| | | 11. 具体项目内容不得污染全局或 common。 |
|---|
| | | 12. 项目本地规范可以补充规则和设计本地流程；已审核通过的本地流程优先执行，但不能削弱全局规范和 common 体系硬约束。 |
|---|
| | | 13. 全局公共数据入口是 `全局存储体系.md` 和 `全局数据格式.md`；读数据先找数据源，写字段先核 schema。 |
|---|
| | | 14. Codex 角色窗口只展示摘要和证据入口，大输出必须落入文件、证据包或正式文档；上下文耗尽时先备份、摘要、裁剪和审计，不得未经确认直接创建新 thread。 |
|---|
