`ce-work`

根据计划的护栏执行——用你面前的代码弄清楚如何操作，发布完整的功能，交给干净的 PR。

ce-work 是执行技能。它需要一个计划（或者，对于较小的范围，一个简单的提示），根据计划的护栏执行实施，连续运行测试，在范围保证时在隔离的工作树中分派子代理，运行质量门，然后移交给提交+ PR 流程。它将计划视为决策工件——对于范围、决策、单元和测试具有权威性——并计算出实际的实施本身。 ce-plan故意不预写的是HOW阶段。

这是复合工程构思链中的第四步也是最后一步：

/ce-ideate         /ce-brainstorm      /ce-plan             /ce-work
"What's worth      "What does this     "What's needed       "Build it."
 exploring?"        need to be?"        to accomplish
                                        this?"

ce-work 主要以软件为中心 - 它提交、运行测试、打开 PR 并与代码审查技能集成。它还具有轻量级的非代码剥离：标记为 execution: knowledge-work 的计划（由 ce-plan 的进近高度流生成）路由到知识工作路径，该路径读取源代码、综合并生成可交付成果，从而跳过代码生命周期。其他没有该标记的非软件工作仍然有效地以 ce-plan 结束，并由人类执行。

TL;DR

问题	回答
它有什么作用？	阅读计划（或确定一个简单的提示），根据护栏执行，连续运行测试，发送经过审查的 PR
何时使用它	实施 `ce-plan` 计划；小型/中型即时工作；恢复部分发货工作
它生产什么	提交 + PR（或仅提交，无 PR 路径）
接下来是什么？审查公关；运行 `/ce-compound` 来获取经验教训
区分	计划感知幂等性、具有工作树隔离的子代理调度、具有残差门的分层审查、PR 中的操作验证

＃＃问题

要求代理人“实施该计划”会以可预见的方式出错：

在拾取部分完成的分支时重新实现已交付的工作
将计划视为脚本 - 编辑列出的文字文件，即使不同的形状会更清晰
对所有被模拟的东西进行测试 - 单独证明逻辑；没有提及各层是否正确交互
半成品功能 - 可见的工作已完成，未连接的回调，未触及的边缘情况
并行工作，无提示数据丢失 — 多个代理在共享目录中写入同一文件；仅最后一次写入幸存
没有质量门 - 差异直接进入 PR，没有简化通过，没有审查，没有运营监控

解决方案

ce-work 作为具有显式门的结构化进程来运行执行：

该计划对于什么具有权威性；代理通过前面的代码计算出如何
每个任务之前进行幂等性检查 - 如果验证已经满足，则跳过它
范围适当的调度（隔离工作树中的内联/串行子代理/并行子代理）
测试发现+集成覆盖+在任何任务标记为完成之前进行系统范围的测试检查
带有剩余工作门的分层代码审查——接受、归档、修复或停止，但绝不默默发布
每个 PR 都有一个操作验证计划 - 监控什么、触发回滚

是什么让它如此新颖

1. 计划感知执行——尊重“什么”/“如何”分离

ce-work 将计划视为决策工件，而不是脚本。范围、决策、U-ID、文件、测试场景和验证标准都是权威的——代理自行计算出实际的实施情况。计划主体在执行期间保持只读状态；进度存在于 git 提交和任务跟踪器中。

2.幂等重新执行

在执行每个任务之前，ce-work 检查单元的工作是否已经存在并符合计划的意图。如果验证已得到满足，请将任务标记为完成并继续。 没有静默重新实现。 这在上下文压缩后恢复、拿起其他人的分支或在几周后返回到部分交付的计划时最为重要。

3.工作树隔离的并行性——显式冲突，而不是静默数据丢失

对于可以并行运行的独立单元，当线束支持时， ce-work 默认为每个子代理工作树隔离：每个子代理位于其自己的目录中的自己的分支上。当协调器显式处理合并冲突时，预测的重叠就会出现。当隔离不可用时，子代理将被禁止暂存或提交，并且协调器会连续合并批次。无论哪种方式，都不会无声覆盖。

