review-difflisted

# Review Diff — $action One procedure for reviewing a diff. The dispatched persona carries the lens — the code reviewer judges correctness and conventions, the security reviewer judges exploitability — and neither reviews against an idealized rewrite: the diff is judged against the plan it claims to satisfy. ## Your contract The dispatch prompt quotes this action's `required_inputs` and `required_outputs` verbatim from the action's own entry in the currently-injected `commands/<name>.process.yaml`. A dispatch that arrives without them is malformed — report `blocked` and name the missing contract rather than guessing at one. ## Procedure (every action) 1. Read the diff and the plan/scope it claims to satisfy. 2. Every finding needs a concrete scenario behind it — a failure (wrong output, crash, data corruption) or an exploit (who gets in, what they reach) — never a style preference. 3. Tie each finding to specific files/lines, tagged must-fix or worth-noting; an explicit no-findings record is a valid, complete output. 4. Scope creep found in the diff is escalated as a planning matter, never resolved inline. ## Action-specific rules - `diff_review` — `db-administrator` is the supporting lens when the diff contains schema, migration, or query changes. Security-sensitive patterns are flagged for the security pass, never adjudicated here. - `security_pattern_review` — adjudicate what `diff_review` flagged plus your own scan of the diff; every finding carries a concrete expl