intent

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

前置识别（优先于三问）

检查	条件	意图
是否按任务名恢复？	完整消息符合 继续<任务名>任务 或 继续 <任务名>	先调用 memory_task_resolve；仅 resolved-active 进入 resume，其余状态按最小消歧/完成说明/stale CP 处理
是否恢复中断？	用户说"继续"/"恢复"，且今日/昨日任务文件（daily file）中存在状态为 🔄 的会话（SUMMARY 索引表的状态列不作为判断依据，见 15-memory §新会话 🔄 检测）	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 不得进入任务执行。

三问判断法

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

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

三问结论：

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

意图类型路由

意图	说明
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. 必须先运行 DocsAudienceIntent（scripts/lib/docs-audience-intent.js / Skill 语义等价），得到 docsAudience + docsSurface。
2. 必须在用户可见回复中写出锁定结果（或 ambiguous 阻断 + 唯一推荐消歧）；不得静默开写。
3. 路由：
   • public-user → user-manual-authoring（+ 条件 readme-authoring）
   • maintainer-dev → maintainer-docs-site-authoring
   • ambiguous → fail closed，推荐置首
   • multi-audience → 拆任务
4. 完成前做受众漂移检查；失败不得宣称文档任务完成。
5. 验证：npm run test:docs-audience。
6. 用户站 guide 完成前须过认知高度：classifyUserDocsCognitiveAltitudeSample（禁止 function-inventory-as-guide）。

问题驱动场景延展（强制 · 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/confidence 一致	matched	null	允许进入已确认转换
proposal 或 requirement 状态缺失	clarify	INTENT_STATE_MISSING	恢复当前引用后重新确认
requirement 不匹配	blocked	INTENT_REQUIREMENT_MISMATCH	重载 active requirement
phase 不匹配	blocked	INTENT_PHASE_MISMATCH	返回预期阶段或刷新阶段证据
confidence 低于执行阈值	clarify	INTENT_LOW_CONFIDENCE	澄清语义，不猜测转换

routeHints/historyRefs 可作为 ignored 解释证据，但不得覆盖当前用户消息或已确认产物。该合同只返回 decision，不自行写 CP state、需求文件或 Hook 状态。

analyze vs audit 区分

维度	analyze	audit
过程类型	多轮收敛分析（≥3 轮，连续 2 轮无新发现后收敛）	多轮深度审查，直至收敛
结束条件	最少 3 轮，连续 2 轮无新发现；轮末输出收敛状态	连续 3 轮有效零发现（仍须满足连续 3 轮零发现，并核验 ReviewCoverageDelta；不区分定向/全面，见 12-audit §多轮收敛规则）
典型表述	"分析/看看/评估/对比/解读"	"深度审查/全面体检/逐项检查/走查"

边界词处理："检查"/"review"/"评审" 倾向 audit，但以覆盖范围和收敛期望为准。

dev vs fix 区分

维度	dev	fix
动机	主动改进（新增/重构/优化/迁移）	被动修正（Bug/报错/回归）
判断标准	系统当前行为正确，但需要扩展或改进	系统当前行为不正确，需要恢复

仍然模糊时，优先按 fix 路由（fix 流程含根因分析 CP1，分析后若实际需要新功能可重路由到 dev）

self-fix 识别标准

条件	说明
修改对象	DevCodex 插件目录下的规范文件（instructions/ · skills/ · prompts/ · agents/ · RULES.md）
修改动机	修复规范内部不一致、错误、缺失（非功能迭代、非新增）

特殊场景——治理记录评估（T_RECORD 分支）：

• 每条非空用户消息都先登记中性 candidate；是否进入 T_RECORD 必须在合理性评估、项目现实扩展和上下文归因后按语义决定。固定措辞或关键词只能帮助检索，不能触发、分类或免除评估。
• 决策归一为：record.violation、record.spec-defect、record.process-improvement、record.pending-issue、record.audit-gap、record.none、record.ambiguous；同一消息允许多个实质意图并存。
• 写入目标由 skills/spec-governance/SKILL.md 的 RecordRouter 决定：VL/PF/PI（优化清单）/ISSUE/GAP 或不写台账；复合意图必须逐项 all-of 验证。
• 每次评估输出完整 GovernanceIntakeDecision；record.none 执行 RecordNoneChallengeGate，record.ambiguous 保持未终结并先澄清。

多任务检测（强制）

用户消息含 ≥2 个独立任务时：

1. 列出识别到的各任务
2. 建议拆分为顺序执行
3. 用户不同意 → 按用户指定顺序
4. 用户未明确反对 → 立即开始第一个任务（无需额外等待确认）

ConcurrencyPolicy 只放开前置只读识别、文件搜索和隔离分析的并发；多个独立任务的正式工作流、CP 状态、报告、记忆和台账写入仍按顺序推进，不能并行提交共享状态。

ℹ️ C14：任务数≥5 时，建议用户拆分会话执行

多任务摘要隔离（强制）

若记忆中同时存在 ≥2 个不同项目/任务的活跃 CP 状态，收到新消息时： ① 根据消息内容显式判断属于哪个任务 ② 对该任务独立重新执行三问判断 ③ 禁止将任务 A 的工作流类型或 CP 状态继承应用到任务 B