@prisma/orm-mongo 8.0.0-rc.1-dev.45 → 8.0.0-rc.10

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.3-to-8.0.0-rc.4/instructions.md

@@ -0,0 +1,158 @@
+---
+from: "8.0.0-rc.3"
+to: "8.0.0-rc.4"
+changes:
+  - id: prisma-config-hard-cut-and-top-level-commands
+    summary: |
+      The deprecated fallbacks are gone: the CLI no longer reads
+      `prisma-next.config.ts`, no longer accepts the flat (un-nested) config shape, and the
+      `prisma-next` command no longer exists. The unified CLI (`@prisma/cli`, installed from
+      the `next` dist-tag; its binary is currently `prisma-cli`) runs the ORM commands at the
+      top level — `contract emit`, `db init`, `migration plan`, `migrate` — with only `init`
+      under the `orm` group (`orm init`), and the only config it reads is `prisma.config.ts`
+      in the engine envelope shape.
+
+      1. Rename `prisma-next.config.ts` to `prisma.config.ts` if you have not already.
+      2. Rewrite the export to the envelope shape. Old flat shape:
+         `import { defineConfig } from '@prisma/orm-postgres/config';`
+         `export default defineConfig({ contract: '…', db: { connection: … } });`
+         New shape:
+         `import { definePrismaConfig } from '@prisma/cli-engine';`
+         `import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';`
+         `export default definePrismaConfig({ orm: ormConfig({ contract: '…', db: { connection: … } }) });`
+         The options object moves into the target helper unchanged. The same pattern applies
+         to `@prisma/orm-sqlite/config` and `@prisma/orm-mongo/config`.
+      3. If the config reads `process.env`, keep (or add) `import 'dotenv/config';` as the
+         first import — the loader does not read `.env` for you.
+      4. In `package.json`, replace the `prisma-next` devDependency with `prisma@latest`
+         plus `@prisma/cli-engine` at the exact version that `@prisma/cli` names in its own
+         dependencies, and rewrite scripts: `prisma-next <subcommand>` becomes
+         `prisma-cli <subcommand>` (`migration apply` becomes `migrate`; `init` alone moves
+         under the orm group as `prisma-cli orm init`).
+      5. Run `prisma-cli contract emit` to confirm the config loads and to regenerate the
+         artifacts (their generated-file headers change with this release).
+    detection:
+      glob: "**/prisma-next.config.ts"
+  - id: raw-moves-to-its-own-lane
+    summary: |
+      Whole-query raw SQL moves address: ``db.sql.raw`SELECT ...` `` becomes
+      ``db.raw.sql`SELECT ...` ``. Everything after the template is unchanged.
+      `.returnsRow(spec)`, `.affectedCount()`, `.returns(codecId)`, and splicing a
+      row-returning statement into another template all behave as they did.
+
+      The client's `raw` property changes shape in the same move. It was a tagged template you
+      could call directly for an expression fragment. It is now the raw lane, an object whose
+      `sql` key holds the statement tag.
+
+      An author who called `db.raw` as a fragment tag has two replacements. Use `fns.raw`
+      inside a builder callback, which is where fragments belong. Or terminate the lane's tag
+      with `.returns(codecId)` for the same expression, now bound to the contract.
+    detection:
+      glob: "**/*.{ts,tsx,mts,cts}"
+      regex:
+        # The old whole-query address, on any receiver.
+        - '\.sql\.raw`'
+        # The client tag being repurposed. `fns.raw` is a fragment call site and
+        # is deliberately excluded: fragments are unchanged by this release.
+        - '(?<!(?<![\w$])fns)\.raw`'
+      anyMatch: true
+  - id: raw-is-no-longer-a-reserved-namespace
+    summary: |
+      A storage namespace named `raw` is allowed again. 8.0.0-rc.2 and 8.0.0-rc.3 refused such a contract when
+      the client was built, with `ORM.NAMESPACE_RESERVED`, because the SQL surface answered
+      `db.sql.raw` with the raw tag. The tag has moved to `db.raw.sql`, so nothing a contract
+      declares can collide with it.
+
+      If you renamed a namespace to get past that error, you may rename it back:
+      `@@schema("raw")` is an ordinary name, reachable as `db.sql.raw.<table>`. Re-emit the
+      contract afterwards, then plan the rename against the database as you would any other
+      namespace rename. The physical schema keeps the name it has until a plan moves it.
+      Renaming back is optional: a namespace you renamed away stays valid.
+    detection:
+      glob: "**/*.{prisma,json}"
+      contains:
+        - "ORM.NAMESPACE_RESERVED"
+        - '@@schema("raw")'
+      anyMatch: true
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.4. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. This applies even to projects whose config needed no
+      migration — the restamp is independent of the config changes above.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.3"'
+---
+
+# 8.0.0-rc.3 → 8.0.0-rc.4 — User upgrade instructions
+
+## `raw-moves-to-its-own-lane`
+
+Whole-query raw SQL has its own front door. The tag that sat inside the namespace map is now a
+lane on the client:
+
+```ts
+// Before
+const plan = db.sql.raw`SELECT id, email FROM users WHERE id = ${1}`
+  .returnsRow({ id: users.columns.id, email: users.columns.email })
+  .build();
+
+// After
+const plan = db.raw.sql`SELECT id, email FROM users WHERE id = ${1}`
+  .returnsRow({ id: users.columns.id, email: users.columns.email })
+  .build();
+```
+
+Everything after the template is unchanged: the terminators, the row specs they take, the plans
+they build, and splicing a row-returning statement into another template.
+
+The client's `raw` property changes shape in the same move. It was the expression tag you could
+call directly; it is now the lane, whose `sql` key holds the statement tag:
+
+```ts
+// Before: `raw` is a tag
+const upper = db.raw`UPPER(${email})`.returns('pg/text@1');
+
+// After, inside a builder callback — where fragments belong
+const rows = db.sql.public.users
+  .select((f, fns) => ({ upper: fns.raw`UPPER(${f.email})`.returns('pg/text@1') }))
+  .build();
+
+// After, from the lane, for a fragment you hold on its own
+const upper = db.raw.sql`UPPER(${email})`.returns('pg/text@1');
+```
+
+The detector looks for the old address and for `raw` used as a tag. It skips the receiver `fns`
+exactly, including `x.fns.raw`, because that is a fragment call site and needs no change. A
+receiver that merely ends in those letters, such as `myfns.raw`, still matches. So does a
+builder callback that names its functions object something else. Check whether the receiver is
+a client before you change anything.
+
+## `raw-is-no-longer-a-reserved-namespace`
+
+8.0.0-rc.2 and 8.0.0-rc.3 refused a contract whose storage declared a namespace named `raw`, because that was
+the key the SQL surface answered with the raw tag:
+
+```text
+ORM.NAMESPACE_RESERVED: The SQL surface exposes the raw statement tag as "db.raw", so a storage
+namespace named "raw" cannot be reached through it. Rename the namespace in the schema.
+```
+
+That constraint is gone. `db.sql` is a namespace map and nothing else, and the lane is composed
+by the client rather than derived from your contract, so the two cannot collide.
+
+If you renamed a namespace to get past the error, you may rename it back:
+
+```prisma
+model Event {
+  id String @id
+  @@schema("raw")
+}
+```
+
+Its tables are then reachable as `db.sql.raw.<table>`, like any other namespace. Re-emit the
+contract, and plan the rename against the database as you would any other namespace rename —
+the physical schema carries the old name until a plan moves it. Renaming back is optional; the
+name you moved to stays valid.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.4-to-8.0.0-rc.5/instructions.md

