docs: prod ran a mission, and the whole chain held

`ClawHDF5` and `JEPA Research` were launched from the UI. The first completed,
and everything shipped over the previous two passes engaged correctly on its
first execution anywhere outside the local stack:

  skills door   installed — api_origin() derived the host from the server's
                own container id, which had never run where it was not tested
  staffing      Topic Research, 3 roles / 4 deliveries, not rust_sdlc's 5 / 14
  drain         92 tool calls
  attribution   92 of 92, across a phase with TWO passes and six turns — the
                case attribute_sessions had never met, and it attributes
                nothing at all unless the counts match exactly
  boundary      all 8 Write/Edit paths under /mission/repo
  arm           inline, 0 retrievals; prod leaves the env unset
  judge         pass 0 met=false "zero URLs — grep -c http returns 0"
                pass 1 met=true  "57 http references"

The judge line is the one worth rereading: the loop converged on the exact
mechanically-checked defect it named, and pass 0 would otherwise have shipped
a report whose every claim was unattributed while reporting `completed`.

Two traps recorded rather than smoothed over:

- The drain selects phases `IN ('completed','failed')`, so a phase on its
  second pass shows zero tool calls and reads as broken while being correct.
- I reused a diagnostic query with no `WHERE mission_id`. That was fine while
  prod held one mission and silently wrong the moment a second launched — it
  compared one mission's tap against two missions' events. The production
  drain query is correctly scoped; the diagnostic was not.

Unexplained: one agent called the `Agent` tool 4 times. Mission agents are
spawning subagents and nothing in our design accounts for it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/NEXT-SESSION.md

@@ -200,15 +200,30 @@ cannot see. gw-05 and web-01 have no fail2ban and `sudo` there needs a password.
 
 ## Next, in order
 
-1. **Watch the first production mission.** Everything below the fold in this
+1. ~~**Watch the first production mission.**~~ **Done — 2026-08-25.** Two were
-   document is now deployed and unexercised in prod, because prod has still
+   launched from the UI (`ClawHDF5`, `JEPA Research`); `ClawHDF5` completed and
-   never run a mission. The door, the staffing, the attribution and the orphan
+   every mechanism from the previous two passes fired correctly the first time.
-   sweep all engage on the next launch. Prod auth is Clerk, so somebody has to
-   click.
 
-   ```
+   | | |
-   ssh gw-04 'docker logs clawmates_server_1 2>&1 | grep -E "skills door installed|drained .* tool call|orphans:"'
+   |---|---|
-   ```
+   | skills door | installed — `api_origin()` derived the host from the server's own container id, first run outside where it was tested |
+   | staffing | `Topic Research`, 3 roles, 4 deliveries (not `rust_sdlc`'s 5/14) |
+   | tap drain | **92** tool calls |
+   | attribution | **92 of 92**, across a phase with TWO passes and six turns |
+   | boundary | all 8 `Write`/`Edit` paths under `/mission/repo` |
+   | delivery arm | `inline`, 0 retrievals — correct, prod leaves the env unset |
+   | judge | pass 0 `met=false` *"zero URLs — `grep -c http` returns 0"*; pass 1 `met=true` *"57 http references"* |
+
+   Two traps it surfaced. **The drain waits for the PHASE, not the pass** —
+   a phase on its second pass reports `tool.call = 0` and looks broken while
+   being correct. And **an unfiltered diagnostic query is a time bomb**: a
+   `select ... from mission_events` with no `WHERE mission_id` was fine while
+   prod held one mission and silently wrong the moment a second launched. The
+   real drain is `WHERE phase_id = $1`; the sloppiness was in the diagnostic.
+
+   Unexplained and worth a look: one agent called the **`Agent` tool 4 times**.
+   Mission agents are spawning subagents, which nothing in our design accounts
+   for.
 
 2. ~~**Measure Trigger properly.**~~ **Done — 2026-08-25.** `skill_delivery`
    ships both arms; `index` sends name + `when_to_use` + a uri and the agent