robodev 0.12.0 → 0.14.0

package/templates/auth-chat/.rulesync/rules/frontend-query-autocomplete.md

@@ -0,0 +1,29 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Frontend QueryAutocomplete usage for database-entity dropdowns with generated label queries and queryParams."
+globs: ["apps/fe/src/**/*.{ts,tsx}"]
+cursor:
+  alwaysApply: false
+  description: "Apply when a frontend form or filter needs a dropdown/search picker of database entities."
+  globs: ["apps/fe/src/**/*.{ts,tsx}"]
+---
+
+# Frontend QueryAutocomplete
+
+Use this pattern whenever the UI needs a dropdown/search picker of entities from the database, such as selecting a alien, company, project, user, category, or any other related row in a form or filter.
+
+Use `QueryAutocomplete` for these database-entity dropdowns. It should call a generated labels endpoint such as `AliensQueries.useListLabels`, not load full related records into the form.
+
+Reference examples:
+
+- Create form: `apps/fe/src/components/features/planets/list/PlanetCreateModal.tsx`
+- Edit form: `apps/fe/src/components/features/planets/details/PlanetEditPage.tsx`
+- Filter control: `apps/fe/src/components/features/planets/list/PlanetsFilters.tsx`
+  The matching labels endpoint input schema must define `search`, usually as `search: z.string().optional()`, because `QueryAutocomplete` passes search text through that parameter.
+
+If a labels endpoint needs extra context, pass it through `QueryAutocomplete` with `queryParams`. The matching labels endpoint input schema can include optional parameters beyond `search`, such as extra filters or flags that control how rows map into `{ id, label }`.
+
+When the autocomplete belongs to a form, import it from `@povio/ui/tanstack` and prefer `field={{ form, name }}`. When it belongs to filters, read and write through the `useFilters` store.
+
+Real app features should use generated labels queries from `@/openapi`.

package/templates/auth-chat/.rulesync/rules/frontend-tables-and-lists.md

@@ -0,0 +1,34 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Frontend list and table patterns for grids, Table, InfiniteTable, filters, and sorting."
+globs: ["apps/fe/src/**/*.{ts,tsx}"]
+cursor:
+  alwaysApply: false
+  description: "Apply when building or changing list pages, grids, tables, filters, sorting, pagination, or row actions."
+  globs: ["apps/fe/src/**/*.{ts,tsx}"]
+---
+
+# Frontend Tables And Lists
+
+The planets feature intentionally shows multiple list patterns while the template is still a prototype:
+
+- Demo switcher: `apps/fe/src/components/features/planets/list/PlanetsPage.tsx`
+- Grid list: `apps/fe/src/components/features/planets/list/PlanetsGridPage.tsx`
+- Table list: `apps/fe/src/components/features/planets/list/PlanetsTablePage.tsx`
+- Infinite table list: `apps/fe/src/components/features/planets/list/PlanetsInfiniteTablePage.tsx`
+- Table wrappers and actions: `apps/fe/src/components/features/planets/list/table/*`
+
+The `Segment` in `PlanetsPage` is demo-only. Real feature pages should usually choose one list pattern and use it consistently.
+
+Prefer paginated API queries for database-backed collections. Use regular generated list queries only for data that is guaranteed to stay short, such as enums, compact option lists, or label-style endpoints.
+
+Use `Table` from `@povio/ui` for small bounded table lists and `InfiniteTable` when incremental loading is useful for the feature. Infinite tables require a paginated backend endpoint and generated `use<Endpoint>Infinite` query. Even non-infinite collection views should normally be backed by a paginated endpoint unless the collection is intentionally bounded.
+
+When a feature needs filters, define a filter schema on the API model, expose it through OpenAPI when useful, and use `useFilters` on the frontend. Put filter controls in a focused component such as `PlanetsFilters`. Use `as="filter"` on Povio UI filter controls.
+
+When a feature needs sorting, expose an enum of sortable keys from the API layer and pass the generated enum schema into `dynamicColumns({ options: { sortable } })`. Use `useSorting` on the frontend and pass its `order` string to the generated query.
+
+Use wrapper components around table primitives. A table wrapper should accept `TableWrapperProps<T>` or `InfiniteTableWrapperProps<T>` from `@povio/ui` and spread props into `Table` or `InfiniteTable`, while defining columns locally with a `getColumns` helper above the component.
+
+Keep per-row actions in a small action component, such as `PlanetsTableActions`, and use a shared row-action wrapper when available so clicks do not accidentally trigger row navigation.

