flow-workflows 0.80.0 → 0.81.0

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

@@ -40,7 +40,7 @@ Mandatory review phase. **`/flow-feat-ship` cannot run without passing through h
   member runs its own `git diff` and opens the same files pays for that material once per agent, and
   a reviewer that spends its turns exploring has fewer left to review. **Any non-zero exit is a
   fallback, not a failure** — no CLI on the machine, a base that does not resolve, a network that
-  cannot reach it: read the diff from git as before and carry on, once, without retrying variants.
+  cannot reach it: read the diff from git and carry on, once, without retrying variants.
   What is not optional is the `Review path` line of §8: a round that skipped the pack and one that
   used it are indistinguishable from the artifact otherwise, which is how a phase quietly stops
   paying for itself.
@@ -69,7 +69,7 @@ Mandatory review phase. **`/flow-feat-ship` cannot run without passing through h
 
 ### 1.5 Freeze what you are about to read, and resolve what to compare it against
 
-Two questions, answered here and nowhere later: **which tree** this round reads, and **against which base**. Both used to be answered implicitly — by the checkout as it happened to stand at each moment, and by `git.default_base` always — and both answers were wrong in a way no artifact could show.
+Two questions, answered here and nowhere later: **which tree** this round reads, and **against which base**. Neither is implicit: the checkout changes while the round runs, and `git.default_base` is not always the right base.
 
 **The candidate.** A round applies its own fixes; the README's own first-minute example is *"3 reviewers, one finding — fixed"*. So "the working tree" is a different tree for the reviewer that read it first, for the skeptic that read it last, and for the `git rev-parse HEAD` taken at §9 — which by construction contains code no reviewer ever saw, and which `/flow-feat-ship §1` then compares against `HEAD` and finds equal. Resolve one revision before §2 launches anything:
 
@@ -79,11 +79,11 @@ Two questions, answered here and nowhere later: **which tree** this round reads,
 - Anchor it so it cannot be collected: `git update-ref refs/flow/candidate/<TICKET> <sha>`. A `stash create` object is unreferenced, and a candidate the `ship` gate cannot resolve is a gate that reports nothing. The ref is local, never pushed, and `/flow-feat-ship §6.5` deletes it.
 - Write `candidate_sha` to `meta.json` — work-level and in the current `mrs[]` entry — **in this pre-flight**. A candidate recorded after the reading is not a freeze.
 
-**The review base.** `reviewed_sha` already records the tree the last passing review read, and `ship` trusts it enough to stop a push — yet the review itself never read it, so a second review re-reads every line the first one cleared, and §2.0 resolves the tier on the accumulated total: a 30-line delta on a 900-line branch reviewed as the 900. Resolve:
+**The review base.** `reviewed_sha` records the tree the last passing review read, and `ship` trusts it enough to stop a push. Reading only the delta since it keeps a second review from re-reading every line the first one cleared, and keeps §2.0 from resolving the tier on the accumulated total — a 30-line delta on a 900-line branch is a 30-line review. Resolve:
 
 - The current MR/PR's `reviewed_sha` (work-level when there is no train) when it is **non-empty** and **an ancestor of the candidate** (`git merge-base --is-ancestor <sha> <candidate>`) → that is the base.
 - Otherwise `git.default_base`. A `reviewed_sha` that is not an ancestor means history was rewritten or the branch recut; say so in one line rather than producing a nonsensical delta.
-- **A first review has no `reviewed_sha` and reads the whole branch**, exactly as before. The delta path only exists after a review that passed.
+- **A first review has no `reviewed_sha` and reads the whole branch**. The delta path only exists after a review that passed.
 - `/flow-feat-review --full` ignores `reviewed_sha` and reads the branch on demand.
 - **Fall back to `git.default_base` and say why** when either holds, because a delta cannot see how it interacts with what was cleared before: the delta touches a file the previous review left a finding on, or it changes an external contract copied under `/flow-feat-build §2.0bis`.
 
@@ -97,7 +97,7 @@ Scope for every reviewer: **the candidate revision of §1.5, against the review
 
 **The CLI resolves it; you obey the output and record any deviation.** `npx flow-workflows@<version> tier --harness hermes --rev <candidate_sha> --base <review base>` prints, from the config it already parses: changed lines over the §1.5 range, diff size, `meta.json.size`, **effective size** (the lower of the two), the built-in `code-review` effort with and without the sensitive-surface bump, whether the panel runs, the resolved `agents.budget_max`/`fanout_max`, whether the measurement landed **within 10% under** a threshold that changed the tier, and which `quality.sensitive_paths` globs the diff matched, with the path that matched each.
 
-Every step of that is arithmetic, and the cost of leaving it here was never mainly the tokens: `06-review.md` recorded the tier *this agent said it derived*, so a round that eyeballed the diff and a round that measured it wrote a byte-identical artifact — on the one number in this command that carries an incentive on it. Same treatment `Review path` and `Cost:` already got, for the same reason.
+Every step of that is arithmetic. A tier this agent derives itself writes the same artifact whether it measured the diff or eyeballed it — on the one number in this command that carries an incentive on it.
 
 **Copy the output verbatim** into the `Review tier` and `Effective size` lines of §8, the way `bundle --checks` copies static analysis out. A computed line, not a narrated one.
 
@@ -107,7 +107,7 @@ Every step of that is arithmetic, and the cost of leaving it here was never main
 - **Whether a matched path is a sensitive *diff*.** The bump asks what the change *does* there, not where it lives: it applies to **control flow, or the data that reaches a person, a charge or a stored record** — a new guard, a new `catch`, a changed condition, a changed value, a changed contract. It does **not** apply when the diff moves **observability alone**: a log level, a channel, a message's text, a metric, a comment. Mixed diff → not observability-only, so it bumps. **Say which of the two it was in one line**; a diff demoted here is the one place a missed defect is expensive.
 - **Query changes.** §3.6 duels every query the diff adds or modifies, at every size, whatever this section resolved — routing them through the bump buys a second opinion on prose where §3.6 buys a plan.
 
