App scaffolds

Full-app prompts for coding agents (Cursor, Claude, Copilot, and similar). Each Copy Prompt is a long-form scaffold brief: product definition, package inventory, repo layout, domain stubs, wiring recipe, ordered implementation steps, acceptance criteria, and docs to read. Paste the whole prompt; the agent must ask you to choose path A / B / C / D1 / D2 before it builds, then follow the linked Sometic docs for exact APIs.

These are not live example apps. Paste Copy Prompt into your agent, then follow the linked docs. For surface-level prompts and llms.txt, see Agents.

Use the sticky index (or mobile chips) to jump between scaffolds. What’s Included opens a right drawer with the package checklist and the full prompt.

Scaffolds

Viewing Auth app end-to-end

Auth app end-to-end

Session-shaped product shell: sign-in, hydrate, refresh, protected routes, and dispose. Uses every System package that belongs in an authenticated app.

• createAppShell with auth, http, query, head, theme, forms
• Provider-independent auth plus one optional adapter
• HTTP 401 refresh queue wired once, not per call site
• Sign-in / register forms with validation (auth.register, not signUp)
• Document head for auth and app chrome pages
• Delivery paths A/B/C (npm) or D1/D2 (CDN simple / modular)

Explanations

Auth owns session. HTTP owns transport and the refresh queue. Query owns server cache and must refetch after re-auth. App Shell shares one session epoch so privileged UI clears together. Forms never embed provider SDKs. Client can() helpers are UX-only; authorize on the server.

Styling

Packages ship unstyled. Style sign-in with your CSS or design tokens. Use @sometic/theme only for token/CSS variable plumbing, not as a forced look. Do not add Google Fonts CDN to publishable app packages; consumer fonts stay in the app shell.

SSR notes

Create auth, http, query, and app-shell inside request or client bootstrap scopes. Never touch window, document, or storage at import time. Prefer cookie or explicit storage adapters that work on the server path you choose. Dispose the shell when the tree unmounts.

FAQ

Which auth provider should the agent pick first?

Start with @sometic/auth-local against your REST API. Swap to auth-firebase, auth-supabase, or auth-oidc later without rewriting form UI. Keep provider SDKs out of field components.

Do I really need App Shell for a login page?

For this scaffold yes. Once you have auth + http + query together, createAppShell (or createSometicApp) keeps session epoch and dispose honest so privileged UI clears as one graph.

Where should 401 refresh live?

In @sometic/http via the auth interceptor and refresh queue. Do not sprinkle ad-hoc retries in every fetch call site.

Is client can() enough for authorization?

No. Client helpers only hide UX. Every privileged API must authorize on the server.

What happens on sign-out?

Clear the session through auth, then dispose or recreate the shell so query caches and bound stores tied to the epoch cannot leak the previous user.

Can I use Elements for the whole auth app?

Option C (Elements + DOM) works for shipped controls (fields, sometic-auth-status). For complex route shells, pick A (React) or B (Vue) when the scaffold needs structure adapters that are not yet custom elements.

How should storage work with SSR?

Pass an explicit storage strategy that is safe for your server path. Never read localStorage or cookies at import time.

B2B SaaS dashboard

Signed-in product home: navigation chrome, server tables, notifications, command palette, and feature-flagged modules on one App Shell.

• App Shell session + dispose graph
• Query-backed data tables and list pages
• Auth permissions for nav and actions
• Notification center + toast feedback
• Tabs, command palette, feature flags

Explanations

SaaS dashboards mix server lists (query + data-table) with client chrome (store). Feature flags gate modules without redeploying shells. Permissions hide actions in the UI only; the API still enforces access. Notifications are a first-class surface, not ad-hoc toast spam.

Styling

Build a dense product layout in your CSS. Structure components accept classes/slots. Do not expect a built-in dashboard theme from Sometic.

SSR notes

Prefetch critical queries on the server when your framework allows. Hydrate App Shell on the client. Command palette and overlays mount only after document is available.

FAQ

Store or query for the main table?

Query. Parking API lists in the client store fights cache invalidation and refresh-after-auth.

Are Tabs and Command palette available as custom elements?

Not as dedicated CEs yet. Use React/Vue structure adapters or @sometic/dom controllers in Vanilla.

How do I gate a whole module?

Evaluate createFeatureFlagController during bootstrap and skip routes or nav items when disabled. Still enforce entitlements on the server.

