lfg

关键：你必须严格按照顺序执行以下每一步。不要跳过任何必需步骤。不要提前跳到编码或实现阶段。规划阶段（步骤 1）必须在任何工作开始前完成并验证。违反此顺序会导致输出质量低下。

在调用下面引用的任何技能时，根据宿主平台提供的可用技能列表解析其名称，并使用确切的条目。某些平台将技能列在插件命名空间下（例如 compound-engineering:ce-plan）；其他平台则列出裸名称。调用不在列表中的简写猜测将失败——在调用技能/任务工具之前，始终匹配列表中的条目。

任务可见性

在步骤 1 之前，如果可用，使用平台的任务跟踪能力发布流水线剩余阶段的简要视图。根据对用户有意义的结果推导，而不是镜像所有十个步骤或暴露内部门控。在调用子技能之前，替换或清除 LFG 的视图，以便仅显示子技能的任务表面；子技能返回后，在调用下一个子技能之前重新创建或刷新 LFG 的剩余流水线工作。仅在其门控触发时添加条件性工作。如果没有可用的任务跟踪能力，则正常继续，不要在聊天中模拟任务列表。

产物根目录

此流水线将计划记录在 <root>/plans/ 下，审查残留记录在 <root>/residual-review-findings/ 下。在首次组合 <root>/ 路径时（根据下面的块）解析 <root>，绝不要在此之前。写入 <root>/... 和读取 <root>/solutions/ 都算作组合 <root>/ 路径，因此任一操作都会触发解析；只有完全不触及 <root>/ 路径的运行——仅限临时或无仓库流程——才会跳过解析。

<!-- ce-docs-root:start -->
在组合任何产物路径之前，解析 CE 产物根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.local.yaml 中的 docs_root，然后是 config.yaml；第一个非空值获胜（<repo-root> = git rev-parse --show-toplevel）。未设置 -> <root> 为 docs，与之前完全相同。
• 验证设置的值：一个仓库相对目录，其真实路径（解析符号链接后）必须位于仓库内部，且既不是仓库根目录也不在 .git/ 下。否则停止并报错，指出 docs_root 和该值——绝不回退到 docs。
• 使用 <root> 作为唯一的产物位置：如果不存在则创建，将每个路径组合为 <root>/<subdir> 并包含此技能自己的子目录，并且绝不读取 docs。
  <!-- ce-docs-root:end -->

每阶段路由载体

在步骤 1 之前，解释调用对话是否表达了将流水线阶段——规划或实现——分配给特定模型或工具的语义意图。这是判断，而不是关键词或提示词匹配：明确的指令如“用 fable 规划”或“使用 Codex 实现”会创建分配，而在功能内容、引用材料、比较文本或文件名中单纯提及 Codex、Composer、Fable 或其他模型/工具则不会。两个流水线阶段是可路由的，每个都有自己的载体：

• 规划 路由到 ce-plan，作为 plan_model:<alias> 载体——规划作者模型（模型提升），仅限模型。示例别名：fable、opus。规划没有跨工具引擎：将工具范围限定到规划的分配（“用 codex 规划”、“在 cursor 上规划”）不受支持——将其作为路由载体阻塞问题提出，而不是将工具名称编码为 plan_model:<harness>，因为 ce-plan 无法处理该载体，并且会静默回退到会话模型。只有实现阶段可以路由到不同的工具。
• 实现 路由到 ce-work，作为 implementation_engine 对象（语法如下）——作者工具/模型。

按范围解析每个指令：

