Design Spec

Codex compatibility note:

• Invoke repository skills with $skill-name in Codex; this mirrored copy rewrites legacy Claude /skill-name references.
• Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes.
• User-question prompts mean to ask the user directly in Codex.
• Ignore Claude-specific mode-switch instructions when they appear.
• Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first.
• For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence.
• If a required step/tool cannot run in this environment, stop and ask the user before adapting.

Codex Project-Reference Loading (No Hooks)

Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.

Always read:

• docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)
• docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)
• docs/project-reference/lessons.md (always-on guardrails and anti-patterns)

Missing/stale context route: If docs/project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run $project-init or the narrow setup route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/stale, ask the user to run $sync-codex; do not auto-run it.

Situation-based docs:

• Project structure/architecture/tech-stack/deployment/setup (any layer — backend, frontend, or infra): project-structure-reference.md
• Backend/CQRS/API/domain/entity changes: backend-patterns-reference.md, domain-entities-reference.md
• Frontend/UI/styling/design-system: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
• Spec authoring, docs/specs/ pathing, or TC format: feature-spec-reference.md, spec-system-reference.md, spec-principles.md
• Behavior/public-contract changes or spec-test-code sync: workflow-spec-test-code-cycle-reference.md plus the spec docs above
• Derived spec indexes/ERDs/reimplementation guides: spec-system-reference.md and source Feature Specs under docs/specs/
• Integration test implementation/review: integration-test-reference.md
• E2E test implementation/review: e2e-test-reference.md
• Code review/audit work: code-review-rules.md plus domain docs above based on changed files

Do not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Produce a structured, tech-agnostic UI/UX design specification from a requirement/PBI/story/wireframe so a developer can rebuild the UI on ANY stack — every component, state, design token, responsive rule, and accessibility need documented and linked back to the governing Feature Spec.

Summary (read this if nothing else — PURPOSE + every main step):

• Purpose — translate requirements into a developer-ready UI/UX spec (component inventory, states, design tokens, responsive behavior, accessibility), tech-agnostic: name components by UX role, never by framework/library class.
• Step 0–0b — research first: inventory existing related screens/components + map connected flows, record in §1 so the spec matches the live UI system; if a governing Feature Spec exists, seed from its §6 interaction surface and reuse its view + observable-state vocabulary verbatim. — why: divergent vocabulary breaks the navigable spec↔design hub.
• Step 1–2 — read & route input, set complexity: Figma URL → $figma-design; image/screenshot → visual analysis tooling; wireframe/sketch → --mode=wireframe; PBI/text → extract requirements. Pick Quick Spec (§1–4) vs Full Spec (§1–7, +Flow Diagram for multi-page).
• Step 3–6 — author the body: build component inventory (new vs existing), define all 7 states + interactions, extract design tokens (reuse design-system), document responsive breakpoints (mobile 320–767 / tablet 768–1023 / desktop 1024+).
• Step 7–8 — save & link back: write the artifact to team-artifacts/design-specs/, then set the governing Feature Spec's design_spec:/mockup: frontmatter to the saved path — frontmatter only, never the §1–8 body. — why: artifact-review --type=design fails if the path is not recorded.

Workflow:

1. Read Source — Extract UI requirements from PBI, story, or Figma URL
2. Determine Complexity — Quick Spec (sections 1-4) vs Full Spec (all 7 sections)
3. Build Component Inventory — List new vs existing components
4. Define States & Tokens — Interactions, design tokens, responsive breakpoints
5. Save Artifact — Output to team-artifacts/design-specs/

Key Rules:

• If Figma URL provided → auto-routes to $figma-design for context extraction
• If wireframe image provided (hand-drawn/digital/tool-export) → handled internally via --mode=wireframe (see "Mode: wireframe" below)
• If screenshot provided → uses visual analysis tooling for design extraction
• Reference existing design system tokens from docs/project-reference/design-system/
• Component patterns: docs/project-reference/frontend-patterns-reference.md
• Include accessibility requirements (keyboard nav, ARIA labels, contrast)
• [BLOCKING] Tech-agnostic output: spec prose/headings follow docs/project-reference/spec-principles.md §3 — describe components by UX role, not framework/library names; source paths and class names appear ONLY in evidence fields (**Evidence**, [Source:]), frontmatter, and Mermaid.

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Design Specification

