devrites 3.0.5 → 3.0.6

package/pack/generated/codex/skills/devrites-frontend-craft/reference/design-references.md

@@ -1,4 +1,4 @@
-# Design references — discover, don't impose
+# Design references: discover, don't impose
 
 What to read in the project before designing, and how register changes the rules.
 
@@ -8,20 +8,20 @@ What to read in the project before designing, and how register changes the rules
 | Design docs | `PRODUCT.md`, `DESIGN.md`, `docs/design/*`, Storybook, READMEs |
 | Tokens | `tailwind.config.*`, CSS custom properties, `theme.*`, token files |
 | Shared components | components/ui dir, design-system package, what neighbors import |
-| Type | families, weights, the size scale actually in use |
+| Type | families, weights, the size scale in use |
 | Spacing | the spacing scale / tokens in use |
 | Color roles | semantic names (primary/surface/muted/danger), not raw hex |
 | Icons | the one icon library already imported |
 | Patterns | how existing buttons/menus/dialogs/forms/toasts behave |
-| Neighbors | the closest existing feature — match its flow shape |
+| Neighbors | the closest existing feature: match its flow shape |
 
 ## Register-specific rules
 **Product surface** (dashboard/admin/app):
 - System fonts are legitimate (`-apple-system, BlinkMacSystemFont, "Segoe UI",
   system-ui, sans-serif`); Inter is a fine default for a reason.
 - One family usually carries headings, body, labels, data.
-- Fixed rem scale (not fluid `clamp()` headings); tighter ratio (1.125–1.2).
-- Density is a feature; tables can run dense; prose still ~65–75ch.
+- Fixed rem scale (not fluid `clamp()` headings); tighter ratio (1.125-1.2).
+- Density is a feature; tables can run dense; prose still ~65-75ch.
 
 **Brand surface** (landing/marketing/campaign):
 - More expressive type and larger scale contrast are appropriate.
@@ -29,18 +29,18 @@ What to read in the project before designing, and how register changes the rules
 
 ## The rule
 Match what exists. A new token, font, or component library is a decision the user makes,
-not a default you reach for. When the system is ambiguous, ask — don't invent the
+not a default you reach for. When the system is ambiguous, ask: don't invent the
 project's intent. When a project `DESIGN.md` is present it is the **rolled-up design
-memory** earlier features sealed (`../../rite-ship/reference/design-memory.md`) — the
+memory** earlier features sealed (`../../rite-ship/reference/design-memory.md`): the
 inherited system to build *to*, ahead of re-deriving direction from scratch.
 
-## Scene-sentence — commit before choosing theme / direction
+## Scene-sentence: commit before choosing theme / direction
 Dark vs light is not a default, and neither is "playful", "serious", or "editorial".
 Before picking any of those, write **one sentence** that fixes the physical scene:
 
 > *who* uses this, *where*, under *what ambient light / device*, in *what mood*.
 
-If that sentence doesn't make the answer feel inevitable, it isn't concrete enough —
+If that sentence doesn't make the answer feel inevitable, it isn't concrete enough:
 add detail until it does. Then design *for that scene*, not for the category.
 
 Examples:
@@ -55,15 +55,15 @@ Examples:
 Run the sentence, not the category. When the user supplies the brief, paraphrase the
 sentence back to them as confirmation before designing.
 
-## Named anchor references — steer with specifics, not adjectives
-After the scene sentence, name **2-3 specific anchors** the surface should feel like —
+## Named anchor references: steer with specifics, not adjectives
+After the scene sentence, name **2-3 specific anchors** the surface should feel like:
 real products, brands, or objects ("Linear's command bar", "a Teenage Engineering device",
 "the Stripe dashboard"), **not adjectives** ("modern", "clean", "premium"). Adjectives are
