devrites 1.19.0

package/pack/.claude/skills/rite-polish/reference/anti-ai-slop.md

@@ -0,0 +1,177 @@
+# Anti-AI-slop
+
+Tells of generic LLM-generated work — in **UI** and in **code**. Applies at two stages:
+
+- **At build time** (preventive) — `/rite-build` checks against these as it writes; the
+  cheap moment to avoid them.
+- **At polish time** (catch) — `/rite-polish` Phase 1 (Code) + Phase 2 (Backend) + Phase 4
+  (UI) scrub anything that slipped through.
+
+Avoid these unless the project's existing system explicitly uses them. When in doubt,
+match the neighbors.
+
+## UI anti-slop (banned defaults)
+- Default **purple/blue gradients** as the brand look. Special case: any
+  hero hex in the `#6366f1 → #a855f7 → #ec4899` family applied as a default.
+- **Gradient text** (`background-clip: text`) used decoratively on headings.
+- **Glassmorphism** (`backdrop-filter: blur(...)` on translucent panels) as
+  a default surface.
+- **Side-stripe colored borders** on cards/sections — the
+  "tiny-bar-of-meaningful-accent-color-on-the-left" pattern. Distinctive
+  templating tell.
+- **Pure `#000` / `#fff`** as raw text or background — too clinical; use
+  near-black/near-white tokens (`oklch(0.18 0 0)` / `oklch(0.98 0 0)` or
+  the project's surface tokens).
+- **All-CAPS body text** for paragraphs/labels. Reserve uppercase for short
+  micro-copy (badges, eyebrows); never for sentences.
+- **Em-dash overuse** in UI copy — multiple em-dashes per paragraph, em-
+  dashes where a comma or period would do. A clear AI tell.
+- **Cards inside cards** — nested bordered/elevated containers.
+- **Identical card grids** for everything, regardless of content.
+- A **generic rounded-square icon tile** above every heading/section.
+- **Gray text on colored backgrounds** (fails contrast, looks templated).
+- The **hero-metric cliché** — three big numbers in a row with no real meaning.
+- **Decorative bounce / elastic easing** on everything; motion without purpose.
+- **Reflex fonts** picked because they're the default in a tutorial:
+  - Inter for every product when the project has its own choice.
+  - **DM Sans**, **Plus Jakarta Sans**, **Fraunces**, **Newsreader** when
+    they're not the project's actual type system.
+  Match the project; don't reach for the "tasteful default" of 2024.
+- **Modal-first thinking** — reaching for a modal as the answer to every interaction.
+
+### Category-reflex check — run at two altitudes
+
+Most generic-AI design fails one of these two reflex tests. Run both — the
+second one catches what the first one misses.
+
+- **First-order:** if someone could guess the theme + palette *from the
+  category alone* — "observability → dark blue", "healthcare → white +
+  teal", "fintech → navy + gold", "AI tool → black with a violet accent",
+  "crypto → neon on black" — the styling is on the first training-data
+  reflex. Rework the scene sentence
+  (`devrites-frontend-craft/reference/design-references.md`) and the
+  colour-commitment strategy
+  (`devrites-frontend-craft/reference/quality-standards.md`) until the
+  answer isn't obvious from the domain.
+- **Second-order:** if a stranger looked at the surface with *no copy
+  visible* and confidently said "this is a CRM / fitness tracker / fintech
+  / AI workflow tool", the styling is still on a category template — just
+  one tier deeper. The first reflex was avoided, the second wasn't.
+  Re-shape until the surface doesn't telegraph its category from looks
+  alone.
+
+Both pass = the surface looks like *this product*, not "an app in this category".
+
+## Code anti-slop (UI **and** backend)
+- **Over-defensive checks** — `if (x && x.length > 0)` repeated, layered null guards,
+  belt-and-braces nullability the surrounding code already proves. Signals lack of
+  confidence in the flow.
+- **Blanket `catch` / "robust" error handling** that swallows errors or wraps them in
+  generic "Something went wrong." Hides bugs. Catch narrow; rethrow with context; fail
+  closed on auth/permission/transaction.
+- **Useless wrapper functions** — `function getUser(id){ return User.find(id); }` adds a
+  hop with no value. Inline or remove.
+- **Over-engineered abstractions** for trivial problems — a factory + interface + plugin
+  registry for a 10-line function. **Don't add abstraction before two real callers**
+  (see `coding-style.md`, `patterns.md`).
+- **Convention-blind** code — ignores the repo's naming, file layout, error patterns,
+  validation style. "Generic good code" beats the project's idiom; reuse first (see
+  `coding-style.md`).
+- **Going beyond the spec** — features/options/configs/flags the spec didn't ask for.
+  Implement exactly what was specified; flag extras as follow-ups.
+- **Comment noise — the most common code tell.** Default to **zero** comments; the code and
+  the names carry the meaning. A comment earns its place only by answering *why* in one
+  sentence (intent, a trade-off, a non-obvious constraint, a "here be dragons" warning). Cut
+  every comment that restates the code:
+  - *What-comments* — `// increment i by 1`, `// set the user name`, `// return the result`.
+  - *Tutorial comments* — `// loop through the array` over a `.forEach`; `// check if null`.
+  - *Sycophant / filler* — `// helper function`, `// this is important`, `// magic happens here`.
+  - *Ownerless TODOs* — `// TODO: improve this later` with no issue/owner.
+  - *Meta / edit-process comments* — the agent narrating its own edit: `// Now I'll add error
+    handling`, `// Updated to handle the edge case`, `// As requested`, `// Step 1: … Step 2:`.
+    The reader doesn't care how the diff was produced.
+  - *Hedging / apologetic / overconfident comments* — `// should work`, `// hopefully handles
+    this`, `// I think`, `// hacky`, `// sorry`, or `// obviously` / `// just` / `// trivial`.
+    They admit the code is unverified (or paper over it). Verify the code; delete the doubt.
+  Density smell: more than roughly **one comment per ~10 lines of straightforward code** means
+  you are narrating, not explaining. Rename the thing or delete the comment.
+- **Names must match the contract.** A name is a promise about what the symbol does — keep it
+  honest. A `validateUser()` that actually checks payment status, an `isReady` that mutates
+  state, a `getUser()` that also writes a log: the name lies. Models pick names that *sound*
+  plausible for the category; verify the name says what the code does.
+- **Generic AI naming** — `process_data`, `handle_thing`, `do_it`, `result`, `data`,
+  `temp`, `manager`, `helper`, `util2`. Name for *intent*, in the repo's casing and idiom —
+  not for the action's category.
+- **Premature config** — feature flags / config knobs / extension points with no current
+  user.
+- **Dead leftovers** — TODOs without an owner/issue, commented-out code, unused imports,
+  `console.log`s, debug prints.
+- **Hallucinated imports & APIs** — an import of a package or module the project doesn't
+  declare (absent from the manifest/lockfile) or that doesn't exist, and invented methods or
+  parameters on a real library. Unused imports are dead code; *non-existent* ones are the model
+  inventing dependencies. Verify every import resolves and every unfamiliar API exists at the
+  source (`devrites-source-driven`) — never invent one.
+- **Placeholder bodies posing as complete** — a function that looks implemented but only does
+  `pass` / `...` / `return None` / `throw NotImplementedError` / returns a constant. It promises
+  functionality that isn't there. A genuine `@abstractmethod` / interface / Protocol stub is
+  fine — the slop is the stub pretending to be the real implementation.
+- **Fake or inflated docstrings** — a generic "This function does X" / "Handles the logic" that
+  restates the signature, or a 10-line docstring over a 2-line body. A real public-API docstring
+  earns its place; the slop is the one that inflates or says nothing. Follow the project's doc
+  convention either way.
+- **Oversized units (smell, not a hard gate)** — a function past ~50 logical lines, cyclomatic
+  complexity >10, more than ~4 parameters, or nesting ≥4 deep is a god-function smell. Split it
+  or flatten with guard clauses; judge in context, don't game the metric.
+- **Unexplained magic constants** — a bare literal, a hardcoded URL/endpoint, or an embedded
+  account/provider/test ID inline with no name or source. Give it a name (a const) or a home
+  (config/env). The mirror image of premature config, and just as much a tell.
+- **Copy-paste duplication** — a near-identical block pasted and tweaked instead of reused.
+  Reuse → extend → build new (`coding-style.md`, `patterns.md`); duplication beats the *wrong*
+  abstraction, but pasted clones are slop, not a deliberate AHA call.
+
+### Comment density — before / after
+
+```js
+// Before (slop): a comment narrating almost every line
+function calculateTotal(items) {
+  // initialize the total to zero
+  let total = 0;
+  // loop through each item in the items array
+  for (const item of items) {
+    // add the item price to the total
+    total += item.price;
+  }
+  // return the final total
+  return total;
+}
+
+// After: the names carry it; no comment needed
+function sumPrices(items) {
+  return items.reduce((total, item) => total + item.price, 0);
+}
+
+// A comment that earns its place — it explains WHY, not what:
+// Prices are in minor units (cents); the gateway rejects fractional amounts.
+const total = sumPrices(items);
+```
+
+## Why these are banned
+They signal "a model generated this" rather than "this team designed/wrote this." They
+ignore the product's register and the project's idiom, add noise, hide bugs (defensive
+catches), bloat the diff (over-engineering, beyond-spec), and often fail accessibility
+or correctness review. They're cargo-cult, not craft.
+
+## What to do instead
+- **UI**: project tokens / shared components / consistent type & spacing
+  (`design-system-discovery.md`); content shapes layout; motion serves feedback;
+  reserve modals for focused interrupting tasks.
+- **Code**: validate at trust boundaries (don't sprinkle null checks); catch narrow,
+  recover or rethrow; one clear name per concept; one responsibility per function;
+  reuse before write (`coding-style.md`); implement exactly the spec; let inherent
+  complexity be — don't pad with ceremony.
+- If the project **does** use one of these intentionally, follow the project. Consistency
+  beats the rule.
+
+## When in doubt: ask
+A "robust" check or shiny abstraction you can't justify in one sentence is probably slop.
+Delete it; or ask the user if it should exist.

package/pack/.claude/skills/rite-polish/reference/anti-patterns.md

@@ -0,0 +1,27 @@
+# rite-polish — anti-patterns
+
+Load this when standing a non-trivial polish decision, or when tempted to
+skip normalize, polish without Chesterton's Fence, or cite clean lint/build
+as proof of quality.
+
+Pack-wide rationalizations + red flags (incl. lint-pass-as-quality): see
+[rules/anti-patterns.md](../../../rules/anti-patterns.md).
+
+## Phase-specific rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "Tests pass; the feature is done." | Tests don't measure ship-quality, design drift, anti-slop, or backend polish. |
+| "UI looks fine to me." | Must align to the design system + meet CWV/WCAG 2.2 — not match a personal taste. |
+| "Code is simple enough; no need to audit." | Measure first. If there's no hotspot, that's fine — but record "no hotspots found", don't skip silently. |
+| "It's a small UI change; polish without normalize is fine." | **NO** — decoration on drift is banned. Phase 3 runs before Phase 4, always. |
+| "Backend looks OK; skip Phase 2." | If the diff touched BE, Phase 2 runs — error responses, logging hygiene, queries, anti-slop. |
+
+## Red Flags
+
+- About to polish UI (Phase 4) without running normalize (Phase 3) first.
+- No browser evidence saved for a UI polish.
+- Code polish ran without naming a single technique (guard clauses, Extract Method, ...).
+- Backend was touched but `polish-report.md` shows no Phase 2 section.
+- A "simplification" that changes observable behavior — that's not behavior-preserving.
+- Reading a Chesterton's Fence as "looks dead" and deleting without explaining what it guards.

package/pack/.claude/skills/rite-polish/reference/backend-polish.md

@@ -0,0 +1,80 @@
+# Backend polish (when backend touched)
+
+Runs as Phase 2 of `/rite-polish` when the feature touches server-side code — handlers /
+controllers / services / routes / models / migrations / queries / jobs / workers / auth /
+schemas. Polishes the **server side** to ship-quality before review, the way UI normalize
++ polish does for the client side.
+
+## Scope detection (BE is in scope if any of these are touched)
+- API/route handlers (REST/GraphQL/gRPC); controllers/services/middleware.
+- DB layer: models, queries, migrations, schemas, ORM calls.
+- Auth/session/permission code; trust-boundary checks.
+- Background jobs, workers, schedulers, queue handlers.
+- Server-side files in the project's language (`.rb`/`.py`/`.go`/`.rs`/`.java`/`.cs`/
+  `.php`/`.ts`-server etc.) outside the UI layer.
+
+## Polish checklist
+
+### Error handling (consistent + meaningful)
+- [ ] **Consistent error response shape** across endpoints (e.g. an RFC 7807 problem
+      document or the project's existing convention). One shape — not three.
+- [ ] **Correct HTTP / protocol status codes** (4xx for client errors, 5xx for server
+      errors; not 200 with `{ error: ... }`).
+- [ ] **Custom error classes** (or equivalent) so callers can distinguish error kinds.
+- [ ] **Fail closed** on auth/permission/transaction errors — deny + roll back; never
+      default to allow or partial commit (`error-handling.md`, `security.md`).
+- [ ] **Narrow `catch`** — no blanket `catch (e) {}` swallows. If you catch, recover or
+      rethrow with context.
+
+### Logging hygiene
+- [ ] **Structured logs** (key/value or JSON) with **context** — request id, user/actor
+      id, operation, duration.
+- [ ] Log the **events that matter**: failures, access violations, validation rejections,
+      retries, auth events.
+- [ ] **Never log** secrets, tokens, full credentials, PII, full request bodies for
+      sensitive endpoints. Mask or omit.
+- [ ] No `console.log` / debug prints left in. No noisy "got here" lines.
+
+### Data & queries
+- [ ] **No N+1** — fetch in batches / use joins or includes.
+- [ ] **No unbounded result sets** — pagination/limits where data can grow.
+- [ ] **Parameterized queries** only; never string-built SQL/shell/HTML.
+- [ ] **Indexes** exist for new query patterns (or recorded as a follow-up if the project
+      adds them by migration).
+- [ ] **Transaction boundaries** are right — one logical write = one transaction; rollback
+      on error; no partial commits.
+- [ ] Don't return more fields than the caller needs.
+
+### API contract
+- [ ] Response shape matches the contract the spec set (and what the UI / consumers
+      expect — match against `references/` if any).
+- [ ] **Idempotency** where applicable (PUT/DELETE; retry-safe POSTs with idempotency
+      keys).
+- [ ] **Pagination, sorting, filtering** consistent with neighboring endpoints.
+- [ ] **Validation at the boundary** — type/length/format/range on untrusted input;
+      reject what doesn't match (see `security.md` three-tier).
+
+### Performance (measure first)
+- [ ] Hot-path work measured; obvious wins (cache, batch, hoist) applied; perf claims
+      cite a number (`devrites-audit perf`).
+- [ ] No accidental quadratic loops over growing collections.
+
+### Cleanup
+- [ ] **Dead routes / unused endpoints** removed if this feature created them and they're
+      unused.
+- [ ] Naming + comments in touched server code: clear, intent-revealing, no fake-helpful
+      "// gets the user" lines.
+- [ ] No leftover `TODO`s without an owner/issue.
+- [ ] **Migrations** are reversible where reasonable; destructive ones have rollback notes.
+
+### Anti-slop (code patterns — see `anti-ai-slop.md`)
+- [ ] No over-defensive null/length checks layered redundantly.
+- [ ] No useless wrapper functions ("`function getUser(id) { return User.find(id); }`").
+- [ ] No generic AI naming (`process_data`, `handle_thing`, `do_it`).
+- [ ] No "robust" code that catches everything and hides bugs.
+- [ ] Didn't go **beyond the spec** — implemented what the spec asked, no extras.
+
+## Rules
+- Feature scope only. Don't refactor unrelated server code.
+- Re-prove after changes: targeted tests + a real request/response observation.
+- A polish change that breaks a test isn't behavior-preserving — revert and reconsider.

package/pack/.claude/skills/rite-polish/reference/browser-polish-evidence.md

@@ -0,0 +1,31 @@
+# Browser polish evidence
+
+Polish claims need visual proof. When a browser can run, capture evidence via the proof
+ladder (`devrites-browser-proof`) and record it in `browser-evidence.md` (and summarize
+in `polish-report.md`).
+
+## Required when a browser can run
+- Screenshots of the polished UI at the target viewports (375 / 768 / 1280 as relevant).
+  **Open each screenshot and describe what's actually visible** — a path is not proof.
+- All key interaction states captured or exercised: hover, focus, active, disabled,
+  loading, empty, error, success.
+- Console clean (no errors/warnings) — captured.
+- No layout shift on load — observed.
+- Reduced-motion behavior checked if motion was added.
+- **Design references**: if the spec saved references in `.devrites/work/<slug>/references/`,
+  compare the polished UI against them — does it match the agreed target? Note any diffs.
+
+## Before/after
+Where polish changed something visible, capture a **before/after** pair. The pair is the
+evidence that the change is real and an improvement, not a regression.
+
+## If no browser is available
+- Record the limitation explicitly in `browser-evidence.md`.
+- Write the exact manual steps to verify (route, viewport, what to look for in each
+  state).
+- Do **not** claim the polish is verified. Mark it **pending (manual)** and let
+  `/rite-review` / `/rite-seal` weigh the UI risk.
+
+## Never
+- Cite "lint clean" / "build passed" / "no type errors" as evidence of *visual* quality.
+- Assert a state works without exercising it.

package/pack/.claude/skills/rite-polish/reference/code.md

@@ -0,0 +1,85 @@
+# Code + backend polish (Phase 1 + Phase 2)
+
+Loaded from `/rite-polish` every run, regardless of UI scope. Two sub-phases:
+code polish (Phase 1) and, when backend is touched, backend polish (Phase 2).
+
+## Rules consulted (read on demand from `.claude/rules/`)
+
+- `coding-style.md` — Phase 1 (simplify, dead code, naming, comments).
+- `patterns.md` — Phase 1 simplification — avoid over-engineering.
+- `error-handling.md` — Phase 2 backend (no silent catches, consistent errors).
+- `performance.md` — Phase 2 backend (N+1s, query bounds).
+- `documentation.md` — keep touched docs current; record polish-time decisions.
+
+## Operating rules
+
+- **Never cite clean automation** (lint/build pass) as proof of good design or
+  simplicity.
+- Feature scope only. Spec Drift Guard applies.
+- Re-run targeted tests after each change — a simplification that breaks a
+  test wasn't behavior-preserving.
+
+## Phase 1 — Code polish *(always)*
+
+Delegates the audit to `devrites-audit simplify`. Reduce complexity in the
+feature's touched code while **preserving exact behavior**. Scope = active
+feature only.
+
+- **Measure first, target hotspots** — deep nesting, long branchy functions,
+  high cyclomatic complexity, sprawling conditionals. Don't redistribute
+  complexity, reduce it. Untargeted cleanup just moves decision points around.
+- **Behavior-preserving techniques** (name the one used per change): guard
+  clauses (flatten nested if/else, return early on unwanted cases), Extract
+  Method (a coherent block into a named single-responsibility helper), simplify
+  conditionals (switch/lookup over a long if-else; decompose a complex boolean
+  into well-named parts), dedupe, inline single-use indirection, replace
+  hand-rolled utils with the stdlib/existing helper, delete dead code this
+  feature added.
+- **Chesterton's Fence** — understand *why* something exists before removing it.
+  If you can't explain a check, branch, or wrapper, you may not remove it —
+  many "useless" lines guard a real edge case.
+- **Behavior preservation** — observable behavior stays identical; tests stay
+  green. If behavior would change, it's not simplification — it needs its own
+  acceptance + proof (and maybe drift handling). Prefer transformations with
+  obvious equivalence.
+- **Don't over-reduce / proportionality** — inherent complexity is fine;
+  readability is the goal, not a metric. Forcing the complexity number down by
+  *hiding* branches elsewhere is worse. Don't spend disproportionate effort on
+  small, stable, rarely-touched code; target central/often-read code.
+- **Guardrails** — feature scope only, no project-wide refactor; don't delete
+  suspected dead code **outside** this feature without asking; re-prove after
+  simplifying (a simplification that breaks a test wasn't behavior-preserving);
+  cleverness that's shorter but harder to read is not simpler.
+- **Cleanup**: remove TODOs, `console.log`s, commented-out code, unused
+  imports/vars; tighten naming and comments in code this feature touched.
+
+## Phase 2 — Backend polish *(if BE touched)*
+
+See [backend-polish.md](backend-polish.md). For server-side scope (handlers,
+services, routes, models, migrations, queries, jobs, auth). Polish the server
+side to ship-quality:
+
+- **Error responses consistent** + correct status codes + custom error classes
+  + fail closed on auth/permission/transaction errors. No blanket `catch`es.
+- **Logging hygiene** — structured logs with context (request id, user, op);
+  log key events; **never** log secrets / tokens / PII. No leftover
+  `console.log` / debug prints.
+- **Data & queries** — no N+1, no unbounded result sets, parameterized
+  queries, right transaction boundaries, return only what the caller needs.
+- **API contract** matches the spec (and any saved `references/`); idempotency
+  where applicable; consistent pagination/sorting/filtering; validation at the
+  boundary.
+- **Performance** — measure-first; obvious wins applied; no quadratic loops on
+  growing collections (`devrites-audit perf`).
+- **Cleanup** — remove dead routes, unused endpoints + bad naming this feature
+  added.
+- **Code anti-slop** — kill over-defensive layered null/length checks, useless
+  wrappers, generic AI naming, "robust" catches that hide bugs, anything
+  outside the spec ([anti-ai-slop.md](anti-ai-slop.md) — Code section).
+
+## Output → appends to `polish-report.md`
+
+```
+Phase 1 (code polish): findings → fixes (technique + why behavior preserved)
+Phase 2 (backend polish): error/log/data/API/cleanup fixes | n/a (no backend)
+```

package/pack/.claude/skills/rite-polish/reference/design-system-discovery.md

@@ -0,0 +1,35 @@
+# Design-system discovery
+
+Before touching UI, learn the system that already exists. Read it from the codebase —
+don't impose a generic one.
+
+## Register first
+Decide the surface's **register** (drives every other rule):
+- **Brand surface** — landing, marketing, portfolio, campaign. More expressive type,
+  larger scale contrast, motion welcome.
+- **Product surface** — dashboard, admin, settings, app UI, tools. System fonts are
+  legitimate; one family often suffices; fixed rem scale; tighter ratio (1.125–1.2);
+  density is a feature.
+
+## What to discover
+| Thing | Where to look |
+|---|---|
+| Design docs | `PRODUCT.md`, `DESIGN.md`, `docs/design/*`, Storybook |
+| Tokens | `tailwind.config.*`, CSS custom properties, `theme.*`, tokens files |
+| Shared components | components/ui dir, design-system package, imports neighbors use |
+| Spacing scale | the spacing tokens / Tailwind scale actually in use |
+| Type scale | heading/body sizes, font families, weights in use |
+| Color roles | semantic names (primary/surface/muted/danger), not raw hexes |
+| Icon set | the one icon library already imported |
+| Interaction patterns | how existing buttons/menus/dialogs/toasts behave |
+| Form patterns | label placement, validation, error display in existing forms |
+| Neighboring screens | the closest existing feature — match its flow shape |
+
+## Rules
+- Use existing tokens/components **first**. A hard-coded value where a token exists is
+  drift.
+- Don't add a second component library or icon set without asking.
+- Match the closest neighbor's IA and flow shape rather than inventing a new one.
+- **Default vs departure**: preserve the existing identity (default, ~90% of cases).
+  Reject it only on an explicit signal — a design doc that points at *this* surface as
+  the failure, or the user asking to rebuild it. If unsure, you're in default mode.

package/pack/.claude/skills/rite-polish/reference/harden-checklist.md

@@ -0,0 +1,109 @@
+# Harden checklist — UI against real-world inputs
+
+Designs that only work on the happy path are not production-ready. `/rite-polish`
+Phase 2 (UI polish) uses this list to harden the feature against the inputs, errors,
+languages, and network conditions real users will throw at it.
+
+Feature scope only — don't harden screens this feature doesn't touch.
+
+## 1. Extreme content (the input axis)
+
+Walk every text-bearing surface in the feature with deliberately hostile data:
+
+- **Very long text** — names of 200+ chars, descriptions of 5000+ chars, titles
+  longer than the viewport. Check truncation, wrapping, ellipsis, overflow.
+- **Very short / empty text** — single-char names, empty strings, names that are
+  whitespace only. Check whether layout collapses or filters fail.
+- **Unicode** — emoji (`👨‍👩‍👧‍👦` — note grapheme clusters in count limits),<!-- pack-scan-ignore: intentional ZWJ in emoji edge-case example -->
+  zero-width joiners, RTL text (`مرحبا`), combining accents (`café` vs `café`).
+- **Numerics at scale** — `0`, negative numbers, `1.000.000`, `1234567890`, very
+  large currency. Check column width, formatter behaviour, locale separators.
+- **List sizes** — empty list, 1 item, 50 items, 1000+ items. Check pagination,
+  virtualisation, empty state, loading-state-then-empty.
+- **Adversarial input** — strings with `<script>`, `‮` (RTL override),<!-- pack-scan-ignore: intentional RTL-override example in adversarial-input checklist -->
+  trailing whitespace, leading zeros. Confirm escaping at render time (not just
+  on submit).
+
+## 2. Error scenarios (the failure axis)
+
+Every async path needs designed behaviour for at least these states:
+
+- **Network failure** — offline, slow (throttled to 3G), timeout, intermittent.
+- **HTTP** — `400` (validation), `401` (signed-out), `403` (permission),
+  `404` (gone), `409` (conflict), `429` (rate-limited), `500` / `502` /
+  `503` (server).
+- **Partial success** — a bulk action where some items succeed and others fail.
+- **Stale data** — user reads, leaves the tab open for an hour, then acts on
+  data that's since changed.
+- **Concurrent edit** — two windows of the same user, or two users on the same
+  record.
+
+For each: what does the UI show? Can the user recover, or are they stranded?
+Errors must be visible **where the user was acting**, not in a corner toast they
+might miss.
+
+## 3. Network / device conditions
+
+- **Slow connection** — does the surface show progress, or feel frozen?
+- **Offline** — does anything that *could* work offline still work (drafts,
+  cached views), and is everything that can't gracefully blocked with a clear
+  message?
+- **Touch + small screen** — every interactive element ≥ 24×24 CSS px (44×44
+  for primary touch targets). No drag-only flows.
+- **Keyboard-only** — full feature reachable without a mouse; visible focus;
+  Esc closes overlays; Enter submits primary forms.
+- **Screen reader** — every control has a name; live regions for async
+  feedback; reading order matches visual order.
+- **Reduced motion** — `prefers-reduced-motion` removes non-essential motion
+  (no auto-carousel, no spring entrances).
+- **High zoom** — 200% text zoom; layout doesn't break, nothing overflows.
+
+## 4. Localisation / i18n
+
+Even single-locale features get hardened against the dimensions i18n exposes,
+because real text behaves the same way:
+
+- **String length variance** — German + Finnish + Japanese typically run +30–60%
+  longer than English; check buttons, table headers, badges.
+- **RTL** — Hebrew / Arabic mirror the layout. Even if the project is LTR-only,
+  no RTL content should *break* anything.
+- **Date / number formats** — `1,234.56` vs `1.234,56` vs `1 234.56`. Currency
+  symbol placement.
+- **Pluralisation** — "1 item" vs "2 items" vs "0 items" — and locales with
+  more than two plural forms.
+
+## 5. Permission / authorisation states
+
+Designed states for what the **current user** can / cannot do:
+
+- **Not signed in** — does the surface degrade, redirect, or 404 cleanly?
+- **Signed in, no permission** — message states what's missing and how to get
+  it; doesn't show empty data as if it were a real empty state.
+- **Signed in, partial permission** — read-only mode designed (controls
+  disabled with reason; never silently no-oped).
+- **Signed in, owner / admin** — surfaces destructive actions appropriately and
+  guards them.
+
+## 6. Tooling-assisted checks (when available)
+
+If the project has the tools, run them; capture evidence in `evidence.md`.
+
+- `prefers-reduced-motion`: emulate in DevTools → re-verify motion.
+- Throttle to "Slow 3G" → re-verify loading + error states.
+- Lighthouse / axe / pa11y → re-verify accessibility floor.
+- Browser-harness or Chrome DevTools MCP (per `devrites-browser-proof`) → capture
+  screenshots of the worst-case input states above.
+
+## Reporting in `/rite-polish`
+
+For each finding raised by this checklist, classify by Phase-3 normalize bucket
+per [ui.md](ui.md):
+- **Token gap** — the design system already has the answer (`text-truncate`
+  token, `state-empty` component) and it isn't being used.
+- **Component miss** — the project already has an `EmptyState`, `ErrorBanner`,
+  `OfflineNotice`, and a one-off was built instead.
+- **Flow / IA misalignment** — the error / empty / offline state doesn't follow
+  the project's pattern (e.g. inline where the project shows a banner; toast
+  where the project uses inline).
+
+Fix in scope; route anything that would balloon the diff as a follow-up FYI.