-**No CLI, or a non-zero exit → the prose fallback**, and `Review path` names it with the reason (the same contract the panel follows). Measure `git diff --shortstat <review base>...<candidate_sha>`; **≤150 → XS · 151-600 → S · 601-1500 → M · >1500 → L**; effective size = the lower of that and `meta.json.size`; `proportional` runs the built-in at **medium/high/high/xhigh** by size and the panel at M and above (at S only on a sensitive surface); the bump raises the effort one tier (medium→high→xhigh→**max**) and always runs the panel; `full` is **xhigh** plus the panel at any size, `light` is the built-in alone at **medium** with no panel, no §3 and no §6 — and a sensitive surface lifts `light` to the proportional tier for that work. The thresholds and the ladder are documented in `docs/CONFIGURATION.md`, where they can be read without being re-taught to a model on every invocation.
+**No CLI, or a non-zero exit → the prose fallback**, and `Review path` names it with the reason (the same contract the panel follows). Measure `git diff --shortstat <review base>...<candidate_sha>`; **≤150 → XS · 151-600 → S · 601-1500 → M · >1500 → L**; effective size = the lower of that and `meta.json.size`; `proportional` runs the built-in at **medium/high/high/xhigh** by size and the panel at M and above (at S only on a sensitive surface); the bump raises the effort one tier (medium→high→xhigh→**max**) and always runs the panel; `full` is **xhigh** plus the panel at any size, `light` is the built-in alone at **medium** with no panel, no §3 and no §6 — and a sensitive surface lifts `light` to the proportional tier for that work.
 
 **The diff pointing *higher* than `meta.json.size`** is worth one line in `06-review.md` (the work may be misclassified), never a heavier review. **The sensitive-surface bump is never scaled away** — a 12-line change to an authorization check still gets the panel, on a delta exactly as on a first review.
 
@@ -156,7 +156,7 @@ Launch the reviewers selected in §2.0 and **consolidate their findings into a s
 
 When both run, deduplicate overlapping correctness/simplification findings (count each once). The `review_skill` specialists (offensive/defensive security, silent failures, architecture) are not repeated in later phases.
 
-**Dedup keeps every source, not the first one.** A finding carries its **origin** from here to §8 — `built-in`, a panel role, or the pass that raised it (`§3.5`, `§3.6`, `§5`, `§5.5`) — and a finding more than one source raised lists all of them. Counted once, credited to each. Beyond the built-in and the panel this command runs four specialised passes, roughly 1 800 of its words, every one added after a real defect got through and not one able to show it still earns that cost: a finding only the idiom audit saw and a finding three sources raised say opposite things about that pass, and until now both were written identically. The `Cost:` line stopped being a headcount when `meta.json.cost[]` arrived; this is the same move for the thing those costs are spent on.
+**Dedup keeps every source, not the first one.** A finding carries its **origin** from here to §8 — `built-in`, a panel role, or the pass that raised it (`§3.5`, `§3.6`, `§5`, `§5.5`) — and a finding more than one source raised lists all of them. Counted once, credited to each: a finding only one pass saw and a finding three sources raised say opposite things about that pass, and §9 records the difference.
 
 ### 2.2 Design truth vs design rationale (do not inherit rationalizations)
 `03-design.md` goes to reviewers as context, with unequal authority:
@@ -175,7 +175,7 @@ Only what §2 does **not** already cover; skipped entirely under `light` (§2.0)
 
 ## 3.5. Completeness sweep (anti-abandonment, M/L only)
 
-Counters a reviewer abandoning a large diff early. **Only if `meta.json.size` is M or L**, and only
+Counters a reviewer abandoning a large diff early. **Only if the effective size of §2.0 is M or L**, and only
 if §2.0b's budget still covers it (it is the first phase dropped).
 
 **It runs after §2-§3 are consolidated, never in parallel with them.** The whole phase is an audit of
@@ -267,7 +267,7 @@ Findings enter the normal flow: §6, then the output. Blinded for the same reaso
 
 A filter against over-reporting, not a second review; narrow gate. Never runs under `light` (§2.0).
 
-**When it runs.** All three conditions:
+**When it runs.** All four conditions:
 
 | Condition | Threshold |
 |---|---|
@@ -276,7 +276,7 @@ A filter against over-reporting, not a second review; narrow gate. Never runs un
 | Findings | **≥ 4** ambiguous findings across §2-§5 |
 | Budget | §2.0b's budget still covers a round (§6 is the second phase dropped) |
 
-Read the real diff (`git diff --stat` against the target branch), not the recorded size.
+Read the real diff (`git diff --stat <review base>...<candidate_sha>`, §1.5), not the recorded size.
 
 When all three hold: in **`manual`**, offer it with `AskUserQuestion` ("Verify the ambiguous findings with skeptics in parallel? Discards false positives before you go fix them."). In **`guided`/`auto`, do not ask** — flow mechanics: run it and note in `06-review.md` that you did.
 
@@ -356,7 +356,7 @@ Write `.claude/work/<TICKET>/06-review.md`. The `Cost:` line of `## Summary` is
 ## Discarded by adversarial verification
 <only if §6 was run; list of refuted findings with reason, or "not applicable">
 <if the `fanout_max` cap left ambiguous findings unverified, list them here as "unverified (cap)">
-<if §6 did not run, one line saying which condition did not hold — size, diff size, or count>
+<if §6 did not run, one line saying which condition did not hold — size, diff size, count, or budget>
 
 ## Blockers (must-fix)
 1. [file:line] · <origin> · description + concrete proposal
@@ -379,12 +379,11 @@ Write `.claude/work/<TICKET>/06-review.md`. The `Cost:` line of `## Summary` is
 - Blockers → **do not advance `phase`**. Leave `phase = "build"`; the user resolves them.
 - No blockers → `phase = "review"`, add to `phases_done`. **In a multi-MR/PR work**, also add `review` to the current `in_progress` MR/PR's own `phases_done` (its `mrs[]` entry) — `/flow-feat-ship §1` gates on it per MR/PR.
 - **Record *what* you reviewed, and separately what you changed after reading it**, in the same write, work-level and — in a multi-MR/PR work — in this MR/PR's `mrs[]` entry too:
-  - `reviewed_sha` = **the candidate of §1.5**, the revision the reviewers actually read. Not `git rev-parse HEAD`, which is what it used to be and which by then holds this round's own fixes — code no reviewer saw, recorded as reviewed, and `ship` finding it equal to `HEAD` every time.
-  - `fixed_sha` = `git rev-parse HEAD` after this round's fixes, or **empty** when the round applied none. Two fields because they are two facts, and collapsing them is what hid the delta.
+  - `reviewed_sha` = **the candidate of §1.5**, the revision the reviewers actually read. Not `git rev-parse HEAD`, which by then holds this round's own fixes — code no reviewer saw, recorded as reviewed, and `ship` finding it equal to `HEAD` every time.
+  - `fixed_sha` = `git rev-parse HEAD` after this round's fixes, or **empty** when the round applied none. Two fields because they are two facts.
   - `phases_done` says a review *happened*; these say which tree, and `/flow-feat-ship §1` reads both before pushing. Written whenever the phase advances, never when it does not: a review that ended in blockers reviewed nothing that stands.
 - **Record which pass found what**, in the same write: `meta.json.review_findings[]`, one entry per finding **per source** — `{ round, origin, severity, file, discarded_by_skeptic }`, and no finding text, which stays in the artifact. `flow review --record` writes these itself when the CLI ran the panel; when the agentic panel ran, write them here from the origins §2.1 carried. `flow cost` reads them back per origin: how many findings each pass contributed, how many only it raised, and how many of those survived §6. That last number is the only evidence a pass is still earning its words.
