flow-workflows 0.76.0 → 0.77.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.76.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.77.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
@@ -296,6 +296,9 @@ prose describing a file is otherwise obeyed to the letter.
     "",
     {"ref": "#1", "text": "batch read sources", "mark": "wait", "link": "https://gitlab.com/…/merge_requests/9977"},
     {"ref": "#2", "text": "per-event and per-recipient counters", "mark": "current"},
+    {"ref": "1–2", "text": "counter columns + migration · repository query", "mark": "done", "indent": 4},
+    {"ref": "3", "text": "per-recipient aggregation in the use case", "mark": "current", "indent": 4},
+    {"ref": "4", "text": "expose both counters on the endpoint", "mark": "pending", "indent": 4},
     {"ref": "#3–#6", "text": "channel map · use case · document detail · route", "mark": "pending"},
     "",
     {"ref": "Now", "text": "unit suite and the test agent over #2", "mark": "info"},
@@ -307,10 +310,10 @@ prose describing a file is otherwise obeyed to the letter.
 }
 ```
 
-- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
+- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one per block) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
 - **`ref` need not be a number**: `#1`, `#3–#6`, `Now`, `Next`, `Decision`. Column width is per block; blocks are separated by blank lines — use them so the MR/PR train and the labels below do not drag each other wide.
 - **`link` is a field, never a URL inside `text`** — and **every line that names an MR/PR carries it**: the train entries, a blocker about somebody else's MR/PR, a `Now` or `Next` about the open one. The URL is in `meta.json.mrs[].url` or in whatever recorded that blocker; a bare `!10327` typed into `text` is a number the reader cannot make clickable, which is the whole point of the field. No URL recorded anywhere → the number in `text` and nothing else, and go and record it.
-- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
+- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (2b) **the plan steps of the MR/PR being built**, right under its train entry — only while `build` or `fix` is working through a written plan (`$flow-feat-build §2.0ter`, `$flow-bug-fix §2.0bis`); one line per step, `ref` its number (`1`, `2`…), `indent: 4`, `key` `step-<n>`, `mark` `done` · `current` · `pending` from the plan's ticks in the phase artifact — never ahead of them; past three finished steps they collapse into one `done` line (`1–4`, `key` `steps-done`), and past three pending ones the tail collapses the same way (`key` `steps-pending`), so the block stays at five lines or fewer; drop the block when the MR/PR's build ends. This is the step list the user watches: a harness's own task list, where there is one, is a bonus on top — the panel is what every harness can feed; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
 - **Rules:** `phase` is the phase you are **running now** (not `meta.json.phase`, which advances only at Close). `header: true` means ticket, type, phase and age are drawn by the reader — do not repeat them in `lines`. Keep it under ~14 lines. Every fact from `meta.json` and the artifacts — an invented MR/PR state is worse than a blank panel. Write in the language of the work's artifacts.
 
 ### 4.2 Over the terminal's MCP — `panel_set` once, `panel_patch` from then on
@@ -385,6 +388,10 @@ that never asked, because they answered it and the screen says it did not land;
 nobody clears keeps that tab claiming them for ever. The same applies to a blocker that lifted and
 to a `wait` line whose MR/PR merged.
 
+**(f) Each plan step that lands** (the (2b) block): one patch, the moment its tick goes into the
+phase artifact — that step to `done`, the next to `current`, `Now` moved on. Not batched at the end
+of the MR/PR: a list that jumps from nothing to finished told the user nothing while it mattered.
+
 ### 4.5 `meta.json.cost[]` — what a phase measured, when it could
 
 A phase that can measure what it spent appends one entry: `{ "phase": "review", "at": "<ISO>",

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

@@ -95,7 +95,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - 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 → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `$flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: tick its numbered steps off in `04-fix.md` where they stand, and show them in the live panel's step block (flow-core §4.1 (2b), patched per §4.4 (f)); a harness task list, if there is one, goes on top as `$flow-feat-build §2.1` says. 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.
 

package/adapters/codex/skills/flow-doctor/SKILL.md

@@ -235,7 +235,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
-- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) — informational only. The plan steps are shown in the live panel and recorded in the phase artifact; a harness task list is an extra. Absent on Claude Code → one line saying it is withheld from newer models unless `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` is set under `env`, for whoever wants it without a panel.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -150,7 +150,9 @@ Execution mode:
 
 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.
 
