flow-workflows 0.80.0 → 0.82.0

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.80.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -30,12 +30,9 @@ a command relies on is simply absent in that session, and nothing else will repo
 - **Look before you read.** The first thing a phase does about configuration is list what is there:
   `ls <root>/FLOW*.md` (the root being the one the next bullet resolves). One call, and it is not
   optional — **an overlay you did not list is an overlay you did not read**, and nothing downstream
-  will notice. This is not a hypothetical: every command below, and every artifact they write,
-  refers to the effective configuration as "`FLOW.md`", which is a file that exists, so reading it
-  and stopping feels finished. Two real sessions in a row read the base in full and never went
-  looking for the overlay sitting beside it — the models it set were silently the defaults, and
-  both runs reported the keys as unset with no way to tell that apart from a repo that never set
-  them. **Name the files this listing found the first time a phase reports any configured value**,
+  will notice. Every command and artifact calls the effective configuration "`FLOW.md`", a file that
+  exists, so reading it and stopping feels finished — and a missed overlay reports its keys as unset,
+  indistinguishable from a repo that never set them. **Name the files this listing found the first time a phase reports any configured value**,
   so a missed overlay is visible in the artifact rather than invisible everywhere.
 - Read `FLOW.md` at the repo root as the base, then the optional overlay for the harness running
   this command: `FLOW.claude.md`, `FLOW.codex.md`, `FLOW.opencode.md`, `FLOW.gemini.md`,
@@ -68,11 +65,8 @@ a command relies on is simply absent in that session, and nothing else will repo
 - **A fenced block in a FLOW file is an example, and an example is not configuration.** These
   files are prose with keys in them, and the rule that decides what a key *is* — a `- key:` line
   under a `## section` — knows nothing about triple backticks. So a block written to be pasted
-  ("add this to try it once") was read as the configuration it illustrates, for as long as it sat
-  there. It happened in a real repo: `agents.exec_cmd` came from the fenced example of a file whose
-  prose argued at length that it was deliberately unset, and every review round took the one-shot
-  path that prose warned against — with nothing anywhere to say so, because the file and the
-  configuration disagreed while both looked right. **Skip fenced regions when you read a FLOW
+  ("add this to try it once") would be read as the configuration it illustrates, while the prose
+  around it says otherwise and nothing reports the disagreement. **Skip fenced regions when you read a FLOW
   file**; `flow-workflows` does the same, so the two of you resolve the same config.
 - Merge by section and key. A key present in the active overlay replaces the base value; a key
   absent there inherits the base. **A present-but-empty overlay key masks the base** and resolves
@@ -93,7 +87,7 @@ a command relies on is simply absent in that session, and nothing else will repo
      alongside whatever it was already asking. Resolve the destination by the ownership rule below.
      Never a question of its own, never a key off the list, and at most **one key per work** — the
      second one waits for the next work or for `/flow-init`.
-  3. `guided`/`auto` → take the default and **record** it: one line in the phase artifact as today,
+  3. `guided`/`auto` → take the default and **record** it: one line in the phase artifact,
      plus an entry in `meta.json.defaults_used[]` — `{ "key": "agents.security", "default":
      "general-purpose", "phase": "review" }`. Asking here would break the never-a-question contract
      (§2); recording keeps the decision readable afterwards, and `/flow-doctor` aggregates it.
@@ -120,8 +114,7 @@ a command relies on is simply absent in that session, and nothing else will repo
   the consolidation appends to `KNOWLEDGE.md` at the repo root. Per-call timeout
   `knowledge.timeout_s` (empty = 2 s); a failure or timeout → continue without it, silently.
 **How a consolidation runs** (`ship`, `postmortem`, `abandon`, and the offer in `/flow-work-status`
-when `read_staging` has entries). No role set at all → say so in one line and stop; nothing here is
-worth a command of its own, which is why there is no longer one:
+when `read_staging` has entries). No role set at all → say so in one line and stop:
 
 1. **Read the staging** for this branch with `knowledge.read_staging`; the role empty → the "why"
    findings already written in this work's artifacts (`03-design.md` ADR-light and challenges,
@@ -185,15 +178,20 @@ line: the wait inherits this thread's model because no key is set. Name the key,
 
 ## 2. Autonomy — `autonomy.mode`
 
-`manual` (default) · `guided` · `auto`. Read it once and apply it throughout the command.
+`manual` (default) · `guided` · `auto` · `unattended`. Read it once and apply it throughout the command.
 
 | Mode | Decisions | End of the command |
 |---|---|---|
 | `manual` | Stop at every decision point | Propose the next command with one `AskUserQuestion` (recommended step as default). Invoke it only on confirmation. Never make the user type it. |
 | `guided` | Resolve low-risk, unambiguous ones with the recommended default and **record** the choice in the phase artifact. Ask at genuine decision points. | Chain into the recommended next command automatically — the call that starts it first, no closing report before it (§3). |
 | `auto` | As `guided`, plus resolve the remaining decision points with sensible, recorded defaults. | Chain without pausing, same rule. |
+| `unattended` | As `auto`, for a run **nobody is watching** (a script, a container, a headless CLI). Every place `auto` would still stop for a person resolves by §2.1 instead. | Chain as `auto`; the run ends at a **stop file** (§2.1), never at a question. |
 
