@tekyzinc/gsd-t 2.71.10 → 2.71.12

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 All notable changes to GSD-T are documented here. Updated with each release.
 
+## [2.71.12] - 2026-04-08
+
+### Changed (smart router — design-to-code pipeline)
+- **Pipeline Routing** — Smart router now treats design-to-code requests as a multi-step pipeline (clean → decompose → build) instead of picking a single command. When a user says "rebuild from this Figma" or "start from scratch with this design," the router evaluates pipeline entry point based on current state and auto-advances through subsequent steps.
+- **Entry Point Detection** — "start over" / "from scratch" / "clean slate" enters at clean step (removes UI assets, then decompose, then build). Missing design contracts enters at decompose. Existing contracts enters at build.
+- **Inline Cleanup** — Clean step removes UI component files while preserving non-UI files (API, stores, router config, project scaffold). No separate `quick` command needed.
+- **Design Command Slugs** — Added `design-decompose`, `design-build`, `design-audit`, `design-review` to valid router command slugs.
+
+### Why
+User gave the router a single prompt asking to delete old assets and rebuild from a Figma design. The router could only pick one command, so it had to choose between `quick` (cleanup) and `design-decompose` (contracts). The natural workflow is a pipeline that the router should execute end-to-end.
+
+## [2.71.11] - 2026-04-08
+
+### Fixed (design-build — review gates and measurement)
+- **Explicit Blocking Review Gates** — Steps 5 (widgets) and 6 (pages) now include their own inline bash polling loops instead of cross-referencing Step 3. The subagent was treating "Wait for human review (Step 3)" as an informational note and skipping the gate entirely, building all three tiers without ever showing the review UI.
+- **Concrete Widget Measurement** — Step 5 now has full Playwright `page.evaluate()` code for measuring grid columns, gap, children-per-row, padding, and child positioning. Previously was a single vague line ("Playwright measure the assembled widget").
+- **Concrete Page Measurement** — Step 6 now has explicit Playwright code for grid column count verification, section ordering, widget width ratios, spacing, and responsive breakpoints. Grid column mismatch (e.g., 4-across instead of 2-across) is flagged as `severity: "critical"`.
+- **Auto-Rejection for Grid Failures** — Review server now auto-rejects items with `grid-template-columns`, `gridTemplateColumns`, `columns-per-row`, or `children-per-row` measurement failures as critical (same as chart type mismatches).
+
+### Why
+User ran `design-build` and the builder completed all three tiers (elements → widgets → pages) without ever displaying the review panel. The review gate in Steps 5/6 used parenthetical cross-references that the subagent ignored. Additionally, the page rendered 4-across when the contract specified 2-across — the measurement step had no concrete code to catch this.
+
 ## [2.70.15] - 2026-04-06
 
 ### Changed (design pipeline — decompose verification)

package/commands/gsd-t-design-build.md

@@ -175,23 +175,27 @@ If rejected:
 
 Continue building remaining elements. Don't wait for human review — queue them all.
 
-## Step 3: Wait for Human Review
+## Step 3: Wait for Human Review (BLOCKING)
 
-After all elements are built and queued, enter the poll loop:
+**This is a BLOCKING step. Do NOT proceed to Step 4 until the human submits their review. Do NOT skip this step. Do NOT treat this as optional.**
+
+After all elements are built and queued, **STOP** and enter the poll loop:
 
 ```
-Waiting for human review...
+Waiting for human review of elements...
   Review UI: http://localhost:3456/review
   {N} elements queued, awaiting submission
 ```
 
-Poll for the review-complete signal:
+Poll for the review-complete signal — **actually run this bash loop**:
 ```bash
 while [ ! -f .gsd-t/design-review/review-complete.json ]; do
   sleep 5
 done
 ```
 
+**Only after `review-complete.json` appears**, proceed to Step 4.
+
 ## Step 4: Process Feedback
 
 Read `.gsd-t/design-review/review-complete.json` and each feedback file in `.gsd-t/design-review/feedback/`.
@@ -233,29 +237,96 @@ If any elements were re-queued → return to Step 3 (max 3 review cycles total).
 
 ## Step 5: Widget Assembly Phase
 
