Harness Engineering Code Review

Philosophy

Find introduced risk before summaries. Code review should be precise enough for Codex inline findings and broad enough to catch traceability, validation, readiness gaps, and repeated context failures.

When to Use

Use when handling PRs, branches, diffs, commits, readiness, and disputed review feedback. Keep scope tight: inspect changed files, direct evidence, and at most the focused surfaces needed for the active review lane before widening.

Inputs

Diff, repo guidance, Linear issue, spec, plan, PR evidence, validation output, live PR review state, Codex provenance or session-collector evidence when cited, and any supplied review-mode contract.

Outputs

Return schema_version: 1 when structured, plus mode, side-effect class, severity-ranked findings, traceability, blockers, verdict, reproduction status, security review, behavior proof, work candidate, repeated-failure route, blackboard delta, git staging status, staged paths, and next handoff. Use .harness/review/**.md with Artifact Identity frontmatter for durable review artifacts.

Always make steering and proof searchable: include interactive_status, selection_evidence, route, stage, scope, traceability, validation, safe_to_continue, and blocked_reason. In headless review, use autonomous_assumption only with evidence and confidence; if mutation or readiness authority is ambiguous, ask once or return blocked.