thevoidforge 21.0.11 → 21.0.12

package/dist/.claude/commands/build.md

@@ -0,0 +1,116 @@
+# /build — Execute the Build Protocol
+
+## 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
+
+## Phase 0 — Orient (Picard leads)
+1. Read `/docs/PRD.md` — extract the YAML frontmatter block
+2. Validate frontmatter values: `type` must be one of (full-stack, api-only, static-site, prototype, game). `auth` must be (yes, no). `payments` must be (stripe, lemonsqueezy, none). `deploy` must be (vps, vercel, railway, cloudflare, static, docker, ios, android, cross-platform). If `type: game`, check game-specific fields (game_engine, game_genre). If `deploy: ios|android|cross-platform`, check mobile fields (mobile_framework, bundle_id). See BUILD_PROTOCOL.md "Game Project Detection" and "Mobile Framework Detection" sections for phase adaptations.
+3. Read `/docs/methods/BUILD_PROTOCOL.md` — check skip rules against frontmatter
+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.
+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
+11. **Gate:** ADRs written, all PRD sections accounted for, PRD snapshot saved, skip rules documented in build-state.md
+
+## Phase 1 — Scaffold (Stark + Kusanagi)
+1. Read `/docs/methods/BACKEND_ENGINEER.md` (Step 0 — Orient section only)
+2. Initialize framework, configs, directory structure per PRD
+3. Set up test runner per `/docs/methods/TESTING.md` (Setup Checklist section)
+4. Log decisions to `/logs/phase-01-scaffold.md`
+5. **Gate:** `npm run build` passes, directory structure matches architecture, test runner works
+
+## Phase 2 — Infrastructure (Kusanagi)
+1. Read `/docs/methods/DEVOPS_ENGINEER.md` (Senku section only)
+2. Database setup (Banner assists), Redis if needed, environment config
+3. Verify: dev server starts, DB connects, `npm test` passes
+4. Log to `/logs/phase-02-infrastructure.md`
+5. **Gate:** All verification commands pass
+
+## Phase 3 — Auth (Stark + Galadriel, Kenobi reviews) [SKIP if `auth: no`]
+1. Implement auth providers, login, signup, password reset, sessions, middleware, roles
+2. Write auth integration tests — test all paths including failures
+3. Kenobi reviews: session cookies, CSRF, password hashing, OAuth config
+4. Log to `/logs/phase-03-auth.md`
+5. **Gate:** Login/signup/logout work manually AND auth tests pass
+
+## Phase 4 — Core Feature (Stark + Galadriel)
+1. Identify the single most important user journey from the PRD
+2. Build vertical slice: schema -> API -> UI -> wire up
+3. Follow patterns: `/docs/patterns/api-route.ts`, `/docs/patterns/service.ts`
+4. Write unit tests for core service logic, integration tests for API routes
+5. Log to `/logs/phase-04-core.md`
+6. **PRD alignment check (Living PRD):** Compare what was built against the PRD section for this feature. If the implementation deviates (different schema fields, different UI flow, different behavior), choose: fix the code to match the PRD, OR update the PRD to match reality. Never leave a silent contradiction. Log deviations in `/logs/phase-04-core.md`.
+7. **Gate:** Core journey works end-to-end manually AND service tests pass (>80% coverage for core service). PRD alignment verified — no unresolved deviations. **"Works manually" means:** execute the happy path AND at least one error path against the running server. For file uploads, fetch the returned URL and verify it serves. For forms, submit invalid data and verify the error message is specific. Verify cross-module paths (generated URLs are accepted by their consumers).
+
+## Phase 5 — Supporting Features (Stark + Galadriel) [1-3 features per session]
+1. Build in dependency order: schema -> API -> UI -> verify per feature
+2. After each feature batch: build passes, previous flows still work, new flow works, all tests pass
+3. Log each feature batch to `/logs/phase-05-features.md`
+4. **Gate:** All features work, no regressions, all tests pass. For each new feature: verify the happy path AND the primary error path against the running server. Verify cross-module integration (uploaded files serve correctly, error messages display in UI, generated URLs resolve).
+
+## Phase 6 — Integrations (Stark/Romanoff, Kenobi reviews) [SKIP sections per frontmatter]
+1. Each integration: client wrapper in /lib/, env vars, test mode, error handling
+2. Follow `/docs/patterns/service.ts` for wrappers, `/docs/patterns/job-queue.ts` for async work
+3. Kenobi reviews each integration's security
+4. Log to `/logs/phase-06-integrations.md`
+5. **PRD alignment check (Living PRD):** Compare each integration against the PRD's integration section. If the implementation uses a different provider, different API, or different behavior than the PRD specifies, choose: fix the code OR update the PRD. Log deviations.
+6. **Gate:** Each integration tested in test mode, webhook handling verified. PRD alignment verified. For each integration: verify the full chain works (upload → URL → fetch, payment → webhook → state change, email → delivery confirmation). Submit data that triggers integration-specific errors and verify error messages are surfaced to the user.
+
+## Phase 7 — Admin (Stark + Galadriel) [SKIP if `admin: no`]
+1. Dashboard, user management, analytics views, audit logging
+2. Log to `/logs/phase-07-admin.md`
+3. **Gate:** Admin can view users/data, audit log records actions
+
+## Phase 8 — Marketing (Galadriel) [SKIP if `marketing: no`]
+1. Homepage, features, pricing, legal pages, SEO meta
+2. Log to `/logs/phase-08-marketing.md`
+3. **PRD alignment check (Living PRD):** Compare marketing pages against the PRD's marketing section. Verify copy claims (feature counts, pricing tiers, testimonial accuracy), visual treatments, and page structure match. Fix code OR update PRD for deviations.
+4. **Gate:** Pages render, SEO present, mobile responsive, PRD alignment verified
+
+## Phases 9-11 — Double-Pass Review Cycle (Batman + Galadriel + Kenobi)
+
+### Pass 1 — Find (all three run in parallel)
+1. **Batman (QA):** Read `/docs/methods/QA_ENGINEER.md`. Run Oracle + Red Hood + Alfred + Deathstroke + Constantine in parallel. Lucius reviews config separately. Log to `/logs/phase-09-qa-audit.md`
+2. **Galadriel (UX)** [SKIP if `type: api-only`]: Read `/docs/methods/PRODUCT_DESIGN_FRONTEND.md`. Run Elrond + Arwen + Samwise in parallel, then Bilbo + Legolas + Gimli + Radagast sequentially. Log to `/logs/phase-10-ux-audit.md`
+3. **Kenobi (Security):** Read `/docs/methods/SECURITY_AUDITOR.md`. Run Leia + Chewie + Rex + Maul in parallel, then Yoda → Windu → Ahsoka → Padmé sequentially. Log to `/logs/phase-11-security-audit.md`
+
+### Fix Batch
+4. Resolve all critical/high findings across all three audits
+5. Where findings conflict between agents, apply conflict resolution from `/docs/methods/SUB_AGENTS.md`
+
+### Pass 2 — Re-Verify (all three run in parallel)
+6. **Batman:** Nightwing re-runs test suite + Red Hood re-probes fixed areas + Deathstroke re-tests boundaries
+7. **Galadriel:** Samwise re-audits a11y on modified components + Radagast re-checks edge cases
+8. **Kenobi:** Maul re-probes all remediated vulnerabilities
+9. If Pass 2 finds new issues, fix and re-verify until clean
+10. **Gate:** All agents sign off — test suite green, a11y clean, no critical/high security findings
+
+## Phase 12 — Deploy (Kusanagi)
+1. Read `/docs/methods/DEVOPS_ENGINEER.md` — execute full sequence
+2. Run `npx voidforge deploy --headless` to provision infrastructure and deploy from the terminal (no browser needed — uses vault credentials and PRD frontmatter). If the vault isn't set up yet, generate deploy scripts per DEVOPS_ENGINEER.md instead.
+3. Configure DNS/SSL, monitoring, backups
+4. Log to `/logs/phase-12-deploy.md`
+5. **Gate:** Health check passes in production, monitoring active, backup tested
+
+## Phase 12.5 — Wong's Pattern Usage Log
+After build and before launch, log which patterns were used: pattern name, framework adaptation, custom mods. Store in `docs/pattern-usage.json`. Feeds Wong's promotion analysis in `/debrief`.
+
+## Phase 13 — Launch (All agents)
+1. Full checklist: SSL, email, payments, analytics, monitoring, backups, security headers, legal, performance, mobile, accessibility, all tests passing
+2. Log final status to `/logs/phase-13-launch.md`
+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.**
+
+## At Every Phase
+- Update `/logs/build-state.md` when starting and completing each phase
+- Log non-obvious decisions to `/logs/decisions.md`
+- If you notice context pressure symptoms (re-reading files, forgetting decisions), ask user to run `/context`. Only checkpoint if usage exceeds 70%.