-**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+**The steps go to the live panel** (flow-core §4.1 (2b), §4.4 (f)) — that is the list the user watches, whatever the harness. Publish the block when the first step starts, patch it as each one lands.
+
+**A harness task list is optional on top.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all (Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true`). There → seed it too; not there → nothing is missing and nothing is said. Either way the plan in `05-implementation.md` is the record: tick each step there (`- [x]`) as it lands — the panel and any task list follow the ticks, never the other way round.
 
 ### 2.1bis The premise this change rests on (any size, XS included)
 
@@ -201,7 +203,7 @@ The step's changes are **always reported before anything is recorded**. Who deci
 
 **After completing each plan step**:
 
-1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
+1. **Tick the step** in `05-implementation.md`, patch the panel's step block (flow-core §4.4 (f)), and mark it `completed` in the harness task list if there is one (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.76.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.77.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
@@ -295,6 +295,9 @@ prose describing a file is otherwise obeyed to the letter.
     "",
     {"ref": "#1", "text": "batch read sources", "mark": "wait", "link": "https://gitlab.com/…/merge_requests/9977"},
     {"ref": "#2", "text": "per-event and per-recipient counters", "mark": "current"},
+    {"ref": "1–2", "text": "counter columns + migration · repository query", "mark": "done", "indent": 4},
+    {"ref": "3", "text": "per-recipient aggregation in the use case", "mark": "current", "indent": 4},
+    {"ref": "4", "text": "expose both counters on the endpoint", "mark": "pending", "indent": 4},
     {"ref": "#3–#6", "text": "channel map · use case · document detail · route", "mark": "pending"},
     "",
     {"ref": "Now", "text": "unit suite and the test agent over #2", "mark": "info"},
@@ -306,10 +309,10 @@ prose describing a file is otherwise obeyed to the letter.
 }
 ```
 
-- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
+- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one per block) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
 - **`ref` need not be a number**: `#1`, `#3–#6`, `Now`, `Next`, `Decision`. Column width is per block; blocks are separated by blank lines — use them so the MR/PR train and the labels below do not drag each other wide.
 - **`link` is a field, never a URL inside `text`** — and **every line that names an MR/PR carries it**: the train entries, a blocker about somebody else's MR/PR, a `Now` or `Next` about the open one. The URL is in `meta.json.mrs[].url` or in whatever recorded that blocker; a bare `!10327` typed into `text` is a number the reader cannot make clickable, which is the whole point of the field. No URL recorded anywhere → the number in `text` and nothing else, and go and record it.
-- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
+- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (2b) **the plan steps of the MR/PR being built**, right under its train entry — only while `build` or `fix` is working through a written plan (`/flow:feat:build §2.0ter`, `/flow:bug:fix §2.0bis`); one line per step, `ref` its number (`1`, `2`…), `indent: 4`, `key` `step-<n>`, `mark` `done` · `current` · `pending` from the plan's ticks in the phase artifact — never ahead of them; past three finished steps they collapse into one `done` line (`1–4`, `key` `steps-done`), and past three pending ones the tail collapses the same way (`key` `steps-pending`), so the block stays at five lines or fewer; drop the block when the MR/PR's build ends. This is the step list the user watches: a harness's own task list, where there is one, is a bonus on top — the panel is what every harness can feed; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
 - **Rules:** `phase` is the phase you are **running now** (not `meta.json.phase`, which advances only at Close). `header: true` means ticket, type, phase and age are drawn by the reader — do not repeat them in `lines`. Keep it under ~14 lines. Every fact from `meta.json` and the artifacts — an invented MR/PR state is worse than a blank panel. Write in the language of the work's artifacts.
 
 ### 4.2 Over the terminal's MCP — `panel_set` once, `panel_patch` from then on
@@ -384,6 +387,10 @@ that never asked, because they answered it and the screen says it did not land;
 nobody clears keeps that tab claiming them for ever. The same applies to a blocker that lifted and
 to a `wait` line whose MR/PR merged.
 
