@prisma/orm-sqlite 8.0.0-rc.11-dev.46 → 8.0.0-rc.11-dev.47

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prisma/orm-sqlite",
-  "version": "8.0.0-rc.11-dev.46",
+  "version": "8.0.0-rc.11-dev.47",
   "license": "Apache-2.0",
   "type": "module",
   "sideEffects": false,
@@ -10,16 +10,16 @@
     "skills"
   ],
   "dependencies": {
-    "@prisma/orm-family-sql": "8.0.0-rc.11-dev.46",
-    "@prisma/orm-framework": "8.0.0-rc.11-dev.46",
-    "@prisma/orm-target-sqlite": "8.0.0-rc.11-dev.46",
-    "@prisma/orm-toolchain": "8.0.0-rc.11-dev.46",
+    "@prisma/orm-family-sql": "8.0.0-rc.11-dev.47",
+    "@prisma/orm-framework": "8.0.0-rc.11-dev.47",
+    "@prisma/orm-target-sqlite": "8.0.0-rc.11-dev.47",
+    "@prisma/orm-toolchain": "8.0.0-rc.11-dev.47",
     "pathe": "^2.0.3"
   },
   "devDependencies": {
-    "@internal/sqlite": "8.0.0-rc.11-dev.46",
-    "@repo/tsconfig": "8.0.0-rc.11-dev.46",
-    "@repo/tsdown": "8.0.0-rc.11-dev.46",
+    "@internal/sqlite": "8.0.0-rc.11-dev.47",
+    "@repo/tsconfig": "8.0.0-rc.11-dev.47",
+    "@repo/tsdown": "8.0.0-rc.11-dev.47",
     "tsdown": "0.22.14",
     "typescript": "5.9.3"
   },

package/skills/prisma-8/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   ORM 7 or earlier (schema.prisma + @prisma/client).
 metadata:
   library: '@prisma/orm-sqlite'
-  library_version: '8.0.0-rc.11-dev.46'
+  library_version: '8.0.0-rc.11-dev.47'
   version: '2026-09-12'
 ---
 

package/skills/prisma-8/references/debug.md

@@ -101,7 +101,7 @@ The single source of truth: read the envelope, find the row by `code`, follow th
 | `MIGRATION.PATH_UNREACHABLE` / `MIGRATION.MARKER_MISMATCH` | `db migrate` | Run `db migrate --show --db $URL` to inspect the path, then `migration plan --from <from> --to <target>` or `migration list` to audit the graph — see `references/migration-review.md`. |
 | `MIGRATION.PLAN_ORIGIN_UNKNOWN` / `MIGRATION.HASH_NOT_IN_GRAPH` / `MIGRATION.SNAPSHOT_MISSING` | `migration plan` | Origin resolution — `references/migration-model.md` § *The trap* and `references/migrations.md` § *Dev → ship transition*. |
 | `MIGRATION.MISSING_INVARIANTS` | `migration status` `warn` diagnostic (exit 0) | The live marker reached the destination hash structurally but doesn't carry all invariants the target ref requires. Run `db migrate --to <name> --db $URL` to take a path that covers the missing invariants. See `references/migration-review.md`. |
-| `MIGRATION.MARKER_NOT_IN_HISTORY` / `CONTRACT.UNREADABLE` | `migration status` `warn` diagnostics (exit 0; CI gates parse `--json`) | Read `severity` *and* `code`. Up-to-date / pending / no-marker states are not codes — read `spaces[].currentContract` and `migrations[].status` in the `--json` document. `references/migration-review.md` covers the marker-out-of-history flow. |
+| `MIGRATION.MARKER_NOT_IN_HISTORY` / `CONTRACT.UNREADABLE` | `migration status` `warn` diagnostics (exit 0) | Read `severity` *and* `code`. Up-to-date / pending / no-marker states are not codes — read `spaces[].currentContract` and `migrations[].status` in the `--json` document. `references/migration-review.md` covers the marker-out-of-history flow. |
 | `BUDGET.ROWS_EXCEEDED` / `BUDGET.TIME_EXCEEDED` | Runtime, when the `budgets` middleware is active | Tune `budgets({ maxRows, maxLatencyMs, ... })` or rewrite the query. See `references/runtime.md`. |
 | `LINT.SELECT_STAR` / `LINT.NO_LIMIT` / `LINT.DELETE_WITHOUT_WHERE` / `LINT.UPDATE_WITHOUT_WHERE` / `LINT.READ_ONLY_MUTATION` | Runtime, when the `lints` middleware is active | Fix the query (add a `WHERE` / `LIMIT` / explicit columns), or relax the lint config. See `references/runtime.md`. |
 | `PLAN.HASH_MISMATCH` | Runtime, executing a precompiled plan | The contract the plan was built against does not match the runtime contract. Re-emit, rebuild, redeploy. |

package/skills/prisma-8/references/migration-review.md

@@ -84,8 +84,6 @@ These codes surface on `migration plan`, `migration ref set`, and `db migrate`
 | `MIGRATION.MARKER_MISMATCH` | `db migrate` (pre-DDL, before the runner) | Live DB marker hash is not a graph node — drift the offline planner cannot see. | `migration plan --from <graph-tip>` if the marker is canonical; `migration ref set db <marker-hash>` if the on-disk graph is canonical; investigate out-of-band applies. |
 | `MIGRATION.PATH_UNREACHABLE` | `db migrate` (path resolution) | No migration path from the current marker to the resolved target in the on-disk graph. | Read the improved `fix` payload — it names `fromHash` / `targetHash` and suggests `migration plan --from <from> --to <target>`; run `migration list` to inspect the graph. |
 