1. 限定范围的指令——指令命名了阶段（“用 fable 规划”、“用 codex 实现”、“规划用 fable，实现用 codex”）。将其路由到该阶段的载体。多个限定范围的指令可以同时解析，每个指向自己的阶段。
2. 未限定范围的指令——裸模型/工具分配，未命名阶段（“使用 fable”、“用 codex”）。将其绑定到仅实现阶段；绝不将未限定范围的指令扩展到规划或每个阶段。在步骤 1 之前的 LFG 开场行中披露已解析的绑定（例如“将实现路由到 Codex；规划保留在会话模型上。”）。
3. 未限定范围且确实存在歧义，且有人类在场——当未限定范围的指令可能合理属于多个阶段，且错误绑定会造成重大损失，并且宿主是交互式的（暴露了阻塞问题工具且不是 disable-model-invocation/无头运行），则在步骤 1 之前提出一个预先问题来绑定阶段，然后继续无干预。在 disable-model-invocation/无头运行中，绝不提问——应用实现默认值并披露。默认路径是强制性的：LFG 从调度器、循环和嵌套编排器运行，没有用户可回答，因此未解决的指令必须始终回退到已披露的默认值，而不是阻塞。

需求强度从整个指令推断，而不是单个词：“使用 Codex 实现”是偏好强度（prefer）；“仅使用 Composer 实现”是需求强度（require），因为其含义拒绝原生回退。

实现载体语法。 当实现解析为一个候选时，保留一个临时的 implementation_engine 对象，包含以下四个字段：

• mode：prefer 或 require
• target：恰好是 codex、claude、grok、cursor 或 composer 之一——工具名称，绝不是模型名称
• model：显式模型固定，否则为 null
• source：调用者可查看的来源，标识当前 LFG 指令

一个命名了裸模型而没有工具的指令（例如“使用 fable”、“用 opus”）是模型固定，而不是目标：将其编码为服务于该模型系列的工具，并在 model 中使用别名——Claude 系列模型（fable、opus、sonnet、haiku）为 {"target":"claude","model":"<alias>"}。绝不要将模型名称放在 target 中；如果你无法将命名模型映射到五个工具之一，那是路由载体阻塞问题，而不是静默丢弃用户指令的 null 绑定。

当实现指令改为命名有序回退列表时，不要将其截断为标量载体——保留整个有序分配作为当前任务的实现意图，并且不传递 implementation_engine: 对象。在 CE Work 接口处，该仍然活跃的当前任务分配优先级高于配置，并按顺序进行标准化/预检。这是阶段范围上下文，而不是计划内容；如果宿主无法在其技能调用之间保留该上下文，则停止并报告路由载体阻塞问题，而不是静默丢弃后续候选。

清理产品输入。 从进入规划的功能请求中移除所有路由指令，保持请求其他部分不变。绝不要将 implementation_engine 对象或任何移除的指令传递给 ce-plan、ce-doc-review、ce-code-review、已定决策简报或任何规划或审查产品输入——载体是阶段范围的路由权限，而不是产品内容或已定产品决策。plan_model:<alias> 载体是唯一的例外：它是结构化的路由数据，与清理后的请求一起传递给 ce-plan——绝不嵌入其中。不要在此处从静态配置构造载体：当某个阶段没有显式绑定时，ce-work 和 ce-plan 负责解析仍然适用的会话/项目意图和静态的每次检出配置。

