thevoidforge 21.0.10 → 21.0.12

package/dist/.claude/commands/dangerroom.md

@@ -0,0 +1,74 @@
+# /dangerroom — The Danger Room (Mission Control Dashboard)
+
+> *"The Danger Room is where X-Men train. It's where your project gets forged."*
+
+## What It Does
+
+Starts the VoidForge wizard server and opens the Danger Room dashboard in your browser. The Danger Room shows real-time build ops, growth metrics, campaign status, treasury data, and heartbeat monitoring — all in one place.
+
+## Usage
+
+```
+/dangerroom [install|start|status|stop]
+```
+
+## Modes
+
+### `/dangerroom` or `/dangerroom start`
+
+Start the wizard server and open the Danger Room:
+
+1. Check if the wizard server is already running (check port 3141)
+2. If not running: start with `node wizard/server.js` or `npx voidforge start`
+3. Open `http://localhost:3141/danger-room` in the default browser
+4. If Cultivation is installed: opens to `#growth` tab by default
+5. **Remote server:** If running on EC2/VPS where port 3141 is not publicly exposed, guide the user to use an SSH tunnel: `ssh -i your-key.pem -L 3141:localhost:3141 user@host` — then open `http://localhost:3141/danger-room` in their local browser. (Field report #122)
+
+### `/dangerroom install`
+
+Alias for starting the wizard server. Ensures the server is running and the Danger Room is accessible. If the project uses the scaffold branch (no packages/voidforge/wizard/server.ts), report: "The Danger Room requires the main branch. Run `git checkout main` or install VoidForge with `npx voidforge init`."
+
+### `/dangerroom status`
+
+Also available as `--status` flag for consistency.
+
+Check the current state:
+- Is the wizard server running? (check port 3141)
+- Which tabs are available? (Ops always; Growth/Campaigns/Treasury/Heartbeat/Deep Current if Cultivation installed)
+- Is the heartbeat daemon running?
+- Last known URL
+
+### `/dangerroom stop`
+
+Stop the wizard server if running.
+
+## Tabs
+
+| Tab | What It Shows | Available When |
+|-----|--------------|----------------|
+| **Ops** | Campaign timeline, phase pipeline, findings, experiments, PRD coverage, prophecy graph | Always |
+| **Growth** | Revenue/spend/net KPIs, ROAS by platform, traffic sources, conversion funnel | Cultivation installed |
+| **Campaigns** | Ad campaign table, A/B test groups, agent recommendations | Cultivation installed |
+| **Treasury** | Financial summary, budget utilization, platform connections, reconciliation | Cultivation installed |
+| **Heartbeat** | Daemon status, token health, scheduled jobs, anomaly alerts | Cultivation installed |
+| **Deep Current** | Situation model, campaign proposals, prediction accuracy, autonomy status | Deep Current initialized |
+
+## Global Elements
+
+- **Freeze button** — visible across all tabs when Cultivation is installed. Emergency pause on all automated spending.
+- **Agent ticker** — real-time feed of agent activity at the bottom of every tab.
+- **Sidebar** — context gauge, version, deploy status, tests, cost (visible across all tabs).
+
+## Prerequisites
+
+- Node.js installed
+- Port 3141 available (or set `VOIDFORGE_PORT` env var)
+- The `packages/voidforge/wizard/server.ts` file must exist. If it does not (scaffold/core users):
+  1. Offer: "The Danger Room requires the wizard server. Pull it from upstream? [Y/n]"
+  2. On yes: `git fetch voidforge main 2>/dev/null || git remote add voidforge https://github.com/tmcleod3/voidforge.git && git fetch voidforge main` then `git checkout voidforge/main -- packages/voidforge/`
+  3. Run `npm install` to install wizard dependencies
+  4. Proceed with `/dangerroom start`
+  5. On no: stop with "Run manually: `git checkout voidforge/main -- packages/voidforge/`"
+
+## Arguments
+$ARGUMENTS

package/dist/.claude/commands/debrief.md

@@ -0,0 +1,178 @@
+Bashir examines the patient. Time to diagnose.
+
+## Context Setup
+1. Read `/docs/methods/FIELD_MEDIC.md` for operating rules
+2. Read `/logs/build-state.md`, `/logs/assemble-state.md`, `/logs/campaign-state.md`
+3. Read recent git history: `git log --oneline -20`
+
+## Step 0 — Reconstruct the Timeline (Ezri)
+
+Ezri reads the session's history and reconstructs what happened:
+
+1. Read all `/logs/` files — build state, assemble state, campaign state, phase logs
+2. Read `git log` — all commits from this session/campaign
+3. Read any error patterns — repeated fixes, reverted changes, multiple attempts
+4. Produce a timeline: what was attempted, what succeeded, what failed, what required multiple attempts
+
+If `$ARGUMENTS` contains `--campaign`, analyze the full campaign history.
+If `$ARGUMENTS` contains `--session`, analyze just this session.
+Default: auto-detect scope from available logs.
+
+## Step 1 — Investigate Root Causes (O'Brien)
+
+For each failure, difficulty, or retry identified by Ezri:
+
+Classify the root cause:
+- **Methodology gap** — missing step, wrong order, blind spot in the protocol
+- **Tooling limitation** — can't run the app, can't generate assets, missing capability
+- **Communication failure** — agent missed context, wrong file read, lost state
+- **Scope issue** — too much in one mission, wrong grouping, mixed requirement types
+- **Framework-specific** — React render loop, route collision, state management bug
+- **External dependency** — needs credentials, needs user input, needs design assets
+
+Map each root cause to the VoidForge component responsible (which command, which agent, which method doc).
+
+## Step 2 — Propose Solutions (Nog)
+
+For each root cause, Nog proposes a fix that works within VoidForge's existing framework:
+
+- New agent? → name it from the correct universe, define the role
+- New step in existing command? → specify where it goes in the sequence
+- New checklist item? → specify which agent gets it
+- New pattern? → write it with code examples
+- Method doc update? → specify the file and section
+
+**Constraint:** All proposals must reference existing VoidForge concepts (agents, phases, commands, patterns). No solutions that require reimagining the system.
+
+## Step 2.5 — Operational Learning Extraction (O'Brien + Nog)
+
+After root cause analysis (Step 1) and before writing the report (Step 3), check if any findings are project-scoped operational learnings — facts that matter in future sessions but don't belong in cross-project methodology. See FIELD_MEDIC.md Step 2.5 for full extraction criteria and entry format.
+
+For each candidate, draft a structured entry (title, category, verified date, scope, evidence, context). Present to user: *"Bashir found [N] operational learnings worth preserving. Review and approve for LEARNINGS.md?"*
+
+Approved entries written to `docs/LEARNINGS.md` (created on first use). Hard cap: 50 active entries.
+
+## Step 2.5b — Promotion Analysis (Wong)
+
+After extraction, Wong checks `docs/LESSONS.md` for lesson clusters AND checks `docs/LEARNINGS.md` for promotable entries (appeared in 2+ projects):
+- If 3+ lessons share the same category AND target the same method doc → Wong drafts a specific method doc update
+- Present for user approval: "Wong recommends promoting these lessons into [method doc] [section]: [proposed text]. Approve?"
+- If approved: apply the change, mark lessons as "Promoted to: [doc]" in LESSONS.md
+- If submitting upstream (`--submit`): include the proposed change in the GitHub issue body
+
+## Step 3 — Write the Report (Jake)
+
+Produce a structured post-mortem:
+
+```markdown
+# Field Report — [Project Name]
+## Filed by: Bashir (Post-Mission Analysis)
+## Date: YYYY-MM-DD
+## Scope: [campaign / session / specific mission]
+
+### What Happened
+[Timeline from Ezri]
+
+### What Went Wrong
+[Root causes from O'Brien — categorized by type]
+
+### Proposed Fixes
+[Solutions from Nog — with specific file/agent/command references]
+
+### Severity Assessment
+- Methodology flaw (affects all users) vs. edge case (specific project)
+- Frequency: will this happen often or was it unusual?
+- Impact: minutes, hours, or days of rework?
+
+### Files That Should Change in VoidForge
+| File | Proposed Change | Priority |
+|------|----------------|----------|
+```
+
+## Step 4 — User Review
+
+Present the full report. The user can:
+- `[submit]` → create GitHub issue on tmcleod3/voidforge (Step 5)
+- `[save]` → save to `/logs/debrief-YYYY-MM-DD.md`
+- `[edit]` → user modifies before submitting
+- `[skip]` → discard
+
+**When `--submit` is specified:** Present the full report, then proceed directly to Step 5 without re-asking "shall I submit?" The flag already signals intent — showing the report fulfills the review obligation, and the user can interrupt with `[edit]` if they spot an issue. Do NOT skip the report presentation step — the user must always see the full report before it goes out. The `--submit` flag enables auto-proceed, not auto-skip.
+
+## Step 5 — Submit to Starfleet (GitHub Issue)
+
+If user approves submission:
+1. Check for `gh` CLI authentication or `github-token` in vault
+2. **Always submit to `tmcleod3/voidforge`.** Field reports are methodology feedback — they belong upstream regardless of which project found the issue. Use `--repo tmcleod3/voidforge` explicitly.
+3. Create issue on `tmcleod3/voidforge` with:
+   - Title: `Field Report: [one-line summary]`
+   - Label: `field-report`
+   - Body: the full post-mortem markdown
+4. Confirm: "Report filed — Starfleet will review. Issue #XX"
+
+If `$ARGUMENTS` contains `--dry-run`, generate report but skip submission.
+
+## Privacy
+
+The submitted report contains:
+- Session timeline (what commands ran, what findings emerged)
+- Root cause analysis (methodology gaps identified)
+- Proposed solutions (specific VoidForge changes)
+
+It does NOT contain:
+- Source code from the user's project
+- Credentials, API keys, or secrets
+- File contents (only file names if relevant to the methodology issue)
+- Personal information
+
+The user reviews and approves every word before submission.
+
+## Step 6 — Inbox Mode (--inbox)
+
+If `$ARGUMENTS` contains `--inbox`, skip Steps 0-5 and triage incoming field reports instead:
+
+1. **Detect the current repository** via `gh repo view --json nameWithOwner`. Inbox mode reads from the current repo — when triaging, you work on whatever project you're in.
+2. Fetch open field reports: `gh issue list --repo [current-repo] --label field-report --state open --json number,title,body,createdAt`
+3. If no open reports → "Bashir's inbox is empty. No field reports pending."
+4. For each report:
+   - Read the full body
+   - Extract: severity, root causes, proposed fixes
+   - Check which fixes are already shipped (grep the codebase for the proposed changes)
+   - Summarize in one line
+5. Present the inbox:
+   ```
+   ═══════════════════════════════════════════
+     BASHIR'S INBOX — Field Reports
+   ═══════════════════════════════════════════
+
+     [count] open field reports.
+
+     #N  [Title] — [severity]
+         Key finding: [one-line summary]
+         Status: [N already fixed / N remaining]
+
+     [triage #N / triage all]
+   ═══════════════════════════════════════════
+   ```
+6. When user selects an issue to triage:
+   - Read the full issue body
+   - For each proposed fix, classify as:
+     - `accept` — valid finding, should be implemented
+     - `already-fixed` — check the codebase, this was already addressed
+     - `wontfix` — edge case, not worth the complexity
+     - `needs-info` — can't evaluate without more context
+   - For accepted fixes: list the specific file changes with line-level detail
+   - Present triage results to user
+   - On user approval:
+     - Apply accepted fixes (modify method docs, commands, patterns)
+     - Comment on the GitHub issue with triage results
+     - Close the issue if fully addressed: `gh issue close <number> --comment "Triaged and resolved."`
+7. After all issues processed, summarize: "Inbox cleared. [N] issues triaged, [N] fixes applied."
+
+## Arguments
+- No arguments → full debrief of current session
+- `--submit` → generate, present for review, then submit as GitHub issue after user approval
+- `--inbox` → read incoming field reports from GitHub, triage and apply fixes (upstream repo only)
+- `--campaign` → analyze the full campaign (all missions)
+- `--session` → analyze just this session
+- `--dry-run` → generate report but don't submit

package/dist/.claude/commands/deploy.md

@@ -0,0 +1,99 @@
+# /deploy — Kusanagi's Deploy Agent
+
+> *"The net is vast and infinite. But your code isn't on it until you deploy."*
+
+Read `/docs/methods/DEVOPS_ENGINEER.md` for operating rules (see "Deploy Automation" section).
+
+## Context Setup
+1. Read PRD frontmatter for `deploy:` target (vps, vercel, railway, docker, static, cloudflare)
+2. Read `/logs/deploy-state.md` — if exists, check last deploy status
+3. Read `.env` or vault for deploy credentials (SSH_HOST, SSH_KEY_PATH, VERCEL_TOKEN, etc.)
+4. Check `git status` — refuse to deploy with uncommitted changes
+
+## Step 1 — Target Detection (Kusanagi)
+
+Read deploy target from PRD frontmatter. If not specified, scan for evidence:
+- `vercel.json` or `.vercel/` → Vercel
+- `railway.json` or `railway.toml` → Railway
+- `Dockerfile` or `docker-compose.yml` → Docker
+- `SSH_HOST` in .env or vault → VPS/EC2
+- `wrangler.toml` → Cloudflare Workers/Pages
+- None found → ask: "Where should this deploy? [vps/vercel/railway/docker/static]"
+
+## Step 2 — Pre-Deploy Checks (Levi)
+
+Levi verifies the deploy is safe:
+1. **Build passes:** `npm run build` (or equivalent) must succeed
+2. **Tests pass:** `npm test` must pass (if test suite exists)
+3. **No uncommitted changes:** `git status` clean
+4. **Credentials available:** SSH key, API token, or platform credentials accessible
+5. **Version tagged:** Current version from VERSION.md matches the commit being deployed
+6. If any check fails → ABORT with clear error message
+
+## Step 3 — Deploy Execution (Levi)
+
+Execute the deploy strategy for the detected target:
+
+**VPS/EC2:**
+```
+1. ssh -i $KEY $USER@$HOST "cd /opt/app && git pull origin main"
+2. ssh ... "npm ci --production"
+3. ssh ... "npx prisma migrate deploy" (if Prisma detected)
+4. ssh ... "npm run build"
+5. ssh ... "pm2 restart ecosystem.config.js" (or systemd restart)
+```
+
+**Vercel:** `vercel --prod --token $VERCEL_TOKEN`
+**Railway:** `railway up` or git push to Railway remote
+**Docker:** `docker build -t app . && docker push && ssh ... "docker pull && docker restart"`
+**Static/Cloudflare:** `wrangler deploy` or S3 sync
+
+## Step 4 — Health Check (L)
+
+After deploy completes:
+1. Wait 10 seconds for service startup
+2. Curl the health endpoint: `curl -sf https://$DEPLOY_URL/api/health` or the root URL
+3. Verify HTTP 200 response within 30 seconds
+4. If health check fails → Step 5 (rollback)
+5. If healthy → log success to deploy-state.md
+
+## Step 5 — Rollback (Valkyrie)
+
+If health check fails:
+1. **VPS:** `ssh ... "git checkout HEAD~1 && npm ci && npm run build && pm2 restart"`
+2. **Vercel:** `vercel rollback --token $VERCEL_TOKEN`
+3. **Docker:** `ssh ... "docker restart [previous-image]"`
+4. Re-run health check on rolled-back version
+5. Log rollback to deploy-state.md with timestamp and reason
+
+## Step 6 — Report
+
+```
+═══════════════════════════════════════════
+  DEPLOY COMPLETE
+═══════════════════════════════════════════
+  Target:     [vps | vercel | railway | docker]
+  URL:        https://your-app.com
+  Version:    v2.9.0
+  Commit:     abc123
+  Health:     ✓ 200 OK (142ms)
+  Timestamp:  2026-03-22T12:00:00Z
+═══════════════════════════════════════════
+```
+
+Update `/logs/deploy-state.md` with deploy results.
+
+## Arguments
+- No arguments → detect target and deploy
+- `--staging` → deploy to staging/preview (if target supports it)
+- `--rollback` → rollback to previous deploy
+- `--status` → show current deploy state without deploying
+- `--dry-run` → show what would be deployed without executing
+
+## Safety Rails
+- Never deploy with uncommitted changes
+- Never deploy without a passing build
+- Always health check after deploy
+- Always rollback on health check failure
+- Deploy log with timestamps for audit trail
+- In blitz mode at campaign end: auto-deploy after Victory Gauntlet passes

package/dist/.claude/commands/devops.md

@@ -0,0 +1,143 @@
+# /devops — Kusanagi's Infrastructure & Deploy
+
+## Context Setup
+1. Read `/logs/build-state.md` — understand current project state
+2. Read `/docs/PRD.md` frontmatter — check `deploy` value to determine target
+3. Read `/docs/methods/DEVOPS_ENGINEER.md`
+
+## Agent Deployment Manifest
+
+**Lead:** Kusanagi (Anime — Ghost in the Shell)
+
+**Core team (always deployed):**
+- **Senku** (Dr. Stone) — provisioning: server setup, dependencies, runtime, idempotent scripts
+- **Levi** (Attack on Titan) — deployment: process management, zero-downtime, rollback scripts
+- **Spike** (Cowboy Bebop) — networking: reverse proxy, DNS, TLS, firewall, CORS headers
+- **L** (Death Note) — monitoring: health checks, uptime, alerting, log aggregation
+- **Bulma** (Dragon Ball) — backup: database dumps, file backup, retention, restore testing
+- **Holo** (Spice & Wolf) — cost: resource sizing, instance selection, cost estimation, optimization
+
+**Extended team (deployed on full infra reviews):**
+- **Valkyrie** (Marvel/Anime crossover) — disaster recovery: failover, data center redundancy, RTO/RPO
+- **Vegeta** (Dragon Ball) — scaling: horizontal scaling, load balancing, auto-scaling policies
+- **Trunks** (Dragon Ball) — migration: database migration strategy, zero-downtime schema changes
+- **Mikasa** (Attack on Titan) — security hardening: SSH config, fail2ban, unattended upgrades
+- **Erwin** (Attack on Titan) — strategy: multi-environment management, staging/production parity
+- **Mustang** (FMA) — orchestration: Docker Compose, container networking, service discovery
+- **Olivier** (FMA) — cold region: CDN configuration, edge caching, geographic distribution
+- **Hughes** (FMA) — documentation: runbook writing, infrastructure diagrams, onboarding docs
+- **Calcifer** (Ghibli) — energy: resource efficiency, idle scaling, sleep/wake optimization
+- **Duo** (Gundam) — CI/CD: GitHub Actions, pipeline design, automated testing in deploy
+
+## Deploy Target Branching
+
+The infrastructure sequence adapts based on `deploy` in PRD frontmatter:
+
+| Target | Senku | Levi | Spike | L | Bulma |
+|--------|-------|------|-------|---|-------|
+| `vps` | Full provision.sh | PM2 + deploy.sh | Caddy/Nginx + DNS | Health + uptime | DB backup + cron |
+| `vercel` | Skip | `vercel.json` config | DNS only | Vercel analytics | Vercel Postgres backup |
+| `railway` | Skip | railway.toml config | DNS only | Railway metrics | Railway backup |
+| `docker` | Dockerfile + compose | docker-compose deploy | Traefik/Caddy | Container health | Volume backup |
+| `static` | Skip | Static hosting config | DNS + CDN | Uptime monitor only | Skip |
+
+## Sequence — VPS (full)
+
+### Senku — Provisioning
+Create `/scripts/provision.sh`:
+- System updates, tools, runtime (Node/Python/Ruby per stack)
+- Database (Postgres/MySQL), Redis if needed
+- Reverse proxy (Caddy preferred), process manager (PM2)
+- App user (non-root), firewall (22/80/443 only), fail2ban
+- Log rotation, swap, unattended security upgrades
+- Script must be idempotent — safe to run twice
+
+### Levi — Deployment
+Create `/scripts/deploy.sh`:
+- Pull latest code → `npm ci` → generate ORM → migrate → build → reload PM2 → health check
+- Auto-rollback on health check failure
+- Create `/scripts/rollback.sh` for manual rollback
+
+### Spike — Networking
+- Caddyfile or nginx config with HTTPS, gzip, security headers
+- SSL auto-renewal
+- DNS records documented
+- SPF/DKIM/DMARC for email sending
+
+### PM2 Config
+Create `ecosystem.config.js`:
+- Web: cluster mode (>= 2 instances), memory limit
+- Workers: fork mode, memory limit
+- Auto-start on reboot (`pm2 startup` + `pm2 save`)
+
+### L — Monitoring
+- Health endpoint: `/api/health` checking DB, Redis (if used), disk space
+- External uptime monitor (document which service)
+- Structured request logging (method, path, status, duration)
+- Error tracking integration
+- Slow query logging (>1s)
+- Alerts: CPU >80%, Memory >85%, Disk >80%
+
+### Bulma — Backup
+Create `/scripts/backup-db.sh`:
+- Compressed database dump
+- Upload to off-site storage (R2/S3)
+- 30-day retention, auto-cleanup
+- Daily cron job
+- **Test restore at least once** — document the procedure
+
+### Holo — Cost
+Document in `/docs/INFRASTRUCTURE.md`:
+- Monthly hosting cost
+- Per-user cost at current and projected scale
+- Most expensive service
+- Right-sizing recommendations
+
+## First-Deploy Pre-flight Checklist
+
+Before the first production deployment:
+
+- [ ] All environment variables set on server (compare against .env.example)
+- [ ] Secrets are production values (not dev/test keys)
+- [ ] Database created and accessible from server
+- [ ] Database seeded with required initial data (admin user, default config)
+- [ ] DNS records pointed to server IP
+- [ ] SSL certificate provisioned (or auto-provision configured)
+- [ ] Firewall rules active (22/80/443 only)
+- [ ] Health check endpoint responds correctly
+- [ ] Deploy script tested on a staging environment first (if available)
+- [ ] Rollback script tested
+- [ ] Backup script runs successfully
+- [ ] Monitoring alerts configured and tested
+- [ ] Error tracking receives test errors
+- [ ] Kenobi has reviewed server security configuration
+
+Log all results to `/logs/phase-12-deploy.md`.
+
+## Post-Deploy Smoke Tests
+
+After the first production deployment (and after each subsequent deploy), verify the application works at runtime — not just the infrastructure:
+
+- **Health check:** `/api/health` returns 200 (already in checklist above)
+- **Primary user flow:** Execute the core journey against the production URL via curl/fetch — verify end-to-end
+- **File serving:** If the app serves uploaded files (via proxy, CDN, or storage), upload a test file and fetch its URL — verify HTTP 200 + correct content-type
+- **Error handling:** Submit intentionally invalid data to a form endpoint — verify the error response is specific (not a generic 500)
+- **Auth flow:** If auth exists, verify login → authenticated request → logout works against production
+- **Cross-module paths:** Verify any URL/key/path patterns generated by the app are accepted by their serving endpoints in production
+
+If any smoke test fails, halt the deploy and run `/scripts/rollback.sh` before investigating.
+
+## Deliverables
+1. /scripts/ (provision.sh, deploy.sh, rollback.sh, backup-db.sh)
+2. /docs/RUNBOOK.md — operational procedures for 3am debugging
+3. /docs/INFRASTRUCTURE.md — server inventory, DNS, costs
+4. ecosystem.config.js (or equivalent)
+5. Reverse proxy config
+6. Cron jobs documented
+7. Monitoring configured
+
+## Handoffs
+- Code bugs found during deploy → Batman, log to `/logs/handoffs.md`
+- Security config review → Kenobi, log to `/logs/handoffs.md`
+- Scaling architecture → Picard, log to `/logs/handoffs.md`
+- App performance issues → Stark, log to `/logs/handoffs.md`

package/dist/.claude/commands/gauntlet.md

@@ -0,0 +1,140 @@
+# /gauntlet — Thanos's Comprehensive Review
+
+*"I am inevitable."*
+
+The Gauntlet tests everything. Every domain. Multiple rounds. Escalating intensity. The project either survives or it doesn't. This is NOT a build command — it assumes code is already written. Run it after `/build` or `/campaign` to put the finished product through absolute hell.
+
+## Context Setup
+1. Read `/docs/methods/GAUNTLET.md` for operating rules
+2. Read `/logs/build-state.md` — what was built, what phases completed
+3. Read `/docs/PRD.md` — the source of truth for what the project should be
+
+## Round 1 — Discovery (parallel)
+
+**Thanos:** "Before I test, I must understand."
+
+Use the Agent tool to run all five in parallel — these are read-only analysis:
+
+- **Agent 1 (Picard — Architecture):** Schema review, service boundaries, dependency graph, scaling assessment. Read the full `/architect` protocol but produce findings only (no ADRs — this is review, not design).
+- **Agent 2 (Stark — Code Review):** Pattern compliance, logic errors, type safety, cross-module data flow tracing. Read `/review` protocol. One pass across all source files.
+- **Agent 3 (Galadriel — UX Surface Map):** Product surface map, usability walkthrough (Step 1.5), Éowyn's enchantment scan (Step 1.75). No fixes yet — discovery only.
+- **Agent 4 (Kenobi — Attack Surface Inventory):** List all endpoints, WebSocket handlers, file I/O, credential access points, user input parsing. Classify each by risk tier. No deep audit yet — just the map.
+- **Agent 5 (Kusanagi — Infrastructure Discovery):** Scan deploy scripts, generated configs, provisioning scripts, CI/CD templates. Classify each by risk: hardcoded credentials, open ports, missing auth on generated services. No deep audit yet — just the map.
+
+Synthesize all five into a unified findings list. Log to `/logs/gauntlet-round-1.md`.
+
+## Round 2 — First Strike (parallel)
+
+**Thanos:** "Now I test every stone."
+
+Use the Agent tool to run all four in parallel — full domain audits:
+
+- **Agent 1 (Batman — Full QA):** Run the complete `/qa` protocol. Oracle + Red Hood + Alfred + Deathstroke + Constantine + Nightwing + Lucius. Every edge case, every error state, every boundary.
+- **Agent 2 (Galadriel — Full UX):** Run the complete `/ux` protocol. Elrond + Arwen + Samwise + Bilbo + Legolas + Gimli + Radagast + Éowyn. Usability, visual, a11y, copy, performance, edge cases, enchantment.
+- **Agent 3 (Kenobi — Full Security):** Run the complete `/security` protocol. Leia + Chewie + Rex + Maul parallel scans, then Yoda → Windu → Ahsoka → Padmé sequential audits.
+- **Agent 4 (Stark — Integration Tracing):** For every API endpoint, trace the full data path: client request → validation → service → database → response. For every file upload, trace: upload → storage → retrieval → display. For every credential, trace: entry → vault → usage → cleanup.
+
+Merge all findings. Deduplicate across domains.
+
+**→ FIX BATCH 1:** Fix all Critical and High findings. Update finding status. **Build-output gate:** If the project has a build step, run the build after fixes and verify output — framework-generated inline scripts, hydration markers, and SSR output are invisible to source-level analysis but can be broken by security hardening (especially CSP changes). Check: `npm run build && grep -c '<script>' dist/**/*.html`.
+
+## Round 2.5 — Runtime Smoke Test (Hawkeye)
+
+If the project has a runnable server, start it and verify the full lifecycle:
+1. Start the server (`npm run dev`, `python manage.py runserver`, etc.)
+2. Hit every new/modified API endpoint with curl — verify HTTP status codes
+3. If WebSocket endpoints exist, open a connection and verify handshake + data flow
+4. If terminal/PTY features exist, create a session and verify it stays alive for 5 seconds
+5. If the server cannot start (scaffold/methodology-only), skip with a note
+
+This catches runtime bugs invisible to static analysis: IPv6 binding, native module ABI, WebSocket framing, browser caching.
+
+## Round 3 — Second Strike (parallel)
+
+**Thanos:** "The first wave reveals. The second wave breaks."
+
+Use the Agent tool to run all four in parallel — targeted re-verification:
+
+- **Agent 1 (Batman — Re-probe):** Nightwing re-runs the test suite. Red Hood re-probes fixed areas. Deathstroke tests new boundaries created by the fixes. Focus on regressions.
+- **Agent 2 (Galadriel — Error States + Re-verify):** Samwise re-audits a11y on all modified components. Radagast re-checks edge cases on fixed flows. Bilbo re-checks microcopy on any changed UI.
+- **Agent 3 (Kenobi — Re-probe + Access Control):** Maul re-probes all remediated vulnerabilities. Ahsoka verifies access control across every role boundary. Padmé verifies the primary user flow still works (critical path smoke test).
+- **Agent 4 (Kusanagi — DevOps):** Run the complete `/devops` protocol with full team: Senku (provisioning), Levi (deploy), Spike (networking), L (monitoring), Bulma (backup), Holo (cost), Valkyrie (disaster recovery). Deploy scripts, monitoring, backups, health checks, page weight gate, security headers.
+
+**→ FIX BATCH 2:** Fix remaining findings.
+
+## Round 4 — The Crossfire (parallel — adversarial)
+
+**Thanos:** "Now the real test. Everyone attacks everyone else's work."
+
+Use the Agent tool to run all five in parallel — pure adversarial:
+
+- **Maul** (Star Wars) — Attacks code that passed /review. Looks for exploits in "clean" code.
+- **Deathstroke** (DC) — Probes endpoints that /security hardened. Tests if remediations can be bypassed.
+- **Loki** (Marvel) — Chaos-tests features that /qa cleared. What breaks under unexpected conditions?
+- **Constantine** (DC) — Hunts cursed code in FIXED areas specifically. Code that only works by accident.
+- **Éowyn** (Tolkien) — Final enchantment pass on the polished, hardened product. Where can delight still be added without compromising security or stability?
+
+**→ FIX BATCH 3:** Fix all adversarial findings. If any fix is applied, re-run the affected adversarial agent on the fixed area only.
+
+## Round 5 — The Council (parallel — convergence)
+
+**Thanos:** "One last look. Every domain. One voice."
+
+Use the Agent tool to run all six in parallel:
+
+- **Spock** (Star Trek) — Did any QA/security/UX fix break code patterns or quality?
+- **Ahsoka** (Star Wars) — Did any fix introduce access control gaps?
+- **Nightwing** (DC) — Full regression: run the entire test suite. Any failures?
+- **Samwise** (Tolkien) — Final accessibility audit on all modified components.
+- **Padmé** (Star Wars) — Critical path functional verification. Open the app, complete the main task, verify output.
+- **Troi** (Star Trek) — PRD compliance: read the PRD prose section-by-section, verify every claim against the implementation. Numeric claims, visual treatments, copy accuracy.
+
+If the Council finds issues:
+1. Fix code discrepancies. Flag asset requirements as BLOCKED.
+2. Re-run the Council (max 2 iterations).
+3. If not converged after 2 rounds, present remaining findings to the user.
+
+## The Snap — Thanos's Verdict
+
+**If all domains sign off:**
+> *"I am inevitable. The project survives the Gauntlet."*
+
+Present the final summary:
+- Total findings across all 5 rounds
+- Total fixes applied
+- Findings by domain (QA, UX, Security, Architecture, DevOps)
+- Test suite status
+- Outstanding items (if any)
+
+**Wong extracts lessons:** Append notable patterns to `/docs/LESSONS.md`.
+
+**If findings remain:**
+Present them with severity and recommendation. The user decides whether to ship or iterate.
+
+## Arguments
+- No arguments → full 5-round gauntlet
+- `--fast` → 3 rounds only (skip Round 4 Crossfire + Round 5 Council). (formerly `--quick` — renamed v17.3 for cross-command consistency)
+- `--security-only` → 4 rounds of security only (Kenobi marathon)
+- `--ux-only` → 4 rounds of UX only (Galadriel marathon)
+- `--qa-only` → 4 rounds of QA only (Batman marathon)
+- `--resume` → resume from last completed round (reads gauntlet state from logs)
+- `--ux-extra` → Extra Éowyn enchantment emphasis across all rounds. Galadriel's team proposes micro-animations, copy improvements, and delight moments beyond standard usability/a11y.
+- `--assess` → **Pre-build assessment.** Rounds 1-2 only (Discovery + First Strike), no fix batches. Produces assessment report grouped by root cause. For evaluating existing codebases before a rebuild or migration — not for post-build hardening. See also `/assess` command which chains this with architecture review and PRD gap analysis.
+- `--infinity` → **The Infinity Gauntlet.** 10 rounds (2x full pass). Every active agent deployed as its own dedicated sub-process — not combined, not summarized. ~60-80 agent launches across all 9 universes. The full ~110 active roster called off the bench. See GAUNTLET.md "The Infinity Gauntlet" section for the complete wave structure. Use after completing a major version or before first production ship.
+- `--muster` → Synonym for `--infinity`. The Gauntlet already deploys the full roster at maximum intensity — `--muster` is the universal flag name for the same concept. **ENFORCEMENT: Must launch Agent tool sub-processes. Inline analysis is not a Muster.**
+
+## Operating Rules
+- Update `/logs/gauntlet-state.md` after EVERY round
+- The Gauntlet does NOT build code — it reviews and hardens existing code
+- Fixes happen BETWEEN rounds, not batched at the end
+- **Confidence scoring is mandatory.** Every finding must include: ID, severity, confidence score (0-100), file, description, fix recommendation. Format: `[ID] [SEVERITY] [CONFIDENCE: XX] [FILE] [DESCRIPTION]`. See GAUNTLET.md "Agent Confidence Scoring" for ranges.
+- **Low-confidence escalation:** Findings below 60 confidence MUST be escalated to a second agent from a different universe before inclusion. If the second agent disagrees, drop the finding. If the second agent agrees, upgrade to medium confidence.
+- **High-confidence fast-track:** Findings at 90+ confidence skip re-verification in Pass 2.
+- If context pressure symptoms appear, ask user to run `/context`. Only checkpoint at >70%. NEVER reduce Gauntlet rounds, skip agents, or "run efficiently" based on self-assessed context pressure. See CAMPAIGN.md "Quality Reduction Anti-Pattern" — this is a hard rule.
+- The Gauntlet is the final test before shipping. Treat it with appropriate gravity.
+
+## Handoffs
+- If architecture changes are needed → log for Picard
+- If new tests are needed → log for Batman (`/test`)
+- If deploy config changes are needed → log for Kusanagi (`/devops`)
+- At completion, offer Bashir (`/debrief`) to capture session learnings