project-review

项目审查

project-review 是项目级最终验收能力。它由模型调用，也可以手动调用。它会冻结验收基线，通过 review-loop 驱动只读审查员，并给出最终结论：PASS、FAIL 或 BLOCKED。Producer 会执行经授权的修复；project-review 本身不会修复产物。

何时使用

• 项目已有获批的目标（SPEC、简报或工单图），且实现范围明确，需要进行检查：在 light-implement 或一批工单完成后、release-workflow 之前。
• 技能准入：验收依据是某个包的 SKILL.md 及其证据时。

如果存在 docs/agents/light-project.md，请先采用其中的审查配置和验收策略，然后冻结实际验收依据。

核心行为

1. 冻结验收基线并选择一个配置：generic.md、 software.md、 manuscript.md、 agent-skill.md 或 specification.md。
2. 通过 review-loop 调用审查员：普通产物使用 generic-review，软件差异使用 light-code-review，有适用且已获认可的领域审查员时则使用该审查员。审查员只返回问题发现。
3. 验证问题发现，仅安排范围明确且属于范围内的修复，然后请一位全新、独立的评估员进行评估。
4. 满足停止规则后给出结论。

进入模式

使用以下三种模式之一；详情见 WORKFLOW.md：

• init：冻结验收基线和配置，然后开始审查。
• review：执行一轮范围明确的证据收集、评审、验证、修复和评估。
• resume：继续下一项尚未完成的已记录操作，不改写先前的证据。

交接与停止

• PASS：每项已冻结的标准都有标记正确的证据，且全新的评估员接受该基线。
• FAIL：某项已冻结条件未满足，且无法通过已确认、范围内且有明确边界的修复解决。
• BLOCKED：缺少所需基线、权限、环境、证据、访问权限或独立上下文；记录之间存在冲突；或修复次数上限阻止了安全收敛。

默认最多进行三轮。在 .project-review/ 下记录持久状态；精确的状态目录树和恢复规则请参阅 WORKFLOW.md。如果验收依据是跟踪器工单，则在 PASS 后解决该工单，并在 FAIL 或 BLOCKED 后评论说明阻塞原因（工单收尾）。

可选能力

• FAIL 且 Cause: direction → 工单收尾后，使用 verdict.md 路径调用 light-redirect。若不可用或调用被拒绝 → 在工单中评论 FAIL 即为交接。
• 存在 .scratch/<feature>/plan.html → 给出结论并完成工单收尾后，调用 light-html-plan 刷新该页面。若页面或能力不存在 → 跳过。

参考资料

• WORKFLOW.md — init/review/resume、角色数据包、状态目录树。
• acceptance-charter.md — 冻结基线和配置字段。
• evidence-protocol.md — 证据标签和记录。
• finding-schema.md — 问题发现的标识、处置方式和注册表。
• review-rubric.md — 核心检查项和配置维度。
• subagent-protocol.md — Critic/Evaluator 数据包和独立性要求。
• stopping-rules.md — 结论转换和修复次数上限。
• migration.md — 仅供了解历史；运行时无需使用。