8.0 KiB
8.0 KiB
计划与提交
适用于需要制定 plan 的开发任务。本文件定义任务、分工、交付批次、提交与独立审查;执行与验证节奏见模块依赖。计划和 Skill 均不授予提交、合并、发布或外部调用权限。
任务与交付批次
- 任务是完整结果:以可独立验收的能力或结果拆分,包含必要的入口、执行、结果及失败恢复路径;函数、文件或单条旧用例不默认构成一个交付任务。
- 开工边界:每项任务写清做什么、不做什么、交付物、修改边界、前置依赖、维护者、完成标准和验证方式。缺项或关键前提未确认时只阻塞受影响任务,继续其他已授权的独立工作。
- 审查单位提前声明:交付批次是集中验收与独立审查的单位,默认一个 plan 为一批;大型计划可在执行合同中预先划定多批,并明确跨批集成顺序与最终验收。不得临近收尾拆批来规避原验收标准。
依赖与分工
- 按能力衔接:依赖的是具体输入和已验证能力,不是整个前置包的完成标签;尚未接通真实上游的部分明确留待集成验收,不以替身通过冒充完成。
- 独立任务主动并发:前置满足、输入与修改范围互不影响且有实际收益的任务分工并发实现、验证和交付;共享状态、连续决策和简单任务由主代理处理,不为并发而制造拆分。
- 隔离与归属:各线使用包含所需未提交改动的同一可核验基线,并发写入者使用隔离工作区;共享接口、迁移、装配和生成文件指定唯一维护者。不得擅自提交来制造基线,也不得从缺少当前改动的旧 HEAD 开工;无法安全隔离时说明具体限制,先推进不冲突工作。
- 集成有负责人:委派给出输入、输出、文件边界和完成判据,主代理按依赖顺序承接差异与证据,验证实际消费者和跨任务链路。重测试按环境与预算容量限流,可变数据库、端口和会话相互隔离。
研发相位(判据可判定)
| 相位 | 进入判据 | 验证义务 |
|---|---|---|
| 开发期 | 任务尚未通过自身完成标准 | 只跑受影响快速检查或相关文件测试,及时修复失败 |
| 能力稳定 | 任务自身完成标准全绿(按 L 级证据口径) | 跑相应回归与真实接缝验证;替身与隔离遵守测试隔离 |
| 批次稳定 | 批次内全部任务能力稳定 | 集中本批完整门禁与必要真实入口验证,再进入批次审查 |
- 发现影响目标或授权的设计缺口时返回对应决策,不以临时替身掩盖,也不扩大无关任务;已有目标、方案和证据仍有效时直接承接。
- 证据复用:确认代码、合同、输入、环境、配置和工具版本仍适用后复用证据;出现相关变更、证据失效、新失败或未解决疑点时重验对应范围,影响不清时扩大到能覆盖风险的范围。
- 验证期冻结源码:验证会话自持写闸门(
工具/验证锁.py;pytest会话开始持共享锁,结束比对源码哈希,不一致把退出码置 3 表示本轮作废)。持锁期间不改src/、不跑make 生成与make 格式写入;写入口用--执行在独占锁内落盘,检查与写入之间不留窗口。格式化同样算改源码:改过src/而没有重新生成的轮次一律作废,不采信其结论,也不把作废轮次的失败当成产品缺陷。 - 全量必须用户明确授权:日常循环只跑受影响模块(
make 快检 范围=<受影响路径>);严禁未经用户明确请求擅自执行make 验收数据库或全量make 数据库测试(高成本违规操作)。模块纯逻辑/校验/提示词改动,以对应模块的快检与离线测试为完成证据;只有改动了src/muse/*/存储.py、数据库/迁移/或触发器/不可变约束时,才需要在共享测试库上验证对应模块的数据库用例。跨模块全量验证仅在用户明确指令时执行。发现期需要多模块时使用局部路径的make 数据库分片 范围=<路径>。改过src/就必须在写独占锁内重新生成并重验覆盖范围。
验证级别
| 级别 | 适用范围 | 完成证据 |
|---|---|---|
| L1 | 文档、注释、索引类改动,且未命中 L3 判据 | 对应机械检查通过,含本批链接、索引或声明核对 |
| L2 | 未命中 L3 判据的局部实现 | 相关单元或契约测试通过,以及 git diff --check |
| L3 | 跨模块、超过 2 个文件、修改超过 100 行、核心逻辑变动、不可逆操作,任一命中 | 本批约定模块门禁(非全量)、与变更直接相关的真实接缝验证,以及独立整体审查;全量数据库验收由用户按需授权,不作为自动前提 |
不可逆操作包括数据写入、删除和生产凭据变更。不可逆操作或核心逻辑变动须先评审方案,再对稳定批次审查;其余任务不叠加同一范围的评审。缺对应证据时标记 needs_verification,不以手工台账计数代替。纯声明批次按声明、索引和差异验证,不因级别运行无关数据库、模型或恢复演练;外部验证仍需相应授权。
验证、提交与审查
- 验证不过不收尾:任务未通过与自身完成标准相称的验证时,继续实现并重验受影响部分;不以“基本完成”隐去失败或推给无关后续任务。分相位验证判据见上节;完成声称的证据分级与重任务判据见本文件验证级别。
- 一任务一提交:获得明确提交授权后,每个完整任务验证通过即单独提交,只包含该任务产物;不把整个 plan 攒成一次大提交。未获授权时保留可审差异并说明未提交,不执行
git add或git commit,也不反复索取同一授权。提交不代表可合并或发布;合并、发布还须满足相应批次审查与集成验收,并另有明确授权。 - 整体审查按级触发:L3 重任务批次(按本文件验证级别判定)稳定并通过约定门禁后,起独立只读子代理审查本批全部真实改动,覆盖逻辑完整性、一致性、合理性、可行性,以及任务间链路、垃圾代码和被替代实现残留;通过前不得宣布该批完成。审查基线覆盖本批未提交与已提交改动,不能只看 HEAD 而漏掉工作树。L1/L2 批次以门禁绿加抽查代替,不起独立审查、不重复审查。
- 审查不叠加:不逐小任务、逐提交重复同一批次审查;已有审查覆盖的维度与有效证据直接承接,不因 Skill 名称不同再审一次。必要的高危方案事前评审不取消。发现问题后修复、验证,并对问题与受影响范围重审;影响扩大时同步扩大审查,不能以“一次”为由免除重审。
- 整体验收不省略:多批计划最终核对批次间链路、未覆盖接缝、交付物与恢复条件;已有证据仍适用的部分复用,新增或受影响的集成行为必须验证,不能把各批通过简单相加当作整体验收。
- 集中收尾:按批次同步权威记录和索引,清理本次替代内容,框架与创作内容分开审查、分开提交;按已交付能力、具体阻塞和剩余验收项汇报,不以测试或文档数量替代进度。
判定依据
任务边界和批次范围由计划逐项复核;运行命令、退出码、输入与代码版本构成验证证据;审查记录列明真实差异范围、四维结论和未覆盖项。链接、索引和格式使用现有机械检查;内容是否完整由独立语义审查判断,不以字符串存在性检查冒充流程正确。