Intent

前置识别（优先于三问）

chat 子类标签（仅用于回答策略，不新增工作流）

当消息已命中 chat 时，进一步区分以下两类常见说明意图：

⚠️ 上述两个标签只是 chat 下的回答策略辅助标签，不是新的顶层工作流。 ⚠️ 面向用户的默认输出场景下，仍应优先用自然语言解释；仅在回答确有必要时才最小化展开内部细节。 ℹ️ 项目内 dev 模式下的规范优化、规则提升与实现讨论，不因这两个标签增加额外限制。

两项均为否 → 进入三问判断。

TaskContinuationIntentGate

任务名续接只把名称当定位键，不把名称、Hook 命中或派生索引当作状态真相。匹配顺序固定为 stable taskId → active displayName exact → active alias exact → completed/rejected exact；相似名称只返回最多 5 个建议，禁止 fuzzy 自动命中。resolved-active 后仍须按 task.json → sessions.md → 当前绑定产物/checkpoint 定向复水化并复证 CP digest；ambiguous / not-found / completed / rejected / stale-confirmation / scale-blocked 不得进入任务执行。

三问判断法

⛔ 意图识别基于用户消息的语义目的，不依赖关键词匹配。

先理解当前真实用户消息与已有任务，再通过 profile_context_plan 提交结构化结论：路由沿用 intent、routeKey、changeTypes；可选 semanticDecision 使用 IntentSemanticDecisionV1，其 sourceRef 必须引用当前可信入口的 envelopeId、envelopeDigest 与 contextEpoch。按实际意图填写 workflowPreference、workflowFacts、executionDecision、languageDecision，不能从昵称、中文字符占比、代码/引用或宿主问答包装推断这些字段。语言明确要求及持续偏好优先；临时回复语言使用 scope=turn，持续任务偏好使用 scope=task。宿主结构化问答只把 answer 作为用户回复，question 保留为上下文。模型选择明确指定的 Skill 时提交 explicitSkillId；精确引用或示例不自动激活 Skill。缺少必要信息时先定向读取，只有确实影响下一步的歧义才向用户询问。

三问结论：

• 任一指向变更 → 检查是否满足 self-fix 条件 → 满足则 self-fix；否则 dev 或 fix
• 三问全指向分析 → 区分 analyze vs audit

意图类型路由

验证的暂停、缩小范围或确认同样由模型解释，通过当前来源绑定的 semanticDecision.validationDecision 提交 action（none、revoke、confirm-current-budget）；确认可附 requestedBudgetDigest 与 declaredChangedPathCount。执行模式和验证范围是不同决定，不因回复出现“暂停”“确认”或 @ 别名自动变更。运行时继续校验验证卡、任务、项目、候选和单轮屏障。任务恢复使用既有 memory_task_resolve 的精确查询与恢复证据，不把自然语言的“继续……”直接当历史任务名。

项目现实扩展衔接

意图识别分两层输出：

1. 语义初判：仅基于用户消息和当前对话，判断用户最终目的。
2. 项目现实扩展后最终路由：在目标项目已确定、Profile 已加载后，结合项目技术栈、目录结构、当前需求/bug 产物、测试与发布约束，确认是否需要修正工作流或子类型。

约束：

• 项目未确定前，不得为了“扩展意图”发起超出当前明确文件范围的工作区扫描。
• 若项目现实扩展推翻语义初判，应在 PC1 中写清“语义初判 → 最终路由”的变化。
• 若扩展发现这是多项目或跨服务任务，应先标注边界与入口项目，再决定是否需要加载关联服务 profile。

Intent Expansion Card

非 chat 工作流在 CP1 / 问题确认前输出或写入可审查的 Intent Expansion Card，避免压缩恢复后只剩模糊摘要。

• dev 模式默认向用户展示完整 Card；prod、instruction-fallback 宿主或低风险轻任务可退化为 3~5 行摘要。
• 压缩恢复、resume 或用户明确要求“按文件真相重建”时，必须先按文件真相源重建 Card，再决定最终路由。
• 🔴 ProactiveBetterAlternativeGate 联动（PI-20260724-cp1-intent-expansion-proactive）：请求 CP1/CP2 确认前，须主动交付 Expansion 与更优/备选路线（含遗漏场景），不得等用户追问「还有没有更合理建议」才补。

DocsAudienceIntent（文档写作任务强制）

当用户意图涉及编写/改写 README、文档站、website docs、用户手册、contributing、API 参考或模糊「写文档」时：

1. 必须由模型根据用户目标、预期读者与现有文档判定 docsAudience + docsSurface；scripts/lib/docs-audience-intent.js 仅校验 DocsAudienceDecisionV1 的结构，不从文字或目录名判定受众。
2. 说明采用的受众；信息不足时先读取相关上下文，必要的消歧须给出有依据的推荐，不因缺少固定词自动阻断。
3. 路由：
   • public-user → user-manual-authoring（+ 条件 readme-authoring）
   • maintainer-dev → maintainer-docs-site-authoring
   • ambiguous → 补充上下文，仍无法确定且影响产物时再消歧
   • multi-audience → 按读者组织相应交付物，沿用用户已确认的任务范围
4. 完成前做受众漂移检查；失败不得宣称文档任务完成。
5. npm run test:docs-audience 只证明结构与摘要绑定；真实文档须经模型内容审查和实际用户路径验证。
6. 可读性、受众漂移等结论必须绑定当前正文摘要，包含理由与来源引用；没有 DocsContentReviewV1 的辅助函数结果为 unverified，不得冒充内容验收通过。

问题驱动场景延展（强制 · PI-20260724-proactive-scenario-extension）

当用户提出具体痛点/问题（文档看不懂、流程缺步、规范歧义、某种失败模式等），助手在正面回答之后，同一轮须主动延展 3+ 条相关场景或风险（表格或编号），不得只回一句就结束、等用户再问「还有没有其他场景」。

• 机器抽检：classifyProactiveScenarioExtensionSample(userMessage, assistantReply) 不得为 missing-extension（在适用痛点句上）。
• 与 Intent Expansion / C12 同向：扩展是默认义务。

HostCapabilityRoutingHandoff

intent 始终拥有 workflowIntent。当前消息的 identity 可在入口阶段形成 OriginalInstructionRefV1，但只有项目现实扩展和最终 workflow 路由完成后，才按需把 workflowIntent + instructionRefId + host/variant + scope/risk/confidence 交给 host-capability-routing，由后者选择 direct / plan_first / auto_authorized。

• host-capability-routing 不得把 portable decision 回写成新的 workflow intent。
• direct 不等于跳过 CP；plan_first 不等于 native Plan 已进入；auto_authorized 必须引用既有 autoAuthorityRef。
• chat 且无 DevCodex 执行意图时不触发。
• Skill/catalog 缺失、variant 未知或证据不足时维持当前 workflow route，并使用 portable fallback。