docs: restructure DESIGN.md into Geist-inspired foundations + docs/ui product rules

.agents/skills/frontend/information-architecture/SKILL.md

@@ -44,7 +44,7 @@ Rules:
 - **"Schema history" is not a sibling tab.** Version history lives inside the Schema tab, below the editor and beside the `VersionNavigator` seam. The two overlap on purpose: the navigator is the *reader* (one version, with what it changed), the history is the *ledger* (every version at once). `?tab=versions` remains as a redirect; it does not appear in the tab bar.
 - **The 4-step checklist is onboarding, not navigation.** It retires itself twice over: when the journey is finished (`hasReleases` makes `done` derivable) and when somebody dismisses it. Dismissal is **per project** and persisted — finishing one project does not teach you the pipeline for the next. It gates nothing and is never the sole path to a screen.
   `hasReleases` is derived in `useProjectReadiness` from the two-hop read (project → dataset → releases) rather than added to the project-stats wire model: the Overview dashboard already makes both requests for its own cards, so a third spelling of the fact on the server would be exactly the drift these rules exist to prevent.
-- **Inference is a rail destination, not a project tab.** Model connections carry no `project_id`: one workspace is one SQLite file, every project uses the same connections, and navigation maps 1:1 to domain objects — so a project tab would state a scope the object does not have. This **supersedes the earlier rail rule** ("logo, collapse toggle, Home, Projects, account avatar — nothing else"); the rail now carries Home, Projects, Inference and the account control, and `DESIGN.md` carries the same membership in both places it states it. What earns a rail entry is a workspace-level object with nowhere else to live, never mere frequency of use.
+- **Inference is a rail destination, not a project tab.** Model connections carry no `project_id`: one workspace is one SQLite file, every project uses the same connections, and navigation maps 1:1 to domain objects — so a project tab would state a scope the object does not have. This **supersedes the earlier rail rule** ("logo, collapse toggle, Home, Projects, account avatar — nothing else"); the rail now carries Home, Projects, Inference and the account control, and `docs/ui/navigation.md` carries the same membership. What earns a rail entry is a workspace-level object with nowhere else to live, never mere frequency of use.
 - **Home is the workspace's dashboard, and Overview is the project's.** They do not
   overlap, because they answer different questions: Home asks *what is waiting on me,
   anywhere*, which no single project can answer, and Overview asks *what does this

.agents/skills/process/public-writing/SKILL.md

@@ -75,13 +75,13 @@ issue number — inside a sentence, a quotation, or a denial. "Nothing here clos
 
 ## Paragraphs, not notation — and voice
 
-Write the way `DESIGN.md` writes: complete sentences that explain reasoning. Telegraphic
-fragments, bare citation chains and stacked parentheticals cost the reader more than they save
-the writer. Structure still earns its place — a settled-options list stays a list, a comparison
-stays a table.
+Write complete sentences that explain reasoning, the way this repository's documentation
+writes. Telegraphic fragments, bare citation chains and stacked parentheticals cost the reader
+more than they save the writer. Structure still earns its place — a settled-options list stays
+a list, a comparison stays a table.
 
-`DESIGN.md`'s copy rules hold here too: **no exclamation marks, no "successfully", no "please"**
-— plus no filler acknowledgment, no restating the request before answering, no announcing a
+House style for public prose: **no exclamation marks, no "successfully", no "please"** — plus
+no filler acknowledgment, no restating the request before answering, no announcing a
 conclusion the text does not support.
 
 Before posting, reread the draft asking: does it name a company or product, and is the mention a

CONTRIBUTING.md

@@ -280,10 +280,13 @@ If a change fights either boundary, the change is wrong — not the boundary.
 
 Any change to `@visionset/app` or `@visionset/ui-core` is governed by
 [`DESIGN.md`](DESIGN.md) at the repository root — **read it before building or changing a
-screen**, not after. It owns the tokens, the type scale, the navigation rules, the tab
-shapes, the annotation workspace, and (since #206) the rules for project-level data
-surfaces: what a header carries, how numbers are formatted, and why a disabled button with
-no explanation is forbidden.
+screen**, not after. It owns the visual foundations: colour semantics, typography roles,
+spacing, radius, materials, motion, action hierarchy, and accessibility. The product's own
+UI rules live beside it: [`docs/ui/product-principles.md`](docs/ui/product-principles.md)
+(what a screen must show and offer — headers, numbers, why a disabled button with no
+explanation is forbidden), [`docs/ui/navigation.md`](docs/ui/navigation.md) (breadcrumbs,
+the rail, URL state), and [`docs/ui/annotator.md`](docs/ui/annotator.md) (the annotation
+workspace).
 
 It is prose over running code, not decoration. `frontend/ui-core/src/styles.css` carries the
 tokens and `tokens.ts` mirrors them, gated against each other in both directions by