flow-workflows 0.81.0 → 0.82.1

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

@@ -26,7 +26,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 Invoked by `$flow-feat-review` and `$flow-bug-review` (duel over the diff), `$flow-work-respond` (a reviewer objected to a query), `$flow-feat-design` (access paths), `$flow-feat-build`, `$flow-feat-validate`. Invoke directly for any doubt outside them (chat question, comment on an open MR/PR, a year-old query).
 
-**Autonomy.** Modes as in flow-core §2. The duel, challenger count and whether to measure are flow mechanics — never a question, in any mode. **Hard gates — stop and ask, in every mode:** (1) **creating, seeding or dropping any database, schema or table**, including a throwaway one (§4) — show exact commands and target, never a database the project uses; (2) **any DDL** on a real database (index, column, collation) — the flow's schema gate; (3) editing code (output is a verdict, not a patch); (4) posting anything to an MR/PR or ticket.
+**Autonomy.** Modes as in flow-core §2. The duel, challenger count and whether to measure are flow mechanics — never a question, in any mode. **Hard gates — stop and ask, in every mode:** (1) **creating, seeding or dropping any database, schema or table**, including a throwaway one (§4) — show exact commands and target, never a database the project uses; (2) **any DDL** on a real database (index, column, collation) — the flow's schema gate; (3) editing code (output is a verdict, not a patch); (4) posting anything to an MR/PR or ticket. **In `unattended`** (flow-core §2.1) (1) and (2) are never done: the verdict is schema-only and says so; (3) and (4) do not apply, this command never edits or posts.
 
 ## 1. Resolve the subject
 

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

@@ -22,7 +22,11 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, auton
 
 **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.
 
-Use when returning to a work after a break (next morning, another session).
+Use when returning to a work after a break (next morning, another session) — including a work an
+unattended run left waiting on a person (flow-core §2.1).
+
+**In `unattended`** this command asks nothing: recap, name the next step, end. It is how a person
+reads where the run got to, not how the run continues.
 
 ## 1. Detection
 
@@ -45,6 +49,7 @@ Last updated:   <updated_at>
 Notes:          <meta.notes>
 Cross-repo:     <meta.related_repos entries not "done", as "repo: scope"; or "—">
 Ticket thread:  <new since <updated_at>: <n> comment(s) that change the work — detailed below · or "nothing new" · or "not read">   (line only in ticket mode, from §2.5)
+Unattended:     <from `.claude/work/stop.json` when its `work` is this one: `question` → the gate and the question, verbatim, with its options · `blocked` → the detail · `running` → "a run is working in <phase>, or died there, at <at>" · `done` → the MR/PR · `picked_up` → omit the line>   (line only when that file names this work)
 ```
 
 - `MR/PRs:` and `Waves:` from `meta.json.mrs` (same format as `$flow-work-status §2`). `∥` = can run in parallel, `→` = waits for the previous wave to merge.
@@ -86,6 +91,7 @@ With what is new (there is already work on disk):
 
 ## 4. Next step
 
+- A pending `question` in the `Unattended:` line → say that the next phase will ask it first (flow-core §2.1); the next step itself comes from `phase` as always.
 - Suggest the concrete command from `phase` and `size`. Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `$flow-feat-build` or `$flow-bug-fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `$flow-feat-start <TICKET>` there. flow only reminds; it never scans or touches the other repo.

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.81.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.82.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
@@ -177,15 +177,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.
@@ -210,7 +215,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. **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` |
+| 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
 
@@ -233,6 +343,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
@@ -251,7 +364,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`
@@ -723,7 +836,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

package/adapters/gemini/commands/flow/bug/fix.toml

@@ -48,6 +48,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.
@@ -114,13 +120,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/gemini/commands/flow/bug/investigate.toml

