flow-workflows 0.94.1 → 0.95.1

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/adapters/opencode/commands/flow-work-README.md

@@ -254,7 +254,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
 - `/flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow-feat-start`, `/flow-work-green`, `/flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow-news`.
 - `/flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
 - `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · study · answer · merged · review · pipeline), routes to the phase that answers it — a `study` run stops at the door to code with a summary for a person to approve — and makes no decision of its own. Refuses to run in any other mode.
-- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`).
+- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`). A work started with `/flow-feat-start --study` (or `/flow-bug-start --study`) ends its study here on its own; one started without the flag is built here, even with the key set.
 - `/flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow-work-try <branch>` / `/flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

package/adapters/opencode/commands/flow-work-resume.md

@@ -90,7 +90,7 @@ With what is new (there is already work on disk):
 ## 4. Next step
 
 - An `Unattended:` line → the question is the orchestrator's to bring back: say so, and that answering it here instead means clearing `meta.json.pending` and continuing in this session's mode; the next step itself comes from `phase` as always.
-- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
+- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `/flow-feat-start <TICKET>` there. flow only reminds; it never scans or touches the other repo.
 - Do not advance on your own. The user decides.

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,38 @@ 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**
+- **`--study` on `/flow:feat:start` and `/flow:bug:start`** makes a work a study for someone else to
+  build: its last study phase hands it to `/flow:work:handoff`, as the key alone did until now.
+- **Without the flag, a work is built here**, even in a repo with `git.handoff_branch` set. The key
+  only says where a study is pushed.
+- **Change in behaviour:** a repo that set the key to send every study off now passes `--study` on
+  the works it hands off. Nothing changes in `unattended`.
+
+The key was repo-wide, so a repo whose tickets are sometimes studied for a server and sometimes
+built on the laptop had no way to say "build this one here": in `auto` every plan chained into the
+handoff. The choice now belongs to the work. `start` records it as `meta.json.handoff`, and `design`,
+`plan`, `investigate` and `resume` read the field instead of the key. `--study` with the key empty
+says so in one line and goes on as a work built here.
+
 ## v0.94.1 — An unattended start with a study no longer stops because the container cannot fetch  ·  2026-10-14
 
 **In short**

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

@@ -96,7 +96,7 @@ Branch and Pull/Merge Request conventions.
                       #   - make database-update
                       #   - make frontend
 
-- `handoff_branch:`   # branch `/flow:work:handoff` pushes a finished study to, holding only that work's folder. `{TICKET}` substituted. Empty = the command refuses: where a study goes is the receiver's convention. e.g. `study/{TICKET}`. Set → the study phases end at `/flow:work:handoff` instead of `build`/`fix` (not in `unattended`); pair it with `autonomy.mode: auto` and the study runs on its own up to the push.
+- `handoff_branch:`   # branch `/flow:work:handoff` pushes a finished study to, holding only that work's folder. `{TICKET}` substituted. Empty = the command refuses: where a study goes is the receiver's convention. e.g. `study/{TICKET}`. It does not decide which works are studies: a work started with `--study` (`/flow:feat:start`, `/flow:bug:start`) ends its study phases at `/flow:work:handoff` instead of `build`/`fix` (not in `unattended`), one started without it is built here. Pair it with `autonomy.mode: auto` and a `--study` work runs on its own up to the push.
 
 ## autonomy
 How much the flow advances on its own vs. stopping to ask you.