@mindstudio-ai/remy 0.1.333 → 0.1.335

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

@@ -19,7 +19,7 @@ The dev session gets its own database — a snapshot of the live database at ses
 - **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. Just be considerate that the user may have created their own data (user rows or other data) while testing, and it might be frustrating for them to have it wiped.
+The dev database's data is disposable — reset or truncate it whenever that helps. Just be considerate that the user may have created their own data (user rows or other data) while testing, and it might be frustrating for them to have it wiped. If a schema sync fails, the error names the table and what is out of step between the platform's schema record and the table itself; fix exactly that.
 
 ### Debugging
 

package/dist/prompt/compiled/tables.md

@@ -389,20 +389,14 @@ const [_, newOrder, pending] = await db.batch(
 
 ## Migrations
 
-No migration files. Migrations 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
-
-On deploy, the platform:
-1. Parses your table definition files (TypeScript AST — the interface IS the schema)
-2. Diffs against the current live database schema
-3. Generates DDL (`CREATE TABLE`, `ALTER TABLE ADD COLUMN`, `ALTER TABLE DROP COLUMN`, `DROP TABLE`)
-4. Applies to a staging copy of the database
-5. Promotes the staging copy to live
-
-The TypeScript interface is the single source of truth for the schema. Add a field to the interface, push, and the column exists. No migration files, no CLI commands.
-
-**In development**, schema changes are synced automatically to the dev database. The dev database is a disposable snapshot — it can be reset to a fresh copy of production data or truncated to empty tables at any time. There's no risk of breaking anything by experimenting with schema changes in dev.
+No migration files. The table's TypeScript interface is the schema, and the platform brings the database to match it:
+- **New tables** — created
+- **New, dropped, or retyped columns, and changed `unique` constraints** — the table is rebuilt: a table with the declared shape is created, every row is copied across, and it replaces the old one in one transaction. New columns arrive empty; dropped columns and their data are gone; a retyped column's values are carried across, converted where SQLite can.
+- **Dropped tables** — dropped when the table file is removed from the manifest
+- **Renames** — not detected; a renamed column or table is a drop plus an add, and its data does not carry over
+
+On deploy, the platform parses the table files, diffs against the live schema, applies the changes to a clone of the live database, and promotes the clone. If any change fails, the release fails and the live database is untouched.
+
+Add a field to the interface, push, and the column exists. No migration files, no CLI commands.
+
+**In development**, schema changes are applied to the dev database automatically, by the same rules. Its data is disposable — it can be reset to a fresh copy of production or truncated to empty tables at any time. If a schema sync fails, the error names the table and what is out of step between the platform's schema record and the table itself; fix exactly that.

package/dist/prompt/skills/auth.md

@@ -100,6 +100,7 @@ export const Users = db.defineTable<{
 
 ### Platform-Managed Column Behavior
 
+- **`id`** — the platform-assigned managed-user UUID. Omit it on every insert (`Users.push({ email, ... })`) and let it default; never hand-write one (`id: 'analyst-test'`, etc.). A non-UUID id can't map to the platform user record — it silently never syncs and orphans the row. Reference a user by the id returned from `Users.push(...)`, never a made-up string. (This is the trap scenario seeds fall into — see the `scenarios` skill.)
 - **`email` / `phone` / `apiKey`** — read-only from code. Writing via `update()` or `push()` throws a `MindStudioError`. Use the auth API to change a user's email or phone, and `auth.createApiKey()` / `auth.revokeApiKey()` for API keys.
 - **`roles`** — read/write from both code and the dashboard. `Users.update(userId, { roles: ['admin'] })` works and syncs to the platform. Dashboard role changes sync back to the table.
 - All other columns are fully the developer's. When auth creates a user row, only the managed columns (email/phone, roles) are populated. All user-defined columns start as null until the user completes onboarding — type them as optional and guard against null.

package/dist/prompt/skills/scenarios.md

@@ -52,11 +52,20 @@ Scenarios live at `dist/methods/.scenarios/` — inside the methods package scop
 // dist/methods/.scenarios/apOverdueInvoices.ts
 
 import { db } from '@mindstudio-ai/agent';
+import { Users } from '../src/tables/users';
 import { Vendors } from '../src/tables/vendors';
 import { PurchaseOrders } from '../src/tables/purchase-orders';
 import { Invoices } from '../src/tables/invoices';
 
 export async function apOverdueInvoices() {
+  // Seed an app user through the auth-mapped table. Never set `id` — omit it so
+  // the platform assigns the UUID that maps this row to its managed user. A
+  // hand-written id ('user-requester-1', etc.) can't sync and orphans the row.
+  const requester = await Users.push({
+    email: 'jordan@example.com',
+    roles: ['requester'],
+  });
+
   const vendor = await Vendors.push({
     name: 'Acme Corp',
     contactEmail: 'billing@acme.com',
@@ -65,7 +74,7 @@ export async function apOverdueInvoices() {
 
   const po = await PurchaseOrders.push({
     vendorId: vendor.id,
-    requestedBy: 'user-requester-1',
+    requestedBy: requester.id,
     totalAmountCents: 500000,
     status: 'active',
   });
@@ -93,7 +102,8 @@ An empty scenario is valid — it exists so you can switch to "clean slate" stat
 
 ```typescript
 export async function emptyRequester() {
-  // No data — the truncate clears everything.
+  // No data — the truncate clears every table (the auth users table aside,
+  // whose real accounts are preserved).
 }
 ```
 
@@ -102,7 +112,7 @@ Shared setup code can go in `dist/methods/.scenarios/_helpers/`.
 ## How Scenarios Run
 
 When a scenario runs, the platform:
-1. **Truncates** all tables (deletes all rows, preserves schema - unless skipTruncate is true)
+1. **Truncates** all tables (deletes all rows, preserves schema - unless skipTruncate is true). The auth-mapped users table is the exception — it's preserved, because its rows are real app accounts mirrored to the platform, so a reseed must never delete them. Seed users additively with `Users.push(...)` (id omitted); they persist across reseeds.
 2. **Executes** the seed function (your `db.push()` calls populate the clean database)
 3. **Assigns** the roles from the scenario's `roles` field to the dev test user — a real write to that user's row, so it requires app auth to be enabled
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.333",
+  "version": "0.1.335",
   "description": "Remy coding agent",
   "repository": {
     "type": "git",