四技能调度中枢

解决什么问题

当你需要把一个复杂需求从架构设计推进到可执行规划再到实际落地时，常见的失败模式是：谁来协调、谁在哪个阶段该介入、产出物质量谁来把关全部含糊不清。工程师在 TOGAF 里做了架构，又在 Loop 里重新解构需求，中间靠口头确认，最后发现 Graph 执行的任务和当初的架构决策对不上。

x-rw-orchestrator-c0 的定位就是调度中枢：它不写架构文档、不拆任务、不跑 DAG，只负责让四阶段流水线按固定顺序走完，并在每个节点做产出物检查和人工审批。

它如何工作

核心是一条不可跳过的四阶流水线：

• PRE_ANALYSIS — 先加载 LoopEngineering O2，以审计模式对用户原始指令做多轮澄清分析，产出结构化输入材料
• TOGAF_RUN — 把 O2 的材料（而非原始需求）喂给 TOGAF，完成 L1–L5 分层分析，重点产出 AI 消费子集
• G1_WAIT — 架构门禁，人工审批 TOGAF 产出，通过才放行
• LOOP_RUN → G2_WAIT → GRAPH_RUN — 规划、规划门禁、DAG 执行，每一步同样有 check_output 产出物校验

三个硬性约定值得单独说：

1. 不允许绕过流水线 — 哪怕看起来只是"问个架构问题"，只要调用了 C0，就必须走完 O2→L1→O2→G3
2. L1 之前必须 O2 前置分析 — 原始需求不能直接丢给 TOGAF
3. 结束时必须输出调用链路总结 — Mermaid 流程图加每个 Skill 的输入产出摘要，保证可追溯

异常处理按四级响应：L0 节点自愈重试、L1 反思、L2 跨层会诊进入 REVIEW_MODE、L3 熔断转 SAFE_MODE 通知人工介入。小循环（G3 内部）和大循环（跨层）都有次数上限，超限强制进入 SHUTDOWN，避免死循环。

适用边界

• 只适合复杂任务。简单问题用这套流程会明显偏重，文档写满 L1–L5 加七项实现层产物的成本远大于收益。
• 人在环路未被移除，但审批负担不轻。G1/G2 必须人工输入审批人姓名才通过，留空即驳回；这是设计上的约束，不是配置项。
• Python 3.8+ 是完整体验的前提。没有 Python 时流水线仍可用纯自然语言推进，但 state.json 和 call_chain.json 需要手动编辑。
• 运行时依赖另外三个 Skill（TOGAF、LoopEngineering、GraphEngineering）就绪，C0 本身不包含它们的实现。