@lumerahq/cli 0.20.0 → 0.22.0

package/dist/index.js

@@ -226,25 +226,25 @@ async function main() {
     switch (command) {
       // Resource commands
       case "plan":
-        await import("./resources-R4IYU4BF.js").then((m) => m.plan(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.plan(args.slice(1)));
         break;
       case "apply":
-        await import("./resources-R4IYU4BF.js").then((m) => m.apply(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.apply(args.slice(1)));
         break;
       case "pull":
-        await import("./resources-R4IYU4BF.js").then((m) => m.pull(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.pull(args.slice(1)));
         break;
       case "destroy":
-        await import("./resources-R4IYU4BF.js").then((m) => m.destroy(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.destroy(args.slice(1)));
         break;
       case "list":
-        await import("./resources-R4IYU4BF.js").then((m) => m.list(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.list(args.slice(1)));
         break;
       case "show":
-        await import("./resources-R4IYU4BF.js").then((m) => m.show(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.show(args.slice(1)));
         break;
       case "diff":
-        await import("./resources-R4IYU4BF.js").then((m) => m.diff(args.slice(1)));
+        await import("./resources-W7TYJOQN.js").then((m) => m.diff(args.slice(1)));
         break;
       // Development
       case "dev":
@@ -255,7 +255,7 @@ async function main() {
         break;
       // Project
       case "init":
-        await import("./init-ZFBNNPDX.js").then((m) => m.init(args.slice(1)));
+        await import("./init-RPJHBBWD.js").then((m) => m.init(args.slice(1)));
         break;
       case "register":
         await import("./register-OOU477QY.js").then((m) => m.register(args.slice(1)));

package/dist/{init-ZFBNNPDX.js → init-RPJHBBWD.js}

@@ -43,45 +43,6 @@ function processTemplate(content, replacements) {
 var TEMPLATE_EXCLUDE = /* @__PURE__ */ new Set(["template.json"]);
 var TEMPLATE_RENAMES = /* @__PURE__ */ new Map([["_gitignore", ".gitignore"]]);
 var TEMPLATE_RAW_COPY = /* @__PURE__ */ new Set(["pnpm-lock.yaml"]);
-var STUDIO_PROBLEM_FIRST_FLAG = "studio_problem_first";
-var PROBLEM_FIRST_AGENTS_MD = `# {{projectTitle}}
-
-This file is project-specific durable memory for future Studio agent sessions.
-Keep it concise and update it only with context that is not obvious from the
-file tree alone.
-
-## Purpose
-
-Describe the business problem this workspace solves and who uses it.
-
-## Business Workflow
-
-Capture the durable workflow, domain terms, review expectations, and important
-edge cases.
-
-## Domain Notes
-
-Record user-specific terminology, assumptions, constraints, and preferences
-that future agents should preserve.
-
-## Project Conventions
-
-Document non-obvious architecture, naming, validation, or UX conventions that
-should guide future changes.
-
-## Validation
-
-List the commands or checks that should pass before changes are considered
-done.
-
-## Decisions and Follow-ups
-
-Record durable decisions and unresolved questions that should carry forward.
-
-Do not use this file as a generic Lumera platform manual, tool guide, or code
-index. Do not store secrets, credentials, tokens, private keys, or transient
-chat summaries.
-`;
 function copyDir(src, dest, replacements, isRoot = true) {
   if (!existsSync(dest)) {
     mkdirSync(dest, { recursive: true });
@@ -121,20 +82,6 @@ function ensureClaudeInstructionsLink(projectRoot) {
     writeFileSync(claudeMdPath, readFileSync(agentsMdPath, "utf-8"));
   }
 }
-async function isStudioProblemFirstScaffoldEnabled(targetDir) {
-  try {
-    const token = getToken(targetDir);
-    const api = createApiClient(token);
-    const me = await api.getMe();
-    return me.user?.feature_flags?.[STUDIO_PROBLEM_FIRST_FLAG] === true;
-  } catch {
-    return false;
-  }
-}
-function applyProblemFirstProjectInstructionsScaffold(projectRoot, replacements) {
-  const agentsMdPath = join(projectRoot, "AGENTS.md");
-  writeFileSync(agentsMdPath, processTemplate(PROBLEM_FIRST_AGENTS_MD, replacements));
-}
 function isGitInstalled() {
   try {
     execSync("git --version", { stdio: "ignore" });
@@ -427,11 +374,7 @@ async function init(args) {
     [sourceName, finalProjectName],
     [sourceTitle, projectTitle]
   ];
-  const problemFirstScaffold = await isStudioProblemFirstScaffoldEnabled(targetDir);
   copyDir(templateDir, targetDir, replacements);
-  if (problemFirstScaffold) {
-    applyProblemFirstProjectInstructionsScaffold(targetDir, replacements);
-  }
   ensureClaudeInstructionsLink(targetDir);
   const installCommand = existsSync(join(targetDir, "pnpm-lock.yaml")) ? "pnpm install --frozen-lockfile" : "pnpm install";
   function listFiles(dir, prefix = "") {

package/dist/{resources-R4IYU4BF.js → resources-W7TYJOQN.js}

@@ -2306,6 +2306,7 @@ async function planAgents(api, localAgents, projectId) {
       if ((remote.description || "") !== (agent.description || "")) diffs.push("description");
       if ((remote.system_prompt || "").trim() !== systemPrompt.trim()) diffs.push("system_prompt");
       if ((remote.model || "") !== (agent.model || "")) diffs.push("model");
+      if (agent.thinking_level !== void 0 && (remote.thinking_level || "") !== agent.thinking_level) diffs.push("thinking_level");
       if ((remote.idle_reap_timeout_seconds ?? 0) !== (agent.idle_reap_timeout_seconds ?? 0)) diffs.push("idle_reap_timeout_seconds");
       if ((remote.policy_script || "").trim() !== (policyScript || "").trim()) diffs.push("policy_script");
       if ((remote.policy_enabled || false) !== (agent.policy_enabled || false)) diffs.push("policy_enabled");
@@ -2399,6 +2400,7 @@ async function applyAgents(api, localAgents, projectId) {
       description: agent.description || "",
       system_prompt: systemPrompt,
       model: agent.model || "",
+      ...agent.thinking_level !== void 0 ? { thinking_level: agent.thinking_level } : {},
       idle_reap_timeout_seconds: agent.idle_reap_timeout_seconds ?? 0,
       skill_ids: skillIds,
       policy_script: policyScript || "",
@@ -2457,6 +2459,7 @@ async function pullAgents(api, platformDir, filterName, projectId) {
     };
     if (agent.description) config.description = agent.description;
     if (agent.model) config.model = agent.model;
+    if (agent.thinking_level) config.thinking_level = agent.thinking_level;
     if (agent.idle_reap_timeout_seconds) config.idle_reap_timeout_seconds = agent.idle_reap_timeout_seconds;
     if (skillSlugs.length > 0) config.skills = skillSlugs;
     if (agent.policy_enabled) config.policy_enabled = true;
@@ -3702,13 +3705,16 @@ async function diff(args) {
       console.log(`  description: ${pc2.red(remote.description || "(empty)")} \u2192 ${pc2.green(local.agent.description || "(empty)")}`);
     if ((remote.model || "") !== (local.agent.model || ""))
       console.log(`  model: ${pc2.red(remote.model || "(default)")} \u2192 ${pc2.green(local.agent.model || "(default)")}`);
+    if (local.agent.thinking_level !== void 0 && (remote.thinking_level || "") !== local.agent.thinking_level)
+      console.log(`  thinking_level: ${pc2.red(remote.thinking_level || "(default)")} \u2192 ${pc2.green(local.agent.thinking_level)}`);
     if ((remote.idle_reap_timeout_seconds ?? 0) !== (local.agent.idle_reap_timeout_seconds ?? 0))
       console.log(`  idle_reap_timeout_seconds: ${pc2.red(String(remote.idle_reap_timeout_seconds ?? 0))} \u2192 ${pc2.green(String(local.agent.idle_reap_timeout_seconds ?? 0))}`);
     if ((remote.policy_enabled || false) !== (local.agent.policy_enabled || false))
       console.log(`  policy_enabled: ${pc2.red(String(remote.policy_enabled || false))} \u2192 ${pc2.green(String(local.agent.policy_enabled || false))}`);
     const promptChanged = (remote.system_prompt || "").trim() !== local.systemPrompt.trim();
     const policyChanged = (remote.policy_script || "").trim() !== (local.policyScript || "").trim();
-    if (!promptChanged && !policyChanged && remote.name === local.agent.name && (remote.description || "") === (local.agent.description || "") && (remote.model || "") === (local.agent.model || "") && (remote.idle_reap_timeout_seconds ?? 0) === (local.agent.idle_reap_timeout_seconds ?? 0) && (remote.policy_enabled || false) === (local.agent.policy_enabled || false)) {
+    const thinkingLevelChanged = local.agent.thinking_level !== void 0 && (remote.thinking_level || "") !== local.agent.thinking_level;
+    if (!promptChanged && !policyChanged && !thinkingLevelChanged && remote.name === local.agent.name && (remote.description || "") === (local.agent.description || "") && (remote.model || "") === (local.agent.model || "") && (remote.idle_reap_timeout_seconds ?? 0) === (local.agent.idle_reap_timeout_seconds ?? 0) && (remote.policy_enabled || false) === (local.agent.policy_enabled || false)) {
       console.log(pc2.green(`  \u2713 No changes`));
     } else {
       if (promptChanged) renderFullDiff("system_prompt.md", remote.system_prompt || "", local.systemPrompt);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lumerahq/cli",
-  "version": "0.20.0",
+  "version": "0.22.0",
   "description": "CLI for building and deploying Lumera apps",
   "type": "module",
   "engines": {

package/templates/default/AGENTS.md

@@ -1,215 +1,53 @@
 # {{projectTitle}}
 
-A Lumera app built with collections, automations, hooks, custom agents, and a React frontend.
+> Status: new project — nothing built yet.
 
-## Project Structure
+<!--
+AGENT CONTRACT — keep this file true.
+This is the project's durable memory, shared by every coding agent that works
+here. It records what cannot be re-derived from the code: why things are the
+way they are, what the business needs, what must not break.
+- Update it in the same turn as the change that makes it stale.
+- Small focused edits; delete stale lines rather than appending duplicates.
+- Leave a section empty rather than padding it.
+- Do NOT put here: platform documentation (skills and prompts carry that),
+  code inventories, secrets/credentials, or transient chat summaries.
+- Preserve user-written notes verbatim unless the user says otherwise.
+-->
 
-```
-platform/
-├── collections/       # Collection schemas (JSON) — deployed via lumera apply
-├── automations/       # Python automations (config.json + run.py per automation)
-├── agents/            # Custom AI agents (config.json + system_prompt.md + optional policy.js)
-├── hooks/             # JavaScript hooks on collection lifecycle events
-src/
-├── routes/index.tsx   # Home page
-├── lib/queries.ts     # Data fetching helpers
-├── components/        # Shared UI components
-├── components/ui/     # shadcn UI primitives (installed via MCP)
-scripts/               # Utility scripts (seed data, migrations, etc.)
-```
+## What this is
 
-The starter UI is intentionally throwaway. `src/routes/index.tsx` is just the
-default landing page shown before the real app exists, and `index.html` is only
-the Vite shell. When building the user's first real workflow or screen, replace
-the starter home page with the app experience instead of preserving or building
-around the placeholder content.
+One paragraph: the problem this solves, for whom, and its current shape
+(app / automation / agent / one-off analysis). Update when scope changes.
 
-## Lumera Concepts
+## Business context
 
-A Lumera app is built from these primitives — all defined as code in `platform/`:
+- Who uses it, when, and for what workflow (roles, cadence — e.g. month-end)
+- Domain terms with tenant-specific meaning
+- Source-of-truth data and how it arrives (uploads, mailbox, webhooks, integrations)
 
-- **Collections** (`platform/collections/*.json`) — Data tables with typed fields. Deployed via `lumera apply`.
-- **Automations** (`platform/automations/*/`) — Python scripts that run on Lumera's servers. Each has a `config.json` and `run.py`.
-- **Custom agents** (`platform/agents/*/`) — AI-powered agents with prompts, skills, optional policies, and reusable sessions. Use them for classification, extraction, enrichment, drafting, guided review, and tool-heavy workflows. When creating or changing agents, read the Building Agents skill first.
-- **Hooks** (`platform/hooks/*.js`) — JavaScript on collection lifecycle events (`before_create`, `after_update`, etc.).
-- **Webhooks** — Receive events from external services (Stripe, GitHub, etc.). Events land in `lm_event_log`; process them with hooks or automations.
-- **Mailbox** — Each tenant gets an email address. Inbound emails are persisted to `lm_mailbox_messages` — use hooks to trigger automations on new mail.
-- **Email** — Send transactional emails from automations via `from lumera import email`. Logged to `lm_email_logs`.
+## Data
 
-All resources use **external IDs** in the format `<app-name>:<resource-name>` (auto-derived from `package.json` name + directory/file name).
+- What each collection represents; non-obvious field/status semantics
+- Identifiers that map to external systems, and their formats
 
-## Project Namespacing
+## Decisions
 
-**All collection names are automatically namespaced by project.** Always use bare names (e.g. `orders`, not `myproject__orders`) everywhere — in collection JSON files, Python SDK calls, JavaScript hooks, and frontend queries. The platform resolves bare names to the project-scoped version transparently.
+- YYYY-MM-DD — decision — why.
 
-- `pb.ensure_collection("orders", ...)` → stored as `{project}__orders`
-- `query_sql("SELECT id FROM orders")` → resolves to `{project}__orders`
-- `ctx.dao.find("orders", ...)` → resolves to `{project}__orders`
-- `pbSql({ sql: "SELECT id FROM orders" })` in frontend → resolves via `X-Lumera-Project` header
+## Working agreements
 
-**Never manually prefix collection names with `{project}__`.** Two projects can each have an `orders` collection — they are fully isolated.
+- User preferences: review gates, deploy expectations, formatting
 
-For detailed technical reference (data models, relationships, design decisions), see [architecture.md](architecture.md).
+## Correctness
 
-## UI Components
+- What "correct" means here: validations, reconciliations, tolerances, approvals
+- Known edge cases; behavior when required data is missing
 
-**Always use shadcn components for UI.** Never hand-code primitives like buttons, dialogs, cards, inputs, tables, etc.
+## Gotchas
 
-### Installing components
+- Things that look wrong but are intentional; workarounds and why
 
-Install shadcn components with `pnpm dlx` (the sandbox's default JS package manager). Match the sandbox-pinned shadcn version:
+## Follow-ups
 
-```bash
-pnpm dlx shadcn@4.1.2 add button card dialog      # Install specific components
-pnpm dlx shadcn@4.1.2 add table input label select  # Install more as needed
-```
-
-Components install into `src/components/ui/` and are fully editable.
-
-### shadcn MCP server
-
-A `shadcn` MCP server is available to browse and search the registry. Use `mcp({ server: "shadcn" })` to list available tools, then:
-
-```
-mcp({ search: "button" })        # Search across all MCP servers
-mcp({ server: "shadcn" })        # List shadcn tools
-```
-
-Useful MCP tools:
-- **search_items_in_registries** — fuzzy search components by name
-- **view_items_in_registries** — view component source code
-- **get_item_examples_from_registries** — find usage examples with full code
-- **get_add_command_for_items** — get the install command
-
-All tools use the `@shadcn` registry (e.g. `@shadcn/button`, `@shadcn/card`).
-
-### Project setup
-
-- `components.json` — configures shadcn paths, aliases, and theme
-- `src/styles.css` — shadcn neutral theme CSS variables
-- `src/lib/utils.ts` — `cn()` utility, import from `@/lib/utils`
-- `src/components/ui/` — installed shadcn components (editable)
-
-**Do not hand-code UI primitives.** If you need a button, card, dialog, table, form, select, tabs, tooltip, or any standard UI element — install it from shadcn first.
-
-## Frontend API Calls
-
-Custom apps run in an **iframe**. **Always use the `@lumerahq/ui` bridge for API calls.** Never use raw `fetch()` against Lumera API endpoints.
-
-```ts
-// ✅ Correct — uses postMessage bridge, no CORS issues
-import { pbSql, pbCreate, pbUpdate, pbDelete } from '@lumerahq/ui/lib';
-
-// New read queries: use SQL for collection access, including lookups, lists, reports, joins, ordering, and filters
-const result = await pbSql<{ id: string; amount: number }>({
-  sql: 'SELECT id, amount FROM orders WHERE status = {:status} ORDER BY updated DESC LIMIT 100',
-  params: { status: 'pending' },
-});
-const records = result.rows;
-
-// CRUD
-await pbCreate('orders', { amount: 100 });
-await pbUpdate('orders', recordId, { status: 'done' });
-await pbDelete('orders', recordId);
-
-// ❌ WRONG — direct fetch will fail with CORS errors
-fetch('/api/pb/sql', { method: 'POST', body: JSON.stringify({ sql: '...' }) });
-fetch('https://app.lumerahq.com/api/pb/sql', ...);
-```
-
-**Why:** The bridge sends requests to the parent window via `postMessage`. The parent makes the actual API call on its own origin — no CORS, and auth is handled automatically.
-
-**Rules:**
-- Always import from `@lumerahq/ui/lib` — never write a custom `apiFetch` with raw `fetch()`
-- Use `pbSql()` for new read-only collection access
-- Existing `pbList()` / `pbSearch()` filter code remains supported for simple existing list/search reads; do not rewrite working code just because SQL exists
-- Use record helpers such as `pbCreate()`, `pbUpdate()`, and `pbDelete()` for mutations
-- Token is not needed — the bridge handles auth via the parent session
-- `X-Lumera-Project` header is not needed — the parent adds it automatically
-
-## Shareable Links
-
-For any URL a human will open (copy-link, invites, emails, QR codes), use `getShareableAppUrl()` or `buildShareableAppUrl()` from `@lumerahq/ui/lib` — **never `window.location.href`**. The app runs inside an iframe, so `window.location` returns the internal `/_apps/{company}/{app}/...` URL instead of the shell's `/app/{appId}` URL.
-
-```ts
-import { buildShareableAppUrl, getShareableAppUrl } from '@lumerahq/ui/lib';
-const link = getShareableAppUrl(); // preserves current path/search/hash
-const invoiceLink = buildShareableAppUrl('/invoices/123', { router: 'hash' });
-```
-
-When reporting a deployed app, use `launch_url` from the deploy response. Do not share `iframe_url`; it is only the internal iframe/static asset mount.
-
-## Preview and Verification
-
-The Studio environment already runs the Vite dev server and exposes it through
-the portal's **Preview tab**. Users are not expected to run local developer
-commands, and raw localhost URLs are not reachable from the Studio portal.
-
-**Never tell users to run `pnpm dev`, `pnpm dev:vite`, `npm run dev`, or any
-other dev-server command. Never tell users to open `localhost`, `127.0.0.1`, or
-Vite ports such as `http://localhost:5173/`.** When explaining how to verify UI
-changes, tell them to open the **Preview tab**.
-
-
-## Workflow
-
-Follow the user's lead. If they tell you exactly what to build and no critical unknowns block correctness, build it. If critical unknowns exist, ask before encoding assumptions. The workflow below is the default when they describe a goal and leave the approach to you.
-
-### Step 1: Understand and Plan
-1. **Read skills first** — Read the matching skill files for API details and patterns.
-2. **Decide one-off vs repeatable** — Determine whether the user needs a one-off answer/artifact or a repeatable workflow. For one-off tasks, answer the question, analyze the data, or produce the requested artifact directly; do not build an app unless the user asks. Propose an app, automation, agent, or durable workflow only when the process will be reused.
-3. **Inspect uploaded files** — If the user uploaded files, inspect them before planning. Identify what each file represents: one-time input data, recurring source data, configuration data, mapping/lookup tables, business rules or domain knowledge, templates, expected input/output examples, exports from another system, or debugging evidence. Decide whether each file should be used only for this turn, stored as durable configuration/reference data, imported into collections, converted into an automation input, or preserved as documentation/examples.
-4. **Identify critical unknowns** — Before proposing or building, list unknowns that affect correctness in real use. Pay special attention to source-of-truth data, ownership/assignment/approval rules, escalation or routing rules, permissions/roles/access control, integrations and required scopes, identifiers and mappings between systems, and what should happen when required data is missing.
-5. **Ask blockers, state assumptions** — Ask concise clarifying questions for blockers. Do not silently create manual lookup tables, fallback rules, durable apps, or business assumptions unless the user explicitly accepts them. For non-blocking details, state your assumption and proceed.
-6. **Discuss the plan** — Propose the **smallest validated useful slice**: a complete horizontal slice that proves the workflow with real data and realistic edge cases. Propose incremental steps that layer on complexity; if decisions are obvious, you can execute multiple steps in one go.
-7. **Stop and ask the user to approve.** Iterate until they're happy with the plan. They may reorder steps, drop features, or add ones you didn't think of.
-
-### Step 2: Build (one slice at a time)
-1. **Build horizontally** — Pick the first step. Build the full slice: collection schema and/or agent definition → `lumera apply` → seed data → UI route/components → commit. Each slice should be deployable and usable on its own.
-2. **Stop and ask for feedback** — Tell the user to open the **Preview tab** to see the app. Do not mention local dev-server commands or localhost URLs. Iterate on the slice until they're happy.
-3. **Repeat** — Move to the next step. Build, deploy, get feedback.
-
-### Rules
-1. **Code is source of truth** — Edit files in `platform/`, then deploy with `lumera apply`. Don't edit in the Lumera UI.
-2. **Keep docs current** — After each slice, update `architecture.md` with what was built (data models, relationships, hook logic, design decisions). Also update the project description at the top of this file (`AGENTS.md`) so it reflects what the project actually does now — not the original template description.
-3. **Commit and push** — After each slice or significant change, stage your changes, create a meaningful commit with both a title and description, then push. The sandbox is ephemeral — uncommitted work is lost if recycled.
-   - Use a conventional subject (`feat:`, `fix:`, `chore:`, `docs:`, `test:`) that explains the user-visible change, not just the filenames.
-   - Include a body that describes why the change was needed, what you changed, and the main areas covered.
-   - Avoid generic messages like `update files`, `changes`, `WIP`, or filename-only summaries.
-   - Prefer a HEREDOC so multi-line messages are reliable:
-     ```bash
-     git add -A
-     git commit -m "$(cat <<'EOF'
-     feat: add invoice approval dashboard
-
-     Adds the first invoice review slice with a collection schema, seeded
-     example data, and a dashboard for approving or rejecting invoices.
-
-     Covers:
-     - invoice collection fields and statuses
-     - approval actions in the UI
-     - project documentation updates
-     EOF
-     )"
-     git push
-     ```
-4. **Deploy marker** — When your changes need `lumera apply`, include at the end of your response: `<!-- DEPLOY: short commit message -->`. Skip for frontend-only changes.
-
-## File Artifacts
-
-When you create a file the user should **see** in chat (HTML pages, SVG graphics, CSV exports, PDFs, images, charts, etc.), call `create_artifact` with the file path after writing it. This uploads the file and renders an inline preview or download card in the chat. Without this step, the file exists in the sandbox but the user cannot see it.
-
-Always call `create_artifact` for: `.html`, `.svg`, `.csv`, `.json`, `.xml`, `.md`, `.txt`, `.pdf`, `.png`, `.jpg`, `.gif`, `.xlsx`, `.docx`, `.pptx`, `.zip` — any file the user asked to see or download.
-
-## Python
-
-Python 3.14 is pre-installed with common data packages (pandas, numpy, matplotlib, pdfplumber, openpyxl, etc.). To install additional packages use `uv add <package>` (preferred) or `pip install <package>`.
-
-## Key Commands
-
-```bash
-lumera plan                            # Preview changes (dry run)
-lumera apply                           # Deploy everything
-lumera run scripts/seed.py             # Run a script remotely
-lumera status                          # Show sync status
-```
+- [ ] Open questions and deferred work

package/templates/default/template.json

@@ -3,5 +3,5 @@
   "title": "Blank Starter",
   "description": "A minimal blank canvas with React frontend and Lumera platform scaffolding. No pre-built collections or agents — start from scratch.",
   "category": "General",
-  "version": "1.1.0"
+  "version": "1.2.0"
 }

package/templates/default/architecture.md

@@ -1,29 +0,0 @@
-# Architecture
-
-> Update this file as you build — it should always reflect the current state of the project so any agent or developer can understand the system from this file alone.
-
-## Overview
-
-This is a blank starter. No collections, automations, or hooks are defined yet. Build your app by adding resources to `platform/` and deploying with `lumera apply`.
-
-## Collections
-
-_None yet — add collection schemas to `platform/collections/` as you build._
-
-## Automations
-
-_None yet — add automation configs to `platform/automations/` as you build._
-
-## Hooks
-
-_None yet — add hook scripts to `platform/hooks/` as you build._
-
-## Frontend Routes
-
-| Route | Purpose |
-|-------|---------|
-| `/` | Home page — blank canvas, ready to build |
-
-## Design Decisions
-
-_Document key decisions here as you make them._