flow-workflows 0.68.0 → 0.70.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 |
@@ -367,7 +368,9 @@ configuration, normally the active harness overlay. One worked set ships as an *
 never loaded: [`examples/symfony/`](plugins/flow/examples/symfony/) is a filled-in `FLOW.md` plus
 four reviewers for a Symfony + Doctrine repo, to copy and edit. Three generic hooks ship: a guard
 against pushing to `master`/`main`, an update notice at session start, and a session-start line
-saying which work this branch belongs to and where it stands. Optional dependencies (a knowledge
+saying which work this branch belongs to and where it stands — after a compaction, that last one
+prints the brief and plan the build is held to instead, since there the context is what was lost,
+not the thread. Optional dependencies (a knowledge
 source such as `domain-memory` or `codegraph`, your git host CLI, a tracker CLI) improve specific
 steps; without them those steps degrade and the rest works.
 

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.68.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.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
@@ -152,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.
@@ -179,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.
@@ -209,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.
 
@@ -407,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-fix/SKILL.md

@@ -48,7 +48,7 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `guided`/`auto` this is one of the only two stops of the whole flow (this one and `ship`): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 
@@ -60,11 +60,38 @@ blockers lived in the half a third option let in.
 
 Save the brief at the top of `04-fix.md`. Any "also fix X while we're at it" during implementation → §2.3.
 
+## 2.0bis Plan the fix (more than 2 steps)
+
+A fix of one or two steps is its own plan, and a planning round on it is pure friction. Past that the steps stop fitting in the brief — which says what stops happening, never in which file — and the fix starts being discovered while it is typed. **Trigger: more than 2 fix steps.** Two or fewer → skip, record one line in `04-fix.md` (`plan: skipped — 2 steps`) and go to §2.1.
+
+The steps come from the root cause in `03-investigation.md`, not from the repo you are about to open: a step that cause never implied is either the investigation being wrong (§4.1) or scope that belongs in §2.3. **No code yet.** Under 200 words:
+
+```markdown
+## Plan
+1. <step> — `<file or path>` — <the test that proves it, or "covered by step M">
+2. …
+
+- **Point of no return**: <the migration, contract or published event after which rollback stops being a revert — or "none">.
+- **Out of this plan**: <the adjacent thing that will be tempting once these files are open>.
+```
+
+Rules, and the first one is the bug flow's own:
+- **The regression test is a step, and it comes first when it can fail before the fix.** `$flow-bug-validate` is what proves the fix, and `$flow-bug-review` refuses to run without it on size ≥ S (`$flow-bug-start §2`). A plan that leaves the test until last has the one step that can still say "the cause was not this" arriving after everything is already built on the answer.
+- **A step is a thing on disk**, not a phase of thought: "add the idempotency key on the retry path", not "look at the retry logic".
+- **A step that widens the blast radius is not part of the minimal fix** (§2.1) — it goes to §2.3 before it is written down here, not after it is built.
+- A fix whose plan needs more than about five steps is usually two tickets or a feature in disguise: check §4.2 before planning further.
+
+**Present it, then behave by mode:**
+- `manual` / `guided` → **stop**: full stop header (flow-core §3), the plan, one `AskUserQuestion` — **Approve and fix** · **Change the order or the steps**. On a bug the order is the decision: it is what settles whether the proof comes before the repair.
+- `auto` → **do not stop**. Print the numbered steps and the point of no return, record the plan as accepted, and open the same message with the call that starts §2.1 (flow-core §3: a report is never the last thing in a turn you meant to continue).
+
+Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was going to be one step and turns into a third**: come back here and write it then — the trigger is the shape of the work, not the moment it was first guessed.
+
 ## 2.1 Work
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → task list (`TaskCreate` where the harness offers one; otherwise a numbered list ticked off in `04-fix.md`).
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 
@@ -118,6 +145,9 @@ A **product decision** the fix turns out to need is neither of these — not sco
 **What is NOT touched**:
 - <adjacent areas out of scope>
 
+## Plan
+<the numbered steps of §2.0bis, its point of no return and its "out of this plan" line — or one line saying the step was skipped and why (`plan: skipped — 2 steps`). What §2.1 tracks with `TaskCreate`. Steps are annotated as they are reworked, never deleted: a plan edited to match what happened records nothing.>
+
 ## Fix description
 <one sentence: "The fix consists of …">
 

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.

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

@@ -59,7 +59,7 @@ Rules for writing it:
 
 **Ask the user with `AskUserQuestion`** whether the brief reflects what they expect — **hard gate, in every autonomy mode, `auto` included**: it is the last point where scope can be corrected before there is a diff to argue with.
 
-In `guided`/`auto` this is one of the only two stops per MR/PR, so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
+In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
 
@@ -84,7 +84,36 @@ Hard rules:
 - **If there is a "Pattern deviation" section**: copy it too — it reminds you at coding time not to mimic the repo pattern.
 - **If the design says "none"** (no external surfaces), skip this step and record: "## Contracts to respect — none declared in design".
 
-Without this copy, do not proceed to §2.1.
+Without this copy, do not proceed to §2.0ter.
+
+## 2.0ter Plan this MR/PR (size-gated)
+
+`03-design.md` §"Implementation plan (order)" is the **feature's** order, written before `$flow-feat-plan` split anything — it does not know which of its steps belong to this MR/PR. The brief above says what this MR/PR delivers in business terms; neither says which files are touched in which order. On a MR/PR big enough to lose its thread, that plan is written here.
+
+**Gate — run this step only when the current `mrs[]` entry is big enough**: `lines_est > 150` **or** `files_est > 5`. No estimates in the entry (an older plan) → fall back to its `size`: `M`/`L` run it, `XS`/`S` skip. No `mrs[]` at all (XS/S, single MR/PR) → skip; the brief and the contracts are the whole plan, and a 30-line change does not earn a planning round. Skipped → record one line in `05-implementation.md` — the estimates that let it through (`plan: skipped — 40 lines / 2 files`), or `plan: skipped — single MR/PR` when there is no entry to read — and go to §2.1.
+
+Write it against `03-design.md` and the contracts just copied — **no code yet, no exploratory edits**. Under 250 words, as numbered steps:
+
+```markdown
+## Plan MR/PR #N
+1. <step> — `<file or path>` — <test that proves it, or "covered by step M">
+2. …
+
+- **Point of no return**: <the migration, contract, published event or flag after which rollback stops being a revert — or "none">.
+- **Out of this plan**: <what belongs to a later MR/PR and will be tempting while inside these files>.
+```
+
+Rules for the steps:
+- **A step is a thing on disk**, not a phase of thought: "add the nullable column + migration", not "analyse the schema". A step nobody can tell is finished is two steps or none.
+- **Order by what unblocks what**, and put the point of no return as late as the design allows: everything reversible lands before it.
+- **Every step names its test** or the step that covers it. A step that proves no acceptance criterion and guards no contract is a candidate to cut — same bar as `03-design.md` §"Planned tests".
+- Steps come from the **design**, not from the repo you are about to open. A step the design never mentions is either a deviation to log (§3 "Deviations from design") or scope that belongs in §2.4.
+
+**Present it, then behave by mode:**
+- `manual` / `guided` → **stop**: full stop header (flow-core §3), the plan, and one `AskUserQuestion` — **Approve and build** · **Change the order or the steps** (the user edits, rewrite it, ask again). This is a genuine decision point: the order of an irreversible step is exactly what is expensive to argue with once there is a diff.
+- `auto` → **do not stop**. Print the numbered steps and the point of no return, record the plan as accepted, and open the same message with the call that starts §2.1 (flow-core §3: a report is never the last thing in a turn you meant to continue).
+
+Save it in `05-implementation.md` under `## Plan MR/PR #N`, right after the brief. It is what seeds `TaskCreate` in §2.1, and what a §2.3 hot cut splits: the steps already done stay in this MR/PR, the ones still pending move to the new entry.
 
 ## 2.1 Work
 
@@ -115,7 +144,7 @@ Execution mode:
   - **Give it a bounded first step.** A piece with no natural first move ("do the whole module") produces nothing for hours; split it by file or by numbered step until it has one.
   - **Check the round at every stop of this command**, not only at the end: an agent past `agents.stall_after_minutes` (empty → 25) with nothing written to its path is stopped, split in two and relaunched.
 
-Use `TaskCreate` to track the steps from the design's implementation plan. Mark each step `in_progress` when starting and `completed` when done — do not batch.
+Use `TaskCreate` to track the steps of the **§2.0ter plan for this MR/PR** — one task per numbered step, same order. Step skipped there (small MR/PR) → seed from `03-design.md` §"Implementation plan (order)", taking only the steps this MR/PR covers per `04-mr-plan.md`; the feature's plan predates the split and carries steps that belong to siblings. Mark each step `in_progress` when starting and `completed` when done — do not batch.
 
 ### 2.1bis The premise this change rests on (any size, XS included)
 
@@ -221,7 +250,7 @@ Warning thresholds:
 
 If either is exceeded, **pause** and ask the user with `AskUserQuestion` (options, in this order):
 
-1. **Cut here (recommended if the current piece is coherent)**. What is built so far stays as this MR/PR; what remains of the plan goes into a new one inserted in `meta.json.mrs` right after. Zero code wasted.
+1. **Cut here (recommended if the current piece is coherent)**. What is built so far stays as this MR/PR; what remains — the §2.0ter steps still pending, or what is left of `04-mr-plan.md` where that step was skipped — goes into a new one inserted in `meta.json.mrs` right after. Zero code wasted.
 2. **Continue and record the overrun**. When the cut would be artificial. Note the deviation in `05-implementation.md` to calibrate `$flow-feat-plan` on future tickets.
 3. **Reopen plan**. Return to `$flow-feat-plan` to rethink the entire split. Only if the overrun shows the plan is wrong at a deeper level, not just that this MR/PR is slightly underestimated.
 
@@ -269,6 +298,9 @@ Keep `.claude/work/<TICKET>/05-implementation.md` updated as you work (not at th
 **This MR/PR does NOT include**:
 - <pieces that are out of scope>
 
+## Plan MR/PR #N
+<the numbered steps of §2.0ter, its point of no return and its "out of this plan" line — or one line saying the step was skipped and why (`plan: skipped — 40 lines / 2 files`). What §2.1 seeds `TaskCreate` from and what a §2.3 cut splits. Steps are struck through or annotated as they are reworked, never deleted: a plan edited to match what happened records nothing.>
+
 ## Changes per file
 - <file> — what changed and why (1 line each)
 

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.68.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.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
@@ -151,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.
@@ -178,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.
@@ -208,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.
 
@@ -406,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/fix.toml

@@ -44,7 +44,7 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `guided`/`auto` this is one of the only two stops of the whole flow (this one and `ship`): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 
@@ -56,11 +56,38 @@ blockers lived in the half a third option let in.
 
 Save the brief at the top of `04-fix.md`. Any "also fix X while we're at it" during implementation → §2.3.
 
+## 2.0bis Plan the fix (more than 2 steps)
+
+A fix of one or two steps is its own plan, and a planning round on it is pure friction. Past that the steps stop fitting in the brief — which says what stops happening, never in which file — and the fix starts being discovered while it is typed. **Trigger: more than 2 fix steps.** Two or fewer → skip, record one line in `04-fix.md` (`plan: skipped — 2 steps`) and go to §2.1.
+
+The steps come from the root cause in `03-investigation.md`, not from the repo you are about to open: a step that cause never implied is either the investigation being wrong (§4.1) or scope that belongs in §2.3. **No code yet.** Under 200 words:
+
+```markdown
+## Plan
+1. <step> — `<file or path>` — <the test that proves it, or "covered by step M">
+2. …
+
+- **Point of no return**: <the migration, contract or published event after which rollback stops being a revert — or "none">.
+- **Out of this plan**: <the adjacent thing that will be tempting once these files are open>.
+```
+
+Rules, and the first one is the bug flow's own:
+- **The regression test is a step, and it comes first when it can fail before the fix.** `/flow:bug:validate` is what proves the fix, and `/flow:bug:review` refuses to run without it on size ≥ S (`/flow:bug:start §2`). A plan that leaves the test until last has the one step that can still say "the cause was not this" arriving after everything is already built on the answer.
+- **A step is a thing on disk**, not a phase of thought: "add the idempotency key on the retry path", not "look at the retry logic".
+- **A step that widens the blast radius is not part of the minimal fix** (§2.1) — it goes to §2.3 before it is written down here, not after it is built.
+- A fix whose plan needs more than about five steps is usually two tickets or a feature in disguise: check §4.2 before planning further.
+
+**Present it, then behave by mode:**
+- `manual` / `guided` → **stop**: full stop header (flow-core §3), the plan, one `AskUserQuestion` — **Approve and fix** · **Change the order or the steps**. On a bug the order is the decision: it is what settles whether the proof comes before the repair.
+- `auto` → **do not stop**. Print the numbered steps and the point of no return, record the plan as accepted, and open the same message with the call that starts §2.1 (flow-core §3: a report is never the last thing in a turn you meant to continue).
+
+Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was going to be one step and turns into a third**: come back here and write it then — the trigger is the shape of the work, not the moment it was first guessed.
+
 ## 2.1 Work
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → task list (`TaskCreate` where the harness offers one; otherwise a numbered list ticked off in `04-fix.md`).
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 
@@ -114,6 +141,9 @@ A **product decision** the fix turns out to need is neither of these — not sco
 **What is NOT touched**:
 - <adjacent areas out of scope>
 
+## Plan
+<the numbered steps of §2.0bis, its point of no return and its "out of this plan" line — or one line saying the step was skipped and why (`plan: skipped — 2 steps`). What §2.1 tracks with `TaskCreate`. Steps are annotated as they are reworked, never deleted: a plan edited to match what happened records nothing.>
+
 ## Fix description
 <one sentence: "The fix consists of …">
 

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".