-After all elements are approved:
+**GATE: Do NOT start this step until ALL elements from Step 2 have been reviewed and approved by the human in the review UI.**
 
 1. Read widget contracts from `.gsd-t/contracts/design/widgets/`
 2. For each widget:
    a. Build the widget — MUST import approved element components, not rebuild them inline
    b. Verify imports: grep the widget file for element imports
-   c. Playwright measure the assembled widget
-   d. Queue for review (same flow as elements)
-3. Wait for human review (Step 3)
-4. Process feedback (Step 4)
+   c. **Render-Measure-Compare** — use Playwright to measure the assembled widget against its contract specs:
+      ```javascript
+      // In Playwright page.evaluate():
+      const widget = document.querySelector(widgetSelector);
+      const s = getComputedStyle(widget);
+      const rect = widget.getBoundingClientRect();
+      // Measure layout properties from widget contract:
+      // - grid-template-columns / grid-template-rows (column count, track sizes)
+      // - gap / row-gap / column-gap
+      // - padding, margin, border-radius
+      // - width, height, aspect-ratio
+      // Count direct children and verify against contract's expected child count
+      const children = widget.children;
+      const childRects = [...children].map(c => c.getBoundingClientRect());
+      // Verify children-per-row: count children whose top is within 2px of first child's top
+      const firstRowTop = childRects[0]?.top;
+      const childrenPerRow = childRects.filter(r => Math.abs(r.top - firstRowTop) < 2).length;
+      // Compare ALL measured values against contract specs
+      // Build measurements array: [{ property, expected, actual, pass }]
+      ```
+      **Every measurement failure MUST appear in the queue JSON measurements array with `pass: false`.**
+   d. Write queue JSON to `.gsd-t/design-review/queue/{widget-id}.json` (same format as elements, with `"type": "widget"`)
+   e. Check for auto-rejections (sleep 3, check `rejected/` dir) — fix and re-queue if rejected (max 2 cycles)
+3. After ALL widgets are built and queued, **STOP and poll for human review** — this is a BLOCKING wait, do NOT proceed until the human submits:
+   ```
+   Waiting for human review of widgets...
+     Review UI: http://localhost:3456/review
+     {N} widgets queued, awaiting submission
+   ```
+   ```bash
+   while [ ! -f .gsd-t/design-review/review-complete.json ]; do
+     sleep 5
+   done
+   ```
+4. Process feedback — read `review-complete.json` and each feedback file, apply changes/fixes per the same rules as Step 4. Clear queue, delete signal, clear feedback after processing. If any widgets re-queued → return to sub-step 3 (max 3 review cycles).
 
 ## Step 6: Page Composition Phase
 
-After all widgets are approved:
+**GATE: Do NOT start this step until ALL widgets from Step 5 have been reviewed and approved by the human in the review UI.**
 
 1. Read page contracts from `.gsd-t/contracts/design/pages/`
 2. For each page:
    a. Build the page — MUST import approved widget components
-   b. Verify grid layout, section ordering, responsive breakpoints
-   c. Playwright measure the full page
-   d. Queue for review
-3. Wait for human review
-4. Process feedback
+   b. **Render-Measure-Compare** — use Playwright to verify the full page layout against its contract specs:
+      ```javascript
+      // In Playwright page.evaluate():
+      // 1. GRID LAYOUT — verify column count matches contract
+      const grid = document.querySelector(pageGridSelector);
+      const gridStyle = getComputedStyle(grid);
+      const columns = gridStyle.gridTemplateColumns.split(' ').length;
+      // Compare against contract's expected column count (e.g., 2, not 4)
+      
+      // 2. SECTION ORDERING — verify widgets appear in contract-specified order
+      const sections = [...grid.querySelectorAll('[data-section]')];
+      const sectionOrder = sections.map(s => s.dataset.section);
+      // Compare against contract's section order array
+      
+      // 3. WIDGET DIMENSIONS — verify each widget's width relative to grid
+      const gridRect = grid.getBoundingClientRect();
+      const widgetRects = sections.map(s => s.getBoundingClientRect());
+      // For a 2-column grid: each widget should be ~50% of grid width (minus gap)
+      // For a 1-column widget spanning full width: should be ~100% of grid width
+      
+      // 4. SPACING — verify gap, padding, margins match contract
+      // gap, rowGap, columnGap, padding
+      
+      // 5. RESPONSIVE — if contract specifies breakpoints, measure at each viewport width
+      // Build measurements array: [{ property, expected, actual, pass }]
+      ```
+      **Grid column count is a CRITICAL measurement. If the contract says 2 columns and the page renders 4, this is `severity: "critical"` and MUST be flagged.**
+   c. Write queue JSON to `.gsd-t/design-review/queue/{page-id}.json` (same format, with `"type": "page"`)
+   e. Check for auto-rejections (sleep 3, check `rejected/` dir) — fix and re-queue if rejected (max 2 cycles)
+3. After ALL pages are built and queued, **STOP and poll for human review** — this is a BLOCKING wait, do NOT proceed until the human submits:
+   ```
+   Waiting for human review of pages...
+     Review UI: http://localhost:3456/review
+     {N} pages queued, awaiting submission
+   ```
+   ```bash
+   while [ ! -f .gsd-t/design-review/review-complete.json ]; do
+     sleep 5
+   done
+   ```
+4. Process feedback — same rules as Step 4. Clear queue, delete signal, clear feedback. If any pages re-queued → return to sub-step 3 (max 3 review cycles).
 
 ## Step 7: Cleanup and Report
 
