flow-workflows 0.90.0 → 0.91.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.90.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.91.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
@@ -244,11 +244,12 @@ configuration; these orders are the whole interface, and nothing else about the
 assumed:
 
 ```
-<cmd> why                                   → start | study | answer | review | pipeline | merged
+<cmd> why                                   → start | study | answer | review | pipeline | merged | conflict
 <cmd> ticket --json                         → {number, title, body, comments[{author, at, text}], base, kind}
 <cmd> answer                                → one option's exact text, or free text; exit 2 = no reply
 <cmd> events --json                         → {"comments":[{thread,kind,id,author,at,body,url,path?,line?}]}
                                                | {"sha":…, "failed":[{name,conclusion,url,log_tail}]}
+                                               | {"conflict":{"base":…, "base_sha":…}}
 <cmd> ask --question-file F --options-file F [--recommended N] [--free-text] [--gate NAME]
 <cmd> publish --title-file F --body-file F [--part N --of M]
 <cmd> blocked --reason-file F
@@ -308,7 +309,7 @@ run has.
 runs the study phases as any run does, and three rules make it stop where it should:
 
 - **The door to code.** The first step of `$flow-feat-build` and `$flow-bug-fix` pre-flight, in
-  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review` or `pipeline` → go on;
+  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review`, `pipeline` or `conflict` → go on;
   `study` → the study ends here; anything else, or the order failing → `blocked`. Every path from a
   study to code crosses that door, an answered question that resumes straight into `build`
   included, so the phases before it carry no clause. The run kind is read there, never stored: the
@@ -351,6 +352,7 @@ person asking for changes, a ticket that already has code — is `$flow-work-run
 | The next MR/PR of a train (`ship` close) | record — not started: one MR/PR per unattended run |
 | `build` with no startable MR/PR (its `depends_on` not `merged` in `meta.json`) | blocked — the reason names what must merge; an unattended `build` never stacks a branch on another, and never creates a remote branch |
 | The parent of a stacked MR/PR merged — rebase and force-push | blocked — never force-push unattended |
+| Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`$flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |

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

@@ -45,19 +45,34 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 4. **Integrating the base branch** — any `git merge`/`git rebase` of `git.default_base` into the branch, and any history rewrite or force-push it implies (§5.C).
 5. **Green-washing — NEVER, in any mode:** no rerun of a failed check hoping it passes; never disable, skip, `@skip`/`xit`, loosen a threshold, or delete a test/lint rule to force green; never resolve a conflict by blindly taking one side (`--ours`/`--theirs`, `checkout --theirs`, discarding the base's changes) — resolve by understanding both sides.
 
-**In `unattended`** (flow-core §2.1) — launched by `$flow-work-run` on `why = pipeline` — this
-command asks nothing and never touches the forge. Gate 5 holds exactly as written; the others
-resolve this way:
+**In `unattended`** (flow-core §2.1) — launched by `$flow-work-run` on `why = pipeline` or
+`why = conflict` — this command never touches the forge. Gate 5 holds exactly as written; the
+others resolve this way:
 
 - **§1–§2** — no MR/PR is resolved and no forge is read: the failures are `<cmd> events --json` →
   `{"sha", "failed": [{name, conclusion, url, log_tail}]}`, and `log_tail` is the evidence. The order
   failing → `blocked`; `failed` empty → `done`, the summary saying so. `sha` not `HEAD` → `blocked`:
   the result is about another commit, and fixing it here would be fixing a guess.
+  On `why = conflict` the events are `{"conflict": {"base", "base_sha"}}` instead: the MR/PR
+  conflicts with `base`, which the orchestrator left in the checkout as `origin/<base>` at
+  `base_sha`. That is the only blocker of the round — category C, nothing to triage. `origin/<base>`
+  missing or not at `base_sha` → `blocked`: the run would merge a base nobody named.
 - **§3** — triage as written, recorded in `09-ci.md`. **K** (flaky / infra) → `blocked` with the
   evidence: the run has no rerun order, and the orchestrator owns reruns and the red-round limit.
-  **C** (conflict, behind base) and anything needing a rebase or force-push → `blocked`: the
-  orchestrator brings the base in. A **human** blocker → `blocked`, naming who. **S** → fixed within
+  **C** (conflict, behind base) on `why = pipeline`, and anything needing a rebase or force-push →
+  `blocked`: the orchestrator brings the base in, and relaunches with `why = conflict` when it
+  conflicts. A **human** blocker → `blocked`, naming who. **S** → fixed within
   scope, otherwise `blocked` with the justification.
+- **§5.C on `why = conflict`** — gate 4 is recorded (`unattended:integrate-base`), never asked:
+  the orchestrator launched the run for exactly this. No fetch: the base is `origin/<base>` as the
+  orchestrator left it, never `git.default_base` read from the config. Always `git merge
+  origin/<base>`, never a rebase. Each conflict is resolved on its merits as step 3 says; step 6's
+  "intent of either side unclear" → `git merge --abort`, then question `decision` when the two
+  sides want things that contradict each other (a product decision: which intent wins), `blocked`
+  otherwise. The base it merges goes into this round of `09-ci.md` before the merge starts; the
+  answer re-enters at §5.C, reads the base there, and merges again from `origin/<base>` — an
+  unfinished merge does not survive the run. Step 4's design change that is more than a tweak →
+  `blocked`. The merge commit, after the full local gate, is the round's commit.
 - **§5** — fixes and the local verification as written; a local gate it cannot get green →
   `blocked`. A fix adding behaviour gets its brief recorded, not asked; a fix that needs a schema
   change, a design invalidation that is more than a tweak, or a high-severity finding from the

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

@@ -36,7 +36,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
   other mode a person is the router (`$flow-next`).
 - `autonomy.orchestrator_cmd` empty → flow-core §2.1: no phase runs.
 - Run `<cmd> why`. It fails, or prints anything but `start`, `study`, `answer`, `review`,
-  `pipeline` or `merged` → print what it returned and its stderr in the §3 header and end. No closing order: an
+  `pipeline`, `merged` or `conflict` → print what it returned and its stderr in the §3 header and end. No closing order: an
   orchestrator that cannot say why it launched the run cannot take one either.
 - Run `<cmd> ticket --json` and keep `number`, `title`, `base` and `kind` (`kind` absent or `null` → `feat`: the tracker could not tell, so flow decides). `kind` is re-read on every run; only a run that starts the work uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
@@ -64,7 +64,8 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `$flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `$flow-work-green` — the failed jobs come from `<cmd> events --json` |
-| `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
+| `conflict` | exists | `$flow-work-green` — the MR/PR conflicts with its base; which base, and where it stands, come from `<cmd> events --json` |
+| `review` · `pipeline` · `conflict` | none | `blocked` — there is no work of this ticket to answer for |
 
 **The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → nothing to do. It is
 not — a study made on another machine arrives on the ticket's `base`, a run that died before its

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.90.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.91.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
@@ -243,11 +243,12 @@ configuration; these orders are the whole interface, and nothing else about the
 assumed:
 
 ```
-<cmd> why                                   → start | study | answer | review | pipeline | merged
+<cmd> why                                   → start | study | answer | review | pipeline | merged | conflict
 <cmd> ticket --json                         → {number, title, body, comments[{author, at, text}], base, kind}
 <cmd> answer                                → one option's exact text, or free text; exit 2 = no reply
 <cmd> events --json                         → {"comments":[{thread,kind,id,author,at,body,url,path?,line?}]}
                                                | {"sha":…, "failed":[{name,conclusion,url,log_tail}]}
+                                               | {"conflict":{"base":…, "base_sha":…}}
 <cmd> ask --question-file F --options-file F [--recommended N] [--free-text] [--gate NAME]
 <cmd> publish --title-file F --body-file F [--part N --of M]
 <cmd> blocked --reason-file F
@@ -307,7 +308,7 @@ run has.
 runs the study phases as any run does, and three rules make it stop where it should:
 
 - **The door to code.** The first step of `/flow:feat:build` and `/flow:bug:fix` pre-flight, in
-  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review` or `pipeline` → go on;
+  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review`, `pipeline` or `conflict` → go on;
   `study` → the study ends here; anything else, or the order failing → `blocked`. Every path from a
   study to code crosses that door, an answered question that resumes straight into `build`
   included, so the phases before it carry no clause. The run kind is read there, never stored: the