1. 使用上面准备好的清理后的功能请求（或当没有路由指令时，你被调用时未更改的参数）调用 ce-plan 技能。当规划阶段指令已解析时，在其调用前加上 plan_model:<alias> 载体——与请求并列的结构化路由数据，绝不嵌入其中——这样即使在线模式，ce-plan 的模型提升也能在所选模型上编写计划。

   在调用之前，从调用对话中编写一个已定决策简报，并与这些参数一起传递：方向（1-2 行）；已定决策，每个包含四个必需字段——决策、其来源类别（user-directed 或 user-approved）、被拒绝的替代方案以及一行理由；开放领域；以及一个常设的报告冲突行。如果某个条目的被拒绝替代方案无法陈述，则降级为指令或开放领域。按主题限定范围——仅关于正在交付的功能的决策；如有疑问，则降级（重新讨论是安全的底线；引入过时的结算则不是）。如果对话中没有已定决策，则完全跳过编写，并如上所述直接调用 ce-plan——无需空简报仪式。简报是临时的：一旦 ce-plan 写入计划，计划中标记的 KTD 即为权威。

   门控：停止。如果 ce-plan 报告任务是非软件的且无法在线模式下处理，则停止流水线并通知用户 LFG 需要软件任务。如果 ce-plan 返回包含 settled-decision-invalidated 的阻塞报告，则停止流水线并通知用户原因——不要重试。否则，验证 ce-plan 工作流是否在 <root>/plans/ 下创建了计划文件。如果没有创建计划文件，则使用相同的参数再次调用 ce-plan。重试时直接使用已编写的简报——绝不重新编写。在存在书面计划之前，不要继续执行步骤 2。记录计划文件路径——它将传递给步骤 2 的 ce-work 和步骤 4 的 ce-code-review。

   在继续之前读取计划元数据。如果计划具有 artifact_contract: ce-unified-plan/v1，则仅当其具有 artifact_readiness: implementation-ready 和 execution: code 时才继续。对于 artifact_readiness: requirements-only、任何无法识别的 readiness 值、execution: knowledge-work、方法计划输出、寻求答案/通用输出或无效的类似进度的 readiness 值，停止流水线。LFG 从不直接启动 /goal；当目标模式或动态工作流适当时，ce-work 拥有该实现引擎的选择，并且必须随后将控制权返回给 LFG。

2. 当不存在标量临时载体时，包括当保留的有序当前任务分配仍在上下文中活跃时，使用 mode:return-to-caller <plan-path-from-step-1> 调用 ce-work 技能。当标量载体存在时，使用确切的字符串形式 mode:return-to-caller implementation_engine:<compact-json> <plan-path-from-step-1>。

   如果标量临时载体存在，将其确切的 implementation_engine.{mode,target,model,source} 数据序列化为紧凑 JSON，紧跟在 implementation_engine: 前缀之后（例如 implementation_engine:{"mode":"prefer","target":"codex","model":null,"source":"lfg-current-turn"}）。这是可移植字符串信封中的结构化调用者数据，不是计划路径或实现提示的一部分。当不存在时，不要传递空载体。ce-work 然后解析保留的有序当前任务分配（如果存在），否则解析适用的会话/项目意图和静态的每次检出配置。LFG 是自动的无头调用者：它从不提示削弱需求强度路由。

   可选的 implementation_run:<safe-id> 载体仅用于恢复。绝不要在初始步骤 2 调用中包含它。在下面的一次证据协调恢复中，将其放在相同的引擎载体之后（如果存在）和未更改的计划路径之前：mode:return-to-caller implementation_run:<safe-id> <plan-path-from-step-1> 或 mode:return-to-caller implementation_engine:<compact-json> implementation_run:<safe-id> <plan-path-from-step-1>。安全 ID 匹配 ^[A-Za-z0-9._-]{1,128}$ 并包含至少一个非句点字符。拒绝格式错误或重复的运行/引擎载体，而不是启动工作。

   门控：停止。在继续之前读取结构化返回。status: blocked 或 status: failed 返回会停止流水线。特别是，不可用的 require 路由不得提示、回退或启动原生工作。完成的 prefer 回退可以继续到步骤 3，但仅一次，并在向用户突出披露其请求与实际路由/模型以及 fallback_reason 之后；回退不是再次调用实现的理由。

   对于 status: complete，验证实现工作已执行——文件已创建或修改，超出计划。需要相同的计划路径、更改的文件、尝试/完成的 U-ID（如果存在）、验证结果、行为变更信号以及 standalone_shipping_skipped: true。还需要路由感知的收据字段 implementation_engine_binding、requested_route、actual_route、requested_model、actual_model、fallback_reason、run_id、unit_receipts、plan_checkpoint、blockers 和 recovery_path。即使原生执行使某些值为 null，这些字段也是必需的；它们一起携带绑定来源、请求与实际身份、回退、持久运行、每个单元的过程/集成/验证/提交状态、检查点披露、阻塞和恢复。恢复返回必须携带相同的 run_id；绝不要将恢复视为启动新单元或第二个 LFG 尾部的许可。

   当 behavior_change: true 时，还需要 verification_evidence，其中命名相关的单元/任务、检查的现有测试、添加/更改或未更改的测试、适用的红色失败或表征证据、验证运行以及任何故意的测试例外。不要在 LFG 内部决定测试策略；证据是 ce-work 的契约。还要从返回中读取 settled_decision_conflicts：阻塞路由的条目以 status: blocked 到达并停止流水线；记录任何已继续并标记的条目——它们必须到达步骤 6 的持久残留记录和步骤 8 的 PR 描述上下文，因为后续审查可能不会重新发现它们。

   如果 behavior_change: true 但 verification_evidence 缺失或过于模糊，无法判断行为如何被保护，则再调用一次 ce-work 进入恢复模式。如果存在，则重用相同的 implementation_engine:<compact-json> 载体，并保持相同的计划路径。使用安全的非空 run_id，添加 implementation_run:<safe-id>，其值来自第一次返回。当 actual_route 为 native 且 run_id 为 null 时，重复原始 ce-work 调用一次，不带 implementation_run: 载体；这保留了预先存在的原生幂等性/证据协调路径。没有安全运行 ID 的非原生返回保持阻塞，而不是尝试发现或第二次实现。不要提示用户，也不要更改计划路径或引擎载体；这是证据协调，而不是新的调度。恢复依赖于 ce-work 的协调路径来检查已实现的工作，填充缺失的证据，并返回而不重新实现。如果第二次返回仍然缺乏连贯的验证证据，则停止为阻塞并报告缺失字段，而不是继续简化/审查/交付。

