flow-workflows 0.95.0 → 0.95.1

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.95.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.1`.** 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
@@ -394,6 +394,7 @@ person asking for changes, a ticket that already has code — is `$flow-work-run
 | An approved study's branch (`run`, `why = start`, no build or fix begun) | record — fast-forwarded to its base when it holds no commit of its own (`$flow-work-run` §2); the base unreadable or the fast-forward failing → blocked. Not integrating: nothing of the run's is merged |
 | Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`$flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
+| A wait — a suite, a quality gate, anything run in the background (`validate`, `review`) | in the turn, on its condition, with a deadline (§6.5) — never a supervisor, never a fixed-length sleep, never ending the turn to be woken |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |
 
@@ -802,7 +803,7 @@ merge now. Delegating that judgement is how a pipeline ends up declared green by
 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
+**Then end the turn** — except in `unattended`, below. 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
@@ -819,6 +820,21 @@ moving.
 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.
 
+**In `unattended`, the wait stays in the turn** (§2.1). Nobody can bring back a run whose turn
+ended, and whether a headless harness re-invokes a run when its background task finishes is not
+something the run can count on. So no supervisor and no ending the turn: the wait is sat through
+here, on the condition it waits for, with a deadline —
+
+- **In the foreground**, when the command fits the harness's own limit for one call.
+- **Otherwise launched with its exit code written to a file**, then waited on by a loop that checks
+  for that file every few seconds and stops at the deadline — one tool call per stretch, each under
+  that same limit, repeated until the file appears or the deadline passes. The loop runs inside the
+  call, so its cycles cost nothing on this thread.
+- **Never a fixed-length sleep.** A guessed duration pays the whole sleep when the suite finished in
+  a fraction of it, and wakes before the suite when the guess is short.
+
+The deadline reached with nothing back → `blocked`, naming the command and how long it ran.
+
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,

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

@@ -41,7 +41,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; 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).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow — in `unattended`, waited on in this turn, flow-core §6.5; otherwise, 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; in `unattended` it is never run without an answer — a schema difference to apply is question
 `migration`, flow-core §2.1; the orchestrator's *Apply it* relaunches this phase, this site takes the
 answer just applied and runs it, and `05-validation.md` names that answer beside the migration).

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

@@ -302,7 +302,7 @@ Not run for XS/S, small diffs, or fewer than 4 ambiguous findings. When skipped,
 
 Read `quality.*` from `FLOW.md`. Empty → auto-discover equivalent commands (Makefile, npm/composer scripts, Gradle, dotnet, Xcode, Flutter…) and note what you use.
 
-Launch in parallel (background if slow):
+Launch in parallel (background if slow; in `unattended`, waited on in this turn, flow-core §6.5):
 - `quality.style_fix`
 - `quality.static_analysis`
 - `quality.test_one` (if there are new tests, with the appropriate filter)

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

@@ -46,7 +46,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 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. **Full suite**: run `quality.test` from `FLOW.md` in the background (in `unattended`, waited on in this turn, flow-core §6.5); if empty, auto-discover the project's test command and note what you use. **A suite measured in tens of minutes is a wait, not a step**: hand it to a supervisor subagent on `models.supervisors` (flow-core §6.5) — it runs it, times out, and brings back the exit code plus the failing tests' output, never a reading of whether those failures matter. Short suites stay here; delegating ninety seconds costs more than running them. A repo with more than one suite chains them in that one key (`make test && make test-frontend`); when it does not and the diff touches a suite the key misses, run that one too and say so in one line.
 
 ## 3. Criteria coverage (S and larger)
 

package/adapters/gemini/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.95.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.1`.** 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
@@ -393,6 +393,7 @@ person asking for changes, a ticket that already has code — is `/flow:work:run
 | An approved study's branch (`run`, `why = start`, no build or fix begun) | record — fast-forwarded to its base when it holds no commit of its own (`/flow:work:run` §2); the base unreadable or the fast-forward failing → blocked. Not integrating: nothing of the run's is merged |
 | Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow:work:green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
+| A wait — a suite, a quality gate, anything run in the background (`validate`, `review`) | in the turn, on its condition, with a deadline (§6.5) — never a supervisor, never a fixed-length sleep, never ending the turn to be woken |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |
 
@@ -801,7 +802,7 @@ merge now. Delegating that judgement is how a pipeline ends up declared green by
 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
+**Then end the turn** — except in `unattended`, below. 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
@@ -818,6 +819,21 @@ moving.
 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.
 
+**In `unattended`, the wait stays in the turn** (§2.1). Nobody can bring back a run whose turn
+ended, and whether a headless harness re-invokes a run when its background task finishes is not
+something the run can count on. So no supervisor and no ending the turn: the wait is sat through
+here, on the condition it waits for, with a deadline —
+
+- **In the foreground**, when the command fits the harness's own limit for one call.
+- **Otherwise launched with its exit code written to a file**, then waited on by a loop that checks
+  for that file every few seconds and stops at the deadline — one tool call per stretch, each under
+  that same limit, repeated until the file appears or the deadline passes. The loop runs inside the
+  call, so its cycles cost nothing on this thread.
+- **Never a fixed-length sleep.** A guessed duration pays the whole sleep when the suite finished in
+  a fraction of it, and wakes before the suite when the guess is short.
+
+The deadline reached with nothing back → `blocked`, naming the command and how long it ran.
+
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,

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

@@ -37,7 +37,7 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 Then:
 1. Run only that test with `quality.test_one` from FLOW.md; it must pass.
-2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow; 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).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow — in `unattended`, waited on in this turn, flow-core §6.5; otherwise, 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; in `unattended` it is never run without an answer — a schema difference to apply is question
 `migration`, flow-core §2.1; the orchestrator's *Apply it* relaunches this phase, this site takes the
 answer just applied and runs it, and `05-validation.md` names that answer beside the migration).

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

@@ -298,7 +298,7 @@ Not run for XS/S, small diffs, or fewer than 4 ambiguous findings. When skipped,
 
 Read `quality.*` from `FLOW.md`. Empty → auto-discover equivalent commands (Makefile, npm/composer scripts, Gradle, dotnet, Xcode, Flutter…) and note what you use.
 
-Launch in parallel (background if slow):
+Launch in parallel (background if slow; in `unattended`, waited on in this turn, flow-core §6.5):
 - `quality.style_fix`
 - `quality.static_analysis`
 - `quality.test_one` (if there are new tests, with the appropriate filter)

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

@@ -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 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. **Full suite**: run `quality.test` from `FLOW.md` in the background (in `unattended`, waited on in this turn, flow-core §6.5); 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/hermes/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.95.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.1`.** 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
@@ -394,6 +394,7 @@ person asking for changes, a ticket that already has code — is `/flow-work-run
 | An approved study's branch (`run`, `why = start`, no build or fix begun) | record — fast-forwarded to its base when it holds no commit of its own (`/flow-work-run` §2); the base unreadable or the fast-forward failing → blocked. Not integrating: nothing of the run's is merged |
 | Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
+| A wait — a suite, a quality gate, anything run in the background (`validate`, `review`) | in the turn, on its condition, with a deadline (§6.5) — never a supervisor, never a fixed-length sleep, never ending the turn to be woken |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |
 
@@ -802,7 +803,7 @@ merge now. Delegating that judgement is how a pipeline ends up declared green by
 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
+**Then end the turn** — except in `unattended`, below. 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
@@ -819,6 +820,21 @@ moving.
 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.
 
+**In `unattended`, the wait stays in the turn** (§2.1). Nobody can bring back a run whose turn
+ended, and whether a headless harness re-invokes a run when its background task finishes is not
+something the run can count on. So no supervisor and no ending the turn: the wait is sat through
+here, on the condition it waits for, with a deadline —
+
+- **In the foreground**, when the command fits the harness's own limit for one call.
+- **Otherwise launched with its exit code written to a file**, then waited on by a loop that checks
+  for that file every few seconds and stops at the deadline — one tool call per stretch, each under
+  that same limit, repeated until the file appears or the deadline passes. The loop runs inside the
+  call, so its cycles cost nothing on this thread.
+- **Never a fixed-length sleep.** A guessed duration pays the whole sleep when the suite finished in
+  a fraction of it, and wakes before the suite when the guess is short.
+
+The deadline reached with nothing back → `blocked`, naming the command and how long it ran.
+
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,

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

@@ -41,7 +41,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 Then:
 1. Run only that test with `quality.test_one` from FLOW.md; it must pass.
-2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow; 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).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow — in `unattended`, waited on in this turn, flow-core §6.5; otherwise, 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; in `unattended` it is never run without an answer — a schema difference to apply is question
 `migration`, flow-core §2.1; the orchestrator's *Apply it* relaunches this phase, this site takes the
 answer just applied and runs it, and `05-validation.md` names that answer beside the migration).

package/adapters/hermes/skills/flow-feat-review/SKILL.md

@@ -302,7 +302,7 @@ Not run for XS/S, small diffs, or fewer than 4 ambiguous findings. When skipped,
 
 Read `quality.*` from `FLOW.md`. Empty → auto-discover equivalent commands (Makefile, npm/composer scripts, Gradle, dotnet, Xcode, Flutter…) and note what you use.
 
-Launch in parallel (background if slow):
+Launch in parallel (background if slow; in `unattended`, waited on in this turn, flow-core §6.5):
 - `quality.style_fix`
 - `quality.static_analysis`
 - `quality.test_one` (if there are new tests, with the appropriate filter)

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

@@ -46,7 +46,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 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. **Full suite**: run `quality.test` from `FLOW.md` in the background (in `unattended`, waited on in this turn, flow-core §6.5); 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/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.95.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.1`.** 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
@@ -393,6 +393,7 @@ person asking for changes, a ticket that already has code — is `/flow-work-run
 | An approved study's branch (`run`, `why = start`, no build or fix begun) | record — fast-forwarded to its base when it holds no commit of its own (`/flow-work-run` §2); the base unreadable or the fast-forward failing → blocked. Not integrating: nothing of the run's is merged |
 | Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
+| A wait — a suite, a quality gate, anything run in the background (`validate`, `review`) | in the turn, on its condition, with a deadline (§6.5) — never a supervisor, never a fixed-length sleep, never ending the turn to be woken |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |
 
@@ -801,7 +802,7 @@ merge now. Delegating that judgement is how a pipeline ends up declared green by
 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
+**Then end the turn** — except in `unattended`, below. 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
@@ -818,6 +819,21 @@ moving.
 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.
 
+**In `unattended`, the wait stays in the turn** (§2.1). Nobody can bring back a run whose turn
+ended, and whether a headless harness re-invokes a run when its background task finishes is not
+something the run can count on. So no supervisor and no ending the turn: the wait is sat through
+here, on the condition it waits for, with a deadline —
+
+- **In the foreground**, when the command fits the harness's own limit for one call.
+- **Otherwise launched with its exit code written to a file**, then waited on by a loop that checks
+  for that file every few seconds and stops at the deadline — one tool call per stretch, each under
+  that same limit, repeated until the file appears or the deadline passes. The loop runs inside the
+  call, so its cycles cost nothing on this thread.
+- **Never a fixed-length sleep.** A guessed duration pays the whole sleep when the suite finished in
+  a fraction of it, and wakes before the suite when the guess is short.
+
+The deadline reached with nothing back → `blocked`, naming the command and how long it ran.
+
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,

package/adapters/opencode/commands/flow-bug-validate.md

@@ -39,7 +39,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; 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).
+2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow — in `unattended`, waited on in this turn, flow-core §6.5; otherwise, 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; in `unattended` it is never run without an answer — a schema difference to apply is question
 `migration`, flow-core §2.1; the orchestrator's *Apply it* relaunches this phase, this site takes the
 answer just applied and runs it, and `05-validation.md` names that answer beside the migration).

package/adapters/opencode/commands/flow-feat-review.md

@@ -300,7 +300,7 @@ Not run for XS/S, small diffs, or fewer than 4 ambiguous findings. When skipped,
 
 Read `quality.*` from `FLOW.md`. Empty → auto-discover equivalent commands (Makefile, npm/composer scripts, Gradle, dotnet, Xcode, Flutter…) and note what you use.
 
-Launch in parallel (background if slow):
+Launch in parallel (background if slow; in `unattended`, waited on in this turn, flow-core §6.5):
 - `quality.style_fix`
 - `quality.static_analysis`
 - `quality.test_one` (if there are new tests, with the appropriate filter)

package/adapters/opencode/commands/flow-feat-validate.md

@@ -44,7 +44,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 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. **Full suite**: run `quality.test` from `FLOW.md` in the background (in `unattended`, waited on in this turn, flow-core §6.5); 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.95.0",
+  "version": "0.95.1",
   "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.95.0",
+  "version": "0.95.1",
   "author": {
     "name": "Alberto Vioque",
     "email": "mashware@gmail.com"

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,22 @@ 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.95.1 — An unattended run waits for its tests instead of sleeping a guess  ·  2026-10-15
+
+**In short**
+- **In `unattended`, a wait happens in the turn.** A suite or a quality gate run in the background
+  is waited on by a loop that ends when it finishes, with a deadline. No supervisor, and the turn
+  does not end to be woken.
+- **Never a fixed-length sleep.** Unattended runs were guessing one — seven minutes for a suite
+  that took three — and losing up to half an hour per run.
+- Nothing changes outside `unattended`.
+
+The rule for waits told every run to hand the wait off and end the turn, trusting the harness to
+wake it. A headless run cannot rely on that, so the model kept itself alive with a sleep of its
+own choosing. flow-core §6.5 now says how an unattended run waits, the §2.1 table names the case,
+and `validate` and `review` point to it where they launch something in the background. The
+deadline reached with nothing back ends the run as `blocked`.
+
 ## v0.95.0 — One repo can study some works for handoff and build others here  ·  2026-10-15
 
 **In short**