@@ -350,6 +351,7 @@ person asking for changes, a ticket that already has code — is `/flow:work:run
 | The next MR/PR of a train (`ship` close) | record — not started: one MR/PR per unattended run |
 | `build` with no startable MR/PR (its `depends_on` not `merged` in `meta.json`) | blocked — the reason names what must merge; an unattended `build` never stacks a branch on another, and never creates a remote branch |
 | The parent of a stacked MR/PR merged — rebase and force-push | blocked — never force-push unattended |
+| Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow:work:green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |

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

@@ -41,19 +41,34 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 4. **Integrating the base branch** — any `git merge`/`git rebase` of `git.default_base` into the branch, and any history rewrite or force-push it implies (§5.C).
 5. **Green-washing — NEVER, in any mode:** no rerun of a failed check hoping it passes; never disable, skip, `@skip`/`xit`, loosen a threshold, or delete a test/lint rule to force green; never resolve a conflict by blindly taking one side (`--ours`/`--theirs`, `checkout --theirs`, discarding the base's changes) — resolve by understanding both sides.
 
-**In `unattended`** (flow-core §2.1) — launched by `/flow:work:run` on `why = pipeline` — this
-command asks nothing and never touches the forge. Gate 5 holds exactly as written; the others
-resolve this way:
+**In `unattended`** (flow-core §2.1) — launched by `/flow:work:run` on `why = pipeline` or
+`why = conflict` — this command never touches the forge. Gate 5 holds exactly as written; the
+others resolve this way:
 
 - **§1–§2** — no MR/PR is resolved and no forge is read: the failures are `<cmd> events --json` →
   `{"sha", "failed": [{name, conclusion, url, log_tail}]}`, and `log_tail` is the evidence. The order
   failing → `blocked`; `failed` empty → `done`, the summary saying so. `sha` not `HEAD` → `blocked`:
   the result is about another commit, and fixing it here would be fixing a guess.
+  On `why = conflict` the events are `{"conflict": {"base", "base_sha"}}` instead: the MR/PR
+  conflicts with `base`, which the orchestrator left in the checkout as `origin/<base>` at
+  `base_sha`. That is the only blocker of the round — category C, nothing to triage. `origin/<base>`
+  missing or not at `base_sha` → `blocked`: the run would merge a base nobody named.
 - **§3** — triage as written, recorded in `09-ci.md`. **K** (flaky / infra) → `blocked` with the
   evidence: the run has no rerun order, and the orchestrator owns reruns and the red-round limit.
-  **C** (conflict, behind base) and anything needing a rebase or force-push → `blocked`: the
-  orchestrator brings the base in. A **human** blocker → `blocked`, naming who. **S** → fixed within
+  **C** (conflict, behind base) on `why = pipeline`, and anything needing a rebase or force-push →
+  `blocked`: the orchestrator brings the base in, and relaunches with `why = conflict` when it
+  conflicts. A **human** blocker → `blocked`, naming who. **S** → fixed within
   scope, otherwise `blocked` with the justification.
+- **§5.C on `why = conflict`** — gate 4 is recorded (`unattended:integrate-base`), never asked:
+  the orchestrator launched the run for exactly this. No fetch: the base is `origin/<base>` as the
+  orchestrator left it, never `git.default_base` read from the config. Always `git merge
+  origin/<base>`, never a rebase. Each conflict is resolved on its merits as step 3 says; step 6's
+  "intent of either side unclear" → `git merge --abort`, then question `decision` when the two
+  sides want things that contradict each other (a product decision: which intent wins), `blocked`
+  otherwise. The base it merges goes into this round of `09-ci.md` before the merge starts; the
+  answer re-enters at §5.C, reads the base there, and merges again from `origin/<base>` — an
+  unfinished merge does not survive the run. Step 4's design change that is more than a tweak →
+  `blocked`. The merge commit, after the full local gate, is the round's commit.
 - **§5** — fixes and the local verification as written; a local gate it cannot get green →
   `blocked`. A fix adding behaviour gets its brief recorded, not asked; a fix that needs a schema
   change, a design invalidation that is more than a tweak, or a high-severity finding from the

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

@@ -32,7 +32,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
   other mode a person is the router (`/flow:next`).
 - `autonomy.orchestrator_cmd` empty → flow-core §2.1: no phase runs.
 - Run `<cmd> why`. It fails, or prints anything but `start`, `study`, `answer`, `review`,
-  `pipeline` or `merged` → print what it returned and its stderr in the §3 header and end. No closing order: an
+  `pipeline`, `merged` or `conflict` → print what it returned and its stderr in the §3 header and end. No closing order: an
   orchestrator that cannot say why it launched the run cannot take one either.
 - Run `<cmd> ticket --json` and keep `number`, `title`, `base` and `kind` (`kind` absent or `null` → `feat`: the tracker could not tell, so flow decides). `kind` is re-read on every run; only a run that starts the work uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
@@ -60,7 +60,8 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow:work:respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow:work:green` — the failed jobs come from `<cmd> events --json` |
-| `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
+| `conflict` | exists | `/flow:work:green` — the MR/PR conflicts with its base; which base, and where it stands, come from `<cmd> events --json` |
+| `review` · `pipeline` · `conflict` | none | `blocked` — there is no work of this ticket to answer for |
 
 **The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → nothing to do. It is
 not — a study made on another machine arrives on the ticket's `base`, a run that died before its

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.90.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.91.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
@@ -244,11 +244,12 @@ configuration; these orders are the whole interface, and nothing else about the
 assumed:
 
 ```
