lfg

结果。 请求应到达其形态所要求的最终状态，由负责此事的 Compound Engineering 技能产出，并将所有未解决事项记录在用户能看到的地方。大多数请求以该技能的结果结束，不涉及分支。代码变更是步骤更多的一种形态：它应在一个开放的拉取请求中结束，你持有其 URL，并且 CI 已有结论；此前需完成实现、简化、审查并应用符合条件的发现，将其余发现记录下来，捕获任何持久经验，提交并推送。除非用户授权本次运行进行合并，否则合并由用户负责。

工作来源。 在会更改代码的路径上，只有在本次运行中验证过工作来源后才能实现；且只有两种来源符合条件：可直接实施的计划，由 ce-work 实施；或 ce-debug 返回的 fixed，其中修复本身就是实现。计划是会话识别出的计划，定义见 references/intake.md。绝不要在计划目录中搜索候选计划，也不要处理你自行发现的文件。若已有计划，绝不要从头制定计划。

按请求性质选择路径。 将请求匹配到负责该事项的技能；宿主提供的技能列表就是目录。选择前先阅读 references/intake.md；只有它定义了各条路径、路径优先级、传递给各子技能的内容，以及如何解读每种返回结果。简而言之：

• 计划路径，或本次会话中由 ce-plan 编写的计划，走计划路径。
• 对失败或错误行为的具体报告交给 ce-debug；复现问题是该技能的职责，不是 intake 的职责。
• 如果变更取决于用户尚未决定的判断，先交给 ce-pov；只有支持该变更的结论才能继续。若结论后无内容可构建，则以该结论结束。
• 对产品形态存在多种合理解读的请求，有人在场时交给 ce-brainstorm；无人参与的流水线模式下交给 ce-plan。
• 若请求的结果不是代码变更，则交给负责该结果的技能（ce-explain、ce-prototype、ce-pov、ce-ideate 等）；调用该技能就是整个运行：返回其结果并结束。
• 其他任何代码变更都交给 ce-plan。

不确定时，选择更依赖证据的路径。

交互。 仅通过 ce-brainstorm 向用户提问，且仅限有人参与时。其他所有工作都应继续进行，无需等待：可逆的工作应完成并展示给用户，以便其事后纠正；只有超出用户授权范围的不可逆操作（未经授权的合并、强制推送、删除数据）才应停止。lfg 用于调度器、循环和嵌套编排器。另一个问题是 references/stage-routing.md 定义的路由消歧：当对话将规划或实现分配给某个模型或执行环境时，路由前先阅读该文件；只有它包含承载字符串及其清理规则。

遇到以下任何情况时，停止并说明原因：

• 无法提供工作来源：规划返回 blocked、诊断未找到安全修复、修复会造成分歧、ce-pov 不支持该变更，或无法传递阶段分配。
• 子技能返回的内容不完整，或缺少证据。
• 已确定的决策被推翻。
• 项目定义的发布流程未能通过。

停止时，不得推送此前尚未推送的内容。

将此处提及的每项技能与宿主的可用技能列表进行匹配，并调用完全对应的条目；某些宿主会为其添加命名空间（例如 compound-engineering:ce-plan）。开始前先阅读 references/task-visibility.md：它定义通过平台的任务跟踪能力发布的阶段视图、聊天叙述，以及完成规则：只有步骤实际运行后才算完成；子技能返回后，应在同一轮中恢复下一编号步骤；并且在 DONE 或停止之前，不得结束本轮。

执行流程（会更改代码的路由）

1. 按照 references/intake.md 生成工作来源。在计划路由上，先阅读 references/plan-brief.md；只有它定义已确定决策简报和产物根目录规则。任何明确的 status: blocked 返回（包括 settled-decision-invalidated）都会终止本次执行。阻塞状态优先于现有产物，且绝不重试。只有在没有阻塞项，且没有计划文件由 ce-plan 报告本次执行已写入时，才使用相同参数再次调用 ce-plan，并原样复用已编写的简报；之后计划必须通过 references/plan-brief.md 中的就绪检查。在计划路由上，如果规划阶段指令已解析，则 plan_model:<alias> 载荷与请求一同传递。后续每个步骤都记录工作来源。LFG 绝不直接启动 /goal；由 ce-work 实施并返回控制权。

2. 先阅读 references/work-return.md，然后调用 ce-work 技能，并使用 mode:return-to-caller <plan-path-from-step-1>。缺陷路由不执行此步骤：ce-debug 已完成实施并提交，references/debug-return.md 是其门控依据。只有有效的 status: complete 才能继续；任何其他状态或格式错误的返回都会终止流水线。

3. 现在阅读 references/review-followup.md；它适用于步骤 3 至 7。对分支差异调用 ce-simplify-code 技能，并使用 mode:pipeline；仅当更改只涉及文档或大约少于 10 行时才跳过调用。

4. 使用 mode:agent plan:<plan-path-from-step-1> 调用 ce-code-review 技能；在缺陷路由上省略 plan:。如果某项 settled_conflict 发现的证据表明已确定的决策无法奏效（不可行、目标错误或具有破坏性），则在发布前置条件之前，将其作为阻塞项报告并终止流水线。

发布前置条件（从步骤 5 起的每次推送）。 运行一次 git remote。没有远程仓库意味着仅在本地操作：完成各步骤要求的所有提交，但跳过所有推送、PR 创建／编辑和 CI 监控操作，包括完整跳过步骤 10。这是终止状态，不是错误。

5. 按该文件的规定应用并持久保存审查修复。在仍有符合条件的审查修复仅存在于工作树、尚未提交时，不得继续进行剩余项交接、运行浏览器测试或输出 DONE。

6. 自主交接剩余项：每当存在尚未应用的可执行发现、步骤 4 的 settled_conflict 标记，或步骤 2 中已继续执行且被标记的 settled_decision_conflicts 条目时，都必须按照该文件的规定将其持久记录：写入 PR 正文；如果不会创建 PR，则记录在工单或 DONE 报告中。仅当这三项都不存在时才跳过。剩余项持久记录完成之前不得输出 DONE。如果报告已说明追踪器工单提交失败，绝不得因此阻止 DONE。不要提示用户。

7. 如果本次执行产生了代码、测试和计划中未体现的持久推理，则使用 mode:non-interactive 调用 ce-compound 技能；该文件载明完整条件。Documentation skipped 表示成功；在此处执行时，会在 PR 创建时将经验教训写入 PR。

8. 使用 mode:pipeline 调用 ce-test-browser 技能。

9. 先阅读 references/shipping.md；它适用于步骤 9 至 11。然后使用 mode:pipeline branding:on 调用 ce-commit-push-pr 技能。

10. 如存在未关闭的 PR，则按照 references/shipping.md 的规定，使用 ce-babysit-pr mode:pipeline <pr-url> 监控 PR，直至 CI 作出决定。不要在此处重新实现 CI 监控。

11. 按照 references/shipping.md 中的收尾流程完成后，输出 <promise>DONE</promise>。