规划与执行

家族概览

本族处于实施边界。ce-plan 产出可被 worker 拿来执行的产物；ce-doc-review 在提交前证明它；ce-work 实施它；ce-worktree 在必要时隔离工作区。

ce-plan

目的：设计 HOW 如何构建。三种输出契约（Phase 0.6）：Direct / Chat brief / Durable。不确定时取更重的那种。

Durable 是强制的

当满足以下任一条件：无头 / 流水线 / 用户要求“plan” / “plan file” / “output format” / 续接既有计划条目 / 风险面（认证、支付、迁移、外部契约）。

5 个阶段

Phase 5.3.8 — 文档审查关

强制：调用 ce-doc-review mode:non-interactive <plan-path>。即便在流水线模式下也不例外。若不可用，记录一条结构化的占位结果，含 skipped_reason: skill_unreachable。审查结果以结果文件的路径返回，不把结果正文粘进对话；由调用方按需读文件。

Phase 5.4 菜单

仅交互模式；流水线返回结构化审查结果并停止。5 个选项：启动 ce-work（推荐） / 处理审查的待办项 / 原型化一个仍待感受的问题 / 创建 Issue / 在浏览器中打开（仅 HTML）。通用规划 / 求答 / 仅需求类产物跳过执行选项。

References（19 文件、14 个代理、约 4,900 行 — 最大技能）

包含与 ce-brainstorm + ce-ideate 共享的 html-rendering.md（638 行）与 markdown-rendering.md（242 行）；与 ce-brainstorm 共享的 settled-decisions.md（45 字节，受一致性校验保护）。approach-altitude.md 用于“计划的计划”流。deepening-workflow.md 用于信心检查深化。reasoning-elevation.md 用于 5.3.7 处的模型提升边界。publishing.md 用于发布副本——只投用户点名的发布方，本地文件仍是记录。

ce-doc-review

目的：对计划/规格的多人格审查。始终运行 coherence-reviewer + feasibility-reviewer。可选运行 adversarial / product-lens / security-lens。

阶段

1. 获取并分类文档（先在磁盘上核实）。
2. 宣布本次评审团队（简短、各条件人格给一句理由），然后保持安静直到结果齐；分派时把各自的人格文件路径交给它。
3. 若有 trio 人格触发，进行跨模型判断。
4. 综合 +（编排器在授权范围内应用修正）。
5. 走查与交接（交互式）或结构化返回（非交互式）。交互式走查 = 路由问题 + 逐条发现走查 + 完成报告；批量预览只服务走查里的自动处置。

8 个人格

coherence-reviewer · feasibility-reviewer · adversarial-document-reviewer · product-lens-reviewer · security-lens-reviewer · design-lens-reviewer · scope-guardian-reviewer · whole-doc-reviewer（仅跨模型）。scope-guardian-reviewer 的机制定尺双向生效：既建议把没人要求的机制挪进「考虑过但不构建」清单，也改判「被计划收窄的请求行为」——对请求所要求部分的延迟、门控、封顶或跳过，除非满足可论证的危害条件，否则建议按请求原样规划。

References（15 文件、8 个人格、1 个 schema）

• references/document-intake.md（44）
• references/dispatch.md（52）
• references/persona-selection.md（41）
• references/cross-model-review.md（198）— 累加式，不阻塞
• references/synthesis-and-presentation.md（343）
• references/walkthrough.md（347）— 仅交互
• references/bulk-preview.md（146）— 仅交互
• references/open-questions-defer.md（158）
• references/rendering-floor.md（175）— 跨场景共享
• references/findings-schema.json（85）— JSON schema

脚本：scripts/cross-model-doc-review.sh（1,086 行）— 跨模型评审的 peer 统一经被钉住的 acpx@0.19.5 传输路由，文档已嵌入提示、peer 不再从磁盘重读。

ce-work

目的：端到端执行计划。独立模式：实施 + 验证 + 发布收尾。返回调用者模式：仅实施 + 验证；调用者（lfg）负责发布。

阶段

硬约束

