feat(ce-brainstorm, ce-plan): unify brainstorm and plan into one readiness-staged artifact

AGENTS.md

@@ -235,8 +235,8 @@ This applies equally to any platform's variables — a skill converted from Code
 
 ## Repository Docs Convention
 
-- **Requirements** live in `docs/brainstorms/` — requirements exploration and ideation.
-- **Plans** live in `docs/plans/` — implementation plans and progress tracking.
+- **Plans** live in `docs/plans/` — unified plan artifacts. New `ce-brainstorm` outputs are requirements-only unified plans (`artifact_readiness: requirements-only`); `ce-plan` enriches them to implementation-ready plans (`artifact_readiness: implementation-ready`). Historical `docs/brainstorms/*-requirements.*` files remain readable legacy inputs and should not be migrated just because a new plan is created.
+- **Brainstorm evidence / legacy requirements** may live in `docs/brainstorms/` — historical requirements docs and specialized analysis artifacts such as `docs/brainstorms/riffrec-feedback/`. Do not treat this as the canonical output path for new `ce-brainstorm` artifacts.
 - **Solutions** live in `docs/solutions/` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`). Relevant when implementing or debugging in documented areas.
 - **Specs** live in `docs/specs/` — target platform format specifications.
 

README.md

@@ -12,7 +12,7 @@ Traditional development accumulates technical debt. Every feature adds complexit
 
 Compound engineering inverts this. 80% is in planning and review, 20% is in execution:
 
-- Plan thoroughly before writing code with `/ce-brainstorm` and `/ce-plan`
+- Plan thoroughly before writing code with `/ce-brainstorm` and `/ce-plan` using one readiness-based plan artifact
 - Review to catch issues and calibrate judgment with `/ce-code-review` and `/ce-doc-review`
 - Codify knowledge so it is reusable with `/ce-compound`
 - Keep quality high so future changes are easy
@@ -36,9 +36,9 @@ Use `/ce-ideate` before the loop when you want the agent to generate and critiqu
 |-------|---------|
 | `/ce-strategy` | Create or maintain `STRATEGY.md` -- the product's target problem, approach, persona, key metrics, and tracks. Read as grounding by ideate, brainstorm, and plan |
 | `/ce-ideate` | Optional big-picture ideation: generate and critically evaluate grounded ideas, then route the strongest one into brainstorming |
-| `/ce-brainstorm` | Interactive Q&A to think through a feature or problem and write a right-sized requirements doc before planning |
-| `/ce-plan` | Turn feature ideas into detailed implementation plans |
-| `/ce-work` | Execute plans with worktrees and task tracking |
+| `/ce-brainstorm` | Interactive Q&A to think through a feature or problem and write a requirements-only unified plan before planning |
+| `/ce-plan` | Enrich feature ideas or requirements-only plans into implementation-ready plans |
+| `/ce-work` | Execute implementation-ready plans with worktrees and task tracking |
 | `/ce-debug` | Systematically reproduce failures, trace root cause, and implement fixes |
 | `/ce-code-review` | Multi-agent code review before merging |
 | `/ce-compound` | Document learnings to make future work easier |
@@ -50,12 +50,12 @@ Each cycle compounds: brainstorms sharpen plans, plans inform future plans, revi
 
 ## Quick Example
 
-A typical cycle starts by turning a rough idea into a requirements doc, then planning from that doc before handing execution to `/ce-work`:
+A typical cycle starts by turning a rough idea into a requirements-only unified plan, enriching that same plan, then handing execution to `/ce-work`:
 
 ```text
 /ce-brainstorm "make background job retries safer"
