Parked questions say who decides (9.3.2)

.agents/plugins/marketplace.json

@@ -6,7 +6,7 @@
   "plugins": [
     {
       "name": "flow-next",
-      "version": "9.3.1",
+      "version": "9.3.2",
       "source": {
         "source": "local",
         "path": "./plugins/flow-next"

.claude-plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Plan-first workflows for Claude Code and Factory Droid. Ships flow-next: zero-dep, spec-driven, unattended flow --auto runs.",
-    "version": "9.3.1"
+    "version": "9.3.2"
   },
   "plugins": [
     {
       "name": "flow-next",
       "description": "Zero-dependency, spec-driven agentic SDLC: durable specs, context-fit plans, re-anchored workers, adversarial cross-model review, and receipts. Includes 21 subagents, 26 commands, 29 skills.",
-      "version": "9.3.1",
+      "version": "9.3.2",
       "author": {
         "name": "Gordon Mickel",
         "email": "gordon@mickel.tech",

CHANGELOG.md

@@ -6,6 +6,12 @@ Flow-Next changed shape with 5.0.0. One command, `/flow-next:flow`, reads whatev
 
 ## Unreleased
 
+## [flow-next 9.3.2] - 2026-10-27
+
+### Fixed
+
+- **A question that waits on someone else now says who decides, so each role can find its own.** When a conversation hands a decision to someone who isn't there ("product decides"), capture parks it under `## Open Questions` with its owner, `*(owner: product)*`, where it used to land among the unknowns with no owner. Refine accepts any role, not only product or engineering, and once the owner answers it moves the answer into the section it belongs to. Backlog mode's parked questions carry the same tag. A product owner, QA lead or engineer can ask the agent for the open questions for their role across every branch, or have a scheduled task post them to chat: [For teams](https://flow-next.dev/guides/for-teams/#questions-that-wait-on-someone-else) walks through it. Nothing to configure, including in a repository with its own `SPEC.md`.
+
 ## [flow-next 9.3.1] - 2026-10-25
 
 ### Fixed

SPEC.md

@@ -32,6 +32,7 @@ auxiliary_sections:
   - Resolved via Experiment  # written by /flow-next:refine when a question was settled by running something
   - Resolved via Research    # written by /flow-next:refine --scope=research, or by plan when its research scouts ran
   - Parked unknowns          # optional fog slot; one bullet per genuinely-unknown item, emptied as they resolve
+  - Open Questions           # a decision for someone outside the conversation; each names its owner role
   - Requirement coverage     # written by /flow-next:capture only when it judges the route plan; /flow-next:plan fills it; closes the body unless you place it as a heading
 template_kind: static-scaffold  # no {{var}} substitution; read for structure, write via flowctl spec set-plan
 ---
@@ -51,10 +52,12 @@ free. Renaming or removing `## Acceptance Criteria`, `## Boundaries`,
 the features that parse them (R-ID coverage, PR "Not in this PR", the PR
 briefing's context and decision excerpts).
 
-/flow-next:capture writes the sections this file names and adds none it leaves out.
+/flow-next:capture writes the sections this file names and adds none it leaves out,
+except `## Open Questions`: a question handed to someone else is always kept.
 Auxiliary sections are named in the frontmatter `auxiliary_sections` list. Drop an
 entry (e.g. `Conversation Evidence`, which no tool reads) and captured specs stop
-carrying it. A SPEC.md with no such list gets no auxiliary sections.
+carrying it. A SPEC.md with no such list gets no auxiliary sections except
+Open Questions.
 
 Full guide:
 flow-next docs, "Customizing the scaffold for your project"
@@ -179,13 +182,29 @@ byte-for-byte by every other writer; only `refine --scope=research --force`
 replaces it.
 -->
 
+<!--
+OPTIONAL AUXILIARY SECTION — `## Open Questions`:
+Written by capture, refine and flow's backlog mode when a decision belongs to
+someone who is not in the conversation ("product decides", "ask security"). One
+bullet per question, naming who decides as a role, never a person:
+
+- **<question>** — for <owner> to decide; leaning <X>. *(owner: <role>)*
+
+<role> is product, engineering, or the team's own word (qa, security). Teammates
+find the questions for their role by that tag, on any branch. When the owner
+answers, the answer moves into the section that owns it and the bullet is
+deleted; a question posted to the tracker keeps its anchor, marked answered.
+-->
+
 <!--
 OPTIONAL AUXILIARY SECTION — `## Parked unknowns`:
 Written only when the spec actually carries fog. One bullet per genuinely-unknown
 item, each passing the fog-or-ticket test: decidable now → decide it here and now,
 so it never reaches this section; resolvable by scheduled work → make it a task or
 a ticket; genuinely unknown (needs a decision, an experiment, or an outside answer
-nobody has yet) → park it here, one line, naming what would resolve it.
+nobody has yet) → park it here, one line, naming what would resolve it. A
+decision someone can make but who is not in the conversation is not fog: it goes
+to `## Open Questions` with its owner.
 
 Graduate-on-resolution: the moment refine or plan resolves a parked item, its
 answer moves into the canonical section that owns it and the bullet is DELETED

agent_docs/conduct/refine.md

@@ -6,6 +6,6 @@ A correct run asks only the questions whose answers would change what gets built
 - [ ] Every question goes through the blocking question tool, and each body carries a stakes sentence, a named recommendation with its rationale, and one confidence tier (`[high]`, `[judgment-call]`, `[your-call]`). Each round asks the whole current frontier, never pairs a question with its own prerequisite, and names an abandoned branch at the next round's opener. A transcript that prints "Question 1: ..." as plain narration has broken this.
 - [ ] Codebase-, project-docs-, and experiment-answerable questions are resolved by investigation and logged under `## Resolved via Codebase`, `## Resolved via Project Docs`, or `## Resolved via Experiment` with evidence, instead of being put to the user — an experiment runs automatically only when read-only or fully disposable, and an inconclusive result goes to the user with the data. A stateful experiment run automatically, or a "should we" question answered by grep, has broken this.
 - [ ] Skipped questions land under `## Open Questions` with the unconfirmed leaning and an owner hint, never as decided content; with one or more skips, the write-back consent checkpoint is asked before the spec is written. Answers are recorded at the precision given: a preference goes to `## Decision Context`, and a numeric criterion appears only when the user stated the number.
-- [ ] Sections no answer belongs in and the auxiliary sections come back byte-for-byte, and acceptance-criteria R-IDs are appended, never renumbered or replaced. The one sanctioned deletion is a `## Parked unknowns` bullet this session resolved, whose answer appears in the section that owns it.
+- [ ] Sections no answer belongs in and the auxiliary sections come back byte-for-byte, and acceptance-criteria R-IDs are appended, never renumbered or replaced. The sanctioned changes are deleting a `## Parked unknowns` bullet or an unanchored `## Open Questions` entry this session resolved, whose answer appears in the section that owns it, and flipping an anchored `## Open Questions` entry to `status=answered` with its answer under it.
 - [ ] The completion summary reports the question count (zero with "the spec is clear enough to build"), the skip disposition when there were skips, and every section the session changed; for a spec without tasks the next step recommends `/flow-next:work <id> --no-plan` for a ready cohesive spec, with plan only where decomposition is useful.
 - [ ] Under `--scope=research`, before any scout dispatch the run says which case applied (skipped with its reason, a delta rerun, `--force`, or the scouts it dispatches); the pass asks no questions and writes only `## Resolved via Research`.

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

@@ -1,6 +1,6 @@
 {
   "name": "flow-next",
-  "version": "9.3.1",
+  "version": "9.3.2",
   "description": "Zero-dependency, spec-driven agentic SDLC: durable specs, context-fit plans, re-anchored workers, adversarial cross-model review, and receipts. Includes 21 subagents, 26 commands, 29 skills.",
   "author": {
     "name": "Gordon Mickel",

plugins/flow-next/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-next",
-  "version": "9.3.1",
+  "version": "9.3.2",
   "description": "Zero-dependency, spec-driven agentic SDLC: durable specs, context-fit plans, re-anchored workers, adversarial cross-model review, and receipts. Compatible with Codex, Claude Code, and Factory Droid.",
   "author": {
     "name": "Gordon Mickel",

plugins/flow-next/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-next",
-  "version": "9.3.1",
+  "version": "9.3.2",
   "description": "Zero-dependency, spec-driven agentic SDLC: durable specs, context-fit plans, re-anchored workers, adversarial cross-model review, and receipts.",
   "author": {
     "name": "Gordon Mickel",

plugins/flow-next/codex/docs/flow-next/spec-template.md

@@ -99,16 +99,16 @@ Frontmatter is authoring guidance, not spec content, and may be stripped from th
 
 ### Leaving a section out
 
-`/flow-next:capture` writes the sections your template names and adds none it leaves out. The seven canonical sections are named as headings. The auxiliary sections (`Conversation Evidence`, `Strategy Alignment`, `Parked unknowns`, `Requirement coverage` and the rest) are named in the frontmatter `auxiliary_sections` list, and each still appears only when its own trigger fires.
+`/flow-next:capture` writes the sections your template names and adds none it leaves out, with one exception: `## Open Questions`, where a question handed to someone else is parked with its owner, is written whenever such a question comes up, because dropping it would lose the question. The seven canonical sections are named as headings. The auxiliary sections (`Conversation Evidence`, `Strategy Alignment`, `Parked unknowns`, `Requirement coverage` and the rest) are named in the frontmatter `auxiliary_sections` list, and each still appears only when its own trigger fires.
 
-Position follows the template as well. An auxiliary section you place as a heading in your `SPEC.md` lands where you put it. One that is named only in the list takes the placement its list entry states, which for the bundled entries is `Conversation Evidence` at the top of the body and `Requirement coverage` at the end.
+Position follows the template as well. An auxiliary section you place as a heading in your `SPEC.md` lands where you put it. One that is named only in the list takes the placement its list entry states, which for the bundled entries is `Conversation Evidence` at the top of the body and `Requirement coverage` at the end. `Open Questions` goes where your template places it, otherwise just before `Requirement coverage`.
 
 To stop a section from landing in your specs, delete its entry from that list in your `SPEC.md`. Two entries are worth knowing about:
 
 - **`Conversation Evidence`** is the block of verbatim user quotes capture puts at the top of a spec. No tool reads it. Capture still collects the quotes during the run and still checks every untagged criterion against them before it writes. Dropping the entry costs one thing. A reviewer who later doubts an untagged criterion can no longer look the quote up in the spec.
 - **`Requirement coverage`** is the placeholder table capture adds on a planned route. `/flow-next:plan` writes its own coverage table, so dropping the entry only means the table arrives with the plan.
 
-A `SPEC.md` written from scratch, with no `auxiliary_sections` list, gets no auxiliary sections from capture. A `SPEC.md` copied from the bundled file keeps the list and behaves as before.
+A `SPEC.md` written from scratch, with no `auxiliary_sections` list, gets no auxiliary sections from capture other than `Open Questions`. A `SPEC.md` copied from the bundled file keeps the list and behaves as before.
 
 ### What breaks if you rename or remove a canonical heading
 

plugins/flow-next/codex/docs/flow-next/teams.md

@@ -442,6 +442,7 @@ What `.flow/` looks like with N developers in parallel:
 - **Spec-level isolation.** Each spec is `fn-<N>-<slug>` with its markdown at `.flow/specs/fn-<N>-<slug>.md`, sidecar JSON at `.flow/specs/fn-<N>-<slug>.json`, and its own task tree under `.flow/tasks/fn-<N>-<slug>.M.json|md`. Two devs working on `fn-12-...` and `fn-15-...` never touch each other's files.
 - **Task-level dependencies.** Within a spec, `requires: [task-ids]` frontmatter is the contract. A task is *ready* when all its requires have status `done`. `flowctl ready --spec fn-12-...` lists ready tasks.
 - **Branch strategy.** Work never asks: it stays on the current branch when that is not the default branch, and otherwise creates a per-spec branch (`--branch=new`). Worktrees scale to several specs in flight (`--branch=worktree`). Current-branch is for solo, single-spec work.
+- **Questions travel on the branch.** A decision that belongs to someone else is parked under the spec's `## Open Questions` with its owner (`*(owner: product)*`), and the branch is pushed. The owner fetches, asks for the open questions for their role, and answers into the spec, which stays the source of truth. A scheduled task can post the list to chat. See [For teams](https://flow-next.dev/guides/for-teams/#questions-that-wait-on-someone-else).
 - **Spec-level dependencies chain, they do not wait.** A spec whose parent (`depends_on_epics`) has every task done and its branch on origin builds as a **chain**: its branch forks from the parent's tip and its PR targets the parent's branch, so a reviewer sees only that layer's diff; on GitHub the PR is also linked into the parent's **stack**. Chains are linear (one open parent, one child at a time). Humans merge from the bottom layer up, from the stack UI or through land; a parent reworked after the child branched may leave the child needing a rebase. See the [orchestration guide](orchestration.md#chaining-the-loops).
 - **Worker isolation has two layers.** Each task runs in a fresh-context worker, preventing context bleed. Concurrent writers also need separate mutable workspaces and a conductor-owned integration step; an atomic task claim alone provides neither.
 - **Memory tree as shared state.** `.flow/memory/` is the only multi-writer surface. The convention: bug entries are written by `/work` and `/qa` from review and QA findings; knowledge entries (`decisions/`, `architecture-patterns/`, `conventions/`) are written by humans or by `/work` with explicit confirmation. `/flow-next:audit` reconciles drift periodically.

plugins/flow-next/codex/skills/flow-next-capture/workflow.md

@@ -104,11 +104,12 @@ Tag only what capture authored: `[paraphrase]`, `[inferred]`, `[strategy:<track>
 
 ### 2.2 — Apply the resolved template
 
-The section structure comes from the canonical [the bundled `templates/spec.md`](../../templates/spec.md) (cross-link, never re-embed the list), resolved first-match from `<repo_root>/SPEC.md` → `<repo_root>/spec.md` → the bundled file. Read only the template that resolves: when the repo has `SPEC.md` or `spec.md`, do not open the bundled file. **The resolved template decides what goes in the spec:** write the sections it names as headings or in `auxiliary_sections`, in its order and positions, follow its instructions, and add no section it leaves out (the bundled entries put `Conversation Evidence` at the top and `Requirement coverage` at the end). A section with no conversation signal stays absent; empty beats fabricated.
+The section structure comes from the canonical [the bundled `templates/spec.md`](../../templates/spec.md) (cross-link, never re-embed the list), resolved first-match from `<repo_root>/SPEC.md` → `<repo_root>/spec.md` → the bundled file. Read only the template that resolves: when the repo has `SPEC.md` or `spec.md`, do not open the bundled file. **The resolved template decides what goes in the spec:** write the sections it names as headings or in `auxiliary_sections`, in its order and positions, follow its instructions, and add no section it leaves out except `## Open Questions` below (the bundled entries put `Conversation Evidence` at the top and `Requirement coverage` at the end). A section with no conversation signal stays absent; empty beats fabricated.
 
 - **`## Acceptance Criteria`** — `- **R1:** ...` prose bullets, allocated from R1 (fresh spec, no renumber concern). When `.flow/criteria.md` exists, never restate a G-ID as an R-ID; reference it in prose and write an R only for what this spec adds.
 - **`## Requirement coverage`** — only when the template names it, `NO_PLAN_OPT=0`, and §2.8 resolved to `plan`: each R-ID mapped to `fn-N.M (TBD - populate via /flow-next:plan)`. Omitted on the `direct` and `refine` routes: work's single implicit task is the coverage, and a placeholder nobody fills would mislead completion review. Capture writes no tasks.
 - **`## Parked unknowns`** (optional) — only genuine fog, one bullet each, naming what would resolve it. Decidable now → decide it; resolvable by scheduled work → a task for plan; inferred fill-in stays tagged, not parked.
+- **`## Open Questions`** (optional; written even when the template leaves it out, as refine does; placed where the template puts it, otherwise before `## Requirement coverage`) — a decision the conversation hands to someone who isn't in it ("PM decides", "ask security"), one bullet each: `**<question>** — for <owner> to decide; leaning <X>. *(owner: <role>)*`. The role is the one the person named (product, engineering, qa), never a person's name. A decision with nobody named to make it stays in Parked unknowns; never settle a parked question from your own leaning.
 
 ### 2.4 — Testability
 

plugins/flow-next/codex/skills/flow-next-flow/references/backlog-mode.md

@@ -507,6 +507,11 @@ question` with `--subject-id`, `--blocked-stage`, `--reason-code`,
 or normalized `issue.id` for a tracker-only item; the display handle is locator
 input only, never hash identity.
 
+The question line ends with who decides, `*(owner: <role>)*`: the role the
+blocking reason points at (missing scope or intent → product; a technical block
+→ engineering). The same line goes into the spec's `## Open Questions` entry. The
+tag is prose, so it changes neither the question id nor dedup.
+
 Where the question parks depends on whether a spec exists:
 
 - **Spec-backed** (`question <spec-id>`) - the durable parked state lives in the