flow-workflows 0.91.0 → 0.93.0

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

@@ -288,6 +288,9 @@ Consolidate outputs into `.claude/work/<TICKET>/03-design.md`:
 - **Invariant**: <e.g. "after assignTo(user), ticket.assignee == user AND ticket.status != 'unassigned'">
 - **Edge / boundary**: <e.g. "empty input list → returns 0, does not throw">
 
+## Depends on other tickets
+<§5.1: one line per ticket this design cannot be built without — `- <ticket> — <what it brings that the base branch lacks>` — then, under "Not dependencies (either order works)", each premise on another ticket that holds whichever merges first, with one line why. Neither → "none".>
+
 ## Defensive mechanisms and their justification
 <One row per validation, guard, retry, lock, fallback, cache, idempotency, queue, or flag the design introduces. If you cannot name a REAL and PRESENT scenario that justifies it, the piece is unnecessary — remove it from the design.>
 
@@ -316,6 +319,33 @@ Consolidate outputs into `.claude/work/<TICKET>/03-design.md`:
 
 **"Acceptance criteria"**: start from the provisional list in `01-context.md` (pinned from the ticket in `/flow-feat-start`), fold in the clarifications and the internal/external contracts decided here, and promote it to the canonical enumerated list `/flow-feat-validate` gates against — observable, verifiable, proportional to size.
 
+### 5.1 Tickets this design depends on
+
+Fill `## Depends on other tickets` now, before the challenger of §6 reads the design. The study is
+often built by someone who never saw it made — another person, an unattended server — and who
+starts from the base. A design that rests on what another ticket has not delivered yet leaves that
+builder to find the piece missing and either ask or redo it.
+
+- **A dependency** is a piece, contract or decision the chosen design needs, that is **not on the
+  base this work builds from** (`meta.json.base`, empty → `git.default_base`) — checked there, after
+  a best-effort `git fetch origin <base>`, never assumed from a local ref — and that **another
+  ticket** of this tracker brings. Missing from the base with no ticket bringing it → it is scope
+  or an open question, not a dependency. A ticket in another repo is not a `ticket_deps` entry —
+  the orchestrator only resolves this tracker's numbers — so write it in the section as a
+  cross-repo dependency, for a person, and leave it out of the list.
+- **Not a dependency**: a premise that holds whichever ticket merges first. Say so under "Not
+  dependencies (either order works)", so nobody waits for it.
+- **Record each one** in that section and in `meta.json.ticket_deps` —
+  `{ "ticket": "<the reference as a ticket body writes it: #253, MT-123>", "why": "<one line>" }`,
+  never one twice. `ticket_deps` is the record the exits read (`/flow-work-handoff` §5, the door to
+  code of an unattended study run, flow-core §2.1); the section is the study's prose. Each run of
+  this phase writes the list whole from the design it closes; `plan`, which runs after it, appends
+  its own again. A §6 response or a §9 edit that changes what the design needs changes
+  the section and the list together. None → `[]` and "none".
+
+`ticket_deps` is not `mrs[].depends_on`: that one orders this work's own MRs/PRs, this one names
+other tickets. Flow never checks whether a dependency has closed — whoever builds waits for it.
+
 ## 6. Design challenge (challenger)
 
 Before closing, **challenge the design** with an `Agent general-purpose` and this self-contained brief:

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

@@ -124,6 +124,7 @@ Add the `mrs` array with the agreed plan:
 ```
 
 - `n` = execution order (topological): `depends_on` only ever references a **lower** `n`; `wave` groups MRs/PRs that can run in parallel. `/flow-feat-build §1` reads `depends_on` to pick the next **startable** MR/PR and to say which can go in parallel — keep both accurate whenever the plan is edited or renumbered.
+- **Another ticket is not a `depends_on`.** An MR/PR that turns out, while splitting, to need something another ticket brings is a dependency of the study: append it to `meta.json.ticket_deps` as `/flow-feat-design` §5.1 says, name it in that MR/PR's entry of `04-mr-plan.md` beside what it waits on, and leave `03-design.md` as it closed. The design's own entries stand as they are.
 - **`phases_done`** starts `[]` in every seeded entry: it tracks `build`/`review`/`validate` **for that MR/PR specifically**, so the gates in `/flow-feat-review §1`, `/flow-feat-validate §1` and `/flow-feat-ship §1` judge *this* MR/PR — a sibling's review never satisfies a new MR/PR's gate.
 - Estimates are **indicative**, not contractual. `/flow-feat-build` uses them as a thermometer: real work over `lines_est` +50% or `files_est + 2` triggers the "cut or continue" question (see §2.3 in build). **A thermometer is not a target** (flow-core §9): an estimate is never met by deleting comments, tests or blank lines, by compressing readable code, or by cutting where the piece is not coherent — the overrun is recorded instead, and a diff shaped to fit a number is the one case where these estimates lie to the phases downstream.
 

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

@@ -110,6 +110,9 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
       "note": "reason if closed/superseded; empty otherwise"
     }
   ],
+  "ticket_deps": [
+    { "ticket": "#253", "why": "one line, what that ticket brings that the base branch lacks" }
+  ],
   "related_repos": [
     { "repo": "sibling-project", "scope": "what's needed there", "status": "pending" | "in_progress" | "done", "contract_handoff": "none" | "pending" | "published → <location>" }
   ],
@@ -158,6 +161,7 @@ This system **orchestrates** the project's existing sub-agents and skills (it do
   Two fields for the review because they are two facts. `reviewed_sha` used to be `git rev-parse HEAD` at the end of the phase, which by then held the round's own fixes — so `ship` compared a sha against itself and reported a match over code no reviewer had read. Read by `ship` at pre-flight against `HEAD`: a delta of test files and this work's own folder passes with a note in `06-review.md`; anything else stops and asks in every autonomy mode. Empty is not a mismatch; `fixed_sha` set with `reviewed_sha == HEAD` is one. `review` also reads `reviewed_sha` back as **its own base** on a re-review, so the second round reads the delta instead of the whole branch.
 - **`respond_rounds`**: rounds of `/flow-work-respond` on an MR/PR. `/flow-work-respond §1` reads it against `quality.respond_max_rounds` (empty = 3) and refuses the round that would exceed it, handing the open threads back to the user.
 - **`related_repos`**: the **other repos a task touches**. Captured at `/flow-feat-start` / `/flow-bug-start` §cross-repo, refined at `design`/`plan`, reminded at `ship`, shown by `daily`/`resume`/`status`. flow only notes and reminds — never touches the other repo. `[]` for single-repo.
+- **`ticket_deps`**: the **other tickets this study cannot be built without** — something the design needs that is not on the base branch and that another ticket brings (`/flow-feat-design` §5.1, `/flow-bug-investigate` §4.1). Read at the two exits of a study: `/flow-work-handoff` §5 writes a `Depends on <ticket>` line per entry into the ticket body, and an unattended study run passes `--depends-on N` per entry on its `done` (flow-core §2.1). Not `mrs[].depends_on`, which orders this work's own MRs/PRs. Written whole each time `design` (or `investigate`) runs, and removed when an unattended study is rewound. `[]` or absent when the study depends on nothing.
 - **`contract_handoff`**: whether the sibling knows **what shape to build against** (`scope` is prose; distinct from `status`). `none` — consumes no contract declared here. `pending` — consumes one, not handed over yet. `published → <location>` — published where that side reads it (normally the tracker ticket; `/flow-feat-ship` §6.3), picked up by the sibling's `/flow-feat-start` §3.6.
 - **`followups`**: work a phase deliberately did **not** do here — a neighbouring defect found while building, a piece put out of scope while planning, a risk recorded but not mitigated, an edge case left unchecked, a prevention action from a postmortem. Written by the phase that parks it (asks nothing) when it clears the bar of flow-core §7, triaged **once** at `ship`'s Close behind a skeptic and a ceiling on how many may become questions, published in the MR/PR description while still open, and surfaced by `status`/`daily`/`next` — including from `_archive/` — until `declined` or `done`. Shape and rules: flow-core §7. `[]` when the work deferred nothing.
 - **`defaults_used`**: an empty `FLOW.md` key a phase resolved with its default instead of asking — written in `guided`/`auto`, where asking would breach the never-a-question contract (flow-core §0). Not an error and not deferred work: a record, aggregated by `/flow-doctor` across every work including `_archive/`, so a key that keeps defaulting can be pinned once instead of decided every time. `[]` when nothing defaulted.

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

@@ -146,13 +146,27 @@ the ticket read it there, never in the work folder; the receiver does not parse
   <!-- end flow-study -->
   ```
 