@@ -307,8 +378,10 @@ Update `.gsd-t/progress.md` with completion status.
 
 - NEVER share builder context with Term 2 — coordination is files only
 - NEVER skip the review cycle — every component goes through Term 2 + human
-- NEVER proceed to widgets before all elements are approved
+- NEVER proceed to widgets before all elements are reviewed and approved by the human — the bash polling loop MUST block until `review-complete.json` appears
+- NEVER proceed to pages before all widgets are reviewed and approved by the human — same blocking poll
 - NEVER rebuild element functionality inline in widgets — always import
+- NEVER skip or shortcut the bash polling loop — it MUST actually execute and block
 - Max 3 review cycles per phase — if still failing, stop and present to user
 - Auto-open the browser review UI so the user doesn't have to find it
 - Kill all background processes on completion or error

package/commands/gsd.md

@@ -59,14 +59,46 @@ When the same request could fit multiple commands at different scales:
 
 ### Design-to-code routing:
 
-When the request involves UI implementation from a design (Figma, screenshots, mockups, "pixel-perfect", "match the design", "rebuild the frontend"):
-- **NEVER route to `quick`** — design-to-code requires the full workflow with design contract, token extraction, and visual verification
+When the request involves UI implementation from a design (Figma URL, screenshots, mockups, "pixel-perfect", "match the design", "rebuild the frontend", "build from this Figma"):
+
+**This is a PIPELINE, not a single command.** The router must evaluate where the user is in the pipeline and execute from that point forward, auto-advancing through subsequent steps.
+
+**Pipeline order:**
+1. **Clean** (if requested) — remove existing UI assets via inline cleanup (not a separate `quick` command)
+2. **Decompose** — `design-decompose` to extract element → widget → page contracts from the Figma design
+3. **Build** — `design-build` to implement from contracts with review gates
+
+**Pipeline entry logic — evaluate these in order, enter at the first that applies:**
+
+| Condition | Entry point | Steps executed |
+|-----------|-------------|----------------|
+| User says "start over", "from scratch", "rebuild", "remove existing", "clean slate" | **Clean → Decompose → Build** | Remove existing UI assets in `src/components/`, `src/views/`, and related style files. Then run `design-decompose` with the Figma URL. Then run `design-build`. |
+| No design contracts exist (`.gsd-t/contracts/design/` missing or empty) | **Decompose → Build** | Run `design-decompose` with the Figma URL. Then run `design-build`. |
+| Design contracts exist but UI not yet built (contracts present, source files missing) | **Build** | Run `design-build` directly. |
+| Design contracts AND source files exist | **Build** | Run `design-build` (will measure existing components against contracts). |
+
+**How to execute the pipeline:**
+
+Route to the entry point command. At the end of that command, **auto-advance to the next pipeline step** — do not stop and ask the user. Display:
+```
+→ Design pipeline: {step 1} ✓ → {step 2} (starting) → {step 3} (pending)
+```
+
+**Clean step** (inline, not a separate command):
+When cleanup is needed, do it at the start of `design-decompose` before reading the Figma:
+- Remove UI component files (`src/components/`, `src/views/`, or equivalent)
+- Remove associated style files and test files for those components
+- Keep non-UI files (API services, stores, types, utilities, router config)
+- Keep the project scaffold (App.vue/tsx, main.ts, index.html)
+- `git add -A && git commit -m "chore: clean UI assets for design rebuild"`
+
+**NEVER route design-to-code requests to `quick`** — design-to-code requires the full pipeline with contracts, measurement, and review gates.
+
+**Fallback for non-pipeline design routing** (when the request is about an existing milestone/wave, not a fresh design build):
 - **If no active milestone exists** → route to `wave` (creates milestone → partition with design contract → plan → execute with visual verification)
 - **If a milestone exists but no domains** → route to `partition` (creates design contract in Step 3.6)
 - **If domains exist but no tasks** → route to `plan`
 - **If tasks exist** → route to `execute` (design-to-code stack rule will inject)
