red-team

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 finding that the brief explicitly declared out-of-scope is wasted; flag it under noted_for_followup, not must-fix.

Phase 2 — Walk the attack surfaces

For each surface below, generate 2–5 concrete scenarios. Skip surfaces that don't apply (e.g. no input boundary for a pure config change). For each scenario produce: the exact input/state/sequence that reproduces it + the resulting failure.

2.1 — Input boundaries

For every external input (HTTP body, query param, file upload, env var, stdin, message-queue payload):

• Empty / null / missing / type-wrong / length-overflow
• Unicode edge cases: surrogate pairs, RTL marks, NULL bytes, BOM, normalization forms
• Injection vectors: SQL fragments, shell metacharacters, path traversal (../), template engine syntax, XSS, SSRF urls
• Numeric edges: 0, -1, MAX_INT, MIN_INT, Infinity, NaN, floating-point precision drift
• Date edges: epoch, far-future, DST boundaries, leap seconds, locale-specific format ambiguity