@askrjs/cli 0.0.3 → 0.0.4

package/skills/askr-migration-react/SKILL.md

@@ -1,81 +0,0 @@
----
-name: askr-migration-react
-description: Use when translating React-shaped code, habits, or component designs into idiomatic Askr, including replacing useState/useEffect patterns, JSX assumptions, data fetching, routing, context, component APIs, and UI primitive choices.
----
-
-# Askr Migration React
-
-Use this only when a task, sample, or codebase slice is React-shaped and must be translated into idiomatic Askr. It is a transition skill, not a default entrypoint for normal Askr feature work.
-
-## Use This When
-
-- The input code or prompt uses React hooks, React Router, or React-only UI assumptions.
-- A generated design mirrors React patterns that need translation before implementation.
-- A migration task needs native Askr ownership for state, async work, routing, or primitives.
-- The fastest path is to convert a known React shape instead of designing from scratch.
-
-## Inspect First
-
-- The current app's Askr imports and component patterns
-- The route tree and feature boundaries already present in the repo
-- The React-shaped state, async, routing, and primitive assumptions you are replacing
-
-## Choose The Replacement
-
-- React `useState` -> Askr `state()` as a `[getter, setter]` pair.
-- React `useMemo` -> Askr `derive()` when a reactive computation is needed.
-- React `useEffect` data loading -> Askr `resource()` or `createQuery()` based on ownership.
-- React Router component routes -> Askr route registration with `group()`, `page()`, `route()`, and `fallback()`.
-- React context -> Askr `defineScope()` and `readScope()`.
-- React keyed list `.map` -> `For` when identity or dynamic list updates matter.
-
-## Do This In Order
-
-1. Identify whether the React-shaped code is really local state, shared data, routing, context, or primitive behavior.
-2. Remove React imports and hook assumptions before translating line by line.
-3. Replace state, async, routing, and context with the owning Askr primitives.
-4. Move feature logic to the correct route, feature, adapter, or shared boundary.
-5. Replace React-only UI libraries with Askr-compatible primitives when behavior matters.
-6. Validate call order, async truth, and route registration before closing the migration.
-
-## Copy This Shape
-
-```tsx
-import { state } from "@askrjs/askr";
-import { resource } from "@askrjs/askr/resources";
-
-const [open, setOpen] = state(false);
-const user = resource(({ signal }) => loadUser(id, { signal }), [id]);
-
-<button onClick={() => setOpen((value) => !value)}>{open() ? "Close" : "Open"}</button>;
-```
-
-## Never Do These
-
-- Importing React hooks or React runtime helpers.
-- Treating state getters like values instead of functions.
-- Porting React Router route components directly.
-- Hiding async work in effects when the UI depends on it.
-- Assuming third-party React component packages are compatible.
-
-## Validate
-
-- No React imports remain unless the project intentionally embeds React separately.
-- Runtime helper call order is stable.
-- Async work has cancellation and visible loading or error states.
-- Routing uses Askr route registration.
-- Interactive UI uses Askr-compatible primitives.
-
-## Done When
-
-- The translated code reads like Askr instead of line-by-line React porting.
-- State, async work, routing, and context use native Askr ownership.
-- Feature logic sits in the right file boundaries.
-- Remaining UI assumptions are compatible with the app's existing primitives.
-
-## Handoff
-
-- Use `askr-mental-model` when primitive choice is still unclear.
-- Use `askr-project-structure` when the migration requires moving files or ownership boundaries.
-- Use `askr-query-mutation` or `askr-resources-data` when async ownership is the real blocker.
-- Use `askr-testing-determinism` before closing migrated behavior.

package/skills/askr-migration-react/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Migration React"
-  short_description: "Translate React habits to askr"
-  default_prompt: "Use $askr-migration-react to convert React-shaped code into askr."

package/skills/askr-observability-debugging/SKILL.md