-/ce-plan docs/brainstorms/background-job-retry-safety-requirements.md
-/ce-work
+/ce-plan docs/plans/2026-06-18-001-feat-background-job-retry-safety-plan.md
+/ce-work docs/plans/2026-06-18-001-feat-background-job-retry-safety-plan.md
 /ce-code-review
 /ce-compound
 ```

docs/skills/README.md

@@ -35,9 +35,9 @@ The steps of every engineering iteration. `/ce-ideate` runs only when you need t
 | Skill | Description |
 |-------|-------------|
 | [`/ce-ideate`](./ce-ideate.md) | *Optional first step* — discover strong, qualified directions worth exploring with six conceptual frames, warrant requirement, adversarial filtering |
-| [`/ce-brainstorm`](./ce-brainstorm.md) | Define what something should become — collaborative dialogue, named gap lenses, right-sized requirements doc |
-| [`/ce-plan`](./ce-plan.md) | Bound execution with guardrails — U-IDs, test scenarios, automatic confidence check; WHAT decisions, not HOW code |
-| [`/ce-work`](./ce-work.md) | Execute against the plan's guardrails — figure out the HOW with code in front of you, ship through quality gates |
+| [`/ce-brainstorm`](./ce-brainstorm.md) | Define what something should become — collaborative dialogue, named gap lenses, requirements-only unified plan |
+| [`/ce-plan`](./ce-plan.md) | Bound execution with guardrails — enrich unified plans with U-IDs, test scenarios, automatic confidence check; WHAT decisions, not HOW code |
+| [`/ce-work`](./ce-work.md) | Execute against implementation-ready plan guardrails — figure out the HOW with code in front of you, ship through quality gates |
 | [`/ce-compound`](./ce-compound.md) | Close the loop by capturing what you learned into `docs/solutions/` so the next iteration starts smarter — bug track + knowledge track |
 
 ---

docs/skills/ce-brainstorm.md

@@ -1,10 +1,10 @@
 # `ce-brainstorm`
 
-> Think through what something should become — collaboratively, one question at a time — then write a right-sized requirements doc.
+> Think through what something should become — collaboratively, one question at a time — then write a right-sized requirements-only unified plan.
 
-`ce-brainstorm` is the **definition** skill. It's a thinking partner that asks one question at a time, pressure-tests your premises against named gap lenses, explores 2-3 concrete approaches before recommending one, and produces a right-sized requirements document strong enough that planning never has to invent product behavior.
+`ce-brainstorm` is the **definition** skill. It's a thinking partner that asks one question at a time, pressure-tests your premises against named gap lenses, explores 2-3 concrete approaches before recommending one, and, for software work, produces a requirements-only unified plan strong enough that planning never has to invent product behavior.
 
-It runs equally well on software features, on entirely non-software topics (event planning, business decisions, personal-project framing, travel itineraries, naming briefs), and anywhere in between. The same one-question-at-a-time discipline; the same right-sized template; the same Synthesis Summary before any artifact lands.
+It runs equally well on software features, on entirely non-software topics (event planning, business decisions, personal-project framing, travel itineraries, naming briefs), and anywhere in between. The same one-question-at-a-time discipline applies everywhere. Software brainstorms write the requirements-only unified plan artifact; non-software brainstorms stay in facilitation mode and can hand their synthesis to `ce-plan` for a domain-appropriate plan.
 
 This is the middle step in the compound-engineering ideation chain:
 
@@ -23,9 +23,9 @@ It's also the most common standalone entry point — for any feature, decision,
 
 | Question | Answer |
 |----------|--------|
-| What does it do? | Collaborative dialogue to clarify scope, pressure-test premises, explore approaches, and write a right-sized requirements doc |
+| What does it do? | Collaborative dialogue to clarify scope, pressure-test premises, explore approaches, and write a requirements-only unified plan |
 | When to use it | Vague feature ideas, "let's brainstorm", multiple plausible directions, unclear scope; non-software decisions and projects |
-| What it produces | Requirements doc in `docs/brainstorms/` (with R-IDs, A-IDs, F-IDs, AE-IDs in software mode) |
+| What it produces | Software: requirements-only unified plan in `docs/plans/` with `artifact_readiness: requirements-only` and R/A/F/AE IDs. Non-software: chat synthesis plus optional handoff to `ce-plan`, not a software unified artifact. |
 | What's next | `/ce-plan`, `/ce-work` for trivial scope, doc review, or publish to Proof |
 
 ---
@@ -53,7 +53,7 @@ A typical "let's brainstorm" with an AI also has shape problems: it asks five qu
 - **Opt-in visual probes** for decisions that are faster to judge as rough sketches than prose
 - **Synthesis Summary** as the last opportunity to correct scope before the doc lands
 - **Fresh-context claim verification** checks the doc's repo claims before it lands
-- **Right-sized requirements document** with stable identifiers (R/A/F/AE) that flow into planning
+- **Right-sized Product Contract** inside a unified plan with stable identifiers (R/A/F/AE) that flow into planning
 
 ---
 
@@ -93,19 +93,19 @@ Before writing the doc, `ce-brainstorm` emits a **scoping synthesis** shaped lik
 
 ### 7. Stable identifiers that flow downstream
 
-The requirements doc carries plan-feeding identifiers — R-IDs (Requirements), A-IDs (Actors), F-IDs (Key Flows), AE-IDs (Acceptance Examples). `ce-plan` consumes these and traces every implementation unit and test scenario back to them. Origin scope boundaries (especially "Outside this product's identity") flow through unchanged.
+The Product Contract carries plan-feeding identifiers — R-IDs (Requirements), A-IDs (Actors), F-IDs (Key Flows), AE-IDs (Acceptance Examples). `ce-plan` consumes these and traces every implementation unit and test scenario back to them. Origin scope boundaries (especially "Outside this product's identity") flow through unchanged.
 
 ### 8. Universal brainstorming for non-software
 
 Building a software feature? Standard flow. Naming a product? Choosing a vacation? Deciding a career move? `ce-brainstorm` routes to a domain-agnostic facilitator that preserves the one-question-at-a-time discipline and right-sized output.
 
-### 9. Implementation kept out of the requirements doc by default
+### 9. Implementation kept out of the Product Contract by default
 
 Requirements describe **what** behavior is expected from the user's perspective. They do not describe libraries, schemas, endpoints, file layouts, or code structure — unless the brainstorm is itself about a technical or architectural decision. This keeps planning's job clean: invent the **how**, not the **what**.
 
 ### 10. Grounding and verification ride inside your think-time
 
-On Standard and Deep brainstorms, a cheap extraction-tier scout is dispatched in the background while you answer the first question. It writes a grounding dossier — verbatim quotes with `file:line` pointers — to scratch storage and hands back a short gist, so the dialogue stays lean while the evidence stays available on demand. Before the requirements doc is written, a fresh-context verifier (a mid-tier model that never saw the dialogue) checks the doc's repo claims — absence claims, file references — against the codebase, running while you review the synthesis confirmation. Refuted claims are corrected before the doc lands; unverifiable ones become explicit assumptions. The dossier path is handed to `ce-plan` so planning starts from verified quotes instead of re-scanning. On platforms without per-agent model selection, both run on the inherited model with the same read budgets; with no subagent support at all, the skill falls back to inline scanning and verification.
+On Standard and Deep brainstorms, a cheap extraction-tier scout is dispatched in the background while you answer the first question. It writes a grounding dossier — verbatim quotes with `file:line` pointers — to scratch storage and hands back a short gist, so the dialogue stays lean while the evidence stays available on demand. Before the requirements-only unified plan is written, a fresh-context verifier (a mid-tier model that never saw the dialogue) checks the Product Contract's repo claims — absence claims, file references — against the codebase, running while you review the synthesis confirmation. Refuted claims are corrected before the plan lands; unverifiable ones become explicit assumptions. The dossier path is handed to `ce-plan` so planning starts from verified quotes instead of re-scanning. On platforms without per-agent model selection, both run on the inherited model with the same read budgets; with no subagent support at all, the skill falls back to inline scanning and verification.
 
 ---
 
@@ -117,7 +117,7 @@ The pressure test detects a specificity gap (who are these "users"?) and an atta
 
 Three approaches surface — per-notification-type mute with TTL, a global do-not-disturb schedule, mute on the rule rather than the channel — with tradeoffs and a recommendation. The Synthesis Summary reads back the shape that emerged ("per-channel mute on notification rules, 24h preset for the 3 AM support pings"), names the trade-offs made in dialogue (per-channel over per-user, mute lives on the rule), what's deferred (presence-based mute, quiet-hours schedules), and a single call-out about the rule-delete loss path. You confirm and add a 24h preset.
 
-A right-sized requirements doc is written and the Phase 4 menu offers next steps — `/ce-plan` (recommended), agent doc review, publish to Proof, or skip-to-build for trivial scope.
+A requirements-only unified plan is written under `docs/plans/` and the Phase 4 menu offers next steps — `/ce-plan` (recommended), Product Contract review, publish to Proof, or skip-to-build only for trivial scope with a sufficient Definition of Done.
 
 ---
 
@@ -148,19 +148,19 @@ Skip `ce-brainstorm` when:
    |  picks one survivor + carries warrant + rationale
    v
 /ce-brainstorm
-   |  produces requirements / brief
+   |  produces requirements-only unified plan
    |  software mode: R-IDs, A-IDs, F-IDs, AE-IDs + scope boundaries
    |  universal mode: a domain-appropriate brief
    v
 /ce-plan
-   |  reads the doc as origin
+   |  enriches the same plan to implementation-ready
    |  R-IDs flow into Requirements; A/F/AE-IDs trace into units and tests
    |  origin scope boundaries are preserved verbatim
    v
 /ce-work
 ```
 
