@damiangilgonzalez/harness 1.3.7

package/skills/typescript/evals/cases.yaml

@@ -0,0 +1,46 @@
+skill: typescript
+
+should_trigger:
+  - prompt: "Make this generic function preserve the literal type of its argument instead of widening to string."
+    why: Core type-system work — const type parameters / inference preservation, framework-agnostic.
+  - prompt: "Why won't TypeScript narrow this union inside the switch? The fields still show as the whole union."
+    why: Non-obvious narrowing symptom — discriminant/destructure-before-check, squarely this skill.
+  - prompt: "Set up a strict tsconfig for a Vite + Node monorepo with project references."
+    why: Compiler config, project references, bundler-vs-nodenext fork — owned here.
+  - prompt: "Type X is not assignable to type Y — help me fix the type, not cast it with as."
+    why: Non-obvious phrasing of a pure type-assignability problem; the explicit no-cast ask is this skill's stance.
+  - prompt: "Configura el tsconfig en modo estricto y elimina los any de este modulo."
+    why: Spanish trigger — strict config plus replacing any with precise types, language/compiler scope.
+  - prompt: "Convert these magic-string statuses into a discriminated union with an exhaustiveness check."
+    why: Discriminated unions + never guard, the canonical modeling pattern here.
+  - prompt: "Por que no estrecha el tipo despues del if? sigue siendo string | undefined."
+    why: Catalan/Spanish non-obvious narrowing question — type-system diagnosis.
+
+should_not_trigger:
+  - prompt: "Add an Express route handler that streams a file with backpressure handling."
+    route_to: nodejs
+    why: Runtime/server behavior (streams, http), not the type system.
+  - prompt: "Type my React component props and wire up the useReducer state."
+    route_to: react
+    why: Framework idioms; the type mechanics are borrowed from here but the wiring belongs to react.
+  - prompt: "Generate Drizzle schema types from my Postgres tables."
+    route_to: drizzle-orm
+    why: ORM schema-to-type generation is owned by the ORM skill.
+  - prompt: "Add type hints to this Python function and fix the mypy errors."
+    route_to: python
+    why: Different language; TS skill does not cover Python typing.
+  - prompt: "Set up Vitest with TS path aliases and coverage reporting."
+    route_to: testing-web
+    why: Test runner/coverage setup; tsconfig path-alias knowledge is borrowed but the tooling is the test skill's.
+
+capability:
+  - scenario: >
+      Given a loosely-typed module (any-heavy, string-keyed state object, no tsconfig),
+      produce strict types plus a tsconfig that compiles under `tsc --noEmit`.
+    must_include:
+      - "Replaces every `any` with `unknown`, a generic, or a precise type."
+      - "Models the state as a discriminated union with a literal discriminant (not string)."
+      - "Adds an exhaustive `never` guard so a new union member is a compile error."
+      - "Ships a strict tsconfig: strict, noUncheckedIndexedAccess, verbatimModuleSyntax, isolatedModules."
+      - "Uses `import type` for type-only imports where applicable."
+      - "Uses no `as` casts to silence errors (each remaining `as` is justified, e.g. `as const` or a validated boundary)."

package/skills/typescript/references/build-and-monorepo.md