package/templates/auth-chat/.rulesync/rules/frontend-translations.md

@@ -0,0 +1,26 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Frontend translation key structure and no-hardcoded-text conventions."
+globs: ["apps/fe/src/**/*.{ts,tsx,json}"]
+cursor:
+  alwaysApply: false
+  description: "Apply when adding or changing frontend user-facing text, locale files, or translation keys."
+  globs: ["apps/fe/src/**/*.{ts,tsx,json}"]
+---
+
+# Frontend Translations
+
+Do not hardcode user-facing frontend text. Add copy to locale files and access it through `useTranslation`.
+
+Translation key structure should generally follow the feature/component tree. The planets feature is the current reference example:
+
+- `planets.page.*`
+- `planets.views.*`
+- `planets.filters.*`
+- `planets.createModal.*`
+- `planets.editModal.*`
+- `planets.table.*`
+- `planets.detail.*`
+
+When Slovenian translations are required, preserve real Slovenian characters with carons, especially Unicode `U+0161`, `U+010D`, and `U+017E`. Do not leave mojibake or replacement-character artifacts in locale files.

package/templates/auth-chat/.rulesync/rules/project-overview.md

@@ -0,0 +1,32 @@
+---
+root: true
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Project overview and Rulesync source-of-truth guidance."
+globs: ["**/*"]
+cursor:
+  alwaysApply: true
+  description: "Project overview and Rulesync source-of-truth guidance."
+  globs: ["**/*"]
+---
+
+# Space starter AI rules
+
+This project is a Vite React frontend in `apps/fe` plus a Robodev backend at the **repository root** (`database.ts` + `api/**/*.ts` using `@robodev-ai/sdk`). There is no Expo / mobile app in this starter. End-user auth is reserved on the project host at `/api/user/*`. There is no in-browser fake backend.
+
+`robodev deploy` from this root uploads schema and APIs. It does not host the Povio SPA. Run the UI with bun in `apps/fe`.
+
+Shared AI rules and skills are authored in `.rulesync/`. Generated files for Codex, Claude Code, and Cursor are local outputs and should be regenerated with `bun rules:gen`.
+
+The demo is a shared chat room plus an authenticated invite-email form. Signed-in users read and post on `GET/POST /api/messages`. Invites go through `POST /api/invite` (`auth: "required"`); posting a chat message does not send email. Do not add `api/user/**`.
+
+When an app has multiple user roles with distinct UI or business workflows, use the conditional role-based app structure rule. Do not apply role splitting to simple single-role apps or small permission differences.
+
+Use the more specific generated rules for:
+
+- Robodev `defineDatabase` tables in `database.ts`.
+- Robodev `defineApi` routes in `api/`.
+- Reserved `/api/user/*` auth contracts (do not implement `api/user/**` in the project).
+- Frontend API boundaries around generated `@/openapi` queries and models.
+- Povio UI and semantic Tailwind token usage.
+- Frontend forms, tables/lists, `QueryAutocomplete`, translations, and component structure.
+- Role-based frontend structure when the app has multiple distinct user roles.

package/templates/auth-chat/.rulesync/rules/robodev-api.md