+**(f) Each plan step that lands** (the (2b) block): one patch, the moment its tick goes into the
+phase artifact — that step to `done`, the next to `current`, `Now` moved on. Not batched at the end
+of the MR/PR: a list that jumps from nothing to finished told the user nothing while it mattered.
+
 ### 4.5 `meta.json.cost[]` — what a phase measured, when it could
 
 A phase that can measure what it spent appends one entry: `{ "phase": "review", "at": "<ISO>",

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

@@ -91,7 +91,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - 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 → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow:feat:build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: tick its numbered steps off in `04-fix.md` where they stand, and show them in the live panel's step block (flow-core §4.1 (2b), patched per §4.4 (f)); a harness task list, if there is one, goes on top as `/flow:feat:build §2.1` says. 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.
 

package/adapters/gemini/commands/flow/doctor.toml

@@ -231,7 +231,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
-- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) — informational only. The plan steps are shown in the live panel and recorded in the phase artifact; a harness task list is an extra. Absent on Claude Code → one line saying it is withheld from newer models unless `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` is set under `env`, for whoever wants it without a panel.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -146,7 +146,9 @@ Execution mode:
 
 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.
 
-**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+**The steps go to the live panel** (flow-core §4.1 (2b), §4.4 (f)) — that is the list the user watches, whatever the harness. Publish the block when the first step starts, patch it as each one lands.
+
+**A harness task list is optional on top.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all (Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true`). There → seed it too; not there → nothing is missing and nothing is said. Either way the plan in `05-implementation.md` is the record: tick each step there (`- [x]`) as it lands — the panel and any task list follow the ticks, never the other way round.
 
 ### 2.1bis The premise this change rests on (any size, XS included)
 
@@ -197,7 +199,7 @@ The step's changes are **always reported before anything is recorded**. Who deci
 
 **After completing each plan step**:
 
-1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
+1. **Tick the step** in `05-implementation.md`, patch the panel's step block (flow-core §4.4 (f)), and mark it `completed` in the harness task list if there is one (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.76.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.77.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
@@ -296,6 +296,9 @@ prose describing a file is otherwise obeyed to the letter.
     "",
     {"ref": "#1", "text": "batch read sources", "mark": "wait", "link": "https://gitlab.com/…/merge_requests/9977"},
     {"ref": "#2", "text": "per-event and per-recipient counters", "mark": "current"},
+    {"ref": "1–2", "text": "counter columns + migration · repository query", "mark": "done", "indent": 4},
+    {"ref": "3", "text": "per-recipient aggregation in the use case", "mark": "current", "indent": 4},
+    {"ref": "4", "text": "expose both counters on the endpoint", "mark": "pending", "indent": 4},
     {"ref": "#3–#6", "text": "channel map · use case · document detail · route", "mark": "pending"},
     "",
     {"ref": "Now", "text": "unit suite and the test agent over #2", "mark": "info"},
@@ -307,10 +310,10 @@ prose describing a file is otherwise obeyed to the letter.
 }
 ```
 
-- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
+- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one per block) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
 - **`ref` need not be a number**: `#1`, `#3–#6`, `Now`, `Next`, `Decision`. Column width is per block; blocks are separated by blank lines — use them so the MR/PR train and the labels below do not drag each other wide.
 - **`link` is a field, never a URL inside `text`** — and **every line that names an MR/PR carries it**: the train entries, a blocker about somebody else's MR/PR, a `Now` or `Next` about the open one. The URL is in `meta.json.mrs[].url` or in whatever recorded that blocker; a bare `!10327` typed into `text` is a number the reader cannot make clickable, which is the whole point of the field. No URL recorded anywhere → the number in `text` and nothing else, and go and record it.
-- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
+- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (2b) **the plan steps of the MR/PR being built**, right under its train entry — only while `build` or `fix` is working through a written plan (`/flow-feat-build §2.0ter`, `/flow-bug-fix §2.0bis`); one line per step, `ref` its number (`1`, `2`…), `indent: 4`, `key` `step-<n>`, `mark` `done` · `current` · `pending` from the plan's ticks in the phase artifact — never ahead of them; past three finished steps they collapse into one `done` line (`1–4`, `key` `steps-done`), and past three pending ones the tail collapses the same way (`key` `steps-pending`), so the block stays at five lines or fewer; drop the block when the MR/PR's build ends. This is the step list the user watches: a harness's own task list, where there is one, is a bonus on top — the panel is what every harness can feed; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
 - **Rules:** `phase` is the phase you are **running now** (not `meta.json.phase`, which advances only at Close). `header: true` means ticket, type, phase and age are drawn by the reader — do not repeat them in `lines`. Keep it under ~14 lines. Every fact from `meta.json` and the artifacts — an invented MR/PR state is worse than a blank panel. Write in the language of the work's artifacts.
 
 ### 4.2 Over the terminal's MCP — `panel_set` once, `panel_patch` from then on
@@ -385,6 +388,10 @@ that never asked, because they answered it and the screen says it did not land;
 nobody clears keeps that tab claiming them for ever. The same applies to a blocker that lifted and
 to a `wait` line whose MR/PR merged.
 