package/dist/.claude/commands/campaign.md

@@ -0,0 +1,201 @@
+The Prophets have shown me the path. Time to execute the plan.
+
+## Blitz Mode Check
+
+**IMPORTANT: If `$ARGUMENTS` contains `--blitz`, this is BLITZ MODE.** In blitz mode:
+- Do NOT ask for confirmation at mission briefs — proceed immediately
+- Run full `/assemble` (do NOT imply `--fast` — blitz means autonomous, not reduced quality)
+- Auto-continue to the next mission after each one completes
+- Auto-debrief after each mission (`/debrief --submit`)
+- Still run the Victory Gauntlet at Step 6 (non-negotiable)
+- Still commit after each mission via `/git`
+- Log mission briefs but do not wait for user input
+
+**`--blitz` ≠ `--fast`.** Blitz skips human interaction. Fast skips review phases. They are independent flags and can be combined (`--blitz --fast`) if the user wants both.
+
+**In blitz mode, make ALL decisions autonomously. Never ask the user a question. If uncertain, choose the option that preserves quality (e.g., run the Gauntlet, not skip it). The only human interaction in blitz mode is the final completion summary.**
+
+**Blitz per-mission checklist** (verify ALL before continuing to next mission):
+1. `/assemble` completed
+2. `/git` committed
+3. `/debrief --submit` filed (MANDATORY — not optional)
+4. `campaign-state.md` updated with mission status + debrief issue number
+5. Proceed to next mission
+
+## Context Setup
+1. Read `/logs/campaign-state.md` — if it exists, we're mid-campaign
+2. Read `/docs/methods/CAMPAIGN.md` for operating rules
+3. Read the PRD — check `/PRD-VOIDFORGE.md` first (VoidForge's own roadmap, root-level), fall back to `/docs/PRD.md` (user project PRD)
+
+## Planning Mode (--plan)
+
+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:
+   - 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.
+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
+
+After planning mode completes, the user can run `/campaign` (no flags) to start executing.
+
+---
+
+## Execution Mode (default)
+
+## Step 0 — Kira's Operational Reconnaissance
+
+Check for unfinished business:
+
+1. Read `/logs/campaign-state.md` — campaign progress
+2. Read `/logs/build-state.md` — in-progress builds
+3. Read `/logs/assemble-state.md` — in-progress assemblies
+4. Run `git status` — uncommitted changes
+5. Check auto-memory for project context
+6. Check for VoidForge vault: `~/.voidforge/vault.enc`
+   - If vault exists → check provisioning state (`~/.voidforge/runs/*.json`)
+   - If vault exists + not provisioned → flag: "Run `voidforge deploy` before continuing."
+   - If vault exists + provisioned → verify `.env` is populated. If not, suggest re-running provisioner.
+   - If no vault → proceed normally
+
+**Verdicts:**
+- If assemble-state shows incomplete phases → run `/assemble --resume` first
+- If build-state shows incomplete phases → resume `/build` first
+- If uncommitted changes exist → ask: "Commit first, or continue?"
+- If `/campaign --resume` was passed → resume from campaign-state's active mission
+- If campaign-state has unresolved BLOCKED items → present them: "These items from previous missions are still blocked: [list]. Resolve now, skip, or continue?"
+- If vault exists but `.env` is sparse → offer: "The vault has credentials but infrastructure isn't provisioned. Run `voidforge deploy` now?" In `--blitz` mode: auto-run provisioner.
+- If clear → proceed to Step 0.5
+
+## Step 0.5 — Vault Auto-Inject
+
+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
+
+## Step 1 — Dax's Strategic Analysis
+
+Read the PRD and diff against the codebase:
+
+1. Read the PRD fully (`/PRD-VOIDFORGE.md` if it exists at root, otherwise `/docs/PRD.md`) — extract every feature, route, schema, integration
+2. Scan the codebase — what exists? Routes, schema files, components, tests
+3. Read PRD Section 16 (Launch Sequence) for user-defined phases
+4. Read YAML frontmatter for skip flags (`auth: no`, `payments: none`, etc.)
+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.
+9. **Separately list BLOCKED items** — asset/infrastructure requirements that code can't satisfy
+
+**Priority cascade:**
+1. Section 16 phases (if defined by user)
+2. Dependency order: Auth → Core → Supporting → Integrations → Admin → Marketing
+3. Complexity-first: within a dependency tier, build the hardest features first (most integrations, most edge cases, most schema relationships). Hard things when energy is fresh, polish later.
+4. PRD section order as tiebreaker when complexity is equal
+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
+
+For the next mission on the list:
+- Are dependencies met? (e.g., Payments needs Auth)
+- Are credentials needed? (e.g., Stripe key for payments)
+- Are schema changes needed before building?
+- Any blockers from previous missions?
+
+Flag blockers. Suggest resolutions. If blocked, check the mission after.
+
+## Step 3 — Sisko's Mission Brief
+
+Present to the user:
+```
+═══════════════════════════════════════════
+  MISSION BRIEF — [Mission Name]
+═══════════════════════════════════════════
+  Objective:  [What gets built]
+  PRD Scope:  [Which sections]
+  Prereqs:    [Met / Blocked]
+  BLOCKED:    [Asset/infra items that won't be built — flag for user]
+  Est. Phases: [Which /build phases apply]
+═══════════════════════════════════════════
+  Confirm? [Y/n/skip/override]
+```
+
+If `$ARGUMENTS` contains `--blitz`, skip confirmation and proceed immediately. Otherwise, wait for user confirmation before proceeding.
+
+## Step 4 — Deploy Fury
+
+On confirmation (or immediately in `--blitz` mode):
+1. Run `/assemble` with the scoped mission description
+   When running from within `/campaign`, use a reduced pipeline: architecture (quick) + build + 1 review round + security (if new endpoints). Defer UX, DevOps, QA, Test, Crossfire, and Council to the Victory Gauntlet. This keeps per-mission cost manageable across multi-mission campaigns.
+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)
+
+After every 4th mission (missions 4, 8, 12, etc.), run a Gauntlet checkpoint before continuing:
+
+1. **Count completed missions** in this campaign. If `completedMissions % 4 === 0`, trigger checkpoint.
+
+**ENFORCEMENT:** After committing each mission, increment your mission counter. Check: if completedMissionsThisCampaign is divisible by 4, trigger the checkpoint. In blitz mode, this check is mandatory and automatic — do not skip or defer it. Log the count in campaign-state.md after each mission: "Missions completed: N. Next checkpoint at: N+X."
+
+2. **Run `/gauntlet --fast`** (3 rounds: Discovery → First Strike → Second Strike). This catches cross-module integration bugs that individual `/assemble` runs miss — each `/assemble` only reviews its own changeset, but the Gauntlet reviews the **combined system**.
+3. **Fix all Critical and High findings** before proceeding to the next mission.
+4. **Commit fixes** via `/git` with message: `Gauntlet checkpoint after mission N: X fixes`
+5. If `$ARGUMENTS` includes `--fast`, skip the checkpoint gauntlets (but NOT the final gauntlet in Step 6).
+
+**Why every 4 missions:** Individual `/assemble` runs catch 95% of issues within their scope. The remaining 5% are cross-cutting: missing imports between modules, inconsistent auth enforcement across endpoints built in different missions, CORS/CSP gaps for new connection patterns. Catching these every 4 missions prevents compounding — a bug in mission 2 that affects mission 6 is caught at mission 4, not at the end.
+
+## Step 5 — Debrief and Commit
+
+After `/assemble` completes:
+1. Run `/git` to commit and version the mission
+2. Update `/logs/campaign-state.md` — mark mission complete, update stats. When updating, include the debrief issue number: "Debrief: #XX" or "Debrief: SKIPPED (not blitz)" or "Debrief: N/A (normal mode)".
+3. **BLITZ GATE:** If `$ARGUMENTS` contains `--blitz`, run `/debrief --submit` NOW. Do not proceed to the next step until the debrief is filed. This is non-negotiable — blitz captures learnings while context is fresh. Log the debrief issue number in campaign-state.md.
+   **Lightweight alternative:** ONLY if `/context` shows actual usage above 70% (~700k tokens), append a 3-line summary to `/logs/campaign-debriefs.md` instead (mission name, finding counts, key lesson). You MUST report the actual context percentage to justify this. "Context is heavy" without a number is not valid justification.
+4. **Collect BLOCKED items** from this mission (assets, infrastructure, copy issues). For each:
+   - If it's a future feature → append to `ROADMAP.md` under the appropriate version
+   - If it's a missing asset the user must provide → add to a `## Blocked Items` section in campaign-state.md with what's needed and who can unblock it
+   - If it's a PRD requirement that can't be satisfied by code → flag in the Prophecy Board as BLOCKED with the reason
+5. Check: are all PRD requirements COMPLETE or BLOCKED?
+   - **No** → loop back to Step 1 (next mission)
+   - **Yes** → Step 6
+
+**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)
+
+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.
+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
+7. Sisko signs off: *"The Prophets' plan is fulfilled. The campaign is complete."*
+
+8. **Run `/debrief --submit`** — mandatory end-of-campaign post-mortem covering all missions together. Captures cross-cutting learnings that per-mission debriefs miss. In blitz mode, auto-submits per FIELD_MEDIC.md rule 2 exception. This is non-negotiable, like the Victory Gauntlet itself. (Field report #31)
+
+**Victory ≠ "everything built." Victory = "everything buildable was built correctly, survived the Gauntlet, and everything unbuildable is explicitly acknowledged."**
+
+## Arguments
+- `--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.
+- `--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
+
+**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/dist/.claude/commands/cultivation.md

@@ -0,0 +1,166 @@
+# /cultivation — Install the Cultivation Growth Engine
+
+> *"Cultivation is patient, strategic, and plays the longest game." — Koravellium Avast*
+
+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):
+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.
+
+## What Cultivation IS
+
+Cultivation is VoidForge's autonomous growth engine — the ensemble of:
+- Heartbeat daemon scheduled jobs (token refresh, spend monitoring, reconciliation, A/B evaluation)
+- Growth tabs in the Danger Room dashboard (Growth Overview, Ad Campaigns, Treasury, Heartbeat)
+- CLI commands (`/grow`, `/treasury`, `/portfolio`) for human-initiated strategy
+- Deterministic optimization rules that run 24/7 (kill underperformers, evaluate A/B tests, rebalance budgets)
+
+Cultivation is NOT a separate web application. The Danger Room is the single operational dashboard.
+
+## /cultivation install
+
+### Prerequisites
+1. VoidForge must be initialized (CLAUDE.md exists, PRD exists)
+2. Project does NOT need to be deployed — Cultivation now supports Day-0 setup (v14.0)
+
+### Installation Steps — 7-Step Day-0 Onboarding
+
+Growth infrastructure from the first commit, not the first customer. (Field report #131)
+
+**Step 1 — Financial Foundation:**
+- "Let's set up your growth treasury. Where will your ad spend come from?"
+- Options: Mercury (API key), Brex (OAuth), existing bank account (manual), manual budget entry, **Stablecoin Treasury (USDC / approved stablecoins)**
+- If Mercury/Brex: guide through API key/OAuth setup, test connection, store in financial vault
+- If manual: enter monthly budget allocation ($X/month for growth)
+- If **Stablecoin Treasury**:
+  1. **Provider selection:** Circle (recommended) / Bridge / Manual external off-ramp
+  2. **Destination bank:** Mercury (recommended) / External bank
+  3. **Treasury operating mode:** Maintain buffer (recommended — keep minimum USD balance) / Just-in-time funding (off-ramp only when obligation is imminent)
+  4. **Buffer threshold:** Minimum USD operating balance + minimum days of runway
+  5. **Freeze thresholds:**
+     - Stop off-ramp if reconciliation mismatch exceeds N bps
+     - Stop platform budget increases if bank balance below threshold
+     - Freeze all autonomous spend if provider connectivity fails for N consecutive cycles
+  6. **TOTP verification:** Required before enabling any write operations (off-ramp, invoice settlement, unfreeze)
+  - Store encrypted: provider credentials, source wallet/account IDs, destination bank mapping, approved networks and assets, funding mode and thresholds, TOTP metadata
+- Create financial vault `~/.voidforge/treasury/vault.enc` (AES-256-GCM, scrypt — memory-hard, zero-dep)
+- Set spending limits and circuit breakers from the start: pause if ROAS < 1.0x for 7 days, daily cap per platform
+- TOTP 2FA setup: generate secret, display QR + copyable text, store in keychain
+
+**Step 2 — Revenue Tracking:**
+- "Where does your revenue come from?"
+- Auto-detect: scan project for `stripe` dependency or `STRIPE_SECRET_KEY` in env/vault
+- If Stripe found: "Stripe is already configured. Connect it to Treasury for revenue tracking?" → store read-only API key in vault
+- If no payment processor: "Set up Stripe? Or track revenue manually?" → guide Stripe key setup or accept manual tracking
+- Connect revenue source → Treasury starts tracking from day 0
+- For pre-revenue projects: "No revenue yet? That's fine — Treasury will start tracking when your first payment arrives."
+
+**Step 3 — Ad Platform Setup:** (deferred to Mission 2 — runs via `/grow --setup`)
+- Flag: "Ad platforms can be configured later with `/grow --setup`. Continuing installation."
+
+**Step 4 — Install heartbeat daemon:**
+If `packages/voidforge/wizard/server.ts` exists:
+- Create launchd plist (macOS) or systemd unit (Linux): `com.voidforge.heartbeat`
+- Prompt for vault password to start daemon
+- Daemon begins monitoring (token refresh, health checks, reconciliation)
+
+If `packages/voidforge/wizard/server.ts` does NOT exist:
+- Display: "Step 4 (Heartbeat daemon): Skipped — requires wizard server. To enable: answer Y to the wizard pull prompt at startup, or run: `git checkout origin/main -- packages/voidforge/ && npm install`"
+
+**Step 5 — Install wizard server service** (for persistent dashboard):
+If `packages/voidforge/wizard/server.ts` exists:
+- Create launchd plist: `com.voidforge.server`
+- Wizard server runs persistently (serves Danger Room with growth tabs)
+
+If `packages/voidforge/wizard/server.ts` does NOT exist:
+- Display: "Step 5 (Wizard server): Skipped — requires wizard server."
+
+**Step 6 — Enable growth tabs in Danger Room:**
+If `packages/voidforge/wizard/server.ts` exists:
+- Growth tab: shows connected treasury + revenue data from Step 1-2
+- Treasury tab: shows vault status, circuit breakers, budget allocation
+- Campaigns tab: empty state with guidance ("Run `/grow --setup` to configure ad platforms")
+- Heartbeat tab: daemon status, last refresh timestamp
+
+If `packages/voidforge/wizard/server.ts` does NOT exist:
+- Display: "Step 6 (Danger Room tabs): Skipped — requires wizard server."
+
+**Step 7 — Confirm success:**
+
+If wizard is present (full install):
+```
+═══════════════════════════════════════════
+  CULTIVATION INSTALLED — Day 0
+═══════════════════════════════════════════
+  Financial vault:   ✓ Created
+  TOTP 2FA:          ✓ Configured
+  Treasury:          ✓ Connected (Mercury | Manual: $X/mo)
+  Revenue:           ✓ Connected (Stripe) | ○ Not yet
+  Heartbeat daemon:  ✓ Running (PID XXXXX)
+  Danger Room:       ✓ Growth tabs enabled
+  Dashboard:         http://localhost:3141/danger-room#growth
+═══════════════════════════════════════════
+  Next steps:
+    /grow --setup     Configure ad platforms
+    /grow             Start your first growth campaign
+═══════════════════════════════════════════
+```
+
+If wizard is NOT present (partial install):
+```
+═══════════════════════════════════════════
+  CULTIVATION INSTALLED — Day 0 (Partial)
+═══════════════════════════════════════════
+  Financial vault:   ✓ Created
+  TOTP 2FA:          ✓ Configured
+  Treasury:          ✓ Connected (Mercury | Manual: $X/mo)
+  Revenue:           ✓ Connected (Stripe) | ○ Not yet
+  Heartbeat daemon:  — Skipped (requires wizard)
+  Wizard server:     — Skipped (requires wizard)
+  Danger Room:       — Skipped (requires wizard)
+═══════════════════════════════════════════
+  Steps 1-3 complete. Steps 4-6 require the wizard server.
+  To enable full Cultivation:
+    git checkout origin/main -- packages/voidforge/
+    npm install
+  Then re-run /cultivation install to complete Steps 4-6.
+
+  What works now:
+    /grow             Phases 1-3 (SEO, analytics, content)
+    /grow --audit-only  Full methodology audit
+═══════════════════════════════════════════
+```
+
+**Step 8 — Offer Tier 3 opt-in:**
+If `packages/voidforge/wizard/server.ts` exists:
+- "Enable scheduled AI agents? These run weekly creative refresh and monthly strategy reviews. They consume Claude API credits. [Y/n]"
+- If yes: configure `--auto-creative` and `--auto-strategy` flags
+
+If `packages/voidforge/wizard/server.ts` does NOT exist:
+- Display: "Step 8 (Scheduled AI agents): Skipped — requires heartbeat daemon."
+
+## /cultivation status
+
+Also available as `--status` flag for consistency.
+
+Show current Cultivation state:
+- Heartbeat daemon: running/stopped/degraded
+- Growth tabs: enabled/disabled
+- Active campaigns: count
+- Platforms connected: list
+- Vault session: active/expired
+
+## /cultivation uninstall
+
+1. Warn about active campaigns
+2. Offer to pause all campaigns
+3. Export financial data
+4. Remove launchd/systemd services
+5. NEVER auto-delete `~/.voidforge/treasury/`
+
+## Arguments
+$ARGUMENTS

package/dist/.claude/commands/current.md

@@ -0,0 +1,128 @@
+# /current — Tuvok's Deep Current (Autonomous Campaign Intelligence)
+
+> *"Logic is the beginning of wisdom, not the end."*
+
+Read `/docs/methods/DEEP_CURRENT.md` for operating rules.
+
+## Prerequisites
+If `packages/voidforge/wizard/server.ts` does not exist and the mode requires it (`--scan`, `--propose`, default):
+1. Offer: "Deep Current's site scanner and daemon integration require the wizard server. Pull it from upstream? [Y/n]" (Note: `--intake` works without wizard/ — it's a Claude Code interview, not a server feature.)
+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`
+3. On no: stop with "Run manually: `git checkout voidforge/main -- packages/voidforge/`"
+
+## Context Setup
+1. Read `/logs/deep-current/situation.json` — if exists, we have a situation model
+2. Read `/logs/campaign-state.md` — campaign history
+3. If no situation model: this is first run — classify project state
+
+## Default Mode (scan → analyze → propose)
+
+### Step 1 — SENSE (Torres + Vin + Marsh + Kira)
+
+Torres scans the deployed site (if deployed):
+- HTTP response times on main routes
+- Meta tags (title, description, OG, JSON-LD)
+- Security headers (HTTPS, HSTS, CSP, CORS)
+- Cache headers, compression
+- Analytics snippets detected (GA4, Plausible, PostHog)
+- Mobile viewport, favicon, sitemap, robots.txt
+
+Vin reads analytics (if connected):
+- Traffic trends (7-day, 30-day)
+- Top pages, referral sources
+- Conversion rates by path
+- Bounce rates
+
+Marsh scans competitors (from PRD or user input):
+- Pricing, features, positioning
+- SEO comparison (meta tags, structured data)
+
+Kira reads operational state:
+- Campaign history, gauntlet history, build state
+- Unresolved BLOCKED items
+- Active heartbeat daemon status
+
+### Step 2 — ANALYZE (Seven)
+
+Seven scores 5 dimensions (0-100):
+1. **Feature completeness** — PRD vs codebase diff (Dax's existing logic)
+2. **Quality** — gauntlet findings + field report count + test coverage
+3. **Performance** — Lighthouse scores + response times
+4. **Growth readiness** — analytics presence + SEO + conversion paths + content
+5. **Revenue potential** — pricing page + payment integration + funnel completeness
+
+Lowest score = first priority.
+
+### Step 3 — PROPOSE (Tuvok)
+
+Generate campaign proposal:
+```markdown
+# Campaign Proposal — [Name]
+## Generated by: The Deep Current (Tuvok)
+## Trigger: [signal that caused this]
+
+### The Case
+[Data-backed reasoning for this campaign]
+
+### Missions
+[Ordered list, same format as Dax's Prophecy Board]
+
+### Expected Impact
+[Quantified prediction: "SEO fixes → +30% organic traffic"]
+
+### Risk Assessment
+[What could go wrong]
+
+### Alternatives Considered
+[What else was evaluated]
+
+### Autonomy Recommendation
+[Tier 1/2/3 with rationale]
+```
+
+Save to `/logs/deep-current/proposals/YYYY-MM-DD-[name].md`
+
+### Step 4 — Present
+
+Show the proposal. In Tier 1 (default): "Tuvok recommends this campaign. Launch? [Y/n/modify]"
+
+## --intake Mode (Cold Start)
+
+For greenfield or new projects:
+1. Ask: "What problem are you solving? For whom?" (ONE paragraph)
+2. Torres scans the site (if deployed)
+3. Marsh scans competitors
+4. Seven identifies gaps
+5. Tuvok generates a draft PRD (via /prd internally)
+6. User reviews PRD
+7. Paris computes first campaign
+8. Present proposal
+
+## --scan Mode
+
+Run SENSE step only. Update situation model. No proposal.
+
+## --status Mode
+
+Show current situation model:
+```
+═══════════════════════════════════════════
+  DEEP CURRENT — [Project Name]
+═══════════════════════════════════════════
+  State:    [GREENFIELD/PARTIAL/DEPLOYED/OPERATING]
+  Last scan: [timestamp]
+
+  Feature:     ████████░░  78/100
+  Quality:     █████████░  85/100
+  Performance: ██████░░░░  62/100
+  Growth:      ████░░░░░░  45/100  ← lowest
+  Revenue:     ███████░░░  70/100
+
+  Recommendation: [one-line from latest proposal]
+  Prediction accuracy: XX% (N campaigns)
+  Autonomy tier: [1/2/3]
+═══════════════════════════════════════════
+```
+
+## Arguments
+$ARGUMENTS