61 lines
7.5 KiB
Markdown
61 lines
7.5 KiB
Markdown
---
|
|
name: execute-plan
|
|
description: 仅用户指定 execute-plan 时启用；实施已批准计划，验证、review 并完成本地 Git 提交。
|
|
---
|
|
|
|
# 执行已确认计划
|
|
|
|
完成条件：批准目标已实现，必要验证及 review 通过，本次变更已完成本地 Git 提交，并给出真实 commit hash。首次实现或测试通过不是终点，不以“可提交”或询问是否提交代替执行。
|
|
|
|
在批准范围内自主完成实现、检查、修复和提交，不在各步骤间重复索要许可。保留下述范围变更与重大偏差的确认边界；具体实现和工具安排自行决定，不强制子代理、worktree 或 TDD。按新会话约定执行，不依赖旧讨论。
|
|
|
|
## 读取与核对
|
|
|
|
1. 完整读取用户指定计划；路径不明则询问。从计划定位或 `.agent/MEMORY.md` 确定根目录并读 `CONTEXT.md`，再按任务核实代码、测试与项目约束；架构、数据、部署资料仅在涉及对应改动时读取，不扫描历史计划，避免无关的全仓库扫描。定位冲突或系统不符先澄清，不猜根目录；无 CONTEXT 时依靠计划与代码。
|
|
2. 核对计划批准依据、目标、范围与验收。基线变化先调查影响，无关更新不阻塞；关键缺口、未批准或实质冲突先澄清。已批准的规则迁移按计划执行，不因仍有旧规则重复确认。
|
|
3. 记录仓库身份、分支、HEAD（或无提交）及暂存/未暂存/未跟踪状态，足以区分用户已有修改。保护用户内容；重叠且不能隔离时先解决，不回退或混合提交。
|
|
|
|
宿主禁止实施时遵从限制；新会话是使用约定，不能假称清空了上下文。
|
|
|
|
## 资产与上下文
|
|
|
|
执行记录放在计划旁的独立 `execution-日期时间.md`。沿用用户指定位置，根目录下最多一层计划目录，不插入项目层。目录不可用时报告，不回退代码库。
|
|
|
|
生成资产使用以下 YAML；未知字段留空，特殊值加引号：
|
|
|
|
```yaml
|
|
---
|
|
系统: 系统名称
|
|
时间: YYYY-MM-DD
|
|
目标: 资产对应目标
|
|
---
|
|
```
|
|
|
|
执行记录沿用计划决策日期，执行时间另记正文；计划重新批准后用用户当地确认日期。进度与排版不改日期；旧元数据缺失不等于缺少批准，不编造日期。
|
|
|
|
Markdown 正文中代码、命令和多行配置用带语言标记的围栏代码块，标识符与路径用行内代码，原文引用用 `>` 并注明来源。顶部 YAML 不包代码块，不为排版添加冗余内容。
|
|
|
|
- CONTEXT 只记录已确认且当前有效的业务约束、技术约束，可注明适用模块及必要原因；不放待实施方案、废弃决策、历史计划路径、任务、代码或日志。目标为“保存系统当前业务与技术约束”，时间为最近确认决策日期。局部编码选择不提升为系统约束。
|
|
- 对照 CONTEXT 与计划：无关更新继续，其他实质冲突先澄清。实施、验证及 review 完成后，重读 CONTEXT，用本次落实的约束替换失效规则，保留无关的有效约束；失败或部分完成不提前更新，不记录状态变迁或旧规则。
|
|
- 执行记录仅保留任务状态、配套文件及理由、关键验证命令/结果、兼容性与上线要求、阻塞与偏差，不粘贴完整工具日志。恢复会话或压缩后重读 CONTEXT、计划和执行状态；无变化时复用已读内容。
|
|
|
|
## 实施边界
|
|
|
|
- 每项改动对应批准任务或验收；优先复用现有能力，自主决定具体代码及内部组织，不要求计划提供详细代码或逐字照抄算法示例。
|
|
- 在最小改动范围内遵循单一职责、开闭原则，按需应用设计模式；避免功能模块耦合及通用架构能力依赖业务规则，降低扩展与审查复杂度，不为模式引入无必要抽象。
|
|
- 不为缩小 diff 堆叠旧逻辑。发现本次目标相关且计划未覆盖的复用提取或模块解耦机会时，说明代码依据、收益、成本和影响范围，向用户确认；确认纳入后按范围变更流程更新 plan.md 再实施，不擅自重构或重复确认已批准方案。
|
|
- 核实引用和兼容用途后，移除本次范围内已无用途的死代码、被替代的遗留实现及失效分支，保持代码简洁；不能仅因代码陈旧就删除，范围外清理仍先确认。
|
|
- 若发现实现与已确认决策有重大出入（如核心假设不成立、业务语义或架构边界必须改变），立即停止执行，保留现场并记录证据、已完成内容和待对齐问题；建议用户回到 align-plan 重新对齐范围与边界。新计划重新确认前不继续实现，不用就地改计划掩盖偏离或宣称完成。
|
|
- 可补必要测试/配置文件并说明对应验收；其他文件扩展、业务/接口/架构变化或依赖升级须先确认，不能包装为配套改动。无关发现只记录，不顺手修复或重构。
|
|
- 一般范围调整直接更新同一 plan.md，仅保留最新方案；清除旧批准依据并标待确认，对话只给摘要、原因及链接。用户重新批准后继续；重大出入按上述停止流程返回 align-plan，不生成版本副本或历史方案。完成前重读文件，若内容已变而未重新批准，先澄清。
|
|
|
|
## 验证、Review 与提交
|
|
|
|
1. 完成后重新完整读取原目标与批准计划，对照任务 diff：验收是否满足、保留行为是否成立、是否越界、是否影响调用方与错误路径。
|
|
2. 先从原始目标和验收推导正常、边界、异常及保留行为测试，断言依据需求而非复制实现逻辑；核对用例能否发现目标偏离，不只验证修改的代码是否按自身逻辑运行。复用已有测试、补真实缺口，不堆重复用例或追求覆盖率数字。运行计划要求及必要回归检查，文档变更用适当结构检查；记录实际证据，无变化且无新疑点时不重复运行。
|
|
3. 自行完成范围、正确性、模块边界及失效代码清理的 review；范围内问题直接修复，再跑受影响检查，不把首次 review 当作等待用户的关卡。越界内容仅撤销能可靠隔离的自身改动。无法在范围内解决的失败或环境阻碍报告为未完成，不绕过检查提交；用户调整验证要求时记录差异。
|
|
根据实际 diff 与证据复核接口、数据、配置及新旧版本兼容性。需要特殊上线操作时列出前置条件、步骤顺序、验证点及必要回退限制；否则明确“无需特殊上线步骤或顺序”。未知或未验证部分如实标注，不把本地测试通过等同于上线兼容。涉及计划外迁移或行为变化时先更新计划并确认；评估不授权实际部署。
|
|
4. 仅暂存本任务文件/片段，检查完整暂存 diff，确保不含用户原有改动、MEMORY 或讨论资产。无法隔离或 MEMORY 已被跟踪时先解决，不擅自取消跟踪。
|
|
5. 检查通过后，必须按项目规范执行本地 `git commit`；不 push、amend、跳过 hooks 或改 Git 身份。Hook 改动须重新检查验证。可在范围内修复的提交失败应修复重试；身份、权限等需用户处理的阻碍报告为“未完成提交”，保留现场。非 Git 项目不自行初始化；确实无任务差异时说明目标已满足及证据，不创建空提交。
|
|
6. 读取实际 commit hash 与提交文件，确认本次变更均已提交、无混入用户内容；检查工作区残余并更新外部记录。最终简报结果、验证、兼容性及上线顺序、偏差与 hash。若有本任务变更未提交，不得宣称执行完成；无关用户改动不影响本任务完成。详细结果给记录链接。
|