flow-workflows 0.82.0 → 0.82.1

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.82.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.1`.** 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
@@ -246,7 +246,7 @@ The §3 stop header is still printed at every stop — a log is the only screen
 | Push and MR/PR creation (`ship`) | `autonomy.unattended_ship: draft` → push the work branch and create the MR/PR **as draft**; never merge, never mark it ready; the forge refusing a draft → blocked, never retried as a normal one. Empty or `stop` → question `ship` |
 | Writing a DB schema change, index or migration — in any phase, a review's own fixes included — or applying one (`validate`) | question `migration`, before the first line of it is written or run |
 | `review` with blockers or high-severity findings | question `high_findings` |
-| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain |
+| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain. **One exception, and it is measured, never judged**: every failing test also fails, under the same name, on the base (`git merge-base HEAD <git.default_base>`, run in a detached worktree), none of them lives in a file this diff touches, and none is the test that proves an acceptance criterion → record `{"key":"unattended:validate-red-base","default":"<n> red on HEAD and on base <short sha>: <test names>","phase":"validate"}` and advance; `ship` lists those tests under "Not verified — needs a human". Short of all three — a failure the base does not reproduce, a base that cannot be run, a test this diff touched — blocked |
 | A product decision (§7 `decision`) | question `decision` |
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |

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

@@ -93,7 +93,7 @@ this is the same gate as a red test.
 
 ## 5. Close
 
-- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1).
+- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1 — unless every failing test also fails on the base, the one exception that row records; the reproduction test lives in a file this diff touches, so it never qualifies).
 - Green → `phase = "validate"`, add to `phases_done`; in the same write record `validated_sha` = `git rev-parse HEAD` — the tree the regression test passed on, which `$flow-bug-ship §0` reads. Suggest `$flow-bug-review`.
 - **Other bugs detected become `followups[]` entries** (flow-core §7) when they clear its bar — a reproducible symptom with someone who suffers it, not «this looks fragile» — per the output template.
 - **Stage what the validation taught** (`knowledge.stage` set; silence by default): a mutation that stayed green, a disguise the scenario wore, a fixture that could not produce the case — findings about how this codebase is tested, not about this diff. Same rule and evidence line as the review's Close.

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

@@ -52,7 +52,9 @@ pushes. Each place it would ask:
   `$flow-feat-build`). It is the last thing the run does.
 
 **In every mode**, criteria `07-validation.md` marks `not-verified-unattended` go into the body under
-`## Not verified — needs a human`, with what to do for each. The §3 preview shows that section like
+`## Not verified — needs a human`, with what to do for each — and so do the tests the suite left red
+because they also fail on the base (`unattended:validate-red-base`): each name, and the base sha
+where it failed too. The §3 preview shows that section like
 any other, and the person reading it is the check the run could not do.
 
 ## 1. Pre-flight

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

@@ -225,6 +225,9 @@ Write `.claude/work/<TICKET>/07-validation.md`:
 - **Autonomy handoff — this one stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR: a hard gate in every mode, so do **not** chain into it. Stop here and propose `$flow-feat-ship` with a single `AskUserQuestion` (recommended option by default), invoking it only when the user confirms. This is the deliberate end of a run in `auto`.
   **In `unattended`** (flow-core §2.1): the phase advanced → chain into `$flow-feat-ship`, which
   decides from `autonomy.unattended_ship` between a draft MR/PR and a question. It did not advance
