flow-workflows 0.94.0 → 0.94.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.94.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.94.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

package/adapters/codex/skills/flow-work-run/SKILL.md

@@ -96,9 +96,11 @@ switch" case included, and only while no build or fix has begun (neither `05-imp
 that is where it lives. A study writes no code, so its branch still sits where the base was when the
 study began; an approval that waited for the tickets the study depends on (`meta.json.ticket_deps`)
 would otherwise build on a base that lacks them. `<base>` = `meta.json.base`, empty →
-`git.default_base`: `git fetch origin <base>`, then `<ref>` = `origin/<base>`; the fetch failing
-with a remote configured → `blocked`, since a stale ref would leave the build on the old base
-unnoticed. No remote → the local `<base>`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
+`git.default_base`: `git fetch origin <base>` when a remote is configured (best-effort, as
+`$flow-feat-build` does — a fetch the container cannot make is not an error: the orchestrator left
+`origin/<base>` where the forge had it when it launched the run, and a container is given no git
+credentials), then `<ref>` = `origin/<base>` when it resolves, the local `<base>` otherwise. Neither
+resolves → `blocked`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
 `<ref>` → the branch holds no commit of its own and the base moved: `git merge --ff-only <ref>`, and
 record `{ "key": "unattended:base-caught-up", "default": "<old short sha> → <new short sha> on
 <base>", "phase": "run" }`. The fast-forward fails → `blocked`, its message as the reason. Not an

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.94.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.94.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

package/adapters/gemini/commands/flow/work/run.toml

@@ -92,9 +92,11 @@ switch" case included, and only while no build or fix has begun (neither `05-imp
 that is where it lives. A study writes no code, so its branch still sits where the base was when the
 study began; an approval that waited for the tickets the study depends on (`meta.json.ticket_deps`)
 would otherwise build on a base that lacks them. `<base>` = `meta.json.base`, empty →
-`git.default_base`: `git fetch origin <base>`, then `<ref>` = `origin/<base>`; the fetch failing
-with a remote configured → `blocked`, since a stale ref would leave the build on the old base
-unnoticed. No remote → the local `<base>`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
+`git.default_base`: `git fetch origin <base>` when a remote is configured (best-effort, as
+`/flow:feat:build` does — a fetch the container cannot make is not an error: the orchestrator left
+`origin/<base>` where the forge had it when it launched the run, and a container is given no git
+credentials), then `<ref>` = `origin/<base>` when it resolves, the local `<base>` otherwise. Neither
+resolves → `blocked`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
 `<ref>` → the branch holds no commit of its own and the base moved: `git merge --ff-only <ref>`, and
 record `{ "key": "unattended:base-caught-up", "default": "<old short sha> → <new short sha> on
 <base>", "phase": "run" }`. The fast-forward fails → `blocked`, its message as the reason. Not an

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.94.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.94.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

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

@@ -96,9 +96,11 @@ switch" case included, and only while no build or fix has begun (neither `05-imp
 that is where it lives. A study writes no code, so its branch still sits where the base was when the
 study began; an approval that waited for the tickets the study depends on (`meta.json.ticket_deps`)
 would otherwise build on a base that lacks them. `<base>` = `meta.json.base`, empty →
-`git.default_base`: `git fetch origin <base>`, then `<ref>` = `origin/<base>`; the fetch failing
-with a remote configured → `blocked`, since a stale ref would leave the build on the old base
-unnoticed. No remote → the local `<base>`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
+`git.default_base`: `git fetch origin <base>` when a remote is configured (best-effort, as
+`/flow-feat-build` does — a fetch the container cannot make is not an error: the orchestrator left
+`origin/<base>` where the forge had it when it launched the run, and a container is given no git
+credentials), then `<ref>` = `origin/<base>` when it resolves, the local `<base>` otherwise. Neither
+resolves → `blocked`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
 `<ref>` → the branch holds no commit of its own and the base moved: `git merge --ff-only <ref>`, and
 record `{ "key": "unattended:base-caught-up", "default": "<old short sha> → <new short sha> on
 <base>", "phase": "run" }`. The fast-forward fails → `blocked`, its message as the reason. Not an

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.94.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.94.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

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

@@ -94,9 +94,11 @@ switch" case included, and only while no build or fix has begun (neither `05-imp
 that is where it lives. A study writes no code, so its branch still sits where the base was when the
 study began; an approval that waited for the tickets the study depends on (`meta.json.ticket_deps`)
 would otherwise build on a base that lacks them. `<base>` = `meta.json.base`, empty →
-`git.default_base`: `git fetch origin <base>`, then `<ref>` = `origin/<base>`; the fetch failing
-with a remote configured → `blocked`, since a stale ref would leave the build on the old base
-unnoticed. No remote → the local `<base>`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
+`git.default_base`: `git fetch origin <base>` when a remote is configured (best-effort, as
+`/flow-feat-build` does — a fetch the container cannot make is not an error: the orchestrator left
+`origin/<base>` where the forge had it when it launched the run, and a container is given no git
+credentials), then `<ref>` = `origin/<base>` when it resolves, the local `<base>` otherwise. Neither
+resolves → `blocked`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
 `<ref>` → the branch holds no commit of its own and the base moved: `git merge --ff-only <ref>`, and
 record `{ "key": "unattended:base-caught-up", "default": "<old short sha> → <new short sha> on
 <base>", "phase": "run" }`. The fast-forward fails → `blocked`, its message as the reason. Not an

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,21 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.94.1 — An unattended start with a study no longer stops because the container cannot fetch  ·  2026-10-14
+
+**In short**
+- **`/flow:work:run` on `start` takes the base the orchestrator left** when `git fetch origin <base>`
+  fails, as `/flow:feat:build` already did. A container is given no git credentials, so that fetch
+  could never succeed there, and every handed-off study stopped as `blocked` before building.
+- Nothing changes on a laptop or outside `unattended`: the fetch still runs first, and a fetch that
+  works still decides the base.
+
+The catch-up of a study's branch with its base fetched `origin/<base>` and treated a failed fetch as
+`blocked`, to avoid building on a stale ref. Under an orchestrator that ref is not stale: the
+contract has it leave `origin/<base>` where the forge had it when the run was launched, and gives the
+container no credentials to fetch with. The fetch is now best-effort; `origin/<base>` is used when it
+resolves, the local `<base>` otherwise, and the run is `blocked` only when neither does.
+
 ## v0.94.0 — A repo commits the FLOW config for where flow runs, and whoever launches flow picks it  ·  2026-10-14
 
 **In short**