Where to go next

You have the whole mental model: declare with a name, yield what you do not own, derive the rest. Everything below is a variation on it.

Fill the gaps in what you built

You have	Next thing worth adding
A query and a mutation	Persistence — storage persistence as an insertion (localStorage by default)
A list	Collections — entity storage, selectors, updates
A form	Validation — custom and async validators
Routes	Route guards and Route providers
A running app	Non-blocking navigation — pending UI instead of a freeze

Concepts worth a dedicated read

• The mental model — the design principles behind the API you just used
• Exceptions as values — declared failures, exhaustively handled
• Insertions — writing your own and composing them
• Typed insertion pipes — readable composition for each primitive
• Generators — craftGen outside a service

Teach the app its boundaries

The graph you just tested is also a map you can constrain. Architecture rules are ordinary Vitest assertions on the static Craft graph: unique identities, unique HTTP, pure craftComputed, folder lanes, exclusive feature branches — and any neighbourhood you can look up is a rule you can write. Nx still owns the workspace graph (imports, affected, cache); Craft judges the app. Craft graph vs Nx is the split.

Setup is in that guide. The demo suite already runs them:

npx nx architecture demo

When your app grows

• Service scopes — when function stops being enough
• Scaling routes — splitting collections before TypeScript's instantiation ceiling bites
• Lazy services and App start
• Observability — logging and tracing that follow the dependency graph

Reference

Looking for one symbol? The API index lists every export with a one-line description and a link.

See it running

Examples points at the demo application, which exercises most of the above end to end.

Importing Craft into an app that an agent will edit? Point it at coding agents — llms.txt, the @craft-ts/mcp server, and the Agent Skills.

← 10. Test what you wrote