CodeWhale 审查回执如何用 --write-receipt 与 --check-receipt 在推送前确认 diff 未变【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale用codewhale review审查完本地 diff 之后真正的问题往往是从审查那一刻到执行git push之间工作区又动了。CodeWhale 的 review 回执review receipt就是为这个窗口设计的codewhale review --write-receipt在审查成功后把一份本地 JSON 回执写到 Codewhale 状态目录的review-receipts/子目录可用--receipt-path path指定位置推送前再运行codewhale review --check-receipt它会不调用模型把当前 diff 的指纹与回执中的指纹做本地比对。这份机制的定义见 docs/RECEIPTS.md实现位于 crates/tui/src/lib.rs 与 crates/tui/src/tools/review.rs。审查回执记录了什么、不记录什么回执是 pre-push handoff artifact它只记录“审查的是哪份 diff、审查报告了什么”本身不会 push、不会打 tag、不会开 PR也不宣称替代维护者审查。当前回执包含以下字段diff_fingerprint被审查 diff 的 SHA-256 指纹是后续比对的核心provider与model本次审查实际路由到的 provider/modelchecks_run附加在回执上的本地检查。为空表示没有附加任何检查有附加检查时它们必须报告通过的 statusfindings结构化 issue/suggestion 计数及 issue 位置当审查输出是结构化 JSON 时unresolved_risk由未解决的 findings 推导出的保守摘要review_content_sha256审查文本的 SHA-256。回执刻意不包含原始 diff 正文。这意味着回执是审计记录而不是 diff 的载体跨机器交接时审阅方拿到的是指纹和结论diff 本身仍来自仓库。第一步审查成功后写出回执在有未推送改动的仓库工作区内执行codewhale review --write-receipt这条命令审查的是当前工作区 diff。--write-receipt的含义是“在成功的审查之后写出持久化 pre-push 审查回执”见ReviewArgs中的参数注释。几个要点必须有真实 diff。命令在取 diff 后若发现为空会直接报错No diff to review.不会走到写回执这一步。diff 的范围由目标参数决定与后续--check-receipt必须一致--staged审查git diff --cached--base ref如origin/main审查git diff base...HEAD--path file把 diff 限定到某个路径。模型路由可用--provider name与--model name覆盖回执里记录的provider/model就是实际路由结果。若--receipt-path没有提供回执写入 Codewhale 状态目录的review-receipts/下提供了则写入该路径父目录不存在时会自动创建。成功信号stderr 输出Review receipt written: path。加--json时输出 JSON 中带receipt_path回执文件路径和receipt回执内容两个字段便于脚本消费。参数约束在 crates/tui/src/lib.rs 的validate_review_receipt_args中硬性校验--receipt-path必须与--write-receipt或--check-receipt二选一搭配--write-receipt与--check-receipt互斥不能同时给。第二步推送前运行 --check-receipt 门禁codewhale review --check-receipt这是纯本地门禁不调用模型不产生模型费用。它的逻辑是按与审查时相同的参数重新收集 diff计算指纹然后与回执中的diff_fingerprint比较。回执来源二选一显式指定codewhale review --check-receipt --receipt-path path缺省时在review-receipts/目录里找与当前 diff 指纹匹配的最新一份本地回执。找不到时命令报错并提示No review receipt found for the current diff. Run codewhale review --write-receipt first, or pass --receipt-path.。关键前提check 收集 diff 用的目标参数要和 write 时一致。如果你写回执时用的是--base origin/maincheck 时也要带同样的--base--staged、--path同理。参数不一致时两边计算出的 diff 不同指纹必然对不上得到的diff_mismatch反映的是“比对了不同范围的 diff”而不是你真正的改动。检查通过时命令以 0 退出并输出Review receipt valid: path这是可以直接接在git push前面的门禁codewhale review --check-receipt git push检查失败时如何读输出检查不通过时命令以非零退出码结束并打印Review receipt check failed: reason。按 docs/RECEIPTS.md 与 crates/tui/src/lib.rs 中run_review_receipt_check的实现失败原因分四类diff 已变化diff_mismatch当前 diff 指纹与回执不符。正确动作是重新运行codewhale review --write-receipt审查新 diff文档同时要求在 PR 交接中复用回执前先比较diff_fingerprint。回执有未解决风险unresolved_risk写回执的那次审查报告了结构化 issueunresolved_risk.unresolved为真时check 会直接失败reason 是回执里的风险摘要。也就是说想让门禁通过审查输出本身必须没有未解决的 issue——“审查过了”不等于“审查干净了”。回执 schema 不受支持unsupported_schemaschema_version与当前版本不匹配。附加检查未通过check_failedchecks_run中某项检查的 status 不是通过状态reason 形如review receipt check name did not pass: status。需要机器可读结果时对 check 加上--jsoncodewhale review --check-receipt --json输出形如字段值来自实际回执{ mode: review_receipt_check, success: true, validation: { passed: true, status: valid, diff_fingerprint: sha256:…, receipt_fingerprint: sha256:…, unresolved: false, risk_level: none } }validation.status的取值固定为valid、diff_mismatch、unresolved_risk、unsupported_schema、check_failed、invalid之一可直接作为 CI 判断分支的依据。边界与限制--check-receipt不调用模型因此它验证的是“diff 未变 回执本身无未解决风险/失败检查”不是“代码现在一定正确”代码变了指纹就对不上这是它的设计边界。回执不携带原始 diff 正文只带diff_fingerprint与审查结论摘要交接场景下 diff 仍需要从仓库获取。checks_run为空是合法状态表示没附加任何本地检查一旦附加检查项的 status 必须是通过状态否则 check 门禁失败。回执写在本地状态目录属于本机产物换机器后要么拷贝回执文件并用--receipt-path指过去要么在目标机器上重新--write-receipt。当 check 返回Review receipt valid退出码 0时就可以执行git push若非零退出按上面四类原因处理——最常见的是第 1 类diff 又改了重新写一份回执再查一次。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考