# 指挥中心规格文档证据分级规则

## 目的

这份文档用于统一指挥中心相关规格文档中的证据表达方式，明确区分：

- 已被代码或规则资产直接证实的事实
- 已被外部接口或文档契约明确约束的事实
- 代码中表达了实现方向，但实现质量、完整性或正确性仍不充分的内容
- 当前没有直接证据、只能作为候选判断的内容

目标不是让规格文档写得更保守，而是让“观察到的事实”“归纳后的结构”“目标态设计”之间的边界始终可追溯、可复核、可讨论。

## 为什么必须分级

如果不做证据分级，指挥中心文档很容易把三类内容混写在一起：

1. 代码里已经存在并可直接定位的行为
2. 为了便于抽象而做出的归一化整理
3. 未来希望达成、但当前未被运行时或资产严格证明的目标结构

混写的直接问题是：

- 读者会把“推断出的整理结果”误认为“当前已实现事实”
- 后续实现或重构时，无法判断某一条到底是在复述现状，还是在提出目标
- 多份规格文档之间会出现证据强弱不一致、措辞口径不一致的问题

因此，所有指挥中心规格文档都必须对关键判断显式标注证据等级。

## 证据标签

以下 4 个标签为唯一允许使用的标准标签，必须按原文书写，不得改写，不得替换为同义词。

### 1. `code-confirmed`

定义：该结论可由当前仓库中的代码、规则资产、静态配置或可直接定位的实现内容直接支持。

适用场景：

- 某个字段、流程步骤、状态分类、规则动作在代码或规则资产中可直接定位
- 某个输出结构、配置项、动作通道已被实现内容明确写出
- 某条成功路径虽然未证明线上真实跑通，但“存在该逻辑分支”这一事实已被代码直接证实

使用边界：

- `code-confirmed` 只证明“代码/资产中存在该实现或定义”
- 不自动等于“生产可用”“运行时已验证成功”“端到端已闭环”

### 2. `contract-defined`

定义：该结论不是直接来自仓库实现，而是由当前被认可的接口契约、协议文档、外部约束文档明确规定。

适用场景：

- 浏览器侧/服务侧接口字段、消息格式、状态码语义由契约文档定义
- 某一能力边界来自明确的外部 API 文档或经项目认可的集成约束

使用边界：

- `contract-defined` 证明“契约如此定义”
- 不自动等于“本仓库已实现”
- 如果代码实现与契约不一致，应分别描述，不得互相覆盖

### 3. `implementation intent exists but not rigorous / buggy`

定义：代码中已经出现实现意图、雏形或局部链路，但当前证据不足以把它写成稳定事实；或者已知实现不严谨、存在缺口、疑似有 bug、成功语义未被严格证明。

适用场景：

- 能看到相关函数、分支、调用点、配置项或动作名，但缺少足够证据证明其稳定成立
- 逻辑存在，但状态语义混乱、异常处理不足、前后约束不完整
- 只能证明“作者想做这件事”，不能证明“这件事已经被可靠实现”

使用边界：

- 该标签用于承认“实现方向存在”
- 同时明确指出“不能把它提升为已确认事实”
- 这是指挥中心文档中承接“代码里有影子，但证据不够硬”的唯一合法标签

### 4. `no direct evidence / candidate only`

定义：当前没有找到代码、规则资产、契约文档或其他直接证据；该内容只能作为候选结构、候选能力、候选拆分或待确认项。

适用场景：

- 为了统一配置结构而提出的候选字段
- 为了后续架构演进而提出的候选能力名称
- 仅由推测、命名习惯、经验归纳得到的判断

使用边界：

- 该标签明确表示“目前只是候选，不是事实”
- 不能把它写成“已有但待接入”“已支持但未启用”之类更强说法，除非另有直接证据

## 推荐表述模板

### `code-confirmed`

可用表述：

- “根据当前代码/规则资产，可直接确认……，证据等级：`code-confirmed`。”
- “文档中的……来自现有实现直接证据，证据等级：`code-confirmed`。”
- “这里只能确认代码层存在该成功路径/动作定义，证据等级：`code-confirmed`；不代表运行时已验证。”

### `contract-defined`

可用表述：

