Skip to content
Tikab's Toolkit

The example app

example/ is one consumer of the Toolkit — a small project tool. It exists for two reasons: to prove the building blocks compose into a working product, and to serve as reference code when you build your own consumer. It is the part you replace; nothing in packages/ depends on it.

The domain (the part that is "the example")

Workspaces contain projects; projects contain tasks; tasks get assigned, commented on, and can carry file attachments with AI analysis. Time-scoped news, configurable statuses/roles, permission groups, and an AI assistant on top.

Loading diagram...

All of this lives in the app schema fragment and the app's server functions — none of it leaks into the Toolkit.

Composition vs domain

A good way to read the example: ask of every file "is this wiring a block or being the product?"

Composition (thin, copyable)Domain (the example's own)
/api/auth/$ route → auth blocktask/project/news server functions
/api/files proxy → storage blockthe dashboard, briefing, work views
/admin/* routes → admin-ui blockspermission registry and rules
enqueue helpers → jobs blockjob task definitions
outbox panels → mailer's listMailboxthe seed script

Internationalization

Every user-facing string in the app goes through Paraglide JS — typed message functions compiled from example/messages/sv.json and en.json (Swedish is the base locale; the account menu switches). The Toolkit's UI blocks are string-free by contract, so the app passes them their labels from the same message files — including the whole /admin area (sadmin_* keys).

The three surfaces

SurfaceWhat it demonstrates
The app (/)the product itself — blocks composed into features
/sandboxevery block on its own harness page (sandbox-first); open in dev, site-admin-only in production
/adminthe admin-ui blocks composed against the app's server functions