* test(#2845): failing-first suite for UI-SPEC inventory provenance Binds two shared formats before either exists, so the suite is RED against next: the gsd-ui-checker dimension roster (asserted independently on twelve surfaces, eight English and four translated) and the provenance-line grammar the UI-SPEC template emits and Dimension 7 consumes. Every parity assertion is paired with a synthetic mutation case, so the guard's failure branch executes rather than only reading a correct tree: limit-1 (a surface still declaring 6), limit (7), limit+1 (8), a dropped dimension, a label that drifts on one surface only, a non-contiguous roster, a duplicated number, and a surface that stops declaring a count at all. A seeded fast-check property renders the roster under formatting noise (CRLF, padding, interleaved sections) and asserts the parse round-trips and is strictly sensitive to a dropped heading. Assertions are on parsed typed records, never raw substrings. * docs: normalize design-a-ui-phase how-to to American English House style for docs/ is American English (CLAUDE.md). This file carried colour/initialisation/initialise/artefact throughout. Spelling only — no content change; kept separate from the #2845 feature commit so the release-notes classifier and the hotfix cherry-pick filter see it for what it is. * feat(#2845): require provenance for UI-SPEC component inventories A UI-SPEC's component inventory was treated downstream as a closed allowlist while the document recorded nothing about whether the list had been enumerated from the installed design system or recalled from memory. A recalled inventory is indistinguishable from an enumerated one, so an executor complying with the spec builds against a fraction of what the package offers, and every gate stays green because they assert semantics rather than composition. The UI-SPEC template gains a Component Inventory slot carrying one of two provenance lines: the command that enumerated the list, the count it returned, the resolved package@version and the date; or a Could not enumerate record with a real reason. gsd-ui-researcher gains an enumeration ladder and must record the line rather than write the list from recall. gsd-ui-checker gains Dimension 7. An inventory with no provenance line, a count with no command, an empty could-not-enumerate reason, or a line still carrying the template's unfilled placeholders BLOCKs; a partial line, a line placed below its table, or an honest negative record FLAGs; a complete line passes, and so does a spec carrying no inventory at all, which keeps every UI-SPEC predating the dimension validating unchanged. Whatever the verdict, an unsourced inventory is reported as a non-exhaustive list of known-good components rather than a closed allowlist, so the executor is never blocked from a component the spec merely failed to mention. The checker never runs the recorded command. The dimension count moved on all thirteen surfaces that assert it, across five languages. Also corrects the claim in the English, Korean and Portuguese how-tos that this checker applies a scored six-pillar rubric — that rubric belongs to /gsd-ui-review's retroactive audit. * chore(#2845): backfill changeset pr number to 3745 --------- Co-authored-by: sim <sim@local>
This commit is contained in:
Tom Boucher
@@ -94,6 +94,7 @@ GSD uses a multi-agent architecture where thin orchestrators (workflow files) sp
|
||||
- Offers shadcn initialization for React/Next.js/Vite projects
|
||||
- Asks only unanswered design contract questions
|
||||
- Enforces registry safety gate for third-party components
|
||||
- **Enumerates the component inventory rather than recalling it (#2845):** the UI-SPEC's `## Component Inventory` carries a provenance line — the command that enumerated it, the count it returned, the resolved `<package>@<version>`, and the date — or, when nothing can enumerate it, a `Could not enumerate: <reason>` record in the same slot
|
||||
|
||||
---
|
||||
|
||||
@@ -295,7 +296,20 @@ Two further dimensions carry no number: **Verify Command Format Sanity** and
|
||||
| **Color** | Cyan |
|
||||
| **Produces** | BLOCK/FLAG/PASS verdict |
|
||||
|
||||
**Verification Dimensions** — labels match the agent's own `## Dimension <N>` headings:
|
||||
|
||||
| # | Dimension |
|
||||
|---|---|
|
||||
| 1 | Copywriting |
|
||||
| 2 | Visuals |
|
||||
| 3 | Color |
|
||||
| 4 | Typography |
|
||||
| 5 | Spacing |
|
||||
| 6 | Registry Safety |
|
||||
| 7 | Inventory Provenance |
|
||||
|
||||
**Key behaviors:**
|
||||
- **Inventory provenance (#2845):** a UI-SPEC whose component inventory carries no provenance line is reported as a defect, and the inventory is downgraded from a closed allowlist to a **non-exhaustive list of known-good components** — so an executor is never blocked from something the spec merely failed to mention. A spec with no inventory at all PASSes, which is what keeps every UI-SPEC written before the dimension existed validating unchanged. The checker never executes the recorded command; it reads the spec as a document.
|
||||
- **Adversarial stance / "The Auditor" (#1578):** applies explicit BLOCK/FLAG/PASS tiers and an anti-capitulation rule that resists author-framing pressure while still allowing self-correction when the prior dimension application was mistaken. Persona effects are strongest on Sonnet-class reasoning and unvalidated on budget/Haiku-class routing; the criteria and evidence remain authoritative.
|
||||
|
||||
---
|
||||
|
||||
@@ -275,20 +275,21 @@
|
||||
**Requirements:**
|
||||
- REQ-UI-01: System MUST detect existing design system state (shadcn components.json, Tailwind config, tokens)
|
||||
- REQ-UI-02: System MUST ask only unanswered design contract questions
|
||||
- REQ-UI-03: System MUST validate against 6 dimensions (Copywriting, Visuals, Color, Typography, Spacing, Registry Safety)
|
||||
- REQ-UI-03: System MUST validate against 7 dimensions (Copywriting, Visuals, Color, Typography, Spacing, Registry Safety, Inventory Provenance)
|
||||
- REQ-UI-04: System MUST enter revision loop if validation returns BLOCKED (max 2 iterations)
|
||||
- REQ-UI-05: System MUST offer shadcn initialization for React/Next.js/Vite projects without `components.json`
|
||||
- REQ-UI-06: System MUST enforce registry safety gate for third-party shadcn registries
|
||||
|
||||
**Produces:** `{padded_phase}-UI-SPEC.md` — Design contract consumed by executors
|
||||
|
||||
**6 Validation Dimensions:**
|
||||
**7 Validation Dimensions:**
|
||||
1. **Copywriting** — CTA labels, empty states, error messages
|
||||
2. **Visuals** — Focal points, visual hierarchy, icon accessibility
|
||||
3. **Color** — Accent usage discipline, 60/30/10 compliance
|
||||
4. **Typography** — Font size/weight constraint adherence
|
||||
5. **Spacing** — Grid alignment, token consistency
|
||||
6. **Registry Safety** — Third-party component inspection requirements
|
||||
7. **Inventory Provenance** — Component inventory enumerated from the installed design system, not recalled
|
||||
|
||||
**shadcn Integration:**
|
||||
- Detects missing `components.json` in React/Next.js/Vite projects
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# How to design a UI phase
|
||||
|
||||
**Goal:** Produce a locked UI design contract (`UI-SPEC.md`) that fixes spacing, colour, typography, and copywriting decisions before the planner writes tasks, preventing visual inconsistency caused by ad-hoc styling choices during execution.
|
||||
**Goal:** Produce a locked UI design contract (`UI-SPEC.md`) that fixes spacing, color, typography, and copywriting decisions before the planner writes tasks, preventing visual inconsistency caused by ad-hoc styling choices during execution.
|
||||
|
||||
**Prerequisites:** `.planning/ROADMAP.md` exists. The phase must have frontend or UI work. Running `/gsd-discuss-phase N` first is strongly recommended — the UI researcher reads `CONTEXT.md` to avoid re-asking decisions you have already made.
|
||||
|
||||
@@ -13,7 +13,7 @@ Not all phases need `/gsd-ui-phase`. Use it when:
|
||||
- The phase introduces new UI surfaces (pages, flows, layouts)
|
||||
- Multiple components will be built and visual consistency matters
|
||||
- You are starting a new project's frontend and need a design system baseline
|
||||
- You are adding significant UI work to an existing project and want to lock tokens, spacing, and colour before execution
|
||||
- You are adding significant UI work to an existing project and want to lock tokens, spacing, and color before execution
|
||||
|
||||
Skip it when:
|
||||
|
||||
@@ -34,8 +34,8 @@ If no phase number is given, GSD Core targets the current phase.
|
||||
|
||||
The command runs in two stages:
|
||||
|
||||
1. **`gsd-ui-researcher`** — reads `CONTEXT.md`, `RESEARCH.md`, and `REQUIREMENTS.md` for existing decisions, detects the design system state (shadcn `components.json`, Tailwind config, existing tokens), and asks only the unanswered design questions across five areas: spacing, colour, typography, copywriting, and registry safety.
|
||||
2. **`gsd-ui-checker`** — validates the resulting `UI-SPEC.md` across six dimensions. If issues are found, a revision loop reruns the researcher (up to two iterations) targeting only the flagged items.
|
||||
1. **`gsd-ui-researcher`** — reads `CONTEXT.md`, `RESEARCH.md`, and `REQUIREMENTS.md` for existing decisions, detects the design system state (shadcn `components.json`, Tailwind config, existing tokens), and asks only the unanswered design questions across five areas: spacing, color, typography, copywriting, and registry safety.
|
||||
2. **`gsd-ui-checker`** — validates the resulting `UI-SPEC.md` across seven dimensions. If issues are found, a revision loop reruns the researcher (up to two iterations) targeting only the flagged items.
|
||||
|
||||
**Output:** `{padded_phase}-UI-SPEC.md` in `.planning/phases/{phase-dir}/`.
|
||||
|
||||
@@ -48,20 +48,21 @@ The researcher locks decisions across five areas:
|
||||
| Area | Examples |
|
||||
|---|---|
|
||||
| **Spacing** | Base scale (4px or 8px), grid alignment, component padding |
|
||||
| **Colour** | Primary, accent, neutral palette; 60/30/10 rule; dark-mode considerations |
|
||||
| **Color** | Primary, accent, neutral palette; 60/30/10 rule; dark-mode considerations |
|
||||
| **Typography** | Font families, size/weight scale constraints, heading hierarchy |
|
||||
| **Copywriting** | CTA labels, empty state messages, error state copy, loading indicators |
|
||||
| **Registry safety** | shadcn component inspection protocol (see below) |
|
||||
| **Component inventory** | What the design system actually provides, plus the command that enumerated it (see below) |
|
||||
|
||||
The checker validates the spec against six pillars, scored 1–4 each: Copywriting, Visuals, Colour, Typography, Spacing, and Experience Design (loading / error / empty state coverage).
|
||||
The checker validates the spec against its seven dimensions — Copywriting, Visuals, Color, Typography, Spacing, Registry Safety, and Inventory Provenance — returning PASS, FLAG or BLOCK for each. (The scored 1–4 six-pillar rubric belongs to `/gsd-ui-review`'s retroactive audit, not to this checker.)
|
||||
|
||||
---
|
||||
|
||||
## shadcn initialisation
|
||||
## shadcn initialization
|
||||
|
||||
For React, Next.js, and Vite projects, the researcher offers to initialise shadcn if no `components.json` is found. The flow:
|
||||
For React, Next.js, and Vite projects, the researcher offers to initialize shadcn if no `components.json` is found. The flow:
|
||||
|
||||
1. Visit `ui.shadcn.com/create` and configure your preset (colours, border radius, fonts)
|
||||
1. Visit `ui.shadcn.com/create` and configure your preset (colors, border radius, fonts)
|
||||
2. Copy the preset string
|
||||
3. Run:
|
||||
|
||||
@@ -69,7 +70,7 @@ For React, Next.js, and Vite projects, the researcher offers to initialise shadc
|
||||
npx shadcn init --preset <paste>
|
||||
```
|
||||
|
||||
The preset string becomes a first-class GSD Core planning artefact that is reproducible across phases and milestones.
|
||||
The preset string becomes a first-class GSD Core planning artifact that is reproducible across phases and milestones.
|
||||
|
||||
---
|
||||
|
||||
@@ -86,6 +87,65 @@ The checker will flag the spec as BLOCKED if registry safety is not addressed. D
|
||||
|
||||
---
|
||||
|
||||
## Record where the component inventory came from
|
||||
|
||||
If your project has a design system, the UI-SPEC lists the components it provides — and the
|
||||
planner and executor read that list as the design surface they are allowed to build from. A list
|
||||
written from the model's recall looks identical to one enumerated from the installed package, so
|
||||
`gsd-ui-checker` Dimension 7 requires the spec to say which it was.
|
||||
|
||||
The section carries one provenance line, directly above its table:
|
||||
|
||||
```text
|
||||
Enumerated by `npx shadcn info --json` — 153 components — @acme/design-system@4.2.1 — 2026-08-21.
|
||||
```
|
||||
|
||||
Four things are required, and each is there for a reason:
|
||||
|
||||
| Part | Why it is required |
|
||||
|---|---|
|
||||
| The command | The only re-runnable part. A reader can check the claim without re-deriving it. |
|
||||
| The count | Makes an under-listed inventory visible at a glance — "13 components" against a package reporting 153 is a difference you can see. |
|
||||
| `<package>@<version>` | The **resolved installed** version, so a spec reused after an upgrade is visibly stale. A caret range from `package.json` does not do this. |
|
||||
| The date | Bounds how old the claim is. |
|
||||
|
||||
Use whatever the design system provides — a first-party CLI with a JSON mode, an MCP tool, or the
|
||||
installed package's own metadata:
|
||||
|
||||
```bash
|
||||
npx shadcn info # shadcn projects
|
||||
node -p "Object.keys(require('@acme/design-system/package.json').exports).length"
|
||||
node -p "require('@acme/design-system/package.json').version" # resolved version
|
||||
```
|
||||
|
||||
If nothing can enumerate it, record that in the same slot instead, with a real reason:
|
||||
|
||||
```text
|
||||
Could not enumerate: package ships no exports map and no CLI.
|
||||
```
|
||||
|
||||
### What the checker does with it
|
||||
|
||||
| What the spec carries | Dimension 7 | What it means for the executor |
|
||||
|---|---|---|
|
||||
| Command, count, version, date | **PASS** | Sourced list. |
|
||||
| Command and count, no version or date | **FLAG** | Accepted, but staleness is invisible. Add the missing part. |
|
||||
| A complete line, but below the table instead of above it | **FLAG** | Accepted. Move it up — a caveat has to be read before the list it qualifies. |
|
||||
| `Could not enumerate: <reason>` | **FLAG** | Honest and accepted. The list is explicitly non-exhaustive. |
|
||||
| An inventory with no provenance line | **BLOCK** | Enumerate and re-run `/gsd-ui-phase`. |
|
||||
| A count with no command, or a bare `Could not enumerate:` | **BLOCK** | Nothing falsifiable was recorded. |
|
||||
| No inventory section at all | **PASS** | Not applicable — including every spec written before this dimension existed, and any project with `Tool: none`. Nothing to enumerate is not a defect. |
|
||||
|
||||
**A missing provenance line never blocks the executor.** The checker reports it against the spec
|
||||
and downgrades the list to a **non-exhaustive set of known-good components** — so nothing stops
|
||||
you using a component the spec simply failed to mention. Reaching for one outside the table is the
|
||||
expected path, not an exception.
|
||||
|
||||
The checker never runs the recorded command. It reads the spec as a document; executing a command
|
||||
string lifted out of one would be a code-execution path through untrusted text.
|
||||
|
||||
---
|
||||
|
||||
## Use sketch findings as a head start
|
||||
|
||||
If you have already run `/gsd-sketch --wrap-up`, the UI researcher loads `.claude/skills/sketch-findings-[project]/` automatically. Pre-validated decisions (layout, palette, typography, spacing) are treated as locked — the researcher does not re-ask them. You see a note at the start of the run:
|
||||
@@ -109,13 +169,13 @@ This is the main reason to run `/gsd-sketch --wrap-up` before `/gsd-ui-phase`: i
|
||||
/gsd-ui-review 3 # audit phase 3 specifically
|
||||
```
|
||||
|
||||
It works on any project with frontend code — GSD project initialisation is not required.
|
||||
It works on any project with frontend code — GSD project initialization is not required.
|
||||
|
||||
**What it checks (6 pillars, scored 1–4 each):**
|
||||
|
||||
1. Copywriting — CTA labels, empty states, error states
|
||||
2. Visuals — focal points, visual hierarchy, icon accessibility
|
||||
3. Colour — accent usage discipline, 60/30/10 compliance
|
||||
3. Color — accent usage discipline, 60/30/10 compliance
|
||||
4. Typography — font size and weight constraint adherence
|
||||
5. Spacing — grid alignment, token consistency
|
||||
6. Experience Design — loading, error, and empty state coverage
|
||||
@@ -137,7 +197,7 @@ It works on any project with frontend code — GSD project initialisation is not
|
||||
/gsd-ui-review N ← retroactive visual audit (optional but recommended)
|
||||
```
|
||||
|
||||
`/gsd-ui-phase` sits between discuss and plan because the planner reads `UI-SPEC.md` as design context — tasks in `PLAN.md` reference spacing tokens, colour variables, and copywriting decisions that the spec locked.
|
||||
`/gsd-ui-phase` sits between discuss and plan because the planner reads `UI-SPEC.md` as design context — tasks in `PLAN.md` reference spacing tokens, color variables, and copywriting decisions that the spec locked.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -253,20 +253,21 @@
|
||||
**要件:**
|
||||
- REQ-UI-01: システムは既存のデザインシステムの状態を検出しなければならない（shadcn の components.json、Tailwind 設定、トークン）
|
||||
- REQ-UI-02: システムは未回答のデザインコントラクトの質問のみを行わなければならない
|
||||
- REQ-UI-03: システムは6つの次元（コピーライティング、ビジュアル、カラー、タイポグラフィ、スペーシング、レジストリセーフティ）に対してバリデーションしなければならない
|
||||
- REQ-UI-03: システムは7つの次元（コピーライティング、ビジュアル、カラー、タイポグラフィ、スペーシング、レジストリセーフティ、インベントリプロビナンス）に対してバリデーションしなければならない
|
||||
- REQ-UI-04: バリデーションが BLOCKED を返した場合、システムはリビジョンループに入らなければならない（最大2回の反復）
|
||||
- REQ-UI-05: `components.json` のない React/Next.js/Vite プロジェクトに対して、システムは shadcn の初期化を提案しなければならない
|
||||
- REQ-UI-06: システムはサードパーティの shadcn レジストリに対してレジストリセーフティゲートを適用しなければならない
|
||||
|
||||
**生成物:** `{padded_phase}-UI-SPEC.md` — エグゼキューターが参照するデザインコントラクト
|
||||
|
||||
**6つのバリデーション次元:**
|
||||
**7つのバリデーション次元:**
|
||||
1. **コピーライティング** — CTA ラベル、空状態、エラーメッセージ
|
||||
2. **ビジュアル** — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
|
||||
3. **カラー** — アクセントカラーの使用規律、60/30/10 準拠
|
||||
4. **タイポグラフィ** — フォントサイズ/ウェイトの制約遵守
|
||||
5. **スペーシング** — グリッド配置、トークンの一貫性
|
||||
6. **レジストリセーフティ** — サードパーティコンポーネントの検査要件
|
||||
7. **インベントリプロビナンス** — コンポーネントインベントリがインストール済みのデザインシステムから列挙されたものであり、記憶に頼っていないこと
|
||||
|
||||
**shadcn 連携:**
|
||||
- React/Next.js/Vite プロジェクトで `components.json` が欠落していることを検出
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
コマンドは 2 つのステージで実行されます。
|
||||
|
||||
1. **`gsd-ui-researcher`** — `CONTEXT.md`、`RESEARCH.md`、`REQUIREMENTS.md` を読み込んで既存の決定事項を確認し、デザインシステムの状態（shadcn の `components.json`、Tailwind 設定、既存トークン）を検出し、スペーシング・カラー・タイポグラフィ・コピーライティング・レジストリ安全性の 5 つの領域で未回答のデザイン問題のみを確認します。
|
||||
2. **`gsd-ui-checker`** — 生成された `UI-SPEC.md` を 6 つの側面で検証します。問題が発見された場合、指摘された項目のみを対象に研究者が再実行されるリビジョンループが起動します（最大 2 回のイテレーション）。
|
||||
2. **`gsd-ui-checker`** — 生成された `UI-SPEC.md` を 7 つの側面で検証します。問題が発見された場合、指摘された項目のみを対象に研究者が再実行されるリビジョンループが起動します（最大 2 回のイテレーション）。
|
||||
|
||||
**出力:** `.planning/phases/{phase-dir}/` 内の `{padded_phase}-UI-SPEC.md`。
|
||||
|
||||
|
||||
@@ -189,20 +189,21 @@
|
||||
**요구사항.**
|
||||
- REQ-UI-01: 기존 디자인 시스템 상태를 감지해야 합니다(shadcn components.json, Tailwind config, 토큰).
|
||||
- REQ-UI-02: 아직 답변되지 않은 설계 계약 질문만 물어봐야 합니다.
|
||||
- REQ-UI-03: 6개 차원에 대해 유효성을 검사해야 합니다(Copywriting, Visuals, Color, Typography, Spacing, Registry Safety).
|
||||
- REQ-UI-03: 7개 차원에 대해 유효성을 검사해야 합니다(Copywriting, Visuals, Color, Typography, Spacing, Registry Safety, Inventory Provenance).
|
||||
- REQ-UI-04: 유효성 검사가 BLOCKED를 반환하면 수정 루프에 진입해야 합니다(최대 2회 반복).
|
||||
- REQ-UI-05: `components.json`이 없는 React/Next.js/Vite 프로젝트에 shadcn 초기화를 제공해야 합니다.
|
||||
- REQ-UI-06: 서드파티 shadcn 레지스트리에 대한 레지스트리 안전 게이트를 적용해야 합니다.
|
||||
|
||||
**생성 산출물.** `{padded_phase}-UI-SPEC.md` — 실행자가 사용하는 설계 계약
|
||||
|
||||
**6가지 유효성 검사 차원.**
|
||||
**7가지 유효성 검사 차원.**
|
||||
1. **Copywriting** — CTA 레이블, 빈 상태, 오류 메시지
|
||||
2. **Visuals** — 초점, 시각적 계층구조, 아이콘 접근성
|
||||
3. **Color** — 강조색 사용 규율, 60/30/10 준수
|
||||
4. **Typography** — 글꼴 크기/굵기 제약 준수
|
||||
5. **Spacing** — 그리드 정렬, 토큰 일관성
|
||||
6. **Registry Safety** — 서드파티 컴포넌트 검사 요구사항
|
||||
7. **Inventory Provenance** — 컴포넌트 인벤토리가 설치된 디자인 시스템에서 열거된 것이어야 하며, 기억에 의존해 작성되지 않았을 것
|
||||
|
||||
**shadcn 통합.**
|
||||
- React/Next.js/Vite 프로젝트에서 누락된 `components.json`을 감지합니다.
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
명령은 두 단계로 실행됩니다:
|
||||
|
||||
1. **`gsd-ui-researcher`** — `CONTEXT.md`, `RESEARCH.md`, `REQUIREMENTS.md`에서 기존 결정을 읽고, 디자인 시스템 상태(shadcn `components.json`, Tailwind 설정, 기존 토큰)를 감지하며, 간격, 색상, 타이포그래피, 카피라이팅, 레지스트리 안전성 다섯 영역에 걸쳐 답하지 않은 디자인 질문만 묻습니다.
|
||||
2. **`gsd-ui-checker`** — 결과로 생성된 `UI-SPEC.md`를 여섯 가지 차원에서 검증합니다. 문제가 발견되면 수정 루프가 플래그된 항목만을 대상으로 연구자를 다시 실행합니다(최대 두 번 반복).
|
||||
2. **`gsd-ui-checker`** — 결과로 생성된 `UI-SPEC.md`를 일곱 가지 차원에서 검증합니다. 문제가 발견되면 수정 루프가 플래그된 항목만을 대상으로 연구자를 다시 실행합니다(최대 두 번 반복).
|
||||
|
||||
**출력:** `.planning/phases/{phase-dir}/`의 `{padded_phase}-UI-SPEC.md`.
|
||||
|
||||
@@ -53,7 +53,7 @@
|
||||
| **카피라이팅** | CTA 레이블, 빈 상태 메시지, 오류 상태 복사, 로딩 인디케이터 |
|
||||
| **레지스트리 안전성** | shadcn 컴포넌트 검사 프로토콜(아래 참조) |
|
||||
|
||||
체커는 6가지 기둥(각 1~4점 채점)에 대해 스펙을 검증합니다: 카피라이팅, 시각적, 색상, 타이포그래피, 간격, 경험 디자인(로딩/오류/빈 상태 커버리지).
|
||||
체커는 일곱 가지 차원(카피라이팅, 시각적, 색상, 타이포그래피, 간격, 레지스트리 안전, 인벤토리 출처)에 대해 스펙을 검증하며 각 차원마다 PASS, FLAG 또는 BLOCK을 반환합니다. (1~4점으로 채점하는 6가지 기둥 루브릭은 이 체커가 아니라 `/gsd-ui-review`의 소급 감사에 속합니다.)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ Se nenhum número de fase for fornecido, o GSD Core usa a fase atual como alvo.
|
||||
O comando é executado em dois estágios:
|
||||
|
||||
1. **`gsd-ui-researcher`** — lê `CONTEXT.md`, `RESEARCH.md` e `REQUIREMENTS.md` em busca de decisões existentes, detecta o estado do sistema de design (shadcn `components.json`, configuração do Tailwind, tokens existentes), e faz apenas as perguntas de design não respondidas em cinco áreas: espaçamento, cores, tipografia, textos e segurança do registro.
|
||||
2. **`gsd-ui-checker`** — valida o `UI-SPEC.md` resultante em seis dimensões. Se problemas forem encontrados, um ciclo de revisão reexecuta o pesquisador (até duas iterações) visando apenas os itens sinalizados.
|
||||
2. **`gsd-ui-checker`** — valida o `UI-SPEC.md` resultante em sete dimensões. Se problemas forem encontrados, um ciclo de revisão reexecuta o pesquisador (até duas iterações) visando apenas os itens sinalizados.
|
||||
|
||||
**Saída:** `{padded_phase}-UI-SPEC.md` em `.planning/phases/{phase-dir}/`.
|
||||
|
||||
@@ -53,7 +53,7 @@ O pesquisador bloqueia decisões em cinco áreas:
|
||||
| **Textos** | Rótulos de CTA, mensagens de estado vazio, textos de estado de erro, indicadores de carregamento |
|
||||
| **Segurança do registro** | Protocolo de inspeção de componentes shadcn (veja abaixo) |
|
||||
|
||||
O verificador valida a especificação em seis pilares, com pontuação de 1 a 4 cada: Textos, Visuais, Cores, Tipografia, Espaçamento e Design de Experiência (cobertura de estados de carregamento / erro / vazio).
|
||||
O verificador valida a especificação em suas sete dimensões — Textos, Visuais, Cores, Tipografia, Espaçamento, Segurança de Registro e Proveniência do Inventário — retornando PASS, FLAG ou BLOCK para cada uma. (A rubrica de 6 pilares com pontuação de 1 a 4 pertence à auditoria retroativa do `/gsd-ui-review`, não a este verificador.)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -253,20 +253,21 @@
|
||||
**需求：**
|
||||
- REQ-UI-01：系统必须检测现有设计系统状态（shadcn components.json、Tailwind 配置、令牌）
|
||||
- REQ-UI-02：系统必须只提问尚未回答的设计契约问题
|
||||
- REQ-UI-03：系统必须从 6 个维度进行验证（文案、视觉、颜色、排版、间距、注册表安全）
|
||||
- REQ-UI-03：系统必须从 7 个维度进行验证（文案、视觉、颜色、排版、间距、注册表安全、清单来源）
|
||||
- REQ-UI-04：当验证返回 BLOCKED 时，系统必须进入修订循环（最多 2 次迭代）
|
||||
- REQ-UI-05：对于没有 `components.json` 的 React/Next.js/Vite 项目，系统必须提供 shadcn 初始化
|
||||
- REQ-UI-06：系统必须对第三方 shadcn 注册表实施注册表安全门控
|
||||
|
||||
**产出物：** `{padded_phase}-UI-SPEC.md` — 执行者使用的设计契约
|
||||
|
||||
**6 个验证维度：**
|
||||
**7 个验证维度：**
|
||||
1. **文案** — CTA 标签、空状态、错误消息
|
||||
2. **视觉** — 焦点、视觉层次、图标无障碍
|
||||
3. **颜色** — 强调色使用规范、60/30/10 合规性
|
||||
4. **排版** — 字体大小/粗细约束遵守情况
|
||||
5. **间距** — 网格对齐、令牌一致性
|
||||
6. **注册表安全** — 第三方组件检查要求
|
||||
7. **清单来源** — 组件清单必须从已安装的设计系统中枚举得出，而非凭记忆写出
|
||||
|
||||
**shadcn 集成：**
|
||||
- 检测 React/Next.js/Vite 项目中缺失的 `components.json`
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
该命令分两个阶段运行：
|
||||
|
||||
1. **`gsd-ui-researcher`** — 读取 `CONTEXT.md`、`RESEARCH.md` 和 `REQUIREMENTS.md` 中的已有决策，检测设计系统状态（shadcn `components.json`、Tailwind 配置、现有 token），并仅针对以下五个领域中尚未回答的设计问题进行提问：间距、颜色、字体、文案和注册表安全。
|
||||
2. **`gsd-ui-checker`** — 从六个维度验证生成的 `UI-SPEC.md`。如果发现问题，修订循环会重新运行研究员（最多两次迭代），专门针对被标记的项目。
|
||||
2. **`gsd-ui-checker`** — 从七个维度验证生成的 `UI-SPEC.md`。如果发现问题，修订循环会重新运行研究员（最多两次迭代），专门针对被标记的项目。
|
||||
|
||||
**输出：** `.planning/phases/{phase-dir}/` 中的 `{padded_phase}-UI-SPEC.md`。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user