@@ -1,83 +0,0 @@
----
-name: askr-observability-debugging
-description: Use when adding Askr observability, debugging, structured logs, request IDs, trace IDs, query and mutation diagnostics, event-sourced replay context, agent-run audit trails, and dev-only diagnostics.
----
-
-# Askr Observability Debugging
-
-Use this when failures must be explainable to users, developers, or operators. The goal is preserved correlation data, safe user-facing errors, and diagnosable stale or event-driven failures.
-
-## Use This When
-
-- A failure needs request, trace, command, run, or event correlation.
-- You need safe user-visible error copy plus deeper operator diagnostics.
-- The UI depends on stale-state or eventual-consistency diagnostics.
-- An agent workflow, realtime flow, or write path needs audit-friendly tracing.
-
-## Inspect First
-
-- Existing error normalization and logging helpers in `src/shared`
-- API request and response metadata available from adapters
-- Query and mutation consistency or error states
-- Agent run IDs, command IDs, event IDs, and audit requirements
-
-## Preserve These IDs
-
-- Request ID or trace ID.
-- User, session, or workspace ID where safe.
-- Command ID, idempotency key, aggregate ID, version, event ID, or projection cursor.
-- Query key and invalidation prefix.
-- Run ID, tool call ID, approval ID, and artifact ID for agentic workflows.
-
-## Do This In Order
-
-1. Preserve correlation metadata at the adapter boundary.
-2. Normalize errors into a user-safe message plus structured diagnostics.
-3. Show safe copy to users and deeper context only in logs or dev-only panels.
-4. Preserve stale-state, projection, or replay context when eventual consistency matters.
-5. Add focused tests for duplicate-event, stale-state, or correlation behavior when the flow depends on it.
-
-## Copy This Shape
-
-```ts
-const normalized = normalizeApiError(error, {
-  requestId,
-  commandId,
-  eventId,
-  queryKey: "accounts:list",
-});
-
-logError("accounts.refresh.failed", normalized.diagnostics);
-return {
-  message: "Unable to refresh accounts.",
-  diagnostics: normalized.diagnostics,
-};
-```
-
-## Never Do These
-
-- Swallowing errors in async handlers.
-- Console-only diagnostics for production-critical flows.
-- Showing raw stack traces or transport payloads to users.
-- Losing correlation IDs between adapters, features, and UI errors.
-- Logging private prompts, tokens, or sensitive request bodies to preserve debugging context.
-
-## Validate
-
-- Errors include user-safe copy and developer-useful context.
-- Eventual-consistency states are diagnosable.
-- Agent workflows have audit-friendly run and event IDs.
-- Logs do not contain secrets or private prompts.
-
-## Done When
-
-- User-facing failures stay safe and intelligible.
-- Operators have enough correlation data to trace the issue.
-- Stale or event-sourced failures are diagnosable separately from command success.
-- No logs or diagnostics leak secrets or private prompts.
-
-## Handoff
-
-- Use `askr-api-integration` when metadata is being dropped before it reaches the feature layer.
-- Use `askr-agent-workflows` when run IDs, tool calls, approvals, or artifacts need user-facing traceability.
-- Use `askr-testing-determinism` to prove duplicate-event, stale-state, or error-correlation behavior.

package/skills/askr-observability-debugging/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Observability Debugging"
-  short_description: "Trace and debug Askr workflows"
-  default_prompt: "Use $askr-observability-debugging to add diagnostics."

package/skills/askr-project-structure/SKILL.md

