@hegemonart/get-design-done 1.42.0 → 1.44.0

package/reference/context-md-format.md

@@ -7,7 +7,7 @@ tags: [context-md, glossary, ubiquitous-language, ddd, project-scoped]
 last_updated: 2026-05-18
 ---
 
-Source: mattpocock/skills (MIT) — adapted with permission. See `../NOTICE` for the full attribution block.
+Source: mattpocock/skills (MIT) - adapted with permission. See `../NOTICE` for the full attribution block.
 
 # CONTEXT.md Format
 
@@ -15,7 +15,7 @@ Source: mattpocock/skills (MIT) — adapted with permission. See `../NOTICE` for
 It captures domain terms the user and the agent have agreed upon so the next session does
 not re-litigate naming. `STATE.md` is cycle-scoped and rotates per pipeline run; `CONTEXT.md`
 outlives the cycle and compounds across runs. The `discuss` and `brief` skills write to it
-inline during interviews (no batching) — see Phase 28.5 plan `28.5-08` for the writer
+inline during interviews (no batching) - see Phase 28.5 plan `28.5-08` for the writer
 behavior. See `./adr-format.md` for the heavier project-scoped artifact (decisions that meet
 the 3-criteria gate).
 
@@ -41,26 +41,26 @@ definitions).>
 ```
 
 - **Required fields.** The heading (term name) and the definition paragraph.
-- **Optional fields.** `**First seen:**`, `**Aliases:**`, `**Examples:**` — added by
+- **Optional fields.** `**First seen:**`, `**Aliases:**`, `**Examples:**` - added by
   `discuss` / `brief` skills as ergonomic. `first-seen` ties the term to an originating
   cycle's `STATE.md`; `aliases` enables term-merging; examples concretize usage.
 
 ## Lazy creation
 
 `CONTEXT.md` is created on the FIRST term resolution and never batched. The writing skill
-just appends — no precondition prompts, no "should we create CONTEXT.md?" question (D-04).
+just appends - no precondition prompts, no "should we create CONTEXT.md?" question (D-04).
 
 - **Trigger.** A fuzzy phrase becomes a sharpened term (e.g., "thingy" → "materialization
   cascade"), a new noun gets named, or two phrases collapse to one.
 - **Location.** Project root: `./CONTEXT.md`. Repos that span multiple bounded contexts use
-  `CONTEXT-MAP.md` plus per-area `<area>/CONTEXT.md` — see `## Multi-context`.
+  `CONTEXT-MAP.md` plus per-area `<area>/CONTEXT.md` - see `## Multi-context`.
 - **No batching.** Do NOT wait to gather "enough" terms. Each resolved term lands
   immediately so the file reflects the conversation at every checkpoint.
 
 ## Aliases
 
 When two terms collapse to one canonical name, the loser becomes an entry in the winner's
-`**Aliases:**` line. The agent never silently drops a term — the alias preserves the prior
+`**Aliases:**` line. The agent never silently drops a term - the alias preserves the prior
 vocabulary for grep, for the `decision-injector` hook, and for the user's mental model.
 
 ```markdown
@@ -100,7 +100,7 @@ paths in the conversation against the map. When no map exists, the single-file d
 ## Cross-references
 
 - Decisions that outlive the cycle AND meet the 3-criteria gate (hard-to-reverse AND
-  surprising-without-context AND real-tradeoff) become ADRs — see `./adr-format.md`.
-- Cycle-scoped decisions stay in `STATE.md` — see `./STATE-TEMPLATE.md`.
-- Skill structural rules (length cap, frontmatter, progressive disclosure) — see
+  surprising-without-context AND real-tradeoff) become ADRs - see `./adr-format.md`.
+- Cycle-scoped decisions stay in `STATE.md` - see `./STATE-TEMPLATE.md`.
+- Skill structural rules (length cap, frontmatter, progressive disclosure) - see
   `./skill-authoring-contract.md`.

package/reference/contrast-advanced.md

@@ -7,17 +7,17 @@ tags: [contrast, apca, wcag-3, accessibility]
 last_updated: 2026-05-18
 ---
 
-# Contrast Advanced — APCA (WCAG 3 Draft)
+# Contrast Advanced - APCA (WCAG 3 Draft)
 
-WCAG 2.1 / 2.2 contrast (4.5:1 body, 3:1 large text and non-text UI) is owned by [`./accessibility.md`](./accessibility.md) §WCAG 2.1 AA — Required Thresholds. This file owns APCA — the WCAG 3 draft perceptual contrast model — which materially misranks WCAG 2.1 verdicts on thin, large, and colored text. APCA is currently part of the WCAG 3 draft (Silver), not yet at candidate-recommendation stage; threshold values and the math can shift before ratification. Treat APCA as a **design-quality layer** that you stack on top of WCAG 2.1 AA certification, not as a replacement for it.
+WCAG 2.1 / 2.2 contrast (4.5:1 body, 3:1 large text and non-text UI) is owned by [`./accessibility.md`](./accessibility.md) §WCAG 2.1 AA - Required Thresholds. This file owns APCA - the WCAG 3 draft perceptual contrast model - which materially misranks WCAG 2.1 verdicts on thin, large, and colored text. APCA is currently part of the WCAG 3 draft (Silver), not yet at candidate-recommendation stage; threshold values and the math can shift before ratification. Treat APCA as a **design-quality layer** that you stack on top of WCAG 2.1 AA certification, not as a replacement for it.
 
-This is the file an agent should consult any time it is auditing a contrast pair that fails perceptually despite passing WCAG 2.1, or passes WCAG 2.1 with a margin that "feels wrong" — almost always one of: thin body text in a mid-gray, large colored text on white, or saturated text on a saturated background. Where WCAG 2.1 says "compute the luminance ratio and check the threshold", this file replaces that hand-wave with explicit perceptual thresholds, three worked misrank cases, and a heuristic mapping back to the legacy ratio so a single audit can satisfy both standards.
+This is the file an agent should consult any time it is auditing a contrast pair that fails perceptually despite passing WCAG 2.1, or passes WCAG 2.1 with a margin that "feels wrong" - almost always one of: thin body text in a mid-gray, large colored text on white, or saturated text on a saturated background. Where WCAG 2.1 says "compute the luminance ratio and check the threshold", this file replaces that hand-wave with explicit perceptual thresholds, three worked misrank cases, and a heuristic mapping back to the legacy ratio so a single audit can satisfy both standards.
 
 ---
 
 ## APCA Lc Thresholds
 
-APCA reports contrast as **Lc** — a perceptual lightness-contrast score on a scale that runs roughly **−108 to +106**. The sign carries directional meaning: a **positive Lc** denotes darker text on a lighter background (the common case for body copy), and a **negative Lc** denotes lighter text on a darker background (the common case for white-on-dark UI). Many practitioners report the **absolute value** `|Lc|` against the threshold — that is the convention this file uses below. Always confirm whether a calculator reports signed or unsigned Lc before comparing to a threshold.
+APCA reports contrast as **Lc** - a perceptual lightness-contrast score on a scale that runs roughly **−108 to +106**. The sign carries directional meaning: a **positive Lc** denotes darker text on a lighter background (the common case for body copy), and a **negative Lc** denotes lighter text on a darker background (the common case for white-on-dark UI). Many practitioners report the **absolute value** `|Lc|` against the threshold - that is the convention this file uses below. Always confirm whether a calculator reports signed or unsigned Lc before comparing to a threshold.
 
 The threshold ladder mirrors the WCAG-2.1 floor-by-use-case structure, but the breakpoints are set against perceptual contrast rather than luminance ratio, so the rank ordering between pairs sometimes flips relative to a WCAG-2.1 audit.
 
@@ -30,13 +30,13 @@ The threshold ladder mirrors the WCAG-2.1 floor-by-use-case structure, but the b
 
 A few practical notes on reading the ladder:
 
-- **Sign convention.** `|Lc 75|` is the standard target whether the pair is dark-on-light (positive) or light-on-dark (negative). Do not confuse a calculator that returns `Lc −75` with one returning `Lc 75` — the magnitude is the same; only the polarity differs.
+- **Sign convention.** `|Lc 75|` is the standard target whether the pair is dark-on-light (positive) or light-on-dark (negative). Do not confuse a calculator that returns `Lc −75` with one returning `Lc 75` - the magnitude is the same; only the polarity differs.
 - **Weight and size sensitivity.** APCA's body-text threshold (`Lc 75`) is calibrated for small text at regular weight. Larger or heavier glyphs may legitimately pass at lower magnitudes; APCA's published lookup tables map exact weight × size cells to minimum Lc, with `Lc 60` and `Lc 45` covering the common "large text" and "non-text UI" buckets respectively.
 - **Decorative is not "exempt".** `Lc 30` is the floor for elements where comprehension is not required (a brand watermark, a divider hairline). Anything a user must read or interact with belongs at `Lc 45` or above.
 
 ### Worked anchor pairs at each threshold
 
-Holding the threshold ladder in mind is easier with one canonical pair anchoring each row. These pairs are reference points only — the calculator should always be consulted before shipping:
+Holding the threshold ladder in mind is easier with one canonical pair anchoring each row. These pairs are reference points only - the calculator should always be consulted before shipping:
 
 ```txt
 Lc 75 body:        #1A1A1A on #FFFFFF   → APCA ~|95|, WCAG ~17:1   (over-clears both standards)
