flow-workflows 0.84.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.84.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
@@ -290,7 +291,7 @@ run has.
 |---|---|
 | Business brief before code (`build`, `fix`) | record — the brief is written to the phase artifact, marked `recorded (unattended)`, and travels in the MR/PR body |
 | Push and MR/PR creation (`ship`) | `publish` — the run commits on its own branch, writes title and body, and hands them over; the orchestrator pushes and opens the draft |
-| 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 |
+| 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 — except in `respond` and `green`, where it is blocked: a schema change agreed after the MR/PR exists goes back through `build` |
 | `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. **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` |
@@ -382,7 +383,7 @@ the next review would take *Fix them* again, with nothing left to fix.
 | `clarify` | `design` §1.5.5 / §9 | `design` | §1.5.5 — the choice and the size check / §9 | `03-design.md` "Decisions clarified while choosing the approach" / the criterion it clarifies | free text |
 | `design_challenge` | `design` §6 | `design` | §7 | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
 | `investigation_challenge` | `investigate` | `investigate` | the section after the challenge | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
-| `decision` | any phase | the same phase | the step that surfaced it | where that phase keeps its decisions (§7) | the options that were on the table · free text |
+| `decision` | any phase | the same phase — `work:respond` for a review round | the step that surfaced it — the end of §4 for a review round | where that phase keeps its decisions (§7) — this round's section of `08-feedback.md` for a review round | the options that were on the table · free text |
 | `migration` | `build` / `fix` | the same phase | the unticked plan step that writes it | "Decisions made during implementation" in `05-implementation.md` / `04-fix.md` | *Write it and continue* · *Change the design first* |
 | `migration` | `validate` (apply) | the same phase | its pre-flight — it re-runs whole, and its apply site takes the answer just applied | `meta.json.defaults_used[]` only — the artifact is written whole at the end, and names the answer beside the migration it applied (`07-validation.md` "Edge cases verified" / `05-validation.md`) | *Apply it* |
 | `migration` | `ship` (pre-deploy SQL) | the same phase | its pre-flight — the draft lives only in context; the site takes the answer just applied | `05-implementation.md` / `04-fix.md`, beside the SQL | *The SQL is complete — ship 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-README/SKILL.md

@@ -248,7 +248,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
   resume; otherwise status.
 - `$flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`$flow-feat-start`, `$flow-work-green`, `$flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `$flow-news`.
 - `$flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
-- `$flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
+- `$flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged · review · pipeline), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
 - `$flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `$flow-work-try <branch>` / `$flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `$flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

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

@@ -36,13 +36,38 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix); `unattended` resolves gates 1–4 as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Any push** (§6).
 2. Creating/switching a branch, or DB schema changes/migrations, if a fix requires them.
 3. **Re-triggering a pipeline or job on the remote** (CI resources; outward action).
 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:
+
+- **§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.
+- **§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
+  scope, otherwise `blocked` with the justification.
+- **§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
+  review gate the round cannot clear → `blocked` (flow-core §2.1). Commits as `auto`.
+- **§7 before the closing order** — logged as written; offers are `Later`; re-posting the
+  performance comment is not done — a changed number goes into `publish-body.md`.
+- **§6** — no push, no rerun, no watch. The closing order, after the WIP commit (flow-core §2.1): `publish` with the
+  work's `publish-title.md` / `publish-body.md` and the `--part/--of` `$flow-feat-ship` passed; the
+  orchestrator pushes and the pipeline runs again.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)

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

@@ -32,7 +32,9 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`. **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`; `unattended` resolves the gates as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Posting any comment/reply** to the MR/PR (§7).
 2. **Any push** (§6.2).
 3. Creating/switching a branch, or DB schema changes/migrations, when an agreed change requires them.
@@ -40,6 +42,47 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 Everything else: take the sensible default and record it; ask only when irreversible/costly, ambiguous and not settled by ticket + design + knowledge search, or a hard gate.
 
