@mortar-ai/skill 0.6.0 → 0.7.0

package/references/schema-migrations.md

@@ -1,16 +1,29 @@
 # Schema migrations and resource artifacts
 
 Read this reference when authoring backend source, reviewing a typed migration
-plan, resolving revision/checksum conflicts, generating app-data types, or
+plan, resolving revision/checksum conflicts, writing application data types, or
 deciding whether a Mortar capability belongs in source at all.
 
-## One canonical plan, four derived type targets
+## One canonical plan, AI-owned application types
 
 Mortar parses SQL into `mortar.migration-plan.v1`, a language-neutral JSON plan.
 That plan—not TypeScript, Swift, Kotlin, or Dart code—is the execution contract.
-After a successful apply, the canonical live schema may generate app-data models
-for all four SDK languages. Generated models are downstream output; never edit
-them to request a schema change.
+Mortar does not generate project source. After apply, the AI Turn combines the
+canonical live schema, the relevant operations from `references/openapi.yaml`,
+and the project's runtime conventions to write application-owned models and
+request/response code through Harness. Those files are downstream consumers;
+never edit them to request a schema change.
+
+Search the OpenAPI by stable operation ID, for example:
+
+```sh
+rg -n 'operationId: (insertDatabaseRows|listDatabaseRows)' \
+  /tmp/skills/mortar/references/openapi.yaml
+```
+
+Read the selected operation and every referenced component schema before
+writing code. An operation marked `x-mortar-project-code: forbidden` belongs to
+Harness/control-plane tooling and must never be called from a user app.
 
 ## Versioned database SQL
 
@@ -31,8 +44,14 @@ ALTER TABLE submissions SET ACCESS app_only;
 
 The parser accepts common PostgreSQL type spellings and canonicalizes them to
 Mortar's logical types: `text`, `number`, `bool`, `json`, `timestamp`, and
-`uuid`. It rejects row data, backfills, triggers, stored procedures, transaction
-control, and calls that pretend functions/storage/cron are SQL.
+`uuid`. `id`, `created_at`, and `updated_at` are server-owned row metadata, so
+they are not declared as application columns; system timestamps may still be
+used in an index, as above. `NOT NULL` enforces required-field presence. Logical
+type names inform project-language types but do not currently runtime-validate
+every row value. The parser rejects `DEFAULT`, `UNIQUE`, `CHECK`, foreign keys,
+row data, backfills, triggers, stored procedures, transaction control, and calls
+that pretend functions/storage/cron are SQL. Never invent unsupported DDL or
+describe client validation as a database constraint.
 
 Plan/apply guarantees: