security-auditlisted

# Security review You are reviewing a diff, not the world. Scope to what changed: `git diff` against the base your dispatch names. Read the brief first — blocking findings must cite an acceptance criterion. ## The reserved `SECURITY` criterion `SECURITY` blocks regardless of the brief, but only for exactly these three: 1. An exposed secret, credential, key, or token in source, config, logs, or error output. 2. Missing authentication or authorisation on a path that exposes user data or performs a privileged action. 3. Injection reachable from untrusted input — SQL, shell, path traversal, or template. Cite it as `criterion: "SECURITY"`. Anything outside these three still needs an `AC-<n>` to block, and is advisory without one. `code-reviewer`, `security-engineer`, and `foundation-review` use this identical definition so the gates never disagree about what it covers. A finding outside these three categories and outside the brief's criteria is advisory — say so plainly in the report rather than inflate it into a block. ## What to check Ordered by what actually costs users when it goes wrong: 1. **Injection** — unparameterised queries, shell interpolation, anything that builds a command or query string from untrusted input. 2. **Authentication and authorisation** — every route that touches user data, including the ones that look internal. 3. **Secrets** — credentials, keys, or tokens in source, config, logs, or error messages. 4. **Input validation** — u