4. U-ID 跨执行锚定

当计划定义 U-ID 时，它们会作为任务前缀传播到提交消息中，并传播到最终摘要中。这在跨计划编辑中有效——分割单元的深化过程不会破坏引用，因为 U-ID 是稳定的。头脑风暴起源 ID (R/A/F/AE) 在存在时同样会被保留。

5. 在“完成”之前测试质量门

代码编译时任务尚未完成。在将任何功能承载任务标记为完成之前， ce-work 会发现正在更改的现有测试文件，检查测试场景是否涵盖适用的类别（快乐路径、边缘、错误路径、集成），并跟踪更改可能影响的回调、中间件和观察者的两个级别。嘲笑一切都证明了孤立的逻辑；集成覆盖率证明了各层确实可以协同工作。

6. 具有显式剩余处理的分层代码审查

每项更改都会受到审查。默认是harness-native（例如，克劳德代码中的/review）——快速，足以满足大多数差异。仅在真实信号上升级到 ce-code-review：敏感表面、大而分散的变化或明确的请求。当更深入的审查发现自动修复未解决的残留时， ce-work 不会默默地发布 - 它会显示一个四选项门（应用/提交票据/接受持久接收器/停止）。 “接受”需要真实持久的记录；研究结果不能只存在于短暂的会话中。

7. 默认操作验证

每个 PR 描述都包含 Post-Deploy Monitoring & Validation 部分：日志查询、要观察的指标、预期的健康信号、故障信号、回滚触发器。如果确实没有对生产产生影响，则该部分仍然存在，并将其作为记录的决策而不是隐含的决策。

8. 根据提示进行智能分类

并非每次调用都有计划。 ce-work 接受一个简单的提示并按复杂性进行分类：琐碎的工作（几个文件，没有行为改变）直接进行实现；中小型工作建立任务清单；对于大型或敏感工作表面，建议首先使用 /ce-brainstorm 或 /ce-plan。分类使得 ce-work 对于小型工作的直接调用来说是合理的，而无需强制所有事情都使用完整的链。

简单示例

包含四个实施单位的计划已出台。 ce-work 读取它，在一个单元上拾取 Execution note: test-first ，并记下要记住的延迟实现问题。它构建一个带有 U-ID 前缀的任务列表，并确认当前分支名称是有意义的。

并行安全检查发现四个单元之间没有文件重叠，并且工作树隔离可用 - 因此所有四个单元并行调度，每个单元在自己的分支上。他们完成；协调器按依赖顺序合并它们；每次合并后测试都会通过。幂等性检查发现前一个会话已经满足一个单元的验证，并将其标记为完成而无需重新实现。

差异不在敏感表面上，也不是很大/漫射，因此线束本机审查可以处理它；这两个建议的调查结果已内联解决。最终验证通过；起草操作验证计划； ce-commit-push-pr 打开 PR，其中包含摘要、测试说明、操作部分和复合工程徽章。计划本身保持不变——它是一个决策工件，它是否发布是源自 git，而不是记录在文档中。

何时去实现它

在以下情况下使用 ce-work：

ce-plan 计划已准备就绪，您可以发货了
您有小型或中型工作，没有计划 - 裸提示模式可以处理它
您正在恢复部分交付的工作
您想要具有安全隔离的并行执行
您需要完整的运输流程 - 测试、简化、审查、残差、操作验证、公关

在以下情况下跳过 ce-work：

产品行为尚未确定 → /ce-brainstorm
没有为重要工作建立实施护栏 → /ce-plan
该错误有已知的根本原因和明显的修复 → /ce-debug
任务是非软件的，不是标记的 execution: knowledge-work 计划 - 普通的非软件工作是人类活动（标记的知识工作计划确实会导致剥离）