Create structured UI/UX design specification documents from requirements or PBIs for developer handoff.

When to Use

• A PBI or user story needs a design spec before implementation
• Translating requirements into concrete UI layout, states, and tokens
• Documenting component inventory and interaction patterns
• Creating responsive breakpoint specifications

When NOT to Use

• This skill auto-routes Figma URLs to $figma-design; wireframes are handled internally via --mode=wireframe — no need to call a separate skill
• Building the actual UI -- use design --lane=marketing (marketing/creative) or design --lane=product (product UIs)
• Reviewing existing UI code -- use web-design-guidelines

Prerequisites

Read before executing:

• The source PBI, user story, or requirements document
• docs/project-reference/design-system/ -- project design tokens (if applicable)
• Existing design specs in team-artifacts/design-specs/ for format consistency

Frontend/UI Context

When this task involves frontend or UI changes,

• Frontend patterns: docs/project-reference/frontend-patterns-reference.md
• Styling/BEM guide: docs/project-reference/scss-styling-guide.md
• Design system tokens: docs/project-reference/design-system/README.md

Workflow

[BLOCKING] Step 0 — Inventory existing UI + map connected flows (per the SYNC:existing-ui-research protocol carried by this skill). Before authoring the spec, inventory the existing related screens / components / pages already serving this feature or domain, and map every connected feature flow that links to / embeds / navigates to-or-from the new screen. Record the matched screens + flows in §1 Overview so the spec faithfully matches the current UI system. Skip only for backend-only work (state it explicitly).

[BLOCKING] Step 0b — Seed from the governing Feature Spec's §6 interaction surface (when one exists). Detect whether a canonical Feature Spec already governs this feature (look under docs/specs/** for a spec covering the same capability). If one exists, READ its §6 Process Flows & Interaction Surface — the View Inventory (§6.2), Navigation Map (§6.3), Key UI States (§6.4), and Per-Story Interaction Flow (§6.5) — and use it as this design-spec's starting frame:

• Reuse the spec's vocabulary verbatim — carry over the SAME UX-role view names from §6.2 and the SAME observable-state names from §6.4 (the Default / Loading / Disabled / Error / Empty / Success vocabulary in this skill's "Observable State Definitions" table is the shared language). NEVER rename or re-partition what the spec already named — the two artifacts MUST speak the same language or the navigable hub breaks.
• Deepen, do not diverge or contradict. The spec stays tech-agnostic; this design-spec is the companion that adds visual fidelity (layout, tokens, pixel detail) ON TOP of the spec's intent. Map each §6.5 step and each §6.4 state into concrete visual treatment, preserving the US-/OP-/BR- logical-ID cross-refs the spec already owns.
• This coupling is the SYNC:ui-intent-layer contract carried below — see that block for the full rule; do not restate it here.

Skip ONLY when no governing Feature Spec exists (author the interaction frame from the source PBI/story instead) — state which case applies.

1. Read source input & route by type

   Input Detected	Detection	Action
   Figma URL	figma.com/design or figma.com/file in text	Activate $figma-design to extract context, then continue
   Image/screenshot	Image file attached to prompt	Use visual analysis tooling to extract design guidelines, then continue
   Hand-drawn wireframe	Image + "wireframe"/"sketch" keyword	Run --mode=wireframe (internal — see "Mode: wireframe" section)
   PBI/story text	Acceptance criteria present	Extract UI requirements from text, continue
   Verbal/text requirements	No image, no URL, no PBI	Clarify with user, then continue

For ANY visual input: extract design context FIRST, then proceed to spec generation.

2. Determine spec complexity

   IF single form or simple component → Quick Spec (sections 1-4 only)
   IF full page or multi-component view → Full Spec (all 7 sections)
   IF multi-page flow → Full Spec + Flow Diagram
   