@@ -0,0 +1,30 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Robodev defineApi file routes and handler conventions."
+globs: ["api/**/*.ts"]
+cursor:
+  alwaysApply: false
+  description: "Apply when editing Starbase API routes."
+  globs: ["api/**/*.ts"]
+---
+
+# Robodev API
+
+Project APIs live in `api/`. `api/planets.ts` is served at `/planets` and `/api/planets`. Prefer the `/api/...` path in OpenAPI and frontend clients.
+
+## File layout
+
+- `api/foo.ts` → `/api/foo`
+- `api/foo/[id].ts` → `/api/foo/:id`
+- Export `get` / `post` / `put` / `patch` / `delete` as `defineApi(...)`.
+- Shared helpers belong in `api/_lib.ts`. Do not export `defineApi` from `_lib.ts`.
+- Do not add `api/user/**`. Those paths are reserved for Robodev Auth.
+
+## Handlers
+
+- Use `auth: "required"` on routes that Tiny marked authenticated.
+- Handler context includes `db`, `user`, `email`, `storage`, `params`, `query`, `body`.
+- Return JSON for 200, or `{ status, body }` for errors (404/403/400).
+- Keep request/response shapes compatible with `openapi.json` so OpenAPI codegen stays stable.
+- After changing public contracts, update `openapi.json` if needed and run `bun openapi:gen` from `apps/fe`.

package/templates/auth-chat/.rulesync/rules/robodev-auth.md

@@ -0,0 +1,40 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Reserved Robodev /api/user auth contracts."
+globs: ["**/*.ts", "apps/fe/src/**/*.{ts,tsx}"]
+cursor:
+  alwaysApply: false
+  description: "Apply when touching auth, login, register, or /api/user clients."
+  globs:
+    [
+      "database.ts",
+      "api/**/*.ts",
+      "apps/fe/src/components/features/auth/**/*.{ts,tsx}",
+      "apps/fe/src/clients/**/*.ts",
+    ]
+---
+
+# Robodev Auth
+
+End-user auth is reserved on the project host. Do not implement `api/user/**` in this project.
+
+## Contracts
+
+| Method  | Path                                      | Notes                                                   |
+| ------- | ----------------------------------------- | ------------------------------------------------------- |
+| POST    | `/api/user/auth/login`                    | `{ email, password }` → `{ accessToken, refreshToken }` |
+| POST    | `/api/user/auth/register`                 | password min 12, 201, token pair                        |
+| POST    | `/api/user/auth/refresh`                  | `{ refreshToken }` → new pair                           |
+| GET     | `/api/user/auth/magic-link`               | query `email`, generic status                           |
+| GET     | `/api/user/auth/magic-link/callback`      | query `code` → tokens                                   |
+| POST    | `/api/user/auth/forgot-password`          | `{ email }`                                             |
+| POST    | `/api/user/auth/forgot-password/callback` | `{ code, password }`                                    |
+| GET     | `/api/user/auth/google`                   | start OAuth; `redirect_uri` required                    |
+| GET/PUT | `/api/user/me`                            | flat `{ id, name, email }`                              |
+
+Access tokens last 15 minutes. Refresh tokens last 30 days. Frontend stores both and refreshes on 401 via `UserAuthApi.accessToken`.
+
+Error `code` is top-level: `invalid-credentials`, `identity-already-exists`, `identity-not-found`, `nonce-invalid`.
+
+Codegen operationIds stay Tiny-shaped (`UserAuthLocalPasswordController_login`, `UserMeController_get`, …) in `openapi.json`.

package/templates/auth-chat/.rulesync/rules/robodev-database.md

@@ -0,0 +1,22 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Robodev database.ts Drizzle schema and deploy sync."
+globs: ["database.ts"]
+cursor:
+  alwaysApply: false
+  description: "Apply when editing the Starbase database schema."
+  globs: ["database.ts"]
+---
+
+# Robodev Database
+
+The backend schema lives in `database.ts` at the project root. Default-export `defineDatabase` with Drizzle `pgTable` definitions. `robodev deploy` from this root creates or syncs the named Postgres database. There are no migration files.
+
+## Rules
+
+- Import table helpers from `@robodev-ai/sdk` (`pgTable`, `uuid`, `text`, `timestamp`, `integer`, and query helpers).
+- Do not recreate User or auth tables. End users live in platform `robodev_auth`. Store `userId` as `text` matching `ctx.user.id`.
+- Prefer scalar columns and foreign keys. Destructive drops need deploy confirmation or `--force`.
+- Export named tables so API files can import them from `../database` or `api/_lib.ts`.
+- Seed demo rows in API handlers on first read (see `api/_lib.ts` `ensureSeed`), not with a separate seed runner.