@@ -1,79 +0,0 @@
----
-name: askr-project-structure
-description: Use when deciding where Askr app files belong, naming components, separating route-first pages, layouts, features, shared helpers, adapters, reusable UI, tests, and package-owned responsibilities.
----
-
-# Askr Project Structure
-
-Use this before creating, moving, or splitting files. The goal is one obvious owner per file and no parallel architecture.
-
-## Use This When
-
-- You need to add a new file.
-- You are tempted to put logic in a page because it is nearby.
-- The repo already has routes, features, adapters, or shared helpers and you need the right owner.
-- You want to avoid duplicate structures for the same concern.
-
-## Inspect First
-
-- The existing route registry and nearest `_layout.tsx` owner.
-- The nearest existing feature folder for the same domain.
-- The nearest adapter, shared helper, and reusable component folder.
-- Existing tests for the same surface.
-
-## Keep The Existing App Shape
-
-- If the repo uses `src/pages/**/_routes.tsx`, keep using it.
-- If the repo uses `src/routes/*`, keep using it.
-- If the repo uses `src/shared`, keep shared helpers there.
-- If the repo uses `src/lib` for shared helpers, keep using it.
-- Do not create a second route tree, a second shared layer, or a second feature layout because one file looked easier.
-
-## Pick The Owner
-
-- URL reachability: nearest route registry file.
-- Shell chrome or persistent branch UI: matching `_layout.tsx`.
-- Domain workflow, queries, mutations, and feature UI: `src/features/<feature>/`.
-- Reusable display-only pieces: the repo's shared components folder.
-- Cross-cutting helpers such as formatting or parsing: the repo's shared helper folder.
-- Generated clients, raw fetch wrappers, and DTO mapping: `src/adapters/`.
-- Visual styling and tokens: CSS or theme layer, not runtime logic.
-
-## Copy This Shape
-
-```text
-src/pages/app/billing.tsx          # route-owned page shell
-src/features/billing/billing-form.tsx
-src/features/billing/billing.query.ts
-src/adapters/billing-client.ts
-src/shared/format-money.ts
-```
-
-## Reject These Shapes
-
-- `src/pages/app/billing.tsx` importing a generated API client directly.
-- `src/components/shared/billing-table.tsx` owning billing mutations and route redirects.
-- `src/shared/billing.tsx` containing JSX and transport code together.
-- API clients in components or UI primitives.
-- Business logic or transport code in `src/pages`.
-- JSX in `src/shared` or `src/adapters`.
-- Duplicate shells across pages.
-- One component that owns routing, fetching, mutation, and styling.
-- Parallel abstractions for a concern Askr already owns.
-
-## Validate
-
-- Another agent could predict where the file belongs.
-- No page directly owns raw transport or DTO mapping.
-- No JSX leaked into adapters or shared helper files.
-- New folders match the existing repo shape instead of creating a second one.
-
-## Done When
-
-- No duplicate structure was introduced for the same concern.
-
-## Handoff
-
-- Use `askr-routing-layouts` when the hard part is URL ownership.
-- Use `askr-resources-data` or `askr-query-mutation` when the hard part is async ownership.
-- Use `askr-testing-determinism` once ownership is settled and you need validation.

package/skills/askr-project-structure/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Project Structure"
-  short_description: "Place Askr files in the right layer"
-  default_prompt: "Use $askr-project-structure to decide where Askr app files belong."

package/skills/askr-query-mutation/SKILL.md