-When `ce-plan` loads with a requirements doc as input, it does not re-litigate product behavior. The doc is authoritative. Plan-time decisions are about execution guardrails — not what's being built.
+When `ce-plan` loads with a requirements-only unified plan as input, it does not re-litigate product behavior. The Product Contract is authoritative. Plan-time decisions are about execution guardrails — not what's being built.
 
 ---
 
@@ -185,8 +185,8 @@ The Phase 4 handoff offers planning, agent doc review, publish to Proof, direct-
 | _(empty)_ | Asks for the feature description |
 | `<feature idea>` | Open-ended brainstorm |
 | `<problem>` | Routes via the product pressure test |
-| Existing `*-requirements.md` path or topic | Resume offer |
-| `output:html` | Write the requirements doc as a single self-contained HTML file instead of markdown. Exclusive — the doc is `.md` OR `.html`, never both. Default is markdown. Set `brainstorm_output: html` in `.compound-engineering/config.local.yaml` to make HTML the default. Pipeline mode (LFG, `disable-model-invocation`) always forces markdown so downstream automation gets a stable text shape. |
+| Existing requirements-only plan path, legacy `*-requirements.md` path, or topic | Resume offer |
+| `output:html` | Write the requirements-only unified plan as a single self-contained HTML file instead of markdown. Exclusive — the artifact is `.md` OR `.html`, never both. Default is markdown. Set `brainstorm_output: html` in `.compound-engineering/config.local.yaml` to make HTML the default. Pipeline mode (LFG, `disable-model-invocation`) always forces markdown so downstream automation gets a stable text shape. |
 
 ---
 