package/templates/auth-chat/.rulesync/rules/role-based-app-structure.md

@@ -0,0 +1,36 @@
+---
+root: false
+targets: ["claudecode", "codexcli", "cursor"]
+description: "Conditional role-based frontend and API structure for apps with distinct user roles."
+globs: ["apps/fe/src/**/*.{ts,tsx}", "api/**/*.ts"]
+cursor:
+  alwaysApply: false
+  description: "Apply only when an app has multiple user roles with distinct UI surfaces or business workflows."
+  globs: ["apps/fe/src/**/*.{ts,tsx}", "api/**/*.ts"]
+---
+
+# Role-Based App Structure
+
+Apply this rule only when the app has multiple user roles with meaningfully different UI surfaces or business workflows. For single-role apps or small permission differences, keep normal feature-based structure and express authorization in handlers, ACL metadata, or UI affordances.
+
+## Frontend Structure
+
+Split role-specific frontend code by role first:
+
+- `apps/fe/src/components/features/<role>/<feature>/...` for role-owned feature UI, such as `admin/companies`, `manager/projects`, or `worker/timesheets`.
+- `apps/fe/src/pages/(private)/(<role>)/...` for role-owned private routes and layout guards.
+- Shared auth, profile, layout, and role-neutral UI should stay outside role folders.
+
+When two roles touch the same entity with different screens or permissions, prefer separate role-owned feature components over a single component with many role branches.
+
+## API Structure
+
+Create role-prefixed `defineApi` files for role-owned behavior even when the backing table is shared. For example, use `api/manager/projects.ts` and `api/worker/projects.ts` when managers can create projects while workers can only list assigned ones.
+
+Role-prefixed routes should keep the role visible across the API surface:
+
+- Files: `api/<role>/<resource>.ts`, such as `api/manager/projects.ts`.
+- HTTP paths: `/api/<role>/<resource>`, such as `/api/manager/projects/paginate`.
+- Generated client modules should follow the same names.
+
+Keep shared auth, user, and media contracts role-neutral. Auth stays reserved at `/api/user/*`.

package/templates/auth-chat/.rulesync/skills/media-feature/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: media-feature
+description: "Use when adding or changing feature-level media/file upload support or frontend FileUpload handling."
+targets: ["claudecode", "codexcli", "cursor"]
+codexcli:
+  short-description: Add or update media upload support for features.
+---
+
+# Media Feature Skill
+
+Preserve the upload contract:
+
+1. Frontend selects a `File`.
+2. Frontend calls `MediaQueries.useUploadRequest` with metadata only (`POST /api/files/presigned-url`).
+3. Frontend uploads bytes to the returned URL (`POST /api/files/upload` via Starbase `ctx.storage`).
+4. Feature create/update submits only `image: { id }`.
+5. Feature reads resolve that ID to `image: { id, url }`.
+
+Never send `File`, `Blob`, base64, or raw bytes in a feature create/update request.
+
+Media metadata lives in the `media` table in `database.ts`. Bytes live in Robodev storage. Planet images use resource name `planet-image`.