+**In `unattended`** (flow-core §2.1) — launched by `$flow-work-run` on `why = review` — this command
+asks nothing and never touches the forge: the threads come from the orchestrator, the replies go
+back through it, and the hard gates above resolve this way:
+
+- **§1** — no MR/PR is resolved: the work is the one `$flow-work-run` found, on the branch the
+  orchestrator checked out. A round over the ceiling → `blocked`, its reason being the (a)(b)(c)
+  hand-back of §1.
+- **§2** — the threads are `<cmd> events --json` → `comments[]`, grouped by `thread` (each comment:
+  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line` when it has them). The untrusted-input
+  rule stands unchanged. The machine-state check is skipped: the orchestrator relaunches for the
+  pipeline separately. The order failing → `blocked`; no comments → `done`, the summary saying so.
+- **§3–§4** — triage and stances as `auto` decides them, the table and the drafts written to
+  `08-feedback.md` instead of shown. A thread only a person can settle — a product decision, or a
+  `D` the recorded rationale and the code do not decide — goes into **one** question for all of them,
+  asked **before anything is replied or committed**: `ask --gate decision`, free text `T<n>: <answer>`
+  per thread, with `pending.phase: "respond"`, `pending.resume: "work:respond"` (never the work's
+  `meta.json.phase`) and `pending.resume_at: "end of §4"`, and the run ends there. The answer is
+  written into this round's section of `08-feedback.md`, and the relaunch re-enters at the end of
+  §4, reading the threads and stances from that file rather than from `events`. **At the end of §4
+  — on a first run and on that re-entry alike** — a reply that would repeat an earlier round's
+  (§8's repeated-answer rule) is caught before anything is posted → `blocked`, naming the thread.
+  `§4.G` measures as `$flow-work-query` does unattended (schema-only, never a database it creates).
+- **§5–§6** — a change adding behaviour gets its brief recorded (`recorded (unattended)`), not
+  asked. A design invalidation that is more than a tweak, or an agreed change that needs a schema
+  change → `blocked` (flow-core §2.1): the run does not redesign. Commits as `auto`. §6.1 runs
+  whole; a high-severity finding the round cannot clear → `blocked` with the findings. **§6.2 does
+  not run**: nothing is pushed — the orchestrator pushes on `publish`.
+- **§8 before §7** — §8 completes the round's section §3–§4 opened in `08-feedback.md` (never a
+  second one) and counts `respond_rounds`, before any reply and before any `blocked` from here on.
+  A `blocked` earlier than this point (the repeated answer, §6.1) also counts the round first. The agent-lessons offer is `Later`; re-posting the performance comment is not
+  done — a changed number goes into `publish-body.md` instead.
+- **§7** — one `<cmd> reply --thread <thread> --body-file <work>/reply-<thread>.md` per answered
+  thread, the reply naming the commit that changes the code. **Never resolve.** A `reply` that exits
+  ≠ 0 is recorded in `08-feedback.md` and the remaining replies still go out.
+- **The one closing order**, after the WIP commit (flow-core §2.1): code changed this round →
+  `publish` with the work's `publish-title.md` / `publish-body.md` (updated when the round changed
+  what they say, and naming any thread whose reply failed) and the `--part/--of` `$flow-feat-ship`
+  passed — the commits the replies name must reach the branch; no code changed and every reply went
+  out → `done`, the summary listing the threads answered; no code changed and a reply failed →
+  `blocked`, naming those threads.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)

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.
@@ -55,7 +55,9 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
 | `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `$flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
-| `review` · `pipeline` | any | `blocked` — not supported yet in `unattended`; the reason says so |
+| `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 |
 
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`

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.84.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
@@ -289,7 +290,7 @@ run has.
 |---|---|
 | Business brief before code (`build`, `fix`) | record — the brief is written to the phase artifact, marked `recorded (unattended)`, and travels in the MR/PR body |
 | Push and MR/PR creation (`ship`) | `publish` — the run commits on its own branch, writes title and body, and hands them over; the orchestrator pushes and opens the draft |
-| 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 |
+| 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 — except in `respond` and `green`, where it is blocked: a schema change agreed after the MR/PR exists goes back through `build` |
 | `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. **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` |
@@ -381,7 +382,7 @@ the next review would take *Fix them* again, with nothing left to fix.
 | `clarify` | `design` §1.5.5 / §9 | `design` | §1.5.5 — the choice and the size check / §9 | `03-design.md` "Decisions clarified while choosing the approach" / the criterion it clarifies | free text |
 | `design_challenge` | `design` §6 | `design` | §7 | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
 | `investigation_challenge` | `investigate` | `investigate` | the section after the challenge | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
-| `decision` | any phase | the same phase | the step that surfaced it | where that phase keeps its decisions (§7) | the options that were on the table · free text |
+| `decision` | any phase | the same phase — `work:respond` for a review round | the step that surfaced it — the end of §4 for a review round | where that phase keeps its decisions (§7) — this round's section of `08-feedback.md` for a review round | the options that were on the table · free text |
 | `migration` | `build` / `fix` | the same phase | the unticked plan step that writes it | "Decisions made during implementation" in `05-implementation.md` / `04-fix.md` | *Write it and continue* · *Change the design first* |
 | `migration` | `validate` (apply) | the same phase | its pre-flight — it re-runs whole, and its apply site takes the answer just applied | `meta.json.defaults_used[]` only — the artifact is written whole at the end, and names the answer beside the migration it applied (`07-validation.md` "Edge cases verified" / `05-validation.md`) | *Apply it* |
 | `migration` | `ship` (pre-deploy SQL) | the same phase | its pre-flight — the draft lives only in context; the site takes the answer just applied | `05-implementation.md` / `04-fix.md`, beside the SQL | *The SQL is complete — ship 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/README.toml

@@ -244,7 +244,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
   resume; otherwise status.
 - `/flow:work:daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow:feat:start`, `/flow:work:green`, `/flow:work:respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow:news`.
 - `/flow:work:status` — all works in `.claude/work/`, current phase, divergence with git.
-- `/flow:work:run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
+- `/flow:work:run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged · review · pipeline), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
 - `/flow:work:resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow:work:try <branch>` / `/flow:work:try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow:work:clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

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

@@ -32,13 +32,38 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix); `unattended` resolves gates 1–4 as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Any push** (§6).
 2. Creating/switching a branch, or DB schema changes/migrations, if a fix requires them.
 3. **Re-triggering a pipeline or job on the remote** (CI resources; outward action).
 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:
