Build with database and authentication

Model runtime records and saved actions, define access deliberately, and exercise the intended identity paths in Preview. Treat the current database/authentication export and backend story as unfinished: use documentation-safe data only and do not ship real Users credentials from the current workflow.

Coverage: UI + MCP for schema, records, actions, mounts, and Preview. Partial MCP/product coverage for a production backend and exported client authentication.

Understand the files

Ordinary runtime tables live below database/, normally under database/tables/. The fixed database/auth/users table supplies authentication identities and stable system fields:

• Email: required, unique, primary email string;

• Password: required secret password input, stored as a hash;

• Verified: boolean;

• Created: computed date/time;

• Role: relation to the structural Roles table.

The Users file is protected from rename, move, duplicate, and delete. You can add application fields, but protected base field identities and datatypes remain part of authentication behavior.

Model an ordinary table

1. Create a Database table in the intended folder.

2. In Model, add the smallest schema that represents the domain.

3. Set primary, required, unique, secret, computed, default, format, and relation options only where needed.

4. In Data, create documentation-safe representative records.

5. In Actions, define saved View, Insert, Update, or Delete operations.

6. Configure access, parameters, writable/default fields, returned fields, filters, sorting, grouping, aggregates, pagination, or limits according to the action kind.

7. Preview each action under the identities it should allow and deny.

Column migrations can transform or clear incompatible cell data. Inspect affected records before changing a datatype or deleting a column.

Configure identity and access

Use public access only for data that is genuinely public. For signed-in or role-restricted behavior:

1. verify the Users and Roles structures;

2. create only fake users in a disposable/documentation project;

3. set the Preview identity deliberately;

4. test allowed and denied paths;

5. confirm secret columns are absent from readable result shapes and conditions.

Preview deliberately returns the same authentication failure for an unknown email and an incorrect password to avoid account enumeration.

Mount Views and call actions

Components consume a saved View through mount-view. Runtime write behavior refers to persisted Insert, Update, or Delete action definitions and supplies their allowed parameters and writable values.

Keep read and write proof separate. A View can be safely previewed without authorizing a write action. Running table-run-action can mutate records and must be requested explicitly.

Ask an agent to prepare the model

In the Website project, inspect <table reference>, the protected Users/roles structures, and <consumer Component reference>. Define <schema> and saved actions <actions/access/parameters> using only fake records. Mount <View> in the Component and wire the visible read state. Show the proposed write-action inputs, but do not run table-run-action, create a real user, expose password hashes, export frontend data, or publish a backend. Preview public, allowed, and denied identities; report the current shipping limitations and stop.

MCP table-* operations cover schema, rows, saved actions, aggregates, identity, Preview, and explicit execution. Server-side validation still applies to protected, secret, relation, and Content-file restrictions.

Verify the model

• inspect table schema and current records after any migration;

• inspect every action's kind, parameters, writable/default/returned fields, and access rule;

• preview View results as public, signed-out, and each relevant role;

• prove denied requests fail closed;

• verify secret fields never appear in readable shapes;

• inspect Component mounts and generated output;

• test the actual backend separately before production use.

Current shipping status

The model and Preview can express more than the current generated stack safely ships:

• Component authentication actions currently export as a TODO rather than a complete client sign-in/sign-out implementation.

• The public backend boilerplate's SQL action execution path is not production-ready.

• Complete exclusion of Users data and password hashes from frontend export is marked unfinished in the current source.

Until those boundaries are implemented and runtime-verified, keep Users data editor-only, use no real credentials, and do not describe the current workflow as production authentication.

Undo and external effects

Allowed schema, action-definition, and editor record changes use table transaction behavior. A write action executed against runtime/backend data is a separate side effect; undoing its definition does not restore affected records.

Before a real write, record the target environment, exact action, affected rows, authorization, and rollback procedure.