3. 对分支差异调用 ce-simplify-code 技能。

   这在审查之前运行，以便步骤 4 的代码审查覆盖简化后的代码。当变更是纯文档（仅更改了 markdown/文档路径）或微不足道（大约少于 10 行更改）时，跳过此步骤。否则让 ce-simplify-code 自行解析分支差异范围；它保留行为并运行测试套件。传递步骤 1 的计划路径作为结构固定上下文，而不是作为简化范围（分支差异仍然是范围），并带有一行约束：session-settled: 标记的 KTD 是简化必须保留的结构固定（故意重复保持重复）。

   不要在此步骤提交。ce-simplify-code 将其更改留在工作树中；步骤 4 的审查范围包括工作树（包括未提交的更改），步骤 8 的 ce-commit-push-pr 提交剩余的所有内容。在此处提交会将任何仍未提交的 ce-work 编辑扫入误导性的 refactor 提交，并可能卡在从未变干净的树上。

4. 使用 mode:agent plan:<plan-path-from-step-1> 调用 ce-code-review 技能。

   传递步骤 1 的计划文件路径，以便 ce-code-review 可以验证需求完整性。读取技能发出的可操作发现摘要。还要读取任何标记为 settled_conflict 的发现（每个都命名冲突的 KTD）。标记的发现，其证据是无效的——已定决策不可行：不可行、错误或破坏性——会停止流水线为阻塞，并报告发现，在交付前提条件之前。标记的偏好级发现继续（仅报告），但必须流入步骤 6 的残留记录。

   mode:agent 是仅报告的——它呈现发现但从不编辑树；LFG 在步骤 5 中应用符合条件的发现。在向用户叙述进度时，将其描述为“审查发现 X → 在步骤 5 中应用 X”，而不是“代码审查未自动修复”。仅报告审查后跟 LFG 应用的修复是预期的契约，而不是差距。

交付前提条件（步骤 5–9）。 在交付步骤之前运行一次 git remote。如果它列出没有远程（例如，沙箱/一次性检出，有 git init 但没有 origin），则交付是仅本地的：执行下面步骤要求的所有提交，但跳过每个推送、PR 创建/编辑和 CI 监控操作——步骤 5 和 6 中的推送，步骤 8 中的推送和 PR 创建，以及完整的步骤 9。缺少远程是终端仅本地状态，而不是错误：绝不要重试推送或寻找远程——进行本地提交并继续到步骤 10。当远程存在时，正常执行步骤 5–9。

