execute

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Execute

执行

Implementation methodology. Loads alongside the domain skill (e.g., "noodle") — this teaches process, the domain skill teaches the codebase.

Operate fully autonomously. Never ask the user. Don't stop until the work is fully complete.

Track all work with Tasks (TaskCreate, TaskUpdate, TaskList). One task per decomposed change; mark in_progress when starting, completed when done.

实施方法论，它与领域技能（例如 "noodle"）一同加载：本方法论讲解流程，而领域技能讲解代码库相关内容。

完全自主运行，无需询问用户，在工作完全完成前不要停止。

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

Execution Flow

执行流程

1. Scope

1. 范围界定

Establish what needs doing:

Plan phase: Read the assigned phase from
```
brain/plans/
```
. Read the overview for scope boundaries. Invoke Skill(backlog) for project-specific context. Load domain skills listed in "Applicable skills."
Backlog item: Read the todo from
```
brain/todos.md
```
. If a linked plan exists, read it. Otherwise, scope from the description.
Ad-hoc request: The user prompt is the scope. Identify affected files and packages before starting.

Output: a clear, bounded description of what changes and what doesn't.

明确需要完成的工作内容：

计划阶段：从
```
brain/plans/
```
读取分配的阶段内容，阅读概览明确范围边界，调用Skill(backlog)获取项目特定上下文，加载「适用技能」中列出的领域技能。
待办项：从
```
brain/todos.md
```
读取待办内容，如果存在关联的计划则读取对应计划，否则根据描述界定范围。
临时需求：用户提示即为范围，开始前先确认受影响的文件和包。

输出：清晰、有边界的描述，明确哪些内容需要变更、哪些不需要变更。

2. Decompose

2. 任务拆解

Break scope into discrete changes. Each change:

One function/type + its tests, OR one bug fix
Independently compilable
One conventional commit

Single-change scopes skip decomposition.

将范围拆分为独立的变更项，每个变更项满足：

一个函数/类型 + 对应的测试，或一个bug修复
可独立编译
对应一个规范化提交

仅包含单个变更的范围可跳过拆解步骤。

3. Implement

3. 执行实施

Worktree First — Non-Negotiable

优先使用worktree，硬性要求

Never edit files on main. Multiple sessions run concurrently; editing main causes merge conflicts and lost work.

If CWD is already inside

.worktrees/

, use it. Otherwise:

noodle worktree create <descriptive-name>

Use absolute paths or

noodle worktree exec <name> <cmd>

. Never
cd
into a worktree — if it gets removed while the shell is inside, the session dies permanently.

Commit inside the worktree. When done:

noodle worktree merge <name>

Skip only when the user is interactively driving a single-agent session and explicitly chooses main.

绝对不要在main分支上编辑文件。多个会话会并行运行，编辑main分支会导致合并冲突和工作内容丢失。

如果当前工作目录（CWD）已经在

.worktrees/

内，直接使用即可，否则执行：

noodle worktree create <描述性名称>

使用绝对路径或者

noodle worktree exec <名称> <命令>

操作。绝对不要cd进入worktree目录——如果worktree在shell处于该目录时被删除，会话会永久崩溃。

在worktree内执行提交，完成后执行：

noodle worktree merge <名称>

仅当用户在交互式驱动单Agent会话且明确选择使用main分支时，可跳过本规则。

Delegation

任务委派

Self-execute: Single change, or tightly coupled changes (shared types, sequential dependencies).
Sub-agents: 2+ independent changes touching different files. Front-load context: scope, relevant code, domain skill name.
Team execution: 2+ parallelizable phases in a plan. See below.
Codex: Mechanical work not requiring judgment (renames, boilerplate, repetitive edits). Never for architectural decisions.

Sequential is fine when phases are tightly coupled. Before parallelizing, ask: "Does any phase's output become another phase's input?" If one phase defines a type/interface that another consumes, they share an API contract and must be sequential — otherwise each invents its own version. Only phases with no type-level coupling can overlap.

自行执行：单个变更，或耦合度高的变更（共享类型、顺序依赖）。
子Agent：2个及以上涉及不同文件的独立变更，提前提供上下文：范围、相关代码、领域技能名称。
团队执行：计划中2个及以上可并行的阶段，见下文说明。
Codex：不需要判断的机械性工作（重命名、样板代码、重复性编辑），绝不要用于架构决策。

当阶段耦合度高时按顺序执行即可。并行执行前先确认：「是否有某个阶段的输出会成为另一个阶段的输入？」如果某个阶段定义了另一个阶段要使用的类型/接口，二者共享API契约，必须按顺序执行——否则各自会产出自己的版本。只有不存在类型级别耦合的阶段可以并行执行。

Team Execution

团队执行

The lead orchestrates — it does NOT implement. Research via sub-agents, delegate all implementation to teammates.

Lead worktree: Use current worktree if already in one, otherwise
```
noodle worktree create plan-<N>-lead
```
Team:
```
TeamCreate
```
— all tasks go through this team's task list

Per-teammate worktrees:

noodle worktree create plan-<N>-phase-<M>

Spawn teammates:
```
Task
```
with
```
mode: "bypassPermissions"
```
,
```
team_name
```
, worktree path, scope, and domain skill name. Always spawn fresh agents to keep context clean.
Teammates commit on their own branches
Review before merging: Spawn a review agent to check each teammate's work against the plan before merging

Merge teammates into lead (not main):

bash

git -C .worktrees/plan-<N>-lead merge <teammate-branch>
noodle worktree cleanup plan-<N>-phase-<M>

