oh-my-opencode 4.13.0 → 4.14.1

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/taste-feedback/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: taste-feedback
+description: "Use during the build phase to show the user intermediate visual output and ask for taste direction before the full build completes — enables mid-flight course correction so taste mismatches are caught early, not in review"
+---
+
+# Live Taste Feedback
+
+The standard Designpowers pipeline catches taste mismatches at critique — after the full build is done. That's expensive. A wrong colour palette discovered after 8 components are built means rebuilding all 8. This skill interrupts the build at strategic moments to show intermediate output and ask: "Is this heading in the right direction?"
+
+## When to Use
+
+- During `design-builder` execution, at natural visual checkpoints
+- When the build involves subjective aesthetic decisions (colour, typography, spacing, tone)
+- When this project's taste direction (`design-taste`) is ambiguous on the decision at hand
+- When the project is new and there's little explicit direction yet for this decision
+- When the design-lead's direction was based on interpretation, not explicit user instruction
+
+## Do Not Use When
+
+- The user is in auto mode and hasn't opted into taste checks
+- The build is purely structural (data models, API integration, routing)
+- This project's `design-taste` direction already settles this decision clearly
+- The user has explicitly said "just build it, I'll review at the end"
+
+## Process
+
+### Step 1: Identify Checkpoints
+
+Before the build begins, identify 2-4 moments where taste feedback is most valuable. More than 4 interruptions becomes annoying. Choose wisely.
+
+**High-value checkpoints:**
+
+| Checkpoint | Why It Matters | When to Show |
+|------------|---------------|-------------|
+| **Colour and typography applied** | The foundational visual layer — everything else builds on this | After the first component is styled |
+| **Layout structure visible** | Spatial relationships, density, whitespace | After the primary screen scaffold is built |
+| **First interaction implemented** | How the interface moves and responds | After the first stateful component works |
+| **Content integrated** | How real words look in the design | After content-writer's copy is in place |
+
+**Low-value checkpoints (avoid):**
+
+| Checkpoint | Why It's Low Value |
+|------------|-------------------|
+| Unstyled HTML structure | Nothing to react to aesthetically |
+| Individual component in isolation | Context-free judgement is unreliable |
+| After every small change | Interruption fatigue kills the creative flow |
+
+### Step 2: Prepare the Checkpoint
+
+At each checkpoint, capture the current state:
+
+1. **Take a screenshot** of the running output (or describe the visual state precisely if screenshots aren't available)
+2. **Identify the taste-sensitive decisions** visible in the current output
+3. **Prepare specific questions** — do not ask "does this look good?" (too vague)
+
+Good taste questions are specific and answerable:
+
+| Bad Question | Good Question |
+|-------------|--------------|
+| "Does this look good?" | "The heading is set in 32px Inter Medium — is that weight right, or do you want bolder/lighter?" |
+| "Any feedback?" | "The cards have 16px padding and 8px radius. Does this density feel right, or do you want more breathing room?" |
+| "Is this the right direction?" | "I went warm grey (#F5F3F0) for the background instead of pure white. Does this warmth match what you had in mind?" |
+
+### Step 3: Present the Checkpoint
+
+Show the user the intermediate state with targeted questions:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  TASTE CHECK  [1 of 3]
+  Phase: [e.g., "Colour & Typography"]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  [Screenshot or detailed visual description]
+
+  DECISIONS VISIBLE:
+  • [Decision 1 — e.g., "Sage green (#8FAE8B) as primary"]
+  • [Decision 2 — e.g., "Space Grotesk for headings, Inter for body"]
+  • [Decision 3 — e.g., "Generous padding, low density"]
+
+  TASTE QUESTIONS:
+  1. [Specific question about a visible decision]
+  2. [Specific question about a visible decision]
+
+  Quick responses welcome:
+  • "Looks right" → continue building
+  • "Warmer/cooler/bolder/quieter" → adjust and continue
+  • "Stop — wrong direction" → pause build, discuss
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Step 4: Process the Response
+
+The user's response determines what happens next:
+
+| Response | Action | Taste Signal |
+|----------|--------|-------------|
+| "Looks right" / "Yes" / "Continue" | Resume building. No changes needed | Moderate positive — note in design-memory as confirmed direction |
+| Specific adjustment ("make it warmer") | Apply the adjustment, show confirmation, then continue | Strong — record the adjustment and the direction they moved from/to |
+| "Wrong direction" / "Stop" | Pause the build. Ask what feels off. This is the most valuable taste data | Very strong negative — record what was rejected and why |
+| Detailed feedback ("I like the type but the colour feels too muted") | Apply partial changes. Acknowledge what works, adjust what doesn't | Mixed signal — record both the positive and negative separately |
+| "Skip these checks" | Disable further taste checks for this build. Respect the preference | Meta-preference — they want to review at the end instead |
+
+### Step 5: Adjust and Confirm
+
+When the user requests a change:
+
+1. Make the adjustment
+2. Show the updated state briefly — do not re-present the full checkpoint
+3. Confirm: "Updated [what changed]. Continuing the build."
+4. Do not ask for re-approval unless the change was ambiguous
+
+If the change cascades (e.g., new colour palette affects multiple components already built):
+
+1. Flag the cascade: "This colour change will affect the 3 components already built. I'll update them all."
+2. Update everything before continuing
+3. Optionally show the cascaded result at the next checkpoint
+
+### Step 6: Record Taste Data
+
+After each checkpoint interaction, update taste signals:
+
+1. Record confirmed decisions as positive signals in `design-memory`
+2. Record adjustments with before/after — these are the richest taste data
+3. Record rejections as anti-pattern candidates
+4. Note the *direction* of adjustments — "wanted warmer", "wanted more contrast", "wanted tighter spacing" — these directional signals generalize across projects
+
+## Checkpoint Frequency
+
+Adapt based on user behaviour:
+
+| User Behaviour | Adjust To |
+|---------------|-----------|
+| Approves every checkpoint quickly | Reduce to 1-2 checkpoints — they trust the direction |
+| Gives detailed feedback at every checkpoint | Maintain 3-4 — they want to shape the output |
+| Says "skip" or seems impatient | Drop to 1 checkpoint or none — ask at the end |
+| Requests more checkpoints | Add checkpoints — they want more control |
+
+The system should learn this preference over time via `design-memory`.
+
+## Integration With Pipeline Modes
+
+| Mode | Behaviour |
+|------|-----------|
+| **Direct** | Taste checkpoints are shown naturally — they fit the approval flow |
+| **Auto** | Taste checkpoints are **disabled by default** in auto mode. The user chose speed. If the user opts in ("auto but check my taste"), enable minimal checkpoints (1-2 max) |
+
+## Integration
+
+- **Called by:** `design-builder` (at visual checkpoints during build), `using-designpowers` (can be enabled/disabled)
+- **Calls:** `design-memory` (to record taste signals from feedback)
+- **Reads from:** Taste profile (to determine checkpoint frequency and known preferences), `design-state.md` (for current decisions)
+- **Pairs with:** `design-memory`, `ui-composition`, `designpowers-critique`
+
+## Anti-Patterns
+
+| Pattern | Why It Fails |
+|---------|-------------|
+| Asking "does this look good?" | Too vague. The user can't give actionable feedback without specific questions |
+| Checking after every change | Interruption fatigue. 2-4 checkpoints per build, maximum |
+| Showing unstyled output | There's nothing to react to. Wait until visual decisions are visible |
+| Ignoring "skip" signals | If the user wants to review at the end, respect that. Don't force mid-flight checks |
+| Not recording feedback | Every checkpoint interaction is taste data. If you don't record it, you'll ask the same questions next project |
+| Presenting in auto mode without consent | Auto mode means "don't interrupt me." Only show taste checks if the user explicitly opted in |
+| Asking about non-visual decisions | "Is this the right React component pattern?" is not a taste question. Keep checks visual and aesthetic |

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/taste-report/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: taste-report
+description: "Use when the user wants to see how they design — \"what's my taste\", \"show me my taste report\", \"how do I decide\", \"what are my patterns\", or periodically as the personal profile matures. Generates a longitudinal, reflective report from the PERSONAL taste profile (design-memory) — recurring moves, tells, evolution, blind spots — that helps a designer understand their own instincts. Personal layer only: it never reports client-specific signals from any project's DESIGN.md"
+---
+
+# Taste Report
+
+A taste report turns the personal taste profile from a lookup table into a mirror. `design-memory` accumulates a designer's portable instincts over many projects; this skill reads that accumulation and reflects it back as something the designer can actually learn from — *how you decide, what you reach for, what you reject, and how that's changed.* It's the moment the system stops just remembering your taste and starts helping you see it.
+
+## Scope: Personal Layer Only
+
+This report describes the **portable** taste in `~/.designpowers/taste-profile.md` — the instincts that travel with the designer regardless of client. It **must not** include client- or project-specific signals (the contents of any project's `DESIGN.md`). A client's required teal accent is that client's taste, not the designer's. If the personal profile is clean (it should be — `design-memory`'s Promotion Gate keeps client specifics out), this is automatic. If you notice client-bound entries that leaked into the personal profile, flag them as contamination rather than reporting them as the designer's taste.
+
+## When to Use
+
+- The user asks: "what's my taste?", "how do I design?", "show me my patterns", "what do I always do?"
+- Periodically, as the profile matures — offer it after a project's retrospective once the profile has **3+ projects** of history (below that, there isn't enough signal; say so).
+- When a designer wants to articulate their own style — for a portfolio, a team, a client pitch.
+
+## What the Report Contains
+
+Read `~/.designpowers/taste-profile.md` and the project history, then synthesise — don't just reformat the tables. Look for the patterns *across* entries that the designer might not see themselves.
+
+```markdown
+# How You Design — Taste Report
+_Generated [date] · based on [N] projects · [X] strong opinions, [Y] soft patterns_
+
+## In one line
+[The single sharpest characterisation of their taste. e.g. "You're a restraint-first
+designer who earns every accent and trusts whitespace to do the work."]
+
+## How you decide
+[3-5 observations about their decision-making, each with evidence from the profile.
+Not what they like — HOW they choose. e.g.:
+- "You subtract before you add — your overrides almost always remove an element
+   rather than restyle it (4 of 5 recorded overrides)."
+- "You decide colour last. Type and spacing are settled before accent appears."]
+
+## What you reach for
+[Recurring moves — the defaults they return to across projects. The strong opinions
+and confirmed soft patterns, framed as instincts not rules.]
+
+## What you reject
+[The anti-patterns, synthesised into a point of view. e.g. "You reject anything that
+performs friendliness — confetti, mascots, exclamation marks, skeleton 'delight'."]
+
+## How your taste is evolving
+[Movement over time from the project history. What's hardened from soft to strong,
+what you've changed your mind about, what's newly appearing. e.g. "Your tolerance
+for density has risen — early projects favoured sparse layouts, recent ones trust
+the user with more on screen."]
+
+## Possible blind spots
+[Gentle, honest. Tendencies that could become ruts, or places the profile is thin.
+e.g. "Every project leans editorial-serif for personality — worth testing whether
+that's taste or habit." Frame as questions, not judgements.]
+
+## Where the signal is thin
+[What the profile doesn't yet know — areas with little evidence, so the designer
+knows what's well-established vs. a guess. Honesty about confidence.]
+```
+
+## How to Write It Well
+
+1. **Synthesise, don't transcribe.** The value is in patterns *across* entries — "you always subtract," "you decide colour last" — not in re-listing the table rows. If you're just reformatting the profile, you haven't done the work.
+2. **Every claim cites evidence.** Tie each observation to specific projects, overrides, or repeated decisions in the profile. No evidence, no claim — this is `design-memory`, and the same "evidence over claims" rule applies.
+3. **Describe decision-making, not just preference.** "Prefers muted palettes" is a lookup. "Decides colour last, after structure is settled" is insight. Reach for the second.
+4. **Be honest about confidence and thinness.** Distinguish strong, well-evidenced patterns from thin ones. Don't manufacture a richer picture than the data supports.
+5. **Blind spots are a gift, not a verdict.** Surface ruts and gaps gently, as questions. The goal is self-awareness, never a grade.
+6. **Stay in the personal layer.** If a "preference" is really one client's brand requirement, it does not belong here.
+
+## Integration
+
+- **Reads from:** `~/.designpowers/taste-profile.md` and its project history (via `design-memory`)
+- **Never reads:** any project's `DESIGN.md` as personal taste (that's client taste — see `design-md`)
+- **Offered after:** `design-retrospective`, once the profile has enough history
+- **Pairs with:** `design-memory` (the store), `design-taste` (per-project calibration)
+- **Produces:** a report for the user — not a profile edit. It reflects; it does not rewrite the profile.

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/token-architecture/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: token-architecture
+description: "Use when building or restructuring design token systems — global tokens, semantic tokens, component tokens, naming conventions, theming, and multi-platform token distribution"
+---
+
+# Token Architecture
+
+Design tokens are the single source of truth for visual decisions. They bridge design intent and code. This skill structures how tokens are named, layered, and distributed.
+
+## When to Use
+
+- When starting a new design system
+- When `design-system-alignment` identifies inconsistency
+- When adding theming (dark mode, brand variants)
+- When shipping across web, iOS, and Android
+
+## The Three-Layer Model
+
+### Layer 1: Global Tokens (the palette)
+Raw values. Named by what they are, not what they do.
+```
+--color-green-500: #2D6B4F;
+--space-4: 16px;
+--radius-md: 12px;
+```
+These never appear in component CSS.
+
+### Layer 2: Semantic Tokens (the meaning)
+Map global tokens to roles. Named by what they do.
+```
+--color-surface: var(--color-green-100);
+--color-text-primary: var(--color-green-900);
+--color-accent: var(--color-green-500);
+```
+Theming happens here — dark mode swaps semantic mappings, not global values.
+
+### Layer 3: Component Tokens (the specifics)
+Map semantic tokens to component contexts. Optional but valuable at scale.
+```
+--button-bg: var(--color-accent);
+--card-bg: var(--color-surface);
+```
+
+## Naming Convention
+
+`--{category}-{property}-{variant}-{state}`
+
+Categories: color, space, font, radius, shadow, motion. Never use hex values in names or ambiguous abbreviations.
+
+## Theming
+
+Dark mode is a semantic token remap:
+```css
+[data-theme="dark"] {
+  --color-surface: var(--color-grey-900);
+  --color-text-primary: var(--color-grey-100);
+}
+```
+Global tokens stay. Semantic tokens swap. Component tokens inherit.
+
+## Accessibility
+
+- Always define foreground/background pairs together and verify AA contrast
+- Motion tokens must include `--motion-duration-none: 0ms` for reduced-motion
+
+## What You Deliver
+
+- Token file (CSS custom properties, JSON, or both) with all three layers
+- Naming convention document
+- Theme variants if applicable
+
+## Integration
+
+- **Informed by:** `design-lead`, `ui-composition`
+- **Feeds into:** `design-builder`, `design-system-alignment`

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/ui-composition/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: ui-composition
+description: "Use when building layouts, choosing colours, setting typography, establishing visual hierarchy, designing responsive behaviour, or making any visual design decision — ensures every visual choice serves both aesthetics and accessibility"
+---
+
+# UI Composition
+
+Visual design is where intent becomes tangible. Every colour, every spacing decision, every typographic choice either includes or excludes people. This skill ensures visual decisions are principled, systematic, and inclusive.
+
+## When to Use
+
+- Designing screen layouts or page structures
+- Choosing or refining colour palettes
+- Setting typography systems
+- Establishing spacing and grid systems
+- Designing for responsive breakpoints
+- Creating or modifying visual hierarchy
+- Designing dark mode or high contrast variants
+
+## Process
+
+### Step 1: Reference the Foundation
+
+Before making visual decisions, confirm you have:
+- Design brief or strategy (from earlier phases)
+- Personas (especially ability spectrum considerations)
+- Existing design system (invoke `design-system-alignment` if one exists)
+
+### Step 2: Layout and Structure
+
+**Grid system:**
+- Define columns, gutters, and margins
+- Ensure the grid adapts across breakpoints (mobile, tablet, desktop)
+- Test that content reflows sensibly when zoomed to 200%
+
+**Visual hierarchy:**
+- Establish a clear reading order that works both visually and in the DOM
+- Ensure the hierarchy communicates through structure, not colour alone
+- Verify that removing all colour still leaves a readable, navigable page
+
+**Spacing system:**
+- Use a consistent spacing scale (e.g., 4px base)
+- Ensure touch targets are at least 44x44px
+- Provide adequate spacing between interactive elements to prevent accidental activation
+
+### Step 3: Colour
+
+**Palette construction:**
+- Define primary, secondary, neutral, and semantic colours (success, warning, error, info)
+- Every colour pairing must meet WCAG AA contrast ratios minimum (4.5:1 for text, 3:1 for large text and UI components)
+- Target WCAG AAA (7:1) where feasible
+
+**Colour independence:**
+- Never convey information through colour alone
+- Always pair colour with text labels, icons, or patterns
+- Test with simulated colour blindness (protanopia, deuteranopia, tritanopia)
+
+**Dark mode / high contrast:**
+- If applicable, design dark mode as a first-class experience, not an afterthought
+- Ensure all contrast ratios hold in both modes
+- Respect `prefers-color-scheme` and `prefers-contrast` media queries
+
+### Step 4: Typography
+
+**Type scale:**
+- Define a modular scale with clear hierarchy (heading levels, body, caption, label)
+- Base body size: minimum 16px (1rem)
+- Line height: 1.5 for body text, 1.2-1.3 for headings
+
+**Readability:**
+- Line length: 45-75 characters for body text
+- Paragraph spacing: at least 1.5x the font size
+- Avoid justified text (ragged right is more readable for most people)
+- Ensure text can be resized to 200% without loss of content or functionality
+
+**Font selection:**
+- Prioritise legibility over personality
+- Ensure the chosen font has distinct characters for I, l, 1 and O, 0
+- Provide fallback fonts in the same classification
+
+### Step 5: Responsive Design
+
+Design for these breakpoints (adjust to project needs):
+- **Mobile** (320-480px): single column, stacked layout, thumb-reachable interactions
+- **Tablet** (481-1024px): flexible layout, touch and pointer support
+- **Desktop** (1025px+): multi-column, keyboard and pointer optimised
+
+At every breakpoint:
+- Content priority remains correct
+- Touch targets remain adequate
+- Text remains readable without horizontal scrolling
+- No information is hidden that was visible at other breakpoints (unless intentionally progressive)
+
+### Step 6: Document Decisions
+
+For each visual decision, document:
+- **What:** the decision made
+- **Why:** how it serves the design principles and personas
+- **Accessibility:** how it meets inclusive design requirements
+
+## Integration
+
+- **Called by:** `writing-design-plans` (as part of plan execution)
+- **Pairs with:** `design-system-alignment` (for consistency), `cognitive-accessibility` (for visual load), `adaptive-interfaces` (for user preferences)
+- **Reviewed by:** `designpowers-critique`
+
+## Quick Reference: Accessibility Minimums
+
+| Element | Requirement |
+|---------|------------|
+| Text contrast | 4.5:1 (AA) or 7:1 (AAA) |
+| Large text contrast | 3:1 minimum |
+| UI component contrast | 3:1 against adjacent colours |
+| Touch target | 44x44px minimum |
+| Focus indicator | Visible, 3:1 contrast against adjacent |
+| Text resize | Content usable at 200% zoom |
+| Colour alone | Never the sole indicator of state or meaning |

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/usability-testing/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: usability-testing
+description: "Use when planning or conducting usability tests — writing test scripts, defining tasks, selecting participants, analysing findings, and turning observations into design actions"
+---
+
+# Usability Testing
+
+Testing with real people is how you find out if the design works — not by looking at it, but by watching someone use it.
+
+## When to Use
+
+- After design-builder produces a working prototype
+- Before declaring a design complete
+- When the design-critic flags persona coverage gaps
+- When assumptions about user behaviour need evidence
+
+## Process
+
+### Step 1: Define What You're Testing
+
+Write 3-5 task scenarios that map to the core jobs in the brief. Each task:
+- **Starts with a realistic trigger** — "You just bought a new plant and want to add it to the app"
+- **Has a clear success condition** — "The plant appears in your list with a watering schedule"
+- **Does not tell the user how** — never say "tap the + button"
+
+### Step 2: Select Participants
+
+Recruit 5-8 participants. At minimum include:
+- 1 person who uses a screen reader
+- 1 person over 60
+- 1 person who is not a native speaker of the interface language
+- 1 person with low tech confidence
+
+Reference `inclusive-personas` for the ability spectrum.
+
+### Step 3: Choose Method
+
+| Method | When to use | Minimum participants |
+|--------|-----------|---------------------|
+| Moderated think-aloud | New flows, complex interactions | 5 |
+| Unmoderated remote | Simple tasks, large sample | 8-12 |
+| Guerrilla (hallway) | POC validation, time-constrained | 3-5 |
+| Accessibility audit with AT users | After build, before ship | 2-3 |
+
+### Step 4: Write the Test Script
+
+1. **Welcome** — explain what you're testing (the design, not them)
+2. **Background** — 2-3 questions about their relationship to the problem
+3. **Tasks** — present each scenario one at a time, observe silently
+4. **Debrief** — "What was hardest?" "What would you change?"
+
+Never help during a task. Silence is data.
+
+### Step 5: Analyse Findings
+
+Classify outcomes per task:
+- **Completed easily** — no hesitation, no errors
+- **Completed with difficulty** — hesitation or errors but recovered
+- **Failed** — could not complete
+- **Completed wrong** — thought they succeeded but didn't
+
+Severity: Critical (blocks 2+ participants), Major (significant difficulty), Minor (noticed but not impeding).
+
+### Step 6: Turn Findings Into Actions
+
+Every finding becomes a design action: "[Severity] [What happened] → [Design action] → [Which agent handles it]"
+
+## What You Deliver
+
+- Task success rates table
+- Ranked findings by severity
+- Design actions with agent assignments
+- Recommendation: iterate / ship / rethink
+
+## Integration
+
+- **Informed by:** `inclusive-personas`, `design-discovery`
+- **Feeds into:** `design-lead`, `design-builder`, `design-strategist`

package/packages/shared-skills/skills/frontend/references/designpowers/vendor/skills/verification-before-shipping/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: verification-before-shipping
+description: "Use before declaring any design work complete, fixed, or ready — requires running verification and confirming output before making any success claims. Evidence before assertions, always"
+---
+
+# Verification Before Shipping
+
+Do not say it is done until you have proof. This skill prevents the most common failure mode in design work — declaring completion based on intent rather than evidence.
+
+## The Rule
+
+NEVER claim work is complete, fixed, passing, or ready without running verification and confirming the output. "I believe this works" is not verification. "I ran these checks and here are the results" is.
+
+## When to Use
+
+- Before declaring a design task complete
+- Before moving from one phase to the next
+- Before handoff to engineering
+- Before creating a PR or committing design artefacts
+- Any time you are about to say "done"
+
+## Process
+
+### Step 1: Check Against the Plan
+
+If a design plan exists:
+- [ ] Every task in the plan is marked complete
+- [ ] Every verification criterion in the plan has been met
+- [ ] No tasks were skipped or deferred without explicit user approval
+
+### Step 2: Check Against the Brief
+
+Reference the design brief:
+- [ ] The stated problem is addressed
+- [ ] All identified personas are served
+- [ ] Success criteria are met or measurable
+- [ ] Nothing in "out of scope" crept into scope (and vice versa)
+
+### Step 3: Accessibility Verification
+
+Run — do not guess:
+
+**If code exists:**
+- [ ] Automated accessibility scan (axe-core, Lighthouse, or equivalent) — report results
+- [ ] Keyboard navigation test — report results
+- [ ] Screen reader test (at minimum, check heading structure and form labels)
+- [ ] Zoom to 200% — report results
+- [ ] Check prefers-reduced-motion behaviour — report results
+
+**If design artefacts only:**
+- [ ] Contrast ratios verified with a tool (not by eye)
+- [ ] Touch targets measured (not estimated)
+- [ ] Heading hierarchy documented
+- [ ] All states designed (not just the happy path)
+
+### Step 4: Content Verification
+
+- [ ] All placeholder text has been replaced with real content
+- [ ] Error messages are written (not "TODO")
+- [ ] Alt text is present for all images
+- [ ] Labels are specific and descriptive
+
+### Step 5: Cross-Reference Personas
+
+For each persona from the inclusive-personas phase:
+- [ ] Could [Persona 1] complete the primary task? How?
+- [ ] Could [Persona 2] complete the primary task? How?
+- [ ] Could [Edge Case Persona] complete the primary task? What barriers remain?
+
+### Step 6: Check Design Debt
+
+Before declaring the project shippable, review the Design Debt Register in `design-state.md`:
+
+- [ ] All Critical and Major items are Resolved (not just Open or Escalated)
+- [ ] Any Escalated items have been addressed or consciously Accepted by the user
+- [ ] Open Minor items have been reviewed — the user knows what debt ships with this release
+- [ ] Accessibility debt items have explicit user acknowledgement if Accepted
+
+### Step 7: Report
+
+Present verification results to the user:
+
+```markdown
+## Verification Report: [Feature/Task]
+
+**Date:** [YYYY-MM-DD]
+
+### Plan Completion
+[All tasks complete / X tasks remaining]
+
+### Brief Alignment
+[Aligned / Gaps identified]
+
+### Accessibility Results
+- Automated scan: [Pass/Fail — specific issues]
+- Keyboard: [Pass/Fail — specific issues]
+- Screen reader: [Pass/Fail — specific issues]
+- Zoom: [Pass/Fail — specific issues]
+- Motion: [Pass/Fail — specific issues]
+
+### Content Status
+[Complete / Gaps identified]
+
+### Persona Walkthrough
+[Summary of persona-by-persona evaluation]
+
+### Design Debt Status
+- Open items shipping with this release: [count]
+- Escalated items: [count] — [resolved/accepted]
+- Accessibility debt accepted: [count] — [summary]
+- Oldest unresolved: [DD-XXX] from [date]
+
+### Verdict
+[Ready to ship / Issues to resolve first]
+```
+
+## Integration
+
+- **Called by:** Before any completion claim
+- **Follows:** `designpowers-critique`, `design-handoff`
+- **Blocks:** Completion claims, PR creation, merge decisions
+
+## The Iron Law
+
+If you cannot produce evidence that the design works for the identified personas — including those at the margins of the ability spectrum — it is not done. Go back and verify.