red-blue-reviewlisted

# Red/Blue Review Use opposing lenses to find what breaks and what defends it. Do not list generic risks. Produce concrete attack paths, failure paths, and mitigations. ## Inputs To Gather - The artifact: code, diff, design, ADR, spec, migration, runbook, or launch plan. - The asset at risk: money, data integrity, availability, privacy, developer time, customer trust. - The threat or failure model: malicious actor, operator error, dependency failure, scale, bad data, ambiguous requirements. - The deployment context: environments, permissions, observability, rollback path. ## Red Team Act like the system will be misused, overloaded, misconfigured, or attacked. Check: - Trust boundaries and privilege escalation. - Input validation and malformed data. - Authentication, authorization, and tenant isolation. - Secrets handling and accidental leakage. - Retry storms, duplicate effects, race conditions, and idempotency gaps. - Silent data corruption and partial writes. - Missing timeouts, circuit breakers, and backpressure. - Operational mistakes: bad deploy, bad config, bad rollback, stale docs. ## Blue Team Defend with practical controls, not wishful thinking. For each credible issue: - Prevention: code/design change that stops it. - Detection: logs, metrics, traces, alerts, invariants, tests. - Containment: rate limits, circuit breakers, feature flags, kill switches. - Recovery: rollback, replay, reconciliation, data repair. - Ownership: who notices and who acts. ## Ou