flow-workflows 0.67.0 → 0.69.0

package/README.md

@@ -263,6 +263,7 @@ Ordered by effect. Each is one line in `FLOW.md`:
 
 | Change | What it drops | What you lose |
 |---|---|---|
+| `models.supervisors` to a cheaper tier | The waits — a running pipeline, a deploy that has not landed, a long suite — stop being watched on the thread's model | Nothing: a supervisor reports status and evidence, and the verdict on them was never its to give |
 | `models.agents` / `models.workers` to a cheaper tier | Subagents stop running on the thread's model | Little: a subagent reads a diff and reports ≤250 words |
 | `quality.review_depth: light` | The panel, the reinforcements, the skeptic fan-out | Depth on everything but the built-in reviewer; a sensitive surface still bumps back up |
 | `agents.budget_max`, `agents.fanout_max` | Rounds past the ceiling, in the order each command declares | Coverage — but named coverage: what a ceiling skipped is reported, never silently dropped |

package/adapters/codex/CORE.md

@@ -17,7 +17,7 @@ Every `$flow-*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.67.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.69.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -65,6 +65,15 @@ a command relies on is simply absent in that session, and nothing else will repo
   base branch — and goes out in no MR/PR at all. So a phase writing a tracked file writes it
   **here**, in the directory it is running in, and `$flow-feat-ship §5.5` is what catches the
   tools that could not be told.
+- **A fenced block in a FLOW file is an example, and an example is not configuration.** These
+  files are prose with keys in them, and the rule that decides what a key *is* — a `- key:` line
+  under a `## section` — knows nothing about triple backticks. So a block written to be pasted
+  ("add this to try it once") was read as the configuration it illustrates, for as long as it sat
+  there. It happened in a real repo: `agents.exec_cmd` came from the fenced example of a file whose
+  prose argued at length that it was deliberately unset, and every review round took the one-shot
+  path that prose warned against — with nothing anywhere to say so, because the file and the
+  configuration disagreed while both looked right. **Skip fenced regions when you read a FLOW
+  file**; `flow-workflows` does the same, so the two of you resolve the same config.
 - Merge by section and key. A key present in the active overlay replaces the base value; a key
   absent there inherits the base. **A present-but-empty overlay key masks the base** and resolves
   to the normal empty-key fallback — this is how Codex can inherit its session model while a legacy
@@ -143,10 +152,10 @@ explicit rather than degrading in silence.
 
 ## 1. Models — which model runs a step
 
-Two keys, and they govern **subagents only**: `models.agents` for every subagent a command
-improvises, `models.workers` for the parallel fan-out rounds (falling back to `models.agents`).
-Empty, absent, or no section → everything runs on the model you were launched with, and you say
-nothing.
+Three keys, and they govern **subagents only**: `models.agents` for every subagent a command
+improvises, `models.workers` for the parallel fan-out rounds, and `models.supervisors` for the
+bounded waits of §6.5 — the last two falling back to `models.agents`. Empty, absent, or no section
+→ everything runs on the model you were launched with, and you say nothing.
 
 - Pass the resolved value to every subagent you launch, **except** an agent named in `agents.<role>`,
   which keeps the model its own definition sets.
@@ -170,6 +179,11 @@ Agents named in `agents.<role>` are the exception here as above: they keep whate
 definition sets, so a round can mix inherited and self-declared models. Report which, not whether it
 was wise.
 
+**A delegated wait says the same line at one agent.** A round of fifteen and a single supervisor
+sitting on a forty-minute pipeline are the same blank cheque arriving at different speeds. So when a
+wait is dispatched (§6.5) with `models.supervisors` and `models.agents` both empty, say it in one
+line: the wait inherits this thread's model because no key is set. Name the key, never a model.
+
 ## 2. Autonomy — `autonomy.mode`
 
 `manual` (default) · `guided` · `auto`. Read it once and apply it throughout the command.
@@ -200,6 +214,10 @@ sensible default and record it.
 - (c) **Continuing to the next MR/PR of a train** — asked in `manual`, taken and recorded in `guided`/`auto`.
 - (d) **Size confirmation** — take the proposed size, record it, move on.
 - (e) **Anything already decided and recorded** in the work's artifacts or `meta.json.notes`. Reopen only when new evidence contradicts the premise — then lead with the evidence.
+- (f) **Delegating a wait** (§6.5) — handing a running pipeline, a deploy that has not landed or a
+  long suite to a supervisor is mechanics, and the cost objection to waiting is exactly what the
+  delegation removes. Take it, record it. What is still asked in `manual` is whatever the evidence
+  turns out to call for, once it is back.
 
 Asking these anyway is how an unattended run degrades into a manual one.
 
@@ -398,6 +416,48 @@ magnitude over what anyone intended.
 - **The cost is reported where the user reads it**, as `spent/budget`: a phase silently skipped for
   budget and a phase that found nothing are not the same result.
 
