| | |
|---|
| | | |
|---|
| | | 临时事项一旦被后续引用、进入交付、影响结论或被纳入正式结果，必须补齐为正式事项证据链。 |
|---|
| | | |
|---|
| | | ## 9.5 实用优先与最小充分治理 |
|---|
| | | |
|---|
| | | MB-X 默认遵循“实用、快速落地、小步快跑、避免过度设计”。治理的作用是保护目标、边界和关键证据，不是证明每一个动作都再次获得许可。 |
|---|
| | | |
|---|
| | | 1. 先做满足当前目标的最小可用闭环；没有真实需求、失败证据或容量压力，不提前设计复杂扩展机制。 |
|---|
| | | 2. 项目内普通、可逆、可验证的文档、代码、测试、下载、文件整理、工具操作和角色日常工作，在已登记事项与角色范围内直接执行并普通验收，不做逐动作、逐文件、逐命令、逐尝试审批。 |
|---|
| | | 3. 默认使用语义验收。字节级冻结仅用于外部原始证据、正式证据包或 manifest、签名/JCS 协议、合规材料、数据库回执以及明确要求不可变的接口契约。 |
|---|
| | | 4. 独立审核只放在会实质影响目标、结论、权限边界、安全、不可逆外部状态或正式发布的阶段门。风险提高审核强度，不改变“职责就近、项目内决定由项目角色作出”的归属。 |
|---|
| | | 5. 同一轮审核应一次返回完整的实质问题集合；修复方做一次合并修订，再做一次必要复核。不得为证明“上一次审核存在”而增加元审核，也不得把一个问题拆成连续多轮授权链。 |
|---|
| | | 6. 可修复的普通错误允许在同一事项内修正并重跑；只有越界、不可逆副作用、凭据暴露、访问控制、数据破坏或状态不确定时才停止并升级。 |
|---|
| | | 7. 旧流程与旧失败历史保持可追溯，但新事项按本原则执行；不得因历史上曾使用逐次授权而自动沿用。 |
|---|
| | | |
|---|
| | | ## 10. 审核规范 |
|---|
| | | |
|---|
| | | 审核的目标是发现真问题，不是制造流程负担。 |
|---|
| | |
|---|
| | | 4. 非核心可读性建议。 |
|---|
| | | 5. 不影响主流程的诊断项缺失。 |
|---|
| | | |
|---|
| | | 审核员还必须遵守最小充分原则：普通事项由请求者或安排者验收即可；需要独立审核时，以完整事项或实质阶段门为单位，一次给全问题，不逐文件、逐步骤、逐尝试重复审核。 |
|---|
| | | |
|---|
| | | 审核复杂事项时，可以拆分审计步骤，也可以使用 subagent，但必须由主审核员整合判断，不得直接转发未经复核的碎片结论。 |
|---|
| | | |
|---|
| | | ## 11. 真 Bug 和问题归因规范 |
|---|