- “根据当前接口契约，……被定义为……，证据等级：`contract-defined`。”
- “该字段/消息结构来自认可的集成契约，证据等级：`contract-defined`。”
- “这里描述的是契约约束，不等于仓库内实现已完成，证据等级：`contract-defined`。”

### `implementation intent exists but not rigorous / buggy`

可用表述：

- “当前实现中可以看到……的意图，但证据尚不足以将其写成稳定事实，证据等级：`implementation intent exists but not rigorous / buggy`。”
- “代码存在相关链路，但实现不够严谨/疑似有缺口，因此仅标为 `implementation intent exists but not rigorous / buggy`。”
- “目前最多只能确认作者试图支持……，不能确认其已被可靠实现，证据等级：`implementation intent exists but not rigorous / buggy`。”

### `no direct evidence / candidate only`

可用表述：

- “……目前没有直接证据，只能作为候选项，证据等级：`no direct evidence / candidate only`。”
- “该拆分/命名属于归一化建议，不代表现状事实，证据等级：`no direct evidence / candidate only`。”
- “除非后续补到代码或契约证据，否则这里只能保持为 `no direct evidence / candidate only`。”

## 禁止表述模式

以下表述在指挥中心规格文档中禁止使用，除非同时给出更低证据等级并明确限定范围。

### 1. 禁止把代码存在误写为运行时已验证

禁止示例：

- “系统已经稳定支持……”
- “该链路已完成闭环……”
- “运行时已证明可以成功……”

问题：这些表述把“代码里有逻辑”错误提升成“真实运行已被验证”。

### 2. 禁止把推断结构误写为既有事实

禁止示例：

- “当前配置结构就是……”
- “系统已有统一能力模型……”
- “所有任务已经按该 schema 实现……”

问题：如果只是为了整理而归纳出的标准结构，应标为候选或目标态，不能写成现状。

### 3. 禁止使用模糊强化词替代证据标签

禁止示例：

- “基本可以认为……”
- “大概率就是……”
- “看起来已经支持……”
- “应该算是实现了……”

问题：模糊判断会绕开证据分级，导致读者无法判断结论强度。

### 4. 禁止自造同义标签或混用近义词

禁止示例：

- “代码已确认”
- “契约已定义”
- “半实现”
- “待验证”
- “候选”

问题：这些中文近义词会破坏跨文档一致性。必须使用本文规定的 4 个精确标签原文。

## 示例：`95598-repair-city-dispatch`

示例结论：

- 对 `95598-repair-city-dispatch` 而言，音频提醒、短信/消息提醒、外呼、处置日志等成功路径行为，如果能够在规则资产或实现内容中直接定位，应写为 `code-confirmed`。
- 但这只能说明“代码或规则里存在这些成功路径定义”。
- 不能据此直接写成“运行时已经稳定成功触发音频/短信/外呼/处置日志”。
- 如果当前没有端到端运行验证证据，那么“运行时成功”只能写为 `implementation intent exists but not rigorous / buggy`，或者在证据更弱时写为 `no direct evidence / candidate only`；不能提升为 `code-confirmed`。

推荐写法：

“在 `95598-repair-city-dispatch` 中，音频提醒、短信/消息提醒、外呼、处置日志相关成功路径可在规则资产中直接定位，因此这些‘规则层已定义的成功路径行为’可标注为 `code-confirmed`。但目前没有同等强度证据证明这些动作在真实运行时已稳定成功，因此‘运行时成功已验证’这一结论不能标为 `code-confirmed`；在缺少严格运行证据时，应标为 `implementation intent exists but not rigorous / buggy`。”

## 执行规则

- 所有指挥中心相关规格文档，必须使用本文定义的 4 个精确标签。
- 不允许使用任何同义词、中文替代词、缩写或自定义等级名。
- 一条关键结论如果没有证据等级，就视为表达不合格。
- 当同一主题同时涉及“代码事实”和“目标结构”时，必须拆句分别标注，不能合并成一个模糊结论。

## 最短落地准则

写每一条关键判断前，先问两个问题：

1. 我是在复述当前已被直接证据支持的事实，还是在做归一化整理/目标设计？
2. 我手上的证据，到底支撑的是代码存在、契约约束、实现意图，还是根本没有直接证据？

只有先回答这两个问题，指挥中心规格文档才能保持严格、可复核和可持续重写。