-<cmd> why                                   → start | study | answer | review | pipeline | merged
+<cmd> why                                   → start | study | answer | review | pipeline | merged | conflict
 <cmd> ticket --json                         → {number, title, body, comments[{author, at, text}], base, kind}
 <cmd> answer                                → one option's exact text, or free text; exit 2 = no reply
 <cmd> events --json                         → {"comments":[{thread,kind,id,author,at,body,url,path?,line?}]}
                                                | {"sha":…, "failed":[{name,conclusion,url,log_tail}]}
+                                               | {"conflict":{"base":…, "base_sha":…}}
 <cmd> ask --question-file F --options-file F [--recommended N] [--free-text] [--gate NAME]
 <cmd> publish --title-file F --body-file F [--part N --of M]
 <cmd> blocked --reason-file F
@@ -308,7 +309,7 @@ run has.
 runs the study phases as any run does, and three rules make it stop where it should:
 
 - **The door to code.** The first step of `/flow-feat-build` and `/flow-bug-fix` pre-flight, in
-  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review` or `pipeline` → go on;
+  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review`, `pipeline` or `conflict` → go on;
   `study` → the study ends here; anything else, or the order failing → `blocked`. Every path from a
   study to code crosses that door, an answered question that resumes straight into `build`
   included, so the phases before it carry no clause. The run kind is read there, never stored: the