@@ -0,0 +1,42 @@
+---
+from: "8.0.0-rc.4"
+to: "8.0.0-rc.5"
+changes:
+  - id: attach-pg-client-error-listener
+    summary: |
+      Attach an 'error' listener to any pg `Client` or `Pool` your own code constructs outside the Prisma runtime. node-postgres emits 'error' on the pool or client when an idle connection drops (database restart, pooler timeout, network blip); with no listener Node treats it as an uncaught exception and kills the process. Starting at rc.5 every pool and client the Prisma runtime creates or receives — including a pool you pass via the `pg:` binding — gets a listener automatically, so this only applies to pg handles your code uses directly (health checks, side-channel observers, hand-rolled scripts).
+    detection:
+      glob: "**/*.{ts,tsx}"
+      contains:
+        - "new Client("
+        - "new pg.Client("
+        - "new Pool("
+        - "new pg.Pool("
+      anyMatch: true
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.5. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. The restamp is independent of the other changes in this
+      release.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.4"'
+---
+
+# 8.0.0-rc.4 → 8.0.0-rc.5 — User upgrade instructions
+
+## `attach-pg-client-error-listener`
+
+Walk every file matched by `detection.glob`. For each `pg.Client` or `pg.Pool` your code constructs and uses directly (not one handed to `postgres({ pg: ... })` / `supabase({ pg: ... })` — the runtime covers those since rc.5), attach an `'error'` listener right after construction, before `connect()`:
+
+```ts
+const client = new pg.Client({ connectionString });
+client.on('error', () => {});
+await client.connect();
+```
+
+A no-op listener is enough: connect and query failures still reject their own promises, so nothing real is masked — the listener only stops a dropped idle connection from becoming an uncaught exception. If the handle is long-lived and you have a logging channel, log the error instead of discarding it.
+
+Note that a surrounding `try/catch` does **not** cover this case — the `'error'` event is emitted on the client object asynchronously, outside any promise chain the `catch` can see.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.5-to-8.0.0-rc.6/instructions.md

