executing-plans

执行计划

概览

加载计划，严格审查，执行所有任务，并在完成后报告。

开始时宣布：“我将使用执行计划技能来实施此计划。”

对于非简单执行，加入 Aegis Visibility：简要说明当前工作片段与计划、检查点、偏离情况或验证边界的关系。完成时，将计划遵循情况、证据、复杂度和剩余风险交由 verification-before-completion，以生成统一回执。

如果有可用的子 Agent，且计划包含真正独立的任务，优先使用 subagent-driven-development；不支持子 Agent 不会阻止内联执行。所有 Agent 共用同一个工作区，协调者仍是唯一负责 Git 变更的人。

流程

第 1 步：加载并审查计划

1. 阅读计划文件
2. 如果计划或当前检查点包含 Execution Readiness View，请在实施前阅读，并根据其意图锁定、范围边界、基线锁定、所有者 / 契约约束、兼容性边界、退役边界、测试义务、审查关卡、偏离 / 回退规则以及完成前所需证据，核对计划是否符合其要求。
3. 严格审查——找出计划中的任何疑问或顾虑
4. 如果该视图与计划、基线或当前工作树证据相矛盾，请返回计划审查，或在编辑前刷新建议交接内容。
5. 实施前运行 TDD Route Guard：确认 Mode、Decision、Strict authority、严格信号、轻量模式适用性、Test posture 和验证要求。严格步骤必须由明确的用户 / 项目请求或记录在案的自动决策授权；仅有计划批准或风险标签不构成授权。缺少处于 off 模式的记录时，只能将其补记为 Mode: off / Decision: skipped，不得加载 TDD。缺少或不受支持的自动决策应返回计划审查。如果存在任何严格信号，或微小 / 低风险 / 单一所有者 / 不改变行为的证明不完整，则自动轻量模式记录不受支持。只有在记录了严格授权时，Decision: strict 才能授权执行名为 Write failing test、Verify RED、GREEN 或 REFACTOR 的步骤。执行过程中不得自行推断 strict。
6. 如果有顾虑：开始前与人类协作者提出
7. 首次写入前，捕获 TaskStartSnapshot：根目录、HEAD、分支或分离状态、上游分歧、暂存 / 未暂存 / 未跟踪路径、活跃的 Git 操作以及 git worktree list --porcelain。保留任务开始前已有的状态；不得暂存、重置、清理或提交这些状态。
8. 除非规则要求独立历史，或另一个目标拥有当前分支，否则沿用当前分支。如果理由充分且安全，可在当前工作区切换到或创建分支；但 worktree 仍需并行检出，或不存在阻塞性的脏状态。
9. 如果没有顾虑：创建 TodoWrite 并继续

第 1.5 步：长任务检查点设置

如果计划包含多个任务、可能跨会话执行，或涉及架构 / 契约 / 工作流变更：

1. 宣布：“我将使用 long-task-continuation 技能为此计划设置检查点，并跟踪偏离情况。”
2. 加载 aegis:long-task-continuation。
3. 根据计划创建初始检查点：
   • 当前待办事项
   • 当前任务
   • 已完成任务
   • 证据引用
   • 阻碍因素
   • 下一步
4. 每项任务开始前，重述当前检查点。
5. 每项任务完成后，更新检查点、证据引用和偏离检查。

在进行由验证驱动的计划外编辑前，请阅读保留的 PatchShape、CanonicalOwner、UpwardDrillSignal、结果和证据引用。编辑前，将它们与候选方案的比较交由 systematic-debugging 处理，由其判断方向是否一致。已证明属于独立规范所有者根因的情况，仍按正常计划路径处理。

步骤 2：执行任务

对于界面／交互变更，在进行受影响的编辑前，先组合使用 ui-ux-governance，并在相关用户接触点验证计划中限定的体验标准。

对于每项任务：

1. 标记为 in_progress

2. 严格遵循每个步骤（计划中的步骤都很小）

