7b8aa3ff43
- 新增 .agent/rules/子代理交付.md：三要素交付、证据指针、仅阻断级汇报、最小必读，并登记 rules 目录与 AGENTS.md SoT 路由 - 计划与提交：补研发相位判据表（开发期/能力稳定/批次稳定）与证据复用规则；修复指向已路由文件的悬空引用；完成声称对齐父仓 verification-principles 的 L1/L2/L3 分级 - 整体审查按级触发：L3 重任务批次（跨模块/>2 文件/>100 行/核心逻辑/不可逆，任一命中）才起独立只读四维审查，L1/L2 以门禁绿加抽查代替（决策 D1–D4）；AGENTS.md 工作协议第 6 条同步 分支上的旧版 维护索引.py、文档索引测试与总体架构.md 不采纳，以 main 演化版为准。门禁：make 检查、架构 75 passed、git diff --check 通过。
41 lines
5.7 KiB
Markdown
41 lines
5.7 KiB
Markdown
# 计划与提交
|
||
|
||
适用于需要制定 plan 的开发任务。本文件定义任务、分工、交付批次、提交与独立审查；执行与验证节奏见[模块依赖](模块依赖.md)。计划和 Skill 均不授予提交、合并、发布或外部调用权限。
|
||
|
||
## 任务与交付批次
|
||
|
||
- **任务是完整结果**：以可独立验收的能力或结果拆分，包含必要的入口、执行、结果及失败恢复路径；函数、文件或单条旧用例不默认构成一个交付任务。
|
||
- **开工边界**：每项任务写清做什么、不做什么、交付物、修改边界、前置依赖、维护者、完成标准和验证方式。缺项或关键前提未确认时只阻塞受影响任务，继续其他已授权的独立工作。
|
||
- **审查单位提前声明**：交付批次是集中验收与独立审查的单位，默认一个 plan 为一批；大型计划可在执行合同中预先划定多批，并明确跨批集成顺序与最终验收。不得临近收尾拆批来规避原验收标准。
|
||
|
||
## 依赖与分工
|
||
|
||
- **按能力衔接**：依赖的是具体输入和已验证能力，不是整个前置包的完成标签；尚未接通真实上游的部分明确留待集成验收，不以替身通过冒充完成。
|
||
- **独立任务主动并发**：前置满足、输入与修改范围互不影响且有实际收益的任务分工并发实现、验证和交付；共享状态、连续决策和简单任务由主代理处理，不为并发而制造拆分。
|
||
- **隔离与归属**：各线使用包含所需未提交改动的同一可核验基线，并发写入者使用隔离工作区；共享接口、迁移、装配和生成文件指定唯一维护者。不得擅自提交来制造基线，也不得从缺少当前改动的旧 HEAD 开工；无法安全隔离时说明具体限制，先推进不冲突工作。
|
||
- **集成有负责人**：委派给出输入、输出、文件边界和完成判据，主代理按依赖顺序承接差异与证据，验证实际消费者和跨任务链路。重测试按环境与预算容量限流，可变数据库、端口和会话相互隔离。
|
||
|
||
## 研发相位（判据可判定）
|
||
|
||
| 相位 | 进入判据 | 验证义务 |
|
||
|---|---|---|
|
||
| 开发期 | 任务尚未通过自身完成标准 | 只跑受影响快速检查或相关文件测试，及时修复失败 |
|
||
| 能力稳定 | 任务自身完成标准全绿（按 L 级证据口径） | 跑相应回归与真实接缝验证；替身与隔离遵守[测试隔离](测试隔离.md) |
|
||
| 批次稳定 | 批次内全部任务能力稳定 | 集中本批完整门禁与必要真实入口验证，再进入批次审查 |
|
||
|
||
- 发现影响目标或授权的设计缺口时返回对应决策，不以临时替身掩盖，也不扩大无关任务；已有目标、方案和证据仍有效时直接承接。
|
||
- **证据复用**：确认代码、合同、输入、环境、配置和工具版本仍适用后复用证据；出现相关变更、证据失效、新失败或未解决疑点时重验对应范围，影响不清时扩大到能覆盖风险的范围。
|
||
|
||
## 验证、提交与审查
|
||
|
||
- **验证不过不收尾**：任务未通过与自身完成标准相称的验证时，继续实现并重验受影响部分；不以“基本完成”隐去失败或推给无关后续任务。分相位验证判据见上节；完成声称的证据分级（L1/L2/L3）与重任务判据以 [`../../../.agents/rules/verification-principles.md`](../../../.agents/rules/verification-principles.md) 为准。
|
||
- **一任务一提交**：获得明确提交授权后，每个完整任务验证通过即单独提交，只包含该任务产物；不把整个 plan 攒成一次大提交。未获授权时保留可审差异并说明未提交，不执行 `git add` 或 `git commit`，也不反复索取同一授权。提交不代表可合并或发布；合并、发布还须满足相应批次审查与集成验收，并另有明确授权。
|
||
- **整体审查按级触发**：L3 重任务批次（判据见 [`../../../.agents/rules/verification-principles.md`](../../../.agents/rules/verification-principles.md)——跨模块、超过 2 个文件、修改超 100 行、核心逻辑变动、不可逆操作，任一命中）稳定并通过约定门禁后，起独立只读子代理审查本批全部真实改动，覆盖逻辑完整性、一致性、合理性、可行性，以及任务间链路、垃圾代码和被替代实现残留；通过前不得宣布该批完成。审查基线覆盖本批未提交与已提交改动，不能只看 HEAD 而漏掉工作树。L1/L2 批次以门禁绿加抽查代替，不起独立审查、不重复审查。
|
||
- **审查不叠加**：不逐小任务、逐提交重复同一批次审查；已有审查覆盖的维度与有效证据直接承接，不因 Skill 名称不同再审一次。必要的高危方案事前评审不取消。发现问题后修复、验证，并对问题与受影响范围重审；影响扩大时同步扩大审查，不能以“一次”为由免除重审。
|
||
- **整体验收不省略**：多批计划最终核对批次间链路、未覆盖接缝、交付物与恢复条件；已有证据仍适用的部分复用，新增或受影响的集成行为必须验证，不能把各批通过简单相加当作整体验收。
|
||
- **集中收尾**：按批次同步权威记录和索引，清理本次替代内容，框架与创作内容分开审查、分开提交；按已交付能力、具体阻塞和剩余验收项汇报，不以测试或文档数量替代进度。
|
||
|
||
## 判定依据
|
||
|
||
任务边界和批次范围由计划逐项复核；运行命令、退出码、输入与代码版本构成验证证据；审查记录列明真实差异范围、四维结论和未覆盖项。链接、索引和格式使用现有机械检查；内容是否完整由独立语义审查判断，不以字符串存在性检查冒充流程正确。
|