# 证据与决策策略

建立或修订需求契约时加载本参考。

## 证据标签

- `FACT`：有稳定来源定位直接支持的事实。
- `INFERENCE`：可以用于计划或搜索，但还没有权威确认的合理推断。
- `OPEN`：可能阻塞，也可能不阻塞实现的缺失信息。
- `CONFLICT`：两个看似权威的来源互相冲突。

不要因为实现已经采用某个推断，就悄悄把 `INFERENCE` 升级成 `FACT`。

## 证据账本字段

每条证据都要包含：

- 唯一证据 ID；
- 来源类型和稳定定位；
- 可用时记录来源版本或观察时间；
- 主题，如 `behavior`、`visual`、`api`、`analytics`、`security`、`rollout`；
- 归一化陈述；
- 证据标签；
- 置信度：`high`、`medium`、`low`；
- 受影响的验收标准或子任务；
- 歧义或访问限制说明。

## 冲突处理

按主题解决冲突，不要设置一个适用于所有材料的全局排名。

| 冲突主题 | 通常优先采用 | 不要默认认为 |
|---|---|---|
| 业务行为 | 用户明确确认、当前已评审 PRD/Issue 验收 | 现有代码存在就一定正确 |
| 视觉值/布局 | 当前精确 Figma 节点、变量、组件和注释 | 截图估值就是精确 Token |
| 交互 | 明确验收、Prototype、注释和用户确认 | 视觉上靠近就代表可以点击 |
| API 线协议 | 当前已确认的 OpenAPI、Schema、后端类型和错误契约 | 前端 Mock 就代表生产契约 |
| 现有行为 | 运行复现、测试、当前调用链和运行日志 | 旧文档一定仍然有效 |
| 浏览器支持 | 仓库支持策略和 CI 浏览器矩阵 | 一次本地 Chromium 通过就足够 |

仍然存在实质冲突时，列出明确选项及各自影响。只问一个精确问题，不要笼统地说“请澄清需求”。

## 搜索与决策的边界

可以用同义词、可能的方法名、UI 文案、领域词、事件名和相关组件名寻找候选代码，但这种关联不是产品证据。实现产品行为前，必须把它连接到需求、设计注释、API 契约或用户明确决定。

## 阻塞性问题

以下不确定性会改变关键语义，必须阻塞受影响实现：

- 谁可以读取、写入、审批、删除、付费或发布；
- 不可逆或破坏性行为；
- 计费、价格、配额或法律/合规含义；
- 持久化数据结构或公共 API 兼容性；
- 主用户流程或成功定义；
- 高影响功能的发布和回滚安全。

低风险文案、已有 Token 覆盖的轻微布局细节，或完全遵循现有模式且不改变公共行为的实现选择，可以在记录假设后继续。