-  **The retirement rule, written down before the data arrives** so it cannot be argued backwards later: a pass that contributes **no exclusive surviving finding across twenty reviews** is removed from this command. Zero is zero, and the decision is made against the number rather than against whoever is most attached to the pass.
-- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most and, until now, the one phase that never staged — a work with three review rounds and seventeen blockers produced zero knowledge cards because nothing asked for them while they were in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `ship`»). Never `knowledge.save` here.
+- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most, and this is the only moment its findings are in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `ship`»). Never `knowledge.save` here.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - **Record what the agents missed** (flow-core §6.7, `agents.learn` not `off`; asking nothing): for each finding that survived, the panel member or named `agents.<role>` whose category it falls in and who did not report it, and the delegated `build` agent whose code it sits in → one `meta.json.agent_lessons[]` row each, only when the lesson passes the §6.7 test. The origins §2.1 carried are what make this possible — a finding with no origin teaches nobody.
 - **Configuration this phase earned the right to ask about** (flow-core §0, `manual` only, at most one key per work, as an extra option on this same stop — never a question of its own): a `Cost:` line that went over `agents.budget_max` → `quality.review_depth`. In `guided`/`auto` neither is asked: the default is taken and recorded in `meta.json.defaults_used[]`.

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

@@ -85,7 +85,6 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
   "branch": "{PREFIX}XXXXX-slug",
   "size": "XS" | "S" | "M" | "L",
   "phase": "context" | "design" | "plan" | "build" | "review" | "validate" | "ship" | "investigate" | "fix" | "postmortem" | "done" | "abandoned",
-  // retired in v0.53.0 and still read from older works: "brainstorm" → treat as "context", "diagnose" → as "investigate"
   "phases_done": ["context", ...],
   "candidate_sha": "40-char sha the current review froze before reading, or ''",
   "reviewed_sha": "40-char sha the last passing review read, or ''",
@@ -118,11 +117,11 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
   ],
   "followups": [
     { "id": "F1",
-      "kind": "prevention" | "audit" | "out-of-scope" | "risk" | "edge-case" | "other-bug",
+      "kind": "prevention" | "audit" | "out-of-scope" | "risk" | "edge-case" | "other-bug" | "tooling" | "decision",
       "title": "one line, what would be done",
       "why": "one line, why it was parked and why it still matters",
       "source": "design" | "plan" | "build" | "validate" | "fix" | "postmortem",
-      "status": "proposed" | "accepted" | "in_progress" | "declined" | "done",
+      "status": "proposed" | "accepted" | "in_progress" | "declined" | "logged" | "done",
       "ticket": null, "work": null, "note": "" }
   ],
   "defaults_used": [

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

@@ -29,7 +29,6 @@ Use when returning to a work after a break (next morning, another session).
 - `git branch --show-current`.
 - Search `.claude/work/` for the `meta.json` whose `branch` matches.
 - None found → ask the user for the ticket or whether to start a new one.
-- **A `phase` retired in v0.53.0** — `brainstorm` or `diagnose`, from a work started before it — is mapped, never refused: `brainstorm` → `design` (its `02-brainstorm.md` is that command's §1.5 output, already done), `diagnose` → `investigate` (its `02-diagnose.md` is that command's §1.5 output). Say which mapping you applied, in one line, and suggest the mapped command. Do not rewrite `meta.json` for it; the phase advances normally at the next Close.
 - `meta.json.worktree` non-null and the current directory is not that worktree → tell the user the work lives in a worktree and to `cd <worktree>` before continuing; run the repo-state checks below from there (`git -C <worktree> …`).
 
 ## 2. Recap

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.80.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.81.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
@@ -29,12 +29,9 @@ a command relies on is simply absent in that session, and nothing else will repo
 - **Look before you read.** The first thing a phase does about configuration is list what is there:
   `ls <root>/FLOW*.md` (the root being the one the next bullet resolves). One call, and it is not
   optional — **an overlay you did not list is an overlay you did not read**, and nothing downstream
-  will notice. This is not a hypothetical: every command below, and every artifact they write,
-  refers to the effective configuration as "`FLOW.md`", which is a file that exists, so reading it
-  and stopping feels finished. Two real sessions in a row read the base in full and never went
-  looking for the overlay sitting beside it — the models it set were silently the defaults, and
-  both runs reported the keys as unset with no way to tell that apart from a repo that never set
-  them. **Name the files this listing found the first time a phase reports any configured value**,
+  will notice. Every command and artifact calls the effective configuration "`FLOW.md`", a file that
+  exists, so reading it and stopping feels finished — and a missed overlay reports its keys as unset,
+  indistinguishable from a repo that never set them. **Name the files this listing found the first time a phase reports any configured value**,
   so a missed overlay is visible in the artifact rather than invisible everywhere.
 - Read `FLOW.md` at the repo root as the base, then the optional overlay for the harness running
   this command: `FLOW.claude.md`, `FLOW.codex.md`, `FLOW.opencode.md`, `FLOW.gemini.md`,
@@ -67,11 +64,8 @@ a command relies on is simply absent in that session, and nothing else will repo
 - **A fenced block in a FLOW file is an example, and an example is not configuration.** These
   files are prose with keys in them, and the rule that decides what a key *is* — a `- key:` line
   under a `## section` — knows nothing about triple backticks. So a block written to be pasted
-  ("add this to try it once") was read as the configuration it illustrates, for as long as it sat
-  there. It happened in a real repo: `agents.exec_cmd` came from the fenced example of a file whose
-  prose argued at length that it was deliberately unset, and every review round took the one-shot
-  path that prose warned against — with nothing anywhere to say so, because the file and the
-  configuration disagreed while both looked right. **Skip fenced regions when you read a FLOW
+  ("add this to try it once") would be read as the configuration it illustrates, while the prose
+  around it says otherwise and nothing reports the disagreement. **Skip fenced regions when you read a FLOW
   file**; `flow-workflows` does the same, so the two of you resolve the same config.
 - Merge by section and key. A key present in the active overlay replaces the base value; a key
   absent there inherits the base. **A present-but-empty overlay key masks the base** and resolves
@@ -92,7 +86,7 @@ a command relies on is simply absent in that session, and nothing else will repo
      alongside whatever it was already asking. Resolve the destination by the ownership rule below.
      Never a question of its own, never a key off the list, and at most **one key per work** — the
      second one waits for the next work or for `/flow-init`.
-  3. `guided`/`auto` → take the default and **record** it: one line in the phase artifact as today,
+  3. `guided`/`auto` → take the default and **record** it: one line in the phase artifact,
      plus an entry in `meta.json.defaults_used[]` — `{ "key": "agents.security", "default":
      "general-purpose", "phase": "review" }`. Asking here would break the never-a-question contract
      (§2); recording keeps the decision readable afterwards, and `/flow-doctor` aggregates it.
@@ -119,8 +113,7 @@ a command relies on is simply absent in that session, and nothing else will repo
   the consolidation appends to `KNOWLEDGE.md` at the repo root. Per-call timeout
   `knowledge.timeout_s` (empty = 2 s); a failure or timeout → continue without it, silently.
 **How a consolidation runs** (`ship`, `postmortem`, `abandon`, and the offer in `/flow-work-status`
-when `read_staging` has entries). No role set at all → say so in one line and stop; nothing here is
-worth a command of its own, which is why there is no longer one:
+when `read_staging` has entries). No role set at all → say so in one line and stop:
 
 1. **Read the staging** for this branch with `knowledge.read_staging`; the role empty → the "why"
    findings already written in this work's artifacts (`03-design.md` ADR-light and challenges,