-**Hard gates — stop and ask in every mode, no exceptions:**
+`unattended` is never inferred — not from a headless harness, not from a missing terminal. It is
+the value someone wrote in the FLOW config, or it is not in effect.
+
+**Hard gates — in `manual`, `guided` and `auto`, stop and ask, no exceptions** (in `unattended`
+each one resolves as §2.1's table says — never approved in silence):
 1. Any push or MR/PR creation (all of `ship`).
 2. Creating or switching a branch when the base is ambiguous (not on a clean main, or a possible train/stacked branch).
 3. DB schema changes or migrations.
@@ -218,7 +216,112 @@ sensible default and record it.
   delegation removes. Take it, record it. What is still asked in `manual` is whatever the evidence
   turns out to call for, once it is back.
 
-Asking these anyway is how an unattended run degrades into a manual one.
+Asking these anyway is how a run in `guided`/`auto` degrades into a manual one.
+
+### 2.1 `unattended` — where a person would have been asked
+
+Nobody answers a question in this mode. A question tool — `AskUserQuestion`, OpenCode's `question`,
+whatever the harness calls it — either blocks a run that has no one to unblock it or, in print mode,
+ends it with a question nobody reads. So **no question tool is ever called in `unattended`**, and a
+question in prose is not a substitute. The run goes as far as it can without a person, and where it
+needs one it **stops and says exactly what for**. It never answers for them. Each place a command
+would have asked resolves one of three ways:
+
+- **record** — take the resolution the table names, write it where the phase keeps its decisions,
+  add `{ "key": "unattended:<site>", "default": "<resolution>", "phase": "<phase>" }` to
+  `meta.json.defaults_used[]` (the prefix says it is not a FLOW key), and continue.
+- **question** — a decision only a person can take. Write the stop file with `reason: "question"`,
+  the question and its options as `AskUserQuestion` would have carried them, set the panel's
+  `attention` to `wait`, and **end the run**: no further phase starts. A person picks the work up
+  in a session of their own, in any other mode, and the next phase asks them (below).
+- **blocked** — something the run cannot get past (the environment, a tool, a check that keeps
+  failing). The stop file with `reason: "blocked"` and a one-line `detail`, `attention: block`, end
+  the run.
+
+The §3 stop header is still printed at every stop — a log is the only screen that run has.
+
+| Where | In `unattended` |
+|---|---|
+| 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`) | `autonomy.unattended_ship: draft` → push the work branch and create the MR/PR **as draft**; never merge, never mark it ready; the forge refusing a draft → blocked, never retried as a normal one. Empty or `stop` → question `ship` |
+| Writing a DB schema change, index or migration — in any phase, a review's own fixes included — or applying one (`validate`) | question `migration`, before the first line of it is written or run |
+| `review` with blockers or high-severity findings | question `high_findings` |
+| `validate` with a red suite or a criterion `unproven` | blocked — the phase does not advance and does not chain |
+| A product decision (§7 `decision`) | question `decision` |
+| Clarifying questions on the ticket (`start`) | question `clarify` — after the branch and the work folder exist, with the questions also written to `01-context.md` |
+| An unanswered high-severity challenge (`design`, `investigate`) | question `design_challenge` / `investigation_challenge` |
+| No ticket, a tracker read that fails, a checkout that is not a clean default base (`start`) | blocked — the runner owns the checkout and the ticket |
+| Below-XS check (`start`) | record — open the work |
+| "Create the branch?" (`start`), the 2–3 line note an XS `build`/`fix` asks for, a contract the design left in prose (`build`) | record — create it · write the note from the ticket · convert it to literal and say so in the artifact |
+| `git.worktree: ask` | record — in place |
+| Cross-repo scope (`start`) | record — only the repos the ticket names |
+| Criteria that need a person to verify (`validate`) | record — `not-verified-unattended`; every later `ship`, in any mode, lists them in the body under "Not verified — needs a human" |
+| The query duel needs a database (`review`, `query`) | record — schema-only verdict; never create or seed a database |
+| "Was it merged?" (`ship` close) | record — not merged |
+| The next MR/PR of a train (`ship` close) | record — not started: one MR/PR per unattended run |
+| `build` with no startable MR/PR (its `depends_on` not `merged` in `meta.json`) | blocked — the detail names what must merge; an unattended `build` never stacks a branch on another, and never creates a remote branch |
+| The parent of a stacked MR/PR merged — rebase and force-push | blocked — never force-push unattended |
+| Any offer about the work's own bookkeeping — a tracker issue, the first `KNOWLEDGE.md` or a knowledge save, a FLOW convention, an agent lesson or a saved specialist, the follow-up survey, carrying files over from the main checkout, a contract handoff, archiving the work | record — `Later`; nothing written outside the work folder |
+| A step the command cannot complete (a red suite it cannot fix, a tool missing, auth failing, the same check failing a second time) | blocked |
+| Anything `auto` already decides on its own (size, flow mechanics, WIP commits, the next command) | as `auto` |
+
+A place where `auto` would still ask and this table does not name is a **question** — the
+conservative reading, never a guess dressed as a default.
+
+**The stop file** — `.claude/work/stop.json`, at the root of the main checkout (§0: the repo root is
+the main checkout's, whichever worktree the phase runs in). One fixed path, so a runner finds it
+without knowing the work's folder, and `start` can write it before that folder exists. Written
+whole, every time, with every field — by unattended runs, and outside that mode only to mark it
+`picked_up` (below). **One unattended run per repository**: its
+worktrees all share this file. A clean-tree check never counts `.claude/work/` — the flow's own
+folder.
+
+```json
+{"reason": "question",
+ "phase": "build",
+ "gate": "migration",
+ "ticket": "168",
+ "work": "168-unattended-autonomy-mode",
+ "branch": "168-unattended-autonomy-mode",
+ "worktree": null,
+ "question": "The design adds a nullable column `mails.opened_at` and its migration. Write and apply it?",
+ "options": [{"label": "Write and apply it", "recommended": true}, {"label": "Change the design first"}],
+ "mr_url": null,
+ "detail": null,
+ "at": "2026-09-29T14:30:00+02:00"}
+```
+
+- `reason`: `running` · `question` · `blocked` · `done` · `picked_up`. It mirrors the panel's `attention` (§4.2):
+  `question` ↔ `wait`, `blocked` ↔ `block`, `done` ↔ `done`, `running` and `picked_up` ↔ absent.
+  Set both in the same step.
+- `work`, `branch`, `worktree`: where the person picks it up — `null` for the ones that do not exist
+  yet when `start` stops early.
+- `gate`: the site's id from the table, or `null`. `question` and `options` carry the whole question,
+  the recommended option first — whoever reads it has not seen this session.
+- `done` is written when the run's work is over: the MR/PR created (`mr_url` set; with a train,
+  `detail` says which MR/PR comes next and what it waits on), or a phase that finds nothing to do
+  (every MR/PR merged, a work already shipped) — `detail` says which. **No unattended phase ends
+  with `running` in the file**: every ending is one of `question`, `blocked` or `done`.
+- `at` from the real clock (`date -Iseconds`).
+
+**Every phase that starts in this mode writes `reason: "running"` first** — the whole file, `work`,
+`branch` and `worktree` included — unless it holds a `question`, for this work or any other: no
+person has answered it yet, and the file is the only record of it, so say so and end the run,
+touching nothing. One question at a time per repository. (A `blocked` is overwritten: running
+again *is* its retry, once the runner has fixed what it named.) A run that dies therefore leaves
+`running` behind. For the runner: `running` at exit is a crash; a `question` older than the run's
+own start is the earlier stop, still waiting, and the run refused to go past it.
+
+**A person picks it up in any other mode.** `/flow-work-resume` names the pending stop in its
+recap, and **the next phase that runs on that work** (`stop.json.work` is this one — never another
+work's) **asks it first** — the question, verbatim, with its options — before doing anything else,
+then overwrites the file with `reason: "picked_up"`. The answer decides what happens next, as any
+answer does: *go on* → the phase goes on; *change the design*, *fix them* → the phase does that
+instead (back to `design`, fix and review again). A `ship` question is not replayed: `ship`'s own
+preview asks it, fresh. **The person's session must not itself be `unattended`**: set the mode where
+only the runner reads it — a FLOW file the runner's own environment writes (its container, its CI
+checkout), or the overlay of a harness only the runner uses. `/flow-doctor` says which file the
+mode came from.
 
 ## 3. Reporting — how every stop reads
 
@@ -241,6 +344,9 @@ terminal by construction, the turn is over before you notice.
   the answer arrives, before the work resumes (§4.4e).
 - **Stopping? Then say so.** `I need:` names the decision or the action you are waiting on. It
   never announces that you are continuing — if you were, you would not be writing this header.
+- **In `unattended`, the stop is the stop file** (§2.1): write it, set the panel's `attention`,
+  end the run. The header below is still printed — a log is the only screen that run has — but
+  nothing in it is asked.
 
 The user comes back to a screen they walked away from, often with other works in other panes.
 They have read none of your tool calls, subagent reports or artifacts. So every stop **opens with
@@ -259,7 +365,7 @@ I need: <one line — the decision or action you are waiting on>
 - **Short lines.** One or two lines of headline, then two to five bullets, one idea each. No "for context", no restating an earlier stop. When the user asks a technical question, answer it in full.
 - **Out of the chat, into the artifact:** your own process, your mistakes, corrections to subagent reports, bookkeeping. Subagent completion or idle notifications never earn a turn of their own.
 - **Zero-context rule.** First mention of an identifier carries 4–6 words of what it is. Never cite a section number without naming what it is. No jargon the user has not used first.
-- **If it is a question, it is `AskUserQuestion`.** Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
+- **If it is a question, it is `AskUserQuestion`** — in `unattended`, the stop file (§2.1). Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
 - **What the question is about travels with the question.** A brief, an MR/PR body, a plan, a finding: put it where the user answers it — in the question text and its options — and not only in the prose above. **Nothing runs between the two**: a tool call after that prose is what makes a terminal fold it away, and the last thing a chat UI collapses is exactly the thing they were asked to read. A gate answered without seeing what it was about is not a gate; "it is in `05-implementation.md`" is not showing it, because the answer then costs opening an editor and finding the file. Too long for the harness's question → print it as the **last** thing before asking, tool calls already done.
 
 ## 4. Live panel — over the terminal's MCP, or `panel.json`
@@ -271,7 +377,7 @@ right now. **Any progress line you were about to type into the chat is a panel u
 **Two transports, one document.** When the tools `panel_set` / `panel_patch` / `panel_get` are
 available, this console is a pane of agent-terminal: publish the panel through them (§4.2) and
 **stop writing `.claude/work/<work>/panel.json`** — while a pane is claimed, its file is not read at
-all. When they are not there, write the file exactly as before (§4.3). No work folder (lightweight
+all. When they are not there, write the file (§4.3). No work folder (lightweight
 `respond`/`green`) → nothing to publish, either way.
 
 **Look for them before you conclude they are missing**, once per session, in pre-flight. A harness
@@ -414,8 +520,7 @@ single largest token cost of a work, so every work carries a short handoff:
   MR/PR of `04-mr-plan.md`; `review` opens the design's contracts and the implementation log;
   `ship` opens the brief and the review verdict. A summary that does not answer the question you
   have is the cue to open the artifact — never a licence to guess.
-- Missing summary (a work started before this rule) → read the artifacts as before, write the
-  summary at your Close.
+- Missing summary → read the artifacts, write the summary at your Close.
 - **Name the phase, never the command.** An artifact outlives the session that wrote it and may be
   resumed from a different agent, where the same phase is invoked under another name. Write the
   phase — `validate`, `review`, `ship #2` — not the invocation. Applies to `00-summary.md`,
@@ -450,7 +555,7 @@ around each of its own findings to work out which changes are its doing, and how
 looks clean is clean by luck. **The parent thread is a writer too**: applying a round's fixes while
 its agents are still reading is the same collision, from the side nobody counts.
 
-So a round that contains a writer is not one round. Readers fan out freely, as they always did;
+So a round that contains a writer is not one round. Readers fan out freely;
 writers go one at a time, each either alone or in a worktree of its own, and the readers sit
 entirely before them or entirely after them. The parent's own edits wait until the round is
 consolidated. Ordering costs wall clock and the phase says so in one line — a reading nobody can
@@ -492,8 +597,7 @@ Dropping a silent agent is always allowed, and always reported (`N/M` reported).
 no deadline is what costs a session.
 
 **The budget belongs to the command, not to the round.** `agents.fanout_max` caps *one* parallel
-round; nothing capped what a command spends across all of its rounds, and the phases that fan out
-compose: a review can run a panel, then area reinforcements, then a coverage sweep that relaunches
+round, and the phases that fan out compose: a review can run a panel, then area reinforcements, then a coverage sweep that relaunches
 the panel, then one skeptic per finding — each round inside its own cap and the command an order of
 magnitude over what anyone intended.
 
@@ -558,15 +662,13 @@ must *react to* mid-wait is not a wait at all: it is the work, and it stays here
 ### 6.6 — Which agent a role resolves to
 
 **The harness already tells you which agents are installed**, each with a line on what it is for,
-and choosing the one that fits a piece of work is something you do well without being told. A rule
-that answers every empty role with `general-purpose` throws that away: a repo with a frontend
-specialist installed and no `agents.frontend` got a generalist told to act like one. So wherever a
+and choosing the one that fits a piece of work is something you do well without being told. Answering every empty role with `general-purpose` throws that away. So wherever a
 command says *"`agents.<role>`, empty → `Agent general-purpose` with the role"*, it means this:
 
-1. **`agents.<role>` names an agent** → that agent, as always.
+1. **`agents.<role>` names an agent** → that agent.
 2. **Empty** → the installed agent whose description fits the role **and this work's stack** best —
    read the list your harness gives you, never a guess at a name. None fits clearly →
-   `general-purpose` with the role in the prompt, as before. An agent that fits the role but not the
+   `general-purpose` with the role in the prompt. An agent that fits the role but not the
    stack (a PHP reviewer on a React diff) does not fit.
 
 **`agents.selection`** decides how far your judgement reaches:
@@ -712,11 +814,11 @@ one more thing the user has to decide about.
   "title": "one line, what would be done",
   "why": "one line, why it was parked and why it still matters",
   "source": "design" | "plan" | "build" | "validate" | "fix" | "postmortem",
-  "status": "proposed" | "accepted" | "declined" | "logged" | "done",
+  "status": "proposed" | "accepted" | "in_progress" | "declined" | "logged" | "done",
   "ticket": null, "work": null, "note": "" }
 ```
 
-The artifact keeps its human-readable section exactly as before, with the `F<n>` id in front of each
+The artifact keeps its human-readable section, with the `F<n>` id in front of each
 row so the prose and the record never drift. **The record is the addition, not a replacement**: a
 reader of `05-implementation.md` still sees the ideas in context.
 
@@ -735,7 +837,8 @@ reader of `05-implementation.md` still sees the ideas in context.
   ships, gets reviewed, and comes back as a ticket that costs a whole work to answer what was two
   minutes of the user's. The test is one line: **if the answer changes what the code being written
   does now, ask now; if it changes what someone builds later, record it.** Asked now means one
-  `AskUserQuestion` the moment it surfaces, **in every `autonomy.mode`, `auto` included** — the
+  `AskUserQuestion` the moment it surfaces, **in every `autonomy.mode`, `auto` included** (in
+  `unattended`, a `decision` question in the stop file, §2.1) — the
   never-ask list of §2 is about flow mechanics, and a product decision is the opposite of mechanics —
   phrased as the question itself with the options that were on the table, recommended one first. The
   answer goes where the phase keeps its decisions (the brief in `04-fix.md`, the ADR-light in
@@ -751,8 +854,8 @@ at `ship`'s Close, when the work is done and the user can see the whole set.
 
 **A skeptic sorts them before the user sees them.** `/flow-*-review` already refuses to hand over an
 unverified finding: its §6 gives each ambiguous one to a skeptic whose job is to *refute* it, burden
-of proof on the finding. Deferred work reached the user through no filter at all, judged only by the
-phase that parked it — the one party that cannot judge it, having just found it. So at Close, when
+of proof on the finding. Deferred work needs the same filter: the phase that parked it is the one party that cannot judge
+it, having just found it. So at Close, when
 **3 or more** entries are still `proposed`, they go to a skeptic first (grouped into at most
 `agents.fanout_max` briefs, the ceilings of §6 unchanged; **fewer than 3 → no agent**, the command
 applies the bar itself):
@@ -779,15 +882,10 @@ Then, and only then, the survey:
   **Not worth it** · **Later**. The `title` and `why` are the entire prompt. **`decision` entries
   are asked as their product question** — they never go to the skeptic, a question's value not being
   a thing to refute — and sit outside the ceiling.
-- **`tooling` asks nothing.** `logged`, and a count on screen. Asking **Log it** about a lint floor
-  with slack in it was one question too many.
+- **`tooling` asks nothing.** `logged`, and a count on screen.
 - **Not worth it** → `declined`, with the reason if given. Never asked again.
 - **`logged` is a status, not a destination.** The entry stays exactly where it already is — in
-  `meta.json.followups[]` and in its artifact section — and no file is written anywhere. This used
-  to append a line to a versioned debt log, one per repo; **that file is gone**. No command read it,
-  `status` and `daily` excluded it on purpose, and it duplicated a record the work already keeps
-  forever, so it grew without ever being triaged. A note nobody reads is not a lighter obligation
-  than a ticket, it is the same obligation with the reader removed. If a gap in the machinery is
+  `meta.json.followups[]` and in its artifact section — and no file is written anywhere. If a gap in the machinery is
   worth someone's time, it is worth a ticket; if it is not, the record in the work is where it ends.
 - **A `decision` answered** → the answer is written into the artifact that owns it and the entry
   becomes `done` with the answer in `note`. Deferred again → stays `proposed`.
@@ -879,7 +977,7 @@ largest saving the review has.
 
 **What follows from that is a temptation, and it belongs to the diff, not to the plan.** A threshold
 that buys a lighter review pays whoever lands just under it: twelve lines below 150 is a review at
-`medium` with no project panel and no §6 round, twelve above it is the panel. So, in every phase:
+`medium`, twelve above it is one at `high`; at 600 the project panel joins. So, in every phase:
 
 **The diff reports the change; the change is never shaped to fit the number.** Never delete a
 comment, a test, a blank line or a log line, never compress readable code into fewer statements,

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

@@ -52,6 +52,12 @@ What is NOT touched:
 
 In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief.
 
+In `unattended` (flow-core §2.1) nobody is there to answer: write the brief, mark it
+`recorded (unattended)` under its heading, record the site in `meta.json.defaults_used[]`, and fix.
+The gate's purpose moves to the draft MR/PR, whose body carries the brief for the person who reads it.
+**A schema change or migration is still a question** (`migration`): before writing the first line
+of one → stop file, end the run. A person continues from there.
+
 **The brief travels inside the question** (flow-core §3) — read in the prompt being answered, not by opening `04-fix.md` — and **nothing runs between the brief and the question**: a tool call after it is what lets a terminal fold it away. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
@@ -118,13 +124,13 @@ the fix is minimal precisely because it trusts that. When the fix depends on X b
 cause and the investigation's evidence does not close that — one reproduction, a correlation, a
 `git blame` that fits the story — that is the premise, and one skeptic on it costs less than the
 second regression. **Refuted** → back to `/flow-bug-investigate`, never a second patch layered on
-the first. **Unsettled** → recorded in `04-fix.md` under "Premises the fix depends on" and carried
+the first (in `unattended`, the run ends `blocked` there, flow-core §2.1). **Unsettled** → recorded in `04-fix.md` under "Premises the fix depends on" and carried
 into the stop, because `/flow-bug-validate` writes a regression test against the cause the fix
 assumed.
 
 ## 2.3 Something outside the brief comes up?
 
-Anything **not in the §2 brief** ("while I'm at it, I'll also fix X", "this rename fits here", "this extra test covers another case"): **pause before touching it** and ask with `AskUserQuestion`:
+Anything **not in the §2 brief** ("while I'm at it, I'll also fix X", "this rename fits here", "this extra test covers another case"): **pause before touching it** and ask with `AskUserQuestion` (in `unattended`: *No, leave it out*, recorded):
 - **Yes, add it to the brief** — update the brief in `04-fix.md`, continue.
 - **No, leave it out** — note it under "Areas with similar risk" (a risk from the same pattern) or under "Ideas for separate tickets" in `04-fix.md`, **and append it to `meta.json.followups[]`** as `kind: "audit"` (similar risk) or `kind: "out-of-scope"`, `source: "fix"` (flow-core §7). **Only when it clears the bar of flow-core §7** — a named subject, a path that has actually been seen, and waiting costing more than doing it now; short of that the artifact section keeps it and `followups[]` never sees it.
 

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

@@ -20,6 +20,11 @@ description: "Find the root cause of the bug (not just the symptom)"
 
 Investigation phase: reproduce the failure, then find **why it happened** — not just what is failing.
 
+**In `unattended`** (flow-core §2.1) this command asks nothing. The hypothesis sweep runs as in
+`auto` · a size that no longer fits → record the new size · a `high` challenge with no response →
+question `investigation_challenge`, the findings and their options in the stop file · a bug that
+cannot be reproduced and needs a person to try → blocked.
+
 ## 1. Pre-flight
 
 Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, the live panel, `00-summary.md`) — skip if you already read it in this session. **Models: the subagents it launches take `models.agents`; its parallel rounds take `models.workers`.**
@@ -28,9 +33,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
 - `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` and stop.
-- Require `context` in `phases_done`. A work whose `phase` is the retired `diagnose` (written before
-  v0.53.0) is treated as having finished §1.5: read its `02-diagnose.md`, carry it into
-  `03-investigation.md`, and go straight to §3.
+- Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
 
@@ -38,9 +41,6 @@ Isolate **what** fails before looking for **why**. On **S** this is the whole of
 first half and the chain is `start → investigate (reproduce only) → fix → …`; on **M/L** it is the
 ground §3 stands on. **XS** skips straight to `/flow-bug-fix`.
 
-*(This was the `bug:diagnose` command until v0.53.0. Reproducing and finding the cause were two commands
-sharing five headings, and the S-size chain already ran them back to back.)*
-
 1. **Focused knowledge query on the symptom.** `knowledge.search` set → 2-3 parallel queries about
    the **suspected component** (handler, worker, endpoint, module): the same root cause often
    returns wearing a different symptom. Dead-letter queue → `"DLX <handler-name>"`, `"retry policy

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

