工作执行命令

高效执行工作，同时保持质量和精加工功能。

＃＃ 介绍

该命令采用工作文档（计划或规范）或描述工作的简单提示，并系统地执行它。重点是通过快速了解需求、遵循现有模式并始终保持质量来交付完整的功能。

Beta 推出说明： 当您想要试用 Codex 授权时，请手动调用 ce-work-beta。在测试期间，规划和工作流程切换保持稳定的 ce-work 以避免双路径编排复杂性。

输入文档

#$ARGUMENTS

参数解析

解析 $ARGUMENTS 以获得以下可选标记。在将剩余部分解释为计划文件路径或裸提示之前，先剥离每个已识别的标记。

所有标记都是可选的。如果不存在，则返回到下面的解决链。

模糊激活： 还可以识别命令性委托意图短语，例如“使用 codex”、“委托给 codex”、“codex 模式”或“委托模式”等价于 delegate:codex。在提示中仅提及“codex”（例如，“修复 codex 转换器错误”）不得激活委托——只有明确的委托意图才会触发它。

模糊停用： 还将“无代码”、“本地模式”、“标准模式”等短语识别为相当于 delegate:local。

设置解析链

从参数中提取令牌后，使用以下优先级链解析委托状态：

1. 参数标志 -- 当前调用中的 delegate:codex 或 delegate:local （最高优先级）
2. 配置文件 -- 从下面的配置块中提取设置。 work_delegate 的值 codex 激活委派； false 停用。
3. 硬默认 -- false（委托关闭）

配置（预先解决）： !cat "$(git rev-parse --show-toplevel 2>/dev/null)/.compound-engineering/config.local.yaml" 2>/dev/null || echo '__NO_CONFIG__'

If the block above contains YAML key-value pairs, extract values for the keys listed below. If it shows __NO_CONFIG__, the file does not exist — all settings fall through to defaults. If it shows an unresolved command string, read .compound-engineering/config.local.yaml from the repo root using the native file-read tool (e.g., Read in Claude Code, read_file in Codex). If the file does not exist, all settings fall through to defaults.

如果任何设置具有无法识别的值，则转为该设置的硬默认值。对于没有硬默认值的可选设置（work_delegate_model、work_delegate_effort），无法识别或无法解析的值会解析为 unset — 相应的标志在 codex exec 调用中被省略，因此 Codex 从 ~/.codex/config.toml 解析。切勿将无效值替换为 CLI 标志。

配置键：

• work_delegate -- codex 或默认 false
• work_delegate_consent -- true 或默认 false
• work_delegate_sandbox -- yolo （默认）或 full-auto
• work_delegate_decision -- auto （默认）或 ask
• work_delegate_model -- 要使用的 Codex 模型。可选 — 当未设置或不可解析时，遵循用户的 ~/.codex/config.toml 默认值。 Passthrough — 任何非空字符串都被视为有效；只有 YAML 解析失败或空值才会解析为取消设置。
• work_delegate_effort -- minimal、low、medium、high 或 xhigh 之一。可选 - 当取消设置或设置为此枚举之外的值时，解析为取消设置并遵循用户的 ~/.codex/config.toml 默认值。

存储已解析的状态以供下游消费：

• delegation_active -- 布尔值，委托模式是否开启
• delegation_source -- argument 或 config 或 default -- 授权是如何解决的（环境卫士使用它来决定通知的详细程度）
• sandbox_mode -- yolo 或 full-auto （来自配置或默认 yolo）
• consent_granted -- 布尔值（来自配置 work_delegate_consent）
• delegate_model -- 配置中的字符串，或未设置（遵循 Codex 配置）
• delegate_effort -- 来自配置的字符串，或未设置（遵循 Codex 配置）。每批次工作量选择的下限；没有直接传递到 codex exec。
• effective_effort -- 每批次派生值 (default | medium | high | xhigh)，在每批次之前根据 delegate_effort 计算，并根据 references/codex-delegation-workflow.md 选取级别（“每批次工作量”）。提供 codex exec 调用来代替 delegate_effort。

执行工作流程

阶段 0：输入分类

根据 <input_document> 中提供的内容确定如何继续。

