flow-workflows 0.79.0 → 0.81.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.79.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
@@ -30,12 +30,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`,
@@ -68,11 +65,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
@@ -93,7 +87,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.
@@ -120,8 +114,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,
@@ -271,7 +264,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
@@ -414,8 +407,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`,
@@ -450,7 +442,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
@@ -492,8 +484,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.
 
@@ -558,15 +549,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:
@@ -712,11 +701,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.
 
@@ -751,8 +740,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):
@@ -779,15 +768,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`.
@@ -879,7 +863,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/codex/skills/flow-bug-investigate/SKILL.md

@@ -28,9 +28,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 - 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
 
@@ -38,9 +36,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/codex/skills/flow-bug-review/SKILL.md

@@ -37,7 +37,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
   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.
@@ -72,7 +72,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 - **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
 
@@ -235,7 +235,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/codex/skills/flow-doctor/SKILL.md

@@ -47,9 +47,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/codex/skills/flow-feat-design/SKILL.md

@@ -27,7 +27,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)
@@ -36,13 +36,10 @@ 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.
 
-### 1.5.1 Focused knowledge query
+### 1.5.1 Focused knowledge query, then the inventory
 
 `knowledge.search` set → 2-3 parallel queries on the **concept or pattern** the feature covers, not
 its title (`$flow-feat-start` already queried that): tracking → `"tracking deduplication"`,
@@ -50,6 +47,11 @@ its title (`$flow-feat-start` already queried that): tracking → `"tracking ded
 `"attachment handler"`, `"tax rules integration"`. Two seconds, then continue regardless. Hits go
 under "Additional domain context" in §5's template.
 
