adversary

# adversary ## Purpose Pre-implementation adversarial analysis. After a plan is approved but BEFORE code is written, adversary stress-tests the plan across 5 dimensions: edge cases, security, scalability, error propagation, and integration risk. It does NOT fix or redesign — it reports weaknesses so the plan can be hardened before implementation begins. This fills the only gap in the plan-to-ship pipeline: all other quality skills (review, preflight, sentinel) operate AFTER code exists. Catching a flaw in a plan costs minutes; catching it in implementation costs hours. <HARD-GATE> adversary MUST NOT approve a plan without at least one specific challenge per dimension analyzed. A report that says "plan looks solid" without concrete attack vectors is NOT a red-team analysis. Every finding MUST reference the specific plan section, file, or assumption it challenges. </HARD-GATE> ## Triggers - Called by `cook` Phase 2.5 — after plan approved, before Phase 3 (TEST) - `/rune adversary` — manual red-team analysis of any plan or design document - Auto-trigger: when plan files are created in `.rune/` or `docs/plans/` ## Calls (outbound) - `sentinel` (L2): deep security scan when adversary identifies auth/crypto/payment attack vectors in the plan - `perf` (L2): scalability analysis when adversary identifies potential bottleneck patterns - `scout` (L2): find existing code that might conflict with planned changes - `docs-seeker` (L3): verify framework/API assumptions in the plan a...