@@ -0,0 +1,157 @@
+---
+from: "8.0.0-rc.5"
+to: "8.0.0-rc.6"
+changes:
+  - id: postgres-temporal-representations
+    summary: |
+      PostgreSQL temporal columns no longer read as JavaScript `Date`. Each of `date`,
+      `timestamp(p)`, `timestamptz(p)` and `time(p)` now offers two explicit representations,
+      and five codecs were removed with no compatibility aliases:
+
+      | Retired | Replace with (Temporal) | Replace with (text) |
+      | --- | --- | --- |
+      | `pg/date@1` | `Date` → `pg/date-temporal@1` (`Temporal.PlainDate`) | `DateString` |
+      | `pg/timestamp@1` | `Timestamp(p)` → `pg/timestamp-temporal@1` (`Temporal.PlainDateTime`) | `TimestampString(p)` |
+      | `pg/timestamptz@1` | `Timestamptz(p)` → `pg/timestamptz-temporal@1` (`Temporal.Instant`) | `TimestamptzString(p)` |
+      | `pg/time@1` | `Time(p)` → `pg/time-temporal@1` (`Temporal.PlainTime`) | `TimeString(p)` |
+      | `sql/timestamp@1` (`field.timestamp()`) | `Timestamptz(p)` or `field.temporal.timestamptz(p)` | `TimestamptzString(p)` |
+
+      1. **Decide a representation per column.** The bare PSL spellings (`Date`, `Timestamp`,
+         `Timestamptz`, `Time`) keep working and now select the Temporal-backed codec. If a
+         column's values should stay text — because your code treats them as strings, or
+         because they include values Temporal cannot denote (`infinity`, non-ISO `DateStyle`
+         output, years beyond ±271821) — rename the type to its `*String` spelling. Note
+         `pg/time@1` already handed back a `string`: a `time` column whose value you treat as
+         text needs `TimeString(p)`, not `Time(p)`.
+      2. **Replace `field.timestamp()`.** The generic cross-target helper and its
+         `sql/timestamp@1` codec are gone. On PostgreSQL use `field.temporal.timestamptz(p)`
+         (or `field.temporal.timestamptzString(p)`), or the bare `Timestamptz(p)` type.
+      3. **Repoint any codec id you wrote by hand.** Ids appear in raw-lane return
+         declarations (``db.raw.sql`now()`.returns('pg/timestamptz@1')``), in
+         `prepare({ id })`, and in hand-built contracts. A retired id no longer resolves and
+         fails contract validation rather than degrading silently.
+      4. **Re-emit every contract.** `prisma contract emit` rewrites `contract.json` and
+         `contract.d.ts` together; the generated application types are where the new
+         representation becomes visible. Commit the regenerated artifacts. A contract emitted
+         before this release references a codec the registry cannot resolve and is rejected at
+         runtime.
+      5. **Provide a Temporal implementation if you kept any Temporal-backed column.** Prisma
+         bundles no polyfill. Where the runtime has no native `Temporal`, install a global one
+         in your entry point before any query runs — `import 'temporal-polyfill/full/global';`.
+         Take `full/global`, not `global`: the default build omits non-ISO calendars and its
+         published types resolve to `export {}`, so TypeScript will not see the namespace.
+         **Every read** of a Temporal-backed column needs it, and so does any insert into a
+         table carrying `temporal.updatedAt()`, whose generated value is a `Temporal.Instant`.
+         Without it the operation fails with `RUNTIME.TEMPORAL_UNAVAILABLE`, which names the
+         codec and recommends the matching `*String` type. A contract whose temporal columns
+         are all `*String` needs no Temporal anywhere.
+      6. **Update application code that consumed a `Date`.** `Temporal.Instant.from()` parses
+         **only an ISO string carrying an offset** — it throws on a `Date`, on an
+         epoch-millisecond number, and on a date-time string with no offset. Convert by source:
+
+         | You have | Use |
+         | --- | --- |
+         | a `Date` | `instant = date.toTemporalInstant()`, or `Temporal.Instant.fromEpochMilliseconds(date.getTime())` |
+         | epoch milliseconds | `Temporal.Instant.fromEpochMilliseconds(ms)` |
+         | an ISO string **with** an offset (`…Z`, `…+02:00`) | `Temporal.Instant.from(text)` |
+         | an ISO string **without** an offset | pick the zone it meant: `Temporal.PlainDateTime.from(text).toZonedDateTime('UTC').toInstant()` |
+         | "now" | `Temporal.Now.instant()` |
+
+         Match the column, not just the type name: a `date` column takes a
+         `Temporal.PlainDate` (`Temporal.PlainDate.from('2024-01-01')`), a `timestamp` column a
+         `Temporal.PlainDateTime`, a `time` column a `Temporal.PlainTime`. Only `timestamptz`
+         takes an `Instant`.
+
+         `Temporal.Instant.compare(a, b)` replaces `a.getTime() - b.getTime()`, but **both
+         operands must already be `Instant`s** — it throws on a `Date`. Values read back from
+         the ORM already are; convert anything you brought from elsewhere first.
+
+         In tests, be careful with **`toMatchObject`**. A Temporal value has no own enumerable
+         properties — every accessor lives on the prototype — so a subset matcher finds nothing
+         to compare and passes for *any* value of the same type. `toEqual` is not affected
+         (Vitest compares these correctly), but `toMatchObject` will silently stop checking the
+         timestamp. Where you need a subset match, compare `toString()` or use the type's own
+         `equals` / `compare`.
+    detection:
+      glob: "**/*.{ts,mts,cts,prisma,json}"
+      regex:
+        - "pg/(date|timestamp|timestamptz|time)@1"
+        - "sql/timestamp@1"
+        - "field\\.timestamp\\("
+      anyMatch: true
+  - id: literal-default-needs-the-string-spelling
+    summary: |
+      A literal `@default(...)` on a Temporal-backed temporal column cannot be emitted today.
+      The default value is encoded through the column's codec while the contract is being
+      emitted, inside the CLI's own process, and stock Node ships no `Temporal`. So
+
+      ```prisma
+      occurredAt Timestamptz @default("2024-01-01T00:00:00Z")
+      ```
+
+      fails `prisma contract emit` with `CONTRACT.SOURCE_LOAD_FAILED` and "this runtime has no
+      global Temporal implementation".
+
+      Use the string spelling for a column that needs a literal default:
+
+      ```prisma
+      occurredAt TimestamptzString @default("2024-01-01T00:00:00Z")
+      ```
+
+      Function defaults are unaffected — `@default(now())` lowers to a PostgreSQL `now()`
+      storage default, never passes through a codec, and works on either representation.
+    detection:
+      glob: "**/*.prisma"
+      regex:
+        - "(Date|Timestamp|Timestamptz|Time)(\\([0-9]+\\))?\\s+@default\\(\""
+      anyMatch: true
+  - id: orm-init-no-longer-installs-agent-skills
+    summary: |
+      `prisma orm init` no longer installs agent skills: the GitHub fetch (`npx skills add`)
+      is removed and nothing inside `orm init` replaces it. Agent-skills setup belongs to the
+      family-level `prisma init` command. The `--skip-skills` flag is removed with the
+      behavior it opted out of. Existing projects keep whatever skills they already have;
+      only scripts that invoke `orm init` and expect it to deliver skills (or pass
+      `--skip-skills`) need to change.
+    detection:
+      glob: "**/*.{sh,yml,yaml,json,md}"
+      regex:
+        - '\borm\s+init\b'
+      anyMatch: true
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.6. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. The restamp is independent of the other changes in this
+      release.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.5"'
+---
+
+# 8.0.0-rc.5 → 8.0.0-rc.6 — User upgrade instructions
+
+# PostgreSQL temporal representations
+
+Both entries are schema-and-code renames; there is no codemod, because the choice between the
+Temporal and the string representation is per column and only you know which values a column
+holds. Work through the schema first, re-emit, then let the generated `contract.d.ts` types drive
+the application-code changes — the compiler will point at every site whose value type moved.
+
+Two behaviours are worth knowing before you choose. A Temporal codec rejects what `Temporal` cannot
+denote — `infinity`, years beyond roughly ±271821, and output rendered under a non-ISO `DateStyle` —
+naming the `*String` type that reads the same column losslessly. And a nested read returns the same
+text a flat read does, because temporal expressions are cast to `text` before PostgreSQL builds the
+JSON, which means both reflect the session `TimeZone`.
+
+## `orm-init-no-longer-installs-agent-skills`
+
+Nothing to change in an existing project: skills already on disk stay as they are. Walk every `orm init` invocation the detection finds (a mention in prose that is not a command needs no action):
+
+- An invocation passing `--skip-skills`: drop the flag — it no longer exists and the invocation fails with an unknown-flag error. The behavior it opted out of is gone, so the flagless invocation is the equivalent.
+- A plain invocation with no flag: the scaffold itself is unchanged, but it no longer installs agent skills. If the script (or the person following it) relied on that, run `prisma init` in the project afterwards; that command owns skills setup now. If skills were incidental, no change is needed.
+
+## `contract-artifacts-restamp`
+
+For every `contract.json` matched by `detection`, run the project's emit command (`prisma contract emit`, or the project's `contract:emit` script) once after upgrading. The only expected diff is the embedded `version` moving to `8.0.0-rc.6`.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.6-to-8.0.0-rc.7/instructions.md

