v0.103.0 — The project's roadmap: flow reads where you are and ticks off what ships

In short

• A roadmap above the ticket. Keep your plan as a markdown file of phases, milestones and checkbox tasks (ROADMAP.md, or any file you name in roadmap.path). flow reads it without being told.
• next, daily and resume say where the project stands — current phase, what is in progress and by which work, and the next item nobody has started.
• feat:start links the work to its item; feat:ship marks it in progress or ticks it off inside the MR/PR, so the roadmap moves with the code. Intermediate MRs/PRs of a train never touch it.
• roadmap.mark: never keeps a team document read-only; roadmap.path: none turns it off.

Closes #224.

v0.102.1 — From a worktree, flow finds the work it is in

In short

• next, daily and resume see your works from inside a worktree. Before, they said "nothing in flight" there, because the work folders only exist in the main checkout.
• From the main checkout they say which worktree each work lives in, so "where were we" is answered with a cd.
• Every phase finds its work the same way — by branch, by any MR branch of a train, or by the worktree it was created in — the way the session-start header already did.

Closes #223.

v0.102.0 — A query that entered after the review still reaches the MR with its plan

In short

• New queries and new tables get the performance comment too. Before, only a modified query
  did: a new query ships with its plan on the branch (base row new), a new table with its DDL,
  its indexes and the plan of the queries that read it.
• The review duels its own fixes. A blocker fixed in the round, or a scope widened when a
  finding asked, that adds a query is tried on its plan before the review closes. "No queries
  touched" now means none in the candidate and none in the fixes.
• Ship asks the re-review question on its own. Code the reviewers never read is a separate
  question, never a line inside the MR/PR preview, and when that code adds a query or a schema
  object the question names it: shipping as it stands leaves it unmeasured, and says so.

A bug fix widened its scope after a review finding and added a query that checked who owned the
record. The review had already written "no queries touched", the query was judged by reading it,
and ship folded "these lines were only reviewed by me" into the MR preview — so no plan was ever
taken and no comment was posted.

v0.101.0 — An approved study answers its own design questions too

In short

• after_study: recommended now reaches design, plan and investigate — once the work has
  crossed the door to code (05-implementation.md or 04-fix.md exists) and building sent it back
  to the study. Before that door nothing changes: --study sets handoff at start, before anyone
  approved anything.
• Still a person's call, in every phase the rule covers: a recommended option that adds
  another repository or changes a sibling's contract, and one that writes a schema object
  approved-schema.md does not list. A migration question in build, fix or review for an
  unlisted object now stops — the recommended answer used to take it past hard gate 3.
• A bundled challenge answer is judged response by response: one that widens the work stops
  the whole question.
• Answers given before plan wrote mrs go into the draft MR/PR under ## Decided without asking while no part is published yet.

A study approved with "take the recommended option" still stopped at every design question a gap
in the build sent it back to, and the answer — always the recommended one — came hours later on a
cold relaunch.

An unattended split builds every part without waiting for merges

In short

• publish --part … --stack when the orchestrator offers it. <cmd> ticket --json saying "stack": true means the orchestrator can stack a split's parts: ship passes --stack with every part, and the next part no longer waits for the previous one to merge.
• /flow:work:run routes why = next. Nothing merged: the published parts stay published, meta.json.base becomes the part published last (or the umbrella), and the next startable MR/PR is built on it — a published dependency counts as met on this route only.
• Without stack nothing changes: the next part waits for why = merged, as before.

Why
An unattended split used to stop after each part until a person merged it, so a split ticket left to run overnight was one part long in the morning. agent-runner v0.28.0 stacks a split's parts (mashware/agent-runner#481): each part's PR targets the part below it, and the orchestrator retargets and restacks on its own.

Upgrading
Nothing to configure. Only an orchestrator that says "stack": true changes anything.

A failure is called pre-existing only under the same load

• An unattended validate checks the base the way HEAD went red: same command, the whole suite when the whole suite failed, never the failing file alone.
• A test red in the suite and green on its own runs three times on each side, counts and durations recorded. Green on the base and red on HEAD even once → this diff made it, and the repair looks at what the diff adds under concurrency, never a longer timeout or a retry.

A part's merge that comes back no longer blocks the split

• /flow:work:run with why = merged and the merge already recorded goes on: a run that recorded a part's merge and then stopped is relaunched with the same merged. It used to block with «nothing published»; it now takes the next startable MR/PR, or closes the work.
• /flow:feat:plan knows a split's parts may not reach the default branch: in unattended, a part cannot wait for an earlier one to be released or deployed. The plan merges the two, or drops the wait and leaves the real-release check to a person on the MR/PR.

v0.99.0 — After an approved study, an unattended run answers its own questions

In short

• New key autonomy.after_study: recommended, read only in unattended. Once the work holds a
  study a person approved — a study run approved with why = start, or a study handed off from
  elsewhere — a question in build, fix, review, validate or ship no longer ends the run:
  it takes the recommended option and goes on in the same turn.
• Every question still reaches you, in the draft MR/PR. Each one goes to auto-answers.md and
  from there into the body under ## Decided without asking: the question, its options, the one
  taken checked. Disagree → ask for the change on the MR/PR.
• Three cases still ask: a question with no recommended option, a third high-findings round on
  the same MR/PR, and anything outside those five phases — the study itself, respond and green.
• Empty or ask → nothing changes.

An unattended build stopped on a question whose recommended option was the one the person would
have picked, and the answer came hours later — a relaunch that started cold, without the context or
the cache of the run that asked. With the study approved, the person had already decided what
mattered; the rest can wait for the MR/PR.

v0.98.0 — One overview, and it knows what you merged

In short

• /flow:work:status is gone; /flow:work:daily is the one overview. Everything only status
  showed moved in: one block per open work (phase, MR/PR states, size against the estimate,
  measured cost), log against git on the current branch, orphaned branches and folders, residue.
  With forge and tracker unavailable it is still the full local picture.
• An MR/PR merged outside flow no longer looks in progress. daily asks the forge for the real
  state of every MR/PR a work recorded as open; merged or closed there → merged on the forge, work
  still says in progress, pointing at /flow:work:clean (last part) or /flow:work:resume (more
  parts planned). Read-only: clean still writes the verdict.
• "You" is the authenticated account, never a name. Tickets assigned to you come from
  assignee = currentUser() on Jira and @me on GitHub/GitLab; review threads compare your login
  to the author's username. tracker.assignee overrides it only as an exact id or email, and
  {ASSIGNEE} no longer falls back to git.assignee — a forge username is not a tracker account.
• The Jira examples now run. start_cmd, done_cmd and abandon_cmd use --key/--status/
  --yes and --assignee, the syntax acli accepts; the positional form they showed was refused.

Two developers sharing a first name ran daily, and one got the other's tickets: the tracker
query was left to the model, which matched by name. The same user had been using status to see
what was in flight after a busy day — it read only meta.json, so every MR merged on the forge
still showed as in progress until each work was resumed one by one.

v0.97.2 — An update to an open MR/PR no longer declares a part

• Updating an MR/PR that is already open publishes without --part/--of. /flow:work:green and /flow:work:respond used to repeat the part ship declared; an orchestrator may refuse a part on a run launched for a pipeline, a conflict or a review.
• A refused closing order can be corrected once. An order that exits ≠ 0 closed nothing: when its error names something the run wrote — an argument, a file, an uncommitted tree — the run fixes it and sends the same order again. A second refusal still ends the run.