stress-test

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