Advisory Code Review

Type: Review pattern
Referenced from: openclaw-autoreview-skill

Definition

A code review approach where the review output is treated as advisory input to a decision, not as an authoritative mandate. Every finding must be independently verified by reading the actual code path and adjacent files before any action is taken.

Core Principles

  1. Verify before acting — Read the real code path. Don't trust the review output at face value.
  2. Reject speculative risks — Unrealistic edge cases, broad rewrites, and over-complicated fixes are discarded.
  3. Small targeted fixes — Fix at the right ownership boundary. No refactors unless they clearly improve the bug class.
  4. Fix bug classes — When a finding reveals a repeated pattern, inspect the scope for sibling instances and fix them all at once.
  5. Keep going until clean — Review must return no accepted/actionable findings before stopping.

Why Advisory (Not Authoritative)

  • Review models hallucinate — They can misread code semantics, invent non-existent bugs, or suggest changes that break working code.
  • Context is incomplete — The reviewer doesn't know business constraints, ownership boundaries, or follow-up plans.
  • Overcorrection risk — Authoritative review output leads to "fix everything the reviewer says" which over-complicates codebases.

Application to Factory Pipelines

In a factory pipeline, advisory review fits as a closeout check — the last step before ship where a second opinion catches real issues without blocking progress on false positives.

Code changes → [Advisory Review] → Verify findings → Fix accepted → Ship

The review is a filter, not a gate. Findings that survive verification get fixed; the rest are noted and discarded.

Contrasts

Pattern Authority Who Acts
Advisory review Reviewer suggests, actor decides Code author
Approval gate Reviewer approves/blocks Reviewer
Auto-fix Tool applies changes directly Tool