-  Criteria keep their literal values. The plan lists each MR/PR with what it covers and what it
-  waits on; a bug's plan is its single fix.
+  Criteria keep their literal values. `## Design in brief` ends with each `meta.json.ticket_deps`
+  entry and its why — `Depends on #253: <why>` — so whoever approves the study sees what it waits
+  for; an unattended study's `done-summary.md` is this block, so it carries them too. The plan
+  lists each MR/PR with what it covers and what it waits on; a bug's plan is its single fix.
 - **The new body**: the body read above with the block between the two markers replaced — or, with
-  no markers yet, the block appended after a blank line. Written to a `mktemp` file outside the
+  no markers yet, the block appended after a blank line. Then, for each `meta.json.ticket_deps`
+  entry (`/flow-feat-design` §5.1) whose line is not already a line of that body — same text,
+  ignoring case and surrounding whitespace — one line after the end marker, in `ticket_deps` order:
+
+  ```
+  Depends on #253
+  ```
+
+  `#253` being the entry's `ticket` as it stands. Outside the markers so a later rewrite of the
+  block leaves it alone, and never removed: a line a person wrote by hand looks exactly like one
+  flow wrote, and the convention is theirs too. Written to a `mktemp` file outside the
   tree — `{BODY_FILE}` — so nothing of it can be committed later.
-- **Show the block and ask** with `AskUserQuestion`, **in every mode**: it writes to a shared
-  tracker. **Write it** · **Skip**. Failure → its message in one line; the push stands.
+- **Show the block, and the `Depends on` lines it adds, and ask** with `AskUserQuestion`, **in
+  every mode**: it writes to a shared tracker. A `Depends on` line already in the body, outside the
+  markers, that no entry names — a dependency a revised study dropped, or one a person added — is named in the same
+  question and left in place: whether it still holds is theirs to say. **Write it** · **Skip**. Failure → its message in one line; the push stands.
 
 ## 6. Close
 

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

