@mindstudio-ai/remy 0.1.34 → 0.1.35

package/dist/subagents/designExpert/prompts/typography.md

@@ -0,0 +1,39 @@
+## Typography Guidelines
+
+Typography is the single fastest way to give an interface identity. Consider what is being built and how type can help it be effective - both in terms of design and usability. Use the <font_library> as a reference for real, interesting, beautiful fonts that are available to use before falling back to fonts you already know. The fonts in the library were hand-sourced by a typography nerd who loves fonts (just read the descriptions, you'll see!) - trust that they are beautiful. There is a reason branding agencies get paid the big bucks for choosing the perfect fonts - we need to be thinking at a similar level here.
+
+Use type to create a strong hierarchy that drives the rest of the design — clear distinction between headings, body, labels, and captions. Use weight and size, not just color, to create hierarchy. Choose fonts that elevate the interface and give it personality.
+
+Avoid generic Google Fonts fonts and aim to surprise and delight the user with creative and unexpected choices and pairings.
+
+### Fonts to Avoid
+Even though these fonts look nice, they are unfortunately so overused that they will immediately ruin the impact of the rest of the design. Avoid them at all costs unless the user explicitly asks for them:
+- Avoid Playfair Display, Lora, Cormorant Garamond, Outfit, Raleway, Josefin Sans, Space Grotesk, Nunito, Poppins, Plus Jakarta Sans
+
+### Typography block format
+
+A `` ```typography `` fenced block in a `type: design/typography` spec file declares fonts (with source URLs) and one or two anchor styles (typically Display and Body). Derive additional styles (labels, buttons, captions, overlines) from these anchors:
+
+```
+fonts:
+  XXXXXX:
+    src: https://...
+  YYYYYY:
+    src: https://...
+
+styles:
+  Display:
+    font: XXXXXX
+    size: XXpx
+    weight: XXX
+    letterSpacing: X.XXem
+    lineHeight: X.X
+    case: ordinary
+    description: Page titles and hero text
+  Body:
+    font: YYYYYY
+    size: YYpx
+    weight: YYY
+    lineHeight: Y.Y
+    description: Default reading text
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.34",
+  "version": "0.1.35",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",
@@ -19,7 +19,7 @@
     "remy": "./dist/index.js"
   },
   "scripts": {
-    "build": "tsup && cp -r src/prompt/static src/prompt/compiled src/prompt/actions dist/ && cd src/subagents && find . -name '*.md' -exec sh -c 'mkdir -p ../../dist/subagents/$(dirname {}) && cp {} ../../dist/subagents/{}' \\;",
+    "build": "tsup",
     "dev": "tsup --watch",
     "typecheck": "tsc --noEmit",
     "lint:fix": "prettier --write ./src",

package/dist/actions/buildFromInitialSpec.md

@@ -1,15 +0,0 @@
-This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
-
-The user has reviewed the spec and is ready to build. 
-
-Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything.
-
-Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan.
-
-When code generation is complete, verify your work: 
-- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works 
-- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
-- Ask the `visualDesignExpert` to take a screenshot and verity that the visual design looks correct. Fix any issues it flags - we want the user's first time seeing the finished product to truly wow them.
-- Finally, use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
-
-When everything is working, use `productVision` to mark the MVP roadmap item as done, then call `setProjectOnboardingState({ state: "onboardingFinished" })`.

package/dist/actions/publish.md

@@ -1,12 +0,0 @@
-This is an automated action triggered by the user pressing "Publish" in the editor.
-
-The user wants to deploy their app. Pushing to the `main` branch triggers a production deploy.
-
-Review the current state of the working tree — what has changed since the last commit, what's been committed since the last push, and the overall shape of recent work. Write a user-friendly changelog with `presentPublishPlan` — summarize what changed in plain language ("added vendor approval workflow", "fixed invoice totals", "updated the dashboard layout"). Reference specific code or file paths only when it helps clarity. This is what the user will see before deploying.
-
-If approved:
-- Stage and commit any uncommitted changes with a clean, descriptive commit message
-- Push to main
-- Let the user know their app is deploying
-
-If dismissed, acknowledge and do nothing.

package/dist/actions/sync.md

@@ -1,19 +0,0 @@
-This is an automated action triggered by the user pressing "Sync" in the editor.
-
-The user has manually edited files since the last sync. The `refs/sync-point` git ref marks the last known-good sync state. It's created using a temporary git index that captures the full working tree (including unstaged changes) as a tree object — so it represents exactly what the files looked like at sync time, not just what was committed.
-
-To see what the user changed, run: `git diff refs/sync-point -- src/ dist/`
-
-This compares the sync-point tree against the current working tree. Do not add `HEAD` or any other ref — the command as written diffs directly against the working tree, which is what you want.
-
-In the diff output: lines prefixed with `-` are what was in the file at last sync. Lines prefixed with `+` are the user's current edits. Sync should bring the other side in line with the `+` side.
-
-Analyze the changes and write a sync plan with `presentSyncPlan` — a clear markdown summary of what changed and what you intend to update. Write it for a human: describe changes in plain language ("renamed the greeting field", "added a note about error handling"), not as a list of file paths and code diffs. Reference specific code or file paths only when it helps clarity. The user will review and approve before you make changes.
-
-If approved:
-- If spec files (`src/`) changed, update the corresponding code in `dist/` to match
-- If code files (`dist/`) changed, update the corresponding spec in `src/` to match
-- If both changed, reconcile — spec is the source of truth for intent, but respect code changes that add implementation detail
-- When all files are synced, call `clearSyncStatus`
-
-If dismissed, acknowledge and do nothing.

package/dist/compiled/README.md

@@ -1,100 +0,0 @@
-# Compiled Prompt Fragments
-
-This directory contains distilled prompt fragments generated from the source
-docs in `docs/developer-guide/` (project root). These are loaded by `../index.ts` and injected
-into Remy's system prompt at runtime.
-
-## How to compile
-
-The compilation is done manually in a session with an LLM (Claude Code or
-similar). Work through the source docs and compile them into prompt-ready
-fragments.
-
-### Step 1: Compile with an LLM
-
-Open a session and ask it to work through the compilation. Give it these
-instructions:
-
----
-
-**You will compile source docs into prompt fragments for Remy, a coding agent
-that builds MindStudio apps. The compiled fragments go in `src/prompt/compiled/`
-and are loaded into the agent's system prompt at runtime.**
-
-**Work through this one source file at a time, sequentially.** For each one:
-1. Read the source doc thoroughly
-2. Decide whether it should become its own fragment, be merged with a related
-   source, or be skipped entirely
-3. Present your draft of the compiled fragment
-4. Wait for review and feedback before moving to the next one
-
-Do not parallelize this work. Do not generate multiple fragments at once. Each
-fragment deserves careful attention — these are the instructions a coding agent
-will follow to build real products, and mistakes here propagate into every app
-it builds.
-
-Source files are in `docs/developer-guide/` at the project root.
-
-## How to think about compilation
-
-**Your audience is an LLM acting as a coding agent.** It needs to produce
-correct code, not learn concepts. Everything you write should be optimized
-for an agent that is actively building a MindStudio app and needs to get
-the details right.
-
-### What to keep
-
-- **API signatures, parameter types, return types, and code examples.**
-  These must be exactly right. The agent will copy these patterns directly
-  into the code it writes. A wrong type or a missing parameter means broken
-  code in production.
-- **Concrete examples, specific error cases, explicit constraints, enumerated
-  edge cases.** These are the highest-value content. A source doc that says
-  "ensure data integrity, including checking for duplicate keys, null foreign
-  references, and orphaned records" — the specific checks ARE the value.
-  Collapsing that to "ensure data integrity" loses the actionable detail.
-- **Tables and structured reference data.** Manifest fields, db predicates,
-  interface config schemas, role API methods — these are lookup references
-  the agent will consult while writing code. Keep them complete.
-- **Rules and constraints that affect correctness.** "Only packages declared
-  in package.json are available at runtime" is the kind of detail that
-  prevents hard-to-debug errors.
-
-### What to strip
-
-- **Setup instructions, installation steps, CLI commands.** The agent isn't
-  setting up a dev environment — it's writing code inside one.
-- **Platform internals and deployment pipeline details.** How the platform
-  builds and deploys is not the agent's concern.
-- **Conceptual explanations and philosophy.** "Why" something was designed
-  a certain way is rarely useful mid-task. Keep the "what" and "how."
-- **Marketing language, feature pitches, comparative positioning.**
-- **Cross-references to other docs** ("see Section X for details"). The
-  fragment should be self-contained.
-
-### Fragment format
-
-```markdown
-# Fragment Title
-
-Brief one-line context.
-
-## Section
-...content...
-```
-
-No YAML frontmatter. No meta-commentary. Just the reference content the
-agent needs. Each fragment should make sense on its own — the agent may
-not see all fragments in every session.
-
----
-
-### Step 2: Review
-
-Read through the compiled fragments and verify code examples are accurate.
-The LLM may hallucinate API details — cross-check against the source docs.
-
-### Step 3: Commit
-
-The compiled fragments are committed to git. They're the snapshot the agent
-uses at runtime.

package/dist/compiled/auth.md

@@ -1,77 +0,0 @@
-# Roles & Auth
-
-MindStudio apps use role-based access control. Roles are defined in the manifest, assigned to users in the editor, and enforced in methods. The backend is the authority — methods enforce access control via `auth.requireRole()`. The frontend can read roles for conditional rendering, but enforcement always happens server-side.
-
-**Roles are optional.** Many apps don't need them — single-user apps, internal tools, simple utilities. If the app doesn't have multiple user types with different permissions, skip roles entirely. Only add them when the app explicitly needs to distinguish who can do what.
-
-## Defining Roles
-
-In `mindstudio.json`:
-
-```json
-{
-  "roles": [
-    { "id": "requester", "name": "Requester", "description": "Can submit vendor requests and purchase orders." },
-    { "id": "approver", "name": "Approver", "description": "Reviews and approves purchase orders." },
-    { "id": "admin", "name": "Administrator", "description": "Full access to all app functions." },
-    { "id": "ap", "name": "Accounts Payable", "description": "Processes invoices and payments." }
-  ]
-}
-```
-
-- `id` — kebab-case, used in code (`auth.requireRole('admin')`)
-- `name` — display name shown in the editor
-- `description` — what this role can do (useful for the agent and for users in the role assignment UI)
-
-Roles are synced to the platform on deploy. Adding or removing roles in the manifest creates or deletes them on the next push.
-
-## Backend Auth API
-
-```typescript
-import { auth } from '@mindstudio-ai/agent';
-```
-
-### `auth.requireRole(...roles)`
-
-Throws a 403 error if the current user doesn't have **any** of the specified roles. Use at the top of methods to gate access.
-
-```typescript
-auth.requireRole('admin');                // single role
-auth.requireRole('admin', 'approver');    // any of these
-```
-
-### `auth.hasRole(...roles)`
-
-Returns `boolean`. Same logic as `requireRole` but doesn't throw. Use for conditional behavior within a method.
-
-### `auth.userId`
-
-The current user's UUID. Always available.
-
-### `auth.roles`
-
-Array of role names assigned to the current user.
-
-### `auth.getUsersByRole(role)`
-
-Returns an array of user IDs that have the specified role. Useful for things like "notify all admins."
-
-## Frontend Auth
-
-```typescript
-import { auth } from '@mindstudio-ai/interface';
-
-auth.userId;            // current user's ID
-auth.name;              // display name
-auth.email;             // email address
-auth.profilePictureUrl; // URL or null
-```
-
-The frontend SDK provides display-only auth context. Role checking for UI purposes (showing/hiding elements) is done by reading role data from the backend:
-
-```typescript
-const { isAdmin, pendingCount } = await api.getDashboard();
-{isAdmin && <AdminPanel />}
-```
-
-The frontend is untrusted — anyone can modify JavaScript in the browser. Access control must be enforced server-side in methods. The frontend shows or hides UI based on role data from the backend, but the backend is the authority.

package/dist/compiled/design.md

@@ -1,251 +0,0 @@
-# Frontend Design Notes
-
-Design standards for web interfaces in MindStudio apps.
-
-## Quality Bar
-
-Every interface must feel like a polished, shipping product — not a
-prototype, not a starter template, not a homework assignment. The standard
-is iOS and Apple's bundled iOS apps, Notion, Stripe. If it wouldn't look
-good on Dribbble, Behance, or Mobbin, it's not done.
-
-MindStudio apps are end-user products. The interface is the product. Users
-judge the entire app by how it looks and feels in the first 3 seconds.
-
-## Design System from the Spec
-
-The brand spec files in `src/interfaces/@brand/` define the app's visual identity at the brand level: a small palette of named colors and font choices with one or two anchor styles. These are brand decisions, not implementation details. Derive the full design system (CSS variables, component styles, spacing, borders, etc.) from these foundations.
-
-Set up a lightweight theme layer early (CSS variables or a small tokens file) so brand colors and type styles are defined once and referenced everywhere. Map brand colors to semantic roles (background, text, accent, surface, border) and derive any additional shades you need. Keep it simple: a handful of CSS variables for colors and a few reusable text style classes or utilities for typography.
-
-**When brand spec files are present, always use the defined fonts and colors in generated code.** Do not pick your own fonts or colors when the spec defines them. Reference colors semantically (as CSS variables or named constants) rather than scattering raw hex values through the codebase.
-
-### Colors block format
-
-A `` ```colors `` fenced block in a `type: design/color` spec file declares 3-5 brand colors with evocative names, hex values, and descriptions. The names are brand identity names (not CSS property names), and the descriptions explain the color's role in the brand:
-
-```colors
-Midnight:
-  value: "#000000"
-  description: Primary background and dark surfaces
-Charcoal:
-  value: "#1C1C1E"
-  description: Elevated surfaces and containers
-Snow:
-  value: "#F5F5F7"
-  description: Primary text and foreground elements
-Smoke:
-  value: "#86868B"
-  description: Secondary text and supporting content
-```
-
-Derive additional implementation colors (borders, focus states, hover states, disabled states) from the brand palette rather than expecting them to be specified.
-
-### Typography block format
-
-A `` ```typography `` fenced block in a `type: design/typography` spec file declares fonts (with source URLs) and one or two anchor styles (typically Display and Body). Styles can include an optional `case` field (`uppercase`, `lowercase`, `capitalize`) for text-transform. Derive additional styles (labels, buttons, captions, overlines) from these anchors:
-
-```typography
-fonts:
-  Satoshi:
-    src: https://api.fontshare.com/v2/css?f[]=satoshi@400,500,600,700&display=swap
-  Clash Grotesk:
-    src: https://api.fontshare.com/v2/css?f[]=clash-grotesk@400,500,600&display=swap
-
-styles:
-  Display:
-    font: Satoshi
-    size: 40px
-    weight: 600
-    letterSpacing: -0.03em
-    lineHeight: 1.1
-    case: uppercase
-    description: Page titles and hero text
-  Body:
-    font: Satoshi
-    size: 16px
-    weight: 400
-    lineHeight: 1.5
-    description: Default reading text
-```
-
-## Be Distinctive
-
-AI-generated interfaces tend to converge on the same generic look: safe
-fonts, timid colors, predictable layouts. Fight this actively. Every
-interface should have character and intentionality — it should look like a
-designer made deliberate choices, not like it was generated from a template.
-
-**Typography must be a conscious choice.** Pick fonts that are beautiful,
-distinctive, and appropriate for the product's personality. Generic system
-fonts and overused defaults make everything look the same. Typography is
-the single fastest way to give an interface identity.
-
-**Commit to a color palette.** One or two dominant colors with sharp accents
-outperform timid, evenly-distributed palettes. Draw inspiration from the
-app's domain — a finance tool might use deep greens and golds; a creative
-tool might use bold, saturated primaries. The palette should feel intentional
-and owned, not randomly selected.
-
-**Backgrounds create atmosphere.** Solid white or solid gray is the safe
-default and the enemy of distinctiveness. Layer subtle gradients, use warm
-or cool tints, add geometric patterns or contextual textures. The background
-sets the mood before the user reads a single word.
-
-**Layouts should surprise.** Avoid the predictable patterns: three equal
-boxes with icons, centered hero with subtitle, generic card grid. Use
-asymmetry, varied column widths, creative negative space, unexpected
-compositions. Study Behance and Mobbin for layout inspiration. Every screen
-should feel considered, not generated.
-
-## App-Like, Not Web-Page-Like
-
-Interfaces run fullscreen in the user's browser or a wrapped webview mobile
-app. They should feel like native apps, not websites.
-
-- **No long scrolling pages.** Use structured layouts: cards, split panes,
-  steppers, tabs, grouped sections that fit the viewport. The interface
-  should feel like a single-purpose tool, not a document.
-- **On mobile**, scrolling may be necessary, but use sticky headers, fixed
-  CTAs, and anchored navigation to keep key actions within reach.
-- Think of every screen as something the user opens, uses, and closes —
-  not something they read.
-
-## Visual Design
-
-- **Typography:** Strong hierarchy — clear distinction between headings,
-  body, labels, and captions. Use weight and size, not just color, to
-  create hierarchy. Choose fonts that elevate the interface and give it
-  personality.
-- **Color:** Clean, vibrant, intentional. Use color to communicate state
-  and guide attention, not to decorate. Commit to a direction — bold and
-  saturated, or muted and editorial — and follow through consistently.
-- **Spacing:** Consistent and generous. Padding and margins should be
-  uniform across all components — nothing should feel cramped or uneven.
-  White space is a feature, not wasted space.
-- **Components:** Every component (buttons, inputs, cards, modals, lists)
-  should look like it belongs to the same design system. Consistent border
-  radii, consistent shadows, consistent padding. If two buttons on the
-  same screen look different for no reason, that's a bug.
-
-## Animation
-
-Use motion to make interactions feel polished, not to show off. Focus on
-high-impact moments: a well-orchestrated page load with staggered reveals
-creates more delight than scattered micro-interactions everywhere.
-
-- Transitions between states should be smooth but fast.
-- Streaming content should flow into containers that grow naturally without
-  pushing sibling elements around.
-- No parallax, no cheesy scroll effects, no bounce/elastic easing, no
-  gratuitous loading animations.
-
-## Layout Stability
-
-Layout shift is never acceptable. Elements jumping around as content loads
-or streams in makes an interface feel broken.
-
-- Reserve space for content that hasn't arrived yet. Use fixed/min-height
-  containers, skeletons, or aspect-ratio boxes.
-- Images must always have explicit dimensions so the browser reserves space
-  before the image loads.
-- Loading-to-loaded transitions should swap content in-place without
-  changing container size.
-- Buttons must not change size during loading states. Use a fixed width or
-  `min-width`, and swap the label for a spinner or short text that fits the
-  same space. "Submit" becoming "Submitting..." should not make the button
-  wider and push adjacent elements around.
-- Conditional UI should use opacity/overlay transitions, not insertion into
-  flow that displaces existing content.
-
-## Responsive Design
-
-Every interface must work on both desktop and mobile.
-
-- Use the full viewport. Backgrounds should extend to edges.
-- On desktop, use the space — multi-column layouts, sidebars, spacious
-  cards. Avoid narrow centered columns with empty gutters on a wide screen.
-- On mobile, stack gracefully. Prioritize content and actions.
-- Test at both extremes. A layout that only looks good at one breakpoint
-  is not done.
-
-## Forms
-
-Forms should feel like interactions, not paperwork.
-
-- Group related fields visually. Use cards or sections, not a flat list.
-- Inline validation — show errors as the user types, not after submit.
-  Validation must never introduce layout shift.
-- Loading states after submission. Always indicate that something is
-  happening.
-- Disabled states should be visually distinct but not jarring.
-- Even data entry can be beautiful. Pay attention to alignment, padding,
-  and spacing. Consistency is key.
-
-## Data Fetching and Updates
-
-The UI should feel instant. Never make the user wait for a server round-trip
-to see the result of their own action.
-
-- **Optimistic updates.** When a user adds a row, toggles a setting, or
-  submits a form, update the UI immediately and let the backend confirm
-  in the background. If the backend fails, revert and show an error.
-- **Use SWR for data fetching** (`useSWR` from the `swr` package). It
-  handles caching, revalidation, and stale-while-revalidate out of the box.
-  Prefer SWR over manual `useEffect` + `useState` fetch patterns.
-- **Mutate after actions.** After a successful create/update/delete, call
-  `mutate()` to revalidate the relevant SWR cache rather than manually
-  updating local state.
-- **Skeleton loading.** Show skeletons that mirror the layout on initial
-  load. Never show a blank page or centered spinner while data is loading.
-
-## What Good Looks Like
-
-- A dashboard that feels like Linear — clean data, clear hierarchy, every
-  pixel intentional.
-- A form that feels like Stripe Checkout — focused, calm, confident.
-- A settings page that feels like iOS Settings — organized, scannable,
-  no clutter.
-- A list view that feels like Notion — flexible, spacious, information-dense
-  without feeling crowded.
-
-## What to Actively Avoid
-
-These are the hallmarks of generic AI-generated interfaces. Every one of
-them makes an interface look like it was auto-generated rather than designed.
-
-- **Generic fonts.** Overused defaults that strip away all personality.
-  Instead: pick a distinctive Google Font that fits the app's character.
-- **Purple or indigo anything.** Purple gradients, purple buttons, purple
-  accents. This is the #1 AI-generated aesthetic cliché. Instead: use
-  a color palette that fits the app's domain — greens for finance, warm
-  neutrals for productivity, bold primaries for creative tools, or just
-  confident grayscale.
-- **Colored left-border callout boxes.** Rounded divs with a thick colored
-  `border-left` — the generic "info card" pattern. Instead: use typography,
-  spacing, and background tints to create hierarchy. If you need to call
-  something out, use a full subtle background or a top border.
-- **Three equal boxes with icons.** The default AI landing page layout.
-  Instead: use asymmetric layouts, varied column widths, or a single
-  focused content area.
-- **Timid color palettes.** Evenly distributed, non-committal colors.
-  Instead: one or two dominant colors with sharp accents. Commit to a
-  direction.
-- **Card-heavy nested layouts.** Cards inside cards, everything boxed.
-  Instead: use space, typography, and dividers to create hierarchy without
-  extra containers.
-- **Inconsistent spacing.** 12px here, 20px there, 8px somewhere else.
-  Instead: define a spacing scale (4/8/12/16/24/32/48/64) and use it
-  everywhere.
-- **Components from different visual languages.** Rounded buttons next to
-  square inputs, shadows mixed with flat design. Instead: pick one system
-  and apply it consistently.
-- **Long scrolling forms with no visual grouping.** Instead: group fields
-  into sections with clear headings, cards, or stepped flows.
-- **Cramped layouts.** Text pressed against edges, no room to breathe.
-  Instead: generous padding, comfortable margins, let the content float.
-- **Loading states that are just a centered spinner on a blank page.**
-  Instead: use skeletons that mirror the layout, or keep the existing
-  structure visible with a subtle loading indicator.
-- **Any interface where the first reaction is "this looks like a demo" or
-  "this looks like it was made with a website builder."**

package/dist/compiled/dev-and-deploy.md

@@ -1,69 +0,0 @@
-# Development & Deployment
-
-## How Development Works
-
-The sandbox uses the same tunnel binary and execution pipeline as local development. Code changes take effect immediately — esbuild transpiles methods per-request, no restart needed. The dev database is a disposable snapshot of production.
-
-### The Dev Inner Loop
-
-1. Edit method code in `dist/methods/src/` — next method invocation uses updated code automatically
-2. Edit frontend code in `dist/interfaces/web/src/` — HMR updates the browser instantly
-3. Add/modify table definitions — schema changes sync to the dev database automatically
-4. Run scenarios to set up specific data states for testing
-
-### Dev Database
-
-The dev session gets its own database — a snapshot of the live database at session start. Your code writes to this snapshot, not to production.
-
-- **Reset to live data** — overwrite the dev database with a fresh copy of production
-- **Truncate** — keep the schema, delete all row data (used by scenarios for a clean canvas)
-- **Schema sync** — add a field to a table interface and it's immediately available in dev
-
-The dev database is disposable. Experiment freely — there's no risk of breaking anything.
-
-### Debugging
-
-`console.log`, `console.warn`, and `console.error` in methods are captured and displayed in the terminal. They don't affect the method's return value. Every method execution is logged with full input, output, duration, and error info.
-
-## What Happens on Deploy
-
-```bash
-git push origin main
-```
-
-The platform builds and deploys automatically:
-
-1. **Parse manifest** — read `mindstudio.json` from the commit
-2. **Compile methods** — esbuild bundles each method into a single JS file
-3. **Compile interfaces** — build web SPA (`npm install && npm run build`), generate configs for API/Discord/Telegram/cron/etc.
-4. **Parse table schemas** — TypeScript AST to column definitions, diff against live database
-5. **Compute effects** — roles diff, cron diff, bot command diffs, table DDL
-6. **Apply** — create/update roles, sync bot commands, apply DDL to a staging database copy, swap the live pointer
-
-### Preview Deployments
-
-Push to a non-default branch for a preview deployment — same build pipeline, but doesn't affect the live app. Useful for testing changes before merging.
-
-### Database Migrations on Deploy
-
-Schema changes are automatic:
-- **New tables** — `CREATE TABLE` applied automatically
-- **New columns** — `ALTER TABLE ADD COLUMN` applied automatically
-- **Dropped columns** — `ALTER TABLE DROP COLUMN` applied automatically when a column is removed from the interface
-- **Dropped tables** — `DROP TABLE` applied automatically when a table file is removed from the manifest
-- **Type changes and renames** — not supported in the automatic migration path
-
-Schema changes are always applied to a clone of the live database, never directly. If DDL fails, the live database is untouched and the release is marked `failed`.
-
-### Rollback
-
-Rollback is a git revert — creates a new commit, triggers a new build. The previous release's database still exists (databases are per-release), so data isn't lost.
-
-### Common Build Failures
-
-- **Method compilation error** — TypeScript/syntax error in a method file. Error message includes file and line.
-- **Web build error** — npm install or build command failed. Check build log stdout/stderr.
-- **Table schema error** — TypeScript file couldn't be parsed. Ensure the table definition uses the `defineTable<T>()` pattern.
-- **Missing manifest fields** — method declared but path doesn't exist, or export doesn't match.
-
-Failed releases don't affect the current live release.