计划文档（输入是现有计划或规范的文件路径）：首先读取计划的元数据 - Markdown 计划的 YAML frontmatter，或 HTML 计划的可见标题文本（两种格式都带有相同的字段）。如果它带有 execution: knowledge-work，则这是一个 非代码计划 - 阅读 references/non-code-execution.md 并遵循该剥离，而不是此工作流程的其余部分。否则（该字段不存在或 execution: code）→ 跳到阶段 1 并运行正常的代码生命周期。 （标记检查位于此处，位于计划文档处理内部，因为检测标记需要已有文件；下面的“裸提示”不受影响。）

裸提示（输入是工作描述，而不是文件路径）：

1. Scan the work area

• 根据提示识别可能更改的文件
  • 查找这些区域的现有测试文件（搜索导入、引用或与实现文件共享名称的测试/规范文件）
  • 注意受影响地区的当地模式和惯例

2. 评估复杂性和路线

   Complexity	Signals	Action
   Trivial	1-2 files, no behavioral change (typo, config, rename)	Proceed to Phase 1 step 2 (environment setup), then implement directly — no task list, no execution loop. Apply Test Discovery if the change touches behavior-bearing code
   Small / Medium	Clear scope, under ~10 files	Build a task list from discovery. Proceed to Phase 1 step 2
   Large	Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations	Inform the user this would benefit from /ce-brainstorm or /ce-plan to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2

第 1 阶段：快速启动

1. 阅读计划并澄清 （如果从阶段 0 到达且仅有提示，则跳过）

• 完整阅读工作文件
  • 将计划视为决策工件，而不是执行脚本
  • 如果计划包含 Implementation Units、Work Breakdown、Requirements（或旧版 Requirements Trace）、Files、Test Scenarios 或 Verification 等部分，请将这些部分用作主要来源材料执行
  • 检查每个实现单元上的 Execution note — 这些携带该单元的计划执行状态信号（例如，测试优先或表征优先）。创建任务时请注意它们。
  • 检查 Deferred to Implementation 或 Implementation-Time Unknowns 部分 - 这些是规划者在执行过程中故意留给您解决的问题。在开始之前记下它们，以便它们告知您的方法，而不是在任务中让您感到惊讶
  • 检查 Scope Boundaries 部分 - 这些是明确的非目标。如果实施开始将您拉向相邻的工作，请回头参考它们
  • 查看计划中提供的任何参考资料或链接
  • 如果用户在此会话中明确要求 TDD、测试优先或表征优先执行，请尊重该请求，即使计划没有 Execution note
  • 如果有任何不清楚或不明确的地方，请立即提出澄清问题
  • 如果需要澄清上述问题，请获得用户对已解决答案的批准。如果不需要澄清，则无需单独的批准步骤即可继续 - 计划范围是计划的权威，无需重新协商
  • 不要跳过这个 - 现在提出问题比构建错误的东西更好
  • 不要在执行过程中编辑计划主体。 计划是一个决策工件；进度存在于 git 提交和任务跟踪器中，而不是计划中。 ce-work 不会改变计划——它是否是从 git 派生的，没有记录在文档中。旧版计划可能在单位标题或 status: 字段上包含 - [ ] / - [x] 标记 - 将其作为状态忽略；每个单元的完成情况是在执行期间通过读取当前文件状态来确定的。

2. 设置环境

