piv-fix-review-findings

修复审查发现的问题

审查提出了一些发现——但审查是输入，而不是工作指令。 如何处理每一项，由你决定。

代码审查（文件或问题描述）：$review

方向 / 范围（现在修复什么，哪些延后）：$scope

如果代码审查内容在文件中，请先通读整个文件，以便在分类前了解所有发现。

1. 先分类（由人决定）

动代码之前先对发现进行分类。遵循范围参数中的任何指示；如果指示不明确，就按类别列出发现并询问，不要默认全部修复：

• 现在修复（本次 PR） — 确实存在、属于当前范围，并且与本次更改相关。
• 延后 / 记录为问题 — 确实存在，但可以稍后处理；不要让本次 PR 膨胀。请创建跟踪问题（或记录下来），而不是在这里修复。
• 需要人工检查 / 手动测试 — 任何需要你亲自检查或测试后才能确认的内容。请标记出来，不要悄悄自动修复。
• 噪声 / 不予修复 — 说明原因，然后忽略。

不要让审查者决定范围——“确实存在，但稍后处理”是合理且常见的选择；干净、精简的小型 PR 胜过范围蔓延的 PR。

2. 逐项修复“现在修复”的问题

对于每一项：

1. 说明问题所在。
2. 进行修复。
3. 创建并运行测试，以证明修复有效。

3. 验证

运行 piv-validate 技能以完成修复。

4. 如果在 PR 上操作——提交并推送

如果这些修复位于 PR 分支上，请提交（使用 piv-commit）并推送，以便 PR 包含这些修复，审查可以在更新后的 PR 上重新运行。如果没有修复任何内容（全部延后），则无需推送——只需确保已将延后的事项记录为问题。

输出

简短报告：已修复的内容（及其测试）、已延后 / 记录的内容（附问题引用）、需要人工检查 / 测试的内容；如果在 PR 上操作，还要说明已推送的提交，并确认 PR 已更新。