SYSTEM-SHEET —

Filled BEFORE any markup. The route map says what exists; the inventory says what it is built from and — critically — how many variants of each thing are allowed. That number is the budget systemscan enforces after the build. Declaring four button variants and shipping nine is the disease this file exists to prevent.

Product

What it does:
Who uses it, how often:
Stack / where the markup lands:
The moment of care:

Route map

route	job (one line)	layout family	in the shell?	traffic
`/`			yes	high
`/…`

The shell

structure:
collapses to (mobile):
current-route indicator:

Build order 1. 2.

Component inventory

component	variants (name them all)	budget	where used
button	primary / ghost / danger	3	everywhere
input
select
table
…

Non-control components — pills, badges, banners, skeletons, avatars, tags. systemscan does not count these (no focus, no interaction), which makes them exactly where drift breeds unseen. Declare them here anyway and police them by eye against components.png:

component	variants	where used
status pill

Rule: a variant not on this list does not get built. If a screen needs one, that is a design decision — edit this file first, then build it.

State matrix

component	default	hover	focus-visible	active	disabled	loading	empty	error	selected
button	✓	✓	✓	✓	✓	✓	n/a	n/a	n/a

Contrast survives every state. A degraded, stale or disabled view usually dims something, and dimming is how a designed state quietly becomes unreadable — text at opacity: .5 on a coloured surface can fall from 6.9:1 to under 3:1 while every linter stays silent, because they all read the undimmed computed colour. State the consequence for each state that changes opacity or colour:

state	what it dims	measured contrast after dimming
error / stale
disabled

How each state is reachable. Five beautiful empty states nobody can open are five states nobody reviewed. Name the mechanism — a :target fragment, a query param, a fixture flag — preferring one that survives with JS off, and list the URLs:

mechanism:
URLs:

Empty / loading / error are not edge cases. They are the first thing a new user sees. For each screen that can be empty, write the actual words:

screen	empty state says	the one action that fills it

Density

Tables: rows per screen · sticky header? · sort affordance · tabular-nums on numerals
Charts: route to the dataviz skill — do not improvise a series palette here
What gets truncated, and how the full value is reachable:

Gate checklist

every route has a one-line job and a layout family
the shell is described, including its mobile collapse and its current-route indicator
every component has a named, justified variant count — not "a few"
every interactive component's focus-visible is designed, not defaulted
empty / loading / error are written as real copy for every screen that can hit them
build order is by traffic
no peak. If a screen has a wow moment, justify it or cut it.