+### 6.5 — A wait is delegated, never sat through
+
+**Waiting is not a phase, and on this thread it is not free.** A pipeline polled from here charges
+the whole conversation for every cycle that reads `pending`: the context is resent, the model
+reasons about a state that has not moved, and a forty-minute suite costs more to *watch* than the
+diff it is checking cost to write. The expense was never the waiting — it is who does it.
+
+So a wait you expect to run **longer than a few minutes** goes to **one supervisor subagent**, with
+a brief closed at both ends:
+
+- **What to watch** — the exact command, run id or resource, never "the CI".
+- **How often, and until when** — the interval, and a deadline after which it returns what it has
+  instead of waiting forever.
+- **Every terminal state** — success *and* failure, so it neither comes back at the first red job
+  with three still running, nor sits out a queue that will never move.
+- **What it brings back** — status (`finished` · `failed` · `timed out`), and the evidence for it:
+  job names, exit codes, the log tail that matters, the run URL, the SHA it watched. Plus the path
+  it writes before replying, exactly like any other brief.
+
+**It reports; it never rules.** The supervisor says which job failed and hands you the log. It does
+not decide that the failure is flaky, that the threshold is close enough, or that the branch can
+merge now. Delegating that judgement is how a pipeline ends up declared green by whoever was
+cheapest to ask, which is the one thing `$flow-work-green` exists to forbid. Delegate the waiting
+and the evidence; the verdict stays here.
+
+**Then end the turn.** Dispatching a supervisor and staying in a poll loop of your own pays both
+bills and saves nothing. What wakes you is whatever the harness offers — a background task that
+re-invokes you when it finishes, a scheduled wake-up, a message back to this thread; where it offers
+none, the supervisor's evidence file is read at your next stop, and **you say that** rather than
+implying something is being watched. Refresh `panel.json` before you go (§4): the line carries
+`mark: "wait"` and `stale_after_minutes` set to the deadline you gave, because a thread that goes
+quiet with `current` on screen reads as a session that died.
+
+**A supervisor is a subagent** — it runs on `models.supervisors` (empty → `models.agents`, then what
+this thread runs on), and it counts against `agents.budget_max` like any other, relaunches included.
+Bound it with the deadline instead of relaunching a wait that has already told you the queue is not
+moving.
+
+**Not every wait is worth a brief.** A suite that finishes in ninety seconds costs more to delegate
+than to run — the brief, the round trip and the report are the whole of the saving. And anything you
+must *react to* mid-wait is not a wait at all: it is the work, and it stays here.
+
 ## 7. Deferred work — `followups[]`
 
 Every chain in this plugin reaches moments where the right call is **not to do it here**: a build

package/adapters/codex/skills/flow-bug-ship/SKILL.md

@@ -25,7 +25,7 @@ Close the bug flow: commit, push, MR/PR. Same mechanics as `$flow-feat-ship`, wi
 
 ## 0. Pre-flight
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 - Read `meta.json` and `00-summary.md`; open in full only `04-fix.md` (the Brief), `06-review.md` (the verdict), `05-validation.md`, the §"Root cause identified" of `03-investigation.md`, and `99-postmortem.md` if it exists. (flow-core §5)
 - Require `review` in `phases_done`; also `validate` if `size` ≥ S, and `postmortem` if `size` is M or L (the same sizes `$flow-bug-review §8` routes to postmortem — one rule). Missing → refuse and redirect to the missing step.
@@ -160,6 +160,8 @@ Assign to `git.assignee` from FLOW.md (empty → unassigned). Squash per `git.sq
 
 **Record the URL the moment it exists**: write it into `meta.json` (the `mrs` entry if there is one) and refresh `panel.json` (flow-core §4) right here, before §3.2 and before anything else can fail.
 
+**The pipeline the push starts is not watched from this thread — `$flow-feat-ship` §4.1, in full and unchanged**: close with CI reported as *running*, or delegate the wait to a supervisor subagent on `models.supervisors` (flow-core §6.5) with a deadline, taking back status and failing-job evidence only. A red pipeline is `$flow-work-green`'s to triage, never this command's.
+
 ### 3.2 Pre-deploy thread (deployment gate)
 **Only if `git.predeploy_gate` is active and the fix has pre-deploy SQL** (§1). After creating the MR/PR, open **a single resolvable/blocking thread** with all the consolidated SQL, using the host from `git.host`/`git.cli` (GitLab: `glab api ".../merge_requests/<iid>/discussions"`; GitHub: review conversation with required resolution). Body: the SQL block under "Pre-deploy: run this SQL on the server BEFORE deploying" + "Resolve only after running it in production".
 

package/adapters/codex/skills/flow-bug-validate/SKILL.md

@@ -22,7 +22,7 @@ Validate that the fix works and that the bug does not return.
 
 ## 1. Pre-flight
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 - Read `meta.json` and `00-summary.md`; open in full only `03-investigation.md` (§3 areas with similar risk, and the minimal reproduction) — the testing agent reads it and `04-fix.md` itself. (flow-core §5)
 - Require `fix` in `phases_done`.
@@ -37,7 +37,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 Then:
 1. Run only that test with `quality.test_one` from FLOW.md; it must pass.
-2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow; measured in tens of minutes → delegate it as a wait to a supervisor subagent on `models.supervisors`, flow-core §6.5 — it returns the exit code and the failing output, and the reading of them stays here).
 3. DB touched → verify the schema has no unexpected differences (`quality.db_update` or the FLOW.md equivalent, if defined).
 4. Security or authentication touched → launch the `agents.security` agent from FLOW.md in parallel over the fix files (empty → `Agent general-purpose` with a security role).
 

package/adapters/codex/skills/flow-doctor/SKILL.md

@@ -78,15 +78,17 @@ is invalid.
 
 #### 1.5.2 Resolved models (only if either file has a `models` key)
 
-Two keys, both about subagents. Print what each one actually reaches:
+Three keys, all about subagents. Print what each one actually reaches:
 
 ```
