code-reviewinglisted

# 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 -