@@ -1,115 +0,0 @@
----
-name: askr-query-mutation
-description: Use when modeling shared server state in Askr with createQuery, createMutation, invalidate, service boundaries, consistency states, pending writes, cache keys, event-sourced read models, and explicit read/write coordination.
----
-
-# Askr Query Mutation
-
-Use this for shared keyed reads and writes that must coordinate across screens or survive beyond one render. The goal is deliberate keys, narrow invalidation, and truthful write reconciliation.
-
-## Use This When
-
-- Multiple screens need the same keyed server state.
-- A write must invalidate or reconcile shared reads.
-- The UI needs pending, error, stale, or pending-write truth after a mutation.
-- Event-sourced or eventually consistent data needs explicit reconciliation.
-
-## Inspect First
-
-- Existing query keys and invalidation prefixes.
-- The nearest feature owner for the data.
-- The adapter or service boundary that should receive `signal`.
-- Existing stale, syncing, or pending-write UI on the same surface.
-
-## Pick The Data Owner First
-
-- One route or container owns the read and no other screen shares it: use `askr-resources-data`.
-- Shared keyed read that multiple screens can refresh or invalidate: use `createQuery()`.
-- Write with visible pending, error, result, and invalidation behavior: use `createMutation()`.
-
-## Do This In Order
-
-1. Design a stable, prefix-friendly query key.
-2. Keep fetch and mutation transport in an adapter or service boundary.
-3. Use `createQuery()` for the shared read and `createMutation()` for the write.
-4. Invalidate only the affected key or prefix after success.
-5. Preserve version, event ID, cursor, or command metadata when the UI must reason about projection lag.
-
-## Copy This Shape
-
-```ts
-import { createQuery, invalidate } from "@askrjs/askr/data";
-
-const user = createQuery({
-  key: `user:${id}`,
-  fetch: ({ signal }) => userService.getUser(id, { signal }),
-});
-
-await user.refresh();
-invalidate("user:");
-```
-
-## Mutation Shape
-
-```ts
-import { createMutation } from "@askrjs/askr/data";
-
-const saveUser = createMutation({
-  action: (input, { signal }) => userService.updateUser(input, { signal }),
-  affects: (input) => [`user:${input.id}`, "users:"],
-  afterSuccess: "invalidate",
-});
-
-await saveUser.execute({ id, name });
-```
-
-- Only use optimistic updates when rollback or refetch behavior is explicit.
-- If the backend is event-sourced, prefer truthful `pending-write` or `syncing` UI over pretending the projection already caught up.
-- Keep optimistic local intent separate from confirmed read-model state.
-
-## Event-Sourced Consistency
-
-Use this pattern when writes append events and reads come from projections:
-
-- Command success means the write was accepted, not necessarily that every read model is caught up.
-- Include command ID, aggregate ID, expected version, observed version, event ID, or projection cursor in mutation results when the backend exposes them.
-- Use `affects` and `afterSuccess: 'invalidate'` to mark affected queries as `pending-write` and refresh them.
-- Keep the old query data visible while `consistency` is `pending-write`, `refreshing`, or `stale`.
-- On stream reconnect or cursor gaps, invalidate the affected query prefix instead of replaying uncertain local state.
-- Use `isConsistent` to compare returned read data against expected versions or event IDs.
-- Use `reconcile` to retry while a projection is behind, with user-visible stale/syncing feedback.
-
-```ts
-const account = createQuery({
-  key: `account:${id}`,
-  fetch: ({ signal }) => accountsService.getAccount(id, { signal }),
-  isConsistent: (data) => data.version >= expectedVersion(),
-  reconcile: () => true,
-});
-```
-
-- Fetching directly in many leaf components.
-- Hiding writes inside presentational UI.
-- Cache keys that cannot be invalidated predictably.
-- Generic query clients or global state abstractions unless the app already owns one.
-- Optimistic updates without rollback or refetch.
-- Treating write acknowledgement as read-model convergence in event-sourced systems.
-- Cache keys that mix route-local UI state with shared server-state identity.
-
-## Validate
-
-- Query keys are stable and prefix-friendly.
-- `signal` reaches the service boundary.
-- Mutation pending and error states are visible outside the button that triggered them.
-- Success invalidates only the affected read model.
-- Event or version metadata is preserved when the UI needs to reason about catch-up.
-
-## Done When
-
-- The feature did not grow a second cache or state layer.
-
-## Handoff
-
-- Use `askr-api-integration` when DTO mapping or transport details are the real blocker.
-- Use `askr-error-loading-empty` when the hard part is presenting stale, syncing, or retry truth.
-- Use `askr-realtime-streaming` when queries must reconcile with live events.

package/skills/askr-query-mutation/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Query Mutation"
-  short_description: "Coordinate shared read/write state"
-  default_prompt: "Use $askr-query-mutation to model shared server state and writes."

package/skills/askr-realtime-streaming/SKILL.md

@@ -1,76 +0,0 @@
----
-name: askr-realtime-streaming
-description: Use when building Askr realtime UX with SSE, WebSocket, event streams, reconnects, cursors, cancellation, backpressure-aware UI, optimistic updates, projection lag, and event-sourced state.
----
-
-# Askr Realtime Streaming
-
-Use this for live data, event streams, and projection-driven UI. The goal is one clear stream owner, safe reconnect behavior, and bounded DOM and memory cost.
-
-## Use This When
-
-- You need SSE, WebSocket, or long-lived event streaming.
-- The UI depends on reconnect, cursor, or projection-lag behavior.
-- A timeline, operator log, or live table needs bounded updates.
-- You need to reconcile stream events with queries or feature-owned state.
-
-## Inspect First
-
-- Adapter support for SSE, WebSocket, polling, or long-running requests
-- Event schema: event ID, sequence, aggregate ID, type, timestamp, and payload
-- Query keys and mutation invalidation affected by streamed events
-- Reconnect and resume requirements
-
-## Do This In Order
-
-1. Own the stream lifecycle in a route or feature container, not a leaf row or list item.
-2. Preserve `lastEventId` or cursor for reconnect.
-3. Apply events idempotently by event ID or sequence.
-4. Detect gaps and refetch or invalidate the affected read model instead of guessing.
-5. Bound long-running buffers so memory and DOM cost stay predictable.
-6. Show `connected`, `reconnecting`, `stale`, or `failed` state when freshness matters.
-
-## Copy This Shape
-
-```ts
-const MAX_EVENTS = 200;
-
-function applyEvent(nextEvent: StreamEvent) {
-  setEvents((current) => {
-    if (current.some((event) => event.id === nextEvent.id)) {
-      return current;
-    }
-
-    return [...current, nextEvent].slice(-MAX_EVENTS);
-  });
-  setLastEventId(nextEvent.id);
-}
-```
-
-## Never Do These
-
-- Assuming streamed events arrive exactly once or in order.
-- Clearing the screen during reconnect.
-- Unbounded in-memory event lists.
-- Mixing transport code into pages or components.
-- Treating command success as projection success.
-
-## Validate
-
-- Reconnect resumes from a cursor or falls back to refetch.
-- Duplicate and out-of-order events are safe.
-- Projection lag has visible UI.
-- Stream teardown happens on navigation or unmount.
-
-## Done When
-
-- Stream ownership is clear and not buried in leaf components.
-- Reconnect, duplicate, gap, and teardown paths are handled.
-- Memory and DOM cost stay bounded for long-running screens.
-- Projection success is never inferred from command success alone.
-
-## Handoff
-
-- Use `askr-query-mutation` when stream events reconcile shared queries.
-- Use `askr-api-integration` when cursor, event ID, or transport shape is unclear.
-- Use `askr-observability-debugging` when reconnect failures or duplicate events need operator diagnostics.

