| 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 是通用的软件正确性调查入口。它合并两种常见场景：
- 用户已知问题：用户说某个行为不对、某个 bug 复现、某条链路异常，需要查根因。
- 模块正确性 review：用户让 review 某个模块、文件、diff 或 PR，需要主动寻找可能导致错误结果的真实风险。
两种场景共用同一条主线：现象/契约 -> 候选原因 -> 贝叶斯证据更新 -> 根因分类 -> spec 对照 -> CR 报告。
对抗性检验在 x-cr 中是正确性取证方法：主动构造能击穿当前实现或判断的输入、状态、依赖失败、权限、缓存、并发、测试过拟合场景，再用代码路径、spec、测试、日志或 diff 证据确认、降级或排除。
命名、格式、纯风格偏好归属 x-audit-style；架构一致性、单一事实源、过度抽象、分层/依赖等结构性问题归属 x-audit-arch。x-cr 聚焦“软件是否按预期正确工作”。
必读参考
执行 x-cr 时加载：
references/bayesian-review.md：贝叶斯根因调查方法。references/checklist-general.md：正确性检查清单。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：
- 用户当前消息中的期望行为和约束。
- task
README.md、dev-checklist.md、plan.md、dev-report.md。
- PR 描述、issue、产品文档、模块 README。
- 测试用例中的契约断言。
- 既有调用方行为和公开 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. 用证据更新置信度
按贝叶斯公式组织推理：
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。