+**Then the inventory.** Run §3's prior inventory **now**, before any approach is proposed, and keep
+its result for `03-design.md`'s "## What already exists". An approach proposed without it reinvents
+what the repository already has, and a lens whose only job was to go and look for it spends an
+agent on what one search answers for every advisor at once. §3 is then already done.
+
 ### 1.5.2 Panel or single agent?
 
 - **M or L**, in `manual`: offer the **parallel approach panel** with `AskUserQuestion` ("Generate
@@ -58,11 +60,14 @@ under "Additional domain context" in §5's template.
   panel, note it in one line of `03-design.md`, go to §1.5.3.
 - Declined, or the user insisted on running this on S → §1.5.4.
 
-### 1.5.3 Approach panel (parallel fan-out — LLM-council pattern)
+### 1.5.3 Approach panel (parallel fan-out, one round)
 
-**Launch the advisors as parallel subagents** — one per lens, single round, each blind to the others
-(LLM-council: independent advisors, then a chairman synthesises; a **cross-critique** round in
-between for **L** only).
+**Launch the advisors as parallel subagents** — one per lens, a single round, each blind to the
+others; then you synthesise. **There is no debate round.** Advisors that share one base model share
+its blind spots: a round in which they read and attack each other tends to converge on the most
+confident answer rather than surface a new one, and it costs as many agents as the first round. The
+diversity is in what each lens is asked to *optimise*, and the adversarial pass is §6's challenger,
+which attacks the design that was actually chosen.
 
 **How wide the fan-out goes** — `agents.fanout_max` from `FLOW.md` (empty → **4**): never more than
 that in one round, and never more than `agents.budget_max` (empty → **12**) across this whole
@@ -70,22 +75,16 @@ command run (flow-core §6); a round that does not fit is truncated and the trun
 (`3/4`). With `models.workers` and `models.agents` empty, a round of 4 or more inherits this thread's
 model — say so in one line before launching, naming the key and never a model (flow-core §1).
 
-| Size | Rounds |
-|---|---|
-| M | Advisors → you synthesise |
-| L | Advisors → cross-critique → you synthesise |
-
-**You are the chairman.** Round 1 (and round 2 on L) are subagents; the synthesis and the ranking are
-yours, never a subagent's — you hold the work's context and you write `03-design.md`.
+**You are the chairman.** The advisors are subagents; the synthesis and the ranking are yours, never
+a subagent's — you hold the work's context and you write `03-design.md`.
 
-**Round 1 — advisors (parallel, blind to each other).** One subagent per lens, up to `fanout_max`.
-M → the first three lenses; L → add `operations`, and also on a sensitive surface (authentication or
+**Advisors (parallel, blind to each other).** One subagent per lens, up to `fanout_max`. M → the
+first two lenses; L → add `operations`, and also on a sensitive surface (authentication or
 authorization, payments, personal data, a public contract, a migration):
 
 | Lens | Brief |
 |---|---|
-| `minimum` | The **smallest** approach that solves the declared use case, nothing more (strict MVP) |
-| `reuse` | The approach that **most reuses** existing pieces in the affected module or its neighbours |
+| `minimum` | The **smallest** approach that solves the declared use case, built on what the inventory found before anything new (strict MVP) |
 | `reframe` | **Challenge the premise**: what if the problem is solved without building what was asked, or somewhere else? |
 | `operations` | The most production-solid approach (observability, integration failure, data at scale) |
 
@@ -93,31 +92,22 @@ Each advisor gets this brief, with its lens substituted:
 
 > Propose ONE approach to solve ticket `<TICKET>`, from this lens: `<lens brief>`. Read
 > `.claude/work/<TICKET>/01-context.md` for context and the effective FLOW configuration (base plus
-> active harness overlay) for project conventions. Do not
+> active harness overlay) for project conventions. What already exists in the repository:
+> `<the §1.5.1 inventory>` — propose a new piece only where nothing there fits. Do not
 > write code. Be specific about real modules and layers of this project. Report: name, what it is
 > (one sentence), modules/layers affected, main risk, and why it could be a bad idea. Under 250 words.
 > **Write that same answer to `.claude/work/<TICKET>/approaches/<lens>.md` before you reply** — the
 > file is the deliverable and the reply is a copy of it.
 
-**Round 2 — cross-critique (L only, parallel).** Each advisor receives the full set and attacks the
-*others* from its own lens:
-
-> You are the "`<lens>`" advisor. The approaches proposed for `<TICKET>` are in
-> `.claude/work/<TICKET>/approaches/` — read them all, plus `.claude/work/<TICKET>/01-context.md`.
-> From your lens (`<lens brief>`), critique the
-> OTHER approaches — not your own. For each one name its single biggest flaw for THIS project, or
-> "none". Then say which is strongest and which weakest, and why. Be concrete and grounded in the
-> project; do not invent flaws to fill space. **Write your critique to
-> `.claude/work/<TICKET>/approaches/critique-<lens>.md` before you reply.**
-
-**Round 3 — you synthesise.** A reply that arrived is already in your context and its file adds
+**Then you synthesise.** A reply that arrived is already in your context and its file adds
 nothing — **open only the files of the lenses that did not answer**, and only then. Rank the
-approaches best to worst *for this case* (project fit and
-simplicity, not generic merit), weighing the fatal flaws the critique surfaced. State explicitly
-where the advisors **agreed** and where they **disagreed** — the disagreement is the useful part.
+approaches best to worst *for this case* (project fit and simplicity, not generic merit), weighing
+each one's own "why it could be a bad idea" against the others' — rank on substance, not on which
+advisor wrote best. State explicitly where the advisors **agreed** and where they **disagreed** —
+the disagreement is the useful part.
 
-`agents.fanout_tool` set → run the rounds through that tool instead of plain parallel subagents; the
-rounds, the briefs and the ceiling do not change.
+`agents.fanout_tool` set → run the round through that tool instead of plain parallel subagents; the
+lenses, the briefs and the ceiling do not change.
 
 **A round that answers nothing is read off disk before it is written off** (flow-core §6). The
 advisors write their files first and reply second, so `ls .claude/work/<TICKET>/approaches/` settles
@@ -125,15 +115,15 @@ what actually happened: a file there is an answer that got lost in transit, and
 it without spending a single agent. Only a lens with no file is empty — **it is asked once for its
 answer and then dropped, never relaunched**, because an empty result is as often a truncated report
 as an advisor with nothing to say, and a relaunched round is paid for twice out of one
-`agents.budget_max`. Synthesise from those that answered and record `N/M`. An empty critique round
-→ rank from the approaches alone.
+`agents.budget_max`. Synthesise from those that answered and record `N/M`.
 
 ### 1.5.4 Single agent (the S case, or a declined panel)
 
 Launch a `general-purpose` subagent with this short, self-contained brief:
 
 > Generate 3-5 distinct approaches to solve `<title>` following the project conventions (see
-> the effective FLOW configuration and `.claude/work/<TICKET>/01-context.md`). For each: a
+> the effective FLOW configuration and `.claude/work/<TICKET>/01-context.md`), building on what
+> already exists: `<the §1.5.1 inventory>`. For each: a
 > one-sentence description,
 > modules/layers affected, main risk, and why it could be a bad idea. Do not write code. Report in
 > markdown, under 400 words.
@@ -166,7 +156,7 @@ A sensitive domain (payments, authentication, tracking) → launch **in parallel
 
 ## 3. Prior inventory (reuse before creating)
 
-**Before** launching the design subagents, list what the feature needs that **already exists** in code or DB. Launch an `Agent` with `subagent_type: Explore`:
+**M/L already ran this in §1.5.1** — reuse that result and skip to §4. XS/S: **before** launching the design subagents, list what the feature needs that **already exists** in code or DB. Launch an `Agent` with `subagent_type: Explore`:
 
 > For feature `<title>` (see `.claude/work/<TICKET>/01-context.md`), search the repo for related pieces that already exist and could be reused: domain entities, value objects, repositories, services, events, columns or tables, CQRS commands/queries, and similar endpoints. Do not propose design — only list what is found with one line each and its location. If the feature mentions concepts like `<concept1>`, `<concept2>`, search for those specifically.
 