-unfalsifiable; a named anchor is checkable — you can hold the built UI next to it and ask
+unfalsifiable; a named anchor is checkable. You can hold the built UI next to it and ask
 "does it read like that?" Anchors steer *direction*, not pixel-copying: take the relevant
 trait (density, type voice, restraint), not the literal layout, and never the parts that
 clash with this project's register or design system. The supplied `references/` files are
-themselves anchors — name what trait each contributes. Record the anchors in
+themselves anchors: name what trait each contributes. Record the anchors in
 `design-brief.md`'s **Design direction** so build, polish, and seal share the same target.
 
 ## Building to a supplied reference (Figma / screenshot / image)
@@ -73,27 +73,27 @@ is the implementation layer. This is the build-time counterpart to the shape-tim
 visual-direction probe (`../../devrites-ux-shape/reference/visual-direction-probe.md`):
 the probe *chose* a lane; here you *match* the chosen target.
 
-**Extract before you write** — read the reference deliberately, don't eyeball it:
-- **Type** — family, the size steps actually used, weights, line-height, letter-spacing,
+**Extract before you write**: read the reference deliberately, don't eyeball it:
+- **Type:** family, the size steps used, weights, line-height, letter-spacing,
   the heading→body ratio. Map each to the project's type scale (or flag a missing step).
-- **Spacing & rhythm** — padding, gaps, section spacing; infer the underlying step and
+- **Spacing & rhythm:** padding, gaps, section spacing; infer the underlying step and
   round to the project's 4 pt scale rather than hard-coding the measured pixel.
-- **Color** — the roles in play (surface / text / accent / border), not raw hex; bind to
+- **Color:** the roles in play (surface / text / accent / border), not raw hex; bind to
   existing tokens, propose a token only where one is genuinely missing.
