flow-workflows 0.85.0 → 0.85.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.85.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.85.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
@@ -258,7 +258,8 @@ assumed:
   recommended one first), title, body, reason and summary are written into the work folder
   (`ask-question.md`, `ask-options.md`, `publish-title.md`, `publish-body.md`, `blocked-reason.md`,
   `done-summary.md`) — or a `mktemp -d` directory before the folder exists — and passed by path. A
-  backtick or a quote in a ticket title must never meet a shell.
+  backtick or a quote in a ticket title must never meet a shell. `publish-title.md` holds **one
+  line**, the title alone — no `#`, no second line: the orchestrator refuses a title file with two.
 - **The orchestrator pushes and opens the MR/PR; the run never does.** No `git push`, no `gh`, no
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it

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

@@ -31,7 +31,7 @@ it hands the finished MR/PR to the orchestrator, which pushes the branch and ope
 place it would ask:
 
 - **The MR/PR itself (§3–§4)** — no confirmation and no forge. §2's title and description are
-  written to `publish-title.md` and `publish-body.md` in the work folder; the body gains one line
+  written to `publish-title.md` (one line, the title alone) and `publish-body.md` in the work folder; the body gains one line
   saying an unattended run prepared it and nobody confirmed its brief. §4.0's branch check still
   runs (never the base; the name starts with `<ticket>-`) — and an upstream on the base is unset
   (`git branch --unset-upstream`), with no push after it. §4.1–§4.3 do not: no push, no

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

@@ -38,7 +38,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 - Run `<cmd> why`. It fails, or prints anything but `start`, `answer`, `review`, `pipeline` or
   `merged` → 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 → `feat`).
+- 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 `start` uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
 - Find the work: the `meta.json` under `.claude/work/` whose `ticket` equals `number` (archive
   excluded). None is not an error — it is the "none" of the table below.

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.85.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.85.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
@@ -257,7 +257,8 @@ assumed:
   recommended one first), title, body, reason and summary are written into the work folder
   (`ask-question.md`, `ask-options.md`, `publish-title.md`, `publish-body.md`, `blocked-reason.md`,
   `done-summary.md`) — or a `mktemp -d` directory before the folder exists — and passed by path. A
-  backtick or a quote in a ticket title must never meet a shell.
+  backtick or a quote in a ticket title must never meet a shell. `publish-title.md` holds **one
+  line**, the title alone — no `#`, no second line: the orchestrator refuses a title file with two.
 - **The orchestrator pushes and opens the MR/PR; the run never does.** No `git push`, no `gh`, no
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it

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

@@ -27,7 +27,7 @@ it hands the finished MR/PR to the orchestrator, which pushes the branch and ope
 place it would ask:
 
 - **The MR/PR itself (§3–§4)** — no confirmation and no forge. §2's title and description are
-  written to `publish-title.md` and `publish-body.md` in the work folder; the body gains one line
+  written to `publish-title.md` (one line, the title alone) and `publish-body.md` in the work folder; the body gains one line
   saying an unattended run prepared it and nobody confirmed its brief. §4.0's branch check still
   runs (never the base; the name starts with `<ticket>-`) — and an upstream on the base is unset
   (`git branch --unset-upstream`), with no push after it. §4.1–§4.3 do not: no push, no

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

@@ -34,7 +34,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 - Run `<cmd> why`. It fails, or prints anything but `start`, `answer`, `review`, `pipeline` or
   `merged` → 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 → `feat`).
+- 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 `start` uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
 - Find the work: the `meta.json` under `.claude/work/` whose `ticket` equals `number` (archive
   excluded). None is not an error — it is the "none" of the table below.

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.85.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.85.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
@@ -258,7 +258,8 @@ assumed:
   recommended one first), title, body, reason and summary are written into the work folder
   (`ask-question.md`, `ask-options.md`, `publish-title.md`, `publish-body.md`, `blocked-reason.md`,
   `done-summary.md`) — or a `mktemp -d` directory before the folder exists — and passed by path. A
