devrites 1.19.0

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

@@ -0,0 +1,136 @@
+# Normalize + UI quality (Phase 3 + Phase 4)
+
+Loaded from `/rite-polish` only when the diff touches UI. Two phases, strict
+order: normalize to the design system (Phase 3), then the ship-quality detail
+pass (Phase 4). Normalize removes drift and aligns to the system; polish sweats
+the details. Skipping normalize means polishing drift.
+
+## Operating rules
+
+- **NEVER polish without normalizing first** — decoration on drift is banned.
+  Phase 3 runs before Phase 4, always.
+- Browser evidence required for UI polish when a browser can run
+  ([browser-polish-evidence.md](browser-polish-evidence.md)).
+- Don't invent a new design system. Ask when design-system principles are
+  ambiguous. Spec Drift Guard applies (a design-system contradiction is drift).
+
+## Why this order
+
+A beautiful component that ignores the project's tokens, components, and flow
+shape is *worse* than a plain one that fits — it adds a second system the team
+must maintain. Alignment is the precondition for polish, not an optional first
+step. **Fixing the symptom without naming the cause is how drift compounds:**
+patching a colour without adding the token bakes the next drift in; swapping a
+class without moving to the shared component leaves the next caller to redo the
+work.
+
+## Phase 3 — Normalize
+
+Goal: this feature looks and behaves like it belongs in *this* product.
+
+1. **Discover the design system**
+   ([design-system-discovery.md](design-system-discovery.md)): docs, tokens,
+   shared components, spacing/type scales, color roles, icon set, interaction
+   & form patterns, neighboring screens.
+2. **Identify drift by root cause**, classifying each into one of **three
+   buckets** — the bucket dictates the fix:
+
+   | Bucket | What it is | Fix |
+   |---|---|---|
+   | **Token gap** | A value is hard-coded where a token should carry it (colour, spacing, type size, radius, shadow). | Use the existing token; if a needed slot doesn't exist, propose adding it to the system — don't invent one inline. |
+   | **Component miss** | A one-off implementation exists where a shared component already covers the case (button, input, dialog, menu, table row). | Swap to the shared component. Don't fork it into the feature folder. |
+   | **Flow / IA misalignment** | The feature's flow shape, naming, or mental model doesn't match neighbouring features (modal where the project goes inline; save-on-blur where the project uses explicit submit; new vocabulary for an existing concept). | Reshape the flow / rename to the project's vocabulary. The most expensive bucket — and the most damaging if skipped. |
+
+   Sub-cases that map back to the buckets above: generic-AI-template styling →
+   **Token gap** (hard-coded styling that should ride a token) or **Component
+   miss** (rebuilt instead of reused); orphaned styles or components this
+   feature created → **Component miss** (consolidate or remove); inconsistent
+   IA / naming → **Flow / IA misalignment**.
+3. **Fix root causes, not symptoms** — use existing tokens, swap to shared
+   components, align flow shape with neighbors, consolidate duplication, remove
+   obsolete styles created by this feature. Ask the user when a design-system
+   principle is genuinely ambiguous — don't guess the system's intent.
+
+## Phase 4 — UI polish
+
+Only after functionality is complete **and** Phase 3 is done. Systematic detail
+pass against the UI quality bar below — zoom in, squint, use the thing. Little
+things add up.
+
+Meet the **2026 quality bar** — CWV (LCP ≤ 2.5s / INP ≤ 200ms / CLS ≤ 0.1) and
+WCAG 2.2 AA. Avoid [anti-ai-slop.md](anti-ai-slop.md). If the spec saved design
+references in `references/`, **match them**.
+
+Run the production-hardening sweep before declaring polish done — extreme
+inputs, errors, network, i18n, permission states — per
+[harden-checklist.md](harden-checklist.md). Polish that only works on the happy
+path isn't polish.
+
+### UI quality bar (checklist)
+
+- [ ] **Aligned to the design system** — drift named and resolved by root cause (Phase 3)
+- [ ] **IA & flow** match neighboring features
+- [ ] **Visual hierarchy** — the primary action is obviously primary
+- [ ] **Spacing** uses design tokens consistently; rhythm reads as deliberate
+- [ ] **Alignment** perfect at every breakpoint
+- [ ] **Typography** hierarchy consistent; line length sane (65–75ch prose)
+- [ ] **Color & contrast** — semantic roles; text ≥ 4.5:1 (≥ 3:1 large/UI), WCAG 2.2 AA
+- [ ] **All interaction states** — hover, active, focus, disabled, selected
+- [ ] **Focus states visible** and **keyboard navigation** works
+- [ ] **Loading** states clear; **empty** states welcoming with a next action
+- [ ] **Error** states helpful (what happened + how to recover); **success** states clear
+- [ ] **Forms** properly labeled, validated, with inline errors
+- [ ] **Copy & terminology** consistent with the product's vocabulary
+- [ ] **Icons** consistent set, properly sized and aligned
+- [ ] **Responsive** behavior correct across target viewports
+- [ ] **Target size** ≥ 24×24px (WCAG 2.2 AA); ≥ 44×44px for primary touch; **no drag-only** actions
+- [ ] **Motion** smooth (~60fps), purposeful; **reduced-motion** respected
+- [ ] **Performance basics** — no obvious jank, oversized images, or blocking work
+- [ ] **No console errors or warnings**
+- [ ] **No layout shift** on load
+- [ ] Works in the project's **supported browsers**
+- [ ] **Code quality** in touched UI files — no TODOs, console.logs, commented-out code
+
+### Measurable bar (2026)
+
+Polish verifies against the frontend quality standards
+(`devrites-frontend-craft/reference/quality-standards.md`), measured not assumed:
+- Core Web Vitals (p75): **LCP ≤ 2.5 s · INP ≤ 200 ms · CLS ≤ 0.1**.
+- WCAG 2.2 AA: semantic HTML, keyboard-operable, visible focus ≥ 3:1, no drag-only.
+- Responsive at **320 / 768 / 1024 / 1440**; survives 200% text zoom; no horizontal scroll.
+- No console errors/warnings; no axe violations; `prefers-reduced-motion` honored.
+Cite the evidence in `browser-evidence.md`.
+
+### Triage
+
+If it ships in 30 minutes, fix what users will actually notice (hierarchy,
+states, broken layout, bad copy) before micro-spacing. Don't introduce bugs
+while polishing — re-prove after changes.
+
+### Refinement modes (optional dials within Phase 4)
+
+| Mode | When | What it means |
+|---|---|---|
+| **bolder** | Surface reads safe / generic / forgettable. | Stronger hierarchy + weight contrast, one decisive accent, more committed scale. Reject generic-bold reflexes — gradients, glassmorphism, neon. |
+| **quieter** | Surface reads loud / overstimulating. | Reduce chroma, increase whitespace, flatten elevation, soften motion. Personality stays; intensity drops. |
+| **distill** | Too many elements / colours / sizes competing. | Remove anything that doesn't earn its place: redundant copy, decorative shadows/borders. One primary action per screen. |
+| **harden** | Surface only works on the happy path. | Walk [harden-checklist.md](harden-checklist.md) explicitly. Design every error / empty / partial / offline state. |
+
+Modes are advisory. Default Phase 4 covers all four already; the mode just
+shifts the emphasis of the same pass when the brief asks for it.
+
+## NEVER
+
+- Polish before it's functionally complete.
+- Polish without aligning first (decoration on drift).
+- Guess at design-system principles instead of asking.
+- Introduce bugs while polishing (re-prove after changes).
+- Invent a new design system or add a component/icon library without asking.
+
+## Output → appends to `polish-report.md`
+
+```
+Phase 3 (normalize): drift found → root-cause fixes
+Phase 4 (UI polish): quality-bar deltas
+Browser evidence: <summary>
+```