Should the sidebar open state go in query?

No. That is UI chrome. Keep it in @sometic/store (ui/prefs). Keep server rows in query.

How do notifications relate to toasts?

Use notifications for durable inbox-style events. Toasts are short confirmations after mutations. Do not spam toast for every background event.

Can one dashboard host multiple products?

Yes under one App Shell. Share auth/http/query; split feature areas with tabs or routes and flag gates.

AI product workspace

Chat-shaped product shell with drafts, offline queue, query history, and honest boundaries. Sometic owns app behavior; your model API stays yours.

• Thread list + composer forms
• Draft persistence for unfinished prompts
• Offline queue for send-when-online
• Query cache for thread/message history
• Head titles per conversation

Explanations

Sometic does not ship an AI SDK. Treat the model endpoint as any authenticated HTTP API. Drafts protect composer state. Offline queue retries transport, not model semantics. Query holds thread history; store holds UI chrome (sidebar width, selected model label).

Styling

Chat layouts are entirely consumer CSS. Keep message bubbles, streaming cursors, and markdown rendering in the app. Use Sometic controls for composer inputs and overlays only.

SSR notes

Thread pages can SSR head titles and empty shells. Message lists usually hydrate client-side with query. Never read localStorage drafts at import time.

FAQ

Does Sometic stream model tokens?

No. Implement streaming with fetch/ReadableStream in your app. Use @sometic/http for auth headers and abort on dispose.

Is there an @sometic/ai package?

No. Do not invent one. Call your model provider or backend proxy through HTTP.

Where do unfinished composer prompts go?

@sometic/drafts, with secrets omitted. Never persist API keys in drafts.

What does the offline queue retry?

Transport failures for send mutations you enqueue. It does not reinterpret model output or tool calls.

Thread list in store or query?

Query, keyed by user/workspace. Store only holds chrome like collapsed sidebar or selected model label.

Should the browser hold provider API keys?

Prefer a backend proxy. If the browser must call a provider, never park secrets in drafts or the client store.

How do I cancel an in-flight generation?

Abort the HTTP request tied to the turn. On shell dispose, in-flight requests should abort with the client.

Markdown / code highlighting?

Bring your own renderer. Sometic does not ship a markdown package.

Multi-tenant admin console

Org switcher, capability matrix, approvals, and audit activity for operators managing many tenants.

• Tenant-scoped auth capabilities
• Permission matrix UI
• Approval queues
• Activity / audit feeds
• Tenant data tables

Explanations

Tenant id belongs in query keys and HTTP headers from your backend contract. Permissions and matrices are UX gates. Approvals and activity engines model workflows; they are not a hosted multi-tenant SaaS. Always re-check on the server when switching orgs.

Styling

Admin density: tight tables, clear danger actions. Use Alert/Dialog for irreversible tenant changes. Style severity with your tokens.

SSR notes

Tenant context often comes from URL or cookie. Resolve it before creating query clients. Avoid flashing the wrong tenant’s data during hydrate.

FAQ

Is there a @sometic/tenant package?

No. Model tenancy with auth capabilities, query key scoping, and your API. Do not invent a tenant package.

Where does tenant id belong?

In the URL or cookie you choose, then in query keys and HTTP headers. Never trust tenant id from the client alone.

What clears when I switch orgs?

Invalidate or remount tenant-scoped query keys. Re-run permission checks. Do not reuse the previous tenant’s cached rows.

Is the permission matrix authoritative?

No. It is UX. The API must reject unauthorized actions even if the matrix looks open.

Can approvals span tenants?

Only if your API allows it. Keep approval payloads tenant-scoped and re-authorize after every org switch.

Analytics / reporting desk

Filterable reports, uploads of CSV exports, and query-builder driven tables. Charts stay outside Sometic by design.

• Query builder filters
• Data table result sets
• Upload for export/import jobs
• Theme-aware contrast for dense UI
• Honest chart boundary (your chart lib)

Explanations

Query builder shapes filters; query caches responses; data-table presents rows. Upload owns transport boundaries for files. Visualization is explicitly out of scope for Sometic so the agent must pick a real chart library.

Styling

Dense report UI. Prefer high-contrast tokens from theme helpers. Keep chart colors in the chart library config, not in @sometic packages.

SSR notes

Filter state can live in the URL. Prefetch the default report query when possible. Uploads are client-only.

FAQ

Does Sometic include charts?