@@ -0,0 +1,141 @@
+# Build & monorepo config
+
+Field-by-field tsconfig, project references, resolution matrix, `tsgo`/TS7 adoption, and
+declaration publishing. All targets TypeScript 5.9. Read the section you need.
+
+## tsconfig fields that earn their place
+
+| Field | Set to | Why |
+| --- | --- | --- |
+| `strict` | `true` | Turns on the whole family (`noImplicitAny`, `strictNullChecks`, `strictFunctionTypes`, …). Non-negotiable. |
+| `noUncheckedIndexedAccess` | `true` | `arr[i]` / `rec[k]` become `T \| undefined` — the runtime truth. |
+| `verbatimModuleSyntax` | `true` | Forces explicit `import type`; never emits a type-only import as a runtime `require`; blocks `export default` in CJS-emitted modules. |
+| `isolatedModules` | `true` | Guarantees each file transpiles standalone, so esbuild/swc/babel are safe. |
+| `skipLibCheck` | `true` | Skips type-checking `node_modules` `.d.ts` — large build-time win, negligible risk. |
+| `resolveJsonModule` | `true` | Import `*.json` with inferred types. |
+| `moduleDetection` | `force` | Treats every file as a module (no accidental global scripts). |
+| `noEmit` | `true` (apps) | A bundler emits; `tsc` only type-checks. Libraries set it `false` to emit `.d.ts`. |
+| `composite` | `true` (referenced pkgs) | Required for project references; enables incremental `.tsbuildinfo`. |
+
+## bundler vs nodenext matrix
+
+| | `moduleResolution: "bundler"` | `moduleResolution: "nodenext"` |
+| --- | --- | --- |
+| Pair `module` with | `"esnext"` or `"preserve"` | `"nodenext"` |
+| Who runs the output | a bundler (Vite, esbuild, webpack, Next) | Node directly |
+| Relative import extension | omit (`import "./util"`) | required (`import "./util.js"`) |
+| `package.json` `exports`/`imports` | resolved | resolved |
+| Conditional exports honored | yes | yes (per CJS/ESM condition) |
+| Path aliases | resolved at type-check; bundler must mirror them | resolved at type-check; Node needs `imports`/loader to mirror |
+| Choose when | app/library bundled before it ships | library/script Node executes as-is |
+
+Rule of thumb: if anything bundles the code before it runs, use `bundler`. If Node loads the
+`.js` directly, use `nodenext` and write the `.js` extension on relative imports.
+
+## Project references (the monorepo backbone)
+
+Layout: one `tsconfig.base.json` at the root with the strict flags, then per-package configs.
+
+```jsonc
+// tsconfig.base.json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "verbatimModuleSyntax": true,
+    "isolatedModules": true,
+    "skipLibCheck": true,
+    "target": "esnext",
+    "module": "nodenext",
+    "moduleResolution": "nodenext",
+    "declaration": true,
+    "declarationMap": true,
+    "composite": true
+  }
+}
+```
+
+```jsonc
+// packages/app/tsconfig.json
+{
+  "extends": "../../tsconfig.base.json",
+  "compilerOptions": { "rootDir": "src", "outDir": "dist" },
+  "references": [{ "path": "../core" }, { "path": "../ui" }]
+}
+```
+
+- Build the whole graph in dependency order: `tsc -b` (or `tsgo -b`). It caches per package via
+  `.tsbuildinfo` and only rebuilds what changed.
+- Each referenced package needs `composite: true` and must emit declarations.
+- A package may only import from packages it lists under `references`; TS enforces the boundary,
+  which kills accidental cross-package coupling.
+
+## Path aliases — and the reality check
+
+```jsonc
+{
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": { "@core/*": ["packages/core/src/*"] }
+  }
+}
+```
+
+`paths` only rewrites types for the **type-checker**. The runtime/bundler must mirror it:
+Vite (`resolve.alias`), Node (`package.json` `imports` with the `#`-prefix subpath convention),
+or a runtime resolver. Aliases that the bundler does not mirror compile fine and crash at
+runtime — prefer `package.json` `imports` (`"#core/*"`) when Node runs the code, since Node
+resolves those natively.
+
+## tsgo / TypeScript 7 adoption
+
+The native (Go) compiler is in preview as `@typescript/native-preview`, ships the `tsgo`
+binary, and type-checks ~10x faster (Microsoft's VS Code repo, 1.5M LOC: 89s -> 8.74s, 10.2x).
+
+```bash
+npm i -D @typescript/native-preview
+npx tsgo --noEmit          # same flags as tsc
+npx tsgo -b                 # build a project-references graph
+```
+
+Adoption steps:
+1. Add it as a dev dependency; keep `typescript` (`tsc`) installed as the stable fallback.
+2. Run `tsgo --noEmit` in CI for the speed win; if a diagnostic differs, fall back to `tsc` for
+   that check and report it — the preview does not yet cover 100% of `tsc` behavior.
+3. Stable TS 7.0 is targeted for 2026; until then treat `tsgo` as the checker, `tsc` as the
+   reference/emitter.
+
+## Declaration emit & publishing a library
+
+```jsonc
+{
+  "compilerOptions": {
+    "declaration": true,        // emit .d.ts
+    "declarationMap": true,     // .d.ts.map so go-to-def lands on source
+    "outDir": "dist",
+    "rootDir": "src"
+  }
+}
+```
+
+```jsonc
+// package.json — modern dual/ESM publish
+{
+  "type": "module",
+  "exports": {
+    ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js" }
+  },
+  "files": ["dist"]
+}
+```
+
+- `types`/`typesVersions` must point at the emitted `.d.ts`; put `types` **first** in each
+  `exports` condition so resolvers find it.
+- For libraries, do not set `noEmit`; let `tsc -b` (or your bundler with dts plugin) emit.
+- Validate the published surface with a tool like `@arethetypeswrong/cli` before release.
+
+## Running TS without a build
+
+- `tsx file.ts` — fast esbuild-based runner for scripts and dev (replaces `ts-node`).
+- Node `--experimental-strip-types` (Node 22+) runs `.ts` by erasing types; no type-checking.
+- Both *execute*; neither *checks*. Always keep `tsc --noEmit` (or `tsgo --noEmit`) in CI.

package/skills/typescript/references/type-system.md

@@ -0,0 +1,162 @@
+# Type-system deep dives
+
+Recipes the SKILL body points to. All target TypeScript 5.9. Read the relevant section, not
+the whole file.
+
+## Conditional types + `infer`
+
+`infer` introduces a type variable inside the `extends` clause and binds it to whatever
+matched. It is how you destructure types positionally.
+
+```ts
+type ElementOf<T> = T extends readonly (infer U)[] ? U : never;
+type Unwrap<T> = T extends Promise<infer U> ? Unwrap<U> : T; // recursive unwrap of nesting
+type FirstArg<F> = F extends (a: infer A, ...rest: any[]) => any ? A : never;
+```
+
+Distributive conditional types: when the checked type is a *naked* type parameter and the
+input is a union, the conditional distributes over each member. Wrap both sides in a tuple to
+turn it off.
+
+```ts
+type ToArray<T> = T extends any ? T[] : never;
+type A = ToArray<string | number>;   // string[] | number[]  (distributed)
+type NonDist<T> = [T] extends [any] ? T[] : never;
+type B = NonDist<string | number>;   // (string | number)[]  (not distributed)
+```
+
+## Mapped types: key remapping, modifiers
+
+```ts
+// Remap keys with `as` + template literals; filter by mapping to never.
+type Getters<T> = { [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K] };
+type RemoveId<T> = { [K in keyof T as K extends "id" ? never : K]: T[K] };
+
+// Modifiers: + / - add or strip readonly and optional.
+type Mutable<T>  = { -readonly [K in keyof T]: T[K] };
+type Concrete<T> = { [K in keyof T]-?: T[K] }; // strip optionality
+```
+
+## Template-literal types
+
+```ts
+type Route = `/${string}`;                       // any path-ish string
+type Method = "GET" | "POST" | "PUT" | "DELETE";
+type Endpoint = `${Method} ${Route}`;            // "GET /users", ...
+type CSSVar = `--${string}`;
+// Inference inside templates:
+type ParseId<T> = T extends `user_${infer N}` ? N : never; // ParseId<"user_42"> = "42"
+```
+
+## Recursive types (with care)
+
+Recursion is allowed but the depth is bounded by the instantiation-depth limit; deep tuple
+recursion (e.g. length-N tuples) hits it fast. Prefer tail-recursive accumulator patterns.
+
+```ts
+type DeepReadonly<T> = T extends (infer U)[]
+  ? readonly DeepReadonly<U>[]
+  : T extends object
+    ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
+    : T;
+```
+
+## Variance: `in` / `out` annotations
+
+TS infers variance structurally; you can annotate it on type parameters to make intent
+explicit and speed up checking on large generic types.
+
+- **Covariant** (`out T`): T appears only in output position (return types, readonly props).
+- **Contravariant** (`in T`): T appears only in input position (parameters).
+- **Invariant** (`in out T`): both.
+
+```ts
+interface Consumer<in T> { consume(value: T): void; }     // contravariant
+interface Producer<out T> { produce(): T; }               // covariant
+```
+
+Method parameters are checked **bivariantly** by default for legacy reasons;
+`strictFunctionTypes` makes standalone function-type parameters strictly contravariant, but
+**method** shorthand stays bivariant — prefer the `prop: (x: T) => U` arrow form when you
+want strict checking.
+
+## Branded / nominal patterns
+
+Structural typing means two aliases of `string` are interchangeable. Brand to forbid mixing:
+
+```ts
+declare const brand: unique symbol;
+type Brand<T, B> = T & { readonly [brand]: B };
+
+type UserId = Brand<string, "UserId">;
+type Cents  = Brand<number, "Cents">;
+
+const userId = (s: string): UserId => s as UserId; // brand only after validation
+function charge(amount: Cents) {}
+// charge(100);            // error: number is not Cents
+// charge(userId("u1"));   // error: UserId is not Cents
+```
+
+The brand exists only at the type level (zero runtime cost). Apply the cast in exactly one
+validated constructor, never sprinkle `as UserId` across the codebase.
+
+## Declaration merging
+
+Interfaces with the same name merge; this is how you augment third-party or global types.
+
+```ts
+// Augment a module's types without forking it.
+declare module "express" {
+  interface Request { userId?: string; }
+}
+// Augment globals.
+declare global {
+  interface Window { __APP_VERSION__: string; }
+}
+export {}; // make this file a module so `declare global` is allowed
+```
+
+`type` aliases do **not** merge — only `interface` and `namespace` do.
+
+## Function overloads
+
+Provide multiple call signatures, one implementation signature (which is not callable). Order
+overloads most-specific first.
+
+```ts
+function toArray(x: string): string[];
+function toArray(x: number): number[];
+function toArray(x: string | number): (string | number)[] {
+  return [x];
+}
+```
+
+Prefer a single generic or a union return over overloads when the relationship is
+expressible — overloads don't compose and don't infer across each other.
+
+## Type predicates & assertion functions
+
+```ts
+// Type predicate: narrows the argument when it returns true.
+function isString(x: unknown): x is string { return typeof x === "string"; }
+
+// Assertion function: narrows by throwing otherwise (note the `asserts` keyword).
+function assertDefined<T>(x: T): asserts x is NonNullable<T> {
+  if (x == null) throw new Error("expected a value");
+}
+
+const v: string | undefined = maybe();
+assertDefined(v);
+v.toUpperCase(); // v is string here
+```
+
+TS 5.5+ infers type predicates for simple filter callbacks, so
+`arr.filter((x) => x != null)` now narrows to `T[]` without a hand-written predicate in many
+cases — but an explicit predicate is still clearer for non-trivial checks.
+
+## `const` type parameters & `NoInfer`
+
+```ts
+function widen<const T>(x: T): T { return x; }         // keeps literals, no `as const`
+function build<T>(items: T[], fallback: NoInfer<T>) {} // fallback can't drive inference of T
+```

package/skills/typescript/scripts/verify.sh

@@ -0,0 +1,52 @@
+#!/usr/bin/env bash
+# verify.sh — prove the TS toolchain enforces strictness + exhaustiveness.
+# Read-only on the target: writes ONLY to its own temp dir. Exits 0 with a clear
+# message when no TS/node is available (no false failure on a clean machine).
+set -euo pipefail
+
+# Resolve a type-checker: prefer tsgo (TS7 preview), else npx typescript's tsc.
+# Strict flags are passed on the CLI because naming files on the CLI bypasses tsconfig.
+FLAGS="--noEmit --strict --noUncheckedIndexedAccess --target esnext --module nodenext --moduleResolution nodenext"
+if command -v tsgo >/dev/null 2>&1; then
+  CHECK="tsgo"
+elif command -v npx >/dev/null 2>&1; then
+  CHECK="npx -y -p typescript tsc"
+else
+  echo "SKIP: no tsgo and no npx on PATH — cannot type-check. (exit 0)"
+  exit 0
+fi
+
+TMP="$(mktemp -d)"
+trap 'rm -rf "$TMP"' EXIT
+
+# good.ts: exhaustive never guard MUST pass.
+cat > "$TMP/good.ts" <<'TS'
+type S = { k: "a" } | { k: "b" };
+export function f(s: S): number {
+  switch (s.k) {
+    case "a": return 1;
+    case "b": return 2;
+    default: { const _: never = s; return _; }
+  }
+}
+TS
+
+# bad.ts: missing "b" case -> never guard MUST fail to compile.
+cat > "$TMP/bad.ts" <<'TS'
+type S = { k: "a" } | { k: "b" };
+export function f(s: S): number {
+  switch (s.k) {
+    case "a": return 1;
+    default: { const _: never = s; return _; }
+  }
+}
+TS
+
+run() { ( cd "$TMP" && $CHECK $FLAGS "$1" ) >/dev/null 2>&1; }
+
+fail=0
+if run good.ts; then echo "PASS: good.ts type-checks"; else echo "FAIL: good.ts should compile"; fail=1; fi
+if run bad.ts;  then echo "FAIL: bad.ts should NOT compile (exhaustiveness)"; fail=1; else echo "PASS: bad.ts rejected"; fi
+
+if [ "$fail" -ne 0 ]; then echo "verify.sh: FAILED"; exit 1; fi
+echo "verify.sh: OK — strict + exhaustiveness enforced"

package/skills/ui-engineering/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: ui-engineering
+description: "Use when the question is how interface should be BUILT — component boundaries, state that belongs in the URL vs the component, loading/empty/error states, forms, optimistic updates, build vs adopt. NOT the visual system (`design`), NOT framework mechanics (`react`/`nextjs`)."
+tags: [interface, frontend, architecture, components, state, craft]
+recommends: [design, motion-craft]
+profiles: [ui, full]
+origin: risco
+---
+
+# UI engineering — the decisions between the design and the framework
+
+There is a layer that neither the design skill nor the framework skill owns. The design says what
+the screen should be. The framework says how its API works. **In between sits every decision that
+makes an interface either durable or a maintenance tax** — and it is where most interface work
+actually goes wrong.
+
+Nothing here is framework-specific. These decisions are the same in React, Vue, Svelte, SwiftUI and
+plain HTML; only the syntax moves.
+
+## The one rule
+
+**State goes to the outermost place that still needs it, and no further.** Almost every interface
+tangle is that rule broken in one of two directions: state hoarded in a component that others need,
+or state hoisted into a global store that only one component ever reads.
+
+| Where the state lives | When that is right |
+| --- | --- |
+| **The URL** | Anything a user would bookmark, share, or expect the back button to restore: filters, tabs, pagination, the open item |
+| **The server** | Anything that outlives the session or belongs to more than one user |
+| **A shared parent** | Two siblings genuinely need it, and it dies with the screen |
+| **The component** | Nobody else reads it: hover, focus, an open menu, an in-flight draft |
+
+The most common and most expensive mistake is the first row: state that belongs in the URL kept in a
+component. It looks fine until someone reloads, shares a link, or presses back — and then the
+interface silently loses what the user did.
+
+## Every state, not just the happy one
+
+An interface is not finished when it renders data. It is finished when it renders **all five**:
+
+| State | The question it answers | The usual failure |
+| --- | --- | --- |
+| **Loading** | "Is it working?" | A spinner where the shape is already known — use the shape |
+| **Empty** | "Is it broken, or is there nothing?" | Blank. It must say which, and what to do next |
+| **Error** | "What now?" | A message with no action. Every denial carries its own way out |
+| **Partial** | "Some of it failed" | Ignored entirely; the screen shows a half-truth |
+| **Success** | "It worked" | Silence, so the user does it twice |
+
+The empty state is the one that gets skipped, and it is the first state a new user ever sees.
+
+## Component boundaries
+
+A component earns its existence by **hiding a decision**, not by being reused. Splitting for reuse
+alone produces the worst interfaces: a wrapper around a wrapper, each passing props through, none
+owning anything.
+
+Draw the boundary where:
+
+- it owns a piece of state nothing outside needs;
+- it can be described in one sentence without "and";
+- swapping its internals changes nothing outside it.
+
+Do **not** draw a boundary because a file is long. Long is not a defect; a file that does two
+unrelated things is, and it is usually short.
+
+## Forms
+
+Forms are where interfaces most often insult people, and the rules are unglamorous:
+
+- **Validate on blur, not on keystroke.** Telling someone their email is invalid while they are on
+  the third character is scolding them for not having finished.
+- **Never clear what they typed.** Not on error, not on refresh, not on navigation. Their input is
+  theirs.
+- **Disable the submit only while submitting**, never as a way of enforcing validity — a disabled
+  button with no reason is a dead end.
+- **The error goes next to the field**, and says what to do, not what is wrong.
+
+## Optimistic updates
+
+Show the result before the server confirms **only** when you can honestly undo it. That means: the
+operation is idempotent, the failure is rare, and reverting it is visible and comprehensible.
+
+Optimism on a destructive or an expensive action is a lie you will have to retract in front of the
+user. Deleting, paying, sending — those wait.
+
+## Build or adopt
+
+Adopting a component costs bundle size, an API you did not design, and an upgrade you will owe
+later. Building costs the accessibility work you will get wrong.
+
+The split is not about difficulty, it is about **who is the authority on the behaviour**:
+
+- **Adopt** for behaviour with a specification you would otherwise be reimplementing badly: focus
+  trapping, combobox semantics, date handling, virtualisation.
+- **Build** for anything that is your product's own logic wearing a UI, or where the library gives
+  you 60% and you fight the remaining 40% forever.
+
+## Anti-patterns → STOP
+
+| If you're about to… | Reality / Fix |
+| --- | --- |
+| Put a filter or tab selection in component state | It belongs in the URL. Reload, share and back are part of the interface. |
+| Add a global store because passing props feels tedious | Tedious is not broken. Global state that one component reads is a leak with ceremony. |
+| Ship a screen with only the loaded state | Loading, empty, error and partial are not extras. The empty one is what a new user sees first. |
+| Split a component because the file got long | Length is not the defect. Two unrelated responsibilities are, and they are usually short. |
+| Show a delete as done before the server confirms | Optimism on a destructive action is a lie you will retract in public. |
+| Reach here for how the framework's hooks work | That is `../react/SKILL.md` or `../nextjs/SKILL.md`. This skill decides what to build; those decide how to express it. |
+
+## See Also
+
+- `../design/SKILL.md` — the visual system these decisions serve.
+- `../motion-craft/SKILL.md` — how the pieces here move once they exist.
+- `../design-loop/SKILL.md` — the graded critique that judges the result.
+- `../accessibility/SKILL.md` — the ground under focus, semantics and forms.

package/skills/ui-engineering/evals/cases.yaml

@@ -0,0 +1,38 @@
+skill: ui-engineering
+
+should_trigger:
+  - prompt: "Where should the filter state live — component, context or the URL?"
+    why: "The canonical case: the one rule this skill exists to apply."
+  - prompt: "How should I split these components? The file is getting big."
+    why: "Component boundaries, and the file-length premise is one this skill corrects."
+  - prompt: "We only render the loaded state. What else does this screen need?"
+    why: "The five states are the checklist this skill owns."
+  - prompt: "¿Valido el formulario mientras escribe o al salir del campo?"
+    why: "Form behaviour, in Spanish; the trigger is the decision, not the language."
+  - prompt: "Should I use a component library for the date picker or build it?"
+    why: "Build vs adopt, decided by who owns the behaviour's specification."
+  - prompt: "Can we show the delete as done immediately and roll back if it fails?"
+    why: "Optimistic updates, and this is the case where the answer is no."
+
+should_not_trigger:
+  - prompt: "Design the pricing page — layout, type scale, the colour system."
+    route_to: "design"
+    why: "The visual system is decided before this layer has anything to build."
+  - prompt: "My useEffect runs twice in development and I don't understand why."
+    route_to: "react"
+    why: "Framework mechanics. This skill decides what to build, not how the framework behaves."
+  - prompt: "The dropdown animation feels cheap, what duration should it use?"
+    route_to: "motion-craft"
+    why: "Once the component exists, how it moves is motion craft."
+  - prompt: "Grade this dashboard and tell me if it is actually good."
+    route_to: "design-loop"
+    why: "Judging a finished screen is the critique loop, not the build decisions."
+  - prompt: "Set up the Next.js App Router with server actions for this project."
+    route_to: "nextjs"
+    why: "Stack setup is the stack skill's; this one is framework-agnostic by construction."
+
+capability:
+  - prompt: "Our search page keeps its query and filters in component state. Users complain the back button loses everything. What is wrong and what is the fix?"
+    why: "The single most expensive instance of the one rule, stated as a real symptom rather than as theory."
+  - prompt: "This list screen shows a spinner, then rows. What states are we missing and why does each matter?"
+    why: "Forces the five-state checklist, including the empty state that a new user sees first."