三、核心工程循环模型（The Three Engineering Loops）
本章承接第二章的开工准备，分别说明切片实现、合并准入和版本交付。图中的 TDD、领域签字、系统测试与部署均按任务适用范围执行；无须部署的任务在验收与交接后结束工程交付。
3.1 【内循环】切片实现与本地验证（Local Micro-Loop）
本指南在 TDD 的“红—绿—重构”基础上增加核心判据的变异测试，用于验证测试确实能够发现目标缺陷：
- 先红（Red）：编写针对目标行为的测试，实际运行并捕获预期的失败。目标接口尚未声明导致的编译失败可作为初始红的一部分；依赖缺失、环境未启动或无关语法错误不能作为有效红灯。
- 转绿（Green）：编写满足目标契约的最小实现，确认目标测试通过。
- 变异测试（Mutation Testing）：在隔离环境临时移除核心校验、破坏目标不变量或修改关键业务规则，再运行对应测试。测试应由通过转为失败，以证明该断言能发现这类缺陷；这不等于证明测试已覆盖所有错误。
- 恢复与重构（Restore & Refactor）：准确恢复变异前的实现，确认测试重新转绿；在测试持续通过的前提下重构，再运行受影响检查。
提示
- 先红豁免：纯文档或注释修改、生成产物刷新，以及既有测试无需改变期望且持续通过的局部机械重构，可豁免先红。仍须执行适用检查并记录依据；行为变化不能以“重构”为名豁免。
- 变异测试范围：依据风险与测试计划选择核心业务判据；不得为无可执行行为的改动编造测试结果。
- 重复失败处置：同一失败在无新证据、无新假设时连续出现 3 次，暂停该路径的盲目重试，转入根因诊断；不受影响的工作可继续。
3.1.1 受测输入冻结与证据绑定
- 明确输入：登记本次验证实际使用的源码、配置、夹具、契约、依赖与环境。Git Commit SHA 或代码树 Hash 只标识其中一部分；参与验证的未跟踪文件、生成文件和外部输入须单独纳入清单或明确排除，敏感值仅记录安全引用。
- 冻结与运行：格式化和自动修复在冻结前完成；验证时使用工具支持的只检查模式，禁止隐式改写受测输入。构建与日志输出放在约定目录，不因正常生成输出误判输入漂移；生成物若参与后续验证，应登记其摘要。
- 关联版本：运行前后核对输入摘要，记录真实结果；提交后将证据关联到对应的完整 Commit SHA。后续改动不会抹去历史证据，但旧证据不能直接证明新版本通过，应按影响重新验证。
- 受控重绑定：仅在团队已定义并实现证据复用机制，且工具校验受测输入、比较基线、环境、检查集合及有效期均满足政策时，才可把已有证据关联到新提交。不能仅凭“只是 Rebase”或“只改文档”放行；条件不满足或无可用校验机制时，重新运行适用检查。重绑定不等于重新测试。摘要覆盖完整内容树，或由项目正式登记且有遗漏校验的输入闭包；同时核对工具版本、门禁清单版本与环境。无法归类的变更、闭包不完整或基线失效时按项目规则回退完整验证，不能用人工猜测复用旧绿。
3.1.2 分层门禁与执行节拍
下表是本文的分层示例，名称、触发点和范围须映射到团队真实入口。T0—T3 表达执行节拍，不代表测试技术，也不要求每个任务依次运行所有层级。
| 节拍层级 | 建议触发时机 | 验证职责与边界 |
|---|---|---|
| T0（编辑内环） | 编辑期间 | 当前模块的类型检查、Lint 与快速测试，提供及时反馈 |
| T1（提交门禁） | 提交前，按团队规则执行 | 受影响闭包及规定的轻量检查；影响范围未知时回退全量 |
| T2（完整回归） | 任务验收、合并前或团队规定的全量节拍 | 项目定义的全量回归与条件门；明确是否包含外部依赖 |
| T3（系统验证） | 相关高风险变更、定时构建或发布前 | 真实依赖集成、迁移、端到端、故障及恢复验证；范围由本次影响决定 |
每个入口均按 §6.2 登记执行者、阻断位置、证据与盲区。若门禁受阻，先诊断并记录责任人与下一步；不得把受阻、未运行或历史失败改记为通过。
3.2 【中循环】合并准入（PR Admission Loop）
- PR 或等价变更单关联需求、适用规格、两轴审查和验证记录；涉及重要决定时补充 D-ID / ADR。上述信息可位于同一张任务卡中，不要求小任务创建多份文件。
- 核对本次适用的 Required Checks，分别记录未运行、取消、跳过、受阻、失败与通过。不适用项注明依据，不计作通过；历史失败是否允许例外，按既定规则由有权负责人处理。
- 审查发现按第四章完成处置与复核。候选内容或合并基线变化后，重新判断验证和审查范围；必须绑定实际合入的内容。
- 合并权限由分支保护等机制执行；未配置自动阻断时，明确人工责任人，不能宣称已由 CI 强制。
3.3 【外循环】发布、运行与效果反馈（Release & Evolution Loop）
- 切片合入后先判断版本必备范围是否齐备；未齐备时继续实施或调整计划，不能把每次合入都当成一次完整发布。
- 需要部署的版本按第七章完成“候选构建与登记 → 隔离验收 → 准入固化 → 目标环境发布 → 核验与回执”。运行问题按预案处置，结果未知时先查证。
- 完成运行交接后，按 §0.7 观察用户结果和业务目标，按第九章分析交付瓶颈。正常交付做效果评估与改进；发生事故或已确认缺陷时再开展相应的根因分析。
- 缺陷改进优先落入类型或编译约束、确定性回归测试、可靠工具，再补充必要规则；同步清理失效规则。未完成项带责任人与复查条件回到需求池。
3.4 测试资产矩阵与验收映射
text
验收条目 → 断言/用例 → 真实或替身依赖 → 执行入口 → 触发节拍 → 责任人 → 阻断位置 → 结果证据 → 已知盲区同一验收条目可由多类测试共同证明；同一端到端用例也可覆盖多个条目。用户验收按已接受的目标与环境核对最终结果，不因端到端用例通过而自动完成业务验收。预期值须独立于被测实现推导，替身通过不能代替真实依赖验证。
| 测试类别 | 核心验证目的 | 必须声明的边界与已知盲区 |
|---|---|---|
| 静态 / 架构检查 | 类型安全、分层依赖方向、禁用 API、代码规范 | 无法验证动态运行时语义与业务逻辑正确性 |
| 单元测试 | 纯函数、算法实现、值对象、领域不变量 | 无法验证跨模块集成协作与真实持久化副作用 |
| 组件测试 | 组件生命周期、状态机迁移、内部模块交互 | 明确哪些依赖真实、哪些外部依赖被 Mock 替换 |
| 性质 / 模糊测试 | 在广义输入域内校验数学性质与不变量，搜寻极端反例 | 声明随机输入域范围、种子（Seed）及可复现用例 |
| 业务数值向量测试 | 精确校验金额公式、舍入规则、量纲换算及边界临界点 | 预期值必须独立推导，严禁在测试体内复制生产代码实现 |
| 编译契约 / 诊断测试 | 类型推导约束、正反编译断言（如 Rust trybuild）、文档用例 | 区分编译期类型拦截与运行时逻辑断言 |
| API / 跨语言契约 | 服务边界字段类型、错误编码、向下兼容性 | 区分通信 Schema 兼容性与业务授权语义兼容性 |
| 真依赖集成测试 | 事务隔离级别、真实 SQL 行为、缓存失效、分布式锁 | 声明真实服务版本、运行身份、初始 Fixture、迁移基线 |
| 端到端业务测试 | 从入口请求至最终业务终态的全链路流转 | 明确起止边界，声明中间环节的替身依赖与未覆盖路径 |
| 冒烟测试 | 验证构建发布产物是否具备基本可运行性 | 属于关键路径探针，严禁等同于全量回归或生产验收 |
| 确定性故障恢复测试 | 在受控时序下模拟重试风暴、租约过期、宕机接管 | 区分软件模拟故障与真实物理网络/硬件故障的差距 |
| 浏览器 / App 行为 | 客户端真实渲染、路由导航、交互反馈、权限提示 | 模拟器环境不等于真机硬件；连接真实浏览器不代表后端真实 |
| 视觉 / 无障碍测试 | 界面布局、多端适配、焦点流动、键盘导航、读屏语义 | 视觉截图完全正确无法证明业务状态、金额及授权正确 |
| 性能 / 压力 / 容量 | 吞吐上限、P99 延迟、内存泄漏、背压机制 | 声明负载模型、硬件规格、数据基数与噪音过滤方式 |
| 覆盖率 / 变异评估 | 评估测试集的行/分支覆盖深度与对逻辑缺陷的击杀率 | 代码被执行不代表被有效断言；严禁追求无意义的覆盖率数字 |
| Agent 治理 / 对抗验证 | 越权拒绝、注入隔离、审批绑定、预算拦截、停止与委派边界 | 确定性策略拦截与模型对抗评测分别记录；观察真实系统副作用 |
| 安全与权限验证 | 越权、租户隔离、敏感数据边界及威胁模型中的场景 | 工具扫描不能穷尽业务逻辑缺陷；按风险安排人工审查 |
| 迁移与发布制品验收 | 迁移顺序、不可变产物启动、配置与恢复前提 | 使用真实候选制品；禁止依赖源码挂载补齐缺失文件 |