Bundle mission-control into Triple-C instead of cloning from GitHub

The mission-control (Flight Control) project is being closed upstream.
This embeds the project files directly in the repo under container/mission-control/,
bakes them into the Docker image at /opt/mission-control, and copies them into place
at container startup instead of git cloning from GitHub.

Also adds missing osc52-clipboard, audio-shim, and triple-c-sso-refresh to the
programmatic Docker build context in image.rs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

HOW-TO-USE.md

@@ -226,12 +226,12 @@ When enabled, the host Docker socket is mounted into the container so Claude Cod
 
 ### Mission Control
 
-Toggle **Mission Control** to integrate [Flight Control](https://github.com/msieurthenardier/mission-control) — an AI-first development methodology — into the project. When enabled:
+Toggle **Mission Control** to integrate Flight Control — an AI-first development methodology bundled with Triple-C — into the project. When enabled:
 
-- The Flight Control repository is automatically cloned into the container
+- The bundled Flight Control files are installed into the container
 - Flight Control skills are installed to Claude Code's skill directory (`~/.claude/skills/`)
 - Project instructions are appended with Flight Control workflow guidance
-- The repository is symlinked at `/workspace/mission-control`
+- The files are symlinked at `/workspace/mission-control`
 
 Available skills include `/mission`, `/flight`, `/leg`, `/agentic-workflow`, `/flight-debrief`, `/mission-debrief`, `/daily-briefing`, and `/init-project`.
 

MISSION-CONTROL-SETUP.md

@@ -0,0 +1,106 @@
+# Mission Control Setup Instructions
+
+Reference document for adding Flight Control methodology to any project.
+
+## How Triple-C Installs Mission Control
+
+When Mission Control is enabled for a project in Triple-C:
+
+1. **Bundled files install**: The Mission Control files bundled with Triple-C are copied to `/home/claude/mission-control/` (persisted in the config volume)
+2. **Skills install**: All skills from the bundled `.claude/skills/` are copied to `~/.claude/skills/` so Claude Code discovers them automatically as `/slash-commands`
+3. **Workspace symlink**: `/workspace/mission-control/` symlinks to the installed copy for methodology doc access
+4. **Global instructions**: Mission Control usage instructions are injected into `~/.claude/CLAUDE.md`
+
+This happens automatically on every container start, so skill updates from new Triple-C releases are picked up on restart.
+
+## Two pieces are needed per project:
+
+1. **Global CLAUDE.md** — Handled automatically by Triple-C when Mission Control is enabled
+2. **Project CLAUDE.md** — Add the Flight Operations section to each project's `CLAUDE.md`
+
+Then run `/init-project` to create the `.flightops/` directory.
+
+---
+
+## 1. Global CLAUDE.md Instructions
+
+These are **automatically injected by Triple-C** when Mission Control is enabled. For reference, the injected content is:
+
+```markdown
+## Mission Control
+
+The `/workspace/mission-control/` directory contains **Flight Control** — an AI-first development methodology for structured project management. Use it for all project work.
+
+### How It Works
+
+- **Mission Control is a tool, not a project.** It provides skills and methodology for managing other projects.
+- All Flight Control skills are installed as personal skills in `~/.claude/skills/` and are automatically available as `/slash-commands`
+- The methodology docs and project registry live in `/workspace/mission-control/`
+
+### When to Use
+
+When working on any project that has a `.flightops/` directory, follow the Flight Control methodology:
+1. Read the project's `.flightops/ARTIFACTS.md` to understand artifact storage
+2. Read `.flightops/FLIGHT_OPERATIONS.md` for the implementation workflow
+3. Use Mission Control skills for planning and execution
+
+### Available Skills
+
+| Skill | When to Use |
+|-------|-------------|
+| `/init-project` | Setting up a new project for Flight Control |
+| `/mission` | Defining new work outcomes (days-to-weeks scope) |
+| `/flight` | Creating technical specs from missions (hours-to-days scope) |
+| `/leg` | Generating implementation steps from flights (minutes-to-hours scope) |
+| `/agentic-workflow` | Executing legs with multi-agent workflow (implement, review, commit) |
+| `/flight-debrief` | Post-flight analysis after a flight lands |
+| `/mission-debrief` | Post-mission retrospective after completion |
+| `/daily-briefing` | Cross-project status report |
+
+### Key Rules
+
+- **Planning skills produce artifacts only** — never modify source code directly
+- **Phase gates require human confirmation** — missions before flights, flights before legs
+- **Legs are immutable once in-flight** — create new ones instead of modifying
+- **`/agentic-workflow` orchestrates implementation** — it spawns separate Developer and Reviewer agents
+- **Artifacts live in the target project** — not in mission-control
+```
+
+---
+
+## 2. Project CLAUDE.md Instructions
+
+Add this section to each project's `CLAUDE.md`:
+
+```markdown
+## Flight Operations
+
+This project uses Flight Control (bundled with Triple-C) for structured development.
+
+**Before any mission/flight/leg work, read these files in order:**
+1. `.flightops/README.md` — What the flightops directory contains
+2. `.flightops/FLIGHT_OPERATIONS.md` — **The workflow you MUST follow**
+3. `.flightops/ARTIFACTS.md` — Where all artifacts are stored
+4. `.flightops/agent-crews/` — Project crew definitions for each phase (read the relevant crew file)
+```
+
+---
+
+## 3. Initialize the Project
+
+After adding the CLAUDE.md sections, run `/init-project` from mission-control to:
+
+1. Create the `.flightops/` directory with methodology references
+2. Configure the artifact system (files or Jira)
+3. Set up agent crew definitions
+4. Register the project in `/workspace/mission-control/projects.md`
+
+---
+
+## Quick Checklist for New Projects
+
+- [ ] Enable Mission Control for the project in Triple-C (auto-installs skills to `~/.claude/skills/`)
+- [ ] Add Flight Operations section to the project's `CLAUDE.md`
+- [ ] Run `/init-project` from mission-control
+- [ ] Add the project to `/workspace/mission-control/projects.md`
+- [ ] Add `.flightops/` to the project's `.gitignore` (if artifacts should not be committed) or commit it (if they should)

README.md

@@ -83,7 +83,7 @@ Triple-C supports [Model Context Protocol (MCP)](https://modelcontextprotocol.io
 
 ### Mission Control Integration
 
-Optional per-project integration with [Flight Control](https://github.com/msieurthenardier/mission-control) — an AI-first development methodology. When enabled, the repo is cloned into the container, skills are installed, and workflow instructions are injected into CLAUDE.md.
+Optional per-project integration with Flight Control — an AI-first development methodology bundled with Triple-C. When enabled, the bundled files are installed into the container, skills are installed, and workflow instructions are injected into CLAUDE.md.
 
 ### Web Terminal (Remote Access)
 

app/src-tauri/Cargo.lock

@@ -1957,6 +1957,25 @@ dependencies = [
  "png 0.18.1",
 ]
 
+[[package]]
+name = "include_dir"
+version = "0.7.4"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "923d117408f1e49d914f1a379a309cffe4f18c05cf4e3d12e613a15fc81bd0dd"
+dependencies = [
+ "include_dir_macros",
+]
+
+[[package]]
+name = "include_dir_macros"
+version = "0.7.4"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "7cab85a7ed0bd5f0e76d93846e0147172bed2e2d3f859bcc33a8d9699cad1a75"
+dependencies = [
+ "proc-macro2",
+ "quote",
+]
+
 [[package]]
 name = "indexmap"
 version = "1.9.3"
@@ -4927,6 +4946,7 @@ dependencies = [
  "fern",
  "futures-util",
  "iana-time-zone",
+ "include_dir",
  "keyring",
  "local-ip-address",
  "log",

app/src-tauri/Cargo.toml

@@ -28,6 +28,7 @@ dirs = "6"
 log = "0.4"
 fern = { version = "0.7", features = ["date-based"] }
 tar = "0.4"
+include_dir = "0.7"
 reqwest = { version = "0.12", default-features = false, features = ["json", "rustls-tls"] }
 iana-time-zone = "0.1"
 sha2 = "0.10"

app/src-tauri/src/docker/container.rs

@@ -80,7 +80,7 @@ When working on any project that has a `.flightops/` directory, follow the Fligh
 
 const MISSION_CONTROL_PROJECT_INSTRUCTIONS: &str = r#"## Flight Operations
 
-This project uses [Flight Control](https://github.com/msieurthenardier/mission-control) for structured development.
+This project uses **Flight Control** (bundled with Triple-C) for structured development.
 
 **Before any mission/flight/leg work, read these files in order:**
 1. `.flightops/README.md` — What the flightops directory contains

app/src-tauri/src/docker/image.rs

@@ -1,6 +1,7 @@
 use bollard::image::{BuildImageOptions, CreateImageOptions, ListImagesOptions};
 use bollard::models::ImageSummary;
 use futures_util::StreamExt;
+use include_dir::{include_dir, Dir};
 use std::collections::HashMap;
 use std::io::Write;
 
@@ -11,6 +12,11 @@ const DOCKERFILE: &str = include_str!("../../../../container/Dockerfile");
 const ENTRYPOINT: &str = include_str!("../../../../container/entrypoint.sh");
 const SCHEDULER: &str = include_str!("../../../../container/triple-c-scheduler");
 const TASK_RUNNER: &str = include_str!("../../../../container/triple-c-task-runner");
+const OSC52_CLIPBOARD: &str = include_str!("../../../../container/osc52-clipboard");
+const AUDIO_SHIM: &str = include_str!("../../../../container/audio-shim");
+const SSO_REFRESH: &str = include_str!("../../../../container/triple-c-sso-refresh");
+
+static MISSION_CONTROL_DIR: Dir = include_dir!("$CARGO_MANIFEST_DIR/../../container/mission-control");
 
 pub async fn image_exists(image_name: &str) -> Result<bool, String> {
     let docker = get_docker()?;
@@ -150,38 +156,48 @@ where
     Ok(())
 }
 
+fn append_file_to_archive(
+    archive: &mut tar::Builder<&mut Vec<u8>>,
+    path: &str,
+    content: &[u8],
+    mode: u32,
+) -> Result<(), std::io::Error> {
+    let mut header = tar::Header::new_gnu();
+    header.set_size(content.len() as u64);
+    header.set_mode(mode);
+    header.set_cksum();
+    archive.append_data(&mut header, path, content)
+}
+
+fn append_embedded_dir(
+    archive: &mut tar::Builder<&mut Vec<u8>>,
+    dir: &Dir,
+    prefix: &str,
+) -> Result<(), std::io::Error> {
+    for file in dir.files() {
+        let path = format!("{}/{}", prefix, file.path().display());
+        append_file_to_archive(archive, &path, file.contents(), 0o644)?;
+    }
+    for subdir in dir.dirs() {
+        append_embedded_dir(archive, subdir, prefix)?;
+    }
+    Ok(())
+}
+
 fn create_build_context() -> Result<Vec<u8>, std::io::Error> {
     let mut buf = Vec::new();
     {
         let mut archive = tar::Builder::new(&mut buf);
 
-        let dockerfile_bytes = DOCKERFILE.as_bytes();
+        append_file_to_archive(&mut archive, "Dockerfile", DOCKERFILE.as_bytes(), 0o644)?;
-        let mut header = tar::Header::new_gnu();
+        append_file_to_archive(&mut archive, "entrypoint.sh", ENTRYPOINT.as_bytes(), 0o755)?;
-        header.set_size(dockerfile_bytes.len() as u64);
+        append_file_to_archive(&mut archive, "triple-c-scheduler", SCHEDULER.as_bytes(), 0o755)?;
-        header.set_mode(0o644);
+        append_file_to_archive(&mut archive, "triple-c-task-runner", TASK_RUNNER.as_bytes(), 0o755)?;
-        header.set_cksum();
+        append_file_to_archive(&mut archive, "osc52-clipboard", OSC52_CLIPBOARD.as_bytes(), 0o755)?;
-        archive.append_data(&mut header, "Dockerfile", dockerfile_bytes)?;
+        append_file_to_archive(&mut archive, "audio-shim", AUDIO_SHIM.as_bytes(), 0o755)?;
+        append_file_to_archive(&mut archive, "triple-c-sso-refresh", SSO_REFRESH.as_bytes(), 0o755)?;
 
-        let entrypoint_bytes = ENTRYPOINT.as_bytes();
+        append_embedded_dir(&mut archive, &MISSION_CONTROL_DIR, "mission-control")?;
-        let mut header = tar::Header::new_gnu();
-        header.set_size(entrypoint_bytes.len() as u64);
-        header.set_mode(0o755);
-        header.set_cksum();
-        archive.append_data(&mut header, "entrypoint.sh", entrypoint_bytes)?;
-
-        let scheduler_bytes = SCHEDULER.as_bytes();
-        let mut header = tar::Header::new_gnu();
-        header.set_size(scheduler_bytes.len() as u64);
-        header.set_mode(0o755);
-        header.set_cksum();
-        archive.append_data(&mut header, "triple-c-scheduler", scheduler_bytes)?;
-
-        let task_runner_bytes = TASK_RUNNER.as_bytes();
-        let mut header = tar::Header::new_gnu();
-        header.set_size(task_runner_bytes.len() as u64);
-        header.set_mode(0o755);
-        header.set_cksum();
-        archive.append_data(&mut header, "triple-c-task-runner", task_runner_bytes)?;
 
         archive.finish()?;
     }

container/Dockerfile

@@ -122,6 +122,8 @@ RUN chmod +x /usr/local/bin/audio-shim \
 COPY triple-c-sso-refresh /usr/local/bin/triple-c-sso-refresh
 RUN chmod +x /usr/local/bin/triple-c-sso-refresh
 
+COPY mission-control /opt/mission-control
+
 COPY entrypoint.sh /usr/local/bin/entrypoint.sh
 RUN chmod +x /usr/local/bin/entrypoint.sh
 COPY triple-c-scheduler /usr/local/bin/triple-c-scheduler

container/entrypoint.sh

@@ -145,13 +145,12 @@ fi
 if [ "$MISSION_CONTROL_ENABLED" = "1" ]; then
     MC_HOME="/home/claude/mission-control"
     MC_LINK="/workspace/mission-control"
-    if [ ! -d "$MC_HOME/.git" ]; then
+    if [ ! -d "$MC_HOME" ]; then
-        echo "entrypoint: cloning mission-control..."
+        echo "entrypoint: installing mission-control..."
-        su -s /bin/bash claude -c \
+        cp -r /opt/mission-control "$MC_HOME"
-            'git clone https://github.com/msieurthenardier/mission-control.git /home/claude/mission-control' \
+        chown -R claude:claude "$MC_HOME"
-            || echo "entrypoint: warning — failed to clone mission-control"
     else
-        echo "entrypoint: mission-control already present, skipping clone"
+        echo "entrypoint: mission-control already present, skipping install"
     fi
     # Symlink into workspace so Claude sees it at /workspace/mission-control
     ln -sfn "$MC_HOME" "$MC_LINK"

container/mission-control/.claude/skills/agentic-workflow/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: agentic-workflow
+description: Active orchestrator for multi-agent flight execution. Drives the full leg cycle (design, implement, review, commit) using three separate Claude instances.
+---
+
+# Agentic Workflow
+
+Orchestrate multi-agent flight execution. You drive the full leg cycle — designing legs, spawning Developer and Reviewer agents, and managing git workflow — for a target project's flight.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+- A mission must exist and be `active`
+- A flight must exist and be `ready` or `in-flight`
+
+## Invocation
+
+```
+/agentic-workflow flight {number} for {project-slug} mission {number}
+```
+
+Example: `/agentic-workflow flight 03 for epipen mission 04`
+
+## Phase 1: Context Loading
+
+1. **Read `projects.md`** to find the target project's path
+2. **Read `{target-project}/.flightops/ARTIFACTS.md`** for artifact locations
+3. **Read `{target-project}/.flightops/agent-crews/leg-execution.md`** for project crew definitions, interaction protocol, and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/leg-execution.md`)
+   - **Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections. Each prompt subsection MUST have a fenced code block.
+   - **If the file exists but is malformed**: STOP. Tell the user: "Phase file `leg-execution.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults." Do NOT improvise missing prompts — halt and get the file fixed.
+4. **Read the mission artifact** — outcomes, success criteria, constraints
+5. **Read the flight artifact** — objective, design decisions, leg list
+6. **Read the flight log** — ground truth from prior execution
+7. **Count total legs** from the flight spec — track progress throughout
+8. **Determine starting point** — which leg is next based on flight log and leg statuses
+9. **Read git strategy** from `{target-project}/.flightops/ARTIFACTS.md` `## Git Workflow` section. Default to `branch` if the section is absent.
+10. **Set `{working-directory}`** — `branch`: the target project root; `worktree`: the worktree path (see Git Workflow section below)
+
+**Mark flight as in-flight**: After loading the flight artifact, if the flight status is `ready`, update it to `in-flight` before proceeding. If already `in-flight`, leave it as-is.
+
+If resuming a flight already in progress, verify state consistency:
+- Flight log entries must match leg statuses
+- If discrepancies exist, remediate before proceeding
+
+## Phase 2: Leg Cycle
+
+Repeat for each leg in the flight.
+
+### 2a: Leg Design
+
+1. **Design the leg** using the `/leg` skill (if the Skill tool is unavailable, read `.claude/skills/leg/SKILL.md` and follow the workflow directly)
+   - Read the flight spec, flight log, and relevant source code
+   - Create the leg artifact with acceptance criteria
+2. **Spawn a Developer agent for design review** (Task tool, `subagent_type: "general-purpose"`)
+   - Working directory: `{working-directory}`
+   - Provide the "Review Leg Design" prompt from the leg-execution phase file's Prompts section
+   - The Developer reads the leg artifact and cross-references against actual codebase state
+   - The Developer provides a structured assessment: approve, approve with changes, or needs rework
+3. **Incorporate feedback** — update the leg artifact to address any issues raised
+   - High-severity issues: must fix before proceeding
+   - Medium-severity issues: fix unless there's a clear reason not to
+   - Low-severity issues and suggestions: apply at discretion
+4. **Re-review if substantive changes were made** — spawn another Developer for a second pass
+   - Skip if only minor/cosmetic fixes were applied
+   - If the second review raises new high-severity issues, fix and re-review once more
+   - **Max 2 design review cycles** — if issues persist after 2 rounds, escalate to human
+5. **Update leg status** to `ready`
+6. **Signal `[HANDOFF:review-needed]`** when the leg design is finalized
+
+### 2b: Leg Implementation
+
+**NEVER implement code directly.** Spawn a Developer agent via the Task tool.
+
+**Interactive/UAT legs**: If the leg is a UAT, alignment, or other interactive leg (identified by slug like `uat-*`, `alignment-*`, or explicit marking in the flight spec), do NOT spawn agents to execute it autonomously. The human performs verification — the Flight Director guides them through it:
+1. **Design the leg** normally (2a), but keep it lightweight — the acceptance criteria are verification steps, not implementation tasks
+2. **Skip the autonomous implementation cycle** (no Developer/Reviewer agents)
+3. **Guide the human through verification steps one at a time** — present a single step, wait for the human to perform it and report results, then proceed to the next step
+4. **Fix issues inline** — if the human reports a failure, diagnose and fix it (spawning a Developer agent if code changes are needed), then re-verify that step before moving on
+5. **Commit when all steps pass** — spawn a Developer agent to update artifacts and commit
+
+**Standard (autonomous) legs**: Follow the Developer/Reviewer cycle below.
+
+1. **Spawn a Developer agent** (Task tool, `subagent_type: "general-purpose"`)
+   - Working directory: `{working-directory}`
+   - Provide the "Implement" prompt from the leg-execution phase file's Prompts section
+   - The Developer updates leg status to `in-flight`, implements to acceptance criteria
+   - When done, the Developer updates leg status to `landed`, updates flight log, and signals `[HANDOFF:review-needed]` — do NOT let it commit
+2. **Spawn a Reviewer agent** (Task tool, `subagent_type: "general-purpose"`)
+   - Working directory: `{working-directory}`
+   - Provide the "Review" prompt from the leg-execution phase file's Prompts section
+   - The Reviewer evaluates ALL uncommitted changes against acceptance criteria and code quality
+   - The Reviewer signals `[HANDOFF:confirmed]` or lists issues with severity
+3. **If issues found**, spawn a new Developer agent to fix them
+   - Provide the "Fix Review Issues" prompt from the leg-execution phase file with the Reviewer's feedback
+   - Loop review/fix until the Reviewer confirms
+4. **Spawn the Developer agent to commit** after review passes
+   - Provide the "Commit" prompt from the leg-execution phase file's Prompts section
+   - The commit must include code changes, updated flight log, and leg status updated to `completed`
+
+### 2c: Leg Transition
+
+After `[COMPLETE:leg]` (all git/PR operations run from `{working-directory}`):
+1. Increment `legs_completed`
+2. **Manage PR**:
+   - **First leg**: Open a draft PR with the leg checklist in the body (see PR Body Format below), then check off the completed leg
+   - **Subsequent legs**: Use `gh pr edit --body` to check off the newly completed leg in the existing PR body
+3. If more legs remain → return to 2a
+4. If all legs complete → proceed to Phase 3
+
+## Phase 3: Flight Completion
+
+1. **Verify all legs** show `completed` status
+2. **Verify flight log** has entries for all legs
+3. **Verify documentation** — check that CLAUDE.md, README, and other project docs reflect any new commands, endpoints, configuration, or APIs introduced during the flight. If not, spawn a Developer agent to update them.
+4. **Update flight status** to `landed`
+5. **Check off flight** in mission artifact
+6. **Clean up worktree** (worktree strategy only) — run `git worktree remove` after the PR is marked ready for review
+7. **Signal `[COMPLETE:flight]`**
+
+The flight debrief is a separate step run via `/flight-debrief` after the flight lands. The debrief transitions the flight to `completed`.
+
+## Architecture
+
+The Flight Director (you) orchestrates according to this skill. Project crew composition, roles, models, and prompts are defined in `{target-project}/.flightops/agent-crews/leg-execution.md`.
+
+**Separation is mandatory.** Project crew agents run in the target project and load its CLAUDE.md and conventions. The Reviewer has no knowledge of the Developer's reasoning — only the resulting changes. This provides objective review.
+
+**Model selection:** Follow the model preferences in the phase file. MC may use Opus for complex planning. Never use Opus for the Reviewer.
+
+## Handoff Signals
+
+Signals are part of the Flight Control methodology and are NOT configurable per-project. All crew agents must use these exact signals:
+
+| Signal | Emitted By | Meaning |
+|--------|-----------|---------|
+| `[HANDOFF:review-needed]` | Developer | Code/artifact ready for review |
+| `[HANDOFF:confirmed]` | Reviewer | Review passed |
+| `[BLOCKED:reason]` | Any crew agent | Cannot proceed, needs resolution |
+| `[COMPLETE:leg]` | Developer | Leg finished and committed |
+| `[COMPLETE:flight]` | Flight Director | Flight landed |
+
+## Flight Director Decision Log
+
+The Flight Director must maintain transparency about its own decisions. After each major orchestration step, log what happened and why in the flight log under a `### Flight Director Notes` subsection:
+
+1. **Phase file loading** — Record which phase file was loaded (project or default fallback) and what crew was extracted
+2. **Agent spawning** — Record which agent was spawned, with what prompt, and what model
+3. **Review cycle decisions** — When incorporating feedback, note what was accepted/rejected and why
+4. **Escalation decisions** — When choosing between "fix and re-review" vs "escalate to human," note the reasoning
+5. **Signal interpretation** — When a crew agent's output is ambiguous, note how it was interpreted
+
+This is not a separate file — it goes in the flight log alongside leg entries. The goal is that anyone reviewing the flight log can understand not just what the crew did, but why the Flight Director made the orchestration choices it did.
+
+## Git Workflow
+
+### Strategy Selection
+
+Read the `## Git Workflow` section from `{target-project}/.flightops/ARTIFACTS.md`. The `Strategy` property determines which workflow to use. If the section is absent, default to `branch`.
+
+### Shared Elements
+
+Both strategies use the same branch naming, commit format, PR lifecycle, and PR body format.
+
+**Branch naming**: `flight/{number}-{slug}`
+
+**Commit message format:**
+```
+leg/{number}: {description}
+
+Flight: {flight-number}
+Mission: {mission-number}
+```
+
+**PR lifecycle:**
+
+| Event | Action |
+|-------|--------|
+| First leg complete | Open draft PR with leg checklist in body |
+| Each leg complete | Commit code + artifacts, update PR checklist |
+| Flight landed | Mark PR ready for review |
+
+**PR body format:**
+
+```markdown
+## {Flight Title}
+
+{Flight objective — one paragraph}
+
+**Mission**: {Mission Title}
+
+## Legs
+
+- [ ] `{leg-slug}` — {brief description}
+- [ ] `{leg-slug}` — {brief description}
+```
+
+### Strategy: Branch
+
+The default single-checkout workflow. One flight at a time per working copy.
+
+| Step | Command |
+|------|---------|
+| Flight start | `git checkout -b flight/{number}-{slug}` |
+| Set `{working-directory}` | Target project root |
+| Agents work in | Project root |
+| Flight landed | PR marked ready for review |
+
+### Strategy: Worktree
+
+Worktree isolation enables parallel flights on a single repo clone.
+
+| Step | Command |
+|------|---------|
+| Flight start | `git worktree add .worktrees/flight-{number}-{slug} -b flight/{number}-{slug}` |
+| Set `{working-directory}` | `.worktrees/flight-{number}-{slug}` |
+| Orchestrator stays on | Main branch (does not checkout the flight branch) |
+| Agents work in | Worktree path |
+| Flight landed | PR marked ready for review, then `git worktree remove .worktrees/flight-{number}-{slug}` |
+
+**Note:** The `.worktrees/` directory must be in `.gitignore` when using this strategy.
+
+## Error Handling
+
+| Situation | Action |
+|-----------|--------|
+| Developer agent fails mid-leg | Spawn new Developer with context of what failed |
+| Design review loops > 2 times | Escalate to human with unresolved design issues |
+| Code review loops > 3 times | Escalate to human |
+| Leg marked aborted | Escalate to human with abort details |
+| Artifact discrepancy | Remediate before proceeding |
+| Off the rails | Roll back to last leg commit, escalate |
+| Stale worktree (worktree strategy) | Run `git worktree prune`, recreate if needed |
+| Agent hangs on tests | Kill the agent, spawn new Developer to isolate and fix hanging tests |

container/mission-control/.claude/skills/daily-briefing/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: daily-briefing
+description: Cross-project status report with health assessment, stale work detection, and methodology insights. Use for a quick overview of all managed projects.
+---
+
+# Daily Briefing
+
+Generate a comprehensive status report across managed projects with health assessments, staleness detection, and cross-project methodology insights.
+
+## Prerequisites
+
+- `projects.md` must exist (run `/init-mission-control` first)
+
+## Output
+
+Daily briefings are saved to the `daily-briefings/` directory in the mission-control repository root, named by date: `daily-briefings/YYYY-MM-DD.md`. This directory is gitignored — briefings are local-only, ephemeral documents.
+
+If a briefing already exists for today, append a sequence number: `YYYY-MM-DD-2.md`, `YYYY-MM-DD-3.md`, etc.
+
+## Workflow
+
+### Phase 1: Load Projects Registry
+
+1. **Read `projects.md`** to get the full list of managed projects
+2. Extract each project's slug, description, path, and status
+
+### Phase 2: Project Selection Interview
+
+Present the user with a **checkbox list** (AskUserQuestion with `multiSelect: true`) of all registered projects so they can select which ones to include in the briefing.
+
+**AskUserQuestion limits each question to 4 options.** Split projects across multiple questions in groups of 3, reserving the 4th option as "None from this group" (description: "Skip these projects") so the user can opt out of an entire group without blocking submission. Send all questions in a single AskUserQuestion call.
+
+Format each project option as:
+- **Label**: Project slug
+- **Description**: Short project description from the registry
+
+### Phase 3: Project Scanning
+
+For each selected project, gather data by spawning **parallel Explore agents** (Task tool, `subagent_type: "Explore"`) — one per project. Each agent should:
+
+1. **Check initialization status**
+   - Check if `{project-path}/.flightops/ARTIFACTS.md` exists
+   - If missing, note the project as "not initialized" and skip artifact scanning
+
+2. **Read artifact configuration**
+   - Read `{project-path}/.flightops/ARTIFACTS.md` for directory structure and naming conventions
+
+3. **Discover all artifacts**
+   - For filesystem-based projects, scan `{project-path}/missions/` for mission directories
+   - For each mission, scan for flights; for each flight, scan for legs
+   - Read all discovered artifacts and capture:
+     - **Status fields** from each mission, flight, and leg
+     - **Titles and objectives**
+     - **Checklist completion** (count checked vs unchecked items)
+
+4. **Read debriefs**
+   - Read any flight debriefs and mission debriefs found
+   - Extract key learnings, recommendations, and action items
+
+5. **Check git activity**
+   - Run `git log --oneline --since="7 days ago" -20` in the project directory
+   - Capture recent commit activity as a proxy for momentum
+
+6. **Return structured findings**
+   The agent should return a structured summary including:
+   - Project initialization status
+   - List of all missions with status
+   - List of all flights with status
+   - List of all legs with status
+   - Debrief summaries (key learnings and recommendations)
+   - Recent git activity summary
+   - Any anomalies (e.g., in-flight legs with no recent commits)
+
+### Phase 4: Health Analysis
+
+For each scanned project, assess health across these dimensions:
+
+#### Activity Status
+- **Active**: Has in-flight work AND recent commits
+- **Stalled**: Has in-flight work but NO recent commits (7+ days)
+- **Idle**: No in-flight work
+- **Fresh**: Recently completed work (within 7 days)
+
+#### Staleness Detection
+Flag artifacts that appear stale or abandoned:
+- **Missions** with status `active` or `planning` but no flight activity in 14+ days
+- **Flights** with status `in-flight` or `planning` but no leg progress in 7+ days
+- **Legs** with status `in-flight` or `planning` but no recent commits in 7+ days
+- **Open questions** that remain unresolved across any active artifacts
+
+#### Completion Assessment
+- Missions nearing completion (most success criteria checked)
+- Flights with all legs completed but not yet marked `landed`
+- Orphaned artifacts (legs without flights, flights without missions)
+
+### Phase 5: Cross-Project Insights
+
+Analyze all debriefs (flight and mission) across selected projects to extract:
+
+#### Common Patterns
+- Recurring recommendations across projects
+- Shared technical or process challenges
+- Patterns in what goes well vs what struggles
+
+#### Mission Control Methodology Improvements
+- Feedback about the mission/flight/leg hierarchy itself
+- Skill effectiveness observations (were leg specs clear enough? were flight plans accurate?)
+- Suggestions for new skills, templates, or workflow changes
+
+#### Project-Specific Recommendations
+- Per-project action items drawn from debrief insights
+- Suggested next steps based on current state
+
+### Phase 6: Generate Briefing
+
+Create the daily briefing file at `daily-briefings/YYYY-MM-DD.md`. Ensure the `daily-briefings/` directory exists first.
+
+**Format:**
+
+```markdown
+# Daily Briefing — {YYYY-MM-DD}
+
+## Executive Summary
+{2-3 sentence overview of portfolio health — how many projects active, key highlights, top concerns}
+
+---
+
+## Project Reports
+
+### {Project Slug}
+
+**Health**: {Active | Stalled | Idle | Fresh} {optional: brief qualifier}
+**Recent Activity**: {X commits in last 7 days | No recent commits}
+
+#### Current State
+| Level | Active | Completed | Stale | Total |
+|-------|--------|-----------|-------|-------|
+| Missions | {n} | {n} | {n} | {n} |
+| Flights | {n} | {n} | {n} | {n} |
+| Legs | {n} | {n} | {n} | {n} |
+
+#### In Progress
+- **Mission**: {title} — {status summary}
+  - **Flight**: {title} — {status}, {X/Y legs complete}
+    - {Current/next leg and its status}
+
+#### Staleness Alerts
+- {Description of stale artifact and how long it's been inactive}
+
+#### Recommendations
+- {Actionable recommendation based on current state and debrief insights}
+
+---
+
+{Repeat for each selected project}
+
+---
+
+## Not Initialized
+{List any selected projects that lack `.flightops/` — suggest running `/init-project`}
+
+---
+
+## Cross-Project Insights
+
+### Common Patterns
+{Themes observed across multiple project debriefs}
+
+### Methodology Observations
+{Feedback about Flight Control itself — what's working, what could improve}
+
+### Recommended Actions
+1. {Highest-priority cross-project action}
+2. {Second priority}
+3. {Third priority}
+```
+
+### Phase 7: Present Summary
+
+After writing the briefing file, present a **concise verbal summary** to the user:
+
+1. The file path where the full briefing was saved
+2. Portfolio-level health (X active, Y stalled, Z idle)
+3. Top 3 items needing attention (stale work, approaching completions, blockers)
+4. Any cross-project methodology insights worth highlighting
+
+Keep the verbal summary short — the detailed report is in the file.
+
+## Guidelines
+
+### Read-Only
+This skill only reads project artifacts and git history. It **never** modifies any project files, artifacts, or source code.
+
+### Parallel Scanning
+Spawn project scanning agents in parallel for efficiency. Don't scan projects sequentially.
+
+### Graceful Degradation
+- Projects without `.flightops/` get noted but don't block the report
+- Projects with no missions directory get reported as "no Flight Control artifacts"
+- Missing or malformed artifacts get flagged, not crashed on
+
+### Honest Assessment
+Report what you find. Don't sugarcoat stale projects or inflate activity. The briefing is for situational awareness — accuracy matters more than optimism.
+
+### Brevity in Verbal Summary
+The written briefing is the detailed artifact. The verbal summary should be 5-10 lines max — just the highlights and the file path.

container/mission-control/.claude/skills/flight-debrief/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: flight-debrief
+description: Post-flight analysis for continuous improvement. Use after a flight is completed to capture lessons learned and improve the methodology.
+---
+
+# Flight Debrief
+
+Perform comprehensive post-flight analysis for continuous improvement.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+- A flight must have status `landed` before debriefing
+
+## Workflow
+
+### Phase 1: Context Loading
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Load flight documentation**
+   - Read the mission for overall context and success criteria
+   - Read the flight for objectives, design decisions, and checkpoints
+   - Read ALL legs to understand the planned implementation
+   - Read the complete flight log for ground truth on what happened
+
+5. **Load project context**
+   - Read the target project's `README.md` and `CLAUDE.md`
+   - Identify key implementation files from leg outputs and flight log
+
+6. **Examine actual implementation**
+   - Read files created or modified during the flight
+   - Compare intended vs actual implementation
+   - Note deviations, workarounds, or unexpected discoveries
+
+### Phase 2: Crew Debrief Interviews
+
+Read `{target-project}/.flightops/agent-crews/flight-debrief.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/flight-debrief.md`).
+
+**Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Phase file `flight-debrief.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
+
+#### Developer Interview
+1. **Spawn a Developer agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
+   - Provide the "Debrief Interview" prompt from the flight-debrief phase file's Prompts section
+   - The Developer examines code changes, test coverage, patterns, and technical debt
+   - The Developer provides structured debrief input
+
+#### Architect Interview
+1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
+   - Provide the "Debrief Design Review" prompt from the flight-debrief phase file's Prompts section
+   - The Architect compares planned design decisions against actual implementation
+   - The Architect evaluates whether the flight design held up and provides feedback for future flights
+   - This closes the design feedback loop — the same role that reviewed the spec now evaluates the outcome
+
+#### Human Interview
+Brief questions to capture insights documents may miss. Keep this lightweight — 2-3 questions max based on what you observed in the flight log.
+
+- **On anomalies/deviations**: "The log mentions [X] — what drove that decision?"
+- **On leg quality**: "Were any leg specs unclear or missing key context?"
+- **On blockers**: "What slowed you down most? Was it predictable?"
+
+Skip the human interview if the flight log is comprehensive and there are no obvious gaps.
+
+### Phase 3: Deep Analysis
+
+Synthesize Developer input, Architect input, human input, and document analysis across multiple dimensions:
+
+#### Outcome Analysis
+- Did the flight achieve its objective?
+- Which mission success criteria did this flight advance?
+- Were all checkpoints met?
+- What value was delivered?
+
+#### Process Analysis
+- How accurate were the leg specifications?
+- Were there gaps requiring improvisation?
+- Did the leg sequence make sense?
+- Were legs appropriately sized?
+- Did acceptance criteria prove verifiable?
+
+#### Technical Analysis
+- What technical decisions were made during flight that weren't planned?
+- Were there architectural surprises?
+- What technical debt was introduced?
+- Does implementation align with project conventions?
+
+#### Deviation Analysis
+- What deviations occurred and why?
+- Were deviations captured in the flight log?
+- Should any deviations become standard practice?
+
+#### Knowledge Capture
+- What was learned that should be documented?
+- Are there reusable patterns that emerged?
+- Are README or CLAUDE.md updates needed?
+
+### Phase 4: Skill Effectiveness Analysis
+
+Evaluate whether the mission-control skills could be improved:
+
+#### Mission Skill
+- Did the mission provide adequate context?
+- Were success criteria clear and measurable?
+
+#### Flight Skill
+- Did the flight structure support execution?
+- Were design decisions adequately captured?
+- Was the leg breakdown appropriate?
+
+#### Leg Skill
+- Did legs provide sufficient implementation guidance?
+- Were acceptance criteria verifiable?
+- Were edge cases adequately identified?
+
+### Phase 5: Generate Debrief
+
+Create the flight debrief artifact using the format defined in `.flightops/ARTIFACTS.md`.
+
+### Phase 6: Flight Status Transition
+
+Ask the user if the flight should be marked as `completed`. If confirmed, update the flight artifact's status from `landed` to `completed`.
+
+## Guidelines
+
+### Thoroughness Over Speed
+- Read files completely, not just skim
+- Consider root causes, not just symptoms
+- Think about systemic improvements
+
+### Be Specific and Actionable
+Avoid vague recommendations. Instead of "improve documentation," say:
+- "Add a 'Devcontainer Commands' section to CLAUDE.md documenting the docker exec workflow"
+
+### Distinguish Severity
+- **Critical**: Would have prevented significant rework or failure
+- **Important**: Would have meaningfully improved efficiency
+- **Minor**: Nice-to-have improvements
+
+### Credit What Worked
+Identify effective patterns that should be reinforced or codified.
+
+### Consider the Meta-Level
+- Did the mission/flight/leg hierarchy work?
+- Were the right artifacts being created?
+- Is there friction that could be eliminated?
+
+## Output
+
+Create the debrief artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
+
+After creating the debrief, summarize the top 3-5 most impactful recommendations.

container/mission-control/.claude/skills/flight/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: flight
+description: Create technical flight specifications from missions. Use when breaking down a mission into implementable work or planning technical approach.
+---
+
+# Flight Specification
+
+Create a technical flight spec from a mission.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+- A mission must exist before creating a flight
+
+## Workflow
+
+### Phase 1: Context Gathering
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Read the parent mission**
+   - Understand the outcome being pursued
+   - Identify which success criteria this flight addresses
+   - Note constraints that apply
+
+5. **Check existing flights**
+   - What flights already exist for this mission?
+   - What's been completed vs. in progress?
+   - Are there dependencies on other flights?
+
+### Phase 2: Code Interrogation
+
+Explore the target project's codebase to inform the technical approach:
+
+1. **Identify relevant code areas**
+   - What existing code relates to this flight?
+   - What patterns are already established?
+   - What dependencies exist?
+
+2. **Find files likely to be affected**
+   - Source files to modify
+   - Test files to create/update
+   - Configuration changes needed
+
+3. **Understand existing patterns**
+   - Code style and conventions
+   - Error handling approaches
+   - Testing patterns
+
+4. **Check for schema/migration implications**
+   - Does this flight add or modify database tables?
+   - What migration tooling does the project use?
+   - Are there existing migration patterns to follow?
+
+### Phase 3: User Input
+
+Before asking structured technical questions, share a brief summary of what you learned during context gathering and code interrogation, then prompt the user for open-ended input:
+
+- "Here's what I've gathered about the mission context and codebase: [summary]. Before I ask specific technical questions, what are your thoughts on what this flight should cover? Feel free to share approach preferences, priorities, concerns — anything that should shape this flight."
+
+Use the user's response to inform and focus the crew interview questions that follow.
+
+### Phase 4: Crew Interview
+
+Ask technical questions to resolve the approach:
+
+1. **Technical approach**
+   - "Should we extend existing code or create new modules?"
+   - "What's the preferred pattern for [specific decision]?"
+   - "Are there performance considerations?"
+
+2. **Open questions**
+   - Surface ambiguities in requirements
+   - Clarify edge cases
+   - Identify unknowns
+
+3. **Design decisions**
+   - Document choices and rationale
+   - Get agreement on trade-offs
+   - Note constraints discovered
+
+4. **Prerequisites verification**
+   - "Is [dependency] ready?"
+   - "Do we have access to [resource]?"
+
+5. **Validation approach**
+   - "How will this flight be validated?"
+   - "Is test automation needed, or is manual verification sufficient?"
+   - "What tests should be created or updated?"
+
+### Phase 5: Spec Creation
+
+Create the flight artifact using the format defined in `.flightops/ARTIFACTS.md`.
+
+Also create the flight log artifact (empty, ready for execution notes).
+
+### Phase 5b: Design Review
+
+Spawn an Architect agent to validate the flight spec against the real codebase before presenting it to the crew.
+
+Read `{target-project}/.flightops/agent-crews/flight-design.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/flight-design.md`).
+
+**Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Phase file `flight-design.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
+
+1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
+   - Provide the "Review Flight Design" prompt from the flight-design phase file's Prompts section
+   - The Architect reads the flight spec and cross-references design decisions, prerequisites, technical approach, and leg breakdown against actual codebase state and architecture best practices
+   - The Architect provides a structured assessment: approve, approve with changes, or needs rework
+2. **Incorporate feedback** — update the flight artifact to address issues raised
+   - High-severity issues: must fix before proceeding
+   - Medium-severity issues: fix unless there's a clear reason not to
+   - Low-severity issues and suggestions: apply at discretion
+3. **Re-review if substantive changes were made** — spawn another Architect for a second pass
+   - Skip if only minor/cosmetic fixes were applied
+   - **Max 2 design review cycles** — if issues persist after 2 rounds, escalate to human
+4. **Proceed to Phase 6** with a codebase-validated spec
+
+### Phase 6: Iterate
+
+1. Walk through the spec with the crew
+2. Validate technical approach is sound
+3. Confirm leg breakdown is appropriate
+4. Refine until approved
+
+## Guidelines
+
+### Flight Sizing
+
+A well-sized flight:
+- Takes 1-3 days of focused work
+- Breaks into 3-8 legs typically
+- Has a clear, verifiable objective
+- Addresses specific mission criteria
+
+**Too small**: Single leg's worth of work
+**Too large**: More than a week of work, vague checkpoints
+
+### Leg Identification
+
+Break flights into legs based on technical boundaries:
+- Each leg should be atomic (independently completable)
+- Legs should have clear inputs and outputs
+- Consider dependencies between legs
+- Group related changes together
+
+**For scaffolding flights**: Include a final `verify-integration` leg
+
+**For interface changes**: Identify consumers that need updates
+
+**For documentation**: Consider whether README, CLAUDE.md, or other docs need updates as part of this flight — especially for flights adding new CLI commands, API endpoints, or configuration options
+
+**For schema changes**: Include explicit migration legs and verify against the live database, not just mocks
+
+**For UAT and alignment**: During the crew interview, ask the user whether they'd like to include a UAT and alignment leg. Explain that this optional leg is a guided UAT session — the agent walks the user through a series of tests and verification steps, fixing issues along the way until the user is satisfied with the results. If the user opts in, include it in the breakdown, marked as optional.
+
+### Pre-Flight Rigor
+
+- Open questions MUST be resolved before execution
+- Design decisions MUST be documented with rationale
+- Prerequisites MUST be verified, not assumed
+- **Environment conflicts**: Flights introducing network services (ports, databases, containers) must check for conflicts with existing services on the developer's machine during planning. Ask: "What else is running that could conflict?"
+
+### Adaptive Planning
+
+- Flights can be modified during `planning` state
+- Once `in-flight`, flights may still be modified (e.g., changing planned legs) as long as the flight log captures the change and rationale
+- New legs can be added if scope grows
+
+## Output
+
+Create the following artifacts using locations and formats from `.flightops/ARTIFACTS.md`:
+
+1. **Flight spec** — The flight plan
+2. **Flight log** — Empty, ready for execution notes

container/mission-control/.claude/skills/init-mission-control/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: init-mission-control
+description: Onboard to Mission Control by setting up the projects registry. Use when projects.md is missing or when adding new projects.
+---
+
+# Mission Control Onboarding
+
+Set up the projects registry (`projects.md`) and orient the user to the Flight Control workflow.
+
+## When to Use
+
+Run `/init-mission-control` when:
+- `projects.md` doesn't exist (first time using Mission Control)
+- Adding a new project to the registry
+- Updating an existing project's details
+
+## Workflow
+
+### 1. Check Registry Status
+
+Check if `projects.md` exists in the mission-control repository root.
+
+**If missing:**
+> "No projects registry found. Let's set one up — this tells Mission Control where your projects live."
+
+**If exists:**
+> "Projects registry found. Want to add a new project or update an existing one?"
+
+### 2. Create or Update Registry
+
+**If creating new:**
+1. Copy `projects.md.template` to `projects.md`
+2. Remove the example entries
+3. Interview the user to register their first project (see step 3)
+
+**If updating:**
+1. Read existing `projects.md`
+2. Ask: add new project, or update existing?
+3. Proceed accordingly
+
+### 3. Discover Projects
+
+Ask the user how they want to add projects:
+
+> "Want to scan a directory for projects, or add a single project?"
+
+**Option A: Scan a directory**
+1. Ask for the parent directory path (e.g., `~/projects`)
+2. Scan immediate subdirectories for git repos
+3. Present the list and ask which ones to register
+4. Auto-detect details for each selected project
+5. Ask for descriptions in batch (or let the user provide them later)
+
+**Option B: Add a single project**
+1. Ask for the project path (e.g., `~/projects/my-app`)
+2. Verify it exists and is a git repo
+3. Auto-detect details
+4. Ask only for what can't be detected: description, and optionally stack/status
+
+**Auto-detection:** For each project directory, run:
+- **Slug**: directory name
+- **Remote**: `git -C <path> remote get-url origin`
+
+Only ask the user for fields that can't be auto-detected.
+
+### 4. Orientation
+
+After the registry is set up, briefly orient the user:
+
+> "You're all set. Here's the workflow:"
+> 1. **`/init-project`** — Run this in each project to set up `.flightops/` with methodology references and configure the project crew
+> 2. **`/mission`** — Define what you want to achieve (outcomes, not tasks)
+> 3. **`/flight`** — Break a mission into technical specs
+> 4. **`/leg`** — Generate implementation steps for each flight leg
+> 5. **`/agentic-workflow`** — Execute legs with automated Developer + Reviewer agents
+
+> "Start with `/init-project` on the project you just registered."
+
+### 5. Offer Next Step
+
+> "Want to run `/init-project` for {project-slug} now?"
+
+If yes, invoke the `/init-project` skill for the registered project.
+
+## Guidelines
+
+### Keep It Quick
+
+This is onboarding, not the main work. Get the registry set up and move on.
+
+### Don't Over-Explain
+
+The user will learn the methodology by using it. Give the orientation but don't lecture.
+
+### Validate Paths
+
+When the user provides a filesystem path, verify it exists before adding to the registry.

container/mission-control/.claude/skills/init-project/FLIGHT_OPERATIONS.md

@@ -0,0 +1,182 @@
+# Flight Operations Quick Reference
+
+> For full methodology docs, see [mission-control](https://github.com/msieurthenardier/mission-control)
+
+## Before You Start
+
+**Read these files in order:**
+1. `.flightops/ARTIFACTS.md` — Where and how artifacts are stored (project-specific)
+2. The **flight log** for your active flight — Ground truth for what happened
+3. The **leg artifact** you're implementing — Your acceptance criteria
+
+---
+
+## Project Crew & Phases
+
+Each phase of the Flight Control workflow has a crew definition in `.flightops/agent-crews/`:
+
+| Crew | Purpose |
+|------|---------|
+| `mission-design.md` | Crew for `/mission` (e.g., Architect validates viability) |
+| `flight-design.md` | Crew for `/flight` (e.g., Architect reviews spec) |
+| `leg-execution.md` | Crew for `/agentic-workflow` (e.g., Developer + Reviewer) |
+| `flight-debrief.md` | Crew for `/flight-debrief` (e.g., Developer provides perspective) |
+| `mission-debrief.md` | Crew for `/mission-debrief` (e.g., Architect provides perspective) |
+
+Crew files define: roles, models, interaction protocols, prompts, and signals. Customize these to change your project's agent configuration.
+
+---
+
+## Multi-Agent Workflow
+
+Legs must be implemented by a **separate Developer instance** and reviewed by a **separate Reviewer instance** (or whatever crew is defined in `leg-execution.md`). Mission Control designs legs and orchestrates — it does NOT implement code directly.
+
+The Reviewer has no knowledge of the Developer's reasoning — only the resulting changes. This separation provides objective code review. Use the `/agentic-workflow` skill in mission-control to drive this cycle.
+
+---
+
+## ⚠️ Leg Completion Checklist (MANDATORY)
+
+**You MUST complete ALL of these before emitting `[COMPLETE:leg]`:**
+
+| Step | Action |
+|------|--------|
+| 1 | All acceptance criteria verified |
+| 2 | Tests passing |
+| 3 | **Update flight log** — Add leg progress entry (see below) |
+| 4 | **Mark leg completed** — Update leg status to `completed` |
+| 5 | **Update flight** — Check off the leg in flight artifact |
+| 6 | **Commit/save with all artifact updates** |
+
+**Flight log entry MUST include:**
+- Leg status, started date, completed date
+- Changes Made (what was implemented)
+- Verification (how acceptance criteria were confirmed)
+- Any decisions, deviations, or anomalies
+
+Refer to `.flightops/ARTIFACTS.md` for exact locations and formats.
+
+---
+
+## Workflow Signals
+
+Emit at the end of your response, on its own line:
+
+| Signal | When |
+|--------|------|
+| `[HANDOFF:review-needed]` | Artifact changes ready for validation |
+| `[HANDOFF:confirmed]` | Review complete, no issues |
+| `[BLOCKED:reason]` | Cannot proceed |
+| `[COMPLETE:leg]` | Leg done AND checklist complete |
+
+---
+
+## Implementing a Leg
+
+### Pre-Implementation
+1. Read mission, flight, and leg artifacts
+2. Read flight log for context from prior legs
+3. Verify leg accuracy against existing code
+4. **Update leg status** to `in-flight`
+5. Present summary and get approval before proceeding
+
+### Implementation
+5. Implement to acceptance criteria
+6. Run tests with a timeout — use the test runner's timeout flag (e.g., `--timeout`,
+   `--test-timeout`, `-timeout`) so hanging tests fail fast instead of stalling.
+   If a test hangs, kill it, isolate the hanging test, and fix the root cause before
+   continuing. Log hanging tests and their resolution in the flight log.
+7. Run code review, fix Critical/Major issues
+8. Re-review until clean
+
+### Post-Implementation
+9. Propagate changes (project docs, flight artifacts if scope changed)
+10. **Complete the Leg Completion Checklist above**
+11. Signal `[COMPLETE:leg]`
+
+---
+
+## Just-in-Time Planning
+
+Flights and legs are created one at a time, not upfront.
+
+| Reviewing... | Should exist | Should NOT exist yet |
+|--------------|--------------|----------------------|
+| Mission | Mission artifact | Flight artifacts (only listed) |
+| Flight | Flight artifact | Leg artifacts (only listed) |
+| Leg | Leg artifact | Ready to implement |
+
+Listed flights/legs are **tentative suggestions** that evolve based on discoveries.
+
+---
+
+## Reviewing Artifacts
+
+When reviewing a mission, flight, or leg:
+
+1. Read the artifact thoroughly
+2. Validate against project goals and existing code
+3. Check for ambiguities or missing details
+4. Make changes directly if needed
+5. Describe any changes made
+6. Signal `[HANDOFF:confirmed]` if no issues, or describe changes for validation
+
+---
+
+## Code Review Gate
+
+```
+Implement → Test → Review → Fix → Re-review → Complete
+```
+
+| Severity | Action |
+|----------|--------|
+| Critical | Must fix |
+| Major | Must fix |
+| Minor | Fix if safe, else defer |
+
+Deferred issues go in the flight log.
+
+---
+
+## ⚠️ Flight Completion Checklist (MANDATORY)
+
+**When you complete the FINAL leg of a flight, also complete these steps:**
+
+| Step | Action |
+|------|--------|
+| 1 | Complete all items in the Leg Completion Checklist above |
+| 2 | **Update flight log** — Add flight completion entry with summary |
+| 3 | **Update flight status** — Set `**Status**: landed` in flight.md |
+| 4 | **Update mission** — Check off this flight in mission.md |
+| 5 | **Verify all legs** — Confirm all legs show `completed` status |
+| 6 | **Update project docs** — Ensure CLAUDE.md, README, and other docs reflect any new commands, endpoints, configuration, or APIs introduced during the flight |
+| 7 | Signal `[COMPLETE:leg]` (the orchestrator will trigger Phase 4) |
+
+The orchestrator will then:
+- Mark the PR ready for human review
+
+The flight debrief is a separate step run via `/flight-debrief`, which transitions the flight from `landed` to `completed`.
+
+---
+
+## Database Schema Changes
+
+When a flight modifies database schemas:
+
+1. **Include migration steps in the leg** — schema changes need explicit CREATE/ALTER statements or migration commands
+2. **Verify migrations run** — acceptance criteria must include confirming the migration executed successfully against the live database
+3. **Update SCHEMA docs** — if the project maintains a SCHEMA reference, update it in the same leg that creates the migration
+4. **Test against real DB** — unit tests with mocks are not sufficient for schema changes; verify against the actual database
+
+A table defined in SCHEMA but never created via migration is a gap — treat schema documentation and migration execution as a single atomic operation.
+
+---
+
+## Key Principles
+
+1. **Flight log is ground truth** — Read it first, update it always
+2. **Never modify in-flight legs** — Create new ones instead
+3. **Binary acceptance criteria** — Met or not met
+4. **Log everything** — Decisions, deviations, anomalies
+5. **Signal clearly** — End of response, own line

container/mission-control/.claude/skills/init-project/README.md

@@ -0,0 +1,29 @@
+# Flight Operations
+
+This directory contains reference materials for the [Flight Control](https://github.com/anthropics/flight-control) development methodology.
+
+## Contents
+
+- **FLIGHT_OPERATIONS.md** — Quick reference for implementing missions, flights, and legs
+- **ARTIFACTS.md** — Project-specific configuration for how artifacts are stored
+- **agent-crews/** — Project crew definitions for each phase (who Mission Control works with)
+
+## For AI Agents
+
+When working on this project with Flight Control:
+
+1. Read `ARTIFACTS.md` to understand how this project stores missions, flights, and legs
+2. Read `FLIGHT_OPERATIONS.md` for the implementation workflow
+3. Read the relevant `agent-crews/*.md` file for crew definitions and prompts
+4. Check the artifact locations defined in `ARTIFACTS.md` for active work
+5. Follow the code review gate before marking any leg complete
+6. Update flight-log after each leg (location depends on artifact system)
+
+## Sync Behavior
+
+| File | Synced? | Notes |
+|------|---------|-------|
+| README.md | Yes | Updated via `/init-project` |
+| FLIGHT_OPERATIONS.md | Yes | Updated via `/init-project` |
+| ARTIFACTS.md | No | Project-specific, customize freely |
+| agent-crews/*.md | No | Project-specific, customize freely |

container/mission-control/.claude/skills/init-project/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: init-project
+description: Initialize a project for Flight Control. Creates .flightops directory with methodology reference and artifact configuration. Run before using other Flight Control skills on a new project.
+---
+
+# Project Initialization
+
+Prepare a project for Flight Control by creating the `.flightops/` directory with methodology references and artifact configuration.
+
+## When to Use
+
+Run `/init-project` when:
+- Starting to use Flight Control on a new project
+- You suspect the .flightops reference may be outdated
+- Another skill indicates the reference needs to be synced
+
+## Workflow
+
+### 1. Identify Target Project
+
+1. **Read `projects.md`** to find the project's path, remote, and description
+2. If the project isn't listed, ask the user for:
+   - Project name/slug
+   - Filesystem path
+   - Brief description
+3. Optionally offer to add the project to `projects.md`
+
+### 2. Check and Apply Migrations
+
+Check for legacy directory layouts and offer to migrate them.
+
+1. **Read `migrations.md`** from the skill directory (`${SKILL_DIR}/migrations.md`)
+2. **Run detection checks** for each migration in order (001, 002, ...)
+3. **If no migrations are needed**, proceed silently to the next step
+4. **If any migrations are needed**, present a summary to the user:
+   > "Detected legacy directory layout in {project}. The following migrations are available:"
+   >
+   > - _Each applicable migration's user message_
+   >
+   > "Apply these migrations?"
+5. **On confirmation**, apply the actions for each applicable migration in order
+6. **On decline**, warn the user that some skills may not work correctly with the old layout, but continue using whatever directory structure exists
+
+### 3. Check Sync Status
+
+Run the hash comparison script to determine sync status:
+
+```bash
+bash "${SKILL_DIR}/check-sync.sh" \
+  "${SKILL_DIR}" \
+  "{target-project}/.flightops"
+```
+
+The script outputs one of:
+- `missing` - Directory doesn't exist in target project
+- `outdated` - Directory exists but files differ from source
+- `current` - All files are up-to-date
+
+### 4. Prompt and Sync Methodology Files
+
+Based on the status:
+
+**If `missing`**:
+> "Flight operations directory not found. Create `{project}/.flightops/` with methodology references?"
+
+**If `outdated`**:
+> "Flight operations references in {project} are outdated. Update?"
+
+**If `current`**:
+> "Flight operations references are up-to-date in {project}."
+
+If the user confirms, create/update the directory:
+
+```bash
+mkdir -p "{target-project}/.flightops"
+cp "${SKILL_DIR}/FLIGHT_OPERATIONS.md" "{target-project}/.flightops/"
+cp "${SKILL_DIR}/README.md" "{target-project}/.flightops/"
+```
+
+### 5. Configure Artifact System (New Projects Only)
+
+**Only if ARTIFACTS.md doesn't exist**, ask the user to select an artifact system:
+
+> "How should mission, flight, and leg artifacts be stored?"
+
+Available templates:
+- **files** — Markdown files in the repository (`templates/ARTIFACTS-files.md`)
+- **jira** — Jira issues: Epics, Stories, Sub-tasks (`templates/ARTIFACTS-jira.md`)
+
+#### 5a. Check for Setup Questions
+
+After the user selects a template, read the template file and check if it contains a `## Setup Questions` section with a table of questions.
+
+If setup questions exist:
+1. Parse the questions from the table (first column contains the questions)
+2. Ask the user each question interactively
+3. Replace the placeholder answers in the table with the user's responses
+
+#### 5b. Copy and Populate Template
+
+Copy the selected template, with answers populated if setup questions were asked:
+
+```bash
+cp "${SKILL_DIR}/templates/ARTIFACTS-{selection}.md" \
+   "{target-project}/.flightops/ARTIFACTS.md"
+```
+
+If setup questions were answered, update the ARTIFACTS.md file to replace the placeholder answers with the user's responses.
+
+**If ARTIFACTS.md already exists**, do not modify it — it's project-specific and may have been customized.
+
+### 6. Configure Project Crew
+
+Set up phase-specific crew definitions that control how Mission Control interacts with project-side agents.
+
+1. **Check if `.flightops/agent-crews/` exists**
+
+   **If missing** (first run):
+   - Copy all defaults from `${SKILL_DIR}/defaults/agent-crews/` to `{target-project}/.flightops/agent-crews/`
+   - Brief the user:
+     > "Default crew has been set up for all phases. Your agent crews define who Mission Control (Flight Director) works with during each phase — which agents exist, their roles, models, and prompts."
+   - Ask about customization:
+     > "Want to customize any agent crew? (Most projects work fine with defaults)"
+   - If yes: ask which crew → show current definitions → walk through changes (add/remove/modify roles, adjust prompts, change interaction protocol)
+   - If no: proceed with defaults
+
+   **If exists** (re-run):
+   - Copy any missing crew files from defaults (new crews added to the methodology)
+   - Ask the user:
+     > "Agent crew files already exist. Default crew definitions may have been updated since your project was initialized. Want to review and update any crew files to the latest defaults?"
+   - If yes: for each file, show what changed between their version and the current default, ask whether to overwrite or keep their version
+   - If no: leave all existing files untouched
+
+### 7. Update CLAUDE.md
+
+Check if the project's `CLAUDE.md` file references the flight operations directory:
+
+1. **If CLAUDE.md doesn't exist**, create it with a Flight Operations section
+2. **If CLAUDE.md exists but lacks a Flight Operations section**, append one
+3. **If CLAUDE.md already has a Flight Operations section**, leave it unchanged
+
+#### 7a. Fix Stale Path References
+
+If migrations were applied in Step 2, scan the project's `CLAUDE.md` for stale path references within the Flight Operations section and fix them:
+
+- Replace `.flight-ops/` → `.flightops/`
+- Replace `phases/` → `agent-crews/` (only within Flight Operations context)
+
+This ensures the CLAUDE.md instructions point to the correct post-migration paths.
+
+Add this section:
+
+```markdown
+## Flight Operations
+
+This project uses [Flight Control](https://github.com/msieurthenardier/mission-control).
+
+**Before any mission/flight/leg work, read these files in order:**
+1. `.flightops/README.md` — What the flightops directory contains
+2. `.flightops/FLIGHT_OPERATIONS.md` — **The workflow you MUST follow**
+3. `.flightops/ARTIFACTS.md` — Where all artifacts are stored
+4. `.flightops/agent-crews/` — Project crew definitions for each phase (read the relevant crew file)
+```
+
+### 8. Post-Sync Instructions
+
+After creating or updating the directory, inform the user:
+
+> "If you have Claude Code running in {project}, restart it to pick up the new flight operations references."
+
+This ensures Claude Code loads the new files into its context when working in the target project.
+
+## Output
+
+This skill creates/updates the following at project root:
+
+```
+{project}/
+├── CLAUDE.md                  # Updated with Flight Operations section
+└── .flightops/               # Hidden directory for Flight Control
+    ├── README.md              # Explains the directory purpose
+    ├── FLIGHT_OPERATIONS.md   # Quick reference for implementation (synced)
+    ├── ARTIFACTS.md           # Artifact system configuration (project-specific)
+    └── agent-crews/           # Project crew definitions (project-specific)
+        ├── mission-design.md
+        ├── flight-design.md
+        ├── leg-execution.md
+        ├── flight-debrief.md
+        ├── mission-debrief.md
+        └── routine-maintenance.md
+```
+
+## File Sync Behavior
+
+| File | Synced on update? | Notes |
+|------|-------------------|-------|
+| CLAUDE.md | Append only | Adds Flight Operations section if missing |
+| README.md | Yes | Methodology reference |
+| FLIGHT_OPERATIONS.md | Yes | Methodology reference |
+| ARTIFACTS.md | No | Created once from template, then project-specific |
+| agent-crews/*.md | Ask on re-run | Created from defaults; on re-run, user can choose to update to latest defaults |
+
+## Guidelines
+
+### Don't Over-Prompt
+
+If everything is `current`, just inform the user briefly and move on. No confirmation needed.
+
+### Respect ARTIFACTS.md
+
+Never overwrite ARTIFACTS.md — it may contain project-specific customizations. Only create it if missing.
+
+### Keep It Quick
+
+This is a setup step, not the main work. Complete it efficiently so the user can proceed to their actual task.

container/mission-control/.claude/skills/init-project/check-sync.sh

@@ -0,0 +1,119 @@
+#!/bin/bash
+# check-sync.sh - Compare .flightops directory between source and target
+#
+# Usage: check-sync.sh <source-dir> <target-dir>
+#
+# Outputs:
+#   missing  - Target directory doesn't exist (neither .flightops/ nor .flight-ops/)
+#   outdated - Target exists but one or more files differ from source
+#   current  - All files match source
+#
+# Additional output lines:
+#   agent-crews:{missing|empty|present}     - Crew directory status
+#   crew-missing:{filename}                 - Default crew file not found in project (repeats per file)
+#   legacy-layout:flight-ops                - .flight-ops/ detected (old name)
+#   legacy-layout:phases                    - phases/ detected (old name)
+#
+# Note: Only checks synced files (README.md, FLIGHT_OPERATIONS.md).
+#       ARTIFACTS.md and agent-crews/ are project-specific and not synced.
+
+set -e
+
+SOURCE_DIR="$1"
+TARGET_DIR="$2"
+
+if [[ -z "$SOURCE_DIR" || -z "$TARGET_DIR" ]]; then
+  echo "Usage: check-sync.sh <source-dir> <target-dir>" >&2
+  exit 1
+fi
+
+if [[ ! -d "$SOURCE_DIR" ]]; then
+  echo "Error: Source directory not found: $SOURCE_DIR" >&2
+  exit 1
+fi
+
+# Resolve the actual target directory, falling back to legacy name
+EFFECTIVE_TARGET="$TARGET_DIR"
+LEGACY_FLIGHT_OPS=false
+
+if [[ ! -d "$TARGET_DIR" ]]; then
+  # Derive the legacy path: replace trailing .flightops with .flight-ops
+  LEGACY_DIR="${TARGET_DIR%/.flightops}/.flight-ops"
+  if [[ "$LEGACY_DIR" != "$TARGET_DIR" && -d "$LEGACY_DIR" ]]; then
+    EFFECTIVE_TARGET="$LEGACY_DIR"
+    LEGACY_FLIGHT_OPS=true
+  else
+    echo "missing"
+    exit 0
+  fi
+fi
+
+# Compare each file in source directory
+FILES_TO_CHECK=("FLIGHT_OPERATIONS.md" "README.md")
+ALL_CURRENT=true
+
+for FILE in "${FILES_TO_CHECK[@]}"; do
+  SOURCE_FILE="$SOURCE_DIR/$FILE"
+  TARGET_FILE="$EFFECTIVE_TARGET/$FILE"
+
+  if [[ ! -f "$SOURCE_FILE" ]]; then
+    continue
+  fi
+
+  if [[ ! -f "$TARGET_FILE" ]]; then
+    ALL_CURRENT=false
+    break
+  fi
+
+  SOURCE_HASH=$(sha256sum "$SOURCE_FILE" | cut -d' ' -f1)
+  TARGET_HASH=$(sha256sum "$TARGET_FILE" | cut -d' ' -f1)
+
+  if [[ "$SOURCE_HASH" != "$TARGET_HASH" ]]; then
+    ALL_CURRENT=false
+    break
+  fi
+done
+
+if $ALL_CURRENT; then
+  echo "current"
+else
+  echo "outdated"
+fi
+
+# Report on agent-crews directory existence, checking both current and legacy names
+CREW_DIR=""
+LEGACY_PHASES=false
+
+if [[ -d "$EFFECTIVE_TARGET/agent-crews" ]]; then
+  CREW_DIR="$EFFECTIVE_TARGET/agent-crews"
+elif [[ -d "$EFFECTIVE_TARGET/phases" ]]; then
+  CREW_DIR="$EFFECTIVE_TARGET/phases"
+  LEGACY_PHASES=true
+fi
+
+if [[ -z "$CREW_DIR" ]]; then
+  echo "agent-crews:missing"
+elif [[ -z "$(ls -A "$CREW_DIR" 2>/dev/null)" ]]; then
+  echo "agent-crews:empty"
+else
+  echo "agent-crews:present"
+  # Check for missing crew files (new skills added since init)
+  DEFAULT_CREWS_DIR="$SOURCE_DIR/defaults/agent-crews"
+  if [[ -d "$DEFAULT_CREWS_DIR" ]]; then
+    for DEFAULT_FILE in "$DEFAULT_CREWS_DIR"/*.md; do
+      BASENAME=$(basename "$DEFAULT_FILE")
+      if [[ ! -f "$CREW_DIR/$BASENAME" ]]; then
+        echo "crew-missing:$BASENAME"
+      fi
+    done
+  fi
+fi
+
+# Report legacy layout detection
+if $LEGACY_FLIGHT_OPS; then
+  echo "legacy-layout:flight-ops"
+fi
+
+if $LEGACY_PHASES; then
+  echo "legacy-layout:phases"
+fi

container/mission-control/.claude/skills/init-project/defaults/agent-crews/flight-debrief.md

@@ -0,0 +1,126 @@
+# Flight Debrief — Project Crew
+
+Crew definitions for post-flight analysis. The Flight Director interviews the
+human and project-side agents to capture both execution and design perspectives.
+
+## Crew
+
+### Developer
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Provides developer perspective on flight execution. Reviews what was
+  built, identifies technical debt introduced, evaluates implementation quality,
+  and surfaces issues that flight logs may not capture.
+- **Actions**: debrief-interview
+
+### Architect
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Closes the design feedback loop. Evaluates whether the design decisions
+  made during flight planning held up in practice. Reviews architectural impact of
+  what was built and whether the approach should be adjusted for future flights.
+- **Actions**: debrief-design-review
+
+## Interaction Protocol
+
+### Developer Interview
+1. Flight Director loads flight context (mission, flight, legs, log, actual code)
+2. Flight Director spawns **Developer** to review implementation and provide feedback
+3. Developer examines code changes, test coverage, patterns used, debt introduced
+4. Developer provides structured debrief input
+
+### Architect Interview
+1. Flight Director spawns **Architect** to review whether design decisions held up
+2. Architect compares flight-design spec against actual implementation
+3. Architect evaluates architectural impact and provides feedback for future flights
+
+### Human Interview
+1. Flight Director interviews human with targeted questions based on flight log
+2. Keep lightweight — 2-3 questions max
+
+### Synthesis
+1. Flight Director synthesizes Developer input + Architect input + human input + document analysis
+2. Generates debrief artifact
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description |
+|----------|-------------|
+| `{project-slug}` | Project identifier from projects.md |
+| `{flight-number}` | Current flight number |
+| `{flight-artifact-path}` | Path to the flight artifact file |
+
+## Prompts
+
+### Developer: Debrief Interview
+
+```
+role: developer
+phase: flight-debrief
+project: {project-slug}
+flight: {flight-number}
+action: debrief-interview
+
+Review the implementation produced during this flight. Examine the code changes,
+test coverage, and architectural decisions made.
+
+Provide structured input for the debrief:
+
+**Implementation Quality**:
+- Does the code follow project conventions?
+- Are there patterns that should be documented?
+- What technical debt was introduced?
+
+**Leg Spec Accuracy**:
+- Were leg specs clear and sufficient for implementation?
+- What was missing or misleading?
+- Were acceptance criteria verifiable?
+
+**Testing Assessment**:
+- Is test coverage adequate?
+- Are there untested edge cases?
+- Do tests meaningfully validate behavior?
+
+**Recommendations**:
+- What should future flights in this area account for?
+- Are there refactoring opportunities?
+- What documentation is missing?
+```
+
+### Architect: Debrief Design Review
+
+```
+role: architect
+phase: flight-debrief
+project: {project-slug}
+flight: {flight-number}
+action: debrief-design-review
+
+Read the flight artifact at {flight-artifact-path}. Compare the design decisions,
+technical approach, and leg breakdown that were planned against what was actually
+implemented.
+
+Provide structured input for the debrief:
+
+**Design Decisions Assessment**:
+- Which design decisions held up well in practice?
+- Which decisions had to be revised during implementation? Why?
+- Were there decisions that should have been made differently?
+
+**Architectural Impact**:
+- Did the implementation maintain or improve the system's architecture?
+- Were there unplanned structural changes? Are they sound?
+- Did the approach create any architectural debt?
+
+**Flight Design Accuracy**:
+- Was the technical approach feasible as specified?
+- Were prerequisites correctly identified?
+- Was the leg breakdown appropriate for the actual work?
+
+**Forward-Looking**:
+- What should future flight designs in this area account for?
+- Are there architectural patterns that emerged worth standardizing?
+- What design assumptions should be revisited?
+```

container/mission-control/.claude/skills/init-project/defaults/agent-crews/flight-design.md

@@ -0,0 +1,72 @@
+# Flight Design — Project Crew
+
+Crew definitions for flight specification. The Flight Director designs the
+technical spec and uses project-side agents to validate against the real codebase.
+
+## Crew
+
+### Architect
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Reviews flight specs for technical soundness. Validates design
+  decisions, prerequisites, technical approach, and leg breakdown against
+  architecture best practices and actual codebase state. Ensures the flight
+  is buildable and well-structured.
+- **Actions**: review-flight-design
+
+## Interaction Protocol
+
+### Design Review
+1. Flight Director creates flight spec and interviews human
+2. Flight Director spawns **Architect** to review against codebase
+3. Architect evaluates design decisions, prerequisites, approach, leg breakdown
+4. Flight Director incorporates feedback
+5. Max 2 review cycles — escalate to human if unresolved
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description |
+|----------|-------------|
+| `{project-slug}` | Project identifier from projects.md |
+| `{flight-number}` | Current flight number |
+| `{flight-artifact-path}` | Path to the flight artifact file |
+
+## Prompts
+
+### Architect: Review Flight Design
+
+```
+role: architect
+phase: flight-design-review
+project: {project-slug}
+flight: {flight-number}
+action: review-flight-design
+
+Read the flight artifact at {flight-artifact-path}. Cross-reference its design
+decisions, prerequisites, technical approach, and leg breakdown against the actual
+codebase state and architecture best practices.
+
+Evaluate:
+1. Design decisions — are they sound given the real codebase and architecture?
+2. Prerequisites — are they accurate? Is anything missing or already done?
+3. Technical approach — is it feasible? Does it follow existing patterns?
+4. Leg breakdown — are legs well-scoped, properly ordered, with correct dependencies?
+5. Codebase state — does the spec account for current working tree, existing tooling,
+   and conventions that might affect implementation?
+6. Architecture — does the approach maintain or improve system structure?
+
+Provide structured output:
+
+**Overall assessment**: approve | approve with changes | needs rework
+
+**Issues** (ranked by severity):
+- [high/medium/low] Description — recommended fix
+
+**Suggestions** (non-blocking improvements):
+- Description
+
+**Questions** (for the designer to clarify):
+- Question
+```

container/mission-control/.claude/skills/init-project/defaults/agent-crews/leg-execution.md

@@ -0,0 +1,216 @@
+# Leg Execution — Project Crew
+
+Crew definitions and interaction protocol for implementing flight legs.
+The Flight Director (Mission Control) orchestrates this phase using the
+/agentic-workflow skill.
+
+## Crew
+
+### Developer
+- **Context**: {working-directory}/
+- **Model**: Sonnet
+- **Role**: Implements code changes. Also performs design reviews against real
+  codebase to validate leg specs before implementation.
+- **Actions**: implement, fix-review-issues, commit, review-leg-design
+
+### Reviewer
+- **Context**: {working-directory}/
+- **Model**: Sonnet (NEVER Opus)
+- **Role**: Reviews code changes for quality, correctness, and criteria compliance.
+  Has NO knowledge of Developer's reasoning — only sees resulting changes.
+- **Actions**: review
+
+### Accessibility Reviewer (optional)
+- **Context**: {working-directory}/
+- **Model**: Sonnet
+- **Enabled**: false
+- **Role**: Reviews UI changes for accessibility compliance. Evaluates against
+  WCAG 2.1 AA standards, screen reader compatibility, keyboard navigation,
+  color contrast, ARIA usage, and semantic HTML. Only spawn when the leg
+  involves user-facing interface changes.
+- **Actions**: review-accessibility
+
+## Separation Rules
+
+- Developer and Reviewer load the target project's CLAUDE.md and conventions
+- Reviewer has NO knowledge of Developer's reasoning — only resulting changes
+- Each agent instance gets fresh context (no carryover between legs)
+
+**Note:** Handoff signals (`[HANDOFF:review-needed]`, `[HANDOFF:confirmed]`, `[BLOCKED:reason]`, `[COMPLETE:leg]`) are defined by the Flight Control methodology in the agentic-workflow skill, not in this file. Do not modify signal names here — they must match what the Flight Director expects.
+
+## Interaction Protocol
+
+### Design Review
+1. Flight Director spawns **Developer** for design review
+2. Developer reviews leg against codebase, provides structured assessment
+3. Flight Director incorporates feedback
+4. Max 2 review cycles — escalate to human if unresolved
+
+### Implementation
+1. Flight Director spawns **Developer** to implement
+2. Developer implements to acceptance criteria, updates flight log
+3. Developer signals [HANDOFF:review-needed] — does NOT commit
+
+### Code Review
+1. Flight Director spawns **Reviewer** to evaluate all uncommitted changes
+2. If **Accessibility Reviewer** is enabled and leg involves UI changes,
+   spawn in parallel with Reviewer
+3. If issues: Flight Director spawns new **Developer** to fix
+4. Loop until all reviewers signal [HANDOFF:confirmed] — max 3 cycles
+
+### Commit
+1. Flight Director spawns **Developer** to commit
+2. Developer commits code + artifacts, signals [COMPLETE:leg]
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description | Available In |
+|----------|-------------|-------------|
+| `{project-slug}` | Project identifier from projects.md | All prompts |
+| `{flight-number}` | Current flight number | All prompts |
+| `{leg-number}` | Current leg number | Leg-scoped prompts |
+| `{leg-artifact-path}` | Path to the leg artifact file | review-leg-design |
+| `{working-directory}` | Resolved working directory for the agent (project root for branch strategy, worktree path for worktree strategy) | All prompts |
+| `{reviewer-issues}` | Full text of reviewer feedback (dynamic) | fix-review-issues |
+
+## Prompts
+
+### Developer: Review Leg Design
+
+```
+role: developer
+phase: leg-design-review
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: review-leg-design
+
+Read the leg artifact at {leg-artifact-path}. Cross-reference its acceptance
+criteria, implementation guidance, and file references against the actual codebase.
+
+Evaluate:
+1. Acceptance criteria — specific, verifiable, complete?
+2. Implementation guidance — complete and correctly ordered?
+3. Edge cases — missing scenarios?
+4. Codebase state — account for working tree, existing tooling, uncommitted changes?
+5. File/line references — accurate against current codebase?
+6. Dependencies — prerequisite legs completed? Outputs available?
+
+Provide structured output:
+
+**Overall assessment**: approve | approve with changes | needs rework
+
+**Issues** (ranked by severity):
+- [high/medium/low] Description — recommended fix
+
+**Suggestions** (non-blocking):
+- Description
+
+**Questions** (for the designer):
+- Question
+```
+
+### Developer: Implement
+
+```
+role: developer
+phase: leg-implementation
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: implement
+
+Read leg artifact. Update leg status to in-flight. Implement to acceptance criteria.
+Run tests with a timeout flag appropriate to this project's test runner — fail fast,
+do not wait indefinitely for hanging tests. If a test hangs, isolate and fix it.
+Update flight log with outcomes. Propagate changes to artifacts (flight, mission, leg),
+CLAUDE.md, README, and other project documentation as needed. Do NOT commit yet —
+signal [HANDOFF:review-needed] when implementation is complete.
+```
+
+### Reviewer: Review
+
+```
+role: reviewer
+phase: leg-review
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: review
+
+Review all changes since the last commit. Evaluate against:
+1. Leg acceptance criteria — are all criteria met?
+2. Code quality — style, clarity, maintainability
+3. Correctness — edge cases, error handling, security
+4. Tests — coverage, meaningful assertions, no regressions
+5. Artifacts — flight log updated, leg status correct
+
+Signal [HANDOFF:confirmed] if all changes are satisfactory.
+If issues found, list them with severity (blocking/non-blocking) and specific
+file:line references.
+```
+
+### Accessibility Reviewer: Review Accessibility
+
+```
+role: accessibility-reviewer
+phase: leg-review
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: review-accessibility
+
+Review all UI changes since the last commit for accessibility compliance.
+
+Evaluate against:
+1. WCAG 2.1 AA — do changes meet Level AA success criteria?
+2. Semantic HTML — proper heading hierarchy, landmark regions, form labels?
+3. Keyboard navigation — all interactive elements reachable and operable?
+4. Screen readers — ARIA attributes correct and meaningful? Live regions?
+5. Color and contrast — minimum 4.5:1 for text, 3:1 for large text/UI?
+6. Focus management — visible focus indicators, logical tab order?
+
+Signal [HANDOFF:confirmed] if all changes are accessible.
+If issues found, list them with severity (blocking/non-blocking), WCAG criterion
+reference, and specific file:line references.
+```
+
+### Developer: Fix Review Issues
+
+```
+role: developer
+phase: leg-implementation
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: fix-review-issues
+
+Address the following review feedback:
+{reviewer-issues}
+
+Fix all blocking issues. Non-blocking issues: fix if straightforward, otherwise
+note as accepted. Signal [HANDOFF:review-needed] when fixes are complete.
+```
+
+### Developer: Commit
+
+```
+role: developer
+phase: leg-implementation
+project: {project-slug}
+flight: {flight-number}
+leg: {leg-number}
+action: commit
+
+Review has passed. Before committing, complete ALL post-completion checklist items
+in the leg artifact:
+1. Check off all acceptance criteria in the leg artifact
+2. Update leg status to completed
+3. Check off this leg in flight.md
+4. If final leg: update flight.md status to landed, check off flight in mission.md
+
+Then commit all changes (code + artifacts) with appropriate message.
+Signal [COMPLETE:leg].
+```

container/mission-control/.claude/skills/init-project/defaults/agent-crews/mission-debrief.md

@@ -0,0 +1,74 @@
+# Mission Debrief — Project Crew
+
+Crew definitions for post-mission retrospective. The Flight Director interviews
+both the human and a project-side Architect to capture strategic technical perspective.
+
+## Crew
+
+### Architect
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Provides architectural perspective on mission outcomes. Evaluates
+  whether the system evolved well across flights, identifies structural issues,
+  and assesses long-term maintainability of what was built.
+- **Actions**: debrief-interview
+
+## Interaction Protocol
+
+### Architect Interview
+1. Flight Director loads full mission context (all flights, logs, debriefs, code)
+2. Flight Director spawns **Architect** to review overall system evolution
+3. Architect examines architectural changes across all flights
+4. Architect provides structured debrief input
+
+### Human Interview
+1. Flight Director interviews human with mission-level questions
+2. Covers coordination experience, outcome satisfaction, process feedback
+
+### Synthesis
+1. Flight Director synthesizes Architect input + human input + document analysis
+2. Generates mission debrief artifact
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description |
+|----------|-------------|
+| `{project-slug}` | Project identifier from projects.md |
+
+## Prompts
+
+### Architect: Debrief Interview
+
+```
+role: architect
+phase: mission-debrief
+project: {project-slug}
+action: debrief-interview
+
+Review the system changes produced across all flights in this mission. Examine
+the architectural evolution, pattern consistency, and structural health.
+
+Provide structured input for the debrief:
+
+**Architectural Assessment**:
+- Did the system's architecture improve, maintain, or degrade?
+- Are there structural issues that emerged across flights?
+- Were design decisions consistent across the mission?
+
+**Pattern Analysis**:
+- What patterns were established? Are they good ones?
+- Is there inconsistency that should be reconciled?
+- Are there reusable patterns worth documenting?
+
+**Technical Debt**:
+- What debt was introduced across the mission?
+- What's the priority for addressing it?
+- Are there quick wins vs. long-term concerns?
+
+**Forward-Looking**:
+- What architectural considerations should the next mission account for?
+- Are there scaling or performance concerns on the horizon?
+- What documentation or conventions should be established?
+```

container/mission-control/.claude/skills/init-project/defaults/agent-crews/mission-design.md

@@ -0,0 +1,72 @@
+# Mission Design — Project Crew
+
+Crew definitions for mission planning. The Flight Director interviews the human
+and uses project-side agents to validate technical viability.
+
+## Crew
+
+### Architect
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Validates technical viability of proposed outcomes. Ensures business
+  goals align with what's actually possible given the codebase, stack, and
+  constraints. Does NOT add implementation details — focuses on feasibility,
+  risks, and architectural implications.
+- **Actions**: validate-mission
+
+## Interaction Protocol
+
+### Research & Interview
+1. Flight Director researches codebase and external context
+2. Flight Director interviews human about outcomes, stakeholders, constraints, criteria
+3. Human must explicitly sign off before proceeding — iterate until approved
+
+### Technical Viability Check
+1. Flight Director spawns **Architect** to review draft mission against codebase
+2. Architect evaluates: Are proposed outcomes achievable? Are there technical risks
+   the mission doesn't account for? Does the stack support what's being asked?
+3. Architect provides assessment — feasible / feasible with caveats / not feasible
+4. Flight Director incorporates feedback, re-interviews human if scope changes
+5. Human gives final sign-off
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description |
+|----------|-------------|
+| `{project-slug}` | Project identifier from projects.md |
+
+## Prompts
+
+### Architect: Validate Mission
+
+```
+role: architect
+phase: mission-design
+project: {project-slug}
+action: validate-mission
+
+Read the draft mission artifact. Cross-reference proposed outcomes and success
+criteria against the actual codebase, stack, and project constraints.
+
+Evaluate:
+1. Technical feasibility — can the proposed outcomes be achieved with this stack?
+2. Architectural implications — does this require significant structural changes?
+3. Risk factors — what technical risks could block success?
+4. Constraints accuracy — are stated constraints complete and correct?
+5. Sizing — is the scope realistic for a mission (days-to-weeks)?
+
+Provide structured output:
+
+**Feasibility**: feasible | feasible with caveats | not feasible
+
+**Risks** (ranked by impact):
+- [high/medium/low] Description — mitigation
+
+**Caveats** (if feasible with caveats):
+- Description
+
+**Questions** (for the Flight Director):
+- Question
+```

container/mission-control/.claude/skills/init-project/defaults/agent-crews/routine-maintenance.md

@@ -0,0 +1,592 @@
+# Routine Maintenance — Project Crew
+
+Crew definitions for codebase health inspection. The Flight Director
+coordinates specialist reviewers for automated checks and an Architect
+for severity assessment and roundtable moderation.
+
+## Crew
+
+### Inspector
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Performs broad read-only codebase inspection across all applicable
+  categories. Runs test suites, linters, type checkers, audit commands, and
+  manual code review. Returns structured findings without modifying any files.
+- **Actions**: inspect-codebase
+
+### Security Reviewer
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Role**: Performs focused manual security review of authentication flows,
+  injection surfaces, secrets handling, CORS/CSP configuration, and data
+  exposure risks. Goes deeper than the Inspector's Category 1 automated checks
+  with targeted code path analysis.
+- **Actions**: review-security
+
+### CI/CD Reviewer (optional)
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Enabled**: false (enable when project has CI/CD pipelines)
+- **Role**: Reviews CI/CD pipeline configuration, build security, deployment
+  practices, and environment consistency. Evaluates pipeline definitions,
+  secret management in CI, and deployment safeguards.
+- **Actions**: review-cicd
+
+### Accessibility Reviewer (optional)
+- **Context**: {project}/
+- **Model**: Sonnet
+- **Enabled**: false (enable when project has user-facing UI)
+- **Role**: Reviews codebase for accessibility compliance against WCAG 2.1 AA
+  standards. Evaluates semantic HTML, keyboard navigation, screen reader
+  compatibility, color contrast, ARIA usage, and focus management.
+- **Actions**: review-accessibility
+
+### Architect
+- **Context**: {project}/
+- **Model**: Opus
+- **Role**: Reviews all reviewer findings alongside debrief context. Assigns
+  severity per finding, challenges questionable assessments, moderates
+  roundtable discussion with specialist reviewers, and produces final codebase
+  assessment with maintenance scope recommendation.
+- **Actions**: assess-findings, moderate-roundtable
+
+## Separation Rules
+
+- All reviewers are strictly **read-only** — they may run commands but must NEVER modify files
+- Each reviewer operates independently during Phase 4 — no cross-reviewer communication
+- The Architect sees all reviewer findings but not their internal reasoning
+- Roundtable discussion is mediated by the Flight Director, not direct agent-to-agent
+
+**Note:** Handoff signals are not used in this crew. The routine-maintenance workflow is
+sequential (review → assess → roundtable → report) and does not use the leg-based
+handoff protocol.
+
+## Interaction Protocol
+
+### Delegation Planning
+1. Flight Director loads context, conducts scoping interview with human
+2. Flight Director assesses project size and identifies module boundaries
+3. Flight Director builds delegation plan (agent count, scope assignments, partitioning)
+4. Human approves or adjusts the plan
+
+### Specialist Review
+1. Flight Director spawns agents per the delegation plan — Inspector(s) + Security Reviewer always, CI/CD and Accessibility if enabled
+2. Each agent receives its scope assignment and output discipline rules
+3. All reviewers perform read-only checks and return structured findings
+4. For partitioned Inspectors: Flight Director merges and de-duplicates findings
+
+### Initial Assessment
+1. Flight Director spawns **Architect** (Opus) with all reviewer findings + debrief context
+2. Architect assigns initial severity per finding
+3. Architect raises challenges or questions directed at specific reviewers
+
+### Roundtable
+1. Flight Director routes Architect's challenges to the relevant reviewers
+2. Each challenged reviewer responds with evidence, rebuttals, or concurrence
+3. Flight Director collects responses and spawns Architect for final resolution
+4. Architect produces final assessment incorporating roundtable discussion
+5. Max 2 roundtable cycles — unresolved disagreements go to the human
+
+### Human Review and Scoping
+1. Flight Director presents findings to human, grouped by severity
+2. Human confirms, overrides, or adjusts findings
+3. If Maintenance Required: Flight Director recommends a shortlist (~5-7 items); human selects scope for maintenance mission
+4. Deferred findings remain in the report for future cycles
+
+### Synthesis
+1. Flight Director generates maintenance report artifact
+2. If confirmed: Flight Director creates maintenance mission scaffold
+
+## Template Variables
+
+The Flight Director substitutes these variables in prompts at runtime:
+
+| Variable | Description |
+|----------|-------------|
+| `{project-slug}` | Project identifier from projects.md |
+| `{applicable-categories}` | Numbered list of categories to inspect (1-7 always, 8-10 conditional) |
+| `{project-stack}` | Language, framework, test runner, linter, formatter, type checker, audit tool |
+| `{known-debt}` | Debt items from mission debrief and flight debriefs (if available, otherwise "None — ad-hoc inspection") |
+| `{known-security-debt}` | Security-specific debt items extracted from debriefs (if available, otherwise "None") |
+| `{known-cicd-debt}` | CI/CD-specific debt items extracted from debriefs (if available, otherwise "None") |
+| `{areas-of-concern}` | User-specified areas of concern from scoping interview |
+| `{scope-assignment}` | Scope restriction from the delegation plan (files, directories, or "full project") |
+| `{all-reviewer-findings}` | Combined structured findings from all reviewers (used in Architect prompts) |
+| `{architect-challenges}` | Architect's challenges directed at a specific reviewer (used in roundtable) |
+| `{roundtable-responses}` | All reviewer rebuttals and responses from the roundtable (used in resolution) |
+
+## Prompts
+
+### Inspector: Inspect Codebase
+
+```
+role: inspector
+phase: routine-maintenance
+project: {project-slug}
+action: inspect-codebase
+
+Perform a read-only codebase inspection across the following categories:
+{applicable-categories}
+
+Project stack: {project-stack}
+
+Known debt from prior debriefs, if available (do not re-flag as new discoveries):
+{known-debt}
+
+User areas of concern:
+{areas-of-concern}
+
+IMPORTANT: You are strictly READ-ONLY. You may run test suites, linters, type
+checkers, audit commands, and read any file. You must NEVER modify source files,
+configuration, dependencies, or any other project file.
+
+**Scope assignment**: If a scope restriction is provided, inspect only the
+specified files and directories. Run automated tools against the full project
+(tools are fast and comprehensive), but limit manual code review to the assigned
+scope. If no scope restriction is given, inspect the full project.
+
+For each applicable category, perform the checks listed below and report findings.
+
+**Category 1 — Security**:
+- Review auth paths (focus on recently changed code if mission context is available)
+- Check input sanitization on endpoints
+- Verify CORS/CSP configuration
+- Scan for hardcoded secrets (API keys, tokens, passwords)
+- Review third-party data flow for exposure risks
+
+**Category 2 — Test Systems**:
+- Run the test suite and report results
+- Check coverage delta (if tooling available)
+- Find new code paths without test coverage
+- Detect flaky tests (tests that pass/fail inconsistently)
+- Check test performance (slow tests)
+- Find hardcoded test data that should be fixtures
+
+**Category 3 — Dependency Health**:
+- Run the dependency audit command (npm audit, cargo audit, etc.)
+- Check for outdated dependencies
+- Find unused dependencies
+- Verify lockfile is consistent
+- Check license compliance
+- Check for Dependabot/Renovate PRs and security alerts
+- Assess auto-merge eligibility for patch updates
+
+**Category 4 — Code Quality**:
+- Run linter and formatter check (report violations, do NOT fix)
+- Find dead code (unused exports, unreachable branches)
+- Grep for TODOs/FIXMEs/HACKs (focus on recently introduced ones if mission context is available)
+- Detect code duplication
+- Check pattern consistency with existing codebase
+
+**Category 5 — Type & API Safety**:
+- Run the type checker and report errors
+- Find `any` casts (TypeScript), `unsafe` blocks (Rust), or equivalent
+- Check for unhandled errors or missing error types
+- Detect API contract drift (mismatched types between client/server)
+- Find deprecated API usage
+
+**Category 6 — Documentation**:
+- Check README accuracy against current state
+- Verify new public interfaces have documentation
+- Find stale comments referencing old behavior
+- Check CHANGELOG for completeness
+- Verify CLAUDE.md accuracy
+
+**Category 7 — Git & Branch Hygiene**:
+- List stale branches (merged but not deleted)
+- Find large committed files (>1MB)
+- Scan for secrets in recent git history
+- Check commit message quality
+- Check for GitHub/remote warnings (secret scanning, code scanning alerts)
+- Find merge conflicts against main
+- Check upstream divergence
+
+**Category 8 — CI/CD Pipeline** (if applicable):
+- Check CI status on main/default branch
+- Detect build time regression
+- Find skipped or disabled checks
+- Check config drift between environments
+
+**Category 9 — Infrastructure & Config** (if applicable):
+- Check env var documentation (.env.example vs actual usage)
+- Find pending database migrations
+- Find temporary feature flags that should be removed
+
+**Category 10 — Performance & Observability** (if applicable):
+- Find new operations without logging/tracing
+- Detect potential N+1 queries
+- Check bundle size (if web project)
+- Find resource cleanup issues (unclosed connections, missing cleanup)
+
+**Output discipline**: Keep findings concise. Do not paste full command output,
+full file contents, or long dependency lists. Summarize and reference.
+
+**Output format**: Return findings as a structured list per category:
+
+## Category {N}: {Name}
+
+### Finding: {title}
+- **Evidence**: {one-line summary with file paths and line numbers}
+- **Impact**: {what could go wrong}
+- **Recommendation**: {what to do about it}
+
+Include code excerpts only for Critical or High severity findings.
+
+If a category has no issues, report:
+## Category {N}: {Name}
+No issues found.
+```
+
+### Security Reviewer: Review Security
+
+```
+role: security-reviewer
+phase: routine-maintenance
+project: {project-slug}
+action: review-security
+
+Perform a focused, manual security review of the codebase. You go deeper than
+automated scanning — trace actual code paths and evaluate security posture.
+
+Project stack: {project-stack}
+
+Known security debt from prior debriefs (do not re-flag as new discoveries):
+{known-security-debt}
+
+User areas of concern:
+{areas-of-concern}
+
+IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
+You must NEVER modify source files, configuration, dependencies, or any other
+project file.
+
+**Scope assignment**: Review only the files and areas specified. If no scope
+restriction is given, review the full project.
+
+**Output discipline**: Keep findings concise. Include code excerpts only for
+Critical or High severity findings. Do not paste full file contents or raw
+command output.
+
+**Review areas**:
+
+1. **Authentication & Authorization**
+   - Trace auth flows end-to-end (login, token refresh, logout)
+   - Check for missing auth checks on protected routes/endpoints
+   - Verify role-based access control is enforced consistently
+   - Look for privilege escalation paths
+
+2. **Injection Surfaces**
+   - SQL/NoSQL injection: check all database queries for parameterization
+   - Command injection: check shell executions, subprocess calls
+   - XSS: check output encoding in templates and API responses
+   - Path traversal: check file system operations with user input
+
+3. **Secrets & Configuration**
+   - Scan for hardcoded credentials, API keys, tokens in source
+   - Check .env files are gitignored
+   - Verify secrets are not logged or included in error responses
+   - Check for overly permissive CORS configuration
+
+4. **Data Handling**
+   - Review PII/sensitive data flows — where is it stored, logged, transmitted?
+   - Check encryption at rest and in transit
+   - Verify sensitive data is not cached inappropriately
+   - Check for data leakage in error messages or debug output
+
+5. **Dependency Risk**
+   - Cross-reference critical dependencies against known CVE databases
+   - Check for dependencies with known supply-chain risks
+   - Verify integrity checks (lockfile hashes, checksums)
+
+**Output format**: Return findings as a structured list:
+
+### Finding: {title}
+- **Severity estimate**: critical | high | medium | low
+- **Attack vector**: {how this could be exploited}
+- **Evidence**: {specific code paths, file:line references}
+- **Recommendation**: {what to do about it}
+
+If no security issues found, state: "No security issues identified."
+```
+
+### CI/CD Reviewer: Review CI/CD
+
+```
+role: cicd-reviewer
+phase: routine-maintenance
+project: {project-slug}
+action: review-cicd
+
+Perform a focused review of the project's CI/CD pipeline configuration,
+build security, and deployment practices.
+
+Project stack: {project-stack}
+
+Known CI/CD debt from prior debriefs (do not re-flag as new discoveries):
+{known-cicd-debt}
+
+User areas of concern:
+{areas-of-concern}
+
+IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
+You must NEVER modify source files, configuration, dependencies, or any other
+project file.
+
+**Output discipline**: Keep findings concise. Include code excerpts only for
+Critical or High severity findings. Do not paste full file contents or raw
+command output.
+
+**Review areas**:
+
+1. **Pipeline Configuration**
+   - Review pipeline definitions (GitHub Actions, GitLab CI, Concourse, etc.)
+   - Check for outdated action/image versions
+   - Verify branch protection rules are consistent with pipeline triggers
+   - Detect redundant or overlapping pipeline steps
+
+2. **Build Security**
+   - Check for secrets exposed in build logs or artifacts
+   - Verify pipeline secrets are scoped appropriately (not org-wide when repo-level suffices)
+   - Check for unpinned dependencies in build steps (e.g., `uses: action@main` vs `@v4.1.0`)
+   - Review build artifact permissions and retention policies
+
+3. **Deployment Safeguards**
+   - Verify deployment gates exist (approval steps, environment protection rules)
+   - Check rollback capability — is there a documented or automated rollback path?
+   - Verify environment promotion flow (dev → staging → prod) is enforced
+   - Check for drift between environment configurations
+
+4. **Pipeline Health**
+   - Check recent build success rates and durations
+   - Identify flaky pipeline steps
+   - Find disabled or skipped checks that should be active
+   - Check for resource waste (oversized runners, unnecessary matrix builds)
+
+**Output format**: Return findings as a structured list:
+
+### Finding: {title}
+- **Severity estimate**: critical | high | medium | low
+- **Evidence**: {specific config files, pipeline definitions, line references}
+- **Impact**: {what could go wrong}
+- **Recommendation**: {what to do about it}
+
+If no CI/CD issues found, state: "No CI/CD issues identified."
+```
+
+### Accessibility Reviewer: Review Accessibility
+
+```
+role: accessibility-reviewer
+phase: routine-maintenance
+project: {project-slug}
+action: review-accessibility
+
+Perform a focused accessibility review of the project's user-facing UI.
+Evaluate against WCAG 2.1 AA standards.
+
+Project stack: {project-stack}
+
+IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
+You must NEVER modify source files, configuration, dependencies, or any other
+project file.
+
+**Output discipline**: Keep findings concise. Include code excerpts only for
+Critical or High severity findings. Do not paste full file contents or raw
+command output.
+
+**Review areas**:
+
+1. **Semantic HTML & Structure**
+   - Check heading hierarchy (h1-h6 in logical order)
+   - Verify landmark regions (main, nav, aside, footer)
+   - Check form labels and fieldset/legend usage
+   - Verify list markup for list-like content
+
+2. **Keyboard Navigation**
+   - Check all interactive elements are reachable via Tab
+   - Verify custom widgets have appropriate keyboard handlers
+   - Check for keyboard traps (modals, dropdowns)
+   - Verify skip-to-content links exist
+
+3. **Screen Reader Compatibility**
+   - Check ARIA attributes for correctness and necessity
+   - Verify dynamic content updates use live regions
+   - Check image alt text (present, meaningful, not redundant)
+   - Verify form error messages are associated with inputs
+
+4. **Visual & Color**
+   - Check text contrast ratios (4.5:1 normal, 3:1 large text)
+   - Verify UI component contrast (3:1 against background)
+   - Check that color is not the sole indicator of meaning
+   - Verify visible focus indicators on all interactive elements
+
+5. **Motion & Timing**
+   - Check for prefers-reduced-motion support on animations
+   - Verify no auto-playing media without controls
+   - Check for appropriate timeouts with user notification
+
+**Output format**: Return findings as a structured list:
+
+### Finding: {title}
+- **WCAG criterion**: {e.g., 1.1.1 Non-text Content, Level A}
+- **Severity estimate**: critical | high | medium | low
+- **Evidence**: {specific components, file:line references}
+- **Recommendation**: {what to do about it}
+
+If no accessibility issues found, state: "No accessibility issues identified."
+```
+
+### Architect: Assess Findings
+
+```
+role: architect
+phase: routine-maintenance
+project: {project-slug}
+action: assess-findings
+
+Review all specialist findings and assign severity ratings. You have access to:
+- All reviewer findings (provided below)
+- Known debt context from debriefs and prior maintenance reports (if available)
+
+{all-reviewer-findings}
+
+Known debt from debriefs, if available (already acknowledged — note as "previously identified" if re-found):
+{known-debt}
+
+For each finding, assign one of:
+- **Pass** — No issue (reviewer flagged something that is actually fine)
+- **Advisory** — Minor issue, acceptable to defer
+- **Action Required** — Should be addressed before next major work cycle
+- **Critical** — Blocks further work, immediate attention needed
+
+**Assessment criteria**:
+- Does this finding represent a real risk, or is it noise?
+- Is the severity proportional to the actual impact?
+- Would this compound if left for another cycle?
+- Is this a new discovery or previously acknowledged debt?
+- Do multiple reviewers corroborate the same issue?
+- Are any reviewer assessments questionable — too alarmist or too dismissive?
+
+**Challenge reviewers** where you disagree or need clarification. For each
+challenge, name the reviewer and provide your specific question or objection.
+This initiates the roundtable discussion.
+
+**Output format**:
+
+## Overall Assessment
+{Flight Ready | Maintenance Required}
+
+## Findings
+
+| # | Source | Category | Finding | Initial Severity | New/Known | Notes |
+|---|--------|----------|---------|-----------------|-----------|-------|
+| 1 | {reviewer} | {cat} | {title} | {severity} | {new/known} | {brief note} |
+
+## Challenges for Roundtable
+
+### To {Reviewer Name}: {question or objection}
+{Context for why you're challenging this finding — what seems off, what
+additional evidence would change your assessment, or why you think the
+severity should be different.}
+
+## Severity Summary
+- Critical: {N}
+- Action Required: {N}
+- Advisory: {N}
+- Pass: {N}
+
+## Recommended Maintenance Scope
+(Only if Maintenance Required)
+
+Group related Action Required and Critical findings into suggested flight scopes:
+
+### Flight: {suggested title}
+- Finding #{N}: {title}
+- Finding #{N}: {title}
+- Rationale: {why these group together}
+```
+
+### Reviewer: Roundtable Rebuttal
+
+```
+role: {reviewer-role}
+phase: routine-maintenance
+project: {project-slug}
+action: roundtable-rebuttal
+
+The Architect has challenged one or more of your findings during the
+severity assessment roundtable. Respond to each challenge with evidence.
+
+Architect's challenges:
+{architect-challenges}
+
+For each challenge:
+1. **Provide additional evidence** — code paths, specific examples, tool output
+   that supports your finding
+2. **Concede if appropriate** — if the Architect raises a valid point, adjust
+   your assessment rather than defending a weak position
+3. **Clarify misunderstandings** — if the Architect misread your finding,
+   restate it with more precision
+
+Be direct and evidence-based. The goal is consensus, not debate for its own sake.
+
+**Output format**:
+
+### Re: {Architect's challenge title}
+- **Response**: {concur | rebut | clarify}
+- **Evidence**: {additional code paths, line references, tool output}
+- **Revised assessment** (if changed): {updated severity or recommendation}
+```
+
+### Architect: Roundtable Resolution
+
+```
+role: architect
+phase: routine-maintenance
+project: {project-slug}
+action: roundtable-resolution
+
+Review the roundtable responses from specialist reviewers and produce your
+final assessment.
+
+Reviewer responses:
+{roundtable-responses}
+
+For each challenged finding:
+1. **Weigh the evidence** — did the reviewer provide convincing support?
+2. **Assign final severity** — this is your call, but account for reviewer expertise
+3. **Note reasoning** — briefly explain why you maintained or changed severity
+
+If any disagreements remain unresolved, flag them for human review rather than
+forcing consensus.
+
+**Output format**:
+
+## Roundtable Resolution
+
+### Finding #{N}: {title}
+- **Original severity**: {severity}
+- **Reviewer response**: {concur | rebut | clarify} — {summary}
+- **Final severity**: {severity}
+- **Reasoning**: {why}
+
+## Updated Overall Assessment
+{Flight Ready | Maintenance Required}
+
+## Updated Severity Summary
+- Critical: {N}
+- Action Required: {N}
+- Advisory: {N}
+- Pass: {N}
+
+## Unresolved Disagreements (if any)
+{Finding and both perspectives — for human to decide}
+
+## Updated Recommended Maintenance Scope
+(Only if Maintenance Required — incorporate roundtable outcomes)
+
+### Flight: {suggested title}
+- Finding #{N}: {title}
+- Finding #{N}: {title}
+- Rationale: {why these group together}
+```

container/mission-control/.claude/skills/init-project/migrations.md

@@ -0,0 +1,104 @@
+# Init-Project Migrations
+
+When `/init-project` runs, it checks for legacy directory layouts from earlier versions of Flight Control and offers to migrate them. Migrations are idempotent — they only apply when the old layout is detected and the new layout doesn't yet exist.
+
+## Migration Registry
+
+### 001 — Rename `.flight-ops/` to `.flightops/`
+
+Early versions of Flight Control used `.flight-ops/` (with a hyphen). The current convention is `.flightops/` (no hyphen).
+
+**Detection** (returns true if migration is needed):
+
+```bash
+[[ -d "{target-project}/.flight-ops" && ! -d "{target-project}/.flightops" ]]
+```
+
+**Actions:**
+
+1. Rename the directory:
+   ```bash
+   mv "{target-project}/.flight-ops" "{target-project}/.flightops"
+   ```
+2. Update `.gitignore` if it references the old name:
+   ```bash
+   sed -i 's/\.flight-ops/\.flightops/g' "{target-project}/.gitignore"
+   ```
+
+**User message:**
+> Renaming `.flight-ops/` → `.flightops/` (updated naming convention)
+
+---
+
+### 002 — Rename `phases/` to `agent-crews/`
+
+Early versions stored crew definitions in `.flightops/phases/`. The current convention is `.flightops/agent-crews/`.
+
+**Detection** (returns true if migration is needed):
+
+```bash
+[[ -d "{target-project}/.flightops/phases" && ! -d "{target-project}/.flightops/agent-crews" ]]
+```
+
+> **Note:** This runs after migration 001, so it checks the post-rename `.flightops/` path.
+
+**Actions:**
+
+1. Rename the subdirectory:
+   ```bash
+   mv "{target-project}/.flightops/phases" "{target-project}/.flightops/agent-crews"
+   ```
+
+**User message:**
+> Renaming `phases/` → `agent-crews/` (updated naming convention)
+
+---
+
+### 003 — Update lifecycle states to unified model
+
+Flight Control now uses a unified lifecycle for both flights and legs: `planning → ready → in-flight → landed → completed` (or `aborted`). This replaces the old divergent states:
+
+- **Flights**: `diverted` → `aborted`; added `completed` after `landed`
+- **Legs**: `queued` → `planning`; `review` → `landed`; `blocked` → `aborted`; added `ready` and `completed`
+
+**Detection** (returns true if migration is needed):
+
+```bash
+grep -rql 'queued\|diverted\|blocked\|review.*completed' "{target-project}/.flightops/ARTIFACTS.md" 2>/dev/null
+```
+
+> **Note:** This runs after migrations 001 and 002, so it checks the post-rename `.flightops/` path.
+
+**Actions:**
+
+1. Update state definitions in ARTIFACTS.md:
+   - Replace flight status line: `planning | ready | in-flight | landed | diverted` → `planning | ready | in-flight | landed | completed | aborted`
+   - Replace leg status line: `queued | in-flight | review | completed | blocked` → `planning | ready | in-flight | landed | completed | aborted`
+   - Replace flight state tracking: `planning` → `ready` → `in-flight` → `landed` (or `diverted`) → `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+   - Replace leg state tracking: `queued` → `in-flight` → `review` → `completed` (or `blocked`) → `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+   - Replace `landed | diverted` → `landed | aborted` in debrief templates
+   - Replace `landed/diverted` → `landed/aborted` in debrief templates
+   - Replace `completed | in-flight | blocked` → `completed | landed | in-flight | aborted` in flight log templates
+
+2. Update existing artifact files in the project (if any):
+   - In flight artifacts: replace `**Status**: diverted` → `**Status**: aborted`
+   - In leg artifacts: replace `**Status**: queued` → `**Status**: planning`, `**Status**: review` → `**Status**: landed`, `**Status**: blocked` → `**Status**: aborted`
+   - In flight log entries: replace `**Status**: blocked` → `**Status**: aborted`
+
+   Find artifacts using the locations defined in ARTIFACTS.md (typically `missions/` directory for file-based projects).
+
+**User message:**
+> Updating lifecycle states to unified model: flights and legs now share `planning → ready → in-flight → landed → completed (or aborted)`
+
+---
+
+## Adding Future Migrations
+
+To add a new migration:
+
+1. Assign the next sequential ID (e.g., `003`)
+2. Write a **Detection** check that returns true only when the migration is needed and false if already applied (idempotent)
+3. List the **Actions** to perform — prefer `mv` over copy-and-delete to preserve file contents and git history
+4. Write a short **User message** shown during the migration summary
+5. Consider ordering — if the migration depends on a previous one having run, note that in the detection section
+6. Keep migrations non-destructive: rename and update references, never delete user content

container/mission-control/.claude/skills/init-project/templates/ARTIFACTS-files.md

@@ -0,0 +1,575 @@
+# Artifact System: Filesystem
+
+This project stores Flight Control artifacts as markdown files in the repository.
+
+## Directory Structure
+
+```
+{project}/
+├── missions/
+│   └── {NN}-{mission-slug}/
+│       ├── mission.md
+│       ├── mission-debrief.md
+│       └── flights/
+│           └── {NN}-{flight-slug}/
+│               ├── flight.md
+│               ├── flight-log.md
+│               ├── flight-briefing.md
+│               ├── flight-debrief.md
+│               └── legs/
+│                   └── {NN}-{leg-slug}.md
+└── maintenance/
+    └── {YYYY-MM-DD}.md
+```
+
+## Naming Conventions
+
+- **Slugs**: Lowercase, kebab-case, derived from title (e.g., "User Authentication" → `user-authentication`)
+- **Sequence numbers**: Missions, flights, and legs use two-digit prefixes (`01`, `02`, etc.) for ordering
+
+---
+
+## Core Artifacts
+
+### Mission
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{NN}-{slug}/mission.md` |
+| Created | During mission planning |
+| Updated | Until status changes to `active` |
+
+**Format:**
+
+```markdown
+# Mission: {Title}
+
+**Status**: planning | active | completed | aborted
+
+## Outcome
+What success looks like in human terms.
+
+## Context
+Why this mission matters now. Background information.
+
+## Success Criteria
+- [ ] Criterion 1 (observable, binary)
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Stakeholders
+Who cares about this outcome and why.
+
+## Constraints
+Non-negotiable boundaries.
+
+## Environment Requirements
+- Development environment (devcontainer, local toolchain, cloud IDE)
+- Runtime requirements (GUI, audio hardware, network access)
+- Special tooling (Docker, specific CLI versions)
+
+## Open Questions
+Unknowns that need resolution during execution.
+
+## Known Issues
+Emergent blockers and issues discovered during execution. Add items here as flights surface problems that affect the broader mission — things not anticipated during planning but visible at the mission level.
+
+- [ ] {Issue description} — discovered in Flight {N}, affects {scope}
+
+## Flights
+
+> **Note:** These are tentative suggestions, not commitments. Flights are planned and created one at a time as work progresses. This list will evolve based on discoveries during implementation.
+
+- [ ] Flight 1: {description}
+- [ ] Flight 2: {description}
+- [ ] Flight N *(optional)*: Alignment — vibe coding session for creative collaboration and hands-on adjustments
+```
+
+---
+
+### Flight
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{mission}/flights/{NN}-{slug}/flight.md` |
+| Created | During flight planning |
+| Updated | Until status changes to `in-flight` |
+
+**Format:**
+
+```markdown
+# Flight: {Title}
+
+**Status**: planning | ready | in-flight | landed | completed | aborted
+**Mission**: [{Mission Title}](../../mission.md)
+
+## Contributing to Criteria
+- [ ] {Relevant success criterion 1}
+- [ ] {Relevant success criterion 2}
+
+---
+
+## Pre-Flight
+
+### Objective
+What this flight accomplishes (one paragraph).
+
+### Open Questions
+- [ ] Question needing resolution
+- [x] Resolved question → see Design Decisions
+
+### Design Decisions
+
+**{Decision Title}**: {Choice made}
+- Rationale: Why this choice
+- Trade-off: What we're giving up
+
+### Prerequisites
+- [ ] {What must be true before execution}
+
+### Pre-Flight Checklist
+- [ ] All open questions resolved
+- [ ] Design decisions documented
+- [ ] Prerequisites verified
+- [ ] Validation approach defined
+- [ ] Legs defined
+
+---
+
+## In-Flight
+
+### Technical Approach
+How the objective will be achieved.
+
+### Checkpoints
+- [ ] {Milestone 1}
+- [ ] {Milestone 2}
+
+### Adaptation Criteria
+
+**Divert if**:
+- {Condition requiring re-planning}
+
+**Acceptable variations**:
+- {Minor changes that don't require diversion}
+
+### Legs
+
+> **Note:** These are tentative suggestions, not commitments. Legs are planned and created one at a time as the flight progresses. This list will evolve based on discoveries during implementation.
+
+- [ ] `{leg-slug}` - {Brief description}
+- [ ] `{leg-slug}` - {Brief description}
+- [ ] `uat-and-alignment` *(optional)* - Guided UAT session with iterative fixes
+
+---
+
+## Post-Flight
+
+### Completion Checklist
+- [ ] All legs completed
+- [ ] Code merged
+- [ ] Tests passing
+- [ ] Documentation updated
+
+### Verification
+How to confirm the flight achieved its objective.
+```
+
+---
+
+### Leg
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{mission}/flights/{flight}/legs/{NN}-{slug}.md` |
+| Created | Before leg execution |
+| Updated | Never once `in-flight` (immutable) |
+
+**Format:**
+
+```markdown
+# Leg: {slug}
+
+**Status**: planning | ready | in-flight | landed | completed | aborted
+**Flight**: [{Flight Title}](../flight.md)
+
+## Objective
+Single sentence: what this leg accomplishes.
+
+## Context
+- Relevant design decisions from the flight
+- How this fits into the broader technical approach
+- Key learnings from prior legs (from flight log)
+
+## Inputs
+What exists before this leg runs:
+- Files that must exist
+- State that must be true
+
+## Outputs
+What exists after this leg completes:
+- Files created or modified
+- State changes
+
+## Acceptance Criteria
+- [ ] Criterion 1 (specific, observable)
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Verification Steps
+How to confirm each criterion is met:
+- {Command or manual check for criterion 1}
+- {Command or manual check for criterion 2}
+
+## Implementation Guidance
+
+1. **{First step}**
+   - Details about what to do
+
+2. **{Second step}**
+   - Details
+
+## Edge Cases
+- **{Edge case 1}**: How to handle
+
+## Files Affected
+- `path/to/file.ext` - {What changes}
+
+---
+
+## Post-Completion Checklist
+
+**Complete ALL steps before signaling `[COMPLETE:leg]`:**
+
+- [ ] All acceptance criteria verified
+- [ ] Tests passing
+- [ ] Update flight-log.md with leg progress entry
+- [ ] Set this leg's status to `completed` (in this file's header)
+- [ ] Check off this leg in flight.md
+- [ ] If final leg of flight:
+  - [ ] Update flight.md status to `landed`
+  - [ ] Check off flight in mission.md
+- [ ] Commit all changes together (code + artifacts)
+```
+
+---
+
+## Supporting Artifacts
+
+### Flight Log
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{mission}/flights/{flight}/flight-log.md` |
+| Created | When flight is created |
+| Updated | Continuously during execution (append-only) |
+
+**Format:**
+
+```markdown
+# Flight Log: {Flight Title}
+
+**Flight**: [{Flight Title}](flight.md)
+
+## Summary
+Brief overview of execution status and key outcomes.
+
+---
+
+## Leg Progress
+
+### {Leg Name}
+**Status**: completed | landed | in-flight | aborted
+**Started**: {timestamp}
+**Completed**: {timestamp}
+
+#### Changes Made
+- {Summary of what was implemented}
+
+#### Notes
+{Observations during execution}
+
+---
+
+## Decisions
+Runtime decisions not in original plan.
+
+### {Decision Title}
+**Context**: Why needed
+**Decision**: What was chosen
+**Impact**: Effect on flight or future legs
+
+---
+
+## Deviations
+Departures from planned approach.
+
+### {Deviation Title}
+**Planned**: What the flight specified
+**Actual**: What was done instead
+**Reason**: Why the deviation was necessary
+
+---
+
+## Anomalies
+Unexpected issues encountered.
+
+### {Anomaly Title}
+**Observed**: What happened
+**Severity**: blocking | degraded | cosmetic
+**Resolution**: How handled or "unresolved"
+
+---
+
+## Session Notes
+Chronological notes from work sessions.
+```
+
+---
+
+### Flight Briefing
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{mission}/flights/{flight}/flight-briefing.md` |
+| Created | Before flight execution begins |
+| Purpose | Pre-flight summary for crew alignment |
+
+**Format:**
+
+```markdown
+# Flight Briefing: {Flight Title}
+
+**Date**: {briefing date}
+**Flight**: [{Flight Title}](flight.md)
+**Status**: Flight is ready for execution
+
+## Mission Context
+{Brief reminder of mission outcome and how this flight contributes}
+
+## Objective
+{What this flight will accomplish}
+
+## Key Decisions
+{Summary of critical design decisions crew should know}
+
+## Risks and Mitigations
+| Risk | Mitigation |
+|------|------------|
+| {risk} | {mitigation} |
+
+## Legs Overview
+1. `{leg-slug}` - {description} - {estimated complexity}
+2. `{leg-slug}` - {description} - {estimated complexity}
+
+## Environment Requirements
+{Any special setup needed before starting}
+
+## Success Criteria
+{How we'll know the flight succeeded}
+```
+
+---
+
+### Flight Debrief
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{mission}/flights/{flight}/flight-debrief.md` |
+| Created | After flight lands or diverts |
+| Purpose | Post-flight analysis and lessons learned |
+
+**Format:**
+
+```markdown
+# Flight Debrief: {Flight Title}
+
+**Date**: {debrief date}
+**Flight**: [{Flight Title}](flight.md)
+**Status**: {landed | aborted}
+**Duration**: {start} - {end}
+**Legs Completed**: {X of Y}
+
+## Outcome Assessment
+
+### Objectives Achieved
+{What the flight accomplished}
+
+### Mission Criteria Advanced
+{Which success criteria this flight contributed to}
+
+## What Went Well
+{Specific things that worked effectively}
+
+## What Could Be Improved
+
+### Process
+- {Recommendations for flight execution}
+
+### Technical
+- {Code quality, architecture, debt}
+
+### Documentation
+- {Gaps identified}
+
+## Deviations and Lessons Learned
+
+| Deviation | Reason | Standardize? |
+|-----------|--------|--------------|
+| {what changed} | {why} | {yes/no} |
+
+## Key Learnings
+{Insights for future flights}
+
+## Recommendations
+1. {Most impactful recommendation}
+2. {Second recommendation}
+3. {Third recommendation}
+
+## Action Items
+- [ ] {Immediate actions}
+- [ ] {Near-term improvements}
+```
+
+---
+
+### Mission Debrief
+
+| Property | Value |
+|----------|-------|
+| Location | `missions/{NN}-{mission}/mission-debrief.md` |
+| Created | After mission completes or aborts |
+| Purpose | Post-mission retrospective and methodology improvements |
+
+**Format:**
+
+```markdown
+# Mission Debrief: {Mission Title}
+
+**Date**: {debrief date}
+**Mission**: [{Mission Title}](mission.md)
+**Status**: {completed | aborted}
+**Duration**: {start} - {end}
+**Flights Completed**: {X of Y}
+
+## Outcome Assessment
+
+### Success Criteria Results
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| {criterion} | {met/not met} | {notes} |
+
+### Overall Outcome
+{Did we achieve what we set out to do?}
+
+## Flight Summary
+| Flight | Status | Key Outcome |
+|--------|--------|-------------|
+| {flight} | {landed/aborted} | {outcome} |
+
+## What Went Well
+{Effective patterns and successes}
+
+## What Could Be Improved
+{Process, planning, execution improvements}
+
+## Lessons Learned
+{Insights to carry forward}
+
+## Methodology Feedback
+{Improvements to Flight Control process itself}
+
+## Action Items
+- [ ] {Follow-up work}
+- [ ] {Process improvements}
+```
+
+---
+
+### Maintenance Report
+
+| Property | Value |
+|----------|-------|
+| Location | `maintenance/{YYYY-MM-DD}.md` |
+| Created | After a mission or ad-hoc, during routine maintenance |
+| Purpose | Codebase health assessment and maintenance recommendation |
+
+**Format:**
+
+```markdown
+# Maintenance Report: {YYYY-MM-DD}
+
+**Date**: {report date}
+**Triggered by**: [{Mission Title}](missions/{NN}-{slug}/mission.md) *(optional — omit if ad-hoc)*
+**Assessment**: {Flight Ready | Maintenance Required}
+
+## Categories Inspected
+{Numbered list of categories that were checked}
+
+## Executive Summary
+{2-3 sentence overview of codebase health and key findings}
+
+## Findings by Category
+
+### Category {N}: {Name}
+
+| # | Finding | Severity | New/Known | Recommendation |
+|---|---------|----------|-----------|----------------|
+| {n} | {title} | {severity} | {new/known} | {recommendation} |
+
+**Details:**
+{Per-finding evidence with file paths and line numbers}
+
+## Severity Summary
+
+| Severity | Count |
+|----------|-------|
+| Critical | {N} |
+| Action Required | {N} |
+| Advisory | {N} |
+| Pass | {N} |
+
+## Known Debt Carried Forward
+{Debt items from debriefs that were acknowledged but not addressed, or "None — no prior debt context"}
+
+## Recommendations
+1. {Most impactful recommendation}
+2. {Second recommendation}
+3. {Third recommendation}
+
+## Maintenance Mission
+{Link to scaffolded mission if created, or "Not required — codebase is flight ready"}
+```
+
+---
+
+## State Tracking
+
+States are tracked in the frontmatter or status field of each artifact:
+
+| Artifact | States |
+|----------|--------|
+| Mission | `planning` → `active` → `completed` (or `aborted`) |
+| Flight | `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`) |
+| Leg | `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`) |
+
+## Conventions
+
+- **Immutability**: Never modify legs once `in-flight`; create new ones instead
+- **Append-only logs**: Flight logs are append-only during execution
+- **Flight briefings**: Created before execution, not modified after
+- **Debriefs**: Created after completion, may be updated with follow-up notes
+- **Mission as briefing**: The mission.md document serves as both definition and briefing (no separate mission-briefing.md)
+
+## Git Workflow
+
+| Property | Value |
+|----------|-------|
+| Strategy | `branch` |
+
+**Options:**
+
+- **`branch`** (default) — Single-checkout workflow. The orchestrator creates a feature branch and all agents work in the project root. One flight at a time per working copy.
+- **`worktree`** — Worktree isolation. The orchestrator creates a git worktree under `.worktrees/` for each flight. Agents work in the worktree path. Parallel flights are possible on a single repo clone.
+
+When using the `worktree` strategy, add `.worktrees/` to `.gitignore`.

container/mission-control/.claude/skills/init-project/templates/ARTIFACTS-jira.md

@@ -0,0 +1,408 @@
+# Artifact System: Jira
+
+This project stores Flight Control artifacts as Jira issues.
+
+## Issue Type Mapping
+
+| Flight Control | Jira Issue Type | Hierarchy |
+|----------------|-----------------|-----------|
+| Mission | Epic | Parent |
+| Flight | Story | Child of Epic |
+| Leg | Sub-task | Child of Story |
+
+## Setup Questions
+
+Answer these questions when configuring Jira artifacts for your project:
+
+| Question | Answer |
+|----------|--------|
+| What is the Jira project key? | `PROJECT` |
+| JQL query for discovering flight documentation? | (e.g., `project = PROJECT AND labels = flight-control`) |
+
+## Configuration
+
+| Property | Value |
+|----------|-------|
+| Project Key | `PROJECT` |
+| Board | (specify board name or ID) |
+| Labels | `flight-control` |
+
+---
+
+## Custom Fields
+
+<!-- Add your project's custom Jira fields here -->
+
+| Custom Field | Jira Field ID | Required | Used For | Notes |
+|--------------|---------------|----------|----------|-------|
+| (example) Team | `customfield_10001` | Yes | All issues | Select from predefined teams |
+| (example) Sprint | `customfield_10002` | No | Stories, Sub-tasks | Assign to sprint |
+
+## Project Rules
+
+<!-- Document project-specific Jira rules and conventions here -->
+
+### Required Fields by Issue Type
+
+**Epic (Mission):**
+- (list required fields for your project)
+
+**Story (Flight):**
+- (list required fields for your project)
+
+**Sub-task (Leg):**
+- (list required fields for your project)
+
+### Workflow Rules
+
+- (document any workflow restrictions or automation rules)
+- (e.g., "Stories cannot move to In Progress without Epic Link")
+
+### Naming Conventions
+
+- (document any naming patterns required by your project)
+- (e.g., "Epic summaries must start with [MISSION]")
+
+---
+
+## Core Artifacts
+
+### Mission → Epic
+
+| Field | Mapping |
+|-------|---------|
+| Summary | Mission title |
+| Description | See format below |
+| Labels | `flight-control`, `mission` |
+
+**Description Format:**
+
+```
+## Outcome
+{What success looks like in human terms}
+
+## Context
+{Why this mission matters now}
+
+## Success Criteria
+- [ ] {Criterion 1}
+- [ ] {Criterion 2}
+
+## Stakeholders
+{Who cares about this outcome}
+
+## Constraints
+{Non-negotiable boundaries}
+
+## Environment Requirements
+{Development and runtime requirements}
+
+## Open Questions
+{Unknowns needing resolution}
+
+## Known Issues
+Emergent blockers and issues discovered during execution. Add items here as flights surface problems that affect the broader mission — things not anticipated during planning but visible at the mission level.
+
+- [ ] {Issue description} — discovered in Flight {N}, affects {scope}
+
+## Flights
+> **Note:** These are tentative suggestions, not commitments. Flights are planned and created one at a time as work progresses. This list will evolve based on discoveries during implementation.
+
+- [ ] Flight 1: {description}
+```
+
+---
+
+### Flight → Story
+
+| Field | Mapping |
+|-------|---------|
+| Summary | Flight title |
+| Description | See format below |
+| Epic Link | Parent mission epic |
+| Labels | `flight-control`, `flight` |
+
+**Description Format:**
+
+```
+## Objective
+{What this flight accomplishes}
+
+## Contributing to Criteria
+- {Relevant success criterion 1}
+- {Relevant success criterion 2}
+
+## Design Decisions
+{Key technical decisions and rationale}
+
+## Prerequisites
+- [ ] {What must be true before execution}
+
+## Technical Approach
+{How the objective will be achieved}
+
+## Legs
+> **Note:** These are tentative suggestions, not commitments. Legs are planned and created one at a time as the flight progresses. This list will evolve based on discoveries during implementation.
+
+- [ ] {leg-slug} - {description}
+
+## Validation Approach
+{How will this flight be validated? Manual testing, automated tests, or both?}
+
+## Verification
+{How to confirm success}
+```
+
+---
+
+### Leg → Sub-task
+
+| Field | Mapping |
+|-------|---------|
+| Summary | Leg title |
+| Description | See format below |
+| Parent | Flight story |
+| Labels | `flight-control`, `leg` |
+
+**Description Format:**
+
+```
+## Objective
+{Single sentence: what this leg accomplishes}
+
+## Context
+{Design decisions and learnings from prior legs}
+
+## Inputs
+{What must exist before this leg runs}
+
+## Outputs
+{What exists after completion}
+
+## Acceptance Criteria
+- [ ] {Criterion 1}
+- [ ] {Criterion 2}
+
+## Verification Steps
+How to confirm each criterion is met:
+- {Command or manual check for criterion 1}
+- {Command or manual check for criterion 2}
+
+## Implementation Guidance
+{Step-by-step guidance}
+
+## Files Affected
+{List of files to modify}
+```
+
+---
+
+## Supporting Artifacts
+
+### Flight Log → Story Comments
+
+| Property | Value |
+|----------|-------|
+| Location | Comments on the Flight (Story) |
+| Format | Timestamped comments with prefix |
+| Update pattern | Append new comments during execution |
+
+**Comment Format:**
+
+```
+[Flight Log] {YYYY-MM-DD HH:MM}
+
+## {Entry Type}: {Title}
+
+{Content based on entry type - see below}
+```
+
+**Entry Types:**
+
+- `Leg Progress` - Status updates for leg completion
+- `Decision` - Runtime decisions not in original plan
+- `Deviation` - Departures from planned approach
+- `Anomaly` - Unexpected issues encountered
+- `Session Notes` - General progress notes
+
+---
+
+### Flight Briefing → Story Comment
+
+| Property | Value |
+|----------|-------|
+| Location | Comment on the Flight (Story) |
+| Created | Before flight execution begins |
+| Label | `[Flight Briefing]` |
+
+**Comment Format:**
+
+```
+[Flight Briefing] {YYYY-MM-DD}
+
+## Mission Context
+{How this flight contributes to mission}
+
+## Objective
+{What this flight will accomplish}
+
+## Key Decisions
+{Critical decisions crew should know}
+
+## Risks
+| Risk | Mitigation |
+|------|------------|
+| {risk} | {mitigation} |
+
+## Legs Overview
+1. {leg} - {description}
+2. {leg} - {description}
+
+## Success Criteria
+{How we'll know the flight succeeded}
+```
+
+---
+
+### Flight Debrief → Story Comment
+
+| Property | Value |
+|----------|-------|
+| Location | Comment on the Flight (Story) |
+| Created | After flight lands or diverts |
+| Label | `[Flight Debrief]` |
+
+**Comment Format:**
+
+```
+[Flight Debrief] {YYYY-MM-DD}
+
+**Status**: {landed | aborted}
+**Duration**: {start} - {end}
+**Legs Completed**: {X of Y}
+
+## Outcome Assessment
+{What the flight accomplished}
+
+## What Went Well
+{Effective patterns}
+
+## What Could Be Improved
+{Recommendations}
+
+## Deviations
+| Deviation | Reason | Standardize? |
+|-----------|--------|--------------|
+| {what} | {why} | {yes/no} |
+
+## Key Learnings
+{Insights for future flights}
+
+## Recommendations
+1. {Most impactful recommendation}
+2. {Second recommendation}
+3. {Third recommendation}
+
+## Action Items
+- [ ] {action}
+```
+
+---
+
+### Mission Debrief → Epic Comment
+
+| Property | Value |
+|----------|-------|
+| Location | Comment on the Mission (Epic) |
+| Created | After mission completes or aborts |
+| Label | `[Mission Debrief]` |
+
+**Comment Format:**
+
+```
+[Mission Debrief] {YYYY-MM-DD}
+
+**Status**: {completed | aborted}
+**Duration**: {start} - {end}
+**Flights Completed**: {X of Y}
+
+## Success Criteria Results
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| {criterion} | {met/not met} | {notes} |
+
+## Flight Summary
+| Flight | Status | Outcome |
+|--------|--------|---------|
+| {flight} | {status} | {outcome} |
+
+## What Went Well
+{Successes}
+
+## What Could Be Improved
+{Improvements}
+
+## Lessons Learned
+{Insights}
+
+## Action Items
+- [ ] {action}
+```
+
+---
+
+## State Mapping
+
+### Mission (Epic)
+
+| Flight Control | Jira Status |
+|----------------|-------------|
+| planning | To Do |
+| active | In Progress |
+| completed | Done |
+| aborted | Cancelled |
+
+### Flight (Story)
+
+| Flight Control | Jira Status |
+|----------------|-------------|
+| planning | To Do |
+| ready | Ready |
+| in-flight | In Progress |
+| landed | In Review |
+| completed | Done |
+| aborted | Cancelled |
+
+### Leg (Sub-task)
+
+| Flight Control | Jira Status |
+|----------------|-------------|
+| planning | To Do |
+| ready | Ready |
+| in-flight | In Progress |
+| landed | In Review |
+| completed | Done |
+| aborted | Cancelled |
+
+---
+
+## Conventions
+
+- **Naming**: Use clear, action-oriented summaries
+- **Linking**: Always link Stories to Epic, Sub-tasks to Story
+- **Labels**: Apply `flight-control` label to all artifacts
+- **Immutability**: Never modify Sub-tasks once In Progress; create new ones
+- **Comments**: Use prefixes (`[Flight Log]`, `[Flight Briefing]`, etc.) for filtering
+
+## Git Workflow
+
+| Property | Value |
+|----------|-------|
+| Strategy | `branch` |
+
+**Options:**
+
+- **`branch`** (default) — Single-checkout workflow. The orchestrator creates a feature branch and all agents work in the project root. One flight at a time per working copy.
+- **`worktree`** — Worktree isolation. The orchestrator creates a git worktree under `.worktrees/` for each flight. Agents work in the worktree path. Parallel flights are possible on a single repo clone.
+
+When using the `worktree` strategy, add `.worktrees/` to `.gitignore`.

container/mission-control/.claude/skills/leg/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: leg
+description: Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight.
+---
+
+# Leg Implementation Guidance
+
+Generate detailed implementation guidance for LLM execution.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+- A flight must exist before creating legs
+
+## Workflow
+
+### Phase 1: Context Loading
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Read the parent flight**
+   - Understand the objective being achieved
+   - Review design decisions and constraints
+   - Note the technical approach defined
+
+5. **Read the flight log in detail** (critical)
+
+   The flight log captures ground truth from actual implementation. Read it fully and extract:
+   - Actual outcomes from completed legs
+   - Deviations from the original plan
+   - Anomalies discovered during execution
+   - Environment details (versions, configurations)
+   - Decisions made during implementation
+   - Workarounds for issues encountered
+
+6. **Identify this leg's scope**
+   - Which leg from the flight's leg list?
+   - What comes before and after?
+   - Dependencies on other legs?
+   - How do prior leg outcomes affect this leg?
+
+7. **Identify environment constraints**
+   - Execution environment (devcontainer, WSL, cloud)?
+   - User context (root, specific user)?
+   - Environment variables or shell setup needed?
+   - Commands inside vs outside containers?
+
+### Phase 2: Implementation Analysis
+
+Deep dive into the specific implementation:
+
+1. **Identify exact files to modify**
+   - Read existing files that will be changed
+   - Understand current code structure
+   - Note imports, dependencies, patterns
+
+2. **Understand existing patterns**
+   - How is similar functionality implemented?
+   - What conventions does the codebase follow?
+   - What testing patterns are used?
+
+3. **Determine inputs and outputs**
+   - What state exists before this leg?
+   - What state must exist after completion?
+   - What can the implementing agent assume?
+
+4. **Identify edge cases**
+   - What could go wrong?
+   - What validation is needed?
+   - What error handling is required?
+   - If this leg modifies database schemas: does it include migration creation AND execution? Both must happen in the same leg — a schema defined but never migrated is a gap.
+
+5. **Identify dependent code** (for interface changes)
+   - Does this leg modify shared interfaces?
+   - What files consume these interfaces?
+   - Should updating consumers be part of this leg?
+
+6. **Identify platform considerations**
+   - Does this leg touch OS-specific features?
+   - What platform differences might affect implementation?
+
+### Phase 3: Guidance Generation
+
+Create the leg artifact using the format defined in `.flightops/ARTIFACTS.md`.
+
+## Guidelines
+
+### Writing Effective Objectives
+
+State exactly what the leg accomplishes:
+
+**Weak**: "Set up the database stuff"
+
+**Strong**: "Create the User model with email, password_hash, and timestamp fields"
+
+### Acceptance Criteria
+
+Criteria must be:
+- **Binary**: Either met or not met
+- **Observable**: Can be verified by inspection or test
+- **Complete**: Nothing else needed for "done"
+
+**Weak**: "Code is clean" (subjective)
+
+**Strong**: "User model exists in `prisma/schema.prisma`"
+
+### Verification Steps
+
+Tell the agent exactly *how* to confirm each criterion:
+
+**Weak**: "Make sure it works"
+
+**Strong**: 
+```markdown
+## Verification Steps
+- Run `npx prisma migrate status` — should show no pending migrations
+- Run `npm test` — all tests pass
+- Tab through form fields — focus order matches visual order
+```
+
+For accessibility work, include specific checks:
+- Keyboard navigation sequences
+- Screen reader commands to test
+- Automated tool commands (Lighthouse, axe-core)
+
+### Implementation Guidance
+
+Be explicit, not implicit:
+
+**Implicit**: "Add validation to the email field"
+
+**Explicit**: "Add email validation using the `validator` library's `isEmail` function. Return HTTP 400 with `{ "error": "Invalid email format" }` on validation failure."
+
+### Code Examples
+
+Provide examples when:
+- The codebase has specific patterns to follow
+- There are multiple valid approaches
+- The implementation isn't obvious from context
+
+### Leg Sizing
+
+A well-sized leg:
+- Takes minutes to a few hours
+- Is atomic (can be completed independently)
+- Has clear, verifiable acceptance criteria
+- Produces a working increment
+
+**Too small**: Single-line change with no meaningful criteria
+**Too large**: Would benefit from intermediate checkpoints
+
+### Documenting Workarounds
+
+When implementing a workaround, document:
+- **What**: The workaround clearly
+- **Why**: Why the ideal solution wasn't feasible
+- **When to remove**: Condition for replacement
+
+### Immutability
+
+Once a leg is `in-flight`:
+- Do NOT modify the leg document
+- If requirements change, mark it `aborted` (changes rolled back)
+- Create a new leg with updated requirements
+
+## Output
+
+Create the leg artifact using the location and format defined in `.flightops/ARTIFACTS.md`.

container/mission-control/.claude/skills/mission-debrief/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: mission-debrief
+description: Post-mission retrospective for outcomes assessment and methodology improvement. Use after a mission completes or aborts to capture overall lessons learned.
+---
+
+# Mission Debrief
+
+Perform comprehensive post-mission retrospective and methodology assessment.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+- A mission must have at least one completed or aborted flight before debriefing
+
+## Workflow
+
+### Phase 1: Context Loading
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Load mission documentation**
+   - Read the mission for original outcome, success criteria, and constraints
+   - Read ALL flight documents for objectives and results
+   - Read ALL flight debriefs for per-flight lessons learned
+   - Read flight logs for execution details
+
+5. **Load project context**
+   - Read the target project's `README.md` and `CLAUDE.md`
+   - Understand what was built during this mission
+
+### Phase 2: Crew Debrief Interviews
+
+Read `{target-project}/.flightops/agent-crews/mission-debrief.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/mission-debrief.md`).
+
+**Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Phase file `mission-debrief.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
+
+#### Architect Interview
+1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
+   - Provide the "Debrief Interview" prompt from the mission-debrief phase file's Prompts section
+   - The Architect reviews architectural evolution across all flights, pattern consistency, and structural health
+   - The Architect provides structured debrief input
+
+#### Human Interview
+Interview the crew to capture qualitative insights that documents alone cannot reveal.
+
+##### Flight Log Clarifications
+Surface specific observations from flight logs and ask for context:
+- Anomalies or deviations noted in logs — what caused them?
+- Decisions made during execution — what drove those choices?
+- Blockers or delays — were these predictable in hindsight?
+- Workarounds implemented — should these become standard practice?
+
+##### Mission Control Experience
+For the human(s) who served as mission control:
+- "What was your experience coordinating this mission?"
+- "Were there moments of confusion or uncertainty about status?"
+- "Did the flight/leg structure help or hinder your oversight?"
+- "What information was missing when you needed it?"
+
+##### Project-Specific Feedback
+- "What surprised you most during this mission?"
+- "What would you do differently if starting over?"
+- "Are there project-specific conventions that should be documented?"
+- "Did any tools, libraries, or patterns prove particularly valuable or problematic?"
+
+##### Agentic Orchestration Feedback (if applicable)
+If the mission used automated orchestration (LLM agents executing legs):
+- "How well did handoffs between agents work?"
+- "Were there failures in agent coordination or context transfer?"
+- "Did agents make decisions that required human correction?"
+- "What guardrails or checkpoints would have helped?"
+- "Was the level of autonomy appropriate for the tasks?"
+
+**Note**: Adapt questions based on what the flight logs and artifacts reveal. Surface specific examples rather than asking in the abstract.
+
+### Phase 3: Outcome Assessment (synthesize Architect + human input)
+
+#### Success Criteria Evaluation
+For each success criterion:
+- Was it met? Partially met? Not met?
+- What evidence supports this assessment?
+- If not met, what blocked it?
+
+#### Overall Outcome
+- Did the mission achieve its stated outcome?
+- Was the outcome still the right goal by the end?
+- What value was delivered to stakeholders?
+
+### Phase 4: Flight Analysis
+
+#### Flight Summary
+For each flight:
+- Status (landed/completed/aborted)
+- Key accomplishments
+- Major challenges
+
+#### Flight Patterns
+- Which flights went smoothly? Why?
+- Which flights struggled? Why?
+- Were there common issues across flights?
+
+### Phase 5: Process Analysis
+
+#### Planning Effectiveness
+- Was the initial flight plan accurate?
+- How many flights were added/removed/changed?
+- Were estimates reasonable?
+
+#### Execution Patterns
+- What worked well in execution?
+- What friction points emerged?
+- Were the right artifacts being created?
+
+#### Methodology Assessment
+- Did the mission/flight/leg hierarchy work for this project?
+- Were briefings and debriefs valuable?
+- What would you change about the process?
+
+### Phase 6: Knowledge Capture
+
+#### Lessons Learned
+- Technical lessons (architecture, patterns, tools)
+- Process lessons (planning, execution, communication)
+- Domain lessons (business logic, requirements)
+
+#### Reusable Patterns
+- What patterns emerged that could be templated?
+- What conventions should be documented?
+
+#### Documentation Updates
+- Does CLAUDE.md need updates?
+- Does README need updates?
+- Are there new runbooks or guides needed?
+
+### Phase 7: Generate Debrief
+
+Create the mission debrief artifact using the format defined in `.flightops/ARTIFACTS.md`.
+
+### Phase 8: Mission Status Transition
+
+If the mission is not already marked as `completed` or `aborted`, update the mission artifact's status to `completed`.
+
+## Guidelines
+
+### Holistic View
+Look at the mission as a whole, not just individual flights. Identify patterns and systemic issues.
+
+### Stakeholder Perspective
+Frame outcomes in terms stakeholders care about. Did we deliver what was promised?
+
+### Honest Assessment
+Be candid about what didn't work. The debrief is for learning, not for blame.
+
+### Actionable Insights
+Every lesson should have a "so what?" — how should future missions be different?
+
+### Methodology Feedback
+This is the best time to identify improvements to Flight Control itself.
+
+### Interview Integration
+Weave interview insights throughout the debrief, not as a separate section. Crew perspectives should inform:
+- Why certain outcomes were achieved or missed
+- Root causes behind process friction
+- Context that flight logs alone cannot capture
+- Recommendations that reflect lived experience, not just document analysis
+
+## Output
+
+Create the debrief artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
+
+After creating the debrief, summarize:
+1. Overall mission outcome assessment
+2. Top 3 things that went well
+3. Top 3 things to improve
+4. Recommended methodology changes

container/mission-control/.claude/skills/mission/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: mission
+description: Create outcome-driven missions through research and user interview. Use when starting a new project, feature, or initiative that needs planning.
+---
+
+# Mission Creation
+
+Create a new mission through research and collaborative discovery.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+
+## Workflow
+
+### Phase 1: Research
+
+Before asking questions, gather context:
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+   - If not listed, ask the user for details
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Explore the target project's codebase**
+   - Project structure and architecture
+   - Existing patterns and conventions
+   - Related functionality
+
+5. **Read existing documentation**
+   - README and project docs
+   - Any existing missions
+   - Technical specs or design documents
+
+6. **Search external sources if needed**
+   - API documentation
+   - Library documentation
+   - Relevant patterns or best practices
+
+### Phase 2: User Input
+
+Before asking structured questions, share a brief summary of what you learned during research and prompt the user for open-ended input:
+
+- "Here's what I've gathered about the project so far: [summary]. Before I ask specific questions, what are your thoughts on what this mission should include? Feel free to share goals, ideas, concerns, scope preferences — anything that should shape this mission."
+
+Use the user's response to inform and focus the interview questions that follow.
+
+### Phase 3: Interview
+
+Ask about outcomes, not tasks. Focus on:
+
+1. **Desired outcomes**
+   - "What does success look like when this is done?"
+   - "What problem does this solve for users/stakeholders?"
+   - "How will you know this mission succeeded?"
+
+2. **Stakeholders and their needs**
+   - "Who benefits from this outcome?"
+   - "Are there competing interests to balance?"
+   - "Who needs to approve or review?"
+
+3. **Constraints**
+   - "What technical constraints exist?"
+   - "Are there timeline or resource boundaries?"
+   - "What's out of scope?"
+
+4. **Success criteria**
+   - "What specific, observable criteria indicate completion?"
+   - "How will each criterion be verified?"
+   - "Do any criteria name specific tools or technologies? Reframe as capabilities."
+   - "Could each criterion be satisfied by more than one implementation approach?"
+
+5. **Environment requirements**
+   - "What development environment will be used?"
+   - "Are there runtime dependencies?"
+   - "What tooling versions are required?"
+
+### Phase 4: Draft
+
+Create the mission artifact using the format defined in `.flightops/ARTIFACTS.md`.
+
+### Phase 4b: Technical Viability Check
+
+Read `{target-project}/.flightops/agent-crews/mission-design.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/mission-design.md`).
+
+**Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Phase file `mission-design.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
+
+1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
+   - Provide the "Validate Mission" prompt from the mission-design phase file's Prompts section
+   - The Architect reviews the draft mission against the codebase, stack, and constraints
+   - The Architect provides a structured assessment: feasible / feasible with caveats / not feasible
+2. **Incorporate feedback** — update the mission artifact to address issues raised
+   - If not feasible: discuss with user, adjust scope or approach
+   - If feasible with caveats: present caveats to user, adjust if needed
+3. **Human gives final sign-off** before proceeding
+
+### Phase 5: Iterate
+
+Present the draft and iterate:
+
+1. Walk through each section with the user
+2. Validate success criteria are measurable
+3. Screen each criterion for technology names, tool names, config file paths, or specific libraries — reframe any that describe implementation rather than capability
+4. Confirm flight breakdown makes sense
+5. Refine until the user explicitly approves
+
+## Guidelines
+
+### Mission Sizing
+
+A well-sized mission:
+- Takes days to weeks to complete
+- Spawns 5-7 flights typically
+- Represents a meaningful outcome stakeholders recognize
+- Has clear success criteria
+
+**Too small**: Can be completed in a single flight
+**Too large**: Success criteria are vague or numerous (>10)
+
+### Outcome vs. Activity
+
+Frame missions around results, not tasks:
+
+**Activity-focused** (avoid):
+> Implement user authentication
+
+**Outcome-focused** (prefer):
+> Users can securely access their personal data without sharing credentials
+
+This applies equally to success criteria. Criteria that name specific tools or technologies constrain the solution space prematurely — if the prescribed tool doesn't work, the criteria become misaligned with reality.
+
+**Implementation-specific criterion** (avoid):
+> OAuth tokens are stored in Redis with a 24-hour TTL
+
+**Capability-focused criterion** (prefer):
+> Authenticated sessions persist across browser restarts for up to 24 hours
+
+### Alignment Flight
+
+During the interview phase, ask the user whether they'd like to include an alignment flight. Explain that this optional flight is a vibe coding session — the user and agent work together interactively, exploring the codebase, trying ideas, and making hands-on adjustments that benefit from human judgment and real-time feedback. It's a space for creative collaboration rather than structured execution. If the user opts in, include it in the suggested breakdown, marked as optional.
+
+### Adaptive Planning
+
+- Missions can be updated as understanding develops
+- New flights can be added during execution
+- Success criteria can be refined (with stakeholder agreement)
+
+## Output
+
+Create the mission artifact using the location and format defined in `.flightops/ARTIFACTS.md`.

container/mission-control/.claude/skills/preflight-check/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: preflight-check
+description: Verify all registered projects have current methodology files and crew definitions. Reports status and offers to re-initialize projects that need it.
+---
+
+# Preflight Check
+
+Verify all registered projects have current Flight Control methodology files and crew definitions. Reports findings and offers to run `/init-project` on projects that need it.
+
+## When to Use
+
+- After updating methodology files or adding new skills to mission-control
+- After adding new default crew files
+- Periodically, to catch drift across managed projects
+- When onboarding a new team member who may have stale project setups
+
+## Prerequisites
+
+- `projects.md` must exist (run `/init-mission-control` first)
+
+## Workflow
+
+### Phase 1: Load Projects Registry
+
+1. **Read `projects.md`** to get the full list of managed projects
+2. Extract each project's slug, path, and description
+
+### Phase 2: Check Each Project
+
+For each project in the registry:
+
+1. **Verify project path exists** — if the directory doesn't exist on disk, mark as `unreachable` and skip
+2. **Run the sync check**:
+   ```bash
+   bash "${SKILL_DIR}/../init-project/check-sync.sh" \
+     "${SKILL_DIR}/../init-project" \
+     "{project-path}/.flightops"
+   ```
+3. **Parse the output** and classify the project:
+
+| Status | Meaning | Action Needed |
+|--------|---------|---------------|
+| `missing` | No `.flightops/` directory | Needs `/init-project` |
+| `outdated` | Methodology files differ from source | Needs `/init-project` |
+| `current` | Methodology files match | None for methodology |
+| `agent-crews:missing` | No crew directory at all | Needs `/init-project` |
+| `agent-crews:empty` | Crew directory exists but empty | Needs `/init-project` |
+| `crew-missing:{file}` | Specific crew file missing (new skill) | Needs crew file added |
+| `legacy-layout:*` | Old directory naming detected | Needs migration via `/init-project` |
+
+### Phase 3: Report
+
+Present a summary table:
+
+> **Project Sync Status**
+>
+> | Project | Path | Methodology | Crew | Issues |
+> |---------|------|-------------|------|--------|
+> | my-app | ~/projects/my-app | current | 1 missing | `routine-maintenance.md` not found |
+> | api-server | ~/projects/api-server | outdated | current | Methodology files stale |
+> | frontend | ~/projects/frontend | current | current | — |
+>
+> **{N} projects need attention, {M} are current.**
+
+Group issues by type:
+- **Needs full init**: projects with `missing`, `agent-crews:missing`, or legacy layouts
+- **Needs methodology update**: projects with `outdated` status
+- **Needs new crew files**: projects with `crew-missing` entries (list which files)
+- **Unreachable**: projects whose paths don't exist on disk
+
+### Phase 4: Remediate
+
+If any projects need attention:
+
+> "Want me to run `/init-project` on the projects that need it?"
+>
+> Options:
+> - **All** — re-init every project that needs attention
+> - **Select** — choose which projects to update
+> - **Skip** — just take the report, no changes
+
+For each project the user selects:
+
+1. **Run `/init-project`** using the skill workflow (read `.claude/skills/init-project/SKILL.md` and execute)
+   - For projects that only need new crew files: skip straight to Step 6 (Configure Project Crew) — the "If exists (re-run)" path will copy missing crew files from defaults without touching existing ones
+   - For projects that need methodology updates: run the full workflow
+   - For projects with legacy layouts: run from Step 2 (migrations)
+2. **Report result** — confirm what was updated for each project
+
+### Phase 5: Summary
+
+After remediation (or if skipped), output a final status:
+
+> **Sync complete.**
+> - {N} projects checked
+> - {M} projects updated
+> - {K} projects already current
+> - {J} projects unreachable (verify paths in `projects.md`)
+
+## Guidelines
+
+### Non-Destructive
+
+This skill never overwrites customized files without user consent. The underlying `/init-project` workflow:
+- Copies missing crew files from defaults (safe — fills gaps)
+- Asks before updating existing crew files (respects customization)
+- Never overwrites `ARTIFACTS.md` (project-specific)
+
+### Missing Crew Files vs. Drift
+
+These are distinct situations:
+- **Missing crew file**: A new default crew was added to mission-control but the project doesn't have it yet. This is a gap — the file should be copied from defaults.
+- **Crew file drift**: A project's crew file differs from the current default. This is expected — projects customize their crews. Report it as informational but do not flag it as needing remediation.
+
+### Quick and Quiet
+
+If all projects are current, say so in one line and stop. No confirmation prompts needed when there's nothing to do.

container/mission-control/.claude/skills/routine-maintenance/SKILL.md

@@ -0,0 +1,387 @@
+---
+name: routine-maintenance
+description: Codebase health assessment and maintenance recommendation. Use after a mission or ad-hoc to verify codebase is flight-ready or scaffold a maintenance mission.
+---
+
+# Routine Maintenance
+
+Perform an exhaustive, aviation-style codebase inspection. Can be triggered after a mission completes or run ad-hoc at any time. Produces a findings report and optionally scaffolds a maintenance mission for significant issues.
+
+## Prerequisites
+
+- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
+
+## Workflow
+
+### Phase 1: Context Loading
+
+1. **Identify the target project**
+   - Read `projects.md` to find the project's path
+
+2. **Verify project is initialized**
+   - Check if `{target-project}/.flightops/ARTIFACTS.md` exists
+   - **If missing**: STOP and tell the user to run `/init-project` first
+   - Do not proceed without the artifact configuration
+
+3. **Read the artifact configuration**
+   - Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
+
+4. **Load prior maintenance reports (if any exist)**
+   - Read previous reports in `maintenance/` to identify deferred findings from earlier cycles
+   - Deferred findings are those documented in prior reports but not addressed by a maintenance mission
+   - This ensures recurring issues are tracked across cycles rather than re-discovered as "new"
+
+5. **Load mission and debrief documentation (if available)**
+   - If a recent mission exists, read it for outcome, success criteria, and known issues
+   - If a mission debrief exists, read it for lessons learned and action items
+   - If flight debriefs exist, read them for per-flight technical debt and recommendations
+   - This provides known-debt context so the inspection can distinguish new issues from acknowledged ones
+   - If no mission context is available (ad-hoc run), proceed without known-debt context
+
+6. **Identify project stack**
+   - Read `README.md`, `CLAUDE.md`, and package files (`package.json`, `Cargo.toml`, `go.mod`, etc.)
+   - Determine language, framework, test runner, linter, formatter, type checker, and dependency audit tool
+
+### Phase 2: Scoping Interview
+
+Two parts: category enablement and inspection focus.
+
+#### Category Enablement
+
+Categories 1–7 always apply to every project. Ask the user yes/no for optional categories:
+
+> "Before I begin the inspection, a few quick questions:"
+>
+> 1. "Does this project have CI/CD pipelines?" → enables Category 8 + CI/CD Reviewer
+> 2. "Does this project have deployments, databases, or environment-specific configs?" → enables Category 9
+> 3. "Does this project have monitoring, metrics, or observability tooling?" → enables Category 10
+> 4. "Does this project have user-facing UI (web pages, components, forms)?" → enables Accessibility Reviewer
+
+#### Inspection Focus
+
+> 5. "Where should the inspection focus?"
+>    - **Recent changes** — "Since when? (last mission, last flight, specific date, N days)"
+>    - **Specific areas** — "Which modules, directories, or concerns?"
+>    - **Full codebase** — "Everything"
+>
+> "Any specific areas of concern for this project?"
+
+Record all responses. The focus selection and areas of concern drive the delegation plan in Phase 3.
+
+### Phase 3: Delegation Planning
+
+Before spawning any agents, the Flight Director creates an explicit plan for how to partition work across sub-agents. Each sub-agent has its own context window — the delegation plan ensures no single agent is overwhelmed by project scale.
+
+#### 3a: Assess Project Size
+
+Run a quick structural assessment:
+
+1. **Count source files** — `find {target-project} -name "*.{ext}" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l` (use appropriate extensions for the stack)
+2. **Identify module boundaries** — check for workspace configs (`Cargo.toml` workspaces, `package.json` workspaces, `go.work`), top-level directories with independent configs, or monorepo structure
+3. **Classify project size**:
+   - **Small**: < 100 source files
+   - **Medium**: 100–500 source files
+   - **Large**: > 500 source files
+
+#### 3b: Determine Scope
+
+Based on the interview focus selection:
+
+- **Recent changes**: Run `git log` / `git diff` to identify changed files since the user's specified cutoff. Map changed files to their containing modules. The inspection scope is the changed files plus their immediate dependencies (imports, shared types, test files).
+- **Specific areas**: Scope is the user-specified modules/directories. Identify their boundaries and dependencies.
+- **Full codebase**: Scope is everything. For large projects, this triggers module partitioning (see 3c).
+
+#### 3c: Build the Delegation Plan
+
+The plan determines how many agents to spawn, what each one covers, and in what order. Present it to the user for approval before executing.
+
+**Concurrency constraint**: Claude Code supports a default maximum of **4 concurrent sub-agents**. Additional agents are queued automatically and start as running agents complete. The delegation plan must account for this by organizing agents into **waves** of up to 4.
+
+**Sub-agent context constraint**: Each sub-agent starts with a fresh context window containing only its prompt. All sub-agent output returns to the Flight Director's context. Verbose results from multiple agents accumulate and can exhaust the Flight Director's context — this makes output discipline a hard constraint, not a suggestion.
+
+**Delegation rules by scope and size:**
+
+| Scope | Small/Medium Project | Large Project |
+|-------|---------------------|---------------|
+| **Recent changes** | One agent per role, scoped to changed files | Same — changed files are naturally bounded |
+| **Specific areas** | One agent per role, scoped to specified areas | Same — user has already bounded the scope |
+| **Full codebase** | One agent per role, full project | **Partition**: see below |
+
+**Full codebase on large projects — partitioning strategy:**
+
+The Inspector is the most context-hungry role. Partition it:
+
+1. **Tool-pass Inspector**: One agent that runs all automated tools (linters, type checkers, test suite, audit commands) across the full project. Tool output is structured and concise — this agent reads command output, not source code.
+2. **Module Inspectors**: One agent per identified module boundary. Each performs manual code review (dead code, patterns, TODOs, duplication) only within its module. If no clear module boundaries exist, partition by top-level source directories.
+
+Specialist reviewers (Security, CI/CD, Accessibility) are naturally scoped by their domain and generally do not need partitioning. If a specialist reviewer's scope is too broad (e.g., security review of a 1000-file project), scope it to: files flagged by the tool-pass Inspector + files in security-critical paths (auth, API handlers, data access).
+
+**Wave planning**: Assign agents to waves of up to 4 concurrent agents. Prioritize by dependency:
+- **Wave 1**: Tool-pass Inspector + specialist reviewers (Security, CI/CD, Accessibility) — up to 4 agents. The tool pass runs automated commands; specialists do independent manual review. These have no dependencies on each other.
+- **Wave 2** (if partitioned): Module Inspectors — these can optionally use tool-pass findings to focus their manual review, so they benefit from running after Wave 1. Up to 4 module agents per wave.
+
+For small/medium projects or scoped inspections, everything fits in a single wave.
+
+**The delegation plan structure:**
+
+> **Delegation Plan**
+>
+> Scope: {recent changes since X | specific areas: X, Y | full codebase}
+> Project size: {small | medium | large} (~{N} source files)
+> Modules: {list of identified modules, or "flat project"}
+>
+> **Wave 1** (concurrent):
+> | # | Agent | Role | Scope | Strategy |
+> |---|-------|------|-------|----------|
+> | 1 | Inspector (tools) | Run automated tools | Full project | Commands only, no code reads |
+> | 2 | Security Reviewer | Auth & injection review | src/auth/, src/api/handlers/ | Manual code path analysis |
+> | 3 | CI/CD Reviewer | Pipeline review | .github/workflows/ | Config review |
+> | 4 | Accessibility Reviewer | WCAG 2.1 AA review | src/components/ | UI review |
+>
+> **Wave 2** (after Wave 1 completes):
+> | # | Agent | Role | Scope | Strategy |
+> |---|-------|------|-------|----------|
+> | 5 | Inspector (module A) | Manual code review | src/api/ | Categories 4-6 |
+> | 6 | Inspector (module B) | Manual code review | src/core/ | Categories 4-6 |
+>
+> "Here's how I plan to partition the inspection. Want to adjust anything?"
+
+For small/medium projects or scoped inspections, the plan is straightforward (one wave, one agent per role) and can be presented briefly. Only expand the full table for large/full-codebase inspections.
+
+#### 3d: Refinement
+
+This delegation strategy is expected to evolve. After each maintenance run, note in the flight log or maintenance report whether the partitioning was effective:
+- Did any agent hit context limits or return shallow results?
+- Were module boundaries appropriate?
+- Should specialists have been scoped differently?
+
+These observations inform future delegation plans for the same project.
+
+### Phase 4: Specialist Review
+
+Read `{target-project}/.flightops/agent-crews/routine-maintenance.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/routine-maintenance.md`).
+
+**Validate structure**: The crew file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Crew file `routine-maintenance.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
+
+Execute the delegation plan from Phase 3, wave by wave. Spawn all agents within a wave in parallel (up to 4 concurrent). Wait for a wave to complete before starting the next. Every reviewer is strictly **read-only** — they may run test suites, linters, type checkers, and audit commands, but must NEVER modify source files, configuration, or dependencies.
+
+Each agent receives:
+- Its assigned scope from the delegation plan
+- The relevant prompt from the crew file
+- The output discipline rules (see Guidelines)
+
+**Context management**: As each agent completes, summarize its findings before storing them for downstream use. Do not accumulate full raw output from every agent — the Flight Director's context is finite.
+
+#### Inspector
+
+1. **Spawn Inspector agent(s)** per the delegation plan (Agent tool, `subagent_type: "general-purpose"`)
+   - Provide the "Inspect Codebase" prompt from the crew file's Prompts section
+   - Include: applicable category list, project stack info, known debt from debriefs, user's areas of concern, and **scope assignment from the delegation plan**
+   - For partitioned inspections: each Inspector agent receives its module/area scope and only the categories relevant to its assignment
+   - The Inspector performs broad automated checks and returns structured findings per category
+
+#### Security Reviewer
+
+1. **Spawn a Security Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
+   - Provide the "Review Security" prompt from the crew file's Prompts section
+   - Include: project stack info, known security debt from debriefs, and **scope assignment from the delegation plan**
+   - The Security Reviewer performs focused manual analysis of auth flows, injection surfaces, secrets handling, and data exposure — deeper than the Inspector's Category 1 automated checks
+
+#### CI/CD Reviewer (if enabled)
+
+1. **Spawn a CI/CD Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
+   - Provide the "Review CI/CD" prompt from the crew file's Prompts section
+   - Include: project stack info, known CI/CD debt from debriefs
+   - The CI/CD Reviewer evaluates pipeline definitions, build security, deployment safeguards, and environment consistency
+
+#### Accessibility Reviewer (if enabled)
+
+1. **Spawn an Accessibility Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
+   - Provide the "Review Accessibility" prompt from the crew file's Prompts section
+   - The Accessibility Reviewer evaluates against WCAG 2.1 AA standards, semantic HTML, keyboard navigation, screen reader compatibility, and color contrast
+
+#### Merge Partitioned Results
+
+If the Inspector was partitioned into multiple agents, merge their findings into a single consolidated findings list before proceeding to Phase 5. De-duplicate findings that appear in multiple modules.
+
+### Phase 5: Severity Assessment & Roundtable
+
+#### 5a: Initial Assessment
+
+1. **Spawn an Architect agent** (Opus) with all reviewer findings + debrief context (Agent tool, `subagent_type: "general-purpose"`)
+   - Provide the "Assess Findings" prompt from the crew file's Prompts section
+   - Include: all reviewer findings, known debt items (if available from debriefs)
+   - The Architect assigns an initial severity to each finding and raises challenges or questions directed at specific reviewers where findings seem incorrect, overlapping, or missing context
+
+#### 5b: Roundtable
+
+The Architect and specialist reviewers hash out findings through structured discussion. The Flight Director mediates.
+
+1. **Route Architect's challenges** to the relevant reviewers
+   - For each reviewer with outstanding challenges, spawn them with the "Roundtable Rebuttal" prompt from the crew file
+   - Include the Architect's specific challenges directed at that reviewer
+   - Reviewers respond with evidence, rebuttals, or concurrence
+2. **Collect responses** from all challenged reviewers
+3. **Return to Architect** with roundtable responses
+   - Spawn Architect with the "Roundtable Resolution" prompt from the crew file
+   - Include all reviewer rebuttals and new evidence
+   - Architect produces final assessment incorporating the discussion
+4. **Max 2 roundtable cycles** — if consensus isn't reached after 2 rounds, present both perspectives to the human in Phase 6 and let them decide
+
+#### Severity Scale
+
+| Severity | Meaning |
+|----------|---------|
+| **Pass** | No issue found |
+| **Advisory** | Minor issue, deferring is acceptable |
+| **Action Required** | Should be addressed before next major work cycle |
+| **Critical** | Blocks further work, immediate attention needed |
+
+The Architect produces an overall assessment:
+- **Flight Ready** — All findings are Pass or Advisory
+- **Maintenance Required** — Any finding is Action Required or Critical
+
+### Phase 6: Human Review and Scoping
+
+Present findings grouped by severity (Critical first, then Action Required, Advisory, Pass):
+
+> **Overall Assessment: {Flight Ready | Maintenance Required}**
+>
+> {Findings summary table}
+
+Then ask:
+1. "Do these findings match your sense of the codebase health?"
+2. "Any findings to override or adjust severity?"
+
+Apply any overrides the user requests.
+
+#### Scope Selection
+
+If the assessment is Maintenance Required, help the user choose a manageable scope rather than scaffolding everything. Present a recommended shortlist:
+
+> **Recommended scope** (Critical items are always included):
+>
+> {Numbered list of Critical + top Action Required findings, capped at ~5-7 items}
+>
+> {Count} additional Action Required and {count} Advisory findings are documented in the report for a future cycle.
+>
+> "Want me to scaffold a maintenance mission for these items? You can add or remove findings from the list."
+
+The goal is a mission that can land in a single focused session. All findings are captured in the report regardless — deferred items aren't lost, they'll surface again in the next maintenance cycle. This keeps maintenance approachable even when the backlog is large.
+
+### Phase 7: Generate Maintenance Report
+
+Create the maintenance report artifact at the location defined in `.flightops/ARTIFACTS.md` (typically `maintenance/YYYY-MM-DD.md`). If a report already exists for today's date, append a numeric suffix (e.g., `2026-03-26-2.md`).
+
+**Report contents:**
+- Title (date-based) and date
+- Optional "Triggered by" link to the mission that prompted the inspection (if applicable)
+- Inspection scope and delegation plan summary
+- Overall assessment (Flight Ready / Maintenance Required)
+- Categories inspected
+- Executive summary
+- Findings by category (each with severity, description, evidence, recommendation)
+- Severity summary (counts per level)
+- Known debt carried forward (from debriefs, acknowledged but not addressed)
+- Delegation effectiveness notes (for refining future inspections)
+- Recommendations
+
+### Phase 8: Scaffold Maintenance Mission (conditional)
+
+**Only if**: Overall assessment is Maintenance Required AND the user confirmed they want a maintenance mission. Only the findings the user selected in Phase 6 are scaffolded — deferred findings remain in the report for future cycles.
+
+This phase produces the full artifact tree — mission, flights, and legs — so the maintenance work is ready for `/agentic-workflow` execution without running `/mission`, `/flight`, or `/leg` separately.
+
+#### 8a. Mission
+
+Scan existing `missions/` directories to determine the next sequence number `{NN}`. Create `missions/{NN}-maintenance/mission.md` using the standard mission format from `.flightops/ARTIFACTS.md`:
+- **Status**: `planning`
+- **Outcome**: "Resolve codebase health issues identified in maintenance report {YYYY-MM-DD}"
+- **Context**: Link to the maintenance report in `maintenance/{YYYY-MM-DD}.md`
+- **Success Criteria**: One criterion per selected finding
+- **Flights**: List the flights from step 8b
+- Populate all standard mission sections. Mark sections with no relevant content as "N/A" (e.g., Open Questions, Stakeholders).
+
+#### 8b. Flights
+
+Re-group the user's selected findings into flights. Use the Architect's recommended groupings as a starting point, but adjust for any findings the user removed or added during Phase 6 scoping. Typical groupings: one flight per category with actionable findings, or by technical area when findings from different categories affect the same subsystem.
+
+Each flight gets its own directory with `flight.md` and `flight-log.md`. Use the standard formats from `.flightops/ARTIFACTS.md` with these maintenance-specific notes:
+
+- **Status**: `ready` — maintenance flights skip the Pre-Flight phase (no open questions or design decisions to resolve for concrete fixes). Mark Pre-Flight Checklist items as N/A.
+- **Mission**: Link back to the maintenance mission
+- **Objective**: What this group of fixes accomplishes
+- **Technical Approach**: Brief description of the fix strategy per finding
+- **Legs**: List the legs from step 8c
+- Populate all other standard flight sections. Mark sections with no relevant content as "N/A".
+
+The `flight-log.md` is created empty (header only) — it will be populated during execution.
+
+#### 8c. Legs
+
+Each flight gets one leg per discrete fix. Create leg files using the standard format from `.flightops/ARTIFACTS.md` with these fields populated:
+
+- **Status**: `ready`
+- **Flight**: Link back to the flight
+- **Objective**: Fix one specific finding (reference the finding number from the report)
+- **Context**: Link to the maintenance report finding and the Architect's recommendation
+- **Inputs/Outputs**: Files that exist before and after the fix
+- **Acceptance Criteria**: The specific condition that resolves the finding — derived from the Architect's recommendation
+- **Verification Steps**: How to confirm the fix (e.g., "run `npm audit` and confirm no high/critical vulnerabilities", "run `cargo clippy` with no warnings")
+- **Implementation Guidance**: Concrete steps to resolve the finding, based on the Inspector's evidence and the Architect's recommendation
+- **Files Affected**: List files identified in the Inspector's evidence
+- Mark sections with no relevant content as "N/A" (e.g., Edge Cases for straightforward dependency updates).
+
+Keep legs atomic — one finding, one fix. If a finding requires touching many files but is conceptually one change (e.g., "replace all `any` casts"), that's still one leg.
+
+#### 8d. Update Report Backlink
+
+After scaffolding, update the "Maintenance Mission" section at the bottom of the maintenance report (from Phase 7) with a link to the newly created mission.
+
+## Guidelines
+
+### Read-Only Inspection
+
+This skill NEVER modifies source files, configuration, or dependencies in the target project. The Inspector runs checks and reports findings. The only files created are the maintenance report and optionally a full maintenance mission scaffold (mission, flights, and legs) — all are Flight Control artifacts.
+
+### Output Discipline
+
+This is a **hard constraint**, not a suggestion. All sub-agent output returns to the Flight Director's context window. With 4+ reviewers plus roundtable agents, verbose output will exhaust the Flight Director's context and break the workflow.
+
+All reviewer agents must follow these rules:
+
+1. **Summary-first**: Each finding includes a title, severity estimate, file path, and a one-line evidence summary
+2. **Selective detail**: Include code excerpts or extended evidence only for Critical and High severity findings
+3. **No raw dumps**: Never paste full command output, full file contents, or long dependency lists — summarize and reference
+4. **Drill-down on demand**: If the Architect or roundtable needs deeper evidence for a specific finding, the Flight Director spawns a follow-up agent scoped to that single finding
+
+The Flight Director must also enforce this when collecting results — if an agent returns excessively verbose output, summarize it before passing to downstream agents.
+
+### Known Debt Awareness
+
+Cross-reference Inspector findings against known debt from debriefs. Findings that match acknowledged debt should note "previously identified in {debrief}" rather than presenting them as new discoveries. This prevents alarm fatigue.
+
+### Proportional Response
+
+Not every codebase needs a maintenance mission. If the inspection finds only Advisory items, the report should clearly state "Flight Ready" and not push for unnecessary work.
+
+### Honest Assessment
+
+Report what you find, even if the codebase is in great shape. A clean report is valuable — it confirms the team's work quality and builds confidence for the next mission.
+
+### Severity Calibration
+
+- **Critical** is reserved for issues that would cause failures, security vulnerabilities, or data loss
+- **Action Required** means the issue will compound or cause problems if left for another cycle
+- **Advisory** is for genuine improvements that have no urgency
+- **Pass** means the category was inspected and is healthy
+
+## Output
+
+Create the maintenance report artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
+
+After generating the report, summarize:
+1. Overall assessment (Flight Ready or Maintenance Required)
+2. Count of findings by severity
+3. Top recommendations
+4. Whether a maintenance mission was scaffolded (and if so, how many flights and legs)

container/mission-control/.gitignore

@@ -0,0 +1,44 @@
+# Local configuration
+projects.md
+daily-briefings/
+.claude/settings.local.json
+
+# OS files
+.DS_Store
+Thumbs.db
+Desktop.ini
+
+# Editors and IDEs
+*.swp
+*.swo
+*~
+.vscode/
+.idea/
+*.sublime-project
+*.sublime-workspace
+
+# Python
+__pycache__/
+*.py[cod]
+*.egg-info/
+dist/
+build/
+.venv/
+venv/
+env/
+uv.lock
+*.egg
+
+# Node
+node_modules/
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+.pnpm-debug.log*
+
+# Environment and secrets
+.env
+.env.*
+!.env.example
+*.pem
+*.key

container/mission-control/CLAUDE.md

@@ -0,0 +1,100 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Invocation Context
+
+You may be invoked by:
+- **A human** — Interactive session, ask questions freely
+- **An LLM orchestrator** — Run `/agentic-workflow` to drive multi-agent flight execution
+
+When orchestrated, you are the **Flight Director** — responsible for driving execution, coordinating agents, and making go/no-go decisions. Emit signals like `[HANDOFF:review-needed]` and `[COMPLETE:leg]` at appropriate points. The orchestrator monitors your output for these markers.
+
+**When a human says a leg is ready to implement**, invoke `/agentic-workflow`. Do not read the leg spec, do not plan execution steps, do not execute commands directly. You become the orchestrator by loading the skill.
+
+### Loading Skills in Non-Interactive Contexts
+
+**The Skill tool is ONLY available in interactive human sessions.** If you are a spawned agent, running via `claude -p`, or inside a container/SDK — you do NOT have the Skill tool. Do not attempt to call it.
+
+To execute a skill, read its SKILL.md file directly and follow the workflow:
+
+```
+Read .claude/skills/{skill-name}/SKILL.md and execute the workflow described there.
+```
+
+**All Flight Control skills** (listed in the table below) **live in this repository** (mission-control), under `.claude/skills/`. The Flight Director runs from the mission-control directory, so relative `.claude/skills/` paths in skill docs resolve here. Target projects may have their own unrelated skills in their own `.claude/skills/` directories — those are separate.
+
+## First-Contact Check
+
+If `projects.md` does not exist in this repository, suggest running `/init-mission-control` to set up the projects registry before proceeding with any other skills.
+
+## Project Overview
+
+Flight Control is an AI-first software development lifecycle methodology using aviation metaphors. It organizes work into three hierarchical levels:
+
+- **Missions** (human-optimized) — Define outcomes in human terms, days-to-weeks scope
+- **Flights** (balanced) — Technical specifications with pre/in/post-flight checklists, hours-to-days scope
+- **Legs** (AI-optimized) — Structured implementation steps with explicit acceptance criteria, minutes-to-hours scope
+
+This repository contains the methodology documentation and Claude Code skills for interactive planning.
+
+## Claude Code Skills
+
+Eleven skills automate the planning, execution, debrief, and oversight workflow:
+
+| Skill | Purpose |
+|-------|---------|
+| `/init-mission-control` | Onboard to Mission Control (set up `projects.md` registry) |
+| `/init-project` | Initialize a project for Flight Control (creates `.flightops/` directory) |
+| `/mission` | Create outcome-driven missions through research and interview |
+| `/flight` | Create technical flight specs from missions |
+| `/leg` | Generate implementation guidance for LLM execution |
+| `/agentic-workflow` | Drive multi-agent flight execution (design, implement, review, commit) |
+| `/flight-debrief` | Post-flight analysis for continuous improvement |
+| `/mission-debrief` | Post-mission retrospective for outcomes assessment |
+| `/routine-maintenance` | Post-mission codebase health assessment and maintenance recommendation |
+| `/preflight-check` | Verify all projects have current methodology files and crew definitions |
+| `/daily-briefing` | Cross-project status report with health assessment and methodology insights |
+
+Run `/init-project` before using the other skills on a new project to create the flight operations reference directory and configure the artifact system.
+
+**Artifact Systems:** Each project defines how artifacts are stored in `.flightops/ARTIFACTS.md`. Skills read this configuration and adapt their output accordingly.
+
+**IMPORTANT: Planning skills produce documentation only.** `/init-project`, `/mission`, `/flight`, `/leg`, `/flight-debrief`, `/mission-debrief`, and `/routine-maintenance` must:
+- **NEVER implement code changes** — only create/update artifacts
+- **NEVER modify source files** in the target project (no `.rs`, `.ts`, `.tsx`, `.json`, etc.)
+
+`/agentic-workflow` orchestrates implementation by spawning separate agents that execute code changes in the target project. The orchestrator itself never modifies source files directly.
+
+> **Phase gates require confirmation.** Missions must be fully agreed before designing
+> flights. Flights must be fully agreed before designing legs. Never skip ahead — get
+> explicit user confirmation at each transition.
+
+## Projects Registry
+
+The `projects.md` file in this repository catalogs all active projects on this device. When using skills:
+
+1. **Read `projects.md` first** to find the target project's path, remote, and description
+2. **Read `.flightops/ARTIFACTS.md`** in the target project to determine artifact locations
+3. **Create all artifacts in the target project** — not in mission-control
+
+The registry provides:
+- Project slug and description
+- Filesystem path (e.g., `~/projects/my-app`)
+- Git remote
+- Optional stack and status information
+
+## Lifecycle States
+
+- **Missions**: `planning` → `active` → `completed` (or `aborted`)
+- **Flights**: `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+- **Legs**: `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+
+## Public Repository
+
+This is a public repository. Keep all committed content anonymized:
+
+- **No personal paths** — Use generic examples like `~/projects/my-app`, not actual home directories
+- **No usernames** — Use placeholders like `username` in examples
+- **No project-specific details** — Keep examples generic
+- `projects.md` is gitignored for this reason — it contains local paths and is not committed

container/mission-control/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Flight Control Contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

container/mission-control/README.md

@@ -0,0 +1,201 @@
+# Flight Control
+
+An AI-first software development lifecycle methodology using aviation metaphors to bridge human intent and AI execution.
+
+## What is Mission Control?
+
+This repository is a **centralized command center** for managing multiple projects in parallel. Each project may have its own stack, systems, and constraints, but mission-control provides a consistent workflow and orchestration layer across all of them.
+
+- **Project registry** — Track active projects with paths, remotes, and configurations
+- **Shared methodology** — Apply structured planning regardless of project differences
+- **Claude Code skills** — Interactive tools for mission, flight, and leg creation
+
+Artifacts (missions, flights, legs) are created in target projects, not here. Mission-control holds the methodology, skills, and coordination—your projects hold the work.
+
+## The Aviation Model
+
+Flight Control organizes work into three hierarchical levels, each optimized for its primary audience:
+
+```
+Mission (human-optimized)
+  └── Flight (balanced)
+        └── Leg (AI-optimized)
+```
+
+- **Missions** define outcomes in human terms—what success looks like and why it matters
+- **Flights** translate outcomes into technical specifications with planning checklists
+- **Legs** provide structured, specific instructions optimized for AI consumption
+
+## Why Aviation?
+
+Aviation succeeds through layered planning and clear handoffs. Pilots follow flight plans but improvise when conditions demand it—weather, emergencies, ATC instructions. Structured planning enables effective improvisation by providing a baseline to deviate from and return to. Similarly, Flight Control separates strategic intent (missions) from tactical execution (legs), with flights serving as the translation layer.
+
+## Agentic Workflow
+
+**LLM orchestrators**: Run `/agentic-workflow` to drive multi-agent flight execution with Claude Code. The skill orchestrates the full leg cycle — design, implement, review, commit — using three separate Claude instances.
+
+## Getting Started
+
+### Prerequisites
+
+- [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installed
+- A project on disk with a git remote, initialized with Claude Code (`claude /init`)
+
+### Walkthrough
+
+1. **Clone mission-control** — Clone this repo and open it in Claude Code.
+
+2. **Set up the projects registry** — Run `/init-mission-control` (or manually copy `projects.md.template` → `projects.md` and fill in your project details). This creates the central registry that all skills read from.
+
+3. **Initialize your project** — Run `/init-project` and select your project. This creates `.flightops/` in your target project with artifact configuration, methodology reference, and crew definitions.
+
+4. **Review agent crew files** — Check the files in `{project}/.flightops/agent-crews/`. These define the crew composition (roles, models, prompts) for each phase. Customize them to your needs.
+
+5. **Create a mission** — Run `/mission`. This interviews you about desired outcomes and creates a mission artifact in your target project.
+
+6. **Design a flight** — Run `/flight` to break the mission into a technical specification with pre/in/post-flight checklists.
+
+7. **Execute** — Run `/agentic-workflow` to drive multi-agent implementation. This orchestrates design, implement, review, and commit cycles across legs.
+
+8. **Debrief** — Run `/flight-debrief` and `/mission-debrief` after completion to capture lessons learned.
+
+## Documentation
+
+1. **[Overview](docs/overview.md)** — Philosophy and principles behind Flight Control
+2. **[Missions](docs/missions.md)** — Writing outcome-driven mission statements
+3. **[Flights](docs/flights.md)** — Creating technical specifications with pre/post checklists
+4. **[Flight Logs](docs/flight-logs.md)** — Recording execution progress and decisions
+5. **[Legs](docs/legs.md)** — Structuring AI-optimized implementation steps
+6. **[Workflow](docs/workflow.md)** — End-to-end flow from mission to completion
+
+## Core Concepts
+
+### The Audience Gradient
+
+Documentation becomes progressively more structured as it moves down the hierarchy:
+
+| Level | Audience | Style |
+|-------|----------|-------|
+| Mission | Humans, stakeholders | Narrative prose, outcome-focused |
+| Flight | Developers, AI | Technical spec with checklists |
+| Leg | AI agents | Structured format, explicit criteria |
+
+### Lifecycle States
+
+Each level tracks progress through defined states:
+
+- **Missions**: `planning` → `active` → `completed` (or `aborted`)
+- **Flights**: `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+- **Legs**: `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
+
+### Scaling
+
+Flight Control scales from solo developers to teams. The methodology provides structure and continuity across sessions regardless of team size.
+
+## Artifact Organization
+
+The hierarchy nests naturally:
+
+```
+Mission
+├── Mission Debrief
+└── Flight
+    ├── Flight Log
+    ├── Flight Briefing
+    ├── Flight Debrief
+    └── Leg
+```
+
+How you store these artifacts depends on your project's needs. Flight Control supports multiple artifact systems:
+
+- **Markdown files** — Version-controlled documentation in your repository
+- **Issue trackers** — Jira, Linear, GitHub Issues with linked relationships
+- **Hybrid** — Missions in markdown, flights/legs as tickets
+
+Each project configures its artifact system during initialization. The methodology and Claude Code skills adapt to your choice.
+
+## Claude Code Skills
+
+Flight Control includes Claude Code skills for interactive planning:
+
+| Skill | Purpose |
+|-------|---------|
+| `/init-mission-control` | Set up the projects registry |
+| `/init-project` | Initialize a project for Flight Control |
+| `/mission` | Create outcome-driven missions through research and interview |
+| `/flight` | Create technical flight specs from missions |
+| `/leg` | Generate implementation guidance for LLM execution |
+| `/flight-debrief` | Post-flight analysis for continuous improvement |
+| `/agentic-workflow` | Drive multi-agent flight execution |
+| `/mission-debrief` | Post-mission retrospective for outcomes assessment |
+| `/daily-briefing` | Cross-project status report with health assessment |
+
+## Recommended Workflow
+
+All work runs from a single **Mission Control** session. Mission Control handles planning directly and spawns agents into the target project's context for implementation, review, and commits. Each spawned agent gets a clean context with only the information it needs, while Mission Control maintains continuity across the entire flight.
+
+### Context Strategy
+
+- **Mission Control**: Long-running session spanning an entire flight — accumulates knowledge across legs, orchestrates all work
+- **Spawned agents**: Fresh context per task — designed with precise instructions and the relevant artifacts, execute in the target project directory
+
+Claude Code's version control in mission-control acts as the orchestrator for development of the remote project. No second interactive session is needed.
+
+### The Cycle
+
+```mermaid
+sequenceDiagram
+    participant MC as Mission Control
+    participant A as Spawned Agents
+
+    Note over MC,A: ─── Mission Planning ───
+    MC->>MC: /mission — research, interview, define outcomes
+    MC->>MC: Review and confirm mission
+
+    Note over MC,A: ─── Flight Planning ───
+    MC->>MC: /flight — create technical spec, checklists
+    MC->>MC: Review and confirm flight
+
+    Note over MC,A: ─── Execution ───
+    MC->>MC: /agentic-workflow
+
+    loop For each leg
+        Note over MC: Design phase
+        MC->>A: Spawn designer agent
+        A->>A: Design leg spec
+        A-->>MC: Leg designed
+
+        MC->>MC: Review leg design
+
+        Note over MC: Implement phase
+        MC->>A: Spawn implementer agent<br/>(target project context)
+        A->>A: Implement leg, update logs
+        A-->>MC: Implementation complete
+
+        Note over MC: Review phase
+        MC->>A: Spawn reviewer agent<br/>(target project context)
+        A->>A: Review changes, verify criteria
+        A-->>MC: Review complete
+
+        Note over MC: Commit phase
+        MC->>A: Spawn commit agent<br/>(target project context)
+        A->>A: Stage and commit changes
+        A-->>MC: Committed
+
+        MC->>MC: Update flight checklist
+    end
+
+    Note over MC,A: Flight lands
+
+    Note over MC,A: ─── Debrief ───
+    MC->>MC: /flight-debrief
+    MC->>MC: /mission-debrief
+```
+
+### Why This Matters
+
+A single orchestrating session eliminates context drift between planning and execution. Mission Control sees every leg's outcome and carries that knowledge forward into the next design. Spawned agents get clean, focused contexts — they don't need flight-wide memory because Mission Control provides exactly the context they need. Artifacts stay synchronized because one session owns the full lifecycle.
+
+## License
+
+[MIT](LICENSE)

container/mission-control/docs/flight-logs.md

@@ -0,0 +1,252 @@
+# Flight Logs
+
+Flight logs are living records created during flight execution. They capture what actually happened—when legs started and ended, what changed, decisions made mid-flight, and any deviations or anomalies encountered.
+
+## What is a Flight Log?
+
+A flight log is the authoritative record of a flight's execution. While the flight document describes the *plan*, the flight log documents *reality*. There is exactly one flight log per flight, updated continuously during execution.
+
+**Important**: Flight logs are **append-only** during execution. Never delete or modify existing entries—only add new ones. This preserves the historical record and ensures nothing is lost when revisiting decisions later.
+
+### Flight Log vs. Other Artifacts
+
+| Artifact | Purpose | When Written | Updates |
+|----------|---------|--------------|---------|
+| Flight | Plan what to do | Before execution | During planning only |
+| Flight Log | Record what happened | During execution | Continuously |
+| Leg | Instructions for one task | Before execution | Never (immutable) |
+
+## Why Flight Logs Matter
+
+### For Current Execution
+
+Flight logs provide:
+- **Continuity**: When work resumes after interruption, the log shows where things stand
+- **Decision history**: Why choices were made when the plan didn't fit reality
+- **Anomaly tracking**: Issues that didn't block progress but need future attention
+
+### For Future Legs
+
+When creating new legs, the flight log reveals:
+- What actually worked vs. what was planned
+- Decisions that affect subsequent implementation
+- Discovered complexity that should inform estimates
+- Patterns or anti-patterns emerging from execution
+
+### For Post-Flight Debrief
+
+The flight log enables meaningful retrospectives by capturing:
+- Actual vs. planned progression
+- Root causes of deviations
+- Learnings that should inform future flights
+
+## Flight Log Structure
+
+```markdown
+# Flight Log: {Flight Title}
+
+## Flight Reference
+[{Flight Title}](flight.md)
+
+## Summary
+Brief overview of the flight's execution status and key outcomes.
+
+---
+
+## Leg Progress
+
+### {Leg Name}
+**Status**: completed | landed | in-flight | aborted
+**Started**: {timestamp}
+**Completed**: {timestamp}
+
+#### Changes Made
+- {Summary of what was implemented}
+- {Files modified and why}
+
+#### Notes
+{Any relevant observations during execution}
+
+---
+
+## Decisions
+
+Choices made during execution that weren't in the original plan.
+
+### {Decision Title}
+**Context**: Why this decision was needed
+**Options Considered**: What alternatives existed
+**Decision**: What was chosen
+**Rationale**: Why this choice was made
+**Impact**: How this affects the flight or future legs
+
+---
+
+## Deviations
+
+Departures from the planned approach.
+
+### {Deviation Title}
+**Planned**: What the flight specified
+**Actual**: What was done instead
+**Reason**: Why the deviation was necessary
+**Outcome**: Result of the deviation
+
+---
+
+## Anomalies
+
+Unexpected issues or behaviors encountered.
+
+### {Anomaly Title}
+**Observed**: What happened
+**Expected**: What should have happened
+**Severity**: blocking | degraded | cosmetic
+**Resolution**: How it was handled (or "unresolved")
+**Follow-up**: Any actions needed later
+
+---
+
+## Session Notes
+
+Chronological notes from each work session.
+
+### {Date/Session Identifier}
+- {Note about progress or observation}
+- {Note about what was attempted}
+- {Note about what was learned}
+```
+
+## When to Update the Flight Log
+
+### Starting a Leg
+
+Record:
+- Leg name and start timestamp
+- Any context carried from previous legs
+- Initial observations about the task
+
+### During Execution
+
+Record:
+- Decisions that diverge from or extend the plan
+- Unexpected complexity or simplicity
+- Anomalies encountered (even if resolved)
+
+### Completing a Leg
+
+Record:
+- Completion timestamp
+- Summary of changes made
+- Files modified
+- Any notes for future legs
+
+### Encountering Issues
+
+Record immediately:
+- What went wrong
+- What was expected
+- Severity and impact
+- Resolution or workaround
+
+## Using Flight Logs When Creating Legs
+
+When generating new legs with `/leg`, the flight log must be consulted to understand:
+
+1. **What's actually complete**: The log shows real completion status, not just planned progress
+2. **Decisions made**: Mid-flight decisions may change how subsequent legs should be implemented
+3. **Discovered context**: Anomalies and deviations reveal system behavior that affects new work
+4. **Patterns established**: Implementation approaches that worked (or didn't) inform future guidance
+
+### Example: Log Informing Leg Creation
+
+**Flight log entry:**
+```markdown
+### API Authentication Leg
+**Status**: completed
+
+#### Changes Made
+- Implemented JWT auth in `src/middleware/auth.ts`
+- Used `jose` library instead of planned `jsonwebtoken` (see Decisions)
+
+#### Decisions
+**JWT Library Change**
+- Context: `jsonwebtoken` had CVE flagged in security scan
+- Decision: Switch to `jose` library
+- Impact: All subsequent auth-related code must use `jose` patterns
+```
+
+**Impact on next leg:**
+When creating the "Protected Routes" leg, the guidance must specify using `jose` patterns, not the originally planned `jsonwebtoken` approach. Without the flight log, this context would be lost.
+
+## Location
+
+Flight log location is defined in `.flightops/ARTIFACTS.md`. The artifact system determines where and how logs are stored.
+
+## Best Practices
+
+### Keep Entries Atomic
+
+Write entries as things happen, not in batches. Batched entries lose detail and context.
+
+### Be Factual, Not Editorial
+
+**Good**: "Validation logic required 3 additional edge cases not in spec"
+**Avoid**: "The spec was incomplete and caused problems"
+
+### Link to Specifics
+
+Reference file paths, line numbers, commit hashes when relevant. Vague entries lose value quickly.
+
+### Capture the "Why"
+
+The code shows *what* changed. The log should capture *why* decisions were made.
+
+### Don't Duplicate the Leg
+
+The leg document has acceptance criteria and implementation guidance. The log records completion status and what actually happened—not a copy of the plan.
+
+## Common Patterns
+
+### Discovery Pattern
+
+When execution reveals something unexpected:
+
+```markdown
+### Discovery: Rate Limiting Already Exists
+**Observed**: Found existing rate limiter in `src/middleware/rateLimit.ts`
+**Expected**: Needed to implement from scratch per flight spec
+**Impact**: Leg `implement-rate-limiting` can be simplified to configuration
+**Action**: Updated leg scope, reduced from 4 hours to 30 minutes
+```
+
+### Blocker Pattern
+
+When progress stops:
+
+```markdown
+### Blocker: Missing API Credentials
+**Observed**: Stripe API key not in environment
+**Severity**: blocking
+**Impact**: Cannot test payment integration
+**Resolution**: Requested credentials from DevOps
+**Unblocked**: {timestamp when resolved}
+```
+
+### Adaptation Pattern
+
+When the plan needs adjustment:
+
+```markdown
+### Deviation: Schema Change
+**Planned**: Add `verified` boolean to User model
+**Actual**: Added `verifiedAt` timestamp instead
+**Reason**: Team decided verification time is valuable data
+**Outcome**: Provides more information, minor query adjustments needed
+```
+
+## Next Steps
+
+- [Flights](flights.md) — Understanding flight structure and lifecycle
+- [Legs](legs.md) — How legs are created and executed
+- [Workflow](workflow.md) — The complete flow from mission to completion

container/mission-control/docs/flights.md

@@ -0,0 +1,462 @@
+# Flights
+
+Flights are the balanced layer of Flight Control—technical enough for implementation, readable enough for humans. A flight and its flight plan are synonymous: the document *is* the plan.
+
+## What is a Flight?
+
+A flight translates mission outcomes into technical specifications. Flights are:
+
+- **Technically scoped**: Bounded implementation work
+- **Checklist-driven**: Pre-flight, in-flight, and post-flight phases
+- **Adaptive**: Living documents that evolve with understanding
+
+### Flight vs. Mission vs. Leg
+
+| Aspect | Mission | Flight | Leg |
+|--------|---------|--------|-----|
+| Question | Why? | What & How? | Do this |
+| Audience | Stakeholders | Developers/AI | AI agents |
+| Flexibility | High | Medium | Low |
+| Updates | Rarely | As needed | Never (create new) |
+
+## Flight Structure
+
+Every flight has three sections corresponding to its lifecycle:
+
+```markdown
+# Flight: {Title}
+
+## Mission Link
+Parent mission and relevant success criteria.
+
+---
+
+## Pre-Flight
+
+### Objective
+What this flight accomplishes.
+
+### Open Questions
+- [ ] Question needing resolution
+- [ ] Another question
+
+### Design Decisions
+Choices made and their rationale.
+
+### Prerequisites
+What must be true before execution begins.
+
+### Pre-Flight Checklist
+- [ ] Questions resolved
+- [ ] Design decisions documented
+- [ ] Prerequisites verified
+- [ ] Legs defined
+
+---
+
+## In-Flight
+
+### Technical Approach
+How the objective will be achieved.
+
+### Checkpoints
+Key milestones during execution.
+
+### Adaptation Criteria
+When to deviate from plan.
+
+### Legs
+Links to implementation legs.
+
+---
+
+## Post-Flight
+
+### Completion Checklist
+- [ ] All legs completed
+- [ ] Integration verified
+- [ ] Tests passing
+- [ ] Documentation updated
+
+### Verification
+How to confirm the flight achieved its objective.
+
+### Retrospective Notes
+What was learned during this flight.
+```
+
+## Pre-Flight Phase
+
+Pre-flight is about readiness. No implementation happens here—only planning.
+
+### Open Questions
+
+Capture unknowns that need resolution before execution:
+
+```markdown
+### Open Questions
+- [ ] Should we use JWT or session-based auth?
+- [ ] What OAuth providers do we need to support?
+- [ ] How long should sessions remain valid?
+```
+
+Questions should be:
+- **Specific**: Clear what information is needed
+- **Blocking**: Execution can't proceed without answers
+- **Resolvable**: Someone can answer them
+
+Check off questions as they're resolved and document answers in Design Decisions.
+
+### Design Decisions
+
+Record choices and rationale:
+
+```markdown
+### Design Decisions
+
+**Authentication Method**: JWT tokens
+- Rationale: Stateless, works across services
+- Trade-off: Token revocation more complex
+- Decided by: Security team review
+
+**Session Duration**: 7 days with refresh
+- Rationale: Balance security and convenience
+- Trade-off: Longer exposure window
+- Decided by: Product requirements
+```
+
+Design decisions prevent relitigating settled questions and help future maintainers understand *why*.
+
+### Prerequisites
+
+List conditions required for execution:
+
+```markdown
+### Prerequisites
+- [ ] Database schema migrations ready
+- [ ] API authentication middleware exists
+- [ ] Test environment configured
+- [ ] Security review of approach completed
+```
+
+Prerequisites are external dependencies. If they're not met, the flight can't begin safely.
+
+### Pre-Flight Checklist
+
+The gate check before execution:
+
+```markdown
+### Pre-Flight Checklist
+- [ ] All open questions resolved
+- [ ] Design decisions documented with rationale
+- [ ] Prerequisites verified
+- [ ] Legs defined with acceptance criteria
+- [ ] Estimated scope is reasonable
+```
+
+When all items are checked, the flight moves from `planning` to `ready`.
+
+## Flight Briefing
+
+Before execution begins, create a **flight briefing** to align the crew:
+
+```markdown
+# Flight Briefing: {Title}
+
+## Mission Context
+How this flight contributes to the mission.
+
+## Objective
+What this flight will accomplish.
+
+## Key Decisions
+Critical design decisions the crew should know.
+
+## Risks
+Known risks and mitigation strategies.
+
+## Legs Overview
+Summary of legs with complexity notes.
+
+## Success Criteria
+How we'll know the flight succeeded.
+```
+
+The briefing is created when the flight moves to `ready` status.
+
+## In-Flight Phase
+
+In-flight is execution. Legs are being worked, progress is tracked in the [flight log](flight-logs.md).
+
+### Technical Approach
+
+Document *how* the objective will be achieved:
+
+```markdown
+### Technical Approach
+
+1. Create user model with email/password fields
+2. Implement registration endpoint with validation
+3. Add login endpoint with JWT generation
+4. Create middleware for protected routes
+5. Add password reset flow
+```
+
+This bridges design decisions to concrete implementation without being leg-level specific.
+
+### Checkpoints
+
+Define milestones for progress tracking:
+
+```markdown
+### Checkpoints
+- [ ] User registration working end-to-end
+- [ ] Login returning valid tokens
+- [ ] Protected routes rejecting invalid tokens
+- [ ] Password reset emails sending
+```
+
+Checkpoints help identify if a flight is on track or needs intervention.
+
+### Adaptation Criteria
+
+When should the plan change?
+
+```markdown
+### Adaptation Criteria
+
+**Divert if**:
+- Security vulnerability discovered in approach
+- External API changes break integration
+- Performance testing reveals blocking issues
+
+**Acceptable variations**:
+- Minor API changes for developer experience
+- Additional validation rules
+- Extended error handling
+```
+
+Explicit adaptation criteria prevent both rigid adherence to bad plans and unnecessary scope creep.
+
+### Legs
+
+Reference the implementation legs:
+
+```markdown
+### Legs
+- [x] `create-user-model` - completed
+- [x] `registration-endpoint` - completed
+- [ ] `login-endpoint` - in-flight
+- [ ] `auth-middleware` - planning
+- [ ] `password-reset` - planning
+```
+
+### Flight Log
+
+During execution, maintain a [flight log](flight-logs.md) alongside this document. The flight log records:
+
+- **Leg progress**: When legs start and complete, with summaries of changes
+- **Decisions**: Choices made during execution not in the original plan
+- **Deviations**: Departures from the planned approach and why
+- **Anomalies**: Unexpected issues or behaviors encountered
+
+The flight log is essential for:
+- Providing continuity when work resumes after interruption
+- Informing the creation of subsequent legs
+- Enabling meaningful post-flight retrospectives
+
+## Post-Flight Phase
+
+Post-flight is verification and learning. Implementation is complete; now confirm success.
+
+### Completion Checklist
+
+Verify all work is finished:
+
+```markdown
+### Completion Checklist
+- [ ] All legs marked completed
+- [ ] Code merged to main branch
+- [ ] Integration tests passing
+- [ ] Documentation updated
+- [ ] No blocking issues remaining
+```
+
+### Verification
+
+How to confirm the flight succeeded:
+
+```markdown
+### Verification
+
+**Manual verification**:
+1. Create new user account
+2. Log in with credentials
+3. Access protected endpoint
+4. Log out and verify token invalid
+
+**Automated verification**:
+- `npm run test:auth` passes
+- `npm run test:e2e` auth flows pass
+```
+
+### Retrospective Notes
+
+Capture learnings for future flights:
+
+```markdown
+### Retrospective Notes
+
+**What went well**:
+- JWT library well-documented
+- Security review caught edge case early
+
+**What could improve**:
+- Underestimated password reset complexity
+- Should have spiked OAuth earlier
+
+**For next time**:
+- Include OAuth research in pre-flight
+- Add explicit leg for error handling
+```
+
+## Flight Lifecycle
+
+Flights progress through defined states:
+
+### States
+
+```
+planning ──► ready ──► in-flight ──► landed ──► completed
+                           │
+                           └──► aborted
+```
+
+**planning**
+Pre-flight phase. Questions being resolved, design decisions being made.
+
+**ready**
+Pre-flight checklist complete. All prerequisites met. Ready to execute.
+
+**in-flight**
+Legs actively being executed. Checkpoints being reached. Flights may be modified during this phase (e.g., changing planned legs) as long as the flight log captures the change and rationale.
+
+**landed**
+All legs complete. Verification passed. Flight achieved its objective. Ready for debrief.
+
+**completed**
+Debrief done. Flight fully wrapped up and artifacts updated.
+
+**aborted**
+Flight cancelled. Changes are rolled back. Document the reason for future reference.
+
+### In-Flight Modifications
+
+Flights can be modified while `in-flight` — for example, when planned legs need to change due to discoveries during execution. This is not a separate state; simply update the flight artifact and record the change and rationale in the flight log.
+
+**Create a new flight when:**
+- A completely new objective emerges
+- The discovered work is independent of the current flight's goal
+- The new work serves different mission success criteria
+
+### State Transitions
+
+| From | To | Trigger |
+|------|----|---------|
+| planning | ready | Pre-flight checklist complete |
+| ready | in-flight | First leg begins |
+| in-flight | landed | All legs complete |
+| in-flight | aborted | Flight cancelled, changes rolled back |
+| landed | completed | Debrief complete |
+
+## Connecting to Parent Mission
+
+Flights serve missions. Each flight should clearly link to:
+
+```markdown
+## Mission Link
+
+**Mission**: [Secure User Authentication](../mission.md)
+
+**Contributing to criteria**:
+- [ ] Users can create accounts with email/password
+- [ ] Session management handles concurrent logins
+```
+
+This traceability ensures flights aren't orphaned work—they connect to meaningful outcomes.
+
+## Connecting to Child Legs
+
+Flights generate legs. The flight defines *what* needs to happen; legs define the *exact* implementation steps.
+
+A well-structured flight enables AI agents to execute legs without needing clarification:
+
+**Flight provides**:
+- Technical approach and patterns
+- Design decisions and constraints
+- Context about the broader system
+
+**Legs consume**:
+- Specific task to complete
+- Acceptance criteria to meet
+- Context from flight document
+
+## Common Pitfalls
+
+### Skipping Pre-Flight
+
+Rushing to implementation creates problems. Pre-flight exists to:
+- Surface hidden complexity
+- Align on approach before work begins
+- Identify blocking dependencies
+
+A thorough pre-flight prevents mid-flight crises.
+
+### Over-Specifying
+
+Flights should guide, not constrain. Leave room for:
+- Implementation details discovered during work
+- Better approaches found during execution
+- Minor adjustments that don't affect outcomes
+
+### Ignoring Adaptation Criteria
+
+When circumstances change, adapt the plan. Flights that ignore reality become fiction. Use adaptation criteria to decide when to divert.
+
+### Skipping Post-Flight
+
+Post-flight isn't bureaucracy—it's learning. Retrospective notes prevent repeating mistakes. Verification confirms the flight actually succeeded.
+
+## Flight Debrief
+
+After a flight lands (or diverts), create a **flight debrief** for retrospective analysis:
+
+```markdown
+# Flight Debrief: {Title}
+
+## Outcome Assessment
+What the flight accomplished and which mission criteria it advanced.
+
+## What Went Well
+Effective patterns during execution.
+
+## What Could Be Improved
+Process and technical recommendations.
+
+## Deviations and Lessons
+What changed from the plan and why.
+
+## Recommendations
+Top 3-5 most impactful improvements.
+
+## Action Items
+Follow-up work and improvements.
+```
+
+The debrief enables continuous improvement and informs future flights.
+
+## Next Steps
+
+- [Flight Logs](flight-logs.md) — Recording execution progress and decisions
+- [Legs](legs.md) — Learn to write AI-optimized implementation steps
+- [Workflow](workflow.md) — See how flights flow into legs

container/mission-control/docs/legs.md

@@ -0,0 +1,383 @@
+# Legs
+
+Legs are the AI-optimized layer of Flight Control. They provide structured, explicit instructions that AI agents can execute without ambiguity.
+
+## What is a Leg?
+
+A leg is a single, atomic unit of implementation work. Legs are:
+
+- **Explicit**: No ambiguity about what "done" means
+- **Bounded**: Clear start and end points
+- **Context-complete**: All necessary information included
+- **AI-consumable**: Structured for machine parsing
+
+### Leg vs. Flight vs. Mission
+
+| Aspect | Mission | Flight | Leg |
+|--------|---------|--------|-----|
+| Scope | Outcome | Feature | Task |
+| Duration | Days-weeks | Hours-days | Minutes-hours |
+| Modifications | Allowed | Allowed | Create new instead |
+| Audience | Humans | Developers/AI | AI agents |
+
+## Leg Structure
+
+Legs follow a consistent structure optimized for AI consumption:
+
+```markdown
+# Leg: {slug}
+
+## Flight Link
+[Parent flight](../flight.md)
+
+## Objective
+Single sentence describing what this leg accomplishes.
+
+## Context
+Information the AI needs to understand this task.
+
+## Inputs
+- What exists before this leg runs
+
+## Outputs
+- What exists after this leg completes
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Verification Steps
+How to confirm each criterion is met (commands, manual checks, tools).
+
+## Implementation Guidance
+Specific patterns, approaches, or constraints.
+
+## Files Likely Affected
+- `path/to/file.ts`
+- `path/to/test.ts`
+```
+
+## Writing Effective Legs
+
+### Objectives
+
+State exactly what the leg accomplishes in one sentence:
+
+**Weak**:
+> Set up the user stuff
+
+**Strong**:
+> Create the User model with email, password_hash, and timestamps fields
+
+The objective should be:
+- **Specific**: Clear what will be created/modified
+- **Verifiable**: Can confirm completion by inspection
+- **Atomic**: One cohesive piece of work
+
+### Context
+
+Provide information the AI needs but might not have:
+
+```markdown
+## Context
+
+This project uses Prisma for database access. The existing `prisma/schema.prisma`
+file contains the Post and Comment models. User will be referenced by these
+models via foreign keys.
+
+Authentication uses JWT tokens. The password_hash field will store bcrypt hashes
+(cost factor 12). The email field must be unique and will be used as the login
+identifier.
+```
+
+Good context includes:
+- Relevant technology/framework information
+- Relationship to existing code
+- Design decisions from the parent flight
+- Constraints that affect implementation
+
+### Inputs and Outputs
+
+Be explicit about state before and after:
+
+```markdown
+## Inputs
+- Prisma schema at `prisma/schema.prisma` with Post and Comment models
+- No existing User model or authentication
+
+## Outputs
+- User model added to Prisma schema
+- Migration file generated
+- Migration applied to development database
+```
+
+Inputs help the AI understand starting conditions. Outputs define the expected end state.
+
+### Acceptance Criteria
+
+Define exactly what "done" means:
+
+```markdown
+## Acceptance Criteria
+- [ ] User model exists in `prisma/schema.prisma`
+- [ ] User model has fields: id, email, password_hash, created_at, updated_at
+- [ ] email field has `@unique` attribute
+- [ ] Migration file exists in `prisma/migrations/`
+- [ ] `npx prisma migrate status` shows no pending migrations
+- [ ] TypeScript types generated (`npx prisma generate` succeeds)
+```
+
+Acceptance criteria should be:
+- **Binary**: Either met or not met
+- **Observable**: Can verify by inspection or test
+- **Complete**: Nothing else required for "done"
+
+### Verification Steps
+
+Tell the AI exactly *how* to confirm each criterion:
+
+```markdown
+## Verification Steps
+- Run `npx prisma migrate status` — should show no pending migrations
+- Run `npm test` — all tests pass
+- Open browser to `/users` — page loads without errors
+- Tab through form fields — focus order matches visual order
+- Run `npx lighthouse --accessibility` — score ≥ 90
+```
+
+Verification steps should be:
+- **Executable**: Commands or specific actions
+- **Deterministic**: Same result every time
+- **Mapped to criteria**: Clear which criterion each step validates
+
+For accessibility legs, include specific checks:
+- Keyboard navigation sequences to test
+- Screen reader commands (e.g., "navigate to main content via skip link")
+- Automated tool commands (Lighthouse, axe-core)
+
+### Implementation Guidance
+
+Provide specific direction when needed:
+
+```markdown
+## Implementation Guidance
+
+Use Prisma's native type for id:
+```prisma
+id String @id @default(cuid())
+```
+
+For timestamps, use Prisma's auto-managed fields:
+```prisma
+created_at DateTime @default(now())
+updated_at DateTime @updatedAt
+```
+
+Do not add relations to Post/Comment yet—that's a separate leg.
+```
+
+Implementation guidance helps when:
+- Project has specific patterns to follow
+- There are multiple valid approaches (pick one)
+- Constraints aren't obvious from context
+
+### Files Likely Affected
+
+Help the AI know where to look:
+
+```markdown
+## Files Likely Affected
+- `prisma/schema.prisma` - Add User model
+- `prisma/migrations/*` - New migration file (generated)
+```
+
+This isn't prescriptive—the AI might touch other files. It's a starting point for orientation.
+
+## Leg Lifecycle
+
+Legs progress through defined states:
+
+### States
+
+```
+planning ──► ready ──► in-flight ──► landed ──► completed
+                           │
+                           └──► aborted
+```
+
+**planning**
+Leg is being designed. Acceptance criteria and implementation guidance being defined.
+
+**ready**
+Leg design approved. Ready for implementation.
+
+**in-flight**
+AI agent actively working on implementation.
+
+**landed**
+Implementation complete. Flight log updated. Ready for review.
+
+**completed**
+Review passed. Acceptance criteria confirmed met.
+
+**aborted**
+Leg cancelled. Changes are rolled back. Document the reason in the flight log.
+
+### State Transitions
+
+| From | To | Trigger |
+|------|----|---------|
+| planning | ready | Design review passes |
+| ready | in-flight | Developer begins work |
+| in-flight | landed | Developer reports completion |
+| in-flight | aborted | Cannot proceed, changes rolled back |
+| landed | completed | Review passes |
+| landed | in-flight | Issues found, needs fixes |
+
+Note: Legs may only be modified while in `planning` state. Once `in-flight`, create new legs instead of modifying existing ones.
+
+## Patterns for AI Consumption
+
+### Be Explicit, Not Implicit
+
+**Implicit** (requires inference):
+> Add validation to the email field
+
+**Explicit** (no inference needed):
+> Add email validation: must be non-empty, valid email format (use validator library's isEmail), maximum 255 characters. Return 400 status with `{ error: "Invalid email format" }` on failure.
+
+### Provide Examples
+
+When patterns might be unclear, show don't tell:
+
+```markdown
+## Implementation Guidance
+
+Follow the existing controller pattern:
+
+```typescript
+// Example from PostController
+export async function createPost(req: Request, res: Response) {
+  const { title, content } = req.body;
+
+  if (!title) {
+    return res.status(400).json({ error: "Title is required" });
+  }
+
+  const post = await prisma.post.create({
+    data: { title, content, authorId: req.user.id }
+  });
+
+  return res.status(201).json(post);
+}
+```
+
+Apply this pattern to the registration endpoint.
+```
+
+### State Constraints Clearly
+
+Don't bury constraints in prose:
+
+**Buried**:
+> Create the endpoint and make sure it handles errors properly and validates input and also we're using Express and the response should be JSON.
+
+**Clear**:
+```markdown
+## Constraints
+- Framework: Express.js
+- Response format: JSON
+- Error handling: Return appropriate HTTP status codes
+- Validation: Validate all input before processing
+```
+
+### Link to Flight for Context
+
+When details would be redundant, reference the parent:
+
+```markdown
+## Context
+
+See [parent flight](../flight.md) for:
+- Authentication approach (JWT tokens)
+- Session duration decisions
+- Error response format standards
+```
+
+## Common Pitfalls
+
+### Too Large
+
+If a leg takes more than a few hours, it's probably too big. Signs:
+- Multiple independent pieces of functionality
+- Would benefit from intermediate checkpoints
+- Hard to write clear acceptance criteria
+
+Split into smaller legs.
+
+### Too Small
+
+If a leg is trivial, it adds overhead without value. Signs:
+- Single line change
+- No meaningful acceptance criteria
+- Part of a larger atomic operation
+
+Combine with related work.
+
+### Ambiguous Acceptance Criteria
+
+If criteria require judgment, they're not criteria:
+
+**Ambiguous**: "Code is clean and readable"
+**Specific**: "Functions are under 50 lines, no eslint warnings"
+
+**Ambiguous**: "Error handling is good"
+**Specific**: "All async operations wrapped in try/catch, errors logged with context"
+
+### Missing Context
+
+AI agents don't have your mental model. Include:
+- Why this approach (from flight decisions)
+- How this fits with existing code
+- What patterns to follow
+- What to avoid
+
+## Relationship to Flight
+
+Legs are generated from flights. The flight provides:
+- Technical approach
+- Design decisions
+- Overall context
+
+Legs provide:
+- Specific implementation steps
+- Explicit acceptance criteria
+- Focused scope
+
+A flight might generate many legs:
+
+```
+Flight: User Registration Flow
+├── Leg: create-user-model
+├── Leg: registration-endpoint
+├── Leg: email-validation
+├── Leg: password-hashing
+├── Leg: registration-tests
+└── Leg: registration-docs
+```
+
+## Immutability Principle
+
+Once a leg is `in-flight`, don't modify it. If requirements change:
+
+1. Mark the current leg as aborted (changes rolled back)
+2. Create a new leg with updated requirements
+3. Reference the old leg for context
+
+This preserves history and prevents confusion about what the AI was asked to do.
+
+## Next Steps
+
+- [Workflow](workflow.md) — See the complete mission → flight → leg flow
+- [Flights](flights.md) — Understand where legs come from

container/mission-control/docs/missions.md

@@ -0,0 +1,245 @@
+# Missions
+
+Missions are the human-optimized layer of Flight Control. They define *what* success looks like without prescribing *how* to achieve it.
+
+## What is a Mission?
+
+A mission represents a meaningful outcome—something a stakeholder would recognize as valuable. Missions are:
+
+- **Outcome-driven**: Focused on results, not activities
+- **Human-readable**: Written for people, not machines
+- **Strategically scoped**: Large enough to matter, bounded enough to complete
+
+### Mission vs. Flight vs. Leg
+
+| Aspect | Mission | Flight | Leg |
+|--------|---------|--------|-----|
+| Audience | Humans, stakeholders | Developers, AI | AI agents |
+| Scope | Outcome | Technical spec | Single task |
+| Style | Narrative | Structured | Explicit |
+| Duration | Days to weeks | Hours to days | Minutes to hours |
+
+## Writing Effective Missions
+
+### Start with Outcomes
+
+Frame missions around what changes when they're complete:
+
+**Weak** (activity-focused):
+> Implement user authentication
+
+**Strong** (outcome-focused):
+> Users can securely access their personal data without sharing credentials across services
+
+The outcome framing:
+- Clarifies *why* the work matters
+- Leaves implementation decisions to flights
+- Provides a clear test for completion
+
+### Define Success Criteria
+
+Every mission needs measurable success criteria. These answer: "How do we know we're done?"
+
+```markdown
+## Success Criteria
+
+- [ ] Users can create accounts with email/password
+- [ ] Users can authenticate via OAuth providers
+- [ ] Session management handles concurrent logins
+- [ ] Security audit passes with no critical findings
+```
+
+Success criteria should be:
+- **Observable**: Can be verified by inspection
+- **Binary**: Either met or not met
+- **Independent**: Achievable without external dependencies
+- **Capability-focused**: Describes what users or the system can do, not which tool or technology achieves it
+
+### Consider Stakeholders
+
+Missions serve stakeholders. Identify them explicitly:
+
+```markdown
+## Stakeholders
+
+- **End users**: Need frictionless, secure access
+- **Security team**: Requires compliance with auth standards
+- **Support team**: Needs ability to assist locked-out users
+```
+
+Stakeholder identification helps:
+- Prioritize competing concerns
+- Identify missing success criteria
+- Communicate progress meaningfully
+
+## Mission Structure
+
+A mission document typically contains:
+
+```markdown
+# Mission: {Title}
+
+## Outcome
+What success looks like in human terms.
+
+## Context
+Why this mission matters now. Background information.
+
+## Success Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Stakeholders
+Who cares about this outcome and why.
+
+## Constraints
+Non-negotiable boundaries (budget, timeline, technology).
+
+## Environment Requirements
+Development environment, runtime dependencies, special tooling.
+
+## Open Questions
+Unknowns that need resolution during execution.
+
+## Known Issues
+Emergent blockers and issues discovered during execution.
+
+## Flights
+Links to flights executing this mission.
+```
+
+## Mission Lifecycle
+
+Missions progress through defined states:
+
+### States
+
+```
+planning ──► active ──► completed
+                │
+                └──► aborted
+```
+
+**planning**
+The mission is being defined. Outcome, success criteria, and constraints are still being refined. No flights have started.
+
+**active**
+At least one flight is in progress. The mission outcome is being pursued. New flights may be created as understanding develops.
+
+**completed**
+All success criteria are met. Stakeholders have accepted the outcome. The mission can be archived.
+
+**aborted**
+The mission was cancelled before completion. This might happen due to:
+- Changed priorities
+- Discovered infeasibility
+- External factors
+
+Aborted missions should document *why* they were cancelled for future reference.
+
+### State Transitions
+
+| From | To | Trigger |
+|------|----|---------|
+| planning | active | First flight begins |
+| active | completed | All success criteria met |
+| active | aborted | Cancellation decision |
+| planning | aborted | Cancellation decision |
+
+## Communicating Mission Status
+
+Missions are stakeholder-facing. Status updates should be meaningful to non-technical audiences:
+
+**Weak update**:
+> Completed 3 of 5 flights
+
+**Strong update**:
+> Users can now create accounts and log in. Next: adding OAuth support and security review.
+
+Link progress to outcomes, not activities.
+
+## Common Pitfalls
+
+### Too Granular
+
+If a mission can be completed in a single flight, it's probably too small. Consider:
+- Is this a meaningful outcome or just a task?
+- Would a stakeholder recognize this as valuable?
+- Does it warrant its own success criteria?
+
+### Too Vague
+
+Missions need boundaries. "Improve the product" isn't a mission—it's a direction. Missions should be:
+- Completable (has an end state)
+- Measurable (success criteria exist)
+- Bounded (scope is clear)
+
+### Implementation Leaking In
+
+Missions should not prescribe *how*:
+
+**Leaking implementation**:
+> Build a React-based authentication flow using JWT tokens stored in HttpOnly cookies
+
+**Proper abstraction**:
+> Users can securely authenticate across sessions without re-entering credentials
+
+This applies to success criteria too. Criteria that name tools or technologies lock you into an approach before flights even begin:
+
+**Implementation-specific criteria** (avoid):
+> - [ ] JWT tokens are validated via middleware on every request
+> - [ ] User records are stored in PostgreSQL with bcrypt-hashed passwords
+
+**Capability-focused criteria** (prefer):
+> - [ ] Unauthorized requests are rejected before reaching protected resources
+> - [ ] Stored credentials cannot be recovered even if the database is compromised
+
+Save implementation details for flights.
+
+## Mission Debrief
+
+After a mission completes (or aborts), create a **mission debrief** for retrospective learning:
+
+```markdown
+# Mission Debrief: {Title}
+
+## Success Criteria Results
+Which criteria were met, partially met, or not met.
+
+## Flight Summary
+Overview of how each flight contributed.
+
+## What Went Well
+Effective patterns and successes.
+
+## What Could Be Improved
+Process and execution improvements.
+
+## Lessons Learned
+Insights to carry forward.
+
+## Methodology Feedback
+Improvements to Flight Control itself.
+```
+
+The debrief captures organizational learning and informs future missions.
+
+## Relationship to Flights
+
+Missions spawn flights. A typical mission might have:
+
+```
+Mission: Secure User Authentication
+├── Flight: Account creation flow
+├── Flight: Login and session management
+├── Flight: OAuth integration
+└── Flight: Security hardening
+```
+
+Flights can be planned upfront or emerge as the mission progresses. The mission provides the "why"; flights provide the "what" and "how".
+
+## Next Steps
+
+- [Flights](flights.md) — Learn to create technical specifications
+- [Workflow](workflow.md) — See how missions flow into flights

container/mission-control/docs/overview.md

@@ -0,0 +1,136 @@
+# Flight Control Overview
+
+Flight Control is a methodology for AI-first software development that maintains meaningful human oversight while maximizing AI effectiveness.
+
+## Philosophy
+
+### AI-First, Human-Guided
+
+Traditional development methodologies were designed for human developers. They assume humans will interpret requirements, make design decisions, and adapt to changing circumstances. AI agents work differently—they excel with explicit structure but struggle with ambiguity.
+
+Flight Control inverts the traditional approach:
+
+- **Humans define outcomes**, not implementation details
+- **AI executes implementations**, not strategic decisions
+- **The methodology bridges the gap** through progressive specification
+
+### Why Aviation Works
+
+Aviation provides a proven model for high-stakes operations where planning and execution are separate concerns:
+
+| Aviation | Flight Control |
+|----------|----------------|
+| Mission objectives | Mission outcomes |
+| Flight plan | Flight specification |
+| Flight legs | Implementation legs |
+| Pilot authority | Human oversight |
+| Autopilot execution | AI execution |
+
+The key insight: pilots don't recompute routes in real-time. They follow pre-computed flight plans while retaining authority to adapt when circumstances demand. Similarly, AI agents shouldn't reinvent architecture with each task—they should execute well-specified legs while flagging issues for human review.
+
+## Key Principles
+
+### 1. Outcome-Driven Planning
+
+Missions start with outcomes, not tasks:
+
+**Traditional**: "Build a user authentication system"
+**Flight Control**: "Users can securely access their accounts with minimal friction"
+
+The outcome framing keeps focus on what matters while leaving implementation flexible.
+
+### 2. Adaptive Specifications
+
+Flights are living documents. Unlike traditional specs that become stale, flight plans explicitly track:
+
+- Open questions requiring resolution
+- Design decisions and their rationale
+- Prerequisites and dependencies
+- Adaptation criteria (when to deviate from plan)
+
+### 3. Structured Execution
+
+Legs are optimized for AI consumption:
+
+- Explicit acceptance criteria
+- Required context clearly stated
+- Expected inputs and outputs defined
+- No ambiguity in scope
+
+### 4. Layered Feedback
+
+Information flows both directions:
+
+- **Downward**: Missions inform flights, flights generate legs
+- **Upward**: Leg completion updates flights, flight outcomes inform mission status
+
+## Comparison to Traditional Methodologies
+
+### vs. Agile/Scrum
+
+Agile emphasizes iterative human collaboration. Flight Control complements this by structuring how AI fits into iterations:
+
+- Sprints can contain multiple flights
+- Stories map roughly to flights
+- Tasks map to legs
+
+Flight Control adds the missing layer: how to specify work for AI execution.
+
+### vs. Waterfall
+
+Waterfall assumes complete upfront specification. Flight Control embraces uncertainty:
+
+- Missions can spawn new flights as understanding evolves
+- Flights can be modified in-flight when circumstances change
+- Legs can be aborted and replaced
+
+### vs. CRISP-DM / ML Workflows
+
+Data science workflows focus on experimentation. Flight Control adds structure without eliminating iteration:
+
+- Experimental flights can have "explore" legs
+- Failed experiments inform mission outcomes
+- Reproducibility is built into leg specifications
+
+## The Audience Gradient
+
+A core innovation is the **audience gradient**—documentation shifts style based on who consumes it:
+
+```
+Human Readable ◄─────────────────────────────► AI Optimized
+     │                    │                         │
+  Mission              Flight                      Leg
+     │                    │                         │
+ Narrative prose    Technical spec          Structured format
+ Outcome-focused    Checklist-driven        Explicit criteria
+ Flexible scope     Bounded scope           Fixed scope
+```
+
+This gradient acknowledges that humans and AI have different strengths:
+
+- Humans excel at ambiguity, context, and strategic thinking
+- AI excels at following explicit instructions consistently
+
+Flight Control puts each audience where they're strongest.
+
+## When to Use Flight Control
+
+Flight Control works best when:
+
+- AI agents are part of your development workflow
+- Work benefits from clear specification before execution
+- You need traceability from outcomes to implementation
+- Multiple people (or AI sessions) contribute to a single outcome
+
+It may be overkill for:
+
+- Quick one-off scripts
+- Solo exploratory coding
+- Highly uncertain R&D with no clear outcomes
+
+## Next Steps
+
+- [Missions](missions.md) — Learn to write outcome-driven mission statements
+- [Flights](flights.md) — Create technical specifications with pre/post checklists
+- [Legs](legs.md) — Structure AI-optimized implementation steps
+- [Workflow](workflow.md) — Understand the end-to-end flow

container/mission-control/docs/workflow.md

@@ -0,0 +1,473 @@
+# Workflow
+
+This document describes how work flows through Flight Control from mission inception to completion.
+
+## The Complete Flow
+
+```mermaid
+flowchart TB
+    subgraph MISSION
+        direction TB
+        planning[planning] --> active[active] --> completed[completed]
+        planning -.-> aborted[aborted]
+
+        subgraph " "
+            direction LR
+            flightA[Flight A] --> legsA[legs]
+            flightB[Flight B] --> legsB[legs]
+            flightC[Flight C] --> legsC[legs]
+        end
+
+        active --> flightA
+        active --> flightB
+        active --> flightC
+        legsA --> completed
+        legsB --> completed
+        legsC --> completed
+    end
+```
+
+## Phase 1: Mission Definition
+
+### Starting Point
+
+Work begins with an outcome someone wants to achieve:
+
+> "We need users to be able to authenticate securely"
+
+This human need becomes a mission.
+
+### Mission Creation
+
+1. **Write the outcome** — What does success look like?
+2. **Define success criteria** — How will we know we're done?
+3. **Identify stakeholders** — Who cares about this outcome?
+4. **Document constraints** — What boundaries exist?
+
+```markdown
+# Mission: Secure User Authentication
+
+## Outcome
+Users can securely access their accounts without credential friction.
+
+## Success Criteria
+- [ ] Users can create accounts
+- [ ] Users can log in and maintain sessions
+- [ ] Password reset flow exists
+- [ ] Security audit passes
+
+## Stakeholders
+- End users, Security team, Support team
+
+## Constraints
+- Must complete before Q2 launch
+- Must meet SOC2 requirements
+```
+
+### Mission State: `planning`
+
+The mission exists but no work has started. This is the time for:
+- Refining the outcome statement
+- Adjusting success criteria
+- Identifying initial flights
+
+## Phase 2: Flight Planning
+
+### Decomposing the Mission
+
+A mission typically requires multiple flights. Identify the major work areas:
+
+```
+Mission: Secure User Authentication
+├── Flight: Account Creation
+├── Flight: Login and Sessions
+├── Flight: Password Reset
+└── Flight: Security Hardening
+```
+
+### Creating the First Flight
+
+Start with the flight that unblocks others or provides the most learning:
+
+```markdown
+# Flight: Account Creation
+
+## Mission Link
+[Secure User Authentication](../mission.md)
+- Contributing to: "Users can create accounts"
+
+## Pre-Flight
+
+### Objective
+Users can register new accounts with email and password.
+
+### Open Questions
+- [ ] What password requirements?
+- [ ] Email verification required before use?
+
+### Design Decisions
+(To be filled as questions are resolved)
+
+### Prerequisites
+- [ ] Database provisioned
+- [ ] API framework set up
+```
+
+### Flight State: `planning`
+
+Pre-flight phase. Resolve open questions, document decisions, verify prerequisites.
+
+## Phase 3: Pre-Flight Completion
+
+### Resolving Questions
+
+Each open question gets answered and documented:
+
+```markdown
+### Open Questions
+- [x] What password requirements?
+- [x] Email verification required before use?
+
+### Design Decisions
+
+**Password Requirements**: Minimum 8 characters, 1 uppercase, 1 number
+- Rationale: Balance security and usability
+- Decided by: Security team
+
+**Email Verification**: Required before accessing protected features
+- Rationale: Prevent spam accounts
+- Decided by: Product requirements
+```
+
+### Defining Legs
+
+With decisions made, break the flight into legs:
+
+```markdown
+### Legs
+- [ ] `create-user-model` - Database model for users
+- [ ] `registration-endpoint` - API endpoint for registration
+- [ ] `email-verification` - Verification email and confirmation flow
+- [ ] `registration-tests` - Test coverage for registration
+```
+
+### Pre-Flight Checklist
+
+Complete the gate check:
+
+```markdown
+### Pre-Flight Checklist
+- [x] All open questions resolved
+- [x] Design decisions documented
+- [x] Prerequisites verified
+- [x] Legs defined with acceptance criteria
+```
+
+### Flight State: `ready`
+
+Pre-flight complete. Ready for execution.
+
+## Phase 4: Leg Execution
+
+### Mission State: `active`
+
+When the first leg begins, the mission becomes active.
+
+### Flight State: `in-flight`
+
+Legs are being executed. A [flight log](flight-logs.md) tracks progress, recording when legs start and complete, decisions made during execution, and any deviations or anomalies encountered.
+
+### Leg Lifecycle
+
+Each leg follows its own progression:
+
+```
+planning ──► ready ──► in-flight ──► landed ──► completed
+```
+
+**Example: `create-user-model` leg**
+
+```markdown
+# Leg: create-user-model
+
+## Objective
+Create the User model with authentication fields.
+
+## Acceptance Criteria
+- [ ] User model in schema
+- [ ] Fields: id, email, password_hash, verified, timestamps
+- [ ] Migration applied
+- [ ] Types generated
+```
+
+**Execution flow:**
+
+1. Leg design approved, moves to `ready`
+2. Developer begins, leg moves to `in-flight`
+3. Developer completes implementation, leg moves to `landed`, flight log updated
+4. Reviewer verifies acceptance criteria met
+5. Leg moves to `completed`
+
+### Parallel vs. Sequential Legs
+
+Some legs can run in parallel:
+
+```
+create-user-model ────► registration-endpoint ────► registration-tests
+                  └──► email-verification ────────┘
+```
+
+The model must exist first, but the endpoint and email flows can be built simultaneously, then tests cover everything.
+
+### Handling Aborted Legs
+
+When a leg can't proceed:
+
+1. Mark it `aborted` — changes are rolled back
+2. Determine if it needs:
+   - Flight-level decision (update the flight)
+   - External resolution (wait for dependency)
+   - New leg with updated requirements
+
+```markdown
+## Status: aborted
+
+**Reason**: Email service credentials not available in dev environment
+**Changes**: Rolled back
+**Next**: New leg after DevOps provisions SendGrid API key
+```
+
+## Phase 5: Flight Completion
+
+### All Legs Complete
+
+When every leg reaches `completed`:
+
+```markdown
+### Legs
+- [x] `create-user-model` - completed
+- [x] `registration-endpoint` - completed
+- [x] `email-verification` - completed
+- [x] `registration-tests` - completed
+```
+
+### Post-Flight Checklist
+
+```markdown
+### Completion Checklist
+- [x] All legs completed
+- [x] Code merged to main
+- [x] Tests passing in CI
+- [x] Documentation updated
+```
+
+### Verification
+
+Confirm the flight achieved its objective:
+
+```markdown
+### Verification
+
+Manual test completed:
+1. ✓ Created account with test@example.com
+2. ✓ Received verification email
+3. ✓ Clicked link, account verified
+4. ✓ Can access protected features
+```
+
+### Flight Debrief
+
+**Run `/flight-debrief` to capture learnings.** This is a required step, not optional.
+
+The debrief skill will:
+- Analyze what went well and what could improve
+- Identify process and technical lessons
+- Recommend methodology improvements
+- Update project documentation if needed
+
+The debrief artifact becomes part of the flight record and informs future flights.
+
+### Flight State: `landed`
+
+Post-flight complete. The flight achieved its objective.
+
+## Phase 6: Mission Progression
+
+### Tracking Mission Progress
+
+As flights land, mission success criteria get checked:
+
+```markdown
+## Success Criteria
+- [x] Users can create accounts ← Flight: Account Creation landed
+- [ ] Users can log in and maintain sessions ← Flight: Login in-flight
+- [ ] Password reset flow exists ← Flight: Password Reset planning
+- [ ] Security audit passes ← Flight: Security Hardening planning
+```
+
+### Spawning New Flights
+
+Discoveries during execution may require new flights:
+
+> "During the Login flight, we discovered we need rate limiting to prevent brute force attacks."
+
+Create a new flight:
+
+```
+Mission: Secure User Authentication
+├── Flight: Account Creation [landed]
+├── Flight: Login and Sessions [in-flight]
+├── Flight: Password Reset [planning]
+├── Flight: Security Hardening [planning]
+└── Flight: Rate Limiting [NEW - planning]
+```
+
+### Mission Completion
+
+When all success criteria are met:
+
+```markdown
+## Success Criteria
+- [x] Users can create accounts
+- [x] Users can log in and maintain sessions
+- [x] Password reset flow exists
+- [x] Security audit passes
+```
+
+### Mission Debrief
+
+**Run `/mission-debrief` to perform a retrospective.** This is a required step, not optional.
+
+The debrief skill will:
+- Assess whether the mission achieved its stated outcomes
+- Synthesize lessons from all flight debriefs
+- Capture process and methodology improvements
+- Interview participants for qualitative insights
+
+The mission debrief is the primary source for improving Flight Control itself.
+
+### Mission State: `completed`
+
+All outcomes achieved. The mission can be archived with its debrief.
+
+## Feedback Loops
+
+### Upward Feedback
+
+Information flows from legs to flights to missions:
+
+- **Leg → Flight**: Completion status, discovered complexity, blockers (captured in flight log)
+- **Flight → Mission**: Progress on success criteria, new flight needs
+
+### Downward Feedback
+
+Guidance flows from missions to flights to legs:
+
+- **Mission → Flight**: Priority changes, constraint updates
+- **Flight → Leg**: Design decisions, context updates, flight log history
+
+### Adaptation
+
+When circumstances change:
+
+1. **Leg-level**: Block the leg, create new leg
+2. **Flight-level**: Divert the flight, re-plan
+3. **Mission-level**: Adjust success criteria or abort
+
+## Handling Diversions
+
+### When to Divert vs. Create New Flight
+
+**Divert the current flight when:**
+- The objective remains the same but the approach must change
+- External factors (security issues, API changes) invalidate the current plan
+- Discovered complexity requires re-planning but the goal is unchanged
+
+**Create a new flight when:**
+- A completely new objective emerges
+- The discovered work is independent of the current flight's goal
+- The new work serves different mission success criteria
+
+### In-Flight Modifications
+
+Flights can be modified while `in-flight` — for example, when planned legs need to change due to discoveries during execution. Update the flight artifact and record the change and rationale in the flight log.
+
+### Flight Abortion
+
+When a flight must be cancelled, changes are rolled back:
+
+```markdown
+## Status: aborted
+
+**Reason**: Security audit revealed JWT vulnerability requires a fundamentally different approach
+**Changes**: Rolled back — new flight will be created for Auth0 integration
+```
+
+### Mission Abortion
+
+Sometimes missions should be cancelled:
+
+```markdown
+## Status: aborted
+
+**Reason**: Business pivot - authentication now handled by parent company SSO
+**Learning**: Coordinate with enterprise architecture earlier
+**Artifacts**: Account creation flight code preserved in branch for reference
+```
+
+Document the reason for future reference.
+
+## State Summary
+
+### All States in One View
+
+```
+MISSION STATES
+planning ──► active ──► completed
+                │
+                └──► aborted
+
+FLIGHT STATES
+planning ──► ready ──► in-flight ──► landed ──► completed
+                           │
+                           └──► aborted
+
+LEG STATES
+planning ──► ready ──► in-flight ──► landed ──► completed
+                           │
+                           └──► aborted
+```
+
+## When to Create vs. Modify
+
+### Create New
+
+- **Mission**: New outcome needed
+- **Flight**: New area of work identified
+- **Leg**: Requirements changed after `in-flight`
+
+### Modify Existing
+
+- **Mission**: Refining success criteria during `planning`
+- **Flight**: Updating during `planning` phase
+- **Leg**: Only while `planning` (before work begins)
+
+### Rule of Thumb
+
+Once work begins, create new rather than modify. This preserves history and prevents confusion about what was actually requested.
+
+## Quick Reference
+
+| Phase | Mission State | Flight State | Leg State | Action |
+|-------|---------------|--------------|-----------|--------|
+| Defining outcomes | planning | — | — | — |
+| Planning first flight | planning | planning | — | — |
+| Pre-flight complete | planning | ready | — | — |
+| Designing first leg | active | in-flight | planning | — |
+| Leg design approved | active | in-flight | ready | — |
+| Executing leg | active | in-flight | in-flight | — |
+| Leg implementation done | active | in-flight | landed | — |
+| Leg reviewed | active | in-flight | completed | — |
+| Flight done | active | landed | — | — |
+| Flight debriefed | active | completed | — | `/flight-debrief` |
+| All flights done | completed | — | — | `/mission-debrief` |

container/mission-control/projects.md.template

@@ -0,0 +1,29 @@
+# Projects Registry
+
+This file catalogs all active projects to provide context for mission, flight, and leg planning.
+
+Copy this file to `projects.md` and fill in your project details.
+
+---
+
+## example-project
+
+**Description**: Brief description of what this project does.
+
+| Property | Value |
+|----------|-------|
+| Path | `/path/to/project` |
+| Remote | `git@github.com:username/repo.git` |
+| Stack | (optional) Key technologies used |
+| Status | (optional) Current state of the project |
+
+---
+
+## another-project
+
+**Description**: Another project description.
+
+| Property | Value |
+|----------|-------|
+| Path | `/path/to/another-project` |
+| Remote | `git@github.com:username/another-repo.git` |