package/templates/auth-chat/.rulesync/skills/povio-ui-styling/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: povio-ui-styling
+description: Mandatory first skill for any Tiny Template web frontend UI work in apps/fe. Load and apply it before other frontend, design, UX, accessibility, responsive, animation, or performance skills when creating, changing, reviewing, debugging, polishing, or refactoring pages and React components. It requires checking and using @povio/ui primitives before raw HTML or custom controls, and governs UIConfig defaults, UIOverrides, Tailwind utilities, semantic tokens, shared UI wrappers, and dedicated CSS files.
+---
+
+# Povio UI Styling
+
+Apply the narrowest styling layer that expresses the intended scope. Preserve one source of truth for each visual rule.
+
+## Priority and Coordination
+
+This is the foundation skill for every UI task under `apps/fe`. Apply it first, before broader design, UX, accessibility, animation, responsive, or React performance skills. Those skills may improve the result, but they must preserve the component and styling decisions defined here.
+
+Use this skill for all work that creates, changes, reviews, or diagnoses visible or interactive frontend UI, including:
+
+- Pages, layouts, navigation, dashboards, cards, lists, and empty states
+- Forms, filters, search, inputs, validation, uploads, and settings
+- Buttons, links, menus, dialogs, drawers, popovers, tooltips, and toasts
+- Tables, pagination, tags, badges, typography, icons, and loading states
+- Responsive behavior, theming, accessibility, motion, and visual polish
+- Component extraction, shared wrappers, design-system alignment, and Figma implementation
+
+This skill does not replace feature-specific skills. Apply the relevant feature skill as well, after establishing the Povio UI component and styling layer.
+
+## Inspect Before Styling
+
+1. Read the target component and nearby feature components.
+2. Inspect existing `@povio/ui` usage in `apps/fe` for the relevant primitive.
+3. Inspect `apps/fe/src/styles/overrides/uiOverrides.override.ts` and the matching file under `styles/overrides/defaults` before changing a Povio primitive.
+4. Inspect `apps/fe/src/styles/theme.css` for available generated tokens, but never edit that file manually.
+5. Inspect `apps/fe/src/styles/base.css` and `globals.css` before adding global rules or tokens.
+
+## Use This Decision Order
+
+### 1. Use an Existing Povio UI Component
+
+Use `@povio/ui` whenever it provides the semantic control or presentation primitive. This includes buttons, links, typography, icons, inputs, textareas, selects, checkboxes, radios, switches, forms, uploads, tags, badges, tables, pagination, menus, tooltips, modals, confirmations, drawers, popovers, toasts, loading indicators, and empty or feedback states.
+
+Prefer the component's supported props and variants over restyling its internals. Do not recreate a primitive with a raw HTML element merely to get a different appearance.
+
+Before introducing a native interactive element, a custom control, or a third-party UI component, search `@povio/ui` exports and existing feature usage for an existing equivalent. Native structural elements such as `main`, `section`, `article`, `nav`, and layout containers remain appropriate when no Povio semantic component exists.
+
+### 2. Use `UIConfig` for Application-Wide Defaults
+
+Use the root `UIConfig.Provider` when an existing Povio variant or option is correct and only its default should change across the application.
+
+Examples:
+
+- Make all inputs default to `small`.
+- Set the default table-cell typography size.
+- Set the default tag text size.
+
+Do not use `UIConfig` for a one-off screen or to invent a new variant.
+
+### 3. Use Tailwind for Composition and Local Presentation
+
+Use Tailwind classes in JSX for:
+
+- Page and component layout
+- Grid and flex behavior
+- Width, height, spacing, alignment, and overflow
+- Responsive composition
+- A one-instance surface, border, or text treatment
+- State selectors that remain short and readable
+
+Use semantic project utilities such as `bg-elevation-fill-default-1`, `text-text-default-1`, and `border-elevation-outline-default-1`. Do not use removed default palette utilities such as `bg-blue-500`, and do not repeat raw hex values in components.
+
+Keep Povio component `className` additions focused on outer layout or a genuinely local treatment. Do not pile conflicting utilities onto a component to fight its configured CVA variants. If the same correction is required on most instances, move it to `UIConfig` or `UIOverrides`.
+
+### 4. Use `UIOverrides` for Design-System-Level Povio Changes
+
+Use `UIOverrides.defineOverride(...)` when a Povio primitive must change consistently throughout the application:
+
+- Change the base classes of every instance.
+- Add or change supported variants.
+- Change compound-variant behavior.
+- Change internal slots not exposed by ordinary component props.
+- Align a primitive with the application's Figma design system.
+
+Place overrides under `apps/fe/src/styles/overrides/defaults/<component>.override.ts` and register them in `uiOverrides.override.ts`. Use the existing `mode`, `base`, `config`, variant, and compound-variant patterns.
+
+Update `apps/fe/src/types/ui.d.ts` when a new override variant must augment public Povio component types.
+
+Do not use `UIOverrides` for:
+
+- Page layout
+- One feature's special card
+- One exceptional component instance
+- A workaround that can be expressed through an existing prop
+
+Changing an override affects every consumer. Search all uses of the primitive and verify representative screens before finishing.
+
+### 5. Use a Shared Wrapper for Repeated Product Semantics
+
+Create a component under `apps/fe/src/components/shared` when several features need the same product-specific composition but the base Povio primitive should remain unchanged.
+
+Examples:
+
+- `StatusTag` mapping domain statuses to Povio `Tag` variants
+- `WalkSchedule` composing typography, icons, and layout
+- `PageCard` applying a repeated application surface
+
+Expose semantic props rather than forwarding a growing collection of styling flags.
+
+### 6. Use Dedicated CSS for Selector-Heavy or Browser-Level Behavior
+
+Create or extend a `.css` file when CSS communicates the rule more clearly than Tailwind:
+
+- Pseudo-elements used for connected timelines or route lines
+- Multi-step keyframes
+- Complex descendant, sibling, or state selectors
+- Calendar grids and overlapping appointments
+- Map-library markers, popups, or third-party DOM overrides
+- Print styles
+- Browser-global behavior such as scrollbars
+- Rules driven by CSS custom properties that many descendants consume
+
+Co-locate feature CSS with its owning component and import it there. Use a narrow, feature-prefixed class namespace, for example `walk-route__marker`. Keep truly global rules in `globals.css` or `base.css`.
+
+Do not create a CSS file for ordinary spacing, flex/grid layout, a simple hover, or a semantic color already expressible with a short Tailwind class list.
+
+## Scope Guide
+
+| Desired scope                                                  | Styling layer               |
+| -------------------------------------------------------------- | --------------------------- |
+| Existing primitive behavior                                    | Povio UI props/variants     |
+| Default for every instance                                     | `UIConfig`                  |
+| One page or component composition                              | Tailwind                    |
+| Every instance or internal Povio slot                          | `UIOverrides`               |
+| Repeated product-specific composition                          | Shared wrapper              |
+| Pseudo-elements, keyframes, complex selectors, third-party DOM | Scoped `.css`               |
+| Generated design tokens                                        | Figma-generated `theme.css` |
+| Handwritten global token or browser rule                       | `base.css` or `globals.css` |
+
+## Guardrails
+
+- Use `@povio/ui` before creating a custom primitive.
+- Do not let guidance from a general frontend or design skill replace an available `@povio/ui` primitive with raw HTML, a local reimplementation, or another component library.
+- Use semantic Tailwind tokens from the project theme.
+- Never manually edit `apps/fe/src/styles/theme.css`.
+- Avoid `!important`; resolve ownership or specificity instead.
+- Avoid inline `style` except for truly runtime numeric values such as map coordinates or calculated dimensions. Prefer CSS custom properties when descendants need the value.
+- Avoid Sass, CSS-in-JS, and a second styling system.
+- Preserve visible focus, disabled, hover, pressed, error, and loading states.
+- Respect `prefers-reduced-motion` for nonessential animation.
+- Keep touch targets at least 44 by 44 CSS pixels where practical.
+- Verify changes at mobile and desktop breakpoints.
+
+## Examples
+
+Use Tailwind for local layout:
+
+```tsx
+<section className="grid gap-4 rounded-modal-rounding-default border border-elevation-outline-default-1 bg-elevation-fill-default-1 p-4">
+  <Typography size="title-4">{title}</Typography>
+  {children}
+</section>
+```
+
+Use `UIConfig` for an existing global default:
+
+```tsx
+<UIConfig.Provider
+  config={{
+    input: { size: "small" },
+  }}
+>
+  {children}
+</UIConfig.Provider>
+```
+
+Use a scoped CSS file for a connected route line:
+
+```css
+.walk-route__marker::after {
+  content: "";
+  position: absolute;
+  inset-block: 1.25rem -0.75rem;
+  inset-inline-start: 50%;
+  width: 0.125rem;
+  background: rgb(var(--elevation-outline-default-1-base));
+  transform: translateX(-50%);
+}
+```
+
+Use `UIOverrides` only when the same primitive-level change is intentionally global:
+
+```ts
+export const tagOverride = UIOverrides.defineOverride("tag.cva", {
+  mode: "overrideCva",
+  base: ["inline-flex items-center border"],
+  config: {
+    variants: {
+      color: {
+        success: "border-interactive-subtle-success-idle bg-interactive-subtle-success-idle",
+      },
+    },
+  },
+});
+```
+
+## Verification
+
+1. Run formatting, linting, and TypeScript checks relevant to `apps/fe`.
+2. Inspect at least one representative use for every globally changed primitive.
+3. Check keyboard focus and disabled/error states.
+4. Check mobile and desktop layouts.
+5. Confirm no raw default-palette classes or duplicated design values were introduced.