@@ -16,6 +16,11 @@ prompt = """
 
 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.gemini.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`.**

package/adapters/gemini/commands/flow/bug/postmortem.toml

@@ -93,5 +93,5 @@ 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/gemini/commands/flow/bug/review.toml

@@ -234,5 +234,5 @@ Cost line: count every subagent this command launched — reviewers = §2.1 buil
 - **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/gemini/commands/flow/bug/ship.toml

@@ -19,6 +19,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.gemini.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`.**
@@ -118,7 +129,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) ──────────────────────────────────
@@ -152,7 +163,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/gemini/commands/flow/bug/start.toml

@@ -19,6 +19,15 @@ Start a bug. `{{args}}` 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.gemini.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/gemini/commands/flow/bug/validate.toml

@@ -36,7 +36,7 @@ Read `~/.claude/flow/CORE.gemini.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
@@ -89,7 +89,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 — unless every failing test also fails on the base, the one exception that row records; the reproduction test lives in a file this diff touches, so it never qualifies).
 - 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/gemini/commands/flow/doctor.toml

@@ -98,7 +98,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.
 
@@ -161,9 +163,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
 

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

@@ -27,9 +27,9 @@ Implementation phase. Code is written here.
 - `size` XS/S: may start without a design — ask the user for a 2-3 line note on what will be done and save it as a minimal `03-design.md`. No MR/PR plan (always 1 MR/PR).
 - **If `meta.json.mrs` has more than one entry**: pick the **startable** MR/PR — the `pending` one with the **lowest `n` whose `depends_on` are all `merged`**. Dependencies still `pending`/`in_progress` → not startable, even with a low `n`. (No `wave`/`depends_on` — an older plan — → "first pending by `n`".)
   - **Parallel siblings**: startable `pending` MRs/PRs in the **same `wave`** with no dependency between them can be built in parallel or as a train. `manual`: let the user choose which to take now (default: lowest `n`); `guided`/`auto`: take the lowest `n`, record the choice. Mark the chosen one `in_progress`.
-  - All `merged` → warn: feature is done, nothing to build.
-  - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop.
-  - **Train/stacked**: this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow:feat:ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow:feat:start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow:feat:start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
+  - All `merged` → warn: feature is done, nothing to build (in `unattended`: `done`, `detail` saying so).
+  - Some `pending` but **none** startable → start nothing: tell the user which MR/PR must merge to unlock the next wave, and stop. In `unattended`: `blocked`, the detail naming it.
+  - **Train/stacked** (never in `unattended`: there the startable MR/PR gets a **new branch of its own** from `git.default_base`, created as `/flow:feat:start §5.2` (in place) or `§5.4` (worktree) says — `git.worktree: always` → worktree, `off`/empty/`ask` → in place; base `git.default_base`, already decided, so §5.1 asks nothing; `--no-track`, no linked remote branch — and never commits onto a previous MR/PR's branch; flow-core §2.1): this MR/PR needs its own branch stacked on the previous one — do **not** keep committing on the previous MR/PR's branch. `/flow:feat:ship §6.2` creates and links it when it chains here; if you arrived directly and are still on the previous branch, create it now per `/flow:feat:start §5` (explicit base = the previous MR/PR's branch, `--no-track`, worktree per `git.worktree`) and, for `tracker.tool: gh`, the linked-branch step `/flow:feat:start §5.5`. Record `stacked_on` in `meta.json`. The train does **not** wait for the previous MR/PR to merge.
 
 ## 2. Business brief (before typing)
 
@@ -59,6 +59,12 @@ Rules for writing it:
 
 In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by 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 build.
+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): the user reads it in the prompt they are answering, never by opening `05-implementation.md`. Write the file, run whatever you need, and *then* open the gate — **nothing runs between the brief and the question**, because a tool call after it is what lets a terminal fold the brief into one collapsed line, and the gate is answered blind. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
@@ -182,7 +188,7 @@ said in one line, never silently skipped. `manual` → offer it with `AskUserQue
 premise that X before building on it?"). `guided`/`auto` → run it and record it; it is flow
 machinery, not a decision.
 
-**The verdict, and the rule that makes it worth running.** **Refuted** → the brief or the design is
+**The verdict, and the rule that makes it worth running** (in `unattended`, *Refuted* ends the run as `blocked`, flow-core §2.1). **Refuted** → the brief or the design is
 wrong, not the code: stop, say what fell, and go back (§2.4 for a brief, `/flow:feat:design` for a
 contract) rather than patching around it. **Holds** → one row in §3 with what was read. **Unsettled
 stays unsettled** — the same rule as the query duel's *no number, no win*: it is recorded as an open
@@ -252,7 +258,7 @@ Warning thresholds:
 - **Real lines > `lines_est * 1.5`**, or
 - **Real files > `files_est + 2`**.
 
-If either is exceeded, **pause** and ask the user with `AskUserQuestion` (options, in this order):
+If either is exceeded, **pause** and ask the user with `AskUserQuestion` (options, in this order — in `unattended`, take option 2 and record it):
 
 1. **Cut here (recommended if the current piece is coherent)**. What is built so far stays as this MR/PR; what remains — the §2.0ter steps still pending, or what is left of `04-mr-plan.md` where that step was skipped — goes into a new one inserted in `meta.json.mrs` right after. Zero code wasted.
 2. **Continue and record the overrun**. When the cut would be artificial. Note the deviation in `05-implementation.md` to calibrate `/flow:feat:plan` on future tickets.
@@ -279,7 +285,7 @@ slip under a threshold buys itself the review a smaller change had earned.
 
 ### 2.4 Does something fall outside the brief?
 
-If during the build the temptation arises to add something **not in the §2 brief** ("while I'm here…", "this test would also cover X…", "this rename would improve Y…"), **pause before doing it** and ask the user with `AskUserQuestion`:
+If during the build the temptation arises to add something **not in the §2 brief** ("while I'm here…", "this test would also cover X…", "this rename would improve Y…"), **pause before doing it** and ask the user with `AskUserQuestion` (in `unattended`: *No, leave it out*, recorded):
 - **Yes, add it to the brief** — update the brief in `05-implementation.md` and continue. (If the addition is large, consider §2.3: it could trigger a MR/PR cut.)
 - **No, leave it out** — note it in the "Ideas for separate tickets" section of `05-implementation.md` **and append it to `meta.json.followups[]`** as `kind: "out-of-scope"`, `source: "build"` (flow-core §7): the section keeps it in context, the record is what survives the archive. **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. Continue with the original brief.
 

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

@@ -20,6 +20,12 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 Technical design phase. **Still no production code is written.** Opens the option space first (M/L), then designs the approach that was chosen. Output: a plan the next step executes.
 
+**In `unattended`** (flow-core §2.1) this command asks nothing. Panel and approach choice run as in
+`auto` · questions the options surfaced (§1.5.5) or an acceptance criterion that is ambiguous (§9) →
+question `clarify` · a size that no longer fits (§1.5.5, §7) → record the new size · a `high`
+challenge with no response (§6) → question `design_challenge`, the findings and their options in the
+stop file · the design review (§9) → recorded as accepted, as in `auto`.
+
 ## 1. Pre-flight
 
 - Load `meta.json` by current branch. Missing → ask the user to start with `/flow:feat:start`.

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

@@ -384,5 +384,8 @@ Write `.claude/work/<TICKET>/06-review.md`. The `Cost:` line of `## Summary` is
 - **Record what the agents missed** (flow-core §6.7, `agents.learn` not `off`; asking nothing): for each finding that survived, the panel member or named `agents.<role>` whose category it falls in and who did not report it, and the delegated `build` agent whose code it sits in → one `meta.json.agent_lessons[]` row each, only when the lesson passes the §6.7 test. The origins §2.1 carried are what make this possible — a finding with no origin teaches nobody.
 - **Configuration this phase earned the right to ask about** (flow-core §0, `manual` only, at most one key per work, as an extra option on this same stop — never a question of its own): a `Cost:` line that went over `agents.budget_max` → `quality.review_depth`. In `guided`/`auto` neither is asked: the default is taken and recorded in `meta.json.defaults_used[]`.
 - Report findings and next step **following the stop header** (flow-core §3) **when this is a stop**; in `guided`/`auto` with a clean gate the next command runs in this same turn, so this goes to `06-review.md` and the turn opens with the call that chains — the `Cost:` line then travels to the stop the run does reach, added to that phase's own. Include it once. Body: the findings that **survived** verification and what you did with each — a blocker, an applied fix, a rejection with its reason. Corrections to the reviewers' own reports go to `06-review.md`, not here.
-- **Autonomy handoff.** Only when there are **no blockers and no unresolved high-severity findings** — with any of those, stop in every mode (hard gate). Clean: in `manual`, propose `/flow:feat:validate` with a single `AskUserQuestion` and invoke it on confirmation; in `guided`/`auto`, **chain into `/flow:feat:validate` automatically** in this same turn. Never chain into `/flow:feat:ship` from here — ship is reached through `validate`.
+- **Autonomy handoff.** Only when there are **no blockers and no unresolved high-severity findings** — with any of those, stop in every mode (hard gate; in `unattended`, see below). Clean: in `manual`, propose `/flow:feat:validate` with a single `AskUserQuestion` and invoke it on confirmation; in `guided`/`auto`, **chain into `/flow:feat:validate` automatically** in this same turn. Never chain into `/flow:feat:ship` from here — ship is reached through `validate`.
+- **In `unattended`** (flow-core §2.1), blockers or unresolved high-severity findings are question
+  `high_findings`: the surviving findings in `question`, one line each, and the run ends. A person
+  picks it up in a session of their own, where they are fixed and reviewed again.
 """

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

