Back to Details

piv-fix-review-findings

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix Review Findings

修复审查发现的问题

A review produced findings — but a review is input, not a work order. You decide what happens to each one.
Code-review (file or description of issues): $review
Direction / scope (what to fix now vs defer): $scope
If the Code-review is a file, read the entire file first so you understand every finding before triaging.
审查会发现问题——但审查只是输入信息，而非工作指令。你需要决定每个问题的处理方式。
代码审查（文件或问题描述）：$review
方向/范围（哪些问题立即修复，哪些延后处理）：$scope
如果代码审查是文件形式，请先通读整个文件，以便在分类处理前了解所有问题。

1. Triage first (the human's call)

1. 先分类处理（人工决策）

Sort the findings before touching code. Honor any direction in the scope argument; if it's unclear, surface the findings grouped and ask rather than fixing everything by default:
  • Fix now (this PR) — real, in-scope, belongs with this change.
  • Defer / log as an issue — real but later; don't bloat this PR. Create a tracker issue (or note it) instead of fixing it here.
  • Needs a human look / manual test — anything you should inspect or test by hand before trusting it. Flag it, don't silently auto-fix.
  • Noise / won't-fix — say why, then drop it.
Don't let the reviewer dictate scope — "real, but later" is a valid and common call; a clean small PR beats a sprawling one.
在修改代码前先对问题进行分类。遵循范围参数中的任何指示；若指示不明确，则将问题分组并询问，而非默认修复所有问题：
  • 立即修复（本次PR）——真实存在、属于当前范围、与本次修改相关的问题。
  • 延后处理/记录为问题——真实存在但可后续处理；不要让本次PR变得臃肿。创建跟踪问题（或记录下来），而非在此处修复。
  • 需人工检查/手动测试——任何需要你手动检查或测试后才能确认的问题。标记出来，不要静默自动修复。
  • 无效问题/无需修复——说明原因后忽略该问题。
不要让审查者决定范围——“真实存在但后续处理”是合理且常见的选择；简洁的小型PR优于冗长杂乱的PR。

2. Fix the "fix now" set — one at a time

2. 逐一修复“立即修复”的问题

For each:
  1. Explain what was wrong.
  2. Make the fix.
  3. Create and run a test that proves it.
针对每个需立即修复的问题：
  1. 说明问题所在。
  2. 进行修复。
  3. 创建并运行测试用例以验证修复效果。

3. Validate

3. 验证修复

Run the 
piv-validate
skill to finalize the fixes.
运行
piv-validate
技能以完成最终修复验证。

4. If operating on a PR — commit and push

4. 若针对PR操作——提交并推送

If these fixes are on a PR branch, commit them (use 
piv-commit
) and push so the PR reflects the fixes and the review can re-run on the updated PR. If nothing was fixed (everything deferred), there's nothing to push — just make sure the deferred items are logged as issues.
如果这些修复是在PR分支上进行的，请提交这些修改（使用
piv-commit
）并推送，使PR体现修复内容，以便审查可在更新后的PR上重新进行。如果没有修复任何问题（所有问题均延后处理），则无需推送——只需确保延后处理的问题已记录为跟踪问题即可。

Output

输出结果

A short report: what was fixed (with its test), what was deferred/logged (with issue refs), what needs a manual look/test — and, if on a PR, the pushed commit + confirmation the PR is updated.
一份简短报告：说明哪些问题已修复（附带测试用例）、哪些问题已延后处理/记录（附带问题引用）、哪些问题需要人工检查/测试——如果针对PR操作，还需说明已推送的提交以及PR已更新的确认信息。