@@ -97,4 +97,4 @@ Neither role set → skip this block silently.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - **Write every prevention action and similar-risk area to `meta.json.followups[]`** (flow-core §7), ids matching the tables above. This is the whole point of the phase: an action that lives only in `99-postmortem.md` is archived with the work and read by nobody, which is how the incident repeats.
 - Suggest `/flow-bug-ship`. Say how many follow-ups it will ask about at its Close — **do not triage them here**: mid-postmortem is the wrong moment to judge what is worth a ticket, and `ship` asks once with the whole set in view.
-- **Autonomy handoff — stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR, a hard gate in every mode: do **not** chain into it; stop here and propose `/flow-bug-ship` with a single `AskUserQuestion` (recommended option by default).
+- **Autonomy handoff — stops in every mode, `auto` included.** `ship` pushes and opens the MR/PR, a hard gate in every mode: do **not** chain into it; stop here and propose `/flow-bug-ship` with a single `AskUserQuestion` (recommended option by default). In `unattended` (flow-core §2.1), chain into `/flow-bug-ship`: it decides between a draft and a question.

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

@@ -37,7 +37,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
   member runs its own `git diff` and opens the same files pays for that material once per agent, and
   a reviewer that spends its turns exploring has fewer left to review. **Any non-zero exit is a
   fallback, not a failure** — no CLI on the machine, a base that does not resolve, a network that
