630190e4d3
Capture the command-center operation analyses, inventory outputs, and browser pipeline reference files produced during the current research pass so they can be reviewed from the branch. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
9.0 KiB
指挥中心规格文档证据分级规则
目的
这份文档用于统一指挥中心相关规格文档中的证据表达方式，明确区分：
- 已被代码或规则资产直接证实的事实
- 已被外部接口或文档契约明确约束的事实
- 代码中表达了实现方向，但实现质量、完整性或正确性仍不充分的内容
- 当前没有直接证据、只能作为候选判断的内容
目标不是让规格文档写得更保守，而是让“观察到的事实”“归纳后的结构”“目标态设计”之间的边界始终可追溯、可复核、可讨论。
为什么必须分级
如果不做证据分级，指挥中心文档很容易把三类内容混写在一起：
- 代码里已经存在并可直接定位的行为
- 为了便于抽象而做出的归一化整理
- 未来希望达成、但当前未被运行时或资产严格证明的目标结构
混写的直接问题是：
- 读者会把“推断出的整理结果”误认为“当前已实现事实”
- 后续实现或重构时，无法判断某一条到底是在复述现状，还是在提出目标
- 多份规格文档之间会出现证据强弱不一致、措辞口径不一致的问题
因此，所有指挥中心规格文档都必须对关键判断显式标注证据等级。
证据标签
以下 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 个精确标签。
- 不允许使用任何同义词、中文替代词、缩写或自定义等级名。
- 一条关键结论如果没有证据等级，就视为表达不合格。
- 当同一主题同时涉及“代码事实”和“目标结构”时，必须拆句分别标注，不能合并成一个模糊结论。
最短落地准则
写每一条关键判断前，先问两个问题：
- 我是在复述当前已被直接证据支持的事实，还是在做归一化整理/目标设计？
- 我手上的证据，到底支撑的是代码存在、契约约束、实现意图，还是根本没有直接证据？
只有先回答这两个问题，指挥中心规格文档才能保持严格、可复核和可持续重写。