@@ -270,7 +263,7 @@ right now. **Any progress line you were about to type into the chat is a panel u
 **Two transports, one document.** When the tools `panel_set` / `panel_patch` / `panel_get` are
 available, this console is a pane of agent-terminal: publish the panel through them (§4.2) and
 **stop writing `.claude/work/<work>/panel.json`** — while a pane is claimed, its file is not read at
-all. When they are not there, write the file exactly as before (§4.3). No work folder (lightweight
+all. When they are not there, write the file (§4.3). No work folder (lightweight
 `respond`/`green`) → nothing to publish, either way.
 
 **Look for them before you conclude they are missing**, once per session, in pre-flight. A harness
@@ -413,8 +406,7 @@ single largest token cost of a work, so every work carries a short handoff:
   MR/PR of `04-mr-plan.md`; `review` opens the design's contracts and the implementation log;
   `ship` opens the brief and the review verdict. A summary that does not answer the question you
   have is the cue to open the artifact — never a licence to guess.
-- Missing summary (a work started before this rule) → read the artifacts as before, write the
-  summary at your Close.
+- Missing summary → read the artifacts, write the summary at your Close.
 - **Name the phase, never the command.** An artifact outlives the session that wrote it and may be
   resumed from a different agent, where the same phase is invoked under another name. Write the
   phase — `validate`, `review`, `ship #2` — not the invocation. Applies to `00-summary.md`,
@@ -449,7 +441,7 @@ around each of its own findings to work out which changes are its doing, and how
 looks clean is clean by luck. **The parent thread is a writer too**: applying a round's fixes while
 its agents are still reading is the same collision, from the side nobody counts.
 
-So a round that contains a writer is not one round. Readers fan out freely, as they always did;
+So a round that contains a writer is not one round. Readers fan out freely;
 writers go one at a time, each either alone or in a worktree of its own, and the readers sit
 entirely before them or entirely after them. The parent's own edits wait until the round is
 consolidated. Ordering costs wall clock and the phase says so in one line — a reading nobody can
@@ -491,8 +483,7 @@ Dropping a silent agent is always allowed, and always reported (`N/M` reported).
 no deadline is what costs a session.
 
 **The budget belongs to the command, not to the round.** `agents.fanout_max` caps *one* parallel
-round; nothing capped what a command spends across all of its rounds, and the phases that fan out
-compose: a review can run a panel, then area reinforcements, then a coverage sweep that relaunches
+round, and the phases that fan out compose: a review can run a panel, then area reinforcements, then a coverage sweep that relaunches
 the panel, then one skeptic per finding — each round inside its own cap and the command an order of
 magnitude over what anyone intended.
 
@@ -557,15 +548,13 @@ must *react to* mid-wait is not a wait at all: it is the work, and it stays here
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,
-and choosing the one that fits a piece of work is something you do well without being told. A rule
-that answers every empty role with `general-purpose` throws that away: a repo with a frontend
-specialist installed and no `agents.frontend` got a generalist told to act like one. So wherever a
+and choosing the one that fits a piece of work is something you do well without being told. Answering every empty role with `general-purpose` throws that away. So wherever a
 command says *"`agents.<role>`, empty → `Agent general-purpose` with the role"*, it means this:
 
-1. **`agents.<role>` names an agent** → that agent, as always.
+1. **`agents.<role>` names an agent** → that agent.
 2. **Empty** → the installed agent whose description fits the role **and this work's stack** best —
    read the list your harness gives you, never a guess at a name. None fits clearly →
-   `general-purpose` with the role in the prompt, as before. An agent that fits the role but not the
+   `general-purpose` with the role in the prompt. An agent that fits the role but not the
    stack (a PHP reviewer on a React diff) does not fit.
 
 **`agents.selection`** decides how far your judgement reaches:
@@ -711,11 +700,11 @@ one more thing the user has to decide about.
   "title": "one line, what would be done",
   "why": "one line, why it was parked and why it still matters",
   "source": "design" | "plan" | "build" | "validate" | "fix" | "postmortem",
-  "status": "proposed" | "accepted" | "declined" | "logged" | "done",
+  "status": "proposed" | "accepted" | "in_progress" | "declined" | "logged" | "done",
   "ticket": null, "work": null, "note": "" }
 ```
 
-The artifact keeps its human-readable section exactly as before, with the `F<n>` id in front of each
+The artifact keeps its human-readable section, with the `F<n>` id in front of each
 row so the prose and the record never drift. **The record is the addition, not a replacement**: a
 reader of `05-implementation.md` still sees the ideas in context.
 
@@ -750,8 +739,8 @@ at `ship`'s Close, when the work is done and the user can see the whole set.
 
 **A skeptic sorts them before the user sees them.** `/flow-*-review` already refuses to hand over an
 unverified finding: its §6 gives each ambiguous one to a skeptic whose job is to *refute* it, burden
-of proof on the finding. Deferred work reached the user through no filter at all, judged only by the
-phase that parked it — the one party that cannot judge it, having just found it. So at Close, when
+of proof on the finding. Deferred work needs the same filter: the phase that parked it is the one party that cannot judge
+it, having just found it. So at Close, when
 **3 or more** entries are still `proposed`, they go to a skeptic first (grouped into at most
 `agents.fanout_max` briefs, the ceilings of §6 unchanged; **fewer than 3 → no agent**, the command
 applies the bar itself):
@@ -778,15 +767,10 @@ Then, and only then, the survey:
   **Not worth it** · **Later**. The `title` and `why` are the entire prompt. **`decision` entries
   are asked as their product question** — they never go to the skeptic, a question's value not being
   a thing to refute — and sit outside the ceiling.
-- **`tooling` asks nothing.** `logged`, and a count on screen. Asking **Log it** about a lint floor
-  with slack in it was one question too many.
+- **`tooling` asks nothing.** `logged`, and a count on screen.
 - **Not worth it** → `declined`, with the reason if given. Never asked again.
 - **`logged` is a status, not a destination.** The entry stays exactly where it already is — in
-  `meta.json.followups[]` and in its artifact section — and no file is written anywhere. This used
-  to append a line to a versioned debt log, one per repo; **that file is gone**. No command read it,
-  `status` and `daily` excluded it on purpose, and it duplicated a record the work already keeps
-  forever, so it grew without ever being triaged. A note nobody reads is not a lighter obligation
-  than a ticket, it is the same obligation with the reader removed. If a gap in the machinery is
+  `meta.json.followups[]` and in its artifact section — and no file is written anywhere. If a gap in the machinery is
   worth someone's time, it is worth a ticket; if it is not, the record in the work is where it ends.
 - **A `decision` answered** → the answer is written into the artifact that owns it and the entry
   becomes `done` with the answer in `note`. Deferred again → stays `proposed`.
@@ -878,7 +862,7 @@ largest saving the review has.
 
 **What follows from that is a temptation, and it belongs to the diff, not to the plan.** A threshold
 that buys a lighter review pays whoever lands just under it: twelve lines below 150 is a review at
-`medium` with no project panel and no §6 round, twelve above it is the panel. So, in every phase:
+`medium`, twelve above it is one at `high`; at 600 the project panel joins. So, in every phase:
 
 **The diff reports the change; the change is never shaped to fit the number.** Never delete a
 comment, a test, a blank line or a log line, never compress readable code into fewer statements,

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

@@ -26,9 +26,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
 - `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` and stop.
-- Require `context` in `phases_done`. A work whose `phase` is the retired `diagnose` (written before
-  v0.53.0) is treated as having finished §1.5: read its `02-diagnose.md`, carry it into
-  `03-investigation.md`, and go straight to §3.
+- Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
 
@@ -36,9 +34,6 @@ Isolate **what** fails before looking for **why**. On **S** this is the whole of
 first half and the chain is `start → investigate (reproduce only) → fix → …`; on **M/L** it is the
 ground §3 stands on. **XS** skips straight to `/flow-bug-fix`.
 
-*(This was the `bug:diagnose` command until v0.53.0. Reproducing and finding the cause were two commands
-sharing five headings, and the S-size chain already ran them back to back.)*
-
 1. **Focused knowledge query on the symptom.** `knowledge.search` set → 2-3 parallel queries about
    the **suspected component** (handler, worker, endpoint, module): the same root cause often
    returns wearing a different symptom. Dead-letter queue → `"DLX <handler-name>"`, `"retry policy

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