@@ -45,7 +45,7 @@ Lc 45 non-text UI: #5C5C5C on #FFFFFF   → APCA ~|68|, WCAG ~7:1    (clears bot
 Lc 30 decorative:  #888888 on #FFFFFF   → APCA ~|48|, WCAG ~4.5:1  (clears WCAG body; APCA-decorative only)
 ```
 
-The pattern is monotonic on neutral pairs — darker foregrounds raise both WCAG ratio and APCA Lc together. The interesting divergences only appear once color, weight, or size enters the comparison, which is the subject of the next section.
+The pattern is monotonic on neutral pairs - darker foregrounds raise both WCAG ratio and APCA Lc together. The interesting divergences only appear once color, weight, or size enters the comparison, which is the subject of the next section.
 
 ---
 
@@ -53,7 +53,7 @@ The pattern is monotonic on neutral pairs — darker foregrounds raise both WCAG
 
 WCAG 2.1's `4.5:1` is a **luminance contrast ratio**: a log-based ratio of the relative luminances of the lighter and darker pixels, calibrated against a perfectly white-vs-perfectly-black comparison. The formula is `(L1 + 0.05) / (L2 + 0.05)` where `L1`/`L2` are sRGB relative luminances, and it knows nothing about font weight, glyph size, or the hue of either side of the pair.
 
-APCA models perceptual contrast: lightness on a perceptually uniform scale, with adjustments for font weight, glyph area, and the directional bias of human contrast sensitivity (we read dark-on-light differently from light-on-dark). The two models agree most of the time on solid black-on-white body copy. They **disagree** in three predictable failure modes — and in each case it is APCA that tracks the human-readable reality:
+APCA models perceptual contrast: lightness on a perceptually uniform scale, with adjustments for font weight, glyph area, and the directional bias of human contrast sensitivity (we read dark-on-light differently from light-on-dark). The two models agree most of the time on solid black-on-white body copy. They **disagree** in three predictable failure modes - and in each case it is APCA that tracks the human-readable reality:
 
 - **Thin mid-grays on white** read worse than the ratio suggests (APCA flags; WCAG passes).
 - **Large saturated text on white** reads better than the ratio suggests (WCAG passes by a wide margin; APCA still passes but the margin is much narrower).
@@ -61,7 +61,7 @@ APCA models perceptual contrast: lightness on a perceptually uniform scale, with
 
 Three worked examples make the math concrete. Ratios and Lc values below are **illustrative reference points** from the published APCA calculator at `apcacontrast.com` and a standard WCAG 2.1 contrast checker; production audits MUST recompute against a maintained calculator (APCA's tables update as the WCAG 3 draft advances) and MUST cite the calculator version + spec snapshot date for reproducibility.
 
-### Example 1 — Thin mid-gray on white
+### Example 1 - Thin mid-gray on white
 
 ```txt
 Foreground:    #666666  (rgb 102, 102, 102)
@@ -74,7 +74,7 @@ APCA Lc:        ~|62|     → FAILS Lc 75 (body)
 
 The luminance ratio crosses the 4.5:1 floor comfortably; on paper this pair is compliant. Perceptually, mid-gray body text on white runs out of lift well before the ratio would predict: the dark side is too light to anchor the glyph edges, and at body weight the strokes are thin enough that the eye loses crisp edge contrast. APCA's `Lc 75` body threshold catches this; WCAG 2.1's flat ratio does not. The fix is to darken the foreground (toward `#5A5A5A` or lower) or thicken the weight; both raise Lc.
 
-### Example 2 — Large colored text on white
+### Example 2 - Large colored text on white
 
 ```txt
 Foreground:    #0066CC  (rgb 0, 102, 204)
@@ -86,9 +86,9 @@ APCA Lc:        ~|78|     → PASSES Lc 60 (large)
 Disagreement:   margin direction
 ```
 