-  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain.
+  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain. A red suite
+  advances only under the base exception of flow-core §2.1: run the failing tests on the base, and
+  write each name, its result there and the base sha under "Suite results" in `07-validation.md`.
+  Calling a failure "pre-existing" without that run is not the exception — it is a red suite.
 
 In `guided`/`auto` this is, together with the brief in `$flow-feat-build §2`, **the only stop of the whole MR/PR** — everything between them ran without a person. It carries the **full stop header** and the body answers, in this order: what is green, what this MR/PR proves and what it does not, and what shipping it takes. Assume the user has read none of the build and review.

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.82.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.1`.** 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
@@ -245,7 +245,7 @@ The §3 stop header is still printed at every stop — a log is the only screen
 | Push and MR/PR creation (`ship`) | `autonomy.unattended_ship: draft` → push the work branch and create the MR/PR **as draft**; never merge, never mark it ready; the forge refusing a draft → blocked, never retried as a normal one. Empty or `stop` → question `ship` |
 | Writing a DB schema change, index or migration — in any phase, a review's own fixes included — or applying one (`validate`) | question `migration`, before the first line of it is written or run |
 | `review` with blockers or high-severity findings | question `high_findings` |
-| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain |
+| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain. **One exception, and it is measured, never judged**: every failing test also fails, under the same name, on the base (`git merge-base HEAD <git.default_base>`, run in a detached worktree), none of them lives in a file this diff touches, and none is the test that proves an acceptance criterion → record `{"key":"unattended:validate-red-base","default":"<n> red on HEAD and on base <short sha>: <test names>","phase":"validate"}` and advance; `ship` lists those tests under "Not verified — needs a human". Short of all three — a failure the base does not reproduce, a base that cannot be run, a test this diff touched — blocked |
 | A product decision (§7 `decision`) | question `decision` |
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |

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

@@ -89,7 +89,7 @@ this is the same gate as a red test.
 
 ## 5. Close
 
-- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1).
+- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1 — unless every failing test also fails on the base, the one exception that row records; the reproduction test lives in a file this diff touches, so it never qualifies).
 - Green → `phase = "validate"`, add to `phases_done`; in the same write record `validated_sha` = `git rev-parse HEAD` — the tree the regression test passed on, which `/flow:bug:ship §0` reads. Suggest `/flow:bug:review`.
 - **Other bugs detected become `followups[]` entries** (flow-core §7) when they clear its bar — a reproducible symptom with someone who suffers it, not «this looks fragile» — per the output template.
 - **Stage what the validation taught** (`knowledge.stage` set; silence by default): a mutation that stayed green, a disguise the scenario wore, a fixture that could not produce the case — findings about how this codebase is tested, not about this diff. Same rule and evidence line as the review's Close.

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

@@ -48,7 +48,9 @@ pushes. Each place it would ask:
   `/flow:feat:build`). It is the last thing the run does.
 
 **In every mode**, criteria `07-validation.md` marks `not-verified-unattended` go into the body under
-`## Not verified — needs a human`, with what to do for each. The §3 preview shows that section like
+`## Not verified — needs a human`, with what to do for each — and so do the tests the suite left red
+because they also fail on the base (`unattended:validate-red-base`): each name, and the base sha
+where it failed too. The §3 preview shows that section like
 any other, and the person reading it is the check the run could not do.
 
 ## 1. Pre-flight

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

@@ -221,7 +221,10 @@ Write `.claude/work/<TICKET>/07-validation.md`:
 - **Autonomy handoff — this one stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR: a hard gate in every mode, so do **not** chain into it. Stop here and propose `/flow:feat:ship` with a single `AskUserQuestion` (recommended option by default), invoking it only when the user confirms. This is the deliberate end of a run in `auto`.
   **In `unattended`** (flow-core §2.1): the phase advanced → chain into `/flow:feat:ship`, which
   decides from `autonomy.unattended_ship` between a draft MR/PR and a question. It did not advance