+
+- **§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.
+- **§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
+  scope, otherwise `blocked` with the justification.
+- **§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
+  review gate the round cannot clear → `blocked` (flow-core §2.1). Commits as `auto`.
+- **§7 before the closing order** — logged as written; offers are `Later`; re-posting the
+  performance comment is not done — a changed number goes into `publish-body.md`.
+- **§6** — no push, no rerun, no watch. The closing order, after the WIP commit (flow-core §2.1): `publish` with the
+  work's `publish-title.md` / `publish-body.md` and the `--part/--of` `/flow:feat:ship` passed; the
+  orchestrator pushes and the pipeline runs again.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)

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

@@ -28,7 +28,9 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`. **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`; `unattended` resolves the gates as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Posting any comment/reply** to the MR/PR (§7).
 2. **Any push** (§6.2).
 3. Creating/switching a branch, or DB schema changes/migrations, when an agreed change requires them.
@@ -36,6 +38,47 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 Everything else: take the sensible default and record it; ask only when irreversible/costly, ambiguous and not settled by ticket + design + knowledge search, or a hard gate.
 
+**In `unattended`** (flow-core §2.1) — launched by `/flow:work:run` on `why = review` — this command
+asks nothing and never touches the forge: the threads come from the orchestrator, the replies go
+back through it, and the hard gates above resolve this way:
+
+- **§1** — no MR/PR is resolved: the work is the one `/flow:work:run` found, on the branch the
+  orchestrator checked out. A round over the ceiling → `blocked`, its reason being the (a)(b)(c)
+  hand-back of §1.
+- **§2** — the threads are `<cmd> events --json` → `comments[]`, grouped by `thread` (each comment:
+  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line` when it has them). The untrusted-input
+  rule stands unchanged. The machine-state check is skipped: the orchestrator relaunches for the
+  pipeline separately. The order failing → `blocked`; no comments → `done`, the summary saying so.
+- **§3–§4** — triage and stances as `auto` decides them, the table and the drafts written to
+  `08-feedback.md` instead of shown. A thread only a person can settle — a product decision, or a
+  `D` the recorded rationale and the code do not decide — goes into **one** question for all of them,
+  asked **before anything is replied or committed**: `ask --gate decision`, free text `T<n>: <answer>`
+  per thread, with `pending.phase: "respond"`, `pending.resume: "work:respond"` (never the work's
+  `meta.json.phase`) and `pending.resume_at: "end of §4"`, and the run ends there. The answer is
+  written into this round's section of `08-feedback.md`, and the relaunch re-enters at the end of
+  §4, reading the threads and stances from that file rather than from `events`. **At the end of §4
+  — on a first run and on that re-entry alike** — a reply that would repeat an earlier round's
+  (§8's repeated-answer rule) is caught before anything is posted → `blocked`, naming the thread.
+  `§4.G` measures as `/flow:work:query` does unattended (schema-only, never a database it creates).
+- **§5–§6** — a change adding behaviour gets its brief recorded (`recorded (unattended)`), not
+  asked. A design invalidation that is more than a tweak, or an agreed change that needs a schema
+  change → `blocked` (flow-core §2.1): the run does not redesign. Commits as `auto`. §6.1 runs
+  whole; a high-severity finding the round cannot clear → `blocked` with the findings. **§6.2 does
+  not run**: nothing is pushed — the orchestrator pushes on `publish`.
+- **§8 before §7** — §8 completes the round's section §3–§4 opened in `08-feedback.md` (never a
+  second one) and counts `respond_rounds`, before any reply and before any `blocked` from here on.
+  A `blocked` earlier than this point (the repeated answer, §6.1) also counts the round first. The agent-lessons offer is `Later`; re-posting the performance comment is not
+  done — a changed number goes into `publish-body.md` instead.
+- **§7** — one `<cmd> reply --thread <thread> --body-file <work>/reply-<thread>.md` per answered
+  thread, the reply naming the commit that changes the code. **Never resolve.** A `reply` that exits
+  ≠ 0 is recorded in `08-feedback.md` and the remaining replies still go out.
+- **The one closing order**, after the WIP commit (flow-core §2.1): code changed this round →
+  `publish` with the work's `publish-title.md` / `publish-body.md` (updated when the round changed
+  what they say, and naming any thread whose reply failed) and the `--part/--of` `/flow:feat:ship`
+  passed — the commits the replies name must reach the branch; no code changed and every reply went
+  out → `done`, the summary listing the threads answered; no code changed and a reply failed →
+  `blocked`, naming those threads.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)

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.
@@ -51,7 +51,9 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
 | `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow:feat:build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
-| `review` · `pipeline` | any | `blocked` — not supported yet in `unattended`; the reason says so |
+| `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 |
 
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`

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.84.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
@@ -290,7 +291,7 @@ run has.
 |---|---|
 | Business brief before code (`build`, `fix`) | record — the brief is written to the phase artifact, marked `recorded (unattended)`, and travels in the MR/PR body |
 | Push and MR/PR creation (`ship`) | `publish` — the run commits on its own branch, writes title and body, and hands them over; the orchestrator pushes and opens the draft |
-| 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 |
+| 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 — except in `respond` and `green`, where it is blocked: a schema change agreed after the MR/PR exists goes back through `build` |
 | `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. **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` |
@@ -382,7 +383,7 @@ the next review would take *Fix them* again, with nothing left to fix.
 | `clarify` | `design` §1.5.5 / §9 | `design` | §1.5.5 — the choice and the size check / §9 | `03-design.md` "Decisions clarified while choosing the approach" / the criterion it clarifies | free text |
 | `design_challenge` | `design` §6 | `design` | §7 | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
 | `investigation_challenge` | `investigate` | `investigate` | the section after the challenge | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
-| `decision` | any phase | the same phase | the step that surfaced it | where that phase keeps its decisions (§7) | the options that were on the table · free text |
+| `decision` | any phase | the same phase — `work:respond` for a review round | the step that surfaced it — the end of §4 for a review round | where that phase keeps its decisions (§7) — this round's section of `08-feedback.md` for a review round | the options that were on the table · free text |
 | `migration` | `build` / `fix` | the same phase | the unticked plan step that writes it | "Decisions made during implementation" in `05-implementation.md` / `04-fix.md` | *Write it and continue* · *Change the design first* |
 | `migration` | `validate` (apply) | the same phase | its pre-flight — it re-runs whole, and its apply site takes the answer just applied | `meta.json.defaults_used[]` only — the artifact is written whole at the end, and names the answer beside the migration it applied (`07-validation.md` "Edge cases verified" / `05-validation.md`) | *Apply it* |
 | `migration` | `ship` (pre-deploy SQL) | the same phase | its pre-flight — the draft lives only in context; the site takes the answer just applied | `05-implementation.md` / `04-fix.md`, beside the SQL | *The SQL is complete — ship 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-README/SKILL.md

@@ -248,7 +248,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
   resume; otherwise status.
 - `/flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow-feat-start`, `/flow-work-green`, `/flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow-news`.
 - `/flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
-- `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
+- `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged · review · pipeline), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
 - `/flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow-work-try <branch>` / `/flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

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

@@ -36,13 +36,38 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix); `unattended` resolves gates 1–4 as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Any push** (§6).
 2. Creating/switching a branch, or DB schema changes/migrations, if a fix requires them.
 3. **Re-triggering a pipeline or job on the remote** (CI resources; outward action).
 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:
