用途
nav-brief 用于把范围协商前置：当提示看起来像一项任务、但需求存在歧义时，在编写代码之前先渲染一份一屏式 INTENT BRIEF（意图简报），让用户确认后再开始实现，从而减少因猜测范围导致的返工和上下文污染。资料明确指出，歧义不等于复杂：小任务也可能高度模糊（例如“修一下 bug”但没说哪个 bug），而大任务也可能完全明确；真正代价高昂的失败模式是按猜测的范围去实现。
主要能力
- 渲染一屏式简报，字段包括：Goal（目标，一行）、Scope（范围，具体文件/目录/端点，并注明 NOT 不做相邻内容）、Approach（做法，可引用记忆预填）、Limits（数值与约束，标注 ASSUMED）、Verify（如何证明完成）、Won't do（明确的非目标）、Contradict（改善 X 会恶化 Y，或填 none）。
- 最多提出 2 个开放问题；只问无法推断或无法安全假设的内容，其余作为预填默认值供用户否决。
- 确认后收集修正：被修改的默认值可作为知识图谱记忆的候选，通过 nav-graph 的“Remember we decided...”流程保存，使后续简报预填更准确。
- 支持矛盾声明：当 Contradict 行不为 none 时，在填写 Approach 之前先查询既有解决方案（通过 graph_manager.py 的 contradictions 动作，以 2-3 个关键词过滤），并引用匹配的 mem-NNN 编号；若任务较复杂（Task Mode 复杂度 ≥ 0.5 或多于一个子系统），可先交由 nav-triz 生成三种分离模式的候选并推荐其一。
- 简报漂移检测：实现过程中若将要超出已确认简报的 Scope 或 Limits，停止并提示“⚠ BRIEF DRIFT”，让用户选择扩展简报或跳过该改动。
使用方式
触发由钩子决定：仅当本轮注入上下文包含 NAV-BRIEF 提醒块（由 prompt_brief op 在 UserPromptSubmit 时按歧义分数 ≥ 阈值发出）时才渲染简报，不应仅凭自身判断自行触发。配置位于 .agent/.nav-config.json，例如：
"brief_hook": { "enabled": true, "ambiguity_threshold": 0.5, "memory_budget_chars": 1200 }
渲染后须停止，等待用户确认，再进行任何修改项目的 Edit/Write/Bash。遇到以下情况直接跳过简报：上下文中无 NAV-BRIEF 提醒；提示明显是对待确认简报开放问题的回答；用户表示紧急或要求跳过（如“just do it”“quick fix”“skip the brief”），并静默遵从。与 workflow_enforcer / Task Mode 同时触发时，两个块都要显示：WORKFLOW CHECK 决定如何执行（模式），简报决定范围内内容；Task Mode 下已确认的简报替代 PLAN 阶段临时的范围推导。
适用场景
适用于任务型但范围模糊的提示，例如“给 API 加限流”（示例中歧义分数 0.7，简报预填公开路由范围、Limits 标记 ASSUMED、就限流数值提 1 个问题）。相反，“修复 README.md 里的拼写错误”因文件引用已给出完整范围而直接执行。也适用于实现中范围即将超出已确认简报时发出漂移提示。
限制
- 触发源仅为钩子，v1 无状态：钩子可能对包含任务动词的回答重复触发（已知限制）。
- 资料明确将以下能力列为 v1 推迟的未来工作：跨轮持久化待确认简报状态、strict_block 硬性门禁、简报展示/直通计数与每任务修正数等度量、提示重写。
- Contradict 行不应为填而编造张力；大多数任务是常规的，“none”是预期常见情况。漂移检测不覆盖该行。