execute

执行

实现方法。与领域技能（例如“noodle”）一同加载——领域技能讲解代码库，本指南讲解流程。全程完全自主运行。绝不询问用户。工作未全部完成前，不要停止。

使用 Tasks 跟踪所有工作（TaskCreate、TaskUpdate、TaskList）。每项分解后的变更对应一个任务；开始时标记为 in_progress，完成后标记为 completed。

1. 确定范围

明确需要完成的工作：

• 计划阶段：阅读 brain/plans/ 中分配的阶段。阅读概述，明确范围边界。调用 Skill(backlog) 获取项目特定背景信息。加载“Applicable skills”中列出的领域技能。
• 待办事项：阅读 brain/todos.md 中的待办内容。如果有链接的计划，则阅读该计划；否则，根据描述确定范围。
• 临时请求：用户提示就是工作范围。开始前，确定受影响的文件和包。

输出：清晰、明确的说明，界定要做和不做的变更。

2. 分解

将工作范围拆分为离散变更。每项变更应：

• 包含一个函数/类型及其测试，或一个 Bug 修复
• 可独立编译
• 对应一个常规提交

单项变更的工作范围无需分解。

3. 实施

优先使用 Worktree——不可妥协

绝不要在 main 上编辑文件。 多个会话会并发运行；编辑 main 会导致合并冲突和工作丢失。

如果当前工作目录已位于 .worktrees/ 内，则使用该目录。否则，运行：noodle worktree create <descriptive-name>

使用绝对路径或 noodle worktree exec <name> <cmd>。绝不要 cd 进入 worktree——如果它在 shell 位于其中时被移除，会导致会话永久终止。

在 worktree 内提交。完成后：noodle worktree merge <name>

仅当用户正在交互式地驱动单 Agent 会话，并明确选择使用 main 时，才可跳过此步骤。

委派

• 自行执行：单项变更，或紧密耦合的变更（共享类型、存在顺序依赖）。
• 子 Agent：有 2 项或更多互相独立且涉及不同文件的变更。提前提供背景信息：范围、相关代码、领域技能名称。
• 团队执行：计划中有 2 个或更多可并行阶段。参见 references/team-execution.md。
• Codex：无需判断的机械性工作（重命名、样板代码、重复性编辑）。绝不用它做架构决策。

如果各阶段紧密耦合，按顺序执行即可。并行化前，先问：“某个阶段的输出会成为另一个阶段的输入吗？”共享类型级契约的阶段必须按顺序执行。

4. 验证

提交前运行完整验证套件。完整检查清单参见 references/verification.md。绝不要提交未通过检查的代码——如果失败，先修复并重新验证。

5. 提交

使用 <type>(<scope>): <description> 格式，可附加 Refs: #<issue-ID> 页脚。类型：feat、fix、refactor、test、docs、chore。每项逻辑变更对应一个提交。

6. 交付

所有变更提交并通过验证后，发出 stage_yield：

noodle event emit --session $NOODLE_SESSION_ID stage_yield --payload '{"message": "Implemented: <brief summary>"}'

否则，只有在进程正常退出时阶段才会完成——中断的工作会从流水线中丢失。

范围纪律

• 只修改范围内的内容。不添加防御性代码、向后兼容垫片或推测性功能。
• 范围外发现的问题记入质量审查备注——不要修改。
• 计划或需求有误或不完整时，在输出中指出，不要擅自偏离。

原则

运行时从 brain/principles/ 读取：

• [[prove-it-works]]
• [[subtract-before-you-add]]
• [[cost-aware-delegation]]
• [[guard-the-context-window]]
• [[boundary-discipline]]
• [[outcome-oriented-execution]]