+
+- **§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.
+- **§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
+  scope, otherwise `blocked` with the justification.
+- **§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
+  review gate the round cannot clear → `blocked` (flow-core §2.1). Commits as `auto`.
+- **§7 before the closing order** — logged as written; offers are `Later`; re-posting the
+  performance comment is not done — a changed number goes into `publish-body.md`.
+- **§6** — no push, no rerun, no watch. The closing order, after the WIP commit (flow-core §2.1): `publish` with the
+  work's `publish-title.md` / `publish-body.md` and the `--part/--of` `/flow-feat-ship` passed; the
+  orchestrator pushes and the pipeline runs again.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)

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

@@ -32,7 +32,9 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`. **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`; `unattended` resolves the gates as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Posting any comment/reply** to the MR/PR (§7).
 2. **Any push** (§6.2).
 3. Creating/switching a branch, or DB schema changes/migrations, when an agreed change requires them.
@@ -40,6 +42,47 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 Everything else: take the sensible default and record it; ask only when irreversible/costly, ambiguous and not settled by ticket + design + knowledge search, or a hard gate.
 
+**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = review` — this command
+asks nothing and never touches the forge: the threads come from the orchestrator, the replies go
+back through it, and the hard gates above resolve this way:
+
+- **§1** — no MR/PR is resolved: the work is the one `/flow-work-run` found, on the branch the
+  orchestrator checked out. A round over the ceiling → `blocked`, its reason being the (a)(b)(c)
+  hand-back of §1.
+- **§2** — the threads are `<cmd> events --json` → `comments[]`, grouped by `thread` (each comment:
+  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line` when it has them). The untrusted-input
+  rule stands unchanged. The machine-state check is skipped: the orchestrator relaunches for the
+  pipeline separately. The order failing → `blocked`; no comments → `done`, the summary saying so.
+- **§3–§4** — triage and stances as `auto` decides them, the table and the drafts written to
+  `08-feedback.md` instead of shown. A thread only a person can settle — a product decision, or a
+  `D` the recorded rationale and the code do not decide — goes into **one** question for all of them,
+  asked **before anything is replied or committed**: `ask --gate decision`, free text `T<n>: <answer>`
+  per thread, with `pending.phase: "respond"`, `pending.resume: "work:respond"` (never the work's
+  `meta.json.phase`) and `pending.resume_at: "end of §4"`, and the run ends there. The answer is
+  written into this round's section of `08-feedback.md`, and the relaunch re-enters at the end of
+  §4, reading the threads and stances from that file rather than from `events`. **At the end of §4
+  — on a first run and on that re-entry alike** — a reply that would repeat an earlier round's
+  (§8's repeated-answer rule) is caught before anything is posted → `blocked`, naming the thread.
+  `§4.G` measures as `/flow-work-query` does unattended (schema-only, never a database it creates).
+- **§5–§6** — a change adding behaviour gets its brief recorded (`recorded (unattended)`), not
+  asked. A design invalidation that is more than a tweak, or an agreed change that needs a schema
+  change → `blocked` (flow-core §2.1): the run does not redesign. Commits as `auto`. §6.1 runs
+  whole; a high-severity finding the round cannot clear → `blocked` with the findings. **§6.2 does
+  not run**: nothing is pushed — the orchestrator pushes on `publish`.
+- **§8 before §7** — §8 completes the round's section §3–§4 opened in `08-feedback.md` (never a
+  second one) and counts `respond_rounds`, before any reply and before any `blocked` from here on.
+  A `blocked` earlier than this point (the repeated answer, §6.1) also counts the round first. The agent-lessons offer is `Later`; re-posting the performance comment is not
+  done — a changed number goes into `publish-body.md` instead.
+- **§7** — one `<cmd> reply --thread <thread> --body-file <work>/reply-<thread>.md` per answered
+  thread, the reply naming the commit that changes the code. **Never resolve.** A `reply` that exits
+  ≠ 0 is recorded in `08-feedback.md` and the remaining replies still go out.
+- **The one closing order**, after the WIP commit (flow-core §2.1): code changed this round →
+  `publish` with the work's `publish-title.md` / `publish-body.md` (updated when the round changed
+  what they say, and naming any thread whose reply failed) and the `--part/--of` `/flow-feat-ship`
+  passed — the commits the replies name must reach the branch; no code changed and every reply went
+  out → `done`, the summary listing the threads answered; no code changed and a reply failed →
+  `blocked`, naming those threads.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)

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.
@@ -55,7 +55,9 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
 | `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
-| `review` · `pipeline` | any | `blocked` — not supported yet in `unattended`; the reason says so |
+| `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 |
 
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`

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.84.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
@@ -289,7 +290,7 @@ run has.
 |---|---|
 | Business brief before code (`build`, `fix`) | record — the brief is written to the phase artifact, marked `recorded (unattended)`, and travels in the MR/PR body |
 | Push and MR/PR creation (`ship`) | `publish` — the run commits on its own branch, writes title and body, and hands them over; the orchestrator pushes and opens the draft |
-| 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 |
+| 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 — except in `respond` and `green`, where it is blocked: a schema change agreed after the MR/PR exists goes back through `build` |
 | `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. **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` |
@@ -381,7 +382,7 @@ the next review would take *Fix them* again, with nothing left to fix.
 | `clarify` | `design` §1.5.5 / §9 | `design` | §1.5.5 — the choice and the size check / §9 | `03-design.md` "Decisions clarified while choosing the approach" / the criterion it clarifies | free text |
 | `design_challenge` | `design` §6 | `design` | §7 | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
 | `investigation_challenge` | `investigate` | `investigate` | the section after the challenge | the "Response" of each high finding | *Apply the recommended response to each* · free text `F<n>: <response>` |
-| `decision` | any phase | the same phase | the step that surfaced it | where that phase keeps its decisions (§7) | the options that were on the table · free text |
+| `decision` | any phase | the same phase — `work:respond` for a review round | the step that surfaced it — the end of §4 for a review round | where that phase keeps its decisions (§7) — this round's section of `08-feedback.md` for a review round | the options that were on the table · free text |
 | `migration` | `build` / `fix` | the same phase | the unticked plan step that writes it | "Decisions made during implementation" in `05-implementation.md` / `04-fix.md` | *Write it and continue* · *Change the design first* |
 | `migration` | `validate` (apply) | the same phase | its pre-flight — it re-runs whole, and its apply site takes the answer just applied | `meta.json.defaults_used[]` only — the artifact is written whole at the end, and names the answer beside the migration it applied (`07-validation.md` "Edge cases verified" / `05-validation.md`) | *Apply it* |
 | `migration` | `ship` (pre-deploy SQL) | the same phase | its pre-flight — the draft lives only in context; the site takes the answer just applied | `05-implementation.md` / `04-fix.md`, beside the SQL | *The SQL is complete — ship 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-README.md

@@ -246,7 +246,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
   resume; otherwise status.
 - `/flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow-feat-start`, `/flow-work-green`, `/flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow-news`.
 - `/flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
