vk-reviewlisted

# The review pass You cannot review your own work in the session that wrote it. You already decided every questionable line was fine. The reviewer must be a fresh context, and it must be hostile. ## Step 1 — Collect the whole change ``` git diff <base>...HEAD # everything committed on this branch git diff HEAD # staged and unstaged git status --short # untracked files — read each one ``` An empty working-tree diff does not mean there is nothing to review. If the branch is ahead of base, *those commits are the change set*. Reviewing an empty diff produces a false clean bill of health. ## Step 2 — Send it out Spawn the `inspector` agent with the **raw diff**. Never a summary — a summary carries your own framing, which is exactly what the review exists to escape. Where a second vendor's CLI is configured and available, start it first, read-only, on the same diff, and let it run while the inspector works. Two vendors disagreeing is a far stronger signal than one model checking itself. If that command errors or returns nothing, proceed on the inspector alone and record the actual error. Never invent its findings, and never report it unavailable without having run it. ## Step 3 — Grade Every finding is one of: - **P0** — fatal at runtime. It will crash, corrupt data, or expose something. - **P1** — wrong behavior under realistic conditions. Silent, which is worse. - **P2** — minor. Will not block shipping. A finding needs a file, a line range,