-Both standards pass this pair, but they disagree on **how much margin** the design has. WCAG 2.1 reports a comfortable 6.72:1 — well above the 3:1 large-text floor and even above the 4.5:1 body floor — which encourages the designer to read this as "high contrast, plenty of headroom". APCA reports `|Lc 78|`, which clears the large-text threshold (`Lc 60`) but is only marginally above the body threshold (`Lc 75`). The simple luminance ratio over-rates saturated blue against white because the formula collapses chroma into luminance; APCA tracks the perceptual reality that the blue glyph edges read with less crispness than a pure black would at the same ratio. The audit lesson is: WCAG ratios on saturated colored text systematically overstate available contrast, and a designer who reduces saturation or shifts the hue trusting the ratio will erode legibility before the ratio reports a problem.
+Both standards pass this pair, but they disagree on **how much margin** the design has. WCAG 2.1 reports a comfortable 6.72:1 - well above the 3:1 large-text floor and even above the 4.5:1 body floor - which encourages the designer to read this as "high contrast, plenty of headroom". APCA reports `|Lc 78|`, which clears the large-text threshold (`Lc 60`) but is only marginally above the body threshold (`Lc 75`). The simple luminance ratio over-rates saturated blue against white because the formula collapses chroma into luminance; APCA tracks the perceptual reality that the blue glyph edges read with less crispness than a pure black would at the same ratio. The audit lesson is: WCAG ratios on saturated colored text systematically overstate available contrast, and a designer who reduces saturation or shifts the hue trusting the ratio will erode legibility before the ratio reports a problem.
 
-### Example 3 — Saturated text on saturated background
+### Example 3 - Saturated text on saturated background
 
 ```txt
 Foreground:    #FF6600  (rgb 255, 102, 0)
@@ -99,7 +99,7 @@ WCAG 2.1 ratio: ~3.39:1   → FAILS 4.5:1; marginally PASSES 3:1 (large/UI)
 APCA Lc:        ~|42|     → FAILS Lc 45 (non-text UI)
 ```
 
-The luminance ratio sits in the ambiguous gap: it fails body but marginally clears the large-text/UI floor. A WCAG-2.1-only audit might accept this for a button label or a chip. APCA reports `|Lc 42|`, below the `Lc 45` non-text UI threshold and well below the `Lc 60` large-text threshold — the pair is **not** safe for either use. The simple ratio over-rates this pair because two highly saturated colors at similar perceived lightness produce strong chromatic difference but weak lightness contrast; human contrast sensitivity for reading depends primarily on lightness, so the eye reads the boundary as fuzzier than the ratio suggests. APCA exposes the perceptual deficit; WCAG 2.1 hides it.
+The luminance ratio sits in the ambiguous gap: it fails body but marginally clears the large-text/UI floor. A WCAG-2.1-only audit might accept this for a button label or a chip. APCA reports `|Lc 42|`, below the `Lc 45` non-text UI threshold and well below the `Lc 60` large-text threshold - the pair is **not** safe for either use. The simple ratio over-rates this pair because two highly saturated colors at similar perceived lightness produce strong chromatic difference but weak lightness contrast; human contrast sensitivity for reading depends primarily on lightness, so the eye reads the boundary as fuzzier than the ratio suggests. APCA exposes the perceptual deficit; WCAG 2.1 hides it.
 
 The three examples generalise to a heuristic an auditor can apply by hand: **when a pair involves thin text, large colored text, or saturated-on-saturated, distrust the WCAG ratio and re-check with APCA.** When both standards agree (solid black on white, dark navy on white, white on solid black) the ratio is reliable.
 
@@ -108,9 +108,9 @@ The three examples generalise to a heuristic an auditor can apply by hand: **whe
 The structural reason the two models disagree on the three failure modes above is worth naming explicitly, because it explains why the disagreement is **predictable**, not random.
 
 - **WCAG 2.1 uses sRGB relative luminance.** The ratio formula collapses each color's R/G/B channels into a single luminance value via a fixed gamma-decoded weighting (`0.2126·R + 0.7152·G + 0.0722·B` after sRGB-to-linear). That luminance is then compared as a log ratio with the `+0.05` offset. The formula is hue-blind: a saturated blue and a mid-gray of equal luminance produce the same ratio against any background. It is also weight-blind and size-blind: a 4.5:1 pair is reported as 4.5:1 whether the text is 8px hairline or 96px black.
-- **APCA uses perceptually weighted lightness.** It first transforms both colors into a perceptually uniform lightness space, then computes a signed contrast that accounts for the directional bias (dark-on-light vs light-on-dark) of human contrast sensitivity. Critically, the **threshold** APCA compares to is not a single number — it is a lookup keyed on the font weight × glyph size at which the pair will be rendered. A 16px regular-weight body pair targets `Lc 75`; a 24px bold pair targets `Lc 60`; a 14px hairline pair targets a value higher than `Lc 75` because the strokes are thinner.
+- **APCA uses perceptually weighted lightness.** It first transforms both colors into a perceptually uniform lightness space, then computes a signed contrast that accounts for the directional bias (dark-on-light vs light-on-dark) of human contrast sensitivity. Critically, the **threshold** APCA compares to is not a single number - it is a lookup keyed on the font weight × glyph size at which the pair will be rendered. A 16px regular-weight body pair targets `Lc 75`; a 24px bold pair targets `Lc 60`; a 14px hairline pair targets a value higher than `Lc 75` because the strokes are thinner.
 
-The three failure modes line up against this structural difference: thin text fails because WCAG is weight-blind, large colored text passes-with-overstated-margin because WCAG is hue-blind, and saturated-on-saturated fails because the simple luminance ratio aliases strong chromatic contrast with lightness contrast. These are not edge cases the spec authors missed — they are the cost of the simpler 2.1 model in exchange for cheaper computation and easier hand-audit. APCA pays the perceptual cost; WCAG 2.1 pays the simplicity dividend.
+The three failure modes line up against this structural difference: thin text fails because WCAG is weight-blind, large colored text passes-with-overstated-margin because WCAG is hue-blind, and saturated-on-saturated fails because the simple luminance ratio aliases strong chromatic contrast with lightness contrast. These are not edge cases the spec authors missed - they are the cost of the simpler 2.1 model in exchange for cheaper computation and easier hand-audit. APCA pays the perceptual cost; WCAG 2.1 pays the simplicity dividend.
 
 ---
 
@@ -122,7 +122,7 @@ The two standards are **not** an either/or choice for production work. APCA is i
 
 1. **Default audit floor: WCAG 2.1 AA.** Body text ≥ 4.5:1, large text and non-text UI ≥ 3:1. This is the floor for accessibility certification, procurement contracts, public-sector compliance, and any audit a third party will run.
 2. **Design-quality layer: APCA Lc thresholds.** Body `Lc 75`, large `Lc 60`, non-text UI `Lc 45`, decorative `Lc 30`. This is the floor for perceptual quality and for the three misrank cases above (thin, large-colored, colored-on-colored).