用作链式工作流程的一部分

/ce-ideate          (optional)
   |
   v
/ce-brainstorm
   |  requirements / brief
   v
/ce-plan
   |  guardrails — U-IDs, files, test scenarios, scope, risks
   v
/ce-work
   |  honors the guardrails; figures out the HOW with code in front of it
   |  derives progress from git, not plan body
   |  ships through quality gates to PR
   v
/ce-code-review     (optional escalation; auto-invoked at Tier 2)
   |
   v
/ce-compound        — capture the learning

发布后，/ce-compound 将任何可重用的学习内容（遇到的错误、建立的模式、采用的约定）捕获到 docs/solutions/ 中，以便未来运行 ce-plan 和 ce-work 从机构记忆中受益。

使用独立版

许多人直接使用 ce-work 并给出简单的提示 - 当范围很小且代理可以自行确定范围时，ce-plan 就显得有些过分了。

具有明确根本原因的错误修复 - 如果微不足道，则直接实施；任务列表（小型/中型）
小重构 — 提取助手、重命名概念、合并重复
恢复部分交付的计划 - 幂等性防止重新实现
在你的脑海中连接一个你已经设计好的功能，正式的规划将是仪式
多功能并行工作 - 工作树隔离可让您同时推送多个独立功能，而无需 git 争用

对于大型裸提示范围（横切、敏感表面、许多文件），ce-work 建议首先使用 /ce-brainstorm 或 /ce-plan — 但仍可根据您的选择继续。

＃＃参考

论证	效果
（空）	自动使用 `docs/plans/` 中的最新计划
`<plan path>`	原产地执行
`<bare prompt>`	按复杂性分类（简单/小-中/大）

输出：通过 ce-commit-push-pr 提交和（通常）PR。该计划自始至终都是只读的 — ce-work 永远不会改变它；是否发货是从git导出的，没有记录在doc中。

＃＃常问问题

为什么 ce-work 不直接编写计划的确切签名中的所有代码？ 因为该计划故意没有确切的签名——它有决策、单元、文件、范围和测试场景。计划就是做什么； ce-work 是具体方法。这种分离使得计划可以在数周的代码更改和实施者之间进行移植。

如果我没有计划怎么办？ 裸提示模式按复杂性进行分类。琐事直接落实；小/中建立任务列表；大表面建议首先进行规划。

工作树隔离和共享目录并行模式有什么区别？ 工作树隔离为每个子代理在其自己的目录中提供了自己的分支 - 当编排器显式处理合并冲突时，重叠的写入表面。共享目录模式禁止子代理暂存、提交或运行测试套件（编排器在批处理后执行这些操作）。两者都是安全的；工作树隔离是更干净的体验。

为什么它在每个任务之前检查工作是否已经完成？ 上下文压缩后恢复、拿起别人的分支或返回到部分交付的计划都是很常见的。幂等性确保 ce-work 不会默默地重新实现已经存在的内容。

什么是剩余工作门？ 当更深入的代码审查层发现自动修复无法解决的问题时，ce-work 不会默默地发送它们。它要求：立即申请/提交票据/接受（使用耐用水槽）/停止。 “接受”需要真正持久的记录——调查结果不能只存在于会议中。

ce-work 是否支持非软件计划？ 对于标记为 execution: knowledge-work 的计划（由 ce-plan 的接近高度流程生成），是的 - 轻量级剥离读取源、综合并生成可交付成果，跳过提交/测试/PR 生命周期。其他没有该标记的非软件工作仍然以 ce-plan 结束，并由人类执行。

另请参阅

ce-plan — 生成 ce-work 执行的护栏
ce-brainstorm — 定义计划应该完成的任务
ce-ideate — 上游“值得探索的内容”发现
ce-code-review — 第 2 层升级目标
ce-commit-push-pr — 处理最终提交 + PR 流程
ce-compound — 捕获交付后可重用的学习内容