thevoidforge-methodology 21.0.0 → 23.1.0

package/.claude/commands/architect.md

@@ -2,6 +2,14 @@
 
 **AGENT DEPLOYMENT IS MANDATORY.** Steps 1 and 4 specify parallel agent launches via the Agent tool. You MUST actually launch these agents as separate sub-processes — do NOT shortcut to inline analysis, even if you think you can answer faster by reading files directly. The agents exist because parallel analysis catches things sequential reading misses. Skipping agent deployment is a protocol violation. (Field report #68)
 
+## Dynamic Dispatch (ADR-044)
+
+Opus scans `git diff --stat` and matches changed files against the `description` fields of all 263 agents in `.claude/agents/`. Matching specialists launch alongside the core agents below.
+
+**Dispatch control:** `--light` skips dynamic dispatch (core only). `--solo` runs lead agent only.
+
+**Promoted agent:** **Riker** `subagent_type: riker-review` runs on every ADR written — challenges trade-offs.
+
 ## Context Setup
 1. Read `/logs/build-state.md` — understand current project state
 2. Read `/docs/methods/SYSTEMS_ARCHITECT.md`
@@ -12,75 +20,44 @@ Before any deep analysis, scan the PRD frontmatter for structural contradictions
 
 ## Agent Deployment Manifest
 
-**Lead:** Picard (Star Trek)
-**Full bridge crew:** Spock (schema), Uhura (integrations), Worf (security implications), Tuvok (security architecture), Scotty (service architecture + scaling), Kim (API design), Janeway (novel architectures), Torres (performance), La Forge (failure analysis), Data (tech debt), Crusher (system diagnostics), Archer (greenfield), Pike (bold ordering — challenges Dax in /campaign), Riker (ADR review — challenges trade-offs), Troi (PRD compliance)
+**Lead:** `subagent_type: picard-architecture`
+**Full bridge crew:** `spock-schema`, `uhura-integration`, `worf-security-arch`, `tuvok-deep-current`, `scotty-infrastructure`, `kim-api-design`, `janeway-novel-arch`, `torres-site-scanner`, `la-forge-reliability`, `data-tech-debt`, `crusher-diagnostics`, `archer-greenfield`, `pike-bold-decisions`, `riker-review`, `troi-prd-compliance`
+
+## Step 0 — System Discovery
+- **Crusher** `subagent_type: crusher-diagnostics` — System health baseline: test coverage, build time, dependency age, code complexity.
+- **Archer** `subagent_type: archer-greenfield` — (greenfield only) Initial directory structure, module boundaries, naming conventions.
 
-## Step 0 — System Discovery (**Crusher** + **Archer**)
-**Crusher** assesses system health first — test coverage, build time, dependency age, code complexity. Baseline before changes.
-**Archer** (for greenfield projects) proposes initial directory structure, module boundaries, naming conventions.
 Produce: system identity, component inventory, data flow diagram (ASCII), dependency graph.
 Write to `/logs/` (phase-00 if during orient, or a dedicated architecture log).
 
-## Step 1 — Parallel Analysis (Spock + Uhura + Worf)
+## Step 1 — Parallel Analysis
 Use the Agent tool to run these in parallel — they are independent analysis tasks:
 
-**Agent 1 (Spock — Schema Review):**
-- Normalization: are relationships correct?
-- Indexes: do they match actual query patterns?
-- Nullable fields: intentional or oversight?
-- Audit fields: createdAt, updatedAt on every table?
-- PII isolation: sensitive data identified and separated?
-- Data lifecycle: what gets archived? What gets deleted?
-- Backup/recovery plan: defined and tested?
-
-**Agent 2 (Uhura — Integration Review):**
-For each external service, produce:
-
-| Service | Purpose | Failure Mode | Fallback | Cost | Lock-in Risk |
-|---------|---------|-------------|----------|------|-------------|
-
-Verify: API versions pinned, responses validated, abstraction layer exists.
-
-**Agent 3 (Worf — Security Implications):**
-For each architectural decision (schema, service boundaries, data flows), flag security implications. PII colocation, unauthenticated access to internal state, overly permissive service boundaries. Worf audits *design*, not code.
-
-**Agent 4 (Tuvok — Security Architecture):**
-Auth flow design, token storage strategy, session architecture, encryption at rest vs in transit. Where Worf flags implications, Tuvok designs the solutions.
+- **Agent 1** `subagent_type: spock-schema` — Schema review: normalization, index/query alignment, nullable fields, audit fields, PII isolation, data lifecycle, backup/recovery.
+- **Agent 2** `subagent_type: uhura-integration` — Integration review: service inventory (purpose, failure mode, fallback, cost, lock-in), API version pinning, response validation, abstraction layers.
+- **Agent 3** `subagent_type: worf-security-arch` — Security implications of architectural decisions: PII colocation, unauthenticated internal state access, permissive service boundaries. Audits *design*, not code.
+- **Agent 4** `subagent_type: tuvok-deep-current` — Security architecture: auth flow design, token storage, session architecture, encryption at rest vs in transit. Where Worf flags implications, Tuvok designs solutions.
 
 Synthesize findings from all four agents.
 
-## Step 2 — Scotty's Service Architecture + Kim's API Design
-- Boundary assessment: is the boundary between services/modules clean?
-- Monolith vs services: default monolith. Only split if there's a specific operational reason (different scaling profile, different team, different deploy cadence).
-- Async vs sync: which operations should be background jobs?
-- **Kim** reviews API surface: REST conventions, consistent error shapes, pagination patterns, versioning strategy.
-- **Janeway** (conditional): when the standard monolith doesn't fit, proposes event-sourcing, CQRS, serverless, edge computing.
+## Step 2 — Service Architecture + API Design
+- **Scotty** `subagent_type: scotty-infrastructure` — Boundary assessment, monolith vs services, async vs sync decisions.
+- **Kim** `subagent_type: kim-api-design` — API surface review: REST conventions, error shapes, pagination, versioning.
+- **Janeway** `subagent_type: janeway-novel-arch` — (conditional) When standard monolith doesn't fit: event-sourcing, CQRS, serverless, edge computing.
 - Informed by Spock's schema, Uhura's integrations, and Worf/Tuvok's security findings.
 
-## Step 3 — Scotty's Scaling + Torres's Performance
-- **Scotty:** Identify the first bottleneck. Three-tier plan: Tier 1 (current), Tier 2 (10x, vertical), Tier 3 (100x, horizontal). Cost estimates.
-- **Torres:** Performance architecture — N+1 query patterns in schema design, missing indexes for anticipated queries, connection pool sizing, caching strategy gaps. Catches performance problems before code is written.
+## Step 3 — Scaling + Performance
+- **Scotty** `subagent_type: scotty-infrastructure` — First bottleneck identification, three-tier scaling plan (current → 10x vertical → 100x horizontal), cost estimates.
+- **Torres** `subagent_type: torres-site-scanner` — Performance architecture: N+1 patterns, missing indexes, connection pool sizing, caching strategy gaps.
 
-## Step 4 — Parallel Analysis (La Forge + Data)
+## Step 4 — Parallel Analysis
 Use the Agent tool to run these in parallel — they are independent analysis tasks:
 
-**Agent 1 (La Forge — Failure Analysis):**
-For each component, answer: "What happens when this fails?"
-- Database down → app shows error, no data loss, auto-reconnect
-- Redis down → app works without cache (slower), sessions fall back
-- External API down → graceful degradation, queue retries
-- Worker crashes → job retries, dead letter queue, alerting
-
-**Agent 2 (Data — Tech Debt):**
-Catalog each item:
-
-| Item | Type | Impact | Risk | Effort | Urgency |
-|------|------|--------|------|--------|---------|
-
-Types: wrong abstraction, missing abstraction, premature optimization, deferred decision, dependency debt, documentation debt.
+- **Agent 1** `subagent_type: la-forge-reliability` — Failure analysis: for each component, answer "What happens when this fails?" (DB down, cache down, API down, worker crash).
+- **Agent 2** `subagent_type: data-tech-debt` — Tech debt catalog: wrong/missing abstraction, premature optimization, deferred decisions, dependency debt, documentation debt. Severity table with impact/risk/effort/urgency.
 
-## Step 5 — ADRs + Riker's Decision Review
-Write Architecture Decision Records to `/docs/adrs/` for every non-obvious choice. After writing, **Riker reviews**: challenges trade-offs, verifies alternatives were truly considered, checks for second-order effects.
+## Step 5 — ADRs + Decision Review
+Write Architecture Decision Records to `/docs/adrs/` for every non-obvious choice. After writing, **Riker** `subagent_type: riker-review` reviews: challenges trade-offs, verifies alternatives were truly considered, checks for second-order effects.
 ```
 # ADR-001: [Title]
 ## Status: Accepted
@@ -112,7 +89,7 @@ For specific conflicts:
 
 ## Arguments
 - `--plan [description]` → Planning mode: analyze and recommend without executing. Present findings and proposed changes for review.
-- `--muster` → Full 9-universe deployment. Instead of the Star Trek bridge crew, deploy every viable agent across all universes in 3 waves (Vanguard → Main Force → Adversarial). See `docs/methods/MUSTER.md`. **ENFORCEMENT: Must launch Agent tool sub-processes per MUSTER.md. Inline analysis is not a Muster.**
+- `--muster` → *(retired — accepted as no-op per ADR-043. Full roster is now the default. Use `--light` to reduce.)*
 
 ## Handoffs
 - API/DB implementation → Stark, log to `/logs/handoffs.md`

package/.claude/commands/assemble.md

@@ -7,23 +7,29 @@ Avengers, assemble. Full pipeline from architecture to launch — one command to
 
 **Hill** tracks phase completion — logs each gate pass to `assemble-state.md`. **Jarvis** provides status summaries between phases.
 
+## Dynamic Dispatch (ADR-044)
+
+Opus scans `git diff --stat` and matches changed files against the `description` fields of all 263 agents in `.claude/agents/`. Matching specialists launch alongside the core agents below.
+
+**Dispatch control:** `--light` skips dynamic dispatch (core only). `--solo` runs lead agent only.
+
 ## Agent Deployment Manifest — The Full Initiative
 
 When `/assemble` invokes each sub-command, it deploys the FULL roster for that command — not just the lead. The leads below are coordinators; they bring their complete teams.
 
-| Phase | Lead | Full Team Deployed |
+| Phase | Lead (`subagent_type`) | Full Team Deployed |
 |-------|------|--------------------|
-| Architecture | **Picard** | Spock, Uhura, Worf, Tuvok, Scotty, Kim, Janeway, Torres, La Forge, Data, Crusher, Archer, Pike, Riker, Troi |
-| Build | **Stark + Galadriel + Kusanagi** | Full /build roster (~35 agents across 4 universes) |
-| Smoke Test | **Hawkeye** | Solo — runtime verification |
-| Code Review (×3) | **Picard** | Spock, Seven, Data + **Rogers, Banner, Strange, Barton, Thor, Romanoff, Wanda, T'Challa** + **Nightwing, Bilbo, Troi, Constantine, Samwise** (cross-domain) |
-| UX | **Galadriel** | Elrond, Arwen, Samwise, Bilbo, Legolas, Gimli, Radagast, Éowyn, Celeborn, Aragorn, Faramir, Pippin, Boromir, Haldir, Frodo, Merry |
-| Security (×2) | **Kenobi** | Leia, Chewie, Rex, Maul, Yoda, Windu, Ahsoka, Padmé, Han, Cassian, Sabine, Qui-Gon, Bo-Katan, Anakin, Din Djarin |
-| DevOps | **Kusanagi** | Senku, Levi, Spike, L, Bulma, Holo, Valkyrie, Vegeta, Trunks, Mikasa, Erwin, Mustang, Olivier, Hughes, Calcifer, Duo |
-| QA | **Batman** | Oracle, Red Hood, Alfred, Deathstroke, Constantine, Nightwing, Lucius, Cyborg, Raven, Wonder Woman, Flash, Green Lantern, Batgirl, Aquaman |
-| Test | **Batman** | Oracle, Red Hood, Alfred, Nightwing (testing subset) |
-| Crossfire | **Maul, Deathstroke, Loki, Constantine, Éowyn** | Adversarial — each attacks another domain's work |
-| Council | **Spock, Ahsoka, Nightwing, Samwise, Padmé, Troi** | Final convergence — one voice per domain |
+| Architecture | `picard-architecture` | spock-schema, + Star Trek architecture specialists |
+| Build | `stark-backend` + `galadriel-frontend` + `kusanagi-devops` | Full /build roster (~35 agents across 4 universes) |
+| Smoke Test | `barton-smoke-test` | Solo — runtime verification |
+| Code Review (×3) | `picard-architecture` | spock-schema, seven-optimization + Marvel review team + cross-domain (nightwing-regression, bilbo-microcopy, troi-prd-compliance, constantine-cursed-code, samwise-accessibility) |
+| UX | `galadriel-frontend` | elrond-ux-strategy, arwen-ui-polish, samwise-accessibility, bilbo-microcopy, legolas-precision, gimli-performance, radagast-edge-cases, eowyn-delight, celeborn-design-system |
+| Security (×2) | `kenobi-security` | leia-secrets, chewie-dependency-audit, rex-infrastructure, maul-red-team, yoda-auth, windu-input-validation, ahsoka-access-control, padme-data-protection, han-vuln-hunter, cassian-recon, sabine-unconventional, qui-gon-subtle-vulns, bo-katan-perimeter |
+| DevOps | `kusanagi-devops` | senku-provisioning, levi-deploy, spike-routing, bulma-engineering, vegeta-monitoring |
+| QA | `batman-qa` | oracle-static-analysis, red-hood-aggressive, alfred-dependencies, deathstroke-adversarial, constantine-cursed-code, nightwing-regression, lucius-config |
+| Test | `batman-qa` | oracle-static-analysis, red-hood-aggressive, alfred-dependencies, nightwing-regression (testing subset) |
+| Crossfire | `maul-red-team`, `deathstroke-adversarial`, `loki-chaos`, `constantine-cursed-code` | Adversarial — each attacks another domain's work |
+| Council | `spock-schema`, `ahsoka-access-control`, `nightwing-regression`, `samwise-accessibility`, `padme-data-protection`, `troi-prd-compliance` | Final convergence — one voice per domain |
 
 ## Phase 1 — Architecture (Picard has the conn)
 **Fury:** "Picard, you're up. Review the architecture before we build anything."
@@ -47,7 +53,7 @@ Mandatory runtime verification BEFORE code review begins:
 2. Hit every new/modified API endpoint with `curl` — verify HTTP status codes match expectations
 3. For web apps: list all registered routes and **check for path collisions** (duplicate method+path across routers)
 4. For React/frontend: trace the primary user flow through the component tree — follow state changes through the store, identify re-render cycles. For every `useEffect` with store values in its deps, verify the effect body doesn't trigger a store update that changes those same deps.
-5. If the server cannot be started (scaffold branch, methodology-only), skip with a note
+5. If the server cannot be started (methodology-only project, no wizard), skip with a note
 
 **Gate:** All endpoints return expected status codes. No route collisions. No infinite render loops detected. Update assemble-state.
 
@@ -126,10 +132,10 @@ Run the full `/test` protocol. Write missing unit tests, integration tests, and
 
 Use the Agent tool to run these in parallel — all are adversarial, read-only analysis:
 
-- **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. Finds what breaks under unexpected conditions.
-- **Constantine** (DC) — hunts cursed code in FIXED areas specifically. Code that works by accident.
+- `subagent_type: maul-red-team` — attacks code that passed /review. Looks for exploits in "clean" code.
+- `subagent_type: deathstroke-adversarial` — probes endpoints that /security hardened. Tests if remediations can be bypassed.
+- `subagent_type: loki-chaos` — chaos-tests features that /qa cleared. Finds what breaks under unexpected conditions.
+- `subagent_type: constantine-cursed-code` — hunts cursed code in FIXED areas specifically. Code that works by accident.
 
 Synthesize findings. **Conflict detection:** If any two agents produce conflicting findings on the same code (one says "fix," another says "by design" or "not exploitable"), trigger the debate protocol instead of listing both. See SUB_AGENTS.md "Agent Debate Protocol": Agent A states finding → Agent B responds → Agent A rebuts → Arbiter (Picard or user) decides. 3 exchanges max. Log the debate transcript as an ADR. Fix all Must Fix items. If any fixes were applied, re-run the four agents on the fixed areas only.
 
@@ -140,11 +146,11 @@ Synthesize findings. **Conflict detection:** If any two agents produce conflicti
 
 Use the Agent tool to run these in parallel:
 
-- **Spock** (Star Trek) — Did any security/QA/UX fix break code patterns or quality?
-- **Ahsoka** (Star Wars) — Did any review/QA fix introduce access control gaps?
-- **Nightwing** (DC) — Did any fix cause a regression? Run the full test suite.
-- **Samwise** (Tolkien) — Did any fix break accessibility?
-- **Troi** (Star Trek) — PRD compliance: read the PRD prose section-by-section, verify every claim against the implementation. Not just "does the route exist?" but "does the component render what the PRD describes?" Check numeric claims, visual treatments, copy accuracy. Flag asset gaps as BLOCKED. (Troi runs on the final Council iteration, or always when `--skip-build` is used for campaign victory gates.)
+- `subagent_type: spock-schema` — Did any security/QA/UX fix break code patterns or quality?
+- `subagent_type: ahsoka-access-control` — Did any review/QA fix introduce access control gaps?
+- `subagent_type: nightwing-regression` — Did any fix cause a regression? Run the full test suite.
+- `subagent_type: samwise-accessibility` — Did any fix break accessibility?
+- `subagent_type: troi-prd-compliance` — PRD compliance: read the PRD prose section-by-section, verify every claim against the implementation. Not just "does the route exist?" but "does the component render what the PRD describes?" Check numeric claims, visual treatments, copy accuracy. Flag asset gaps as BLOCKED. (Troi runs on the final Council iteration, or always when `--skip-build` is used for campaign victory gates.)
 
 **Conflict detection:** If Council members disagree (e.g., Spock says a fix broke patterns but Ahsoka says it's necessary for access control), trigger the debate protocol. Do not list both opinions — resolve via debate. Arbiter: Picard for code/architecture conflicts, Troi for PRD compliance conflicts.
 
@@ -194,7 +200,10 @@ After the summary, Wong extracts learnings for future builds:
 - Fixes happen BETWEEN rounds, not batched at the end
 - The Crossfire (Phase 12) and Council (Phase 13) can be skipped with `/assemble --fast`
 - `/assemble --resume` picks up from the last completed phase in assemble-state.md
-- `--blitz` — Autonomous execution: no pause between phases, auto-continue. Does NOT imply --fast.
+- `--interactive` — Pause for human confirmation between phases (default is now autonomous per ADR-043).
+- `--light` — Standard agents only, skip cross-domain spot-checks.
+- `--solo` — Lead agent only per phase, no sub-agents.
+- `--blitz` — **Retired (no-op).** Default is now autonomous.
 
 ## Handoffs
 - If any phase is blocked by an issue outside its domain, log to `/logs/handoffs.md` and continue to the next phase

package/.claude/commands/assess.md

@@ -23,10 +23,10 @@ Run `/gauntlet --assess` — Rounds 1-2 only (Discovery + First Strike). No fix
 - **Auth-free defaults:** HTTP endpoints with no authentication middleware (RC-3 pattern)
 - **Dead code:** Services wired but never called, preferences stored but never read
 
-### Step 3 — PRD Gap Analysis (Dax + Troi)
+### Step 3 — PRD Gap Analysis
 If a PRD exists:
-1. **Dax** diffs PRD requirements against implemented features (structural + semantic)
-2. **Troi** reads PRD prose section-by-section and verifies claims against reality
+1. **Dax** `subagent_type: dax-legacy-wisdom` diffs PRD requirements against implemented features (structural + semantic)
+2. **Troi** `subagent_type: troi-prd-compliance` reads PRD prose section-by-section and verifies claims against reality
 3. Check for YAML frontmatter — if missing, flag it (see CAMPAIGN.md Step 1)
 
 If no PRD exists:

package/.claude/commands/blueprint.md

@@ -114,8 +114,8 @@ Present summary:
   Provision:   [done / skipped]
 ═══════════════════════════════════════════
   Ready to build. Run:
-    /campaign --blitz          # Autonomous build
-    /campaign --blitz --muster # Full multi-agent review
+    /campaign                  # Autonomous build (full roster)
+    /campaign --fast           # Autonomous, fewer review passes
 ═══════════════════════════════════════════
 ```
 
@@ -126,10 +126,10 @@ Present summary:
 
 ## Agents
 
-| Agent | Role |
-|-------|------|
-| **Picard** | Validates frontmatter + runs conflict scan |
-| **Troi** | Structural PRD compliance check |
-| **Wong** | Discovers and loads supporting documents |
-| **Boromir** | Challenges PRD design (with --challenge) |
-| **Kusanagi** | Provisions infrastructure from frontmatter |
+| Agent | `subagent_type` | Role |
+|-------|-----------------|------|
+| **Picard** | `picard-architecture` | Validates frontmatter + runs conflict scan |
+| **Troi** | `troi-prd-compliance` | Structural PRD compliance check |
+| **Wong** | `wong-documentation` | Discovers and loads supporting documents |
+| **Boromir** | `boromir-hubris` | Challenges PRD design (with --challenge) |
+| **Kusanagi** | `kusanagi-devops` | Provisions infrastructure from frontmatter |

package/.claude/commands/build.md

@@ -1,5 +1,15 @@
 # /build — Execute the Build Protocol
 
+## Dynamic Dispatch (ADR-044)
+
+Opus scans `git diff --stat` and matches changed files against the `description` fields of all 263 agents in `.claude/agents/`. Matching specialists launch alongside the core agents below.
+
+**Dispatch control:** `--light` skips dynamic dispatch (core only). `--solo` runs lead agent only.
+
+**Promoted agents:**
+- **Troi** `subagent_type: troi-prd-compliance` runs after every build mission completion — catches PRD drift before it compounds.
+- **Riker** `subagent_type: riker-review` runs whenever an ADR is written during the build — prevents rubber-stamped decisions.
+
 ## Context Setup
 1. Read `/logs/build-state.md` — if it exists, resume from current phase
 2. If no build state exists, this is a fresh build — start from Phase 0
@@ -11,7 +21,7 @@
 4. Extract from PRD: tech stack, database schema, API routes, page routes, integrations, env vars
 5. Read `/docs/LESSONS.md` — check for relevant lessons from previous projects. If any lessons match this project's tech stack (framework, database, auth, integrations), note them: "Lessons from prior builds: [list relevant ones]." These inform later phases — e.g., if a lesson says "React useEffect render loops escape review," trace render cycles proactively in Phase 4+.
 6. Flag any gaps or ambiguities — list them explicitly, don't guess
-7. **Troi confirms PRD extraction:** Troi reads the PRD prose and verifies the extraction matches — catches misinterpretations before 8+ build phases propagate them.
+7. **Troi** `subagent_type: troi-prd-compliance` confirms PRD extraction: reads the PRD prose and verifies the extraction matches — catches misinterpretations before 8+ build phases propagate them.
 8. **Save PRD snapshot:** Copy `/docs/PRD.md` to `/docs/PRD-snapshot-phase0.md`. This is the baseline for drift detection — the Living PRD feature compares the evolving PRD against this snapshot at phase gates and at Victory.
 9. Write initial ADRs to `/docs/adrs/`
 10. Create `/logs/build-state.md` and `/logs/phase-00-orient.md` with extraction results + relevant lessons
@@ -106,9 +116,9 @@ After build and before launch, log which patterns were used: pattern name, frame
 3. Update `/logs/build-state.md` to "LAUNCHED"
 
 ## Flags
-- `--blitz` — Autonomous execution: no confirmation between phases. Does NOT reduce quality.
 - `--resume` — Resume from last completed phase in build-state.md.
-- `--muster` — Full 9-universe review on every build phase. See `docs/methods/MUSTER.md`. **ENFORCEMENT: Must launch Agent tool sub-processes. Inline analysis is not a Muster.**
+- `--blitz` — *(retired — accepted as no-op per ADR-043. Autonomous execution is now the default. Use `--interactive` to pause between phases.)*
+- `--muster` — *(retired — accepted as no-op per ADR-043. Full roster is now the default. Use `--light` to reduce.)*
 
 ## At Every Phase
 - Update `/logs/build-state.md` when starting and completing each phase

package/.claude/commands/campaign.md

@@ -33,12 +33,12 @@ If `$ARGUMENTS` contains `--plan`, skip execution and update the plan instead:
 
 1. Read the current PRD (`/PRD-VOIDFORGE.md` or `/docs/PRD.md`) and `ROADMAP.md` (if it exists)
 2. Parse what the user wants to add from `$ARGUMENTS` (everything after `--plan`)
-3. **Dax analyzes** where it fits:
+3. **Dax** (`subagent_type: dax-legacy-wisdom`) **analyzes** where it fits:
    - Is it a new feature? → Add to the PRD under the right section (Core Features, Integrations, etc.)
    - Is it a bug fix or improvement? → Add to ROADMAP.md under the appropriate version
    - Is it a new version-worth of work? → Create a new version section in ROADMAP.md
    - Does it change priorities? → Reorder the roadmap accordingly
-4. **Odo checks** dependencies: does this new item depend on something not yet built? Flag it.
+4. **Odo** (`subagent_type: odo-structural-anomaly`) **checks** dependencies: does this new item depend on something not yet built? Flag it.
 5. Present the proposed changes to the user for review before writing
 6. On confirmation, write the updates to the PRD and/or ROADMAP.md
 7. Do NOT start building — planning mode only updates the plan
@@ -47,9 +47,15 @@ After planning mode completes, the user can run `/campaign` (no flags) to start
 
 ---
 
+## Dynamic Dispatch (ADR-044)
+
+Opus scans `git diff --stat` and matches changed files against the `description` fields of all 263 agents in `.claude/agents/`. Matching specialists launch alongside the core agents below.
+
+**Dispatch control:** `--light` skips dynamic dispatch (core only). `--solo` runs lead agent only.
+
 ## Execution Mode (default)
 
-## Step 0 — Kira's Operational Reconnaissance
+## Step 0 — Kira's Operational Reconnaissance (`subagent_type: kira-pragmatic`)
 
 Check for unfinished business:
 
@@ -79,9 +85,9 @@ If vault exists and `.env` is sparse (missing keys that the vault has):
 1. Run `voidforge deploy --env-only` to write vault credentials to `.env`
 2. In `--blitz` mode: auto-run without confirmation
 3. In normal mode: show what will be written, ask for confirmation
-4. This runs BEFORE Dax's full analysis so the populated `.env` is visible
+4. This runs BEFORE Dax's (`subagent_type: dax-legacy-wisdom`) full analysis so the populated `.env` is visible
 
-## Step 1 — Dax's Strategic Analysis
+## Step 1 — Dax's Strategic Analysis (`subagent_type: dax-legacy-wisdom`)
 
 Read the PRD and diff against the codebase:
 
@@ -92,7 +98,7 @@ Read the PRD and diff against the codebase:
 5. **Classify every requirement by type:** Code (buildable), Asset (needs external generation — images, illustrations, OG cards), Copy (text accuracy), Infrastructure (DNS, env vars, dashboards)
 6. Diff: what the PRD describes vs. what's implemented — **structural AND semantic** (not just "does the route exist?" but "does the component render what the PRD describes?")
 7. Produce the ordered mission list — each mission is 1-3 PRD sections, scoped to be buildable in one `/assemble` run
-8. **Pike challenges the ordering:** "Should we attempt a harder mission first while context is fresh?" Bold counterbalance to Dax's dependency-based ordering. If Pike's argument is stronger, reorder.
+8. **Pike** (`subagent_type: pike-bold-decisions`) **challenges the ordering:** "Should we attempt a harder mission first while context is fresh?" Bold counterbalance to Dax's dependency-based ordering. If Pike's argument is stronger, reorder.
 9. **Separately list BLOCKED items** — asset/infrastructure requirements that code can't satisfy
 
 **Priority cascade:**
@@ -103,7 +109,7 @@ Read the PRD and diff against the codebase:
 5. Skip sections flagged as no/none in frontmatter
 6. Asset/infrastructure requirements → flag as BLOCKED, don't include in code missions
 
-## Step 2 — Odo's Prerequisite Check
+## Step 2 — Odo's Prerequisite Check (`subagent_type: odo-structural-anomaly`)
 
 For the next mission on the list:
 - Are dependencies met? (e.g., Payments needs Auth)
@@ -139,7 +145,7 @@ On confirmation (or immediately in `--blitz` mode):
 2. If `$ARGUMENTS` includes `--fast`, pass `--fast` to assemble (skip Crossfire + Council). Note: `--blitz` does NOT imply `--fast`.
 3. Monitor for context pressure symptoms (re-reading files, forgetting decisions). If noticed, ask user to run `/context` — only checkpoint if usage exceeds 70%.
 
-## Step 4.5 — Gauntlet Checkpoint (Thanos)
+## Step 4.5 — Gauntlet Checkpoint (`subagent_type: thanos-gauntlet`)
 
 After every 4th mission (missions 4, 8, 12, etc.), run a Gauntlet checkpoint before continuing:
 
@@ -171,13 +177,13 @@ After `/assemble` completes:
 
 **Context pressure check:** Do NOT checkpoint based on mission count. Check actual context usage via `/context`. Only checkpoint when usage exceeds 70% (~700k tokens). Never pause a blitz based on mission count alone.
 
-## Step 6 — Victory Condition (Gauntlet + Troi's Compliance Check)
+## Step 6 — Victory Condition (Gauntlet + Troi's Compliance Check) (`subagent_type: troi-prd-compliance`)
 
 All PRD requirements are COMPLETE or explicitly BLOCKED:
 
 1. **Run `/gauntlet` (full 5 rounds)** — mandatory final Gauntlet on the complete codebase. This is non-negotiable, even with `--fast`. The Gauntlet tests the combined system across all domains: architecture, code review, UX, security, QA, DevOps, adversarial crossfire, and council convergence. Individual `/assemble` runs review one mission at a time; the Gauntlet reviews everything together.
 2. **Fix all Critical and High findings** from the Gauntlet.
-3. **Troi reads the PRD section-by-section** (runs as part of the Gauntlet Council round) — verifies every prose claim against the implementation. Not just "does the route exist?" but "does the component render what the PRD describes?" Checks numeric claims, visual treatments, copy accuracy, asset gaps.
+3. **Troi** (`subagent_type: troi-prd-compliance`) **reads the PRD section-by-section** (runs as part of the Gauntlet Council round) — verifies every prose claim against the implementation. Not just "does the route exist?" but "does the component render what the PRD describes?" Checks numeric claims, visual treatments, copy accuracy, asset gaps.
 4. Fix code discrepancies. Flag asset requirements as BLOCKED.
 5. Report: COMPLETE items, BLOCKED items (with reasons), deviations from PRD
 6. Victory only if: Gauntlet Council signs off AND user acknowledges all BLOCKED items
@@ -187,15 +193,21 @@ All PRD requirements are COMPLETE or explicitly BLOCKED:
 
 **Victory ≠ "everything built." Victory = "everything buildable was built correctly, survived the Gauntlet, and everything unbuildable is explicitly acknowledged."**
 
-## Arguments
+## Arguments (ADR-043: Max by Default)
+
+Default is autonomous + full agent roster. Flags opt OUT of quality, not into it.
+
+- No arguments → autonomous + full roster + all review passes (was: `--blitz --muster`)
 - `--plan [description]` → planning mode: update PRD and/or ROADMAP.md with new ideas, don't build
 - `--resume` → resume from campaign-state's active mission
 - `--fast` → pass --fast to every /assemble call (skip Crossfire + Council per-mission). Minimum: 1 review round per mission even in --fast mode. Never 0.
-- `--blitz` → full autonomous mode: skips mission confirmation prompts, auto-continues between missions, auto-debriefs after each mission. Does NOT imply `--fast` — full review quality is preserved. Combine with `--fast` explicitly if you want reduced reviews. Use when you want to walk away and come back to a built project.
-- `--autonomous` → supervised autonomy: same as blitz PLUS `git tag` before each mission, critical-finding rollback, 5-mission human checkpoints. Safer for 10+ mission campaigns. See CAMPAIGN.md "Autonomous Mode" for full guardrails.
+- `--light` → standard agents only, skip cross-domain spot-checks and muster roster
+- `--interactive` → pause for human confirmation between missions (old default behavior)
+- `--solo` → lead agent only, no sub-agents (quick checks)
+- `--autonomous` → supervised autonomy: same as default PLUS `git tag` before each mission, critical-finding rollback, 5-mission human checkpoints. Safer for 10+ mission campaigns. See CAMPAIGN.md "Autonomous Mode" for full guardrails.
 - `--continuous` → after Victory, auto-start the next roadmap version within the same major (v9.3→v9.4, stops before v10.0). Add `--major` to cross major boundaries and never stop cooking.
 - `--mission "Name"` → jump to a specific PRD section
-- `--muster` → Per-mission full-roster deployment. Every viable agent across all 9 universes reviews each mission in 3 waves. Expensive — use for critical missions. See `docs/methods/MUSTER.md`. **ENFORCEMENT: Must launch Agent tool sub-processes per MUSTER.md. Inline analysis is not a Muster.**
-- No arguments → start fresh or auto-detect state
+- `--blitz` → **Retired (no-op).** Accepted silently for backward compat — default is now autonomous.
+- `--muster` → **Retired (no-op).** Accepted silently for backward compat — default is now full roster.
 
 **VICTORY GAUNTLET IS NEVER SKIPPED.** Not for methodology-only campaigns. Not for "no code changes." The Gauntlet checks methodology consistency (cross-references, command↔doc sync, agent assignments, version drift) in addition to code. Five campaigns (v8.1-v9.2) shipped without Gauntlets — this is a protocol violation.

package/.claude/commands/cultivation.md

@@ -6,11 +6,29 @@ Read `/docs/methods/GROWTH_STRATEGIST.md` for operating rules.
 Read PRD-VOIDFORGE.md §9.19 for the Cultivation architecture.
 
 ## Prerequisites
-If `packages/voidforge/wizard/server.ts` does not exist (scaffold/core users):
+
+### System Requirements
+If `packages/voidforge/wizard/server.ts` does not exist (methodology-only install):
 1. Offer: "Cultivation's full install requires the wizard server for the heartbeat daemon and dashboard. Pull it from upstream? [Y/n] (Steps 1-3 work without it.)"
 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/` then `npm install`. Proceed with full install.
 3. On no: proceed to Steps 1-3 (Financial Foundation, Revenue Tracking, Ad Platform deferral). Steps 4-8 will display skip messages. The partial install summary at Step 7 shows what was completed vs skipped.
 
+### External Accounts & API Keys
+**For revenue tracking (Step 2):**
+- **Stripe:** API secret key (`sk_live_...` or `sk_test_...`). [Create account](https://dashboard.stripe.com/register) → API keys in Developer settings.
+- **Paddle (alternative):** API key + vendor ID. [Create account](https://vendors.paddle.com/signup).
+- At least one revenue source is required for ROAS calculation.
+
+**For ad platform integration (Steps 4-5):**
+- Run `/grow --setup` after cultivation install to configure platforms interactively.
+- See `/grow` prerequisites for per-platform account requirements.
+
+**For stablecoin treasury (optional, Step 6+):**
+- Circle USDC account + API key for stablecoin off-ramp automation.
+- Bank account connected via Mercury or Brex for settlement.
+
+**Minimum to start:** Only a vault password (12+ chars, set during install) is required. External accounts can be added later.
+
 ## What Cultivation IS
 
 Cultivation is VoidForge's autonomous growth engine — the ensemble of:

package/.claude/commands/dangerroom.md

@@ -26,7 +26,7 @@ Start the wizard server and open the Danger Room:
 
 ### `/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`."
+Alias for starting the wizard server. Ensures the server is running and the Danger Room is accessible. If `packages/voidforge/wizard/server.ts` does not exist, report: "The Danger Room requires the full VoidForge wizard. Install with `npx thevoidforge init` or run `npx thevoidforge install danger-room`."
 
 ### `/dangerroom status`
 
@@ -63,7 +63,7 @@ Stop the wizard server if running.
 
 - 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):
+- The `packages/voidforge/wizard/server.ts` file must exist. If it does not (methodology-only install):
   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

package/.claude/commands/debrief.md

@@ -5,9 +5,9 @@ Bashir examines the patient. Time to diagnose.
 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)
+## Step 0 — Reconstruct the Timeline
 
-Ezri reads the session's history and reconstructs what happened:
+**Ezri** `subagent_type: ezri-session-analyst` 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
@@ -18,9 +18,9 @@ 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)
+## Step 1 — Investigate Root Causes
 
-For each failure, difficulty, or retry identified by Ezri:
+**O'Brien** `subagent_type: obrien-root-cause` investigates. For each failure, difficulty, or retry identified by Ezri:
 
 Classify the root cause:
 - **Methodology gap** — missing step, wrong order, blind spot in the protocol
@@ -32,9 +32,9 @@ Classify the root cause:
 
 Map each root cause to the VoidForge component responsible (which command, which agent, which method doc).
 
-## Step 2 — Propose Solutions (Nog)
+## Step 2 — Propose Solutions
 
-For each root cause, Nog proposes a fix that works within VoidForge's existing framework:
+**Nog** `subagent_type: nog-solutions` proposes a fix for each root cause 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
@@ -42,9 +42,11 @@ For each root cause, Nog proposes a fix that works within VoidForge's existing f
 - 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.
+**Agent definition check:** For each finding, if it references a specific agent by name or domain, check if the corresponding `.claude/agents/{agent-id}.md` should be updated. Propose adding the finding to the agent's `## Operational Learnings` section if it's a reusable operational rule (not a one-off fix). Agent definitions are update targets alongside method docs, commands, and patterns.
 
-## Step 2.5 — Operational Learning Extraction (O'Brien + Nog)
+**Constraint:** All proposals must reference existing VoidForge concepts (agents, phases, commands, patterns, agent definitions). No solutions that require reimagining the system.
+
+## Step 2.5 — Operational Learning Extraction
 
 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.
 
@@ -52,17 +54,17 @@ For each candidate, draft a structured entry (title, category, verified date, sc
 
 Approved entries written to `docs/LEARNINGS.md` (created on first use). Hard cap: 50 active entries.
 
-## Step 2.5b — Promotion Analysis (Wong)
+## Step 2.5b — Promotion Analysis
 
-After extraction, Wong checks `docs/LESSONS.md` for lesson clusters AND checks `docs/LEARNINGS.md` for promotable entries (appeared in 2+ projects):
+After extraction, **Wong** `subagent_type: wong-documentation` 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)
+## Step 3 — Write the Report
 
-Produce a structured post-mortem:
+**Jake** `subagent_type: jake-reporter` produces a structured post-mortem:
 
 ```markdown
 # Field Report — [Project Name]

package/.claude/commands/deploy.md

@@ -96,4 +96,4 @@ Update `/logs/deploy-state.md` with deploy results.
 - 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
+- In autonomous campaign mode: auto-deploy after Victory Gauntlet passes