Fair question — it came up twice this week, so here’s the full audit. Every prototype I build starts from a copy of the live design tokens, and that copy is currently 19 days old. Since then you’ve shipped three visual changes I haven’t absorbed. Two more differences are sandbox rules that apply to any offline prototype, and two are proposals I made on purpose. Everything is itemized below, and the stale part fixes itself with the button up top.
Not every difference is the same kind of difference — and only one kind is actually a bug.
I read colors, radii, and spacing straight from the codebase when I build — not from memory. But the site ships every week, and a prototype keeps the tokens it was born with. Nineteen days is three releases of quiet drift.
Fixable — that’s the button up topEach one is a single offline file: no webfonts, no production assets, no network at all. So the system font stack stands in for the licensed one, and a plain wordmark stands in for the real logo — close on purpose, identical never.
By design — flagged in every hand-offA prototype exists to test a change. Where I’m proposing something — a bigger first-run button, a guided empty state — it should disagree with production. Those get a clear “proposal” label so nobody mistakes them for the current spec.
On purpose — labeled below~/dev/checkout-service
#4C7DF0 · 6px inputs · 32px buttons · production mark & self-hosted UI font~/dev/checkout-service
#5B8DEF · 8px inputs · 36px buttons (proposal) · wordmark & system fonts (sandbox)Forty-two tokens and assets compared. Seven differ — each row says why, and what happens when I sync.
Why it drifted: the accent was retuned on Jun 24 to pass AA contrast on dark surfaces. My snapshot predates that release, so every primary button I drew since is one shade off.
On sync: adopts #4C7DF0 automatically — no redesign needed.
Why it drifted: the Jun 30 elevation pass flattened raised surfaces by one step. Subtle in isolation — but it’s exactly why my cards read “lighter” than production.
On sync: cards drop to the live surface value.
Why it drifted: the settings redesign tightened form density and squared inputs slightly. My snapshot kept the older, rounder corners.
On sync: inputs sharpen to 6px to match.
Why it differs: prototypes are single offline files — no network requests, no font license baked in. The system stack is the closest metrics match, so letterforms will always sit a hair differently.
On sync: stays as-is. Noted in the hand-off so nobody chases a font bug.
Why it differs: I never redraw the real mark — a near-copy is worse than an honest stand-in. Prototypes carry the text wordmark until the production asset is dropped in.
On sync: stays as-is until an approved asset lands in the prototype pipeline.
Why it differs: deliberate. The onboarding concept argues for bigger first-run targets while a new user finds their footing — this is that argument, drawn.
On sync: untouched. Approve it and it becomes a real token change; pass, and I revert to 32px.
Why it differs: the live empty state is a dead end. The prototype tests a guided “point me at one folder” walkthrough instead — that gap is the prototype doing its job.
On sync: untouched. It’s the thing being decided, not a bug to fix.
Nothing matching that is out of step with the live site — which is the good kind of boring.
Drift is inevitable; stale drift isn’t. Three habits keep the gap honest.
I re-fetch tokens from the codebase the moment a prototype is requested — never from memory, never from last month’s pull.
Each prototype states its snapshot date and lists known gaps — sandbox stand-ins and open proposals — so reviewers know what’s signal and what’s scaffolding.
If live tokens change while a prototype is still in review, I flag the delta in the thread instead of letting it age quietly.
Try it now. Pull today’s tokens and watch the three stale values resolve in place — the prototype pane and the drift log update live.