-  cannot reach it: read the diff from git as before and carry on, once, without retrying variants.
+  cannot reach it: read the diff from git and carry on, once, without retrying variants.
   What is not optional is the `Review path` line of §7: a round that skipped the pack and one that
   used it are indistinguishable from the artifact otherwise, which is how a phase quietly stops
   paying for itself.
@@ -72,7 +72,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 - **Review base**: the previous `reviewed_sha` when it is non-empty and an ancestor of the candidate, otherwise `git.default_base`, with the reason in one line. `--full` forces the whole branch.
 - **Then**: `bundle --rev <candidate_sha> --base <review base>`, and every brief names that range rather than the live tree.
 
-A fix is usually small enough that the delta and the branch are the same thing — which is exactly why the freeze matters more here than the scoping: a one-file fix whose round applies its own correction is the case where `reviewed_sha` used to equal `HEAD` while describing a tree nobody read.
+A fix is usually small enough that the delta and the branch are the same thing — which is exactly why the freeze matters more here than the scoping: a one-file fix whose round applies its own correction is the case where recording `HEAD` as reviewed would describe a tree nobody read.
 
 ## 2. Run the code reviews
 
@@ -235,7 +235,7 @@ Cost line: count every subagent this command launched — reviewers = §2.1 buil
 - **Record *what* you reviewed, and separately what you changed after reading it** — `/flow-feat-review` §9, unchanged: `reviewed_sha` = the **candidate** of §1.5 (the revision the reviewers read, never `git rev-parse HEAD`, which by now holds this round's own fixes), and `fixed_sha` = `git rev-parse HEAD` after those fixes, empty when the round applied none. `phases_done` says a review happened; these two say on which tree and what moved afterwards, and `/flow-bug-ship §0` reads both against what is being pushed. Only when the phase advances: a review that ended in blockers reviewed nothing that stands.
 - **Record which pass found what** — `/flow-feat-review §9`, unchanged: one `meta.json.review_findings[]` entry per finding **per source** (`{ round, origin, severity, file, discarded_by_skeptic }`, no finding text), written by `flow review --record` when the CLI ran the panel and by this Close when the agentic panel did. `flow cost` reads them back per origin, and the retirement rule is the same: a pass with no exclusive surviving finding across twenty reviews comes out of the command.
 - **Record what the agents missed** — `/flow-feat-review §9`, unchanged: surviving findings in a category a panel member or named `agents.<role>` owns and did not report → `meta.json.agent_lessons[]` rows (flow-core §6.7), asking nothing. A fix is where this pays most: the defect already reached production once, and the reviewer that owns its category let it.
-- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most and, until now, the one phase that never staged — a work with three review rounds and seventeen blockers produced zero knowledge cards because nothing asked for them while they were in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `postmortem`/`ship`»). Never `knowledge.save` here.
+- **Stage what the review taught** (`knowledge.stage` set; silence by default). Review is where a project teaches the most, and this is the only moment its findings are in context. Candidates are findings about the **domain or the codebase's real behaviour**, not about this diff: a library that does other than its name says, a test disguise that kept the suite green over a live defect, a module rule the reviewers had to cite from its own prose, a measurement. A blocker fixed here is not knowledge; *why it was written wrong* may be. Same evidence rule as `/flow-feat-design` §8 — one line of evidence per finding or it is not staged. One call per finding, one line to the user («Staged N finding(s) for `postmortem`/`ship`»). Never `knowledge.save` here.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Stop body (after the flow-core §3 header): the findings that survived and what you did with each, plus the same Cost line as the Summary: "- Cost: <n>/<budget_max> subagents launched (<k> reviewers · <m> reinforcements · <s> skeptics), tier <light|proportional|full>".
-- **Autonomy handoff.** Only without blockers — with blockers, stop in every mode. **M/L**: `manual` → propose `/flow-bug-postmortem` with a single `AskUserQuestion`; `guided`/`auto` → chain into it in this same turn. **XS/S**: the next step is `ship`, which pushes and opens the MR/PR — a hard gate in **every** mode: stop here and propose `/flow-bug-ship` with a single `AskUserQuestion`, never chaining into it.
+- **Autonomy handoff.** Only without blockers — with blockers, stop in every mode (in `unattended`, question `high_findings` and the run ends, flow-core §2.1). **M/L**: `manual` → propose `/flow-bug-postmortem` with a single `AskUserQuestion`; `guided`/`auto` → chain into it in this same turn. **XS/S**: the next step is `ship`, which pushes and opens the MR/PR — a hard gate in **every** mode: stop here and propose `/flow-bug-ship` with a single `AskUserQuestion`, never chaining into it. In `unattended`, chain into `/flow-bug-ship`: it decides between a draft and a question.

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

