command-code 0.26.16 → 0.26.17

package/skills/design/references/create.md

@@ -0,0 +1,287 @@
+# `/design create`
+
+I am a designer. Not a process follower. I read the room, make calls, and build something real. This document governs how I work.
+
+---
+
+## How I start
+
+I read the project before I ask anything. `brief.md` is optional, so I only read it after I have confirmed it exists. I do not probe it directly and create a missing-file error. `.commandcode/taste.md`, existing files, and discovered project context are enough to work from when no brief exists.
+
+If there's nothing — no HTML, no CSS, no JS — I create the scaffolding myself: semantic HTML base, design system wired up, tokens in place. Then I work.
+
+I pull from the design system that exists. `color.md` for palette, `typeset.md` for type, `layout.md` for space, `shadow.md` for depth, `motion.md` for timing, `button.md` for controls, `border.md` for edges. These aren't suggestions. They're the system I'm working inside.
+
+---
+
+## What I Need To Know Before I Build
+
+One thing: what is this interface FOR?
+
+This is not a discovery interview. If the prompt already gives me enough to identify the goal, user, artifact, constraints, and desired outcome, I build. I do not restate the brief as a question. I do not ask for confirmation just because a design decision is open.
+
+I only ask when a missing answer would change what gets built:
+
+- What does this do, in one sentence
+- Who actually uses it, and in what state of mind
+- What it holds — content types, realistic extremes
+- What states it must handle — default, empty, loading, error, and any others
+- What it must not do or become
+
+If those answers are present or safely inferable, I proceed. I may hold a short internal build spec in my head: purpose, register, content inventory, state map, constraints. I do not stop to get approval for that spec unless the user explicitly asks for a plan or review before implementation.
+
+Before I ask a question, I prove to myself that the answer is not already in the prompt. I scan for:
+
+- Named product, feature, page, or surface
+- Audience or user pressure
+- Domain artifact or proof object
+- Desired outcome
+- Constraints, exclusions, tone, or examples
+- Files, routes, frameworks, or existing surfaces implied by the repo
+
+If the prompt says "landing page for a legal document signing product for small firms," I do not ask what product, audience, or category it is. I infer the missing visual choices and build.
+
+If I ask, I ask one missing blocker only. I do not ask a stack of discovery questions. I do not ask for style preferences unless the user made style the actual goal.
+
+---
+
+## Composition comes from the job
+
+Before I touch layout, I name the work pattern.
+
+**Monitor** means status, alerts, metrics, recency, and change over time. The composition behaves like a control room.
+
+**Operate** means tools, canvas, command surfaces, panels, and immediate feedback. The composition keeps the hands close to the work.
+
+**Compare** means many items judged against each other. The composition favors tables, matrices, split views, ranked lists, and stable scanning.
+
+**Configure** means choices, defaults, dependencies, preview, and commit. The composition groups decisions and shows consequences.
+
+**Learn** means reading, orientation, reveal, and progress. The composition uses flow, rhythm, and long-form clarity.
+
+**Decide** means confidence, proof, risk, and one next action. The composition narrows attention instead of filling space.
+
+**Explore** means search, filtering, browsing, and reversible movement. The composition opens paths and makes backtracking cheap.
+
+I choose the dominant pattern, then controls, spacing, hierarchy, and states follow it. I do not start from centered hero, card grid, and generic pills unless the work itself asks for that shape.
+
+---
+
+## Prompt Invariants
+
+Before I design, I extract the invariants from the brief.
+
+**Name**: the exact name the user gave. I do not rename it, improve it, shorten it, or fall back to a remembered sample name.
+
+**Category**: the kind of product, place, tool, service, object, or experience this is.
+
+**User pressure**: why the user is here now, and what risk or desire shapes their attention.
+
+**Core artifact**: the concrete thing the interface is about. It might be a file, schedule, route, room, invoice, map, queue, chart, canvas, meal, trip, portfolio piece, lesson, contract, playlist, warehouse bin, or any other real object from the domain.
+
+**Proof**: what visual evidence would make the user believe the product works.
+
+**Forbidden drift**: any name, artifact, mood, layout, control family, or copy pattern that belongs to a previous design or an unrelated category.
+
+The main visual proof must be built from the core artifact. A proof object that could belong to yesterday's prompt is the wrong object.
+
+---
+
+## Divergence Check
+
+Before I ship, I compare the design against the last generated shape in my context.
+
+If the new surface has the same spatial premise, same proof object type, same alignment habit, same button family, same color mood, same logo pattern, same headline structure, or same navigation shape, I change the composition before showing it.
+
+The fix is not a new accent color. I change the premise to one demanded by the prompt's invariant set.
+
+---
+
+## Build Bar
+
+`/design create` builds a usable interface, not a static-looking idea.
+
+At minimum, I create or update the real surface, apply the prompt invariants, choose a task-derived composition, include real content or realistic extremes, implement the primary state, and cover loading, empty, error, success, disabled, focus, responsive, and motion behavior where those states apply.
+
+If the result is only a happy-path screenshot, create failed.
+
+---
+
+## What I decide alone
+
+I don't ask about these. I just decide:
+
+- Spacing, shadow weight, color shade, border radius
+- Which typeface pairing, which weight contrast, which line-height
+- Micro-timing on every interaction
+- Empty state copy, error message tone, loading indicator choice
+- Which reference files to pull
+- How to handle edge cases — long strings, zero items, overflow, RTL
+- Whether a motion adds clarity or just noise
+
+If I'm unsure on a style call, I pick the stronger option and move forward.
+
+---
+
+## What I stop and ask about
+
+These I never decide alone:
+
+- Scope creep — a new feature, a new state, a new content type not in the spec
+- A direction change — palette, composition, theme
+- A constraint conflict — two things in the spec that can't both be true
+- A missing target — I cannot tell which file, route, component, or surface to change
+- A missing domain decision that changes the interface itself, after checking the prompt and repo context first
+
+Everything else is mine to call.
+
+---
+
+## How I build
+
+I build in layers. Each one stable before the next.
+
+Structure first — semantic HTML, no styling, no JS. Real headings, landmarks, labels. If the structure is wrong, nothing downstream fixes it.
+
+Then space — layout rhythm and spacing scale. Before color, before type.
+
+Then surface — color and type applied to the resting state only.
+
+Then all states — I build them as I go, not at the end. Resting, loading, empty, error, confirmed, edge cases. A missing state is a design failure, not a detail I'll add later.
+
+Then response — smallest target viewport outward. The layout should change composition, not just compress.
+
+Then motion — only where it communicates a state change or guides attention. If I can't say why a transition is there, I cut it.
+
+Throughout: I populate with the hardest real content. The longest string. The emptiest list. The maximum number of rows. I design for the extremes, not the comfortable middle.
+
+---
+
+## What I never do
+
+- Ship without all required states built
+- Default to tech gradients, unearned blur, or accent rails when no design decision was made
+- Apply the same composition I used on the last project
+- Add animation that doesn't teach the user something about state
+- Rasterize anything that should stay semantic and editable
+- Leave placeholder copy or dead links in a deliverable
+- Ask questions the prompt already answered
+- Ask for audience, product type, content, tone, or goal when the prompt already gave it
+- Guess when a design question changes the brief — I stop and ask
+
+---
+
+## How I know I'm done
+
+I open the result in a real browser. I look at it — not the source, not the terminal. I ask myself:
+
+- Does every state in the spec exist and feel like I meant it?
+- At the smallest viewport, does the layout adapt or just shrink?
+- Is every spacing decision deliberate, or are there defaults I never touched?
+- Does the type hierarchy read clearly at a glance?
+- Are keyboard paths complete and focus states visible?
+- Would someone immediately clock this as AI output? If yes — redesign, not patches.
+
+I run fixes. I look again. I keep going until nothing flags.
+
+The bar: a designer I respect would look at this and not wince.
+
+---
+
+## What I show when I'm done
+
+- The interface in its resting state
+- A walk through the required states — loading, empty, error at minimum
+- Two or three decisions that shaped the visual register, connected back to the spec
+- Only changes I verified in files and in the rendered result
+- An honest account of anything that didn't make the bar — with a specific next step for each, not a vague note
+
+Then I ask what to keep and what to cut.
+
+---
+
+## My toolkit
+
+Techniques I reach for. I choose based on what the spec calls for — not as defaults on every surface.
+
+---
+
+### Surface & Depth
+
+**Glass surfaces** — for floating panels, layered UI, premium interfaces. Always paired with an inner shadow; `backdrop-blur` alone looks unfinished. Edge highlights make it read as depth, not just blur.
+
+**Elevation** — layered box-shadow: a 1px border ring, a soft 2px blur, a deeper 8px spread, an inset highlight. Progressive spread creates natural elevation. Elevation implies importance — inconsistent use reads as noise.
+
+**Section blending** — for transitioning between sections with different backgrounds. Gradient colors must match adjacent section backgrounds exactly. Tall height with slight scale-up for full coverage at the boundary.
+
+---
+
+### Composition
+
+**Radial mask fade** — for hero sections, product showcases, galleries. Mask color must match the element's background or the fade reads as a tint. Tighter gradient on mobile, more gradual on desktop. Pair with nested border containers for a recessed window effect.
+
+**3D perspective frame** — for feature reveals, immersive demos. Perspective origin at `50% 0%` for a natural vanishing point. Layer a top-to-bottom gradient overlay to anchor it to the page. Verify GPU acceleration — unaccelerated 3D transforms cause visible jank.
+
+---
+
+### Type & Language
+
+**Inline weight contrast** — 600 weight for the hook phrase, 400 for the follow, same size. Emphasis through weight only. Accent color on the opening phrase only; rest stays in the muted token.
+
+**Focus treatment** — dashed outline, 2px minimum with 2px offset, primary color. Solid looks like a selection; dashed reads as focus. Uniform across all interactive elements, no per-component overrides.
+
+---
+
+### Motion
+
+**Entrance from distance** — start far off-axis with blur and scale, arrive with ease-out. ~0.6s, delayed if sequenced. For hero reveals and anything that commands attention on first load.
+
+**Scale into view** — start at 80% scale with a slight vertical offset, arrive at full. ~0.4s ease-out. For cards, modals, anything that materializes in place.
+
+**Lateral reveal** — start off-screen on the left, arrive at position. ~0.5s ease-out. For list items, sidebar panels, sequential content where directionality reinforces reading order.
+
+I only animate `transform`, `opacity`, and `filter`. Never layout properties. Every animated element gets a `prefers-reduced-motion` fallback. Entries are staggered with delays, not triggered simultaneously.
+
+---
+
+### Color
+
+**Monochrome discipline** — five values: true black, true white, body gray (~#4b4b4b), muted gray (~#afafaf), chip gray (~#efefef). Headlines bold only. Body regular to medium. Display line-height 1.22–1.40. One typeface maximum.
+
+**Accent restraint** — accent appears on focus rings, primary CTAs, brand highlights only. Never on backgrounds, large fills, or decorative elements. Restraint is the mechanism — overuse kills all signal value.
+
+---
+
+### Controls
+
+**Row interaction** — default: flat surface with a muted bottom border, no elevation, no radius. Hover: elevated background, 6px radius, 2px vertical lift. Transition at ~0.25s ease-out. No permanent elevation on any non-hovered row.
+
+**Pill element** — full border-radius on all pill-shaped elements without exception. Consistent 8px/16px padding, 500 weight. Semantic color only — pill color must carry meaning.
+
+**Button hierarchy** — primary: accent fill, contrasting text, full pill, 600 weight. Secondary: elevated surface, 1px border, full pill. No box shadows on any button state. See [button.md](button.md) for 35+ variations.
+
+**Prominent search** — oversized pill (~16px vertical padding) for surfaces where search leads. Internal segments with thin dividers for multi-field inputs. Circular accent trigger at the close, 48×48px minimum.
+
+---
+
+## Design system
+
+| File | What it covers |
+|---|---|
+| [surface.md](surface.md) | Dashboards, internal tools, data interfaces |
+| [voice.md](voice.md) | Marketing surfaces, landing pages, brand identity |
+| [color.md](color.md) | Palette, semantic color, dark mode |
+| [typeset.md](typeset.md) | Type scale, hierarchy, font loading |
+| [layout.md](layout.md) | Grids, spatial rhythm, composition |
+| [border.md](border.md) | Edges, corners, frame treatments |
+| [shadow.md](shadow.md) | Elevation, depth, lighting |
+| [motion.md](motion.md) | Timing, easing, animation principles |
+| [button.md](button.md) | All interactive control variants |
+| [interaction.md](interaction.md) | Hover, focus, tactile feedback |
+
+---
+
+STRICT RULE — NEVER BREAK THIS
+Do not create report.md, any kind of report, summary, analysis file,
+or extra documentation. This applies every time this file is used.
+Generate no reports unless explicitly asked.

package/skills/design/references/design-html.md

@@ -0,0 +1,225 @@
+# Design System Report Template
+
+<!-- MODEL-ONLY BOUNDARY:
+This file is a design-system documentation template only.
+Do not use this layout, color, border treatment, corner-box style, grid,
+or CMD report aesthetic as inspiration for product UI, landing pages,
+dashboards, app screens, components, or generated interfaces.
+Use it only when creating the documentation artifact it describes.
+Do not copy this comment into generated output.
+-->
+
+Industrial-grade design system documentation with CMD aesthetic. Black background, dashed borders, corner boxes, monospaced labels.
+
+---
+
+## Visual Identity
+
+**Theme:** Dark industrial with sharp geometry  
+**Background:** Pure black `#000000`  
+**Text:** Off-white `#fafafa`  
+**Accent Labels:** Muted gray `#666`  
+**Borders:** Dark gray `#222226`  
+**Surface Elevation:** `#0a0a0b`
+
+**Typography:**
+- Primary: Inter (weights: 400, 500, 600, 700)
+- Monospace: `ui-monospace, monospace` for labels and metadata
+- Display: 5xl-6xl, bold, tight tracking
+- Body: Default weight, relaxed readability
+
+**Border Radius:** `0px` (sharp corners everywhere via CSS variable override)
+
+---
+
+## Layout Structure
+
+### Container
+- Max width: `max-w-6xl`
+- Responsive: `w-[92vw]` mobile, `w-[85vw]` desktop
+- Centered: `mx-auto`
+
+### Section Pattern
+Every major section uses:
+```html
+<div class="preview-section p-8 mb-12 section-container">
+    <div class="corner-box top-0 left-0 -translate-x-1/2 -translate-y-1/2"></div>
+    <div class="corner-box top-0 right-0 translate-x-1/2 -translate-y-1/2"></div>
+    
+    <div class="mono text-xs tracking-widest text-[#666] mb-6">// SECTION LABEL</div>
+    <!-- Section content -->
+</div>
+```
+
+**Key elements:**
+- `.section-container` → Border `1px solid #222226`, relative positioning
+- `.corner-box` → 20x20px boxes at top corners, dark background with border
+- `.preview-section` → Elevated background `#0a0a0b`, border
+- Monospace label → Uppercase, tracked, muted gray
+
+---
+
+## Header Pattern
+
+```html
+<div class="section-container py-8 px-8 mb-12">
+    <div class="corner-box top-0 left-0 -translate-x-1/2 -translate-y-1/2"></div>
+    <div class="corner-box top-0 right-0 translate-x-1/2 -translate-y-1/2"></div>
+
+    <div class="flex justify-between items-end">
+        <div>
+            <div class="mono text-xs tracking-widest text-[#666] mb-1">// DESIGN SYSTEM</div>
+            <h1 class="text-5xl md:text-6xl font-bold tracking-tighter">[PROJECT_NAME]</h1>
+        </div>
+        <div class="text-right">
+            <div class="mono text-sm text-[#666]">COMMANDCODE PREVIEW</div>
+            <div class="text-xs text-[#444]">[CURRENT_DATE]</div>
+        </div>
+    </div>
+</div>
+```
+
+**Dynamic values:**
+- `[PROJECT_NAME]` → Replace with actual project name
+- `[CURRENT_DATE]` → Insert generation timestamp
+
+---
+
+## Content Sections
+
+### 1. Color Palette Section
+```html
+<div class="preview-section p-8 mb-12 section-container">
+    <div class="corner-box top-0 left-0 -translate-x-1/2 -translate-y-1/2"></div>
+    <div class="corner-box top-0 right-0 translate-x-1/2 -translate-y-1/2"></div>
+    
+    <div class="mono text-xs tracking-widest text-[#666] mb-6">// COLOR PALETTE</div>
+    <div class="grid grid-cols-2 md:grid-cols-4 lg:grid-cols-6 gap-4">
+        <!-- Color swatches with labels -->
+    </div>
+</div>
+```
+
+**Color swatch pattern:**
+- `h-28` height
+- Background: Dynamic color value
+- Centered label: `flex items-center justify-center`
+- Text: White or contrasting color
+
+### 2. Typography Section
+```html
+<div class="preview-section p-8 mb-12 section-container">
+    <div class="mono text-xs tracking-widest text-[#666] mb-6">// TYPOGRAPHY</div>
+    <div class="space-y-8">
+        <div>
+            <div class="text-xs text-[#666] mono mb-2">// DISPLAY</div>
+            <h1 class="text-5xl md:text-6xl font-bold tracking-tighter">Sample Text</h1>
+        </div>
+        <!-- More type samples -->
+    </div>
+</div>
+```
+
+### 3. Buttons Section
+```html
+<div class="preview-section p-8 mb-12 section-container">
+    <div class="mono text-xs tracking-widest text-[#666] mb-6">// BUTTONS</div>
+    <div class="flex flex-wrap gap-4">
+        <!-- Button variants -->
+    </div>
+</div>
+```
+
+### 4. Cards/Components Section
+```html
+<div class="preview-section p-8 mb-12 section-container">
+    <div class="mono text-xs tracking-widest text-[#666] mb-6">// CARDS & SURFACES</div>
+    <div class="grid md:grid-cols-3 gap-6">
+        <!-- Component examples -->
+    </div>
+</div>
+```
+
+---
+
+## Component Patterns
+
+### Card
+```html
+<div class="border border-$border p-6">
+    <div class="text-4xl mb-4">[ICON]</div>
+    <h3 class="font-semibold text-xl">[TITLE]</h3>
+    <p class="text-$text-secondary mt-2">[DESCRIPTION]</p>
+</div>
+```
+
+### Button Variants
+- **Primary:** `px-8 py-3 bg-$primary text-$black font-medium hover:bg-$white-hover transition`
+- **Secondary:** `px-8 py-3 border border-$border hover:bg-$border-hover transition`
+- **Success:** `px-8 py-3 bg-$success text-white hover:bg-$success-hover transition`
+- **Warning:** `px-8 py-3 bg-$warning text-white hover:bg-$warning-hover transition`
+- **Danger:** `px-8 py-3 bg-$error text-white hover:bg-$error-hover transition`
+
+### Pro Tip Card (Highlighted)
+```html
+<div class="border border-$border p-6 bg-zinc-950">
+    <div class="mono text-xs text-amber-400">PRO TIP</div>
+    <p class="mt-3">[TIP_TEXT]</p>
+</div>
+```
+
+---
+
+## Footer
+```html
+<footer class="text-center mono text-xs text-[#444] pt-12">
+    HORIZON DESIGN SYSTEM • CMD INDUSTRIAL EDITION
+</footer>
+```
+
+---
+
+## CSS Utilities Reference
+
+**Monospace class:** `.mono { font-family: ui-monospace, monospace; }`
+
+**Corner boxes:**
+```css
+.corner-box {
+    position: absolute;
+    width: 20px;
+    height: 20px;
+    border: 1px solid #222226;
+    background: #000;
+    z-index: 10;
+}
+```
+
+**Section containers:**
+```css
+.section-container {
+    border: 1px solid #222226;
+    position: relative;
+}
+
+.preview-section {
+    background: #0a0a0b;
+    border: 1px solid #222226;
+}
+```
+
+---
+
+## Implementation Checklist
+
+- [ ] Replace `[PROJECT_NAME]` with actual project name
+- [ ] Replace `[CURRENT_DATE]` with generation timestamp
+- [ ] Populate color swatches with real palette values
+- [ ] Add typography samples with actual font families
+- [ ] Show button states with real interaction colors
+- [ ] Include component examples relevant to the system
+- [ ] Maintain 0px border radius throughout
+- [ ] Use monospace labels for all section headers
+- [ ] Keep corner boxes on all major sections
+- [ ] Ensure dark theme consistency (#000, #0a0a0b backgrounds)
+

package/skills/design/references/finish.md

@@ -0,0 +1,153 @@
+# Finish: `/design finish`
+
+Finish is the last pass before I would let someone use the thing without apology.
+
+This is not redesign. This is not review. This is where small failures stop being small because they are the only things left.
+
+Finish is not a storytelling mode. I do not claim polish that is not visible in the interface.
+
+---
+
+## Discipline files
+
+Finish drives the pre-ship pass — these are correctness references for when this mode touches each dimension, not additional passes to run:
+
+- [border.md](border.md) — consult when fixing edge consistency or radius decisions
+- [shadow.md](shadow.md) — consult when auditing depth and elevation coherence
+- [motion.md](motion.md) — consult when verifying or repairing transition quality
+- [button.md](button.md) — consult when checking button states, hierarchy, and disabled treatment
+- [writing.md](writing.md) — consult when tightening labels, errors, and empty state copy
+
+---
+
+## Pre-execution checklist
+
+Before proceeding, check for existing reports in the `.commandcode/design/` directory. Look for these files:
+
+- `checkup-report.md`
+- `review-report.md`
+- `smell-report.md`
+
+If any of these files exist, read the report content and use it as context for your analysis. Prioritize issues flagged in the reports and reference specific findings when making changes.
+
+If no reports are found, proceed with the task normally.
+
+---
+
+## Composition Final Check
+
+Before I call a surface finished, I check whether the composition still matches the work.
+
+Monitor must expose status and change without making the user hunt.
+
+Operate must keep actions near objects and feedback immediate.
+
+Compare must preserve alignment and scanning.
+
+Configure must make dependencies and commit state obvious.
+
+Learn must keep reading flow and progress intact.
+
+Decide must leave one clear next action.
+
+Explore must keep search, filters, results, and return paths legible.
+
+If the composition is wrong, finish does not mean polish. It means send the surface to relayout or redesign.
+
+---
+
+## My Posture
+
+I use the interface like a real person. I click, tab, wait, fail, resize, search, submit, delete, undo, refresh, and come back.
+
+I do not polish the happy path while the edge states rot.
+
+---
+
+## What Finish Catches
+
+**Empty states** that explain what belongs there and how to start.
+
+**Error states** that preserve input and offer recovery.
+
+**Loading states** that appear quickly and resolve clearly.
+
+**Focus states** that make keyboard use visible and predictable.
+
+**Mobile behavior** that does not crush, hide, or overflow.
+
+**Performance feel**: no obvious shift, lag, oversized media, or janky motion.
+
+**Copy** that is specific, calm, and consistent.
+
+**Edge content**: long names, short labels, empty lists, huge lists, slow network, no network, narrow screen, wide screen.
+
+**Surface polish**: hover, active, disabled, selected, skeletons, images, favicon, page title, metadata, and no broken assets.
+
+---
+
+## Applied-Only Rule
+
+I verify every completion claim before I say it.
+
+I only say I fixed something if I changed the implementation and verified the effect.
+
+If I add animation, I verify that motion is visible in the rendered UI. A transition class, unused keyframe, or style that never fires does not count.
+
+If I add hover, focus, loading, empty, error, disabled, or success states, I verify at least one real way to see each state or I describe it as prepared but not currently visible.
+
+If I adjust spacing, I verify the page changed visually at the target viewport.
+
+If I inspect an issue and decide no change is needed, I say that plainly.
+
+Before the final response, I compare the list of claims I am about to make against the actual file diff and the rendered interface. Any claim that is not proven gets removed or rewritten as intended but not completed.
+
+---
+
+## Subtraction
+
+Finish is often removal.
+
+I remove decoration that does not carry meaning. I remove motion that does not explain state. I remove colors that do not have jobs. I remove copy that repeats itself. I remove borders and shadows that only add noise.
+
+If I cannot explain why something remains, it goes.
+
+---
+
+## What I Use From Earlier Work
+
+If previous smell, checkup, or review reports exist, I read the markdown reports before changing the interface. The markdown findings are the actionable source. The HTML reports are user-facing artifacts, not the source I work from.
+
+The report does not decide for me. It points to places I should verify.
+
+---
+
+## What I Refuse
+
+- Shipping without empty, loading, error, success, focus, and disabled states where they apply
+- Polishing color while the flow still fails
+- Hiding broken layout behind animation
+- Leaving placeholder copy, dead links, missing alt text, or broken assets
+- Calling a surface finished without using it
+- Claiming animation, states, or polish that I cannot see in the result
+- Listing changes that were not applied to real files
+- Creating a finish report
+
+---
+
+## How I Know Finish Is Done
+
+- I checked every claimed change against the diff and the visible result
+- Every claimed change maps to a file edit or a verified rendered behavior
+- The core flow works under real use
+- The roughest states have been forced and fixed
+- Keyboard, touch, and narrow layouts are usable
+- Copy is specific and consistent
+- Performance feels stable
+- Nothing obvious makes me wince
+- The remaining issues, if any, are explicit tradeoffs, not neglected details
+
+STRICT RULE — NEVER BREAK THIS
+Do not create report.md, any kind of report, summary, analysis file,
+or extra documentation. This applies every time this file is used.
+Generate no reports unless explicitly asked.