用途
cc10x-router 是 CC10X 的唯一入口点，负责处理构建、调试、审查与规划请求。它作为运行时契约存在，执行“信任优先”的编排流程：路由意图、恢复工作流状态、写入工作流产物、执行任务图、验证代理输出，并在出现歧义、跳过工作或缺少持久化时按失败关闭（fail closed）处理。
意图路由
技能依据首个匹配的信号进行路由，优先级如下：
- ERROR（关键词：error、bug、fix、broken、crash、fail、debug、troubleshoot、issue）→ DEBUG 工作流，链路为 bug-investigator -> code-reviewer -> integration-verifier。
- PLAN（关键词：plan、design、architect、roadmap、strategy、spec、brainstorm）→ PLAN 工作流，链路为 brainstorming -> planner -> bounded fresh review loop。
- REVIEW（关键词：review、audit、analyze、assess、"is this good"）→ REVIEW 工作流，链路为 code-reviewer。
- ORIENT（关键词：zoom out、explain、understand、"how does X work"、unfamiliar、"map this"、"walk me through"、"where is"、"what does this do"）→ 咨询式定位（不创建代理）。
- DEFAULT（其他一切）→ BUILD 工作流，链路为 component-builder -> [code-reviewer...]。
规则：ERROR 始终优先于 BUILD；REVIEW 仅为咨询性质，绝不创建改代码的任务；ORIENT 为只读咨询，先于 DEFAULT/BUILD，不创建写入代理和阶段图。BUILD 使用复杂度梯度，简单范围走精简的 builder -> verifier -> memory 图，其余及所有已规划工作走完整的 builder -> [reviewer || hunter] -> verifier -> doc-sync -> memory 链。执行前需输出一行：-> {WORKFLOW} workflow (signals: {matched keywords})。
ORIENT 移动（只读）
当用户想理解现有代码而非修改时触发。路由器内联回答，不创建 TaskCreate、不写工作流产物、不生成阶段图、不启用写入代理。步骤包括：映射相关模块/文件；通过 LSP 调用层级与引用向上追踪一层；用项目自身的词汇解释；止步于理解，不提议或应用修改。若明显隐含变更，结尾可建议重新路由（BUILD/DEBUG/PLAN），但不直接开始。
记忆加载与模板校验
路由或恢复前始终执行：创建 .cc10x 目录，读取 activeContext.md、patterns.md、progress.md。若记忆文件缺失，使用 cc10x:session-memory 模板创建并读取。各文件需含指定章节（如 activeContext.md 的 ## Current Focus 等）。自动修复规则：在 ## Last Updated 之前插入缺失章节，每次 Edit 后立即 Read 验证。JUST_GO 机制：若 Session Settings 中 AUTO_PROCEED 为 true，则设为 JUST_GO，自动将非 REVERT 的 AskUserQuestion 门默认到推荐选项并记录日志；但 JUST_GO 绝不覆盖用户/项目标准、开放计划决策或失败停止门。
工作流产物与钩子策略
持久化路由器状态位于 .cc10x/workflows/{workflow_uuid}.json，事件日志位于 .cc10x/workflows/{workflow_uuid}.events.jsonl。路由器拥有的门包括 plan_trust_gate、phase_exit_gate、failure_stop_gate、memory_sync_gate、skill_precedence_gate。在创建工作流、修改产物、更改钩子策略或依赖产物字段恢复前，必须读取 references/workflow-artifact-and-hook-policy.md。
任务元数据契约
每个 CC10X 任务描述以规范化元数据行开头，包括 wf、kind、origin、phase、plan、scope、reason。其中 wf 为必填，承载生成的 workflow_uuid（wf-<ts>-<hex>），不使用 PENDING_SELF；kind 为必填，驱动恢复、路由与计数；origin 在每个 kind:remfix 任务上必填；plan 在 workflow、agent、reverify、memory 任务上必填；reason 在修复与研究任务上必填。
恢复与补水
记忆加载后执行 TaskList()。补水规则包括：按主题前缀查找活跃父工作流任务；若存在多个活跃工作流，按当前对话与匹配的 wf 标记限定范围，无法确定范围则不恢复；通过 wf + kind + phase 从 TaskList() 和 TaskGet() 重建可运行任务，不依赖存储的任务 ID。仅读写 .cc10x/ 状态命名空间，忽略旧的版本分段布局。范围决策恢复：检查活跃上下文中是否存在 [SCOPE-DECISION-PENDING: wf:{...}] 标记，若存在则将用户回复视为该待决范围门的答案。安全规则涵盖共享任务列表的范围限定、带阻塞的在途任务处理、无阻塞在途任务的询问处理，以及旧版任务的询问处理。
工作流准备
共享准备：读取 activeContext.md 的 References 与 Decisions，读取 progress.md 的当前工作流与任务，读取最新的工作流产物。意图就绪门（PLAN 或 BUILD 前必执行）要求意图契约满足：上下文可界定、无矛盾、足够具体。路由器拥有的接口字段包括 plan_mode、verification_rigor、checkpoint_type、proof_status。BUILD/DEBUG/REVIEW/PLAN 准备前需分别读取对应的 references 文件并以其规范块为准。
工作流任务图
父工作流创建：在 TaskCreate() 前生成稳定 workflow_uuid（"wf-" + UTC 时间戳 + 8 位十六进制），用该 UUID 创建父任务，立即创建产物与事件日志（复制规范骨架后替换占位符），写入事件日志，并在任何子任务创建前执行强制回读门（确认 JSON 可解析、UUID 匹配、无残留占位符）。仅在产物存在且回读通过后才创建子任务。BUILD/DEBUG/REVIEW/PLAN 任务图分别应用对应 references 文件中的规范块。研究任务在明确触发时读取 references/remediation-and-research.md。标记规则：BUILD 写 [BUILD-START: wf:{workflow_uuid}]，DEBUG 写 [DEBUG-RESET: wf:{workflow_uuid}]。