devrites 1.19.0

package/pack/.claude/skills/rite-spec/reference/acceptance-criteria.md

@@ -0,0 +1,31 @@
+# Acceptance criteria
+
+Acceptance criteria are the contract the seal checks. Write them so each is
+**independently verifiable by evidence**, not opinion.
+
+## A good criterion
+- Is observable: a test passes, a command outputs X, a screenshot shows Y.
+- Is binary: met or not — no "mostly".
+- Names the evidence: "`npm test path/x.test.ts` passes" or "POST /export returns 200
+  with a CSV body" or "empty state renders 'No exports yet' at 375px".
+- Belongs to a slice: every criterion maps to at least one slice (mapped in `/rite-define`).
+
+## Forms
+| Type | Template |
+|---|---|
+| Functional | "Given <state>, when <action>, then <observable result>." |
+| API | "<METHOD> <route> with <input> returns <status> and <shape>." |
+| UI | "<screen> shows <element/state> at <viewport>; <interaction> does <result>." |
+| UI vs reference | "<screen> matches design reference <Rn> at <viewport>." |
+| Non-functional | "<operation> completes under <budget> / handles <volume>." |
+| Negative | "<invalid input> is rejected with <message>, no <side effect>." |
+
+## Anti-patterns
+- "Works well" / "is fast" / "looks good" — unverifiable. Attach a number or an
+  observation.
+- Criteria with no slice — orphaned scope.
+- Criteria only provable by reading the code — require runtime/test evidence instead.
+
+## At seal time
+Each criterion gets a checkbox + the evidence that proves it. Unproven critical
+criteria force **NO-GO**.

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

@@ -0,0 +1,25 @@
+# rite-spec — anti-patterns
+
+Load this when standing a non-trivial decision in `/rite-spec`, or when the
+agent feels reluctance toward investigation depth, gap-closing, or
+placement decisions.
+
+Pack-wide rationalizations + red flags: see [rules/anti-patterns.md](../../../rules/anti-patterns.md).
+
+## Phase-specific rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "User said *just make it work* — no spec needed." | Vague asks are exactly where `/rite-spec` earns its keep; load `devrites-interview` and ask one question at a time. |
+| "I already understand the request." | Then writing the placement + acceptance criteria takes minutes and saves drift later. Investigation isn't for *you*, it's for `/rite-define`. |
+| "Too small for a spec." | If it's big enough for `/rite-build`, it's big enough for one paragraph of WHAT/WHY + measurable acceptance. |
+| "No design refs were attached, so skip references." | Skip the *gathering*, not the *acknowledgement*. Note "no references provided" in the spec — silence is ambiguous. |
+| "I can resolve gaps as I build." | Drift discovered at slice 3 costs more than 5 questions answered now. |
+
+## Red Flags
+
+- About to start writing `spec.md` without a Placement & integration section.
+- Spec has no measurable acceptance criteria — "works as expected" is not measurable.
+- A `[NEEDS CLARIFICATION]` marker remains on a blocking item.
+- Design references were attached but never opened, saved, or indexed in `references.md`.
+- The investigation didn't read the module/component that currently owns this area.

package/pack/.claude/skills/rite-spec/reference/interview-patterns.md

@@ -0,0 +1,56 @@
+# Interview patterns
+
+Question ladders by domain. Pull the rung that matches the biggest current unknown.
+Each question still follows the protocol: one at a time, best guess attached.
+
+## Vague ask? Map the decision tree first
+For a fuzzy one-liner (`"design a contact page"`, `"add reporting"`), sketch the branches
+the answer splits into, then resolve each **depth-first** — one branch to a decision before
+opening the next:
+
+```text
+contact page
+├─ purpose?   ── sales lead | support request | general
+├─ fields?    ── name/email/message | + company/phone | file upload
+├─ on submit? ── email | ticket/CRM | DB row | embedded third-party form
+└─ success?   ── inline confirm | redirect | autoresponder
+```
+
+Once per interview you may **challenge the premise** instead of refining it
+(*"is a form even the right answer, or a mailto / booking link?"*) — a good reframe
+collapses whole branches. Then use the domain ladders below for each open branch.
+
+## Objective / problem
+- "What does success look like in one sentence?"
+- "Who hits this, how often, and what do they do today instead?"
+- "If we shipped only one thing here, what must it be?"
+
+## Scope boundaries
+- "What is explicitly **out** of scope for this first version?"
+- "Is this a new capability or a change to an existing flow?"
+- "What's the smallest version that's still useful?" (→ slice 1)
+
+## Data model
+- "What are the core entities and how do they relate?"
+- "What's the source of truth, and can these fields change after creation?"
+- "Any uniqueness, ordering, or soft-delete needs?"
+
+## UX / flow
+- "Walk me through the happy path screen by screen."
+- "What are the empty / loading / error / permission-denied states?"
+- "Brand surface (marketing) or product surface (app UI)?" (drives craft)
+
+## Integration / external
+- "Which external systems or APIs are involved, and who owns them?"
+- "Sync or async? What happens when the dependency is down?"
+
+## Non-functional
+- "Any latency, scale, or volume targets I should design to?"
+- "Auth/permission rules? Anything sensitive (PII, secrets, payments)?"
+
+## Acceptance
+- "How will we *prove* this works — what's the test or observation?"
+- "What would make you reject the PR?"
+
+## Anti-references (taste)
+- "Show me one thing that does this well, and one that does it badly."

