Overview

This is the method piece. Every other project from that internship was built through this, so it explains how a design intern shipped 2,172 lines into a production codebase in four weeks without the result being slop.

AI design prototypes have a specific failure mode. They look like the design system and are not made of it. Fake components, hardcoded hex, no verification, and a reviewer who approves something that cannot be built. I wanted prototypes that were faithful to production and, more importantly, provably so.

Designer and tool builder. Formalized mid July 2026 after weeks of ad hoc prototyping. Later packaged and shipped to the company's shared agent-tooling repo so teammates could install it.

01 · The loop

A Vite and Vue sandbox wired to the real component library and the real design tokens. Prototypes are built from actual product components, not lookalikes. That single constraint removes most of the ways a prototype can lie.

Then the verify loop, five Node and Playwright tools that run before anything gets shown.

1. 01
   vaultRead the brainDecisions and domain notes from past sessions load first, so settled questions stay settled.
2. 02
   productCapture ground truthThe real product is the baseline. Mockups and inspiration are inputs, never the source of truth.
3. 03
   sandboxBuild with real componentsPrototypes are made of the actual component library, not lookalikes.
4. 04
   verifyVerifyScreenshot, axe-core audit at four breakpoints, visual regression, pixel-measured fidelity against production, token drift.
5. 05
   rubricScore against the rubricA hard gate, not a vibe. Failing sends the work back to the build step.fail → back to 03
6. 06
   designerPresentOnly verified work gets shown. "Looks right" is not a state this loop can emit.
7. 07
   vaultWrite the decision backWhat was decided and why returns to the brain, so the next session starts warmer.

Deterministic screenshots. An accessibility audit, axe-core against WCAG 2.1 AA, at four breakpoints. Visual regression against a baseline. Token drift, checking that the tokens rendering at runtime still match their canonical values. And fidelity, which composites the candidate against a capture of the real product and produces a percentage.

Plus edit-time hooks that flag hardcoded colours and remind me when a screen is missing one of its four states.

02 · Brain

The other half is an Obsidian vault. Decisions in an ADR-lite format, domain knowledge, and session handoffs.

The point is compounding. Without it, every session re-derives the same context and re-litigates settled questions. With it, a decision made in week one is still binding in week four, and the reasoning is attached to it.

It ended at 161 notes. This case study is written from them.

03 · The rule I am proudest of

I configured the agent to push back on me.

If a request breaks the design system, contradicts an established product pattern, fails accessibility, or is not feasible, it says so instead of building it. There is a matching honesty clause: "verified" has to be earned by actually rendering and checking, guesses are labelled as guesses, and nothing gets asserted that was not run.

That is a strange thing to build. The whole appeal of these tools is that they do what you say. I made mine argue, because a tool that agrees with you is a tool that lets you ship your own worst idea quickly.

It caught real things. It is also directly why the Leo work has a written note saying the 60 second threshold is a considered guess rather than a measurement.

04 · The evidence I lost

The claim this system makes is that fidelity was measured rather than asserted. The proof was a folder of candidate, reference and diff composites produced by the fidelity tool.

That folder is gone. It was written to a gitignored path, and the branch it lived on disappeared. Around 475 screenshots, including every fidelity composite.

I can tell you the tool existed and what it did. I cannot show you its output, which is the exact evidence that made the claim credible, and I would rather say that than quietly restate the number.

The lesson is not "back things up". It is that .gitignore is where evidence goes to die. Every asset lost here was lost because a tool wrote it to an ignored path and everyone treated ignored as temporary. Nothing was deleted on purpose.

I rebuilt the preservation approach around that afterwards, and then watched the same class of mistake happen twice more in narrower forms. First I asked "is it in a repo", which missed a file that lived in no repo. Then "is the repo in the archive", which missed two repos with personal remotes I had mistaken for backups. Then "is the repo in the refresh script", which missed a fourth.

Each fix was correct and each one left the next layer unchecked. A preservation system's coverage is a different property from its correctness, and only coverage gets violated silently.

05 · Still running

This page was built with it.

Not a museum piece: the same loop, a vault for decisions, verification before presenting, hooks that block unverified visual edits, runs my own portfolio now. The site you are reading passed through it, including this sentence.

The marks running through this page are extracted code, not screenshots: Novus Style 2, the direction that was parked in the style debate and kept intact in the lab for exactly this kind of fit. The one that opens the page is the drift band from the top of the Project Hub, the same generator running the same constants.

Reflection

The system is the most transferable thing I made that summer, and it is also the thing I am least interested in leading with. The work it produced should stand on its own.

What I would keep from it, on any team, with or without any of this tooling: build with the real components, verify before you present, write down which numbers are soft, and configure your tools to tell you when you are wrong.