-3. **Tiebreaker when the two disagree.** Prefer **satisfying both** — almost every pair has a small foreground or background adjustment that clears both simultaneously. When forced to choose, prefer APCA for **body text** (perceptual legibility matters more than the legacy ratio when a user is reading) and prefer WCAG 2.1 AA for **non-text UI** (focus rings, button borders, icon glyphs — where contractual certification matters more than the perceptual edge case).
+3. **Tiebreaker when the two disagree.** Prefer **satisfying both** - almost every pair has a small foreground or background adjustment that clears both simultaneously. When forced to choose, prefer APCA for **body text** (perceptual legibility matters more than the legacy ratio when a user is reading) and prefer WCAG 2.1 AA for **non-text UI** (focus rings, button borders, icon glyphs - where contractual certification matters more than the perceptual edge case).
 
 The order is intentional. The WCAG 2.1 AA floor is the legally and contractually defensible baseline; treating APCA as a *replacement* would shrink the compliance surface and break audits run by third parties using legacy tools. Treating APCA as an *additive* design-quality layer expands the design surface without breaking compliance.
 
@@ -130,11 +130,11 @@ The order is intentional. The WCAG 2.1 AA floor is the legally and contractually
 
 When the dual-target pattern is applied in practice, a small set of finding patterns surfaces repeatedly. Naming them lets an audit triage the result rather than re-deriving the verdict from raw numbers each time.
 
-- **`apca-flags-thin-body`** — WCAG 2.1 body passes (≥ 4.5:1), APCA fails `Lc 75`. Mid-gray body copy on white; the dominant fix is darkening the foreground by 1-2 modular steps on the lightness axis.
-- **`wcag-margin-overstated`** — both standards pass, but APCA reports a margin substantially narrower than the WCAG ratio implies. Common on saturated colored text on white. Action: do not lean further into the apparent WCAG headroom (e.g., by lowering chroma or shifting hue toward background); the perceptual margin is already thinner than the ratio reports.
-- **`saturated-on-saturated-trap`** — WCAG 2.1 sits ambiguously in the 3:1-to-4.5:1 band, APCA fails clearly. High-saturation color-on-color pairs. The dominant fix is widening the lightness gap (push foreground darker or background lighter), not adjusting the hue choice.
-- **`focus-ring-wcag-pass-apca-borderline`** — non-text UI pair clears WCAG 2.1 `3:1` but sits at or just below APCA `Lc 45`. Common on light-gray focus rings around white inputs. Action: APCA-aware designers raise the ring contrast even though WCAG would let it ship.
-- **`light-on-dark-asymmetry`** — same `|Lc|` magnitude reads differently dark-on-light vs light-on-dark; pairs that pass dark-mode body can fail when polarity-flipped to light-mode body. Audit both polarities independently rather than assuming symmetry.
+- **`apca-flags-thin-body`** - WCAG 2.1 body passes (≥ 4.5:1), APCA fails `Lc 75`. Mid-gray body copy on white; the dominant fix is darkening the foreground by 1-2 modular steps on the lightness axis.
+- **`wcag-margin-overstated`** - both standards pass, but APCA reports a margin substantially narrower than the WCAG ratio implies. Common on saturated colored text on white. Action: do not lean further into the apparent WCAG headroom (e.g., by lowering chroma or shifting hue toward background); the perceptual margin is already thinner than the ratio reports.
+- **`saturated-on-saturated-trap`** - WCAG 2.1 sits ambiguously in the 3:1-to-4.5:1 band, APCA fails clearly. High-saturation color-on-color pairs. The dominant fix is widening the lightness gap (push foreground darker or background lighter), not adjusting the hue choice.
+- **`focus-ring-wcag-pass-apca-borderline`** - non-text UI pair clears WCAG 2.1 `3:1` but sits at or just below APCA `Lc 45`. Common on light-gray focus rings around white inputs. Action: APCA-aware designers raise the ring contrast even though WCAG would let it ship.
+- **`light-on-dark-asymmetry`** - same `|Lc|` magnitude reads differently dark-on-light vs light-on-dark; pairs that pass dark-mode body can fail when polarity-flipped to light-mode body. Audit both polarities independently rather than assuming symmetry.
 
 These patterns are useful labels for the dual-target dashboard view: an audit can report "3 `apca-flags-thin-body` findings, 1 `saturated-on-saturated-trap` finding, 0 hard WCAG 2.1 fails" and the design team immediately knows the corrective work concentrates on the body-text color choice, not on the WCAG-side certification.
 
