create-monolayer-app 0.1.0-canary.1

package/template/.agents/skills/react-router/references/framework-mode.md

@@ -0,0 +1,213 @@
+# Framework Mode
+
+Framework Mode is React Router's full-stack mode. It uses the React Router Vite plugin, route config in `app/routes.ts`, route modules, generated route types, and rendering strategies such as SSR, SPA mode, and pre-rendering.
+
+Use this reference after the main skill identifies a Framework Mode app.
+
+## Read the Local Docs by Mode
+
+Start with:
+
+```txt
+react-router/docs/start/modes.md
+react-router/docs/start/framework/index.md
+```
+
+Then use the Framework docs under:
+
+```txt
+react-router/docs/start/framework/
+```
+
+Those files cover installation, routing, route modules, data loading, actions, navigation, pending UI, rendering, deploying, and testing. For task-specific details, read relevant files in:
+
+```txt
+react-router/docs/how-to/
+react-router/docs/explanation/
+```
+
+Always check the `[MODES: framework, ...]` marker in a doc before applying it.
+
+## Framework Shape
+
+Examples usually assume the default `appDirectory` of `app`. Check `react-router.config.ts` before assuming exact paths.
+
+Look for these files and conventions:
+
+```txt
+react-router.config.ts
+app/root.tsx
+app/routes.ts
+app/routes/**/*.tsx
+route modules importing from ./+types/...
+```
+
+Typical route module:
+
+```tsx
+import type { Route } from "./+types/product";
+
+export async function loader({ params }: Route.LoaderArgs) {
+  return { product: await getProduct(params.productId) };
+}
+
+export default function Product({ loaderData }: Route.ComponentProps) {
+  return <h1>{loaderData.product.name}</h1>;
+}
+```
+
+## Route Configuration
+
+Framework apps use `app/routes.ts`. Many apps use file-system routing via `flatRoutes()`, but manual route config is also supported.
+
+Before editing routes, read:
+
+```txt
+react-router/docs/start/framework/routing.md
+```
+
+If the app uses file-route conventions, read:
+
+```txt
+react-router/docs/how-to/file-route-conventions.md
+```
+
+## Route Modules
+
+Route modules are the main unit of Framework Mode. Before adding or changing route exports, read:
+
+```txt
+react-router/docs/start/framework/route-module.md
+```
+
+Common exports include:
+
+| Export                            | Use                                                                 |
+| --------------------------------- | ------------------------------------------------------------------- |
+| `default`                         | Route component rendered for the match                              |
+| `loader`                          | Server data loading for SSR/pre-rendering/server data requests      |
+| `clientLoader`                    | Browser-only data loading or supplementing server loader data       |
+| `action`                          | Server mutation called by `<Form>`, `useSubmit`, or fetchers        |
+| `clientAction`                    | Browser-only mutation or client-side wrapper around a server action |
+| `ErrorBoundary`                   | UI for errors thrown by this route's loaders/actions/component      |
+| `HydrateFallback`                 | Initial fallback while client loader hydration runs                 |
+| `links` / `meta`                  | Route document links and metadata                                   |
+| `handle`                          | Arbitrary route metadata consumed via `useMatches`                  |
+| `shouldRevalidate`                | Overrides default loader revalidation behavior                      |
+| `middleware` / `clientMiddleware` | Server/client request pipeline hooks when enabled                   |
+
+Use generated `Route.*` types from `./+types/<route>` for route module args and props.
+
+## Layout and Root Route Rules
+
+- `app/root.tsx` is the root route and should contain global document/app shell concerns.
+- Put global providers, app-wide nav, app-wide footer, scripts/meta/links, and document structure in `root.tsx` when appropriate.
+- Use nested routes/layout routes for section-specific layouts.
+- Do not flatten routes that should share UI or data boundaries.
+
+Useful docs:
+
+```txt
+react-router/docs/explanation/special-files.md
+react-router/docs/start/framework/routing.md
+```
+
+## Data and Mutations
+
+Before working on route data:
+
+```txt
+react-router/docs/start/framework/data-loading.md
+react-router/docs/start/framework/actions.md
+```
+
+Framework rules:
+
+- Load route data with `loader` or `clientLoader`.
+- Mutate route data with `action` or `clientAction`.
+- Prefer route loaders/actions over ad hoc `useEffect` fetching for route data.
+- Use `data()`/Responses and redirects according to the docs.
+- Let React Router revalidate after actions unless the docs point you to `shouldRevalidate`.
+- In SSR/server data routes, keep Node-only/database code in server-only modules and call it from `loader`/`action`, not from browser-rendered component code.
+
+Common patterns:
+
+- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors from `Route.ComponentProps["actionData"]` or `fetcher.data`.
+- Missing record in a loader: throw `data("Not Found", { status: 404 })` and render the route `ErrorBoundary`.
+- Search/filter data: parse the route request URL/search params in the loader so the URL is shareable and bookmarkable.
+
+## Forms, Fetchers, and Pending UI
+
+For forms and pending UI, read:
+
+```txt
+react-router/docs/start/framework/actions.md
+react-router/docs/start/framework/pending-ui.md
+react-router/docs/how-to/fetchers.md
+react-router/docs/explanation/form-vs-fetcher.md
+```
+
+Rules of thumb:
+
+- Search/filter form that updates the URL: `<Form method="get">`.
+- Mutation that should change URL/history or redirect after completion: `<Form method="post">`.
+- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.
+- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.
+
+## Type Safety
+
+Before changing generated route types or typed URL behavior, read:
+
+```txt
+react-router/docs/how-to/route-module-type-safety.md
+react-router/docs/explanation/type-safety.md
+```
+
+Rules:
+
+- Import types from `./+types/<route>`.
+- Use `Route.LoaderArgs`, `Route.ActionArgs`, `Route.ComponentProps`, etc.
+- Use type-only imports where appropriate.
+- Do not edit generated `.react-router/types` files.
+
+## Metadata
+
+Before changing `meta`, read:
+
+```txt
+react-router/docs/how-to/meta.md
+react-router/docs/start/framework/route-module.md
+```
+
+Important: `meta` receives `loaderData`; do not use deprecated `data` args.
+
+## Rendering Strategy
+
+Framework Mode can be SSR, SPA, pre-rendered, or mixed depending on config and route behavior. Before changing rendering behavior, read:
+
+```txt
+react-router/docs/start/framework/rendering.md
+react-router/docs/how-to/spa.md
+react-router/docs/how-to/pre-rendering.md
+react-router/docs/explanation/hydration.md
+```
+
+## Middleware, Sessions, and Auth
+
+Before implementing middleware or auth/session flows, read:
+
+```txt
+react-router/docs/how-to/middleware.md
+react-router/docs/explanation/sessions-and-cookies.md
+```
+
+Middleware and context APIs are version/config sensitive. Check the installed React Router version and the app's `react-router.config.ts` before implementing.
+
+## RSC Framework
+
+If this Framework app uses `unstable_reactRouterRSC` or `@vitejs/plugin-rsc`, also read:
+
+```txt
+references/rsc.md
+react-router/docs/how-to/react-server-components.md
+```

package/template/.agents/skills/react-router/references/rsc.md

@@ -0,0 +1,90 @@
+# React Server Components (RSC)
+
+React Router's RSC support is unstable and exists in two variants:
+
+- **RSC Framework Mode**: Framework Mode with the unstable RSC Vite plugin.
+- **RSC Data Mode**: lower-level RSC runtime APIs and manual bundler/server integration.
+
+Use this reference in addition to `framework-mode.md` or `data-mode.md` after the main skill identifies an RSC app.
+
+## Read the Local RSC Docs
+
+Start with:
+
+```txt
+react-router/docs/how-to/react-server-components.md
+```
+
+Then read the relevant base mode docs:
+
+```txt
+react-router/docs/start/framework/
+react-router/docs/start/data/
+```
+
+RSC docs may describe differences from non-RSC mode rather than repeating every Framework/Data concept, so keep both layers in mind.
+
+## Detect RSC Framework Mode
+
+Look for:
+
+- `unstable_reactRouterRSC` imported from `@react-router/dev/vite`
+- `@vitejs/plugin-rsc`
+- `vite.config.ts` with `plugins: [reactRouterRSC(), rsc()]`
+- Framework route modules plus RSC route exports
+- RSC entry files such as `entry.rsc`
+
+RSC Framework Mode uses a different Vite plugin from non-RSC Framework Mode. Do not swap it for the regular `reactRouter()` plugin.
+
+## Detect RSC Data Mode
+
+Look for:
+
+- `unstable_RSCRouteConfig`
+- route config passed to lower-level RSC APIs
+- APIs such as `unstable_matchRSCServerRequest`, `unstable_routeRSCServerRequest`, `unstable_RSCHydratedRouter`, or `unstable_RSCStaticRouter`
+- custom bundler/server setup around RSC
+
+RSC Data Mode is more manual than RSC Framework Mode. Match the app's bundler and server abstractions before changing routes or entries.
+
+## RSC Route Module Differences
+
+In RSC Framework Mode, many normal Framework Mode concepts still apply, but routes can use server component exports.
+
+Important route-module concepts from the RSC docs include:
+
+- `ServerComponent` instead of the usual client `default` component
+- `ServerErrorBoundary` paired with `ErrorBoundary`
+- `ServerLayout` paired with `Layout`
+- `ServerHydrateFallback` paired with `HydrateFallback`
+- server-rendered React elements returned from loaders/actions
+
+A route module cannot export both the normal client component and its server component counterpart for the same role. Read the RSC docs before adding these exports.
+
+## Client/Server Boundaries
+
+RSC code must respect React's client/server split:
+
+- Use `"use client"` for components that need hooks, browser APIs, or event handlers.
+- Use server-only modules for server data access and secrets.
+- In RSC Framework Mode, prefer the `server-only` and `client-only` boundary imports described in the docs.
+- Do not assume `.server`/`.client` file naming works the same way in RSC Framework Mode; read the RSC docs before relying on those conventions.
+
+## Data Loading in RSC
+
+RSC changes where data can be loaded:
+
+- Server Components can fetch data directly on the server.
+- Loaders/actions may still exist and can have RSC-specific behavior.
+- Client components still need client-safe data and cannot directly access server-only modules.
+
+When choosing between a server component fetch, a loader, and a client loader/action, follow the RSC docs and match existing app patterns.
+
+## Stability
+
+RSC APIs are explicitly unstable. Before implementing or refactoring RSC code:
+
+- Check the installed React Router version.
+- Check the installed `@vitejs/plugin-rsc` version.
+- Read the app's existing RSC entry/config files.
+- Prefer minimal changes that match current patterns.

