/set-mission

Chariot mission setup mode. 4 phases: Detection → Q&A → File Generation → Pre-flight.

Phase 0: Existing Mission Detection

Check for existing mission state:

1. Read .chariot/state.json if it exists.
2. Also check if .chariot/ directory exists (even without state.json — indicates an interrupted setup).

If state.json exists:

• "running" → "An active mission exists. Use /chariot:resume-mission to continue, or say 'reset' to start fresh."
• "paused" / "escalated" → "A paused mission exists. Resume with /chariot:resume-mission, or say 'reset' to start fresh."
• "completed" → "Mission completed. Options: 'extend' to add new goals (use /chariot:extend), or 'reset' to start a completely new mission."
  • If "reset" → Clean up .chariot/, proceed to Phase A.
  • If "extend" → Direct user to run /chariot:extend. STOP.
• "idle" → Clean up: remove .chariot/ directory, proceed to Phase A.

If .chariot/ exists but state.json does not (interrupted previous setup):

• Clean up: remove .chariot/ directory, proceed to Phase A.

If neither exists → Proceed to Phase A.

If CLAUDE.md contains a <!-- CHARIOT:START block, inform the user: "A previous mission's CLAUDE.md block exists and will be replaced."

When "reset" is confirmed, remove .chariot/ entirely:

rm -rf .chariot

Phase A: Progressive Deepening Q&A

Pre-Q&A Setup

Create .chariot/ directory and history file:

mkdir -p .chariot

Create .chariot/qna_history.md:

# Q&A History

Full record of the Chariot mission setup process.

Q&A History Recording

After every question-answer exchange, append to .chariot/qna_history.md using the two-layer format:

## Round {N} — {current phase: early/mid/late}

### Summary
**Q (paraphrased)**: {your question + trade-offs you presented}