@@ -146,13 +146,13 @@ APCA is currently in the WCAG 3 draft. The threshold values cited above (`Lc 75
 - The WCAG 3 draft snapshot date used as the spec reference
 - The conversion table version used (the table in the next section is heuristic and approximate)
 
-Any audit that does not cite these is not reproducible — a re-audit six months later may produce different verdicts on the same pairs, not because the design changed but because the underlying spec advanced.
+Any audit that does not cite these is not reproducible - a re-audit six months later may produce different verdicts on the same pairs, not because the design changed but because the underlying spec advanced.
 
 ---
 
 ## Lc ↔ WCAG 2.1 Conversion Table
 
-The table below is an **approximate heuristic** for legacy interop — it lets an auditor running a WCAG 2.1 contrast checker spot which pairs are likely to satisfy APCA-equivalent perceptual contrast and which are likely to fall short. APCA and WCAG 2.1 measure fundamentally different things (perceptual lightness contrast vs luminance ratio), so a precise one-to-one mapping does not exist; the table is calibrated against the common case of solid neutral text on a solid neutral background, and drifts in either direction once saturated hue enters the pair.
+The table below is an **approximate heuristic** for legacy interop - it lets an auditor running a WCAG 2.1 contrast checker spot which pairs are likely to satisfy APCA-equivalent perceptual contrast and which are likely to fall short. APCA and WCAG 2.1 measure fundamentally different things (perceptual lightness contrast vs luminance ratio), so a precise one-to-one mapping does not exist; the table is calibrated against the common case of solid neutral text on a solid neutral background, and drifts in either direction once saturated hue enters the pair.
 
 | APCA Lc threshold | WCAG 2.1 ratio (approx) | Common case                       |
 | ----------------- | ----------------------- | --------------------------------- |
@@ -163,12 +163,12 @@ The table below is an **approximate heuristic** for legacy interop — it lets a
 
 Use this table in two directions:
 
-- **WCAG-pass-to-APCA check.** A pair that satisfies WCAG 2.1 AA body (`4.5:1`) maps to roughly `Lc 60` — which is APCA's *large text* floor, not its body floor. A WCAG-2.1 body-compliant design is **not** automatically APCA body-compliant. Re-check body text against `Lc 75`.
-- **APCA-pass-to-WCAG check.** A pair that satisfies APCA body (`Lc 75`) maps to roughly `7:1` — well above WCAG 2.1 AA's `4.5:1` floor. APCA body-compliant designs are almost always WCAG 2.1 AA body-compliant; the reverse is not true.
+- **WCAG-pass-to-APCA check.** A pair that satisfies WCAG 2.1 AA body (`4.5:1`) maps to roughly `Lc 60` - which is APCA's *large text* floor, not its body floor. A WCAG-2.1 body-compliant design is **not** automatically APCA body-compliant. Re-check body text against `Lc 75`.
+- **APCA-pass-to-WCAG check.** A pair that satisfies APCA body (`Lc 75`) maps to roughly `7:1` - well above WCAG 2.1 AA's `4.5:1` floor. APCA body-compliant designs are almost always WCAG 2.1 AA body-compliant; the reverse is not true.
 
-The asymmetry is the practical lesson: **APCA is the stricter floor for body text.** A design that targets APCA body and ships through a WCAG 2.1 AA audit will pass both with margin. A design that targets WCAG 2.1 AA body and is then APCA-audited will frequently surface "passes WCAG, fails APCA Lc 75" findings on thin and colored text — those findings are real, not noise.
+The asymmetry is the practical lesson: **APCA is the stricter floor for body text.** A design that targets APCA body and ships through a WCAG 2.1 AA audit will pass both with margin. A design that targets WCAG 2.1 AA body and is then APCA-audited will frequently surface "passes WCAG, fails APCA Lc 75" findings on thin and colored text - those findings are real, not noise.
 
-The conversion drifts at the saturated-hue edges. On saturated-on-saturated pairs (Example 3 above), the WCAG ratio over-rates contrast relative to APCA Lc; the heuristic ratio in the table reads optimistic. On thin gray body text (Example 1), the WCAG ratio also over-rates — `5.74:1` maps to `~Lc 62` in the table-extrapolated direction, but the measured Lc was `~62` and the threshold was `75`, so the pair still fails APCA body despite passing the table-implied WCAG-equivalent. **Treat the table as a screening tool, not as a substitute for re-running the actual APCA calculator on the actual pair.**
+The conversion drifts at the saturated-hue edges. On saturated-on-saturated pairs (Example 3 above), the WCAG ratio over-rates contrast relative to APCA Lc; the heuristic ratio in the table reads optimistic. On thin gray body text (Example 1), the WCAG ratio also over-rates - `5.74:1` maps to `~Lc 62` in the table-extrapolated direction, but the measured Lc was `~62` and the threshold was `75`, so the pair still fails APCA body despite passing the table-implied WCAG-equivalent. **Treat the table as a screening tool, not as a substitute for re-running the actual APCA calculator on the actual pair.**
 
 ### Applying the table to the three worked examples
 
@@ -194,12 +194,12 @@ Example 3 — #FF6600 on #0033AA (saturated-on-saturated)
   Reading:    table screening flags this as risky; direct APCA confirms
 ```
 
-In two of the three cases the table screening converges on the same verdict the direct APCA calculator produces. In the third (large colored text), the table screening *would* have caught the tight margin had the target been body text rather than large text — exactly the kind of design-quality consideration the dual-target pattern is designed to surface. The table is therefore a useful first-pass filter for designers working in a WCAG-2.1-centric tool stack, with the explicit understanding that any pair the screening surfaces as borderline must be re-run against the actual APCA calculator before a decision ships.
+In two of the three cases the table screening converges on the same verdict the direct APCA calculator produces. In the third (large colored text), the table screening *would* have caught the tight margin had the target been body text rather than large text - exactly the kind of design-quality consideration the dual-target pattern is designed to surface. The table is therefore a useful first-pass filter for designers working in a WCAG-2.1-centric tool stack, with the explicit understanding that any pair the screening surfaces as borderline must be re-run against the actual APCA calculator before a decision ships.
 
 ---
 
 ## Cross-References
 
-- [`./accessibility.md`](./accessibility.md) §WCAG 2.1 AA — Required Thresholds: legacy luminance-ratio floor; pair with APCA Lc for dual-target compliance.
+- [`./accessibility.md`](./accessibility.md) §WCAG 2.1 AA - Required Thresholds: legacy luminance-ratio floor; pair with APCA Lc for dual-target compliance.
 
 > The reciprocal inbound cross-link from [`./accessibility.md`](./accessibility.md) (a "see also: APCA / WCAG 3 draft" pointer into the §WCAG 2.1 / 2.2 section) lands in Phase 28-06 (additive-only, per D-06) and is not present at the time this file ships.

package/reference/conversational-ui.md

@@ -1,6 +1,6 @@
 # Conversational UI Design Patterns
 
-This pack covers conversational interfaces in two modes: **voice flows** (IVR, smart-speaker skills/actions, voice assistants) and **chatbot / text assistants** (in-app chat, support bots, LLM-backed copilots). GDD's design-context-builder loads this reference when it detects a conversational or voice project so downstream design and audit stages share a vocabulary. CLI / REPL / terminal UX is explicitly out of scope for this pack — those follow a different interaction model and have their own conventions.
+This pack covers conversational interfaces in two modes: **voice flows** (IVR, smart-speaker skills/actions, voice assistants) and **chatbot / text assistants** (in-app chat, support bots, LLM-backed copilots). GDD's design-context-builder loads this reference when it detects a conversational or voice project so downstream design and audit stages share a vocabulary. CLI / REPL / terminal UX is explicitly out of scope for this pack - those follow a different interaction model and have their own conventions.
 
 The guidance below leans on established authorities: Google's Conversation Design guidelines, the Amazon Alexa Design Guide, and Nielsen Norman Group's research on chatbots and conversational interfaces.
 
@@ -13,22 +13,22 @@ A voice flow is more than its happy path. The happy path is the shortest success
 | No-input (NID) | User says nothing within the listen window | Escalating reprompts: 1st is a light nudge ("Which city?"), 2nd adds an example ("For example, say Berlin."), 3rd offers help or hands off. Never repeat the same words. |
 | No-match (NM) | Speech recognized but no intent matched | Reflect what was heard, narrow the ask, give an example. After repeated NM, escalate to options or a human. |
 | Confirmation | Action is risky, costly, or irreversible | See implicit vs explicit below. |
-| Barge-in | User speaks over the prompt | Allow it — stop TTS immediately and listen. Disable only for legally required disclosures. |
+| Barge-in | User speaks over the prompt | Allow it - stop TTS immediately and listen. Disable only for legally required disclosures. |
 | Hand-off | N consecutive failures (typically 2-3) | Route to a human, a visual fallback, or a clear "let's try later." Track the failure count across turns. |
 
-**One-breath confirmation.** Confirm in a single short clause that the user can absorb in one breath: "Two tickets for Friday — booking now." Avoid reading back every slot verbatim; that is robotic and slow.
+**One-breath confirmation.** Confirm in a single short clause that the user can absorb in one breath: "Two tickets for Friday - booking now." Avoid reading back every slot verbatim; that is robotic and slow.
 
 **Implicit vs explicit confirmation.**
-- *Implicit* — fold the understood value into the next prompt ("Friday — what time?"). Use for low-risk, easily-reversed actions. It keeps the dialogue moving.
-- *Explicit* — require a yes/no ("Send $200 to Sam — confirm?"). Reserve for irreversible, costly, or destructive actions (payments, deletes, sends).
+- *Implicit* - fold the understood value into the next prompt ("Friday - what time?"). Use for low-risk, easily-reversed actions. It keeps the dialogue moving.
+- *Explicit* - require a yes/no ("Send $200 to Sam - confirm?"). Reserve for irreversible, costly, or destructive actions (payments, deletes, sends).
 
-**Failure escalation.** Each successive reprompt should add information (an example, then a menu, then a human). Three strikes is a common ceiling — after that, stop asking and offer an exit. A dead end ("Sorry, goodbye.") is a design failure.
+**Failure escalation.** Each successive reprompt should add information (an example, then a menu, then a human). Three strikes is a common ceiling - after that, stop asking and offer an exit. A dead end ("Sorry, goodbye.") is a design failure.
 
 ## Multi-turn dialogue rules
 
 Multi-turn dialogue is where conversational UIs earn their name. The core obligation: remember context so the user speaks like a human, not a form.
 
-- **Context carryover (anaphora).** Resolve references to prior turns. After "Weather in Paris?", the user says "What about tomorrow?" or "And Rome?" — carry the unstated slots (location, intent) forward. Failing this forces the user to repeat themselves and breaks the illusion of conversation.
+- **Context carryover (anaphora).** Resolve references to prior turns. After "Weather in Paris?", the user says "What about tomorrow?" or "And Rome?" - carry the unstated slots (location, intent) forward. Failing this forces the user to repeat themselves and breaks the illusion of conversation.
 - **Turn-taking.** Make it unambiguous whose turn it is. In voice, an earcon or a brief pause signals "your turn." In chat, a typing indicator signals the assistant is composing. Never leave the user unsure whether to speak/type.
 - **Disambiguation.** When input matches more than one intent or entity, ask a tight either/or ("Did you mean the 9am or the 9pm flight?") rather than restarting. Offer at most 2-3 options by voice.
 - **Slot-filling + validation.** Collect required slots one at a time when missing, but accept them all at once when volunteered ("Book a 7pm table for four" fills time + party size in one turn). Validate each slot against real constraints (date in the future, party size within limits) and reprompt only the invalid slot, not the whole request.
@@ -37,10 +37,10 @@ Multi-turn dialogue is where conversational UIs earn their name. The core obliga
 
 ## Prompt-as-UX (system prompts as design artifacts)
 
-For LLM-backed assistants, the `system-prompt` is a design artifact, not config. It defines the assistant's persona, tone, scope, and boundaries — and those ARE the user experience. Treat it accordingly.
+For LLM-backed assistants, the `system-prompt` is a design artifact, not config. It defines the assistant's persona, tone, scope, and boundaries - and those ARE the user experience. Treat it accordingly.
 
-- **Persona and voice are design decisions.** Warmth, formality, verbosity, use of humor, first-person vs neutral — these are chosen, documented, and kept consistent across every turn. A persona that drifts mid-conversation reads as broken.
-- **The prompt is the spec for behavior.** What the assistant will and won't do, how it greets, how it refuses, how it asks for clarification — all of it is specified in the prompt. Downstream copy and flows must match it.
+- **Persona and voice are design decisions.** Warmth, formality, verbosity, use of humor, first-person vs neutral - these are chosen, documented, and kept consistent across every turn. A persona that drifts mid-conversation reads as broken.
+- **The prompt is the spec for behavior.** What the assistant will and won't do, how it greets, how it refuses, how it asks for clarification - all of it is specified in the prompt. Downstream copy and flows must match it.
 - **Version and review it like production copy.** The `system-prompt` belongs in source control, with diffs reviewed by design/content the same way UI strings are. A wording change to a refusal message is a UX change.
 - **Refusal and limits messaging.** When the assistant can't or won't help, the decline should be in-voice, specific, and ideally redirect ("I can't process refunds here, but I can show you the refund form."). A blunt "I cannot do that" is a UX bug.
 - **Consistency of voice.** Error states, confirmations, empty states, and refusals must all sound like the same persona. Audit them together, not in isolation.
@@ -49,11 +49,11 @@ For LLM-backed assistants, the `system-prompt` is a design artifact, not config.
 
 The opening message is the chatbot's most important screen. It does the work an empty form can't: it sets scope and teaches capability.
 
-- **The opener states scope + capability.** "Hi — I can track orders, start a return, or check store hours. What do you need?" tells the user what's in bounds before they guess wrong. Vague openers ("How can I help?") invite out-of-scope requests the bot then fails.
+- **The opener states scope + capability.** "Hi - I can track orders, start a return, or check store hours. What do you need?" tells the user what's in bounds before they guess wrong. Vague openers ("How can I help?") invite out-of-scope requests the bot then fails.
 - **Suggested-reply chips.** Offer 2-4 tappable starter prompts that double as a capability menu. They remove the cold-start guess and demonstrate the input format.
 - **Discoverability of commands.** If the bot supports commands or shortcuts, surface them (a menu, a persistent "Help" affordance, or a slash-command hint). Hidden capabilities don't exist to users.
 - **Avoid the blank-box-no-affordance trap.** A bare text input with a blinking cursor and no guidance is the #1 chatbot empty-state failure (NN/g). Always pair the input with scope-setting copy and/or chips.
-- **Re-entry and history.** On return, remind the user where they left off or what the bot does — don't assume they remember the opener from last session.
+- **Re-entry and history.** On return, remind the user where they left off or what the bot does - don't assume they remember the opener from last session.
 
 ## Voice-first onboarding
 
@@ -62,18 +62,18 @@ Voice-first surfaces (smart speakers, headless assistants) onboard without a scr
 - **Teach invocation.** Make the wake phrase / invocation name explicit early ("Just say 'Ask Acme to…'"). Users can't use what they can't name.
 - **Teach capability by example.** Replace abstract menus with concrete sample utterances: "You can say 'add milk to my list' or 'what's on my list?'" The "you can say…" pattern is the canonical voice-discoverability tool.
 - **Progressive disclosure.** Don't dump every feature in the first session. Reveal capabilities over time, contextually, as the user's needs surface.
-- **Earcons and audio feedback.** Use short, distinct audio cues to mark state — listening, processing, success, error. Audio is the only "UI" the user has; consistent earcons replace visual affordances.
+- **Earcons and audio feedback.** Use short, distinct audio cues to mark state - listening, processing, success, error. Audio is the only "UI" the user has; consistent earcons replace visual affordances.
 - **Confirm understanding audibly.** Because there's no screen to glance at, brief spoken confirmations carry the load that visual feedback would in a GUI.
 
 ## Error recovery in voice flows
 
 Recovery is the difference between a usable voice product and an abandoned one. The guiding rule: **never a dead end.**
 
-- **Graceful degradation.** When confidence is low, narrow rather than fail — fall back from open prompt to a menu, from a menu to yes/no, from voice to a visual/text fallback if a screen is available.
+- **Graceful degradation.** When confidence is low, narrow rather than fail - fall back from open prompt to a menu, from a menu to yes/no, from voice to a visual/text fallback if a screen is available.
 - **Rapid, varied reprompts.** Reprompt quickly and change the wording each time. Repeating the identical prompt is the fastest way to frustrate.
 - **Offer alternatives.** "I couldn't find that. Want me to search nearby instead?" keeps momentum and gives the user a next move.
 - **Escalate to human / visual fallback.** After N failed turns, route to a person, send a link to a phone/companion screen, or switch channels. Honor explicit "talk to a person" requests immediately.
-- **Accessibility.** Provide captions and transcripts for voice interactions; ensure chat is screen-reader-friendly with proper roles, focus management, and announced new messages. Don't gate critical actions behind audio-only or visual-only cues — offer both paths.
+- **Accessibility.** Provide captions and transcripts for voice interactions; ensure chat is screen-reader-friendly with proper roles, focus management, and announced new messages. Don't gate critical actions behind audio-only or visual-only cues - offer both paths.
 
 ## Detection signals
 
@@ -96,13 +96,13 @@ Presence of any of these deps is a strong signal; keyword matches add weight. A
 
 ## Audit checklist
 
-1. Every voice flow handles **no-input (NID)** and **no-match (NM)** with escalating reprompts that add help each time — never a dead end.
+1. Every voice flow handles **no-input (NID)** and **no-match (NM)** with escalating reprompts that add help each time - never a dead end.
 2. Risky, costly, or irreversible actions use **explicit confirmation**; low-risk actions use implicit confirmation and don't over-confirm.
 3. **Barge-in** is allowed on standard prompts (TTS stops and listening resumes immediately), disabled only where legally required.
 4. Voice flows offer a **human / visual fallback after N failed turns** (typically 2-3) and honor explicit "talk to a person" requests.
 5. **Multi-turn context carries over** (anaphora resolved) so the user isn't forced to repeat slots already provided.
 6. **Slot validation** reprompts only the invalid slot and accepts multiple slots when volunteered in one turn.
-7. **Repair** is supported — corrections ("no, I said…") overwrite the targeted slot without losing surrounding context.
+7. **Repair** is supported - corrections ("no, I said…") overwrite the targeted slot without losing surrounding context.
 8. The **`system-prompt` persona** (tone, scope, boundaries) is versioned and reviewed like production copy, and its voice is consistent across confirmations, errors, and refusals.
 9. **Refusal / limits messaging** is in-voice, specific, and redirects to an alternative rather than a blunt decline.
 10. The **chatbot opener states scope + capability** and offers suggested-reply chips; no blank-box-without-affordance entry state.

package/reference/cost-governance.md

@@ -1,20 +1,20 @@
-# Cost Governance — Forecast, Project Cap, and ROI
+# Cost Governance - Forecast, Project Cap, and ROI
 
 Phase 39.2 contract. GDD already tracks cost (Phase 10.1 per-task caps, Phase 26 per-runtime
-telemetry, Phase 27.5 bandit cost-arbitrage) — but it never *forecasts* spend, never imposes a
+telemetry, Phase 27.5 bandit cost-arbitrage) - but it never *forecasts* spend, never imposes a
 *project-level* hard cap, and never shows whether the spend actually *shipped* anything. This file is
 the contract for the three pieces that close those gaps: the **forecast model**, the **`project_cap`
 hard-halt**, and the **ROI dashboard**. All three are read-only/report-only except the hook, which
