核心引擎 · 难度：进阶

lfg 编排器

将请求一路推进到完成态的顶层技能。references/intake.md 中定义六条路由，正文包含十一个步骤。

lfg 是什么——以及不是什么

lfg 是唯一编排其他技能的技能。它不实现、不测试、不调试、不发布——只把请求路由到负责该工作的技能，然后返回该技能的结果，或对代码变更运行 11 步状态机。本插件中每一条跨技能边都源于 lfg（或者另一台编排器 ce-babysit-pr）。

六条路由

来自 references/intake.md，按严格优先级排序——首条匹配者胜出：

lfg 编排流程 — 14 步链,从意图判定到看护,中间聚合状态
lfg 的六条路由。路由 5 立即返回；其余五条运行 11 步状态机。

路由定义

#路由触发条件首选动作
1计划路径请求指明了一个计划产物（统一计划路径、头脑风暴产物、本会话此前的计划）调用 ce-plan（恢复/深化）或直接使用该计划
2缺陷具体失败/错误的行为需要修复；问题引用 / 失败测试路径 / 堆栈跟踪以 mode:return-to-caller 调用 ce-debug
3判定变更依赖于用户未拍板的一个决定（"我们要不要采用 X？"）调用 ce-pov；判定作为证据携带
4产品未决多种合理的产品行为并存；人在场以 mode:return-to-caller 调用 ce-brainstorm
5非代码结果不是代码变更（解释 / 原型 / 判定 / 构思 / 交接）调用匹配的技能；以该技能的结果结束本次运行
6计划（默认）其他代码变更使用清理后的请求 + 简报调用 ce-plan

十一个步骤（针对代码变更路由）

lfg 步骤详细流程 — Plan / Work / Resolve / PR / Ship / Babysit / Done
11 步状态机。每个步骤的参考文件必须在该步骤之前加载。

各步骤要点

完整细节见 references/plan-brief.md、references/work-return.md、references/review-followup.md、references/shipping.md 以及各技能页。下面是承载契约的摘要。

步骤 1 — 工作源

步骤 1.5 — 已决决策简报（当存在计划时）

简报包含：

无可携带内容时，不要写空简报。

步骤 2 — 实现

步骤 3 — 简化

在分支 diff 上调用 ce-simplify-code mode:pipeline。将计划路径作为上下文传递，供 KTD 保留。仅在仅文档或 10 行以内的变更上跳过。本步骤不要提交；步骤 9 提交残余。

步骤 4 — 评审

调用 ce-code-review mode:agent plan:<plan-path>。缺陷路由：省略 plan:。阅读 Actionable Findings 摘要与产物路径。若某条带 settled_conflict 戳记的发现项，其证据表明已决决策无法落地，则停止流水线。

步骤 5 — 应用并落地修复

仅当以下全部四项成立时才应用某条发现项：

  1. suggested_fix 已给出且具体。
  2. confidence 为 100，或 75 且记录了跨 persona 共识。
  3. 修复是机械性的（无契约/权限/安全变更）。
  4. 编辑前，证据仍能匹配所引用的 file:line。

绝不要把 autofix_class 当作授权。提交 fix(review): apply review findings，当配置了远端时推送。

步骤 6 — 残余交接

以下两种触发器会持久写入残余：

当存在 PR 时：在步骤 9 的 PR 描述上下文中撰写 ## Unapplied review 章节（每条一项，对应一条 bullet）。无 PR 时：以非交互模式加载 references/tracker-defer.md，按配置跟踪器接受的数量尽可能多地建单。

步骤 7 — 复合（合格时）

调用 ce-compound mode:non-interactive。Documentation skipped 即为成功。步骤 9 提交并推送 ce-compound 写下的内容，使该学习在 PR 开启时已合入。不要在步骤 10 之后运行——"CI 已决"之后再推送会留下无人看管的 head。

步骤 8 — 浏览器测试

调用 ce-test-browser mode:pipeline。无头运行，永远不要在 human-verify 流程上暂停；记录并附理由跳过。

步骤 9 — 发布

首先：发布前置。执行一次 git remote。无远端 = 全本地终止（仅提交；不推送、不开 PR、不守 CI）。有远端时：调用 ce-commit-push-pr mode:pipeline branding:on。将步骤 6 的 ## Unapplied review 作为 PR 描述上下文传入。传入 settled_decision_conflicts 条目。缺陷路由：改为传入 debug 的 root_cause 与 issue_of_record。

先读计划的执行档案：它是单个 PR 还是多个 PR。多个 PR 时要一个 stack 并命名其层——每个 PR 组一层，自底向上按合并顺序；某层的 Waits on: 行点名了必须先上线的部署时，把该依赖作为 PR 描述上下文带上。ce-commit-push-pr 从本请求的落地意图里挑 babysit 姿态：用户授予合并时带上落地意图 → 交出 posture:stack-land；任一层带部署依赖时不带落地意图 → 交出 posture:stack-ready，因为没有技能能观测部署，收尾时逐层列出用户必须先确认上线的层。

PR 已存在时跳过创建但仍提交推送未提交内容；pipeline 模式默认不动已有 PR 描述，所以推送后要再以 ce-commit-push-pr mode:pipeline 的描述更新模式把同样的上下文写进去。

步骤 10 — 看护

默认调用 ce-babysit-pr mode:pipeline <pr-url>；当看护跟随一次 stack 提交时，传入 posture:stack-ready 或 posture:stack-land。不要在此处重新实现 CI 看护——看护拥有它。收集结构化结果 { status, fixes_applied, residuals }。

步骤 11 — 收尾

停止条件

lfg 在以下任一条件成立时停止（不产生 DONE）：

停止时，先前已推送的内容不会被推送走。

验证授权与停止消息

调用 lfg 本身就是用户预先批准本次变更所需的验证：浏览器测试、模拟器或真机、截图、跑起应用或 dev server、在该应用上使用电脑。项目指令若要求"先问用户"或"把测试留给用户"，这份批准已经给出——照项目规定的方式跑，不要停下来问。它不覆盖生产系统、真实账号与其数据、删数据或 lfg 本身之外的动作，也永远不替你回答宿主或系统的审批弹窗。

批准仍可被拒绝：它覆盖"先问一下""测试留给用户"这类把决定交给人的指令，不覆盖无条件禁止某种方法的指令（例如"本仓库永不跑浏览器测试"）；后者视为拒绝。拒绝导致改动拿不到证据时，在那一步停下、不报 DONE，并在停止消息里点名是哪条指令或弹窗拒绝、以及怎样才能让它跑（批准它或放宽该指令）。工具缺失等原因跑不了不算拒绝——在回顾里说明没跑与原因，继续。

没到 DONE 的最终消息不是"完成回顾"。开头必须是停止本身：跑停在哪一步、被什么挡住、用户要做什么决定；给出选项并把推荐放最前，有 PR 就附链接；其后才回顾做了什么、留在哪里，引用的子技能返回放在开头之后。不要用提问工具等待回复——这条消息本身就是交接。

参考