@@ -35,7 +35,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
   member runs its own `git diff` and opens the same files pays for that material once per agent, and
   a reviewer that spends its turns exploring has fewer left to review. **Any non-zero exit is a
   fallback, not a failure** — no CLI on the machine, a base that does not resolve, a network that
-  cannot reach it: read the diff from git as before and carry on, once, without retrying variants.
+  cannot reach it: read the diff from git and carry on, once, without retrying variants.
   What is not optional is the `Review path` line of §7: a round that skipped the pack and one that
   used it are indistinguishable from the artifact otherwise, which is how a phase quietly stops
   paying for itself.
@@ -70,7 +70,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 - **Review base**: the previous `reviewed_sha` when it is non-empty and an ancestor of the candidate, otherwise `git.default_base`, with the reason in one line. `--full` forces the whole branch.
 - **Then**: `bundle --rev <candidate_sha> --base <review base>`, and every brief names that range rather than the live tree.
 
-A fix is usually small enough that the delta and the branch are the same thing — which is exactly why the freeze matters more here than the scoping: a one-file fix whose round applies its own correction is the case where `reviewed_sha` used to equal `HEAD` while describing a tree nobody read.
+A fix is usually small enough that the delta and the branch are the same thing — which is exactly why the freeze matters more here than the scoping: a one-file fix whose round applies its own correction is the case where recording `HEAD` as reviewed would describe a tree nobody read.
 
 ## 2. Run the code reviews
 
@@ -233,7 +233,7 @@ Cost line: count every subagent this command launched — reviewers = §2.1 buil
 - **Record *what* you reviewed, and separately what you changed after reading it** — `/flow-feat-review` §9, unchanged: `reviewed_sha` = the **candidate** of §1.5 (the revision the reviewers read, never `git rev-parse HEAD`, which by now holds this round's own fixes), and `fixed_sha` = `git rev-parse HEAD` after those fixes, empty when the round applied none. `phases_done` says a review happened; these two say on which tree and what moved afterwards, and `/flow-bug-ship §0` reads both against what is being pushed. Only when the phase advances: a review that ended in blockers reviewed nothing that stands.
 - **Record which pass found what** — `/flow-feat-review §9`, unchanged: one `meta.json.review_findings[]` entry per finding **per source** (`{ round, origin, severity, file, discarded_by_skeptic }`, no finding text), written by `flow review --record` when the CLI ran the panel and by this Close when the agentic panel did. `flow cost` reads them back per origin, and the retirement rule is the same: a pass with no exclusive surviving finding across twenty reviews comes out of the command.
 - **Record what the agents missed** — `/flow-feat-review §9`, unchanged: surviving findings in a category a panel member or named `agents.<role>` owns and did not report → `meta.json.agent_lessons[]` rows (flow-core §6.7), asking nothing. A fix is where this pays most: the defect already reached production once, and the reviewer that owns its category let it.
-- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most and, until now, the one phase that never staged — a work with three review rounds and seventeen blockers produced zero knowledge cards because nothing asked for them while they were in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `postmortem`/`ship`»). Never `knowledge.save` here.
+- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most, and this is the only moment its findings are in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `postmortem`/`ship`»). Never `knowledge.save` here.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Stop body (after the flow-core §3 header): the findings that survived and what you did with each, plus the same Cost line as the Summary: "- Cost: <n>/<budget_max> subagents launched (<k> reviewers · <m> reinforcements · <s> skeptics), tier <light|proportional|full>".
 - **Autonomy handoff.** Only without blockers — with blockers, stop in every mode. **M/L**: `manual` → propose `/flow-bug-postmortem` with a single `AskUserQuestion`; `guided`/`auto` → chain into it in this same turn. **XS/S**: the next step is `ship`, which pushes and opens the MR/PR — a hard gate in **every** mode: stop here and propose `/flow-bug-ship` with a single `AskUserQuestion`, never chaining into it.

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