3. Build component inventory

   • List all UI components needed
   • Identify reusable vs feature-specific components
   • Note existing components from shared component library or design system

4. Define states and interactions

   • Default, hover, active, disabled, error, loading, empty states
   • User interactions (click, drag, keyboard shortcuts)
   • Transitions and animations

5. Extract design tokens

   • Colors, typography, spacing, shadows, border-radius
   • Reference existing design system tokens where possible

6. Document responsive behavior

   • Mobile (320-767px), Tablet (768-1023px), Desktop (1024px+)
   • What changes at each breakpoint (layout, visibility, sizing)
   • Small-screen minimum bar (spec it explicitly): the layout MUST stay usable on mobile. Preferred = reflow (rows flex-wrap / row → column, grids collapse to one column). Where a component genuinely can't reflow (data tables, canvases, wide grids), specify a min-width/min-height + overflow: auto scroll as the accepted fallback — scrolling is OK. Hard requirement = nothing broken (no clipped, cut-off, or unreachable content/controls). If a component needs a large redesign to work on mobile, flag it for the user rather than assuming a rewrite.

7. Save artifact — pick the filename variant by artifact type:

   • Design spec: team-artifacts/design-specs/{YYMMDD}-designspec-{feature-slug}.md
   • Accessibility audit: team-artifacts/design-specs/{YYMMDD}-ux-audit-{feature-slug}.md
   • Single-component doc: team-artifacts/design-specs/{YYMMDD}-ux-component-{component-name}.md

