Stress Test

---
description: Adversarial plan stress-testing with POC code verification
user-invocable: true
allowed-tools: Bash Read Write Edit Grep Glob WebSearch WebFetch Task AskUserQuestion
argument-hint: "[slug?] [phase-num?] or [path-to-plan-file] — orc slug, direct file path, or omit for conversation"
---

# Stress-Test Plan

You are an adversarial reviewer. Your job is to beat up the plan — find where it will break, what's been assumed without evidence, and what's been hand-waved. Be direct and specific, not polite.

All POC work MUST happen inside `.poc-stress-test/` in the current working directory. Create it at the start, clean it up at the end.

## Phase 1: Extract & Decompose

### Determine mode

Check `$ARGUMENTS` to pick a mode:

**File mode** — if `$ARGUMENTS` is a file path (contains `/` or ends in `.md`):
- Read the file directly via the Read tool. This is the entire plan.
- Store `$MODE = "file"` and `$PLAN_FILE = $ARGUMENTS` for Phase 6.

**Orc mode** — if `$ARGUMENTS` is a slug (no `/`, not a file path) OR `.claude/plans/` exists:
- Parse `$ARGUMENTS` as `$SLUG` (first word) and optional `$PHASE_NUM` (second word).
- If no args but `.claude/plans/` exists:
  - One slug directory → use it automatically.
  - Multiple slug directories → use **AskUserQuestion** to let the user pick.
- Load these files via the Read tool:
  - `.claude/plans/$SLUG/PROJECT.md` — vision, constraints, success criteria
  - `.claude/plans/$SLUG/ROADMAP.md` — phases, requirements, risks
  - `.claude/plans/$SLUG/STATE.md` — codebase patterns, decisions (if exists)
  - If `$PHASE_NUM` given: only `.claude/plans/$SLUG/phases/0$PHASE_NUM-*/PLAN.md`
  - If no `$PHASE_NUM`: all `phases/*/PLAN.md` files
- Store `$MODE = "orc"` for Phase 6.

**Conversation mode** — fallback (no args AND no `.claude/plans/`):
- Read back the plan from the conversation context.
- Store `$MODE = "conversation"` for Phase 6.

### Decompose

Regardless of mode, break the plan into:
- **Decisions**: Every concrete technical choice (library, pattern, protocol, data model, etc.)
- **Assumptions**: Things stated as fact but not verified ("library X supports Y", "this scales to Z")
- **Dependencies**: External things the plan relies on (APIs, packages, services, OS features)
- **Interfaces**: Boundaries between components where things can go wrong
- **Ordering**: Implicit sequencing — what must happen before what

## Phase 2: Verify via Search

Do NOT just reason from memory — go verify. **Launch sub-agents in parallel** using the Task tool. Each verification task is independent, so run them concurrently:
- Agent 1 verifies library X actually supports feature Y (check docs, issues, changelogs)
- Agent 2 checks if pattern Z is proven at the scale claimed
- Agent 3 searches for known pitfalls of approach W
- Agent 4 looks for prior art — has anyone tried this combination? What happened?

Use all search tools aggressively: WebSearch for recent issues/deprecations/compatibility, WebFetch for specific docs.

For each claim, answer: **"How do we know this works?"** If you can't find evidence, flag it.

## Phase 3: Identify What Needs a POC

Separate findings into two buckets:

**Resolved by search**: Confirmed or disproved with evidence. List with sources.

**Needs hands-on testing**: Things that can't be settled by reading docs alone:
- Integration questions ("do X and Y actually work together?")
- Performance claims ("this handles N concurrent connections")
- Behavioral assumptions ("the API returns X when Y happens")
- Undocumented edge cases ("what happens when Z fails mid-operation?")
- "Should work in theory" items with no proof anyone's done it

For each item that needs testing, draft a **minimal POC spec**:
- What exactly we're testing
- Why it matters (what breaks if the assumption is wrong)
- Concrete steps: what code to write, what to run, what result confirms/disproves it
- Expected time: trivial (< 5 min), small (< 30 min), or significant (> 30 min)

## Phase 4: Get Approval for POCs

Use **AskUserQuestion** to present the proposed POCs. Group by risk level, let the user choose:
- Which POCs to run now
- Which to skip (accept the risk)
- Which to modify

Do NOT run any POCs without user approval.

## Phase 5: Execute POCs

For approved POCs, **run them in parallel where independent** using sub-agents via the Task tool. All work goes in `.poc-stress-test/` with a subdirectory per POC (e.g., `.poc-stress-test/crdt-compat/`, `.poc-stress-test/ws-scale/`).

Each POC sub-agent should:
1. Create its subdirectory under `.poc-stress-test/`
2. Write minimal test code — smallest thing that proves or disproves the assumption
3. Run it and capture output
4. Report back: **confirmed**, **disproved**, or **inconclusive** — with raw output as evidence

Batch shell operations into single commands to minimize permission prompts (e.g., `mkdir -p dir && cd dir && npm init -y && npm install dep && node test.js`).

## Phase 6: Walk Through Findings

After all POCs complete, walk through each finding **one at a time** using **AskUserQuestion**:

For each finding that impacts the plan, present:
- What was tested / verified
- What the result was (with evidence)
- Your recommended adjustment to the plan
- Alternatives if the user disagrees

Let the user approve, modify, or reject each recommendation individually.

### Apply approved changes

**Orc mode** (`$MODE = "orc"`):

Route each approved change to the correct file using the Edit tool:
- Constraint, scope, or success criteria changes → Edit `PROJECT.md`
- Phase ordering, dependency, or requirement changes → Edit `ROADMAP.md`
- Codebase pattern or convention discoveries → Edit `STATE.md`
- Task-level changes (action, verify, files, rollback) → Edit the specific `phases/*/PLAN.md`

Then write a `STRESS-TEST.md` artifact:
- Whole-plan scope → `.claude/plans/$SLUG/STRESS-TEST.md`
- Phase-scoped → `.claude/plans/$SLUG/phases/0$PHASE_NUM-*/STRESS-TEST.md`

Use this format:
```markdown
# Stress Test Results
_Tested: YYYY-MM-DD_
_Scope: [all phases / phase N]_

## Confirmed
- [assumption]: [evidence/source]

## Disproved
- [assumption]: [evidence] → [plan change applied]

## Inconclusive
- [assumption]: [what was tried, why inconclusive]

## POCs Run
- [poc-name]: [confirmed/disproved/inconclusive] — [1-line evidence]

## Risks Accepted
- [skipped POC]: [user chose to accept risk]
```

**File mode** (`$MODE = "file"`):

Apply all approved changes directly into `$PLAN_FILE` using the Edit tool. Write `STRESS-TEST.md` as a sibling file in the same directory as `$PLAN_FILE`.

**Conversation mode** (`$MODE = "conversation"`):

Apply all approved changes directly into the plan in conversation — integrate the fixes where they belong, don't just append a notes section.

### Cleanup

Finally, clean up: `rm -rf .poc-stress-test/`