flow-workflows 0.69.0 → 0.70.0

package/README.md

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

package/adapters/codex/CORE.md

@@ -17,7 +17,7 @@ Every `$flow-*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.69.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed

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

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

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

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

package/adapters/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.69.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed

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

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

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

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

package/adapters/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.69.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed

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

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

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

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

package/adapters/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.69.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.70.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed

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

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

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

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

package/package.json

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

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

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,39 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.70.0 — The plan each MR/PR was built from belonged to the feature  ·  2026-09-21
+
+**In short**
+- **`/flow:feat:build` §2.0ter plans the MR/PR it is about to build**: numbered steps, each with its file and the test that proves it, plus the point of no return and what is out of scope. Gated on the entry already in `meta.json.mrs` — `lines_est > 150` or `files_est > 5` — so a small MR/PR never pays for a planning round.
+- **`/flow:bug:fix` §2.0bis gives the same shape to a fix of more than two steps**, and leads it with the bug flow's own rule: the regression test is a step, and it comes first when it can fail before the fix.
+- **`TaskCreate` seeds from that plan** instead of the design's implementation order, which was written before `/flow:feat:plan` split anything and handed each MR/PR its siblings' steps.
+- **A compaction gives the contract back.** The `SessionStart` hook reads the event's `source`, and on `compact` prints the brief and plan from `05-implementation.md` or `04-fix.md` instead of "where was I" — and never invites a resume of work that never stopped.
+- **`manual`/`guided` stop on the plan with one question; `auto` prints it and builds.** No plan-mode primitive is used, so every harness gets the same step.
+
+`03-design.md` writes its implementation plan before the delivery split exists, so its steps never
+knew which MR/PR they would land in — and `build` seeded its task list from that same list all the
+same. Between the business brief, which says what the user gets and never in which file, and the
+first edit, there was nothing that named a path. On a large MR/PR the work was being discovered
+while it was typed, and the record of it arrived afterwards.
+
+The gate reuses numbers that were already there. `/flow:feat:plan` estimates `lines_est` and
+`files_est` per MR/PR, `§2.3` already measures the real diff against them, and the same pair now
+decides whether a plan is worth writing. A bug has no `mrs[]` to estimate against — and an M bug is
+often three lines in a hard place — so there the trigger stays the one the fix flow already used,
+more than two steps, and a fix that turns into a third step mid-way comes back and writes it then.
+
+The order is the decision being asked about, which is why the plan stops for one. On a bug that is
+sharpest: `validate` is what proves a fix and `review` refuses to run without it above size S, so a
+plan that leaves the regression test until last puts the one step that can still refute the root
+cause after everything has been built on it.
+
+Keeping a plan in context is a separate problem from writing one, and it is the hook's, not the
+phase's. Re-reading the plan at every checkpoint spends tokens on the turns that lost nothing;
+`SessionStart` already ran after every compaction and answered with the wrong thing, so the cost
+now falls only on the compactions that actually happen. What it prints is labelled as a record of
+what was agreed rather than an instruction — a hook's stdout arrives as context, and a stale plan
+read as an order outranks the decision that replaced it.
+
 ## v0.69.0 — Waiting on the pipeline was paid for at the main thread's price  ·  2026-09-21
 
 **In short**