@@ -45,9 +45,6 @@ Print this **before** the environment checks: a key nobody set is the commonest
 below looks broken. Read against `examples/FLOW.template.md` — do not invent keys, and do report
 documented keys absent from the effective configuration (the "empty → fallback" rows).
 
-**This was the `config` command until v0.53.0.** One question — *what will the flow do in this repo* —
-had two commands answering different halves of it.
-
 ### 1.5.1 Effective config, per section
 
 For **every** documented key in `examples/FLOW.template.md`, one row:

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

@@ -25,7 +25,7 @@ Technical design phase. **Still no production code is written.** Opens the optio
 ## 1. Pre-flight
 
 - Load `meta.json` by current branch. Missing → ask the user to start with `/flow-feat-start`.
-- Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received), and `02-brainstorm.md` when a work started before v0.53.0 has one — its options are §1.5's output, already done. (flow-core §5)
+- Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
 - `size` is `XS` → suggest jumping to `/flow-feat-build` and stop unless the user insists.
 
 ## 1.5 Approaches — open the option space first (M/L)
@@ -34,9 +34,6 @@ Design that starts from the first idea is design that never had a second one. **
 section; XS and S skip it** and go straight to §2 — the cost does not pay on a change whose shape is
 obvious.
 
-*(This was the `feat:brainstorm` command until v0.53.0: a command whose whole output only this one ever
-read.)*
-
 **No code, and no design yet.** The output of this section is a ranked set of options and one chosen
 approach; §3 onwards designs *that* approach.
 

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

@@ -38,7 +38,7 @@ Mandatory review phase. **`/flow-feat-ship` cannot run without passing through h
   member runs its own `git diff` and opens the same files pays for that material once per agent, and
   a reviewer that spends its turns exploring has fewer left to review. **Any non-zero exit is a
   fallback, not a failure** — no CLI on the machine, a base that does not resolve, a network that
-  cannot reach it: read the diff from git as before and carry on, once, without retrying variants.
+  cannot reach it: read the diff from git and carry on, once, without retrying variants.
   What is not optional is the `Review path` line of §8: a round that skipped the pack and one that
   used it are indistinguishable from the artifact otherwise, which is how a phase quietly stops
   paying for itself.
@@ -67,7 +67,7 @@ Mandatory review phase. **`/flow-feat-ship` cannot run without passing through h
 
 ### 1.5 Freeze what you are about to read, and resolve what to compare it against
 
-Two questions, answered here and nowhere later: **which tree** this round reads, and **against which base**. Both used to be answered implicitly — by the checkout as it happened to stand at each moment, and by `git.default_base` always — and both answers were wrong in a way no artifact could show.
+Two questions, answered here and nowhere later: **which tree** this round reads, and **against which base**. Neither is implicit: the checkout changes while the round runs, and `git.default_base` is not always the right base.
 
 **The candidate.** A round applies its own fixes; the README's own first-minute example is *"3 reviewers, one finding — fixed"*. So "the working tree" is a different tree for the reviewer that read it first, for the skeptic that read it last, and for the `git rev-parse HEAD` taken at §9 — which by construction contains code no reviewer ever saw, and which `/flow-feat-ship §1` then compares against `HEAD` and finds equal. Resolve one revision before §2 launches anything:
 
@@ -77,11 +77,11 @@ Two questions, answered here and nowhere later: **which tree** this round reads,
 - Anchor it so it cannot be collected: `git update-ref refs/flow/candidate/<TICKET> <sha>`. A `stash create` object is unreferenced, and a candidate the `ship` gate cannot resolve is a gate that reports nothing. The ref is local, never pushed, and `/flow-feat-ship §6.5` deletes it.
 - Write `candidate_sha` to `meta.json` — work-level and in the current `mrs[]` entry — **in this pre-flight**. A candidate recorded after the reading is not a freeze.
 
-**The review base.** `reviewed_sha` already records the tree the last passing review read, and `ship` trusts it enough to stop a push — yet the review itself never read it, so a second review re-reads every line the first one cleared, and §2.0 resolves the tier on the accumulated total: a 30-line delta on a 900-line branch reviewed as the 900. Resolve:
+**The review base.** `reviewed_sha` records the tree the last passing review read, and `ship` trusts it enough to stop a push. Reading only the delta since it keeps a second review from re-reading every line the first one cleared, and keeps §2.0 from resolving the tier on the accumulated total — a 30-line delta on a 900-line branch is a 30-line review. Resolve:
 
 - The current MR/PR's `reviewed_sha` (work-level when there is no train) when it is **non-empty** and **an ancestor of the candidate** (`git merge-base --is-ancestor <sha> <candidate>`) → that is the base.
 - Otherwise `git.default_base`. A `reviewed_sha` that is not an ancestor means history was rewritten or the branch recut; say so in one line rather than producing a nonsensical delta.
-- **A first review has no `reviewed_sha` and reads the whole branch**, exactly as before. The delta path only exists after a review that passed.
+- **A first review has no `reviewed_sha` and reads the whole branch**. The delta path only exists after a review that passed.
 - `/flow-feat-review --full` ignores `reviewed_sha` and reads the branch on demand.
 - **Fall back to `git.default_base` and say why** when either holds, because a delta cannot see how it interacts with what was cleared before: the delta touches a file the previous review left a finding on, or it changes an external contract copied under `/flow-feat-build §2.0bis`.
 
@@ -95,7 +95,7 @@ Scope for every reviewer: **the candidate revision of §1.5, against the review
 
 **The CLI resolves it; you obey the output and record any deviation.** `npx flow-workflows@<version> tier --harness opencode --rev <candidate_sha> --base <review base>` prints, from the config it already parses: changed lines over the §1.5 range, diff size, `meta.json.size`, **effective size** (the lower of the two), the built-in `code-review` effort with and without the sensitive-surface bump, whether the panel runs, the resolved `agents.budget_max`/`fanout_max`, whether the measurement landed **within 10% under** a threshold that changed the tier, and which `quality.sensitive_paths` globs the diff matched, with the path that matched each.
 
