FrontMark combines Markdown rendering features with a small Svelte component library. Studio adds a workspace for editing and synchronizing a project’s reusable components. The built library determines which component names can actually be mounted in a page.

The registry also lists candidate Supabase table, map and statistics module paths. Their .svelte files are absent from this checkout, so those names do not become available components in the built library. A listed name is not evidence that an implementation was shipped.

Cards, tabs, forms, tables and diagrams also exist as FrontMark rendering features. They should not be confused with separately registered Svelte components. See FrontMark for the authoring layer.

Source synchronization, component compilation, frontend tests and publication remain separate operations.

The Studio workspace and frontend build explain that workflow. Application behavior still belongs to the backend contracts and permitted runtime calls.

Generated projects often need small, predictable UI surfaces: a list of objects, a validated form, a detail view, a status panel, or a chart. The catalog keeps those surfaces reusable so they do not become one-off handwritten pages.

Catalog rule	Reason
Contract-driven props	Components should be configured from contracts, schemas or generated metadata.
Small composition units	A generated page can combine simple pieces instead of owning a large custom UI.
Runtime neutrality	Components present data and actions; they do not bypass runtime capabilities.
Inspectable output	The same generated metadata should be visible in docs, Studio and lightweight pages.

The following families describe design goals for generated interfaces, not a list of Svelte components currently bundled with this site.

Family	Use	Typical source
📊 Table	Collections, search results and structured lists.	Route schema, storage declaration, generated OpenAPI.
🧾 Form	Validated input and command parameters.	Request schema, contract constraints, allowed actions.
🔎 Detail	Object inspection and generated artifact metadata.	ObjectIR, agreements, component metadata.
📈 Stats	Operational or business counters.	Runtime metrics, health endpoints, generated summaries.
🧭 Chart	Visual summaries and comparison views.	Aggregated metrics or declared report shapes.
🧩 Card	Compact entity previews and navigation blocks.	Component catalog, route index, documentation metadata.
🛡️ Status	Health, validation and drift indicators.	Agreements, runtime checks, health endpoints.
🧪 Test Panel	Generated test status and validation feedback.	Test reports, drift reports, generation logs.

The design target for catalog components is:

• predictable keyboard navigation;
• compact layout that works in documentation and Studio surfaces;
• clear empty, loading and error states;
• no hidden network access outside declared runtime routes;
• visible status when data is generated, stale or partially unavailable;
• consistent formatting for dates, versions, hashes and validation states.

The catalog is intentionally conservative during the beta phase. It should help present generated material, not become a custom application builder.

The next useful catalog step is to attach concrete examples to each family:

Next example	What it should prove
Table from route schema	Columns, labels, empty state and pagination can be generated predictably.
Form from request schema	Required fields and validation messages remain contract-aligned.
Detail from ObjectIR	Structured runtime output can be inspected without custom code.
Status from agreement	Validation and drift state can be shown consistently.

The current source inventory is svelte-components/src/index.js and svelte-components/src/components/. Studio’s authoring service lives in studio/apps/api/src/services/front.ts in sigMAX_runtime.