# Change Governance Intensity 本文件定义项目无关的变更治理强度模型。 它回答： - 一个变更为什么适合轻量、标准或强化治理路径 - 哪些风险维度会提高治理强度 - 哪些最低证据不能因为路径轻量而省略 - 哪些变化必须触发升级或重新分流 本模型定义的是单个变更的治理强度，不是仓库治理成熟度。仓库可以具备不同成熟度，并把本模型映射到自己的执行入口、审查方式和自动化检查；映射层不得反向改写本文件的通用语义。 Loom 仓库自身的执行路径映射见 [loom-governance-intensity-mapping.md](./loom-governance-intensity-mapping.md)。 ## 1. 文档定位 `change-governance-intensity.md` 是变更治理强度的唯一通用落点。 它承接： - 风险维度 - 强度档位 - 升级触发条件 - 轻量路径最低证据 - 项目映射边界 事项入口与分流原则见 [principles.md](./principles.md)。 审查职责分层见 [review-model.md](./review-model.md)。 仓库治理能力档位见 [governance-maturity-model.md](./governance-maturity-model.md)。 本文件不定义任何特定项目的文件布局、命令、工作现场、门禁实现、review engine 或宿主平台操作。 ## 2. 风险维度 变更治理强度由以下维度共同决定。单个维度触发高风险时，不应被其他低风险维度平均掉。 | 维度 | 判断问题 | 升级信号 | | --- | --- | --- | | 范围与边界 | 本次变更是否只影响局部实现或局部文档 | 影响共享契约、公共 API、跨模块职责、项目运行模型或多个事项边界 | | 行为可见性 | 用户、客户、运维或外部系统是否会观察到变化 | 改变可见行为、错误语义、权限边界、数据输出、通知、支付、发布或外部动作 | | 数据与安全 | 是否触碰数据完整性、隐私、认证、授权、安全策略或 secret 处理 | 可能造成数据丢失、越权、泄露、审计缺口或不可逆写入 | | 宿主与发布 | 是否影响部署、发布、CI、宿主平台、集成或运行环境 | 需要发布判断、版本判断、宿主权限、生产 profile、环境迁移或外部服务协调 | | 可逆性 | 变更失败后是否容易回滚或隔离 | 回滚困难、状态迁移不可逆、会污染共享状态或需要人工修复 | | 验证确定性 | 是否能用当前证据直接验证完成 | 验证依赖人工观察、长链路集成、异步外部状态、稀有场景或缺少可靠复现 | | 依赖与并发 | 是否会阻塞其他工作或被其他事项消费 | 定义下游合同、改变依赖图、影响多个并行事项或需要跨团队协调 | | 事实载体 | 目标、范围、证据和结论是否有稳定载体 | 关键判断只存在会话、临时日志或不可复核环境中 | ## 3. 强度档位 ### 3.1 `light` `light` 适用于局部、可逆、低外部可见性的变更。 典型条件： - 目标和范围清楚 - 不改变共享契约、公共边界、运行模型或发布语义 - 不触碰安全、权限、隐私、数据迁移或外部可见动作 - 验证方式明确，且失败影响容易定位和回滚 - 不作为其他事项的上游合同 `light` 不是免审路径。它只表示说明、设计和验证可以更短。 最低证据： - 目标与范围 - 路径判定依据 - 变更摘要 - 当前验证结论 - review 结论或等价审查记录 - release / no-release 判断 - 若某类证据不适用，必须说明原因、消费者边界和重新检查条件 ### 3.2 `standard` `standard` 适用于有明确边界影响、需要跨文件或跨角色协调，但仍可通过局部设计和常规审查控制的变更。 典型条件： - 改变内部合同、模块职责或多个文件的协作方式 - 需要简化设计说明才能让 reviewer 判断范围和验证方式 - 可能影响下游事项，但影响面可列清 - 验证需要组合静态检查、测试、人工检查或宿主读回 - 失败可恢复，但恢复路径需要提前说明 最低证据在 `light` 基础上新增： - 简化设计说明或决策记录 - 受影响边界列表 - 验证矩阵或等价检查清单 - 已知风险与回滚方式 - 下游消费者或依赖关系说明 ### 3.3 `reinforced` `reinforced` 适用于高风险、跨边界、外部可见、不可逆或会成为共享合同的变更。 典型条件： - 改变公共契约、用户可见行为、数据模型、权限、安全、发布、部署或运行模型 - 需要多个审查阶段或专门风险审查 - 需要正式规格、迁移计划、回滚计划或外部协调 - 验证依赖长链路、真实环境、宿主控制面或发布后证据 - 结论会被多个后续事项消费 最低证据在 `standard` 基础上新增： - 正式规格或等价合同 - 风险分解与升级依据 - 行为证据和测试证据，或明确的不适用说明 - 外部可见动作边界和禁止动作 - 发布、迁移或 no-release 结论及其依据 - 当前结论可被下游消费的条件 ## 4. 升级触发条件 执行过程中出现以下任一情况，必须升级或回到分流判断： - 实际范围超过原路径声明 - 发现新的共享契约、公共边界或运行模型变化 - 触碰数据、安全、权限、隐私、发布、部署或外部可见动作 - 验证证据不足、过期、无法复现或与当前变更不绑定 - reviewer 需要补做作者应在准入阶段完成的方向、范围或风险判断 - 轻量路径的不适用说明缺少原因、消费者边界或重新检查条件 - 下游事项开始依赖当前未冻结语义 - 宿主状态、目标环境、账号、权限或当前版本 / 变更对象绑定与预期不一致 - 失败影响从局部可回滚变为共享状态、外部状态或不可逆结果 升级不是失败。升级表示当前证据已经不能支撑原强度判断。 ## 5. 降级禁止条件 以下情况不得降级为 `light`： - 只因为代码量小、文件少或改动看起来简单 - 只因为已经有自动检查 - 只因为 reviewer 可以在最后补判断 - 只因为发布或宿主动作尚未执行 - 把缺失证据标成不适用，但没有原因、消费者边界和重新检查条件 - 把 deferred follow-up 当成本次已完成证据 - 把外部系统、生产账号、真实用户或真实数据风险当成局部实现细节 - 把当前项目的便利路径当成通用治理规则 ## 6. 项目映射边界 不同项目可以把本模型映射到自己的执行路径。 映射可以定义： - 每个强度档位对应哪些入口、工件、检查和审查角色 - 哪些风险维度在该项目中默认升档 - 哪些证据载体是项目权威来源 - 哪些自动检查可以作为结构性证据 - 哪些外部动作需要人工确认或专门权限 映射不得： - 省略 review、权威事实来源与证据链、release / no-release 判断或外部可见风险判断 - 用项目专属命令、目录、门禁或工具名改写本模型 - 把轻量路径变成无载体、无审查、无证据路径 - 把自动化通过解释成语义审查已经完成 - 把某个项目的历史事故或目录习惯提升为通用规则 ## 7. 一句话结论 变更治理强度的目标不是让每个变更都变重，而是让每个变更在开始前有可解释、可审查、可升级的治理路径。