-Every step of that is arithmetic, and the cost of leaving it here was never mainly the tokens: `06-review.md` recorded the tier *this agent said it derived*, so a round that eyeballed the diff and a round that measured it wrote a byte-identical artifact — on the one number in this command that carries an incentive on it. Same treatment `Review path` and `Cost:` already got, for the same reason.
+Every step of that is arithmetic. A tier this agent derives itself writes the same artifact whether it measured the diff or eyeballed it — on the one number in this command that carries an incentive on it.
 
 **Copy the output verbatim** into the `Review tier` and `Effective size` lines of §8, the way `bundle --checks` copies static analysis out. A computed line, not a narrated one.
 
@@ -105,7 +105,7 @@ Every step of that is arithmetic, and the cost of leaving it here was never main
 - **Whether a matched path is a sensitive *diff*.** The bump asks what the change *does* there, not where it lives: it applies to **control flow, or the data that reaches a person, a charge or a stored record** — a new guard, a new `catch`, a changed condition, a changed value, a changed contract. It does **not** apply when the diff moves **observability alone**: a log level, a channel, a message's text, a metric, a comment. Mixed diff → not observability-only, so it bumps. **Say which of the two it was in one line**; a diff demoted here is the one place a missed defect is expensive.
 - **Query changes.** §3.6 duels every query the diff adds or modifies, at every size, whatever this section resolved — routing them through the bump buys a second opinion on prose where §3.6 buys a plan.
 
-**No CLI, or a non-zero exit → the prose fallback**, and `Review path` names it with the reason (the same contract the panel follows). Measure `git diff --shortstat <review base>...<candidate_sha>`; **≤150 → XS · 151-600 → S · 601-1500 → M · >1500 → L**; effective size = the lower of that and `meta.json.size`; `proportional` runs the built-in at **medium/high/high/xhigh** by size and the panel at M and above (at S only on a sensitive surface); the bump raises the effort one tier (medium→high→xhigh→**max**) and always runs the panel; `full` is **xhigh** plus the panel at any size, `light` is the built-in alone at **medium** with no panel, no §3 and no §6 — and a sensitive surface lifts `light` to the proportional tier for that work. The thresholds and the ladder are documented in `docs/CONFIGURATION.md`, where they can be read without being re-taught to a model on every invocation.
+**No CLI, or a non-zero exit → the prose fallback**, and `Review path` names it with the reason (the same contract the panel follows). Measure `git diff --shortstat <review base>...<candidate_sha>`; **≤150 → XS · 151-600 → S · 601-1500 → M · >1500 → L**; effective size = the lower of that and `meta.json.size`; `proportional` runs the built-in at **medium/high/high/xhigh** by size and the panel at M and above (at S only on a sensitive surface); the bump raises the effort one tier (medium→high→xhigh→**max**) and always runs the panel; `full` is **xhigh** plus the panel at any size, `light` is the built-in alone at **medium** with no panel, no §3 and no §6 — and a sensitive surface lifts `light` to the proportional tier for that work.
 
 **The diff pointing *higher* than `meta.json.size`** is worth one line in `06-review.md` (the work may be misclassified), never a heavier review. **The sensitive-surface bump is never scaled away** — a 12-line change to an authorization check still gets the panel, on a delta exactly as on a first review.
 
@@ -154,7 +154,7 @@ Launch the reviewers selected in §2.0 and **consolidate their findings into a s
 
 When both run, deduplicate overlapping correctness/simplification findings (count each once). The `review_skill` specialists (offensive/defensive security, silent failures, architecture) are not repeated in later phases.
 
-**Dedup keeps every source, not the first one.** A finding carries its **origin** from here to §8 — `built-in`, a panel role, or the pass that raised it (`§3.5`, `§3.6`, `§5`, `§5.5`) — and a finding more than one source raised lists all of them. Counted once, credited to each. Beyond the built-in and the panel this command runs four specialised passes, roughly 1 800 of its words, every one added after a real defect got through and not one able to show it still earns that cost: a finding only the idiom audit saw and a finding three sources raised say opposite things about that pass, and until now both were written identically. The `Cost:` line stopped being a headcount when `meta.json.cost[]` arrived; this is the same move for the thing those costs are spent on.
+**Dedup keeps every source, not the first one.** A finding carries its **origin** from here to §8 — `built-in`, a panel role, or the pass that raised it (`§3.5`, `§3.6`, `§5`, `§5.5`) — and a finding more than one source raised lists all of them. Counted once, credited to each: a finding only one pass saw and a finding three sources raised say opposite things about that pass, and §9 records the difference.
 
 ### 2.2 Design truth vs design rationale (do not inherit rationalizations)
 `03-design.md` goes to reviewers as context, with unequal authority:
@@ -173,7 +173,7 @@ Only what §2 does **not** already cover; skipped entirely under `light` (§2.0)
 
 ## 3.5. Completeness sweep (anti-abandonment, M/L only)
 
-Counters a reviewer abandoning a large diff early. **Only if `meta.json.size` is M or L**, and only
+Counters a reviewer abandoning a large diff early. **Only if the effective size of §2.0 is M or L**, and only
 if §2.0b's budget still covers it (it is the first phase dropped).
 
 **It runs after §2-§3 are consolidated, never in parallel with them.** The whole phase is an audit of
@@ -265,7 +265,7 @@ Findings enter the normal flow: §6, then the output. Blinded for the same reaso
 
 A filter against over-reporting, not a second review; narrow gate. Never runs under `light` (§2.0).
 
-**When it runs.** All three conditions:
+**When it runs.** All four conditions:
 
 | Condition | Threshold |
 |---|---|
@@ -274,7 +274,7 @@ A filter against over-reporting, not a second review; narrow gate. Never runs un
 | Findings | **≥ 4** ambiguous findings across §2-§5 |
 | Budget | §2.0b's budget still covers a round (§6 is the second phase dropped) |
 
-Read the real diff (`git diff --stat` against the target branch), not the recorded size.
+Read the real diff (`git diff --stat <review base>...<candidate_sha>`, §1.5), not the recorded size.
 
 When all three hold: in **`manual`**, offer it with `AskUserQuestion` ("Verify the ambiguous findings with skeptics in parallel? Discards false positives before you go fix them."). In **`guided`/`auto`, do not ask** — flow mechanics: run it and note in `06-review.md` that you did.
 
