refactor(workflow-preset): make UI/UX specification template-owned

presets/catalog.community.json

@@ -682,7 +682,7 @@
         "speckit_version": ">=0.8.10.dev0"
       },
       "provides": {
-        "templates": 22,
+        "templates": 23,
         "commands": 8
       },
       "tags": [

presets/catalog.json

@@ -40,7 +40,7 @@
       },
       "provides": {
         "commands": 8,
-        "templates": 22
+        "templates": 23
       },
       "tags": [
         "behavior",

presets/workflow-preset/CHANGELOG.md

@@ -2,6 +2,15 @@
 
 ## Unreleased
 
+- Added a wrapping `spec-template` as the single owner of the source-agnostic
+  `UI/UX Specification` structure, including stable `UI-###` and `UX-###`
+  requirements.
+- Removed design-provider and intake-evidence dependencies from runtime
+  commands, templates, validators, protocols, and public documentation.
+- Separated UI/UX Applicability (`Required`, `Not Applicable`, `Unknown`) from
+  specification Readiness (`Ready`, `Blocked`) across checklist, planning,
+  task, implementation, and receipt contracts.
+
 ## 1.3.12 - 2026-07-01
 
 - Added a shared cross-agent protocol contract with command profiles for specify, plan, tasks, analyze, and implement, while keeping persistent handoff orchestration scoped to `/speckit.implement`.

presets/workflow-preset/commands/speckit.checklist.md

@@ -1,5 +1,5 @@
 ---
-description: Wrap core checklist generation with BDD, NFR, and Visual Fidelity readiness gate.
+description: Wrap core checklist generation with BDD, NFR, and UI/UX specification readiness gates.
 strategy: wrap
 ---
 
@@ -11,64 +11,30 @@ Checklists validate whether requirements are complete, clear, consistent, measur
 
 CORE PRINCIPLE - Test the Requirements, Not the Implementation. Checklist questions must use requirement-quality forms such as "Are ... specified?", "Is ... quantified?", "Can ... be objectively verified?", or "Are ... requirements consistent?"
 
-Use `$ARGUMENTS` as checklist intent. Generate dynamic clarifying questions with no pre-baked catalog only when the answer changes BDD, NFR, or Visual Fidelity checklist content. Use Q1/Q2/Q3 for initial questions and Q4/Q5 only for justified follow-up gaps.
+Use `$ARGUMENTS` as checklist intent. Generate dynamic clarifying questions with no pre-baked catalog only when the answer changes BDD, NFR, or UI/UX specification checklist content. Use Q1/Q2/Q3 for initial questions and Q4/Q5 only for justified follow-up gaps.
 
-For `checklists/behavior-testability.md`, create the file when absent; otherwise append or update without deleting existing checklist content. Before finishing, report the full path, item count, update mode, focus areas, depth level, actor/timing, must-have items, readiness status, and blockers.
+For `checklists/behavior-testability.md`, create the file when absent; otherwise append or update without deleting existing checklist content. Resolve `behavior-testability-checklist-template` through the normal template stack and treat it as the only stable authority for checklist headings, item wording, matrices, columns, and status enums. Do not reproduce those structures in this command.
 
-## BDD Readiness Gate
+## Readiness Gate Behavior
 
-Create or update `checklists/behavior-testability.md` as checklist artifacts only. This checklist is the plan-entry quality gate for BDD readiness and must evaluate requirements directly from `spec.md`; it must not depend on behavior drafts.
+Populate the resolved checklist template directly from `spec.md`. The checklist is the plan-entry quality gate and must not depend on behavior drafts or implementation artifacts.
 
-Include these sections:
+Evaluate:
 
-- User Story Readiness
-- Acceptance Criteria Quality
-- Scenario Coverage
-- Case Coverage Matrix
-- Given Readiness
-- When Readiness
-- Then Readiness
-- Visual Fidelity Readiness
-- Visual Fidelity Evidence Matrix
-- Non-Functional Requirement Readiness
-- Gate Status
-- Blocking Items
+- observable and independently testable user-story behavior;
+- primary, alternate, exception, boundary, permission, validation, and state-conflict coverage when applicable;
+- explicit Given starting conditions, When triggers, and Then outcomes;
+- product-level non-functional requirement applicability and verifiability;
+- UI/UX requirement applicability, observable acceptance criteria, required states, responsive behavior, accessibility, content, and visual hierarchy.
 
-Check that each applicable user story has observable acceptance behavior, each acceptance criterion is verifiable, and primary, alternate, exception, boundary, permission, validation, and state_conflict paths are covered when applicable.
+For UI/UX rows, keep requirement applicability (`Required | Not Applicable | Unknown`) separate from specification readiness (`Ready | Blocked`). Use the stable `UI-###` or `UX-###` requirement ID from `spec.md`. `Unknown` applicability and incomplete Required requirements must appear in Blocking Items when they prevent downstream planning.
 
-Build a Case Coverage Matrix with one row per story or capability case type. Use case status: Required|Not Applicable|Unknown. Cover positive, negative, boundary, permission, validation, and state_conflict case types. Each row must have a stable Case ID. Required rows must cite the source `spec.md` section. Scenario IDs and `case_coverage_blockers` are assigned during `/speckit.plan`. Not Applicable requires rationale. Unknown must appear in Blocking Items. Required case type without observable acceptance behavior blocks PASS.
+Set `Gate Status: PASS` only when every applicable readiness item is checked and `Blocking Items: none`. Otherwise set `Gate Status: BLOCKED` and list each requirement-quality gap that prevents behavior projection or planning.
 
-Check Given readiness from `spec.md`: required roles, permissions, starting state, entity state, and data are explicit enough for later fixture setup.
-
-Check When readiness from `spec.md`: each trigger is an executable user action, request case, or system trigger.
-
-Check Then readiness from `spec.md`: each outcome maps to feedback, business state, error semantics, or assertion intent.
-
-Check Visual Fidelity Readiness when `spec.md` contains `Visual & UI Specification`, visual requirements, visual SSOT refs, HTML SSOT refs, structured IR refs, external intake refs, provider evidence blockers, or provider-specific evidence requests. Also apply it when `spec.md` contains product-side visual requirements such as pixel-perfect, brand-critical, responsive visual, or UI visual acceptance requirements.
-Use the behavior-testability checklist template as the visual gate authority.
-Check Visual/UI Coverage from `spec.md`: `Visual & UI Specification` exists when a visual or UI surface applies; otherwise `spec.md` records a Not Applicable rationale. Every identified visual/UI requirement must use status `Required`, `Not Applicable`, `Unknown`, or `[BLOCKED: PROVIDER_EVIDENCE]`.
-Require source traceability, external intake readiness status when cited, HTML SSOT refs, structured IR refs, evidence refs, provider blocker status, and clear visual requirements for state, responsive, accessibility, component mapping, and accepted exception coverage.
-Build a Visual Fidelity Evidence Matrix with one row per visual requirement. Record requirement status, dependency on provider evidence, visual SSOT refs, HTML SSOT refs, structured IR refs, other evidence refs, readiness input, blocker status, and accepted exception refs.
-The Visual Fidelity Evidence Matrix records visual planning readiness, traceability refs, provider blocker status, accepted exception refs, Gate Status, and Blocking Items; it must not define visual validation work, screenshot comparison, visual diff, baseline capture, or final visual review.
-Use one Visual Fidelity Evidence Matrix as the single visual readiness record; do not duplicate visual readiness decisions outside the matrix and Blocking Items.
-Read visual facts from `spec.md` and cited evidence refs; do not call provider tools, re-extract external intake evidence, parse HTML SSOT bundles, re-parse structured IR artifacts, rebuild provider matrices, or create another visual readiness path.
-Do not add historical visual rules or alternate visual decision paths.
-Unknown visual/UI coverage status must appear in Blocking Items and block PASS when it affects downstream behavior projection or design. Required visual/UI requirements without observable requirement text block PASS. `[BLOCKED: PROVIDER_EVIDENCE]` items remain provider evidence blockers and return to the external intake extension.
-Responsive visual requirements block PASS only when required source-backed state or viewport evidence is missing for a feature that depends on provider evidence.
-Screenshots support visual facts but do not create product semantics.
-
-Check Non-Functional Requirement Readiness from `spec.md`: applicable performance, security and privacy, reliability and recovery, accessibility, compliance and auditability, observability, compatibility, data lifecycle, and cost or operational constraints are explicitly declared in `spec.md` as `Required`, `Not Applicable`, or `Unknown`.
-
-For each NFR dimension, require either verifiable product-level criteria, a `Not Applicable` rationale, or an `Unknown` marker that identifies what must be clarified. Do not require technical designs such as SLAs, RTO/RPO formulas, cache layers, queues, deployment topology, or infrastructure choices unless the product requirement already states them.
-
-Treat these NFR readiness gaps as blocking items: Required but missing from `spec.md`; Required but not verifiable from product-level criteria; Unknown and affects downstream design. Do not block planning for NFR dimensions marked `Not Applicable` with a rationale or for dimensions with explicit no-special-requirement statements.
-
-Set `Gate Status: PASS` only when every applicable readiness item is checked and `Blocking Items: none`. Otherwise set `Gate Status: BLOCKED` and list each unchecked readiness item that prevents behavior projection or downstream planning.
-
-Unchecked readiness items that prevent behavior projection or downstream planning are blocking items. Do not proceed to `/speckit.plan`. Requirement ambiguity returns to `/speckit.clarify` or `/speckit.specify` to resolve missing requirements before planning. Provider evidence readiness blockers return to the external intake extension, not `/speckit.clarify`.
+Unchecked readiness items that prevent downstream planning return to `/speckit.clarify` or `/speckit.specify`. Do not repair requirements inside the checklist command and do not proceed to `/speckit.plan`.
 
 {CORE_TEMPLATE}
 
 ## Behavior Checklist Reporting
 
-Before finishing, report the BDD, NFR, and Visual Fidelity readiness status and call out unchecked items that block planning.
+Before finishing, report the full checklist path, item count, update mode, focus areas, depth level, actor/timing, must-have items, BDD/NFR/UI/UX readiness status, Gate Status, and Blocking Items.

presets/workflow-preset/commands/speckit.clarify.md

@@ -7,9 +7,9 @@ strategy: wrap
 
 This wrapper must not redefine core-owned User Input, Pre-Execution Checks, extension hooks, base path resolution, or core file handling.
 
-Use `spec.md` as the clarification source. Ask and record clarification only for requirement ambiguity that affects product behavior, constraints, non-functional requirement assumptions, visual/UI requirement coverage status, acceptance criteria, user roles, permissions, entity states, data semantics, exceptions, validation rules, or boundaries.
+Use `spec.md` as the clarification source. Ask and record clarification only for requirement ambiguity that affects product behavior, constraints, non-functional requirement assumptions, UI/UX applicability, acceptance criteria, user roles, permissions, entity states, data semantics, exceptions, validation rules, or boundaries.
 
-Do not read or update behavior draft artifacts. Do not use behavior drafts as clarification inputs, and do not open a separate behavior-question channel. Product requirements stay in `spec.md`; update `spec.md` only after user-provided answers make the requirement clear.
+Do not read or update behavior draft artifacts. Product requirements stay in `spec.md`; update `spec.md` only after user-provided answers make the requirement clear.
 
 ## Wrapper Input Additions
 
@@ -21,35 +21,35 @@ Load the active `spec.md` through the core command. Official hooks still apply:
 
 ## Wrapper Outline Additions
 
-## Design Requirement Clarification Strategy
+### UI/UX Requirement Clarification Strategy
 
-When `spec.md` was created from external intake evidence or visual SSOT refs, prioritize clarification questions for evidence-derived gaps already written in `spec.md`. Scan `spec.md` first for `[NEEDS CLARIFICATION]`, visual/UI coverage status `Unknown`, and gaps about provider-unprovided states, responsive behavior, business rules, permissions, and error handling.
+Scan `spec.md` first for `[NEEDS CLARIFICATION]`, UI/UX Applicability `Unknown`, and incomplete `UI-###` or `UX-###` requirements.
 
-Do not call provider tools. Do not re-extract design facts, re-parse provider design links, parse HTML SSOT bundles, re-parse structured IR artifacts, or turn clarification into an intake step. External intake owns source capture and provider readiness; `/speckit.specify` only projects confirmed evidence-backed requirements and trace refs into `spec.md`. `/speckit.clarify` only selects high-impact questions from existing `spec.md` product-decision gaps and records confirmed answers. Do not ask the user to fix provider extraction artifacts.
+Ask at most 5 high-impact questions whose answers materially affect requirements, implementation planning, or validation readiness. Present exactly one question at a time and do not reveal future queued questions.
 
-Ask at most 5 high-impact questions whose answers materially affect requirements, implementation planning, or validation readiness. Maximum of 5 total questions. Present EXACTLY ONE question at a time. Do NOT output them all at once. Never reveal future queued questions.
+Format recommendations as `**Recommended:** Option [X] - <brief rationale>` when a discrete 2-5 option choice is available. For short-answer gaps, use `Suggested` and constrain answers to `<=5 words`. Accept `yes`, `recommended`, or `suggested` as approval of the shown recommendation.
 
-Format recommendations as `**Recommended:** Option [X] - <brief rationale>` when a discrete 2-5 option choice is available. Keep the rationale short and decision-focused. For short-answer gaps, use `Suggested` and constrain answers to `<=5 words`. Accept `yes`, `recommended`, or `suggested` as approval of the shown recommendation. Question selection order:
+Prioritize questions in this order:
 
-1. Visual/UI coverage status: Required, Not Applicable, Unknown, or `[BLOCKED: PROVIDER_EVIDENCE]`.
-2. Required frames, states, and breakpoints for acceptance.
-3. visual fidelity scope: pixel-perfect, design-system faithful, or functional equivalent.
-4. missing UI states such as loading, empty, error, disabled, hover, and focus.
-5. responsive behavior, scrolling, safe areas, and long-copy handling.
-6. required component reuse constraints explicitly stated in `spec.md`.
-7. data semantics for mock copy, API-backed copy, and interface-driven values.
-8. Prototype-uncovered navigation, dialogs, recovery paths, and failure handling.
-9. product-side acceptance evidence and accepted exception approval flow.
+1. UI/UX applicability: Required, Not Applicable, or Unknown.
+2. Target users, experience goals, and critical journeys.
+3. Information architecture, navigation, and recovery paths.
+4. Required default, loading, empty, error, disabled, success, hover, and focus states.
+5. Interaction feedback, validation behavior, and error semantics.
+6. Responsive reflow, scrolling, safe areas, viewport support, and long-content handling.
+7. Keyboard, focus, semantics, contrast, announcements, and other accessibility behavior.
+8. Required copy, visual hierarchy, iconography, imagery, and numeric or date formatting.
+9. Objective UI/UX acceptance criteria.
 
-After each accepted answer, write confirmed answers back into `spec.md` in the relevant Requirements, User Scenarios, Acceptance Criteria, Assumptions, Open Questions, or Visual & UI Specification, visual/responsive/state sections. Update affected visual/UI coverage status when the answer resolves an `Unknown` item. Ensure `## Clarifications`, `### Session YYYY-MM-DD`, and one `- Q: ... -> A: ...` bullet exist for the session. Save `spec.md` after each accepted answer. Do not create a separate provider-specific clarification document.
+After each accepted answer, write confirmed answers back into the relevant `spec.md` requirement, scenario, acceptance criterion, assumption, or UI/UX section. Update Applicability when the answer resolves an `Unknown` decision. Ensure `## Clarifications`, `### Session YYYY-MM-DD`, and one `- Q: ... -> A: ...` bullet exist for the session. Save `spec.md` after each accepted answer.
 
-Do not generate visual restoration checklists. Clarification fills requirement gaps in `spec.md`; `/speckit.checklist` remains responsible for checking requirement text quality and readiness.
+Do not generate checklist artifacts. `/speckit.checklist` remains responsible for checking requirement text quality and readiness.
 
 ## Validation after each write
 
-Run validation after EACH write plus final pass. Confirm the accepted answer appears once in `spec.md`, Total asked questions is at most 5, the targeted ambiguity is removed or replaced, no contradictory earlier statement remains, and heading structure is preserved.
+Run validation after each write plus a final pass. Confirm the accepted answer appears once in `spec.md`, no more than 5 questions were asked, the targeted ambiguity is removed or replaced, no contradictory earlier statement remains, and heading structure is preserved.
 
-Do not update checklist artifacts. After each `spec.md` write, report checklist impact as unresolved readiness context for `/speckit.checklist`.
+Do not update checklist artifacts. Report checklist impact as unresolved readiness context for `/speckit.checklist`.
 
 {CORE_TEMPLATE}
 
@@ -61,6 +61,6 @@ Before finishing, report answered questions, `spec.md` sections updated, and any
 
 - [ ] No more than 5 high-impact questions were asked.
 - [ ] Each accepted answer was written back to `spec.md`.
-- [ ] Any answered visual/UI coverage status was updated in `spec.md`.
+- [ ] Any answered UI/UX applicability decision was updated in `spec.md`.
 - [ ] Validation after each write found no duplicate or contradictory clarification.
-- [ ] Completion reported with sections touched and remaining blockers.
+- [ ] Completion reported sections touched and remaining blockers.