@@ -0,0 +1,33 @@
+---
+from: "8.0.0-rc.6"
+to: "8.0.0-rc.7"
+changes:
+  - id: rename-orm-pagination-methods
+    summary: |
+      Rename ORM collection pagination calls from `.take(n)` to `.limit(n)` and from `.skip(n)` to `.offset(n)`. This applies to SQL and Mongo ORM collections, including relation refinements and grouped SQL collections. Do not rename Mongo query-builder `.skip(n)` calls: that lower-level API continues to mirror the `$skip` pipeline stage.
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.7. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. The toolchain also re-released against
+      `@prisma/cli-engine@0.2.3` (a CLI-side change with no ORM-facing surface).
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.6"'
+---
+
+# 8.0.0-rc.6 → 8.0.0-rc.7 — User upgrade instructions
+
+## `rename-orm-pagination-methods`
+
+Find calls on Prisma 8 ORM collections and apply these translations:
+
+- `.take(n)` → `.limit(n)`
+- `.skip(n)` → `.offset(n)`
+
+Apply the same translation inside `include(...)` refinement callbacks, `combine(...)` branches, and after SQL ORM `groupBy(...)`. Leave Mongo query-builder chains that start from `db.query.from(...)` unchanged: their `.limit(...)` and `.skip(...)` methods name Mongo aggregation pipeline stages rather than the ORM collection API.
+
+## `contract-artifacts-restamp`
+
+For every `contract.json` matched by `detection`, run the project's emit command (`prisma contract emit`, or the project's `contract:emit` script) once after upgrading. The only expected diff beyond the pagination rename is the embedded `version` moving to `8.0.0-rc.7`.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.7-to-8.0.0-rc.8/instructions.md

