# Mission Pilot Runbook

This runbook captures the current recommended way to test mission-driven issue delivery using the existing Claude/Codex issue workflow.

## Goal

Use a mission as the top-level orchestrator and use the existing issue delivery workflow as the execution backend for each mission item.

Current execution backend:

- `./examples/workflows/local_claude_codex_issue_delivery.yaml`

Current pilot issues:

- `#1179` unify runtime version metadata
- `#1180` validate assistant-facing docs and AI artifacts

## Current Constraints

Mission v1 can launch workflow-backed items, but it does not yet have a clean first-class way to assign per-item workflow inputs like `issue_number` during mission creation.

Because of that, the cleanest pilot today is:

1. Create the mission with the correct item graph.
2. Patch the mission so each item carries the correct workflow binding and `issue_number`.

This limitation is tracked by:

- `#1187` support structured workflow bindings on mission items
- `#1188` add retry and requeue controls for failed mission items
- `#1189` show linked workflow execution details in mission status

## Pilot Shape

- One GitHub issue = one mission item
- One mission item = one run of the issue delivery workflow
- One mission = orchestration over the issue portfolio

Dependencies:

- `#1180` depends on `#1179`

## Step 1: Create The Pilot Mission

Run:

```bash
aroom mission create \
  --adapter workflow \
  --workflow-path ./examples/workflows/local_claude_codex_issue_delivery.yaml \
  --prompt "$(cat <<'EOF'
Create a mission plan with exactly these two items and no others.

Title: Mission Delivery Pilot
Description: Prove mission-driven issue delivery on two bounded issues before scaling to the full refactor portfolio.

Item 1:
- summary: Deliver issue #1179 unify runtime version metadata
- temp_id: issue_1179
- priority: 10
- item_type: task
- depends_on: []

Item 2:
- summary: Deliver issue #1180 validate assistant-facing docs and AI artifacts
- temp_id: issue_1180
- priority: 20
- item_type: task
- depends_on: [issue_1179]

Requirements:
- keep the plan to exactly these two items
- preserve the temp_id values exactly
- preserve the dependency exactly
- do not add planning, review, or extra placeholder items
EOF
)" \
  --launch
```

Record the returned mission session ID.

## Step 2: Patch In Workflow Inputs

Replace `<session_id>` and run:

```bash
aroom mission update <session_id> \
  --instruction "$(cat <<'EOF'
Apply only adapter-binding changes.

For the item whose summary is "Deliver issue #1179 unify runtime version metadata":
- set adapter_type to workflow
- set adapter_config to:
  workflow_path: ./examples/workflows/local_claude_codex_issue_delivery.yaml
  extra_inputs:
    issue_number: 1179

For the item whose summary is "Deliver issue #1180 validate assistant-facing docs and AI artifacts":
- set adapter_type to workflow
- set adapter_config to:
  workflow_path: ./examples/workflows/local_claude_codex_issue_delivery.yaml
  extra_inputs:
    issue_number: 1180

Do not add items.
Do not drop items.
Do not change priorities.
Do not change dependencies.
EOF
)"
```

## Step 3: Inspect The Mission

```bash
aroom mission status <session_id>
```

Useful follow-ups:

```bash
aroom mission revisions <session_id>
aroom mission talk <session_id>
```

## What This Pilot Proves

- mission planning and persistence
- dependency handling
- workflow-backed mission execution
- Claude implementation plus Codex review through the existing workflow
- mission-level visibility over the program

## What This Pilot Does Not Yet Prove

- first-class per-item workflow inputs
- retry and requeue
- rich mission status for linked workflow runs

Those gaps are expected in v1 and are the reason the mission-platform issues should be addressed before using mission as the control plane for the full refactor portfolio.
