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

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

@@ -42,7 +42,7 @@ 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 +50,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 +63,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 +78,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 +95,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 +118,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 +159,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-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

package/adapters/gemini/CORE.md

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

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

@@ -38,7 +38,7 @@ 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"`,
@@ -46,6 +46,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
@@ -54,11 +59,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
@@ -66,22 +74,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) |
 
@@ -89,31 +91,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
@@ -121,15 +114,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.
@@ -162,7 +155,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/gemini/commands/flow/work/README.toml

@@ -68,7 +68,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

package/adapters/hermes/CORE.md

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

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

@@ -42,7 +42,7 @@ 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 +50,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 +63,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 +78,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 +95,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 +118,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 +159,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/hermes/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

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

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

@@ -40,7 +40,7 @@ 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"`,
@@ -48,6 +48,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
@@ -56,11 +61,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
@@ -68,22 +76,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) |
 
@@ -91,31 +93,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
@@ -123,15 +116,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.
@@ -164,7 +157,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/opencode/commands/flow-work-README.md

@@ -70,7 +70,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

package/package.json

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

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

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,23 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.80.0 — The advisors were arguing with themselves  ·  2026-09-25
+
+**In short**
+- **The design's approach panel is one round now, with no debate.** The L-only round in which each
+  advisor attacked the others is gone: advisors on one base model share its blind spots, and a
+  round of them critiquing each other converges on the most confident answer instead of finding a
+  new one. The adversarial pass is the challenger that already attacks the chosen design.
+- **`minimum` and `reuse` are one lens.** They kept proposing the same approach. The prior
+  inventory now runs **before** the panel and every advisor reads it, so the smallest approach is
+  built on what already exists without an agent spent going to look for it.
+- **M runs two advisors (`minimum`, `reframe`), L or a sensitive surface adds `operations`** —
+  down from three and four-plus-four.
+- **Measured, not argued.** A new design bench (`evals/design-*`): a duplicate a neighbouring module
+  already has, a ticket whose premise one setting answers, and an L change that puts a slow,
+  outage-prone provider on the charge path. Before and after: 9 of 9 runs caught every trap in both;
+  the three cases went from $17.66 to $13.85, and the L case from $2.89 to $1.78 per run.
+
 ## v0.79.0 — The reviewer that missed it was never told  ·  2026-09-23
 
 **In short**