red-teamlisted

# Red Team a Change A structured adversarial review that runs between build (Stage 4) and peer review (Stage 5). The reviewer in Stage 5 looks for what the code is doing wrong; the red team looks for what an adversary, a hostile user, a corner-case input, or a hostile environment can do to make the code fail. ## When to use this - Orchestrator invokes the `red-team` role for **stage-04c** (this is the normal path). - User explicitly asks for an adversarial review of a change ("red team this", "find what could break"). When **not** to use this: - Security-specific concerns (auth, crypto, PII, secrets) — that's the `security-engineer` role at stage-04b. - Code style, conventions, correctness review — that's the `reviewer` role at stage-05. - Test coverage gaps — that's QA at stage-06. ## Phase 1 — Load context Read in this order: 1. `pipeline/brief.md` — what was promised. 2. `pipeline/design-spec.md` — how it was designed (including §Open Technical Questions and §Risk notes — those are red-team gold). 3. `pipeline/pr-backend.md`, `pipeline/pr-frontend.md`, `pipeline/pr-platform.md`, `pipeline/pr-qa.md` — what was actually built. 4. `pipeline/pre-review.md` (Stage 4a) — what's already been caught by lint / typecheck / dep audit. 5. `pipeline/security-review.md` (Stage 4b, if present) — what security has already flagged. **Do not re-find what they found.** 6. `src/**` — the code itself. Read the changed paths fully. The point is to come in with full context. A red-team fi