package/pack/.claude/skills/rite-spec/reference/investigation.md

@@ -0,0 +1,64 @@
+# Investigation — understand deeply before specifying
+
+The spec is only as good as the investigation behind it. Goal: understand the
+requirement **completely**, decide **where it correctly belongs**, name what it
+**resolves**, and surface every **issue and gap** — then drive the gaps to closure with
+the user so the spec ships fully-covered and correctly-placed. A gap found here is cheap;
+a gap found in `/rite-build` is a drift event.
+
+Use a code-intelligence index if available — codebase-memory-mcp first, cross-checked with codegraph + graphify, else standard methods (LSP / Read/Grep/Glob)
+(see `../../../rules/tooling.md`) — for the structural parts below; it answers "where does this
+live / what calls it / what would it break" far more cheaply and accurately than reading files.
+With none present, fall back to Read/Grep/Glob.
+
+## Produce these findings (write into spec.md)
+1. **The real ask** — restate the goal and the *problem behind the request* (people ask
+   for "a dashboard" when they want an answer to a question). Who hits it, how often,
+   what they do today instead.
+2. **Current behavior** — how it works today, or what's absent. Read the actual code and
+   flows; don't assume.
+3. **Placement — where it should live** *(so it's correctly placed to be used)*
+   - Which module / layer / file / component should own this; the right seam.
+   - Existing patterns/components/utilities to **extend or reuse** instead of duplicating.
+   - **Integration points**: callers and dependents, the data it reads/writes, the
+     APIs/events/contracts it touches (interface analysis — how it interacts with the
+     rest of the system).
+4. **What it resolves** — the outcome/value and how we'll *observe* it's resolved (feeds
+   success + acceptance criteria).
+5. **Issues** — conflicts with existing code/UX/data/permissions, constraints, and
+   anything that makes the obvious approach wrong. Each issue gets a disposition.
+6. **Gaps** — unknowns, ambiguities, undecided behavior, missing inputs. **Every gap
+   becomes a question** (next section).
+7. **Blast radius** — what this change could break (use the code graph's impact/callers).
+   Informs risks, test strategy, and rollback.
+
+Also gather any **design/reference materials** the human supplies (screenshots, Figma,
+links, video) — see [references-intake](references-intake.md). They're part of
+understanding the requirement and become the target later phases verify against.
+
+## Gap analysis (present → desired)
+State the **present state** and the **desired state**; the delta is the work, and the
+**unknowns in the delta are the gaps**. Drive the count of open gaps toward zero before
+handing off to `/rite-define`. Mark each gap inline with `[NEEDS CLARIFICATION: question]`.
+
+## Turn gaps & issues into questions WITH options
+For each material gap/issue (one that changes scope, placement, data model, UX, security,
+migration risk, or acceptance), ask the user — one question at a time, **best guess
+attached**, with structured options and an escape hatch:
+```
+<gap/issue stated in one line>. Why it matters: <...>
+1. <option A> — <implication / where it places the work>
+2. <option B> — <implication>
+3. <option C> — <implication>
+4. Something else — I'll describe it
+   (My best guess: #2, because <reason>.)
+```
+Resolve material gaps before finalizing the spec. Reversible, low-impact gaps: decide,
+record in `assumptions.md`, and move on — don't interrogate.
+
+## Done when
+- The real problem, current behavior, placement, and what-it-resolves are written down.
+- Every issue has a disposition; every material gap is resolved (or explicitly deferred
+  as non-blocking).
+- No blocking `[NEEDS CLARIFICATION]` remains — the spec is **fully covered and correctly
+  placed**. This is the `/rite-spec` readiness gate before `/rite-define` plans it.

package/pack/.claude/skills/rite-spec/reference/question-protocol.md

@@ -0,0 +1,61 @@
+# Question protocol
+
+The discipline behind `/rite-spec` and `devrites-interview`.
+
+## One question at a time
+Ask exactly one question per turn. Multiple questions at once get one answered and the
+rest ignored, and they signal you haven't prioritized.
+
+## Always attach your best guess
+Every question carries your current assumption and *why*:
+> "I'm assuming the export is CSV only (simplest, covers the stated use case). Right,
+> or do you need XLSX/PDF too?"
+This converts an open question into a cheap yes/no correction and reveals your model so
+the user can fix the premise, not just the question.
+
+## Highest-value question first
+Order by how much the answer changes the build. A question that changes the data model
+or acceptance criteria beats a cosmetic one. If two are equal, ask the one that unblocks
+the most downstream work.
+
+## Structured options when the space is enumerable
+```
+1. <option> — <what it implies for build/scope>
+2. <option> — <implication>
+3. <option> — <implication>
+4. Something else — I'll describe it
+```
+Always include the escape hatch (#4). Mark your recommended option.
+
+## Stop conditions (any one)
+- **Confidence** — you can predict the user's answer to the next question (~95%).
+- **Convergence** — the last 2–3 answers only rubber-stamped your guesses; the spec
+  stopped moving.
+- **Soft cap** — after ~8 material questions, proceed with best-guess answers logged as
+  assumptions (hard-stop sooner if the ask is small).
+
+If you keep circling one area without progress, **reframe once** — challenge the premise
+rather than asking again.
+
+## Coverage gate — am I done asking?
+Before declaring the interview complete, each dimension is **resolved** or **explicitly
+deferred** (logged, non-blocking) — never silently skipped:
+- [ ] **Objective** — one-sentence success + the real problem behind it.
+- [ ] **Scope** — what's in vs explicitly out for v1.
+- [ ] **Data model** — core entities + relationships (or "none").
+- [ ] **UX / flow** — happy path + empty / loading / error / permission states (or "no UI").
+- [ ] **Integration** — external systems / APIs / contracts (or "none").
+- [ ] **Non-functional** — auth, sensitive data, latency / scale (or "n/a").
+- [ ] **Acceptance** — how each requirement is *proven* (test / observation).
+
+A blocking gap in any dimension keeps the interview open; a deferred one goes to
+`questions.md` and doesn't block. This feeds the `/rite-spec` readiness gate.
+
+## What NOT to ask
+- Things the codebase answers (read it first).
+- Reversible implementation details (decide and note as an assumption).
+- Everything at once "to be thorough." Thoroughness is depth on the few that matter.
+
+## Record
+Confirmed answers → `decisions.md` (with rationale). Standing assumptions →
+`assumptions.md`. Open non-blocking items → `questions.md`.

package/pack/.claude/skills/rite-spec/reference/references-intake.md

@@ -0,0 +1,57 @@
+# Reference intake — design/style materials from the human
+
+During the spec phase the human **may** hand you **how it should look or behave**:
+screenshots, mockups, a Figma link, a video of a flow, a reference site, or a doc — **or
+nothing at all** (no design, no screenshots, no explanation is perfectly normal). This is
+entirely **optional**. When references *are* given, treat them as first-class inputs:
+gather them, understand them, **save the local ones**, and index them so every later phase
+(build, prove, polish, seal) can check the work against them. When there are none, skip
+this and proceed with the spec.
+
+## Gather + understand each reference
+- **Images / screenshots / mockups** — open and **view** them (the Read tool renders
+  images). Describe what they show: layout, components, spacing, states, the target look.
+- **Figma link** — if a Figma integration is available, pull its design context (frames,
+  tokens, components); otherwise record the link and ask the human for an export/screenshot
+  so there's something concrete to match offline.
+- **Links / reference sites / docs** — fetch and read for the relevant intent (tone,
+  layout, interaction, quality bar). Capture *why* it's a reference, not just the URL.
+- **Video** — note what it demonstrates (the expected interaction/flow). Save it; later
+  phases can step through it as tooling allows.
+
+## Save local assets into the workspace
+Copy any local file (screenshot, mockup, video, export) into
+`.devrites/work/<slug>/references/` so it's durable and connectable later:
+```
+mkdir -p .devrites/work/<slug>/references
+cp "<the file the human gave>" .devrites/work/<slug>/references/<clear-name>.<ext>
+```
+Use clear names (`login-mockup.png`, `checkout-flow.mp4`). Don't move the user's
+original; copy it. For remote-only refs (a live Figma/URL), record the link in the index.
+
+## Index in `references.md`
+```markdown
+# References: <slug>
+| Ref | Type | Location | Shows / why it's a reference | Informs |
+|-----|------|----------|------------------------------|---------|
+| R1 | screenshot | references/login-mockup.png | target login layout + spacing | spec UI, slice 2, polish |
+| R2 | figma | https://figma.com/… (+ export references/tokens.png) | design tokens, component set | all UI |
+| R3 | video | references/checkout-flow.mp4 | expected step order + transitions | build, prove |
+| R4 | link | https://example.com | tone + density to match | craft |
+```
+
+## Feed them into the spec + the design brief
+- Use references to sharpen `spec.md` (UI impact, success/acceptance — e.g. "matches R1").
+- When the feature touches UI, these references are the primary input to **`devrites-ux-shape`**
+  (spec step 3a): they anchor the design direction and can seed the visual-direction probe
+  (a Figma link → pulled design context; reference sites → screenshots). The resulting
+  `design-brief.md` cites them by R-id.
+- A reference can *resolve a gap* ("which layout?") — record that in the gaps table.
+- If a reference **conflicts** with the existing design system, that's an issue to raise
+  with the human (match the system, or adopt the reference — their call).
+
+## Later phases use them (wire-through)
+`devrites-frontend-craft` builds **to** the references; `/rite-polish` compares the built
+UI **against** them; `/rite-prove` / `browser-evidence.md` verify against them; `/rite-seal`
+checks "matches the agreed design references" as acceptance. So save them once here and
+everything downstream can connect to them.

package/pack/.claude/skills/rite-spec/reference/spec-checklists.md

@@ -0,0 +1,73 @@
+# Spec-quality checklists — "unit tests for the English"
+
+Before the spec hands off to `/rite-define`, test the **requirement prose itself** the way you'd
+unit-test code: is each requirement complete, unambiguous, and measurable? These checklists
+interrogate the *writing*, not the implementation — there is no code to run yet. A criterion like
+"the banner is prominent" passes a human skim and fails here ("prominent" is unquantified).
+Catching it now is a one-line spec edit; catching it at `/rite-prove` is a reslice.
+
+**Not implementation tests.** A checklist item asks "is *export* defined for an empty dataset?" —
+it does **not** ask "does `exportCsv()` handle `[]`?". The first tests the spec; the second is
+`/rite-vet`'s test-plan and `/rite-prove`'s job. These files never name a function, file, or library.
+
+## Output — one file per requirement domain
+
+Emit `.devrites/work/<slug>/checklists/<domain>.md`, one per domain the spec actually covers (skip
+a domain the spec marks "none"). The domains mirror the interview taxonomy, so a gap here maps to a
+`devrites-interview` dimension:
+
+| Domain file | Tests the prose of |
+|---|---|
+| `functional.md` | Functional requirements + scenarios — is each capability stated, bounded, testable? |
+| `data-model.md` | Key entities / data model — shapes, fields, lifecycle, relationships (skip if "none"). |
+| `interaction.md` | API / UI impact + UX states — every screen state and contract named (skip if no UI/API). |
+| `non-functional.md` | Constraints, auth / data sensitivity, latency / scale / compatibility budgets. |
+| `edge-cases.md` | Empty / boundary / invalid / concurrent / failure paths the requirements imply. |
+
+## Each item — a question, a verdict, the line it interrogates
+
+```markdown
+# Spec checklist: <domain> — <slug>
+Scored: <iso>   Verdict: pass | gaps (<n CRITICAL / n minor>)
+
+| # | Question (tests the requirement prose) | Verdict | Spec line | Severity |
+|---|---|---|---|---|
+| 1 | Is every quantitative qualifier ("prominent", "fast", "large") given a number or reference? | fail | "banner is prominent" | **CRITICAL** |
+| 2 | Does each requirement name an observable outcome a test could check? | pass | FR-001..004 | — |
+| 3 | Are all enumerations closed — no "etc." / "and so on" / open "…"? | pass | — | — |
+```
+
+Verdict is `pass` / `fail` / `n/a`. A `fail` carries a severity:
+- **CRITICAL** — the ambiguity would change the build or its acceptance: an unquantified
+  acceptance/success criterion, an incomplete enumeration in a requirement, an ambiguous data
+  shape, an undefined edge case on a stated flow, a contradictory pair of requirements.
+- **minor** — vague but non-load-bearing prose. Record it; it does not block.
+
+## The question bank (seed — extend per domain)
+
+Each question tests one of the failure modes of requirement prose:
+- **Measurability** — every "good / fast / prominent / simple / secure" carries a number, a budget,
+  or a named reference. No adjective stands in for a threshold.
+- **Completeness** — every enumeration is closed (no "etc."); every requirement with a precondition
+  states the failure branch; every entity names its required fields + lifecycle; every stated flow
+  names its empty / error / boundary behaviour.
+- **Clarity** — one entity, one name (no `user`/`customer`/`account` drift); no requirement two
+  readers would implement differently; no "should" where "MUST" is meant.
+- **Testability** — each acceptance criterion is binary and names (or clearly implies) its evidence.
+  A criterion only provable by reading code is a fail.
+- **Consistency** — no requirement contradicts another, the data model, or a non-goal.
+
+## How it feeds the readiness gate
+
+The spec **Readiness gate** (bottom of [`spec-template.md`](spec-template.md)) folds these in: every
+emitted `checklists/<domain>.md` must reach `Verdict: pass` (zero CRITICAL fails) before the gate
+passes. Minor fails are logged, not blocking. A single open CRITICAL keeps the spec `Status: Draft`.
+`/rite-define` reads the checklists at its step 0 and **hard-blocks while any CRITICAL is unchecked**;
+a spec that skips the checklists is treated as not-yet-scored — define stops and routes back here.
+
+## Discipline
+- Score honestly. A checklist you pass by softening the *question* instead of the *spec* is the
+  spec-quality version of weakening a test to go green — it defeats the gate.
+- Don't pad. Five real questions that find one CRITICAL beat thirty rubber-stamped rows.
+- These are *English* tests. The moment a question needs a function name to answer, it belongs in
+  `/rite-vet`'s `test-plan.md`, not here.

package/pack/.claude/skills/rite-spec/reference/spec-template.md

@@ -0,0 +1,124 @@
+# `spec.md` template
+
+Write **what** to build and **why** — never **how** (implementation goes in `plan.md`,
+written later by `/rite-define`). Ground every section in the codebase you investigated;
+don't invent files, commands, or conventions.
+
+**Two hard rules:**
+1. **Mark every unknown** with `[NEEDS CLARIFICATION: the exact question]` instead of
+   guessing. Open markers block `/rite-define` and `/rite-build` (no silent assumptions).
+2. **No implementation details** in the spec — no tech/library/endpoint choices in the
+   requirements or success criteria. Those are technology-agnostic.
+
+```markdown
+# Spec: <Feature>
+Slug: <kebab-case>   Created: <date>   Status: Draft | Ready
+
+## Objective
+One paragraph: what this delivers and the value. WHAT + WHY, not HOW.
+
+## Users / actors
+Who uses it and the goal each has.
+
+## Problem statement
+What's broken/missing today; what users do instead.
+
+## User scenarios  *(prioritized, each independently testable)*
+Order by importance; each scenario should be shippable + verifiable on its own → it
+becomes a build slice. Use Given/When/Then.
+- **P1** — Given <state>, When <action>, Then <observable outcome>.
+- **P2** — Given <state>, When <action>, Then <observable outcome>.
+- **P3** — ...
+
+## Functional requirements  *(testable, unambiguous)*
+Number them so tasks and the seal can reference them.
+- **FR-001**: The system MUST <capability>.
+- **FR-002**: The system MUST <capability>.
+- **FR-003**: The system MUST NOT <prohibited behavior>.
+  (Mark gaps: "FR-004: [NEEDS CLARIFICATION: is export CSV-only or also XLSX?]")
+
+## Key entities / data model   *(if data is involved, else "none")*
+Entities, key fields, relationships, lifecycle (created/updated/soft-deleted). No DB
+schema here — that's the plan.
+
+## API / UI impact   *(else "none")*
+Endpoints + contracts (shape, status, errors) at the WHAT level; screens + the states
+each must handle (default/loading/empty/error/success/disabled).
+
+## Design references   *(if the human supplied any, else "none")*
+The screenshots / mockups / Figma / video / links that define the target look & behavior,
+from references.md. Name what each shows and which scenarios it governs.
+- R1 — references/<file> or <url> — <what it shows> → governs <scenario/FR>
+
+## UX/UI design brief   *(if the feature touches UI, else "n/a")*
+When UI is involved, `devrites-ux-shape` writes the feature-level **`design-brief.md`** here
+(design direction, key states, interaction model, visual-direction probe) — the target
+`/rite-build` builds to. Summarize its direction in one line; the full brief lives in
+`design-brief.md`.
+- Direction: <color strategy> · "<scene sentence>" · anchors: <ref A, ref B>
+
+## Success criteria  *(measurable AND technology-agnostic)*
+Observable outcomes that mean "this worked". Numbers where possible. No tech names.
+- Good: "A user exports 10k rows and receives a complete file in under 5s."
+- Good (UI): "The list view matches reference R1 at 1280px and 375px."
+- Bad: "The /export Sidekiq job uses streaming CSV." (that's HOW — belongs in plan)
+
+## Acceptance criteria
+Binary, evidence-backed checklist; each maps to a scenario/FR. See acceptance-criteria.md.
+- [ ] <criterion> (FR-00x)
+
+## Non-goals
+Explicitly out of scope for this version.
+
+## Constraints
+Tech/time/compatibility/perf/security/compliance constraints that bound the solution.
+
+## Placement & integration  *(where it lives — from investigation.md)*
+So the work is **correctly placed to be used**, not bolted on:
+- **Owns / lives in**: the module / layer / file / component that should hold this, + the
+  right seam.
+- **Reuse / extend**: existing patterns, components, utilities to build on — not duplicate.
+- **Integration points**: callers & dependents; data read/written; APIs / events /
+  contracts touched (how it interacts with the rest of the system).
+- **Affected areas**: the real modules / routes / models / components this change touches.
+- **Blast radius**: what could break (from the code-graph impact / callers).
+
+## Commands discovered
+- Tests: <cmd>   Build/typecheck: <cmd>   Lint: <cmd>   Run/dev: <cmd>
+(From package scripts / Makefile / Gemfile / pyproject / go.mod / CI.)
+
+## Test strategy
+What proves each acceptance criterion (unit/integration/e2e/manual).
+
+## Browser proof strategy   *(if UI, else "n/a")*
+Which proof-ladder rung, which routes/viewports, and which design references to verify against.
+
+## Risks
+Ranked. Include migration / data / security / UX risks.
+
+## Gaps, issues & decisions  *(drive the open count toward zero before /rite-define)*
+Every material gap/issue found in investigation, the options offered to the user, and the
+outcome. Resolved here = not rediscovered as drift later.
+| Item | Type (gap / issue / conflict) | Options offered | Decision (owner) | Status |
+|------|------------------------------|-----------------|------------------|--------|
+| <e.g. token scope> | gap | per-user / per-session / follow-up | per-session (user) | resolved |
+
+## Open questions  *( [NEEDS CLARIFICATION] register )*
+List every open marker; blocking ones must be zero at the gate.
+
+## Boundaries
+- **Always do**: conventions to follow without asking.
+- **Ask first**: new deps, second design system, schema/migration, auth changes, scope expansion.
+- **Never do**: destructive ops, drive-by refactors, unrelated cleanup.
+
+## Readiness gate  *(must pass before /rite-define plans it)*
+- [ ] No blocking `[NEEDS CLARIFICATION]` markers remain (deferred ones are non-blocking)
+- [ ] **Placement decided** — where it lives + integration points are known
+- [ ] All material gaps/issues have a recorded decision
+- [ ] **Every spec dimension resolved or explicitly deferred** — objective · scope · data model · UX · integration · non-functional · acceptance (see question-protocol.md "Coverage gate")
+- [ ] Design references gathered + saved (if the human supplied any)
+- [ ] **UX/UI shaped into `design-brief.md`** (if the feature touches UI) — direction, key states, interaction model decided
+- [ ] Requirements are testable and unambiguous
+- [ ] Success criteria are measurable and technology-agnostic
+- [ ] **Spec-quality checklists pass** — every `checklists/<domain>.md` reaches `Verdict: pass` (zero CRITICAL "unit-tests-for-English" fails; see [spec-checklists.md](spec-checklists.md))
+```