• 独立模式：在 commit/push 时，必须先有真实的 ce-code-review 回执。没有它，运行未完成。
• 返回调用者模式：永远不做 simplify / review / PR / babysit。这些归调用者。
• 平凡路径 = 1-2 个文件 + 无行为变更 → 跳过任务列表（仍先解决引擎）。
• 提交范围：每个实施提交只声明自己的文件。禁止 git add -A / .。禁止裸 git commit。
• 提交与 worker 纪律：commit 消息按 incremental 风格约束——能写出描述一次完整、有价值变更的消息才提交，会是 “WIP / partial” 就等；外部 worker 的 reasoning_effort 由配置决定。
• 计划 ID 不写进产物：U- / R- / A- / F- / AE- / KTD- 这类 ID 只对拿着计划的人有意义；代码、注释、文档、脚本、技能里都不要写它们，改成写需求/决策本身在说什么。

返回调用者 schema（必填字段全列）

status（complete/blocked/failed）、plan_path、changed_files、u_ids_attempted、u_ids_completed、verification_results、verification_evidence、implementation_engine_binding、requested_route、actual_route、requested_model、actual_model、fallback_reason、run_id、source_kind、source_digest、unit_receipts、plan_checkpoint、blockers、recovery_path、settled_decision_conflicts、behavior_change、standalone_shipping_skipped: true。

引擎（4 种）

• Native — 编排器自己的上下文。平凡工作的默认。
• Cross-model inline mode — 经由 scripts/cross-model-work.sh（1,150 行）的 CodeX / claude / grok。
• Cross-model dynamic workflow — 用于需要定制工作流形态的计划。
• 外部实施 worker — scripts/agents/implementation-worker.md。

References（15 文件、2 个代理）

• references/input-triage.md（50）
• references/workspace-setup.md（27）
• references/execution-engines.md（64）
• references/cross-model-execution.md（190）
• references/execution-strategy.md（71）
• references/implementation-loop.md（107）
• references/multi-pr-delivery.md — 多 PR 计划按 PR 组交付，提前构建、按合并顺序落地
• references/non-code-execution.md（23）
• references/return-to-caller.md（33）
• references/review-findings-followup.md（82）
• references/shipping-workflow.md（89）
• references/tracker-defer.md（150）— 与 lfg 共享
• references/work-intake.md（51）
• references/implementation-result-schema.json（52）

脚本：scripts/cross-model-work.sh（1,150 行，经被钉住的 acpx@0.19.5 传输路由 peer）、scripts/unit-workspace.py（215 行）+ 6 个库模块（约 4,590 行总计）、scripts/packs-resolve.py（解析项目声明的 Compound Packs）。

ce-worktree

目的：建立隔离的 git worktree — 为新工作创建新分支，或将 worktree 附加到既有引用。极简技能：仅有 SKILL.md，无 references/。

3 个步骤

1. 检测既有隔离 — 比较 git rev-parse --absolute-git-dir 与 (cd "$(git rev-parse --git-common-dir)" && pwd -P)；不同 = worktree（或 submodule）。submodule 视作非隔离。
2. 优先使用原生 worktree 工具 — 主机的 EnterWorktree、/worktree 或 --worktree 标志。永不 偷偷执行 git worktree add。
3. Git 兜底 — git worktree add -b <branch> .worktrees/<branch> origin/<from-branch>。分支名由工作描述派生；永不采用不透明名。

硬规则

• 一个分支，一个 worktree：若目标分支已在别处签出，不要 创建第二个；上报 "already checked out at <path>"，由调用者决定。
• PR worktree 陷阱：FETCH_HEAD 是 detached 的，会让 fix-loop 提交变孤儿。先用 git fetch origin pull/<n>/head:pr-<n>，再用 git worktree add .worktrees/pr-<n> pr-<n>。若要跟踪推送，使用 --detach + gh pr checkout <n>。
• .worktrees/：首先应加入 .gitignore。用 git check-ignore -q .worktrees/（带尾斜杠）探测。未忽略则加入 .gitignore。
• git worktree add 上的权限/沙箱错误：报告失败；提供 “在当前 checkout 中工作” 与 “停下并解决” 二选一。

跨技能边界