From 59c18b5aaa16260734ac59cc5777502af8bc359c Mon Sep 17 00:00:00 2001
From: "github-actions[bot]"
 <41898282+github-actions[bot]@users.noreply.github.com>
Date: Wed, 10 Jun 2026 07:49:21 +0000
Subject: [PATCH] chore: convert CE compound-engineering-v3.12.0

---
 .last-processed                               |   2 +-
 dist/.claude-plugin/plugin.json               |   4 +-
 dist/.codex-plugin/plugin.json                |   2 +-
 dist/.cursor-plugin/plugin.json               |   2 +-
 dist/CHANGELOG.md                             |  12 +
 dist/README.md                                |   2 +-
 dist/commands/ce-ideate.md                    |   2 +-
 dist/references/agent-prompts/manifest.json   |   2 +-
 .../references/brainstorm-sections.md         |  15 +-
 .../references/html-rendering.md              | 199 +++---
 .../references/markdown-rendering.md          |  21 +-
 dist/skills/ce-ideate/SKILL.md                |  43 +-
 .../ce-ideate/references/html-rendering.md    | 593 ++++++++++++++++++
 .../ce-ideate/references/ideation-sections.md | 191 ++++++
 .../references/markdown-rendering.md          | 202 ++++++
 .../references/post-ideation-workflow.md      | 237 +++----
 .../references/universal-ideation.md          |  17 +-
 dist/skills/ce-plan/SKILL.md                  |   4 +-
 .../ce-plan/references/html-rendering.md      | 199 +++---
 .../ce-plan/references/markdown-rendering.md  |  21 +-
 .../ce-plan/references/plan-sections.md       |  14 +-
 dist/skills/ce-release-notes/SKILL.md         |   6 +-
 .../ce-setup/references/config-template.yaml  |   1 +
 dist/skills/ce-work-beta/SKILL.md             |   2 +-
 .../references/non-code-execution.md          |   2 +-
 .../references/shipping-workflow.md           |  11 +-
 dist/skills/ce-work/SKILL.md                  |   2 +-
 .../ce-work/references/non-code-execution.md  |   2 +-
 .../ce-work/references/shipping-workflow.md   |  23 +-
 29 files changed, 1419 insertions(+), 414 deletions(-)
 create mode 100644 dist/skills/ce-ideate/references/html-rendering.md
 create mode 100644 dist/skills/ce-ideate/references/ideation-sections.md
 create mode 100644 dist/skills/ce-ideate/references/markdown-rendering.md

diff --git a/.last-processed b/.last-processed
index c855684..cff8726 100644
--- a/.last-processed
+++ b/.last-processed
@@ -1 +1 @@
-compound-engineering-v3.11.2
+compound-engineering-v3.12.0
diff --git a/dist/.claude-plugin/plugin.json b/dist/.claude-plugin/plugin.json
index 7a8d331..360c8ff 100644
--- a/dist/.claude-plugin/plugin.json
+++ b/dist/.claude-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "ce-lite",
-  "version": "3.11.2-lite",
+  "version": "3.12.0-lite",
   "description": "Lightweight-delegation variant of compound-engineering. Agent registrations removed; specialist prompts loaded on demand from references/agent-prompts/. See https://github.com/ak2k/ce-lite.",
   "author": {
     "name": "Kieran Klaassen",
@@ -23,6 +23,6 @@
     "image-generation"
   ],
   "ce_lite": {
-    "upstream_tag": "compound-engineering-v3.11.2"
+    "upstream_tag": "compound-engineering-v3.12.0"
   }
 }
diff --git a/dist/.codex-plugin/plugin.json b/dist/.codex-plugin/plugin.json
index 56def2b..c8063bf 100644
--- a/dist/.codex-plugin/plugin.json
+++ b/dist/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "compound-engineering",
-  "version": "3.11.2",
+  "version": "3.12.0",
   "description": "AI-powered development tools for code review, research, design, and workflow automation.",
   "author": {
     "name": "Kieran Klaassen",
diff --git a/dist/.cursor-plugin/plugin.json b/dist/.cursor-plugin/plugin.json
index ea6759b..1829446 100644
--- a/dist/.cursor-plugin/plugin.json
+++ b/dist/.cursor-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "compound-engineering",
   "displayName": "Compound Engineering",
-  "version": "3.11.2",
+  "version": "3.12.0",
   "description": "AI-powered development tools for code review, research, design, and workflow automation.",
   "author": {
     "name": "Kieran Klaassen",
diff --git a/dist/CHANGELOG.md b/dist/CHANGELOG.md
index c4ea3f0..0ef9bd5 100644
--- a/dist/CHANGELOG.md
+++ b/dist/CHANGELOG.md
@@ -9,6 +9,18 @@ All notable changes to the compound-engineering plugin will be documented in thi
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [3.12.0](https://github.com/EveryInc/compound-engineering-plugin/compare/compound-engineering-v3.11.2...compound-engineering-v3.12.0) (2026-06-09)
+
+
+### Features
+
+* HTML-first ideation docs and a status-free plan model ([#921](https://github.com/EveryInc/compound-engineering-plugin/issues/921)) ([e74e298](https://github.com/EveryInc/compound-engineering-plugin/commit/e74e29864fbfa2f800fc3e08509e2966e4947f1e))
+
+
+### Bug Fixes
+
+* **ce-release-notes:** placeholder links ([#915](https://github.com/EveryInc/compound-engineering-plugin/issues/915)) ([b625049](https://github.com/EveryInc/compound-engineering-plugin/commit/b6250490bec4c0488d68ad66d72bd99f6edb95fd))
+
 ## [3.11.2](https://github.com/EveryInc/compound-engineering-plugin/compare/compound-engineering-v3.11.1...compound-engineering-v3.11.2) (2026-06-06)
 
 
diff --git a/dist/README.md b/dist/README.md
index aefd4ce..d649fcc 100644
--- a/dist/README.md
+++ b/dist/README.md
@@ -24,7 +24,7 @@ The primary entry points for engineering work, invoked as slash commands. Detail
 | Skill | Description |
 |-------|-------------|
 | [`/ce-strategy`](../../docs/skills/ce-strategy.md) | Create or maintain `STRATEGY.md` — the product's target problem, approach, persona, key metrics, and tracks. Re-runnable to update. Read as grounding by `/ce-ideate`, `/ce-brainstorm`, and `/ce-plan` when present |
-| [`/ce-ideate`](../../docs/skills/ce-ideate.md) | Optional big-picture ideation: generate and critically evaluate grounded ideas, then route the strongest one into brainstorming |
+| [`/ce-ideate`](../../docs/skills/ce-ideate.md) | Optional big-picture ideation: generate and critically evaluate grounded ideas, then route the strongest one into brainstorming. Writes the ranked ideation artifact as a single self-contained HTML file by default (human-facing); pass `output:md` for markdown (exclusive — html OR md, never both) |
 | [`/ce-brainstorm`](../../docs/skills/ce-brainstorm.md) | Interactive Q&A to think through a feature or problem and write a right-sized requirements doc before planning. Pass `output:html` to write the doc as a single self-contained HTML file instead of markdown (exclusive — md OR html, never both) |
 | [`/ce-plan`](../../docs/skills/ce-plan.md) | Create structured plans for any multi-step task -- software features, research workflows, events, study plans -- with automatic confidence checking. Pass `output:html` to write the plan as a single self-contained HTML file instead of markdown (exclusive — md OR html, never both) |
 | [`/ce-code-review`](../../docs/skills/ce-code-review.md) | Structured code review with tiered persona agents, confidence gating, and dedup pipeline |
diff --git a/dist/commands/ce-ideate.md b/dist/commands/ce-ideate.md
index 74cdb8e..0ea12bc 100644
--- a/dist/commands/ce-ideate.md
+++ b/dist/commands/ce-ideate.md
@@ -1,6 +1,6 @@
 ---
 description: "ce-ideate"
-argument-hint: "[feature, focus area, or constraint]"
+argument-hint: "[feature, focus area, or constraint] [output:md]"
 ---
 
 <!-- Generated by ce-lite converter — do not edit. Regenerate via converter/generate_commands.py. -->
diff --git a/dist/references/agent-prompts/manifest.json b/dist/references/agent-prompts/manifest.json
index fac0087..be41dc4 100644
--- a/dist/references/agent-prompts/manifest.json
+++ b/dist/references/agent-prompts/manifest.json
@@ -1,6 +1,6 @@
 {
   "schema_version": 1,
-  "upstream_tag": "compound-engineering-v3.11.2",
+  "upstream_tag": "compound-engineering-v3.12.0",
   "agent_count": 43,
   "agents": [
     {
diff --git a/dist/skills/ce-brainstorm/references/brainstorm-sections.md b/dist/skills/ce-brainstorm/references/brainstorm-sections.md
index 8d2cbca..c859851 100644
--- a/dist/skills/ce-brainstorm/references/brainstorm-sections.md
+++ b/dist/skills/ce-brainstorm/references/brainstorm-sections.md
@@ -233,14 +233,13 @@ the brainstorm.
   alongside `date` and as the resume-detection key when `ce-brainstorm`'s
   Phase 0.1 scans `docs/brainstorms/` for an existing artifact to continue.
 
-### Status flip does not apply to brainstorm
-
-Unlike plans, brainstorm artifacts have no `status` field — there is no
-`active → completed` lifecycle. A brainstorm is a one-time output that
-downstream consumers (`ce-plan`, `ce-doc-review`) reference via the plan's
-`origin:` field. The `<span class="status">` HTML hook described in
-`html-rendering.md` is a plan-side mechanic and does not render on
-brainstorm artifacts.
+### No status field
+
+Brainstorm artifacts have no `status` field and no `active → completed`
+lifecycle — a brainstorm is a one-time output that downstream consumers
+(`ce-plan`, `ce-doc-review`) reference via the plan's `origin:` field. No
+CE artifact carries a mutable status; whether work shipped is derived from
+git, not stored in the doc. Do not introduce one.
 
 ### Field-name stability
 
diff --git a/dist/skills/ce-brainstorm/references/html-rendering.md b/dist/skills/ce-brainstorm/references/html-rendering.md
index 7c61b74..53e291e 100644
--- a/dist/skills/ce-brainstorm/references/html-rendering.md
+++ b/dist/skills/ce-brainstorm/references/html-rendering.md
@@ -27,28 +27,18 @@ These hold regardless of which skill produced the artifact.
   Bunny Fonts, etc.), paired with an offline-readable fallback font stack
   so the doc remains readable if the CDN is unreachable.
 - **All metadata appears as visible text — single source of truth.**
-  The artifact's metadata (title, type, status, date, etc. — exact
+  The artifact's metadata (title, type, date, etc. — exact
   fields per-skill, defined in the section contract) renders as visible
   HTML elements that downstream agents and humans read. No hidden
   machine-readable copy in any form: no `<script type="application/json">`
   frontmatter block, no `data-*` attribute mirror, and no
-  `<meta name="status">` / `<meta name="created">` / `<meta name="origin">`
+  `<meta name="created">` / `<meta name="origin">`
   in `<head>` duplicating the same values that appear in the visible
   header. One representation for each value — drift across two copies is
   the failure this rule prevents.
 
   The text-and-attribute redundancy in `<time datetime="2026-05-12">2026-05-12</time>`
   is acceptable because the attribute is a parser hint, not a hidden copy.
-- **Editable status renders as `<span class="status">{value}</span>`.**
-  Downstream tooling (`ce-work` shipping flip, future HTML-aware
-  consumers) finds and rewrites status by selector. Embedding the
-  status value inside a header `<dl>` cell (`<dt>Status</dt><dd>active</dd>`),
-  inside a `<meta>` tag, or as visible text without the `class="status"`
-  hook all break the flip mechanic — the consumer either can't locate
-  the value or can't disambiguate it from prose. The status span may
-  sit anywhere in the doc (inside the header metadata, in a stats
-  strip, in a hero banner); placement is a visual choice, the selector
-  shape is the contract.
 - **Stable IDs as anchor IDs AND visible text.** Every ID-bearing item
   (R-IDs, U-IDs, A-IDs, F-IDs, AE-IDs, KTDs) gets `id="r1"` on its
   element AND appears as visible text inside the element (e.g., the
@@ -112,45 +102,66 @@ Worktree-root only — do not fall through to a main checkout. Users
 working from a worktree who want HTML defaults can add DESIGN.md to the
 worktree.
 
-**DESIGN.md is a partial override, not all-or-nothing.** Real
-DESIGN.md files vary widely: some are token tables, some are CSS
-variables, some are prose; most cover a subset of what HTML composition
-needs. Apply the tokens that fit a long-form text doc — typography roles,
-text colors, contrast targets, border-radius scale, elevation primitives,
-muted-vs-accent split. Skip the rest. Three specific failure modes to
-defend against:
-
+**DESIGN.md is a partial override, not all-or-nothing.** Real DESIGN.md
+files vary widely: some are token tables, some are CSS variables, some are
+prose; most are authored for a *product or marketing surface*, not a
+long-form doc. The governing split: **take the brand's scale-independent
+identity literally, own the scale-dependent layout values yourself, and
+skip decoration.**
+
+- **Take literally (scale-independent identity):** the color palette
+  (under the contrast rule), font *weight* and *style*, OpenType features,
+  and radius *character* (sharp vs rounded). These carry the brand and are
+  safe at any size.
+- **Own it yourself (scale-dependent layout):** the **type size scale**
+  and **spacing magnitudes**. DESIGN.md values are almost always
+  product/marketing-scaled (display headings at 48-80px, airy ~96px
+  section gaps); read them only as *hierarchy*, then set doc-appropriate
+  values (body ~14-16px, headings ~1.2-1.6× body, comfortable paragraph
+  spacing).
+- **Skip decoration:** decorative or atmospheric brand voltage with no
+  content to attach to in a doc — gradient orbs, full-bleed hero
+  photography, motion. Take the palette and feel; do not reproduce the
+  decoration.
+
+Specific cases:
+
+- **Fonts: load only open webfonts; never attempt a proprietary brand
+  face.** A self-contained doc can only load an open webfont (Google Fonts
+  or an open CDN) via the permitted webfont `<link>` plus an offline
+  fallback stack. **Assume a bespoke brand face is proprietary and do not
+  attempt to load it** — Airbnb Cereal, Coinbase Display/Sans, BMW Type,
+  Waldenburg, Circular and the like will not render in a single file;
+  trying just produces a broken fallback. Use the DESIGN.md's own fallback
+  chain, or a family-matched system stack (serif↔serif, sans↔sans,
+  mono↔mono). Load a named face *only* when it is a known open webfont
+  (Inter, Geist, Cal Sans, Roboto…); when unsure whether a face is open,
+  do not try. Honor the DESIGN.md's declared roles (`body` / `display` /
+  `mono`) and never promote a display/decorative face into a body or
+  small-text role. Net: reproduce the brand's serif-vs-sans structure and
+  weight voice, not necessarily its exact faces.
+- **Typography-scale mismatch.** DESIGN.md typography tokens are usually
+  sized for product UI — marketing pages, app screens, hero sections —
+  with display headings at 48-80px. A long-form doc needs body at ~14-16px
+  and headings at ~1.2-1.6× body. When the size scale looks
+  product-scaled (the common case), use the **family**, **weight**, and
+  **OpenType feature** assignments (these carry the design language) and
+  pick the agent's own size scale for the doc surface. Apply DESIGN.md
+  sizes literally only when they are clearly doc-scaled — body 14-16px,
+  headings under ~32px.
 - **Scope mismatch (product UI vs doc surface).** A DESIGN.md aimed at
-  product marketing or app UI may name page-surface colors, button
-  states, input borders, or hero backgrounds that are tied to *that*
-  surface, not to a generic doc. Page-surface colors are the canonical
-  trap — `--surface: #c0f0fb` belongs on the product's marketing page,
-  not on every plan or requirements doc the team writes. Extract the
-  principle (the design language uses a tinted surface) rather than the
-  literal value when the token is product-UI-scoped. Apply literal
-  values only when the token is generic enough to transfer (text color,
-  type scale ratio, radius scale, contrast ratio).
+  product marketing or app UI may name button states, input borders, or
+  hero backgrounds tied to *that* surface, not a generic doc. The page
+  surface is the case to judge: a **reading canvas** — white, off-white,
+  or a legible dark — transfers **literally** and should be the doc
+  background; a bright product/marketing-hero surface
+  (`--surface: #c0f0fb`) does not — extract the principle (the design
+  language uses a tinted surface) rather than the literal value when the
+  token is product-UI-scoped.
 - **Partial coverage.** When DESIGN.md defines some categories but not
-  others (e.g., colors but no spacing scale, typography but no
-  elevation), use DESIGN.md for what it covers and the fallback default
-  for what it doesn't. Do not require DESIGN.md to be complete before
-  honoring it.
-- **Named font without a fetchable source.** When DESIGN.md names a
-  font (e.g., "Signifier", "Every") without a CDN URL or local
-  `@font-face` source the agent can inline, treat the name as a hint
-  about the design intent, not a literal directive. Emit a system-font
-  stack in the same family (serif vs sans vs mono) and pick a weight
-  that matches the intent. The single-file invariant still holds; do
-  not link to an external stylesheet to fetch the named font.
-- **Typography-scale mismatch.** DESIGN.md typography tokens are often
-  sized for product UI — marketing pages, app screens, hero sections —
-  with body text at 18-20px and headings at 32-52px. A long-form doc
-  surface needs body at ~14-16px and headings at ~1.2-1.6× body. When
-  the DESIGN.md size scale looks product-scaled, use the **family**,
-  **weight**, and **OpenType feature** assignments (these carry the
-  design language) and pick the agent's own **size scale** for the doc
-  surface. Apply DESIGN.md sizes literally only when the tokens are
-  clearly doc-scaled — body tokens at 14-16px, headings under ~32px.
+  others (colors but no spacing scale, typography but no elevation), use
+  it for what it covers and the fallback default for the rest. Do not
+  require DESIGN.md to be complete before honoring it.
 
 ## Format principles
 
@@ -256,6 +267,19 @@ long list overwhelms the eye, especially in dark mode. CSS should leave
 `strong` at `color: inherit` unless a specific surface (status pill, ID
 chip) is being styled.
 
+### Chips and pills: uniform shape, no one-sided accent
+
+Status chips, ID chips, and metric pills in the same row share one shape
+— same border-radius, border weight, and fill treatment. Differentiate
+categories only by the chip's overall fill/text color (applied to the
+whole pill, like a soft-tint badge), never by an accent on one edge. A
+colored stripe or arc on a single side of a pill reads as broken and
+asymmetric — as if a border half-failed to render — so avoid it. The same
+holds for any element, not just chips: differentiate by a full tint, not
+a colored stripe on one edge. If an ID chip should stand out from metric
+chips, vary its fill/text color uniformly, not its edge treatment, and
+keep every chip in the row a visual set.
+
 ### No JS framework runtimes
 
 A small inline `<script>` for active-section TOC tracking or anchor-
@@ -304,11 +328,13 @@ contracts — the agent picks shapes that fit the content.
   bold decision title (often with inline code for technical
   identifiers), and prose rationale. Flat cards (not collapsibles) —
   these are reference material readers scan, not drill into.
-- **Risks** — color-coded cards with status eyebrow (e.g., "RISK ·
-  MITIGATED" / "OPEN · DEFERRED FOLLOW-UP") and prose body. Color of
-  the left-border or accent communicates status at a glance.
-- **Scope Boundaries** — callout cards with color-coded left borders
-  (in-scope vs deferred vs outside) when the distinction is meaningful.
+- **Risks** — cards with a color-coded status eyebrow (e.g., "RISK ·
+  MITIGATED" / "OPEN · DEFERRED FOLLOW-UP") and prose body. Communicate
+  status through the eyebrow's color plus an optional subtle full-card
+  tint — not a colored stripe on one edge (see "Chips and pills").
+- **Scope Boundaries** — callout cards distinguished (in-scope vs deferred
+  vs outside) by a colored eyebrow/label plus a subtle full-card tint when
+  the distinction is meaningful — not a one-edge colored stripe.
 
 The agent picks more elaborate or simpler shapes based on what each
 specific artifact's content needs.
@@ -345,20 +371,33 @@ adding a diagram is not license to thin the prose it depicts.
 
 The agent designs SVG coordinates without rendering — layouts that look
 fine in source can collide in practice. Before emitting, trace each
-labeled arrow and each text label:
-
-- **No arrow path passes through a text label.** If an arrow line or
-  curve crosses a label's bounding box, the text reads as struck-through
-  and the arrow reads as terminating at the wrong element. Fix by
-  re-routing the arrow, moving the label, or applying
-  `paint-order: stroke fill` with a stroke color matching the diagram
-  background to halo the label. The halo width is a judgment call:
+labeled arrow, each shape edge, and each text label:
+
+- **No stroke — arrow *or* shape edge/border — passes through a text
+  label.** If an arrow line/curve, or the border of a box, parallelogram,
+  or other shape, crosses a label's bounding box, the text reads as
+  struck-through and the stroke reads as terminating at the wrong element.
+  Fix by re-routing the arrow, moving the label clear of every edge, or
+  applying `paint-order: stroke fill` with a stroke color matching the
+  diagram background to halo the label. The halo width is a judgment call:
   narrow enough not to bleed into glyph strokes (a halo whose width
   approaches the glyph's own stroke width muddies the text color), wide
-  enough to mask underlying arrows (at least the arrow's stroke width
+  enough to mask the underlying stroke (at least its stroke width
   plus a hairline). Verify by inspecting rendered text at the target
   font size — if glyphs look thicker or more colored-toward-halo than
   the same text outside the diagram, the halo is too wide.
+- **Labels inside skewed or rotated shapes sit in the shape's true
+  interior, not its bounding box.** A parallelogram, isometric face, or
+  rotated rect has an interior offset from its bounding box, so a
+  box-aligned (e.g. left-aligned) label spills past the slanted edge.
+  Inset the label to fall inside the actual shape — account for the
+  skew/rotation offset at the label's vertical position — or place it
+  outside the shape with a short leader. This is the usual failure in the
+  **stacked-layers idiom** (offset parallelograms implying z-order), where
+  per-layer labels left-aligned to the container both overflow the lower
+  layers and get crossed by the neighbouring layer's edge. Prefer
+  labelling each layer in its own un-overlapped region, or to the side of
+  the stack.
 - **Arrow labels sit adjacent to the arrow's midpoint** (typically
   within ~10-15px above or beside the line they describe). A label
   floating at the diagram's edge that readers have to trace back to an
@@ -460,14 +499,28 @@ fine when the content suggests them.
   Before / After, Two alternatives).
 - **Tinted callout cards** for content that is "different in kind"
   (Deferred, Open Questions, advisory notes, unit-level execution notes)
-  — color-coded left borders communicate kind at a glance.
+  — a subtle full-card background tint plus a colored eyebrow/label
+  communicates kind at a glance. Avoid a colored stripe on one edge; tint
+  the whole card instead.
 
 ## Agent-consumability rules
 
-Downstream agents that read HTML today (`ce-work`, future consumers) read
-the HTML file as text linearly, not via DOM extraction. `ce-doc-review` is
-not a current HTML consumer (see opening note). Compose so semantic
-understanding is reachable in source:
+Downstream agents that read HTML today (`ce-work`, a skill re-reading its
+own prior artifact on a resume run, future consumers) reason over the HTML
+as text — the way they reason over markdown, not via DOM extraction or a
+script-style parse. `ce-doc-review` is not a current HTML consumer (see
+opening note).
+
+These rules are why such a consumer can locate one item (a single
+requirement, unit, idea, or other ID-bearing entry) and reason over it from
+source alone — its title, every labeled field, and any diagram's meaning —
+with no hidden machine-readable copy to fall back on. The semantic structure
+*is* the extraction contract: it is what makes the single-source-of-truth
+invariant (no `data-*` or JSON metadata mirror) safe rather than lossy.
+Weakening it — `<article>` item boundaries collapsed into `<div>` soup, a
+field label demoted to an attribute, one item's content scattered across
+distant parts of the doc — breaks that reasoning even when the rendered page
+looks identical. Compose so semantic understanding is reachable in source:
 
 - **Use semantic HTML over `<div>` soup.** `<article>` per unit card,
   `<dl>` for metadata pairs, `<table>` for tabular content, `<details>`
@@ -502,12 +555,10 @@ Before returning the artifact, scan it for common slips:
 - **Single self-contained file.** No companion `.css` / `.js` / `.svg`.
 - **No hidden machine-readable metadata copy.** No
   `<script type="application/json">` frontmatter block, no `data-*`
-  attributes mirroring visible values, **no `<meta name="status">` /
-  `<meta name="created">` / `<meta name="origin">` etc. in `<head>`
+  attributes mirroring visible values, **no `<meta name="created">` /
+  `<meta name="origin">` etc. in `<head>`
   duplicating the visible header**. Metadata lives in visible text;
   one source of truth per value.
-- **Status renders as `<span class="status">{value}</span>`** so
-  downstream tooling can flip `active → completed` by selector.
 - **All stable IDs** appear as both `id=""` and visible text.
 - **Section heading vocabulary** matches the section contract names
   (downstream agents grep these).
@@ -522,6 +573,10 @@ Before returning the artifact, scan it for common slips:
 - **Within-section sub-nav** is present for sections with 6+ repeating
   cards.
 - **Body `<strong>`** is not colored with accent palette.
+- **No one-edge colored accent** (a colored stripe/arc on a single side)
+  on chips, pills, or callout cards — differentiate by uniform fill +
+  colored eyebrow/label instead. A one-sided stripe reads as
+  broken/unintentional; chips in a row must be a uniform visual set.
 - **`<details>`** inside repeating cards have no `open` attribute.
 - **Diagram labels** are legible — no arrow paths crossing text,
   halo width appropriate for font size.
diff --git a/dist/skills/ce-brainstorm/references/markdown-rendering.md b/dist/skills/ce-brainstorm/references/markdown-rendering.md
index c1a1c98..8e20a6b 100644
--- a/dist/skills/ce-brainstorm/references/markdown-rendering.md
+++ b/dist/skills/ce-brainstorm/references/markdown-rendering.md
@@ -13,10 +13,8 @@ content rendered by different skills shares the same markdown principles.
 These hold regardless of which skill produced the artifact.
 
 - **YAML frontmatter at the top of the file.** Standard `---` delimited block
-  containing the artifact's stable metadata (title, status, date, type, etc.
-  — exact fields are per-skill, defined in the section contract). Editable
-  in place; tools and agents that do status flips (`active → completed`)
-  update the YAML directly.
+  containing the artifact's stable metadata (title, date, type, etc.
+  — exact fields are per-skill, defined in the section contract).
 - **ASCII identifiers in anchors.** Markdown headings auto-generate anchors
   from the heading text. Keep headings ASCII so anchors are predictable
   (`#implementation-units`, not `#implementación-units`).
@@ -181,15 +179,12 @@ brainstorm frontmatter). Common rules:
 
 - YAML at the top of the file, delimited by `---` on its own line above
   and below.
-- Field names in lowercase snake_case (`status`, `created_at`, not
-  `Status`, `CreatedAt`).
-- **Status lifecycle is per-contract.** When the section contract
-  defines a `status` field with a lifecycle (plans use
-  `active → completed`, flipped by ce-work at shipping time via direct
-  YAML edit), it is editable in place. When the section contract does
-  not define a status lifecycle (brainstorms, for example, have no
-  `active → completed` flip — they are upstream of plans and
-  referenced via the plan's `origin:`), do not introduce one.
+- Field names in lowercase snake_case (`created_at`, `topic`, not
+  `CreatedAt`, `Topic`).
+- **No status / lifecycle field.** Artifacts are point-in-time records
+  (decision or discovery), not tracked work items. Do not introduce a
+  mutable `status` field or an `active → completed` lifecycle — whether
+  the work shipped is derived from git, not stored in the doc.
 - Stable across artifact revisions — never rename or repurpose a field.
 
 ## Post-write audit
diff --git a/dist/skills/ce-ideate/SKILL.md b/dist/skills/ce-ideate/SKILL.md
index 80c22cc..25a22d2 100644
--- a/dist/skills/ce-ideate/SKILL.md
+++ b/dist/skills/ce-ideate/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: ce-ideate
 description: "Generate and critically evaluate grounded ideas about a topic. Use when asking what to improve, requesting idea generation, exploring surprising directions, or wanting the AI to proactively suggest strong options before brainstorming one in depth. Triggers on phrases like 'what should I improve', 'give me ideas', 'ideate on X', 'surprise me', 'what would you change', or any request for AI-generated suggestions rather than refining the user's own idea."
-argument-hint: "[feature, focus area, or constraint]"
+argument-hint: "[feature, focus area, or constraint] [output:md]"
 
 ---
 
@@ -44,7 +44,7 @@ argument-hint: "[feature, focus area, or constraint]"
 - `ce-brainstorm` answers: "What exactly should one chosen idea mean?"
 - `ce-plan` answers: "How should it be built?"
 
-This workflow produces a ranked ideation artifact in `docs/ideation/`. It does **not** produce requirements, plans, or code.
+This workflow produces a ranked ideation artifact — written to `docs/ideation/` when present, else a CE temp path (see Phase 4). It does **not** produce requirements, plans, or code.
 
 ## Interaction Method
 
@@ -75,9 +75,33 @@ If no argument is provided, proceed with open-ended ideation.
 
 ### Phase 0: Resume and Scope
 
+#### 0.0 Resolve Output Mode
+
+Determine `OUTPUT_FORMAT` for the ideation artifact this run might persist. Output mode is **exclusive** — the ideation doc is written as either HTML (`.html`) OR markdown (`.md`), never both. Precedence: CLI arg > config > default (`html`), with a hard pipeline-mode override.
+
+Unlike `ce-plan` and `ce-brainstorm` (which default to `md`), ce-ideate defaults to **`html`** — ideation artifacts are read mainly by humans weighing candidate directions, and a rich self-contained HTML file (with illustrative diagrams for the top candidates) makes the ideas easier to approach.
+
+**Read config (pre-resolved at skill load):**
+!`cat "$(git rev-parse --show-toplevel 2>/dev/null)/.compound-engineering/config.local.yaml" 2>/dev/null || echo '__NO_CONFIG__'`
+
+Resolution steps:
+
+1. **CLI arg.** Scan `$ARGUMENTS` for a token starting with the literal prefix `output:`. If found, strip it from arguments before treating the remainder as the focus hint, and match its value case-insensitively against `md` and `html`.
+   - `output:` alone (no value) → no-op, fall through to step 2.
+   - `output:<unknown>` (e.g., `output:pdf`) → drop the token, fall through to step 2, and remember to emit a one-line note above the post-ideation menu after final resolution: `Ignored unknown output: value '<value>' — using <resolved_format> instead.` where `<resolved_format>` is the value `OUTPUT_FORMAT` actually resolved to after steps 2-4. Do not hardcode a format in the note — that misleads users when config or the default differs from what you assume.
+2. **Config.** If step 1 did not resolve and the pre-resolved YAML above has an **active (non-commented)** `ideate_output:` key whose value matches `md` or `html` (case-insensitive), use it. Missing, invalid, or commented values fall through silently. Critical: lines starting with `#` are YAML comments and must be ignored — the shipped config template includes a commented example like `# ideate_output: md` to document the option, and matching that as an active setting would silently override the default on every run without the user having opted in.
+3. **Default.** Otherwise `OUTPUT_FORMAT=html`.
+4. **Pipeline override.** When invoked from any pipeline or `disable-model-invocation` context, force `OUTPUT_FORMAT=md` regardless of steps 1-3 — automated downstream consumers parse markdown reliably and HTML in pipeline runs is unnecessary friction.
+
+**Token-parsing convention:** only literal-prefix flag tokens (`output:`, `mode:` where applicable) are consumed and stripped. Other `<word>:<word>` tokens — including conventional commit prefixes like `feat:`, `fix:`, `chore:` that may appear inside a focus hint — pass through verbatim.
+
+**Defer loading the format-rendering reference.** The deliverable is written at Phase 4 (after generation), so `references/ideation-sections.md` and the format-rendering references (`markdown-rendering.md` / `html-rendering.md`) are only needed then — loading them at Phase 0.0 would carry them through the entire grounding and ideation dispatch for no benefit. Resolve `OUTPUT_FORMAT` now, but load the section contract and the matching rendering reference at write time (see `references/post-ideation-workflow.md` §4.1).
+
+The `output:` preference does NOT auto-propagate to `ce-brainstorm` on handoff (Phase 5) — ce-brainstorm re-resolves its own `brainstorm_output` config independently. Asymmetric output (`ideation.html` + `requirements.md`) is acceptable; users who want HTML for both set both keys in `.compound-engineering/config.local.yaml`.
+
 #### 0.1 Check for Recent Ideation Work
 
-Look in `docs/ideation/` for ideation documents created within the last 30 days.
+Look in `docs/ideation/` for ideation documents (`*.md` or `*.html`) created within the last 30 days.
 
 Treat a prior ideation doc as relevant when:
 
@@ -95,8 +119,9 @@ If continuing:
 
 - read the document
 - summarize what has already been explored
-- preserve previous idea statuses
+- preserve the previous ideas and rejection summary
 - update the existing file instead of creating a duplicate
+- **write the update back in the existing file's format**, overriding the Phase 0.0 baseline: resuming a `.html` doc rewrites HTML, a `.md` doc rewrites markdown. Format precedence on resume is: explicit `output:` arg this run > resumed file's extension > config > default (`html`); a pipeline/`disable-model-invocation` run still forces `md` per Phase 0.0. An explicit `output:` arg that differs from the existing file switches the artifact's format (write the new-format file; leave the original in place).
 
 #### 0.2 Subject-Identification Gate
 
@@ -184,7 +209,7 @@ Do not prescribe correction phrases ("say X to switch"). State the inferred mode
 
 **Active confirmation on mode ambiguity.** Only fire when mode classification is genuinely ambiguous *after* 0.2 settled the subject — e.g., "our docs" could mean repo docs (repo-grounded) or public marketing docs (elsewhere-software). Most subjects settled in 0.2 classify cleanly here. When ambiguous, ask one confirmation question via the blocking tool with two self-contained labels naming the two candidate interpretations in plain language (e.g., "Treat as repo docs in this codebase" vs "Treat as public marketing docs") — never leak internal mode names. Otherwise the one-sentence inferred-mode statement is sufficient; do not ask.
 
-**Routing rule (non-software mode).** When Decision 2 = non-software, still run Phase 1 Elsewhere-mode grounding (user-context synthesis + web-research by default; skip phrases honored). Learnings-researcher is skipped by default in this mode — the CWD's `docs/solutions/` rarely transfers to naming, narrative, personal, or non-digital business topics; see Phase 1 for the full rationale. Then load `references/universal-ideation.md` and follow it in place of Phase 2's software frame dispatch and the Phase 6 menu narrative. This load is non-optional — the file contains the domain-agnostic generation frames, critique rubric, and wrap-up menu that replace Phase 2 and the post-ideation menu for this mode, and none of those details live in this main body. Improvising from memory produces the wrong facilitation for non-software topics. Do not run the repo-specific codebase scan at any point. The §6.5 Proof Failure Ladder in `references/post-ideation-workflow.md` still applies — load and follow it whenever a Proof save (the elsewhere-mode default for Save and end) fails, so the local-save fallback path stays reachable in non-software elsewhere runs.
+**Routing rule (non-software mode).** When Decision 2 = non-software, still run Phase 1 Elsewhere-mode grounding (user-context synthesis + web-research by default; skip phrases honored). Learnings-researcher is skipped by default in this mode — the CWD's `docs/solutions/` rarely transfers to naming, narrative, personal, or non-digital business topics; see Phase 1 for the full rationale. Then load `references/universal-ideation.md` and follow it in place of Phase 2's software frame dispatch and the Phase 5 menu narrative. This load is non-optional — the file contains the domain-agnostic generation frames, critique rubric, and wrap-up menu that replace Phase 2 and the post-ideation menu for this mode, and none of those details live in this main body. Improvising from memory produces the wrong facilitation for non-software topics. Do not run the repo-specific codebase scan at any point. The deliverable is auto-written here too (per `references/post-ideation-workflow.md` Phase 4); if the user opens a markdown deliverable in Proof and it fails, the §5.1 Proof handling applies and the auto-written local file remains the intact record.
 
 #### 0.4 Context-Substance Gate (Elsewhere Modes Only)
 
@@ -261,7 +286,7 @@ mkdir -p "$SCRATCH_DIR"
 echo "$SCRATCH_DIR"
 ```
 
-Use the echoed absolute path (`/tmp/compound-engineering/ce-ideate/<run-id>`) as `<scratch-dir>` for every subsequent checkpoint write and cache read in this run. The run directory is not deleted on Phase 6 completion — the V15 cache is session-scoped and reused across run-ids, and the checkpoints follow the cross-invocation-reusable convention of leaving session-scoped artifacts for later invocations to find.
+Use the echoed absolute path (`/tmp/compound-engineering/ce-ideate/<run-id>`) as `<scratch-dir>` for every subsequent checkpoint write and cache read in this run. The run directory is not deleted on completion — the V15 cache is session-scoped and reused across run-ids, the checkpoints follow the cross-invocation-reusable convention, and in the no-repo case the deliverable itself is written here (see `references/post-ideation-workflow.md` Phase 4 and §5.5).
 
 Run grounding agents in parallel in the **foreground** (do not background — results are needed before Phase 2):
 
@@ -361,7 +386,7 @@ This step is a single orchestrator-side analysis against the grounding summary a
 
 **Surprise-me skip.** In surprise-me mode there is no settled subject to decompose — different frames will surface different subjects in Phase 2, and the cross-cutting synthesis step there serves the analogous coverage role. Skip Phase 1.5 in surprise-me mode and note `Decomposition skipped — surprise-me mode` in the grounding summary.
 
-Append the axis list (or skip-reason) to the consolidated grounding summary under a section labeled `Topic axes`. Phase 2 reads this section to thread axes into sub-agent prompts; Phase 3 uses it for axis-spread scoring; Phase 5's artifact template includes it under Grounding Context.
+Append the axis list (or skip-reason) to the consolidated grounding summary under a section labeled `Topic axes`. Phase 2 reads this section to thread axes into sub-agent prompts; Phase 3 uses it for axis-spread scoring; the Phase 4 artifact includes it under Grounding Context (per `references/ideation-sections.md`).
 
 ### Phase 2: Divergent Ideation
 
@@ -424,6 +449,6 @@ After all sub-agents return:
 4. If a focus was provided, weight the merged list toward it without excluding stronger adjacent ideas.
 5. Spread ideas across multiple dimensions when justified: workflow/DX, reliability, extensibility, missing capabilities, docs/knowledge compounding, quality/maintenance, leverage on future work.
 
-**Checkpoint A (V17).** Immediately after the cross-cutting synthesis step completes and the raw candidate list is consolidated, write `<scratch-dir>/raw-candidates.md` (using the absolute path captured in Phase 1) containing the full candidate list with sub-agent attribution. This protects the most expensive output (6 parallel sub-agent dispatches + dedupe) before Phase 3 critique potentially compacts context. Best-effort: if the write fails (disk full, permissions), log a warning and proceed; the checkpoint is not load-bearing. Not cleaned up at the end of the run (the run directory is preserved so the V15 cache remains reusable across run-ids in the same session — see Phase 6).
+**Checkpoint A (V17).** Immediately after the cross-cutting synthesis step completes and the raw candidate list is consolidated, write `<scratch-dir>/raw-candidates.md` (using the absolute path captured in Phase 1) containing the full candidate list with sub-agent attribution. This protects the most expensive output (6 parallel sub-agent dispatches + dedupe) before Phase 3 critique potentially compacts context. Best-effort: if the write fails (disk full, permissions), log a warning and proceed; the checkpoint is not load-bearing. Not cleaned up at the end of the run (the run directory is preserved so the V15 cache remains reusable across run-ids in the same session — see Phase 5).
 
-After merging and synthesis — and before presenting survivors — load `references/post-ideation-workflow.md`. This load is non-optional. The file contains the adversarial filtering rubric, artifact template, quality bar, and the canonical Phase 6 handoff menu (Refine, Open and iterate in Proof, Brainstorm, Save and end) — these options do not appear anywhere in this main body. Skipping the load silently degrades every subsequent step; the agent improvises the menu from memory instead of presenting the documented options. "Quickly" means fewer Phase 2 sub-agents, not skipping references. Do not load this file before Phase 2 agent dispatch completes.
\ No newline at end of file
+After merging and synthesis — and before writing and presenting the deliverable — load `references/post-ideation-workflow.md`. This load is non-optional. The file contains the adversarial filtering rubric, the auto-write + concise-summary flow (Phase 4), the artifact section contract, the quality bar, and the canonical Phase 5 next-steps menu (Open, Brainstorm one idea, Iterate on one idea, Done) — these details do not appear anywhere in this main body. Skipping the load silently degrades every subsequent step; the agent improvises the flow and menu from memory instead of following the documented ones. "Quickly" means fewer Phase 2 sub-agents, not skipping references. Do not load this file before Phase 2 agent dispatch completes.
\ No newline at end of file
diff --git a/dist/skills/ce-ideate/references/html-rendering.md b/dist/skills/ce-ideate/references/html-rendering.md
new file mode 100644
index 0000000..53e291e
--- /dev/null
+++ b/dist/skills/ce-ideate/references/html-rendering.md
@@ -0,0 +1,593 @@
+# HTML Rendering
+
+This is a format-rendering reference — it describes how to render any
+artifact in HTML, independent of which skill is producing it.
+
+It is paired with a section contract (`plan-sections.md`,
+`brainstorm-sections.md`, etc.) that describes *what* the artifact contains.
+This reference describes *how* HTML specifically presents it. The same
+content rendered by different skills shares the same HTML principles.
+
+The HTML artifact is the *only* artifact the skill produces for that run —
+output mode is exclusive (markdown OR HTML, never both). Downstream
+consumers that read HTML today (`ce-work`, human readers) do so directly;
+the agent-consumability rules below make that work. `ce-doc-review` is
+*not* currently an HTML consumer — its mutation mechanics are markdown-only,
+so the ce-plan handoff gates the 5.3.8 doc-review pass to `OUTPUT_FORMAT=md`
+runs and skips it for HTML.
+
+## Hard invariants
+
+These hold regardless of which skill produced the artifact.
+
+- **Single self-contained HTML5 file.** No companion `.css`, `.js`, or
+  `.svg` files. CSS lives in `<style>`. SVG lives inline. Images are
+  base64 data URIs or inline SVG. The one permitted exception is a
+  `<link rel="stylesheet">` to a CDN webfont CSS endpoint (Google Fonts,
+  Bunny Fonts, etc.), paired with an offline-readable fallback font stack
+  so the doc remains readable if the CDN is unreachable.
+- **All metadata appears as visible text — single source of truth.**
+  The artifact's metadata (title, type, date, etc. — exact
+  fields per-skill, defined in the section contract) renders as visible
+  HTML elements that downstream agents and humans read. No hidden
+  machine-readable copy in any form: no `<script type="application/json">`
+  frontmatter block, no `data-*` attribute mirror, and no
+  `<meta name="created">` / `<meta name="origin">`
+  in `<head>` duplicating the same values that appear in the visible
+  header. One representation for each value — drift across two copies is
+  the failure this rule prevents.
+
+  The text-and-attribute redundancy in `<time datetime="2026-05-12">2026-05-12</time>`
+  is acceptable because the attribute is a parser hint, not a hidden copy.
+- **Stable IDs as anchor IDs AND visible text.** Every ID-bearing item
+  (R-IDs, U-IDs, A-IDs, F-IDs, AE-IDs, KTDs) gets `id="r1"` on its
+  element AND appears as visible text inside the element (e.g., the
+  text "R1." inside the table cell or heading). Downstream agents find
+  the ID in source the same way they find it in markdown.
+- **Source / composition signal.** A visible footer at the bottom of
+  the doc names the composition timestamp and the source identifier
+  (the user prompt context, the upstream brainstorm doc when one
+  exists, or just the composing skill name when there's no external
+  source). Example shape:
+  `<footer class="composition-signal">Composed 2026-05-17T14:23Z by ce-plan from <code>docs/brainstorms/...-requirements.md</code></footer>`.
+  Under exclusive output mode this signal is the artifact's own
+  provenance — there's no markdown sibling to reference. Omitting it
+  leaves readers unable to tell how stale the rendering is.
+- **ASCII identifiers.** Class names, element IDs, data attribute names
+  are ASCII-only.
+
+## Precedence stack for style preferences
+
+Honor user style preferences in this order (highest to lowest):
+
+1. **In-session conversation** — explicit direction the user gave this run.
+2. **Preferred stylesheet reference** named in loaded agent-instruction
+   context (typically `AGENTS.md` / `CLAUDE.md`, but scan loaded context;
+   don't enumerate locations). The reference may be a file path
+   (`docs/style.css`), a URL, a named library ("Tailwind"), or a style
+   brand ("Stripe docs"). Agent-instruction files carry deliberate
+   agent-aware preferences, so this tier sits above DESIGN.md.
+3. **DESIGN.md** discovered on the filesystem (see "DESIGN.md discovery"
+   below).
+4. **Fallback default** — the opinionated palette / typography choices the
+   agent makes when no preference exists.
+
+### Active-recall at compose time
+
+Before writing the CSS, scan loaded context for any stylesheet reference
+the user has indicated for documents like this. If found and inlinable
+(short local file, fetchable URL within budget), inline it into `<style>`.
+If found but not inlinable (large framework, paywalled stylesheet, named
+system without a fetchable source), compose CSS in its spirit — typography,
+color, density cues drawn from the named system. Only fall back to the
+default style when no preference signal exists.
+
+The single-file invariant is preserved either way. External
+`<link rel="stylesheet">` is permitted only for CDN webfont CSS (with the
+offline fallback font stack); never link to an external stylesheet
+carrying layout, color, or typography rules the doc cannot read offline.
+
+### DESIGN.md discovery
+
+When tier 3 of the precedence stack applies, look for a DESIGN.md file in
+these locations, first match wins:
+
+1. Worktree root (resolve via `git rev-parse --show-toplevel`).
+2. `docs/DESIGN.md`.
+3. `.compound-engineering/DESIGN.md`.
+
+Read once at compose time. Absent → fall through to the fallback default.
+
+Worktree-root only — do not fall through to a main checkout. Users
+working from a worktree who want HTML defaults can add DESIGN.md to the
+worktree.
+
+**DESIGN.md is a partial override, not all-or-nothing.** Real DESIGN.md
+files vary widely: some are token tables, some are CSS variables, some are
+prose; most are authored for a *product or marketing surface*, not a
+long-form doc. The governing split: **take the brand's scale-independent
+identity literally, own the scale-dependent layout values yourself, and
+skip decoration.**
+
+- **Take literally (scale-independent identity):** the color palette
+  (under the contrast rule), font *weight* and *style*, OpenType features,
+  and radius *character* (sharp vs rounded). These carry the brand and are
+  safe at any size.
+- **Own it yourself (scale-dependent layout):** the **type size scale**
+  and **spacing magnitudes**. DESIGN.md values are almost always
+  product/marketing-scaled (display headings at 48-80px, airy ~96px
+  section gaps); read them only as *hierarchy*, then set doc-appropriate
+  values (body ~14-16px, headings ~1.2-1.6× body, comfortable paragraph
+  spacing).
+- **Skip decoration:** decorative or atmospheric brand voltage with no
+  content to attach to in a doc — gradient orbs, full-bleed hero
+  photography, motion. Take the palette and feel; do not reproduce the
+  decoration.
+
+Specific cases:
+
+- **Fonts: load only open webfonts; never attempt a proprietary brand
+  face.** A self-contained doc can only load an open webfont (Google Fonts
+  or an open CDN) via the permitted webfont `<link>` plus an offline
+  fallback stack. **Assume a bespoke brand face is proprietary and do not
+  attempt to load it** — Airbnb Cereal, Coinbase Display/Sans, BMW Type,
+  Waldenburg, Circular and the like will not render in a single file;
+  trying just produces a broken fallback. Use the DESIGN.md's own fallback
+  chain, or a family-matched system stack (serif↔serif, sans↔sans,
+  mono↔mono). Load a named face *only* when it is a known open webfont
+  (Inter, Geist, Cal Sans, Roboto…); when unsure whether a face is open,
+  do not try. Honor the DESIGN.md's declared roles (`body` / `display` /
+  `mono`) and never promote a display/decorative face into a body or
+  small-text role. Net: reproduce the brand's serif-vs-sans structure and
+  weight voice, not necessarily its exact faces.
+- **Typography-scale mismatch.** DESIGN.md typography tokens are usually
+  sized for product UI — marketing pages, app screens, hero sections —
+  with display headings at 48-80px. A long-form doc needs body at ~14-16px
+  and headings at ~1.2-1.6× body. When the size scale looks
+  product-scaled (the common case), use the **family**, **weight**, and
+  **OpenType feature** assignments (these carry the design language) and
+  pick the agent's own size scale for the doc surface. Apply DESIGN.md
+  sizes literally only when they are clearly doc-scaled — body 14-16px,
+  headings under ~32px.
+- **Scope mismatch (product UI vs doc surface).** A DESIGN.md aimed at
+  product marketing or app UI may name button states, input borders, or
+  hero backgrounds tied to *that* surface, not a generic doc. The page
+  surface is the case to judge: a **reading canvas** — white, off-white,
+  or a legible dark — transfers **literally** and should be the doc
+  background; a bright product/marketing-hero surface
+  (`--surface: #c0f0fb`) does not — extract the principle (the design
+  language uses a tinted surface) rather than the literal value when the
+  token is product-UI-scoped.
+- **Partial coverage.** When DESIGN.md defines some categories but not
+  others (colors but no spacing scale, typography but no elevation), use
+  it for what it covers and the fallback default for the rest. Do not
+  require DESIGN.md to be complete before honoring it.
+
+## Format principles
+
+These shape what "good" HTML looks like; the agent applies them per
+artifact based on content.
+
+### Readable measure, not full bleed
+
+Long-form text is unreadable at full viewport width — past ~80 characters
+per line the eye loses the return sweep and scanning slows. As a
+fallback-default (precedence tier 4, overridden by in-session direction or
+DESIGN.md), center the document in a content container and hold prose to a
+comfortable measure.
+
+- **Page container.** A centered column with a max-width in the ~820-960px
+  band (`margin-inline: auto`) keeps the doc off the far edges of wide
+  monitors while leaving room for the format's richer shapes.
+- **Prose measure.** Hold running paragraphs to roughly 65-80 characters
+  (`max-width: ~70ch` on text blocks). The named test: read a paragraph at
+  full window width on a wide display — if the return sweep to the next
+  line is effortful, the measure is too wide.
+- **Let wide content break out.** Tables, diagrams, and side-by-side
+  columns may use the full container width (or wider) when the content
+  needs it — the measure constraint is for prose, not for everything.
+
+Express the constraint in `ch`/`rem` rather than a single hardcoded pixel
+value so it survives font-size and DESIGN.md overrides. DESIGN.md or an
+in-session instruction overrides these values; this is the fallback when no
+layout preference exists.
+
+### Markdown source is content, not design
+
+When markdown (or markdown-shaped chat context) is part of the input, use
+it for semantic content — what the doc is about, what sections exist,
+what facts each section establishes. Do NOT treat its bullet-vs-table
+presentation choices as authoritative; re-choose the rendering per
+content shape in HTML's richer affordance space. If the markdown rendered
+13 requirements as a bulleted list, that does NOT mean HTML must render
+them as a list — ask whether 13 items sharing `ID + body` shape deserve
+a table.
+
+### Prose is authoritative
+
+When a visualization disagrees with the surrounding prose, the prose
+governs. If they diverge, the visualization is wrong.
+
+### Hyperlink the reference index
+
+When the doc has a Sources & References (or equivalent reference-index)
+section, hyperlink each entry to its canonical destination so readers
+can open it directly. A long bare-text list of paths and ticket IDs is
+the format's biggest unforced UX miss — the reader has to copy-paste
+every entry into a browser or IDE.
+
+Resolve the repo's GitHub URL once at compose time:
+
+```bash
+git remote get-url origin
+```
+
+Apply linking to three reference shapes:
+
+- **Repo-relative code/doc paths** (`services/foo.ts`,
+  `docs/solutions/bar.md`) → `<repo-url>/blob/main/<path>`.
+- **Named GitHub PRs/issues** (`PR #636`, `issue #1048`) →
+  `<repo-url>/pull/636` or `<repo-url>/issues/1048`.
+- **Named external trackers** (Linear `ESP-1705`, Jira `PROJ-123`) →
+  link only when the workspace URL is established in loaded context
+  (e.g., a `linear.app/<workspace>/...` URL appeared earlier in the
+  session or in `AGENTS.md`); otherwise leave as text.
+
+**Do not invent URLs.** If `origin` isn't a GitHub URL (GitLab,
+Bitbucket, internal host) and the equivalent main-tree URL pattern
+isn't obvious, leave entries as `<code>` text. If the external
+tracker workspace isn't established, leave as text. A broken or
+guessed link is worse than no link.
+
+**Scope: reference index only, not inline prose.** Inline `<code>`
+mentions of paths or PRs inside paragraph prose stay as code or text.
+Linking every mention would clutter; readers expect clickable jumps
+where the doc presents itself as a reference index.
+
+### Text contrast is local
+
+Every text-on-background pairing must hold up on its own. A color that
+works for prose on the page background does not automatically work for
+a small label inside a tinted container. The most common violation:
+applying a generic "muted" text variable (calibrated for prose-on-bg) to
+secondary text inside an accent-soft / warn-soft / info-soft container.
+
+Test by reading each filled shape's labels at the rendered scale. If the
+subtitle or secondary text feels washed-out against the fill, the choice
+is wrong for that local context — pick a color from the same family as
+the fill (accent-text for accent-soft, etc.) or drop the muting entirely
+and rely on font-size and weight for hierarchy.
+
+### Body bold not colored by default
+
+Reserve accent text color for status chips, ID chips, links, and section
+borders. Do NOT color `<strong>` in body content by default. Bold weight
+already carries emphasis; applying accent color to every `<strong>` in a
+long list overwhelms the eye, especially in dark mode. CSS should leave
+`strong` at `color: inherit` unless a specific surface (status pill, ID
+chip) is being styled.
+
+### Chips and pills: uniform shape, no one-sided accent
+
+Status chips, ID chips, and metric pills in the same row share one shape
+— same border-radius, border weight, and fill treatment. Differentiate
+categories only by the chip's overall fill/text color (applied to the
+whole pill, like a soft-tint badge), never by an accent on one edge. A
+colored stripe or arc on a single side of a pill reads as broken and
+asymmetric — as if a border half-failed to render — so avoid it. The same
+holds for any element, not just chips: differentiate by a full tint, not
+a colored stripe on one edge. If an ID chip should stand out from metric
+chips, vary its fill/text color uniformly, not its edge treatment, and
+keep every chip in the row a visual set.
+
+### No JS framework runtimes
+
+A small inline `<script>` for active-section TOC tracking or anchor-
+permalink behavior is acceptable. React, Vue, Svelte, or any framework
+runtime is not. The single-file invariant doesn't permit framework
+bundles, and the artifact's longevity doesn't warrant a build dependency.
+
+## Section anatomy
+
+How section types commonly render in HTML. These are patterns, not
+contracts — the agent picks shapes that fit the content.
+
+- **Summary / Problem Frame** — semantic `<section>` with prose
+  paragraphs. Optionally precede with an eyebrow label (small-caps tag
+  above the title) for editorial polish.
+- **Requirements** — `<table>` is the default at 5+ uniform items;
+  bullets at smaller counts. Concern-grouping takes precedence over the
+  flat-table default: when requirements span distinct concerns, group them
+  under bold inline headers (or per-group sections) first, then apply the
+  5+ table default *within* each group rather than flattening the whole
+  section into one table. Each row has the R-ID as visible text in
+  its own column. Consider adding a "covered by" column for reverse
+  traceability when ID-anchored items have downstream references in
+  the same doc.
+- **Implementation Units** — repeating `<article>` cards with a stable
+  ID chip (visible "U1" text), a metadata strip (`<dl>` with field
+  labels and values for Goal, Files, Dependencies), and secondary
+  content (Approach, Test Scenarios, Verification, Patterns to Follow)
+  inside `<details>` collapsibles, **default-closed**. At 3+ units the
+  default-closed rule is load-bearing — rendering all units fully
+  expanded turns the doc into one continuous scroll where the reader
+  can't see the unit list at a glance. The metadata strip is the
+  primary always-visible surface; subsection labels (`<summary>`) are
+  clickable affordances for readers to expand on demand. A single unit
+  with no secondary content can skip `<details>` entirely; the rule
+  fires when content exists to hide. The `<dl>` strip is for *descriptive*
+  fields (Goal, Files, Dependencies). A *directive* field — `Execution
+  note` is the canonical case, carrying a procedural instruction the
+  implementer must act on (e.g. "start with a failing integration test") —
+  does not belong in the strip, where it renders as a passive pair styled
+  like a date and gets skimmed past. Render it as an advisory callout (see
+  Tinted callout cards) so its visual weight matches its actionability. The
+  test: descriptive value -> metadata pair; something the reader must act
+  on -> callout.
+- **Key Technical Decisions** — repeating cards with the decision ID,
+  bold decision title (often with inline code for technical
+  identifiers), and prose rationale. Flat cards (not collapsibles) —
+  these are reference material readers scan, not drill into.
+- **Risks** — cards with a color-coded status eyebrow (e.g., "RISK ·
+  MITIGATED" / "OPEN · DEFERRED FOLLOW-UP") and prose body. Communicate
+  status through the eyebrow's color plus an optional subtle full-card
+  tint — not a colored stripe on one edge (see "Chips and pills").
+- **Scope Boundaries** — callout cards distinguished (in-scope vs deferred
+  vs outside) by a colored eyebrow/label plus a subtle full-card tint when
+  the distinction is meaningful — not a one-edge colored stripe.
+
+The agent picks more elaborate or simpler shapes based on what each
+specific artifact's content needs.
+
+## Diagrams
+
+When the section contract calls for a diagram (architecture, sequence,
+flowchart, state machine, swim lane, data-flow, quantitative
+comparison), HTML renders it as **inline SVG**. The agent picks the
+shape that conveys the content fastest — there is no fixed catalog of
+"approved" diagram types. If the content is quantitative comparison
+across categories, a bar chart is the right shape; if it's component
+relationships, a topology diagram; if it's process flow across
+participants, a swim lane; etc.
+
+**Conceptual diagrams are not wireframes.** The wireframe affordance below
+is scoped to brainstorm requirements docs about *visual products* and is
+excluded for non-visual systems. That exclusion is about wireframes only —
+a brainstorm about a data model, schema, agent workflow, or migration is
+still free to use a conceptual diagram (a before/after field map, a
+source-of-truth fan-out, a state diagram). Don't let the wireframe
+exclusion suppress a conceptual diagram the content warrants.
+
+**Diagrams complement prose; they never replace it.** A diagram is an
+accelerant placed next to the prose it illustrates, not a substitute. The
+IDed prose stays complete and standalone — a reader who ignores every
+diagram still gets the full content in text, and a text-reading downstream
+agent (which does not parse SVG geometry) is never left with a relationship
+that exists only in the picture. This extends the prose-is-authoritative
+rule above: prose governs not only on disagreement but on completeness, so
+adding a diagram is not license to thin the prose it depicts.
+
+### Layout legibility for hand-authored SVG
+
+The agent designs SVG coordinates without rendering — layouts that look
+fine in source can collide in practice. Before emitting, trace each
+labeled arrow, each shape edge, and each text label:
+
+- **No stroke — arrow *or* shape edge/border — passes through a text
+  label.** If an arrow line/curve, or the border of a box, parallelogram,
+  or other shape, crosses a label's bounding box, the text reads as
+  struck-through and the stroke reads as terminating at the wrong element.
+  Fix by re-routing the arrow, moving the label clear of every edge, or
+  applying `paint-order: stroke fill` with a stroke color matching the
+  diagram background to halo the label. The halo width is a judgment call:
+  narrow enough not to bleed into glyph strokes (a halo whose width
+  approaches the glyph's own stroke width muddies the text color), wide
+  enough to mask the underlying stroke (at least its stroke width
+  plus a hairline). Verify by inspecting rendered text at the target
+  font size — if glyphs look thicker or more colored-toward-halo than
+  the same text outside the diagram, the halo is too wide.
+- **Labels inside skewed or rotated shapes sit in the shape's true
+  interior, not its bounding box.** A parallelogram, isometric face, or
+  rotated rect has an interior offset from its bounding box, so a
+  box-aligned (e.g. left-aligned) label spills past the slanted edge.
+  Inset the label to fall inside the actual shape — account for the
+  skew/rotation offset at the label's vertical position — or place it
+  outside the shape with a short leader. This is the usual failure in the
+  **stacked-layers idiom** (offset parallelograms implying z-order), where
+  per-layer labels left-aligned to the container both overflow the lower
+  layers and get crossed by the neighbouring layer's edge. Prefer
+  labelling each layer in its own un-overlapped region, or to the side of
+  the stack.
+- **Arrow labels sit adjacent to the arrow's midpoint** (typically
+  within ~10-15px above or beside the line they describe). A label
+  floating at the diagram's edge that readers have to trace back to an
+  arrow is broken — readers will misread.
+- **Avoid long curves that traverse the diagram** to connect a
+  component on one side to one on the other. If A and D need a labeled
+  connection across a multi-component layout, prefer reordering boxes
+  so A and D are adjacent, numbered step badges next to each
+  participant that the caption ties together, or a short
+  labeled-channel notation — rather than one curve crossing multiple
+  unrelated elements.
+- **Differentiate diagram shapes by geometry first, by fill semantics
+  second.** Geometry (diamond = decision, rect = step, oval =
+  start/end, parallelogram = data) carries the role unambiguously.
+  Fill semantics (accent-soft for highlighted path, warn-soft for
+  fallthrough) carry meaning. Resist introducing additional neutral-tint
+  tiers (a slightly-lighter grey to mark "decision shapes are different
+  from boxes") — when geometry already differentiates, an additional
+  luminance tier adds no information and creates fragility: small RGB
+  deltas survive native browser rendering but can be flattened or
+  inverted inconsistently by dark-mode extensions, accessibility
+  plugins, or printing.
+
+### Plan architecture diagrams are not directional sketches
+
+Do not add hedging captions or section preambles to plan SVG diagrams —
+phrases like "directional guidance for review, not implementation
+specification" do not belong on plan diagrams or on unit-card
+technical-design subsections. Plan diagrams render the same authoritative
+content as the surrounding prose; the prose-is-authoritative rule
+already governs disagreement. Hedging language is reserved for the
+wireframe affordance below, which carries a *required* directional
+caption because the wireframe is explicitly NOT a spec.
+
+## Wireframe mockups (requirements docs only)
+
+When a brainstorm requirements document describes a user-facing visual
+surface (UI feature, screen layout, screen flow, component placement),
+the HTML rendering may include a wireframe mockup. This affordance applies
+ONLY to brainstorm requirements docs that describe visual products — not
+to plan artifacts, and not to brainstorms about non-visual systems (API
+design, agent workflows, infrastructure).
+
+When a wireframe is included:
+
+- **Fidelity ceiling: wireframe, not mockup.** Gray boxes for layout
+  regions, text labels for content placeholders, intentional placeholder
+  copy (`[Product name]`, `[CTA label]`, `[user avatar]`). No
+  pixel-perfect colors, no exact typography choices, no specific
+  component-library references. The wireframe communicates spatial
+  arrangement and structure, not visual style.
+- **Static only.** Inline SVG or simple HTML/CSS for layout. No JS
+  interaction, no working form fields, no state changes, no live data.
+- **Anti-padding.** One wireframe per distinct visual concept.
+- **Mandatory directional caption.** Every wireframe carries an explicit
+  "directional, not the spec" note adjacent to it. Required wording (or
+  close paraphrase): *"Directional only — illustrates the intended
+  user-facing shape. Exact colors, spacing, copy, and component choices
+  are placeholders for review, not requirements."*
+
+Without this caption the wireframe risks being read as a binding visual
+spec, which the affordance is explicitly designed to avoid.
+
+## Affordance idioms
+
+Common HTML affordances the agent can reach for when content benefits.
+These are examples, not requirements — the agent picks what each
+artifact's content warrants. Other affordances not listed here are
+fine when the content suggests them.
+
+- **Sticky TOC sidebar with active-section indicator** — available when
+  the agent judges navigation will materially help and the
+  implementation is reliable: two-column layout on desktop, collapsed
+  to top-of-page on mobile, paired with a small inline
+  `IntersectionObserver` script that toggles `.active` on the matching
+  nav anchor. Trade-off: a broken sticky TOC (layout collisions,
+  active-section state drift, dark-mode CSS issues) is worse than a
+  static top-of-doc TOC. For most long docs, default-closed `<details>`
+  on repeating cards (see Implementation Units anatomy) already cuts
+  the visible scroll length enough that a static TOC works — reach for
+  sticky only when collapsibles alone don't solve the navigation
+  problem.
+- **Within-section sub-nav** for sections containing 6+ repeating cards
+  (Implementation Units, KTDs, Risks at large counts). A short list of
+  card-anchor links (`<ul>` of `<a href="#u1">U1. ...</a>`) rendered at
+  the top of the section gives readers a jump table — no JS needed.
+  Lower-complexity alternative to the sticky TOC for the specific case
+  of long card sections.
+- **Eyebrow labels** (small-caps tag above section titles) for
+  editorial polish, especially when section titles are narrative
+  rather than literal.
+- **Stats strip** at the top of the doc when the artifact has 3+
+  quantifiable signals worth surfacing at a glance.
+- **`<details>` + `<summary>`** for collapsible secondary content
+  inside repeating cards. All collapsibles start closed — `open`
+  attribute should not appear on any `<details>` inside repeating
+  cards by default.
+- **Side-by-side columns** for parallel content (Request / Response,
+  Before / After, Two alternatives).
+- **Tinted callout cards** for content that is "different in kind"
+  (Deferred, Open Questions, advisory notes, unit-level execution notes)
+  — a subtle full-card background tint plus a colored eyebrow/label
+  communicates kind at a glance. Avoid a colored stripe on one edge; tint
+  the whole card instead.
+
+## Agent-consumability rules
+
+Downstream agents that read HTML today (`ce-work`, a skill re-reading its
+own prior artifact on a resume run, future consumers) reason over the HTML
+as text — the way they reason over markdown, not via DOM extraction or a
+script-style parse. `ce-doc-review` is not a current HTML consumer (see
+opening note).
+
+These rules are why such a consumer can locate one item (a single
+requirement, unit, idea, or other ID-bearing entry) and reason over it from
+source alone — its title, every labeled field, and any diagram's meaning —
+with no hidden machine-readable copy to fall back on. The semantic structure
+*is* the extraction contract: it is what makes the single-source-of-truth
+invariant (no `data-*` or JSON metadata mirror) safe rather than lossy.
+Weakening it — `<article>` item boundaries collapsed into `<div>` soup, a
+field label demoted to an attribute, one item's content scattered across
+distant parts of the doc — breaks that reasoning even when the rendered page
+looks identical. Compose so semantic understanding is reachable in source:
+
+- **Use semantic HTML over `<div>` soup.** `<article>` per unit card,
+  `<dl>` for metadata pairs, `<table>` for tabular content, `<details>`
+  / `<summary>` for collapsibles, `<section>` for top-level doc
+  sections. Structure markers carry meaning to a text-reading agent.
+- **Render field labels as visible text, not as attributes.** Emit
+  `<dt>GOAL</dt><dd>...</dd>`, not `<dd data-field="goal">...</dd>`.
+  The label is the semantic anchor.
+- **Keep U-IDs, R-IDs, and similar as visible text** in headings and
+  table cells, not only as `id=""` attributes. The agent finds "U1." in
+  source the same way it finds "U1." in markdown.
+- **Match section heading vocabulary to what the section contract
+  defines.** When the section contract says "Implementation Units," the
+  HTML heading is "Implementation Units" — not "How we'll build it,"
+  even if the narrative version reads better. Section heading
+  vocabulary is the contract downstream consumers grep for. (Editorial
+  re-titles can appear as eyebrow labels, sub-headings, or visual
+  framing — but the load-bearing section heading matches the contract
+  name.)
+- **All semantic content lives in actual HTML text.** No CSS `::before
+  { content: "..." }` carrying meaning, no background images as
+  content, no semantic info that only renders. Whatever the agent sees
+  in source is what it knows.
+- **Stable structure is the public API.** Element types, the ID and
+  label scheme, and the field-label vocabulary do not break across
+  versions. Visual styling can change freely.
+
+## Post-compose audit
+
+Before returning the artifact, scan it for common slips:
+
+- **Single self-contained file.** No companion `.css` / `.js` / `.svg`.
+- **No hidden machine-readable metadata copy.** No
+  `<script type="application/json">` frontmatter block, no `data-*`
+  attributes mirroring visible values, **no `<meta name="created">` /
+  `<meta name="origin">` etc. in `<head>`
+  duplicating the visible header**. Metadata lives in visible text;
+  one source of truth per value.
+- **All stable IDs** appear as both `id=""` and visible text.
+- **Section heading vocabulary** matches the section contract names
+  (downstream agents grep these).
+- **Source / composition signal** is present as a visible footer at
+  the bottom of the doc (composition timestamp + source identifier).
+- **Repeating cards with 3+ instances put secondary content inside
+  default-closed `<details>`.** Fully-expanded unit cards in a long
+  Implementation Units section is a failure mode — the reader can't see
+  the unit list at a glance. Verify by skimming the rendered units:
+  each `<article>` should render as its ID + title + metadata strip
+  with collapsibles below, not as one long block.
+- **Within-section sub-nav** is present for sections with 6+ repeating
+  cards.
+- **Body `<strong>`** is not colored with accent palette.
+- **No one-edge colored accent** (a colored stripe/arc on a single side)
+  on chips, pills, or callout cards — differentiate by uniform fill +
+  colored eyebrow/label instead. A one-sided stripe reads as
+  broken/unintentional; chips in a row must be a uniform visual set.
+- **`<details>`** inside repeating cards have no `open` attribute.
+- **Diagram labels** are legible — no arrow paths crossing text,
+  halo width appropriate for font size.
+- **Diagrams complement prose, not replace it.** Every relationship a
+  diagram conveys is also present in the surrounding IDed prose; no
+  content lives only in an SVG.
+- **No JS framework runtimes** included. Small inline `<script>` for
+  active-section TOC tracking or anchor-permalink behavior is the only
+  acceptable JS.
+- **Each heading level** is visually distinct from others and from
+  inline bold.
+- **No template placeholders** (`{skill}`, `<value>`, `[plan title]`)
+  leaked into output.
+- **No process exhaust** callouts in the artifact.
diff --git a/dist/skills/ce-ideate/references/ideation-sections.md b/dist/skills/ce-ideate/references/ideation-sections.md
new file mode 100644
index 0000000..34a7bb2
--- /dev/null
+++ b/dist/skills/ce-ideate/references/ideation-sections.md
@@ -0,0 +1,191 @@
+# Ideation Sections
+
+This is the section contract for the ce-ideate artifact — it describes
+*what* a persisted ideation document contains, independent of output
+format. It is paired with a format-rendering reference
+(`references/markdown-rendering.md` or `references/html-rendering.md`)
+that describes *how* the resolved format presents these sections. The
+same content renders in either format; only presentation differs.
+
+Load this file at save time alongside the rendering reference matching
+`OUTPUT_FORMAT` (see `references/post-ideation-workflow.md` §4.1).
+
+## What the artifact contains
+
+An ideation artifact is a ranked, critiqued candidate set, the grounding
+the candidates were qualified against, and a record of what was cut. It
+is a human-facing discovery document, not a requirements doc or plan —
+keep it about the ideas and their basis, not implementation.
+
+### Metadata
+
+- **date** — composition date (YYYY-MM-DD).
+- **topic** — kebab-case topic slug.
+- **focus** — the focus hint, when one was given. Omit when open-ended.
+- **mode** — `repo-grounded`, `elsewhere-software`, or
+  `elsewhere-non-software`.
+
+Markdown renders metadata as YAML frontmatter at the top of the file.
+HTML renders it as visible header text (per the html-rendering hard
+invariant: one visible source of truth per value, no hidden
+machine-readable copy).
+
+**No status field — not on the doc, not per idea.** An ideation doc is a
+point-in-time discovery artifact, not a tracked work item: it carries no
+`active → completed` lifecycle and no per-idea "explored" marker.
+Tracking mutable workflow progress inside the artifact would create a
+second source of truth that drifts — whether an idea was later pursued is
+knowable from downstream artifacts (a brainstorm or plan that picked it
+up), so it is not duplicated here.
+
+### Grounding Context
+
+The Phase 1 grounding summary the ideas were qualified against — labeled
+"Codebase Context" in repo mode, "Topic Context" in elsewhere mode.
+
+### Topic Axes (conditional)
+
+The 3-5 axes from Phase 1.5, one per line. When Phase 1.5 was skipped, a
+single line records why (`Decomposition skipped — atomic subject` or
+`Decomposition skipped — surprise-me mode`). Omit the section entirely
+when not applicable.
+
+### Ranked Ideas
+
+The surviving candidates, ranked. Each idea carries:
+
+- **title**
+- **description** — concrete explanation.
+- **axis** — the topic axis this idea targets. Omit when decomposition
+  was skipped.
+- **basis** — tagged `direct:` (quoted evidence) / `external:` (named
+  prior art) / `reasoned:` (written-out first-principles argument).
+- **rationale** — how the basis connects to the move's significance.
+- **downsides** — tradeoffs or costs.
+- **confidence** — 0-100%.
+- **complexity** — Low / Medium / High.
+
+**Keep idea cards expanded; add a jump-list when the section is long.**
+Unlike plan Implementation Units, ideation idea cards are meant to be read
+in full to choose a direction — do not hide their substance behind
+default-closed `<details>`. But the Ranked Ideas section is typically 5-7
+cards and runs long in HTML, so add a within-section jump-list of the
+ranked titles (anchor links to each card) at the top of the section, per
+the rendering reference's within-section sub-nav affordance.
+
+**Illustrative visuals — decide on the idea's shape, not on how clear the
+prose reads.** A well-placed visual can make a direction land faster for a
+human scanning a set of candidates. Decide per survivor — none, a few, or
+most may warrant one; there is no quota and no cap.
+
+Watch one trap when you make this call: the prose always conveys the idea
+(that is the hard rule below), and as a text-native reasoner you will tend
+to read your own prose, judge it "clear," and conclude no visual is needed
+— which quietly under-produces the visuals that actually help a reader. So
+"the prose is already clear" is never the reason to skip. The real
+question is what the idea *hinges on*, and whether that has a shape a
+picture carries faster than a sentence.
+
+**Concrete-vs-abstract is the wrong axis.** Don't reach for a visual
+because an idea feels big or conceptual, and don't skip one because it
+feels small or concrete. A new-feature *concept* is often the best
+candidate — the reader has to picture an unfamiliar arrangement — while
+many concrete changes (an error fix, a drop-in dependency swap) have
+nothing structural to draw. Ask what the idea hinges on, not how abstract
+it is.
+
+- **Hinges on a structure → lean toward a visual.** A relationship
+  between parts, a flow or sequence, a before/after contrast, a
+  structural arrangement, an analogy mapping (especially cross-domain
+  ideas), a quantitative comparison. A picture lands these faster than a
+  sentence even when the prose is perfectly clear — and it should show
+  the *basis* or the *why-it-matters*, not restate the title. New-feature
+  concepts frequently live here.
+- **A single point with nothing structural to show → no visual.** A
+  renamed thing, a copy change, "handle the null case," a drop-in library
+  swap — there is no shape a diagram would add; one here is decoration.
+  Size and abstraction don't decide this: a sweeping concept can still be
+  one proposition ("ship dark mode"), and a small concrete fix can still
+  re-route how two parts talk (real shape, worth drawing).
+
+Decoration — a visual with no shape to show, or one that just restates the
+title — is the failure mode, and it is slop whether it appears once or
+five times. A visual that genuinely shows the idea's shape is never slop,
+however many ideas warrant one.
+
+Two constraints on any visual you do add:
+
+- **Stay at the idea's altitude — illustrative, not a spec.** This is the
+  *opposite* of a plan or requirements diagram. The shared rendering
+  reference treats plan diagrams as authoritative content and forbids
+  "directional sketch" framing; ideation visuals are the reverse —
+  deliberately directional overviews of a direction nobody has committed
+  to yet. Keep them conceptual (contrast, analogy, rough flow). Detailed
+  architecture, sequence diagrams, and wireframes belong downstream in
+  ce-brainstorm / ce-plan once a direction is chosen, not here.
+- **Keep the prose standing alone.** A reader who ignores the visual
+  still gets the complete idea and its basis. The visual accelerates
+  understanding; it never carries content found nowhere else.
+
+Rendering mechanics (inline SVG in HTML with the layout-legibility and
+halo rules; a fenced mermaid block in markdown when the shape suits it)
+follow the rendering reference's Diagrams section — but that section's
+plan-centric, authoritative-diagram framing is overridden here by the
+illustrative, decide-per-idea stance above.
+
+### Rejection Summary
+
+A table of considered-and-cut ideas with a one-line reason each. When an
+axis ended with zero survivors despite recovery, record it as its own
+row so the coverage gap is visible rather than silently absent.
+
+## Markdown skeleton
+
+The section shape both formats carry. In markdown it is written
+literally (omit clearly irrelevant fields only when necessary); in HTML
+the same sections render per `html-rendering.md`.
+
+```markdown
+---
+date: YYYY-MM-DD
+topic: <kebab-case-topic>
+focus: <optional focus hint>
+mode: <repo-grounded | elsewhere-software | elsewhere-non-software>
+---
+
+# Ideation: <Title>
+
+## Grounding Context
+[Grounding summary from Phase 1 — "Codebase Context" in repo mode, "Topic Context" in elsewhere mode]
+
+## Topic Axes
+[3-5 axes from Phase 1.5, one per line, OR a single `Decomposition skipped — ...` line. Omit the section if not applicable.]
+
+## Ranked Ideas
+
+### 1. <Idea Title>
+**Description:** [Concrete explanation]
+**Axis:** [Topic axis this idea targets — omit when decomposition was skipped]
+**Basis:** [`direct:` / `external:` / `reasoned:` — quoted, cited, or written-out argument]
+**Rationale:** [How the basis connects to the move's significance]
+**Downsides:** [Tradeoffs or costs]
+**Confidence:** [0-100%]
+**Complexity:** [Low / Medium / High]
+
+## Rejection Summary
+
+| # | Idea | Reason Rejected |
+|---|------|-----------------|
+| 1 | <Idea> | <Reason rejected> |
+
+[When applicable, append axis-coverage gaps as their own rows so the gap is visible:]
+| - | axis: <name> | recovery skipped (cap reached) — no survivors on this axis |
+```
+
+## No process exhaust
+
+Keep engineering-process metadata out of the artifact — no "captured at
+Phase X" notes, no skill-pointer "next steps", no italic provenance
+lines. The reader wants the ideas and their basis. (HTML carries a
+single visible composition-signal footer per the html-rendering
+invariant; that is the one provenance element that belongs in the doc.)
diff --git a/dist/skills/ce-ideate/references/markdown-rendering.md b/dist/skills/ce-ideate/references/markdown-rendering.md
new file mode 100644
index 0000000..8e20a6b
--- /dev/null
+++ b/dist/skills/ce-ideate/references/markdown-rendering.md
@@ -0,0 +1,202 @@
+# Markdown Rendering
+
+This is a format-rendering reference — it describes how to render any
+artifact in markdown, independent of which skill is producing it.
+
+It is paired with a section contract (`plan-sections.md`,
+`brainstorm-sections.md`, etc.) that describes *what* the artifact contains.
+This reference describes *how* markdown specifically presents it. The same
+content rendered by different skills shares the same markdown principles.
+
+## Hard invariants
+
+These hold regardless of which skill produced the artifact.
+
+- **YAML frontmatter at the top of the file.** Standard `---` delimited block
+  containing the artifact's stable metadata (title, date, type, etc.
+  — exact fields are per-skill, defined in the section contract).
+- **ASCII identifiers in anchors.** Markdown headings auto-generate anchors
+  from the heading text. Keep headings ASCII so anchors are predictable
+  (`#implementation-units`, not `#implementación-units`).
+- **Repo-relative paths for file references.** Always. Never absolute paths
+  — they break portability across machines, worktrees, teammates.
+- **No HTML mixed in.** Keep the markdown pure. No `<div>`, no `<details>`,
+  no inline `<style>`. If a layout idea only works as HTML, defer it to the
+  HTML rendering. Markdown stays markdown.
+
+## Format principles
+
+These shape what "good" markdown looks like; the agent applies them per
+artifact based on content shape.
+
+### ID prefix format
+
+Stable IDs (R, U, A, F, AE, KTD) appear as plain prefixes at the start of
+the bullet or heading — do NOT bold the prefix. The prefix is visually
+distinctive on its own; bolding it inflates visual noise.
+
+```markdown
+- R1. The plan returns paginated sessions.   ← right
+- **R1.** The plan returns paginated sessions.   ← wrong (bolded prefix)
+```
+
+Same applies to unit headings: `### U1. Cloak detection in preflight contract`.
+
+### Content shape: prose vs bullets vs tables
+
+The same content can be rendered three ways; the agent picks per content
+shape, not by template default.
+
+- **Prose** when the content has narrative flow (motivation, decision
+  rationale, problem framing). Bullets fragment narrative into
+  disconnected pieces.
+- **Bullets** when items share a parallel shape but each carries enough
+  prose to not fit a table cell.
+- **Tables** when 5+ items share uniform structure (`ID + body`,
+  `name + value`, `decision + rationale`, `risk + mitigation`). Tables
+  scan faster at that scale and unlock additional columns (status,
+  traceability, severity) that bullets can't accommodate cleanly.
+
+The test: which shape would a reader scan fastest for this content? If
+items have parallel structure and 5+ instances, table. If items are 3-5
+and each has a few lines of prose, bullets. If the content is a single
+narrative thought, prose.
+
+### Bold leader labels within bullets
+
+When a bullet has substructure that benefits from named fields (Key Flows
+with Trigger / Actors / Steps / Outcome, Acceptance Examples with Covers
+/ Given / When / Then), use bold leader labels at the start of nested
+bullets — not deeper heading levels.
+
+```markdown
+- F1. Anonymous capture
+  - **Trigger:** Agent enters Step 2a with no session.
+  - **Actors:** A1, A2
+  - **Steps:** Preflight detects cloak; agent launches; capture proceeds.
+  - **Covered by:** R1, R2, R5
+```
+
+This gives the bullet structure without needing H4/H5 headings that would
+clutter the doc and break TOC generation.
+
+### Section separators
+
+For substantial artifacts, use horizontal rules (`---`) between top-level
+H2 sections. Omit for short docs where separators would dominate.
+
+### Tables for genuinely comparative info only
+
+Use tables for the uniform-shape case in "Content shape" above. Don't use
+tables to render content lists that are really bullets — markdown tables
+are noisier in raw form and worse for diffs.
+
+## Section anatomy
+
+How section types commonly render in markdown. These are patterns, not
+contracts — the agent picks the shape that fits the content.
+
+- **Summary / Problem Frame** — prose paragraphs.
+- **Requirements** — bullets with `R<N>.` prefix. When requirements span
+  more than one concern, grouping under bold inline headers is the default
+  shape, not optional polish (group by capability, not by discussion order);
+  render a flat list only when every requirement is about the same thing.
+  When requirements have status, traceability, or severity that warrant
+  additional columns, escalate to a table.
+- **Implementation Units** — H3 heading per unit with `U<N>.` prefix.
+  Fields (Goal, Files, Patterns, Test Scenarios, Verification) render as
+  bullets with bold leader labels, or as sub-headings if the field has
+  multi-paragraph content.
+- **Key Technical Decisions** — bullets with bold decision name + prose
+  rationale, or numbered KTD-N pattern when traceability matters.
+- **Key Flows / Acceptance Examples** — bullets with bold leader labels
+  (Trigger / Actors / Steps / Outcome / Covers / Given-When-Then).
+- **Scope Boundaries** — bullets, optionally split into "Deferred for
+  later" / "Outside this product's identity" sub-headings when the
+  positioning distinction matters.
+
+The agent picks more elaborate or simpler shapes based on what each
+specific artifact's content needs.
+
+## Diagrams
+
+When the section contract calls for a diagram (architecture, sequence,
+flowchart, state machine, swim lane, data-flow), markdown renders it as
+a fenced mermaid block:
+
+```markdown
+` ``mermaid
+flowchart TB
+  A[Start] --> B{Decision}
+  B -->|yes| C[Action]
+  B -->|no| D[Other action]
+` ``
+```
+
+(`TB` direction default — keeps diagrams narrow in source view and in
+narrow rendered viewports.)
+
+Markdown's diagram affordances are limited compared to HTML. For
+quantitative comparisons (bar charts, scatter plots) markdown has no
+native equivalent — use a table with the data and let prose or caption
+carry the interpretation. The richer visualization happens in the HTML
+rendering.
+
+## Inline code and code blocks
+
+- **Inline code** for identifiers (variable names, function names,
+  flag names, file paths, IDs that aren't section anchors).
+- **Fenced code blocks** with language tag for code, shell commands,
+  API request/response samples. Always specify the language for syntax
+  highlighting and accessibility.
+
+```markdown
+The flag `--cdp-url` accepts a URL.
+
+` ``bash
+browser-use --cdp-url http://localhost:9222
+` ``
+```
+
+## No process exhaust
+
+Engineering process metadata stays out of the artifact:
+
+- No "captured at Phase X" notes
+- No `## Next Steps` pointing to the next skill
+- No italic provenance lines ("*Brainstorm completed 2026-05-13*")
+- No engineering-flow shepherding ("Now read this file:", "Next, run that
+  command:")
+
+This information belongs in commit messages, tool output, and agent
+transcripts — not in the artifact a reader returns to weeks later.
+
+## Frontmatter shape
+
+Per-skill frontmatter fields are defined in each skill's section contract
+(`plan-sections.md` lists plan frontmatter; `brainstorm-sections.md` lists
+brainstorm frontmatter). Common rules:
+
+- YAML at the top of the file, delimited by `---` on its own line above
+  and below.
+- Field names in lowercase snake_case (`created_at`, `topic`, not
+  `CreatedAt`, `Topic`).
+- **No status / lifecycle field.** Artifacts are point-in-time records
+  (decision or discovery), not tracked work items. Do not introduce a
+  mutable `status` field or an `active → completed` lifecycle — whether
+  the work shipped is derived from git, not stored in the doc.
+- Stable across artifact revisions — never rename or repurpose a field.
+
+## Post-write audit
+
+Before declaring the markdown file written, scan it for these common
+slips:
+
+- All stable IDs are plain-prefix format, not bolded.
+- No HTML elements mixed in.
+- All file paths are repo-relative.
+- Horizontal rule separators between H2s (for Standard / Deep artifacts).
+- No process exhaust (Phase X notes, Next Steps pointers, provenance
+  lines).
+- Tables only where 5+ uniform-shape items justify them.
+- Frontmatter has all the per-skill required fields with reasonable values.
diff --git a/dist/skills/ce-ideate/references/post-ideation-workflow.md b/dist/skills/ce-ideate/references/post-ideation-workflow.md
index 5128e3f..f903efe 100644
--- a/dist/skills/ce-ideate/references/post-ideation-workflow.md
+++ b/dist/skills/ce-ideate/references/post-ideation-workflow.md
@@ -32,206 +32,113 @@ Target output:
 - if too many survive, run a second stricter pass
 - if fewer than 5 survive, report that honestly rather than lowering the bar
 
-## Phase 4: Present the Survivors
+## Phase 4: Write and Present the Deliverable
 
-**Checkpoint B (V17).** Before presenting, write `<scratch-dir>/survivors.md` (using the absolute path captured in Phase 1) containing the survivor list plus key context (focus hint, grounding summary, rejection summary). This protects the post-critique state before the user reaches the persistence menu. Best-effort: if the write fails (disk full, permissions), log a warning and proceed; the checkpoint is not load-bearing. Reuses the same `<run-id>` and `<scratch-dir>` generated in Phase 1; not cleaned up at the end of the run (the run directory is preserved so the V15 cache remains reusable across run-ids in the same session — see Phase 6).
+The ideation artifact is produced **automatically** — persistence is not opt-in. After filtering, write the deliverable, show a concise summary, and open it. The full content lives in the file; the session shows only an orienting summary, so the rich format is what the reader actually engages with.
 
-Present the surviving ideas to the user. The terminal review loop is a complete ideation cycle in itself — persistence is opt-in (Phase 5), and refinement happens in conversation with no file or network cost (Phase 6).
+**Checkpoint B (V17).** Before writing the deliverable, write `<scratch-dir>/survivors.md` (absolute path from Phase 1) containing the survivor list plus key context (focus hint, grounding summary, rejection summary). Best-effort: if the write fails, log a warning and proceed; the checkpoint is not load-bearing. Reuses the same `<run-id>` / `<scratch-dir>` generated in Phase 1.
 
-Present only the surviving ideas in structured form:
+### 4.1 Write the Deliverable (automatic, both modes)
 
-- title
-- description
-- **axis** (when Phase 1.5 produced an axis list)
-- **basis** (tagged `direct:` / `external:` / `reasoned:`, with the quoted evidence, cited source, or written-out argument)
-- rationale (how the basis connects to the move's significance)
-- downsides
-- confidence score
-- estimated complexity
+`OUTPUT_FORMAT` (resolved in SKILL.md Phase 0.0; default `html`) sets the extension. Write the file every run — do not wait for the user to ask.
 
-Then include a brief rejection summary so the user can see what was considered and cut.
+1. **Resolve the target directory and extension.**
+   - Extension follows `OUTPUT_FORMAT` (`.html` default, `.md` on override).
+   - **Repo mode:** ensure `docs/ideation/` exists (create if absent).
+   - **Elsewhere mode with `docs/ideation/` already present:** use it.
+   - **Otherwise (no repo, or elsewhere with no `docs/ideation/`):** write into the run's CE temp area — the `<scratch-dir>` resolved in Phase 1 (`/tmp/compound-engineering/ce-ideate/<run-id>/`). Do **not** write into the user's current working directory, and do **not** create a `docs/ideation/` tree for a subject unrelated to the repo. Announce the absolute path and note it is temporary (`/tmp` is cleared on reboot — move it to keep it).
+2. **Choose the file path:** `<dir>/YYYY-MM-DD-<topic>-ideation.<ext>` (or `<dir>/YYYY-MM-DD-open-ideation.<ext>` when no focus exists).
+3. **Load the section contract and rendering reference** (deferred from Phase 0.0): read `references/ideation-sections.md` and the format-rendering reference matching `OUTPUT_FORMAT` — `references/markdown-rendering.md` for `md`, `references/html-rendering.md` for `html`.
+4. **Write the document** per those references. `ideation-sections.md` defines the section contract (metadata, Grounding Context, Topic Axes, Ranked Ideas with per-idea fields, Rejection Summary); the rendering reference defines how the resolved format presents it. Content is identical across formats; only presentation differs.
+   - **On write failure** (no writable path, permissions): announce the failure and offer a custom path (validate writable; create parent dirs). Never lose the survivors silently.
 
-Keep the presentation concise. Allow brief follow-up questions and lightweight clarification.
+**Resume:** update the existing file in place, in its existing format (per SKILL.md Phase 0.1 format precedence); carry the prior ideas and rejection summary forward, adding to them rather than overwriting.
 
-## Phase 5: Persistence (Opt-In, Mode-Aware)
+### 4.2 Present a Concise Summary (not the full deliverable)
 
-Persistence is opt-in. The terminal review loop is a complete ideation cycle. Refinement loops happen in conversation with no file or network cost. Persistence triggers only when the user explicitly chooses to save, share, or hand off (selected in Phase 6).
+The full cards, rationale, downsides, diagrams, and the rejection table live in the file. Do **not** reproduce them in the session — reprinting the whole deliverable as chat text defeats the rich format and leads the reader through plain text before they ever see it. Show a tight orientation instead:
 
-When the user picks an option in Phase 6 that requires a durable record (Open and iterate in Proof, Brainstorm, Save and end), ensure a record exists first. When the user chooses to keep refining, no record is needed unless the user asks.
+- One line with counts and the path: e.g. `Wrote 7 ranked ideas (36 raw, 13 cut) across 5 axes → <absolute path>`.
+- A ranked list, **one line per survivor**: `1. <Title> · <axis> · Conf <High/Med/Low> · Cx <S/M/L>`.
+- The top pick called out in a sentence.
+- Any axis with zero survivors noted in one line (the deliberate gap).
 
-**Mode-determined defaults:**
+This ranked list doubles as the index the user references when choosing an idea in Phase 5. Terminal-only readers still get a usable view; depth is one open away.
 
-| Action | Repo mode default | Elsewhere mode default |
-|---|---|---|
-| Save | `docs/ideation/YYYY-MM-DD-<topic>-ideation.md` | Proof |
-| Share | Proof (additional) | Proof (primary) |
-| Brainstorm handoff | `ce-brainstorm` | `ce-brainstorm` (universal-brainstorming) |
-| End | Conversation only is fine | Conversation only is fine |
+### 4.3 Open It
 
-Either mode can also use the other destination on explicit request ("save to Proof even though this is repo mode", "save to a local file even though this is elsewhere"). Honor such overrides directly.
+- **HTML:** in an interactive session, best-effort open the file in the browser via the platform's open primitive (`open` on macOS, `xdg-open` on Linux, `start` on Windows); always print the absolute path so it can be reopened or shared. Skip auto-open in headless / pipeline runs (no interactive surface).
+- **Markdown:** print the path. Proof (the markdown iterate surface) is reached through the Phase 5 menu — it is a network action, not auto-invoked.
 
-### 5.1 File Save (default for repo mode; on request for elsewhere mode)
+## Phase 5: Next Steps
 
-1. Ensure `docs/ideation/` exists
-2. Choose the file path:
-   - `docs/ideation/YYYY-MM-DD-<topic>-ideation.md`
-   - `docs/ideation/YYYY-MM-DD-open-ideation.md` when no focus exists
-3. Write or update the ideation document
+Ask what to do next using 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_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. Free-text answers are accepted.
 
-Use this structure and omit clearly irrelevant fields only when necessary:
+The deliverable already exists (Phase 4), so the menu is purely *what next* — there is no "save" step.
 
-```markdown
----
-date: YYYY-MM-DD
-topic: <kebab-case-topic>
-focus: <optional focus hint>
-mode: <repo-grounded | elsewhere-software | elsewhere-non-software>
----
+**Stem:** "Your ideation is saved to `<path>`. What next?"
 
-# Ideation: <Title>
+Offer four options (self-contained labels with the distinguishing word front-loaded so they stay distinct when truncated). Option 1 is **format-keyed** — render exactly one of its two labels per run, matching `OUTPUT_FORMAT`:
 
-## Grounding Context
-[Grounding summary from Phase 1 — labeled "Codebase Context" in repo mode, "Topic Context" in elsewhere mode]
+1. *(when `OUTPUT_FORMAT=html`)* **Open in browser** — open the saved HTML deliverable (re-open if it was already opened).
+   *(when `OUTPUT_FORMAT=md`)* **Open and iterate in Proof** — open the saved markdown in Proof's HITL review loop; reviewed edits sync back to the local file.
+2. **Brainstorm one idea with `ce-brainstorm`** — commit a chosen idea to a requirements doc; leaves ce-ideate. Asks which idea first.
+3. **Iterate on one idea (adjust / ask, stay here)** — sharpen or interrogate a chosen idea before committing. Asks which idea and how.
+4. **Done — keep the file and stop.**
 
-## Topic Axes
-[3-5 axes from Phase 1.5, one per line, OR a single line `Decomposition skipped — atomic subject` / `Decomposition skipped — surprise-me mode` when Phase 1.5 was skipped. Omit this section entirely if not applicable.]
+**Adjacent nudge (prose, not a slot):** "Don't want it kept? Say 'discard' and the agent deletes the file." Handled via free text (see §5.5); it is create-only and never deletes a resumed or pre-existing doc.
 
-## Ranked Ideas
+If the user already named an idea inline (e.g. "brainstorm the table tool", "tighten the highlighter idea"), skip the "which idea?" follow-up for §5.2 / §5.3.
 
-### 1. <Idea Title>
-**Description:** [Concrete explanation]
-**Axis:** [Topic axis this idea targets — omit when decomposition was skipped]
-**Basis:** [`direct:` / `external:` / `reasoned:` — quoted, cited, or written-out argument]
-**Rationale:** [How the basis connects to the move's significance]
-**Downsides:** [Tradeoffs or costs]
-**Confidence:** [0-100%]
-**Complexity:** [Low / Medium / High]
-**Status:** [Unexplored / Explored]
+### 5.1 Open in Browser (html) / Open and Iterate in Proof (md)
 
-## Rejection Summary
+- **HTML — Open in browser.** (Re)open the saved file via the platform primitive where available; otherwise print the absolute path. Return to the Phase 5 menu. No Proof, no sync — the HTML file is the canonical record.
+- **Markdown — Open and iterate in Proof.** The local markdown file already exists (Phase 4), so Proof is a review surface over it, not the primary record. Load the `ce-proof` skill in HITL-review mode with:
+  - **source file:** the saved `.md` file from Phase 4.
+  - **doc title:** `Ideation: <topic>` or the doc's H1.
+  - **identity:** `ai:compound-engineering` / `Compound Engineering`.
+  - **recommended next step:** `/ce-brainstorm`.
 
-| # | Idea | Reason Rejected |
-|---|------|-----------------|
-| 1 | <Idea> | <Reason rejected> |
+  On return, the proof skill syncs the reviewed markdown back to the local file; then return to the Phase 5 menu on any status. If the Proof handoff fails after the proof skill's internal retry plus one orchestrator-side retry (~2s pause, narrated as "Retrying Proof... attempt 2/2"), tell the user Proof is unavailable and that the local file is intact at `<path>`, then return to the menu — the deliverable was never at risk (it was written in Phase 4). *(If the user explicitly asked for Proof during an HTML run: Proof is markdown-only and cannot ingest HTML, so render a throwaway markdown copy of the survivors as the Proof source, do not upload the `.html`, and note Proof edits won't sync back into the HTML canonical.)*
 
-[When applicable, append axis-coverage gaps as their own rows so the gap is visible:]
-| - | axis: <name> | recovery skipped (cap reached) — no survivors on this axis |
-```
+### 5.2 Brainstorm One Idea
 
-If resuming:
-- update the existing file in place
-- preserve explored markers
+1. **Identify the idea** by number or name (skip if the user already named it). Match against the ranked list from Phase 4.2.
+2. **Build a focused seed** from the idea's substance already in the orchestrator's context. Do **not** pass the whole file — wasteful and noisy (the other survivors, grounding, and rejection table are irrelevant to defining this one idea, and an HTML file carries CSS/SVG chrome). Do **not** pass only a file pointer — that forces `ce-brainstorm` to re-open and re-extract the idea the orchestrator already holds. The seed is feature-description-shaped:
 
-### 5.2 Proof Save (default for elsewhere mode; on request for repo mode)
+   > `<title> — <description>. Basis: <basis/evidence>. Why it matters: <rationale>. Known tradeoffs: <downsides>.`
 
-Hand off the ideation content to the `ce-proof` skill in HITL review mode. This uploads the doc, runs an iterative review loop (user annotates in Proof, agent ingests feedback, applies agreed edits, and replies/resolves in-thread), and (in repo mode) syncs the reviewed markdown back to `docs/ideation/`.
+   The basis/evidence directly feeds `ce-brainstorm`'s product-pressure-test, so it won't re-derive what we already know. Append a one-line provenance pointer: `(Seeded from ce-ideate: <path>, idea "<title>")` — it records origin and lets brainstorm pull adjacent detail if it wants, without being forced to read anything.
+3. **Load the `ce-brainstorm` skill** with that seed. The saved file is already the record — no extra write step.
 
-Load the `ce-proof` skill in HITL-review mode with:
+**Repo mode only:** do **not** skip brainstorming and go straight to `ce-plan` — `ce-plan` wants brainstorm-grounded requirements. In elsewhere modes, ideation is a legitimate terminal state; brainstorming is optional deeper development of one idea, not a required next rung on an implementation ladder that does not exist in these modes.
 
-- **source content:** the survivors and rejection summary from Phase 4 (in repo mode, this is the file written in 5.1; in elsewhere mode, render to a temp file as the source for upload)
-- **doc title:** `Ideation: <topic>` or the H1 of the ideation doc
-- **identity:** `ai:compound-engineering` / `Compound Engineering`
-- **recommended next step:** `/ce-brainstorm` (shown in the proof skill's final terminal output)
+### 5.3 Iterate on One Idea
 
-The Proof failure ladder in Phase 6.5 governs what happens when this hand-off fails.
+This stays in ce-ideate — no skill handoff. It is the "poke at one idea before committing" step.
 
-**Caller-aware return.** The return-rule bullets below describe the default control flow, but the next step depends on which Phase 6 option invoked the Proof save. Apply the right branch for the caller:
+1. **Identify the idea** (number or name) and **how** the user wants to iterate — adjust it, ask about it, or go deeper. Infer the how from their phrasing when given; otherwise ask.
+2. **Route by intent:**
+   - **Adjust** ("smaller scope", "drop the paste-import part", "reframe around X") — revise that idea's framing, scope, or basis as discussed, then **rewrite the saved file** so the deliverable stays current.
+   - **Ask** ("why High confidence?", "how does this compare to FigJam?") — answer in conversation, grounded in the idea's basis and the Phase 1 grounding. **No file rewrite** unless the discussion yields a change the user wants captured.
+   - **Deepen** ("expand the second-order effects") — extend that idea's analysis; capture into the file only if the user wants it kept.
+3. **Rewrite only on change.** The file is rewritten only when an idea's content actually changes — Q&A alone does not churn it.
+4. **Return to the Phase 5 menu.** Typically the user next brainstorms the sharpened idea (§5.2), iterates more, opens it, or finishes.
 
-- **§6.2 Open and iterate in Proof.** Behavior is mode-aware:
-    - *Repo mode:* return to the Phase 6 menu on every status. The Proof-reviewed content is now synced locally, and the user typically has a follow-up action in the repo (brainstorm toward a plan, save and end, or keep refining).
-    - *Elsewhere mode:* on a successful Proof return (`proceeded` or `done_for_now`), exit cleanly — narrate that the artifact lives at `docUrl` (including any stale-local note if applicable) and stop. Proof iteration is often the terminal act in elsewhere mode; forcing another menu choice after the user already got what they came for produces decision fatigue. Only the `aborted` branch returns to the Phase 6 menu so the user can retry or pick another path.
-- **§6.3 Brainstorm a selected idea.** On a successful Proof return (`proceeded` or `done_for_now`), do **not** stop at the Phase 6 menu — after applying the per-status handling below (including any stale-local pull offer), continue into §6.3's remaining bullets (mark the chosen idea as `Explored`, then load `ce-brainstorm`). Only the `aborted` branch returns to the Phase 6 menu, since no durable record was written.
-- **§6.4 Save and end.** On a successful Proof return (`proceeded` or `done_for_now`), exit cleanly: narrate that the ideation was saved, surface the `docUrl` (and the local-path note if applicable), and stop. Do **not** re-ask the Phase 6 question — the user already chose to end. Only the `aborted` branch returns to the Phase 6 menu so the user can retry or pick a different path.
+### 5.4 Done
 
-When the proof skill returns control:
+The file is already written, so there is no save step.
 
-- `status: proceeded` with `localSynced: true` → the ideation doc on disk now reflects the review. Apply the caller-aware return rule above for the invoking branch.
-- `status: proceeded` with `localSynced: false` → the reviewed version lives in Proof at `docUrl` but the local copy is stale. Offer to pull the Proof doc to `localPath` using the proof skill's Pull workflow. Apply the caller-aware return rule above; if the pull was declined, include a one-line note that `<localPath>` is stale vs. Proof so the next handoff (or final exit narration) doesn't read the old content silently. Placement: above the Phase 6 menu when the caller-aware rule returns to it, in the handoff preamble to `ce-brainstorm` for §6.3, or alongside the final save/exit narration for §6.2 elsewhere / §6.4.
-- `status: done_for_now` → the doc on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to `localPath` so the local ideation artifact stays in sync, then apply the caller-aware return rule above. `done_for_now` means the user stopped the HITL loop — it does not mean they ended the whole ideation session unless the caller-aware rule exits (§6.2 elsewhere mode or §6.4). If the pull was declined, include the stale-local note at the placement described in the previous bullet.
-- `status: aborted` → fall back to the Phase 6 menu without changes, regardless of caller. No durable record was written, so §6.3 must not proceed with the brainstorm handoff and §6.4 must not end — the menu lets the user retry or pick another path.
+- **Inside a git repo:** offer to commit only the ideation doc (do not create a branch, do not push; if the user declines, leave it uncommitted).
+- **Temp-area or non-repo file:** skip the commit offer.
 
-## Phase 6: Refine or Hand Off
+Then narrate the path and end the session — do not return to the menu.
 
-Ask what should happen next using 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_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.
+### 5.5 Discard (free text)
 
-**Question:** "What should the agent do next?"
+Only when the file was **created fresh this run**: delete it, confirm the deletion, and end. On a **resume** run (a pre-existing file was updated in place), do **not** delete — tell the user the existing doc at `<path>` remains and offer no destructive action. Discard is never a default; it fires only on an explicit request.
 
-Offer these four options (labels are self-contained with the distinguishing word front-loaded so options stay distinct when truncated):
-
-1. **Refine the ideation in conversation (or stop here — no save)** — add ideas, re-evaluate, or deepen analysis. No file or network side effects; ending the conversation at any point after this pick is a valid no-save exit.
-2. **Open and iterate in Proof** — save the ideation to Proof and enter the proof skill's HITL review loop: iterate via comments in the Proof editor; reviewed edits sync back to `docs/ideation/` in repo mode.
-3. **Brainstorm a selected idea** — load `ce-brainstorm` with the chosen idea as the seed. The orchestrator first writes a durable record using the mode default in Phase 5.
-4. **Save and end** — persist the ideation using the mode default (file in repo mode, Proof in elsewhere mode), then end.
-
-No-save exit is supported without a dedicated menu option. Pick option 1 and stop the conversation, or use the question tool's free-text escape to say so directly — persistence is opt-in and the terminal review loop is already a complete ideation cycle.
-
-Do not delete the run's scratch directory (`<scratch-dir>` resolved in Phase 1) on completion. The V15 web-research cache is session-scoped and reused across run-ids by later ideation invocations in the same session (see `references/web-research-cache.md`); per-run cleanup would defeat that reuse. Checkpoint A (`raw-candidates.md`) and Checkpoint B (`survivors.md`) are cheap to leave behind and follow the repo's Scratch Space cross-invocation-reusable convention — OS handles eventual cleanup.
-
-### 6.1 Refine the Ideation in Conversation
-
-Route refinement by intent:
-
-- `add more ideas` or `explore new angles` -> return to Phase 2
-- `re-evaluate` or `raise the bar` -> return to Phase 3
-- `dig deeper on idea #N` -> expand only that idea's analysis
-
-No persistence triggers during refinement. The user can choose Save and end (or Brainstorm, or Open and iterate in Proof) when they are ready to persist.
-
-Ending after refinement — or without any refinement at all — is a valid no-save exit. There is no required next step; stopping the conversation here leaves no durable artifact, which matches the opt-in persistence contract.
-
-### 6.2 Open and Iterate in Proof
-
-Invoke the Proof HITL review path via §5.2 with §6.2 as the caller. In repo mode, ensure the local file exists first (run §5.1) so the HITL sync-back has a target; in elsewhere mode, §5.2 renders to a temp file as usual. Honor Phase 5's "ensure a record exists first" contract either way.
-
-Apply §5.2's caller-aware return rule for the §6.2 branch — behavior is mode-aware. In repo mode, return to the Phase 6 menu on every status so the user can pick a follow-up (brainstorm toward a plan, save-and-end, or keep refining) now that the Proof review is reflected in the local file. In elsewhere mode, exit cleanly on a successful Proof return since Proof iteration is often the terminal act — the artifact lives at `docUrl` and is the canonical record; only the `aborted` status returns to the menu.
-
-If the Proof handoff fails, the §6.5 Proof Failure Ladder governs recovery.
-
-### 6.3 Brainstorm a Selected Idea
-
-- Write or update the durable record per the mode default in Phase 5 (file in repo mode, Proof in elsewhere mode). When this routes through §5.2 Proof Save, apply §5.2's caller-aware return rule: continue into the next bullet on a successful Proof return instead of bouncing back to the Phase 6 menu. If Proof returned `aborted` (no durable record written), go back to the Phase 6 menu and do **not** proceed with the brainstorm handoff.
-- Mark the chosen idea as `Explored` in the saved record
-- Load the `ce-brainstorm` skill with the chosen idea as the seed
-
-**Repo mode only:** do **not** skip brainstorming and go straight to `ce-plan` from ideation output — `ce-plan` wants brainstorm-grounded requirements. In elsewhere modes, ideation (or ideation + Proof iteration) is a legitimate terminal state; brainstorming is optional deeper development of one idea, not a required next rung on an implementation ladder that does not exist in these modes.
-
-### 6.4 Save and End
-
-Persist via the mode default (5.1 in repo mode, 5.2 in elsewhere mode), then end. If the user instead asked to use the non-default destination, honor that explicit request.
-
-When the path lands in a Proof save (5.2), apply §5.2's caller-aware return rule for the §6.4 branch: on a successful Proof return, exit cleanly — narrate the save, surface the `docUrl` (and any stale-local note if the pull was declined), and stop. Do **not** loop back to the Phase 6 menu; the user already chose to end. Only a `status: aborted` from Proof returns to the menu so the user can retry or pick another path (file save, custom path, or keep refining). The §6.5 Proof Failure Ladder still governs persistent Proof failures and ends at the Phase 6 menu — that failure-recovery path is distinct from the successful-save exit described here.
-
-When the path lands in a file save (5.1):
-
-- offer to commit only the ideation doc
-- do not create a branch
-- do not push
-- if the user declines, leave the file uncommitted
-
-After the file save (and optional commit), end the session — do not return to the Phase 6 menu.
-
-### 6.5 Proof Failure Ladder
-
-The `ce-proof` skill performs single-retry-once internally on transient failures (`STALE_BASE`, `BASE_TOKEN_REQUIRED`) before surfacing failure. The proof skill's return contract does not expose typed error classes to callers — the orchestrator cannot distinguish retryable vs terminal failures from outside.
-
-**Orchestrator-side retry harness (intentionally minimal):** wrap the proof skill invocation in **one** additional best-effort retry with a short pause (~2 seconds). The proof skill already retried internally, so this catches transient races at the orchestrator boundary without compounding latency. Do not classify error types from outside the skill — no detection mechanism exists.
-
-Distinguish create-failure from ops-failure by inspecting whether the proof skill returned a `docUrl` before failing:
-
-- **Create-failure** (no `docUrl` returned): retry the create.
-- **Ops-failure** (a `docUrl` was returned, but a later operation failed): retry only the failing operation. **Do not recreate** the document.
-
-**Failure narration.** Narrate the single retry to the terminal so the pause does not look like a hang ("Retrying Proof... attempt 2/2"). On persistent failure, narrate that retry exhausted before showing the fallback menu.
-
-**Fallback menu after persistent failure.** Use the platform's blocking question tool. Present these options (omit option (a) if no repo exists at CWD):
-
-- "Save to `docs/ideation/` instead" (repo-mode default destination, available when CWD is inside a git repo)
-- "Save to a custom path the user provides" (validate writable; create parent dirs)
-- "Skip save and keep the ideation in conversation" (no persistence)
-
-If proof returned a partial `docUrl` before failing, surface that URL alongside the fallback options so the user can recover or share the partial record.
-
-After the fallback completes (any path), continue back to the Phase 6 menu so the user can still refine, iterate in Proof, brainstorm, or save and end.
+Do not delete the run's scratch directory (`<scratch-dir>`) on completion — it holds the V15 web-research cache reused across run-ids by later ideation invocations in the same session (see `references/web-research-cache.md`), the Checkpoint A/B files, and (in the no-repo case) the deliverable itself. OS handles eventual cleanup.
 
 ## Quality Bar
 
@@ -247,6 +154,6 @@ Before finishing, check:
 - if sub-agents were used, they improved diversity without replacing the core workflow
 - every rejected idea has a reason
 - survivors are materially better than a naive "give me ideas" list
-- persistence followed user choice — terminal-only sessions did not write a file or call Proof
-- when persistence did trigger, the mode default was respected unless the user explicitly overrode it
-- acting on an idea routes to `ce-brainstorm`, not directly to implementation
+- the deliverable was written automatically in both modes (Phase 4) — to `docs/ideation/` when present, else the CE temp area, never the user's CWD
+- the session showed a concise summary, not a reproduction of the full deliverable
+- acting on an idea routes to `ce-brainstorm` (with a substance seed, not the whole file), not directly to implementation
diff --git a/dist/skills/ce-ideate/references/universal-ideation.md b/dist/skills/ce-ideate/references/universal-ideation.md
index 1b1828b..79bc273 100644
--- a/dist/skills/ce-ideate/references/universal-ideation.md
+++ b/dist/skills/ce-ideate/references/universal-ideation.md
@@ -89,15 +89,16 @@ Target 5-7 survivors by default. If too many survive, run a second stricter pass
 
 ## When to wrap up
 
-Present survivors before any persistence. For each: title, description, **axis** (when decomposition produced an axis list), **basis** (tagged `direct:` / `external:` / `reasoned:`, with the quoted evidence, cited source, or written-out argument), rationale (how the basis connects to the move's significance), downsides, confidence, complexity. Then a brief rejection summary so the user can see what was considered and cut — including any axis that ended up with zero survivors despite recovery, so the coverage gap is visible.
+Wrap up with the same flow as `references/post-ideation-workflow.md` Phases 4–5 — the mechanics are identical in this mode:
 
-Persistence is opt-in. The terminal review loop is a complete ideation cycle. Refinement happens in conversation with no file or network cost. Persistence triggers only when the user explicitly chooses to save, share, or hand off.
+- **Auto-write the deliverable** (Phase 4.1). The full per-idea detail (title, description, axis, basis, rationale, downsides, confidence, complexity) and the rejection summary go in the **file** — persistence is automatic, not opt-in. Location: `docs/ideation/` when it already exists, otherwise the run's CE temp area (`/tmp/compound-engineering/ce-ideate/<run-id>/`) — never the user's CWD. `OUTPUT_FORMAT` (SKILL.md Phase 0.0; default `html`) sets the extension.
+- **Present a concise summary** (Phase 4.2) — the ranked list (title · axis · confidence · complexity), counts, the path, and any zero-survivor axis. Do not reprint the full detail in the session; the rich file is what the user engages with. For HTML, best-effort open it in the browser (Phase 4.3).
 
-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_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. Offer four choices:
+Then offer the Phase 5 next-steps menu via 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_user` in Gemini / Pi). Fall back to a numbered list only when no blocking tool exists or the call errors. Never silently skip. Four options, option 1 format-keyed:
 
-- **Refine the ideation in conversation (or stop here — no save)** — add ideas, re-evaluate, or deepen analysis without writing anything. Ending the conversation at any point after this pick is a valid no-save exit.
-- **Open and iterate in Proof** — invoke the Proof HITL review path per the §6.2 contract in `references/post-ideation-workflow.md`: upload the survivors to Proof (rendered to a temp file since no local file is written in non-software elsewhere mode), iterate via comments, and exit cleanly with the Proof URL as the canonical record on successful return. Proof iteration is typically the terminal act in this mode, so the flow does not force another menu choice afterward. Only an `aborted` status returns to this menu. On persistent Proof failure, apply the §6.5 Proof Failure Ladder from `references/post-ideation-workflow.md` so the iteration attempt is not stranded without recovery.
-- **Brainstorm a selected idea** — go deeper on one idea through dialogue. Unlike repo mode, this is not the first step of an implementation chain — there is no `ce-plan` → `ce-work` after; `ce-brainstorm` in universal mode develops the idea further (e.g., expands a name into a brand brief, a plot into an outline, a decision into a weighed framework) and ends there. Persist first per the §6.3 contract in `references/post-ideation-workflow.md`: save the survivors to Proof (the elsewhere-mode default) or to `docs/ideation/` when the user explicitly asked for a local file, mark the chosen idea as `Explored`, then load `ce-brainstorm` with that idea as the seed. On a successful Proof return (`proceeded` or `done_for_now`), continue into the brainstorm handoff per §5.2's caller-aware return rule; on `aborted`, return to this menu without handing off. On persistent Proof failure, apply the §6.5 Proof Failure Ladder before ending so the brainstorm seed is preserved through a local-save fallback.
-- **Save and end** — share the survivors to Proof (the elsewhere-mode default) and end. Use `docs/ideation/` instead only when the user explicitly asks for a local file. On Proof failure (including after the single orchestrator-side retry), apply the §6.5 Proof Failure Ladder from `references/post-ideation-workflow.md` — surface the local-save fallback menu (custom path or skip) before ending so the user is not stranded without a recovery path.
+1. **Open in browser** *(html)* / **Open and iterate in Proof** *(md)* — open the deliverable (per §5.1). On Proof failure the auto-written local file stays intact.
+2. **Brainstorm one idea with `ce-brainstorm`** — go deeper on one chosen idea (asks which). In universal mode this is **not** the first step of an implementation chain — there is no `ce-plan` → `ce-work` after; `ce-brainstorm` develops the idea further (a name into a brand brief, a plot into an outline, a decision into a weighed framework) and ends there. Seed it with the idea's substance + a provenance pointer (per §5.2) — not the whole file.
+3. **Iterate on one idea (adjust / ask, stay here)** — sharpen or interrogate a chosen idea before committing; adjustments rewrite the file, Q&A does not (per §5.3).
+4. **Done — keep the file and stop.**
 
-No-save exit is supported without a dedicated menu option. Pick Refine and stop the conversation, or use the question tool's free-text escape to say so directly — persistence is opt-in and the terminal review loop is already a complete ideation cycle.
+Discard is a free-text escape ("say 'discard' to delete it"), create-only — never deletes a resumed or pre-existing doc.
diff --git a/dist/skills/ce-plan/SKILL.md b/dist/skills/ce-plan/SKILL.md
index 48ad7ca..5f6968b 100644
--- a/dist/skills/ce-plan/SKILL.md
+++ b/dist/skills/ce-plan/SKILL.md
@@ -122,8 +122,8 @@ If the user references an existing plan file or there is an obvious recent match
 
 Words like "strengthen", "confidence", "gaps", and "rigor" are NOT sufficient on their own to trigger deepening. These words appear in normal editing requests ("strengthen that section about the diagram", "there are gaps in the test scenarios") and should not cause a holistic deepening pass. Only treat them as deepening intent when the request clearly targets the plan as a whole and does not name a specific section or content area to change — and even then, prefer to confirm with the user before entering the deepening flow.
 
-Once the plan is identified and appears complete (all major sections present, implementation units defined, `status: active`):
-- **Routing is keyed on file extension first, then frontmatter.** HTML plans (`.html`) are always software plans — the html-rendering invariant forbids YAML frontmatter, so frontmatter absence is not a non-software signal for HTML. Treat the visible-header metadata (title, status, date) as the frontmatter equivalent.
+Once the plan is identified and appears complete (all major sections present, implementation units defined):
+- **Routing is keyed on file extension first, then frontmatter.** HTML plans (`.html`) are always software plans — the html-rendering invariant forbids YAML frontmatter, so frontmatter absence is not a non-software signal for HTML. Treat the visible-header metadata (title, date) as the frontmatter equivalent.
   - **`.html` plan:** short-circuit to Phase 5.3 (Confidence Check and Deepening) in **interactive mode**. Never route to `references/universal-planning.md` based on missing YAML.
   - **`.md` plan WITH YAML frontmatter:** short-circuit to Phase 5.3 in **interactive mode**.
   - **`.md` plan WITHOUT YAML frontmatter** (non-software plans use a simple `# Title` heading with `Created:` date instead): route to `references/universal-planning.md` for editing or deepening instead of Phase 5.3. Non-software plans do not use the software confidence check.
diff --git a/dist/skills/ce-plan/references/html-rendering.md b/dist/skills/ce-plan/references/html-rendering.md
index 7c61b74..53e291e 100644
--- a/dist/skills/ce-plan/references/html-rendering.md
+++ b/dist/skills/ce-plan/references/html-rendering.md
@@ -27,28 +27,18 @@ These hold regardless of which skill produced the artifact.
   Bunny Fonts, etc.), paired with an offline-readable fallback font stack
   so the doc remains readable if the CDN is unreachable.
 - **All metadata appears as visible text — single source of truth.**
-  The artifact's metadata (title, type, status, date, etc. — exact
+  The artifact's metadata (title, type, date, etc. — exact
   fields per-skill, defined in the section contract) renders as visible
   HTML elements that downstream agents and humans read. No hidden
   machine-readable copy in any form: no `<script type="application/json">`
   frontmatter block, no `data-*` attribute mirror, and no
-  `<meta name="status">` / `<meta name="created">` / `<meta name="origin">`
+  `<meta name="created">` / `<meta name="origin">`
   in `<head>` duplicating the same values that appear in the visible
   header. One representation for each value — drift across two copies is
   the failure this rule prevents.
 
   The text-and-attribute redundancy in `<time datetime="2026-05-12">2026-05-12</time>`
   is acceptable because the attribute is a parser hint, not a hidden copy.
-- **Editable status renders as `<span class="status">{value}</span>`.**
-  Downstream tooling (`ce-work` shipping flip, future HTML-aware
-  consumers) finds and rewrites status by selector. Embedding the
-  status value inside a header `<dl>` cell (`<dt>Status</dt><dd>active</dd>`),
-  inside a `<meta>` tag, or as visible text without the `class="status"`
-  hook all break the flip mechanic — the consumer either can't locate
-  the value or can't disambiguate it from prose. The status span may
-  sit anywhere in the doc (inside the header metadata, in a stats
-  strip, in a hero banner); placement is a visual choice, the selector
-  shape is the contract.
 - **Stable IDs as anchor IDs AND visible text.** Every ID-bearing item
   (R-IDs, U-IDs, A-IDs, F-IDs, AE-IDs, KTDs) gets `id="r1"` on its
   element AND appears as visible text inside the element (e.g., the
@@ -112,45 +102,66 @@ Worktree-root only — do not fall through to a main checkout. Users
 working from a worktree who want HTML defaults can add DESIGN.md to the
 worktree.
 
-**DESIGN.md is a partial override, not all-or-nothing.** Real
-DESIGN.md files vary widely: some are token tables, some are CSS
-variables, some are prose; most cover a subset of what HTML composition
-needs. Apply the tokens that fit a long-form text doc — typography roles,
-text colors, contrast targets, border-radius scale, elevation primitives,
-muted-vs-accent split. Skip the rest. Three specific failure modes to
-defend against:
-
+**DESIGN.md is a partial override, not all-or-nothing.** Real DESIGN.md
+files vary widely: some are token tables, some are CSS variables, some are
+prose; most are authored for a *product or marketing surface*, not a
+long-form doc. The governing split: **take the brand's scale-independent
+identity literally, own the scale-dependent layout values yourself, and
+skip decoration.**
+
+- **Take literally (scale-independent identity):** the color palette
+  (under the contrast rule), font *weight* and *style*, OpenType features,
+  and radius *character* (sharp vs rounded). These carry the brand and are
+  safe at any size.
+- **Own it yourself (scale-dependent layout):** the **type size scale**
+  and **spacing magnitudes**. DESIGN.md values are almost always
+  product/marketing-scaled (display headings at 48-80px, airy ~96px
+  section gaps); read them only as *hierarchy*, then set doc-appropriate
+  values (body ~14-16px, headings ~1.2-1.6× body, comfortable paragraph
+  spacing).
+- **Skip decoration:** decorative or atmospheric brand voltage with no
+  content to attach to in a doc — gradient orbs, full-bleed hero
+  photography, motion. Take the palette and feel; do not reproduce the
+  decoration.
+
+Specific cases:
+
+- **Fonts: load only open webfonts; never attempt a proprietary brand
+  face.** A self-contained doc can only load an open webfont (Google Fonts
+  or an open CDN) via the permitted webfont `<link>` plus an offline
+  fallback stack. **Assume a bespoke brand face is proprietary and do not
+  attempt to load it** — Airbnb Cereal, Coinbase Display/Sans, BMW Type,
+  Waldenburg, Circular and the like will not render in a single file;
+  trying just produces a broken fallback. Use the DESIGN.md's own fallback
+  chain, or a family-matched system stack (serif↔serif, sans↔sans,
+  mono↔mono). Load a named face *only* when it is a known open webfont
+  (Inter, Geist, Cal Sans, Roboto…); when unsure whether a face is open,
+  do not try. Honor the DESIGN.md's declared roles (`body` / `display` /
+  `mono`) and never promote a display/decorative face into a body or
+  small-text role. Net: reproduce the brand's serif-vs-sans structure and
+  weight voice, not necessarily its exact faces.
+- **Typography-scale mismatch.** DESIGN.md typography tokens are usually
+  sized for product UI — marketing pages, app screens, hero sections —
+  with display headings at 48-80px. A long-form doc needs body at ~14-16px
+  and headings at ~1.2-1.6× body. When the size scale looks
+  product-scaled (the common case), use the **family**, **weight**, and
+  **OpenType feature** assignments (these carry the design language) and
+  pick the agent's own size scale for the doc surface. Apply DESIGN.md
+  sizes literally only when they are clearly doc-scaled — body 14-16px,
+  headings under ~32px.
 - **Scope mismatch (product UI vs doc surface).** A DESIGN.md aimed at
-  product marketing or app UI may name page-surface colors, button
-  states, input borders, or hero backgrounds that are tied to *that*
-  surface, not to a generic doc. Page-surface colors are the canonical
-  trap — `--surface: #c0f0fb` belongs on the product's marketing page,
-  not on every plan or requirements doc the team writes. Extract the
-  principle (the design language uses a tinted surface) rather than the
-  literal value when the token is product-UI-scoped. Apply literal
-  values only when the token is generic enough to transfer (text color,
-  type scale ratio, radius scale, contrast ratio).
+  product marketing or app UI may name button states, input borders, or
+  hero backgrounds tied to *that* surface, not a generic doc. The page
+  surface is the case to judge: a **reading canvas** — white, off-white,
+  or a legible dark — transfers **literally** and should be the doc
+  background; a bright product/marketing-hero surface
+  (`--surface: #c0f0fb`) does not — extract the principle (the design
+  language uses a tinted surface) rather than the literal value when the
+  token is product-UI-scoped.
 - **Partial coverage.** When DESIGN.md defines some categories but not
-  others (e.g., colors but no spacing scale, typography but no
-  elevation), use DESIGN.md for what it covers and the fallback default
-  for what it doesn't. Do not require DESIGN.md to be complete before
-  honoring it.
-- **Named font without a fetchable source.** When DESIGN.md names a
-  font (e.g., "Signifier", "Every") without a CDN URL or local
-  `@font-face` source the agent can inline, treat the name as a hint
-  about the design intent, not a literal directive. Emit a system-font
-  stack in the same family (serif vs sans vs mono) and pick a weight
-  that matches the intent. The single-file invariant still holds; do
-  not link to an external stylesheet to fetch the named font.
-- **Typography-scale mismatch.** DESIGN.md typography tokens are often
-  sized for product UI — marketing pages, app screens, hero sections —
-  with body text at 18-20px and headings at 32-52px. A long-form doc
-  surface needs body at ~14-16px and headings at ~1.2-1.6× body. When
-  the DESIGN.md size scale looks product-scaled, use the **family**,
-  **weight**, and **OpenType feature** assignments (these carry the
-  design language) and pick the agent's own **size scale** for the doc
-  surface. Apply DESIGN.md sizes literally only when the tokens are
-  clearly doc-scaled — body tokens at 14-16px, headings under ~32px.
+  others (colors but no spacing scale, typography but no elevation), use
+  it for what it covers and the fallback default for the rest. Do not
+  require DESIGN.md to be complete before honoring it.
 
 ## Format principles
 
@@ -256,6 +267,19 @@ long list overwhelms the eye, especially in dark mode. CSS should leave
 `strong` at `color: inherit` unless a specific surface (status pill, ID
 chip) is being styled.
 
+### Chips and pills: uniform shape, no one-sided accent
+
+Status chips, ID chips, and metric pills in the same row share one shape
+— same border-radius, border weight, and fill treatment. Differentiate
+categories only by the chip's overall fill/text color (applied to the
+whole pill, like a soft-tint badge), never by an accent on one edge. A
+colored stripe or arc on a single side of a pill reads as broken and
+asymmetric — as if a border half-failed to render — so avoid it. The same
+holds for any element, not just chips: differentiate by a full tint, not
+a colored stripe on one edge. If an ID chip should stand out from metric
+chips, vary its fill/text color uniformly, not its edge treatment, and
+keep every chip in the row a visual set.
+
 ### No JS framework runtimes
 
 A small inline `<script>` for active-section TOC tracking or anchor-
@@ -304,11 +328,13 @@ contracts — the agent picks shapes that fit the content.
   bold decision title (often with inline code for technical
   identifiers), and prose rationale. Flat cards (not collapsibles) —
   these are reference material readers scan, not drill into.
-- **Risks** — color-coded cards with status eyebrow (e.g., "RISK ·
-  MITIGATED" / "OPEN · DEFERRED FOLLOW-UP") and prose body. Color of
-  the left-border or accent communicates status at a glance.
-- **Scope Boundaries** — callout cards with color-coded left borders
-  (in-scope vs deferred vs outside) when the distinction is meaningful.
+- **Risks** — cards with a color-coded status eyebrow (e.g., "RISK ·
+  MITIGATED" / "OPEN · DEFERRED FOLLOW-UP") and prose body. Communicate
+  status through the eyebrow's color plus an optional subtle full-card
+  tint — not a colored stripe on one edge (see "Chips and pills").
+- **Scope Boundaries** — callout cards distinguished (in-scope vs deferred
+  vs outside) by a colored eyebrow/label plus a subtle full-card tint when
+  the distinction is meaningful — not a one-edge colored stripe.
 
 The agent picks more elaborate or simpler shapes based on what each
 specific artifact's content needs.
@@ -345,20 +371,33 @@ adding a diagram is not license to thin the prose it depicts.
 
 The agent designs SVG coordinates without rendering — layouts that look
 fine in source can collide in practice. Before emitting, trace each
-labeled arrow and each text label:
-
-- **No arrow path passes through a text label.** If an arrow line or
-  curve crosses a label's bounding box, the text reads as struck-through
-  and the arrow reads as terminating at the wrong element. Fix by
-  re-routing the arrow, moving the label, or applying
-  `paint-order: stroke fill` with a stroke color matching the diagram
-  background to halo the label. The halo width is a judgment call:
+labeled arrow, each shape edge, and each text label:
+
+- **No stroke — arrow *or* shape edge/border — passes through a text
+  label.** If an arrow line/curve, or the border of a box, parallelogram,
+  or other shape, crosses a label's bounding box, the text reads as
+  struck-through and the stroke reads as terminating at the wrong element.
+  Fix by re-routing the arrow, moving the label clear of every edge, or
+  applying `paint-order: stroke fill` with a stroke color matching the
+  diagram background to halo the label. The halo width is a judgment call:
   narrow enough not to bleed into glyph strokes (a halo whose width
   approaches the glyph's own stroke width muddies the text color), wide
-  enough to mask underlying arrows (at least the arrow's stroke width
+  enough to mask the underlying stroke (at least its stroke width
   plus a hairline). Verify by inspecting rendered text at the target
   font size — if glyphs look thicker or more colored-toward-halo than
   the same text outside the diagram, the halo is too wide.
+- **Labels inside skewed or rotated shapes sit in the shape's true
+  interior, not its bounding box.** A parallelogram, isometric face, or
+  rotated rect has an interior offset from its bounding box, so a
+  box-aligned (e.g. left-aligned) label spills past the slanted edge.
+  Inset the label to fall inside the actual shape — account for the
+  skew/rotation offset at the label's vertical position — or place it
+  outside the shape with a short leader. This is the usual failure in the
+  **stacked-layers idiom** (offset parallelograms implying z-order), where
+  per-layer labels left-aligned to the container both overflow the lower
+  layers and get crossed by the neighbouring layer's edge. Prefer
+  labelling each layer in its own un-overlapped region, or to the side of
+  the stack.
 - **Arrow labels sit adjacent to the arrow's midpoint** (typically
   within ~10-15px above or beside the line they describe). A label
   floating at the diagram's edge that readers have to trace back to an
@@ -460,14 +499,28 @@ fine when the content suggests them.
   Before / After, Two alternatives).
 - **Tinted callout cards** for content that is "different in kind"
   (Deferred, Open Questions, advisory notes, unit-level execution notes)
-  — color-coded left borders communicate kind at a glance.
+  — a subtle full-card background tint plus a colored eyebrow/label
+  communicates kind at a glance. Avoid a colored stripe on one edge; tint
+  the whole card instead.
 
 ## Agent-consumability rules
 
-Downstream agents that read HTML today (`ce-work`, future consumers) read
-the HTML file as text linearly, not via DOM extraction. `ce-doc-review` is
-not a current HTML consumer (see opening note). Compose so semantic
-understanding is reachable in source:
+Downstream agents that read HTML today (`ce-work`, a skill re-reading its
+own prior artifact on a resume run, future consumers) reason over the HTML
+as text — the way they reason over markdown, not via DOM extraction or a
+script-style parse. `ce-doc-review` is not a current HTML consumer (see
+opening note).
+
+These rules are why such a consumer can locate one item (a single
+requirement, unit, idea, or other ID-bearing entry) and reason over it from
+source alone — its title, every labeled field, and any diagram's meaning —
+with no hidden machine-readable copy to fall back on. The semantic structure
+*is* the extraction contract: it is what makes the single-source-of-truth
+invariant (no `data-*` or JSON metadata mirror) safe rather than lossy.
+Weakening it — `<article>` item boundaries collapsed into `<div>` soup, a
+field label demoted to an attribute, one item's content scattered across
+distant parts of the doc — breaks that reasoning even when the rendered page
+looks identical. Compose so semantic understanding is reachable in source:
 
 - **Use semantic HTML over `<div>` soup.** `<article>` per unit card,
   `<dl>` for metadata pairs, `<table>` for tabular content, `<details>`
@@ -502,12 +555,10 @@ Before returning the artifact, scan it for common slips:
 - **Single self-contained file.** No companion `.css` / `.js` / `.svg`.
 - **No hidden machine-readable metadata copy.** No
   `<script type="application/json">` frontmatter block, no `data-*`
-  attributes mirroring visible values, **no `<meta name="status">` /
-  `<meta name="created">` / `<meta name="origin">` etc. in `<head>`
+  attributes mirroring visible values, **no `<meta name="created">` /
+  `<meta name="origin">` etc. in `<head>`
   duplicating the visible header**. Metadata lives in visible text;
   one source of truth per value.
-- **Status renders as `<span class="status">{value}</span>`** so
-  downstream tooling can flip `active → completed` by selector.
 - **All stable IDs** appear as both `id=""` and visible text.
 - **Section heading vocabulary** matches the section contract names
   (downstream agents grep these).
@@ -522,6 +573,10 @@ Before returning the artifact, scan it for common slips:
 - **Within-section sub-nav** is present for sections with 6+ repeating
   cards.
 - **Body `<strong>`** is not colored with accent palette.
+- **No one-edge colored accent** (a colored stripe/arc on a single side)
+  on chips, pills, or callout cards — differentiate by uniform fill +
+  colored eyebrow/label instead. A one-sided stripe reads as
+  broken/unintentional; chips in a row must be a uniform visual set.
 - **`<details>`** inside repeating cards have no `open` attribute.
 - **Diagram labels** are legible — no arrow paths crossing text,
   halo width appropriate for font size.
diff --git a/dist/skills/ce-plan/references/markdown-rendering.md b/dist/skills/ce-plan/references/markdown-rendering.md
index c1a1c98..8e20a6b 100644
--- a/dist/skills/ce-plan/references/markdown-rendering.md
+++ b/dist/skills/ce-plan/references/markdown-rendering.md
@@ -13,10 +13,8 @@ content rendered by different skills shares the same markdown principles.
 These hold regardless of which skill produced the artifact.
 
 - **YAML frontmatter at the top of the file.** Standard `---` delimited block
-  containing the artifact's stable metadata (title, status, date, type, etc.
-  — exact fields are per-skill, defined in the section contract). Editable
-  in place; tools and agents that do status flips (`active → completed`)
-  update the YAML directly.
+  containing the artifact's stable metadata (title, date, type, etc.
+  — exact fields are per-skill, defined in the section contract).
 - **ASCII identifiers in anchors.** Markdown headings auto-generate anchors
   from the heading text. Keep headings ASCII so anchors are predictable
   (`#implementation-units`, not `#implementación-units`).
@@ -181,15 +179,12 @@ brainstorm frontmatter). Common rules:
 
 - YAML at the top of the file, delimited by `---` on its own line above
   and below.
-- Field names in lowercase snake_case (`status`, `created_at`, not
-  `Status`, `CreatedAt`).
-- **Status lifecycle is per-contract.** When the section contract
-  defines a `status` field with a lifecycle (plans use
-  `active → completed`, flipped by ce-work at shipping time via direct
-  YAML edit), it is editable in place. When the section contract does
-  not define a status lifecycle (brainstorms, for example, have no
-  `active → completed` flip — they are upstream of plans and
-  referenced via the plan's `origin:`), do not introduce one.
+- Field names in lowercase snake_case (`created_at`, `topic`, not
+  `CreatedAt`, `Topic`).
+- **No status / lifecycle field.** Artifacts are point-in-time records
+  (decision or discovery), not tracked work items. Do not introduce a
+  mutable `status` field or an `active → completed` lifecycle — whether
+  the work shipped is derived from git, not stored in the doc.
 - Stable across artifact revisions — never rename or repurpose a field.
 
 ## Post-write audit
diff --git a/dist/skills/ce-plan/references/plan-sections.md b/dist/skills/ce-plan/references/plan-sections.md
index e019eff..d9db4eb 100644
--- a/dist/skills/ce-plan/references/plan-sections.md
+++ b/dist/skills/ce-plan/references/plan-sections.md
@@ -212,13 +212,13 @@ plan.
 - **`type`** — conventional-commit-prefix-aligned classification (`feat`,
   `fix`, `refactor`, `chore`, `docs`, `perf`, `test`, etc.). Carries the
   intent the eventual commit message should reflect.
-- **`status`** — `active` on creation; `ce-work` flips to `completed` on
-  ship. `ce-plan`'s Phase 0.1 resume fast path keys on `active`. In HTML,
-  status MUST render as `<span class="status">{value}</span>` so the flip
-  mechanic can locate and rewrite it by selector (see
-  `references/html-rendering.md`).
 - **`date`** — creation date in ISO 8601 (`YYYY-MM-DD`), ASCII digits only.
 
+Plans carry **no `status` field** — a plan is a decision artifact, not a
+tracked work item. `ce-work` does not mutate the plan at ship time;
+whether a plan shipped is derived from git, not stored in the doc. Do not
+add a `status` field or an `active → completed` lifecycle.
+
 ### Optional but well-known
 
 These fields are not required, but when set they have fixed names and
@@ -243,8 +243,8 @@ semantics so downstream tooling can rely on them:
 
 Field names are stable across plan revisions — never rename a field or
 repurpose its semantics. Agents composing new plans MUST use these exact
-names; adding new fields is fine, but renaming `status` to `state` or
-`origin` to `source` breaks the downstream consumers above.
+names; adding new fields is fine, but renaming `origin` to `source` or
+`date` to `created` breaks the downstream consumers above.
 
 ## ID and content rules
 
diff --git a/dist/skills/ce-release-notes/SKILL.md b/dist/skills/ce-release-notes/SKILL.md
index 450d53e..61fa87f 100644
--- a/dist/skills/ce-release-notes/SKILL.md
+++ b/dist/skills/ce-release-notes/SKILL.md
@@ -73,12 +73,12 @@ For each release, render:
 
 {body, soft-capped at 25 rendered lines}
 
-[Full release notes →]({url})
+Full release notes: {url}
 ```
 
 `{published_at_human}` is the date in `YYYY-MM-DD` form derived from `published_at`. `{body}` is the release-please body verbatim, with one transformation:
 
-**Soft 25-line cap.** If the body exceeds 25 rendered lines, keep the first 25 lines and append `— N more changes, [see full release notes →]({url})`. Truncation must be **markdown-fence aware**: count the triple-backtick fence lines that appear in the kept portion. If the count is odd, the cut landed inside an open code fence; close it with a `` ``` `` line on the truncated output before appending the "see more" link, so renderers do not swallow the link or following content.
+**Soft 25-line cap.** If the body exceeds 25 rendered lines, keep the first 25 lines and append `— N more changes, see full release notes: {url}`. Truncation must be **markdown-fence aware**: count the triple-backtick fence lines that appear in the kept portion. If the count is odd, the cut landed inside an open code fence; close it with a `` ``` `` line on the truncated output before appending the "see more" link, so renderers do not swallow the link or following content.
 
 After all releases are rendered, append a two-line footer:
 
@@ -135,7 +135,7 @@ Always pass the PR number as a separate argument (list-form) — never interpola
 Write a direct narrative answer to the user's question. Cite the **primary** matching release inline as a version, e.g., `(v2.67.0)`, with a markdown link to the release URL. If older matches exist, reference them inline as:
 
 ```
-previously: [v2.65.0]({older_url}), [v2.62.0]({older_url})
+previously: v2.65.0 ({older_url}), v2.62.0 ({older_url})
 ```
 
 Ground the narrative in the release body and (when available) the enriched PR title/body. Quote sparingly — paraphrase the change in the user's framing rather than dumping the release notes verbatim. Keep the answer scoped to the user's question; do not pad with unrelated changes from the same release.
diff --git a/dist/skills/ce-setup/references/config-template.yaml b/dist/skills/ce-setup/references/config-template.yaml
index 822cc43..b5cea2c 100644
--- a/dist/skills/ce-setup/references/config-template.yaml
+++ b/dist/skills/ce-setup/references/config-template.yaml
@@ -40,6 +40,7 @@
 
 # plan_output: html              # md | html (default: md)
 # brainstorm_output: html        # md | html (default: md)
+# ideate_output: md              # md | html (default: html -- ideation docs are human-facing, so HTML is the default; set md to opt out)
 
 # --- ce-promote ---
 # Written automatically when you decline the Spiral setup offer in /ce-promote.
diff --git a/dist/skills/ce-work-beta/SKILL.md b/dist/skills/ce-work-beta/SKILL.md
index 71103c0..5aa73ab 100644
--- a/dist/skills/ce-work-beta/SKILL.md
+++ b/dist/skills/ce-work-beta/SKILL.md
@@ -140,7 +140,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
    - If anything is unclear or ambiguous, ask clarifying questions now
    - If clarifying questions were needed above, get user approval on the resolved answers. If no clarifications were needed, proceed without a separate approval step — plan scope is the plan's authority, not something to renegotiate
    - **Do not skip this** - better to ask questions now than build the wrong thing
-   - **Do not edit the plan body during execution.** The plan is a decision artifact; progress lives in git commits and the task tracker. The only plan mutation during ce-work is the final `status: active → completed` flip at shipping (see `references/shipping-workflow.md` Phase 4 Step 2). Legacy plans may contain `- [ ]` / `- [x]` marks on unit headings — ignore them as state; per-unit completion is determined during execution by reading the current file state.
+   - **Do not edit the plan body during execution.** The plan is a decision artifact; progress lives in git commits and the task tracker, not the plan. `ce-work` does not mutate the plan — whether it shipped is derived from git, not recorded in the doc. Legacy plans may contain `- [ ]` / `- [x]` marks on unit headings or a `status:` field — ignore them as state; per-unit completion is determined during execution by reading the current file state.
 
 2. **Setup Environment**
 
diff --git a/dist/skills/ce-work-beta/references/non-code-execution.md b/dist/skills/ce-work-beta/references/non-code-execution.md
index 467a543..52b7593 100644
--- a/dist/skills/ce-work-beta/references/non-code-execution.md
+++ b/dist/skills/ce-work-beta/references/non-code-execution.md
@@ -9,7 +9,7 @@ Do **not** run any of the code-shipping machinery — it does not fit knowledge
 - No branch/worktree setup (Phase 1 Step 2).
 - No task-list-from-implementation-units, no execution-strategy/subagent dispatch keyed on `Files:`.
 - No Test Discovery, no test-scenario completeness, no system-wide test check.
-- No incremental code commits, and none of `references/shipping-workflow.md` (no PR, no CI, no `active → completed` flip on a code plan).
+- No incremental code commits, and none of `references/shipping-workflow.md` (no PR, no CI).
 
 ## Execute the production plan
 
diff --git a/dist/skills/ce-work-beta/references/shipping-workflow.md b/dist/skills/ce-work-beta/references/shipping-workflow.md
index 051cedd..a3a476a 100644
--- a/dist/skills/ce-work-beta/references/shipping-workflow.md
+++ b/dist/skills/ce-work-beta/references/shipping-workflow.md
@@ -91,14 +91,7 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
 
    Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output). The `ce-commit-push-pr` skill will ask whether to capture evidence only when evidence is possible.
 
-2. **Update Plan Status**
-
-   If the input document has YAML frontmatter with a `status` field, update it to `completed`:
-   ```
-   status: active  ->  status: completed
-   ```
-
-3. **Commit and Create Pull Request**
+2. **Commit and Create Pull Request**
 
    Load the `ce-commit-push-pr` skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.
 
@@ -112,7 +105,7 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
 
    If the user prefers to commit without creating a PR, load the `ce-commit` skill instead.
 
-4. **Notify User**
+3. **Notify User**
    - Summarize what was completed
    - Link to PR (if one was created)
    - Note any follow-up work needed
diff --git a/dist/skills/ce-work/SKILL.md b/dist/skills/ce-work/SKILL.md
index 416e884..fde7170 100644
--- a/dist/skills/ce-work/SKILL.md
+++ b/dist/skills/ce-work/SKILL.md
@@ -87,7 +87,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
    - If anything is unclear or ambiguous, ask clarifying questions now
    - If clarifying questions were needed above, get user approval on the resolved answers. If no clarifications were needed, proceed without a separate approval step — plan scope is the plan's authority, not something to renegotiate
    - **Do not skip this** - better to ask questions now than build the wrong thing
-   - **Do not edit the plan body during execution.** The plan is a decision artifact; progress lives in git commits and the task tracker. The only plan mutation during ce-work is the final `status: active → completed` flip at shipping (see `references/shipping-workflow.md` Phase 4 Step 2). Legacy plans may contain `- [ ]` / `- [x]` marks on unit headings — ignore them as state; per-unit completion is determined during execution by reading the current file state.
+   - **Do not edit the plan body during execution.** The plan is a decision artifact; progress lives in git commits and the task tracker, not the plan. `ce-work` does not mutate the plan — whether it shipped is derived from git, not recorded in the doc. Legacy plans may contain `- [ ]` / `- [x]` marks on unit headings or a `status:` field — ignore them as state; per-unit completion is determined during execution by reading the current file state.
 
 2. **Setup Environment**
 
diff --git a/dist/skills/ce-work/references/non-code-execution.md b/dist/skills/ce-work/references/non-code-execution.md
index 467a543..52b7593 100644
--- a/dist/skills/ce-work/references/non-code-execution.md
+++ b/dist/skills/ce-work/references/non-code-execution.md
@@ -9,7 +9,7 @@ Do **not** run any of the code-shipping machinery — it does not fit knowledge
 - No branch/worktree setup (Phase 1 Step 2).
 - No task-list-from-implementation-units, no execution-strategy/subagent dispatch keyed on `Files:`.
 - No Test Discovery, no test-scenario completeness, no system-wide test check.
-- No incremental code commits, and none of `references/shipping-workflow.md` (no PR, no CI, no `active → completed` flip on a code plan).
+- No incremental code commits, and none of `references/shipping-workflow.md` (no PR, no CI).
 
 ## Execute the production plan
 
diff --git a/dist/skills/ce-work/references/shipping-workflow.md b/dist/skills/ce-work/references/shipping-workflow.md
index 0957258..2a438e3 100644
--- a/dist/skills/ce-work/references/shipping-workflow.md
+++ b/dist/skills/ce-work/references/shipping-workflow.md
@@ -91,26 +91,7 @@ This file contains the shipping workflow (Phase 3-4). It is loaded when all Phas
 
    Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output). The `ce-commit-push-pr` skill will ask whether to capture evidence only when evidence is possible.
 
-2. **Update Plan Status**
-
-   Update the plan's `status` field from `active` to `completed`. The
-   mechanic depends on the plan's format:
-
-   - **Markdown plan (`.md`).** YAML frontmatter at the top of the file
-     carries the status. Edit the YAML directly:
-     ```
-     status: active  ->  status: completed
-     ```
-   - **HTML plan (`.html`).** Status lives as visible text in the rendered
-     header (typically `<span class="status">active</span>` or similar).
-     Edit the visible element's text content directly. There is no hidden
-     JSON-frontmatter copy to keep in sync — HTML metadata is a single
-     source of truth in visible text per the html-rendering invariants.
-
-   If no status field exists in either format, skip this step — some
-   plans omit frontmatter entirely.
-
-3. **Commit and Create Pull Request**
+2. **Commit and Create Pull Request**
 
    Load the `ce-commit-push-pr` skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.
 
@@ -124,7 +105,7 @@ This file contains the shipping workflow (Phase 3-4). It is loaded when all Phas
 
    If the user prefers to commit without creating a PR, load the `ce-commit` skill instead.
 
-4. **Notify User**
+3. **Notify User**
    - Summarize what was completed
    - Link to PR (if one was created)
    - Note any follow-up work needed