package/adapters/codex/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 codex --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/codex/skills/flow-work-README/SKILL.md

@@ -72,7 +72,7 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
 - **Code review is mandatory**: `$flow-feat-ship` is not run and `$flow-bug-postmortem` is not closed without passing through `/*:review`.
 - **Existing sub-agents**: commands delegate to the project's agents and skills; work is never duplicated.
 - **The subagents' model is the repo's call, never the plugin's (`models` in FLOW.md)**: `agents` (every subagent a command improvises) · `workers` (the fan-out rounds, falling back to `agents`). Empty = **inherit**. There is no key for what the main agent does itself: **an agent cannot switch its own model** (say it, **continue**); **a named agent keeps its own** (`agents.<role>`) — flow-core §1. `$flow-doctor` prints both resolved; `quality.review_skill` owns the review panel.
-- **Parallel multi-agent fan-out (optional, only where it pays)**: plain subagents. (1) `$flow-feat-design` §1.5.3: one agent per lens (minimum / reuse / reframe, + operations for L or a sensitive surface), cross-critique for L only. (2) `$flow-bug-investigate` §3.A: one agent per root cause, evidence **for and against**. (3) `$flow-feat-review` §6 and `$flow-bug-review` §5: one skeptic per **ambiguous** finding, refute-by-default. (4) `$flow-feat-build` §2.1bis and `$flow-bug-fix` §2.2: **one** skeptic on a premise the change depends on and nothing verifies — at **any size, XS included**, once per MR/PR, a category and not a depth tier, like the query duel. Other phases **do not** fan out. `manual`: offered with `AskUserQuestion`; `guided`/`auto`: runs, noted in the artifact. **The fan-out has two ceilings, and the synthesis is not a subagent**: `agents.fanout_max` (empty → **4**) per round and `agents.budget_max` (empty → **12**) for everything one command run launches, with what either cap drops **said** and the phase each command gives up first declared in it; both count agents, not findings, so grouping is intended and one-agent-per-finding past the cap is a breach; the review tier scales to the **diff under review**, not the size of the feature, and the verification gate also needs a **diff over 150 changed lines**; delegate the **gathering**, keep the **deciding**. **A heavier orchestrator is opt-in, per repo**: `agents.fanout_tool` (e.g. Claude Code's `Workflow`), rounds and ceiling unchanged; empty is the default and the portable path.
+- **Parallel multi-agent fan-out (optional, only where it pays)**: plain subagents. (1) `$flow-feat-design` §1.5.3: one agent per lens (minimum / reframe, + operations for L or a sensitive surface), one round, no debate. (2) `$flow-bug-investigate` §3.A: one agent per root cause, evidence **for and against**. (3) `$flow-feat-review` §6 and `$flow-bug-review` §5: one skeptic per **ambiguous** finding, refute-by-default. (4) `$flow-feat-build` §2.1bis and `$flow-bug-fix` §2.2: **one** skeptic on a premise the change depends on and nothing verifies — at **any size, XS included**, once per MR/PR, a category and not a depth tier, like the query duel. Other phases **do not** fan out. `manual`: offered with `AskUserQuestion`; `guided`/`auto`: runs, noted in the artifact. **The fan-out has two ceilings, and the synthesis is not a subagent**: `agents.fanout_max` (empty → **4**) per round and `agents.budget_max` (empty → **12**) for everything one command run launches, with what either cap drops **said** and the phase each command gives up first declared in it; both count agents, not findings, so grouping is intended and one-agent-per-finding past the cap is a breach; the review tier scales to the **diff under review**, not the size of the feature, and the verification gate also needs a **diff over 150 changed lines**; delegate the **gathering**, keep the **deciding**. **A heavier orchestrator is opt-in, per repo**: `agents.fanout_tool` (e.g. Claude Code's `Workflow`), rounds and ceiling unchanged; empty is the default and the portable path.
 - **Knowledge sources (full cycle)**: the `knowledge` section names a tool per **role** — `search`, `stage`, `read_staging`, `save` — any MCP (domain-memory, codegraph…), CLI or skill; a role that is empty degrades (no lookup / finding stays in the artifact / artifacts are the staging / `KNOWLEDGE.md`); `knowledge.timeout_s` (2 s) or any failure → continue silently. **`knowledge.search`**: `$flow-feat-start`, `$flow-bug-start` (ticket keywords), `$flow-feat-design` (approaches, module + integrations), `$flow-bug-investigate` (component in §1.5, cause in §2). **`knowledge.stage`**: closing `$flow-feat-design` and `$flow-bug-investigate`, offer to stage non-obvious domain decisions (silence by default; per-branch). **`knowledge.read_staging`** then **`knowledge.save`** at `$flow-feat-ship` and `$flow-bug-postmortem`: offer to consolidate the "why" only.
 
 ## `meta.json` schema
@@ -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/codex/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