#意图契约

IntentResult 包含固定的默认字段和扩展 data。完整类型、必填与空值规则、全部状态和 JSON 示例见响应结构。下面是便于理解的示例，说明措辞不作为逐字验收标准：

{
  "input": "分析登录失败原因，先不要修改代码。",
  "normalizedInput": "分析登录失败原因，暂不修改代码。",
  "primaryIntent": "分析登录失败原因",
  "requirements": [],
  "intents": [
    { "id": "i1", "action": "analyze", "target": "登录失败原因", "status": "ready", "requirements": [] }
  ],
  "prohibitions": ["暂不修改代码"],
  "data": {}
}

#默认字段

每个动作有 id、action、target、status 和局部 requirements。target 无法确定时可为 null。

#动作分类

这套分类表达用户请求，不选工具、不执行动作。needs_clarification 状态下尚不能确定动作类别时，action 允许为 null。

#易混淆的分类边界

完整响应见取消已有请求、创建业务对象及多动作。

#理解状态

clarification 中的元素为 { "question": "…", "options": [] }，question 和 options 都是必填字段；没有明确选项时 options 为空数组。应用可以据此向用户提问。多个阻塞同时存在时的状态优先级与 reason 规则见动作字段与状态。

ready 不能替代业务授权；awaiting_confirmation 也不自动批准后续动作。状态是对材料的理解，应用决定如何推进。

#语义边界

识别应保留明确的否定、例外、先后条件、数值单位和多对象关系。只提供“分析原因”时，不应添加“实施修复”；明确“暂不修改”时，应保留禁止事项。

整体预算与期限只保留一次，局部/阶段限制放在相应动作 requirements；只有约束时 intents 可以为空。复合条件保留分组，可选项保留可选含义。完整例子见全局与局部要求、阶段限制和只有约束。

这些规则通过提示、结构校验、来源检查和测试共同约束，不能从 JSON 合法直接推出语义正确。实际结果的动作与含义应按评测方法核对。