8. Link back to the governing Feature Spec (when one exists). After saving the artifact, keep the spec the navigable hub: open the governing Feature Spec under docs/specs/** and set its frontmatter design_spec: key to this design-spec's saved path (add the key if absent, update it if stale). If a mockup was also produced (e.g. via $pbi-mockup), set the mockup: key the same way. Edit frontmatter only — never touch the §1–§8 spec body. This satisfies the artifact-review --type=design link-back gate, which fails when a design-spec exists but its path is not recorded in the spec's design_spec: frontmatter. Skip ONLY when no governing Feature Spec exists (the design-spec is standalone) — state that.

Role Context & Artifact Path (canonical)

Applies to Writes under team-artifacts/design-specs/.

• Active Role: ui-ux-designer · Skill: design-spec
• Path: team-artifacts/design-specs/ · Type: designspec · Role token: ux
• Template: .claude/docs/team-artifacts/templates/design-spec-template.md
• Naming: {YYMMDD}-ux-{type}-{slug}.md (general artifact-path pattern: {YYMMDD}-{role}-{type}-{slug}.md)
• Context: DESIGN SPEC — include component states, design tokens, accessibility requirements.
• Quality checklist: - [ ] All states documented · - [ ] Design tokens specified · - [ ] Accessibility notes included · - [ ] Responsive breakpoints defined

Mode: wireframe (image → spec)

Invoke with --mode=wireframe (or whenever a hand-drawn wireframe, digital wireframe, or UI sketch is the input). This mode is an INPUT adapter: it analyzes the image, then flows into the normal spec sections (Output Format) and the M1-M5/M7 compliance gate. design-spec is the canonical owner of wireframe→spec conversion.

Input Routing (wireframe)

Wireframe Analysis

Use visual analysis tooling with these prompts:

Prompt 1: Layout Extraction — "Analyze this wireframe image. Identify: (1) page layout regions (header, sidebar, main, footer), (2) all UI elements with approximate position and type (button, input, table, card, dropdown, modal, tabs), (3) content hierarchy (what is primary vs secondary), (4) interactive elements, (5) any text labels or annotations, (6) navigation patterns."

Prompt 2: Component Identification — "From the wireframe, list every distinct UI component. For each: name it descriptively, classify its complexity (primitive=single element, composite=grouped elements, section=page region), note its purpose."

Wireframe Output Generation

After image analysis, generate (per the SYNC:ui-wireframe-protocol block below):

1. ASCII Wireframe — Recreate layout using box-drawing characters
2. Component Inventory — List with tier classification (Common/Domain-Shared/Page)
3. States Table — Default, Loading, Empty, Error per view
4. Component Decomposition Tree — If detail level warrants (refine/story)
5. Responsive Suggestions — Based on layout complexity

Apply the M1-M5/M7 Compliance for UI Specs gate (below) to all wireframe-derived prose: business-level component names, no code-prop refs, map to feature logic by logical ID, observable state transitions, rebuild-from-spec, business-visible subject matter.

Wireframe-derived specs carry the same Design-Principles Obligations (below): the States Table (item 3) is authored empty/loading/error FIRST (UI-1.5) and covers all 5 interaction states per interactive element (UI-5.2); the Responsive Suggestions (item 5) break where the CONTENT breaks, not at device names (UI-4.4); and where the sketch is silent on type scale, spacing unit, or contrast (UI-2.5, UI-4.1, UI-3.1), record them in §4 as [UNVERIFIED — needs design-system mapping] rather than inventing one-off values measured off the drawing.

Mapped Business Operations

Emit this table linking each interactive component to the feature operations/rules it drives (logical ID is the primary spine; mark [UNVERIFIED — needs feature-spec mapping] when the wireframe alone cannot determine it):

Wireframe Output Formats

• Format A: PBI Section (default) — output a standalone ## UI Layout section compatible with PBI/story templates (consumed by $pbi-mockup).
• Format B: Standalone Spec — output to team-artifacts/design-specs/{YYMMDD}-wireframe-spec-{slug}.md.

Confidence & Review (wireframe)

• Always display confidence level for wireframe interpretation (analysis is 70-80% accurate).
• Always recommend human review before proceeding to implementation.
• If confidence <70%: ask clarifying questions about ambiguous elements by asking the user directly.

Output Format

# Design Spec: {Feature Name}

**Source:** {PBI/story reference}
**Date:** {YYMMDD}
**Status:** Draft | Review | Approved

## 1. Overview

{1-2 sentence summary of what this UI does}

## 2. Component Inventory

| Component | Type     | Source           | Notes                       |
| --------- | -------- | ---------------- | --------------------------- |
| UserCard  | New      | Feature-specific | Displays user avatar + name |
| DataTable | Existing | shared library   | Reuse with custom columns   |

## 3. Layout

{Description or ASCII wireframe of layout structure}

- Desktop: {layout description}
- Tablet: {layout changes}
- Mobile: {layout changes}

## 4. Design Tokens

| Token      | Value          | Usage                 |
| ---------- | -------------- | --------------------- |
| $primary   | #1976D2        | Action buttons, links |
| $text-body | 14px/1.5 Inter | Body text             |
| $gap-md    | 16px           | Section spacing       |

## 5. States & Interactions

| Element  | Default    | Hover      | Active     | Disabled         | Error |
| -------- | ---------- | ---------- | ---------- | ---------------- | ----- |
| Save btn | Blue/white | Darken 10% | Scale 0.98 | Gray/50% opacity | --    |

## 6. Accessibility

- Keyboard navigation order
- ARIA labels for interactive elements
- Color contrast compliance notes

## 7. Open Questions

- {Any unresolved design decisions}

Design-Principles Obligations (per spec section)

The spec is where the 40 UI/UX Design Principles (UI-1.1–UI-9.4, the SYNC:ui-ux-design-principles block below) become INHERITABLE — a downstream implementer builds what the spec SAYS, so an unstated clause is an unbuilt clause. Every spec this skill emits MUST carry these obligations in the named Output Format sections. Project design-system docs OUTRANK the clauses; a genuine conflict is surfaced to the user with both sides, NEVER resolved silently.

Keep every clause obligation written in observable UX language so it survives the M1-M5/M7 gate below — state the visible outcome, never a CSS property or framework prop.

Skip ONLY when the feature has no user-facing surface — state that explicitly so the skip is auditable, not an omission.

M1-M5/M7 Compliance for UI Specs

See .claude/skills/shared/sdd-artifact-contract.md → "AI-SDD Mandates (M1-M7)" for BLOCKING criteria. A UI spec MUST satisfy these before handoff:

• M1 — Business-level component names. Name every component by its UX role — Primary Button, Secondary Button, Modal Dialog, Data Table, Dropdown, Toast — NEVER by a framework component class name or library import. FAIL on tech-term prose.
• M2 — No code-prop refs in prose. Describe behavior and appearance in plain UX language. NEVER reference component-state props, CSS class names, framework directives, or selectors in prose. Those belong only in **Evidence**/[Source:] carriers, frontmatter, and Mermaid.
• M3 — Cross-reference by logical ID. For every behavior driven by feature logic, cite the driving operation or rule by its logical ID (OP-/BR-/FR-) — link UI behavior back to the feature spec, not to handler code. Keep any [Source: namespace/service/id] abstract anchor strictly in the Evidence carrier — never physical code coordinates or repository-root paths.
• M4 — Testable, unambiguous behavior. Every state and interaction MUST have exactly one valid interpretation and an observable completion marker. Replace vague phrases ("handle appropriately", "show feedback") with the concrete observable result.
• M5 — Rebuild-from-spec. A reader with zero codebase knowledge MUST be able to rebuild this UI on ANY framework from the spec alone. If a marker is only resolvable by reading source, it fails M5 — restate it as a visual/textual observable.
• M7 — Business-visibility. A UI spec is a business-tree artifact, so apply the demo test to each case's BODY: "what would a stakeholder SEE change?" — no answer → FAIL as TECHNICAL-ONLY. Every Given = a state a user could arrange; every When = an action a user could take; every Then = an outcome a user could see. FAIL a When that is an invocation (a handler runs, a consumer receives, a job fires, data syncs) or a Then asserting schema/type/nullability/call-count. Judge the BODY, never the title or ID. ⚠️ A UI state a user can SEE is business and PASSES M7 — a spinner, an empty placeholder, an error border, a disabled control are all demoable outcomes, not technical cases. Only invocation-shaped or schema-asserting cases fail.