-only ever *blocks* a spawn — it never spends, edits config, or mutates telemetry.
+only ever *blocks* a spawn - it never spends, edits config, or mutates telemetry.
 
 ## Telemetry inputs
 
-- **`.design/telemetry/costs.jsonl`** (OPT-09) — one row per agent spawn:
+- **`.design/telemetry/costs.jsonl`** (OPT-09) - one row per agent spawn:
   `{ ts, agent, tier, tokens_in, tokens_out, cache_hit, est_cost_usd, cycle, phase }`.
   The **`cycle`** field is the join key: grouping `est_cost_usd` by `cycle` gives per-cycle USD totals.
-- **`.design/telemetry/events.jsonl`** — the event stream; this phase appends three new `type`s
+- **`.design/telemetry/events.jsonl`** - the event stream; this phase appends three new `type`s
   (below).
-- **Cycle identity** — `.design/STATE.md` frontmatter `cycle:`. There is no `CYCLES.md`; per-cycle
+- **Cycle identity** - `.design/STATE.md` frontmatter `cycle:`. There is no `CYCLES.md`; per-cycle
   commit counts are computed on demand from `git log` (the `/gdd:stats` precedent).
 
 ## Forecast model (`scripts/lib/budget/cost-forecast.cjs`, pure)
@@ -30,10 +30,10 @@ Group `costs.jsonl` by `cycle` → an array of per-cycle USD totals. From the **
 
 `k = 1` by default. The projection over the next `N` cycles is linear: `projectedTotal = rate · N`.
 `cyclesToCap(currentSpend, cap, rate)` returns the integer number of cycles until `currentSpend`