No. Pair data-table/query with visx, Chart.js, ECharts, or another library and document that boundary.

Upload vs file input?

File/field inputs collect files. @sometic/upload owns transport, progress, and abort. Use both layers.

Where should filter state live?

Prefer the URL for shareable reports. Cache result sets in query keyed by the serialized filter.

Who serializes the query-builder AST?

Your app. Map the builder output to your API’s filter contract; Sometic does not invent your backend query language.

Huge exports?

Stream or job-based download through your API. Use upload/download progress UI; do not block the main thread on multi-hundred-MB CSV parses in the browser.

SSR for charts?

Only if your chart library supports it. When unsure, hydrate charts on the client after the table query resolves.

Can agents claim a Sometic chart package?

No. That is a hard honesty rule for this scaffold.

Ops / support ticket desk

Queue of support tickets with forms, status updates, notifications, and activity. Not a public Invoice Desk demo.

• Ticket create / update forms
• Query-backed queues and detail panes
• Toast + dialog confirmations
• Notification center for assignments
• Activity timeline on each ticket

Explanations

Ticket desks are form + query products. Keep status machines on the server. Activity records audit; notifications push assignment events. This scaffold replaces missing public examples without advertising parked Invoice Desk apps.

Styling

Ops UI: clear priority colors in your CSS, not hardcoded in packages. Use Alert for SLA breaches.

SSR notes

Queue pages can SSR empty shells. Detail views hydrate with query. Dialogs and toasts are client-only.

FAQ

Is this Invoice Desk?

No. Build a support ticket product. Do not clone or link parked example-invoice apps.

How do I get realtime updates?

Bring websocket or SSE yourself and invalidate query keys. Sometic does not ship a realtime transport.

Who owns ticket status transitions?

Your API. Forms propose changes; activity records the accepted audit trail.

Assignment notifications vs toasts?

Notifications for durable assignment events. Toasts for immediate confirmations after the operator acts.

Should billing be in this prompt?

Not unless you intentionally merge another scaffold. Keep this brief on queues, detail, notifications, and activity.

SLA timers?

Compute on the server or in your app clock. Sometic has no SLA package; use Alert styling for breaches in consumer CSS.

Marketplace listings

Listing create flow, media upload, searchable catalog, and SEO-ready listing pages.

• Listing forms with validation
• Image upload pipeline
• Query catalog + filters
• Select / combobox for categories
• Head SEO per listing

Explanations

Marketplace honesty: payments and search rankings stay outside Sometic. Head owns document metadata for public listing URLs. Upload owns file transport. Combobox is adapter-backed, not a CE.

Styling

Card grids and hero images are consumer layout. Keep listing cards semantic (article/link). Do not fake browser chrome around previews.

SSR notes

Public listing pages should SSR head tags and primary content when possible. Uploads and seller dashboards are client-heavy.

FAQ

Where do payments go?

Stripe or similar, integrated by you. There is no @sometic/payments package.

Combobox as a custom element?

Not shipped. Use React/Vue selection adapters or DOM controllers.

How do listing pages get SEO tags?

Set title/description (and OG fields if you use them) through @sometic/head and head/seo on the listing route.

Seller vs buyer access?

Protect create/edit with auth. Keep public catalog and listing detail unauthenticated when your product requires it.

Search ranking?

Your search backend. Query caches pages of results; it does not rank marketplace inventory.

Image CDN?

Upload through @sometic/upload to your storage; serve via your CDN. Sometic does not host media.

Favorites / carts?

Model them in your API and query keys. Not part of this scaffold’s required surface.

Developer API portal

Docs-like portal for API keys, OIDC login, HTTP demos, and structured navigation.

• OIDC-capable auth path
• HTTP client demos with interceptors
• Head for docs routes
• Tabs / accordion / tree for API reference chrome
• Copy-friendly key forms

Explanations

Portals teach HTTP and auth boundaries. Keep try-it panels behind auth. Tree/Tabs are React/Vue structure (no CEs). Point readers at sometic.dev agents and llms.txt rather than inventing a second docs system.

Styling

Editorial docs density with mono for payloads (JetBrains only if you choose it in the portal app; packages stay font-agnostic).

SSR notes

Docs pages SSR well. Interactive try-it panels hydrate client-side. OIDC redirects are browser flows.

FAQ

Does this replace sometic.dev?

No. Scaffold a customer-facing API portal for your product. Sometic’s own docs stay on sometic.dev.

