X-ray — instance verifier
Use Tools pinned at the bottom of the workbench to turn the X-ray on or off at any time, then sweep your cursor across the canvas below. True instances of canonical legos light up green with their ID, provenance, and tier; a known lego missing its stamp reads amber; a hand-rolled copy stays red. Use the tier focus for an audit at a glance: Auto inspects the innermost stamped unit on hover, or pin Component / Block / Layout to light up every element of that tier on the page at once, each colored by status (green = verified instance, orange = known lego missing its stamp, red = hand-rolled). Border style still tells the tier apart (solid = component, dashed = block, dotted = layout), and hovering snaps to that tier for detail. To grab the code, click an element to lock it, then click Ref (import + usage) or Code (authored source), or hover and press C. Esc or a click on empty space releases the lock. The X-ray only reads the canvas, so this guide and the page chrome stay dark.
Stamp audit — self-verifying
Read live from /api/stamp-audit, which reads each cataloged component's real source and reports whether its data-brite-id stamp is actually present. Dev-only — it 404s in production, where the badge falls back to the manifest flag.
Reading source…
Setup playbook — lighting up green
What a stamp is. A stamp is a small, invisible identity mark baked into a component at its source: a data-brite-id (which canonical lego this is) and a data-brite-tier (component, block, or layout). It has no visual or behavioral effect; it is the maker's mark that lets the X-ray confirm a real instance on sight and lets the audit verify it against the real source. A component is fully wired when it is both indexed (listed in the catalog manifest, so it shows in the Library and the tools know it exists) and stamped (carries the mark at its source).
Every shared component in this package is now stamped at its source, so the stamp audit reads Verified across the board and a real instance lights green the moment you drop it in. (The demo canvas above still shows amber and red on purpose: those are a deliberately unstamped look-alike and a hand-rolled copy.) The steps below are the same path any repo follows to wire up its own components, and to fill in the still-thin Block and Layout tiers, after pulling @brite-nites/design-system and hosting this sandbox.
- 1
Stamp the component at its source root
On the component's real top-level element, add two data attributes: data-brite-id (its canonical id, e.g. brite-button) and data-brite-tier (one of component / block / layout). The X-ray keys off the presence of data-brite-id in the live DOM — a stamped element lights green; an unstamped one is flagged by its detected React component name.
- 2
Confirm it in the catalog manifest
Add (or check) the matching entry in component-manifest.ts: its id, name, importPath, provenance, and tier. The manifest is the single source the Library catalog and the X-ray both read, so the data-brite-id on the element must match the id in the manifest. That match is what makes Ref hand over a real import + usage instead of “no registered source”.
- 3
Let /api/stamp-audit self-verify
The audit endpoint reads each cataloged component's real source and reports whether the data-brite-id mark is actually there — so the badge can never claim a stamp that isn't. A local component shows Verified once its source carries the mark, Drift if the manifest claims a stamp the source lacks, and Unstamped until you add it. Shared package primitives read Deferred: their stamp is owned package-side, so absence here is expected, not drift.
- 4
Wire the server source reader to your path alias
The audit's source reader resolves a local component's importPath by rewriting the @/ alias to src/ under process.cwd(). Confirm your tsconfig.json maps "@/*" to "./src/*" (it does in this sandbox). Shared primitives are read from the package's shipped source maps (sourcesContent), so the design-system package must be built to dist/ before the audit runs.