@@ -198,14 +198,14 @@ Stacking three questions per turn produces diluted answers — users pick the ea
 **Why does it pressure-test my premise? I just want to brainstorm.**
 The named gap lenses catch the most common ways feature briefs fail downstream. They fire only when the gap is actually present in your opening — a concrete, well-framed prompt may earn zero probes.
 
-**Can I skip the requirements doc?**
+**Can I skip the requirements-only plan?**
 Yes. The Lightweight tier and the announce-mode fast path support that. If you only need brief alignment, no doc is written.
 
 **What if I already have a PRD or detailed GitHub issue?**
 Skip `ce-brainstorm` and go directly to `/ce-plan`. The plan skill consumes any kind of input.
 
 **What does "Inferred" mean in the synthesis?**
-The agent composes an internal three-bucket draft (Stated / Inferred / Out of scope) as a thinking step before presenting the scoping synthesis. Inferred items are the agent's bets to fill dialogue gaps. Those that survive the keep test surface as call-outs in the scoping synthesis; the rest dissolve into the requirements doc's Key Decisions when the user confirms.
+The agent composes an internal three-bucket draft (Stated / Inferred / Out of scope) as a thinking step before presenting the scoping synthesis. Inferred items are the agent's bets to fill dialogue gaps. Those that survive the keep test surface as call-outs in the scoping synthesis; the rest dissolve into the Product Contract when the user confirms.
 
 **Does it work for non-software topics?**
 Yes — a domain-agnostic facilitator preserves the one-question-at-a-time discipline and right-sizing for naming, decisions, planning, etc.
@@ -215,7 +215,7 @@ Yes — a domain-agnostic facilitator preserves the one-question-at-a-time disci
 ## See Also
 
 - [`ce-ideate`](./ce-ideate.md) — upstream "what's worth exploring" discovery
-- [`ce-plan`](./ce-plan.md) — turn the requirements doc into an implementation plan
-- [`ce-doc-review`](./ce-doc-review.md) — persona-based review of the requirements doc
+- [`ce-plan`](./ce-plan.md) — enrich the requirements-only unified plan into an implementation-ready plan
+- [`ce-doc-review`](./ce-doc-review.md) — persona-based review of the Product Contract or full plan
 - [`ce-work`](./ce-work.md) — execute lightweight changes directly from a brainstorm
 - [`ce-strategy`](./ce-strategy.md) — anchor brainstorms to a documented product strategy

docs/skills/ce-code-review.md

@@ -106,15 +106,15 @@ When autofix mode runs and the in-skill fixer can't resolve everything, the resi
 
 ### 8. Protected artifacts
 
-Compound-engineering pipeline artifacts (`docs/brainstorms/*`, `docs/plans/*.md`, `docs/solutions/*.md`) are protected — reviewers' findings to delete or gitignore them are discarded during synthesis. These are decision artifacts the pipeline depends on; reviewers shouldn't garbage-collect them.
+Compound-engineering pipeline artifacts (`docs/brainstorms/*` legacy/evidence artifacts, `docs/plans/*.{md,html}` unified plans, `docs/solutions/*.md`) are protected — reviewers' findings to delete or gitignore them are discarded during synthesis. These are decision artifacts the pipeline depends on; reviewers shouldn't garbage-collect them.
 
 ---
 
 ## Quick Example
 
 You invoke `/ce-code-review` on a feature branch with a Rails auth change that includes a database migration.
 
-The skill detects you're on a feature branch (no PR yet), resolves the base from `origin/HEAD` (or PR metadata when an open PR exists), and computes the diff. Stage 2 reads commit messages and writes a 2-3 line intent summary. Stage 2b auto-discovers the plan in `docs/plans/` from the branch name and reads its Requirements (R1-R8, U1-U6).
+The skill detects you're on a feature branch (no PR yet), resolves the base from `origin/HEAD` (or PR metadata when an open PR exists), and computes the diff. Stage 2 reads commit messages and writes a 2-3 line intent summary. Stage 2b auto-discovers the plan in `docs/plans/` from the branch name, classifies readiness, and reads Product Contract Requirements plus implementation U-IDs when the artifact is implementation-ready.
 
 Stage 3 selects reviewers: the 6 always-on, plus security (auth touched), reliability (background job for token cleanup), data-migration (migration file present), and deployment-verification agent when the migration is risky. Seven or eight reviewers total, dispatched in parallel.