@@ -351,6 +352,7 @@ person asking for changes, a ticket that already has code — is `/flow-work-run
 | The next MR/PR of a train (`ship` close) | record — not started: one MR/PR per unattended run |
 | `build` with no startable MR/PR (its `depends_on` not `merged` in `meta.json`) | blocked — the reason names what must merge; an unattended `build` never stacks a branch on another, and never creates a remote branch |
 | The parent of a stacked MR/PR merged — rebase and force-push | blocked — never force-push unattended |
+| Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |

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

@@ -45,19 +45,34 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 4. **Integrating the base branch** — any `git merge`/`git rebase` of `git.default_base` into the branch, and any history rewrite or force-push it implies (§5.C).
 5. **Green-washing — NEVER, in any mode:** no rerun of a failed check hoping it passes; never disable, skip, `@skip`/`xit`, loosen a threshold, or delete a test/lint rule to force green; never resolve a conflict by blindly taking one side (`--ours`/`--theirs`, `checkout --theirs`, discarding the base's changes) — resolve by understanding both sides.
 
-**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = pipeline` — this
-command asks nothing and never touches the forge. Gate 5 holds exactly as written; the others
-resolve this way:
+**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = pipeline` or
+`why = conflict` — this command never touches the forge. Gate 5 holds exactly as written; the
+others resolve this way:
 
 - **§1–§2** — no MR/PR is resolved and no forge is read: the failures are `<cmd> events --json` →
   `{"sha", "failed": [{name, conclusion, url, log_tail}]}`, and `log_tail` is the evidence. The order
   failing → `blocked`; `failed` empty → `done`, the summary saying so. `sha` not `HEAD` → `blocked`:
   the result is about another commit, and fixing it here would be fixing a guess.
+  On `why = conflict` the events are `{"conflict": {"base", "base_sha"}}` instead: the MR/PR
+  conflicts with `base`, which the orchestrator left in the checkout as `origin/<base>` at
+  `base_sha`. That is the only blocker of the round — category C, nothing to triage. `origin/<base>`
+  missing or not at `base_sha` → `blocked`: the run would merge a base nobody named.
 - **§3** — triage as written, recorded in `09-ci.md`. **K** (flaky / infra) → `blocked` with the
   evidence: the run has no rerun order, and the orchestrator owns reruns and the red-round limit.
-  **C** (conflict, behind base) and anything needing a rebase or force-push → `blocked`: the
-  orchestrator brings the base in. A **human** blocker → `blocked`, naming who. **S** → fixed within
+  **C** (conflict, behind base) on `why = pipeline`, and anything needing a rebase or force-push →
+  `blocked`: the orchestrator brings the base in, and relaunches with `why = conflict` when it
+  conflicts. A **human** blocker → `blocked`, naming who. **S** → fixed within
   scope, otherwise `blocked` with the justification.
+- **§5.C on `why = conflict`** — gate 4 is recorded (`unattended:integrate-base`), never asked:
+  the orchestrator launched the run for exactly this. No fetch: the base is `origin/<base>` as the
+  orchestrator left it, never `git.default_base` read from the config. Always `git merge
+  origin/<base>`, never a rebase. Each conflict is resolved on its merits as step 3 says; step 6's
+  "intent of either side unclear" → `git merge --abort`, then question `decision` when the two
+  sides want things that contradict each other (a product decision: which intent wins), `blocked`
+  otherwise. The base it merges goes into this round of `09-ci.md` before the merge starts; the
+  answer re-enters at §5.C, reads the base there, and merges again from `origin/<base>` — an
+  unfinished merge does not survive the run. Step 4's design change that is more than a tweak →
+  `blocked`. The merge commit, after the full local gate, is the round's commit.
 - **§5** — fixes and the local verification as written; a local gate it cannot get green →
   `blocked`. A fix adding behaviour gets its brief recorded, not asked; a fix that needs a schema
   change, a design invalidation that is more than a tweak, or a high-severity finding from the

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

@@ -36,7 +36,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
   other mode a person is the router (`/flow-next`).
 - `autonomy.orchestrator_cmd` empty → flow-core §2.1: no phase runs.
 - Run `<cmd> why`. It fails, or prints anything but `start`, `study`, `answer`, `review`,
-  `pipeline` or `merged` → print what it returned and its stderr in the §3 header and end. No closing order: an
+  `pipeline`, `merged` or `conflict` → print what it returned and its stderr in the §3 header and end. No closing order: an
   orchestrator that cannot say why it launched the run cannot take one either.
 - Run `<cmd> ticket --json` and keep `number`, `title`, `base` and `kind` (`kind` absent or `null` → `feat`: the tracker could not tell, so flow decides). `kind` is re-read on every run; only a run that starts the work uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
@@ -64,7 +64,8 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow-work-green` — the failed jobs come from `<cmd> events --json` |
-| `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
+| `conflict` | exists | `/flow-work-green` — the MR/PR conflicts with its base; which base, and where it stands, come from `<cmd> events --json` |
+| `review` · `pipeline` · `conflict` | none | `blocked` — there is no work of this ticket to answer for |
 
 **The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → nothing to do. It is
 not — a study made on another machine arrives on the ticket's `base`, a run that died before its

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.90.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.91.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
@@ -243,11 +243,12 @@ configuration; these orders are the whole interface, and nothing else about the
 assumed:
 
 ```