-- `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
+- `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · answer · merged · review · pipeline), routes to the phase that answers it, and makes no decision of its own. Refuses to run in any other mode.
 - `/flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow-work-try <branch>` / `/flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

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

@@ -34,13 +34,38 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix). **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2; `guided`/`auto` record their choices in `09-ci.md` (e.g. a pure formatter auto-fix); `unattended` resolves gates 1–4 as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Any push** (§6).
 2. Creating/switching a branch, or DB schema changes/migrations, if a fix requires them.
 3. **Re-triggering a pipeline or job on the remote** (CI resources; outward action).
 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:
+
+- **§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.
+- **§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
+  scope, otherwise `blocked` with the justification.
+- **§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
+  review gate the round cannot clear → `blocked` (flow-core §2.1). Commits as `auto`.
+- **§7 before the closing order** — logged as written; offers are `Later`; re-posting the
+  performance comment is not done — a changed number goes into `publish-body.md`.
+- **§6** — no push, no rerun, no watch. The closing order, after the WIP commit (flow-core §2.1): `publish` with the
+  work's `publish-title.md` / `publish-body.md` and the `--part/--of` `/flow-feat-ship` passed; the
+  orchestrator pushes and the pipeline runs again.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (via `meta.json`, matching `branch`). Read `meta.json` and `00-summary.md`; open in full only `09-ci.md` (previous rounds) and, when §3/§5.C need the recorded "why", `03-design.md`, `05-implementation.md`/`04-fix.md`. (flow-core §5)

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

@@ -30,7 +30,9 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 **Panel words are closed** — `mark`: `done` · `current` · `pending` · `wait` · `block` · `info`; `style`: `normal` · `dim` · `title` · `accent` · `ok` · `warn` · `error`. Anything else is dropped by the reader in silence: the panel still paints, and nobody is told.
 
-**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`. **Hard gates — ALWAYS stop and ask, in every mode, no exceptions:**
+**In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
+
+**Autonomy.** Modes as in flow-core §2 (`autonomy.mode`: `manual` | `guided` | `auto`; empty = `manual`); `guided`/`auto` record their choices in `08-feedback.md`; `unattended` resolves the gates as its paragraph below says. **Hard gates — ALWAYS stop and ask, in `manual`, `guided` and `auto`, no exceptions:**
 1. **Posting any comment/reply** to the MR/PR (§7).
 2. **Any push** (§6.2).
 3. Creating/switching a branch, or DB schema changes/migrations, when an agreed change requires them.
