Overview
What the Askr runtime owns, what your application owns, and which published packages the docs are written against.
Example
Create a starter, start the development server, and verify the production build.
npx @askrjs/cli@latest create startkit my-app
cd my-app
npm run dev
npm run buildWhat Askr owns
The runtime owns reactivity (state(), derive(), selector()), the JSX runtime, app startup (createIsland, createSPA, hydrateSPA from @askrjs/askr/boot), routing (@askrjs/askr/router), async resource loading with cancellation (resource() from @askrjs/askr/resources), and the server-side entrypoints for SSR and SSG. It also ships a scoped lifecycle model — defineScope() and readScope() — for values that need lexical ownership rather than component-local state.
What your application owns
Everything else: your components, your route handlers, your data fetching logic, and how you compose features into pages. Askr doesn't impose a store, a fetch client, or a styling system — @askrjs/ui and @askrjs/themes are optional packages you opt into for component primitives and theming, not part of the core runtime. Your app decides how state is grouped and where side effects live; the runtime just gives you the primitives to do it deterministically.
Published package baseline
The framework itself is @askrjs/askr, with subpath exports for /boot, /router, /resources, /data, /ssr, /ssg, /components, and others — each maps to its own declaration entrypoint, so import from the subpath that owns the feature you're using rather than the root barrel. Scaffolding and static builds come from @askrjs/cli; component and theme packages (@askrjs/ui, @askrjs/themes) are separate, versioned independently.