@runfusion/fusion 0.73.0-beta.2 → 0.73.0-beta.4

package/dist/plugins/.fusion-ce-skills/ce-brainstorm/references/brainstorm-sections.md

@@ -0,0 +1,354 @@
+# Brainstorm Sections
+
+This reference describes what makes a great requirements-only unified plan
+artifact produced by `ce-brainstorm`.
+It does NOT prescribe how the doc looks on the page — rendering is handled by
+the format-specific references (`markdown-rendering.md`, `html-rendering.md`).
+
+## The outcome
+
+A great brainstorm produces the first version of the same plan artifact that
+`ce-plan` later enriches. It enables three audiences to act:
+
+- **The planning agent** (`ce-plan` or a human) produces an implementation
+  plan without inventing user behavior, scope boundaries, or success
+  criteria — the brainstorm answered those.
+- **The reviewer** sees the framing choices, distinguishes pinned from open,
+  and catches scope gaps before planning.
+- **The future reader** traces why the proposed thing matters, who it's for,
+  and what success looks like.
+
+Sections earn their place by serving one of these audiences. Omit padding.
+
+## Unified plan skeleton contract
+
+New `ce-brainstorm` outputs live under `docs/plans/` and use the unified plan
+artifact contract:
+
+- **Path:** `docs/plans/YYYY-MM-DD-NNN-<type>-<topic>-plan.<md|html>`.
+- **`artifact_contract: ce-unified-plan/v1`**.
+- **`artifact_readiness: requirements-only`**.
+- **`product_contract_source: ce-brainstorm`**.
+- **`execution`** only when the brainstorm has enough signal to classify the
+  eventual execution domain. For software features, use `execution: code`.
+  For non-code deliverables, follow the universal-brainstorming route instead
+  of pretending the artifact is executable code.
+
+A requirements-only unified plan is kept **light and standalone-readable**. It
+includes:
+
+- `## Goal Capsule` with objective, product authority, and open blockers.
+- `## Product Contract` containing the brainstorm sections below.
+
+Do **not** emit a `## Goal Launch Block` or `## Reader Index`: the launch prompt
+is skill-emitted at handoff, not a doc section, and the contract carries no
+Reader Index — consumers wayfind by scanning headings. It also omits empty
+`Planning Contract`, `Implementation Units`, `Verification Contract`, and
+`Definition of Done` sections — empty placeholders make requirements-only docs
+look executable and waste downstream tokens. `ce-plan` adds those sections when
+it enriches the same file in place. The next step (planning) is conveyed by the
+Phase 4 handoff menu, not by a section in the doc.
+
+Historical `docs/brainstorms/*-requirements.*` files remain valid legacy
+inputs. Do not migrate or rewrite them when creating new artifacts.
+
+## Decide whether a doc is warranted at all
+
+Brainstorm dialogue does not always need to produce a durable document.
+Skip document creation when **both** hold:
+
+- The user only needs brief alignment — no exploration produced novel scope,
+  framing, or decisions worth preserving in IDed shape.
+- Any durable decisions made during the dialogue can flow naturally to
+  downstream artifacts (`ce-plan`, the commit message, `docs/solutions/`)
+  without a brainstorm doc as an intermediary.
+
+The trigger for creating a doc is when the dialogue surfaced enough
+structural decisions, scope boundaries, or acceptance criteria that
+downstream consumers (planner, reviewer, future reader) need them in a
+durable, IDed form — not just as conversational artifacts.
+
+**Stress test:** a brainstorm about a tiny bug fix where the user asks "fix
+this with a null check or with upstream validation?" and the agent confirms
+"upstream validation, here's why" doesn't need a brainstorm doc. The
+decision flows to `ce-plan` (or directly to commit message, or to
+`docs/solutions/` if it's a pattern worth carrying) without a brainstorm
+artifact in the middle.
+
+Conversely, a brainstorm about a multi-actor feature with contested scope
+and several behavioral conditions probably does need a doc — the planning
+agent needs the structured content the dialogue produced.
+
+## Match depth to content
+
+When a doc IS warranted, depth matches what the dialogue produced. A
+brainstorm with sparse content produces a sparse doc; one with rich content
+produces a rich doc. Don't add ceremony to make a slim brainstorm look
+substantial.
+
+## Prose economy
+
+Match-depth-to-content sizes *which* sections appear and how deep each goes.
+This sizes *how the kept prose reads*. A section can be material and still be
+written loosely — the failure mode is a material section padded into a wall of
+text where contradictions hide and a downstream agent loses the thread. Length
+that earns its place is fine; wordiness around that length is not.
+
+Hold every kept section to these:
+
+- **One idea per sentence.** A Summary is a handful of sentences, not one
+  sentence with five semicolons and four parentheticals. If a sentence needs a
+  second parenthetical to stay true, split it.
+- **A requirement is one sentence of intent plus at most one qualifier.** When
+  a requirement would specify two outcomes ("either A or B, planning decides"),
+  state the intent and send the fork to Outstanding Questions — don't write both
+  arms in full inside the requirement.
+- **Cut hedges and intensifiers.** "Critically", "deliberately", "explicitly",
+  "genuinely", "actually", "simply" carry nothing a downstream agent acts on.
+- **Prefer the verb to the nominalization.** "Demote the grid", not "the
+  demotion of the grid is the deliberate change in this brief".
+
+Precision is not padding: keep domain terms, conditionals, and exact thresholds
+verbatim. Economy targets the connective tissue around them, never the precision
+itself.
+
+**Resolve in place; don't stratify.** When a later decision answers a parked
+question or supersedes earlier text, rewrite or remove the original entry —
+don't append a separate "resolutions" layer that leaves the superseded text
+standing, and don't keep superseded prose as strikethrough. Version control
+holds the history. Stacked question/resolution strata double the reading surface
+and hide which text is live.
+
+**Named test, run before the doc is declared written:** could a reader find a
+contradiction in each section in one pass? A sentence carrying more than one
+parenthetical, or a requirement specifying two outcomes, fails the test — split
+it or defer it.
+
+## Product Contract hard floor
+
+When a requirements-only unified plan is warranted, these are present inside
+`## Product Contract`.
+
+- **Summary** — what is being proposed, in 1-3 lines. Forward-looking.
+  Orients the reader before they invest in detail.
+- **Requirements** (with stable R-IDs) — what must be true about the
+  proposed thing. For very sparse brainstorms (≤3 simple items where the
+  bullets ARE the summary), plain bullets without IDs are acceptable; the
+  trigger for R-IDs is whether downstream consumers will reference them.
+  When requirements span distinct concerns (e.g., "Packaging" /
+  "Migration and compatibility" / "Contributor workflow"), group them
+  under bold inline headers within the Requirements section — group by
+  capability or concern, not by the order requirements were discussed.
+  The trigger is distinct concerns, not item count — even four
+  requirements benefit if they cover three different topics. Skip
+  grouping only when all requirements are genuinely about the same thing;
+  a long flat list is a smell that subgroups were missed. R-IDs stay
+  continuous across groups (R1, R2 in the first group; R3, R4 in the
+  second; never restart at R1 per group).
+
+## Include when material
+
+The agent decides per brainstorm whether each section carries information
+that isn't covered elsewhere. Filling a section with placeholder prose is
+worse than omitting it.
+
+- **Problem Frame** — include when motivation isn't obvious from Summary
+  alone (the *why* needs paragraphs, not a sentence). Backward-looking /
+  situational. Does NOT restate the proposal; the remedy lives in Summary.
+
+- **Key Decisions** — include when the brainstorm produced opinionated
+  framing choices (defaults, scope narrowings, foundational technical picks)
+  that constrain Requirements / Flows / Scope below. Each entry names the
+  decision in bold with prose rationale. Sits high in the rendered doc so
+  readers encounter the framing choices before descending into detail.
+
+- **Actors** — include when the proposed thing has multi-party behavior
+  (multiple humans, agents, or systems meaningfully involved). Skip for
+  non-behavioral brainstorms (naming briefs, data-shape briefs, pure
+  research, decision frameworks).
+
+- **Key Flows** — include when the proposed thing has multi-step behavior.
+  Expected by default for behavioral brainstorms unless the proposed thing
+  is genuinely non-flow-shaped (pure API surface, policy, artifact output)
+  and Actors / Requirements / Scope Boundaries / Acceptance Examples
+  together prevent downstream invention of paths. When omitting from a
+  behavioral brainstorm, note the reason in the doc.
+
+- **Visualizations** — a brainstorm earns a visual when a concept has a
+  **structure worth showing**, and that decision turns on whether the
+  structure exists, *not* on whether your own prose reads clearly. Calling
+  your prose "clear enough" is the trap that quietly under-produces the
+  visuals a reader actually uses — decide on the shape, not the wording.
+  Shapes that warrant one: a data-shape transformation (before/after schema
+  or field mapping), a source-of-truth fan-out (one authority feeding many
+  derived surfaces), state-or-lifecycle logic, a multi-step flow, an
+  entity/relationship structure, a decision boundary, a quantitative
+  comparison — and, for any requirement that changes a UI, screen layout,
+  component placement, or screen flow, a **wireframe**. This applies to
+  backend and conceptual work, not only visual products: a data model, sync
+  protocol, or agent workflow earns a conceptual diagram exactly as a UI
+  requirement earns a wireframe. Match the visual to the shape — a UI/layout
+  shape takes a wireframe in HTML (a mermaid layout diagram or prose in
+  markdown; there is no inline-SVG wireframe in markdown), any other structure
+  takes a conceptual diagram. A visual is cross-cutting, not a section of its
+  own — it sits next to the Key Decision, Requirements group, or Flow it
+  illustrates. **A point with nothing structural to show gets no visual** — a
+  single-field add, a rename, or a one-line change has no structure, and a
+  before/after of one changed line is decoration. One visual per load-bearing
+  concept, never decoration or ceremony.
+
+  **Diagrams complement prose; they never replace it.** A diagram is an
+  on-ramp to the prose it illustrates, not a substitute. The IDed prose
+  (Requirements, Key Decisions, Acceptance Examples) stays complete and
+  standalone — a reader who ignores every diagram still gets the full
+  content in text, and a downstream agent that reads the artifact as linear
+  text is never left with a relationship that exists only in an SVG. Adding
+  a before/after diagram is not license to thin the requirement or decision
+  prose it depicts.
+
+- **Acceptance Examples** — include when any requirement has a
+  state-dependent or conditional shape ("When X, Y") where prose alone leaves
+  ambiguity about edge cases. **Always include AEs covering
+  behavioral-conditional requirements** — that's where the ambiguity bites
+  hardest. Skip when all requirements are unconditional and unambiguous.
+
+- **Success Criteria** — include when there are quality / metric / handoff
+  signals that Requirements don't already carry: quantitative metrics ("p95
+  latency under 200ms"), qualitative criteria ("the agent's output reads as
+  one voice"), process / handoff quality ("ce-doc-review can act on this
+  without follow-ups"). Skip when Requirements ARE the success criteria
+  (every R is "done when the R is true").
+
+- **Scope Boundaries** — include when scope is contested or there are
+  tempting non-goals worth naming explicitly. When the brainstorm is about
+  positioning a product against adjacent ones the team could have built but
+  is rejecting, split into "Deferred for later" (eventually but not v1) and
+  "Outside this product's identity" (positioning decision). Otherwise, a
+  single list is fine.
+
+- **Dependencies / Assumptions** — include when material upstream
+  dependencies exist or when load-bearing assumptions need to be surfaced.
+
+- **Outstanding Questions** — include when there are unresolved items.
+  Distinguish "Resolve Before Planning" (blocks planning) from "Deferred to
+  Planning" (answered during planning or codebase exploration).
+
+- **Sources / Research** — surface research that orients the planner or
+  justifies framing choices. The test: *"if I were the planner reading this
+  cold, would this breadcrumb help me make better choices?"* Yes → surface
+  (code locations, external docs, RFCs, constraints, prior plans — the
+  category is inclusive, not enumerated). Process exhaust (reading the
+  user's prompt, glancing at obvious files) → omit.
+
+## Agent agency
+
+The catalog is a floor, not a ceiling. When the brainstorm's content doesn't
+fit any catalog section, introduce a new one — don't force the content into
+a section it doesn't belong in. Content drives section choices, not vice
+versa.
+
+The agent also picks per artifact:
+
+- Whether Acceptance Examples render as a separate section or embed in each
+  requirement
+- How much depth each present section gets
+
+(Requirements grouping is covered above in the Hard Floor item — group by
+concern by default, rendering a flat list only when all requirements are
+about the same thing, with continuous R-IDs across groups.)
+
+## Brainstorm metadata fields
+
+Every requirements-only unified plan carries a small set of stable metadata fields that
+downstream tooling depends on. The contract is format-independent: in
+markdown these fields appear as YAML frontmatter at the top of the file; in
+HTML they appear as visible header text (typically a `<dl>` of `<dt>`/`<dd>`
+pairs or a stats strip). Field names and semantics are the same across both
+formats so consumers can locate them without knowing which format produced the
+artifact.
+
+### Required
+
+- **`title`** — the artifact's descriptive name with a ` - Plan` suffix
+  (e.g., `Highlighter Tool - Plan`), matching the H1 (markdown) or document
+  `<h1>` (HTML). It is a unified plan at every readiness state, so the title
+  stays stable when `ce-plan` enriches it. Do not put a conventional-commit
+  prefix (`feat:`/`fix:`) in the title — the `type` field carries that.
+- **`type`** — conventional-commit-prefix-aligned classification (`feat`,
+  `fix`, `refactor`, `docs`, etc.).
+- **`date`** — creation date in ISO 8601 (`YYYY-MM-DD`), ASCII digits only.
+  Used in the filename (`docs/plans/YYYY-MM-DD-NNN-<type>-<topic>-plan.<md|html>`).
+- **`topic`** — kebab-case slug identifying the brainstorm subject (e.g.,
+  `surface-scope-earlier`, `demo-reel-local-save`). Used in the filename and
+  as the resume-detection key when `ce-brainstorm` scans for an existing
+  artifact to continue.
+- **`artifact_contract`** — always `ce-unified-plan/v1` for new outputs.
+- **`artifact_readiness`** — always `requirements-only` for new
+  `ce-brainstorm` outputs. Do not use `active`, `in_progress`, `completed`,
+  or `done`.
+- **`product_contract_source`** — always `ce-brainstorm`.
+
+### No status field
+
+Unified plan artifacts have no `status` field and no `active → completed`
+lifecycle. `artifact_readiness` is document completeness, not execution
+progress. No CE artifact carries mutable progress state; whether work shipped
+is derived from git, not stored in the doc. Do not introduce one.
+
+### Field-name stability
+
+Field names are stable across brainstorm revisions — never rename a field
+or repurpose its semantics. Agents composing new brainstorms MUST use these
+exact names; adding new fields is fine, but renaming `topic` to `subject`
+or `date` to `created` breaks filename construction and resume detection.
+
+## ID and content rules
+
+Same shape as plan rules.
+
+- **Stable IDs.** R-IDs (Requirements), A-IDs (if Actors fire), F-IDs (if
+  Flows fire), AE-IDs (if Acceptance Examples fire). No other ID namespaces.
+- **Plain prefix.** `R1.`, `A1.`, `F1.`, `AE1.` as bullet prefixes. Do not
+  bold; the prefix is visually distinctive on its own.
+- **Bold leader labels** inside Flows and Acceptance Examples
+  (`**Trigger:**`, `**Covers R4, R8.**`) provide structure without deeper
+  heading levels.
+- **Repo-relative paths.** Always. Never absolute paths.
+- **No process exhaust.** No "captured at Phase X" notes, no `## Next Steps`
+  pointing to ce-plan, no italic provenance lines. Engineering process
+  metadata belongs in commit messages and tool output, not the artifact.
+- **No implementation details by default.** Libraries, schemas, endpoints,
+  file layouts, code structure stay out unless the brainstorm itself is
+  inherently about a technical or architectural change and those details are
+  the subject of the decision.
+
+## Discipline: Summary vs Problem Frame
+
+When both sections are present, they earn separate sections only by holding
+to different purposes:
+
+| Section | Question it answers | Time direction | Length |
+|---|---|---|---|
+| `## Summary` | What is this doc proposing? | Forward-looking | 1-3 lines |
+| `## Problem Frame` | Why does this proposal exist? | Backward-looking / situational | Paragraphs |
+
+- **Summary doesn't need problem context.** A reader scanning Summary gets
+  the proposal at a glance.
+- **Problem Frame doesn't restate the proposal.** It establishes the
+  situation, the specific moment of pain, and the cost shape — then stops.
+  The remedy lives in Summary; restating it in Problem Frame is the
+  duplication that makes the two sections feel redundant.
+
+## Rendering
+
+The format-specific references describe how to render these sections in each
+output format:
+
+- **Markdown rendering:** `references/markdown-rendering.md`
+- **HTML rendering:** `references/html-rendering.md`
+
+This reference (`brainstorm-sections.md`) is about WHAT the brainstorm
+contains; rendering references are about HOW each format presents it. The
+brainstorm is written in one format — markdown OR HTML, never both — based
+on the resolved output mode. The section catalog is the same regardless of
+format.

package/dist/plugins/.fusion-ce-skills/ce-brainstorm/references/handoff.md

@@ -0,0 +1,172 @@
+# Handoff
+
+This content is loaded when Phase 4 begins — after the requirements-only
+unified plan is written.
+
+---
+
+#### 4.1 Present Next-Step Options
+
+The Phase 4 menu's visible option count varies by state: no unified plan
+artifact hides the review and Proof options, unresolved `Resolve Before
+Planning` hides both `Create the implementation plan` and `Ship it
+autonomously with lfg`, and the lfg option is also hidden for non-software
+brainstorms (`execution` other than `code`). Count the visible options for the
+current state and choose the rendering mode accordingly:
+
+- **4 or fewer visible:** use the platform's blocking question tool (`AskUserQuestion` in Claude Code — call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded; `request_user_input` in Codex; `ask_question` in Antigravity CLI (`agy`), `ask_user` in Pi (requires the `pi-ask-user` extension)). This is the default.
+- **5 or more visible:** render as a numbered list in chat. This is the narrow option-overflow fallback; trimming would hide legitimate choices (plan, ship, review, Proof, refine, pause are all distinct destinations). Include a hint that free-form input is accepted ("Pick a number or describe what you want.") so the numbered list retains the blocking tool's open-endedness.
+
+Never silently skip the question.
+
+If `Resolve Before Planning` contains any items:
+- Ask the blocking questions now, one at a time, by default
+- If the user explicitly wants to proceed anyway, first convert each remaining item into an explicit decision, assumption, or `Deferred to Planning` question
+- If the user chooses to pause instead, present the handoff as paused or blocked rather than complete
+- Do not offer the `Create the implementation plan` or `Ship it autonomously with lfg` options while `Resolve Before Planning` remains non-empty
+
+In both preambles below, the "Pick a number or describe what you want." hint applies only in numbered-list mode. When using the blocking tool, omit that line and pass the remaining stem as the question.
+
+**Path format:** Use absolute paths for chat-output file references — relative paths are not auto-linked as clickable in most terminals.
+
+**Preamble when no blocking questions remain:**
+
+```
+Brainstorm complete.
+
+Plan artifact: <absolute path to requirements-only unified plan>  # omit line if no artifact was created
+
+What would you like to do next? (Pick a number or describe what you want.)
+```
+
+**Preamble when blocking questions remain and user wants to pause:**
+
+```
+Brainstorm paused. Planning is blocked until the remaining questions are resolved.
+
+Plan artifact: <absolute path to requirements-only unified plan>  # omit line if no artifact was created
+
+What would you like to do next? (Pick a number or describe what you want.)
+```
+
+Present only the options that apply. Renumber so visible options stay contiguous starting at 1.
+
+1. **Create the implementation plan** *(recommended)* - Hand off to `ce-plan` and sharpen the requirements into a complete, testable plan. Shown only when `Resolve Before Planning` is empty.
+2. **Ship it autonomously with `lfg`** - Hand the requirements to the full autonomous pipeline: `lfg` plans (`ce-plan`), implements, simplifies, runs independent code review and applies the fixes, opens a PR, and watches CI to green — hands-off, no check-ins. It plans first (unlike a raw `/goal` straight from requirements), so it's the safer autonomous path. Best when you trust the requirements and want it built and shipped without steering. **Opens a PR and pushes a branch.** Shown only for software brainstorms (`execution: code`) with `Resolve Before Planning` empty **and a unified plan artifact was created** — `lfg` hands `ce-plan` that artifact path in pipeline mode and cannot prompt, so with no artifact (e.g. a brief-alignment brainstorm that skipped doc creation per the "Decide whether a doc is warranted" rule) there is nothing to enrich; offer option 1 instead, which can plan interactively from the conversation. For a quicker plan-then-decide flow, or to run a `/goal` yourself, pick option 1 and choose at the `ce-plan` handoff.
+<!--
+FNXC:CompoundEngineering 2026-06-27-18:23:
+FN-7147 requires HTML brainstorm artifacts to remain reviewable instead of hiding the pressure-test option. FN-7149 lets ce-doc-review use only proven DOM-safe HTML mutations; markdown-only apply-set and Open Questions mutations stay disabled, and helper refusal remains report-only.
+-->
+3. **Pressure-test the requirements** - Dispatch reviewer agents with `ce-doc-review` to find gaps, conflicts, weak premises, and scope issues in the requirements; auto-apply safe fixes for markdown; route the rest interactively. Shown when a unified plan artifact exists. Under `OUTPUT_FORMAT=html`, run `ce-doc-review` in DOM-safe-or-report-only mode: persona lenses run and findings are presented, only proven DOM-safe helper mutations may apply, and no markdown apply-set edits or markdown Append-to-Open-Questions write-back are offered.
+4. **Publish to Proof — shareable link** - Publish the markdown unified plan to Every's Proof editor and get a shareable link to read, comment on, or share with others. One-way: the local doc stays canonical. Shown only when a markdown unified plan exists. **Render only when `OUTPUT_FORMAT=md`** (Proof operates on markdown and cannot ingest HTML).
+4. **Open in browser** — open the HTML unified plan locally for review and sharing. Shown only when an HTML unified plan exists. **Render only when `OUTPUT_FORMAT=html`.** Replaces "Publish to Proof" at the same slot under exclusive output mode — the artifact is either markdown OR HTML, never both, so exactly one of the two labels applies per run.
+5. **More clarifying questions to sharpen the doc** - Keep refining scope, edge cases, constraints, and preferences through further dialogue. Always shown.
+
+There is no "done" / "pause" option — the blocking question already waits, and the user ends by dismissing it (Esc) or saying they're finished. The unified plan artifact is already saved.
+
+**Post-review nudge (subsequent rounds only):** If the user has already run `ce-doc-review` this session and residual P0/P1 findings remain unaddressed, add a one-line prose nudge adjacent to the menu (e.g., "Document review flagged 2 P1 findings you may want to address — pick \"Pressure-test the requirements\" to run another pass."). Reference the option by label, not number: the menu renumbers when `Resolve Before Planning` hides `Create the implementation plan` and the lfg option, so a hardcoded option number can point users at the wrong action. Do not add a separate menu option; reuse the existing `Pressure-test the requirements` option. This nudge applies to markdown and HTML artifacts; HTML reruns remain report-only.
+
+#### 4.2 Handle the Selected Option
+
+Selections may be the literal option label (when the user types the label or a close paraphrase) or the option number. Match numbers against the currently-rendered (post-trim) list. Free-form input that doesn't match an option or describe an alternative action should be treated as clarification — ask a follow-up rather than guessing.
+
+**If user selects "Create the implementation plan":**
+
+Immediately load the `ce-plan` skill in the current session. Pass the unified
+plan artifact path when one exists; otherwise pass a concise summary of the
+finalized brainstorm decisions. When the Phase 1.1 grounding scout produced a
+dossier and the file still exists, also pass its path
+(`/tmp/compound-engineering/ce-brainstorm/<run-id>/grounding.md`) — it gives
+planning verified quotes with `file:line` pointers to start from instead of
+re-scanning the repo. Do not print the closing summary first.
+
+**If user selects "Pressure-test the requirements":**
+
+Load the `ce-doc-review` skill, passing the unified plan path as the argument.
+For `.html` artifacts, state that the review is DOM-safe-or-report-only and that no
+markdown autofix or markdown Append-to-Open-Questions write-back will run. When ce-doc-review
+returns "Review complete", return to the Phase 4 options and re-render the
+menu (the requirements may have changed for markdown or from proven DOM-safe HTML fixes; HTML findings are
+advisory when the helper refuses, so still
+re-evaluate `Resolve Before Planning`, the lfg software gate, and residual
+findings). If residual P0/P1 findings remain unaddressed, include the
+post-review nudge above the menu. Do not show the closing summary yet.
+
+**If user selects "Ship it autonomously with `lfg`":**
+
+Immediately invoke the `lfg` skill in the current session via the platform's
+skill-invocation primitive, passing the unified plan artifact path as its
+argument so `lfg`'s `ce-plan` step enriches *this* requirements-only artifact in
+place rather than bootstrapping a new plan. `lfg` then owns the full pipeline
+autonomously — plan, implement (`ce-work` in `return-to-caller` mode), simplify,
+independent code review and applied fixes, commit/push/open PR, and CI watch to
+green. Do not also start a `/goal` or load `ce-work` directly — `lfg`
+orchestrates them. Unlike a goal tool, `lfg` is host-agnostic: it works wherever
+skills run (plus `git`/`gh` for the PR/CI tail, which it guards when absent).
+
+Where the host exposes no skill-invocation primitive, print the `lfg <plan-path>`
+invocation for the user to run and note that it will plan, build, review, and
+open a PR from this artifact.
+
+Do not print the closing summary first.
+
+**If user selects "More clarifying questions to sharpen the doc":** Return to Phase 1.3 (Collaborative Dialogue) and continue asking the user clarifying questions one at a time to further refine scope, edge cases, constraints, and preferences. Continue until the user is satisfied, then return to Phase 4. Do not show the closing summary yet.
+
+**If user selects "Publish to Proof — shareable link":**
+
+Load the `ce-proof` skill to publish the markdown unified plan. Pass:
+
+- **source file:** `docs/plans/YYYY-MM-DD-NNN-<type>-<topic>-plan.md`
+- **doc title:** `Plan: <topic title> (requirements-only)`
+- **identity:** `ai:compound-engineering` / `Compound Engineering`
+
+ce-proof creates a shared Proof doc from the markdown plan file (Create and
+Share workflow), binds the display name, and returns the share URL. Surface
+the URL to the user — they can open it to read, comment, or share with others
+— then return to the Phase 4 options and re-render the menu. This is a one-way
+publish: the local doc stays canonical and nothing syncs back, so option
+eligibility is unchanged (no need to re-evaluate `Resolve Before Planning`,
+the lfg software gate, or residual findings on account of Proof).
+
+If the upload fails (network error, Proof API down), retry once after a short wait. If it still fails, tell the user the upload didn't succeed and briefly explain why, then return to the Phase 4 options — don't leave them wondering why the option did nothing.
+
+**If user selects "Open in browser":** Display the absolute path to the `.html` unified plan so the user can open it locally. Where the platform exposes a browser-opening primitive (e.g., `open` on macOS, `xdg-open` on Linux, `start` on Windows), the agent may invoke it directly; otherwise print the absolute path and let the user open it. After the path is displayed (or the browser is opened), return to the Phase 4 options so the user can pick a follow-up action.
+
+**If the user indicates they're finished** (says "done"/"that's all", or dismisses the menu without picking an option): display the closing summary (see 4.3) and end the turn.
+
+#### 4.3 Closing Summary
+
+Use the closing summary only when this run of the workflow is ending or handing off, not when returning to the Phase 4 options.
+
+In both templates below, substitute `<absolute path to unified plan>` with the
+actual file path written this run — `.md` for `OUTPUT_FORMAT=md`, `.html` for
+`OUTPUT_FORMAT=html`. Do not emit a hardcoded `.md` path when the artifact is
+HTML, or the closing summary will point users at a file that was never written.
+
+When complete and ready for planning, display:
+
+```text
+Brainstorm complete!
+
+Plan artifact: <absolute path to unified plan>  # omit line if no artifact was created
+
+Key decisions:
+- [Decision 1]
+- [Decision 2]
+
+Recommended next step: `ce-plan <plan artifact path>`
+```
+
+If the user pauses with `Resolve Before Planning` still populated, display:
+
+```text
+Brainstorm paused.
+
+Plan artifact: <absolute path to unified plan>  # omit line if no artifact was created
+
+Planning is blocked by:
+- [Blocking question 1]
+- [Blocking question 2]
+
+Resume with `ce-brainstorm` when ready to resolve these before planning.
+```