bvandeusenandClaude Opus 5
7b0984579d
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 8s
CI & Build / integration (push) Successful in 22s
CI & Build / TypeScript typecheck (push) Successful in 32s
CI & Build / Python tests (push) Successful in 53s
CI & Build / Build & push image (push) Successful in 44s
The record view listed values as text and drew a swatch only where the value looked like a colour. Two problems, one cause: a derived value such as color-mix(in srgb, var(--accent) 15%, transparent) was drawn by resolving --accent against THIS app, so previewing another project's system showed Scribe's palette. It looked right, which is why nobody noticed. TokenPreview draws the system from its own record. Every value is resolved on an offscreen probe carrying only that system's declarations, so a system whose app this browser has never loaded renders in its own colours — which is the difference between a tool and a mirror. Specimens are chosen by value SHAPE, never by name: colours become swatches, lengths become rules drawn to scale, gradients and shadows get a surface, font stacks are set in themselves. Nothing matches --fs-space-* or any other convention, because the convention belongs to the install (rule #115) — a system that calls its spacing --gap-N gets the same treatment. Translucent values sit on a checkerboard, or a 15% tint over a solid card reads as opaque and shows the wrong colour. Modes come from the system, not from the app: a system declaring base and light offers both, independent of the theme this page is in. The provenance list keeps its swatches only for self-contained colours — the ones needing no resolution, which it can therefore draw honestly. Everything with a var() inside is left to the preview built for it. Step 2 of milestone #274. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs