feat(cycle4-phase1): chrome.py + decision.v1 foundation (DP6, no skill wiring)

CRAFT Cycle-4 (chrome/legibility, DP6) Phase 1 — the craft-side
foundation + the SKILL.md contract text. NO skill repos are touched and
NO conformance family fires live yet; Phase 2 vendors the copies and
flips Family-F / Family-G on as a coordinated release. No tag this phase.

Two facts (proven in the Phase-0 synthetic harness) shape the design:
  1. Inside Claude the orchestrator's stdout is non-TTY (no color) and
     long output folds — so the legible signal is Claude's MESSAGE BODY
     re-rendering the structured contract as text, not the raw box.
  2. decision.v1 EXTENDS .handoff.json: it retains the keys the continue
     CLI reads (notably `phase`, which authorizes --pick) and adds the
     presentation fields; `gate` must equal `phase`.

New — src/craft/chrome.py (canonical output-signature renderer):
  - STAGE (single-rule box) / DECISION (double-rule, loudest) / RESULT
    (terse) + per-skill glyph signature (◆ presentation-maker · ✎
    paper-writer · ⚔ adversarial) and `CRAFT · <skill>` label.
  - MUST-FIX honored: pads by DISPLAY WIDTH (stdlib unicodedata, NOT
    len(), NOT external wcwidth) so glyph-heavy / em-dash / CJK lines
    align to the border. Dependency-free so it vendors clean (Family-F).
  - Single _color() seam: TTY-gated (isatty), NO_COLOR-aware,
    CRAFT_FORCE_COLOR=1 test hook; no-op when piped (i.e. inside Claude).
  - render_decision never leaks the raw --pick flag or the draft path;
    shows every option's FULL detail; ★ marks default; clean "tell me
    TL1 / TL2" choice prompt. note_noise() appends orchestrator NOISE to
    audit/orchestrator.log off stdout.

New — src/craft/decision.py (decision.v1 shape contract):
  - validate_decision(payload) -> list[str]; never raises; substring-
    stable messages (sibling of run_record.validate_run_record).
  - Checks BOTH contracts: retained handoff keys (phase, draft_dir) AND
    the decision.v1 presentation fields; cross-checks gate==phase,
    default∈option ids, confirm is a real bool, continue.cmd carries the
    {id} placeholder.

New — tests:
  - tests/test_chrome.py (15): display-width basics + alignment on
    glyph/em-dash/CJK lines (the must-fix), color seam via subprocess
    (0 ANSI piped, ANSI under force, NO_COLOR overrides), signature
    content, no path/flag leak, note_noise append-and-never-raise.
  - tests/test_decision.py (51): golden validation + full negative-case
    matrix over the handoff-extension contract.
  - tests/fixtures/decision_v1/: two platform goldens, each a realistic
    handoff-extension — throughline (single_select, confirm:true) +
    image (approve_reject, confirm:false).

New conformance (armed but dormant — graceful-skip until Phase 2):
  - Family F: each skill's vendored chrome.py is byte-identical to the
    canonical (same copy-not-share discipline as llm_config / user_intent;
    glyphs are multi-byte UTF-8 — copy verbatim).
  - Family G: each skill's decision.v1 goldens validate against the shared
    validator.

Docs:
  - docs/reference/chrome-interaction-contract.md — canonical spec + the
    SKILL.md chrome contract text Phase 2 vendors into each skill (re-render
    decision.v1 completely inline as message text; honor `confirm`
    [echo-and-confirm on consequential gates, act directly on
    cheap/already-spent ones]; report stage/cost at boundaries from the
    run-record, no continuous tick; suppress orchestrator NOISE).
  - CRAFT-CONTRACT.md: §2.1 decision.v1 producer row + new §3.7 (the chrome
    / interaction layer) pointing at the canonical doc.
  - mkdocs.yml: Reference nav entry for the new doc.
  - prototypes/cycle4-chrome/: Phase-0 synthetic harness preserved as
    reference (the canonical doc + memory cite it); its generated
    scratch-draft/.handoff.json is gitignored.

Verify: pytest 218 passed, 7 skipped (the dormant Family-F/G rows + the
pre-existing adversarial run-record golden skip); ruff clean.

Note for Adam: the stale .commit-message-craft-v0.4.1.txt (already-used
Cycle-3 follow-up message) can be deleted — `git rm` or just remove it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: aparkin

.gitignore

@@ -10,3 +10,6 @@ dist/
 build/
 # MkDocs build output
 site/
+# Cycle-4 chrome prototype: generated scratch run artifacts (the harness
+# source IS committed; its synthetic .handoff.json output is not)
+prototypes/cycle4-chrome/scratch-draft/

CRAFT-CONTRACT.md

@@ -61,6 +61,7 @@ support window (typically 1-2 minor releases per skill).
 | `layout-overlaps.v1` | presentation-maker | v1 (v0.8.0 G.10-A) | (cascade Tier-1; external integrators) | Stable through CRAFT v1.x |
 | `content-overflow.v1` | presentation-maker | v1 (v0.8.0 G.10-C) | (cascade Tier-1 + revise_loop) | Stable through CRAFT v1.x |
 | `review-cascade.v1` | paper-writer + presentation-maker | v1 (M4b pattern) | (external integrators; future review systems) | Stable through CRAFT v1.x |
+| `decision.v1` | presentation-maker, paper-writer, adversarial | v1 (Cycle-4 DP6; foundation v0.x, wired Phase 2) | the invoking Claude session (chrome/interaction layer) | Stable through CRAFT v1.x |
 
 ### 2.2 Schema-bump policy
 
@@ -446,6 +447,48 @@ audit JSON at `audit/<your-skill>.json`. The platform's existing
 cascade readers will (eventually) lift them at Tier 1 via
 the read-if-present pattern.
 
+### 3.7 The chrome / interaction layer (Cycle-4, DP6)
+
+Skills run as subprocesses of an invoking Claude session. Two facts
+shape how their output reaches the user (both proven in the Cycle-4
+Phase-0 harness):
+
+1. **The message body is the legible signal — not stdout.** A skill's
+   stdout is non-TTY (no color) and the transcript folds long output,
+   so the user sees the skill's progress/decisions only if Claude
+   **re-renders the structured contract as message text.**
+2. **`decision.v1` extends `.handoff.json`.** A halt-and-handoff gate
+   writes a `decision.v1` payload that RETAINS the handoff keys the
+   `continue` CLI reads (notably `phase`, which authorizes `--pick`)
+   and ADDS presentation fields; `gate` must equal `phase`.
+
+The platform provides three pieces, all dependency-free / stdlib-only
+so they vendor cleanly into every skill:
+
+- **`craft.chrome`** — the output-signature renderer (`STAGE` /
+  `DECISION` / `RESULT` boxes + the per-skill glyph signature
+  `◆`/`✎`/`⚔`; a single `_color()` seam that no-ops off-TTY; padding by
+  **display width**, not `len()`). Each skill vendors a **byte-identical
+  copy** (Family-F conformance — same copy-not-share discipline as
+  `llm_config` and `user_intent`).
+- **`craft.decision`** — `validate_decision(payload) -> list[str]`, the
+  `decision.v1` shape contract (checks both the retained handoff keys
+  and the presentation fields).
+- **The SKILL.md chrome contract text** — the Claude-facing instruction
+  block each skill carries, telling the session to re-render decisions
+  completely inline, honor the `confirm` flag (echo-and-confirm on
+  consequential gates; act directly on cheap/already-spent ones), report
+  stage/cost at boundaries from the run-record, and suppress orchestrator
+  NOISE to `audit/orchestrator.log`.
+
+Full specification + the canonical SKILL.md text:
+`docs/reference/chrome-interaction-contract.md`.
+
+**Phasing:** Cycle-4 Phase 1 ships the foundation (the two modules,
+their goldens, the contract text, and armed-but-dormant Family-F /
+Family-G conformance). Phase 2 vendors the copies into each skill and
+flips the conformance families live.
+
 ---
 
 ## 4. Joining the platform (for future skills)

docs/reference/chrome-interaction-contract.md

@@ -0,0 +1,183 @@
+# CRAFT chrome / interaction-layer contract (canonical)
+
+**Schema:** `decision.v1` (the halt-and-handoff presentation contract) + the
+CRAFT output-signature blocks (`STAGE` / `DECISION` / `RESULT`).
+**Renderer:** `craft.chrome` (canonical at `craft-platform/src/craft/chrome.py`;
+each skill VENDORS a byte-identical copy — Family-F conformance).
+**Validator:** `craft.decision.validate_decision`.
+**Status:** Cycle-4 (DP6) Phase 1 — foundation. Wired into skills in Phase 2.
+
+This is the **source of record** for the chrome section that each CRAFT skill
+carries in its `SKILL.md`. Phase 2 vendors the "Contract text for SKILL.md"
+block below into each skill verbatim. Keep this doc and the per-skill SKILL.md
+copies in sync (they are a copy-not-share pair, like the chrome.py vendoring).
+
+---
+
+## Why this contract exists (the two facts it is built on)
+
+Both were proven empirically in the Cycle-4 Phase-0 synthetic harness
+(`prototypes/cycle4-chrome/`):
+
+1. **Inside Claude, the message body is the legible signal — not the box.**
+   A skill's orchestrator runs as a non-TTY subprocess, so (a) its stdout
+   carries **zero color** (the `chrome._color()` seam correctly no-ops when
+   piped) and (b) the Claude transcript **folds** long tool output. The boxed
+   STAGE/DECISION/RESULT blocks are real and useful at a bare terminal, but
+   **inside Claude the user sees them only if Claude re-renders them as message
+   text.** So the contract is: *Claude reconstructs the structured contract
+   (decision.v1 / run-record) as its own message, in a consistent presentation
+   style.* "Pass the box through verbatim" is NOT enough — folded output hides
+   it.
+
+2. **`decision.v1` EXTENDS the existing `.handoff.json` — it does not replace
+   it.** The `continue` CLI reads the handoff's own keys (notably **`phase`**,
+   which authorizes `--pick`). A decision payload therefore RETAINS those keys
+   and ADDS the presentation fields on top. `gate` MUST equal `phase`. This is
+   why `validate_decision` checks both contracts at once.
+
+---
+
+## The three signature classes (what the orchestrator emits)
+
+| Class | Box | When | Prominence |
+|---|---|---|---|
+| `STAGE` | single rule `┌─┐` | a pipeline stage starts/updates | quiet, present |
+| `DECISION` | double rule `╔═╗` | a halt-and-handoff gate | **loudest** |
+| `RESULT` | no box, terse glyph line | a stage/run produces a deliverable | terse |
+
+Each carries the per-skill signature: a glyph + `CRAFT · <skill>` label.
+
+| Skill | Glyph |
+|---|---|
+| presentation-maker | `◆` |
+| paper-writer | `✎` |
+| adversarial | `⚔` |
+
+Color is strictly additive (a bare-terminal bonus through the single
+`_color()` seam); the structural signature (box + glyph + label) carries the
+whole distinction with color stripped — which is the inside-Claude condition.
+
+---
+
+## `decision.v1` shape
+
+`decision.v1` is written to `<draft_dir>/.handoff.json` at a halt. It is the
+union of the real handoff keys and the presentation fields:
+
+```jsonc
+{
+  // --- retained handoff keys (the continue CLI reads these) ---
+  "phase": "throughline_pick",     // the halt id; AUTHORIZES --pick (required)
+  "draft_dir": "/abs/.../talks/draft_N",
+  // ... any other handoff fields the skill already wrote (candidates,
+  //     candidates_md, next_command, …) are retained, not stripped.
+
+  // --- decision.v1 presentation fields ---
+  "schema_version": "decision.v1",
+  "skill": "presentation-maker",   // presentation-maker | paper-writer | adversarial
+  "gate": "throughline_pick",      // MUST equal `phase`
+  "prompt": "Pick the throughline for the deck:",
+  "kind": "single_select",         // single_select | approve_reject | free_text
+  "options": [
+    {"id": "TL1", "summary": "one-line", "detail": "FULL text — show completely"}
+    // … empty list allowed only for free_text
+  ],
+  "default": "TL1",                // str | null; if set, must be an option id
+  "confirm": true,                 // bool — gates the echo-and-confirm beat (below)
+  "continue": {"cmd": "beril-presentation-maker continue {draft_dir} --pick {id}"}
+}
+```
+
+`continue.cmd` MUST carry the `{id}` placeholder so Claude can splice the
+chosen option id. The user must NEVER see the raw `--pick` flag or the draft
+path.
+
+---
+
+## Contract text for SKILL.md (vendor this block into each skill, Phase 2)
+
+> *(Substitute the skill's own name + glyph. The text below is for
+> presentation-maker; paper-writer uses `✎ paper-writer`, adversarial uses
+> `⚔ adversarial`.)*
+
+### CRAFT interaction layer — how to surface this skill's output
+
+This skill's orchestrator runs as a subprocess. Inside this session its stdout
+is non-TTY (no color) and long output is folded out of view, so **the
+user-facing signal is YOUR message, not the raw tool output.** Your job is to
+re-render the skill's structured signals — STAGE progress, DECISION halts,
+RESULT deliverables — as clear, consistent message text. Follow these rules:
+
+1. **Re-render the structured contract as message text — do not rely on the
+   raw box being visible.** When a tool result contains a CRAFT `STAGE` /
+   `DECISION` / `RESULT` block (or the `decision.v1` / run-record JSON behind
+   it), reconstruct it in your own message in a consistent presentation style.
+   The boxed block in stdout is bare-terminal chrome and a data source; the
+   legible copy the user reads is the one you write. Keep your style consistent
+   run-to-run so the skill's "voice" is recognizable.
+
+2. **On a DECISION halt, render the choice completely + inline, honor
+   `confirm`, then act on the reply.** When the orchestrator halts at a gate it
+   writes a `decision.v1` to `<draft_dir>/.handoff.json` and exits; the run is
+   paused waiting for the user. You MUST:
+   - Present **every** option **completely** — show each option's full
+     `detail` text, not just the `summary`, and never a file path or a "see
+     `.handoff.json`". The user decides from what you show; show all of it.
+   - Make choosing trivial: list the option `id`s (e.g. **TL1 / TL2 / TL3**),
+     note which is the `default`, and ask the user to pick one.
+   - **Honor `confirm`:**
+     - `confirm: true` (consequential, hard-to-reverse gates — e.g. a
+       throughline pick that sets the whole deck): after the user picks, **echo
+       the pick back and confirm once** ("Resuming with **TL1** — go?") BEFORE
+       running `continue.cmd`. Do not silent-auto-run.
+     - `confirm: false` (the choice is cheap or already-spent — e.g. an
+       image-approval where the cost is already incurred): run `continue.cmd`
+       directly on the stated choice; no extra confirmation beat needed.
+   - When you act, invoke the command in `continue.cmd`, substituting the
+     chosen `id` for `{id}`. The user must NEVER see or type the raw `--pick`
+     flag or the draft path — you translate their plain choice into the
+     command and run it.
+   - Do not invent options or change the `id`s; use exactly what `decision.v1`
+     carries. For `kind: free_text`, the user's typed reply fills the `{id}`
+     slot.
+
+3. **Report progress + cost at boundaries, from the run-record — not a
+   continuous tick.** The STAGE banners mark stage boundaries; surface a brief
+   "Stage N/M (<stage>) — <state>" line at those boundaries, and read
+   stage/cost/tokens/model from the run-record (`audit/run_record.json`) when
+   reporting them. Do **not** narrate every internal step or invent a live
+   progress meter (continuous live ticking is deferred). A final cost/summary
+   line when the run completes is welcome; per-step "now I'll run the next
+   stage" narration is noise.
+
+4. **Suppress orchestrator NOISE.** Lines the orchestrator marks as internal
+   (e.g. `[orchestrator] …` diagnostics) are written to
+   `<audit_dir>/orchestrator.log`, not to the user. Do not surface that log
+   content unless the user is debugging or an error/blocker requires it.
+
+5. **Speak up only when it carries signal.** A DECISION (rule 2), an
+   error/blocker, a boundary report (rule 3), or a final summary the user asked
+   for. A bare "Stage 5 is running." with nothing else is worse than silence —
+   let the structured re-render do the work.
+
+---
+
+## Conformance
+
+- **Family F** (`tests/test_conformance.py`) — each skill's vendored
+  `chrome.py` is byte-identical to craft-platform's canonical. Graceful-skips
+  until Phase 2 vendors the copies; fails loud after. The glyphs are multi-byte
+  UTF-8 — copy the file verbatim (a locale/encoding slip diverges them
+  invisibly).
+- **Family G** (`tests/test_conformance.py`) — each skill's shipped
+  `decision.v1` goldens (`tests/fixtures/decision_v1/*.json`) validate against
+  the shared `validate_decision`. Graceful-skips until Phase 2.
+- **Platform goldens** (`tests/test_decision.py`) — the canonical
+  `decision.v1` goldens (`tests/fixtures/decision_v1/throughline_single_select.json`,
+  `image_approve_reject.json`) validate clean and are the worked examples of
+  the handoff-extension shape (single_select/confirm:true and
+  approve_reject/confirm:false).
+- **Renderer** (`tests/test_chrome.py`) — display-width alignment (the
+  must-fix: pad by visible glyph width, not `len()`), the color seam, the
+  signature content, and the no-path/no-flag-leak guarantee.

mkdocs.yml

@@ -129,5 +129,6 @@ nav:
       - Adding a skill: extending/adding-a-skill.md
       - External contributors: extending/external-contributors.md
   - Reference:
+      - Chrome / interaction contract: reference/chrome-interaction-contract.md
       - Release notes: reference/release-notes.md
       - Platform proposal: reference/platform-proposal.md

prototypes/cycle4-chrome/README.md

@@ -0,0 +1,135 @@
+# CRAFT Cycle-4 chrome — Phase-0 synthetic harness (PROTOTYPE)
+
+Scratch prototype to prove the two riskiest design bets of Cycle-4 (chrome/
+legibility, DP6) in a **real Claude session**, cheaply, **before** touching any
+skill repo. Brief: `handoffs/CRAFT-cycle4-chrome-legibility-brief.md` (Phase 0
++ Pillars 1–3).
+
+Nothing here is shipped. No skill repos are touched; no git. This is the
+prototype we later harden into the real `chrome.py` + `decision.v1` validator.
+
+## Files
+- `chrome.py` — prototype renderer. `render_stage` / `render_decision` /
+  `render_result`; per-skill glyph+label (◆ presentation-maker · ✎ paper-writer
+  · ⚔ adversarial); a single `_color()` seam (TTY-gated, `NO_COLOR`-aware,
+  no-op when piped). `python chrome.py --demo` prints one of each block.
+- `synthetic_halt.py` — writes a `decision.v1` to a scratch `.handoff.json`,
+  prints the DECISION block, exits 0 like the real halt. `--gate
+  throughline_pick` (default, single_select) or `--gate image_approval`
+  (approve_reject — proves the contract generalizes).
+- `chrome-interaction.md` — draft of the SKILL.md chrome section (the
+  Claude-interaction contract under test in Test 2).
+
+## Design choices in this prototype (the parked open decisions)
+- **STAGE = single-rule box** (`┌─┐`), **DECISION = double-rule box** (`╔═╗`) —
+  DECISION is the most prominent class by design.
+- **RESULT = no box**, a terse glyph-tagged one-liner.
+- **Color is strictly additive.** Every distinction (box + glyph + label) is
+  structural and survives with color stripped. `_color()` is the only ANSI
+  emitter; it no-ops unless stdout is a TTY and `NO_COLOR` is unset.
+
+---
+
+## Adam's test protocol (run in a REAL Claude session)
+
+### Test 1 — signature + color reality
+Have Claude run:
+```
+python chrome.py --demo
+```
+Observe in the tool-result block:
+- Do the **box + glyph + skill-ID label** read as DISTINCT from Claude's
+  surrounding prose? Is "which skill is talking" instant?
+- Does **color** render, come through as raw escape codes (`\033[36m…`), or get
+  stripped? (Expectation from the brief: stripped/absent inside Claude, since
+  the subprocess stdout is non-TTY. Confirm empirically.)
+- Compare single-rule STAGE vs double-rule DECISION — does the prominence
+  ordering read right?
+
+Optional bare-terminal contrast (shows the color seam working where a TTY
+exists): `CRAFT_FORCE_COLOR=1 python chrome.py --demo` vs piped
+`python chrome.py --demo | cat` (latter must be plain).
+
+### Test 2 — decision.v1 inline rendering (the central bet)
+With `chrome-interaction.md` loaded into the session context, have Claude run:
+```
+python synthetic_halt.py
+```
+Observe:
+- Does Claude present the **full** throughline options (TL1/TL2/TL3) cleanly
+  **inline**, including each option's complete `detail` text — NOT a summary,
+  NOT "see .handoff.json"?
+- Does it make choosing trivial (lists the ids + the default) and collect a
+  choice (e.g. "TL1")?
+- On the reply, does it show it would invoke
+  `beril-presentation-maker continue <draft_dir> --pick TL1` — with the user
+  never seeing the raw `--pick` flag or the draft path?
+
+Also run `python synthetic_halt.py --gate image_approval` to confirm the
+approve/reject `kind` renders + collects cleanly too.
+
+**Gate:** if the in-session decision rendering doesn't behave, we adjust
+`decision.v1` + `chrome-interaction.md` HERE (cheap) before wiring any
+pipeline.
+
+---
+
+## Phase-0 findings (CC, in-session, 2026-06-09)
+
+**Both bets PROVED.** Test 1: the box + glyph + `CRAFT · <skill>` label read as
+clearly distinct inside a Claude tool-result block, amid prose — structural,
+zero color needed. Test 2: with `chrome-interaction.md` as the contract, the
+synthetic `decision.v1` halt rendered as a complete inline choice (all three
+candidates, full detail) with a trivial "tell me TL1/TL2/TL3" and no
+path/flag exposed; the `.handoff.json` artifact is well-formed; both
+`single_select` and `approve_reject` kinds render + collect cleanly.
+
+**Color reality confirmed empirically:** captured (non-TTY, i.e. inside Claude)
+→ ZERO ANSI, plain box-drawing. `CRAFT_FORCE_COLOR=1` (bare TTY) → 53 ANSI
+lines. `NO_COLOR` overrides force. So color is absent exactly where legibility
+matters, and the structural signature carries the whole distinction — as the
+brief predicted.
+
+**Two defects found + fixed in-phase (the gate's purpose):**
+1. *Box width blowout* — one long line (the raw `continue.cmd`, ~190 chars with
+   an absolute draft path) stretched the DECISION box off-screen. Fixed: the
+   box is now a FIXED width and every content line is wrapped to it (full text
+   preserved, never truncated); padding uses visible length so color escapes
+   don't push the border.
+2. *Path/flag leak* — the rendered DECISION showed the raw
+   `continue …/talks/draft_3 --pick {id}` line, which the brief says the user
+   must NEVER see. Fixed: removed from the block entirely; replaced with
+   "To choose: tell me TL1 / TL2 / TL3." Claude translates the plain id →
+   `continue.cmd` per the SKILL.md contract.
+   (Residual: a 1-char right-border off-by-one on a few lines ending exactly at
+   the wrap boundary — em-dash/Unicode cell-width; cosmetic, deferred to
+   hardening.)
+
+## Three open decisions — CC's read (hand-back)
+
+1. **Glyph set + box styling — KEEP as prototyped.** ◆/✎/⚔ + single-rule STAGE
+   vs double-rule DECISION gave a clear, correct prominence ordering in-session
+   (DECISION unmistakably loudest, STAGE present-but-quiet, RESULT terse). The
+   double rule is worth reserving exclusively for DECISION. One caution: the
+   glyphs are multi-byte Unicode — fine in the Claude transcript, but the
+   hardened renderer's Family-F byte-identity check must store them UTF-8 and
+   the shell-side presmaker copy must emit the same bytes.
+
+2. **Auto-invoke vs confirm — PRESENT + CONFIRM, do not auto-invoke.** The
+   decision halts are exactly the high-stakes, hard-to-reverse moments
+   (throughline sets the whole deck; image-approval spends/commits). Claude
+   should collect the choice, then run `continue.cmd` — but a throughline pick
+   is consequential enough that a one-beat "resuming with TL1 — go?" is the
+   right default over silent auto-run. For `approve_reject` image the cost is
+   already spent, so confirm-then-run is fine too. Net: the SKILL.md contract
+   should say "collect the choice and resume" but NOT "auto-run without
+   acknowledgement." (Adam's call — flagged because it's a UX/safety tradeoff,
+   not a code one.)
+
+3. **Color — KEEP the `_color()` seam, structural-first.** It costs one
+   well-contained function, it's correct (off when captured, on at a bare TTY,
+   `NO_COLOR` honored), and it's a free win for anyone running a skill directly
+   in a terminal. It is never load-bearing (Phase 0 proved structural-only
+   carries the signal). So: ship structural as the contract, keep color as the
+   documented progressive enhancement. Not worth REMOVING; not worth investing
+   more than the seam.