@@ -23,6 +23,17 @@ Close the bug flow: commit, push, MR/PR. Same mechanics as `/flow-feat-ship`, wi
 1. If `99-postmortem.md` exists, **include the link or the executive summary** in the MR/PR description.
 2. The knowledge-consolidation offer was already made in `/flow-bug-postmortem` — do not ask again here.
 
+**In `unattended`** (flow-core §2.1) this command asks nothing — the same resolutions as
+`/flow-feat-ship`'s unattended paragraph, and its "In every mode" paragraph too, applied to the
+sections here: the MR/PR (§2–§3) is a draft only with `autonomy.unattended_ship: draft`, created as
+§3.1 says for a draft; otherwise question `ship` and the run ends; pre-deploy SQL → question
+`migration`. The tree check (§0) re-runs what is behind `HEAD` once per MR/PR, recorded as
+`/flow-feat-ship` says — here `validate` first, since it ran before the review, then the review on
+the delta — and is `blocked` after that. The
+performance comment (§3.3) is not posted; every offer and survey at Close (§4) — follow-ups,
+conventions, archiving — is `Later`; "was it merged?" is not merged; and Close writes the stop file
+with `reason: "done"` and `mr_url`.
+
 ## 0. Pre-flight
 
 Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, the live panel, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with; the wait it delegates takes `models.supervisors`.**