5. 应用并持久化审查修复（步骤 4 后必需，在残留交接之前）

   加载 references/review-followup.md 并执行其应用步骤（机械应用 + 当更改存在时提交/推送）。在符合条件的审查修复仅留在工作树中未提交时，不要继续到残留交接、运行浏览器测试或输出 DONE。

6. 自主残留交接（仅当步骤 4 报告了一个或多个可操作的 downstream-resolver 发现，且未在步骤 5 中应用时；当报告 Actionable findings: none. 时跳过）

   不要提示用户。此步骤拥抱自动驾驶契约：残留必须在 DONE 之前变得持久，但代理从不停止询问。当步骤 4 发出了任何 settled_conflict 标记的发现，或步骤 2 的返回携带了已继续并标记的 settled_decision_conflicts 条目时，也要运行此步骤——两者都在应用路径之外，但它们是分歧类，必须在此处变得持久。

   1. 以非交互模式加载 references/tracker-defer.md。传递步骤 4/5 中的残留可操作发现（或当摘要被截断时的运行产物）。
   2. 收集结构化返回：{ filed: [...], failed: [...], no_sink: [...] }。
   3. 从结构化返回编写一个 ## Residual Review Findings markdown 部分（这进入步骤 4 中提交的记录文件，不是 PR 正文）：
      • 对于 filed 中的每个项目：一个带有严重性、文件:行、标题和跟踪工单 URL 链接的要点。
      • 对于 failed 中的每个项目：一个带有严重性、文件:行、标题和失败原因（例如 Defer failed: gh returned 401 — tracker unavailable）的要点。
      • 对于 no_sink 中的每个项目：一个带有严重性、文件:行和标题的要点，直接内联，以便提交的记录文件是持久记录。
      • 对于步骤 4 中每个 settled_conflict 标记的发现：一个带有严重性、文件:行、标题和标记命名的冲突 KTD 的要点——即使发现是仅报告的，也要包含。
      • 对于步骤 2 中每个已继续并标记的 settled_decision_conflicts 条目：一个带有 KTD、证据以及如何路由的要点。
   4. 持久记录——绝不是 PR 正文。 不要将 ## Residual Review Findings 部分写入 PR 描述；它会重复 GitHub 自己的跟踪，并在项目解决时变得过时。审查残留没有自己的 GitHub 线程，因此它们通过步骤 2 中提交的跟踪工单加上一个提交的记录文件变得持久——而不是 PR 正文部分或重复工单的 PR 评论。创建/替换 <root>/residual-review-findings/<branch-or-head-sha>.md，包含编写的部分（包括工单链接）和源运行上下文。仅暂存该文件，提交 docs(review): record residual review findings，并在配置了远程时推送（根据交付前提条件）：如果存在上游，则 git push；否则如果存在远程，则解析一个可写的远程（优先 origin，否则第一个配置的远程）并 git push --set-upstream <remote> HEAD；如果根本没有远程，则本地提交是持久接收器。

   在残留变得持久（跟踪工单已提交和/或记录文件已提交）之前，不要输出 DONE。一旦记录文件存在，绝不要让 DONE 阻塞在跟踪工单提交失败上。当远程存在时，推送失败是停止并报告；当没有远程时，绝不要重试推送或阻塞 DONE。

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