@@ -0,0 +1,36 @@
+---
+from: "8.0.0-rc.7"
+to: "8.0.0-rc.8"
+changes:
+  - id: engine-pin-moves-to-0-3-0
+    summary: |
+      The toolchain now peers `@prisma/cli-engine@0.3.0` (up from 0.2.3). Projects assembled
+      by the unified `prisma` CLI resolve the engine automatically. A project that pins
+      `@prisma/cli-engine` itself must move the pin to `0.3.0`. The engine now declares
+      `@prisma/management-api-sdk` as a peer dependency (`^1.55.0`) instead of a regular
+      dependency; the `prisma` CLI shell supplies it at runtime, so only a project that runs
+      the engine outside the CLI shell needs to install the SDK itself.
+    detection:
+      glob: "**/package.json"
+      contains:
+        - '"@prisma/cli-engine": "0.2.3"'
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.8. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.7"'
+---
+
+# 8.0.0-rc.7 → 8.0.0-rc.8 — User upgrade instructions
+
+## `engine-pin-moves-to-0-3-0`
+
+For every `package.json` matched by `detection`, change the `@prisma/cli-engine` version from `0.2.3` to `0.3.0` and reinstall. If the project runs the engine outside the unified `prisma` CLI shell (rare), also install `@prisma/management-api-sdk` at a version satisfying `^1.55.0` — the engine now declares it as a peer dependency and no longer bundles it.
+
+## `contract-artifacts-restamp`
+
+For every `contract.json` matched by `detection`, run the project's emit command (`prisma contract emit`, or the project's `contract:emit` script) once after upgrading. The only expected diff is the embedded `version` moving to `8.0.0-rc.8`.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.8-to-8.0.0-rc.9/instructions.md