Is OIDC required?

Optional. Local or other adapters work; OIDC fits SSO developer portals.

How should try-it panels call APIs?

Through @sometic/http with the same interceptors as production. Never hardcode live secrets into static pages.

Where do API keys display?

Show secrets once after create, then store hashes server-side. Use forms with draft omit so secrets are not persisted in drafts.

Should agents also read llms.txt?

Yes when teaching Sometic package boundaries. Pair with the Agents guide.

Knowledge base / CMS lite

Editable articles with drafts, undo/redo history, conflict handling, and SEO head tags.

• Article forms + validation
• Draft autosave
• History / undo stack
• Conflict detection on concurrent edits
• Head metadata per article

Explanations

CMS lite means structured articles, not a full Notion clone. History and conflict engines protect editors. Rich text rendering is your component; Sometic owns form state and collaboration edges.

Styling

Editor chrome is yours. Keep focus rings visible. Prefer native inputs where possible for a11y.

SSR notes

Published articles SSR. Editor routes client-hydrate with drafts. Conflict UI is client-only.

FAQ

Is there a rich-text package?

No. Bring TipTap, Lexical, ProseMirror, or a textarea. Bind content through forms.

Do drafts/history/conflict ship as CEs?

No. Call the engines from React, Vue, or Vanilla.

How often should autosave run?

Debounce in the app. Drafts persist editor state; do not flood the API on every keystroke.

Who wins on concurrent edits?

Your policy via @sometic/conflict. Prompt reload or merge; never silently overwrite without an audit trail.

Version history UI?

@sometic/history supports undo/redo command stacks. Long-term revision lists still live in your API if you need them.

Published vs draft SEO?

Only published routes should advertise canonical head tags. Keep draft editors noindex if they are public URLs.

Media embeds?

Your editor + upload pipeline. Not required by this scaffold unless you extend it.

Multi-author locking?

Optional presence is yours. Conflict handles save races; it is not a full CRDT collab suite.

Onboarding + gated rollout

First-run checklist, command-driven actions, and feature-flag gates for gradual module rollout.

• Onboarding form wizard
• Feature flag gates per step
• Command palette actions
• App Shell bootstrap
• Prefs store for checklist progress

Explanations

Flags decide what exists. Commands expose intentional actions (including palette). Onboarding progress is client prefs. Do not store server entitlements only in the client store; confirm with auth/query.

Styling

Friendly empty states in consumer CSS. Keep CTAs square if matching docs brand, or follow your product system.

SSR notes

Flag evaluation may need bootstrap payload from the server. Avoid flashing gated modules before flags resolve.

FAQ

Is feature-flags a hosted LaunchDarkly?

No. createFeatureFlagController evaluates rules you supply. Bring LaunchDarkly or your API for remote config if needed.

Is there a Stepper component?

Not yet. Compose forms with your layout, or use tabs for steps.

Flags vs paid entitlements?

Flags gate UX. Billing entitlements still come from your backend and auth capabilities.

Where does checklist progress live?

Prefs in @sometic/store. Do not put it in query unless the server owns completion state.

How do commands show in the UI?

Register with createCommandRegistry and expose them through the command palette structure adapter.

Flash of gated content on load?

Resolve bootstrap flags before rendering gated routes, or show a neutral shell until evaluation finishes.

Offline-first field app

Capture forms in the field, queue mutations while offline, resolve conflicts when back online.

• Persistent store for field drafts
• Offline mutation queue
• Conflict resolution on sync
• Forms with validation
• Auth session hydrate when online

Explanations

Offline-first is an orchestration problem. Queue owns retry. Conflict owns merge policy. Store persistence is for client state; server truth returns through query after sync. Do not pretend every API is offline-safe.

Styling

Large touch targets for field devices. High contrast. Prefer native inputs for mobile keyboards.

SSR notes

Field apps are mostly client/PWA. If you SSR a shell, do not assume navigator.onLine at import time.

FAQ

Does Sometic include a service worker?

No. Add Workbox or platform PWA tooling yourself. Sometic owns queue, draft, and conflict behavior.

What survives a reload?

Whatever you persist on purpose (drafts, queue storage). Rehydrate auth when online before flushing privileged mutations.

Can every endpoint work offline?

No. Only enqueue mutations your API can accept idempotently later. Reference data may need a local cache you own.

When do I detect offline?

In app runtime (online/offline events). Never read navigator at import time.

