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. 用证据更新置信度

按贝叶斯公式组织推理：

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。