-agents   fable    →  improvised subagents: review panel members with no named agent, blinded
-                     auditors, delegated build pieces, the general-purpose challenger
-workers  (empty)  →  fan-out rounds — falls back to `agents`
+agents       fable    →  improvised subagents: review panel members with no named agent, blinded
+                         auditors, delegated build pieces, the general-purpose challenger
+workers      (empty)  →  fan-out rounds — falls back to `agents`
+supervisors  (empty)  →  the delegated waits (running pipeline, pending deploy, long suite) —
+                         falls back to `agents`
 ```
 
-- State once, plainly: **the main agent's own steps are not covered by either key** — reading the
+- State once, plainly: **the main agent's own steps are not covered by any key** — reading the
   ticket, the design, and the single-thread `build`/`fix` run on the model the command was launched
   with, because an agent cannot switch its own model. A phase that wants another one says so at the
   handoff; nothing enforces it.
@@ -129,6 +131,10 @@ Whether the world they describe exists —
 CLIs installed *and authenticated*, agents discoverable, hooks executable, the MCP reachable, the
 base branch resolvable — is §2 below; flag the key here, check the world there, never both.
 
+- **Keys inside a fenced block**: report them, one line, naming the file and the keys — they are
+  an example and resolve to nothing (flow-core §0), which is exactly what a reader who pasted a
+  block to enable it cannot tell from a key that works. Say what to do about it: move the line out
+  of the fence to make it real, leave it there to keep it an illustration.
 - **Fan-out and cost ceilings**: `agents.fanout_max` must be a positive integer; else flag and note
   the default `4` applies. `agents.budget_max` must be a non-negative integer (`0` = no ceiling);
   else flag and note the default `12`. **Both absent → say so as a finding, not a pass**: the review

package/adapters/codex/skills/flow-feat-ship/SKILL.md

@@ -18,7 +18,7 @@ description: "Commit, push, MR/PR, and offer to save domain knowledge"
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `[mcp_servers.<name>]` in `config.toml` (see `config.snippet.toml`).
 > - `$ARGUMENTS` → whatever the user typed after the skill name, empty if nothing — Codex substitutes nothing, so read it off their message.
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 Closes the feature: commit, push, MR/PR (assigned per `git.assignee`, squash per `git.squash`, sections per `git.request_sections`) and an optional offer to consolidate knowledge.
 
@@ -181,6 +181,8 @@ Only here — with the content approved in §3 — invoke `Skill commit-commands
 
 **Record the URL the moment it exists**: write it into this MR/PR's `meta.json.mrs` entry and refresh `panel.json` right here, before §4.2 and before anything else can fail.
 
+**The push just started a pipeline, and this thread does not sit on it.** Its result belongs to `$flow-work-green`, not here, so either close the ship with CI reported as *running* — the honest state — or, when the user wants to hear how it ended, delegate the wait as any other (flow-core §6.5): one supervisor subagent on `models.supervisors`, a deadline, and back with status plus failing-job evidence. Whatever it returns, a red pipeline is triaged by `$flow-work-green`; this command never fixes CI and never closes reporting a green it did not see.
+
 ### 4.2 Pre-deploy thread (deployment gate)
 **Only if `git.predeploy_gate` is active and the branch has pre-deploy SQL** (§2). After creating the MR/PR, open **a single resolvable/blocking thread** with **all** the consolidated SQL, using the `git.host`/`git.cli` host:
 - **GitLab**: `glab api "projects/<repo-url-encoded>/merge_requests/<iid>/discussions" -f body="..."` (resolvable thread).

package/adapters/codex/skills/flow-feat-validate/SKILL.md

@@ -18,7 +18,7 @@ description: "Validate tests, edge cases, and integrity before shipping"
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `[mcp_servers.<name>]` in `config.toml` (see `config.snippet.toml`).
 > - `$ARGUMENTS` → whatever the user typed after the skill name, empty if nothing — Codex substitutes nothing, so read it off their message.
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 Verify the feature is complete: test coverage, edge cases, performance, regressions.
 
@@ -42,7 +42,7 @@ One of the three below writes and two of them read, so they do not all go at onc
 
    **A green suite is not a performance result** — a tiny fixture database proves a query's **rows**, never its **plan**. If `$flow-feat-review §3.6` left any query verdict `unresolved`, or an acceptance criterion concerns speed or volume: run the measurement of **`$flow-work-query §4`** with the volumes in `data.volumes` (or a data set shaped like them — the distribution matters more than the total), record plan and timings, and gate on the result. No `data.*` configuration and the criterion cannot be measured → it is `unproven` with the reason, never silently `proven`.
 
-3. **Full suite**: run `quality.test` from `FLOW.md` in the background; if empty, auto-discover the project's test command and note what you use. A repo with more than one suite chains them in that one key (`make test && make test-frontend`); when it does not and the diff touches a suite the key misses, run that one too and say so in one line.
+3. **Full suite**: run `quality.test` from `FLOW.md` in the background; if empty, auto-discover the project's test command and note what you use. **A suite measured in tens of minutes is a wait, not a step**: hand it to a supervisor subagent on `models.supervisors` (flow-core §6.5) — it runs it, times out, and brings back the exit code plus the failing tests' output, never a reading of whether those failures matter. Short suites stay here; delegating ninety seconds costs more than running them. A repo with more than one suite chains them in that one key (`make test && make test-frontend`); when it does not and the diff touches a suite the key misses, run that one too and say so in one line.
 
 ## 3. Criteria coverage (S and larger)
 

