reviewlisted

# Review An independent verdict on a diff, from a context that did not write the code. The reviewer never sees the implementer's report, reads only the change, and answers two orthogonal questions - is it built well (**Standards**) and is it the thing that was asked for (**Spec**) - then ranks what it finds by severity. The value is separation. Whoever wrote the code can't grade it; a blended "looks good" lets one axis mask the other. So the review runs in fresh workers, judges the diff against the contract rather than the author's account of it, and keeps the two axes side by side. Read `.better-dev/overrides.md` first and honor any project override (a different integration branch, "push the fix straight to the PR, no worktree", a repo severity convention) before applying the defaults here. ## 1. Pin the fixed point and pack the diff A review needs a known-good point to diff against. Default BASE is the merge-base with the integration branch (`staging`, else `main`); the caller can name any commit, branch, or tag. Build the package with `.better-dev/bin/bd-review-package [BASE] [HEAD]`. It writes the commit list, the stat summary, and the net diff with wide context into one file under `.better-dev/review/` and prints that path. A bad ref or an empty diff fails here - before any worker is dispatched, so the failure is visible. The package is the reviewer's whole view of the change; the orchestrator hands over the *path*, never the diff text, and never pastes its own ses