@@ -0,0 +1,63 @@
+---
+from: "8.0.0-rc.8"
+to: "8.0.0-rc.9"
+changes:
+  - id: reemit-supabase-extension-version
+    summary: |
+      Re-emit contracts using the Supabase extension so their extension version metadata matches the installed rc.9 package.
+  - id: mongo-index-projections-use-native-lists
+    summary: |
+      MongoDB wildcard index `include` and `exclude` projections in Prisma schema files must use native PSL lists instead of encoded list strings.
+    detection:
+      glob: "**/*.prisma"
+      matches:
+        - '\b(?:include|exclude)\s*:\s*"\[[^"\r\n]*\]"'
+  - id: mongo-text-index-weights-use-native-records
+    summary: |
+      MongoDB text-index `weights` in Prisma schema files must use native PSL records instead of encoded JSON strings.
+    detection:
+      glob: "**/*.prisma"
+      matches:
+        - '\bweights\s*:\s*"\{\s*(?:\\.|[^"\\])*\}"'
+  - id: explicit-enum-sort-values
+    summary: |
+      PostgreSQL text-backed enums now sort by stored value rather than declaration order; encode semantic ranks explicitly when ordering matters.
+  - id: namespace-qualify-sql-orm-filter-types
+    summary: |
+      SQL ORM reusable filter types now require the domain namespace before the model name: `<Contract, Namespace, Model>`.
+  - id: mongo-unlowered-attributes-are-rejected
+    summary: |
+      MongoDB Prisma schema files must not carry `@default(...)`, `@updatedAt`, or `@db.*` attributes; the Mongo interpreter never lowered them and now rejects them.
+    detection:
+      glob: "**/*.prisma"
+      matches:
+        - '@(?:default\(|updatedAt\b|db\.)'
+---
+
+# 8.0.0-rc.8 → 8.0.0-rc.9 — User upgrade instructions
+
+## `reemit-supabase-extension-version`
+
+After updating the Supabase extension to rc.9, run `prisma contract emit` for each contract that uses it and commit the regenerated `contract.json` and `contract.d.ts`. Verify that the Supabase extension's version metadata is `8.0.0-rc.9` in both artifacts; do not edit generated contracts by hand.
+
+## `mongo-index-projections-use-native-lists`
+
+For every Prisma schema matched by `detection`, replace encoded projection strings with native PSL lists. For example, change `include: "[a, b]"` to `include: ["a", "b"]` and `exclude: "[a]"` to `exclude: ["a"]`. Decode each string's fields in their existing order and preserve whether the argument is `include` or `exclude`.
+
+## `mongo-text-index-weights-use-native-records`
+
+For every Prisma schema matched by `detection`, replace the encoded JSON string passed to `weights` with a native PSL record. For example, change `weights: "{\"title\": 10}"` to `weights: { title: 10 }`, preserving every field name and numeric weight.
+
+## `explicit-enum-sort-values`
+
+Review queries that order text-backed enum columns and rely on declaration order. To retain semantic ranking, use an explicit ranking expression or numeric enum values. For example, a priority enum can use `{ codecId: 'pg/int4@1', nativeType: 'int4' }` with `member('Low', 0)`, `member('High', 1)`, and `member('Urgent', 2)`. In PSL, use `@@type("pg/int4@1")` with `Low = 0`, `High = 1`, and `Urgent = 2`. Update literal writes and type annotations to the numeric values, then re-emit the contract. For an existing database, create a data-preserving migration mapping the old strings to their numeric ranks and update defaults and constraints; do not rewrite applied migration history. PostgreSQL native enum columns retain the database's native ordering.
+
+## `namespace-qualify-sql-orm-filter-types`
+
+Find TypeScript references to `ShorthandWhereFilter`, `RelationPredicate`, `RelationPredicateInput`, and `RelationFilterAccessor`. Add the model's domain namespace as the second generic argument and place the model name third. Rewrite `ShorthandWhereFilter<Contract, Model>` as `ShorthandWhereFilter<Contract, Namespace, Model>` and `ShorthandWhereFilter<Contract, Model, Namespace>` as `ShorthandWhereFilter<Contract, Namespace, Model>`. Rewrite the relation types from `<Contract, Model>` to `<Contract, Namespace, Model>`. Use the namespace facet through which the model is queried, such as `'public'` for `db.public.User`.
+
+## `mongo-unlowered-attributes-are-rejected`
+
+First, before editing any schema, determine whether the project targets MongoDB: its `prisma.config.ts` imports `@prisma/orm-mongo`, or its `package.json` depends on that package. If neither holds, skip this change entirely and leave every schema untouched. The `detection` pattern also matches SQL schemas, where `@default(...)` and `@db.<Type>` are supported and deleting them breaks the contract.
+
+For every matched MongoDB schema, delete each `@default(...)`, `@updatedAt`, and `@db.<Type>` attribute from the field that carries it, leaving the field's type and its other attributes in place. For example, change `status ProductStatus @default(Active)` to `status ProductStatus` and `updatedAt DateTime @updatedAt` to `updatedAt DateTime`. The Mongo interpreter never lowered these attributes into the contract, so the emitted `contract.json` does not change; defaults and timestamps stay the responsibility of application code, as they already were. `prisma contract emit` now fails with `PSL_UNSUPPORTED_FIELD_ATTRIBUTE` while any of them remain.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.9-to-8.0.0-rc.10/instructions.md