Order of reconnect?

Hydrate auth if needed, flush the offline queue, run conflict strategies, then invalidate query so UI shows server truth.

Photo capture in the field?

Use native file/camera inputs plus upload when online. Queue metadata mutations carefully if binaries cannot upload yet.

GPS / maps?

Outside Sometic. Keep coordinates in your form model and API.

Dispose while queued?

Follow engine dispose contracts for listeners and in-flight HTTP. Document whether your queue storage outlives the page.

Conflict UI on a phone?

Keep it simple: show server vs local fields and let the operator choose. Avoid dense merge UIs on small screens.

Compliance / approval workflow

Policy reviews with approval steps, activity audit, notifications, and permission-gated actions.

• Approval step engine
• Activity audit trail
• Notification fan-out
• Permission matrix for reviewers
• Dialog / drawer review panels

Explanations

Compliance UIs need durable audit (activity), explicit decisions (approval), and gated buttons (permissions). Notifications inform; they do not authorize. Keep legal policy text in your CMS; Sometic orchestrates the workflow chrome.

Styling

Conservative, high-contrast. Make approve/reject unmistakable. Prefer clear language over playful motion.

SSR notes

Case detail can SSR summary. Approval actions are client mutations with server enforcement.

FAQ

Is approval a legal system of record?

No. It models steps and UI state. Your backend remains authoritative for compliance outcomes.

Is Drawer available as a custom element?

Not shipped. Use React/Vue Drawer or @sometic/dom controllers.

Do notifications authorize reviewers?

No. They inform. Approve/reject still requires server authorization and permission checks.

Where does the audit trail live?

Activity events in the product, persisted by your API. Do not treat toast history as audit.

Four-eyes / dual control?

Encode that in your approval steps and server rules. The engine will not invent regulatory policy for you.

Export for auditors?

Build an export from your activity store/API. Sometic does not ship a compliance export format.

Can agents use this prompt as-is?

Yes. Paste into Cursor/Claude/Copilot, then open the linked docs for package APIs.

Page FAQ

Why prompts instead of example repos?

Public example apps are paused. Agent scaffolds keep discovery honest: you get a production-shaped brief without a demo product that over-promises UI.

Will these invent packages?

No. Every prompt is scoped to What’s included. Missing custom elements and Experimental adapters are called out.

Which path: A, B, C, D1, or D2?

Every scaffold prompt requires the agent to stop and ask before coding. The human must choose:

• A) React + @sometic/react (npm / Vite)
• B) Vue + @sometic/vue (npm / Vite)
• C) Vanilla + Web Components (@sometic/elements + @sometic/dom, npm / Vite)
• D1) Simple CDN (jsDelivr IIFE <script src>)
• D2) Modular CDN (jsDelivr ESM type="module")

Agents must not assume or default a path. Only the chosen delivery family is used. As soon as you answer, the agent must start scaffolding in that same turn (not just acknowledge the choice).

Why did my agent invent signUp / createHead?

Scaffold prompts now encode package API truth (auth.register, createHeadController, head.set, auth-local /auth/register, Vite @ alias on both sides, applyHead / applyThemeToElement in bootstrap). Re-copy the latest Copy Prompt from this page; older pastes will keep producing those bugs.

How do I use a scaffold with my agent?

Open What’s Included, copy the prompt (or use Copy Prompt on the card), paste it into your agent, answer A / B / C / D1 / D2 when asked, then point the agent at the docs URLs listed in the drawer. Prefer https://sometic.dev/llms.txt if the agent needs a curated index.

Do I need App Shell for every scaffold?

Session-shaped products (auth, SaaS, admin, portals) should use createAppShell / createSometicApp. Read each scaffold’s explanations: offline and CMS-lite scaffolds still compose System packages, but the prompt names the spine explicitly when epoch and dispose matter most.

What about Experimental frameworks?

Wave B/C adapters (Angular, Svelte, Solid, Preact, Alpine, jQuery, HTMX) stay Experimental. These prompts offer Wave A paths A / B / C / D1 / D2 only. Do not ask the agent to fill Experimental adapters to Wave A depth.

Can I mix several scaffolds?

Yes for product modules (for example auth e2e plus SaaS dashboard), but keep one App Shell, one auth instance, and one query client. Do not spawn duplicate System graphs per feature.

Related

• Agents
• App Shell
• App primitives
• What’s included
• Beta maturity