adversary

name	adversary
description	Pre-implementation red-team analysis. Use when a plan is high-risk, critical path, or expensive to reverse. Challenges plans before code is written — finds edge cases, security holes, scalability bottlenecks, error propagation risks, and integration conflicts. Catches flaws at plan time (10x cheaper than post-implementation).
metadata	{"author":"runedev","version":"0.5.0","layer":"L2","model":"opus","group":"quality","tools":"Read, Glob, Grep","emit":"oracle.dispatched, oracle.response, oracle.failed","listen":"agent.stuck, context.preview"}

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.

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.

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 are correct and current
• hallucination-guard (L3): verify that APIs, packages, or patterns referenced in the plan actually exist
• context-engine (L3): (oracle-mode) emit context.preview before bundle build to gate token cost
• session-bridge (L3): (oracle-mode) detach protocol when target model is opus-class for non-blocking dispatch
• council (L3): Step 0.6 — decorrelated multi-perspective critique for CRITICAL-tier plans (one-way-door decisions, auth/payment/crypto/user-data), mode=critique

Called By (inbound)

• cook (L1): Phase 2.5 — after plan approval, before TDD
• plan (L2): optional post-step for critical features
• team (L1): when decomposing large tasks, adversary validates the decomposition
• debug (L2): (oracle-mode) listens to agent.stuck from debug after 3 disproved hypotheses
• fix (L2): (oracle-mode) listens to agent.stuck from fix after 2+ failed attempts
• User: /rune adversary direct invocation

Cross-Hub Connections

• adversary ← cook — plan produced → adversary challenges it → hardened plan feeds Phase 3
• adversary → sentinel — security attack vector identified → sentinel validates depth
• adversary → perf — scalability concern raised → perf quantifies the bottleneck
• adversary → scout — integration risk flagged → scout finds affected code
• adversary → plan — CRITICAL findings → plan revises before implementation
• adversary → council — CRITICAL-tier plan (one-way-door decision, or auth/payment/crypto/user-data) → decorrelated critique before red-teaming

Execution

Step 0: Load Context

1. Read the plan document (from .rune/features/<name>/plan.md, phase file, or user-specified path)
2. Read the requirements document if it exists (.rune/features/<name>/requirements.md from BA)
3. Use scout to identify existing code files that the plan will touch or depend on
4. Identify the plan's core assumptions — what MUST be true for this plan to work?

Step 0.5: Steelman + Pick a Reasoning Lens

Before attacking, steelman the plan's core thesis — restate it in its strongest form (strip weak framing, supply the strongest implied evidence, name what's genuinely good). Attacking a weak paraphrase produces findings the author dismisses with "that's not what I meant." The steelman also seeds the Strength Notes section (Step 6).

The 5 dimensions below answer what to attack. The 5 reasoning modes answer how:

Mode	Core question	Reach for when
Red Team (default)	"How would someone break/exploit/game this?"	auth, payment, user data, public input, perverse incentives. NB: this is persona framing (who attacks, their capability/motivation) — it composes with Step 2's attack-surface inventory, not a duplicate of it
Pre-mortem	"It's 6 months out and this failed — why?"	migrations, infra, architecture, cascading failure
Evidence Audit	"Does the evidence actually support this claim?"	benchmark/"X is faster"/capacity-number justifications
Dialectic	"What's the strongest case for the opposite choice?"	tech/vendor/architecture one-way-door decisions
Socratic	"What is this plan taking for granted?"	vague scope, consensus-driven plans, thin specs

Default to Red Team. Switch or add a second lens when the plan's shape calls for it (signal→mode table + mode mechanics in references/reasoning-modes.md). State which lens you applied per dimension — don't ask the user to pick. Dialectic's synthesis usually produces concrete remediations (likely HARDEN), but maps to REVISE if it exposes a structural flaw in the chosen approach; Socratic's surfaced assumptions and Pre-mortem's narratives become findings.

Step 0.6: Decorrelated Multi-Perspective Gathering (council, CRITICAL-tier only)

adversary's own single pass is one model's opinion, however rigorous. For the subset of plans where being wrong is expensive enough to justify it, call rune:council (mode=critique) before Steps 1-5, instead of (or in addition to) solo analysis.

