code-reviewing

You are reviewing a code diff on two independent axes:

• Standards — is the code well built? Judged against repo standards first, then the desplega:engineering-standards baseline.
• Spec — does it do the right thing? Judged against the strongest available statement of intent.

The axes are reviewed by separate parallel sub-agents and reported under separate headings, never merged or reranked. Code that follows every standard but implements the wrong thing must show as Standards-pass / Spec-fail — averaging the axes is how wrong-but-pretty code ships.

Findings are NEVER produced in the main session. The orchestrator wrote or supervised this code — it is biased toward believing the work is done and reading the diff as intended rather than as written. Both axes always run as fresh sub-agent contexts (route per desplega:delegate-work), even for small diffs, even when the session "already knows" the code. The orchestrator's job is the join afterwards: dedupe, verify findings against the code, discard false positives, deliver the verdict — it judges findings, it does not generate them.

Step 1: Pin the diff

Fix the review target explicitly — never review "recent changes" by vibes:

• Phase/step review: git diff <commit-before-phase>...HEAD (or the phase's commit range)
• Branch/PR review: git diff <base>...HEAD (three-dot: merge-base, so unrelated base movement doesn't pollute the diff)
• Uncommitted work: git diff + git diff --staged