Description
(Epic) Build a propagation pipeline so the standalone demo (Tiny Wire.html) consumes the design system from lib/ instead of duplicating it — but with a human review gate between a design-system change and its arrival in the demo. The flow should be: change lib/ → human reviews/approves the design decision → it propagates to the demo. Not an unattended auto-sync.
Why
Issues #2 (stale inline tokens) and #3 (a11y framing drift) are symptoms of one root cause: the demo hand-duplicates lib/ tokens + components, so the two silently diverge and every change must be mirrored by hand. We want the demo to track the system automatically — without removing the deliberate moment where a person signs off on a design change before it ships into the showcase. Removing the human entirely would let unreviewed token changes flow straight to the public demo.
Recommended prerequisite
None — this is the enabler/parent. Implementing it subsumes the recurrence of #2 (the manual reconcile becomes unnecessary once the demo derives from lib/).
Scope
Architecture + build. Likely components: (a) make the demo source tokens/components from lib/ (e.g. @import, or a small build step that injects the current lib/ token block into the demo), (b) a diff/approval gate — show the human the design delta and require explicit approval before propagation, (c) optionally wire this into the FLOWIE/SYNTHIE operator-agent pattern so the gate is an agent step with a human checkpoint. Explicitly NOT in scope: changing the v1.5 token contract; touching downstream prototypes. Decide build-step vs. live-@import as part of this issue.
Touches
- Tiny Wire.html (shared)
- lib/globals.css (shared)
- lib/components.css (shared)
- build/ or scripts/ — new propagation + gate script (shared)
Source
Ad hoc — requested during the v1.5 green→cobalt migration (2026-06-14 session): "figure out an automated way to update the standalone demo with a gate in it… a human reviews the design decisions before it gets flowed to the demo."
Owner
Lindsay (design-system owner / sole coder).
Acceptance criteria
Description
(Epic) Build a propagation pipeline so the standalone demo (
Tiny Wire.html) consumes the design system fromlib/instead of duplicating it — but with a human review gate between a design-system change and its arrival in the demo. The flow should be: changelib/→ human reviews/approves the design decision → it propagates to the demo. Not an unattended auto-sync.Why
Issues #2 (stale inline tokens) and #3 (a11y framing drift) are symptoms of one root cause: the demo hand-duplicates
lib/tokens + components, so the two silently diverge and every change must be mirrored by hand. We want the demo to track the system automatically — without removing the deliberate moment where a person signs off on a design change before it ships into the showcase. Removing the human entirely would let unreviewed token changes flow straight to the public demo.Recommended prerequisite
None — this is the enabler/parent. Implementing it subsumes the recurrence of #2 (the manual reconcile becomes unnecessary once the demo derives from
lib/).Scope
Architecture + build. Likely components: (a) make the demo source tokens/components from
lib/(e.g.@import, or a small build step that injects the currentlib/token block into the demo), (b) a diff/approval gate — show the human the design delta and require explicit approval before propagation, (c) optionally wire this into the FLOWIE/SYNTHIE operator-agent pattern so the gate is an agent step with a human checkpoint. Explicitly NOT in scope: changing the v1.5 token contract; touching downstream prototypes. Decide build-step vs. live-@importas part of this issue.Touches
Source
Ad hoc — requested during the v1.5 green→cobalt migration (2026-06-14 session): "figure out an automated way to update the standalone demo with a gate in it… a human reviews the design decisions before it gets flowed to the demo."
Owner
Lindsay (design-system owner / sole coder).
Acceptance criteria
lib/— no hand-duplicated:rootlib/change and demo propagationlib/token change does NOT reach the demo until explicitly approved@importvs. build-step injection, and why