package/template/.claude/CLAUDE.md

@@ -0,0 +1,126 @@
+# Ultracite Code Standards
+
+This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting.
+
+## Quick Reference
+
+- **Format code**: `npm exec -- ultracite fix`
+- **Check for issues**: `npm exec -- ultracite check`
+- **Diagnose setup**: `npm exec -- ultracite doctor`
+
+Oxlint + Oxfmt (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable.
+
+---
+
+## Core Principles
+
+Write code that is **accessible, performant, type-safe, and maintainable**. Focus on clarity and explicit intent over brevity.
+
+### Type Safety & Explicitness
+
+- Use explicit types for function parameters and return values when they enhance clarity
+- Prefer `unknown` over `any` when the type is genuinely unknown
+- Use const assertions (`as const`) for immutable values and literal types
+- Leverage TypeScript's type narrowing instead of type assertions
+- Use meaningful variable names instead of magic numbers - extract constants with descriptive names
+
+### Modern JavaScript/TypeScript
+
+- Use arrow functions for callbacks and short functions
+- Prefer `for...of` loops over `.forEach()` and indexed `for` loops
+- Use optional chaining (`?.`) and nullish coalescing (`??`) for safer property access
+- Prefer template literals over string concatenation
+- Use destructuring for object and array assignments
+- Use `const` by default, `let` only when reassignment is needed, never `var`
+
+### Async & Promises
+
+- Always `await` promises in async functions - don't forget to use the return value
+- Use `async/await` syntax instead of promise chains for better readability
+- Handle errors appropriately in async code with try-catch blocks
+- Don't use async functions as Promise executors
+
+### React & JSX
+
+- Use function components over class components
+- Call hooks at the top level only, never conditionally
+- Specify all dependencies in hook dependency arrays correctly
+- Use the `key` prop for elements in iterables (prefer unique IDs over array indices)
+- Nest children between opening and closing tags instead of passing as props
+- Don't define components inside other components
+- Use semantic HTML and ARIA attributes for accessibility:
+  - Provide meaningful alt text for images
+  - Use proper heading hierarchy
+  - Add labels for form inputs
+  - Include keyboard event handlers alongside mouse events
+  - Use semantic elements (`<button>`, `<nav>`, etc.) instead of divs with roles
+
+### Error Handling & Debugging
+
+- Remove `console.log`, `debugger`, and `alert` statements from production code
+- Throw `Error` objects with descriptive messages, not strings or other values
+- Use `try-catch` blocks meaningfully - don't catch errors just to rethrow them
+- Prefer early returns over nested conditionals for error cases
+
+### Code Organization
+
+- Keep functions focused and under reasonable cognitive complexity limits
+- Extract complex conditions into well-named boolean variables
+- Use early returns to reduce nesting
+- Prefer simple conditionals over nested ternary operators
+- Group related code together and separate concerns
+
+### Security
+
+- Add `rel="noopener"` when using `target="_blank"` on links
+- Avoid `dangerouslySetInnerHTML` unless absolutely necessary
+- Don't use `eval()` or assign directly to `document.cookie`
+- Validate and sanitize user input
+
+### Performance
+
+- Avoid spread syntax in accumulators within loops
+- Use top-level regex literals instead of creating them in loops
+- Prefer specific imports over namespace imports
+- Avoid barrel files (index files that re-export everything)
+- Use proper image components (e.g., Next.js `<Image>`) over `<img>` tags
+
+### Framework-Specific Guidance
+
+**Next.js:**
+
+- Use Next.js `<Image>` component for images
+- Use `next/head` or App Router metadata API for head elements
+- Use Server Components for async data fetching instead of async Client Components
+
+**React 19+:**
+
+- Use ref as a prop instead of `React.forwardRef`
+
+**Solid/Svelte/Vue/Qwik:**
+
+- Use `class` and `for` attributes (not `className` or `htmlFor`)
+
+---
+
+## Testing
+
+- Write assertions inside `it()` or `test()` blocks
+- Avoid done callbacks in async tests - use async/await instead
+- Don't use `.only` or `.skip` in committed code
+- Keep test suites reasonably flat - avoid excessive `describe` nesting
+
+## When Oxlint + Oxfmt Can't Help
+
+Oxlint + Oxfmt's linter will catch most issues automatically. Focus your attention on:
+
+1. **Business logic correctness** - Oxlint + Oxfmt can't validate your algorithms
+2. **Meaningful naming** - Use descriptive names for functions, variables, and types
+3. **Architecture decisions** - Component structure, data flow, and API design
+4. **Edge cases** - Handle boundary conditions and error states
+5. **User experience** - Accessibility, performance, and usability considerations
+6. **Documentation** - Add comments for complex logic, but prefer self-documenting code
+
+---
+
+Most formatting and common issues are automatically fixed by Oxlint + Oxfmt. Run `npm exec -- ultracite fix` before committing to ensure compliance.

package/template/.dockerignore

@@ -0,0 +1,4 @@
+.react-router
+build
+node_modules
+README.md

package/template/.vscode/settings.json

@@ -0,0 +1,62 @@
+{
+  "editor.defaultFormatter": "esbenp.prettier-vscode",
+  "editor.formatOnPaste": true,
+  "editor.formatOnSave": true,
+  "emmet.showExpandedAbbreviation": "never",
+  "js/ts.tsdk.path": "node_modules/typescript/lib",
+  "js/ts.tsdk.promptToUseWorkspaceVersion": true,
+  "[astro]": {
+    "editor.defaultFormatter": "astro-build.astro-vscode"
+  },
+  "[css]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[graphql]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[handlebars]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[html]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[javascript]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[javascriptreact]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[json]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[jsonc]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[less]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[markdown]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[scss]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[typescript]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[typescriptreact]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[vue-html]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[vue]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "[yaml]": {
+    "editor.defaultFormatter": "oxc.oxc-vscode"
+  },
+  "editor.codeActionsOnSave": {
+    "source.fixAll.oxc": "explicit"
+  }
+}