-A CI gate should read `diagnostics` from `--json` output and decide based on `severity` plus `code`; see *Workflow — CI* below for the structure.
-
 ## Workflow — *"What's about to run on deploy?"*
 
 The user asks: *"I'm about to merge this PR. What migrations are going to run when I deploy to staging?"*
@@ -166,46 +164,18 @@ The mismatch is a fact about *two pieces of state that disagree*. The investigat
 
 `migration ref set` to silently align the ref with whatever the DB happens to be at is almost never the right move. It papers over drift that you'll pay for later.
 
-## Workflow — CI: verify a branch can advance the target environment
-
-The gate is `migration status --to <env> --db $URL`: it computes the path from the live marker to the ref and reports it, without mutating anything. There is no `--dry-run` flag on `db migrate`; the inspect / gate step is `migration status`.
+## Workflow — CI: deploy to an environment
 
-For a human-readable ordered preview of the migration path before applying, use `db migrate --show --db $URL`. For applied history after a deploy, use `migration log --db $URL` (flat chronological table).
+The whole job is one command:
 
 ```yaml
-- name: Verify staging is reachable
-  run: |
-    pnpm prisma migration status \
-      --to staging --db "$STAGING_DATABASE_URL" --json > status.json
-    node -e '
-      const s = JSON.parse(require("fs").readFileSync("status.json", "utf8"));
-      const problems = [];
-      for (const d of s.diagnostics ?? []) {
-        if (d.severity === "warn") problems.push(`${d.code}: ${d.message}`);
-      }
-      for (const space of s.spaces ?? []) {
-        if (space.currentContract === null) problems.push(`${space.space}: database has no marker`);
-        const unreachable = space.migrations.filter(m => m.status === "unreachable");
-        if (unreachable.length) problems.push(`${space.space}: ${unreachable.length} unreachable migration(s)`);
-      }
-      // Pending migrations are the normal case before Apply; block on them
-      // only if this job is a verify-only gate (set EXPECT_UP_TO_DATE=1).
-      if (process.env.EXPECT_UP_TO_DATE === "1") {
-        for (const space of s.spaces ?? []) {
-          const pending = space.migrations.filter(m => m.status === "pending");
-          if (pending.length) problems.push(`${space.space}: ${pending.length} pending migration(s)`);
-        }
-      }
-      if (problems.length) {
-        console.error("Blocking:\n" + problems.join("\n"));
-        process.exit(1);
-      }
-    '
-- name: Apply
+- name: Migrate staging
   run: pnpm prisma db migrate --to staging --db "$STAGING_DATABASE_URL"
 ```
 
-`migration status` exits non-zero only on hard errors (unreadable migrations directory, unsatisfiable invariants, unreconstructable history). Pending migrations, a missing marker (`currentContract: null`), and the `warn` diagnostics (`MIGRATION.MARKER_NOT_IN_HISTORY`, `MIGRATION.MISSING_INVARIANTS`, `CONTRACT.UNREADABLE`) all leave the exit code at `0` — the agent (or a CI gate) must inspect `spaces[]` and `diagnostics[]` and fail the build itself. Use `--json` so the gate parses a structured shape rather than the human summary.
+`db migrate` is safe to run unattended, by design. Before any operation runs it reads the live marker and refuses with `MIGRATION.MARKER_MISMATCH` if that hash is not a node in the on-disk graph, which is what a database changed outside the migration system looks like. Each operation then evaluates its own `precheck[]` and stops if the database is not in the state the operation expects. A successful run writes the destination hash as the new marker. Nothing runs before `db migrate` in the job.
+
+`migration status --to staging --db $URL` is what a human or agent runs to answer *"what will run on deploy?"* before merging: it reports the path from the live marker to the ref without changing anything. `db migrate --show --db $URL` gives the same path as an ordered preview; `migration log --db $URL` gives the applied history after a deploy.
 
 `db migrate` is interactive-free and has no destructive-op confirmation prompt — the safety rails that prompt for destructive changes live on `db update` (see the `references/migrations.md` skill). Whatever the planner put in the migration graph is what `db migrate` runs; review happens at `migration plan` and at `migration status` time, before the apply step.
 
@@ -235,7 +205,7 @@ This skill is intentionally body-only; the underlying CLI reference (`prisma mig
 - [ ] For concurrent-migration conflicts: re-applied the *core* workflow (edit → plan → apply) rather than following a memorised "diamond convergence" procedure. Ported any data-transform logic from the abandoned `migration.ts` over.
 - [ ] For a ref-mismatch: investigated *which* piece of state is wrong (DB ahead, DB behind, DB on a divergent branch). Did NOT `migration ref set` to silence the mismatch.
 - [ ] Surfaced the destructive-op count from `migration status` (the only operation class that warrants manual review pre-deploy) before the user merges or deploys.
-- [ ] In CI: parsed `migration status --json` `diagnostics[]` and gated on `severity === 'warn'`; did NOT rely on a `--dry-run` flag on `db migrate` (no such flag exists).
+- [ ] In CI: the deploy job is `prisma db migrate --to <ref> --db $URL` and nothing else. Did NOT rely on a `--dry-run` flag on `db migrate` (no such flag exists).
 - [ ] Did NOT confuse `--to` with database selection (`--to` picks the destination hash; `--db` picks the database).
 - [ ] Did NOT use `--ref` (removed; use `--to`).
 - [ ] Did NOT confabulate a "branch diff" CLI subcommand, a `migration revalidate` step, or any other API the skill above doesn't reference.