Trigger — call council when ANY of:

• Step 0.5 selected the Dialectic or Pre-mortem lens (one-way-door architecture/vendor decisions, irreversible migrations — exactly the cases where a second architecture's blind spots differing from yours has the highest expected value)
• The plan touches auth, payment, crypto, or user data at a severity that would otherwise trigger mandatory sentinel escalation (Step 2)
• The user explicitly asks for a second opinion or "gut check" before committing

Do NOT call council for: Quick Challenge mode plans, plans under 3 files with no auth/payment/data logic, or routine feature work — council is opt-in overhead, not a default tax on every adversary run (see council's own Sharp Edges: never auto-fires on every plan).

Request: { question: <steelmanned thesis + the specific risk being tested>, mode: "critique", n: 3, diversity: { prefer_model_families: true }, evidence_required: [reasoning, citation] }. The question MUST be self-contained — council's voices have no access to this conversation.

Consume: fold CouncilResult.agreement.consensus_claims into the relevant dimension's findings below, tagged [council-verified]. Fold agreement.dissent into that dimension's findings too, but tagged [council-dissent] — dissent is information, not something to resolve by picking a side. If decorrelation: NO_DECORRELATION, do not describe the result as a second opinion in the report — say plainly that no independent model family was reachable and the additional voices were same-family subagents.

Step 1: Edge Case Analysis

Challenge the plan's handling of boundary conditions.

For each input/output/state transition in the plan, ask:

• Empty/zero: What happens with no data, zero items, empty strings, null users?
• Overflow: What happens at MAX — 10K items, 1MB payload, 1000 concurrent users?
• Race conditions: What if two operations happen simultaneously? Can state become inconsistent?
• Partial failure: What if step 3 of 5 fails? Is there rollback? Or orphaned state?
• Invalid combinations: What input combinations are technically possible but semantically nonsensical?

EDGE_CASE_TEMPLATE:
- Scenario: [specific edge case]
- Plan assumption: [what the plan assumes]
- Attack: [how this breaks]
- Impact: [what fails — data loss, crash, wrong result, security breach]
- Remediation: [1-sentence fix suggestion]

Step 2: Security Attack Vectors

Analyze the plan for security weaknesses BEFORE any code exists.

• Input trust boundaries: Where does the plan accept external input? Is validation specified?
• Authentication gaps: Does the plan assume auth exists? Are there unprotected routes or actions?
• Data exposure: Could the planned API responses leak sensitive fields? Are there over-fetching risks?
• Privilege escalation: Can a normal user reach admin functionality through the planned flow?
• Injection surfaces: Does the plan involve dynamic queries, template rendering, or shell commands?
• Dependency risk: Does the plan introduce new dependencies? Are they well-maintained and trusted?

If any auth, crypto, or payment logic is in the plan: MUST call rune:sentinel for deep analysis.

SECURITY_TEMPLATE:
- Vector: [attack type — OWASP category if applicable]
- Entry point: [which part of the plan is vulnerable]
- Exploit scenario: [how an attacker would use this]
- Severity: CRITICAL | HIGH | MEDIUM
- Remediation: [what the plan should specify to prevent this]

Step 3: Scalability Stress Test

Project the plan forward — what happens at 10x and 100x scale?

• N+1 queries: Does the plan describe data fetching that will create N+1 database calls?
• Missing pagination: Does the plan handle lists without specifying limits?
• Synchronous bottlenecks: Are there blocking operations in the hot path?
• Cache invalidation: If caching is planned, what happens when data changes? Stale reads?
• State growth: Does the plan accumulate state (in-memory, database, file system) without cleanup?
• External service limits: Does the plan account for rate limits on third-party APIs?

If bottleneck patterns detected: call rune:perf for quantitative analysis.

SCALE_TEMPLATE:
- Bottleneck: [what breaks at scale]
- Current plan: [what the plan specifies]
- At 10x: [what happens]
- At 100x: [what happens]
- Remediation: [what to add to the plan]

Step 4: Error Propagation Analysis

Trace failure paths through the planned system.

• Cascade failures: If Service A fails, does the plan specify what happens to B, C, D?
• Retry storms: Does the plan include retries? Could retries amplify the failure?
• Silent failures: Are there operations that could fail without anyone knowing?
• Inconsistent state: If a multi-step operation fails midway, is the data left in a valid state?
• User experience: When things fail, what does the user see? Is there a degraded mode?
• Recovery path: After failure + fix, can the system resume? Or does it require manual intervention?

ERROR_TEMPLATE:
- Failure point: [where in the plan]
- Propagation: [what else breaks]
- User impact: [what the user experiences]
- Recovery: [how to get back to good state]
- Missing in plan: [what the plan should specify]

Step 5: Integration Risk Assessment

Check for conflicts with existing code and architecture.

• Use rune:scout to find all files the plan will modify or depend on
• Breaking changes: Does the plan modify shared interfaces, types, or APIs that other code depends on?
• Migration gaps: Does the plan require database migrations? Are they reversible?
• Configuration drift: Does the plan add new environment variables, feature flags, or config files?
• Test invalidation: Will existing tests break from the planned changes?
• Deployment ordering: Does the plan require specific deployment sequence? (DB first, then API, then frontend?)

INTEGRATION_TEMPLATE:
- Conflict: [what clashes]
- Existing code: [file:line that would be affected]
- Plan assumption: [what the plan assumes about existing code]
- Reality: [what the existing code actually does]
- Remediation: [how to resolve the conflict]

Step 6: Verdict and Report

Synthesize all findings into an actionable report.

Before reporting, apply rigor filter:

• Only report findings you can justify with specific references to the plan or codebase
• Do NOT report theoretical concerns that require 3+ unlikely conditions to trigger
• Prioritize findings that would cause the MOST wasted implementation time if discovered later
• Consolidate related findings — "auth is underspecified" not 5 separate auth findings

Verdict logic:

• Any CRITICAL finding → REVISE (plan must be updated before Phase 3)
• 3+ HIGH findings → REVISE
• HIGH findings with clear remediations → HARDEN (add remediations to plan, then proceed)
• Only MEDIUM/LOW findings → PROCEED (note findings for implementation awareness)
• If council was invoked (Step 0.6) and returned needs_decision: true → the verdict cannot be PROCEED regardless of adversary's own findings; surface the unresolved dissent to the user instead of silently picking a side

After reporting:

• If verdict is REVISE: return to plan with findings attached as constraints
• If verdict is HARDEN: present remediations to user for plan update
• If verdict is PROCEED: pass findings to cook Phase 3 as implementation notes

Output Format

## Adversary Report: [feature/plan name]
- **Plan analyzed**: [path to plan file]
- **Dimensions checked**: [which of the 5 were relevant]
- **Reasoning lens**: [Red Team | Pre-mortem | Evidence Audit | Dialectic | Socratic — and why]
- **Council**: [not invoked | MULTI_FAMILY (N families) | NO_DECORRELATION — same-family subagents only]
- **Findings**: [count by severity]
- **Verdict**: REVISE | HARDEN | PROCEED

### CRITICAL
- [ADV-001] [dimension]: [description with plan reference]
  - Attack: [how this breaks]
  - Remediation: [specific fix]

### HIGH
- [ADV-002] [dimension]: [description with plan reference]
  - Attack: [how this breaks]
  - Remediation: [specific fix]

### MEDIUM
- [ADV-003] [dimension]: [description]

### Strength Notes
- [what the plan does well — adversary is harsh but fair]

### Verdict
[Summary: why REVISE/HARDEN/PROCEED, what to do next]

Workflow Modes

Full Red-Team (default)

All 5 dimensions analyzed. Used for new features, architectural changes, security-sensitive plans.

Quick Challenge (for smaller plans)

Skip Steps 3-4 (scalability, error propagation). Focus on edge cases, security, and integration. Trigger: plan modifies < 3 files AND no auth/payment/data logic.

Security-Focused

Steps 2 and 5 only (security + integration). Used when sentinel requests adversarial pre-analysis. Trigger: plan involves auth, crypto, payment, or user data handling.

Mode: oracle (v0.2.0)

Triggered by: agent.stuck signal — emitted by debug (after 3 disproved hypotheses) or fix (after 2+ failed attempts on the same file).

Purpose: Break confirmation-bias loops. The same agent that read auth.ts 3 times has formed a theory it cannot un-form. Oracle-mode dispatches a stateless second-model pass with explicit "no prior context" framing, breaking the semantic loop that scout's zoom-out mode (structural pivot) cannot.

When NOT to use:

• Single hypothesis cycle — escalate only after 3 cycles in debug or 2 attempts in fix
• Trivial single-file bugs — overhead exceeds value
• When the user already knows the answer — they're trying to validate, not diagnose

Protocol:

1. Pre-bundle gate — emit context.preview to context-engine first; abort if action=block
2. Build context bundle — see references/context-bundle-format.md for exact format
3. Dispatch — emit oracle.dispatched signal; route via session-bridge detach if target model is opus-class (non-blocking). For genuine architectural independence (security-critical logic, irreversible ops, a loop the in-mesh model cannot break), prefer a different-architecture external CLI (Gemini/Codex) over another Claude instance — a same-family reviewer shares blind spots with the author. Invoke it via the safe transport in references/cross-model-escalation.md: explicit per-call user authorization, read-only sandbox, stdin not inline args, binary pre-flight. Never auto-invoke an external CLI in non-interactive contexts — skip and announce.
4. Wait for response — synchronous if model is sonnet-class, polled via .rune/oracle-pending/<id>.json if opus-class
5. Validate response — every claim MUST cite file:line. Strip + warn on uncited claims (oracle.failed if all claims uncited)
6. Emit response — oracle.response carries the validated diagnosis, consumed by debug/fix to override or refine their current hypothesis

Bundle format (mandatory regex-validated):

[SYSTEM] You are Oracle, a focused one-shot problem solver. You have NO prior context — assume zero project knowledge. Cite file:line for every claim. Reject any claim you cannot ground in the provided files.

[USER] <agent stuck after N hypothesis cycles. What is the most likely root cause not yet considered?>

### File 1: <relative/path/to/file.ts>
<file content, normalized whitespace, max 4k chars per file>

### File 2: <...>
<...>

Hard caps:

• Bundle ≤ 100k tokens (estimated via char count × 0.25)
• Per-file ≤ 4k chars (truncate with explicit ... [truncated] marker)
• Max 12 files per bundle (force caller to prune larger sets)

Response contract — Oracle reply MUST contain:

• A primary diagnosis (1-3 sentences)
• At least 1 file:line citation per claim
• An action recommendation (specific edit, additional file to read, hypothesis to test)

Replies failing this contract are rejected — oracle.failed emitted, primary agent continues without second opinion.

See references/oracle-mode.md for the full protocol and integration with debug/fix. See references/cross-model-escalation.md for the safe external-CLI transport when the second opinion should come from a different model architecture.

Constraints

1. MUST challenge every plan — no rubber-stamping. At minimum, one finding per analyzed dimension
2. MUST NOT modify the plan or write code — adversary is read-only analysis
3. MUST reference specific plan sections or existing code for every finding
4. MUST escalate to sentinel when auth/crypto/payment attack vectors are identified
5. MUST use concrete attack scenarios, not vague warnings ("could be a problem" is NOT a finding)
6. MUST NOT block on MEDIUM/LOW findings — only CRITICAL and HIGH trigger REVISE verdict
7. MUST include Strength Notes — adversary finds weaknesses AND acknowledges what's well-designed 7b. SHOULD steelman the plan's core thesis before challenging it (Step 0.5) — a challenge that only lands against a weaker paraphrase is a weak finding, not a CRITICAL/HIGH. If steelmanning reveals a dimension is genuinely solid, record "No findings after steelman" for that dimension — that satisfies the per-dimension HARD-GATE
8. (oracle-mode) MUST emit context.preview BEFORE building the bundle — abort if context-engine action=block
9. (oracle-mode) MUST validate every Oracle reply citation against the provided files — reject uncited claims as oracle.failed

Mesh Gates

Gate	Requires	If Missing
Plan Gate	A plan document exists (from plan skill or user-provided)	Cannot run — ask for plan first
Codebase Gate	Access to existing codebase (for integration checks)	Skip Step 5, note in report

Sharp Edges

Failure Mode	Severity	Mitigation
Over-challenging — nitpicking every line of the plan	HIGH	Rigor filter: only findings you can justify with specific references. Skip theoretical 3+ condition chains
Strawmanning — attacking a weaker version of the plan than what's written	HIGH	Step 0.5: steelman the thesis first; a challenge that only lands against the weak reading is dropped
One-lens tunnel vision — red-teaming a decision that needed dialectic/evidence-audit	MEDIUM	Step 0.5 signal→mode table: match the reasoning lens to the plan's shape, state which lens you applied
False security alarms — flagging secure patterns as vulnerable	HIGH	Call sentinel for validation before reporting security findings as CRITICAL
Analysis paralysis — too many findings block all progress	MEDIUM	Max 3 CRITICAL + 5 HIGH. If more found, consolidate or prioritize top impact
Missing context — challenging plan without understanding existing codebase	HIGH	Step 0 MUST load existing code context via scout before challenging
Scope creep — reviewing existing code quality instead of plan quality	MEDIUM	Adversary reviews THE PLAN, not the codebase. Existing code is context only
Redundancy with review/preflight — duplicating post-implementation checks	MEDIUM	Adversary operates PRE-implementation only. Never run adversary on existing code
(oracle-mode) Bundle exceeds token cap — caller didn't prune	HIGH	Caller MUST run context.preview first; adversary fails fast with oracle.failed instead of silently truncating signal
(oracle-mode) Oracle reply has no citations — model improvised	CRITICAL	Reject reply with oracle.failed. Primary agent continues without second opinion (better than acting on hallucination)
(oracle-mode) Loop: oracle reply triggers another agent.stuck	HIGH	Cap at 1 oracle dispatch per primary-agent stuck cycle. Subsequent stucks must escalate to user
(cross-model) External CLI invoked without authorization or in non-interactive run	CRITICAL	Per-call user authorization required; non-interactive → skip + announce. See references/cross-model-escalation.md
(cross-model) Bundle interpolated into shell args — embedded $(...) executes	CRITICAL	Always pass via stdin from a temp file; read-only sandbox. Never inline -p "<bundle>"
(cross-model) Rubber-stamping the external reviewer's verdict	MEDIUM	Reply is data, not ruling — reconcile against the artifact; classify each finding
(council) Reporting council output as consensus when decorrelation is NO_DECORRELATION	CRITICAL	Step 0.6 consume rule: report the decorrelation stamp plainly, never imply independent validation from same-family subagents
(council) Calling council on every plan, not just CRITICAL-tier	MEDIUM	Step 0.6 trigger list is explicit — Dialectic/Pre-mortem lens, auth/payment/crypto/user-data, or explicit user request only

Done When

• Plan thesis steelmanned before challenging (Step 0.5) — reasoning lens(es) selected and stated
• All relevant dimensions analyzed (minimum: edge cases + security + integration)
• Every finding references specific plan section or codebase file
• Security-sensitive plans escalated to sentinel (or confirmed not security-relevant)
• Verdict rendered: REVISE, HARDEN, or PROCEED
• Findings formatted for consumption by cook Phase 3 (if PROCEED) or plan (if REVISE)
• Strength Notes section acknowledges well-designed aspects of the plan
• (oracle-mode) If dispatched: response cited file:line for each claim, or oracle.failed emitted with rejection reason
• (council) If CRITICAL-tier trigger matched: council invoked before Steps 1-5, its decorrelation stamp reported plainly, consensus/dissent folded into the relevant dimension findings

Returns

Artifact	Format	Location
Adversary Report	Markdown	inline (stdout)
Threat findings	Structured list (CRITICAL/HIGH/MEDIUM)	inline
Risk matrix per dimension	Table	inline
Verdict + remediation list	Markdown	inline
Hardened plan notes (if PROCEED)	Text	passed to cook Phase 3

Cost Profile

~4000-8000 tokens input (plan + codebase context), ~2000-3000 tokens output. Opus model for adversarial depth. Runs once per feature plan — high cost justified by preventing wasted implementation cycles. When Step 0.6 fires (CRITICAL-tier only): add council's cost profile (~1500-4000 tokens per voice × 2-5 voices) — reserved for the minority of plans where being wrong is expensive.

Scope guardrail: adversary reviews THE PLAN only — never audits existing codebase quality or rewrites code.