/intent

name: intent
description: 识别用户意图类型（dev/fix/analyze/audit/self-fix/chat/resume/other），采用前置识别 + 三问法。Free 层可用。

前置识别（优先于三问）

| 检查 | 条件 | 意图 | |------|------|------| | 是否按任务名恢复？ | 根据完整对话判断用户要续接哪项已有任务，提取任务定位信息 | 先调用 `memory_task_resolve`；仅 `resolved-active` 进入 `resume`，其余状态按最小消歧/完成说明/stale CP 处理 | | 是否恢复中断？ | 当前消息在上下文中表达续接目的，且当前会话的任务恢复证据仍有效；短回答或特定词本身不决定路由 | `resume` → 定向复水化，保留已确认范围与授权 | | 是否纯问答？ | 仅提问/求解释，无文件变更或任务执行意图 | `chat` → 直接路由，跳过三问 |

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

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

| 标签 | 条件 | 默认处理 | |------|------|---------| | 规范说明类 | 用户追问规则来源、判断依据、为什么这样设计 | 先正面解释规则层依据，不默认贴完整原文/路径/编号清单 | | 规范改进类 | 用户追问规范如何提升、还能怎么优化、下一步改进什么 | 先正面讨论改进方向；若用户要落地变更，再转 dev 立项 |

> ⚠️ 上述两个标签只是 `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。缺少必要信息时先定向读取，只有确实影响下一步的歧义才向用户询问。

| 问题 | 指向变更 | 指向分析 | |------|---------|---------| | Q1：最终目的是产生变更（代码/配置/规范文件），还是获得结论/报告？ | 变更 | 结论 | | Q2：分析是手段（为了执行变更）还是目的（为了得出结论）？ | 手段 | 目的 | | Q3：是否需要修改/创建/删除任何文件（含源码与规范文件）？ | 是 | 否 |

**三问结论**：

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

意图类型路由

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

| 意图 | 说明 | |------|------| | `dev` | 新功能开发、重构、优化、迁移 | | `fix` | Bug 修复、报错处理 | | `analyze` | 多轮收敛分析，≥3 轮，输出结论（analyze）| | `audit` | 多轮深度审查，≥3 轮，直至收敛 | | `self-fix` | 规范文件自修复 | | `chat` | 问答、解释（无文件变更）| | `resume` | 恢复上次中断的任务 | | `other` | 不匹配上述任何意图 → plan 工作流 |

项目现实扩展衔接

意图识别分两层输出：

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 与更优/备选路线（含遗漏场景），**不得**等用户追问「还有没有更合理建议」才补。

| 字段 | 说明 | |------|------| | `semantic` | 用户字面语义初判 | | `project` | 目标项目与 active-root | | `continuity` | 是否延续现有 requirement/bug/session | | `action` | 最终工作流与子类型 | | `domain` | 受影响模块/领域 | | `artifact-impact` | source/config/docs/memory/report/deployment 等影响面 | | `risk` | destructive/security/high-risk/normal | | `host-capability` | 是否涉及宿主能力差异及降级边界 | | `validation-route` | test/lint/typecheck/validate/direct replay/官方文档 | | `confidence` | high/medium/low | | `alternatives` | 被排除路线及原因 |

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。

IntentConsistencyGuard-lite

当用户消息准备触发确认、继续或阶段转换时，先由语义路由得到 `semanticAction/confidence`，再使用 `IntentConsistencyInputV1 → IntentConsistencyDecisionV1` 核对显式状态证据；不得让本 Guard 用关键词替代语义识别。机器可执行真相源为 `scripts/lib/intent-consistency.js`。

证据优先级固定为：`user-current > confirmed-requirement-or-proposal > phase > route-hint > history`。`confirm/continue` 必须同时绑定当前 `proposalRef` 与 `requirementRef`；“确认 / 继续 / yes / ok”等短确认只有在引用唯一且 phase/requirement 匹配时才能返回 `matched`。

| 场景 | status | errorCode | 处理 | |---|---|---|---| | refs/phase/c