package/pack/.claude/skills/rite-pressure-test/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: rite-pressure-test
+description: Pressure-test a rough idea — diverge into 3-5 genuinely different options, then converge on one with the trade-off and decision hinge. Use when the user says "ideate", "refine this idea", "stress-test my plan", "I have a vague idea", or `/rite-spec` flags the concept as rough. Not for writing the spec (use `/rite-spec`).
+user-invocable: true
+---
+
+# rite-pressure-test — diverge then converge
+
+Use when the *idea* (not just the requirements) is rough. Generate options, then commit
+to one — so `/rite-spec` has a real direction to specify.
+
+Read `.claude/rules/core.md` first — its operating rules (no silent assumptions, prefer
+existing conventions) shape the divergence. The other rule files load on demand.
+
+## Diverge (widen)
+- Generate 3–5 genuinely different approaches to the underlying goal, not variations of
+  one. Cover at least: the obvious approach, a simpler/smaller approach, and a
+  different-shape approach (different data model, flow, or boundary).
+- For each: one-line description, what it optimizes for, rough cost, main risk.
+- Stay concrete — name real entities, flows, and surfaces, not abstractions.
+
+## Converge (commit)
+- Weigh options against the goal, constraints, and existing codebase conventions.
+- Recommend one, with the reason and the key trade-off accepted.
+- Note what would change the recommendation (the decision's hinge).
+
+## Boundaries
+- This is exploration, not specification. Output a **direction**, not a finished spec —
+  `/rite-spec` writes the spec.
+- Don't over-explore: 3–5 options, one pass of convergence. If the user already knows
+  the direction, skip this and go straight to `/rite-spec`.
+- Ask the user to pick when two options are close and the choice changes the product.
+
+## Output
+```
+Goal (restated): ...
+Options:
+  A. <approach> — optimizes <x>, cost <y>, risk <z>
+  B. ...
+Recommendation: <option> because <reason>; trade-off accepted: <...>
+Hinge: <what would change this>
+Next: /rite-spec <feature>  (using the chosen direction)
+```

package/pack/.claude/skills/rite-prototype/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: rite-prototype
+description: Throwaway prototype answering ONE design question — either a runnable Logic harness or 2–4 radically different UI variations on one route — then delete or absorb. Use when the user says "prototype this", "sanity-check the data model", "try a few UI designs", "let me play with it", "mock it up". Not for production code.
+user-invocable: true
+argument-hint: "[the question the prototype is answering]"
+---
+
+# /rite-prototype — throwaway code that answers ONE question
+
+A prototype is **throwaway code that answers exactly one question**. The question
+chooses the shape — get the shape wrong and the whole prototype wastes the user's time.
+
+## 0. Read core rules
+
+Read `.claude/rules/core.md` first — the operating rules and the "capture the answer"
+persistence discipline apply even to throwaway code. The other rule files load on demand.
+
+## 1. Name the question
+
+If the user did not give the question explicitly, ask **one** short question to pin it
+down. Examples that count as "the question":
+
+- "Does this reducer correctly model add / undo / re-add of the same item?"
+- "Which of these three settings layouts feels right?"
+- "Will the proposed state machine deadlock when X overlaps Y?"
+
+A vague question ("explore this feature") is not enough — push back once to sharpen it.
+
+## 2. Pick the branch
+
+Read the user's prompt + the surrounding code. Two branches:
+
+| Question shape | Branch | Artifact |
+|---|---|---|
+| "Does this **logic / state / data model** behave right?" | **Logic** | Smallest runnable harness — terminal script / REPL / mini node or python file — that pushes the model through the hard cases. |
+| "What should this **look like / which UX wins**?" | **UI** | 2–4 **radically different** UI variations on a single route, switchable via a query param + a small floating selector bar. |
+
+If genuinely ambiguous and the user is AFK: pick by the surrounding code (backend module
+→ Logic; page / component → UI) and state the assumption in a comment at the top.
+
+**Variations must differ in shape.** UI prototypes where the variations are just colour
+or padding tweaks teach nothing — push each variation to a different *information
+architecture* / *interaction model* so the user can pick a direction, not a polish.
+
+## 3. Rules that apply to both branches
+
+1. **Throwaway from day one — and visibly so.** Place the prototype next to where it
+   will eventually be used (so context is obvious) but name it so a casual reader sees
+   it's a prototype: `prototype/`, `__prototype__`, `.scratch/`, etc. Obey the project's
+   existing routing / module convention; don't invent a new top-level structure.
+2. **One command to run.** Use whatever task runner the project already has — `pnpm
+   <name>`, `python <path>`, `bun <path>`. The user must start it without thinking.
+3. **No persistence by default.** State lives in memory. Persistence is usually the
+   thing the prototype is *checking*, not a dependency. If the question explicitly
+   involves a DB, hit a scratch DB or a local file with a name like
+   `PROTOTYPE — wipe me`.
+4. **Skip the polish.** No tests. No error handling beyond what makes it run. No
+   abstractions. The point is learn fast, delete fast.
+5. **Surface state.** After every action (Logic) or on every variant switch (UI), print
+   or render the full relevant state so the user can see what changed.
+6. **Delete or absorb when done.** When the question has an answer, either delete the
+   prototype or fold the validated decision into the real code — don't leave it
+   rotting in the repo.
+
+## 4. Capture the answer
+
+The *answer* is the only durable output. Before declaring the prototype done, write
+one of:
+
+- An entry in the active feature's `decisions.md` (`.devrites/work/<slug>/decisions.md`)
+  with the question and the answer.
+- A `NOTES.md` next to the prototype if no active feature exists.
+
+If the user is around, this is a quick conversation. If they're AFK, leave a placeholder
+("VERDICT: ___") so the next pass fills it in before the prototype is deleted.
+
+## Where this slots in
+
+`/rite-prototype` is a **scoped detour**, not a phase of its own. Typical placements:
+
+- **Between `/rite-spec` and `/rite-define`** — a design question is undecidable on
+  paper; prototype it, capture the answer, return to `/rite-define`.
+- **Mid-build** — `/rite-build` hit a state-model ambiguity that the spec doesn't
+  resolve. Drop into a Logic prototype, capture the answer, return.
+
+After the prototype answers the question and the answer is recorded, return to the
+calling phase. The prototype itself does **not** ship.

package/pack/.claude/skills/rite-prove/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: rite-prove
+description: Prove the completed feature — full tests + build + typecheck + lint + browser-proof ladder — walking `spec.md` acceptance criteria one by one. Use when the user says "prove this", "run the full tests", "is this feature really done", "check it end-to-end". Not for single-slice or pre-completion proof.
+argument-hint: "[feature-slug]"
+user-invocable: true
+---
+
+# /rite-prove — prove the completed feature
+
+Turn "I think it works" into recorded evidence for the **whole feature**. Read the active
+workspace first; if none, run `/rite-spec <feature>`.
+
+> **Differs from built-in `/verify` and `/run` in:** `/verify` proves a
+> single change; `/run` launches the app. `/rite-prove` is feature-scoped:
+> it walks `spec.md` acceptance criteria one-by-one, runs the full relevant
+> test suite + build/typecheck/lint, ascends the browser-proof ladder
+> (browser-harness → DevTools MCP → `/run`+`/verify` → project E2E →
+> manual), and writes `evidence.md` + `browser-evidence.md` keyed to the
+> active `.devrites/work/<slug>/`. Use `/verify` or `/run` on their own
+> when there is no DevRites feature workspace.
+
+## Gate: all slices must be built first
+Read `tasks.md` + `state.md`. **If ANY slice is still pending/unbuilt, STOP** and tell the
+user to finish it with `/rite-build` — `/rite-prove` runs once, when the full task is
+complete, not after each slice. (Each slice already got its own targeted tests during
+`/rite-build`; this phase is the comprehensive proof of the assembled feature.)
+
+**Never report a pass you didn't observe.** If a command couldn't run, say so and give exact manual steps.
+
+**Re-runnable, scoped.** `/rite-prove` runs once when the full feature is assembled, but
+it can be **re-run scoped** afterwards: when `/rite-polish` or `/rite-review` edit code,
+the existing `evidence.md` no longer post-dates the change, so re-run `/rite-prove` over
+the affected criteria/routes to refresh proof before `/rite-seal`.
+
+## Rules consulted (read on demand from `.claude/rules/`)
+**Step 0:** Read `.claude/rules/core.md` first. The other rule files load on demand;
+pull these via `Read` when relevant:
+- `testing.md` — pyramid, determinism, no-flake discipline.
+- `performance.md` — measure first when perf is in scope.
+
+## Operating rules
+- Evidence over confidence. Feature scope only — fix within the feature or record a
+  blocker; don't refactor unrelated code.
+- Spec Drift Guard applies: if tests/evidence reveal the spec is wrong, stop and handle
+  drift (`rite-build/reference/spec-drift-guard.md`).
+
+## Workflow
+0. Read `.claude/rules/core.md` first (the always-on operating rules); pull the
+   on-demand rules above when relevant.
+   Then **run the shared orientation preamble** — it prints `state.md`, the artifacts present,
+   the run mode (HITL/AFK), and the open-question tally by gate, so you orient deterministically
+   instead of re-deriving state from raw Markdown:
+   ```bash
+   P=.claude/skills/devrites-lib/scripts/preamble.sh
+   [ -f "$P" ] || P="${CLAUDE_SKILL_DIR:-}/../devrites-lib/scripts/preamble.sh"
+   [ -f "$P" ] || P=pack/.claude/skills/devrites-lib/scripts/preamble.sh
+   [ -f "$P" ] && bash "$P" || echo "(orientation preamble unavailable on this install — read state.md directly to orient)"
+   ```
+1. **Confirm the gate** (all slices built). Read `spec.md` (acceptance criteria +
+   "Commands discovered"), `tasks.md`, `state.md`, `test-plan.md` if present (the vetted
+   coverage target from `/rite-vet`), and the full `git diff`.
+2. **Discover commands** if not recorded —
+   [test-command-discovery](reference/test-command-discovery.md): README, package
+   scripts, Makefile, CI configs, Gemfile/Rakefile, pyproject, go.mod, Cargo.toml.
+3. **Run the full relevant test suite** for the feature (not a single slice), then the
+   relevant **build / typecheck / lint**.
+4. **UI feature?** Run the browser proof ladder over the feature's routes —
+   [proof-ladder](reference/proof-ladder.md) + [browser-proof](reference/browser-proof.md)
+   (`devrites-browser-proof`): routes, viewports, screenshots (opened + described),
+   console, network, interaction paths, and design-reference match if references exist.
+5. **Map results to acceptance** — walk `spec.md` acceptance criteria; note which are now
+   proven and which aren't. If `test-plan.md` exists, also walk its acceptance→test map and
+   per-gap requirements — a planned test (especially a regression-Critical) with no covering
+   result is an unproven gap, not a pass. **Also walk the test-plan interaction inventory**
+   (every interactive element + user flow): each must have a passing asserting test. An
+   element/flow with no asserting result is an **unproven gap = blocker** — a NO-GO at
+   `/rite-seal`, the same standing as an unproven acceptance criterion (`testing.md`
+   "Completeness"). For UI, the browser proof (step 4) demonstrates the flows; the asserting
+   tests prove the elements.
+5a. **Assertion-strength spot check (critical paths).** For each regression-Critical /
+   irreversible / data-loss path, confirm the covering test actually *can* fail: reject
+   tautological assertions (`toBeDefined`-only, asserting the mock), and **fault-inject** —
+   break the code on purpose (flip a comparison, drop a guard) and confirm the test goes red,
+   then revert. Run the project's mutation-testing tool over the touched criticals if it has
+   one. A test that stays green on deliberately broken code is an unproven gap, not a pass
+   (`testing.md` "Assertion strength"). Record what was fault-checked in `evidence.md`.
+   Run the deterministic gates rather than eyeballing:
+   ```bash
+   D=.claude/skills/devrites-lib/scripts
+   [ -d "$D" ] || D="${CLAUDE_SKILL_DIR:-}/../devrites-lib/scripts"
+   [ -d "$D" ] || D=pack/.claude/skills/devrites-lib/scripts
+   [ -f "$D/test-integrity.sh" ] && { bash "$D/test-integrity.sh"; echo "test-integrity rc=$?"; } || true   # exit 3 = a test was weakened to pass → NO-GO
+   [ -f "$D/mutation-gate.sh" ]  && bash "$D/mutation-gate.sh" || true                                      # changed-files mutation score → band the seal verdict
+   ```
+   For a parser / serializer / encoder / auth-token / pure-transform criterion, add a **round-trip
+   or metamorphic property** check (`decode(encode(x))==x`, `parse∘print==id`) over generated inputs —
+   example tests miss the edge cases these explore. If the same unit regenerated from a paraphrased
+   spec (or a second sample) **diverges in behaviour on shared inputs**, treat that as a low-confidence
+   signal: under AFK it blocks an auto-GO and routes to HITL.
+6. **On failure** → [failure-triage](reference/failure-triage.md) +
+   `devrites-debug-recovery`. Reproduce → isolate → fix within scope → re-run; if a fix
+   would exceed scope, record a blocker.
+7. Update `evidence.md`, `browser-evidence.md` (if UI), and `state.md`.
+
+> **Mid-flight discipline.** When tempted to claim an un-observed pass, skip a rung of the browser-proof ladder, or proceed with slices pending — see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.
+
+## Output
+
+**Footer first** — render the slice meter + flow ribbon by running the progress footer (`progress.sh`, resolved like the step-0 preamble — canonical snippet in `devrites-lib/SKILL.md`); keep the fact lines below it terse (`key value · key value`). Then:
+```
+Proved: <feature>
+Acceptance criteria proven: <n / total>
+Tests:  <cmd → pass/fail (counts)>
+Build:  <cmd → pass/fail>   Lint: <cmd → pass/fail>
+Browser: <ladder rung used + summary | n/a>
+Unresolved failures / blockers: <none | list>
+Next: /rite-polish   (finish the feature → /rite-review → /rite-seal)
+↻ Hygiene: /clear before /rite-polish (evidence.md + browser-evidence.md captured; debug trails noisy). See rules/context-hygiene.md.
+```
+— (see hard rule above).

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

@@ -0,0 +1,25 @@
+# rite-prove — anti-patterns
+
+Load this when standing a non-trivial proof decision, or when tempted to
+report a pass you didn't observe, skip a rung of the browser-proof ladder,
+or proceed without all slices built.
+
+Pack-wide rationalizations + red flags (incl. observed-but-not-recorded):
+see [rules/anti-patterns.md](../../../rules/anti-patterns.md).
+
+## Phase-specific rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "Tests passed during build; that's enough." | Build = per-slice sanity check. Prove = whole-feature suite + build/typecheck/lint + browser. |
+| "Browser proof is overkill for this UI change." | If it's UI and a browser can run, the ladder applies. If you can't, document which rung and why. |
+| "Failure is in pre-existing code, not in this feature." | Still surfaces as a blocker. Feature scope = fix in scope or record + halt. |
+| "Some slices are still pending but the rest can be proved." | No — `/rite-prove` runs once, when every slice is built. Otherwise you're proving a partial system. |
+
+## Red Flags
+
+- Reporting "pass" for a command you didn't actually run.
+- Skipping browser-proof rungs 1–3 because rung 4 (project E2E) was easier.
+- An acceptance criterion left "unproven" without a corresponding blocker note.
+- Tests recorded green but the diff shows the test file wasn't touched (stale run).
+- About to write `evidence.md` without command + output.

package/pack/.claude/skills/rite-prove/reference/browser-proof.md

@@ -0,0 +1,26 @@
+# Browser proof — evidence schema
+
+What `browser-evidence.md` must capture for a UI slice. Delegates to
+`devrites-browser-proof`; this is the record contract.
+
+```markdown
+## Slice <N> — <name>  (<date>)
+- Tooling: browser-harness | devtools-mcp | /run+/verify | <e2e> | manual
+- Route(s): <url(s) exercised>
+- Viewports: 375 / 768 / 1280  (note which were checked)
+- Screenshots: <path(s)>  — described: <what is actually visible>
+- Console: <errors/warnings, or "clean">
+- Network: <failures, or "no failures">
+- Interaction path: <the clicks/inputs performed and the result>
+- Accessibility: <focus order / labels / contrast spot-check>
+- Responsive: <what changed across viewports; any breakage>
+- Limitations: <what could not be verified and why>
+```
+
+## Rules
+- Open every screenshot path and describe it — never assert from the filename.
+- Check at least a small (375) and a large (1280) viewport for layout slices.
+- A clean console + no layout shift are part of the evidence, not extras.
+- If no browser can run, write the manual verification steps a human would follow and
+  mark the slice's browser proof as **pending (manual)**.
+```

package/pack/.claude/skills/rite-prove/reference/failure-triage.md

@@ -0,0 +1,25 @@
+# Failure triage
+
+When a test/build/runtime/browser check fails, triage before fixing. Delegates the deep
+loop to `devrites-debug-recovery`.
+
+## Triage ladder
+1. **Reproduce** — run the failing command again; capture the exact error (quote it).
+2. **Classify** the failure:
+   - test is right, code is wrong → fix the code (in scope).
+   - test is wrong/outdated → that may be **spec drift** (acceptance criteria wrong).
+   - environment/setup (missing dep, wrong node/ruby) → fix setup or record blocker.
+   - flaky (passes on re-run, timing/order) → note it; don't paper over with retries.
+   - external dependency down → record blocker; don't fake the result.
+3. **Isolate** — minimize to the smallest failing case; bisect the diff if needed.
+4. **Fix within scope** — the current slice/feature only. If the fix reaches outside
+   scope, stop and record a blocker in `state.md` (then `/rite-plan unblock`).
+5. **Re-run** the same command; confirm green; record both attempts in `evidence.md`.
+
+## Rules
+- Quote the real error text; don't paraphrase it away.
+- Don't loosen/delete a failing assertion to get green — investigate whether it's drift.
+- Don't add blanket retries/sleeps to hide flakiness.
+- Three failed fix attempts on the same root cause → escalate: `devrites-debug-recovery`
+  for a hypothesis-driven pass, or ask the user.
+- A failure you can't fix in scope is a recorded **blocker**, not a silent skip.

package/pack/.claude/skills/rite-prove/reference/proof-ladder.md

@@ -0,0 +1,26 @@
+# Proof ladder
+
+Prefer real runtime evidence. For UI/browser work, try tools top-down and record which
+rung you used. Detect, don't install — browser tooling setup is the user's call.
+
+1. **browser-harness** (preferred when installed & connected)
+   - Detect: `command -v browser-harness`. Use its doctor/connection check only when
+     safe. Capabilities: navigation, screenshots, coordinate clicks, console logs, DOM
+     reads, network, raw CDP. Connects to the user's Chrome — don't launch a new browser.
+2. **Chrome DevTools MCP** (if configured) — screenshots, DOM, console, network,
+   performance, accessibility tree.
+3. **Claude Code `/run` and `/verify`** (if available) — launch and observe the app;
+   prefer a project-specific run/verify skill if one exists.
+4. **Project-native E2E** (only if already present) — Playwright, Cypress, Capybara,
+   Selenium. Use the project's existing commands; don't add a new framework.
+5. **Manual fallback** — no tooling available: record the limitation and write exact
+   manual steps (route, action, expected result).
+
+## Non-UI scope
+The "ladder" for backend/CLI/data scope is just: targeted tests → build/typecheck/lint
+→ runtime observation (a real request/response or CLI run). Same evidence rules apply.
+
+## Stop conditions
+- Auth wall reached → stop, ask the user; never type credentials from a screenshot.
+- Destructive action required to prove → confirm with the user first.
+- A screenshot tool returns a path → **open and describe it**; a path is not proof.

package/pack/.claude/skills/rite-prove/reference/test-command-discovery.md

@@ -0,0 +1,30 @@
+# Test / build command discovery
+
+Use the project's own commands. Never invent a test runner or build step. Discover from
+these sources, in roughly this order of authority:
+
+| Source | Look for |
+|---|---|
+| `spec.md` → "Commands discovered" | already-found commands (trust first) |
+| `package.json` `scripts` | `test`, `build`, `typecheck`, `lint`, `dev`, `e2e` |
+| `Makefile` / `Justfile` / `Taskfile` | `test`, `build`, `check`, `lint` targets |
+| `Gemfile` / `Rakefile` | `rake test`, `rspec`, `bin/rails test` |
+| `pyproject.toml` / `tox.ini` / `noxfile.py` | `pytest`, `tox`, `nox` |
+| `go.mod` | `go test ./...`, `go build ./...`, `go vet` |
+| `Cargo.toml` | `cargo test`, `cargo build`, `cargo clippy` |
+| CI configs (`.github/workflows`, `.gitlab-ci.yml`, `circleci`) | the exact commands CI runs — the source of truth for "green" |
+| README / CONTRIBUTING | documented dev/test workflow |
+| framework conventions | Rails/Django/Next/etc. defaults when nothing else is set |
+
+## Targeted first
+Run the **narrowest** command that exercises the slice (a single test file/path),
+then widen. A full suite is slower and noisier; use it for the final check, not the
+inner loop.
+
+## Record what you found
+Write the discovered commands back into `spec.md` → "Commands discovered" so later
+phases (and `/rite-seal`) don't rediscover them. Note the runner version if it matters.
+
+## If nothing exists
+No tests in the project: say so. Propose the minimal test setup as a **follow-up**
+(ask before adding a framework), and prove the slice via runtime observation meanwhile.

package/pack/.claude/skills/rite-quick/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: rite-quick
+description: Express lane for a SMALL, reversible change — one short artifact, then build → prove → ship, collapsing the full spec → define → vet → build → prove → review → seal lifecycle into one pass. Use when the user says "quick fix", "small change", "tiny tweak", "just do X", or for a typo / copy / config / single-function / one-file change that is low-risk and unambiguous. Escalates to `/rite-spec` (full lifecycle) the moment scope, risk, or ambiguity grows. Not for auth / data-model / migration / public-API / multi-slice / ambiguous work — those need the full lifecycle.
+argument-hint: "<what to change>"
+user-invocable: true
+---
+
+# /rite-quick — express lane for small changes
+
+The full DevRites lifecycle is right for real features; it is **ceremony** for a typo, a
+copy tweak, a one-function fix, or a small config change. `/rite-quick` keeps the
+discipline that matters (idiom, TDD, evidence, escape-to-full-lifecycle) and drops the
+artifacts that don't, in a **single pass**. Senior-engineer "right step, right time" made
+executable, not advisory.
+
+## The significance gate (the whole safety story)
+
+**Run this first. If ANY of these holds, STOP and route to `/rite-spec` — do NOT use the
+express lane:**
+- Touches **auth / authz**, a **data migration**, a **public API contract**, or any
+  **destructive / data-loss** path (the irreversible-risk list — `rules/afk-hitl.md`).
+- Spans **more than one vertical slice**, or more than a couple of files of real logic.
+- **Ambiguous scope** — you'd have to guess what "done" means, or the ask hides a design
+  decision (data model, new dependency, second design system).
+- Security-sensitive input handling, or a measurable performance-critical path.
+
+If none hold, the change is small + reversible + unambiguous → proceed. **When in doubt,
+escalate** — the cost of the full lifecycle on a small change is minutes; the cost of the
+express lane on a risky one is the failure mode the lifecycle exists to prevent.
+
+## Rules consulted
+Read `.claude/rules/core.md` first. Then the small set this lane actually needs:
+- `coding-style.md` — naming, guard clauses, reuse-first.
+- `testing.md` — TDD, **completeness** (every touched behavior/element asserted) +
+  **assertion strength** (no tautological tests; see it fail first), scaled to the change.
+- `error-handling.md` / `security.md` — only if the change touches input/errors.
+
+## Workflow
+0. **Orient.** Read `core.md`. If a `.devrites/` workspace is active, run the preamble to
+   see it; `/rite-quick` does **not** require one and does **not** create the full tree.
+1. **Significance gate** (above). Fail → STOP, tell the user to run `/rite-spec <feature>`.
+2. **One-line contract.** Restate in 1–3 lines: the change, its **acceptance** (how you'll
+   know it works), and the **scope boundary** (what you will NOT touch). This is the entire
+   "spec + plan" for a quick change — keep it in the chat; optionally drop a `brief.md` +
+   `evidence.md` under `.devrites/work/<slug>/` if the user wants a record. This is the
+   `/rite-frame` FRAME move: if the acceptance won't reduce to a check that could be *false*,
+   the ask is ambiguous → escalate per the significance gate. Its AUDIT pass is the diff
+   self-review in step 5.
+3. **Build with TDD.** Failing test first when behavior changes (see it fail for the right
+   reason) → smallest complete change in the **project's idiom** (reuse before you write,
+   anti-AI-slop) → cover every touched behavior / interactive element with a **real**
+   assertion. UI → check the states + a browser glance.
+4. **Prove (scoped).** Run the **targeted** tests + typecheck / lint for what changed (not
+   the whole suite) → green. Record the command + output. A tautological test that can't
+   fail is not proof.
+5. **Review-lite + ship.** Self-review the diff (correctness, scope, idiom — one pass, no
+   subagent fan-out). Show the diff, then on the user's confirm commit it (Conventional
+   Commits, atomic) — or hand to `/rite-ship` if a workspace is active. **Never push without
+   the user asking.**
+
+## Escalation (mid-flight) — the Spec Drift Guard still applies
+If the "small" change turns out to be not small — a second slice appears, a real design
+decision surfaces, scope grows past the boundary, or you hit an irreversible-risk item —
+**STOP, say so, and route to `/rite-spec` / `/rite-define`**. Don't quietly grow a quick
+fix into an unreviewed feature; that's the exact drift the lifecycle guards against.
+
+## Output
+**Footer first** — render the flow ribbon by running the progress footer (`progress.sh`,
+resolved like the step-0 preamble — canonical snippet in `devrites-lib/SKILL.md`) when a
+workspace is active; otherwise skip it. Then:
+```
+Quick change: <one line>
+Scope: <files touched>   (boundary held? yes)
+Tests: <cmd → pass>   ·   Assertion check: <real asserts, saw red | n/a>
+Diff: <summary>
+Next  ▸ commit (Conventional) on your confirm  ·  or /rite-ship if tracked
+↻ Hygiene: /clear after commit — the change is small and self-contained.
+```
+
+**DO NOT** use this lane to dodge the gate — the express lane is for changes that are
+*actually* small, not for shipping risky work faster.