-  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain.
+  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain. A red suite
+  advances only under the base exception of flow-core §2.1: run the failing tests on the base, and
+  write each name, its result there and the base sha under "Suite results" in `07-validation.md`.
+  Calling a failure "pre-existing" without that run is not the exception — it is a red suite.
 
 In `guided`/`auto` this is, together with the brief in `/flow:feat:build §2`, **the only stop of the whole MR/PR** — everything between them ran without a person. It carries the **full stop header** and the body answers, in this order: what is green, what this MR/PR proves and what it does not, and what shipping it takes. Assume the user has read none of the build and review.
 """

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.82.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.1`.** 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
@@ -246,7 +246,7 @@ The §3 stop header is still printed at every stop — a log is the only screen
 | Push and MR/PR creation (`ship`) | `autonomy.unattended_ship: draft` → push the work branch and create the MR/PR **as draft**; never merge, never mark it ready; the forge refusing a draft → blocked, never retried as a normal one. Empty or `stop` → question `ship` |
 | Writing a DB schema change, index or migration — in any phase, a review's own fixes included — or applying one (`validate`) | question `migration`, before the first line of it is written or run |
 | `review` with blockers or high-severity findings | question `high_findings` |
-| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain |
+| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain. **One exception, and it is measured, never judged**: every failing test also fails, under the same name, on the base (`git merge-base HEAD <git.default_base>`, run in a detached worktree), none of them lives in a file this diff touches, and none is the test that proves an acceptance criterion → record `{"key":"unattended:validate-red-base","default":"<n> red on HEAD and on base <short sha>: <test names>","phase":"validate"}` and advance; `ship` lists those tests under "Not verified — needs a human". Short of all three — a failure the base does not reproduce, a base that cannot be run, a test this diff touched — blocked |
 | A product decision (§7 `decision`) | question `decision` |
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |

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

@@ -93,7 +93,7 @@ this is the same gate as a red test.
 
 ## 5. Close
 
-- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1).
+- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1 — unless every failing test also fails on the base, the one exception that row records; the reproduction test lives in a file this diff touches, so it never qualifies).
 - Green → `phase = "validate"`, add to `phases_done`; in the same write record `validated_sha` = `git rev-parse HEAD` — the tree the regression test passed on, which `/flow-bug-ship §0` reads. Suggest `/flow-bug-review`.
 - **Other bugs detected become `followups[]` entries** (flow-core §7) when they clear its bar — a reproducible symptom with someone who suffers it, not «this looks fragile» — per the output template.
 - **Stage what the validation taught** (`knowledge.stage` set; silence by default): a mutation that stayed green, a disguise the scenario wore, a fixture that could not produce the case — findings about how this codebase is tested, not about this diff. Same rule and evidence line as the review's Close.

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

@@ -52,7 +52,9 @@ pushes. Each place it would ask:
   `/flow-feat-build`). It is the last thing the run does.
 
 **In every mode**, criteria `07-validation.md` marks `not-verified-unattended` go into the body under
-`## Not verified — needs a human`, with what to do for each. The §3 preview shows that section like
+`## Not verified — needs a human`, with what to do for each — and so do the tests the suite left red
+because they also fail on the base (`unattended:validate-red-base`): each name, and the base sha
+where it failed too. The §3 preview shows that section like
 any other, and the person reading it is the check the run could not do.
 
 ## 1. Pre-flight

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

@@ -225,6 +225,9 @@ Write `.claude/work/<TICKET>/07-validation.md`:
 - **Autonomy handoff — this one stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR: a hard gate in every mode, so do **not** chain into it. Stop here and propose `/flow-feat-ship` with a single `AskUserQuestion` (recommended option by default), invoking it only when the user confirms. This is the deliberate end of a run in `auto`.
   **In `unattended`** (flow-core §2.1): the phase advanced → chain into `/flow-feat-ship`, which
   decides from `autonomy.unattended_ship` between a draft MR/PR and a question. It did not advance
-  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain.
+  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain. A red suite
+  advances only under the base exception of flow-core §2.1: run the failing tests on the base, and
+  write each name, its result there and the base sha under "Suite results" in `07-validation.md`.
+  Calling a failure "pre-existing" without that run is not the exception — it is a red suite.
 
 In `guided`/`auto` this is, together with the brief in `/flow-feat-build §2`, **the only stop of the whole MR/PR** — everything between them ran without a person. It carries the **full stop header** and the body answers, in this order: what is green, what this MR/PR proves and what it does not, and what shipping it takes. Assume the user has read none of the build and review.

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.82.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.1`.** 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
@@ -245,7 +245,7 @@ The §3 stop header is still printed at every stop — a log is the only screen
 | Push and MR/PR creation (`ship`) | `autonomy.unattended_ship: draft` → push the work branch and create the MR/PR **as draft**; never merge, never mark it ready; the forge refusing a draft → blocked, never retried as a normal one. Empty or `stop` → question `ship` |
 | Writing a DB schema change, index or migration — in any phase, a review's own fixes included — or applying one (`validate`) | question `migration`, before the first line of it is written or run |
 | `review` with blockers or high-severity findings | question `high_findings` |
-| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain |
+| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain. **One exception, and it is measured, never judged**: every failing test also fails, under the same name, on the base (`git merge-base HEAD <git.default_base>`, run in a detached worktree), none of them lives in a file this diff touches, and none is the test that proves an acceptance criterion → record `{"key":"unattended:validate-red-base","default":"<n> red on HEAD and on base <short sha>: <test names>","phase":"validate"}` and advance; `ship` lists those tests under "Not verified — needs a human". Short of all three — a failure the base does not reproduce, a base that cannot be run, a test this diff touched — blocked |
 | A product decision (§7 `decision`) | question `decision` |
 | Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
 | An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |

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

@@ -91,7 +91,7 @@ this is the same gate as a red test.
 
 ## 5. Close
 
-- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1).
+- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1 — unless every failing test also fails on the base, the one exception that row records; the reproduction test lives in a file this diff touches, so it never qualifies).
 - Green → `phase = "validate"`, add to `phases_done`; in the same write record `validated_sha` = `git rev-parse HEAD` — the tree the regression test passed on, which `/flow-bug-ship §0` reads. Suggest `/flow-bug-review`.
 - **Other bugs detected become `followups[]` entries** (flow-core §7) when they clear its bar — a reproducible symptom with someone who suffers it, not «this looks fragile» — per the output template.
 - **Stage what the validation taught** (`knowledge.stage` set; silence by default): a mutation that stayed green, a disguise the scenario wore, a fixture that could not produce the case — findings about how this codebase is tested, not about this diff. Same rule and evidence line as the review's Close.

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

@@ -50,7 +50,9 @@ pushes. Each place it would ask:
   `/flow-feat-build`). It is the last thing the run does.
 
 **In every mode**, criteria `07-validation.md` marks `not-verified-unattended` go into the body under
-`## Not verified — needs a human`, with what to do for each. The §3 preview shows that section like
+`## Not verified — needs a human`, with what to do for each — and so do the tests the suite left red
+because they also fail on the base (`unattended:validate-red-base`): each name, and the base sha
+where it failed too. The §3 preview shows that section like
 any other, and the person reading it is the check the run could not do.
 
 ## 1. Pre-flight

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

@@ -223,6 +223,9 @@ Write `.claude/work/<TICKET>/07-validation.md`:
 - **Autonomy handoff — this one stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR: a hard gate in every mode, so do **not** chain into it. Stop here and propose `/flow-feat-ship` with a single `AskUserQuestion` (recommended option by default), invoking it only when the user confirms. This is the deliberate end of a run in `auto`.
   **In `unattended`** (flow-core §2.1): the phase advanced → chain into `/flow-feat-ship`, which
   decides from `autonomy.unattended_ship` between a draft MR/PR and a question. It did not advance
-  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain.
+  (red suite, a criterion `unproven`) → `blocked`, naming what failed; never chain. A red suite
+  advances only under the base exception of flow-core §2.1: run the failing tests on the base, and
+  write each name, its result there and the base sha under "Suite results" in `07-validation.md`.
+  Calling a failure "pre-existing" without that run is not the exception — it is a red suite.
 
 In `guided`/`auto` this is, together with the brief in `/flow-feat-build §2`, **the only stop of the whole MR/PR** — everything between them ran without a person. It carries the **full stop header** and the body answers, in this order: what is green, what this MR/PR proves and what it does not, and what shipping it takes. Assume the user has read none of the build and review.

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,20 @@ 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.82.1 — A red suite no longer ships because the run called it old  ·  2026-09-29
+
+**In short**
+- **An unattended `validate` could pass a red suite on its own judgement.** It decided the failures
+  were "pre-existing", chained into `ship`, recorded nothing, and the draft MR/PR never said the suite
+  was red.
+- **Now that call is a measurement.** A red suite advances only when every failing test also fails,
+  under the same name, on the base; none of them is in a file the diff touches; and none proves an
+  acceptance criterion. Anything short of that ends the run `blocked`.
+- **And it is visible.** The run records it in `meta.json`, `07-validation.md` names each test and
+  the base it was checked on, and the MR/PR lists them under "Not verified — needs a human".
+
+Reported in #172.
+
 ## v0.82.0 — Nobody at the terminal, and the run still gets somewhere  ·  2026-09-29
 
 **In short**