---
name: incremental-impl
description: 将已确认的非平凡需求改动拆成完整、可验证、可集成的实施单元，并按依赖顺序增量落地。当任务涉及多文件、跨文件重构、跨切面修改、多个可分离结果或执行已确认计划时使用；纯文档、纯配置或单一明确的小修改不触发。
---

# 增量实现

本技能的核心产物是**需求改动的实施拆分**：把已确认方案变成一组边界完整、完成标准明确的实施单元。单写者、代理派发和工作树只是拆分完成后的执行选择，不能反过来决定单元边界。

## 1. 确认改动边界

- 读取用户最新决定、验收契约、已确认的 `arch_design.md` 和当前计划；这些是实现约束，存在冲突时停止并交回上游澄清。
- 提取本次必须实现的需求结果、必须保持的不变量、明确非目标和已有依赖。
- 有现成计划时复核其中的任务是否满足下文的完整单元定义；不完整就调整边界，不为沿用旧计划保留错误拆分。
- 不在实现阶段重新决定产品范围、模块边界或迁移形态。

## 2. 定义完整实施单元

**完整实施单元**是在依赖已满足的前提下，可以独立交付一个连贯需求结果或一个合法迁移状态的最小改动集合。它包含证明结果成立所需的实现、行为保护和必要配套变更；完成后仓库处于可验证、可继续集成且必要时可回退的状态。

一个单元必须同时满足：

1. **结果完整**：对应一条验收标准或一组不可分割的验收标准。结果所需的各层代码、测试、配置、数据变化和必要文档同步都包含在内，不留下只能依靠未来单元才能成立的半成品。
2. **边界内聚**：单元内的改动因同一个需求结果或技术不变量而同时变化。共享同一行为、事务边界、公共契约或必须原子生效的改动不能为了缩小任务而拆开。
3. **可独立验证**：有明确证据能判断整个结果是否完成，包括自动化测试、构建检查、运行信号或必要的人工验证；一条验收标准可以对应多个验证用例。
4. **依赖明确**：只依赖已经存在或排在前面的稳定结果，不依赖其他未完成单元中的临时签名、隐藏状态或口头约定。
5. **中间状态合法**：完成后项目应可构建、可测试并保持现有行为；迁移任务可以停在设计已允许的兼容状态，但必须写清保护方式、退出条件和后续清理归属。

“修改某个文件”“增加一个数据类型”“补测试”或“交给某个代理”本身通常不是完整单元；只有它能独立完成一个需求结果或合法迁移状态时才算。文件数、代码行数、提交数量和写入者都不是单元边界。

## 3. 拆分需求改动

1. 将验收标准、技术质量目标和行为保护要求映射到具体结果。
2. 把必须同时成立的实现、测试和配套变化合并为一个单元。
3. 只有当两个结果能够分别验证、分别集成且其中一个完成后不依赖另一个的半成品时，才拆成不同单元。
4. 按依赖关系排序；依赖允许时优先验证风险最高或最不确定的单元。不要为制造并行机会改变边界。

输出一张足以指导实施的拆分表：

| Unit | Requirement / Result | Includes | Depends on | Completion Evidence |
|---|---|---|---|---|
| `<name>` | `<完成后成立的需求结果>` | `<代码、测试与配套变化>` | `<已完成结果或无>` | `<如何证明整个单元完成>` |

拆分后逐项自检：

- **完整性**：只完成这个单元，表中的需求结果是否真的成立？若仍需要未来单元补齐，合并或重新定义结果。
- **内聚性**：单元内是否混入了能独立验收、因不同原因变化的结果？若是，拆开。
- **可集成性**：依赖满足后，能否独立验证并让仓库停在合法状态？若不能，调整顺序或边界。

常见组织方式不是硬规则：功能与缺陷通常按端到端行为拆分；跨切面修改按能独立验证和回退的作用域分组；架构迁移按已确认设计中的合法中间状态拆分。

## 4. 增量执行与集成

- 默认单写者按依赖顺序实施。只有拆分完成后，确认候选单元的文件所有权互不重叠、输入输出边界稳定，且彼此不存在未满足依赖，才考虑并行写入。有前后依赖的单元必须等待前置结果完成并集成，不能用“集成顺序明确”代替依赖独立。
- 多写者时记录每个单元的写入者、模型或推理强度、工作树、文件所有权和验证命令。模型与推理强度默认继承，确有需要时使用运行时支持的参数覆盖，不写死型号。
- 并行写者使用运行时原生工作树，或由主代理预先创建并传入路径；只有目录完全不重叠时才可共享工作树。无法建立等价隔离时改为串行。
- 可以使用运行时提供的代理间通信，但正确性不能依赖临时消息。权威接口、决定和进度必须能从仓库或持久计划验证。
- 写入代理收到单元结果、权威资料、工作目录、文件所有权、禁止范围、依赖、验证方式和期望证据。发现契约冲突或无法守住边界时停止并报告。
- 每个单元结束时核对完整性定义和验证证据，再按依赖顺序集成。委派写入只返回变更结果、验证证据和未解决问题；内联实现不生成额外的固定交接模板。
- 按 `git-workflow` 在有意义的语义边界提交，不强制每个实施单元对应一个提交。新行为、缺陷修复和重构的测试纪律交给 `test-driven-development`；异常转入 `systematic-debugging`。
- 只有全部单元集成且整体验收完成后才能声明任务完成；未完成项和范围外发现如实交回用户。