package/skills/askr-realtime-streaming/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Realtime Streaming"
-  short_description: "Build realtime evented UX"
-  default_prompt: "Use $askr-realtime-streaming to build realtime Askr UI."

package/skills/askr-resources-data/SKILL.md

@@ -1,100 +0,0 @@
----
-name: askr-resources-data
-description: Use when loading lifecycle-aware async data in Askr with resource, cancellation signals, pending/error/value states, refresh behavior, route/container ownership, consistency-aware refreshes, and async anti-pattern cleanup.
----
-
-# Askr Resources Data
-
-Use this when one route or feature container owns an async read lifecycle. The goal is one clear async owner, explicit cancellation, and truthful refresh behavior.
-
-## Use This When
-
-- One route or feature container owns the read.
-- The read should cancel on unmount, navigation, or dependency change.
-- Children need plain data props instead of owning their own fetches.
-- The data does not need to live as shared keyed state across screens.
-
-## Inspect First
-
-- The nearest route or feature container that already owns async work.
-- The adapter or service that should receive `signal`.
-- Existing refresh or retry controls for the same surface.
-- Existing tests that cover load, retry, or cancellation behavior.
-
-## Use `resource()` Only When
-
-- The read belongs to one owner in one route or feature container.
-- The owner should cancel stale requests automatically.
-- The screen can keep old data during refresh when safe.
-
-If the same keyed server state must coordinate across screens, stop and use `askr-query-mutation` instead.
-
-## Do This In Order
-
-1. Put the `resource()` call in the smallest route or feature container that owns the data.
-2. Pass `signal` into the adapter or fetch layer.
-3. Keep route handlers synchronous.
-4. Pass `value`, `pending`, `error`, and `refresh()` downward as plain props.
-5. Keep stale data visible during refresh unless that would be unsafe.
-
-## Copy This Shape
-
-```tsx
-import { resource } from "@askrjs/askr/resources";
-
-function UserCard({ id }: { id: string }) {
-  const user = resource(
-    async ({ signal }) => {
-      const response = await fetch(`/api/users/${id}`, { signal });
-      return response.json();
-    },
-    [id],
-  );
-
-  if (user.pending || !user.value) return <p>Loading...</p>;
-  if (user.error) return <p role="alert">Unable to load user.</p>;
-  return <p>{user.value.name}</p>;
-}
-```
-
-## Owner Pattern
-
-```tsx
-function AccountsPage() {
-  const accounts = resource(({ signal }) => loadAccounts({ signal }), []);
-
-  return (
-    <AccountsScreen
-      accounts={accounts.value}
-      pending={accounts.pending}
-      error={accounts.error}
-      onRefresh={() => accounts.refresh()}
-    />
-  );
-}
-```
-
-- Async route components.
-- `useEffect`-style data loading.
-- Custom cancellation tokens when `signal` exists.
-- Hidden loading or error paths.
-- Fetching in generic UI primitives.
-- Route-local async ownership that should actually be shared keyed state.
-
-## Validate
-
-- The async owner is the smallest container that needs the data.
-- `signal` reaches the cancellable work.
-- Loading, empty, error, and retry paths are explicit.
-- Route handlers stay synchronous.
-- Refresh behavior is honest about stale data and projection lag.
-
-## Done When
-
-- The screen did not grow a parallel shared-state layer.
-
-## Handoff
-
-- Use `askr-query-mutation` when this data must become shared keyed state.
-- Use `askr-error-loading-empty` when the hard part is truthful state representation.
-- Use `askr-testing-determinism` to validate cancellation, retry, and refresh behavior.

