--- title: "Design system memory should be editable." description: "We shipped fabricated design-system preview data, deleted it in a 114-line commit, and wrote a gate that forbids those exact strings. What replaced it: artifacts with OK and Fix review states that the next run actually inherits." publishDate: 2026-06-05T00:00:00.000Z author: Sarvesh Chidambaram tags: ["design-system", "memory", "figma", "product-design"] canonical: https://memoire.cv/blog/design-system-memory --- ## We shipped fake memory first The design-system pane in Studio used to look great in screenshots. Token specs like "H1 / 32 / 700". A tidy list of button variants. Section after section of plausible system knowledge, laid out exactly how real extraction output should look. None of it was real. It was preview data typed in by hand so the surface would not look dead while the actual pipeline was being wired up. No project had produced it. No agent had ever read it. It was furniture. We deleted all of it in a 114-line change (commit 7232cf3, 2026-05-27), and we added those exact strings to a gate that fails the build if they ever come back. ## How fake memory gets in I know exactly how that data got there, because I put it there. Empty states look dead. You are building a memory product, the extraction pipeline is half finished, and the pane has to demo well this week. So you type in what the output should look like and tell yourself it is temporary. The day before the memory cleanup, the same purge had already hit the run workbench: mock actions deleted, and a script called assert-no-mock-ui.mjs created to enumerate forbidden placeholder strings file by file (commit 05741d3, 2026-05-26). The design-system pane was simply the next surface the gate caught up with. Fabricated memory is a worse lie than fake chrome, though. Memory is the thing agents act on. If a designer sees "H1 / 32 / 700" in the memory pane and the next Codex run generates type to match, an invention has been laundered into a decision. Nobody chose that scale. It only ever existed as set dressing. The rule we landed on: memory is real or it is absent. And the rule is enforced like a lint check, not written down as a value statement. ## The opposite failure: hidden memory Most AI tools fail in the other direction. They treat memory as a private cache: ingest the design system, store embeddings, let the model retrieve fragments later. That memory is at least real. But when it is wrong (a stale spacing scale, a half-extracted component taxonomy, a research summary that is too confident), there is nowhere to fix it. A product designer should not have to edit a vector store to say "this section is wrong." So the surface we shipped is an artifact you can argue with. Every section of a design-system artifact in the workbench carries literal OK and Fix buttons, a review-state select with three values (Unreviewed, Looks good, Needs work), and a summary you can edit inline. Mark a section OK and it stands as trusted context. Mark it Fix and it goes back for rework. Edit the summary and your wording, not the model's, is what persists. A design system is not a set of tokens. It is a chain of decisions. When an agent changes a button, the useful memory is not just the radius value; it is why the team chose it, which states are required, and when the component may break pattern. Decisions drift, so memory needs a correction loop, not just a retrieval index. ## A pane, not a cache In Studio, design-system and memory are first-class workbench panes, registered in the same slash-command table as run, changes, figma, mermaid-board, and research-lab. Memory is not buried behind a settings screen. It sits next to the run view because it is part of the work. Underneath there is one typed workspace store with bidirectional sync hashing. The CLI writes it, Studio renders it, the MCP server exposes it, and the Codex plugin reads it. Four clients, one memory. The token rule you see in the pane is the same record the next agent session loads. The pane also shows memory in use rather than a global junk drawer: workbench context is scoped to the active session (commit c65fd72, 2026-05-26), so what you see is what the current run will inherit. And the lane stays contextual. It appears when there is design context: an artifact exists, a design-system file changed, Figma is connected, or you open /system, /figma, or /board. First launch stays clean. ## The loop that compounds The operating model that survived all of this is short: 1. Ask Codex or Claude to critique, fix, or extend a flow. 2. Capture the design-system artifact the run produces. 3. Edit the title, sections, and summaries where the agent got it wrong. 4. Mark each section OK or Fix. 5. Let the next run inherit only the reviewed memory. Run that loop a few times and the artifact stops being extraction output and starts being the team's actual position on its own system. ## What held up Three lessons, in the order we paid for them. Never fake the memory, even during development. The placeholder outlives your intent, lands in screenshots, and eventually an agent treats it as truth. Delete it and write the gate the same day; ours now forbids the exact strings we once shipped. Make memory editable before you make it big. One reviewable artifact with OK and Fix beats a thousand embedded fragments nobody can correct. Put memory where the work happens. A pane in the workbench gets reviewed. A cache behind an API goes stale quietly. The design system should not live outside the agent workflow. It should be the thing the workflow improves.