M1 vs M7 — they are not the same gate. M1 governs vocabulary; M7 governs subject matter. A technical case in impeccably tech-free prose satisfies M1 while violating M7 — "the view correctly reflects the synchronized record" names no framework, passes M1, and is still a technical case wearing a business costume. That gap is the most common way business specs rot. Ask what a user could SEE, not which words were used.

Observable State Definitions

Define every state by what a user can SEE (color, icon, position, text), the business meaning, and the operation/rule that triggers it — NEVER by CSS class or component-state prop:

Component States Checklist

Every interactive component MUST document all 7 states by their observable appearance and business meaning — never by CSS class or framework prop (see M2):

• Default — resting appearance; action available to the actor
• Hover — pointer-over affordance change (cursor / elevation / color shift)
• Active — pressed/engaged feedback during interaction
• Focus — keyboard-focus indicator (visible ring/outline) for a11y traversal
• Disabled — muted/non-interactive; precondition or permission not met
• Error — validation/operation failure with inline message + alert affordance
• Loading — in-progress indicator (spinner / skeleton); control non-interactive

Accessibility Audit (WCAG 2.1 AA)

For an accessibility-audit deliverable, produce this checklist report and save it as {YYMMDD}-ux-audit-{feature-slug}.md:

## Accessibility Audit: {Feature}

**Date:** {Date}
**Auditor:** {Name}
**Standard:** WCAG 2.1 AA

### Criteria Checklist

#### Perceivable

- [ ] 1.1.1 Non-text Content: Alt text for images
- [ ] 1.3.1 Info and Relationships: Semantic HTML
- [ ] 1.3.2 Meaningful Sequence: Logical reading order
- [ ] 1.4.1 Use of Color: Not sole means of conveying info
- [ ] 1.4.3 Contrast (Minimum): 4.5:1 text, 3:1 large text
- [ ] 1.4.4 Resize Text: Readable at 200% zoom
- [ ] 1.4.11 Non-text Contrast: 3:1 for UI components

#### Operable

- [ ] 2.1.1 Keyboard: All functions keyboard accessible
- [ ] 2.1.2 No Keyboard Trap: Can navigate away
- [ ] 2.4.1 Bypass Blocks: Skip navigation available
- [ ] 2.4.3 Focus Order: Logical tab sequence
- [ ] 2.4.4 Link Purpose: Clear from link text
- [ ] 2.4.6 Headings and Labels: Descriptive
- [ ] 2.4.7 Focus Visible: Clear focus indicator

#### Understandable

- [ ] 3.1.1 Language of Page: lang attribute set
- [ ] 3.2.1 On Focus: No unexpected context change
- [ ] 3.2.2 On Input: No unexpected context change
- [ ] 3.3.1 Error Identification: Clear error messages
- [ ] 3.3.2 Labels or Instructions: Form labels present

#### Robust

- [ ] 4.1.1 Parsing: Valid HTML
- [ ] 4.1.2 Name, Role, Value: ARIA where needed

### Issues Found

| #   | Criterion | Issue | Severity | Recommendation |
| --- | --------- | ----- | -------- | -------------- |
| 1   |           |       | P1/P2/P3 |                |

### Audit Status: PASS / FAIL / CONDITIONAL

**Remediation Priority:**
{List items by severity}

Examples

Example 1: Simple form spec

Input: "Design spec for customer onboarding form"

Output: Quick Spec with sections 1-4 covering form fields (name, email, company name, plan-tier dropdown), validation rules, submit/cancel actions, and mobile stacking behavior.

Example 2: Complex dashboard spec

Input: "Design spec for order pipeline dashboard with drag-and-drop columns"

Output: Full Spec covering Kanban board layout, order cards (component inventory), drag-and-drop interactions, column states (empty, populated, over-limit), filter bar, responsive collapse to list view on mobile, and accessibility for keyboard drag operations.

Related Skills

Workflow Recommendation

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS: If you are NOT already in a workflow, you MUST ATTENTION use ask the user directly to ask the user. Do NOT judge task complexity or decide this is "simple enough to skip" — the user decides whether to use a workflow, not you:

1. Run the design sequence (Recommended) — $design-spec → $design --lane=product (product UIs) or $design --lane=marketing (marketing/creative) → $workflow-review-changes
2. Execute $design-spec directly — run this skill standalone

[IMPORTANT] Use task tracking to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

[BLOCKING] Understand the existing UI before you design or spec a new/updated screen. Before producing any wireframe, mockup, screen design, or UI spec:

1. Inventory existing related UI — search the project for screens, pages, and components already serving this feature or its domain (consult design-system docs + the real component inventory).
2. Map connected flows — identify every feature that links to, embeds, includes, or navigates to/from the new screen; trace its entry and exit flows so the new screen fits them.
3. Reuse before invent — prefer existing components, patterns, and layout conventions; justify any new component against what already exists.
4. Record findings — note the matched existing screens/components + connected flows in the artifact so downstream design faithfully matches the current UI system.

Skip ONLY when the feature is backend-only (no UI) — state that explicitly.

[BLOCKING] Capture a tech-agnostic UI/UX intent layer in every UI-bearing spec — a reader must be able to visualize how the feature works without naming any technology. When the feature has a user interface, the spec MUST ATTENTION carry an interaction-surface section so the application — not just its API — can be rebuilt on any stack:

1. View Inventory — list each view/screen by its UX ROLE and purpose (e.g. "list of items", "item editor", "confirmation step") and what information it presents. Describe by role, never by an implementation name.
2. Navigation Map — how a user moves between views: entry points, transitions, and exits. Trace how this surface connects to neighboring features already in the system.
3. Key observable UI States — the distinct states a user can observe per view (empty, loading, populated, error, success, permission-denied, etc.) — described as what the user perceives, not how it is rendered.
4. Per-story interaction flow — for each user story, the step-by-step click/action path from intent to outcome, cross-referenced to the logical IDs the spec already owns (US-/OP-/BR-).
5. Couple to the companion design artifact — keep deep visual fidelity (layout, tokens, pixel detail) OUT of the spec; it lives in the linked design-spec/mockup. Record that companion's path in the spec frontmatter so the spec stays the navigable hub.

M1-clean (NON-NEGOTIABLE): the prose names ZERO frameworks,

…(truncated)