Sync bundled mission-control to upstream 15fbc94

Pulls in 15 upstream commits since the April 3 bundling snapshot
(msieurthenardier/mission-control). Notable changes:

- agentic-workflow rewritten as the "fast" variant: per-leg design and
  implement, single review and commit across the whole flight
- New Skill-Project Boundary section: skills no longer read or write
  project-owned artifacts by literal heading
- routine-maintenance scoped to post-mission only; adds state-machine
  reachability and cache freshness audits
- Test metrics capture threaded through debrief, maintenance, and flight
- Crew prompts no longer carry skill-required instructions; SKILL.md is
  the protocol
- Worktree git strategy removed; standardized on {target-project}
- Jira artifact template removed upstream

Local URL correction in init-project/README.md preserved
(anthropics/flight-control -> msieurthenardier/mission-control).

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

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

@@ -1,11 +1,11 @@
 ---
 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.
+description: Active orchestrator for multi-agent flight execution. Drives leg design per leg, then batches implementation across all autonomous legs, with a single code review and commit at the end of the flight.
 ---
 
 # 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.
+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. Leg design is reviewed per leg, but code review and commit are deferred until after the last autonomous leg completes. This eliminates per-leg review/commit overhead while keeping the same leg design and implementation structure.
 
 ## Prerequisites
 
@@ -33,8 +33,6 @@ Example: `/agentic-workflow flight 03 for epipen mission 04`
 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.
 
@@ -46,13 +44,15 @@ If resuming a flight already in progress, verify state consistency:
 
 Repeat for each leg in the flight.
 
+**Mid-execution scope changes**: if the work in this flight stops serving its original purpose (operator pivots, prior assumptions invalidated), don't rewrite the mission/flight artifacts in place. Preserve the original framing as commentary, record the pivot decision in the flight-log Flight Director Notes with rationale, and treat the new framing as the live spec going forward. If the pivot supersedes content in an upstream artifact (maintenance report, prior debrief), annotate at the artifact header rather than rewriting the body — inspection records are snapshots, not living plans.
+
 ### 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}`
+   - Working directory: `{target-project}`
    - 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
@@ -71,41 +71,42 @@ Repeat for each leg in the flight.
 
 **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:
+**Interactive/HAT legs**: If the leg is a HAT (human acceptance test), alignment, or other interactive leg (identified by slug like `hat-*`, `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
+5. **Commit when all steps pass** — update artifacts and commit
 
-**Standard (autonomous) legs**: Follow the Developer/Reviewer cycle below.
+**Standard (autonomous) legs**: Spawn a Developer agent — but do NOT review or commit after each leg.
 
 1. **Spawn a Developer agent** (Task tool, `subagent_type: "general-purpose"`)
-   - Working directory: `{working-directory}`
+   - Working directory: `{target-project}`
    - 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`
+   - When done, the Developer updates leg status to `landed` and updates flight log — do NOT let it commit or signal `[HANDOFF:review-needed]`
 
 ### 2c: Leg Transition
 
-After `[COMPLETE:leg]` (all git/PR operations run from `{working-directory}`):
+After the Developer completes a leg:
 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
+2. If more autonomous legs remain → return to 2a
+3. If this was the last autonomous leg → proceed to Phase 2d
+
+### 2d: Flight Review and Commit
+
+After all autonomous legs are implemented (all uncommitted):
+
+1. **Spawn a Reviewer agent** (Task tool, `subagent_type: "general-purpose"`)
+   - Working directory: `{target-project}`
+   - 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
+2. **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
+3. **Commit** after review passes — include all code changes, updated flight log, and all leg statuses updated to `completed`
+4. **Manage PR**: Open a draft PR with the leg checklist in the body (see PR Body Format below), all legs checked off
 
 ## Phase 3: Flight Completion
 
@@ -114,8 +115,7 @@ After `[COMPLETE:leg]` (all git/PR operations run from `{working-directory}`):
 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]`**
+6. **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`.
 
@@ -141,33 +141,20 @@ Signals are part of the Flight Control methodology and are NOT configurable per-
 
 ## 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.
+Log orchestration decisions in the flight log under `### Flight Director Notes` — phase file loaded, agents spawned, review-cycle calls, escalations, signal interpretations. Anyone reading the log should understand not just what the crew did but why MC made the 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.
+All agents work in the target project root on a feature branch created at flight start.
 
 **Branch naming**: `flight/{number}-{slug}`
 
+**Flight start**: `git checkout -b flight/{number}-{slug}`
+
 **Commit message format:**
 ```
-leg/{number}: {description}
+flight/{number}: {description}
 
-Flight: {flight-number}
 Mission: {mission-number}
 ```
 
@@ -175,8 +162,7 @@ Mission: {mission-number}
 
 | Event | Action |
 |-------|--------|
-| First leg complete | Open draft PR with leg checklist in body |
-| Each leg complete | Commit code + artifacts, update PR checklist |
+| All legs complete | Open draft PR with all legs checked off |
 | Flight landed | Mark PR ready for review |
 
 **PR body format:**
@@ -190,35 +176,10 @@ Mission: {mission-number}
 
 ## Legs
 
-- [ ] `{leg-slug}` — {brief description}
-- [ ] `{leg-slug}` — {brief description}
+- [x] `{leg-slug}` — {brief description}
+- [x] `{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 |
@@ -229,5 +190,4 @@ Worktree isolation enables parallel flights on a single repo clone.
 | 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 |