package/templates/auth-chat/.rulesync/skills/povio-ui-styling/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Povio UI Styling"
+  short_description: "Required first for all apps/fe UI work"
+  default_prompt: "Use $povio-ui-styling first for this apps/fe UI task, preserving @povio/ui primitives before applying other frontend guidance."

package/templates/auth-chat/.rulesync/skills/robodev-api-route/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: robodev-api-route
+description: Add a defineApi route under api/.
+---
+
+# Add a Robodev API route
+
+1. Create `api/<path>.ts` or `api/<path>/[id].ts`.
+2. Export HTTP methods with `defineApi` from `@robodev-ai/sdk`.
+3. Use `auth: "required"` unless the route is public.
+4. Keep JSON shapes aligned with `openapi.json`.
+5. Do not create `api/user/**` files.
+6. Deploy from the project root (`robodev deploy`), then `bun openapi:gen` in `apps/fe` if the contract changed.

package/templates/auth-chat/.rulesync/skills/robodev-table/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: robodev-table
+description: Add a Drizzle table to database.ts and wire it into defineApi handlers.
+---
+
+# Add a Robodev table
+
+1. Add a `pgTable` to `database.ts` and include it in `defineDatabase({ tables })`.
+2. Do not add a User table. Auth users are platform-managed; store `userId` as text.
+3. Import the table in `api/_lib.ts` or the route file that needs it.
+4. Deploy from the project root with `robodev deploy`. Destructive drops need confirmation or `--force`.
+5. If the frontend needs the new fields, update `openapi.json` and run `bun openapi:gen` from `apps/fe`.