-<cmd> why                                   → start | study | answer | review | pipeline | merged
+<cmd> why                                   → start | study | answer | review | pipeline | merged | conflict
 <cmd> ticket --json                         → {number, title, body, comments[{author, at, text}], base, kind}
 <cmd> answer                                → one option's exact text, or free text; exit 2 = no reply
 <cmd> events --json                         → {"comments":[{thread,kind,id,author,at,body,url,path?,line?}]}
                                                | {"sha":…, "failed":[{name,conclusion,url,log_tail}]}
+                                               | {"conflict":{"base":…, "base_sha":…}}
 <cmd> ask --question-file F --options-file F [--recommended N] [--free-text] [--gate NAME]
 <cmd> publish --title-file F --body-file F [--part N --of M]
 <cmd> blocked --reason-file F
@@ -307,7 +308,7 @@ run has.
 runs the study phases as any run does, and three rules make it stop where it should:
 
 - **The door to code.** The first step of `/flow-feat-build` and `/flow-bug-fix` pre-flight, in
-  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review` or `pipeline` → go on;
+  `unattended`, re-reads `<cmd> why`: `start`, `answer`, `merged`, `review`, `pipeline` or `conflict` → go on;
   `study` → the study ends here; anything else, or the order failing → `blocked`. Every path from a
   study to code crosses that door, an answered question that resumes straight into `build`
   included, so the phases before it carry no clause. The run kind is read there, never stored: the
@@ -350,6 +351,7 @@ person asking for changes, a ticket that already has code — is `/flow-work-run
 | The next MR/PR of a train (`ship` close) | record — not started: one MR/PR per unattended run |
 | `build` with no startable MR/PR (its `depends_on` not `merged` in `meta.json`) | blocked — the reason names what must merge; an unattended `build` never stacks a branch on another, and never creates a remote branch |
 | The parent of a stacked MR/PR merged — rebase and force-push | blocked — never force-push unattended |
+| Integrating the base into the MR/PR's branch (`green`) | on `why = conflict`, record — `git merge origin/<base>` as the orchestrator left it, never rebase, each conflict resolved on its merits (`/flow-work-green` §5.C); on any other `why`, blocked — the orchestrator brings the base in |
 | Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
 | A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
 | Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |

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

