@hegemonart/get-design-done 1.35.5 → 1.36.2

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.
@@ -5,14 +5,14 @@
5
5
  },
6
6
  "metadata": {
7
7
  "description": "Get Design Done — 5-stage agent-orchestrated design pipeline with 9 connections, handoff-first workflow, bidirectional Figma write-back, 22+ specialized agents, queryable knowledge layer (intel store, dependency analysis, learnings extraction), and a self-improvement loop (reflector, frontmatter + budget feedback, global-skills layer). v1.20.0 ships the SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream, and resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) for rate-limit + 429 + context-overflow recovery. Full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows) and release automation (auto-tag + GitHub Release + release-time smoke test).",
8
- "version": "1.35.5"
8
+ "version": "1.36.2"
9
9
  },
10
10
  "plugins": [
11
11
  {
12
12
  "name": "get-design-done",
13
13
  "source": "./",
14
14
  "description": "Agent-orchestrated 5-stage design pipeline: Brief → Explore → Plan → Design → Verify. 22+ specialized agents, 9 connections (Figma, Refero, Preview, Storybook, Chromatic, Figma Writer, Graphify, Pinterest, Claude Design), Claude Design handoff, bidirectional Figma write-back, and a queryable intel store (.design/intel/) for dependency and learnings queries. Standalone commands: style, darkmode, compare, figma-write, graphify, handoff, analyze-dependencies, skill-manifest, extract-learnings. Embeds NNG heuristics, WCAG thresholds, typographic systems, motion framework, and anti-pattern catalog. Ships with a full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows) and release automation. Optimization layer (v1.0.4.1, retroactive): gdd-router + gdd-cache-manager skills, PreToolUse budget-enforcer hook, tier-aware agent frontmatter, lazy checker gates, streaming synthesizer, /gdd:warm-cache + /gdd:optimize commands, and cost telemetry at .design/telemetry/costs.jsonl — targeting 50-70% per-task token-cost reduction with no quality-floor regression. v1.20.0 SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream at .design/telemetry/events.jsonl, resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) with rate-limit + 429 + context-overflow recovery, and TypeScript toolchain.",
15
- "version": "1.35.5",
15
+ "version": "1.36.2",
16
16
  "author": {
17
17
  "name": "hegemonart"
18
18
  },
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "get-design-done",
3
3
  "short_name": "gdd",
4
- "version": "1.35.5",
4
+ "version": "1.36.2",
5
5
  "description": "Agent-orchestrated 5-stage design pipeline: Brief → Explore → Plan → Design → Verify. 22+ specialized agents, 9 connections (Figma, Refero, Preview, Storybook, Chromatic, Figma Writer, Graphify, Pinterest, Claude Design), handoff-first workflow via Claude Design bundles, bidirectional Figma write-back (annotations, Code Connect), queryable intel store (`.design/intel/`) for O(1) design surface lookups, and self-improvement loop (reflector agent, frontmatter + budget feedback, global-skills layer at `~/.claude/gdd/global-skills/`). Standalone commands: style, darkmode, compare, figma-write, graphify, handoff, analyze-dependencies, skill-manifest, extract-learnings, reflect, apply-reflections. Embeds NNG heuristics, WCAG thresholds, typographic systems, motion framework, and anti-pattern catalog. Ships with a full CI/CD pipeline (Node 22/24 × Linux/macOS/Windows, lint + schema + frontmatter + stale-ref + shellcheck + gitleaks + injection-scan + blocking size-budget) and release automation (auto-tag + GitHub Release + release-time smoke test). Optimization layer (v1.0.4.1, retroactive): gdd-router + gdd-cache-manager skills, PreToolUse budget-enforcer hook, tier-aware agent frontmatter, lazy checker gates, streaming synthesizer, /gdd:warm-cache + /gdd:optimize commands, and cost telemetry at .design/telemetry/costs.jsonl — targeting 50-70% per-task token-cost reduction with no quality-floor regression. v1.20.0 SDK foundation: gdd-state MCP server (11 typed tools), lockfile-safe STATE.md mutations, event stream at .design/telemetry/events.jsonl, resilience primitives (jittered-backoff, rate-guard, error-classifier, iteration-budget) with rate-limit + 429 + context-overflow recovery, and TypeScript toolchain. v1.27.7 ships gdd-mcp (Phase 27.7): 12 read-only MCP tools for sub-3s priming. v1.28.0 (Phase 28): Foundational References Tier 2 — 5 new reference files (color-theory, composition, proportion-systems, i18n, contrast-advanced), 2 verifier i18n probes + 1 explore i18n-readiness probe, 12 additive cross-link insertions across 10 existing references, 2 orthogonal audit-scoring lens-tags (composition_alignment + i18n_readiness).",
6
6
  "author": {
7
7
  "name": "hegemonart",
package/CHANGELOG.md CHANGED
@@ -4,6 +4,53 @@ All notable changes to get-design-done are documented here. Versions follow [sem
4
4
 
5
5
  ---
6
6
 
7
+ ## [1.36.2] - 2026-06-01
8
+
9
+ ### Phase 36.2 — Knowledge Tier-3: Motion-Tool Verification (Lottie + Rive)
10
+
11
+ Second sub-phase of the split **Phase 36**. Motion existed as a *principle* (Phase 18) but not as a *verifiable artifact* — Lottie/Rive ship animation exports + state machines and GDD never opened them. 36.2 adds a pure motion validator + two optional connections + a verify-time agent. **No new runtime dependency, no new egress** (pure `JSON.parse` + file checks; the Lottie player / Rive runtime are opt-in). Every motion finding is a **warning, never a blocker** (motion is creative, not contractually broken).
12
+
13
+ ### Added
14
+
15
+ - **`scripts/lib/motion/validate-motion.cjs`** — a pure, dependency-free (zero `require`) motion validator. `validateLottie(json, {bytes, budgetBytes})` checks frame-rate sanity, non-positive duration, layer count, embedded-asset bloat, and the perf budget (rules `MO-PARSE/FR/DUR/LAYERS/IMG/BUDGET`); `motionBudget` is the shared byte-cap check; `riveHeader` is the `.riv` magic-byte sanity. Deterministic.
16
+ - **`connections/lottie.md`** — file-probe connection for Lottie JSON exports; static floor = `validateLottie`; the live player is opt-in; degrade-to-static → code-only.
17
+ - **`connections/rive.md`** — file-probe connection for Rive `.riv` exports. `.riv` is binary, so the deep state-machine graph (unreachable states, no-exit loops) needs the opt-in Rive runtime; the pure-JS floor is size + the `RIVE` header + a manual-review advisory.
18
+ - **`agents/motion-verifier.md`** — at verify time, discovers Lottie/Rive exports, runs `validate-motion.cjs`, enforces a perf budget (`motion_budget_kb`, fallback 200 KB), and WARNs. Reads-only.
19
+ - **`agents/design-verifier.md`** — Phase 4E motion hook (gate on exports → delegate to `motion-verifier` → degrade-to-noop).
20
+ - **`connections/connections.md`** + onboarding — 19 → 21 (Lottie + Rive Active rows, `verify` capability-matrix entries, file probes, value-prop + setup matrix).
21
+
22
+ ### Notes
23
+
24
+ - **No new runtime dependency, no new egress.** The pure validator never opens the network; the Lottie player + Rive runtime are maintainer-supplied opt-ins (the print-render precedent).
25
+ - 6-manifest lockstep at **v1.36.2** + `OFF_CADENCE_VERSIONS.add('1.36.2')` + the 24 live-pinned `manifests-version.txt` baselines forward-propagated 1.36.1 → 1.36.2.
26
+ - Inventory relock: connection-list 27 → 29, phase-20 agent-list + frontmatter-snapshot += `motion-verifier`, onboarding → 21, tarball golden 665 → 669 (+4). Registry unchanged (no new `reference/` doc).
27
+
28
+ ---
29
+
30
+ ## [1.36.1] - 2026-06-01
31
+
32
+ ### Phase 36.1 — Knowledge Tier-3: Domain Packs (finance + healthcare + gaming + civic)
33
+
34
+ First sub-phase of the split **Phase 36 (Knowledge Tier 3)**. Adds four industry-specific design-pattern reference packs and wires **domain detection** into the pipeline — closing the industry-lens gap (GDD shipped 18 generic design systems + foundational Tier-2, but no domain-specific patterns). Finance and healthcare especially carry regulatory constraints (PCI-DSS, MiFID II, HIPAA, Section 508) that bleed into UI. **No new pillar, no breaking scoring change, no new runtime dependency, no new egress** — pure reference markdown + agent-prompt edits; detection is keyword/dep matching done by the agent.
35
+
36
+ ### Added
37
+
38
+ - **`reference/domains/finance-patterns.md`** — data-table density (tabular-nums, right-aligned numerics), trading-interface conventions (gain/loss never color-alone), regulatory disclosure placement (Reg-T, MiFID II cost & charges), PCI-DSS PAN masking, number-formatting precision, real-time data states.
39
+ - **`reference/domains/healthcare-patterns.md`** — HIPAA-aware PHI isolation (no PHI in URLs/logs/analytics), idle auto-logout, audit-trail-as-UI, MyChart-class flows, WCAG 2.1 AAA, medical-data visualization. Surfaces risk; does **not** certify compliance.
40
+ - **`reference/domains/gaming-patterns.md`** — HUD/diegetic UI taxonomy, vestibular + photosensitive safety (≤3 flashes/sec, reduced-motion + in-game toggles), ESRB/PEGI age-gates, input-model adaptation (controller/touch/KBM), TV-safe area.
41
+ - **`reference/domains/civic-patterns.md`** — Section 508 + WCAG 2.1 AA hard floor, multi-language gov forms (EN/ES/zh-Hans), Plain Writing Act (grade 6-8), USWDS, session-timeout warnings, one-thing-per-page forms.
42
+ - **`agents/design-context-builder.md`** — new **Step 0F (Domain Detection)**: a dispatcher table (keywords + `package.json` deps → pack) + the confidence rule (≥2 signals or any dep match → auto-apply; 1 weak keyword → suggest; none → skip) + a `<domain>` line in DESIGN-CONTEXT.md. Orthogonal to project-type.
43
+ - **`agents/design-auditor.md`** — **domain checklist addendum**: when a `<domain>` is active, also run that pack's `## Audit checklist` and fold findings into the relevant pillar (additive — never replaces the 7-pillar scoring).
44
+ - All four packs **registered** in `reference/registry.json` (`type: heuristic`, `phase: 36.1`); 145 → 149 entries.
45
+
46
+ ### Notes
47
+
48
+ - **No new runtime dependency, no new egress.** Detection is the agent matching a small embedded signal table — no code, no network.
49
+ - 6-manifest lockstep at **v1.36.1** + `OFF_CADENCE_VERSIONS.add('1.36.1')` + the 23 live-pinned `manifests-version.txt` baselines forward-propagated 1.35.5 → 1.36.1 (opens the v1.36.x arc).
50
+ - The 31.5 tarball golden was regenerated as a reviewed delta: **+4** (the four domain packs), zero removals (661 → 665).
51
+
52
+ ---
53
+
7
54
  ## [1.35.5] - 2026-06-01
8
55
 
9
56
  ### Phase 35.5 — Design-Artifact Export (`/gdd:export`)
package/README.md CHANGED
@@ -150,6 +150,14 @@ Links a design cycle to a **Linear** or **Jira** ticket and keeps them in sync (
150
150
 
151
151
  `/gdd:export <cycle> --format html|pdf|notion` packages a finished cycle's design output (`EXPERIENCE.md`, `DESIGN.md`, `DESIGN-VERIFICATION.md`, the decision log, screenshots) into a stakeholder-shareable artifact — for PMs/execs/brand who aren't in the repo. The [`build-html`](scripts/lib/export/build-html.cjs) assembler emits a **self-contained** HTML (inline CSS, base64-embedded screenshots, **zero external references**); `pdf` is the same HTML plus Paged.js-compatible `@page` print CSS you render yourself; `notion` writes a page via the Notion MCP ([`connections/notion.md`](connections/notion.md), degrade-to-HTML). Every artifact is **redacted**; `--pseudonymize` masks identity/paths/hostname for external sharing; `--pr` posts the HTML preview as a PR comment via `pr-commenter`. **No new runtime dependency** (D-02: pure assembler, no PDF/markdown library). Contract: [`reference/export-formats.md`](reference/export-formats.md).
152
152
 
153
+ ### Domain packs — Knowledge Tier 3 (v1.36.1)
154
+
155
+ Four industry-specific design-pattern packs at [`reference/domains/`](reference/domains/) — **finance** (data-table density, trading-UI color semantics, Reg-T/MiFID II disclosure, PCI-DSS masking, number-formatting precision), **healthcare** (HIPAA PHI isolation, audit-trail-as-UI, WCAG 2.1 AAA, medical-data viz), **gaming** (HUD/diegetic taxonomy, vestibular + photosensitive safety, ESRB/PEGI age-gates, controller/touch input adaptation), and **civic** (Section 508 + WCAG 2.1 AA floor, multi-language gov forms, Plain Writing Act, USWDS). The [`design-context-builder`](agents/design-context-builder.md) auto-detects the domain from brief keywords + `package.json` dependencies (`@stripe/`, `fhir`, `@react-three/fiber`, `@uswds/uswds`, …) and loads the matching pack into downstream context; [`design-auditor`](agents/design-auditor.md) folds each pack's audit checklist into the relevant pillar. Additive knowledge — no new pillar, no new runtime dependency. First sub-phase of Phase 36 (Motion-tool verification + Conversational UI follow).
156
+
157
+ ### Motion-tool verification (v1.36.2)
158
+
159
+ GDD now opens the motion **exports** a project ships. The pure, dependency-free [`validate-motion`](scripts/lib/motion/validate-motion.cjs) checks a **Lottie** JSON for frame-rate sanity, non-positive duration, embedded-asset bloat, and a perf budget (`MO-*` rules); for **Rive** `.riv` (binary) it does size + a `RIVE`-header sanity, and surfaces the state-machine graph (unreachable states, no-exit loops) when the opt-in Rive runtime is present. The [`motion-verifier`](agents/motion-verifier.md) agent runs at verify time ([`connections/lottie.md`](connections/lottie.md) / [`connections/rive.md`](connections/rive.md)) and **WARNs — never blocks** (motion is creative). **No new runtime dependency** — the Lottie player and Rive runtime are opt-in. Second sub-phase of Phase 36.
160
+
153
161
  ### Previous releases
154
162
 
155
163
  - **v1.26.0** — Headless Model Resolver (per-runtime tier→model map, `resolved_models` router field, per-runtime price tables, `reasoning-class` runtime-neutral alias).
@@ -311,6 +311,21 @@ grep -rEn "w-4 h-4|w-5 h-5|w-6 h-6" src/ --include="*.tsx" --include="*.jsx" 2>/
311
311
 
312
312
  ---
313
313
 
314
+ ## Domain checklist addendum (Tier-3)
315
+
316
+ If DESIGN-CONTEXT.md carries a `<domain>` line (set by `design-context-builder` Step 0F — `finance` / `healthcare` / `gaming` / `civic`), **also** run that pack's `## Audit checklist` from `reference/domains/<domain>-patterns.md` and fold its findings into the relevant pillar:
317
+
318
+ | Domain | Pack | Folds into pillar(s) |
319
+ |--------|------|----------------------|
320
+ | finance | `reference/domains/finance-patterns.md` | Typography (tabular-nums / number formatting), Color (gain/loss never color-only), Copy (regulatory disclosure placement), Experience (destructive-action guards) |
321
+ | healthcare | `reference/domains/healthcare-patterns.md` | Experience (PHI isolation, idle auto-logout), Copy (plain medical language), Color (critical-value flags not color-only), Visual Hierarchy (audit-trail surfacing) |
322
+ | gaming | `reference/domains/gaming-patterns.md` | Micro-Polish + Experience (reduced-motion / vestibular, flash thresholds), Layout (TV-safe area), Experience (input-model adaptation, no hover-only) |
323
+ | civic | `reference/domains/civic-patterns.md` | Copy (plain language, grade 6-8), Color (WCAG AA contrast floor), Experience (session-timeout warnings, keyboard operability), Typography (reading level) |
324
+
325
+ A failed domain check is a **finding in its pillar** (it lowers that pillar's score and appears in DESIGN-AUDIT.md), not a separate score. When no `<domain>` is set, skip this addendum. This is **additive** — it never replaces the 7-pillar scoring (per "Supplement, Not Replace" above).
326
+
327
+ ---
328
+
314
329
  ## Execution Steps
315
330
 
316
331
  ### Step 1: Load Context
@@ -250,6 +250,36 @@ Record the detected type in DESIGN-CONTEXT.md as a `<project_type>` line (e.g. `
250
250
 
251
251
  Proceed to Step 1 regardless of outcome.
252
252
 
253
+ ## Step 0F — Domain Detection (Tier-3 packs)
254
+
255
+ Detect the **industry domain** — orthogonal to project type (a finance app can be `web` or `native-ios`). When a domain matches, load its Tier-3 pattern pack so downstream stages (interview, executor, auditor) inherit industry-specific patterns + regulatory constraints. Reuse the file-read grep/glob idiom (< 1 second, no skip).
256
+
257
+ **Domains + packs** (each pack's own `## Detection signals` section is canonical; this table is the dispatcher):
258
+
259
+ | Domain | Pack | Keyword signals | `package.json` dependency signals |
260
+ |--------|------|-----------------|-----------------------------------|
261
+ | finance | `reference/domains/finance-patterns.md` | trading, portfolio, brokerage, ledger, invoice, banking, fintech, payments, KYC | `stripe`, `@stripe/*`, `plaid`, `@plaid/*`, `dwolla-v2`, `finnhub`, `@alpacahq/*`, `ccxt`, `lightweight-charts`, `react-financial-charts`, `highcharts` |
262
+ | healthcare | `reference/domains/healthcare-patterns.md` | patient, clinical, EHR, EMR, telehealth, HIPAA, PHI, provider, diagnosis | `fhir`, `fhirclient`, `fhir-kit-client`, `@medplum/*`, `medplum`, `hl7`, `redox` |
263
+ | gaming | `reference/domains/gaming-patterns.md` | game, HUD, player, level, multiplayer, leaderboard, inventory, quest | `phaser`, `three`, `@react-three/*`, `pixi.js`, `babylonjs`, `@babylonjs/*`, `colyseus`, `playcanvas`, `excalibur`, `matter-js` |
264
+ | civic | `reference/domains/civic-patterns.md` | gov, government, public, citizen, benefits, permit, tax, election, municipal | `@uswds/uswds`, `uswds`, `@trussworks/react-uswds`, `govuk-frontend`, `@18f/*` |
265
+
266
+ ```bash
267
+ grep -iE "trading|portfolio|brokerage|fintech|patient|clinical|EHR|HIPAA|HUD|multiplayer|leaderboard|gov|citizen|benefits|permit" -r . --include="*.md" --include="*.tsx" 2>/dev/null | head
268
+ node -e "const p=require('./package.json');const d={...p.dependencies,...p.devDependencies};console.log(Object.keys(d).join(' '))" 2>/dev/null # match against the dependency column
269
+ ```
270
+
271
+ **Confidence rule (D-02):**
272
+
273
+ - **≥2 distinct signals, OR any dependency match → auto-apply** the pack. Record it + note it in the brief ("Detected finance domain — loaded finance-patterns.md").
274
+ - **Exactly 1 weak keyword signal → suggest**, don't impose ("This looks like a healthcare project — load healthcare-patterns.md? [y/N]").
275
+ - **No signal → skip** (most projects have no domain pack; that's fine).
276
+
277
+ Domain packs are **additive context, never a hard gate**. Multiple domains can co-apply (rare). A brief override wins (if the user says "it's a fintech dashboard", honor it).
278
+
279
+ Record the result in DESIGN-CONTEXT.md as a `<domain>` line (e.g. `<domain>finance</domain>`, or omit when none). Do not inline the pack content here — the executor + `design-auditor` read `reference/domains/<domain>-patterns.md` directly.
280
+
281
+ Proceed to Step 1 regardless of outcome.
282
+
253
283
  ## Step 1 — Auto-Detect Design System State
254
284
 
255
285
  Run all detection commands before asking any questions. Record what is found — this pre-populates the interview and reduces questions to only genuine unknowns.
@@ -368,6 +368,12 @@ When `<project_type>` is a **no-DOM target** — `native-ios`/`native-android`/`
368
368
 
369
369
  ---
370
370
 
371
+ ## Phase 4E — Motion Verification (when Lottie/Rive exports present)
372
+
373
+ **Gate + delegate:** when a Lottie (`*.json` with the `v`/`fr`/`layers` signature, or a `lottie-web` dep) or Rive (`*.riv`, or `@rive-app`) export is found, **delegate to `agents/motion-verifier.md`** — it runs the pure `scripts/lib/motion/validate-motion.cjs` (Lottie MO-* rules + perf budget; `.riv` size + `RIVE` header; Rive state-machine reachability when the runtime is present) and folds a `## Motion verification` block into DESIGN-VERIFICATION.md. None present → `motion verification: skipped.` **WARN, never block (D-02)** — motion findings are warnings unless a `must_have` requires them. Probe + degrade: `connections/lottie.md` / `connections/rive.md`.
374
+
375
+ ---
376
+
371
377
  ## Phase 4C — paper.design Canvas Screenshots (when paper-design: available)
372
378
 
373
379
  **Gate:** Skip this entire Phase 4C block if `paper-design` is `not_configured` or `unavailable` in STATE.md `<connections>`. Print: `paper.design canvas screenshots: skipped.`
@@ -0,0 +1,88 @@
1
+ ---
2
+ name: motion-verifier
3
+ description: Verify-time check for Lottie + Rive motion exports. Discovers exported animations, runs the pure scripts/lib/motion/validate-motion.cjs on Lottie (frame-rate / duration / embedded-asset / perf-budget), checks size + the RIVE magic header on .riv, and surfaces state-machine concerns (unreachable states, no-exit loops) when the Rive runtime is present. WARNs — never blocks (motion is creative, not contractually broken). Degrades to the static validator + a manual-review advisory when no player/runtime is configured.
4
+ tools: Read, Bash, Grep, Glob
5
+ color: green
6
+ default-tier: sonnet
7
+ tier-rationale: "Mechanical validation of exported animation artifacts via a deterministic pure helper + file checks; no design judgment — sonnet-tier, not an Opus plan."
8
+ size_budget: M
9
+ size_budget_rationale: "Honest tier sized to the ~130-line body (M cap 300). The agent states the discover → validate-Lottie → check-Rive → perf-budget → WARN flow and DELEGATES per-tool probe + degrade detail to connections/lottie.md + connections/rive.md and the rule semantics to scripts/lib/motion/validate-motion.cjs (the print-renderer→validate-print-css precedent)."
10
+ parallel-safe: true
11
+ typical-duration-seconds: 30
12
+ reads-only: true
13
+ writes: []
14
+ ---
15
+
16
+ @reference/shared-preamble.md
17
+
18
+ # motion-verifier
19
+
20
+ ## Role
21
+
22
+ At verify time, open the motion **exports** a project ships (Lottie JSON, Rive `.riv`) and surface motion-quality + performance concerns the 7-pillar code audit cannot see — frame-rate sanity, duration, embedded-asset bloat, bundle budget, and (for Rive) state-machine reachability. Motion exists as a *principle* (Phase 18); this agent makes it a *verifiable artifact*.
23
+
24
+ **Hard rule (D-02): WARN, never block.** Every finding is a warning in `DESIGN-VERIFICATION.md`, never a `<blocker>` — motion is creative, not contractually broken. The single exception: a `must_have` that *explicitly* requires motion verification (then a failed check escalates to that must_have).
25
+
26
+ ## When invoked
27
+
28
+ The verify stage (`agents/design-verifier.md`) delegates here **only when** Lottie/Rive exports are present (per `connections/lottie.md` / `connections/rive.md` probes). No exports → this agent does not run. The probes + the three-value `<connections>` schema live in those two connection specs — do not duplicate them here.
29
+
30
+ ## Step 1 — Discover motion exports
31
+
32
+ ```bash
33
+ # Lottie: JSON files carrying the Lottie signature (top-level v / fr / layers), or a lottie dep
34
+ find . -name "*.json" -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null | head -50
35
+ grep -rEl '"(lottie-web|@lottiefiles/|lottie-react)"' package.json 2>/dev/null
36
+ # Rive: binary .riv exports, or an @rive-app dep
37
+ find . -name "*.riv" -not -path "*/node_modules/*" 2>/dev/null | head -50
38
+ grep -rE '@rive-app|rive-react' package.json 2>/dev/null
39
+ ```
40
+
41
+ For each candidate `*.json`, confirm the Lottie signature before validating (a `package.json` is not a Lottie). The validator does this check itself (returns `MO-PARSE` for non-Lottie), so it is safe to pass any JSON.
42
+
43
+ ## Step 2 — Validate Lottie (deterministic, always available)
44
+
45
+ Run the **pure** validator `scripts/lib/motion/validate-motion.cjs` — zero dependencies, no player, no network:
46
+
47
+ ```bash
48
+ node -e "const {validateLottie}=require('./scripts/lib/motion/validate-motion.cjs');const fs=require('fs');const f=process.argv[1];const bytes=fs.statSync(f).size;const r=validateLottie(fs.readFileSync(f,'utf8'),{bytes,budgetBytes:BUDGET});console.log(JSON.stringify(r))" path/to/animation.json
49
+ ```
50
+
51
+ Map each returned warning to a verify finding (all WARN):
52
+
53
+ | Rule | Meaning |
54
+ |------|---------|
55
+ | `MO-PARSE` | not valid JSON / not a Lottie document |
56
+ | `MO-FR` | frame rate outside the sane 1–120 range |
57
+ | `MO-DUR` | non-positive duration (`op <= ip`) |
58
+ | `MO-LAYERS` | very high layer count — review runtime cost |
59
+ | `MO-IMG` | embedded raster asset(s) — prefer external/optimized images |
60
+ | `MO-BUDGET` | bundle exceeds the KB cap (see Step 4) |
61
+
62
+ The validator also returns `info` (fr, layers, durationSeconds, embeddedAssets) — narrate it in the report.
63
+
64
+ ## Step 3 — Check Rive (`.riv` is binary — be honest, D-04)
65
+
66
+ Pure JS cannot parse the `.riv` state-machine graph. The static floor is:
67
+
68
+ - **`riveHeader(bytes)`** — confirm the file begins with the ASCII magic `RIVE` (a corrupt/mislabelled export fails this).
69
+ - **`motionBudget(bytes, budgetBytes)`** — the same perf-budget check as Lottie (Step 4).
70
+
71
+ **Deep state-machine validation** — no unreachable states, no infinite loops without an exit transition — requires the **Rive runtime** (`@rive-app/canvas` / the Rive CLI), which is opt-in / maintainer-supplied (per `connections/rive.md`). When it is present, enumerate the file's state machines + inputs and flag unreachable states / no-exit loops as WARN. When it is absent, emit a **manual-review advisory**: "Rive runtime not configured — open the `.riv` in the Rive editor/runtime and confirm every state is reachable and every loop has an exit." Never block on its absence.
72
+
73
+ ## Step 4 — Performance budget
74
+
75
+ Read the cap from `.design/config.json` → `motion_budget_kb` (fallback **200 KB**, `DEFAULT_BUDGET_BYTES`). Pass `budgetBytes = motion_budget_kb * 1024` to the validator / `motionBudget`. An over-budget export is an `MO-BUDGET` warning, not a blocker.
76
+
77
+ ## Degrade behavior
78
+
79
+ - No Lottie player / no Rive runtime → the pure `validate-motion.cjs` (Lottie) + size/header (Rive) is the deterministic floor; then a code-only review of how the animation is loaded/triggered. Never blocks (D-03).
80
+ - No motion exports at all → this agent is not invoked.
81
+
82
+ ## Record
83
+
84
+ Emit a `## Motion verification` section for `DESIGN-VERIFICATION.md`: per-file findings (file → rules → detail), the `info` narration, the budget used, and the Rive advisory when applicable. Tag each finding **WARN**. Close with the completion marker:
85
+
86
+ ```
87
+ ## MOTION VERIFICATION COMPLETE
88
+ ```
@@ -2,7 +2,7 @@
2
2
 
3
3
  This directory contains connection specifications for external tools and MCPs that the get-design-done pipeline integrates with. Each connection has its own spec file. This file is the index.
4
4
 
5
- **Getting started:** run `/gdd:connections` for the interactive onboarding wizard — it probes all 19 connections, recommends setup based on your project type, and walks you through installing each one (auto-run for reversible MCP adds, copy-command for everything else). You can also run `/gdd:connections list` for a read-only status check or `/gdd:connections <name>` to jump to a single connection's setup.
5
+ **Getting started:** run `/gdd:connections` for the interactive onboarding wizard — it probes all 21 connections, recommends setup based on your project type, and walks you through installing each one (auto-run for reversible MCP adds, copy-command for everything else). You can also run `/gdd:connections list` for a read-only status check or `/gdd:connections <name>` to jump to a single connection's setup.
6
6
 
7
7
  ---
8
8
 
@@ -35,6 +35,8 @@ This directory contains connection specifications for external tools and MCPs th
35
35
  | Linear | Active | [`connections/linear.md`](connections/linear.md) | **Ticket-sync** (Team Surfaces) — `mcp__linear__*` (ToolSearch probe); bidirectional cycle↔issue; redact + `GDD_DISABLE_LINEAR` kill-switch; degrade-to-noop |
36
36
  | Jira | Active | [`connections/jira.md`](connections/jira.md) | **Ticket-sync** (Team Surfaces) — Atlassian MCP `mcp__atlassian__*` (ToolSearch probe); parity with Linear; `GDD_DISABLE_JIRA` kill-switch; degrade-to-noop |
37
37
  | Notion | Active | [`connections/notion.md`](connections/notion.md) | **Export** write-path (not a pipeline stage) — `mcp__notion__*` (ToolSearch probe); `/gdd:export --format notion`; redact + `GDD_DISABLE_NOTION` kill-switch; degrade-to-HTML |
38
+ | Lottie | Active | [`connections/lottie.md`](connections/lottie.md) | **Optional** motion verify (Lottie JSON); static floor = `validate-motion.cjs` (MO-* warnings + perf budget); player opt-in; WARN-never-block, degrade-to-static/code-only (36.2, D-02/D-03) |
39
+ | Rive | Active | [`connections/rive.md`](connections/rive.md) | **Optional** motion verify (Rive `.riv`); size + RIVE-header floor; deep state-machine graph via opt-in Rive runtime, else manual-review advisory; WARN-never-block (36.2, D-02/D-04) |
38
40
 
39
41
  ---
40
42
 
@@ -62,6 +64,8 @@ Each cell describes what the connection contributes at that pipeline stage, or `
62
64
  | Android Emulator | — | — | — | native Android code-gen target (compose-executor / emitCompose) | rendered Compose screenshot when emulator available, else degrade to code-only structural audit (D-03) | — | — | — | — |
63
65
  | Litmus | — | — | — | email render-test target (email-executor) | cross-client rendered evidence when Litmus available, else degrade to the static email-HTML validator / code-only (D-03) | — | — | — | — |
64
66
  | Print-Renderer | — | — | — | print render-test target (pdf-executor) | rendered PDF/page evidence when the print-render is available, else degrade to the static print-CSS validator / code-only (D-03) | — | — | — | — |
67
+ | Lottie | — | — | — | — | Lottie-export motion check: `validate-motion.cjs` (MO-FR/DUR/IMG/BUDGET) when present, WARN-never-block (D-02) | — | — | — | — |
68
+ | Rive | — | — | — | — | Rive-export motion check: size + RIVE-header floor; state-machine graph via opt-in runtime, else manual-review advisory; WARN (D-02/D-04) | — | — | — | — |
65
69
  | Lazyweb | — | reference search via `lazyweb_search` (**Tier 1 — free, tried first**; D-01); complements refero/pinterest | — | — | — | — | — | — | — |
66
70
  | Mobbin | — | reference search via mobbin tools (**Tier 2 — paid, mobile/flow-level**; D-01); complements refero/lazyweb | — | — | — | — | — | — | — |
67
71
  | Slack | — | — | — | — | — | — | — | verify-fail/audit-pass/ship → Slack webhook (routed, redacted, degrade-to-noop; D-04/D-05) | — |
@@ -0,0 +1,126 @@
1
+ # Lottie — Connection Specification
2
+
3
+ This file is the connection specification for the Lottie motion-export check within the get-design-done pipeline. It lives in `connections/` alongside the other connection specs (the closest analog is `connections/print-renderer.md`, the verify-stage rendered-proof connection for the `print` project type). See the connection index for the full connection capability matrix (the Lottie row is added at the 36.2 Wave-B wiring plan).
4
+
5
+ ---
6
+
7
+ Lottie is a JSON animation format (Bodymovin / lottie-web). This connection is the **verify stage's motion check for Lottie exports** — the animation analog of the print-render. Its pipeline role: after a design exports a Lottie `*.json` bundle, the verify stage runs the **pure static validator** to surface structural and perf problems the JSON carries (bad frame rate, zero-length duration, layer/asset bloat, oversized bundle), and — **when a live player is configured** — renders actual playback to catch what the JSON alone cannot show. It narrates the result in plain English in `DESIGN-VERIFICATION.md`. It is consumed at verify time by the `motion-verifier` agent.
8
+
9
+ **Key relationship to the static validator:** the live Lottie player is the *rendered* complement to the *static* validator `scripts/lib/motion/validate-motion.cjs`. The static validator deterministically parses the Lottie JSON (zero dependencies) and checks constraint **classes** via `validateLottie(json, {bytes, budgetBytes})` — returning `{ok, warnings:[{rule,detail}], info}` with rules `MO-PARSE` (not valid JSON / not a Lottie document) / `MO-FR` (frame rate outside the sane 1-120 range) / `MO-DUR` (non-positive duration, `op <= ip`) / `MO-LAYERS` (layer count high, runtime cost) / `MO-IMG` (embedded raster `data:` assets bloat the bundle) / `MO-BUDGET` (bundle exceeds the KB cap, shared with `motionBudget`). A live player checks the **rendered output** — what actually plays. The player is **optional** — its absence is a quality reduction, not a blocking error (D-02).
10
+
11
+ ---
12
+
13
+ ## Setup
14
+
15
+ **Prerequisites:**
16
+
17
+ - **STATIC FLOOR — the pure validator (always available):** `scripts/lib/motion/validate-motion.cjs` is pure and dependency-free (D-01) — zero `require`, no Lottie runtime, deterministic (hermetic tests). It needs **no player and no network**. It parses the Lottie JSON and emits the `MO-*` warnings. This is the floor and it is always present.
18
+ - **OPTIONAL — a live Lottie player (opt-in, maintainer-supplied):** to render *actual playback*, a player is needed — `lottie-web` driven in headless Chrome, or `@lottiefiles/lottie-player`. This is opt-in; like the print-render, prefer a no-external-package path where possible, and where a player IS needed it is supplied by the maintainer in the verify stage — never installed by the pipeline.
19
+
20
+ Per **D-01** there is **NO bundled `lottie-web` / `@lottiefiles/*` dependency** and **no live playback in the default `npm test`** — the pure validator carries the whole hermetic test surface. A live player is an optional, opt-in enhancement the maintainer wires up in the verify stage when one is present.
21
+
22
+ **Verification:**
23
+
24
+ ```bash
25
+ node -e "require('./scripts/lib/motion/validate-motion.cjs').validateLottie" 2>/dev/null && echo "static validator OK"
26
+ ```
27
+
28
+ ---
29
+
30
+ ## Why the Lottie check is useful
31
+
32
+ Motion breakage is largely invisible to code review, and rendered breakage is invisible to the static validator. A Lottie bundle can be well-formed JSON and still ship problems: a frame rate of `0` or `240` (the `MO-FR` band is 1-120), a zero-length or reversed timeline (`op <= ip`, `MO-DUR`), hundreds of layers that tank runtime on low-end devices (`MO-LAYERS`), or a 4MB bundle because a designer baked full-resolution PNGs into the JSON as inline `data:` URIs (`MO-IMG` + `MO-BUDGET`). The static validator catches all of these deterministically, from the JSON alone, with no player.
33
+
34
+ The static validator checks constraint **classes**; it cannot play the animation. A live player renders the **actual** timeline, so playback-only defects — an expression that throws at runtime, a mask that clips wrong, a marker that never fires — surface as observable output rather than a broken animation shipped to production.
35
+
36
+ ---
37
+
38
+ ## When to use the Lottie check
39
+
40
+ **Verify stage:** After a design exports a Lottie `*.json`, run the static validator `validateLottie(json, {bytes, budgetBytes})` — always — to surface the `MO-*` warnings, and run a live player **when available** to capture rendered playback. The verify stage narrates the delta and notes it in `DESIGN-VERIFICATION.md`.
41
+
42
+ The Lottie check is **not** used at generation time. Exporting or hand-authoring a Lottie JSON needs no player, no `lottie-web` runtime, and no network — the pure validator runs anywhere Node runs.
43
+
44
+ ---
45
+
46
+ ## Availability Probe
47
+
48
+ The Lottie connection is discovered by a **file-based** probe (NOT ToolSearch): look for Lottie export artifacts and/or a player dependency.
49
+
50
+ **Step LO1 — Lottie artifact / player presence:**
51
+
52
+ ```bash
53
+ # (a) any JSON files at all?
54
+ find . -name "*.json" -not -path "*/node_modules/*" | head
55
+
56
+ # (b) does one carry the Lottie signature — top-level v, fr, and a layers[] array?
57
+ node -e 'const j=require(process.argv[1]); process.exit(j&&typeof j==="object"&&"v" in j&&"fr" in j&&Array.isArray(j.layers)?0:1)' ./path/to/export.json && echo "Lottie export found"
58
+
59
+ # (c) is a player declared as a dependency?
60
+ grep -E '"(lottie-web|@lottiefiles/[^"]+|lottie-react)"' package.json
61
+ ```
62
+
63
+ - A Lottie export (signature match) OR a player dependency is found → proceed to Step LO2
64
+ - Neither a Lottie artifact nor a player → `lottie: not_configured` (skip all Lottie steps; nothing to verify)
65
+
66
+ **Step LO2 — player capability check:**
67
+
68
+ - A Lottie export is present (or a player is declared) and verification can proceed → `lottie: available` (the static validator alone is enough to be `available` — it is the floor)
69
+ - A player is declared but errors when invoked (missing headless Chrome, broken `@lottiefiles/*` install) → `lottie: unavailable` (fall back to the static validator)
70
+
71
+ **Write the Lottie status to `.design/STATE.md` `<connections>` immediately after probing** — the three-value schema the other connections use (`available` / `unavailable` / `not_configured`).
72
+
73
+ ---
74
+
75
+ ## Fallback Behavior
76
+
77
+ When the Lottie player is `not_configured` or `unavailable`, the verify stage degrades gracefully — no error is raised.
78
+
79
+ **verify stage (the `motion-verifier` agent):**
80
+
81
+ - `lottie: unavailable` → skip rendered playback; **degrade** to the pure validator `scripts/lib/motion/validate-motion.cjs` (the `MO-PARSE/FR/DUR/LAYERS/IMG/BUDGET` warnings), then a **code-only** review of the Lottie JSON structure; note in `DESIGN-VERIFICATION.md`: "Lottie playback skipped — no live player; verified via the static motion validator + a code-only review."
82
+ - `lottie: not_configured` → same as unavailable; note: "Lottie playback skipped — no player configured; verified via the static validator + a code-only review. (A live player — lottie-web in headless Chrome / @lottiefiles/lottie-player — is an opt-in enhancement.)"
83
+
84
+ **Graceful degradation required:** the pipeline must continue when the player is unavailable. Missing rendered-playback data is a **quality reduction, not a blocking error** (D-02 — motion is creative, not contractually broken; the player is an enhancement, never hard-required). The pure validator is always available and is the deterministic floor; the live player is the rendered ceiling on top of it.
85
+
86
+ **WARN, never block (D-02):** every motion finding — every `MO-*` warning and every playback observation — is recorded as a **warning** in `DESIGN-VERIFICATION.md`, **never** a `<blocker>`. The motion-verifier does NOT append a blocker for a missing Lottie connection or for any `MO-*` warning. The single exception: if a `must_have` explicitly requires motion verification, THEN — and only then — an unmet motion requirement may escalate to a blocker.
87
+
88
+ ---
89
+
90
+ ## STATE.md Integration
91
+
92
+ Every stage that probes the Lottie connection writes the result to `.design/STATE.md` under the `<connections>` section:
93
+
94
+ ```xml
95
+ <connections>
96
+ figma: available
97
+ preview: available
98
+ lottie: not_configured
99
+ </connections>
100
+ ```
101
+
102
+ **Status values:**
103
+
104
+ | Value | Meaning |
105
+ |---|---|
106
+ | `available` | A Lottie export is present (or a player is declared) and verification can proceed — the static validator alone satisfies this |
107
+ | `unavailable` | A player is declared but the playback call errored (no headless Chrome, broken `@lottiefiles/*` install) — degrade to the static validator |
108
+ | `not_configured` | No Lottie artifacts and no player dependency — there is nothing to verify |
109
+
110
+ The verify stage re-probes at stage entry (exports and player availability can change between sessions). If STATE.md already carries a `lottie:` status from a prior stage in the SAME session, that status can be trusted for the rest of that session.
111
+
112
+ ---
113
+
114
+ ## Caveats and Pitfalls
115
+
116
+ 1. **The live player is an enhancement, not a requirement.** Its absence degrades to the static validator + a code-only review and never blocks the pipeline (D-02). Do not gate a motion export on rendered playback.
117
+
118
+ 2. **Every motion finding is a warning.** Motion is creative, not contractually broken (D-02). A `MO-FR` / `MO-LAYERS` / `MO-IMG` warning informs the designer; it does not fail the build. Only an explicit `must_have` for motion verification can escalate a finding to a blocker.
119
+
120
+ 3. **The budget is a shared, configurable cap.** `MO-BUDGET` fires only when the caller passes `opts.bytes` (the on-disk size); the cap is `opts.budgetBytes` or the 200 KB `DEFAULT_BUDGET_BYTES` fallback (D-05, when config carries no `motion_budget_kb`). `motionBudget(bytes, budgetBytes)` is shared by the Lottie and Rive paths — keep the unit math (KB = bytes / 1024) consistent.
121
+
122
+ 4. **The signature gate is strict.** `validateLottie` only proceeds when the JSON has top-level `v`, `fr`, AND a `layers[]` array; anything else returns a single `MO-PARSE` warning ("not a Lottie document"). The file probe must use the same three-key signature so the connection does not misfire on unrelated `*.json` files.
123
+
124
+ 5. **No bundled player dependency.** Do NOT add `lottie-web` / `@lottiefiles/*` / `lottie-react` to `package.json` to make this connection work — the player is opt-in and the maintainer supplies it. The default `npm test` stays hermetic and runs only the pure validator (D-01).
125
+
126
+ 6. **Do NOT edit the connection index here.** The Lottie connection's Active-Connections entry and Capability-Matrix row are added by the 36.2 Wave-B wiring plan, not by this spec (the disjointness pattern `print-renderer.md` uses).
@@ -0,0 +1,122 @@
1
+ # Rive — Connection Specification
2
+
3
+ This file is the connection specification for the Rive motion-export check within the get-design-done pipeline. It lives in `connections/` alongside the other connection specs (the closest analog is [`connections/print-renderer.md`](print-renderer.md), the verify-stage RENDERED proof for the `print` project type, and its sibling `connections/lottie.md` covers the JSON-vector motion format). See the connection index for the full connection capability matrix (the Rive row is added at the 36.2 Wave-B wiring plan).
4
+
5
+ ---
6
+
7
+ Rive is the **verify stage's motion check for Rive exports** — interactive animations Rive ships as **binary `.riv` files** that bundle **state machines** (states, transitions, inputs) rather than a linear timeline. Its pipeline role: after a design surface produces a `.riv` artifact, the verify stage uses this connection — **when the Rive runtime is available** — to enumerate the file's state machines and surface graph hazards the static floor cannot see (unreachable states, loops with no exit transition), and narrates the result in plain English. It is consumed at verify time by the `motion-verifier` agent.
8
+
9
+ **Key relationship to the static floor:** `.riv` is a **binary** format, so **pure JavaScript cannot parse the state-machine graph** without the Rive runtime. The static floor in `scripts/lib/motion/validate-motion.cjs` is therefore deliberately narrow — it provides [`riveHeader(headerBytes)`](../scripts/lib/motion/validate-motion.cjs) (a cheap magic-byte sanity check: every `.riv` file begins with the ASCII magic `RIVE`) and `motionBudget(bytes, budgetBytes)` (the shared KB-cap perf-budget check that also backs the Lottie path, rule `MO-BUDGET`). The **deep state-machine validation** the ROADMAP wants — no unreachable states, every loop has an exit transition — lives *above* that floor and needs the Rive runtime. This connection is the **runtime ceiling** on top of the deterministic header+budget floor; its absence is a quality reduction, not a blocking error (D-04).
10
+
11
+ ---
12
+
13
+ ## Setup
14
+
15
+ **Prerequisites:**
16
+
17
+ - **PRIMARY — the Rive runtime:** `@rive-app/canvas`, `@rive-app/react-canvas`, or the Rive CLI. When present, the runtime loads the `.riv` file, enumerates its state machines + inputs, and lets the agent walk the transition graph to check reachability and exit conditions. No bundled dependency is required to *probe*; the runtime is opt-in — prefer a built-in / no-external-package path where possible, and where the runtime IS needed it is maintainer-supplied (never installed by the pipeline).
18
+ - **ALTERNATIVE — header + budget floor only:** where no Rive runtime is available, `scripts/lib/motion/validate-motion.cjs` still runs `riveHeader` (magic-byte sanity) and `motionBudget` (the KB cap) on the raw bytes. This is the documented pure-JS path and needs no dependency at all.
19
+
20
+ Per **D-01** there is **NO bundled `@rive-app/*` (or `rive-react` / Rive CLI) dependency** and **no live state-machine walk in the default `npm test`** — the deep graph check is an optional, opt-in enhancement the maintainer wires up in the verify stage when the Rive runtime is present. The header+budget floor stays hermetic and dependency-free (D-06).
21
+
22
+ **Verification:**
23
+
24
+ ```bash
25
+ node -e "require('@rive-app/canvas')" 2>/dev/null && echo "rive-runtime ok" || command -v rive 2>/dev/null
26
+ ```
27
+
28
+ ---
29
+
30
+ ## Why Rive is useful
31
+
32
+ State-machine breakage is invisible to both code review and the binary header floor. A `.riv` file can pass `riveHeader` (correct magic), sit comfortably under the `motionBudget` KB cap, and still ship broken: a state nobody can transition into (an **unreachable state** — dead art that never plays), or a loop of transitions with **no exit condition** (the machine spins forever and the input that should release it was never wired). Neither hazard is a malformed file, so a magic-byte + size check cannot catch them — they are properties of the *transition graph*, and the graph is locked inside the binary.
33
+
34
+ The header floor checks that the bytes are a plausible `.riv` and fit the budget; it cannot read the graph. With the Rive runtime present, this connection loads the actual file, enumerates state machines and inputs, and walks transitions so unreachable states and exit-less loops surface as a verify-time warning rather than a frozen or never-firing animation in production.
35
+
36
+ ---
37
+
38
+ ## When to use Rive
39
+
40
+ **Verify stage:** After a design surface produces a `.riv` artifact, run this connection — when the Rive runtime is available — to enumerate state machines + inputs and check that every state is reachable and every loop has an exit transition. The verify stage narrates the delta and notes it in `DESIGN-VERIFICATION.md`.
41
+
42
+ This connection is **not** used at generation time. Producing or hand-editing a `.riv` needs no runtime from the pipeline, and the header+budget floor never gates generation — generation stays runtime-free (D-01/D-06). The deep graph walk is strictly a verify-time enhancement.
43
+
44
+ ---
45
+
46
+ ## Availability Probe
47
+
48
+ Rive is discovered by a **file-based** check (NOT ToolSearch): is there a `.riv` artifact to verify, and/or is the Rive runtime installed to verify it with?
49
+
50
+ **Step RV1 — Rive artifact / runtime presence:**
51
+
52
+ ```bash
53
+ find . -name "*.riv" -not -path "*/node_modules/*" 2>/dev/null | head -1
54
+ grep -qE '"(@rive-app/[a-z-]+|rive-react)"' package.json 2>/dev/null && echo "rive-dep" || true
55
+ ```
56
+
57
+ - A `.riv` file is found OR a `@rive-app/*` / `rive-react` dependency is declared → proceed to Step RV2
58
+ - Neither a `.riv` artifact nor a Rive dependency → `rive: not_configured` (skip all Rive steps)
59
+
60
+ **Step RV2 — runtime capability check:**
61
+
62
+ ```bash
63
+ node -e "require('@rive-app/canvas')" 2>/dev/null && echo "runtime ok" || command -v rive 2>/dev/null
64
+ ```
65
+
66
+ - The Rive runtime (`@rive-app/*`) or the Rive CLI loads and can enumerate state machines → `rive: available`
67
+ - A runtime is present but errors on load / cannot read the file (version mismatch, corrupt `.riv`, sandbox) → `rive: unavailable`
68
+ - A `.riv` exists but no runtime at all → `rive: available` for the **floor only** (header + budget run; the deep graph walk degrades to the manual-review advisory below)
69
+
70
+ **Write the Rive status to `.design/STATE.md` `<connections>` immediately after probing** — the three-value schema the other connections use (`available` / `unavailable` / `not_configured`).
71
+
72
+ ---
73
+
74
+ ## Fallback Behavior
75
+
76
+ When Rive is `not_configured`, or `unavailable`, or a `.riv` exists with no runtime, the verify stage degrades gracefully — no error is raised.
77
+
78
+ **verify stage (`motion-verifier` agent):**
79
+
80
+ - **No runtime (`.riv` present, runtime absent)** → skip the state-machine walk; **degrade** to the static floor in `scripts/lib/motion/validate-motion.cjs` — `riveHeader` (magic-byte sanity) + `motionBudget` (the KB cap) — then emit a documented **manual-review advisory**; note in `DESIGN-VERIFICATION.md`: "Rive state-machine check skipped — no Rive runtime; verified `.riv` header + size budget only. Manual review: open the file in the Rive editor / runtime and confirm every state is reachable and every loop has an exit transition."
81
+ - `rive: unavailable` (runtime present but errored) → same degrade to header + budget + the manual-review advisory; note: "Rive runtime present but failed to load the file — verified header + budget only; confirm reachability and loop-exit manually in the Rive editor."
82
+ - `rive: not_configured` (no `.riv`, no dependency) → skip the connection entirely; note: "No Rive artifacts — Rive motion check not applicable."
83
+
84
+ **Graceful degradation required:** the pipeline must continue when the Rive runtime is unavailable. Missing state-machine data is a **quality reduction, not a blocking error** (D-04 — the deep graph walk is an enhancement, never hard-required, mirroring the print-renderer / Lottie connections). The header+budget floor is always available and is the deterministic floor; the runtime walk is the ceiling on top of it. The verify stage does **not** append a `<blocker>` for a missing Rive runtime. If a `must_have` explicitly requires verified state-machine reachability, THEN append a blocker.
85
+
86
+ ---
87
+
88
+ ## STATE.md Integration
89
+
90
+ Every stage that probes Rive writes the result to `.design/STATE.md` under the `<connections>` section:
91
+
92
+ ```xml
93
+ <connections>
94
+ figma: available
95
+ preview: available
96
+ rive: not_configured
97
+ </connections>
98
+ ```
99
+
100
+ **Status values:**
101
+
102
+ | Value | Meaning |
103
+ |---|---|
104
+ | `available` | A `.riv` artifact or the Rive runtime is found (runtime → deep walk; floor-only → header + budget) |
105
+ | `unavailable` | A Rive runtime is present but errored loading the file (version mismatch, corrupt `.riv`, sandbox) |
106
+ | `not_configured` | No `.riv` artifacts and no `@rive-app/*` / `rive-react` dependency — Rive is not set up |
107
+
108
+ The verify stage re-probes at stage entry (runtime availability and the presence of `.riv` artifacts can change between sessions). If STATE.md already carries a `rive:` status from a prior stage in the SAME session, that status can be trusted for the rest of that session.
109
+
110
+ ---
111
+
112
+ ## Caveats and Pitfalls
113
+
114
+ 1. **The deep state-machine walk is an enhancement, not a requirement.** Its absence degrades to `riveHeader` + `motionBudget` + a manual-review advisory and never blocks the pipeline (D-04). Do not gate a Rive build on a verified transition graph.
115
+
116
+ 2. **`.riv` is binary — pure JS cannot read the graph (D-04).** `riveHeader` confirms only the `RIVE` magic bytes; it says nothing about states, transitions, or inputs. Reachability and loop-exit checks are *graph* properties locked inside the binary and require the Rive runtime. Never imply the header check validated the state machine — be honest in `DESIGN-VERIFICATION.md` about which tier ran.
117
+
118
+ 3. **WARN, never block (D-02).** Unreachable states, exit-less loops, and over-budget bundles are **warnings**, never a `<blocker>` — motion is creative, not contractually broken. The `motion-verifier` records them as advisories; only a `must_have` requiring verified reachability escalates one to a blocker.
119
+
120
+ 4. **No bundled runtime.** Do NOT add `@rive-app/canvas`, `@rive-app/react-canvas`, `rive-react`, or the Rive CLI to `package.json` to make this connection work — the runtime is opt-in and the maintainer supplies it. The default `npm test` stays hermetic and runtime-free (D-01/D-06).
121
+
122
+ 5. **Do NOT edit the connection index here.** Rive's Active-Connections row and Capability-Matrix entry are added by the 36.2 Wave-B wiring plan, not by this spec.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@hegemonart/get-design-done",
3
- "version": "1.35.5",
3
+ "version": "1.36.2",
4
4
  "description": "A design-quality pipeline for AI coding agents: brief, plan, implement, and verify UI work against your design system.",
5
5
  "author": "Hegemon",
6
6
  "homepage": "https://github.com/hegemonart/get-design-done",