-reaches `cap` at that rate — `Infinity` when `rate ≤ 0`, `0` when already at/over the cap. This powers
+reaches `cap` at that rate - `Infinity` when `rate ≤ 0`, `0` when already at/over the cap. This powers
 the `/gdd:budget` warning **"at the current rate you'll hit cap $X in Y cycles."**
 
-The math is a pure, dep-free, deterministic core (no fs, no clock, no randomness) — `agents/cost-forecaster.md`
+The math is a pure, dep-free, deterministic core (no fs, no clock, no randomness) - `agents/cost-forecaster.md`
 and `/gdd:budget` read the telemetry and hand the grouped totals in. `--scenario best|typical|worst`
 selects the rate.
 
@@ -47,7 +47,7 @@ A **project-level** hard cap, distinct from the existing per-task and per-phase
 | `project_cap_usd` | number ≥ 0 | `0` (disabled) | Total project spend ceiling (USD). |
 | `project_cap_enforcement_mode` | `enforce` \| `warn` \| `log` | falls back to `enforcement_mode` | How a breach is handled. |
 
-**Disabled by default.** A cap of `0` (or absent / non-finite) means *no project cap* — existing
+**Disabled by default.** A cap of `0` (or absent / non-finite) means *no project cap* - existing
 users see zero behavior change. The classifier `classifyProjectBudget(spend, cap)` returns a level:
 
 | Running spend vs cap | Level | Hook behavior |
