X Cr

---
name: x-cr
description: |
  软件正确性调查 skill。用于用户说“XX 不太对”“这个功能有 bug”“结果和预期不一致”“帮我查原因”，也用于用户要求 review 某个模块、文件、diff 或 PR 的正确性。遇到已知异常或模块 correctness review 时必须优先使用本 skill。
  本 skill 使用贝叶斯根因调查：先列候选原因 H，再按日志、代码路径、测试、diff、spec 等证据 E 更新置信度，最后判断根因属于原始 spec 不一致、实现过程偏移、spec 缺口、环境/数据问题或证据不足。
  x-cr 独立于 x-verify / x-qa-gate 自动门禁，产出 `reports/cr/cr-report-*.md`，x-fix 可按该 CR 报告继续修复。
---

# x-cr · 软件正确性调查

x-cr 是通用的软件正确性调查入口。它合并两种常见场景：

1. 用户已知问题：用户说某个行为不对、某个 bug 复现、某条链路异常，需要查根因。
2. 模块正确性 review：用户让 review 某个模块、文件、diff 或 PR，需要主动寻找可能导致错误结果的真实风险。

两种场景共用同一条主线：**现象/契约 -> 候选原因 -> 贝叶斯证据更新 -> 根因分类 -> spec 对照 -> CR 报告**。

对抗性检验在 x-cr 中是正确性取证方法：主动构造能击穿当前实现或判断的输入、状态、依赖失败、权限、缓存、并发、测试过拟合场景，再用代码路径、spec、测试、日志或 diff 证据确认、降级或排除。

命名、格式、纯风格偏好归属 `x-audit-style`；架构一致性、单一事实源、过度抽象、分层/依赖等结构性问题归属 `x-audit-arch`。x-cr 聚焦“软件是否按预期正确工作”。

## 必读参考

执行 x-cr 时加载：

1. `references/bayesian-review.md`：贝叶斯根因调查方法。
2. `references/checklist-general.md`：正确性检查清单。
3. `references/report-template.md`：CR 报告格式。

语言知识只用于判断运行时错误、类型逃逸、异步错误、资源泄漏、并发和数据边界。风格清单和命名规范退出 x-cr 调查。

## 输入模式

### 模式 A：用户已知问题

触发例子：

- “这个登录状态不太对，帮我查原因”
- “这里结果和预期不一致”
- “这个 bug 是配置读取导致的吗”
- “刷新 token 后还是失败，继续查”

目标：

- 明确实际现象、期望行为和复现证据。
- 用贝叶斯更新逐步降低错误假设，提高真实根因置信度。
- 对照原始 spec，判断根因类别。

### 模式 B：模块正确性 review

触发例子：

- “review 一下这个模块有没有正确性问题”
- “看一下这个 PR 有没有会导致结果错的地方”
- “检查当前 diff 是否会偏离原始需求”

目标：

- 先找模块契约、入口、状态流、关键用户路径和原始 spec。
- 主动提出会导致错误结果的候选假设。
- 只报告有证据支撑的正确性风险。

## 审查范围

- 用户指定文件、目录、diff、PR 或模块时，按指定范围执行。
- 用户只说 `x-cr` / `review` / `检查一下` 时，使用当前 git diff。
- 当前 git diff 为空且用户未指定范围时，请用户给出模块、文件、PR 或现象。

报告路径：

- 在 task 目录中执行：`dev-pipeline/tasks/<task>/reports/cr/cr-report-YYYYMMDD-HHmmss.md`
- 在普通仓库范围执行：`reports/cr/cr-report-YYYYMMDD-HHmmss.md`

## 执行流程

### 1. 建立调查对象

先写清楚本次调查对象：

| 字段 | 内容 |
|------|------|
| 模式 | 已知问题 / 模块正确性 review |
| 用户现象 | 用户看到的错误、异常或疑点 |
| 期望行为 | 用户预期、产品预期或 spec 预期 |
| 实际行为 | 日志、测试、代码路径或用户描述中的实际行为 |
| 审查范围 | 文件、目录、diff、PR、模块 |

模式 A 中，用户现象是第一证据。模式 B 中，模块契约和入口行为是第一证据。

### 2. 定位原始 spec

按优先级查找原始 spec：