首先，检查当前分支：

   current_branch=$(git 分支 --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')

# 如果远程 HEAD 未设置则回退
   if [ -z "$default_branch" ];然后
     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
   菲

如果已经在功能分支（不是默认分支）：

首先，检查分支名称是否有意义 - 像 feat/crowd-sniff 或 fix/email-validation 这样的名称可以告诉未来的读者该作品的内容。自动生成的工作树名称（例如 worktree-jolly-beaming-raven）或其他不透明名称则不会。

如果分支名称无意义或自动生成，建议在继续之前重命名它：

git branch -m <meaningful-name>

从计划标题或工作描述中得出新名称（例如 feat/crowd-sniff）。将重命名作为推荐选项，同时继续按原样进行。

然后问：“继续处理 [current_branch]，还是创建一个新分支？”

• 如果继续（无论是否重命名），请继续执行步骤 3
• 如果创建新的，请按照下面的选项 A 或 B 操作

如果在默认分支上，选择如何继续：

选项A：创建一个新分支

git pull origin [default_branch]
git checkout -b feature-branch-name

根据工作使用有意义的名称（例如 feat/user-authentication、fix/email-validation）。

选项 B：使用工作树（建议用于并行开发）

skill: ce-worktree
# The skill will create a new branch from the default branch in an isolated worktree

选项 C：在默认分支上继续

• 需要明确的用户确认
• 仅在用户明确表示“是的，提交到 [default_branch]”后才继续
• 未经明确许可，切勿直接提交到默认分支

建议：在以下情况下使用工作树：

• 您想要同时处理多个功能
• 你想在实验时保持默认分支干净
• 您打算经常在分行之间切换

3. Create Task List (skip if Phase 0 already built one, or if Phase 0 routed as Trivial)

   • Use the platform's task tracking tool (TaskCreate/TaskUpdate/TaskList in Claude Code, update_plan in Codex, or the equivalent on other harnesses) to break the plan into actionable tasks
   • Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
   • When the plan defines U-IDs for Implementation Units, preserve the unit's U-ID as a prefix in the task subject (e.g., "U3: Add parser coverage"). This keeps blocker references, deferred-work notes, and final summaries anchored to the same identifier the plan uses, so progress and traceability remain unambiguous across plan edits
   • Carry each unit's Execution note into the task when present
   • For each unit, read the Patterns to follow field before implementing — these point to specific files or conventions to mirror
   • Use each unit's Verification field as the primary "done" signal for that task
   • Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
   • Include dependencies between tasks
   • Prioritize based on what needs to be done first
   • Include testing and quality check tasks
   • Keep tasks specific and completable

4. 选择执行策略

委派路由门： 如果 delegation_active 为 true 并且输入是计划文件（不是简单的提示），请阅读 references/codex-delegation-workflow.md 并遵循其预委派检查和委派决策流程。如果所有检查都通过并且委派继续进行，则强制串行执行并使用工作流的批处理执行循环直接进入第 2 阶段。如果任何检查禁用委派，请参阅下面的标准策略表。如果委派处于活动状态，但输入只是一个简单的提示（无计划文件），请将 delegation_active 设置为 false，并附上简短说明：“Codex 委派需要计划文件 - 使用标准模式。”并继续下面的标准策略选择。

创建任务列表后，根据计划的大小和依赖结构决定如何执行：

Parallel Safety Check — required before choosing parallel dispatch:

1. 从每个候选单元的 Files: 部分构建文件到单元的映射（创建、修改和测试路径）
   2. 检查交集 — 任何出现 2 个以上单位的文件路径都意味着重叠
   3. 如果发现重叠且工作树隔离不可用：降级为串行子代理。记录原因（例如，“单元 2 和 4 共享 config/routes.rb — 使用串行调度”）。串行子代理仍然提供上下文窗口隔离，而无需共享目录写入竞争。
   4. 如果发现重叠并且工作树隔离可用：并行调度仍然是安全的 - 子代理独立工作，并且重叠表面作为可预测的合并冲突，编排器通过下面的批处理后流程进行处理。记录预测的重叠，以便批处理后流程知道哪些合并会发生冲突。

即使没有文件重叠，共享协调器工作目录的并行子代理也会面临 git 索引争用（并发暂存/提交会损坏索引）和测试干扰（并发测试运行会获取彼此正在进行的更改）。工作树隔离消除了两者；下面的共享目录后备约束可以缓解这些问题。

子代理隔离 — 为每个并行子代理提供自己的工作树：

• Claude 代码（Agent 工具）： 通过 isolation: "worktree" 和 run_in_background: true。该工具在其自己的分支上的 .claude/worktrees/agent-<id> 下创建每个子代理工作树。在依赖它之前验证 .claude/worktrees/ 是否被 gitignored。
• 其他平台没有内置工作树隔离（例如，Codex spawn_agent、Pi subagent）：子代理共享协调器的目录。

子代理调度使用可用的子代理或任务生成机制。对于每个单位，给出子代理：

• 完整的计划文件路径（用于整体上下文）
• 特定单元的目标、文件、方法、执行说明、模式、测试场景和验证
• 与该单元相关的任何已解决的延迟问题
• 在编写测试之前检查单元的测试场景是否涵盖所有适用类别（快乐路径、边缘情况、错误路径、集成）并补充差距的说明

共享目录后备约束 — 仅在工作树隔离不可用时适用：

• 指示每个子代理：“不要暂存文件 (git add)、创建提交或运行项目测试套件。编排器在所有并行单元完成后处理测试、暂存和提交。”
• 这些约束可防止并发子代理之间的 git 索引争用和测试干扰。
• 工作树隔离处于活动状态时，忽略这些约束 — 子代理可以在自己的工作树分支内暂存、提交和运行其单元的测试。

权限模式： 调度子代理时省略 mode 参数，以便应用用户配置的权限设置。不要传递 mode: "auto" — 它会覆盖用户级设置，例如 bypassPermissions。

After each subagent completes (serial mode):

1. Review the subagent's diff — verify changes match the unit's scope and Files: list
2. Run the relevant test suite to confirm the tree is healthy
3. If tests fail, diagnose and fix before proceeding — do not dispatch dependent units on a broken tree
4. Update the task list (do not edit the plan body — progress is carried by the commit)
5. Dispatch the next unit

批处理中的所有并行子代理完成后（工作树隔离模式）：

1. 等待当前并行批次中的每个子代理完成。
2. 对于每个已完成的子代理，按依赖顺序：检查工作树与协调器分支的差异。如果子代理没有提交自己的工作，则将其暂存并提交到该工作树内。
3. 按依赖顺序将每个子代理的分支合并到协调器的分支中。 如果出现合并冲突，则中止合并（git merge --abort）并针对现在合并的树连续重新分派冲突单元 - 手动解决默默地选择一方并放弃一个单元的意图。 （并行安全检查的预测重叠在这里表现为冲突，而不是共享目录模式下的静默数据丢失。）
4. 每次合并后，运行相关的测试套件。如果测试失败，请在合并下一个分支之前进行诊断和修复。
5. 更新任务列表（进度由合并提交承载）。
6. 合并后，移除每个子代理的工作树并删除其分支。使用子代理结果中返回的绝对路径和分支名称。
   • 首先解锁工作树 - 线束锁定每个子代理工作树：git worktree unlock <absolute-path>
   • 删除工作树：git worktree remove <absolute-path>
   • 删除分支：git branch -d <branch-name>（默认情况下，该分支的寿命比工作树长，如果不清理，则会作为孤儿累积；-d 小写拒绝删除未合并的分支，这就是我们想要的安全性 - 如果失败，请在强制之前进行调查）
7. 调度下一批独立单元，或下一个从属单元。

批处理中的所有并行子代理完成后（共享目录后备）：

1. 等待当前并行批次中的每个子代理完成，然后再对其任何结果采取行动
2. 交叉检查发现的文件冲突：比较批次中所有子代理修改的实际文件（而不仅仅是其声明的 Files: 列表）。子代理可能会创建或修改计划期间未预期的文件 - 这是预期的，因为计划描述的是什么而不是如何。仅当同一批中的 2 个以上子代理修改同一文件时，冲突才会产生影响。在共享工作目录中，只有最后编写者的版本会幸存 - 其他单元对该文件的更改都会丢失。如果检测到冲突：首先提交所有单元中的所有非冲突文件，然后为共享文件串行重新运行受影响的单元，以便每个单元都建立在对方提交的工作的基础上
3. 对于每个已完成的单元，按依赖顺序：检查差异、运行相关测试套件、仅暂存该单元的文件，并使用从单元目标派生的常规消息进行提交
4. 如果在提交单元更改后测试失败，请在提交下一个单元之前进行诊断和修复 5.更新任务列表（不要编辑计划主体——进度由刚刚所做的提交承载）
5. 调度下一批独立单元，或下一个依赖单元

第 2 阶段：执行

1. 任务执行循环

对于按优先级顺序排列的每个任务：

   while (tasks remain):
     - Mark task as in-progress
     - Read any referenced files from the plan or discovered during Phase 0
     - **If the unit's work is already present and matches the plan's intent** (files exist with the expected capability, or the unit's `Verification` criteria are already satisfied by the current code), the work has likely shipped on a prior branch or session. Verify it matches, mark the task complete, and move on. Do not silently reimplement.
     - Look for similar patterns in codebase
     - Find existing test files for implementation files being changed (Test Discovery — see below)
     - If delegation_active: branch to the Codex Delegation Execution Loop
       (see `references/codex-delegation-workflow.md`)
     - Otherwise: implement following existing conventions
     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
     - Run System-Wide Test Check (see below)
     - Run tests after changes
     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
     - Mark task as completed
     - Evaluate for incremental commit (see below)

当一个单位带有 Execution note 时，请尊重它。对于测试优先的单元，在实施该单元之前编写失败的测试。对于特征优先的单元，在更改之前捕获现有行为。对于没有 Execution note 的单位，请务实地进行。

执行姿势的护栏：

• 当测试优先时，不要在同一步骤中编写测试和实现
• 在实施修复或功能之前，不要跳过验证新测试是否失败
• 当进行测试优先时，不要过度实现超出当前行为切片的内容
• 跳过琐碎的重命名、纯配置和纯样式工作的测试优先原则

测试发现 - 在对文件实施更改之前，查找其现有测试文件（搜索导入、引用或与实施文件共享命名模式的测试/规范文件）。当计划指定测试场景或测试文件时，从那里开始，然后检查计划可能未枚举的其他测试覆盖范围。对实现文件的更改应该伴随相应的测试更新——新行为的新测试、更改行为的修改测试、删除行为的删除或更新测试。

测试场景完整性 — 在为包含功能的单元编写测试之前，请检查计划的 Test scenarios 是否涵盖适用于该单元的所有类别。如果类别缺失或场景模糊（例如，“正确验证”而没有命名输入和预期结果），请在编写测试之前从单元自身的上下文中进行补充：

系统范围的测试检查 - 在将任务标记为完成之前，暂停并询问：

何时跳过： 叶节点更改时没有回调、没有状态持久性、没有并行接口。如果更改纯粹是附加的（新的辅助方法、新的视图部分），则检查需要 10 秒，答案是“没有任何触发，跳过”。

**当这最重要时：**涉及回调模型、回退/重试错误处理或通过多个接口公开的功能的任何更改。

2. 增量提交

完成每个任务后，评估是否创建增量提交：

启发式：“我可以编写一条提交消息来描述完整的、有价值的更改吗？如果可以，请提交。如果消息是“WIP”或“部分 X”，请等待。”

如果计划有实施单元，请使用它们作为提交边界的起始指南 - 但根据您在实施过程中发现的内容进行调整。如果一个单元比预期大，则可能需要多次提交，或者小型相关单元可能会合并在一起。使用每个单元的目标来告知提交消息。

提交工作流程：

# 1.验证测试是否通过（使用项目的测试命令）
# 示例：bin/rails 测试、npm 测试、pytest、go 测试等。

# 2. 仅暂存与该逻辑单元相关的文件（不是 `git add .`）
git add <与该逻辑单元相关的文件>

# 3. 使用常规消息提交
git commit -m“壮举（范围）：此单元的描述”

处理合并冲突： 如果在变基或合并过程中出现冲突，请立即解决。增量提交使冲突解决变得更容易，因为每次提交都很小且重点突出。

Note: Incremental commits use clean conventional messages without attribution footers. The final Phase 4 commit/PR includes the full attribution.

并行子代理模式： 提交所有权按隔离模式分割（请参阅第 1 阶段第 4 步）：

• **工作树隔离：**子代理可以在自己的工作树分支内暂存和提交；编排器在批处理后按依赖顺序合并这些分支。
• **共享目录后备：**子代理不提交；在整个并行批处理完成后，编排器会暂存并提交每个单元。

3. 遵循现有模式

• 该计划应引用类似的代码 - 首先阅读这些文件
  • 完全匹配命名约定
  • 尽可能重用现有组件
  • 遵循项目编码标准（请参阅 AGENTS.md；仅当存储库仍保留兼容性垫片时才使用 CLAUDE.md）
  • 如有疑问，请 grep 查找类似的实现

4. 持续测试

• 在每次重大更改后运行相关测试
  • 不要等到结束才进行测试
  • 立即修复故障
  • 添加新行为的新测试，更新更改行为的测试，删除已删除行为的测试
  • **使用模拟的单元测试单独证明逻辑。与真实对象的集成测试证明这些层可以协同工作。**如果您的更改涉及回调、中间件或错误处理 - 您两者都需要。

5. 随心所欲地简化

完成一组相关的实现单元（或每 2-3 个单元）后，检查最近更改的文件以寻找简化机会 - 合并重复的模式、提取共享帮助程序并提高代码重用和效率。这在使用子代理时尤其有价值，因为每个代理都在隔离的上下文中工作，并且无法看到跨单元出现的模式。

不要在每个单元之后都进行简化——早期的模式可能看起来重复，但在后面的单元中故意有所不同。等待自然相边界或当您注意到累积的复杂性时。

如果 ce-simplify-code 可用，请在阶段边界调用它（特别是在阶段 3 之前，当差异 >=30 行时）。否则，请自行检查更改的文件以获得重用和整合的机会。

6. Figma 设计同步（如果适用）

对于 Figma 设计的 UI 工作：

• 按照设计规范实施组件
  • 迭代使用 ce-figma-design-sync 代理进行比较
  • 修复发现的视觉差异
  • 重复直到实现与设计匹配

7. 前端设计指南（如果适用）

对于没有 Figma 设计的 UI 任务——其中实现涉及视图、模板、组件、布局或页面文件，创建用户可见的路线，或者计划包含显式 UI/前端/设计语言：

• 在实施之前加载 ce-frontend-design 技能
  • 遵循其检测、指导和验证流程
  • 如果该技能生成了验证屏幕截图，则它满足第 4 阶段的屏幕截图要求 - 无需单独捕获。如果技能退回到心理审查（无法访问浏览器），则第 4 阶段的屏幕截图仍然适用

8. 跟踪进度
   • 完成任务时保持任务列表更新
   • 注意任何阻碍或意外发现
   • 如果范围扩大则创建新任务
   • 让用户了解主要里程碑
   • 当计划为实施单元定义 U-ID 时，或者计划或原始文档带有稳定的 R-ID（以及可选的 A/F/AE ID）时，请在阻止程序、延期工作说明、任务摘要和最终验证中引用它们，而不是例行状态更新。 U-ID 跨计划编辑锚定单元； R/A/F/AE 在头脑风暴计划交接中锚定产品意图。使用计划提供的 ID，不要发明计划未提供的 ID。这样可以保留可追溯性，而不会将信号隐藏在噪声之下。

第 3-4 阶段：质量检查和收尾工作

When all Phase 2 tasks are complete and execution transitions to quality check, read references/shipping-workflow.md for the full shipping workflow: quality checks, code review, final validation, PR creation, and notification.

法典委托模式

当参数解析后 delegation_active 为 true 时，请阅读 references/codex-delegation-workflow.md 以了解完整的委托工作流程：预检查、批处理、提示模板、执行循环和结果分类。

关键原则

快速启动，执行更快

• 一开始就得到澄清，然后执行
• 不要等待完全理解 - 提出问题并行动
• 目标是完成功能，而不是创建完美的流程

计划是你的指南

• 工作文档应引用类似的代码和模式
• 加载这些参考文献并遵循它们
• 不要重新发明 - 匹配现有的

边走边测试

• 在每次更改后运行测试，而不是在最后运行测试
• 立即修复故障
• 持续测试可防止出现重大意外

质量是内置的

• 遵循现有模式
• 为新代码编写测试
• 在推送之前运行 linting
• 当第 1 层可用或第 2 层标准匹配时进行审查（请参阅 shipping-workflow.md）

提供完整的功能

• 在继续之前标记所有已完成的任务
• 不要让功能完成 80%
• 已发布的已完成功能胜过未发布的完美功能

要避免的常见陷阱

• 分析瘫痪 - 不要想太多，阅读计划并执行
• 跳过澄清问题 - 现在就问，而不是在构建错误的东西之后
• 忽略计划参考 - 该计划有链接是有原因的
• 最后测试 - 持续测试或稍后受苦
• 忘记跟踪进度 - 随时更新任务状态或忘记已完成的工作
• 80% 完成综合症 - 完成功能，不要过早继续
• 无故跳过审核 — 在可用时使用第 1 层；仅根据 shipping-workflow.md 中的标准升级到第 2 级；当两者都被跳过时记录
• 将计划重新划分为人工时间阶段 - 计划的实施单位定义执行范围。不要估计每个单元的工时、提出多日细分或要求用户为“本次会话”选择单元的子集。代理以代理速度执行，上下文窗口压力通过子代理调度（第 1 阶段第 4 步）解决，而不是通过分阶段会话解决。如果计划文件输入对于单次执行来说确实太大，请明确说明并建议用户返回 /ce-plan 以缩小范围 - 不要发明会话阶段作为解决方法。对于裸提示输入，Phase 0 的大型路由已经可以处理超大的工作