package/adapters/codex/skills/flow-work-green/SKILL.md

@@ -32,7 +32,7 @@ Usage: `$flow-work-green [mr-iid-or-url]` — optional; default is the MR/PR of
 
 Extract from `git`: `host`, `cli` (empty → the default for that host), `default_base`. The term MR/PR follows `host`. From `tracker`: `tool`, `prefix`. From `quality`: `test`, `test_one`, `static_analysis`, `style_fix` (local reproduce/verify commands, §5; empty → auto-discover from Makefile / npm / composer scripts), `review_skill` (§5, non-trivial fixes). `agents`: expert sub-agents to delegate fixes to. `knowledge.search` set → `knowledge.search` in §3.
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 **Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
 1. **Any push** (§6).
@@ -82,7 +82,7 @@ Decide the exit on the **combination** of both halves, never on the pipeline alo
 
 - **Pipeline green *and* verdict mergeable** → report both facts, stop.
 - **Pipeline green but blockers remain** → do **not** report "green, you're good": report the pipeline green, list the blockers, continue to §3 with them.
-- **Pipeline running / pending** → offer to **wait** (poll with `Monitor`, or `ScheduleWakeup` every ~2–3 min; with neither tool, say so and let them re-run when CI finishes) or stop and re-run later. Meanwhile work on any **non-pipeline** blockers.
+- **Pipeline running / pending** → **delegate the wait** (flow-core §6.5): one supervisor subagent on `models.supervisors`, told which run to watch, at what interval, with a deadline and every terminal state, bringing back status **plus evidence** (failing job names, exit codes, log tail, run URL) and **no verdict** — the triage of §3 is this thread's, whatever it reports. Then work any **non-pipeline** blockers meanwhile, or end the turn on the harness's own wake-up (a background task that re-invokes you, `Monitor`, `ScheduleWakeup` ~2–3 min). Neither a supervisor nor a wake-up available → say so plainly and let the user re-run when CI finishes; never imply the pipeline is being watched when nothing is watching it.
 - **Pipeline never ran** (no CI, or not triggered) → say so; verdict clean too → stop.
 
 ## 3. Triage every blocker
@@ -144,7 +144,7 @@ Run **before** the other buckets, only after the hard gate:
 
 - **Push (hard gate).** Show what will be pushed (files, commit message), confirm with `AskUserQuestion`. Never push to the base branch: HEAD must not be `git.default_base` and its upstream must point to the branch itself (same anti-deploy lock as `$flow-feat-ship §4.0` and `$flow-work-respond §6.2`). `git push` to the existing branch — the push re-triggers the pipeline. **Force-push only after a rebase the user explicitly chose** (§5.C.2), and only `git push --force-with-lease` — never bare `--force`, never as a way out of a rejected push (the remote moved: fetch and understand first).
 - **Rerun without a push** (rerun-only, K). Only after the user confirms (hard gate): `glab ci retry` / `gh run rerun <run-id> --failed`. Attach the recorded flake evidence. Fails again the same way → **not** flaky: reclassify to T/Y and fix; do not rerun a second time.
-- **Watch it back to green.** Offer to monitor (`Monitor`, or `ScheduleWakeup` every ~2–3 min; with neither, say so instead of implying it is watched) and report when green — or let a later `$flow-work-green` re-check. Do not claim the pipeline is fixed until it reports green: report what you pushed and that CI is re-running.
+- **Watch it back to green — delegated, not polled from here** (flow-core §6.5). The push starts a run that takes as long as the one you just triaged: hand it to the same kind of supervisor as §2.3 and end the turn, or let a later `$flow-work-green` re-check. With neither a supervisor nor a wake-up, say so instead of implying it is watched. Do not claim the pipeline is fixed until it reports green: report what you pushed and that CI is re-running.
 - **Re-read the merge verdict too.** Once the pipeline settles, re-run §2.1 and report the *merge* verdict, not only the pipeline — the only evidence the MR/PR is actually mergeable.
 
 ## 7. Log, loop, and domain knowledge

package/adapters/codex/skills/flow-work-watch/SKILL.md

@@ -18,7 +18,7 @@ description: "Monitor the observability platform after a deploy and alert on err
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `[mcp_servers.<name>]` in `config.toml` (see `config.snippet.toml`).
 > - `$ARGUMENTS` → whatever the user typed after the skill name, empty if nothing — Codex substitutes nothing, so read it off their message.
 
-Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 **Autopiloted post-deploy monitoring**: signals **scoped to the change** over a window (default 30 min), against a baseline; alert on errors or performance regressions from the deploy.
 
@@ -47,7 +47,7 @@ If `knowledge.search` is set, call `knowledge.search` with the ticket name befor
 - **Confirm WHAT is being deployed — never assume it from `meta.json`** (several MR/PRs per ticket; stale artifacts). Cross-reference the **actual deploy event** (e.g. `get_change_stories`) and recent merges; any ambiguity → `AskUserQuestion` which MR/PR or commit is deploying. The surface (§2) is scoped to **that** change.
 - **When to start.** When the code **is live in production**, not at merge. Launched right after the merge → **wait for the deploy yourself**:
   - Check whether the new version is live (`observability.deploy_detect`; empty → `get_change_stories` or other deploy indicators).