package/skills/askr-resources-data/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Resources Data"
-  short_description: "Load cancellable lifecycle data"
-  default_prompt: "Use $askr-resources-data to load async data with resource()."

package/skills/askr-routing-layouts/SKILL.md

@@ -1,107 +0,0 @@
----
-name: askr-routing-layouts
-description: Use when defining Askr routes, route groups, page shells, index routes, fallback routes, navigation, auth requirements, route loaders, layout boundaries, or SPA/SSR/SSG shared route trees.
----
-
-# Askr Routing Layouts
-
-Use this for route registration, shell ownership, route metadata, and navigation. The goal is one obvious route tree that is registered before boot.
-
-## Use This When
-
-- You are adding, moving, or protecting a route.
-- You are changing a shell or layout boundary.
-- You need to attach an auth requirement or route policy.
-- You need to add route-aware navigation.
-
-## Inspect First
-
-- `src/main.tsx`
-- The app's route registry file
-- The nearest branch route file and `_layout.tsx`
-- Existing navigation components for the same branch
-- Tests that already cover routing or layout retention
-
-## Choose The Owner
-
-- `group()` for inherited layout, auth requirements, or policies without a path segment.
-- `page()` for a pathful shell that renders child route content.
-- `route()` for a leaf route.
-- `index()` only inside a `page()` scope.
-- `fallback()` at the root or inside a `page()` scope that owns the fallback.
-
-## Do This In Order
-
-1. Register the route in the existing route tree before app boot.
-2. Put auth requirements and policies on the narrowest route or group that owns them.
-3. Keep route components synchronous and put async work inside route-owned components or features.
-4. Keep navigation in `Link`, `navigate()`, and `currentRoute()` instead of local copies of route state.
-
-## Copy This Shape
-
-```tsx
-import { requireUser } from "@askrjs/auth";
-import { createRouteRegistry, fallback, group } from "@askrjs/askr/router";
-
-export const pageRegistry = createRouteRegistry(() => {
-  group({ layout: RootLayout }, () => {
-    group({ layout: PublicLayout }, () => {
-      registerPublicRoutes();
-    });
-    group({ layout: AppLayout, auth: requireUser() }, () => {
-      registerAppRoutes();
-    });
-    fallback(NotFoundPage);
-  });
-});
-```
-
-## Nested Example
-
-```tsx
-import { requirePermission } from "@askrjs/auth";
-import { fallback, index, page, route } from "@askrjs/askr/router";
-
-export function registerWorkspaceRoutes(): void {
-  page("/workspaces/{workspaceId}", WorkspaceLayout, () => {
-    index(WorkspaceOverviewPage);
-    route("settings", WorkspaceSettingsPage, {
-      auth: requirePermission("workspace.manage"),
-    });
-    route("members", WorkspaceMembersPage, {
-      auth: requirePermission("workspace.read"),
-    });
-    fallback(WorkspaceNotFoundPage);
-  });
-}
-```
-
-Use relative child paths inside `page()`. Put requirements and policies on the narrowest route or group that owns them.
-
-## Never Do These
-
-- Registering routes during render.
-- Calling `route()` inside components; use `currentRoute()` there.
-- Nesting `page()` inside `page()`.
-- Absolute child route paths inside `page()`.
-- Treating `group()` as a fallback scope.
-- Putting theme styling decisions in route registration.
-- Building a second router or page-local auth gate when route metadata already owns it.
-
-## Validate
-
-- The route tree is registered before boot.
-- Shared route behavior lives in `group()` instead of repeated route-local checks.
-- Child routes under `page()` use relative paths.
-- Fallback scope is explicit.
-- Navigation uses router primitives instead of local state copies.
-
-## Done When
-
-- The route tree is still the only route tree in the app.
-
-## Handoff
-
-- Use `askr-auth-access` when the next step is session or permission behavior.
-- Use `askr-project-structure` when routing work also adds new files.
-- Use `askr-testing-determinism` to validate route identity, fallback behavior, and layout retention.