@@ -354,7 +354,7 @@ Write `.claude/work/<TICKET>/06-review.md`. The `Cost:` line of `## Summary` is
 ## Discarded by adversarial verification
 <only if §6 was run; list of refuted findings with reason, or "not applicable">
 <if the `fanout_max` cap left ambiguous findings unverified, list them here as "unverified (cap)">
-<if §6 did not run, one line saying which condition did not hold — size, diff size, or count>
+<if §6 did not run, one line saying which condition did not hold — size, diff size, count, or budget>
 
 ## Blockers (must-fix)
 1. [file:line] · <origin> · description + concrete proposal
@@ -377,12 +377,11 @@ Write `.claude/work/<TICKET>/06-review.md`. The `Cost:` line of `## Summary` is
 - Blockers → **do not advance `phase`**. Leave `phase = "build"`; the user resolves them.
 - No blockers → `phase = "review"`, add to `phases_done`. **In a multi-MR/PR work**, also add `review` to the current `in_progress` MR/PR's own `phases_done` (its `mrs[]` entry) — `/flow-feat-ship §1` gates on it per MR/PR.
 - **Record *what* you reviewed, and separately what you changed after reading it**, in the same write, work-level and — in a multi-MR/PR work — in this MR/PR's `mrs[]` entry too:
-  - `reviewed_sha` = **the candidate of §1.5**, the revision the reviewers actually read. Not `git rev-parse HEAD`, which is what it used to be and which by then holds this round's own fixes — code no reviewer saw, recorded as reviewed, and `ship` finding it equal to `HEAD` every time.
-  - `fixed_sha` = `git rev-parse HEAD` after this round's fixes, or **empty** when the round applied none. Two fields because they are two facts, and collapsing them is what hid the delta.
+  - `reviewed_sha` = **the candidate of §1.5**, the revision the reviewers actually read. Not `git rev-parse HEAD`, which by then holds this round's own fixes — code no reviewer saw, recorded as reviewed, and `ship` finding it equal to `HEAD` every time.
+  - `fixed_sha` = `git rev-parse HEAD` after this round's fixes, or **empty** when the round applied none. Two fields because they are two facts.
   - `phases_done` says a review *happened*; these say which tree, and `/flow-feat-ship §1` reads both before pushing. Written whenever the phase advances, never when it does not: a review that ended in blockers reviewed nothing that stands.
 - **Record which pass found what**, in the same write: `meta.json.review_findings[]`, one entry per finding **per source** — `{ round, origin, severity, file, discarded_by_skeptic }`, and no finding text, which stays in the artifact. `flow review --record` writes these itself when the CLI ran the panel; when the agentic panel ran, write them here from the origins §2.1 carried. `flow cost` reads them back per origin: how many findings each pass contributed, how many only it raised, and how many of those survived §6. That last number is the only evidence a pass is still earning its words.
-  **The retirement rule, written down before the data arrives** so it cannot be argued backwards later: a pass that contributes **no exclusive surviving finding across twenty reviews** is removed from this command. Zero is zero, and the decision is made against the number rather than against whoever is most attached to the pass.
-- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most and, until now, the one phase that never staged — a work with three review rounds and seventeen blockers produced zero knowledge cards because nothing asked for them while they were in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `ship`»). Never `knowledge.save` here.
+- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most, and this is the only moment its findings are in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `ship`»). Never `knowledge.save` here.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - **Record what the agents missed** (flow-core §6.7, `agents.learn` not `off`; asking nothing): for each finding that survived, the panel member or named `agents.<role>` whose category it falls in and who did not report it, and the delegated `build` agent whose code it sits in → one `meta.json.agent_lessons[]` row each, only when the lesson passes the §6.7 test. The origins §2.1 carried are what make this possible — a finding with no origin teaches nobody.
 - **Configuration this phase earned the right to ask about** (flow-core §0, `manual` only, at most one key per work, as an extra option on this same stop — never a question of its own): a `Cost:` line that went over `agents.budget_max` → `quality.review_depth`. In `guided`/`auto` neither is asked: the default is taken and recorded in `meta.json.defaults_used[]`.

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

@@ -83,7 +83,6 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
   "branch": "{PREFIX}XXXXX-slug",
   "size": "XS" | "S" | "M" | "L",
   "phase": "context" | "design" | "plan" | "build" | "review" | "validate" | "ship" | "investigate" | "fix" | "postmortem" | "done" | "abandoned",
-  // retired in v0.53.0 and still read from older works: "brainstorm" → treat as "context", "diagnose" → as "investigate"
   "phases_done": ["context", ...],
   "candidate_sha": "40-char sha the current review froze before reading, or ''",
   "reviewed_sha": "40-char sha the last passing review read, or ''",
@@ -116,11 +115,11 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
   ],
   "followups": [
     { "id": "F1",
-      "kind": "prevention" | "audit" | "out-of-scope" | "risk" | "edge-case" | "other-bug",
+      "kind": "prevention" | "audit" | "out-of-scope" | "risk" | "edge-case" | "other-bug" | "tooling" | "decision",
       "title": "one line, what would be done",
       "why": "one line, why it was parked and why it still matters",
       "source": "design" | "plan" | "build" | "validate" | "fix" | "postmortem",
-      "status": "proposed" | "accepted" | "in_progress" | "declined" | "done",
+      "status": "proposed" | "accepted" | "in_progress" | "declined" | "logged" | "done",
       "ticket": null, "work": null, "note": "" }
   ],
   "defaults_used": [

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

@@ -27,7 +27,6 @@ Use when returning to a work after a break (next morning, another session).
 - `git branch --show-current`.
 - Search `.claude/work/` for the `meta.json` whose `branch` matches.
 - None found → ask the user for the ticket or whether to start a new one.
-- **A `phase` retired in v0.53.0** — `brainstorm` or `diagnose`, from a work started before it — is mapped, never refused: `brainstorm` → `design` (its `02-brainstorm.md` is that command's §1.5 output, already done), `diagnose` → `investigate` (its `02-diagnose.md` is that command's §1.5 output). Say which mapping you applied, in one line, and suggest the mapped command. Do not rewrite `meta.json` for it; the phase advances normally at the next Close.
 - `meta.json.worktree` non-null and the current directory is not that worktree → tell the user the work lives in a worktree and to `cd <worktree>` before continuing; run the repo-state checks below from there (`git -C <worktree> …`).
 
 ## 2. Recap

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.80.0",
+  "version": "0.81.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": {