-- The design-to-code stack rule activates automatically when `.gsd-t/contracts/design-contract.md` OR `.gsd-t/contracts/design/` exists, or Figma MCP is configured — but the **partition step must run first** to create the design contract
-- **For projects with multiple pages or reusable components** (charts, widgets, design system): route to `design-decompose` BEFORE partition to create the hierarchical contract tree (elements → widgets → pages). Single-page/one-off designs can use flat `design-contract.md` created during partition instead.
 
 ## Step 3: Confirm and Execute
 
@@ -77,6 +109,13 @@ When the request involves UI implementation from a design (Figma, screenshots, m
 → Routing to /user:gsd-t-{command}: {brief reason}
 ```
 
+### Design pipeline (from design-to-code routing):
+```
+→ Design pipeline: clean → decompose → build
+  Starting: /user:gsd-t-design-decompose
+```
+Use this format when the router detects a design-to-code pipeline. Show the full pipeline with the current step highlighted. Auto-advance between steps without returning to the router.
+
 ### Continuation (from Step 2a):
 ```
 → /gsd ──▶ continue /user:gsd-t-{last-command}
@@ -102,7 +141,7 @@ Where `{last-command}` is:
 
 **CRITICAL: `{command}` and `{last-command}` MUST be a real GSD-T command slug — never a free-form description.**
 
-Valid command slugs: `quick`, `debug`, `feature`, `execute`, `milestone`, `project`, `scan`, `gap-analysis`, `plan`, `partition`, `discuss`, `impact`, `integrate`, `verify`, `test-sync`, `complete-milestone`, `wave`, `status`, `populate`, `setup`, `init`, `health`, `log`, `pause`, `resume`, `prd`, `brainstorm`, `prompt`, `backlog-add`, `backlog-list`, `backlog-promote`, `promote-debt`, `triage-and-merge`, `version-update`, `version-update-all`
+Valid command slugs: `quick`, `debug`, `feature`, `execute`, `milestone`, `project`, `scan`, `gap-analysis`, `plan`, `partition`, `discuss`, `impact`, `integrate`, `verify`, `test-sync`, `complete-milestone`, `wave`, `status`, `populate`, `setup`, `init`, `health`, `log`, `pause`, `resume`, `prd`, `brainstorm`, `prompt`, `backlog-add`, `backlog-list`, `backlog-promote`, `promote-debt`, `triage-and-merge`, `version-update`, `version-update-all`, `design-decompose`, `design-build`, `design-audit`, `design-review`
 
 **WRONG ❌** — do not do this:
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.71.10",
+  "version": "2.71.12",
   "description": "GSD-T: Contract-Driven Development for Claude Code — 56 slash commands with headless CI/CD mode, graph-powered code analysis, real-time agent dashboard, execution intelligence, task telemetry, doc-ripple enforcement, backlog management, impact analysis, test sync, milestone archival, and PRD generation",
   "author": "Tekyz, Inc.",
   "license": "MIT",

package/scripts/gsd-t-design-review-server.js

@@ -79,7 +79,11 @@ function autoRejectFailures() {
           m.severity === "critical" ||
           m.property === "chart type" ||
           m.property === "display" ||
-          m.property === "flexDirection"
+          m.property === "flexDirection" ||
+          m.property === "grid-template-columns" ||
+          m.property === "gridTemplateColumns" ||
+          m.property === "columns-per-row" ||
+          m.property === "children-per-row"
         );
         if (criticalFailures.length > 0) {
           // Auto-reject: write feedback and remove from queue