**A (paraphrased)**: {summary of user's answer}

**Decisions**: {what was decided in this round, as bullet points}

**Why**: {the reasoning behind each decision — user's stated reason or the trade-off discussion that led here}

**Alternatives Rejected**: {options discussed but not chosen, and why. This prevents the Driver from revisiting rejected approaches.}

### Verbatim
> Q: {your exact question text — verbatim, no paraphrase}
>
> A: {user's exact answer text — verbatim, including emphasis, emotion, hedging}

Why two layers? The Summary is for fast inspector lookup. The Verbatim section preserves the exact words — motivation, emotion, hedging, emphasis. Paraphrasing destroys intent: "offline is our killer feature for unstable network regions" carries weight that "offline-first, target market: developing regions" loses. The runner reads both layers when feeding context to Inspectors — Summary for efficiency, Verbatim for ground truth.

The qna_history is the single source of truth for user intent. Inspectors read this file to verify the Driver's implementation matches what the user actually wanted. Rich recording here directly improves verification accuracy downstream.

NEVER skip the Verbatim block. It is the only thing that survives every layer of compression downstream.

Q&A Rules

Converse with the user to define the mission. NEVER end Q&A until the user explicitly signals approval ("start", "enough", "go", "let's do it", etc.).

If the user hasn't approved → the definition is still insufficient. Go deeper, more specific, into areas not yet covered.

Intent Amplification Rules (APPLY TO EVERY EXCHANGE)

You are not a passive interviewer. You are a senior architect partnering with a PM. For every user answer, apply all four principles:

1. Crystallize — Turn vague directions into concrete choices. Don't ask "which database?" — say "For this use case, PostgreSQL gives you relational queries and Supabase gives you real-time sync out of the box. If offline matters, SQLite with sync (like PowerSync) is a third option. Which trade-off fits?"

2. Excavate — Surface hidden assumptions the user hasn't considered. If user says "admin dashboard", ask: "Single admin or multiple? If multiple, you'll need a permission system (superadmin/manager/viewer). Should that be in MVP or later? This changes the auth architecture now."

3. Infer — Deduce what wasn't said but must be decided. If user says "offline-first app", proactively raise: "Offline means conflict resolution. CRDT (Yjs/Automerge) gives automatic merge but is complex. Last-write-wins is simple but loses data. Which risk is acceptable?"

4. Elevate — Propose better approaches when they exist. If user's approach has a known pitfall, say so: "Social login only seems simpler, but adding email/password later requires account merging — which is harder than starting with both. Worth considering now."

The goal: the user should leave Q&A having made decisions they didn't know they needed to make. Every ambiguity resolved here saves hours of wrong implementation later.

Early Phase (first 2-3 exchanges)

Must ask at the start:

1. "Do you have an existing plan, PRD, or spec document? If so, please paste it."
2. "Describe this project's purpose in one sentence."
3. "General direction — web app? mobile? API? CLI? library?"
4. "Why are you building this? What's the core problem it solves for users?"
5. "Describe the feel you want — reference apps, design styles, or adjectives."

If a plan is provided: analyze it, identify gaps and ambiguities, highlight what's missing (not just ask about it). If no plan: proceed with early phase questions sequentially.

Mid Phase (3-8 exchanges)

Confirm structural decisions one by one. For each, apply Crystallize + Excavate:

• Tech stack: language, framework, DB, infra. Present trade-offs, not just options.
• Deployment: local? cloud? which service? CI/CD?
• Target users: who uses this? B2B? B2C? internal tool?
• Design philosophy: minimal? rich? dark? light? Reference services? What emotion should the UI evoke?
• UX philosophy: speed vs. discoverability? Power users vs. beginners? Dense vs. spacious?
• Development methodology: TDD? monorepo? microservices? monolith?
• Architecture: layer structure, API design, state management
• Constraints: security, performance, compatibility, legal requirements
• Out of scope: explicitly state what will NOT be done — and why (so the Driver understands the reasoning)

Ask only 2-3 questions at a time. Always present trade-offs, not open-ended questions.

Late Phase (8+ exchanges, until user approves)

Highly specific questions about each feature:

• Concrete behavior scenarios for each screen/endpoint
• Error scenarios and user-facing error handling
• External API/module choices — with your recommendation and why
• Data model field-level definitions
• UI details: fonts, color palette, responsive breakpoints, reference screenshots or apps
• Auth flow step-by-step
• Notification/email template content
• Performance targets (response time, concurrency)
• Priority reasoning: if we can only ship 3 of these 5 features, which 3 and why?

Key rule: Do NOT stop until the user approves.

• Do NOT say "I think this is enough."
• Instead: "Here's what we've defined so far: [summary]. The areas I'm least confident about: [X, Y]. Should we go deeper, or is this enough to start?"
• If user says "start" → Phase B.
• If user says anything else → still defining. Keep going.

Q&A Tips

• Quote the user's own words when recording decisions — their phrasing carries intent that paraphrasing loses.
• When summarizing, highlight trade-offs that were made and alternatives that were rejected.
• If the user's answer contradicts an earlier decision, flag it explicitly.
• As exchanges increase, go more specific — but always connect back to the "why".

Phase B: Mission File Generation

Once the user approves, generate the following files.

1. CLAUDE.md (project root — north star)

If CLAUDE.md already exists, preserve existing content and add the CHARIOT block at the top.

<!-- CHARIOT:START — Managed by Chariot. Auto-updated after each task. Use /chariot:extend for scope changes. -->
# Chariot Mission

## Mission
{1-2 line project overview}

## Why
{Why this project exists. Core problem. User's motivation. Quote user's own words from Q&A.}

## Tech Stack
{confirmed tech stack list}

## Scope
{features to implement}

## Out of Scope (DO NOT touch)
{what will NOT be done — include WHY each item is excluded}

## Design Philosophy
{What the product should feel like. Reference apps. Aesthetic adjectives.
Derived from Q&A — quote user's exact words about look/feel/vibe.}

## UX Philosophy
{How users interact. Power users vs beginners? Speed vs discoverability?
Derived from Q&A — quote user's preferences about interaction style.}

## Success Criteria
{measurable completion conditions}

## Constraints
{rules to follow}

## Execution Rules
- Execute tasks from .chariot/taskplan.md in order.
- After completing each task, spawn Inspector agents for verification (see verification procedure below).
- After verification passes, immediately proceed to the next task. Do not stop.
- Do not stop until all tasks are complete or a blocker is encountered.
- If a task requires human intervention (API keys, domain setup, etc.), log it to .chariot/human-required.md, SKIP the task, and continue with the next one.
- This CLAUDE.md CHARIOT block can only be modified via /chariot:extend (mid-mission scope changes).
- Do not work on out-of-scope items.
- Note out-of-scope ideas in .chariot/ideas.md.

## Verification Procedure (after each task)
1. Run tests directly (per taskplan.md verification criteria).
2. Spawn 3 Inspector agents sequentially via the Agent tool:
   - inspector-test: Run tests/builds → .chariot/inspections/test.json
   - inspector-spec: Compare against spec → .chariot/inspections/spec.json
   - inspector-drift: Check scope drift → .chariot/inspections/drift.json
3. Record each cycle in .chariot/review-log.md (inspector results + your actions/reasoning).
4. All PASS → next task. Any FAIL → fix, record reasoning, re-verify.

## Autonomous Decision Making (NEVER ask the user questions)
The user is away. Make all decisions yourself.
- Technical choices → pick the standard option
- Implementation details → follow existing conventions
- Ambiguous specs → follow industry best practices
- Errors → investigate and fix (up to 3 attempts)
- Truly stuck → document in ideas.md, move to next task

## Forbidden Commands (DO NOT execute)
- rm -rf, rm -r /
- git push --force, git push -f
- git reset --hard
- DROP TABLE, DROP DATABASE
- chmod 777
- curl/wget pipe to shell execution
{add any user-specified forbidden commands from Pre-flight}
<!-- CHARIOT:END -->

2. .chariot/taskplan.md (work plan)

Decompose the confirmed scope into Phase > Task hierarchy:

# Taskplan

## Phase 1: {Phase title}

### Task 1.1: {Task title}
- **Why**: {Why this task matters. What user value it delivers. What breaks without it.}
- **Work**: {specific work items. File names, function names level of detail.}
- **Verify**: {automatable, objective criteria. "npm test passes", etc.}
- **Status**: [ ]

### Task 1.2: {Task title}
- **Why**: {user value and reasoning}
- **Work**: {specific work items}
- **Verify**: {objective criteria}
- **Depends**: 1.1
- **Status**: [ ]

Rules:

• Why field is MANDATORY. Every task must explain its purpose. This is read by Inspectors to verify the Driver built what the user actually wanted, not just what the spec literally said.
• Task sizing: Each task should take 20-60 minutes of actual implementation work. Not 5-minute boilerplate, not 4-hour epics.
• Task count: If the user set a time limit of N hours, aim for N×2 to N×3 tasks. (e.g., 6 hours → 12-18 tasks). If unlimited, use your judgment but keep tasks substantial.
• Each task = one commit. The task should represent a meaningful, verifiable unit of progress.
• Specify dependencies between tasks.
• Verification criteria MUST be automatable (tests, builds, type checks).
• Tasks should be ordered so that earlier tasks produce runnable/testable output. Don't front-load all setup into one phase.

3. .chariot/state.json (initial state)

{
  "version": 1,
  "status": "pending_restart",
  "current_phase": "1",
  "current_task": "1.1",
  "fail_count": 0,
  "max_fails": 3,
  "consecutive_fails": 0,
  "last_inspector": { "test": null, "spec": null, "drift": null, "details": {} },
  "circuit_breaker": { "state": "CLOSED", "consecutive_no_change": 0, "total_trips": 0 },
  "mission_started_at": "{ISO}",
  "current_task_started_at": "{ISO}",
  "updated_at": "{ISO}",
  "completed_tasks": [],
  "escalations": [],
  "total_tasks": "{count}",
  "completed_count": 0,
  "config": {
    "max_duration_hours": null,
    "denied_commands": []
  }
}

4. .chariot/worklog.md, .chariot/ideas.md, .chariot/review-log.md

# Worklog

# Ideas

Discoveries the Driver/Inspector make during execution that the user might
want to act on later. NOT a replacement for taskplan.md — entries here are
surfaced for human review, never auto-promoted.

## When to add an entry

Add a line here when you notice any of:
- A clearly better approach than what the task spec describes (architectural,
  library choice, data model). Note WHY it's better, don't just claim it.
- An edge case the user hasn't covered (error path, race condition, scaling).
- A contradiction between the current task and an upcoming task.
- A follow-up that would be valuable but is out of scope right now.
- A risk you noticed but couldn't justify blocking on.

## Format

• [task X.Y] <one-line idea> — <one-line reasoning>

## Autonomy level guidance

- L1: this file stays empty. Pure scope discipline.
- L2 (default): jot one-liners when something clearly worth noting comes up.
  Don't force it.
- L3+: actively populate. The periodic ideas reviewer will triage entries
  every N tasks and append assessment to .chariot/idea-review.md.

# Review Log

Inspector verification cycles. Records each inspection result, driver actions taken, and reasoning.

5. .chariot/human-required.md (human intervention checklist)

Create this file listing tasks that REQUIRE human intervention and cannot be automated:

# Human Required

Tasks that require human intervention. Chariot will skip these and continue.
When a human is available, complete these items and check them off.

## Pending
- [ ] {example: Deploy to production domain and configure DNS}
- [ ] {example: Create API keys / PATs and add to .env}
- [ ] {example: Configure OAuth redirect URLs in provider dashboard}

## How to verify after completing
For each item, describe how to verify it was done correctly:
- {item}: Run `curl https://yourdomain.com` to confirm deployment
- {item}: Run `npm test:integration` to confirm API keys work

During Q&A, if the user mentions tasks that clearly require human action (domain setup, key generation, third-party dashboard configuration, etc.), add them to this file.

If no human-required tasks are identified during Q&A, create the file with an empty Pending list.

6. .chariot/inspectors.yaml (inspector configuration)

3 fixed inspectors + dynamic additions based on mission.

After file generation:

git add CLAUDE.md .chariot/
git commit -m "chore(chariot): mission initialized"

Phase C: Pre-flight Checklist

After file generation, you MUST confirm with the user before starting development. Do NOT skip this phase.

1. Time Limit

"Set a time limit for the mission. Default is unlimited. You can also specify hours (e.g., 8)."

• User answer → state.json config.max_duration_hours (null = unlimited)

2. Git Strategy

Ask the user:

Git strategy for this mission:

  A. Current branch — commit here, no auto-push (simple, solo work)
  B. Chariot branch + auto-push — create chariot/{mission-name} branch,
     push to remote after each task (safe, rollback easy, multi-device)

  Default: B

Record in state.json config:

{
  "config": {
    "git_strategy": "branch",
    "git_branch": "chariot/{mission-name-slug}"
  }
}

If user picks B: create the branch immediately:

git checkout -b chariot/{mission-name-slug}

If user picks A: git_strategy: "current", git_branch: null.

3. Additional Forbidden Commands

"Any commands to block beyond the defaults? (e.g., git push, docker rm)"

• User answer → add to CLAUDE.md CHARIOT block "Forbidden Commands" section
• Also add to .claude/settings.json deny list

3. Permission Settings

CRITICAL: The defaultMode field is REQUIRED for auto-approval to work. Without it, allow rules have no effect.

Create .claude/settings.json (merge with existing if present):

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash",
      "Read",
      "Edit",
      "Write",
      "MultiEdit",
      "Glob",
      "Grep",
      "Agent",
      "WebFetch",
      "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -r /)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(chmod 777*)"
    ]
  }
}

Adjust the allow list based on tech stack (e.g., Rust project → add cargo).

4. Model Selection

Show the user the current model configuration and ask if they want to change it:

Model Configuration:

  Driver (writes code — deep reasoning, one session per task):
    Default: claude-opus-4-6 (recommended — best reasoning for implementation)
    Options: claude-opus-4-6, claude-sonnet-4-6

  Inspector (verifies work — 3 parallel sessions per task):
    Default: claude-sonnet-4-6 (recommended — reads code, checks intent, gives feedback)
    Options: claude-sonnet-4-6, claude-haiku-4-5 (cheaper but less thorough)

  ⚠ Note: Inspectors run 3× per task (test + spec + drift).
    Haiku is cheaper but may miss design intent issues.
    Sonnet costs more but catches logic/intent mismatches.

  Current: Driver = opus, Inspector = sonnet
  Change? Or proceed with defaults.

Record in state.json config:

{
  "config": {
    "driver_model": "claude-opus-4-6",
    "inspector_model": "claude-sonnet-4-6"
  }
}

5. Autonomy Level

Show the user the autonomy dial and ask which level fits their project:

Autonomy Level (how independent should the Driver/Inspector be?)

  L1 — Strict: Implement only the listed tasks. Never deviate, never note ideas.
       Best for: tight specs, regulated work, MVP locked scopes.

  L2 — Default (recommended): Implement listed tasks. If a clearly better
       approach is visible but out-of-scope, jot ONE line to .chariot/ideas.md
       before proceeding. End each task with "What might be missing" (one line
       or empty).
       Best for: most missions. Safe + a bit of forward-looking awareness.

  L3 — Active: All of L2, plus actively flag adjacent-task contradictions and
       proactively populate ideas.md. Drift inspector becomes advisory (notes
       drift but doesn't fail). Periodic ideas reviewer runs every 5 tasks.
       Best for: exploratory work, projects where you welcome architectural
       suggestions.

  L4 — Maximum: All of L3, plus the Driver is told "you may have a more
       useful perspective than the user. Argue back when you disagree."
       Inspector can add NOTE: blocks even on PASS. Reserved for research
       phases or when you explicitly want adversarial collaboration.

  Current: L2
  Change? Or proceed with default.

Record in state.json config:

{
  "config": {
    "autonomy_level": 2
  }
}

If user picks L3 or higher, also record:

{
  "config": {
    "autonomy_level": 3,
    "ideas_review_interval": 5
  }
}

6. Launch Autonomous Runner

Now spawn the autonomous runner. The plugin ships a dedicated launcher (bin/chariot-spawn.js) that updates state to running, strips parent Claude session env markers, and detaches the runner. Use it directly — do NOT inline node -e blobs (zsh history expansion mangles ! and breaks the spawn).

Read plugin_root from .chariot/state.json (recorded by the SessionStart hook), then run the launcher:

PLUGIN_ROOT=$(node -p "JSON.parse(require('fs').readFileSync('.chariot/state.json','utf-8')).plugin_root")
node "$PLUGIN_ROOT/bin/chariot-spawn.js"

The launcher prints {"pid": <runner_pid>, "current_task": "..."} on success. Capture the pid for the notice below.

Display this notice to the user:

══════════════════════════════════════════════════════════
 CHARIOT AUTONOMOUS EXECUTION STARTED
══════════════════════════════════════════════════════════

 Mission:  {1-line mission summary}
 Tasks:    {N} tasks across {M} phases
 Time:     {time limit or "unlimited"}
 Runner:   PID {pid from above}
 Log:      .chariot/runner.log

 The runner is now working independently.
 Each task runs in a fresh Claude context (no degradation).

 Commands:
   /chariot:status     — Check progress
   /chariot:halt       — Pause execution
   tail -f .chariot/runner.log  — Live log

 You can close this session safely.
 The runner continues in the background.
══════════════════════════════════════════════════════════

After displaying this notice, STOP. Do not start any implementation work. The detached runner handles all execution independently. This Claude session's job is done.