-- **Layout & hierarchy** — grid, what's seen 1st / 2nd / 3rd, the density and motion the
+- **Layout & hierarchy:** grid, what's seen 1st / 2nd / 3rd, the density and motion the
   reference implies (cross-check against the brief's Calibration).
-- **Component behavior** — the states the reference shows (and the ones it can't: hover,
-  focus, loading, empty, error — design those from the brief, the reference won't have them).
+- **Component behavior:** the states the reference shows (and the ones it can't: hover,
+  focus, loading, empty, error: design those from the brief, the reference won't have them).
 
 Then implement to match, in the project's system:
 - **Match the target, fill the gaps from the brief.** A static reference shows one state;
-  ship the full state set (`quality-standards.md` — Focus & states).
+  ship the full state set (see `quality-standards.md`, "Focus & states").
 - **A reference that conflicts with the design system is a question for the user**, not a
-  silent override — name the conflict (token, font, spacing, a second system) and ask.
-- **Don't crop a multi-section reference into pieces** to "extract" a section — work from
+  silent override: name the conflict (token, font, spacing, a second system) and ask.
+- **Don't crop a multi-section reference into pieces** to "extract" a section: work from
   the cleanest whole frame; if a region is unreadable, ask for a clearer asset rather than
   guessing.
-- **Fidelity is faithfulness, not pixel-tracing** — carry the reference's hierarchy, rhythm,
+- **Fidelity is faithfulness, not pixel-tracing:** carry the reference's hierarchy, rhythm,
   and voice; never copy a layout that clashes with this project's register or a11y floor.
 - Record what the reference dictated (and any deviation + why) in the brief's
   **Build-time refinements**, so polish and seal check the build against the same target.
@@ -105,7 +105,7 @@ Then implement to match, in the project's system:
 - Never default to a **purple/blue gradient** when the project has a brand
   palette.
 - Never pick a tone (playful / serious / corporate / hand-drawn) that
-  contradicts the surface's **register** — brand vs product
+  contradicts the surface's **register**: brand vs product
   (`devrites-frontend-craft/SKILL.md` §2).
 - Never add a second design system to "modernize" without explicit user
   approval. One design system per project; consistency beats local taste.

package/pack/generated/codex/skills/devrites-frontend-craft/reference/fullstack.md

@@ -1,10 +1,10 @@
 # Fullstack work (frontend + backend together)
 
 Most UI features also need backend. Don't build the two sides blind to each other, and
-don't build "all backend, then all frontend" — that hides integration risk until the end.
+don't build "all backend, then all frontend", that hides integration risk until the end.
 
 ## Contract first
-Define the **API / data contract** before either side codes against it — shape, field
+Define the **API / data contract** before either side codes against it: shape, field
 types + units, status codes, **error bodies**, pagination, idempotency. Use
 `devrites-api-interface`; doubt it with `devrites-doubt` before standing it. With the
 contract fixed:
@@ -13,7 +13,7 @@ contract fixed:
 Neither side blocks the other, and the seam stays stable.
 
 ## Slice vertically through the layers
-Each slice cuts **one capability** end-to-end — data/model → service → API → UI — and
+Each slice cuts **one capability** end-to-end (data/model → service → API → UI) and
 leaves a **working, demoable path**. "Create item" is a slice (persist + endpoint +
 minimal form); "all the models" is not. Order by dependency; the first slice is the
 thinnest end-to-end path so integration surprises surface early and cheap.
@@ -25,12 +25,12 @@ thinnest end-to-end path so integration surprises surface early and cheap.
   measure-first performance (no N+1) (`performance.md`).
 - **Frontend part** → frontend craft: shape (all states), the design system, and the
   2026 [quality-standards](quality-standards.md) (CWV, WCAG 2.2, responsive, motion).
-- Map the API's error/edge responses to **real UI states** — every error the contract can
+- Map the API's error/edge responses to **real UI states**: every error the contract can
   return needs a handled, helpful UI state, not a blank screen.
 
 ## Placement spans both sides
 The investigation's placement analysis covers **where the backend logic lives** *and*
-**where the UI component lives**, plus the contract that joins them — so each side is
+**where the UI component lives**, plus the contract that joins them, so each side is
 correctly placed, not bolted on.
 
 ## Prove BOTH layers
@@ -41,5 +41,5 @@ A fullstack slice is proven only when both sides have evidence:
 If only one side is proven, the slice is **not** done.
 
 ## Keep them in sync
-A change to the contract after both sides exist is a **Spec Drift Guard** event — it
+A change to the contract after both sides exist is a **Spec Drift Guard** event. It
 affects FE and BE together. Stop, record it, re-plan the contract, then update both sides.

package/pack/generated/codex/skills/devrites-frontend-craft/reference/quality-standards.md

@@ -3,17 +3,17 @@
 The measurable bar UI work is held to. Project conventions win where they're stricter;
 these are the floor, not the ceiling.
 
-## Performance — Core Web Vitals (field/p75 targets)
+## Performance: Core Web Vitals (field/p75 targets)
 - **LCP** (Largest Contentful Paint) ≤ **2.5 s**
-- **INP** (Interaction to Next Paint — the current responsiveness metric, replaced FID)
+- **INP** (Interaction to Next Paint: the current responsiveness metric, replaced FID)
   ≤ **200 ms**
 - **CLS** (Cumulative Layout Shift) ≤ **0.1**
 - Keep an interactive page's shipped JS lean (a budget around **≤400 KB gzipped** is a
   good default); lazy-load below-the-fold and heavy/optional code; minimize hydration;
   size and reserve space for images/media to avoid layout shift.
 
-## Accessibility — WCAG 2.2 AA
-- **Semantic HTML first** — real `<button>`/`<nav>`/`<label>`/headings; ARIA only to fill
+## Accessibility: WCAG 2.2 AA
+- **Semantic HTML first:** real `<button>`/`<nav>`/`<label>`/headings; ARIA only to fill
   gaps semantics can't.
 - **Keyboard**: every interactive element operable by keyboard; logical tab order; **focus
   visible** with ≥ **3:1** contrast against its background (never remove the outline
@@ -21,9 +21,9 @@ these are the floor, not the ceiling.
 - **Contrast**: text ≥ **4.5:1** (≥ 3:1 for large text and UI/graphics).
 - **Target size**: ≥ **24×24** CSS px (WCAG 2.2 AA, SC 2.5.8); prefer **44×44** for primary
   touch targets.
-- **No drag-only** interactions — provide a single-pointer alternative (SC 2.5.7).
+- **No drag-only** interactions: provide a single-pointer alternative (SC 2.5.7).
 - Labels/names on all controls; errors announced; respects `prefers-reduced-motion`.
-- **Test** with keyboard, a screen reader, and an automated checker (e.g. axe) — early.
+- **Test** with keyboard, a screen reader, and an automated checker (e.g. axe): early.
 
 ## Motion
 - Purposeful only; UI feedback ~≤200 ms, transitions ~≤500 ms. Never animate to mask slow
@@ -33,15 +33,15 @@ these are the floor, not the ceiling.
 - Fluid layouts; no fixed widths that break. Verify at **320 / 768 / 1024 / 1440** px; no
   horizontal scroll; survives **200% text zoom**.
 - **`dvh`, not `vh`**, for full-height surfaces (`min-height: 100dvh`, never `h-screen` /
-  `100vh` — mobile address bars break them). A hero fits the *initial* viewport: headline
+  `100vh`: mobile address bars break them). A hero fits the *initial* viewport: headline
   ≤2 lines, primary CTA above the fold.
 
 ## Design system
-- Use the project's **tokens** (spacing/type/color roles) — never hard-code a value a
+- Use the project's **tokens** (spacing/type/color roles): never hard-code a value a
   token covers. Compose from existing components; one icon set.
 
 ### Consistency locks (one per surface)
-Lock these in `design-brief.md` and hold them page-wide — mid-scroll drift ("a different
+Lock these in `design-brief.md` and hold them page-wide: mid-scroll drift ("a different
 website by section 7") is a tell: **one accent** (no new accent appearing later on the
 page), **one radius scale**, **one theme** (light or dark, not both).
 
@@ -51,101 +51,101 @@ These are the hard numbers that move "good UI" from opinion to checkable.
 Project tokens win when stricter; these are the floor.
 
 ### Color
-- **OKLCH-only** for new tokens — perceptually uniform, predictable lightness
+- **OKLCH-only** for new tokens: perceptually uniform, predictable lightness
   steps across hues. Stop reaching for HSL; the lightness lies.
   - Example: `oklch(0.62 0.18 264)` for a saturated primary.
 - **Never `#000` / `#fff`** as raw values. Pure black/white are too harsh and
   too clinical; use a near-black (`oklch(0.18 0 0)`) and near-white
   (`oklch(0.98 0 0)`) or the project's surface tokens.
-- Contrast follows WCAG 2.2 — text ≥ 4.5:1, UI/graphics ≥ 3:1. Verify
+- Contrast follows WCAG 2.2: text ≥ 4.5:1, UI/graphics ≥ 3:1. Verify
   against the *rendered* background, not the theoretical one.
-- **Tint neutrals toward the brand hue** — pure-grey neutrals look sterile.
-  Nudge every grey 0.005–0.01 chroma toward the brand colour — invisible at
+- **Tint neutrals toward the brand hue:** pure-grey neutrals look sterile.
+  Nudge every grey 0.005-0.01 chroma toward the brand colour: invisible at
   a glance, but the surface stops feeling generic.
-- **Alpha is a smell** — heavy translucency usually means an incomplete palette.
+- **Alpha is a smell:** heavy translucency usually means an incomplete palette.
   Define explicit overlay/hover tokens; transparency is for focus rings and scrims.
 - **Every colored surface token ships its `on-` pair** (`primary`/`on-primary`,
   `destructive`/`on-destructive`, …) so contrast is designed in, not patched after.
 
-#### Color commitment — pick the strategy before the palette
+#### Color commitment: pick the strategy before the palette
 Decide *how committed* the surface is to colour before opening the picker.
 Four positions on a single axis; pick one, then design within it:
 
 | Strategy | Rough coverage | Use for |
 |---|---|---|
 | **Restrained** | tinted neutrals + 1 accent ≤ ~10% of the surface | Most product UI; brand surfaces that want to look quiet. |
-| **Committed** | one saturated colour carries 30–60% of the surface | Brand pages with a strong identity; product feature surfaces that need a hero colour. |
-| **Multi-role** | 3–4 named colour roles, each used deliberately | Brand campaigns; product data-viz with distinct meanings. |
-| **Saturated** | the surface *is* the colour — full-bleed colour ground | Brand heroes, campaign pages, splash moments. |
+| **Committed** | one saturated colour carries 30-60% of the surface | Brand pages with a strong identity; product feature surfaces that need a hero colour. |
+| **Multi-role** | 3-4 named colour roles, each used deliberately | Brand campaigns; product data-viz with distinct meanings. |
+| **Saturated** | the surface *is* the colour: full-bleed colour ground | Brand heroes, campaign pages, splash moments. |
 
 Two corollaries:
 - The "one accent ≤ ~10%" rule belongs to **Restrained only.** Committed /
   Multi-role / Saturated exceed it deliberately. Don't collapse every
   surface back to Restrained by reflex.
-- *Register* (brand vs product) doesn't pick the strategy by itself — brand
+- *Register* (brand vs product) doesn't pick the strategy by itself: brand
   surfaces aren't always Saturated, product surfaces aren't always
   Restrained. Pick from the scene, not the category.
 
-### Calibration — density & motion
+### Calibration: density & motion
 Colour commitment fixes *how much colour*; two more axes fix *how much space* and
-*how much movement*. Set one position on each — from the **scene sentence**, the same
-way colour is picked — and carry both in `design-brief.md` so the build targets a
+*how much movement*. Set one position on each (from the **scene sentence**, the same
+way colour is picked) and carry both in `design-brief.md` so the build targets a
 calibration instead of re-deciding it per slice.
 
-**Density** — information per viewport; drives which spacing steps dominate:
+**Density**: information per viewport; drives which spacing steps dominate:
 
 | Position | Feels like | Spacing steps that dominate | Use for |
 |---|---|---|---|
 | **Airy** | gallery / calm / room to breathe | `32 / 48 / 64 / 80 / 96` | brand pages, onboarding, focus moments, low-data surfaces |
-| **Balanced** | most product UI | `16 / 20 / 24 / 32` | dashboards, forms, settings — the default |
+| **Balanced** | most product UI | `16 / 20 / 24 / 32` | dashboards, forms, settings: the default |
 | **Dense** | cockpit / data-rich / power tool | `4 / 8 / 12 / 16` | tables, monitors, terminals, pro tools lived in all day |
 
-**Motion** — how much the surface moves; drives which motion classes (table below) are in play:
+**Motion**: how much the surface moves; drives which motion classes (table below) are in play:
 
 | Position | Feels like | Motion classes in play | Use for |
 |---|---|---|---|
 | **Minimal** | crisp, almost still | Instant + State | dense tools, regulated/trust surfaces, reduced-motion-leaning |
-| **Standard** | responsive, purposeful | Instant + State + Layout | most product + brand UI — the default |
+| **Standard** | responsive, purposeful | Instant + State + Layout | most product + brand UI: the default |
 | **Expressive** | choreographed, scroll-aware | + Entrance, deliberate sequencing | brand heroes, launch/campaign moments, story scroll |
 
 Corollaries (same shape as colour commitment):
-- Pick from the **scene sentence**, not the category — "an on-call SRE at 2am" → Dense +
+- Pick from the **scene sentence**, not the category: "an on-call SRE at 2am" → Dense +
   Minimal; "a launch hero in afternoon light" → Airy + Expressive. Register doesn't decide
   it by itself.
-- `prefers-reduced-motion` overrides Motion **downward at runtime** regardless of position —
+- `prefers-reduced-motion` overrides Motion **downward at runtime** regardless of position:
   an Expressive surface still ships a Minimal path.
 - The position is a target, not a straitjacket: a surface may break density locally for
-  emphasis — name the exception in the brief, don't let the whole page drift off it.
+  emphasis: name the exception in the brief, don't let the whole page drift off it.
 
 ### Spacing
 - **4pt base scale** (`4 / 8 / 12 / 16 / 20 / 24 / 32 / 40 / 48 / 64 / 80 /
   96`). Project tokens may use a multiplier; never hardcode in-between
   values.
 - Inline spacing rhythms in multiples of 4 px. Optical alignments may need a
-  1 – 2 px nudge — record the *why* in a comment.
+  1 - 2 px nudge: record the *why* in a comment.
 
 ### Typography scale
 - **Brand surfaces**: fluid `clamp()` headings (e.g.,
   `clamp(2rem, 1rem + 3vw, 3.5rem)`). Display/body pairing OK.
-- **Product surfaces**: **fixed rem scale** (1.125 – 1.2 ratio). One family
+- **Product surfaces**: **fixed rem scale** (1.125 - 1.2 ratio). One family
   usually carries headings, body, labels, data.
-- Body line-height ~1.5; headings ~1.1 – 1.25. Prose width ~ 65–75 ch.
-- Display ceiling: `clamp()` max ≤ ~6rem — larger is shouting. Display
+- Body line-height ~1.5; headings ~1.1 - 1.25. Prose width ~ 65-75 ch.
+- Display ceiling: `clamp()` max ≤ ~6rem: larger is shouting. Display
   letter-spacing floor **≥ −0.04em**; tighter and the letters touch.
-- `text-wrap: balance` on h1–h3; `text-wrap: pretty` on long prose.
+- `text-wrap: balance` on h1-h3; `text-wrap: pretty` on long prose.
 
 ### Motion
 | Class | Duration | Use |
 |---|---|---|
-| Instant | 100 – 150 ms | Hover/press, tooltip enter, color shifts |
-| State | 200 – 300 ms | Toggle, focus ring, dropdown |
-| Layout | 300 – 500 ms | Modal/drawer enter, route transitions |
-| Entrance | 500 – 800 ms | Page entrance, hero animation |
+| Instant | 100 - 150 ms | Hover/press, tooltip enter, color shifts |
+| State | 200 - 300 ms | Toggle, focus ring, dropdown |
+| Layout | 300 - 500 ms | Modal/drawer enter, route transitions |
+| Entrance | 500 - 800 ms | Page entrance, hero animation |
 
 - **Exit at ~75 % of enter.** A 300 ms enter pairs with a 225 ms exit.
 - **Bounce / elastic easing banned** unless the project's design system
   explicitly uses it.
-- Honor `prefers-reduced-motion` — reduce or remove non-essential motion
+- Honor `prefers-reduced-motion`: reduce or remove non-essential motion
   entirely.
 
 ### Dark mode (three-axis compensation)
@@ -162,13 +162,13 @@ scope, propose the compensation rather than ship a flat invert.
 Every interactive element ships **8 visual/interaction states**:
 `default`, `hover`, `active`, `focus-visible`, `disabled`, `loading`,
 `selected`, and an error/invalid surface when relevant.
-- `:focus-visible` ring: **2 – 3 px**, **≥ 3:1** contrast against the
+- `:focus-visible` ring: **2 - 3 px**, **≥ 3:1** contrast against the
   background, **offset 2 px** so the focus is unambiguous on dense layouts.
 
 ### Container queries vs viewport queries
-- **Component breakpoints** — use **container queries** (`@container`). The
+- **Component breakpoints:** use **container queries** (`@container`). The
   same card adapts to its column whether the viewport is 320 or 1920.
-- **Page-level layout** — use viewport queries
+- **Page-level layout:** use viewport queries
   (`@media (min-width: ...)`) for sidebar collapses, header reflows.
 - Mixing the two is normal; using only one is usually a code smell.
 
@@ -194,10 +194,10 @@ rung that carries the structure.
   want a hairline, not elevation.
 - **Elevation is a token scale, not an ad-hoc value.** When a surface genuinely lifts
   (menu, popover, dragged item), use a **small shadow set from the design system** with one
-  consistent light source — never a one-off `box-shadow`. The elevation step and the
+  consistent light source: never a one-off `box-shadow`. The elevation step and the
   semantic z-index role move together.
 - **Texture needs contrast.** Grain / noise / pattern earns its place only when it reads
-  against the surface. Invisible texture is bytes with no signal — drop it.
+  against the surface. Invisible texture is bytes with no signal: drop it.
 - **Asset-led material.** Rich material (photographic grain, real product imagery,
   generated art) comes from a **real raster / generated asset**, not an SVG/CSS
   approximation of one. Don't fake a photo with gradients; ship the asset or use a flat

package/pack/generated/codex/skills/devrites-frontend-craft/reference/reuse-first.md

@@ -1,8 +1,8 @@
-# Reuse first — frontend application
+# Reuse first: frontend application
 
 Frontend-specific application of the canonical reuse rule in
 [`.agents/skills/devrites-lib/reference/standards/coding-style.md`](../../devrites-lib/reference/standards/coding-style.md#reuse-before-you-write)
-(and the slightly longer treatment in `standards/patterns.md`). Same principle —
+(and the slightly longer treatment in `standards/patterns.md`). Same principle:
 **reuse → extend → build new**, with the AHA caveat. This file walks it through for
 components, styles, tokens, icons, hooks, utils, and helpers in a UI feature.
 
@@ -11,12 +11,12 @@ token, icon, hook, util, or helper for the feature, **search the project** for a
 existing one that fits. Reuse it. Don't duplicate.
 
 This applies to UI **and** non-UI code: utilities, helpers, types, validators, schemas,
-formatters, hooks, query helpers — anything that might already exist.
+formatters, hooks, query helpers: anything that might already exist.
 
 ## The decision (in order)
-1. **Search first.** Use a code-intelligence index if available — codebase-memory-mcp first,
+1. **Search first.** Use a code-intelligence index if available (codebase-memory-mcp first,
    cross-checked with codegraph + graphify, else standard methods (LSP / Read/Grep/Glob); see
-   `../../devrites-lib/reference/standards/tooling.md` — to find
+   `../../devrites-lib/reference/standards/tooling.md`) to find
    similar definitions; fall back to grep/glob over `components/`, design tokens, hooks/,
    utils/, lib/. Look for things doing the *same job*, not just the same name.
 2. **Exact fit → REUSE.** Compose / import the existing thing. No copy, no fork.
@@ -25,7 +25,7 @@ formatters, hooks, query helpers — anything that might already exist.
    each branch the internals is not.
 4. **No fit → BUILD NEW**, in the project's idiom. If a similar need is likely to recur,
    propose adding it to the shared system (component library / utils module). If it's
-   truly one-off, build it locally — don't pre-abstract.
+   truly one-off, build it locally: don't pre-abstract.
 
 ## When to *avoid* reuse (the AHA caveat)
 Reuse is good; **forcing** it isn't. **Avoid Hasty Abstractions**: if making the existing
@@ -34,7 +34,7 @@ Duplication is cheaper than the wrong abstraction. Build a sibling component/uti
 a real pattern emerge from two or three callers before consolidating.
 
 ## Record the decision (per slice)
-On each slice, note what was reused / extended / created new — so the seal can see the
+On each slice, note what was reused / extended / created new, so the seal can see the
 consistency story and reviewers can spot silent duplication.
 
 ```
@@ -48,8 +48,8 @@ Created new: <ExportProgress (no prior equivalent; propose for shared lib)>
   finding it. Search first.
 - Copy-pasting a component from `components/` into the feature folder. That's a fork.
 - Adding a second icon set / second toast library / second date util because the existing
-  one didn't quite fit — almost always extend the existing or ask first.
-- Forcing reuse via 8 boolean props that branch the internals — that's an abstraction
+  one didn't quite fit: almost always extend the existing or ask first.
+- Forcing reuse via 8 boolean props that branch the internals. That's an abstraction
   collapsing under its own weight. Split it.
 
 ## Search hints

package/pack/generated/codex/skills/devrites-frontend-craft/reference/shape.md

@@ -5,35 +5,35 @@ follows the user's goal. Skipping this is how you get pretty UI that doesn't wor
 
 **The feature-level shape already exists.** `$rite-spec` ran `devrites-ux-shape` and wrote
 `design-brief.md` (design direction, key states, interaction model). In `$rite-build` this
-is a **per-slice refinement of that brief for the surface you're about to code** — confirm
+is a **per-slice refinement of that brief for the surface you're about to code**: confirm
 the answers below against the brief and fill any slice-specific gaps; don't re-derive the
 design. **Only shape from scratch here** when a UI slice has no `design-brief.md` (a spec
-written before shaping) — then run `devrites-ux-shape` first, or answer these and write the
+written before shaping), then run `devrites-ux-shape` first, or answer these and write the
 brief inline.
 
 ## Answer these before writing markup
-1. **User goal** — what is the user here to accomplish? One sentence.
-2. **Primary action** — the single most important thing on this surface. It must be
+1. **User goal:** what is the user here to accomplish? One sentence.
+2. **Primary action:** the single most important thing on this surface. It must be
    visually obvious. Everything else is secondary.
-3. **Information hierarchy** — what must be seen first, second, third. Rank content;
+3. **Information hierarchy:** what must be seen first, second, third. Rank content;
    the layout expresses the ranking.
-4. **States** — design all of them, not just the happy path:
+4. **States:** design all of them, not just the happy path:
    - default / populated
    - loading (initial + subsequent)
-   - empty (with a clear next action — welcoming, not a dead end)
+   - empty (with a clear next action: welcoming, not a dead end)
    - error (what happened + how to recover)
    - success
    - disabled / read-only / no-permission
    - long content / overflow / many items
-5. **Responsive** — how it reflows from small (320) to large (1440). What collapses,
+5. **Responsive:** how it reflows from small (320) to large (1440). What collapses,
    stacks, hides, or scrolls.
-6. **Accessibility** — focus order, labels, contrast, keyboard operability, semantics.
-7. **Interaction model** — what's inline vs. navigated vs. (rarely) a modal; optimistic
+6. **Accessibility:** focus order, labels, contrast, keyboard operability, semantics.
+7. **Interaction model:** what's inline vs. navigated vs. (rarely) a modal; optimistic
    vs. pending; how feedback is given.
 
 ## Ask when ambiguous
 If the visual direction or the UX flow isn't determined by the existing system + the
-spec, ask the user (show 2–3 concrete options) before building. Guessing a flow is
+spec, ask the user (show 2-3 concrete options) before building. Guessing a flow is
 expensive to undo once coded.
 
 ## Output
@@ -51,10 +51,10 @@ checklist.
   disabled / long-content are not optional.
 - Never decide the visual direction by personal taste when the project has
   an existing system. Discover first (`design-references.md`).
-- Never invent a new flow when a neighboring feature already has one — match
+- Never invent a new flow when a neighboring feature already has one: match
   the neighbor, then deviate only with a recorded reason.
 - Never paper over an ambiguous spec with a "reasonable guess". Ask the user
-  with 2 – 3 concrete options.
+  with 2 - 3 concrete options.
 - Never name a state for the *technical* condition (`isLoadingTrue`) when
   the *user-facing* name (`Loading your invoices…`) tells the user what's
   happening.