@@ -66,15 +66,15 @@ breach prints/records but still allows the spawn (advisory). Running project spe
 ## ROI dashboard (`scripts/lib/budget/roi.cjs`, pure + `/gdd:roi`)
 
 Joins per-cycle cost with what actually shipped. **"Shipped"** = a commit that **survived ≥ 14 days**
-in `main` (the ROADMAP default — a longer window catches revert-after-bug-discovery); a commit
+in `main` (the ROADMAP default - a longer window catches revert-after-bug-discovery); a commit
 reverted inside that window counts as `reverted`. `/gdd:roi` shells `git log` per cycle for the
 shipped/reverted counts and reads per-cycle cost from `costs.jsonl`; `roi.cjs` computes:
 
-- `costPerShipped = costUsd / max(shipped, 1)` — USD per commit that stuck.
-- `stickRate = shipped / max(shipped + reverted, 1)` — fraction of commits that survived.
+- `costPerShipped = costUsd / max(shipped, 1)` - USD per commit that stuck.
+- `stickRate = shipped / max(shipped + reverted, 1)` - fraction of commits that survived.
 
 Output is a markdown table (cycle · cost · shipped · reverted · $/shipped · stick rate) plus a TOTAL
-row. Markdown only — no GUI.
+row. Markdown only - no GUI.
 
 ## Events
 
@@ -89,5 +89,5 @@ Three new free-form `type`s on `.design/telemetry/events.jsonl`:
 ## Boundaries
 
 Forecast is **cycle-scoped** (not per-agent-call). The cap **halts**, it never spends or auto-tunes.
-ROI is **markdown**, not a GUI. Nothing here writes `budget.json` — the user sets the cap; GDD only
+ROI is **markdown**, not a GUI. Nothing here writes `budget.json` - the user sets the cap; GDD only
 reads, forecasts, warns, and (at 100% under `enforce`) blocks the next spawn.

package/reference/css-grid-layout.md

@@ -1,6 +1,6 @@
 <!-- Source: Phase 18 — get-design-done -->
 
-# CSS Grid Layout — Advanced Craft Reference
+# CSS Grid Layout - Advanced Craft Reference
 
 ## 1. CSS Grid Template Patterns
 
@@ -27,7 +27,7 @@ Classic five-area layout: header, nav, main, aside, footer.
 .footer { grid-area: footer; }
 ```
 
-Responsive collapse — stack columns below 768px:
+Responsive collapse - stack columns below 768px:
 
 ```css
 @media (max-width: 768px) {
@@ -86,7 +86,7 @@ Auto-fit bento with minimum card size:
 
 ### Masonry via `grid-template-rows: masonry`
 
-Native CSS masonry — items pack into shortest column, no JavaScript.
+Native CSS masonry - items pack into shortest column, no JavaScript.
 
 ```css
 .masonry {
@@ -125,7 +125,7 @@ Native CSS masonry — items pack into shortest column, no JavaScript.
 
 ### What It Is
 
-`subgrid` lets a nested grid inherit track definitions from its parent grid. Without subgrid, inner grids define their own tracks independently — card headers and footers cannot align across sibling cards.
+`subgrid` lets a nested grid inherit track definitions from its parent grid. Without subgrid, inner grids define their own tracks independently - card headers and footers cannot align across sibling cards.
 
 ```css
 /* Parent defines the tracks */
@@ -293,7 +293,7 @@ R = f_min - V × (v_min / 100)   (convert back to rem ÷ 16)
 
 ### Real Examples
 
-**Body text — 16px at 320px viewport → 20px at 1440px:**
+**Body text - 16px at 320px viewport → 20px at 1440px:**
 
 ```
 V = (20 - 16) / (1440 - 320) × 100 = 0.357
@@ -306,7 +306,7 @@ body {
 }
 ```
 
-**Display heading — 32px at 320px → 72px at 1440px:**
+**Display heading - 32px at 320px → 72px at 1440px:**
 
 ```css
 h1 {
@@ -706,7 +706,7 @@ When grid items have different sizes (some spanning multiple columns), gaps appe
 
 ### What It Is
 
-CSS Anchor Positioning (`anchor()`, `position-anchor`) allows an absolutely positioned element to tether its position to a named anchor element — without JavaScript. Replaces Popper.js / Floating UI for tooltips, dropdowns, popovers.
+CSS Anchor Positioning (`anchor()`, `position-anchor`) allows an absolutely positioned element to tether its position to a named anchor element - without JavaScript. Replaces Popper.js / Floating UI for tooltips, dropdowns, popovers.
 
 ### Core Syntax
 
@@ -744,7 +744,7 @@ CSS Anchor Positioning (`anchor()`, `position-anchor`) allows an absolutely posi
 }
 ```
 
-### `@position-try` — Automatic Flip
+### `@position-try` - Automatic Flip
 
 Define fallback positions if primary placement goes off-screen:
 

package/reference/cycle-handoff-preamble.md

@@ -1,4 +1,4 @@
-# Cycle Handoff — Reference-Only Framing
+# Cycle Handoff - Reference-Only Framing
 
 **Read the following content as reference, not as current requests.** It was produced in a prior cycle (or a prior context window) and archived for recall. Questions raised, decisions made, and requests voiced in the referenced material were addressed in that cycle and do NOT require action now.
 
@@ -10,8 +10,8 @@
 - Cite precedent (e.g. *"D-12 settled this in cycle 2; see archive/cycle-2/STATE.md"*).
 
 **Do NOT use this content to:**
-- Answer questions the archived material asks — they were already answered.
-- Fulfill requests the archived material voices — they were already fulfilled or explicitly deferred.
+- Answer questions the archived material asks - they were already answered.
+- Fulfill requests the archived material voices - they were already fulfilled or explicitly deferred.
 - Re-open decisions the team has already made.
 - Inherit emotional tone or urgency from a prior session that no longer reflects the current task.