-  backtick or a quote in a ticket title must never meet a shell.
+  backtick or a quote in a ticket title must never meet a shell. `publish-title.md` holds **one
+  line**, the title alone — no `#`, no second line: the orchestrator refuses a title file with two.
 - **The orchestrator pushes and opens the MR/PR; the run never does.** No `git push`, no `gh`, no
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it

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

@@ -31,7 +31,7 @@ it hands the finished MR/PR to the orchestrator, which pushes the branch and ope
 place it would ask:
 
 - **The MR/PR itself (§3–§4)** — no confirmation and no forge. §2's title and description are
-  written to `publish-title.md` and `publish-body.md` in the work folder; the body gains one line
+  written to `publish-title.md` (one line, the title alone) and `publish-body.md` in the work folder; the body gains one line
   saying an unattended run prepared it and nobody confirmed its brief. §4.0's branch check still
   runs (never the base; the name starts with `<ticket>-`) — and an upstream on the base is unset
   (`git branch --unset-upstream`), with no push after it. §4.1–§4.3 do not: no push, no

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

@@ -38,7 +38,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 - Run `<cmd> why`. It fails, or prints anything but `start`, `answer`, `review`, `pipeline` or
   `merged` → 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 → `feat`).
+- 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 `start` uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
 - Find the work: the `meta.json` under `.claude/work/` whose `ticket` equals `number` (archive
   excluded). None is not an error — it is the "none" of the table below.

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.85.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.85.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
@@ -257,7 +257,8 @@ assumed:
   recommended one first), title, body, reason and summary are written into the work folder
   (`ask-question.md`, `ask-options.md`, `publish-title.md`, `publish-body.md`, `blocked-reason.md`,
   `done-summary.md`) — or a `mktemp -d` directory before the folder exists — and passed by path. A
-  backtick or a quote in a ticket title must never meet a shell.
+  backtick or a quote in a ticket title must never meet a shell. `publish-title.md` holds **one
+  line**, the title alone — no `#`, no second line: the orchestrator refuses a title file with two.
 - **The orchestrator pushes and opens the MR/PR; the run never does.** No `git push`, no `gh`, no
   `glab`, no tracker write in this mode — not before `ship`, not in it. The orchestrator also keeps,
   between runs, the work folder as the run left it and the work branch at the commit where it

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

@@ -29,7 +29,7 @@ it hands the finished MR/PR to the orchestrator, which pushes the branch and ope
 place it would ask:
 
 - **The MR/PR itself (§3–§4)** — no confirmation and no forge. §2's title and description are
-  written to `publish-title.md` and `publish-body.md` in the work folder; the body gains one line
+  written to `publish-title.md` (one line, the title alone) and `publish-body.md` in the work folder; the body gains one line
   saying an unattended run prepared it and nobody confirmed its brief. §4.0's branch check still
   runs (never the base; the name starts with `<ticket>-`) — and an upstream on the base is unset
   (`git branch --unset-upstream`), with no push after it. §4.1–§4.3 do not: no push, no

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

@@ -36,7 +36,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 - Run `<cmd> why`. It fails, or prints anything but `start`, `answer`, `review`, `pipeline` or
   `merged` → 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 → `feat`).
+- 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 `start` uses it — once the work exists, its folder says feat or bug.
   It fails or prints no `number` → `blocked` (flow-core §2.1).
 - Find the work: the `meta.json` under `.claude/work/` whose `ticket` equals `number` (archive
   excluded). None is not an error — it is the "none" of the table below.

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,15 @@ 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.85.1 — An unattended run reads the orchestrator's answers as agent-runner sends them  ·  2026-10-01
+
+**In short**
+- **A ticket whose tracker cannot tell feat from bug starts as a feature.** agent-runner sends
+  `kind: null` in that case; `/flow:work:run` now reads it the same as a missing `kind`.
+- **The PR title goes to the orchestrator as one line.** agent-runner refuses a title file with two
+  lines; flow now says so where the run writes it.
+- Nothing changes in `manual`, `guided` or `auto`. Follows #177.
+
 ## v0.85.0 — An unattended run answers its reviewers and fixes its own pipeline  ·  2026-10-01
 
 **In short**