@tekyzinc/gsd-t 2.70.16 → 2.71.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -30,7 +30,7 @@ A methodology for reliable, parallelizable development using Claude Code with op
30
30
  npx @tekyzinc/gsd-t install
31
31
  ```
32
32
 
33
- This installs 48 GSD-T commands + 5 utility commands (53 total) to `~/.claude/commands/` and the global CLAUDE.md to `~/.claude/CLAUDE.md`. Works on Windows, Mac, and Linux.
33
+ This installs 51 GSD-T commands + 5 utility commands (56 total) to `~/.claude/commands/` and the global CLAUDE.md to `~/.claude/CLAUDE.md`. Works on Windows, Mac, and Linux.
34
34
 
35
35
  ### Start Using It
36
36
 
@@ -189,6 +189,8 @@ This will replace changed command files, back up your CLAUDE.md if customized, a
189
189
  | `/user:gsd-t-triage-and-merge` | Auto-review, merge, and publish GitHub branches | Manual |
190
190
  | `/user:gsd-t-audit` | Harness self-audit — analyze cost/benefit of enforcement components | Manual |
191
191
  | `/user:gsd-t-design-audit` | Compare built screen against Figma design — structured deviation report | Manual |
192
+ | `/user:gsd-t-design-build` | Build from design contracts with two-terminal review (Term 1 builder) | Manual |
193
+ | `/user:gsd-t-design-review` | Independent review agent for design build (Term 2 reviewer) | Auto |
192
194
 
193
195
  ### Backlog Management
194
196
 
@@ -340,8 +342,8 @@ get-stuff-done-teams/
340
342
  ├── LICENSE
341
343
  ├── bin/
342
344
  │ └── gsd-t.js # CLI installer
343
- ├── commands/ # 53 slash commands
344
- │ ├── gsd-t-*.md # 45 GSD-T workflow commands
345
+ ├── commands/ # 56 slash commands
346
+ │ ├── gsd-t-*.md # 50 GSD-T workflow commands
345
347
  │ ├── gsd.md # GSD-T smart router
346
348
  │ ├── branch.md # Git branch helper
347
349
  │ ├── checkin.md # Auto-version + commit/push helper
@@ -0,0 +1,314 @@
1
+ # GSD-T: Design Build — Build from Design Contracts with Two-Terminal Review
2
+
3
+ You are the design builder (Term 1). You build UI components from design contracts, measure them against specs, and coordinate with an independent review session (Term 2) for unbiased verification.
4
+
5
+ **Architecture**: Term 1 builds → file system → Term 2 reviews → file system → Term 1 reads feedback. Zero shared context between sessions.
6
+
7
+ ## Step 0: Validate Prerequisites
8
+
9
+ 1. Read `.gsd-t/contracts/design/INDEX.md` — if missing, STOP: "Run `/user:gsd-t-design-decompose` first to create design contracts."
10
+ 2. Read `.gsd-t/progress.md` for current state
11
+ 3. Verify `scripts/gsd-t-design-review-server.js` exists (GSD-T package)
12
+ - Get the GSD-T install path: `npm root -g` → `{global_root}/@tekyzinc/gsd-t/scripts/`
13
+ - If not found: "Update GSD-T: `/user:gsd-t-version-update`"
14
+
15
+ ## Step 1: Start Infrastructure
16
+
17
+ ### 1a. Dev Server
18
+
19
+ Check if a dev server is running:
20
+ ```bash
21
+ lsof -i :5173 2>/dev/null | head -2
22
+ ```
23
+
24
+ If not running, detect and start:
25
+ ```bash
26
+ # Check package.json for dev command
27
+ npm run dev &
28
+ # Wait for server to be ready
29
+ for i in $(seq 1 30); do curl -s http://localhost:5173 > /dev/null 2>&1 && break; sleep 1; done
30
+ ```
31
+
32
+ Record the dev server port as `$DEV_PORT`.
33
+
34
+ ### 1b. Review Server
35
+
36
+ Find the review server script:
37
+ ```bash
38
+ GSD_ROOT=$(npm root -g)/@tekyzinc/gsd-t/scripts
39
+ ```
40
+
41
+ Start the review server as a background process:
42
+ ```bash
43
+ node $GSD_ROOT/gsd-t-design-review-server.js \
44
+ --target http://localhost:$DEV_PORT \
45
+ --project $PWD \
46
+ --port 3456 &
47
+ REVIEW_PID=$!
48
+ ```
49
+
50
+ Verify it's running:
51
+ ```bash
52
+ curl -s http://localhost:3456/review/api/status
53
+ ```
54
+
55
+ ### 1c. Launch Term 2 (Independent Review Session)
56
+
57
+ Write the review prompt to disk (Term 2 reads this, not Term 1's context):
58
+ ```bash
59
+ cat > .gsd-t/design-review/review-prompt.md << 'PROMPT'
60
+ You are the design review agent (Term 2). You are an INDEPENDENT reviewer — you have NO knowledge of how components were built. Your job is to compare built output against design contracts.
61
+
62
+ ## Your Loop
63
+
64
+ 1. Poll `.gsd-t/design-review/queue/` every 5 seconds for new JSON files
65
+ 2. For each queue item:
66
+ a. Read the queue JSON — it has component name, selector, measurements, source path
67
+ b. Read the matching design contract from `.gsd-t/contracts/design/`
68
+ c. Open the app at http://localhost:3456/ (proxied through review server)
69
+ d. Use Playwright to navigate to the component and evaluate it against the contract
70
+ e. AI Review — check what measurements can't catch:
71
+ - Does the visual hierarchy feel right?
72
+ - Are proportions correct even if individual measurements pass?
73
+ - Does the component look like the contract describes, holistically?
74
+ f. If CRITICAL issues found (wrong chart type, missing elements, wrong data model):
75
+ - Write rejection to `.gsd-t/design-review/rejected/{id}.json`:
76
+ `{ "id": "...", "reason": "...", "severity": "critical", "timestamp": "..." }`
77
+ - The review server will notify Term 1 automatically
78
+ g. If no critical issues → the component passes to human review (review UI handles this)
79
+ 3. When `.gsd-t/design-review/shutdown.json` appears → exit cleanly
80
+
81
+ ## Rules
82
+ - You write ZERO code. You ONLY review.
83
+ - You have NO context about how anything was built — judge purely by contract vs. output.
84
+ - Be harsh. Your value is in catching what the builder missed.
85
+ - Check `.gsd-t/contracts/design/elements/`, `widgets/`, and `pages/` for specs.
86
+ PROMPT
87
+ ```
88
+
89
+ Launch a new terminal with an independent Claude session:
90
+ ```bash
91
+ # macOS
92
+ osascript -e "tell application \"Terminal\" to do script \"cd $(pwd) && claude --print 'Read .gsd-t/design-review/review-prompt.md and execute the instructions. This is your only directive.'\""
93
+ ```
94
+
95
+ ```bash
96
+ # Linux (fallback)
97
+ gnome-terminal -- bash -c "cd $(pwd) && claude --print 'Read .gsd-t/design-review/review-prompt.md and execute the instructions. This is your only directive.'; exec bash"
98
+ ```
99
+
100
+ Display to user:
101
+ ```
102
+ Design Build — Infrastructure Ready
103
+ ✓ Dev server: http://localhost:$DEV_PORT
104
+ ✓ Review server: http://localhost:3456
105
+ ✓ Review UI: http://localhost:3456/review
106
+ ✓ Term 2: Independent review session launched
107
+ ```
108
+
109
+ Auto-open the review UI:
110
+ ```bash
111
+ open http://localhost:3456/review 2>/dev/null || xdg-open http://localhost:3456/review 2>/dev/null
112
+ ```
113
+
114
+ ## Step 2: Build Phase — Elements
115
+
116
+ Read all element contracts from `.gsd-t/contracts/design/elements/`. Sort by any `order` field or alphabetically.
117
+
118
+ For each element contract:
119
+
120
+ ### 2a. Build the Element
121
+
122
+ Read the element contract. Build or update the component at the specified source path. Follow the contract exactly:
123
+ - Chart type, dimensions, colors, spacing, typography
124
+ - Props interface matching the contract's data model
125
+ - Import patterns (use existing design system components where specified)
126
+
127
+ ### 2b. Render-Measure-Compare
128
+
129
+ After building, use Playwright to measure the rendered component against the contract specs:
130
+
131
+ ```javascript
132
+ // In Playwright page.evaluate():
133
+ const el = document.querySelector(selector);
134
+ const s = getComputedStyle(el);
135
+ const rect = el.getBoundingClientRect();
136
+ // Measure each spec property from the contract
137
+ // Compare against expected values
138
+ // Build measurements array: [{ property, expected, actual, pass }]
139
+ ```
140
+
141
+ ### 2c. Queue for Review
142
+
143
+ Write the queue JSON to `.gsd-t/design-review/queue/{element-id}.json`:
144
+ ```json
145
+ {
146
+ "id": "element-donut-chart",
147
+ "name": "DonutChart",
148
+ "type": "element",
149
+ "order": 1,
150
+ "selector": "svg[viewBox='0 0 200 200']",
151
+ "sourcePath": "src/components/elements/DonutChart.vue",
152
+ "route": "/",
153
+ "measurements": [
154
+ { "property": "chart type", "expected": "donut", "actual": "donut", "pass": true },
155
+ ...
156
+ ]
157
+ }
158
+ ```
159
+
160
+ ### 2d. Check for Auto-Rejections
161
+
162
+ After queuing, check for immediate rejection from Term 2:
163
+ ```bash
164
+ # Brief wait for Term 2 to process
165
+ sleep 3
166
+ ls .gsd-t/design-review/rejected/{element-id}.json 2>/dev/null
167
+ ```
168
+
169
+ If rejected:
170
+ - Read the rejection reason
171
+ - Fix the element based on the rejection feedback
172
+ - Re-measure and re-queue (max 2 auto-rejection cycles per element)
173
+
174
+ ### 2e. Continue Building
175
+
176
+ Continue building remaining elements. Don't wait for human review — queue them all.
177
+
178
+ ## Step 3: Wait for Human Review
179
+
180
+ After all elements are built and queued, enter the poll loop:
181
+
182
+ ```
183
+ Waiting for human review...
184
+ Review UI: http://localhost:3456/review
185
+ {N} elements queued, awaiting submission
186
+ ```
187
+
188
+ Poll for the review-complete signal:
189
+ ```bash
190
+ while [ ! -f .gsd-t/design-review/review-complete.json ]; do
191
+ sleep 5
192
+ done
193
+ ```
194
+
195
+ ## Step 4: Process Feedback
196
+
197
+ Read `.gsd-t/design-review/review-complete.json` and each feedback file in `.gsd-t/design-review/feedback/`.
198
+
199
+ For each element's feedback:
200
+
201
+ ### No changes, no comment → Approved
202
+ - Mark element as complete
203
+ - No action needed
204
+
205
+ ### Property changes only → Apply and verify
206
+ - Read the change list: `[{ property, oldValue, newValue, path }]`
207
+ - Map CSS property changes back to source code:
208
+ - Tailwind: `padding: 16px` → find and update the Tailwind class (e.g., `p-6` → `p-4`)
209
+ - Inline styles: update the style binding directly
210
+ - CSS modules: update the CSS rule
211
+ - Re-run Playwright measurement to verify the change took effect
212
+ - If verification passes → mark complete
213
+ - If verification fails → re-queue for review with updated measurements
214
+
215
+ ### Comment only → Interpret and fix
216
+ - Read the comment — it describes a change to make
217
+ - Implement the change described in the comment
218
+ - Re-measure the element
219
+ - Re-queue for review
220
+
221
+ ### Changes + comment → Apply changes, use comment as context
222
+ - Apply the property changes first
223
+ - Read the comment for additional context or fixes beyond the property changes
224
+ - Implement any additional changes
225
+ - Re-measure and re-queue
226
+
227
+ After processing all feedback:
228
+ - Clear the queue: `rm .gsd-t/design-review/queue/*.json`
229
+ - Delete the signal: `rm .gsd-t/design-review/review-complete.json`
230
+ - Clear feedback: `rm .gsd-t/design-review/feedback/*.json`
231
+
232
+ If any elements were re-queued → return to Step 3 (max 3 review cycles total).
233
+
234
+ ## Step 5: Widget Assembly Phase
235
+
236
+ After all elements are approved:
237
+
238
+ 1. Read widget contracts from `.gsd-t/contracts/design/widgets/`
239
+ 2. For each widget:
240
+ a. Build the widget — MUST import approved element components, not rebuild them inline
241
+ b. Verify imports: grep the widget file for element imports
242
+ c. Playwright measure the assembled widget
243
+ d. Queue for review (same flow as elements)
244
+ 3. Wait for human review (Step 3)
245
+ 4. Process feedback (Step 4)
246
+
247
+ ## Step 6: Page Composition Phase
248
+
249
+ After all widgets are approved:
250
+
251
+ 1. Read page contracts from `.gsd-t/contracts/design/pages/`
252
+ 2. For each page:
253
+ a. Build the page — MUST import approved widget components
254
+ b. Verify grid layout, section ordering, responsive breakpoints
255
+ c. Playwright measure the full page
256
+ d. Queue for review
257
+ 3. Wait for human review
258
+ 4. Process feedback
259
+
260
+ ## Step 7: Cleanup and Report
261
+
262
+ ```bash
263
+ # Signal Term 2 to shut down
264
+ echo '{"shutdown": true}' > .gsd-t/design-review/shutdown.json
265
+ sleep 2
266
+
267
+ # Kill review server
268
+ kill $REVIEW_PID 2>/dev/null
269
+
270
+ # Kill dev server if we started it
271
+ # (only if we started it in Step 1a)
272
+ ```
273
+
274
+ Report:
275
+ ```
276
+ Design Build Complete
277
+ Elements: {N} built, {N} approved
278
+ Widgets: {N} built, {N} approved
279
+ Pages: {N} built, {N} approved
280
+ Review cycles: {N}
281
+
282
+ Changes applied from review: {N}
283
+ Comments addressed: {N}
284
+ ```
285
+
286
+ Update `.gsd-t/progress.md` with completion status.
287
+
288
+ ## Coordination Directory Structure
289
+
290
+ ```
291
+ .gsd-t/design-review/
292
+ ├── queue/ # Term 1 writes, Term 2 + human reads
293
+ │ ├── element-donut.json
294
+ │ └── element-bar.json
295
+ ├── feedback/ # Human review writes, Term 1 reads
296
+ │ ├── element-donut.json
297
+ │ └── element-bar.json
298
+ ├── rejected/ # Term 2 auto-rejects, Term 1 reads
299
+ │ └── element-bar.json
300
+ ├── review-complete.json # Human submit signal → Term 1 polls
301
+ ├── review-prompt.md # Term 2's instructions (no builder context)
302
+ ├── shutdown.json # Term 1 signals Term 2 to exit
303
+ └── status.json # Review server state
304
+ ```
305
+
306
+ ## Rules
307
+
308
+ - NEVER share builder context with Term 2 — coordination is files only
309
+ - NEVER skip the review cycle — every component goes through Term 2 + human
310
+ - NEVER proceed to widgets before all elements are approved
311
+ - NEVER rebuild element functionality inline in widgets — always import
312
+ - Max 3 review cycles per phase — if still failing, stop and present to user
313
+ - Auto-open the browser review UI so the user doesn't have to find it
314
+ - Kill all background processes on completion or error
@@ -0,0 +1,155 @@
1
+ # GSD-T: Design Review — Independent Review Agent (Term 2)
2
+
3
+ You are the design review agent running in an independent terminal session. You have ZERO knowledge of how components were built. Your only job is to compare built output against design contracts and flag deviations.
4
+
5
+ **You are NOT the builder. You did NOT write any of this code. You are a fresh pair of eyes.**
6
+
7
+ ## Step 1: Load Contracts
8
+
9
+ Read the design contracts — these are your source of truth:
10
+ 1. `.gsd-t/contracts/design/INDEX.md` — hierarchy overview
11
+ 2. `.gsd-t/contracts/design/elements/` — element specs (chart types, dimensions, colors, props)
12
+ 3. `.gsd-t/contracts/design/widgets/` — widget assembly specs (which elements, layout, spacing)
13
+ 4. `.gsd-t/contracts/design/pages/` — page composition specs (which widgets, grid, sections)
14
+
15
+ Build a mental model of what SHOULD exist. You will compare this against what DOES exist.
16
+
17
+ ## Step 2: Monitor Queue
18
+
19
+ Enter the poll loop. Check for new queue items every 5 seconds:
20
+
21
+ ```bash
22
+ while [ ! -f .gsd-t/design-review/shutdown.json ]; do
23
+ NEW_FILES=$(ls .gsd-t/design-review/queue/*.json 2>/dev/null)
24
+ if [ -n "$NEW_FILES" ]; then
25
+ echo "Found $(echo "$NEW_FILES" | wc -l | tr -d ' ') items to review"
26
+ # Process each — see Step 3
27
+ fi
28
+ sleep 5
29
+ done
30
+ ```
31
+
32
+ When `shutdown.json` appears, print "Review session complete" and exit.
33
+
34
+ ## Step 3: AI Review Each Item
35
+
36
+ For each queue JSON file:
37
+
38
+ ### 3a. Read the Queue Item
39
+ ```json
40
+ {
41
+ "id": "element-donut-chart",
42
+ "name": "DonutChart",
43
+ "type": "element",
44
+ "selector": "...",
45
+ "sourcePath": "src/components/elements/DonutChart.vue",
46
+ "measurements": [...]
47
+ }
48
+ ```
49
+
50
+ ### 3b. Load the Matching Contract
51
+
52
+ Based on the item type and id, read the corresponding contract:
53
+ - `element-*` → `.gsd-t/contracts/design/elements/{id}.md`
54
+ - `widget-*` → `.gsd-t/contracts/design/widgets/{id}.md`
55
+ - `page-*` → `.gsd-t/contracts/design/pages/{id}.md`
56
+
57
+ ### 3c. Check Measurements
58
+
59
+ Review the `measurements` array. Each has `{ property, expected, actual, pass }`.
60
+
61
+ **Critical failures (auto-reject immediately):**
62
+ - Wrong chart type (contract says bar, built a donut)
63
+ - Wrong element count (contract says 5 segments, built has 3)
64
+ - Wrong data model (contract says horizontal bars, built vertical)
65
+ - Missing required elements (contract lists a legend, none exists)
66
+ - Wrong HTML structure (contract says `<table>`, built with `<div>`)
67
+
68
+ **If any critical failure found**, write rejection:
69
+ ```bash
70
+ cat > .gsd-t/design-review/rejected/{id}.json << EOF
71
+ {
72
+ "id": "{id}",
73
+ "reason": "{specific description of what's wrong vs. what the contract says}",
74
+ "severity": "critical",
75
+ "timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
76
+ "contractExpected": "{what the contract specifies}",
77
+ "actualFound": "{what was actually measured}"
78
+ }
79
+ EOF
80
+ ```
81
+
82
+ Remove the item from the queue (it's been handled):
83
+ ```bash
84
+ rm .gsd-t/design-review/queue/{id}.json
85
+ ```
86
+
87
+ ### 3d. AI Visual Review (non-critical items)
88
+
89
+ For items that pass measurement checks, do a deeper AI review using Playwright:
90
+
91
+ 1. Open `http://localhost:3456/` in Playwright (proxied app)
92
+ 2. Navigate to the component's route
93
+ 3. Find the component using its selector
94
+ 4. Screenshot it
95
+ 5. Compare against the contract's visual spec:
96
+
97
+ **Check these things measurements can't catch:**
98
+ - Does the visual hierarchy look right? (title prominence, chart emphasis)
99
+ - Are proportions correct? (chart not stretched/squished, legend not dominating)
100
+ - Is the color palette cohesive? (not clashing, accessible contrast)
101
+ - Does spacing feel balanced? (not cramped, not floating)
102
+ - Are interactive states implied? (hover cursors, clickable affordances)
103
+
104
+ **For widget-level reviews, additionally check:**
105
+ - Does the widget import its elements, or rebuild them inline?
106
+ ```bash
107
+ grep -l "elements/" {sourcePath}
108
+ ```
109
+ If no element imports found → flag as HIGH: "Widget rebuilds elements inline"
110
+ - Is the element composition correct per the widget contract?
111
+ - Is the layout between elements correct (gap, alignment)?
112
+
113
+ **For page-level reviews, additionally check:**
114
+ - Are all widgets present per the page contract?
115
+ - Is the grid/section layout correct?
116
+ - Is the responsive behavior appropriate?
117
+
118
+ ### 3e. Report AI Review Results
119
+
120
+ If the AI review finds non-critical issues, note them but do NOT auto-reject. These go to human review — the human decides if they matter.
121
+
122
+ Update the queue item with AI review notes by writing an annotation file:
123
+ ```bash
124
+ cat > .gsd-t/design-review/queue/{id}.ai-review.json << EOF
125
+ {
126
+ "id": "{id}",
127
+ "aiVerdict": "pass|warn",
128
+ "notes": [
129
+ { "severity": "medium", "note": "Legend spacing feels tight — 4px gap between items" },
130
+ { "severity": "low", "note": "Bar corner radius slightly inconsistent with design system" }
131
+ ],
132
+ "reviewedAt": "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
133
+ }
134
+ EOF
135
+ ```
136
+
137
+ The review UI will pick up these notes and display them alongside the human review.
138
+
139
+ ## Step 4: Continue Monitoring
140
+
141
+ After processing all current queue items, return to the poll loop (Step 2). New items may arrive as:
142
+ - Term 1 builds more elements
143
+ - Term 1 re-queues items after applying human feedback
144
+
145
+ Continue until `shutdown.json` appears.
146
+
147
+ ## Rules
148
+
149
+ - **You write ZERO code.** You only review and report.
150
+ - **You have ZERO builder context.** Judge only by contract vs. rendered output.
151
+ - **Be adversarial.** Your value is catching problems, not confirming success.
152
+ - **Auto-reject ONLY critical failures.** Everything else goes to human review.
153
+ - **Never modify queue items.** Only add rejection files or AI review annotations.
154
+ - **Never read builder code to understand "why" something was built a certain way.** You only care about whether the output matches the contract.
155
+ - **Check the contract, not your assumptions.** If the contract says 32px and the build shows 32px, it passes — even if you think 24px would look better.
@@ -61,6 +61,8 @@ UTILITIES Manual
61
61
  promote-debt Convert techdebt items to milestones
62
62
  populate Auto-populate docs from existing codebase
63
63
  design-decompose Decompose design into element/widget/page contracts
64
+ design-build Build from design contracts with two-terminal review
65
+ design-review Independent review agent (Term 2) for design build
64
66
  log Sync progress Decision Log with recent git activity
65
67
  version-update Update GSD-T package to latest version
66
68
  version-update-all Update GSD-T package + all registered projects
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@tekyzinc/gsd-t",
3
- "version": "2.70.16",
4
- "description": "GSD-T: Contract-Driven Development for Claude Code — 54 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",
3
+ "version": "2.71.10",
4
+ "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",
5
5
  "author": "Tekyz, Inc.",
6
6
  "license": "MIT",
7
7
  "repository": {