
# Design System Console

`/_admin/design-system` draws the design system your config declares, at the values it actually renders with. The export endpoints and `sovrium design-system` hand the same content to a machine as text; this page is the version a person reads.

It is admin-gated and returns `404` to anyone else, and it is **read-only**. Nothing on it edits configuration — the console is an operational data console, and the design system is one of the things it reflects.

## What the page shows

Three sections, each a live preview frame rendered by the real renderer with your real tokens.

| Section             | What it draws                                                                                                                                               |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Foundations**     | Every token the app renders with — colour, type, spacing, radius, breakpoints, durations — drawn at the value it resolves to in the scheme you are reading. |
| **Tokens in use**   | The same tokens composed into surfaces, so a combination can be judged on sight rather than inferred from a list.                                           |
| **Voice and usage** | The rules a writer follows here: the principles, how the app addresses a reader, the tone per moment, and what each colour is for.                          |

Each frame has an **Open full page** link to `/_admin/design-system/preview/{section}` — `foundations`, `ui-kit` or `voice`. Add `?scheme=dark` to any preview to read it in the dark palette; the values printed beside each swatch follow the scheme, so the page never labels a swatch with a colour it is not showing.

## The component catalog

Below the sections, the catalog renders one specimen per component type, grouped by category. Each category has its own full page at `/_admin/design-system/preview/components/{category}`.

| Category        | Types | Drawn                                            |
| --------------- | ----- | ------------------------------------------------ |
| `form-controls` | 11    | All of them.                                     |
| `data`          | 10    | One — `data-table`. The other nine are reported. |
| `structural`    | 2     | All of them.                                     |
| `layout`        | 10    | Eight; `modal` and `tab-panel` are reported.     |

A type that is not drawn is **named anyway, with the reason**. That is the point of the catalog: a heading over an empty box would assert that the blank is the design. Three reasons appear:

- **Reads records from one of your tables.** Seven of the ten `data` types bind an operator table by construction, and a preview frame carries no operator data. `data-table` is the exception — its data source accepts the platform's own fixture endpoint, so it is drawn over rows that belong to nobody.
- **Renders a live write control, or has no inline appearance.** `modal` renders as a closed overlay with nothing to show inline. `form` and `data-form` are refused for a stronger reason, below.
- **Accepted by the schema with no renderer behind it.** `tab-panel` validates, and a page that uses it renders a bare `div`. The catalog reports the gap rather than drawing the consequence.

:::callout
**No preview frame carries a write path.** The `editors` category — `schema-json-editor`, `schema-yaml-editor`, `schema-form-editor`, `schema-ai-agent` — is excluded permanently, and `form` and `data-form` are excluded from the `data` category, because all six ship a live submit control. This is not a backlog item: a console that edits configuration is the plane Sovrium deliberately does not ship, and a preview frame is not the door it comes back through.
:::

## The share link

A design system's audience is wider than the people who have an account on your instance: designers, an agency, a client stakeholder. `GET /s/design-system/{token}` gives them the charter without giving them a login.

The **Share link** panel on the console mints one. The link is unlisted — it appears in no sitemap, no navigation and no page listing — and it is revocable.

| Operation | Endpoint                                      | Notes                                                        |
| --------- | --------------------------------------------- | ------------------------------------------------------------ |
| Mint      | `POST /api/admin/design-system/shares`        | `201` with the id, the creation time, the token and the URL. |
| List      | `GET /api/admin/design-system/shares`         | Live shares, **metadata only** — id and creation time.       |
| Revoke    | `DELETE /api/admin/design-system/shares/{id}` | `200` once; `404` for an unknown or already-revoked id.      |
| Read      | `GET /s/design-system/{token}`                | Anonymous. No login, no cookie, no account.                  |

**The token is shown exactly once**, in the response to the mint. It is stored only as a SHA-256 digest, so nothing — not the list endpoint, not the audit log, not a log line — can hand it back. That is what makes revocation mean something: an operator who could re-read a link would never learn it had leaked. If you lose the link, revoke it and mint another.

Revoking is immediate and total. The reader gets the same `404` as an unknown or malformed token — never a "this link has been revoked", which is a different answer and exactly what an enumerator collects.

The reader page is a single self-contained document: no script, no form, no comment box, no upload. There is nothing on it to interact with, which is the strongest form of "the widest audience gets the weakest surface".

### What the link publishes

Anyone holding the URL reads the whole design system, not just its tokens. Before you send one, know that it contains:

- your **principles** and your **logo** section, including its clear-space, minimum-size and misuse rules;
- your **voice** — personality, pronoun, what to prefer, what to avoid — and the **tone** instruction for each moment;
- every **colour token** with its value, its usage rule and the token it pairs with;
- the **type scale**, and the spacing, radius, breakpoint, font and duration tokens;
- your **imagery** rules and the icon set;
- the **usage, when and don't** guidance for each of your components;
- the values Sovrium kept outside the token tree, and anything you declared that it does not apply.

It contains no environment-variable value and no record data — the projection reads `design` and `theme` and nothing else, so there is no path on which a secret could arrive. But a brand charter is a document about your product, and a public link to it is a decision. Treat minting one as publishing.

Both mint and revoke write to the [audit log](/en/docs/activity-monitoring) — a mint at `warning` severity, because it is the entry an operator scans for when reconstructing when something became public. Neither entry records the token.

## Related Pages

- [Design System](/en/docs/design) — the `design` key the console draws.
- [Type Scale](/en/docs/design-type-scale) — the ladder the Foundations section renders.
- [Admin Dashboard](/en/docs/admin-dashboard) — the rest of the console, and the export endpoints.
- [Activity Monitoring](/en/docs/activity-monitoring) — where a mint and a revoke are recorded.
- [Security Hardening](/en/docs/security-hardening) — the 404-not-403 posture the share reader follows.