package/templates/auth-chat/README.md

@@ -1,17 +1,36 @@
 # {{NAME}}
 
-Starter app from `robodev create --starter auth-chat`: email + Google sign-in and a shared chat room (`chat` database, `messages` table).
+Starter from `robodev create --starter auth-chat`: Tiny chat APIs (`chat` database, `messages` table), authenticated invite email, and a **local** Povio UI in `apps/fe`.
 
-The project host is the app. After create or deploy, open the printed App URL — no `npm run dev` required. Local Vite is optional:
+The project host is **API-only**. After create or deploy, the printed App URL serves APIs and Swagger — not the SPA. Run the UI with bun:
 
 ```bash
-npm run dev
+cd apps/fe
+bun install
+bun openapi:gen
+bun dev
 ```
 
-Local Vite reads `VITE_API_URL` from `.env` (written by `robodev create` / `robodev link`). Hosted builds use the same origin as the APIs.
+Vite defaults to port **3000** (`VITE_DEV_PORT`). `bun` is required for `apps/fe`.
 
-Docs: https://robodev.povio.dev/docs/starter
+Auth, link, and deploy from this **root**:
 
-`GET /api/me` and `GET/POST /api/messages` (`api/me.ts`, `api/messages.ts`) require a Robodev Auth Bearer token. `GET /api/health` stays public. Email auth works without Google. If Google is not configured on Starbase, the button shows a 503 message. Google OAuth may not complete inside the dashboard preview iframe — use Open app.
+```bash
+npx robodev auth
+npx robodev link
+npx robodev deploy
+```
+
+`robodev create` / `robodev link` write `VITE_API_URL`, `VITE_PUBLIC_API_URL`, and `APP_PUBLIC_API_URL` in `.env`, and rewrite `.config/local.spa.yml` so the FE talks to the project host.
+
+Dashboard create deploys schema + APIs only. The Tiny FE tree is copied by `robodev create`.
+
+`GET /api/me`, `GET/POST /api/messages`, and `POST /api/invite` require a Robodev Auth Bearer token. `GET /api/health` stays public. Invites send one email; posting a chat message does not. Auth stays reserved at `/api/user/*`. Do not add `api/user/**`.
+
+Regenerate AI rules after editing `.rulesync/`:
+
+```bash
+bun rules:gen
+```
 