-  - **Not yet deployed** → poll every ~2-3 min until it appears. Do not start the window.
+  - **Not yet deployed** → **delegate the wait** (flow-core §6.5): one supervisor subagent on `models.supervisors` watching for the go-live of that exact SHA, ~2-3 min interval, a deadline, and back with status plus evidence (pipeline/job names, exit codes, the deploy event) — never with a judgement on whether the deploy is healthy. No supervisor available → poll every ~2-3 min here and say that this thread is doing the waiting. Either way the monitoring window does not start until the code is live.
   - **Pipeline fails** → **abort monitoring** and alert: the code did not reach production.
   - Already deployed → proceed.
 - **How to identify YOUR deploy.** The chain in `observability.deploy_detect`. Empty → merge to base branch → CI/CD pipeline → go-live jobs. Determine the exact merge commit; confirm the go-live jobs of the affected services reach `success`. Any fail → **abort**.

package/adapters/gemini/CORE.md

@@ -16,7 +16,7 @@ Every `/flow:*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.67.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.69.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -64,6 +64,15 @@ a command relies on is simply absent in that session, and nothing else will repo
   base branch — and goes out in no MR/PR at all. So a phase writing a tracked file writes it
   **here**, in the directory it is running in, and `/flow:feat:ship §5.5` is what catches the
   tools that could not be told.
+- **A fenced block in a FLOW file is an example, and an example is not configuration.** These
+  files are prose with keys in them, and the rule that decides what a key *is* — a `- key:` line
+  under a `## section` — knows nothing about triple backticks. So a block written to be pasted
+  ("add this to try it once") was read as the configuration it illustrates, for as long as it sat
+  there. It happened in a real repo: `agents.exec_cmd` came from the fenced example of a file whose
+  prose argued at length that it was deliberately unset, and every review round took the one-shot
+  path that prose warned against — with nothing anywhere to say so, because the file and the
+  configuration disagreed while both looked right. **Skip fenced regions when you read a FLOW
+  file**; `flow-workflows` does the same, so the two of you resolve the same config.
 - Merge by section and key. A key present in the active overlay replaces the base value; a key
   absent there inherits the base. **A present-but-empty overlay key masks the base** and resolves
   to the normal empty-key fallback — this is how Codex can inherit its session model while a legacy
@@ -142,10 +151,10 @@ explicit rather than degrading in silence.
 
 ## 1. Models — which model runs a step
 
-Two keys, and they govern **subagents only**: `models.agents` for every subagent a command
-improvises, `models.workers` for the parallel fan-out rounds (falling back to `models.agents`).
-Empty, absent, or no section → everything runs on the model you were launched with, and you say
-nothing.
+Three keys, and they govern **subagents only**: `models.agents` for every subagent a command
+improvises, `models.workers` for the parallel fan-out rounds, and `models.supervisors` for the
+bounded waits of §6.5 — the last two falling back to `models.agents`. Empty, absent, or no section
+→ everything runs on the model you were launched with, and you say nothing.
 
 - Pass the resolved value to every subagent you launch, **except** an agent named in `agents.<role>`,
   which keeps the model its own definition sets.
@@ -169,6 +178,11 @@ Agents named in `agents.<role>` are the exception here as above: they keep whate
 definition sets, so a round can mix inherited and self-declared models. Report which, not whether it
 was wise.
 
+**A delegated wait says the same line at one agent.** A round of fifteen and a single supervisor
+sitting on a forty-minute pipeline are the same blank cheque arriving at different speeds. So when a
+wait is dispatched (§6.5) with `models.supervisors` and `models.agents` both empty, say it in one
+line: the wait inherits this thread's model because no key is set. Name the key, never a model.
+
 ## 2. Autonomy — `autonomy.mode`
 
 `manual` (default) · `guided` · `auto`. Read it once and apply it throughout the command.
@@ -199,6 +213,10 @@ sensible default and record it.
 - (c) **Continuing to the next MR/PR of a train** — asked in `manual`, taken and recorded in `guided`/`auto`.
 - (d) **Size confirmation** — take the proposed size, record it, move on.
 - (e) **Anything already decided and recorded** in the work's artifacts or `meta.json.notes`. Reopen only when new evidence contradicts the premise — then lead with the evidence.
+- (f) **Delegating a wait** (§6.5) — handing a running pipeline, a deploy that has not landed or a
+  long suite to a supervisor is mechanics, and the cost objection to waiting is exactly what the
+  delegation removes. Take it, record it. What is still asked in `manual` is whatever the evidence
+  turns out to call for, once it is back.
 
 Asking these anyway is how an unattended run degrades into a manual one.
 
@@ -397,6 +415,48 @@ magnitude over what anyone intended.
 - **The cost is reported where the user reads it**, as `spent/budget`: a phase silently skipped for
   budget and a phase that found nothing are not the same result.
 