8. 使用 mode:pipeline branding:on 调用 ce-commit-push-pr 技能。将步骤 1 中记录的计划路径以及步骤 2 中任何已继续并标记的 settled_decision_conflicts 条目线程化到调用中，以便 PR 正文的已定决策来源行及其在标记下继续的条款可以触发。

   这会提交任何剩余的更改，推送分支，并创建拉取请求——根据模式令牌，非交互式。如果它在 PR URL 之后打印了 New concepts: 尾部，则记录概念名称以供步骤 10 使用。一旦 PR URL 已知，将其回填到步骤 6 中提交的任何残留工单中（filed 列表），以便每个工单链接到携带该发现的 PR——尽力而为，绝不要让 DONE 阻塞在失败的工单更新上。如果步骤 6 已经创建了 PR（使用 gh pr view --json number,url,state 2>/dev/null 检查），则跳过 PR 创建，但仍然提交并推送任何未提交的更改。根据交付前提条件，当没有配置远程时，不要调用 ce-commit-push-pr——其提交步骤无条件推送（git push -u origin HEAD），因此字面调用仍会命中不可能的推送。相反，在本地自行提交任何剩余的更改（git add -A && git commit），并完全跳过推送和 PR 创建。

9. 通过 ce-babysit-pr 监控 PR 直至 CI 决定（仅当当前分支存在开放的 PR 时）

   检测 PR；如果不存在或 gh 不可用，则完全跳过此步骤并继续到步骤 10。

   gh pr view --json number,url,state
   

   调用 ce-babysit-pr mode:pipeline <pr-url>。它运行有界流水线循环：监控 CI，通过 ce-debug mode:pipeline 修复真实的（收敛的）失败——绝不削弱、跳过或模拟断言——解决通过 ce-resolve-pr-feedback mode:pipeline 到达的任何审查评论，并在 CI 决定或其预算（默认 3 轮修复）达到时停止。这取代了 LFG 以前手写的 CI 循环；不要在此处重新实现 CI 监控。每当存在开放的 PR 时无条件调用它——看起来可能干净的 CI 运行不是跳过 babysit 并自己轮询 gh pr checks 的理由。某一时刻的绿色 CI 不是此步骤的目标：babysit 还会在 PR 的生命周期内解决审查评论，因此当咨询性检查（例如 Bugbot）仍在等待或评论未处理时，通过的检查不是“完成”，也绝不能替代调用。

   收集其结构化结果（{ status, fixes_applied, residuals }）。它将无法修复的 CI 作为运行报告评论呈现在 PR 上，并返回残留——不要编写 ## CI Failures Unresolved PR 正文部分。needs-human 残留（需要产品/设计决策的修复）被推迟，而不是应用——这是自动驾驶契约，未更改。一旦 babysit 呈现了残留，不要阻塞 DONE。

10. 完成后输出 <promise>DONE</promise>

    对于下面的两个用户可运行交接，默认使用 /ce-explain <name> / /ce-babysit-pr <pr-url>。仅当活动宿主是 Codex 或明确记录了美元前缀技能调用时，才使用 $ce-explain <name> / $ce-babysit-pr <pr-url>。仅将调用渲染为内联代码，并仅输出一种形式。

    如果步骤 8 记录了 New concepts: 尾部，则首先为每个概念输出一行：New concept introduced: <name> — run <rendered ce-explain invocation> to go deeper.

    如果存在开放的 PR，则添加一行，引导用户进行交互式监控直至合并（流水线模式在“CI 决定”时停止，而不是“已合并”）：PR is moving — run <rendered ce-babysit-pr invocation> to watch it through review to merge.

    在 DONE 承诺之前，检查步骤 1 中的规范计划，查找语义角色 work-relationships。当该角色存在时，加载 references/next-work-handoff.md；或者当较旧的未标记产品契约似乎命名了此计划拥有的领域以及未来单独计划的领域及其关系时，也加载；该引用拥有谨慎的遗留语义回退、候选选择和选择加入提供契约。不要匹配确切可见的标题，不要将普通的非目标视为未来工作，也不要在用户明确接受提供之前调用 ce-handoff。如果两个语义信号都不存在，则不要加载引用，也不要做下一步工作提供。

    然后输出 DONE 承诺。

现在从步骤 1 开始。记住：先规划，再工作。绝不跳过规划。