@@ -43,19 +43,34 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 4. **Integrating the base branch** — any `git merge`/`git rebase` of `git.default_base` into the branch, and any history rewrite or force-push it implies (§5.C).
 5. **Green-washing — NEVER, in any mode:** no rerun of a failed check hoping it passes; never disable, skip, `@skip`/`xit`, loosen a threshold, or delete a test/lint rule to force green; never resolve a conflict by blindly taking one side (`--ours`/`--theirs`, `checkout --theirs`, discarding the base's changes) — resolve by understanding both sides.
 
-**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = pipeline` — this
-command asks nothing and never touches the forge. Gate 5 holds exactly as written; the others
-resolve this way:
+**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = pipeline` or
+`why = conflict` — this command never touches the forge. Gate 5 holds exactly as written; the
+others resolve this way:
 
 - **§1–§2** — no MR/PR is resolved and no forge is read: the failures are `<cmd> events --json` →
   `{"sha", "failed": [{name, conclusion, url, log_tail}]}`, and `log_tail` is the evidence. The order
   failing → `blocked`; `failed` empty → `done`, the summary saying so. `sha` not `HEAD` → `blocked`:
   the result is about another commit, and fixing it here would be fixing a guess.
+  On `why = conflict` the events are `{"conflict": {"base", "base_sha"}}` instead: the MR/PR
+  conflicts with `base`, which the orchestrator left in the checkout as `origin/<base>` at
+  `base_sha`. That is the only blocker of the round — category C, nothing to triage. `origin/<base>`
+  missing or not at `base_sha` → `blocked`: the run would merge a base nobody named.
 - **§3** — triage as written, recorded in `09-ci.md`. **K** (flaky / infra) → `blocked` with the
   evidence: the run has no rerun order, and the orchestrator owns reruns and the red-round limit.
-  **C** (conflict, behind base) and anything needing a rebase or force-push → `blocked`: the
-  orchestrator brings the base in. A **human** blocker → `blocked`, naming who. **S** → fixed within
+  **C** (conflict, behind base) on `why = pipeline`, and anything needing a rebase or force-push →
+  `blocked`: the orchestrator brings the base in, and relaunches with `why = conflict` when it
+  conflicts. A **human** blocker → `blocked`, naming who. **S** → fixed within
   scope, otherwise `blocked` with the justification.
+- **§5.C on `why = conflict`** — gate 4 is recorded (`unattended:integrate-base`), never asked:
+  the orchestrator launched the run for exactly this. No fetch: the base is `origin/<base>` as the
+  orchestrator left it, never `git.default_base` read from the config. Always `git merge
+  origin/<base>`, never a rebase. Each conflict is resolved on its merits as step 3 says; step 6's
+  "intent of either side unclear" → `git merge --abort`, then question `decision` when the two
+  sides want things that contradict each other (a product decision: which intent wins), `blocked`
+  otherwise. The base it merges goes into this round of `09-ci.md` before the merge starts; the
+  answer re-enters at §5.C, reads the base there, and merges again from `origin/<base>` — an
+  unfinished merge does not survive the run. Step 4's design change that is more than a tweak →
+  `blocked`. The merge commit, after the full local gate, is the round's commit.
 - **§5** — fixes and the local verification as written; a local gate it cannot get green →
   `blocked`. A fix adding behaviour gets its brief recorded, not asked; a fix that needs a schema
   change, a design invalidation that is more than a tweak, or a high-severity finding from the

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

@@ -34,7 +34,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
   other mode a person is the router (`/flow-next`).
 - `autonomy.orchestrator_cmd` empty → flow-core §2.1: no phase runs.
 - Run `<cmd> why`. It fails, or prints anything but `start`, `study`, `answer`, `review`,
-  `pipeline` or `merged` → print what it returned and its stderr in the §3 header and end. No closing order: an
+  `pipeline`, `merged` or `conflict` → print what it returned and its stderr in the §3 header and end. No closing order: an
   orchestrator that cannot say why it launched the run cannot take one either.
 - Run `<cmd> ticket --json` and keep `number`, `title`, `base` and `kind` (`kind` absent or `null` → `feat`: the tracker could not tell, so flow decides). `kind` is re-read on every run; only a run that starts the work uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
@@ -62,7 +62,8 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
 | `review` | exists | `/flow-work-respond` — the threads come from `<cmd> events --json` |
 | `pipeline` | exists | `/flow-work-green` — the failed jobs come from `<cmd> events --json` |
-| `review` · `pipeline` | none | `blocked` — there is no work of this ticket to answer for |
+| `conflict` | exists | `/flow-work-green` — the MR/PR conflicts with its base; which base, and where it stands, come from `<cmd> events --json` |
+| `review` · `pipeline` · `conflict` | none | `blocked` — there is no work of this ticket to answer for |
 
 **The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → nothing to do. It is
 not — a study made on another machine arrives on the ticket's `base`, a run that died before its

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,22 @@ 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.91.0 — An unattended run resolves the conflicts with its base when the orchestrator launches it for them  ·  2026-10-11
+
+**In short**
+- **A new `why`: `conflict`.** An orchestrator that sees the run's open MR/PR conflict with its base
+  launches it with `why = conflict`; `/flow:work:run` sends it to `/flow:work:green`. Before, an
+  unattended `green` turned any conflict into `blocked` and the draft waited for a person.
+- **`<cmd> events --json`** on such a run is `{"conflict": {"base", "base_sha"}}`, and the base is in
+  the checkout as `origin/<base>` at that commit — the orchestrator brings it in, the run never
+  fetches.
+- **`green` merges, never rebases**, and resolves each conflict on its merits, exactly as §5.C
+  already says (no `--ours`/`--theirs` wholesale, generated files regenerated, the full local gate
+  after), then publishes. Integrating the base is recorded, not asked: the run was launched for it.
+- **Two sides that want contradicting things are a product decision**: the merge is aborted and the
+  run asks (`decision`). The answer re-enters `green`, which merges again from `origin/<base>`.
+- On any other `why`, a conflict is still `blocked`.
+
 ## v0.90.0 — A query that changed reaches the MR with its plan, or with the admission that nobody measured it  ·  2026-10-07
 
 **In short**