@@ -0,0 +1,84 @@
+---
+from: "8.0.0-rc.9"
+to: "8.0.0-rc.10"
+changes:
+  - id: schema-header-use-prisma-8
+    summary: |
+      The schema header that marks a Prisma 8 schema is now `// use prisma-8`. The language server
+      still serves the old header and its Format action rewrites it; new schemas and the
+      inferred-schema printer write the new form. Replace `// use prisma-next`
+      at the top of every `.prisma` file.
+    detection:
+      glob: "**/*.prisma"
+      contains:
+        - "// use prisma-next"
+  - id: env-vars-drop-next-infix
+    summary: |
+      The CLI environment variables lost their `NEXT_` infix: `PRISMA_NEXT_DISABLE_TELEMETRY`,
+      `PRISMA_NEXT_TELEMETRY_ENDPOINT`, `PRISMA_NEXT_DEBUG`, and the rest are now
+      `PRISMA_DISABLE_TELEMETRY`, `PRISMA_TELEMETRY_ENDPOINT`, `PRISMA_DEBUG`, and so on. The old
+      `PRISMA_NEXT_DISABLE_TELEMETRY` opt-out is still honoured; the others are not. Rename them
+      in shell profiles, `.env` files, and CI configuration. The per-user telemetry config also moved
+      from `~/.config/prisma-next/` to `~/.config/prisma-8/`, so the consent prompt runs once more.
+    detection:
+      glob: "**/*"
+      contains:
+        - "PRISMA_NEXT_"
+  - id: primer-file-prisma-8-md
+    summary: |
+      The quick-reference primer `init` writes at the project root is now `prisma-8.md`. Rename the
+      existing `prisma-next.md` and update any README or agent instruction that points at it.
+    detection:
+      glob: "**/prisma-next.md"
+      contains:
+        - "#"
+  - id: to-one-relations-record-nullable
+    summary: |
+      Every `1:1` and `N:1` relation in `contract.json` now carries a `nullable` boolean. A
+      contract without it still loads, with the flag derived from the foreign-key columns (or
+      fields), but its `contract.d.ts` lacks the `Models` namespace. Re-run
+      `prisma contract emit` so the emitted `contract.json` / `contract.d.ts` match the installed
+      toolchain.
+    detection:
+      glob: "**/contract.json"
+      matches:
+        - '"cardinality":\s*"(?:N:1|1:1)",\s*"on":'
+  - id: reemit-supabase-extension-version
+    summary: |
+      Contracts that use the Supabase extension carry its package version in their extension
+      metadata. Re-emit them after upgrading so `contract.json` and `contract.d.ts` say
+      `8.0.0-rc.10` instead of `8.0.0-rc.9`.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"id": "supabase"'
+  - id: contract-dts-exports-models
+    summary: |
+      `contract.d.ts` now exports a `Models` namespace and a `models` constant that name every
+      model with its fields and relations. The re-emit above produces them; use them with
+      `Scalars` and `Shape` to name row types without a client in scope.
+---
+
+## `to-one-relations-record-nullable`
+
+For every `contract.json` matched by `detection`, run the project's emit command (`prisma contract emit`, or the project's `contract:emit` script) once after upgrading. The emit reads the `?` on each to-one relation field in the schema and writes `"nullable": true` or `"nullable": false` next to that relation's `"cardinality"`. The emit also fails, rather than emitting, when a required relation field sits over a nullable foreign key or the reverse; fix the schema so the field's `?` matches the key's `?`, then emit again. Until the re-emit, the client and the migration tools still load the old `contract.json`: a to-one relation without the flag is treated as nullable when any of its foreign-key columns (Mongo: fields) is nullable, and as required otherwise. Migration contract snapshots written by earlier versions are never rewritten and load the same way.
+
+## `contract-dts-exports-models`
+
+After the emit, `import type { Models, models } from './prisma/contract'` (the project's contract path) gives `Models.<namespace>_<Model>` for every model, and `Scalars<M>` / `Shape<M, { '+': 'relation' }>` from `@prisma/orm-postgres/family-contract/types` (or the Mongo family package) derive the default row and a data structure with relations from it. Replace hand-written row types that duplicate a model's fields with these when convenient.
+
+## `schema-header-use-prisma-8`
+
+For every `.prisma` file matched by `detection`, replace the first-line header `// use prisma-next` with `// use prisma-8`. Nothing else in the file changes.
+
+## `env-vars-drop-next-infix`
+
+For every file matched by `detection`, replace the `PRISMA_NEXT_` prefix with `PRISMA_` on each environment variable name. Delete `~/.config/prisma-next/` (or `%APPDATA%\prisma-next\` on Windows); the CLI recreates its config under `prisma-8` and asks for telemetry consent once.
+
+## `primer-file-prisma-8-md`
+
+Rename `prisma-next.md` at the project root to `prisma-8.md`, and update any link to it in the project README or agent instructions.
+
+## `reemit-supabase-extension-version`
+
+For every `contract.json` matched by `detection`, run `prisma contract emit` once after upgrading the Supabase extension and commit the regenerated `contract.json` and `contract.d.ts`. The only expected change is the Supabase extension's `version` field moving from `8.0.0-rc.9` to `8.0.0-rc.10` in both files. Do not edit the generated files by hand.