@@ -122,7 +133,7 @@ Determine whether the fix modifies the database (migrations, mappings/schema, or
 
 ## 2. Show to user and wait for confirmation (REQUIRED)
 
-**Never skip this step** — hard gate: the user approves what will be published before anything is created. Print in this exact format:
+**Never skip this step** — hard gate: the user approves what will be published before anything is created (in `unattended`, the unattended paragraph above decides it). Print in this exact format:
 
 ```
 ─── Preview of {MR or PR, per git.host} (fix) ──────────────────────────────────
@@ -156,7 +167,9 @@ Same as `/flow-feat-ship` §4.0: `git rev-parse --abbrev-ref HEAD` must not be t
 
 ### 3.1 Create MR/PR
 
-Only here — with the content approved in §2 — invoke `Skill commit-commands:commit-push-pr` passing **the final title and description**. The skill must not re-ask; if it does, answer with what was confirmed. If it pushes, it uses `git push -u origin HEAD`, never to the main base.
+**A draft (`unattended`) — read this first:** exactly as `/flow-feat-ship §4.1` says for a draft — never `commit-push-pr`, never the plain CLI; the forge CLI with its draft flag; a refused draft → `blocked`.
+
+Otherwise, only here — with the content approved in §2 — invoke `Skill commit-commands:commit-push-pr` passing **the final title and description**. The skill must not re-ask; if it does, answer with what was confirmed. If it pushes, it uses `git push -u origin HEAD`, never to the main base.
 
 Assign to `git.assignee` from FLOW.md (empty → unassigned). Squash per `git.squash`.
 

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

@@ -23,6 +23,15 @@ Start a bug. `$ARGUMENTS` is **optional**:
 - **Given** — a ticket (format `tracker.prefix` from FLOW.md) → *ticket mode*: start from it (§1 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop. Synthesize the bug from the conversation just held with the user (§1.5). Ask for a one-line symptom only if there is no conversation to draft from.
 
+**In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
+that table says. Here: a ticket is required — empty, or a tracker read that fails, ends the run
+`blocked` · uncommitted changes or a branch other than the main one (§3) → `blocked`: the runner
+owns the checkout · cross-repo scope (§1.6) → only the repos the ticket names · `git.worktree: ask`
+→ in place · a linked remote branch → skipped, nothing is pushed before `ship` · the tracker
+transition (§4.5) → as `auto`. **A thread that changes what the bug *is* (§1.1 precedence) waits
+until the branch and the work folder exist** — create them (§3, §4) first, write it into
+`01-context.md` as open, then question `clarify`; the next phase asks it first (flow-core §2.1).
+
 ## 0. Pre-flight
 
 Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, models, autonomy modes and hard gates, how a stop reads, the live panel, `00-summary.md`) — skip if you already read it in this session. **Models: this command runs with the model it was launched with (no `models` key).**

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

@@ -40,7 +40,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 Then:
 1. Run only that test with `quality.test_one` from FLOW.md; it must pass.
 2. Run the full suite with `quality.test` to rule out collateral regressions (in the background if slow; measured in tens of minutes → delegate it as a wait to a supervisor subagent on `models.supervisors`, flow-core §6.5 — it returns the exit code and the failing output, and the reading of them stays here).
-3. DB touched → verify the schema has no unexpected differences (`quality.db_update` or the FLOW.md equivalent, if defined).
+3. DB touched → verify the schema has no unexpected differences (`quality.db_update` or the FLOW.md equivalent, if defined; in `unattended` it is never run — a schema difference to apply is question `migration`, flow-core §2.1).
 4. Security or authentication touched → launch the `agents.security` agent from FLOW.md in parallel over the fix files (empty → `Agent general-purpose` with a security role).
 
 ## 2.5 Reproduce the original symptom against the running app
@@ -93,7 +93,7 @@ this is the same gate as a red test.
 
 ## 5. Close
 
-- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode.
+- Red test, regressions, **or the original symptom still reproducible in §2.5** → `phase` stays at `fix`; the user iterates. A red gate stops in every mode (in `unattended`, the run ends `blocked` with the failing test named, flow-core §2.1).
 - Green → `phase = "validate"`, add to `phases_done`; in the same write record `validated_sha` = `git rev-parse HEAD` — the tree the regression test passed on, which `/flow-bug-ship §0` reads. Suggest `/flow-bug-review`.
 - **Other bugs detected become `followups[]` entries** (flow-core §7) when they clear its bar — a reproducible symptom with someone who suffers it, not «this looks fragile» — per the output template.
 - **Stage what the validation taught** (`knowledge.stage` set; silence by default): a mutation that stayed green, a disguise the scenario wore, a fixture that could not produce the case — findings about how this codebase is tested, not about this diff. Same rule and evidence line as the review's Close.

package/adapters/hermes/skills/flow-doctor/SKILL.md

@@ -47,9 +47,6 @@ Print this **before** the environment checks: a key nobody set is the commonest
 below looks broken. Read against `examples/FLOW.template.md` — do not invent keys, and do report
 documented keys absent from the effective configuration (the "empty → fallback" rows).
 
-**This was the `config` command until v0.53.0.** One question — *what will the flow do in this repo* —
-had two commands answering different halves of it.
-
 ### 1.5.1 Effective config, per section
 
 For **every** documented key in `examples/FLOW.template.md`, one row:
@@ -105,7 +102,9 @@ supervisors  (empty)  →  the delegated waits (running pipeline, pending deploy
 empty key in `guided`/`auto` records it rather than asking. This block is where that record is read
 back.
 
-Aggregate `defaults_used[]` from every `.claude/work/*/meta.json`, **`_archive/` included**. One row
+Aggregate `defaults_used[]` from every `.claude/work/*/meta.json`, **`_archive/` included**, leaving
+out keys prefixed `unattended:` — those record how an unattended run resolved a stop, not a FLOW key
+with a line to paste. One row
 per key: the key, the default that was used, in how many works, and the last phase that used it.
 Sort by count, most-used first, and cap the block at the ten busiest keys with a count of the rest.
 
@@ -168,9 +167,15 @@ base branch resolvable — is §2 below; flag the key here, check the world ther
   run against a development or throwaway database, never a live one.
 - **Autonomy**: `autonomy.mode` empty → note it defaults to `manual` (every phase stops and, at the
   end, proposes the next command as a one-click confirmation — never runs it unconfirmed). Set →
-  echo the mode and remind that the hard gates stop and ask in every mode and that `guided`/`auto`
+  echo the mode and remind that the hard gates stop and ask in `manual`/`guided`/`auto` and that `guided`/`auto`
   never ask about the flow's own mechanics or anything already decided (both lists: `flow:flow-core`
-  skill §2). Unrecognized value → flag, `manual` assumed.
+  skill §2). Unrecognized value → flag, `manual` assumed. `unattended` → say what it does instead of
+  the gates (flow-core §2.1): nothing is asked, questions end the run in `.claude/work/stop.json` for a runner,
+  and `ship` is a draft only when `autonomy.unattended_ship` is `draft` — echo that value, or that it
+  is empty and ship will stop on a question. Say which file set it: every session that reads that file
+  — a person's included, when they share the checkout and the harness — stops asking too, so it
+  belongs in a FLOW file only the runner's environment has. `unattended_ship` set with any other mode → note it is ignored; a
+  value other than `draft`/`stop` → flag, `stop` assumed.
 
 ## 2. Checks