flow-workflows 0.68.0 → 0.70.0

package/adapters/hermes/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` in `~/.hermes/config.yaml` (see `config.snippet.yaml`).
 > - `$ARGUMENTS` → what the user typed after the skill name: Hermes takes everything from the first non-skill token on as the instruction.
 
-Read `~/.claude/flow/CORE.hermes.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.hermes.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/opencode/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/opencode/commands/flow-bug-fix.md

@@ -46,7 +46,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.
 
@@ -58,11 +58,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.
 
@@ -116,6 +143,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/opencode/commands/flow-bug-ship.md

@@ -23,7 +23,7 @@ Close the bug flow: commit, push, MR/PR. Same mechanics as `/flow-feat-ship`, wi
 
 ## 0. Pre-flight
 
-Read `~/.claude/flow/CORE.opencode.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.opencode.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.
@@ -158,6 +158,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/opencode/commands/flow-bug-validate.md

@@ -20,7 +20,7 @@ Validate that the fix works and that the bug does not return.
 
 ## 1. Pre-flight
 
-Read `~/.claude/flow/CORE.opencode.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.opencode.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`.
@@ -35,7 +35,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 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/opencode/commands/flow-doctor.md

@@ -76,15 +76,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/opencode/commands/flow-feat-build.md

@@ -57,7 +57,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.
 
@@ -82,7 +82,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
 
@@ -113,7 +142,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)
 
@@ -219,7 +248,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.
 
@@ -267,6 +296,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/opencode/commands/flow-feat-ship.md

@@ -16,7 +16,7 @@ description: Commit, push, MR/PR, and offer to save domain knowledge
 > - `/model <value>` → opencode's model picker (`/models`).
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared in `opencode.json` (see this adapter's `opencode.json` for the domain-memory example).
 
-Read `~/.claude/flow/CORE.opencode.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.opencode.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.
 
@@ -179,6 +179,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/opencode/commands/flow-feat-validate.md

