code-reviewlisted

# code-review: fresh eyes on the diff, one axis at a time Runs before substantial work is committed, after `verify` has passed. Trivial changes (a typo, a one-line fix with an obvious cause) skip it; everything with a spec gets it. The subject is the actual diff about to be committed, not the intention behind it. ## Ground rules - **Independent axes, fresh eyes each.** Two axes always run (A and B); a third (C) runs only when the diff is security-sensitive, per its own trigger below. If your tool has subagents, give each axis that runs its own subagent with only the inputs named below. Without subagents, run them as sequential passes, re-reading the diff from scratch each time and carrying no conclusions across. - **Skip what tooling already enforces.** Formatting, line caps, denylist, secrets and the rest of `checks/check.mjs` plus the stack gates are the machines' job. A finding a gate would have caught means the gates were not run; stop and run them. - **Report by severity per axis: blocker, major, minor.** The axes are never merged into one ranked list. Each finding names the file and location, states the problem, and proposes the smallest fix. ## First: did this diff weaken a gate? The axes below hand formatting, denylist, secrets and the rest of `checks/check.mjs` to the machines. That hand-off holds only while the machines still run at full strength, so this scan comes first on every review. It is mechanical and needs no fresh eyes: one pass over t