1. 用户当前消息中的期望行为和约束。
2. task `README.md`、`dev-checklist.md`、`plan.md`、`dev-report.md`。
3. PR 描述、issue、产品文档、模块 README。
4. 测试用例中的契约断言。
5. 既有调用方行为和公开 API 文档。

记录 spec 来源和证据路径。缺少 spec 时，将根因分类中的 `spec 缺口` 作为候选项。

### 3. 建立候选根因

列出 3-6 个候选原因 H，覆盖这些方向：

| 根因类型 | 例子 |
|----------|------|
| H_spec_mismatch | 原始 spec 要 A，当前实现做了 B |
| H_impl_drift | spec 清楚，开发实现过程中漏做、做偏、回归 |
| H_state_boundary | 状态、输入、错误路径、并发边界导致异常 |
| H_config_data | 配置、环境变量、数据形状、迁移状态导致异常 |
| H_test_gap | 测试未覆盖关键契约，错误进入代码 |
| H_spec_gap | 原始 spec 缺少关键约束或存在歧义 |

每个候选原因给出定性先验：`低 / 中 / 高`。先验来自变更影响面、代码路径复杂度、历史风险和现象匹配度。

候选原因应包含对抗性假设：

- 哪个输入会击穿当前实现。
- 哪个状态组合会绕过 guard 或污染后续请求。
- 哪个外部依赖返回值会让系统进入错误状态。
- 哪个权限、缓存、并发或重试场景会破坏契约。
- 哪个测试过拟合场景会让假实现通过。

### 4. 用证据更新置信度

按贝叶斯公式组织推理：

```text
P(H | E) = P(E | H) * P(H) / P(E)
```

报告使用定性置信度：`低 / 中 / 高 / 已确认`。

每轮证据更新记录：

- H：候选根因。
- E：新证据，必须指向日志、测试、diff、代码路径、spec 或调用链。
- 影响：支持 / 削弱 / 中性。
- 更新后置信度。
- 下一步验证动作。

高置信根因需要反证检查：调用方保护、类型/schema 约束、配置默认值、已有测试、错误处理兜底、用户授权变更。

对抗性假设进入 P0/P1 前必须完成同等反证检查；证据链不足时写入 P2 证据缺口或已排除假设。

### 5. 判断根因和 spec 的关系

确认或高置信根因必须归类：

| 分类 | 含义 | 后续动作 |
|------|------|----------|
| 原始 spec 不一致 | 当前实现行为和明确 spec 冲突 | 修实现，或让用户确认改 spec |
| 实现过程偏移 | spec 清楚，实现漏做、做偏、回归、半成品 | 修实现，补验证 |
| spec 缺口 | spec 缺少关键边界、状态或错误路径定义 | 提出需补 spec 的问题 |
| 环境/数据问题 | 代码契约成立，实际环境、配置、数据形状异常 | 修配置、迁移、数据或启动约束 |
| 证据不足 | 关键日志、复现、调用链或 spec 缺失 | 列出下一步取证项 |

### 6. 输出正确性结论

严重度只围绕正确性：

| 等级 | 含义 |
|------|------|
| P0 | 已确认或高置信的错误结果、核心路径失败、spec 冲突、数据破坏、安全绕过 |
| P1 | 中高置信的生产正确性风险：边界、状态、错误处理、并发、配置导致用户可见失败 |
| P2 | 影响判断闭环的测试缺口、spec 缺口、诊断可观测性缺口 |

报告结构必须保留 `审查结论` 和 `问题详情`，供 `x-fix/references/cr-fix-mode.md` 解析。

### 7. 下游衔接

- 用户要求修复时，调用 `x-fix` 并传入 CR 报告路径。
- 用户只要求调查时，输出报告路径和 P0/P1/P2 数量。
- 证据不足时，列出最短取证路径，例如应补日志、应跑命令、应读配置、应确认 spec。

## 关键约束

- 每个问题必须有代码路径、spec、测试、日志或 diff 证据。
- 已知问题调查优先解释“为什么用户看到这个现象”。
- 模块 review 优先验证公开入口、状态流、错误路径和用户可见结果。
- 对抗性检验只服务于正确性结论，必须落到可触发条件、失败路径、影响和证据。
- 风格、命名、排版、抽象偏好退出 x-cr 报告。
- 流水线内的 R1 spec 正确性、R2 边界正确性、R3 测试真实性归 `x-qa-gate`；手动正确性调查归 `x-cr`。