Update workflow-preset to v1.3.7

presets/catalog.json

@@ -29,7 +29,7 @@
     "workflow-preset": {
       "name": "Workflow Preset",
       "id": "workflow-preset",
-      "version": "1.3.6",
+      "version": "1.3.7",
       "description": "Behavior-first specification, design artifacts, and agent-native handoff orchestration",
       "author": "bigsmartben",
       "repository": "https://github.com/bigsmartben/spec-kit-workflow-preset",
@@ -40,7 +40,7 @@
       },
       "provides": {
         "commands": 8,
-        "templates": 24
+        "templates": 26
       },
       "tags": [
         "behavior",

presets/workflow-preset/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## Unreleased
 
+## 1.3.7
+
+- Generalized Figma-derived requirement handling into provider-neutral Design Requirement Intake and Requirement Merge templates while keeping Figma MCP execution outside the preset.
+- Added a row-per-case Case Coverage Matrix to make positive, negative, boundary, permission, validation, and state_conflict applicability explicit before planning.
+- Hardened failure behavior scenarios so permission, validation, state_conflict, and other error paths require structured request cases, error responses, failure feedback, and assertions before tasks are generated.
+- Hardened UI task generation so UI implementation and acceptance tasks are paired with explicit state coverage, viewport coverage, visual proof refs, screenshot refs, and readiness blockers for missing visual or asset evidence.
+
 ## 1.3.6
 
 - Added a Figma Evidence Packet input template and Figma intake contract for Figma-derived specifications without adding Figma MCP execution to the preset.

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

@@ -11,6 +11,17 @@ Check that tasks preserve the planned `M + U` scope. Report missing, widened, or
 
 Analyze whether the feature artifacts close the `spec -> BDD/UIF intent -> contracts -> tasks` loop. This command checks planning consistency only; it does not inspect implementation code or infer interaction flows from built code.
 
+## Analysis Performance Guardrails
+
+Keep analysis bounded to the existing planning artifacts.
+
+- Build a one-pass artifact inventory before deep reading. Record which expected files and directories exist, then short-circuit missing artifact branches as source artifact -> target artifact blockers.
+- Use stable IDs as the primary consistency surface: `CASE-`, `SCN-`, `UIF-`, `FIX-`, `AST-`, and `BLK-`. Compare ID sets and declared method/path references before prose-level interpretation.
+- Read `tasks.md` and `quickstart.md` once for ID, contract path, API method/path, and validation path evidence. Do not repeatedly scan them per scenario when a single evidence map can answer coverage.
+- Read surrounding prose only when a required ID, source section, or blocker explanation is missing or ambiguous.
+- Stop expanding a branch after the first blocker that proves the downstream link cannot be closed. Report the blocker with the source artifact and target artifact instead of continuing speculative checks.
+- Do not create new analysis artifacts, workflow runners, or external-tool requirements.
+
 Check:
 
 - spec.md user stories have BDD coverage.
@@ -22,11 +33,16 @@ Check:
 - UIF API calls exist in contracts/api/.
 - behavior contracts cover scenarios, fixtures, and assertions.
 - tasks.md covers BDD, UIF, API, fixtures, and quickstart validation paths.
+- case coverage is closed from checklist through implementation tasks.
+- Required case types in `checklists/behavior-testability.md` map to behavior draft scenarios, formal behavior contracts, tasks, and quickstart validation paths.
+- positive, negative, boundary, permission, validation, and state_conflict case types are either covered or have `N/A or blocker` evidence.
+- failure scenarios declare error code, failure feedback, and state invariant, rollback, or compensation assertion.
+- quickstart validation paths cover Required failure scenarios.
 
 Report missing, inconsistent, or stale links by source artifact and target artifact. Keep findings actionable and separate blockers from warnings.
 
 {CORE_TEMPLATE}
 
 ## Behavior Analysis Reporting
 
-Before finishing, report whether the vertical consistency chain is closed and list blockers that should be resolved before implementation continues.
+Before finishing, report whether the vertical consistency chain is closed and list blockers that prevent implementation from continuing.

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

@@ -1,8 +1,20 @@
 ---
-description: Wrap core checklist generation with BDD readiness gate.
+description: Wrap core checklist generation with BDD, NFR, and Visual Fidelity readiness gate.
 strategy: wrap
 ---
 
+## Checklist Purpose: "Unit Tests for English"
+
+This wrapper must not redefine core-owned User Input, Pre-Execution Checks, extension hooks, base path resolution, or core file handling.
+
+Checklists validate whether requirements are complete, clear, consistent, measurable, and ready for downstream planning. NOT for verification/testing: do not test implementation behavior, code execution, UI rendering, API responses, or whether the built system works.
+
+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.
+
+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.
+
 ## BDD Readiness Gate
 
 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.
@@ -12,28 +24,34 @@ Include these sections:
 - 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
 
-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.
+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.
+
+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.
 
 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 can become feedback, business state, error semantics, or assertion intent.
+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 Figma-derived requirements.
-Require source traceability, ready gate evidence, and clear visual requirements for
-state, responsive, accessibility, component mapping, and accepted exception
-coverage. Missing raw metadata completeness, metadata index completeness proof,
-node inventory parity, or blocker lint errors are blocking items for
-Figma-derived requirements.
+Check Visual Fidelity Readiness when `spec.md` contains design-derived requirements, a design source, provider evidence blockers, or provider-specific design 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.
+Require source traceability, provider readiness status, evidence refs, and blockers, 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 or visual proof obligation. Record Screenshot evidence level, declared visual proof required, provider evidence refs or screenshot refs, and any Gate Status: BLOCKED item in Blocking Items.
+Use one Visual Fidelity Evidence Matrix as the single visual readiness record; do not duplicate visual evidence decisions outside the matrix and Blocking Items.
+Do not add historical visual rules or alternate visual decision paths.
+Responsive visual requirements block PASS only when they are complex, multi-state, or declare L2 or L3 visual proof; missing viewport-specific evidence then sets Gate Status: BLOCKED and lists the item in Blocking Items.
+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`.
 
@@ -43,10 +61,10 @@ Treat these NFR readiness gaps as blocking items: Required but missing from `spe
 
 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`; Return to `/speckit.clarify` or `/speckit.specify` to resolve missing requirements before 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 `/speckit.specify` or provider intake, not `/speckit.clarify`.
 
 {CORE_TEMPLATE}
 
 ## Behavior Checklist Reporting
 
-Before finishing, report the BDD readiness status and call out unchecked items that block planning.
+Before finishing, report the BDD, NFR, and Visual Fidelity readiness status and call out unchecked items that block planning.

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

@@ -5,17 +5,31 @@ strategy: wrap
 
 ## Spec-Only Clarification Policy
 
+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, 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.
 
-## Figma-Derived Clarification Strategy
+## User Input
+
+Treat `$ARGUMENTS` as prioritization context for the current clarification run. Do not ask the user to restate requirements already present in `spec.md`.
+
+## Pre-Execution Checks
+
+Load the active `spec.md` through the core command. Official hooks still apply: `hooks.before_clarify` runs before Outline, `hooks.after_clarify` runs before Completion Report, and mandatory hooks emit `EXECUTE_COMMAND`. If `spec.md` is missing, follow the core command error path and do not create a new spec here.
+
+## Outline
+
+## Design Requirement Clarification Strategy
 
-When `spec.md` was created from a Figma Evidence Packet, prioritize clarification questions for Figma-derived gaps already written in `spec.md`. Scan `spec.md` first for `Missing / Needs clarification`, `[NEEDS CLARIFICATION]`, `Inferred from structure`, and gaps about Figma-unprovided states, responsive behavior, business rules, permissions, and error handling.
+When `spec.md` was created from Design Requirement Intake or provider-specific evidence such as a Figma Evidence Packet, prioritize clarification questions for design-derived gaps already written in `spec.md`. Scan `spec.md` first for `Missing / Needs Clarification`, `[NEEDS CLARIFICATION]`, `Inferred from Structure`, and gaps about provider-unprovided states, responsive behavior, business rules, permissions, and error handling.
 
-Do not call Figma MCP. Do not re-extract design facts, re-parse Figma links, or turn clarification into a Figma extraction step. `/speckit.specify` owns writing Figma evidence into `spec.md`; `/speckit.clarify` only selects high-impact questions from existing `spec.md` gaps and records confirmed answers.
+Do not call Figma MCP. Do not re-extract design facts, re-parse Figma links, or turn clarification into a Figma extraction step. `/speckit.specify` owns writing qualified evidence-backed design-derived requirements and trace refs into `spec.md`; it does not write raw Figma evidence into `spec.md`. `/speckit.clarify` only selects high-impact questions from existing `spec.md` 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. Prefer questions in this order:
+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] - <reasoning>` 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. Question selection order:
 
 1. Required frames, states, and breakpoints for acceptance.
 2. visual fidelity scope: pixel-perfect, design-system faithful, or functional equivalent.
@@ -26,12 +40,25 @@ Ask at most 5 high-impact questions whose answers materially affect requirements
 7. Prototype-uncovered navigation, dialogs, recovery paths, and failure handling.
 8. acceptance evidence, visual-difference tolerance, and exception approval flow.
 
-After the user answers, write confirmed answers back into `spec.md` in the relevant Requirements, User Scenarios, Acceptance Criteria, Assumptions, Open Questions, or visual/responsive/state sections. Do not create a separate Figma clarification document.
+After each accepted answer, write confirmed answers back into `spec.md` in the relevant Requirements, User Scenarios, Acceptance Criteria, Assumptions, Open Questions, or visual/responsive/state sections. 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 Figma clarification document.
 
 Do not generate visual restoration checklists. Clarification fills requirement gaps in `spec.md`; `/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.
+
+Do not update checklist artifacts. After each `spec.md` write, report checklist impact as unresolved readiness context for `/speckit.checklist`.
+
 {CORE_TEMPLATE}
 
-## Clarification Reporting
+## Completion Report
 
 Before finishing, report answered questions, `spec.md` sections updated, and any unresolved requirement ambiguity that still blocks checklist readiness.
+
+## Done When
+
+- [ ] No more than 5 high-impact questions were asked.
+- [ ] Each accepted answer was written back to `spec.md`.
+- [ ] Validation after each write found no duplicate or contradictory clarification.
+- [ ] Completion reported with sections touched and remaining blockers.