+### 6.5 — A wait is delegated, never sat through
+
+**Waiting is not a phase, and on this thread it is not free.** A pipeline polled from here charges
+the whole conversation for every cycle that reads `pending`: the context is resent, the model
+reasons about a state that has not moved, and a forty-minute suite costs more to *watch* than the
+diff it is checking cost to write. The expense was never the waiting — it is who does it.
+
+So a wait you expect to run **longer than a few minutes** goes to **one supervisor subagent**, with
+a brief closed at both ends:
+
+- **What to watch** — the exact command, run id or resource, never "the CI".
+- **How often, and until when** — the interval, and a deadline after which it returns what it has
+  instead of waiting forever.
+- **Every terminal state** — success *and* failure, so it neither comes back at the first red job
+  with three still running, nor sits out a queue that will never move.
+- **What it brings back** — status (`finished` · `failed` · `timed out`), and the evidence for it:
+  job names, exit codes, the log tail that matters, the run URL, the SHA it watched. Plus the path
+  it writes before replying, exactly like any other brief.
+
+**It reports; it never rules.** The supervisor says which job failed and hands you the log. It does
+not decide that the failure is flaky, that the threshold is close enough, or that the branch can
+merge now. Delegating that judgement is how a pipeline ends up declared green by whoever was
+cheapest to ask, which is the one thing `/flow:work:green` exists to forbid. Delegate the waiting
+and the evidence; the verdict stays here.
+
+**Then end the turn.** Dispatching a supervisor and staying in a poll loop of your own pays both
+bills and saves nothing. What wakes you is whatever the harness offers — a background task that
+re-invokes you when it finishes, a scheduled wake-up, a message back to this thread; where it offers
+none, the supervisor's evidence file is read at your next stop, and **you say that** rather than
+implying something is being watched. Refresh `panel.json` before you go (§4): the line carries
+`mark: "wait"` and `stale_after_minutes` set to the deadline you gave, because a thread that goes
+quiet with `current` on screen reads as a session that died.
+
+**A supervisor is a subagent** — it runs on `models.supervisors` (empty → `models.agents`, then what
+this thread runs on), and it counts against `agents.budget_max` like any other, relaunches included.
+Bound it with the deadline instead of relaunching a wait that has already told you the queue is not
+moving.
+
+**Not every wait is worth a brief.** A suite that finishes in ninety seconds costs more to delegate
+than to run — the brief, the round trip and the report are the whole of the saving. And anything you
+must *react to* mid-wait is not a wait at all: it is the work, and it stays here.
+
 ## 7. Deferred work — `followups[]`
 
 Every chain in this plugin reaches moments where the right call is **not to do it here**: a build

package/adapters/gemini/commands/flow/bug/ship.toml

@@ -21,7 +21,7 @@ Close the bug flow: commit, push, MR/PR. Same mechanics as `/flow:feat:ship`, wi
 
 ## 0. Pre-flight
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 - Read `meta.json` and `00-summary.md`; open in full only `04-fix.md` (the Brief), `06-review.md` (the verdict), `05-validation.md`, the §"Root cause identified" of `03-investigation.md`, and `99-postmortem.md` if it exists. (flow-core §5)
 - Require `review` in `phases_done`; also `validate` if `size` ≥ S, and `postmortem` if `size` is M or L (the same sizes `/flow:bug:review §8` routes to postmortem — one rule). Missing → refuse and redirect to the missing step.
@@ -156,6 +156,8 @@ Assign to `git.assignee` from FLOW.md (empty → unassigned). Squash per `git.sq
 
 **Record the URL the moment it exists**: write it into `meta.json` (the `mrs` entry if there is one) and refresh `panel.json` (flow-core §4) right here, before §3.2 and before anything else can fail.
 
+**The pipeline the push starts is not watched from this thread — `/flow:feat:ship` §4.1, in full and unchanged**: close with CI reported as *running*, or delegate the wait to a supervisor subagent on `models.supervisors` (flow-core §6.5) with a deadline, taking back status and failing-job evidence only. A red pipeline is `/flow:work:green`'s to triage, never this command's.
+
 ### 3.2 Pre-deploy thread (deployment gate)
 **Only if `git.predeploy_gate` is active and the fix has pre-deploy SQL** (§1). After creating the MR/PR, open **a single resolvable/blocking thread** with all the consolidated SQL, using the host from `git.host`/`git.cli` (GitLab: `glab api ".../merge_requests/<iid>/discussions"`; GitHub: review conversation with required resolution). Body: the SQL block under "Pre-deploy: run this SQL on the server BEFORE deploying" + "Resolve only after running it in production".
 

package/adapters/gemini/commands/flow/bug/validate.toml

@@ -18,7 +18,7 @@ Validate that the fix works and that the bug does not return.
 
 ## 1. Pre-flight
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 - Read `meta.json` and `00-summary.md`; open in full only `03-investigation.md` (§3 areas with similar risk, and the minimal reproduction) — the testing agent reads it and `04-fix.md` itself. (flow-core §5)
 - Require `fix` in `phases_done`.
@@ -33,7 +33,7 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 Then:
 1. Run only that test with `quality.test_one` from FLOW.md; it must pass.
-2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow; measured in tens of minutes → delegate it as a wait to a supervisor subagent on `models.supervisors`, flow-core §6.5 — it returns the exit code and the failing output, and the reading of them stays here).
 3. DB touched → verify the schema has no unexpected differences (`quality.db_update` or the FLOW.md equivalent, if defined).
 4. Security or authentication touched → launch the `agents.security` agent from FLOW.md in parallel over the fix files (empty → `Agent general-purpose` with a security role).
 

package/adapters/gemini/commands/flow/doctor.toml

@@ -74,15 +74,17 @@ is invalid.
 
 #### 1.5.2 Resolved models (only if either file has a `models` key)
 
-Two keys, both about subagents. Print what each one actually reaches:
+Three keys, all about subagents. Print what each one actually reaches:
 
 ```