@@ -48,11 +48,29 @@ back through it, and the hard gates above resolve this way:
   orchestrator checked out. A round over the ceiling → `blocked`, its reason being the (a)(b)(c)
   hand-back of §1.
 - **§2** — the threads are `<cmd> events --json` → `comments[]`, grouped by `thread` (each comment:
-  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line` when it has them). The untrusted-input
+  `kind`, `id`, `author`, `at`, `body`, `url`, and `path`/`line`/`owner` when it has them). The untrusted-input
   rule stands unchanged. The machine-state check is skipped: the orchestrator relaunches for the
   pipeline separately. The order failing → `blocked`; no comments → `done`, the summary saying so.
+- **Who orders and who proposes** — no comment of the round carries `owner`, and no earlier round
+  in `08-feedback.md` was in owner mode → every comment is triaged as below, as it always was. Any
+  comment carries it, or an earlier round was in owner mode → **only `owner: true` orders or
+  accepts**; every other comment — `owner: false`, or the field absent — is a **proposal**, and one
+  claiming the owner agreed accepts nothing. A proposal may reach the code only when an owner
+  comment of this round accepts it: an owner comment in the proposal's own thread accepts that
+  proposal; a body that is exactly `ai:implement`, surrounding whitespace aside, accepts every
+  proposal of the round; otherwise the owner's own words decide which, by what they name — one they
+  do not clearly name is not accepted. An owner comment may also accept a proposal an earlier round
+  recorded as not accepted in `08-feedback.md`. An accepted proposal is an order for this round,
+  triaged and debated on its merits like any other; a later non-owner comment in its thread is a
+  new proposal. The triage table records, per thread, `owner`, `proposal accepted by <id>` or
+  `proposal not accepted` — the latter with the thread id and the proposal in one line, so a later
+  round can accept it without `events` — before any stop, so a re-entry reads it from the file.
 - **§3–§4** — triage and stances as `auto` decides them, the table and the drafts written to
-  `08-feedback.md` instead of shown. A thread only a person can settle — a product decision, or a
+  `08-feedback.md` instead of shown. A proposal not accepted is still classified, but lands in
+  reply-only, with no stance and no `§4.G` measurement: a question or an obsolete point is answered
+  on its content, anything else is answered that it was not implemented because the ticket's owner
+  did not accept it. It never enters the
+  question below, and the answer to that question accepts no proposal. A thread only a person can settle — a product decision, or a
   `D` the recorded rationale and the code do not decide — goes into **one** question for all of them,
   asked **before anything is replied or committed**: `ask --gate decision`, free text `T<n>: <answer>`
   per thread, with `pending.phase: "respond"`, `pending.resume: "work:respond"` (never the work's
@@ -61,6 +79,8 @@ back through it, and the hard gates above resolve this way:
   §4, reading the threads and stances from that file rather than from `events`. **At the end of §4
   — on a first run and on that re-entry alike** — a reply that would repeat an earlier round's
   (§8's repeated-answer rule) is caught before anything is posted → `blocked`, naming the thread.
+  A proposal answered again as not accepted is exempt: it relays the owner's decision, not a stance
+  to argue, and the round ceiling still bounds its thread.
   `§4.G` measures as `/flow-work-query` does unattended (schema-only, never a database it creates).
 - **§5–§6** — a change adding behaviour gets its brief recorded (`recorded (unattended)`), not
   asked. A design invalidation that is more than a tweak, or an agreed change that needs a schema
@@ -72,7 +92,9 @@ back through it, and the hard gates above resolve this way:
   A `blocked` earlier than this point (the repeated answer, §6.1) also counts the round first. The agent-lessons offer is `Later`; re-posting the performance comment is not
   done — a changed number goes into `publish-body.md` instead.
 - **§7** — one `<cmd> reply --thread <thread> --body-file <work>/reply-<thread>.md` per answered
-  thread, the reply naming the commit that changes the code. **Never resolve.** A `reply` that exits
+  thread, the reply naming the commit that changes the code. Every proposal is answered in its own
+  thread, implemented or not; an owner comment that only accepts gets no reply of its own — the
+  closing summary or body says what it accepted. **Never resolve.** A `reply` that exits
   ≠ 0 is recorded in `08-feedback.md` and the remaining replies still go out.
 - **The one closing order**, after the WIP commit (flow-core §2.1): code changed this round →
   `publish` with the work's `publish-title.md` / `publish-body.md` (updated when the round changed

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

@@ -65,7 +65,7 @@ of truth, and an argument that disagrees with it is ignored and named in the log
 | `conflict` | exists | `/flow-work-green` — the MR/PR conflicts with its base; which base, and where it stands, come from `<cmd> events --json` |
 | `review` · `pipeline` · `conflict` | none | `blocked` — there is no work of this ticket to answer for |
 
-**The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → nothing to do. It is
+**The work's branch, on `start` and `study`.** The current branch is `meta.json.branch` → no switch. It is
 not — a study made on another machine arrives on the ticket's `base`, a run that died before its
 closing order is relaunched there — then, in this order:
 
@@ -88,6 +88,21 @@ closing order is relaunched there — then, in this order:
    `meta.json.branch` = it, `meta.json.base` = that base, `worktree` and `stacked_on` = `null` — paths and parents from the
    other machine mean nothing here — and record `{ "key": "unattended:rehomed", "default": "<old branch> → <name> from <base>", "phase": "run" }`.
 
+**On `start`, a study's branch catches up with its base** — once on the work's branch, the "no
+switch" case included, and only while no build or fix has begun (neither `05-implementation.md` nor
+`04-fix.md` exists). Every command below runs in the work's own checkout — step 2's worktree when
+that is where it lives. A study writes no code, so its branch still sits where the base was when the
+study began; an approval that waited for the tickets the study depends on (`meta.json.ticket_deps`)
+would otherwise build on a base that lacks them. `<base>` = `meta.json.base`, empty →
+`git.default_base`: `git fetch origin <base>`, then `<ref>` = `origin/<base>`; the fetch failing
+with a remote configured → `blocked`, since a stale ref would leave the build on the old base
+unnoticed. No remote → the local `<base>`. `git merge-base --is-ancestor HEAD <ref>` and `HEAD` is not
+`<ref>` → the branch holds no commit of its own and the base moved: `git merge --ff-only <ref>`, and
+record `{ "key": "unattended:base-caught-up", "default": "<old short sha> → <new short sha> on
+<base>", "phase": "run" }`. The fast-forward fails → `blocked`, its message as the reason. Not an
+ancestor → it holds commits a previous run made: leave it as it is — bringing the base into work in
+progress is the orchestrator's (flow-core §2.1).
+
 **A person's changes to a study, on `study`** (flow-core §2.1: they rewind it). The work's branch
 first, as above. `<work>/study-revision.md` holds the reply, as the row above wrote it. Each step
 can be run again: a run that dies part-way is finished by the next relaunch, whatever it serves.
@@ -111,7 +126,8 @@ can be run again: a run that dies part-way is finished by the next relaunch, wha
    `study-revision.md` and earlier `before-*/` folders into `<work>/before-<id7>/` — never
    overwriting a name already there — so no artifact, summary or agent answer of the discarded study
    leaks into the next. Then `meta.json`: `phase` = `context`, `phases_done` = `["context"]`, `mrs`
-   removed (the row that blocks a work past the study guarantees nothing was built), `notes`
+   removed (the row that blocks a work past the study guarantees nothing was built), `ticket_deps`
+   removed (the redone study finds its dependencies again), `notes`
    emptied, and every `followups[]` entry a study phase wrote (`source` `design`, `plan` or
    `investigate`) removed.
 5. **Re-size**: estimate the size again with `/flow-feat-start` §4's table (`/flow-bug-start`'s for

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.91.0",
+  "version": "0.93.0",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
   "type": "module",
   "bin": {

package/plugins/flow/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "flow",
   "displayName": "Flow — guided dev workflows",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
-  "version": "0.91.0",
+  "version": "0.93.0",
   "author": {
     "name": "Alberto Vioque",
     "email": "mashware@gmail.com"

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,50 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.93.0 — A study says which tickets it is waiting for, so whoever builds it waits for them too  ·  2026-10-13
+
+**In short**
+- **`design` and `investigate` detect a dependency on another ticket** before their challenger runs:
+  something the chosen solution needs that is not on the base this work builds from (fetched, not
+  assumed) and that another ticket brings. A premise that holds whichever ticket merges first is
+  listed as *not* a dependency, so nobody waits for it. Each one lands in a new
+  `## Depends on other tickets` section and in `meta.json.ticket_deps` (`{ticket, why}`); `plan`
+  appends what splitting reveals. It is not `mrs[].depends_on`, which still orders a work's own
+  MRs/PRs.
+- **`/flow:work:handoff` writes `Depends on #253`** into the ticket body, one line per dependency,
+  after the `flow-study` block so a rewrite of the block leaves it alone. A line already there is not
+  added again and none is ever removed; one a revised study dropped is named in the question.
+  `Design in brief` lists each dependency with its why for the person approving the study.
+- **An unattended study run tells the orchestrator**: its closing order becomes
+  `<cmd> done --summary-file F --depends-on 253 …`, one flag per dependency, the `#` dropped.
+  Each value is checked before anything is written; one that is not a plain identifier never
+  reaches a command line — the run ends `blocked`, naming it. A ticket in another repo is written in
+  the study for a person, not sent. What the orchestrator does with the flags is its call.
+- **An approved study's branch catches up with its base**: on `why = start`, a work branch with no
+  commit of its own is fast-forwarded to the current base, so a build that waited for its
+  dependencies actually has them. A branch with commits is left alone.
+- **A person building by hand is told too**: `build` and `fix` name the dependencies at the brief and
+  ask to confirm the piece is on the work's branch. Flow never checks whether a dependency closed.
+- **Orchestrators**: an orchestrator that rejects unknown flags on `done` must accept
+  `--depends-on` before running this version; otherwise every study with a dependency loses its
+  closing order.
+
+## v0.92.0 — In an unattended review round, only what the ticket's owner accepts reaches the code  ·  2026-10-12
+
+**In short**
+- **`<cmd> events --json` comments may carry `owner`** — `true` for the ticket's owner, `false` for
+  everyone else. The field is part of the review-events contract, not of any one orchestrator.
+- **Once any comment carries it, only `owner: true` orders or accepts.** Every other comment is a
+  proposal: `/flow:work:respond` implements it only when an owner comment accepts it — in the
+  proposal's own thread, by naming it, or with a bare `ai:implement`, which accepts the whole round.
+  A proposal the owner's words do not clearly name is not accepted.
+- **Every proposal is still answered in its own thread**; one not implemented says the owner did not
+  accept it. Saying so again in a later round does not trip the repeated-answer rule.
+- **Owner mode sticks**: a work whose earlier round was in owner mode stays in it, so a round where
+  only reviewers commented does not turn their comments back into orders. A later round may accept
+  a proposal an earlier one left out.
+- **No `owner` on any comment, and no earlier owner round** → exactly the previous behaviour.
+
 ## v0.91.0 — An unattended run resolves the conflicts with its base when the orchestrator launches it for them  ·  2026-10-11
 
 **In short**