package/template/AGENTS.md

@@ -0,0 +1,126 @@
+# Ultracite Code Standards
+
+This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting.
+
+## Quick Reference
+
+- **Format code**: `npm exec -- ultracite fix`
+- **Check for issues**: `npm exec -- ultracite check`
+- **Diagnose setup**: `npm exec -- ultracite doctor`
+
+Oxlint + Oxfmt (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable.
+
+---
+
+## Core Principles
+
+Write code that is **accessible, performant, type-safe, and maintainable**. Focus on clarity and explicit intent over brevity.
+
+### Type Safety & Explicitness
+
+- Use explicit types for function parameters and return values when they enhance clarity
+- Prefer `unknown` over `any` when the type is genuinely unknown
+- Use const assertions (`as const`) for immutable values and literal types
+- Leverage TypeScript's type narrowing instead of type assertions
+- Use meaningful variable names instead of magic numbers - extract constants with descriptive names
+
+### Modern JavaScript/TypeScript
+
+- Use arrow functions for callbacks and short functions
+- Prefer `for...of` loops over `.forEach()` and indexed `for` loops
+- Use optional chaining (`?.`) and nullish coalescing (`??`) for safer property access
+- Prefer template literals over string concatenation
+- Use destructuring for object and array assignments
+- Use `const` by default, `let` only when reassignment is needed, never `var`
+
+### Async & Promises
+
+- Always `await` promises in async functions - don't forget to use the return value
+- Use `async/await` syntax instead of promise chains for better readability
+- Handle errors appropriately in async code with try-catch blocks
+- Don't use async functions as Promise executors
+
+### React & JSX
+
+- Use function components over class components
+- Call hooks at the top level only, never conditionally
+- Specify all dependencies in hook dependency arrays correctly
+- Use the `key` prop for elements in iterables (prefer unique IDs over array indices)
+- Nest children between opening and closing tags instead of passing as props
+- Don't define components inside other components
+- Use semantic HTML and ARIA attributes for accessibility:
+  - Provide meaningful alt text for images
+  - Use proper heading hierarchy
+  - Add labels for form inputs
+  - Include keyboard event handlers alongside mouse events
+  - Use semantic elements (`<button>`, `<nav>`, etc.) instead of divs with roles
+
+### Error Handling & Debugging
+
+- Remove `console.log`, `debugger`, and `alert` statements from production code
+- Throw `Error` objects with descriptive messages, not strings or other values
+- Use `try-catch` blocks meaningfully - don't catch errors just to rethrow them
+- Prefer early returns over nested conditionals for error cases
+
+### Code Organization
+
+- Keep functions focused and under reasonable cognitive complexity limits
+- Extract complex conditions into well-named boolean variables
+- Use early returns to reduce nesting
+- Prefer simple conditionals over nested ternary operators
+- Group related code together and separate concerns
+
+### Security
+
+- Add `rel="noopener"` when using `target="_blank"` on links
+- Avoid `dangerouslySetInnerHTML` unless absolutely necessary
+- Don't use `eval()` or assign directly to `document.cookie`
+- Validate and sanitize user input
+
+### Performance
+
+- Avoid spread syntax in accumulators within loops
+- Use top-level regex literals instead of creating them in loops
+- Prefer specific imports over namespace imports
+- Avoid barrel files (index files that re-export everything)
+- Use proper image components (e.g., Next.js `<Image>`) over `<img>` tags
+
+### Framework-Specific Guidance
+
+**Next.js:**
+
+- Use Next.js `<Image>` component for images
+- Use `next/head` or App Router metadata API for head elements
+- Use Server Components for async data fetching instead of async Client Components
+
+**React 19+:**
+
+- Use ref as a prop instead of `React.forwardRef`
+
+**Solid/Svelte/Vue/Qwik:**
+
+- Use `class` and `for` attributes (not `className` or `htmlFor`)
+
+---
+
+## Testing
+
+- Write assertions inside `it()` or `test()` blocks
+- Avoid done callbacks in async tests - use async/await instead
+- Don't use `.only` or `.skip` in committed code
+- Keep test suites reasonably flat - avoid excessive `describe` nesting
+
+## When Oxlint + Oxfmt Can't Help
+
+Oxlint + Oxfmt's linter will catch most issues automatically. Focus your attention on:
+
+1. **Business logic correctness** - Oxlint + Oxfmt can't validate your algorithms
+2. **Meaningful naming** - Use descriptive names for functions, variables, and types
+3. **Architecture decisions** - Component structure, data flow, and API design
+4. **Edge cases** - Handle boundary conditions and error states
+5. **User experience** - Accessibility, performance, and usability considerations
+6. **Documentation** - Add comments for complex logic, but prefer self-documenting code
+
+---
+
+Most formatting and common issues are automatically fixed by Oxlint + Oxfmt. Run `npm exec -- ultracite fix` before committing to ensure compliance.