-agents   fable    →  improvised subagents: review panel members with no named agent, blinded
-                     auditors, delegated build pieces, the general-purpose challenger
-workers  (empty)  →  fan-out rounds — falls back to `agents`
+agents       fable    →  improvised subagents: review panel members with no named agent, blinded
+                         auditors, delegated build pieces, the general-purpose challenger
+workers      (empty)  →  fan-out rounds — falls back to `agents`
+supervisors  (empty)  →  the delegated waits (running pipeline, pending deploy, long suite) —
+                         falls back to `agents`
 ```
 
-- State once, plainly: **the main agent's own steps are not covered by either key** — reading the
+- State once, plainly: **the main agent's own steps are not covered by any key** — reading the
   ticket, the design, and the single-thread `build`/`fix` run on the model the command was launched
   with, because an agent cannot switch its own model. A phase that wants another one says so at the
   handoff; nothing enforces it.
@@ -125,6 +127,10 @@ Whether the world they describe exists —
 CLIs installed *and authenticated*, agents discoverable, hooks executable, the MCP reachable, the
 base branch resolvable — is §2 below; flag the key here, check the world there, never both.
 
+- **Keys inside a fenced block**: report them, one line, naming the file and the keys — they are
+  an example and resolve to nothing (flow-core §0), which is exactly what a reader who pasted a
+  block to enable it cannot tell from a key that works. Say what to do about it: move the line out
+  of the fence to make it real, leave it there to keep it an illustration.
 - **Fan-out and cost ceilings**: `agents.fanout_max` must be a positive integer; else flag and note
   the default `4` applies. `agents.budget_max` must be a non-negative integer (`0` = no ceiling);
   else flag and note the default `12`. **Both absent → say so as a finding, not a pass**: the review

package/adapters/gemini/commands/flow/feat/ship.toml

@@ -14,7 +14,7 @@ prompt = """
 > - `/model <value>` → the `--model` flag at launch.
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `mcpServers` in `settings.json` (see `settings.snippet.json`).
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 Closes the feature: commit, push, MR/PR (assigned per `git.assignee`, squash per `git.squash`, sections per `git.request_sections`) and an optional offer to consolidate knowledge.
 
@@ -177,6 +177,8 @@ Only here — with the content approved in §3 — invoke `Skill commit-commands
 
 **Record the URL the moment it exists**: write it into this MR/PR's `meta.json.mrs` entry and refresh `panel.json` right here, before §4.2 and before anything else can fail.
 
+**The push just started a pipeline, and this thread does not sit on it.** Its result belongs to `/flow:work:green`, not here, so either close the ship with CI reported as *running* — the honest state — or, when the user wants to hear how it ended, delegate the wait as any other (flow-core §6.5): one supervisor subagent on `models.supervisors`, a deadline, and back with status plus failing-job evidence. Whatever it returns, a red pipeline is triaged by `/flow:work:green`; this command never fixes CI and never closes reporting a green it did not see.
+
 ### 4.2 Pre-deploy thread (deployment gate)
 **Only if `git.predeploy_gate` is active and the branch has pre-deploy SQL** (§2). After creating the MR/PR, open **a single resolvable/blocking thread** with **all** the consolidated SQL, using the `git.host`/`git.cli` host:
 - **GitLab**: `glab api "projects/<repo-url-encoded>/merge_requests/<iid>/discussions" -f body="..."` (resolvable thread).

package/adapters/gemini/commands/flow/feat/validate.toml