@@ -16,7 +16,7 @@ description: Validate tests, edge cases, and integrity before shipping
 > - `/model <value>` → opencode's model picker (`/models`).
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared in `opencode.json` (see this adapter's `opencode.json` for the domain-memory example).
 
-Read `~/.claude/flow/CORE.opencode.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.opencode.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.
 
@@ -40,7 +40,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/opencode/commands/flow-work-green.md

@@ -30,7 +30,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.opencode.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.opencode.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).
@@ -80,7 +80,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
@@ -142,7 +142,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/opencode/commands/flow-work-watch.md

@@ -16,7 +16,7 @@ description: Monitor the observability platform after a deploy and alert on erro
 > - `/model <value>` → opencode's model picker (`/models`).
 > - `knowledge.*` roles → whatever tools `FLOW.md` names there; an MCP tool keeps its name, its server is declared in `opencode.json` (see this adapter's `opencode.json` for the domain-memory example).
 
-Read `~/.claude/flow/CORE.opencode.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.opencode.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.
 
@@ -45,7 +45,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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.68.0",
+  "version": "0.70.0",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
   "type": "module",
   "bin": {

package/plugins/flow/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "flow",
   "displayName": "Flow — guided dev workflows",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
-  "version": "0.68.0",
+  "version": "0.70.0",
   "author": {
     "name": "Alberto Vioque",
     "email": "mashware@gmail.com"

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,70 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.70.0 — The plan each MR/PR was built from belonged to the feature  ·  2026-09-21
+
+**In short**
+- **`/flow:feat:build` §2.0ter plans the MR/PR it is about to build**: numbered steps, each with its file and the test that proves it, plus the point of no return and what is out of scope. Gated on the entry already in `meta.json.mrs` — `lines_est > 150` or `files_est > 5` — so a small MR/PR never pays for a planning round.
+- **`/flow:bug:fix` §2.0bis gives the same shape to a fix of more than two steps**, and leads it with the bug flow's own rule: the regression test is a step, and it comes first when it can fail before the fix.
+- **`TaskCreate` seeds from that plan** instead of the design's implementation order, which was written before `/flow:feat:plan` split anything and handed each MR/PR its siblings' steps.
+- **A compaction gives the contract back.** The `SessionStart` hook reads the event's `source`, and on `compact` prints the brief and plan from `05-implementation.md` or `04-fix.md` instead of "where was I" — and never invites a resume of work that never stopped.
+- **`manual`/`guided` stop on the plan with one question; `auto` prints it and builds.** No plan-mode primitive is used, so every harness gets the same step.
+
+`03-design.md` writes its implementation plan before the delivery split exists, so its steps never
+knew which MR/PR they would land in — and `build` seeded its task list from that same list all the
+same. Between the business brief, which says what the user gets and never in which file, and the
+first edit, there was nothing that named a path. On a large MR/PR the work was being discovered
+while it was typed, and the record of it arrived afterwards.
+
+The gate reuses numbers that were already there. `/flow:feat:plan` estimates `lines_est` and
+`files_est` per MR/PR, `§2.3` already measures the real diff against them, and the same pair now
+decides whether a plan is worth writing. A bug has no `mrs[]` to estimate against — and an M bug is
+often three lines in a hard place — so there the trigger stays the one the fix flow already used,
+more than two steps, and a fix that turns into a third step mid-way comes back and writes it then.
+
+The order is the decision being asked about, which is why the plan stops for one. On a bug that is
+sharpest: `validate` is what proves a fix and `review` refuses to run without it above size S, so a
+plan that leaves the regression test until last puts the one step that can still refute the root
+cause after everything has been built on it.
+
+Keeping a plan in context is a separate problem from writing one, and it is the hook's, not the
+phase's. Re-reading the plan at every checkpoint spends tokens on the turns that lost nothing;
+`SessionStart` already ran after every compaction and answered with the wrong thing, so the cost
+now falls only on the compactions that actually happen. What it prints is labelled as a record of
+what was agreed rather than an instruction — a hook's stdout arrives as context, and a stale plan
+read as an order outranks the decision that replaced it.
+
+## v0.69.0 — Waiting on the pipeline was paid for at the main thread's price  ·  2026-09-21
+
+**In short**
+- **A wait is delegated now, not sat through.** A running pipeline, a deploy that has not landed and a suite measured in tens of minutes go to one supervisor subagent with an interval, a deadline and every terminal state; this thread ends its turn instead of polling.
+- **What comes back is evidence, never a verdict** — failing job names, exit codes, the log tail, the run URL, the SHA it watched. Whether a red job is flaky, whether a threshold is close enough, whether the branch can merge is still decided on the main thread.
+- **`models.supervisors`** names the model for it, falling back to `models.agents` and then to inheritance. An empty section behaves exactly as before, and the dispatch says in one line that the wait inherits this thread's model — an unattended wait is where an unpriced default runs longest.
+- **Applied where the flow actually waits**: `/flow:work:green` §2.3 and its re-trigger, `/flow:work:watch` §1, both `validate` commands for a long suite, and both `ship` commands for the pipeline the push starts.
+- **Delegating a wait is mechanics**, so it is on the never-ask list: `manual` still asks whatever the evidence turns out to call for, once it is back.
+
+Every command that waited, waited on the thread holding the whole conversation. `green` offered to
+poll a running pipeline every two or three minutes; `watch` polled for a deploy that had not landed
+yet; `validate` ran the full suite in the background and stayed with it. None of that reads a diff
+or weighs a finding — it reads `pending` — and each cycle resends the entire context to do it. A
+forty-minute pipeline could cost more to watch than the diff cost to write, and the cost was
+invisible because waiting looks like nothing happening.
+
+The delegation is bounded on purpose. The brief names the exact run rather than "the CI", every
+terminal state rather than the first red job, and a deadline after which the supervisor returns what
+it has instead of waiting forever. It writes its evidence to a path before it replies, like every
+other brief, so a report lost in transit is recoverable for the cost of one `ls`. And it counts
+against `agents.budget_max` like any other subagent, relaunches included.
+
+What it must never do is rule. Handing the judgement to whoever is cheapest to ask is how a pipeline
+ends up declared green by a model that was hired to watch a clock — the machine version of the
+green-washing `/flow:work:green` refuses in every autonomy mode. The supervisor reports; the triage,
+the merge verdict and the decision to push stay exactly where they were.
+
+Not every wait is worth a brief either: a suite that finishes in ninety seconds costs more to
+delegate than to run, and anything the phase must react to mid-wait was never a wait — it is the
+work.
+
 ## v0.68.0 — The block written to be pasted was the configuration  ·  2026-09-21
 
 **In short**

package/plugins/flow/examples/FLOW.template.md

@@ -239,11 +239,19 @@ subagent ignores the value and the step says so once, in one line.
 - `workers:`  # the parallel fan-out rounds ONLY: approach panel (design §1.5.3), hypothesis sweep
               #   (investigate §3.A), finding skeptics (review §6 / §5), the deferred-work skeptic
               #   (ship). Empty = falls back to `agents`, then to what the command runs on.
-
-**Two keys, not one per kind of step.** There used to be five — `study`, `code`, `test`, `review` —
-named after phases. They promised a granularity no harness delivers: the main agent cannot switch
-its own model, so the phases those keys named ran on whatever you launched, and the value only ever
-reached the subagents. These two name what can actually be set.
+- `supervisors:` # the ONE subagent a command hands a long wait to instead of polling it from the main thread
+              #   (flow-core §6.5): a running pipeline (green §2.3, §6), a deploy that has not landed yet
+              #   (watch §1), a suite measured in tens of minutes (validate §2). It watches, times out and
+              #   brings back status plus evidence — job names, exit codes, log tail, run URL — and never
+              #   rules on it: triage and the merge verdict stay on the main thread whatever this says.
+              #   Empty = falls back to `agents`, then to what the command runs on, and the dispatch says so
+              #   in one line — an unattended wait is the one place an unpriced default runs longest.
+
+**Three keys, one per kind of subagent — not one per kind of step.** There used to be five —
+`study`, `code`, `test`, `review` — named after phases. They promised a granularity no harness
+delivers: the main agent cannot switch its own model, so the phases those keys named ran on whatever
+you launched, and the value only ever reached the subagents. These three name what can actually be
+set: the improvised agent, the fan-out round, and the wait.
 
 Two limits, stated here because they bound what these keys can promise:
 
@@ -255,7 +263,7 @@ question in `guided`/`auto` and never a gate.
 
 **A named agent keeps its own model.** If `agents.<role>` names a real agent, that agent's own
 definition wins — you configured it, and it is not overridden from two places. `/flow:doctor` prints
-both keys resolved, with who decided each.
+the three keys resolved, with who decided each.
 
 ## data
 How this repo lets you look at a query's **plan** instead of arguing about it. Read by