+**(f) Each plan step that lands** (the (2b) block): one patch, the moment its tick goes into the
+phase artifact — that step to `done`, the next to `current`, `Now` moved on. Not batched at the end
+of the MR/PR: a list that jumps from nothing to finished told the user nothing while it mattered.
+
 ### 4.5 `meta.json.cost[]` — what a phase measured, when it could
 
 A phase that can measure what it spent appends one entry: `{ "phase": "review", "at": "<ISO>",

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

@@ -95,7 +95,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - 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 → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: tick its numbered steps off in `04-fix.md` where they stand, and show them in the live panel's step block (flow-core §4.1 (2b), patched per §4.4 (f)); a harness task list, if there is one, goes on top as `/flow-feat-build §2.1` says. 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.
 

package/adapters/hermes/skills/flow-doctor/SKILL.md

@@ -235,7 +235,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
-- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) — informational only. The plan steps are shown in the live panel and recorded in the phase artifact; a harness task list is an extra. Absent on Claude Code → one line saying it is withheld from newer models unless `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` is set under `env`, for whoever wants it without a panel.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -150,7 +150,9 @@ Execution mode:
 
 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.
 
-**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+**The steps go to the live panel** (flow-core §4.1 (2b), §4.4 (f)) — that is the list the user watches, whatever the harness. Publish the block when the first step starts, patch it as each one lands.
+
+**A harness task list is optional on top.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all (Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true`). There → seed it too; not there → nothing is missing and nothing is said. Either way the plan in `05-implementation.md` is the record: tick each step there (`- [x]`) as it lands — the panel and any task list follow the ticks, never the other way round.
 
 ### 2.1bis The premise this change rests on (any size, XS included)
 
@@ -201,7 +203,7 @@ The step's changes are **always reported before anything is recorded**. Who deci
 
 **After completing each plan step**:
 
-1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
+1. **Tick the step** in `05-implementation.md`, patch the panel's step block (flow-core §4.4 (f)), and mark it `completed` in the harness task list if there is one (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.76.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.77.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
@@ -295,6 +295,9 @@ prose describing a file is otherwise obeyed to the letter.
     "",
     {"ref": "#1", "text": "batch read sources", "mark": "wait", "link": "https://gitlab.com/…/merge_requests/9977"},
     {"ref": "#2", "text": "per-event and per-recipient counters", "mark": "current"},
+    {"ref": "1–2", "text": "counter columns + migration · repository query", "mark": "done", "indent": 4},
+    {"ref": "3", "text": "per-recipient aggregation in the use case", "mark": "current", "indent": 4},
+    {"ref": "4", "text": "expose both counters on the endpoint", "mark": "pending", "indent": 4},
     {"ref": "#3–#6", "text": "channel map · use case · document detail · route", "mark": "pending"},
     "",
     {"ref": "Now", "text": "unit suite and the test agent over #2", "mark": "info"},
@@ -306,10 +309,10 @@ prose describing a file is otherwise obeyed to the letter.
 }
 ```
 
-- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
+- **`mark` says what a line is**; the reader draws it. `done` · `current` (at most one per block) · `pending` · `wait` (waiting on someone else: an open MR/PR, a user decision) · `block` · `info`. Marked lines form an aligned column: symbol, `ref`, text, link pinned right. Do not set `style` on a marked line — except `mark: "info"` + `style: ok|warn|error` when the colour *is* the information (a monitoring verdict).
 - **`ref` need not be a number**: `#1`, `#3–#6`, `Now`, `Next`, `Decision`. Column width is per block; blocks are separated by blank lines — use them so the MR/PR train and the labels below do not drag each other wide.
 - **`link` is a field, never a URL inside `text`** — and **every line that names an MR/PR carries it**: the train entries, a blocker about somebody else's MR/PR, a `Now` or `Next` about the open one. The URL is in `meta.json.mrs[].url` or in whatever recorded that blocker; a bare `!10327` typed into `text` is a number the reader cannot make clickable, which is the whole point of the field. No URL recorded anywhere → the number in `text` and nothing else, and go and record it.
-- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
+- **Order:** (1) work title (`style: title`, no mark); (2) the MR/PR train, one entry per `meta.json.mrs[]` with `ref` `#n`, short title, real-state `mark`, `link` when there is a URL — not-started entries collapse into one `#a–#z` `pending` line; omit the block without `mrs`; (2b) **the plan steps of the MR/PR being built**, right under its train entry — only while `build` or `fix` is working through a written plan (`/flow-feat-build §2.0ter`, `/flow-bug-fix §2.0bis`); one line per step, `ref` its number (`1`, `2`…), `indent: 4`, `key` `step-<n>`, `mark` `done` · `current` · `pending` from the plan's ticks in the phase artifact — never ahead of them; past three finished steps they collapse into one `done` line (`1–4`, `key` `steps-done`), and past three pending ones the tail collapses the same way (`key` `steps-pending`), so the block stays at five lines or fewer; drop the block when the MR/PR's build ends. This is the step list the user watches: a harness's own task list, where there is one, is a bonus on top — the panel is what every harness can feed; (3) `Now` — what is running, the one fact `meta.json` cannot hold; (4) `Next`; (5) `Decision`, `mark: wait`, **only** when parked on the user — over the tools it travels with `attention: "wait"` (§4.2), and both are cleared together; (6) blockers, `mark: block` (a sibling repo with `contract_handoff: pending`, a red pipeline, an unmerged dependency).
 - **Rules:** `phase` is the phase you are **running now** (not `meta.json.phase`, which advances only at Close). `header: true` means ticket, type, phase and age are drawn by the reader — do not repeat them in `lines`. Keep it under ~14 lines. Every fact from `meta.json` and the artifacts — an invented MR/PR state is worse than a blank panel. Write in the language of the work's artifacts.
 
 ### 4.2 Over the terminal's MCP — `panel_set` once, `panel_patch` from then on
@@ -384,6 +387,10 @@ that never asked, because they answered it and the screen says it did not land;
 nobody clears keeps that tab claiming them for ever. The same applies to a blocker that lifted and
 to a `wait` line whose MR/PR merged.
 
+**(f) Each plan step that lands** (the (2b) block): one patch, the moment its tick goes into the
+phase artifact — that step to `done`, the next to `current`, `Now` moved on. Not batched at the end
+of the MR/PR: a list that jumps from nothing to finished told the user nothing while it mattered.
+
 ### 4.5 `meta.json.cost[]` — what a phase measured, when it could
 
 A phase that can measure what it spent appends one entry: `{ "phase": "review", "at": "<ISO>",

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

@@ -93,7 +93,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - 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 → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: tick its numbered steps off in `04-fix.md` where they stand, and show them in the live panel's step block (flow-core §4.1 (2b), patched per §4.4 (f)); a harness task list, if there is one, goes on top as `/flow-feat-build §2.1` says. 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.
 

package/adapters/opencode/commands/flow-doctor.md

@@ -233,7 +233,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
-- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) — informational only. The plan steps are shown in the live panel and recorded in the phase artifact; a harness task list is an extra. Absent on Claude Code → one line saying it is withheld from newer models unless `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` is set under `env`, for whoever wants it without a panel.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -148,7 +148,9 @@ Execution mode:
 
 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.
 
-**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+**The steps go to the live panel** (flow-core §4.1 (2b), §4.4 (f)) — that is the list the user watches, whatever the harness. Publish the block when the first step starts, patch it as each one lands.
+
+**A harness task list is optional on top.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all (Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true`). There → seed it too; not there → nothing is missing and nothing is said. Either way the plan in `05-implementation.md` is the record: tick each step there (`- [x]`) as it lands — the panel and any task list follow the ticks, never the other way round.
 
 ### 2.1bis The premise this change rests on (any size, XS included)
 
@@ -199,7 +201,7 @@ The step's changes are **always reported before anything is recorded**. Who deci
 
 **After completing each plan step**:
 
-1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
+1. **Tick the step** in `05-implementation.md`, patch the panel's step block (flow-core §4.4 (f)), and mark it `completed` in the harness task list if there is one (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,21 @@ 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.77.0 — The steps of the MR/PR you are on are on the panel  ·  2026-09-22
+
+**In short**
+- **The live panel shows the plan steps of the MR/PR being built**, indented under its entry in the
+  train: finished, current and pending, updated as each one lands — on every harness that feeds the
+  panel, not only on the one that has a task list.
+- **A harness task list becomes an extra.** `build` and `fix` still seed it where it exists, but
+  nothing depends on it, and `/flow:doctor` reports it as information rather than a warning.
+
+v0.76.0 made the step list findable on Claude Code, where it only exists behind
+`CLAUDE_CODE_ENABLE_TODO_TOOLS` and costs context in every session. The panel already had the words
+for it (`done` · `current` · `pending`) and is fed the same way from Codex, OpenCode or zcode. The
+ticks in the phase artifact stay the record; the panel and any task list follow them. Steps past three
+on either side collapse into one line, so the block never takes more than five.
+
 ## v0.76.0 — The plan was written for a list the terminal was never given  ·  2026-09-22
 
 **In short**