lfg 编排器
将请求一路推进到完成态的顶层技能。references/intake.md 中定义六条路由，正文包含十一个步骤。
lfg 是唯一编排其他技能的技能。它不实现、不测试、不调试、不发布——只把请求路由到负责该工作的技能，然后返回该技能的结果，或对代码变更运行 11 步状态机。本插件中每一条跨技能边都源于 lfg（或者另一台编排器 ce-babysit-pr）。
六条路由
来自 references/intake.md，按严格优先级排序——首条匹配者胜出：
路由定义
| # | 路由 | 触发条件 | 首选动作 |
|---|---|---|---|
| 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 |
十一个步骤（针对代码变更路由）
各步骤要点
完整细节见 references/plan-brief.md、references/work-return.md、references/review-followup.md、references/shipping.md 以及各技能页。下面是承载契约的摘要。
步骤 1 — 工作源
- 计划路由：使用清理后的请求 + 简报调用
ce-plan。 - 缺陷路由：调用
ce-debug mode:return-to-caller <bug>；返回fixed即为工作源。 - 判定路由：调用
ce-pov；判定作为证据携带，而非作为已决决策。 - 头脑风暴路由（人在场）：
ce-brainstorm mode:return-to-caller <feature>。 - 任何
status: blocked返回都会终止本次运行。
步骤 1.5 — 已决决策简报（当存在计划时）
简报包含：
- 方向（1–2 行）
- 已决决策（每条包含：决策 + 来源类
user-directed|user-approved+ 被否决的替代方案 + 原因） - 开放领域（任何被引用为证据而非定论的 ce-pov 判定）
- 一行请 ce-plan 报告冲突的固定提示
无可携带内容时，不要写空简报。
步骤 2 — 实现
- 计划路由：调用
ce-work mode:return-to-caller <plan-path>。 - 缺陷路由：跳过——
ce-debug已经实现并提交。 - 只有合法的
status: complete才推进。
步骤 3 — 简化
在分支 diff 上调用 ce-simplify-code。将计划路径作为上下文传递，供 KTD 保留。仅在仅文档或 10 行以内的变更上跳过。本步骤不要提交；步骤 9 提交残余。
步骤 4 — 评审
调用 ce-code-review mode:agent plan:<plan-path>。缺陷路由：省略 plan:。阅读 Actionable Findings 摘要与产物路径。若某条带 settled_conflict 戳记的发现项，其证据表明已决决策无法落地，则停止流水线。
步骤 5 — 应用并落地修复
仅当以下全部四项成立时才应用某条发现项：
suggested_fix已给出且具体。confidence为 100，或 75 且记录了跨 persona 共识。- 修复是机械性的（无契约/权限/安全变更）。
- 编辑前，证据仍能匹配所引用的 file:line。
绝不要把 autofix_class 当作授权。提交 fix(review): apply review findings，当配置了远端时推送。
步骤 6 — 残余交接
以下两种触发器会持久写入残余：
- 步骤 4 中未应用的可执行发现项。
- 步骤 4 中带
settled_conflict戳记的发现项。 - 步骤 2 中的
settled_decision_conflicts条目。
当存在 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。
步骤 10 — 看护
默认调用 ce-babysit-pr mode:pipeline <pr-url>；当看护跟随一次 stack 提交时，传入 posture:stack-ready 或 posture:stack-land。不要在此处重新实现 CI 看护——看护拥有它。收集结构化结果 { status, fixes_applied, residuals }。
步骤 11 — 收尾
- 对任何非空的
needs_human_residuals渲染## Needs Needs your decision。 - 回显
New concepts:行。 - 指向交互式看护到合入的入口，附带渲染好的
ce-babysit-pr调用（posture:stack-ready/posture:stack-land时，用同一姿态作用于栈底 PR URL）。 - 当计划记录了
work-relationships语义角色时，按references/next-work-handoff.md触发可选的下一项工作提议。 - 输出
<promise>DONE</promise>。
停止条件
lfg 在以下任一条件成立时停止（不产生 DONE）：
- 工作源无法产生：计划返回 blocked、诊断未找到安全修复、修复会发散、
ce-pov不支持该变更、阶段分配无法下传。 - 子级返回值不是 complete 且有据。
- 已决决策被新证据作废。
- 项目定义的发布流程不够用（例如声明的 stack 工具失败）。
停止时，先前已推送的内容不会被推送走。
参考
references/intake.md— 6 条路由、优先级，以及每个子级收到什么references/plan-brief.md— 产物根 + 已决决策简报references/work-return.md— 读取 ce-work 的结构化返回references/review-followup.md— 步骤 3–7 细节references/shipping.md— 步骤 9–11 细节references/debug-return.md— 缺陷路由的 debug 返回references/next-work-handoff.md— 可选的下一项工作提议references/stage-routing.md— 按阶段的 model/harness 路由载体references/task-visibility.md— 任务列表可见性 + 叙述规则