@@ -20,6 +20,39 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 Closes the feature: commit, push, MR/PR (assigned per `git.assignee`, squash per `git.squash`, sections per `git.request_sections`) and an optional offer to consolidate knowledge.
 
+**In `unattended`** (flow-core §2.1) this command asks nothing, and it is the only place that run
+pushes. Each place it would ask:
+
+- **The MR/PR itself (§3–§4)** — `autonomy.unattended_ship: draft` → skip the confirmation and
+  create it **as draft** with the §2 content (§4.1 says how); never merge it, never mark it ready.
+  The body gains one line saying an unattended run opened it and nobody confirmed its brief.
+  Empty or `stop` → nothing is pushed: question `ship`, the §3 preview as the question, and the run
+  ends; a person ships it from a session of their own. Pre-deploy SQL in the branch → question
+  `migration`, whatever `unattended_ship` says.
+- **The §1 tree check** — `reviewed_sha` or `validated_sha` behind `HEAD` with more than tests →
+  re-run what is behind, **once per MR/PR**: the review on the delta, then `validate`. First record
+  `{ "key": "unattended:ship-recheck", "default": "mr <n>", "phase": "ship" }` in
+  `meta.json.defaults_used[]` — the record, not the context, is what remembers it; an entry with this
+  MR/PR's `n` already there → `blocked`, whatever the sha. Tracked changes this run's own phases left uncommitted → commit them
+  as WIP first (a WIP commit is `auto`'s to make) and check again · **blocking TODO/FIXME (§1)** →
+  continue and list them in the body.
+- **Posting anything else** — the performance comment (§4.3), a contract handoff (§6.3) — → not
+  posted; the numbers go in the body, the handoff stays `pending`.
+- **The offers and surveys (§5, §5.1, §5.2, §5.5, §6.4, §6.4bis)** → `Later`; nothing written outside
+  the work folder.
+- **"Was it merged?" (§6.1)** → not merged; `meta.json` as §6.1 says for an unmerged MR/PR. **The
+  parent merged first (§6.2.1)** → blocked, never force-push. **Train continuation (§6.2)** → not
+  started: one MR/PR per unattended run.
+- **At Close** write the stop file with `reason: "done"`, `mr_url`, and — with `mrs` still pending —
+  `detail` naming the next MR/PR and what it waits on (its `depends_on` merged, then
+  `/flow:feat:build`). It is the last thing the run does.
+
+**In every mode**, criteria `07-validation.md` marks `not-verified-unattended` go into the body under
+`## Not verified — needs a human`, with what to do for each — and so do the tests the suite left red
+because they also fail on the base (`unattended:validate-red-base`): each name, and the base sha
+where it failed too. The §3 preview shows that section like
+any other, and the person reading it is the check the run could not do.
+
 ## 1. Pre-flight
 
 - Read `meta.json` and `00-summary.md`; open in full only the `Brief MR/PR #N` of `05-implementation.md`, the `## Summary`/blockers of `06-review.md` and `07-validation.md`. (flow-core §5)
@@ -131,7 +164,7 @@ Determine whether the branch modifies the database (migrations, mappings/schema,
 
 ## 3. Show the user and wait for confirmation (MANDATORY)
 
-**Never skip this step, even when the content seems obvious.** Hard gate in every mode.
+**Never skip this step, even when the content seems obvious.** Hard gate in every mode — in `unattended`, the unattended paragraph above decides it.
 
 Print to the user in this exact format:
 
@@ -172,7 +205,14 @@ git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null   # must NOT be
 - Train mode (`stacked_on` ≠ null) → the MR/PR must target that parent branch, not the main base.
 
 ### 4.1 Create MR/PR
-Only here — with the content approved in §3 — invoke `Skill commit-commands:commit-push-pr` passing **the final title and description**. The skill must not re-ask for the content; if it does, answer with what was confirmed. Any push it does must be `git push -u origin HEAD` (own branch), never to the base branch.
+**A draft (`unattended`, flow-core §2.1) — read this first: it replaces the invocation below.** Do
+**not** invoke `commit-push-pr`, and do not use the plain CLI fallback below: both open a normal
+MR/PR. Commit, `git push -u origin HEAD`, and create it with the forge CLI and its draft flag
+(`gh pr create --draft`, `glab mr create --draft`, the equivalent elsewhere), assignee and squash as
+below. The forge refusing a draft → `blocked` with its message; never retried without the flag.
+Then record the URL, as the paragraph after the bullets says.
+
+Otherwise, only here — with the content approved in §3 — invoke `Skill commit-commands:commit-push-pr` passing **the final title and description**. The skill must not re-ask for the content; if it does, answer with what was confirmed. Any push it does must be `git push -u origin HEAD` (own branch), never to the base branch.
 
 - `git.assignee` not empty → assign to that user. `git.squash` `true` → enable squash-before-merge.
 - `commit-push-pr` skill unavailable → commit and push manually and create the MR/PR with the `git.cli` CLI from `FLOW.md` — always with the content confirmed in §3.
@@ -465,7 +505,7 @@ Read `meta.json.conventions_candidates[]` (flow-core §8). **No entries with `st
 
 ### 6.4ter Defaults that were used (one line, no question)
 
-`meta.json.defaults_used[]` non-empty → **one line** in the Close: how many empty `FLOW.md` keys this
+`meta.json.defaults_used[]` non-empty (keys prefixed `unattended:` not counted) → **one line** in the Close: how many empty `FLOW.md` keys this
 work resolved with their default, and that `/flow:doctor` lists which ones and prints the line to
 paste. Never a list here, and never a question: in `guided`/`auto` not asking is the contract
 (flow-core §0, §2), and in `manual` the phases already offered what they were allowed to offer.

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

@@ -23,6 +23,20 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 - **Given** — an identifier in `tracker.prefix` format from `FLOW.md` → *ticket mode* (§2 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop or demand a ticket. Draft a ticket from the conversation just held (§2.5), as `/flow:feat:ship` builds the MR/PR body from the work log. Ask for a one-liner 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` (there is no conversation to draft from and nobody to paste it) · uncommitted changes or a
+branch other than the main one (§5.1) → `blocked`: the runner owns the checkout · cross-repo scope
+(§3.5) → only the repos the ticket names · below-XS (§4) → open the work · `git.worktree: ask`
+(§5.0) → in place · §5.5's linked branch → skipped, it pushes a branch and nothing is pushed before
+`ship` · the tracker transition (§6.5) → as `auto`. **Clarifying questions (§2.1 precedence, §3)
+wait until the branch and the work folder exist** — create them (§5, §6) first, write the questions
+into `01-context.md` under "Decisions clarified at start" as open, then question `clarify` with all
+of them in one stop. Whoever picks the work up is asked them by the next phase, first (flow-core
+§2.1).
+A `blocked` before the folder exists still has the stop file: its path does not depend on the folder
+(flow-core §2.1).
+
 ## 1. Pre-flight
 
 - Read the effective FLOW configuration per flow-core §0; neither base nor active overlay → each