flow-workflows 0.85.1 → 0.86.0

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.85.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.86.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
@@ -264,6 +264,11 @@ assumed:
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it
   stopped; the run trusts that and does not re-check it.
+- **The work is the one `$flow-work-run` found** — by the ticket's `number`, never by the current
+  branch. A phase whose pre-flight says "load `meta.json` by current branch" takes that work instead:
+  the checkout can be the ticket's `base` (a study restored from elsewhere) or an umbrella branch (a
+  part just merged), and neither names the work. `run` puts a work whose branch is not checked out
+  back on it before handing over (its §2).
 - **Before any closing order, commit** what this run left uncommitted outside `.claude/work/`, new
   files included (`WIP <TICKET>: before <gate|order>` — `auto`'s WIP authority): the orchestrator
   keeps only what is committed. **Only on the work branch**: before it exists (`start` refusing a
@@ -298,6 +303,7 @@ run has.
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |
 | `<cmd> ticket` failing or empty, a checkout that is not clean on the ticket's `base` (`start`) | blocked — the orchestrator owns the checkout and the ticket |
+| A work whose branch is not checked out (`run`) | as `$flow-work-run` §2 says — switch onto a branch an unattended run made, or record `unattended:rehomed` and create `<number>-<slug>` from `base`; blocked on a dirty checkout or a branch with the work's name that no run here recorded |
 | Below-XS check (`start`) | record — open the work |
 | "Create the branch?" (`start`), the 2–3 line note an XS `build`/`fix` asks for, a contract the design left in prose (`build`) | record — create it · write the note from the ticket · convert it to literal and say so in the artifact |
 | `git.worktree: ask` | record — in place |

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

@@ -183,7 +183,7 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 **Live panel**: publish it now (flow-core §4 — the panel tools, or `<work-dir>/panel.json`). A bug has no MR/PR train, so it is short: the title (the symptom, `style: title`), a `Now` line for what is starting, a `Next` line for the phase this size routes to, and any sibling repo from §1.6 as a `block` line. Every later phase updates it.
 
-In `unattended`, add `"base"`: the ticket's `base`, the branch the fix starts from and targets. Omit it in every other mode.
+In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 

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

@@ -28,14 +28,14 @@ Implementation phase. Code is written here.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
+- Load `meta.json` by current branch — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
 - `size` M/L: require both `03-design.md` **and** `04-mr-plan.md`. Plan missing → send to `$flow-feat-plan`; design missing → send to `$flow-feat-design`.
 - `size` XS/S: may start without a design — ask the user for a 2-3 line note on what will be done and save it as a minimal `03-design.md`. No MR/PR plan (always 1 MR/PR).
 - **If `meta.json.mrs` has more than one entry**: pick the **startable** MR/PR — the `pending` one with the **lowest `n` whose `depends_on` are all `merged`**. Dependencies still `pending`/`in_progress` → not startable, even with a low `n`. (No `wave`/`depends_on` — an older plan — → "first pending by `n`".)
   - **Parallel siblings**: startable `pending` MRs/PRs in the **same `wave`** with no dependency between them can be built in parallel or as a train. `manual`: let the user choose which to take now (default: lowest `n`); `guided`/`auto`: take the lowest `n`, record the choice. Mark the chosen one `in_progress`.
   - All `merged` → warn: feature is done, nothing to build (in `unattended`: `done`, the summary saying so).
   - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop. In `unattended`: `blocked`, the reason naming it.
-  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>` and created as `$flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `$flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `$flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `$flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
+  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>`, written to `meta.json.branch` (a relaunch of this part then finds it) and created as `$flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `$flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `$flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `$flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
 
 ## 2. Business brief (before typing)
 

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

@@ -38,7 +38,7 @@ after writing each challenge's Response.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → ask the user to start with `$flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `$flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
 - `size` is `XS` → suggest jumping to `$flow-feat-build` and stop unless the user insists.
 

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

@@ -28,7 +28,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → send the user to `$flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Missing → send the user to `$flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `$flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md`. (flow-core §5)
 - **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `$flow-feat-build`. Stop.

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

@@ -255,7 +255,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 ```
 
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
-- `base` — `unattended` only: the ticket's `base` (the branch every MR/PR of this work starts from and targets; `$flow-work-run` refreshes it on `merged`). Omit it in every other mode.
+- `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `$flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
 - **This work *is* an accepted follow-up** (the ticket came from another work's `followups[]`, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim instead of re-deriving it, and set the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin` entirely.
 

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

@@ -70,7 +70,7 @@ resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`) — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale, keep going.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

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

@@ -85,7 +85,7 @@ back through it, and the hard gates above resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches) — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale to draw on, keep going — triage and reply loop still work.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

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

@@ -50,15 +50,38 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `start` | none for this ticket | `$flow-feat-start <number>` — `$flow-bug-start <number>` when `kind` is `bug` |
 | `start` | exists, `pending` set | a stop whose `ask` never landed, or a crash after it: send the same question again — `ask` with `<work>/<pending.question_file>`, `<work>/<pending.options_file>`, `--recommended 1` when that options file is not empty, `--free-text` when `pending.free_text`, `--gate pending.gate` — and end. `pending` stays as it is; nothing is recomputed |
 | `start` | exists, an `mrs[]` entry `published`, or `meta.json.published` true (a work with no `mrs`) | `done` — the summary says it is waiting for that merge; the next launch for it is `merged` |
-| `start` | exists, nothing pending | the phase after `meta.json.phase` on this work's route (`$flow-feat-start` §4 for a feature, `$flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
+| `start` | exists, nothing pending | the work's branch first (below), then the phase after `meta.json.phase` on this work's route (`$flow-feat-start` §4 for a feature, `$flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
 | `answer` | `pending` set | apply `<cmd> answer` as flow-core §2.1 "The answer comes back" says, then `pending.resume` at `pending.resume_at`. The order fails or prints nothing → `blocked` |
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
-| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `$flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
+| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read (empty → `git.default_base`); the next startable MR/PR → `$flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `$flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `$flow-work-green` — the failed jobs come from `<cmd> events --json` |
 | `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
 
+**The work's branch, on `start`.** The current branch is `meta.json.branch` → nothing to do. It is
+not — a study made on another machine arrives on the ticket's `base`, a run that died before its
+closing order is relaunched there — then, in this order:
+
+1. Anything `git status --porcelain` lists outside `.claude/work/` — untracked files included, since
+   the WIP commit before a closing order takes new files too → `blocked`: the orchestrator owns the
+   checkout.
+2. `meta.json.base` is set and `meta.json.worktree` is a worktree of this checkout (`git worktree
+   list`) whose branch is `meta.json.branch` → run the phase from there: `git switch` would refuse a
+   branch checked out elsewhere. A path that is not such a worktree falls through to step 3.
+3. `meta.json.base` is set — the work was started or re-homed by an unattended run, so its branch is
+   one this kind of run made — and `meta.json.branch` exists locally → `git switch` onto it, change
+   nothing. It holds the commits a previous run left.
+4. `<number>-<slug>` (`slug` from `meta.json`), or `meta.json.branch` without `meta.json.base`,
+   exists locally → `blocked`, naming it: a branch with the work's name that no run here recorded is
+   history nobody can vouch for.
+5. Otherwise create it as `$flow-feat-start` does in this mode: `git switch --create <name>
+   --no-track <base>` (`base` empty → `git.default_base`), `<name>` being `<number>-<slug>`, or
+   `<number>-<slug>-<n>` when the `in_progress` entry of `meta.json.mrs` has `n` > 1 — the name
+   `$flow-feat-build` gives that part, since the first part's name is already published. Then
+   `meta.json.branch` = it, `meta.json.base` = that base, `worktree` and `stacked_on` = `null` — paths and parents from the
+   other machine mean nothing here — and record `{ "key": "unattended:rehomed", "default": "<old branch> → <name> from <base>", "phase": "run" }`.
+
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`
 and the `done` of the table above.

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.85.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.86.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
@@ -263,6 +263,11 @@ assumed:
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it
   stopped; the run trusts that and does not re-check it.
+- **The work is the one `/flow:work:run` found** — by the ticket's `number`, never by the current
+  branch. A phase whose pre-flight says "load `meta.json` by current branch" takes that work instead:
+  the checkout can be the ticket's `base` (a study restored from elsewhere) or an umbrella branch (a
+  part just merged), and neither names the work. `run` puts a work whose branch is not checked out
+  back on it before handing over (its §2).
 - **Before any closing order, commit** what this run left uncommitted outside `.claude/work/`, new
   files included (`WIP <TICKET>: before <gate|order>` — `auto`'s WIP authority): the orchestrator
   keeps only what is committed. **Only on the work branch**: before it exists (`start` refusing a
@@ -297,6 +302,7 @@ run has.
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |
 | `<cmd> ticket` failing or empty, a checkout that is not clean on the ticket's `base` (`start`) | blocked — the orchestrator owns the checkout and the ticket |
+| A work whose branch is not checked out (`run`) | as `/flow:work:run` §2 says — switch onto a branch an unattended run made, or record `unattended:rehomed` and create `<number>-<slug>` from `base`; blocked on a dirty checkout or a branch with the work's name that no run here recorded |
 | Below-XS check (`start`) | record — open the work |
 | "Create the branch?" (`start`), the 2–3 line note an XS `build`/`fix` asks for, a contract the design left in prose (`build`) | record — create it · write the note from the ticket · convert it to literal and say so in the artifact |
 | `git.worktree: ask` | record — in place |

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

@@ -179,7 +179,7 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 **Live panel**: publish it now (flow-core §4 — the panel tools, or `<work-dir>/panel.json`). A bug has no MR/PR train, so it is short: the title (the symptom, `style: title`), a `Now` line for what is starting, a `Next` line for the phase this size routes to, and any sibling repo from §1.6 as a `block` line. Every later phase updates it.
 
-In `unattended`, add `"base"`: the ticket's `base`, the branch the fix starts from and targets. Omit it in every other mode.
+In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 

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

@@ -24,14 +24,14 @@ Implementation phase. Code is written here.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
+- Load `meta.json` by current branch — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
 - `size` M/L: require both `03-design.md` **and** `04-mr-plan.md`. Plan missing → send to `/flow:feat:plan`; design missing → send to `/flow:feat:design`.
 - `size` XS/S: may start without a design — ask the user for a 2-3 line note on what will be done and save it as a minimal `03-design.md`. No MR/PR plan (always 1 MR/PR).
 - **If `meta.json.mrs` has more than one entry**: pick the **startable** MR/PR — the `pending` one with the **lowest `n` whose `depends_on` are all `merged`**. Dependencies still `pending`/`in_progress` → not startable, even with a low `n`. (No `wave`/`depends_on` — an older plan — → "first pending by `n`".)
   - **Parallel siblings**: startable `pending` MRs/PRs in the **same `wave`** with no dependency between them can be built in parallel or as a train. `manual`: let the user choose which to take now (default: lowest `n`); `guided`/`auto`: take the lowest `n`, record the choice. Mark the chosen one `in_progress`.
   - All `merged` → warn: feature is done, nothing to build (in `unattended`: `done`, the summary saying so).
   - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop. In `unattended`: `blocked`, the reason naming it.
-  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>` and created as `/flow:feat:start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow:feat:ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow:feat:start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow:feat:start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
+  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>`, written to `meta.json.branch` (a relaunch of this part then finds it) and created as `/flow:feat:start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow:feat:ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow:feat:start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow:feat:start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
 
 ## 2. Business brief (before typing)
 

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

@@ -34,7 +34,7 @@ after writing each challenge's Response.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → ask the user to start with `/flow:feat:start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Missing → ask the user to start with `/flow:feat:start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
 - `size` is `XS` → suggest jumping to `/flow:feat:build` and stop unless the user insists.
 

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

@@ -24,7 +24,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → send the user to `/flow:feat:start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Missing → send the user to `/flow:feat:start`.
 - Require `design` in `phases_done`. Missing → send to `/flow:feat:design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md`. (flow-core §5)
 - **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow:feat:build`. Stop.

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

@@ -251,7 +251,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 ```
 
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
-- `base` — `unattended` only: the ticket's `base` (the branch every MR/PR of this work starts from and targets; `/flow:work:run` refreshes it on `merged`). Omit it in every other mode.
+- `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow:work:run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
 - **This work *is* an accepted follow-up** (the ticket came from another work's `followups[]`, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim instead of re-deriving it, and set the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin` entirely.
 

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

@@ -66,7 +66,7 @@ resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`) — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale, keep going.
 - Resolve the target MR/PR, in this order:
   1. `{{args}}` if given (IID or URL).

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

@@ -81,7 +81,7 @@ back through it, and the hard gates above resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches) — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale to draw on, keep going — triage and reply loop still work.
 - Resolve the target MR/PR, in this order:
   1. `{{args}}` if given (IID or URL).

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

@@ -46,15 +46,38 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `start` | none for this ticket | `/flow:feat:start <number>` — `/flow:bug:start <number>` when `kind` is `bug` |
 | `start` | exists, `pending` set | a stop whose `ask` never landed, or a crash after it: send the same question again — `ask` with `<work>/<pending.question_file>`, `<work>/<pending.options_file>`, `--recommended 1` when that options file is not empty, `--free-text` when `pending.free_text`, `--gate pending.gate` — and end. `pending` stays as it is; nothing is recomputed |
 | `start` | exists, an `mrs[]` entry `published`, or `meta.json.published` true (a work with no `mrs`) | `done` — the summary says it is waiting for that merge; the next launch for it is `merged` |
-| `start` | exists, nothing pending | the phase after `meta.json.phase` on this work's route (`/flow:feat:start` §4 for a feature, `/flow:bug:start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
+| `start` | exists, nothing pending | the work's branch first (below), then the phase after `meta.json.phase` on this work's route (`/flow:feat:start` §4 for a feature, `/flow:bug:start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
 | `answer` | `pending` set | apply `<cmd> answer` as flow-core §2.1 "The answer comes back" says, then `pending.resume` at `pending.resume_at`. The order fails or prints nothing → `blocked` |
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
-| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow:feat:build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
+| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read (empty → `git.default_base`); the next startable MR/PR → `/flow:feat:build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow:work:respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow:work:green` — the failed jobs come from `<cmd> events --json` |
 | `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
 
+**The work's branch, on `start`.** The current branch is `meta.json.branch` → nothing to do. It is
+not — a study made on another machine arrives on the ticket's `base`, a run that died before its
+closing order is relaunched there — then, in this order:
+
+1. Anything `git status --porcelain` lists outside `.claude/work/` — untracked files included, since
+   the WIP commit before a closing order takes new files too → `blocked`: the orchestrator owns the
+   checkout.
+2. `meta.json.base` is set and `meta.json.worktree` is a worktree of this checkout (`git worktree
+   list`) whose branch is `meta.json.branch` → run the phase from there: `git switch` would refuse a
+   branch checked out elsewhere. A path that is not such a worktree falls through to step 3.
+3. `meta.json.base` is set — the work was started or re-homed by an unattended run, so its branch is
+   one this kind of run made — and `meta.json.branch` exists locally → `git switch` onto it, change
+   nothing. It holds the commits a previous run left.
+4. `<number>-<slug>` (`slug` from `meta.json`), or `meta.json.branch` without `meta.json.base`,
+   exists locally → `blocked`, naming it: a branch with the work's name that no run here recorded is
+   history nobody can vouch for.
+5. Otherwise create it as `/flow:feat:start` does in this mode: `git switch --create <name>
+   --no-track <base>` (`base` empty → `git.default_base`), `<name>` being `<number>-<slug>`, or
+   `<number>-<slug>-<n>` when the `in_progress` entry of `meta.json.mrs` has `n` > 1 — the name
+   `/flow:feat:build` gives that part, since the first part's name is already published. Then
+   `meta.json.branch` = it, `meta.json.base` = that base, `worktree` and `stacked_on` = `null` — paths and parents from the
+   other machine mean nothing here — and record `{ "key": "unattended:rehomed", "default": "<old branch> → <name> from <base>", "phase": "run" }`.
+
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`
 and the `done` of the table above.

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.85.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.86.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
@@ -264,6 +264,11 @@ assumed:
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it
   stopped; the run trusts that and does not re-check it.
+- **The work is the one `/flow-work-run` found** — by the ticket's `number`, never by the current
+  branch. A phase whose pre-flight says "load `meta.json` by current branch" takes that work instead:
+  the checkout can be the ticket's `base` (a study restored from elsewhere) or an umbrella branch (a
+  part just merged), and neither names the work. `run` puts a work whose branch is not checked out
+  back on it before handing over (its §2).
 - **Before any closing order, commit** what this run left uncommitted outside `.claude/work/`, new
   files included (`WIP <TICKET>: before <gate|order>` — `auto`'s WIP authority): the orchestrator
   keeps only what is committed. **Only on the work branch**: before it exists (`start` refusing a
@@ -298,6 +303,7 @@ run has.
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |
 | `<cmd> ticket` failing or empty, a checkout that is not clean on the ticket's `base` (`start`) | blocked — the orchestrator owns the checkout and the ticket |
+| A work whose branch is not checked out (`run`) | as `/flow-work-run` §2 says — switch onto a branch an unattended run made, or record `unattended:rehomed` and create `<number>-<slug>` from `base`; blocked on a dirty checkout or a branch with the work's name that no run here recorded |
 | Below-XS check (`start`) | record — open the work |
 | "Create the branch?" (`start`), the 2–3 line note an XS `build`/`fix` asks for, a contract the design left in prose (`build`) | record — create it · write the note from the ticket · convert it to literal and say so in the artifact |
 | `git.worktree: ask` | record — in place |

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

@@ -183,7 +183,7 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 **Live panel**: publish it now (flow-core §4 — the panel tools, or `<work-dir>/panel.json`). A bug has no MR/PR train, so it is short: the title (the symptom, `style: title`), a `Now` line for what is starting, a `Next` line for the phase this size routes to, and any sibling repo from §1.6 as a `block` line. Every later phase updates it.
 
-In `unattended`, add `"base"`: the ticket's `base`, the branch the fix starts from and targets. Omit it in every other mode.
+In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 

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

@@ -28,14 +28,14 @@ Implementation phase. Code is written here.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
 - `size` M/L: require both `03-design.md` **and** `04-mr-plan.md`. Plan missing → send to `/flow-feat-plan`; design missing → send to `/flow-feat-design`.
 - `size` XS/S: may start without a design — ask the user for a 2-3 line note on what will be done and save it as a minimal `03-design.md`. No MR/PR plan (always 1 MR/PR).
 - **If `meta.json.mrs` has more than one entry**: pick the **startable** MR/PR — the `pending` one with the **lowest `n` whose `depends_on` are all `merged`**. Dependencies still `pending`/`in_progress` → not startable, even with a low `n`. (No `wave`/`depends_on` — an older plan — → "first pending by `n`".)
   - **Parallel siblings**: startable `pending` MRs/PRs in the **same `wave`** with no dependency between them can be built in parallel or as a train. `manual`: let the user choose which to take now (default: lowest `n`); `guided`/`auto`: take the lowest `n`, record the choice. Mark the chosen one `in_progress`.
   - All `merged` → warn: feature is done, nothing to build (in `unattended`: `done`, the summary saying so).
   - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop. In `unattended`: `blocked`, the reason naming it.
-  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>` and created as `/flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
+  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>`, written to `meta.json.branch` (a relaunch of this part then finds it) and created as `/flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
 
 ## 2. Business brief (before typing)
 

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

@@ -38,7 +38,7 @@ after writing each challenge's Response.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → ask the user to start with `/flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `/flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
 - `size` is `XS` → suggest jumping to `/flow-feat-build` and stop unless the user insists.
 

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

@@ -28,7 +28,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → send the user to `/flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → send the user to `/flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `/flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md`. (flow-core §5)
 - **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build`. Stop.

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

@@ -255,7 +255,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 ```
 
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
-- `base` — `unattended` only: the ticket's `base` (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
+- `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
 - **This work *is* an accepted follow-up** (the ticket came from another work's `followups[]`, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim instead of re-deriving it, and set the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin` entirely.
 

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

@@ -70,7 +70,7 @@ resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`) — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale, keep going.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

package/adapters/hermes/skills/flow-work-respond/SKILL.md

@@ -85,7 +85,7 @@ back through it, and the hard gates above resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches) — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale to draw on, keep going — triage and reply loop still work.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

package/adapters/hermes/skills/flow-work-run/SKILL.md

@@ -50,15 +50,38 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `start` | none for this ticket | `/flow-feat-start <number>` — `/flow-bug-start <number>` when `kind` is `bug` |
 | `start` | exists, `pending` set | a stop whose `ask` never landed, or a crash after it: send the same question again — `ask` with `<work>/<pending.question_file>`, `<work>/<pending.options_file>`, `--recommended 1` when that options file is not empty, `--free-text` when `pending.free_text`, `--gate pending.gate` — and end. `pending` stays as it is; nothing is recomputed |
 | `start` | exists, an `mrs[]` entry `published`, or `meta.json.published` true (a work with no `mrs`) | `done` — the summary says it is waiting for that merge; the next launch for it is `merged` |
-| `start` | exists, nothing pending | the phase after `meta.json.phase` on this work's route (`/flow-feat-start` §4 for a feature, `/flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
+| `start` | exists, nothing pending | the work's branch first (below), then the phase after `meta.json.phase` on this work's route (`/flow-feat-start` §4 for a feature, `/flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
 | `answer` | `pending` set | apply `<cmd> answer` as flow-core §2.1 "The answer comes back" says, then `pending.resume` at `pending.resume_at`. The order fails or prints nothing → `blocked` |
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
-| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
+| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read (empty → `git.default_base`); the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow-work-green` — the failed jobs come from `<cmd> events --json` |
 | `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
 
+**The work's branch, on `start`.** The current branch is `meta.json.branch` → nothing to do. It is
+not — a study made on another machine arrives on the ticket's `base`, a run that died before its
+closing order is relaunched there — then, in this order:
+
+1. Anything `git status --porcelain` lists outside `.claude/work/` — untracked files included, since
+   the WIP commit before a closing order takes new files too → `blocked`: the orchestrator owns the
+   checkout.
+2. `meta.json.base` is set and `meta.json.worktree` is a worktree of this checkout (`git worktree
+   list`) whose branch is `meta.json.branch` → run the phase from there: `git switch` would refuse a
+   branch checked out elsewhere. A path that is not such a worktree falls through to step 3.
+3. `meta.json.base` is set — the work was started or re-homed by an unattended run, so its branch is
+   one this kind of run made — and `meta.json.branch` exists locally → `git switch` onto it, change
+   nothing. It holds the commits a previous run left.
+4. `<number>-<slug>` (`slug` from `meta.json`), or `meta.json.branch` without `meta.json.base`,
+   exists locally → `blocked`, naming it: a branch with the work's name that no run here recorded is
+   history nobody can vouch for.
+5. Otherwise create it as `/flow-feat-start` does in this mode: `git switch --create <name>
+   --no-track <base>` (`base` empty → `git.default_base`), `<name>` being `<number>-<slug>`, or
+   `<number>-<slug>-<n>` when the `in_progress` entry of `meta.json.mrs` has `n` > 1 — the name
+   `/flow-feat-build` gives that part, since the first part's name is already published. Then
+   `meta.json.branch` = it, `meta.json.base` = that base, `worktree` and `stacked_on` = `null` — paths and parents from the
+   other machine mean nothing here — and record `{ "key": "unattended:rehomed", "default": "<old branch> → <name> from <base>", "phase": "run" }`.
+
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`
 and the `done` of the table above.

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.85.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.86.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
@@ -263,6 +263,11 @@ assumed:
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it
   stopped; the run trusts that and does not re-check it.
+- **The work is the one `/flow-work-run` found** — by the ticket's `number`, never by the current
+  branch. A phase whose pre-flight says "load `meta.json` by current branch" takes that work instead:
+  the checkout can be the ticket's `base` (a study restored from elsewhere) or an umbrella branch (a
+  part just merged), and neither names the work. `run` puts a work whose branch is not checked out
+  back on it before handing over (its §2).
 - **Before any closing order, commit** what this run left uncommitted outside `.claude/work/`, new
   files included (`WIP <TICKET>: before <gate|order>` — `auto`'s WIP authority): the orchestrator
   keeps only what is committed. **Only on the work branch**: before it exists (`start` refusing a
@@ -297,6 +302,7 @@ run has.
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |
 | `<cmd> ticket` failing or empty, a checkout that is not clean on the ticket's `base` (`start`) | blocked — the orchestrator owns the checkout and the ticket |
+| A work whose branch is not checked out (`run`) | as `/flow-work-run` §2 says — switch onto a branch an unattended run made, or record `unattended:rehomed` and create `<number>-<slug>` from `base`; blocked on a dirty checkout or a branch with the work's name that no run here recorded |
 | Below-XS check (`start`) | record — open the work |
 | "Create the branch?" (`start`), the 2–3 line note an XS `build`/`fix` asks for, a contract the design left in prose (`build`) | record — create it · write the note from the ticket · convert it to literal and say so in the artifact |
 | `git.worktree: ask` | record — in place |

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

@@ -181,7 +181,7 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 **Live panel**: publish it now (flow-core §4 — the panel tools, or `<work-dir>/panel.json`). A bug has no MR/PR train, so it is short: the title (the symptom, `style: title`), a `Now` line for what is starting, a `Next` line for the phase this size routes to, and any sibling repo from §1.6 as a `block` line. Every later phase updates it.
 
-In `unattended`, add `"base"`: the ticket's `base`, the branch the fix starts from and targets. Omit it in every other mode.
+In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 

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

@@ -26,14 +26,14 @@ Implementation phase. Code is written here.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `03-design.md` (§"External contracts", verbatim) and the current MR/PR entry of `04-mr-plan.md`. (flow-core §5)
 - `size` M/L: require both `03-design.md` **and** `04-mr-plan.md`. Plan missing → send to `/flow-feat-plan`; design missing → send to `/flow-feat-design`.
 - `size` XS/S: may start without a design — ask the user for a 2-3 line note on what will be done and save it as a minimal `03-design.md`. No MR/PR plan (always 1 MR/PR).
 - **If `meta.json.mrs` has more than one entry**: pick the **startable** MR/PR — the `pending` one with the **lowest `n` whose `depends_on` are all `merged`**. Dependencies still `pending`/`in_progress` → not startable, even with a low `n`. (No `wave`/`depends_on` — an older plan — → "first pending by `n`".)
   - **Parallel siblings**: startable `pending` MRs/PRs in the **same `wave`** with no dependency between them can be built in parallel or as a train. `manual`: let the user choose which to take now (default: lowest `n`); `guided`/`auto`: take the lowest `n`, record the choice. Mark the chosen one `in_progress`.
   - All `merged` → warn: feature is done, nothing to build (in `unattended`: `done`, the summary saying so).
   - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop. In `unattended`: `blocked`, the reason naming it.
-  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>` and created as `/flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
+  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `meta.json.base` (empty → `git.default_base`) — the base the orchestrator gave the ticket, an umbrella branch once a split task's first part is merged. That branch may exist only on the remote, or locally without the part that just merged: `git fetch origin <base>` when a remote is configured (best-effort — a fetch the container cannot make is not an error), then start from `origin/<base>` when it resolves, the local `<base>` otherwise. Named `<ticket>-<slug>-<n>`, written to `meta.json.branch` (a relaunch of this part then finds it) and created as `/flow-feat-start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; that base is already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow-feat-ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow-feat-start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow-feat-start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
 
 ## 2. Business brief (before typing)
 

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

@@ -36,7 +36,7 @@ after writing each challenge's Response.
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → ask the user to start with `/flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `/flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
 - `size` is `XS` → suggest jumping to `/flow-feat-build` and stop unless the user insists.
 

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

@@ -26,7 +26,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 
 ## 1. Pre-flight
 
-- Load `meta.json` by current branch. Missing → send the user to `/flow-feat-start`.
+- Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → send the user to `/flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `/flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md`. (flow-core §5)
 - **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build`. Stop.

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

@@ -253,7 +253,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 ```
 
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
-- `base` — `unattended` only: the ticket's `base` (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
+- `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
 - **This work *is* an accepted follow-up** (the ticket came from another work's `followups[]`, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim instead of re-deriving it, and set the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin` entirely.
 

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

@@ -68,7 +68,7 @@ resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`) — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale, keep going.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

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

@@ -83,7 +83,7 @@ back through it, and the hard gates above resolve this way:
 
 ## 1. Pre-flight — locate the work and the MR/PR
 
-- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
+- Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches) — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)
 - **No** work folder (MR opened outside the flow) → **lightweight mode**: skip `meta.json`/artifact reads, warn once that there is no recorded design rationale to draw on, keep going — triage and reply loop still work.
 - Resolve the target MR/PR, in this order:
   1. `$ARGUMENTS` if given (IID or URL).

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

@@ -48,15 +48,38 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `start` | none for this ticket | `/flow-feat-start <number>` — `/flow-bug-start <number>` when `kind` is `bug` |
 | `start` | exists, `pending` set | a stop whose `ask` never landed, or a crash after it: send the same question again — `ask` with `<work>/<pending.question_file>`, `<work>/<pending.options_file>`, `--recommended 1` when that options file is not empty, `--free-text` when `pending.free_text`, `--gate pending.gate` — and end. `pending` stays as it is; nothing is recomputed |
 | `start` | exists, an `mrs[]` entry `published`, or `meta.json.published` true (a work with no `mrs`) | `done` — the summary says it is waiting for that merge; the next launch for it is `merged` |
-| `start` | exists, nothing pending | the phase after `meta.json.phase` on this work's route (`/flow-feat-start` §4 for a feature, `/flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
+| `start` | exists, nothing pending | the work's branch first (below), then the phase after `meta.json.phase` on this work's route (`/flow-feat-start` §4 for a feature, `/flow-bug-start`'s routing for a bug, by `size`), or `phase` itself when its own Close never ran. A work folder the orchestrator restored from a study made elsewhere enters here, and is never started a second time |
 | `answer` | `pending` set | apply `<cmd> answer` as flow-core §2.1 "The answer comes back" says, then `pending.resume` at `pending.resume_at`. The order fails or prints nothing → `blocked` |
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
-| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
+| `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read (empty → `git.default_base`); the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow-work-green` — the failed jobs come from `<cmd> events --json` |
 | `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
 
+**The work's branch, on `start`.** The current branch is `meta.json.branch` → nothing to do. It is
+not — a study made on another machine arrives on the ticket's `base`, a run that died before its
+closing order is relaunched there — then, in this order:
+
+1. Anything `git status --porcelain` lists outside `.claude/work/` — untracked files included, since
+   the WIP commit before a closing order takes new files too → `blocked`: the orchestrator owns the
+   checkout.
+2. `meta.json.base` is set and `meta.json.worktree` is a worktree of this checkout (`git worktree
+   list`) whose branch is `meta.json.branch` → run the phase from there: `git switch` would refuse a
+   branch checked out elsewhere. A path that is not such a worktree falls through to step 3.
+3. `meta.json.base` is set — the work was started or re-homed by an unattended run, so its branch is
+   one this kind of run made — and `meta.json.branch` exists locally → `git switch` onto it, change
+   nothing. It holds the commits a previous run left.
+4. `<number>-<slug>` (`slug` from `meta.json`), or `meta.json.branch` without `meta.json.base`,
+   exists locally → `blocked`, naming it: a branch with the work's name that no run here recorded is
+   history nobody can vouch for.
+5. Otherwise create it as `/flow-feat-start` does in this mode: `git switch --create <name>
+   --no-track <base>` (`base` empty → `git.default_base`), `<name>` being `<number>-<slug>`, or
+   `<number>-<slug>-<n>` when the `in_progress` entry of `meta.json.mrs` has `n` > 1 — the name
+   `/flow-feat-build` gives that part, since the first part's name is already published. Then
+   `meta.json.branch` = it, `meta.json.base` = that base, `worktree` and `stacked_on` = `null` — paths and parents from the
+   other machine mean nothing here — and record `{ "key": "unattended:rehomed", "default": "<old branch> → <name> from <base>", "phase": "run" }`.
+
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`
 and the `done` of the table above.

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,19 @@ 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.86.0 — An unattended run builds a study made on another machine  ·  2026-10-01
+
+**In short**
+- **A study restored on a server is built there, not redone.** When the orchestrator copies a work
+  folder made on a laptop and launches `/flow:work:run` on the ticket's base branch, the run gives
+  the work a branch of its own (`<number>-<slug>`, from that base) and goes straight to the next
+  phase — `build` after a plan. It never designs or plans the ticket again.
+- **A run relaunched after a crash goes back to its branch** instead of failing to find its work.
+- **The next part of a split task finds its work** while the checkout stands on the umbrella branch.
+- **It stops instead of guessing** when the checkout has uncommitted changes, or holds a branch with
+  the work's name that the work never recorded.
+- Nothing changes in `manual`, `guided` or `auto`. Part of #186.
+
 ## v0.85.1 — An unattended run reads the orchestrator's answers as agent-runner sends them  ·  2026-10-01
 
 **In short**