Verify integrated result in lead worktree (see Verify below)
Merge lead to main:
```
noodle worktree merge plan-<N>-lead
```

Foundational phases that later phases depend on: execute first, commit in lead worktree, then create teammate worktrees from that point.

负责人负责编排协调，不负责执行实现。通过子Agent完成调研，将所有实现工作委派给团队成员。

负责人worktree：如果当前已经在worktree内则直接使用，否则执行
```
noodle worktree create plan-<N>-lead
```
团队创建：执行
```
TeamCreate
```
，所有任务都通过该团队的任务列表流转

每个团队成员的worktree：执行

noodle worktree create plan-<N>-phase-<M>

创建团队成员实例：创建
```
Task
```
，指定
```
mode: "bypassPermissions"
```
、团队名称、worktree路径、范围、领域技能名称。始终创建新的Agent保持上下文干净。
团队成员提交：在各自的分支上完成提交
合并前评审：合并前创建评审Agent，对照计划检查每个团队成员的工作内容

将团队成员的代码合并到负责人分支（而非main分支）：

bash

git -C .worktrees/plan-<N>-lead merge <团队成员分支名>
noodle worktree cleanup plan-<N>-phase-<M>

在负责人worktree内验证集成结果（见下文验证部分）
将负责人分支合并到main：
```
noodle worktree merge plan-<N>-lead
```

作为后续阶段依赖的基础阶段：优先执行，在负责人worktree内提交后，再基于该节点创建团队成员的worktree。

4. Verify

4. 验证

Every change must pass before committing. Fix and re-verify on failure. Never commit failing code.

Unit & static analysis — after each change:

```
go test ./...
```
(or scoped to changed packages)
```
go vet ./...
```
```
sh scripts/lint-arch.sh
```
— if present

E2E smoke tests — after integrating changes, before merging to main:

```
pnpm test:smoke
```

In a worktree:

noodle worktree exec <name> pnpm test:smoke

When UI changes: write NEW test cases covering the changed interface

Fixture tests — when changes affect loop behavior or runtime state:

```
pnpm fixtures:loop
```
/
```
pnpm fixtures:hash
```

Update fixtures:

pnpm fixtures:loop:record

then

pnpm fixtures:hash:sync

Visual verification — when changes affect UI:

Use the Chrome tool to open the UI in browser, click through affected flows

Scope check:

```
git diff --stat
```
— matches expected scope
All checklist items addressed (plan phase, todo criteria, or ad-hoc requirements)

每个变更提交前必须通过验证，验证失败则修复后重新验证，绝对不要提交无法通过验证的代码。

单元测试与静态分析——每次变更后执行：

```
go test ./...
```
（或限定在变更的包范围内）
```
go vet ./...
```
```
sh scripts/lint-arch.sh
```
——如果该脚本存在

E2E冒烟测试——变更集成后、合并到main前执行：

```
pnpm test:smoke
```

在worktree内执行：

noodle worktree exec <名称> pnpm test:smoke

如果涉及UI变更：编写新的测试用例覆盖变更的交互界面

Fixture测试——当变更影响循环逻辑或运行时状态时执行：

```
pnpm fixtures:loop
```
/
```
pnpm fixtures:hash
```

更新fixture：执行

pnpm fixtures:loop:record

后再执行

pnpm fixtures:hash:sync

可视化验证——当变更影响UI时执行：

使用Chrome工具在浏览器中打开UI，点击遍历所有受影响的流程

范围检查：

```
git diff --stat
```
——匹配预期的变更范围
所有检查清单项都已完成（计划阶段、待办验收标准、或临时需求）

5. Commit

5. 提交

<type>(<scope>): <description>

Refs: #<issue-ID>

Types:

feat

fix

refactor

test

docs

chore

. Scope: package or area changed. Refs: include when linked issue exists; omit for ad-hoc work.

One commit per logical change.

<type>(<scope>): <description>

Refs: #<issue-ID>

类型：

feat

、

fix

、

refactor

、

test

、

docs

、

chore

。范围：变更的包或领域。关联ID：存在关联issue时包含，临时工作可省略。

每个逻辑变更对应一次提交。

6. Yield

6. 产出

After all changes are committed and verified, emit

stage_yield

to signal the deliverable is complete:

bash

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

This tells the Noodle backend the stage's work is done, even if the agent process hasn't exited yet. Without this, the stage only completes on clean process exit — if the agent is interrupted after committing, the work is lost to the pipeline.

所有变更提交并验证通过后，触发

stage_yield

信号表示交付物已完成：

bash

noodle event emit --session $NOODLE_SESSION_ID stage_yield --payload '{"message": "Implemented: <简要总结>"}'

该信号会告知Noodle后端当前阶段的工作已完成，即使Agent进程还未退出。如果没有该信号，阶段仅会在进程正常退出时标记为完成——如果Agent在提交后被中断，流水线会丢失该部分工作成果。

Scope Discipline

范围准则

Only change what's in scope. No defensive code, backwards-compat shims, or speculative features.
Out-of-scope discoveries go in the quality review notes — don't change them.
Wrong or incomplete plan/requirements: flag it in output, don't silently deviate.

仅变更范围内的内容，不要添加防御性代码、向后兼容垫片、或推测性功能。

发现范围外的问题写入质量评审备注中，不要直接修改。

计划/需求错误或不完整：在输出中明确标记，不要悄无声息地偏离需求。

Principles

原则

Read at runtime from

brain/principles/

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

运行时从

brain/principles/

读取：

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