3. 在任务添加任何新的源代码路径前，重述计划中的 Change Necessity，或在计划未保留该内容时，简要补充一项。计划获批本身并不能证明新的辅助程序、小型守卫、新分支、回退方案、适配器或所有者是必要的。

   Change Necessity:
   - User-visible need:
   - No-change / non-code option:
   - Why code change is necessary:
   - Minimum change boundary:
   - Decision: no-change | docs/config-only | code-change | needs-clarification
   

   如果决策不是 code-change，请暂停执行并返回计划审查，而不是编辑。如果决策是 code-change，则在编辑和验证范围内纳入最小边界。

4. 在进行任何非平凡的源代码编辑前，运行计划中的 Pre-Edit Complexity Check，或简要补充一项：

   使用 using-aegis/references/complexity-governance.md 了解共享构件类别、压力信号和 over-budget 处理方式。

   Complexity Budget:
   - Artifact class:
   - Target files / artifacts:
   - Current pressure:
   - Projected post-change pressure:
   - Budget result: within-budget | at-risk | over-budget
   - Planned governance:
   
   Pre-Edit Complexity Check:
   - Target edit file:
   - Existing pressure signal:
   - Safer edit boundary:
   - Decision: edit-in-place | extract helper | add owner file | split task | pause for plan update
   
   Pre-Edit Owner-Fit Decision:
   - Edit intent: wiring-only | move-out / extract-first | local-fix-without-new-responsibility | new-responsibility | emergency / compatibility patch
   - Owner fit:
   - Safer edit boundary:
   - Decision: edit-in-place | extract helper | add owner file | split task | pause for plan update
   

   如果检查结果与计划的文件边界相矛盾，请暂停并返回计划审查，而不是默默将逻辑塞进负担过重的所有者中。如果预算结果为 over-budget，且任务也不负责治理该超支，请停止执行并返回计划审查，而不是将任务强行推进，假装它仍然是原子任务。 当目标编辑文件超出预算或用途混杂时，默认不得在其中添加 new-responsibility。仅当 wiring-only、move-out / extract-first 和 local-fix-without-new-responsibility 不会增加新职责，且验证边界明确时，才可继续。emergency / compatibility patch 必须说明剩余风险和退役触发条件。

5. 按指定要求运行验证

6. 协调者是 Git 变更的负责人。连贯的任务通过计划中的验证后，在默认本地提交前使用 verification-before-completion，仅暂存任务所属路径，并读取 HEAD、已提交文件列表和剩余任务差异。no commit、只读、无变更和验证失败的任务不得创建常规提交。

7. 在将任务标记为 completed 前，更新 TodoCheckpointDraft 和 DriftCheckDraft。 如果存在 Execution Readiness View，偏移检查必须明确将当前切片与该视图的意图锁定、范围围栏、基线锁定、兼容性边界、退役边界、测试义务和审查关卡进行比较。

8. 标记为 completed

步骤 3：完成开发

所有任务均完成并验证后：

• 如果 Aegis 创建了分支／工作树，或用户要求处理集成事宜， 使用 aegis:finishing-a-development-branch；
• 否则使用 verification-before-completion，报告本地任务提交以及 Task clean / Repository clean，不要擅自增加合并／PR 流程。

何时停止并寻求帮助

出现以下情况时，请立即停止执行：

• 遇到阻碍（缺少依赖项、测试失败、指令不清楚）
• 计划存在妨碍启动工作的重大缺漏
• 不理解某条指令
• 验证反复失败

请先请求澄清，不要猜测。

何时重新审视前面的步骤

在以下情况下返回审查（步骤 1）：

• 合作方根据你的反馈更新了计划
• 需要重新思考基本方案

不要强行越过阻碍——停止并寻求帮助。

请记住

• 首先严格审查计划
• 严格遵循计划步骤
• 不要跳过验证
• 按计划要求参考技能
• 遇到阻碍就停止，不要猜测
• 不要仅仅因为当前分支是 main／master 就创建分支
• 不要仅仅因为任务复杂度、TDD、规划或子 Agent 就触发创建工作树

集成

必需的工作流技能：

• aegis:writing-plans - 创建此技能执行的计划
• aegis:using-git-worktrees - 仅当获批的 Git 生命周期要求进行并发检出时使用
• aegis:finishing-a-development-branch - 仅当分支／工作树集成或清理属于范围时使用