@@ -14,7 +14,7 @@ prompt = """
 > - `/model <value>` → the `--model` flag at launch.
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `mcpServers` in `settings.json` (see `settings.snippet.json`).
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 Verify the feature is complete: test coverage, edge cases, performance, regressions.
 
@@ -38,7 +38,7 @@ One of the three below writes and two of them read, so they do not all go at onc
 
    **A green suite is not a performance result** — a tiny fixture database proves a query's **rows**, never its **plan**. If `/flow:feat:review §3.6` left any query verdict `unresolved`, or an acceptance criterion concerns speed or volume: run the measurement of **`/flow:work:query §4`** with the volumes in `data.volumes` (or a data set shaped like them — the distribution matters more than the total), record plan and timings, and gate on the result. No `data.*` configuration and the criterion cannot be measured → it is `unproven` with the reason, never silently `proven`.
 
-3. **Full suite**: run `quality.test` from `FLOW.md` in the background; if empty, auto-discover the project's test command and note what you use. A repo with more than one suite chains them in that one key (`make test && make test-frontend`); when it does not and the diff touches a suite the key misses, run that one too and say so in one line.
+3. **Full suite**: run `quality.test` from `FLOW.md` in the background; if empty, auto-discover the project's test command and note what you use. **A suite measured in tens of minutes is a wait, not a step**: hand it to a supervisor subagent on `models.supervisors` (flow-core §6.5) — it runs it, times out, and brings back the exit code plus the failing tests' output, never a reading of whether those failures matter. Short suites stay here; delegating ninety seconds costs more than running them. A repo with more than one suite chains them in that one key (`make test && make test-frontend`); when it does not and the diff touches a suite the key misses, run that one too and say so in one line.
 
 ## 3. Criteria coverage (S and larger)
 

package/adapters/gemini/commands/flow/work/green.toml

@@ -28,7 +28,7 @@ Usage: `/flow:work:green [mr-iid-or-url]` — optional; default is the MR/PR of
 
 Extract from `git`: `host`, `cli` (empty → the default for that host), `default_base`. The term MR/PR follows `host`. From `tracker`: `tool`, `prefix`. From `quality`: `test`, `test_one`, `static_analysis`, `style_fix` (local reproduce/verify commands, §5; empty → auto-discover from Makefile / npm / composer scripts), `review_skill` (§5, non-trivial fixes). `agents`: expert sub-agents to delegate fixes to. `knowledge.search` set → `knowledge.search` in §3.
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`.**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; the wait it delegates takes `models.supervisors`.**
 
 **Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
 1. **Any push** (§6).
@@ -78,7 +78,7 @@ Decide the exit on the **combination** of both halves, never on the pipeline alo
 
 - **Pipeline green *and* verdict mergeable** → report both facts, stop.
 - **Pipeline green but blockers remain** → do **not** report "green, you're good": report the pipeline green, list the blockers, continue to §3 with them.
-- **Pipeline running / pending** → offer to **wait** (poll with `Monitor`, or `ScheduleWakeup` every ~2–3 min; with neither tool, say so and let them re-run when CI finishes) or stop and re-run later. Meanwhile work on any **non-pipeline** blockers.
+- **Pipeline running / pending** → **delegate the wait** (flow-core §6.5): one supervisor subagent on `models.supervisors`, told which run to watch, at what interval, with a deadline and every terminal state, bringing back status **plus evidence** (failing job names, exit codes, log tail, run URL) and **no verdict** — the triage of §3 is this thread's, whatever it reports. Then work any **non-pipeline** blockers meanwhile, or end the turn on the harness's own wake-up (a background task that re-invokes you, `Monitor`, `ScheduleWakeup` ~2–3 min). Neither a supervisor nor a wake-up available → say so plainly and let the user re-run when CI finishes; never imply the pipeline is being watched when nothing is watching it.
 - **Pipeline never ran** (no CI, or not triggered) → say so; verdict clean too → stop.
 
 ## 3. Triage every blocker
@@ -140,7 +140,7 @@ Run **before** the other buckets, only after the hard gate:
 
 - **Push (hard gate).** Show what will be pushed (files, commit message), confirm with `AskUserQuestion`. Never push to the base branch: HEAD must not be `git.default_base` and its upstream must point to the branch itself (same anti-deploy lock as `/flow:feat:ship §4.0` and `/flow:work:respond §6.2`). `git push` to the existing branch — the push re-triggers the pipeline. **Force-push only after a rebase the user explicitly chose** (§5.C.2), and only `git push --force-with-lease` — never bare `--force`, never as a way out of a rejected push (the remote moved: fetch and understand first).
 - **Rerun without a push** (rerun-only, K). Only after the user confirms (hard gate): `glab ci retry` / `gh run rerun <run-id> --failed`. Attach the recorded flake evidence. Fails again the same way → **not** flaky: reclassify to T/Y and fix; do not rerun a second time.
-- **Watch it back to green.** Offer to monitor (`Monitor`, or `ScheduleWakeup` every ~2–3 min; with neither, say so instead of implying it is watched) and report when green — or let a later `/flow:work:green` re-check. Do not claim the pipeline is fixed until it reports green: report what you pushed and that CI is re-running.
+- **Watch it back to green — delegated, not polled from here** (flow-core §6.5). The push starts a run that takes as long as the one you just triaged: hand it to the same kind of supervisor as §2.3 and end the turn, or let a later `/flow:work:green` re-check. With neither a supervisor nor a wake-up, say so instead of implying it is watched. Do not claim the pipeline is fixed until it reports green: report what you pushed and that CI is re-running.
 - **Re-read the merge verdict too.** Once the pipeline settles, re-run §2.1 and report the *merge* verdict, not only the pipeline — the only evidence the MR/PR is actually mergeable.
 
 ## 7. Log, loop, and domain knowledge

package/adapters/gemini/commands/flow/work/watch.toml

@@ -14,7 +14,7 @@ prompt = """
 > - `/model <value>` → the `--model` flag at launch.
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared under `mcpServers` in `settings.json` (see `settings.snippet.json`).
 
-Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**
+Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, `panel.json`, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
 
 **Autopiloted post-deploy monitoring**: signals **scoped to the change** over a window (default 30 min), against a baseline; alert on errors or performance regressions from the deploy.
 
@@ -43,7 +43,7 @@ If `knowledge.search` is set, call `knowledge.search` with the ticket name befor
 - **Confirm WHAT is being deployed — never assume it from `meta.json`** (several MR/PRs per ticket; stale artifacts). Cross-reference the **actual deploy event** (e.g. `get_change_stories`) and recent merges; any ambiguity → `AskUserQuestion` which MR/PR or commit is deploying. The surface (§2) is scoped to **that** change.
 - **When to start.** When the code **is live in production**, not at merge. Launched right after the merge → **wait for the deploy yourself**:
   - Check whether the new version is live (`observability.deploy_detect`; empty → `get_change_stories` or other deploy indicators).
-  - **Not yet deployed** → poll every ~2-3 min until it appears. Do not start the window.
+  - **Not yet deployed** → **delegate the wait** (flow-core §6.5): one supervisor subagent on `models.supervisors` watching for the go-live of that exact SHA, ~2-3 min interval, a deadline, and back with status plus evidence (pipeline/job names, exit codes, the deploy event) — never with a judgement on whether the deploy is healthy. No supervisor available → poll every ~2-3 min here and say that this thread is doing the waiting. Either way the monitoring window does not start until the code is live.
   - **Pipeline fails** → **abort monitoring** and alert: the code did not reach production.
   - Already deployed → proceed.
 - **How to identify YOUR deploy.** The chain in `observability.deploy_detect`. Empty → merge to base branch → CI/CD pipeline → go-live jobs. Determine the exact merge commit; confirm the go-live jobs of the affected services reach `success`. Any fail → **abort**.