@@ -38,6 +40,47 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 Everything else: take the sensible default and record it; ask only when irreversible/costly, ambiguous and not settled by ticket + design + knowledge search, or a hard gate.
 
+**In `unattended`** (flow-core §2.1) — launched by `/flow-work-run` on `why = review` — this command
+asks nothing and never touches the forge: the threads come from the orchestrator, the replies go
+back through it, and the hard gates above resolve this way:
+
+- **§1** — no MR/PR is resolved: the work is the one `/flow-work-run` found, on the branch the
+  orchestrator checked out. A round over the ceiling → `blocked`, its reason being the (a)(b)(c)
+  hand-back of §1.
+- **§2** — the threads are `<cmd> events --json` → `comments[]`, grouped by `thread` (each comment:
+  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line` when it has them). The untrusted-input
+  rule stands unchanged. The machine-state check is skipped: the orchestrator relaunches for the
+  pipeline separately. The order failing → `blocked`; no comments → `done`, the summary saying so.
+- **§3–§4** — triage and stances as `auto` decides them, the table and the drafts written to
+  `08-feedback.md` instead of shown. A thread only a person can settle — a product decision, or a
+  `D` the recorded rationale and the code do not decide — goes into **one** question for all of them,
+  asked **before anything is replied or committed**: `ask --gate decision`, free text `T<n>: <answer>`
+  per thread, with `pending.phase: "respond"`, `pending.resume: "work:respond"` (never the work's
+  `meta.json.phase`) and `pending.resume_at: "end of §4"`, and the run ends there. The answer is
+  written into this round's section of `08-feedback.md`, and the relaunch re-enters at the end of
+  §4, reading the threads and stances from that file rather than from `events`. **At the end of §4
+  — on a first run and on that re-entry alike** — a reply that would repeat an earlier round's
+  (§8's repeated-answer rule) is caught before anything is posted → `blocked`, naming the thread.
+  `§4.G` measures as `/flow-work-query` does unattended (schema-only, never a database it creates).
+- **§5–§6** — a change adding behaviour gets its brief recorded (`recorded (unattended)`), not
+  asked. A design invalidation that is more than a tweak, or an agreed change that needs a schema
+  change → `blocked` (flow-core §2.1): the run does not redesign. Commits as `auto`. §6.1 runs
+  whole; a high-severity finding the round cannot clear → `blocked` with the findings. **§6.2 does
+  not run**: nothing is pushed — the orchestrator pushes on `publish`.
+- **§8 before §7** — §8 completes the round's section §3–§4 opened in `08-feedback.md` (never a
+  second one) and counts `respond_rounds`, before any reply and before any `blocked` from here on.
+  A `blocked` earlier than this point (the repeated answer, §6.1) also counts the round first. The agent-lessons offer is `Later`; re-posting the performance comment is not
+  done — a changed number goes into `publish-body.md` instead.
+- **§7** — one `<cmd> reply --thread <thread> --body-file <work>/reply-<thread>.md` per answered
+  thread, the reply naming the commit that changes the code. **Never resolve.** A `reply` that exits
+  ≠ 0 is recorded in `08-feedback.md` and the remaining replies still go out.
+- **The one closing order**, after the WIP commit (flow-core §2.1): code changed this round →
+  `publish` with the work's `publish-title.md` / `publish-body.md` (updated when the round changed
+  what they say, and naming any thread whose reply failed) and the `--part/--of` `/flow-feat-ship`
+  passed — the commits the replies name must reach the branch; no code changed and every reply went
+  out → `done`, the summary listing the threads answered; no code changed and a reply failed →
+  `blocked`, naming those threads.
+
 ## 1. Pre-flight — locate the work and the MR/PR
 
 - Identify the current branch and its work folder `.claude/work/<TICKET>/` (the `meta.json` whose `branch` matches). Read `meta.json` and `00-summary.md`; open in full only `08-feedback.md` (spent rounds, below) and, in §3, the rationale artifacts a thread needs (`03-design.md`, `05-implementation.md`/`04-fix.md`). (flow-core §5)

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.
@@ -53,7 +53,9 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `answer` | nothing pending | `blocked` — there is no question for that answer to decide |
 | `merged` | exists, something published | the entry of `meta.json.mrs` whose `status` is `published` (the only one: one MR/PR per run) becomes `merged`; set `meta.json.base` to the `base` just read; the next startable MR/PR → `/flow-feat-build`; none left, or a work with no `mrs` and `published` true (one MR/PR, every bug) → `phase = done` and `done`, the summary naming the ticket as complete |
 | `merged` | none, or nothing published | `blocked` — nothing of this ticket was published from here |
-| `review` · `pipeline` | any | `blocked` — not supported yet in `unattended`; the reason says so |
+| `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 |
 
 The phase you hand the run to is unattended too: it reads §2.1, chains as `auto` and makes the
 run's one closing order. This command makes none of its own except the re-sent `ask`, the `blocked`

package/package.json

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

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,32 @@ 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**
+- **Review comments on a draft no longer stop an unattended run.** Relaunched with `why = review`,
+  `/flow:work:run` hands the run to `/flow:work:respond`, which reads the threads from the
+  orchestrator (`events --json`), answers each one through it (`reply --thread … --body-file …`),
+  commits what was agreed and hands the work back with `publish` — or `done` when only replies were
+  needed. It still never resolves a thread.
+- **A red pipeline is fixed at the root, or named.** Relaunched with `why = pipeline`,
+  `/flow:work:green` reads the failed jobs and their log tails from the orchestrator, fixes and
+  verifies locally, and ends with `publish`. A flake, an infrastructure failure, a conflict, or
+  anything that needs a rebase or a force-push ends `blocked` with the reason: reruns and the
+  red-round limit belong to the orchestrator. Green-washing stays forbidden in every mode.
+- **What only a person can settle is asked once, before anything is posted**: one question for
+  every thread that needs a product decision or a call the recorded design does not make.
+- Nothing changes in `manual`, `guided` or `auto`. Completes #177.
+
 ## v0.84.0 — An unattended run talks to its orchestrator through one command  ·  2026-10-01
 
 **In short**