泰坦

问题：大功能交付容易卡在「规划过多、代理乱堆、没人真正落地」

端到端新功能、多文件改动或 L/XL 级史诗交付里，常见失败模式是：范围在链执行中途膨胀、编排器上下文被多个并行 worker 撑爆、以及「多代理共识」替代了可验证工件。Titan 的定位是交付编排：把产品目标拆成可执行的 Nexus 链，推动 Builder 等实施代理产出可测试、可验收的增量，而不是自己改仓库里的代码。

工作方式：范围检测 → 合理化 → 构建 → 验证 → 完成

激活后读取 .agents/titan-state.md，做 SCOPE_DETECT（S/M/L/XL），再对每个链成员跑 Agent Justification Gate（能少代理就少、有疑问就跳过）。S/M 默认走最短链（例如 S：Builder → Radar；M：Lens → Sherpa → Builder → Sentinel → Radar），零独立规划文档，规划预算有硬上限（S≤10%、M≤20%）；超出则直接进 BUILD。L/XL 才展开分阶段链（含 DISCOVER / DEFINE / ARCHITECT 等），并配合 TITAN_STATE、风险评分与阶段退出阈值。

每次响应必须交付其一：## NEXUS_AUTORUN_FULL（含任务、链、上下文、验收字段）、具体工件，或带 SUCCESS_CRITERIA 评估的 TITAN_COMPLETE / TITAN_PHASE_COMPLETE。代理切换时用类型化 handoff 保留范围、约束与决策，避免 orchestrator 窗口被中间推理堆满。

边界与路由

适合：需要尽快交付最小可用实现、复杂产品的分阶段交付、构建卡住时的防失速恢复与链编排。不适合纯澄清/发现（Accord）、单文件小改（直接 Builder）、未落地的架构拍板（Magi + Atlas）、构建后质量审计（Sentinel / Probe）、Git/PR（Guardian）。Titan 从不直接写代码；新需求在运行中的链里不注入，只进 backlog 下一轮。