-Edit files in the dashboard Code page, or here, then Save / `npx robodev deploy`.
+Docs: https://robodev.povio.dev/docs

package/templates/auth-chat/api/invite.ts

@@ -0,0 +1,43 @@
+/** POST /api/invite — signed-in users send a chat invite email. */
+import { defineApi, z } from "@robodev-ai/sdk";
+
+function headerValue(
+  headers: Record<string, string | string[] | undefined>,
+  name: string,
+): string | undefined {
+  const raw = headers[name] ?? headers[name.toLowerCase()];
+  if (Array.isArray(raw)) return raw[0];
+  return typeof raw === "string" ? raw : undefined;
+}
+
+function resolveProjectUrl(
+  env: Record<string, string>,
+  headers: Record<string, string | string[] | undefined>,
+): string {
+  const fromEnv =
+    env.APP_PUBLIC_API_URL?.trim() || env.VITE_PUBLIC_API_URL?.trim() || env.VITE_API_URL?.trim();
+  if (fromEnv) return fromEnv.replace(/\/+$/, "");
+  const host = headerValue(headers, "x-forwarded-host") || headerValue(headers, "host");
+  if (!host) return "";
+  const proto =
+    headerValue(headers, "x-forwarded-proto") || (host.includes("localhost") ? "http" : "https");
+  return `${proto}://${host}`.replace(/\/+$/, "");
+}
+
+export const post = defineApi({
+  auth: "required",
+  body: z.object({ to: z.string().email() }),
+  response: z.object({ id: z.string(), status: z.literal("sent") }),
+  handler: async ({ email, body, user, env, headers }) => {
+    const url = resolveProjectUrl(env, headers);
+    const who = user?.name?.trim() || user?.email || "Someone";
+    const project = url ? ` Project URL: ${url}` : "";
+    return email.send({
+      to: body.to,
+      subject: "You're invited to the chat",
+      text:
+        `${who} invited you to a shared chat on Robodev. ` +
+        `Open the App URL and sign in to join.${project}`,
+    });
+  },
+});

package/templates/auth-chat/apps/fe/index.html

@@ -0,0 +1,24 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <link
+      rel="icon"
+      type="image/svg+xml"
+      href="/favicon.svg"
+    />
+    <meta
+      name="viewport"
+      content="width=device-width, initial-scale=1.0"
+    />
+    <title>Space</title>
+  </head>
+
+  <body class="bg-elevation-fill-default-2 text-text-default-1">
+    <div id="app"></div>
+    <script
+      type="module"
+      src="/src/main.tsx"
+    ></script>
+  </body>
+</html>