ce-work

工作执行命令

结果

• 结果： 基于计划、规范或具体工作提示词，完成全面实现并在本地验证的变更集。
• 下游使用方： 独立使用时，交付工作流会将经过验证的变更送交审查和交付。处于 Return-to-Caller Mode 时，调用工作流会收到结构化的实现和验证结果，并负责其余关卡。
• 完成条件： 所有范围内的任务均已完成，必要的验证证据已记录，相关检查均通过，并且运行已进入其负责的交付移交环节（附带代码审查回执或明确的跳过语句——参见 Phase 3-4）、完整的返回结果，或明确的阻塞状态。
• 意图： 完成请求的功能，不重新协商计划，也不转移规范集成权限。工作者接收范围明确的工作单元；宿主编排器检查实际变更，并负责权威验证和规范提交。

执行工作流

必须读取打包的参考资料，不能凭估计处理。 使用运行环境提供的完整技能路径，从此技能已加载的 SKILL.md 所在目录解析下文提到的每个参考资料或脚本路径，绝不通过对目标仓库执行 glob 来查找打包文件。进入相关阶段时读取每份参考资料；在该阶段之前读取不算数，而且此文件要求再次读取的参考资料，必须在指定步骤重新读取，即使它已在上下文中。如果运行环境未提供技能目录，或无法读取必需文件，请在执行该文件所约束的操作前停止，并报告缺少的文件。不要凭记忆重构其规则；应报告缺少的参考资料，而非继续本地操作。

Phase 0：输入分流

首先处理恢复请求。 在将输入分类为计划、路径、空白内容或单独的提示词之前，先识别恢复、检查、回收或清理现有运行的请求。恢复操作绝不派发新工作者、选择新路径、发现其他计划、重新运行已完成的验证，或进入任一交付路径。如果缺少运行 ID，请询问用户；绝不猜测。

在做出任何其他输入判断之前，读取 references/input-triage.md。该文件决定来源解析、控制令牌、恢复、只读发现、计划就绪情况、非代码路由、空白输入和单独提示词的规模判断。以下三条规则在此同样适用：

• 对于琐碎的单独提示词——涉及一两个文件，且不改变行为——跳过任务列表，但写入前仍须确定执行引擎。纯机械式差异也无需进行 PR 后跟进。若对任一情况拿不准，采用更全面的流程。
• 如果本次会话中的 ce-plan 已为某个单独提示词评估规模，则直接执行，不再规划。凡是需要用户权衡的决定，都应作为问题提问，绝不能将其作为返回 ce-plan 或 ce-brainstorm 的路径。
• 如果无法读取该参考资料，请停止；绝不能将控制令牌或不可执行的产物视为代码工作。

当分流选择 Return-to-Caller Mode 时，立即读取 references/return-to-caller.md，并记录该文件将决定此运行如何结束。如果无法读取，请在任何修改发生前停止；不要退回独立模式。

阶段 1：快速开始

1. 建立工作区。 在切换分支、编辑、派发或提交之前，先阅读 references/workspace-setup.md。该文档决定可写的检出目录、计划澄清、分支位置、工作前清点、已有未提交更改的文件，以及任务设置。没有可写的规范检出目录时，绝不写入；除非用户在本次会话中明确要求，否则绝不在实际默认分支上写入。

   不要提交或发布用户未提供的任何内容。 如果某个单元需要的文件已有未提交更改，独立模式会询问一次是否包含或排除该文件。Return-to-Caller Mode 既不询问，也不编辑该文件；它会返回阻塞状态，并指出冲突及恢复方法。

2. 确定引擎，再确定策略。 完成有界计划接收和任务推导后，在选择执行、写入、派发或提交的单元之前，阅读 references/execution-engines.md 并完成其路由选择。无论是否存在显式绑定，该文档均适用；仅当该参考文档选择原生执行或穷尽允许的回退方案时，才可使用原生执行。引擎选择不会改变决定运行如何结束的参考文档。

   如果选择跨模型执行，在任何内容或权限跨交给另一个模型之前，阅读 references/cross-model-execution.md。该文档定义控制器初始化、初始化后的引擎锁定、有界出站、事务、恢复和回执。

   在选择内联、串行或并行执行之前，以及派发任何工作器之前，阅读 references/execution-strategy.md。该文档决定调度、隔离、每个工作器收到的数据包、工作器生命周期和集成方式。宿主编排器负责权威验证并进行规范提交。

阶段 2：执行

在首次实施写入之前（包括走轻量任务路径时），阅读 references/implementation-loop.md。该文档决定如何选择证据、进行验证、何时停止一个单元、增量提交、遵循现有模式、持续测试、简化的边界、UI 工作、进度跟踪和已确定的决策。

该文件中的提交规则始终有效：每次实施提交只能包含该单元所负责的文件。单独执行 git commit 可能会纳入用户预先放入暂存区的内容，因此严禁这样做。

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

任务和本地验证完成后，独立模式会在任何质量检查或交付之前阅读 references/shipping-workflow.md。该文档决定简化、代码审查回执及回退方案、遗留问题、最终验证和交付。

代码审查完成门槛（仅限独立模式）。 发布前必须实际完成代码审查。在发布参考文档记录了实际完成的 ce-code-review 回执或其明确授权的跳过状态之一之前，本次运行尚未完成，不得调用提交或发布技能，也不得报告发布已完成。绝不能用自行审查或先前已处理的问题替代。此规则不适用于 Return-to-Caller Mode。

返回调用方模式

返回调用方模式仅执行实现和本地验证。不得进入第 3–4 阶段，也不得执行最终简化、代码审查、创建 PR、监视 CI、看护或任何其他独立交付操作；这些步骤由调用方负责。

输出结果前，必须再次读取 references/return-to-caller.md。该文件单独定义了完整的返回结果、证据完整性检查、路由和模型记录、恢复语义，以及 standalone_shipping_skipped: true。不得根据本文件构建完整结果。

如果规划或实现已创建状态后，无法读取该必需文件，请保留所有已更改的文件、提交、工作区和控制器记录。返回本文件规定的最简阻塞结果：status: blocked、plan_path、已知时填写 run_id、changed_state、注明缺失参考文件的 blockers，以及 recovery_path。不得清除部分状态、报告成功，或转而走独立交付流程。