@tekyzinc/gsd-t 2.56.10 → 2.56.12

package/commands/gsd-t-execute.md

@@ -678,6 +678,14 @@ Rules:
 7. **E2E Functional Gaps**: Review ALL Playwright specs. Do they test actual
    behavior (state changes, data loaded, navigation works) or just check
    that elements exist? Flag and rewrite any shallow/layout tests.
+8. **Design Fidelity** (if .gsd-t/contracts/design-contract.md exists):
+   Open every implemented screen in a real browser. Screenshot at mobile
+   (375px), tablet (768px), desktop (1280px). Get Figma reference via
+   Figma MCP get_screenshot (or design contract images). Compare every
+   element: chart types, colors, typography, spacing, layout, component
+   states, data visualization style. Any visual deviation from the design
+   is a CRITICAL bug. 'Build shows vertical bars but design shows horizontal
+   stacked bars' is a real bug, not a style opinion.
 
 ## Exploratory Testing (if Playwright MCP available)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.56.10",
+  "version": "2.56.12",
   "description": "GSD-T: Contract-Driven Development for Claude Code — 51 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/templates/CLAUDE-global.md

@@ -322,7 +322,7 @@ After QA passes, every code-producing command spawns a **Red Team agent** — an
 **Key Red Team rules:**
 - **Inverted incentive**: More bugs found = more value. Zero bugs requires exhaustive proof of thoroughness.
 - **False positive penalty**: Reporting non-bugs destroys credibility. Every bug must be reproduced with proof.
-- **Exhaustive categories**: Contract violations, boundary inputs, state transitions, error paths, missing flows, regression, E2E functional gaps — all must be attempted.
+- **Exhaustive categories**: Contract violations, boundary inputs, state transitions, error paths, missing flows, regression, E2E functional gaps, design fidelity (when design contract exists: render in browser, screenshot, compare pixel-by-pixel against Figma) — all must be attempted.
 - **VERDICT**: `FAIL` (bugs found — blocks completion) or `GRUDGING PASS` (exhaustive search, nothing found).
 - **Report**: Written to `.gsd-t/red-team-report.md`; bugs also appended to `.gsd-t/qa-issues.md`.
 

package/templates/stacks/design-to-code.md

@@ -259,7 +259,46 @@ MANDATORY:
 
 ---
 
-## 10. CSS Precision Rules
+## 10. Naming Conventions (Classes, IDs, Data Attributes)
+
+```
+MANDATORY:
+  ├── CSS class naming — use ONE consistent convention per project:
+  │     BEM: .block__element--modifier (e.g., .card__title--highlighted)
+  │     Tailwind: utility classes only (no custom class names needed)
+  │     CSS Modules: camelCase (e.g., styles.cardTitle)
+  │     Scoped CSS (Vue/Svelte): semantic kebab-case (e.g., .card-title)
+  │     NEVER mix conventions in the same project
+  ├── IDs — use sparingly, only when required:
+  │     Form label associations: <label for="email-input">
+  │     Anchor targets: <section id="pricing">
+  │     ARIA references: aria-labelledby, aria-describedby
+  │     NEVER use IDs for styling — classes only
+  │     NEVER use auto-generated or meaningless IDs (id="div1", id="el-47")
+  ├── Data attributes — for JavaScript hooks and testing:
+  │     data-testid for test selectors (e.g., data-testid="submit-button")
+  │     data-* for component state/config (e.g., data-active="true")
+  │     NEVER use classes or IDs for JavaScript selection — use data attributes
+  ├── Component naming — match the design system:
+  │     If Figma layers are named "Hero/CTA Button" → component is CTAButton
+  │     If design system has "Card > Title" → class is .card__title or .card-title
+  │     Align code names with design names for traceability
+  ├── Semantic naming — describe purpose, not appearance:
+  │     BAD: .blue-text, .big-box, .left-panel, .mt-20
+  │     GOOD: .primary-action, .feature-card, .sidebar, .section-spacing
+  │     Exception: utility classes in Tailwind (appearance-based by design)
+  └── File naming — match component names:
+        Component: FeatureCard.vue → styles: feature-card.css or scoped
+        Component: HeroSection.tsx → test: HeroSection.test.tsx
+```
+
+**BAD** — `<div class="div1 blue-thing" id="x47" onclick="...">`
+
+**GOOD** — `<section class="feature-card" data-testid="feature-card-pricing">`
+
+---
+
+## 11. CSS Precision Rules
 
 ```
 MANDATORY:
@@ -290,7 +329,7 @@ MANDATORY:
 
 ---
 
-## 11. Typography Rendering
+## 12. Typography Rendering
 
 ```
 MANDATORY:
@@ -323,7 +362,7 @@ MANDATORY:
 
 ---
 
-## 12. Color Accuracy
+## 13. Color Accuracy
 
 ```
 MANDATORY:
@@ -357,7 +396,7 @@ MANDATORY:
 
 ---
 
-## 13. Interactive States
+## 14. Interactive States
 
 ```
 MANDATORY:
@@ -394,7 +433,7 @@ MANDATORY:
 
 ---
 
-## 14. Visual Verification Loop
+## 15. Visual Verification Loop
 
 ```
 MANDATORY:
@@ -454,7 +493,7 @@ MANDATORY:
 
 ---
 
-## 15. Anti-Patterns
+## 16. Anti-Patterns
 
 ```
 NEVER DO THESE:
@@ -474,7 +513,7 @@ NEVER DO THESE:
 
 ---
 
-## 16. Design-to-Code Verification Checklist
+## 17. Design-to-Code Verification Checklist
 
 Before marking any design implementation task as complete:
 
@@ -486,6 +525,7 @@ Before marking any design implementation task as complete:
 - [ ] Every CSS value traces to a design contract entry
 - [ ] CSS custom properties (or Tailwind config) define all design tokens
 - [ ] Semantic HTML used (no div-soup, proper heading hierarchy)
+- [ ] Naming conventions consistent: classes (BEM/Tailwind/Modules/scoped), IDs (minimal, semantic), data-testid for test hooks
 - [ ] All interactive states implemented (hover, focus, active, disabled)
 - [ ] Responsive behavior implemented for all target breakpoints
 - [ ] Visual verification loop completed at mobile, tablet, and desktop widths