docs(docs): added prisma next overview

apps/docs/content/docs/orm/meta.json

@@ -4,6 +4,9 @@
   "defaultOpen": true,
   "icon": "Database",
   "pages": [
+    "---TEMP Prisma Next---",
+    "...temp-next",
+
     "---Introduction---",
     "index",
 

apps/docs/content/docs/orm/temp-next/how-prisma-next-works.mdx

@@ -0,0 +1,109 @@
+---
+title: How Prisma Next works
+description: Walk through the full lifecycle from Schema to Verified Runtime Queries.
+url: /orm/temp-next/how-prisma-next-works
+metaTitle: "How Prisma Next works schema contract signing and runtime verification"
+metaDescription: "Follow the lifecycle from Schema to Data Contract, Database Signing, immutable Plan creation, and verified runtime query execution."
+---
+
+Prisma Next works as a Verification-First Workflow:
+
+**Schema -> Data Contract -> Database Signing -> Verified Runtime Queries**
+
+## Lifecycle diagram
+
+```mermaid
+flowchart LR
+  A(Schema<br/>authored model definition)
+  B(Data Contract<br/>emit contract.json + contract.d.ts + hashes)
+  C(Database Signing<br/>verify DB state and write Contract Marker)
+  D(Runtime Plan<br/>build immutable Plan from contract-aware query surface)
+  E(Runtime Verification<br/>compare contract and Plan hashes to marker)
+  F(Verified Runtime Queries<br/>execute only after verification succeeds)
+
+  A --> B --> C --> D --> E --> F
+```
+
+## Step 1: Schema
+
+You define the data model in Schema authoring sources.
+
+This is the intent stage: what data exists, how it relates, and what capabilities are required.
+
+```prisma title="schema.prisma"
+model User {
+  id    Int    @id @default(autoincrement())
+  email String @unique
+}
+```
+
+## Step 2: Data Contract
+
+Schema intent is emitted into Contract Artifacts:
+
+- `contract.json` (machine-readable contract data)
+- `contract.d.ts` (typed contract surface)
+
+The Data Contract carries hash identities such as `storageHash` and `profileHash`, which are used for compatibility checks.
+
+```ts title="load-contract.ts"
+import type { Contract } from './contract.d';
+import contractJson from './contract.json' with { type: 'json' };
+import { validateContract } from '@prisma-next/sql-contract/validate';
+
+const contract = validateContract<Contract>(contractJson);
+const { storageHash, profileHash } = contract;
+```
+
+## Step 3: Database Signing
+
+The database is verified against the Data Contract and then signed by writing the Contract Marker.
+
+The Contract Marker stores the signed contract identity (for example `storageHash` and `profileHash`) so later stages can prove compatibility quickly and deterministically.
+
+```sql title="contract-marker.sql"
+-- Conceptual marker record after successful signing
+storage_hash = 'sha256:2e7d...'
+profile_hash = 'sha256:9af1...'
+```
+
+## Step 4: Verified Runtime Queries
+
+Application queries are built as immutable Plans from the contract-aware query surface.
+
+Before execution, runtime verifies that plan and contract identity match the Contract Marker.
+
+- If hashes match, query execution proceeds.
+- If hashes do not match, runtime blocks execution and reports a contract mismatch.
+
+This is what makes runtime queries verified, not assumed.
+
+```ts title="build-and-execute-plan.ts"
+import { schema } from '@prisma-next/sql-relational-core/schema';
+import { sql } from '@prisma-next/sql-lane/sql';
+
+const tables = schema(contract).tables;
+
+const plan = sql({ contract, adapter })
+  .from(tables.user)
+  .select({
+    id: tables.user.columns.id,
+    email: tables.user.columns.email,
+  })
+  .build();
+
+for await (const row of runtime.execute(plan)) {
+  // executes only after Contract Marker verification passes
+  console.log(row.id, row.email);
+}
+```
+
+## Verification-first feedback loop
+
+Prisma Next keeps verification in the loop continuously:
+
+1. Verify before signing database state.
+2. Verify again before runtime query execution.
+3. Fail early on mismatch instead of allowing drift to propagate.
+
+As Schema evolves, the lifecycle repeats with a new Data Contract and a new signature state.

apps/docs/content/docs/orm/temp-next/what-is-prisma-next.mdx

@@ -0,0 +1,71 @@
+---
+title: What is Prisma Next?
+description: Define Prisma Next clearly and lock core terms for the rest of the docs.
+url: /orm/temp-next/what-is-prisma-next
+metaTitle: "What is Prisma Next contract-driven data access with verification"
+metaDescription: "Learn what Prisma Next is and how Data Contracts, Contract Artifacts, and Verification-First Workflow enforce verified execution."
+---
+
+Prisma Next is a **contract-driven data access layer with verification before execution**. It is designed for deterministic behavior, explicit safety checks, and machine-readable artifacts.
+
+Prisma Next is **not Prisma ORM**.
+
+Prisma ORM centers on generating and using an executable client. Prisma Next centers on emitting and using a **Data Contract** that every stage verifies before it acts.
+
+In plain language: Prisma Next turns your Schema into a signed agreement between your application and your database. Queries run only when that agreement is verified.
+
+## Contract-driven architecture in plain language
+
+In a contract-driven architecture:
+
+- You define your data model as a Schema.
+- That Schema is emitted as Contract Artifacts (`contract.json` + `contract.d.ts`).
+- The database is signed to the contract by storing contract hashes in a Contract Marker.
+- Runtime queries verify the contract against that marker before executing.
+
+The Data Contract is the shared source of truth for tools, runtimes, migrations, and automated agents.
+
+## Example: contract artifact (conceptual)
+
+```json title="contract.json"
+{
+  "schemaVersion": "1",
+  "targetFamily": "sql",
+  "storageHash": "sha256:2e7d...",
+  "profileHash": "sha256:9af1...",
+  "models": {
+    "User": {
+      "storage": { "table": "user" },
+      "fields": {
+        "id": { "column": "id" },
+        "email": { "column": "email" }
+      }
+    }
+  }
+}
+```
+
+This is the core idea: application and runtime reason over explicit contract data, not opaque generated runtime behavior.
+
+## What Prisma Next gives you
+
+- A machine-readable Data Contract instead of opaque runtime generation.
+- Deterministic Contract Artifacts that are easy to inspect and reason about.
+- Verification gates before state changes and before query execution.
+- A composable query surface that produces explicit immutable Plans.
+
+## Key terms you will see everywhere
+
+- **Schema**: Human-authored data model.
+- **Data Contract**: Canonical data representation emitted from the Schema.
+- **Contract Artifacts**: `contract.json` and `contract.d.ts`.
+- **Storage Hash**: Identity of storage structure.
+- **Profile Hash**: Identity of capability profile.
+- **Database Signing**: Writing verified contract identity into the database marker.
+- **Contract Marker**: Signed contract identity stored in the database.
+- **Plan**: Immutable query representation prepared for runtime execution.
+- **Verified Runtime Query**: Query execution only after marker verification succeeds.
+
+## One-paragraph definition
+
+Prisma Next is a contract-driven data access layer, not Prisma ORM. It takes an authored Schema, emits deterministic Contract Artifacts, signs the database to that contract, and enforces verification again before runtime queries execute. This Verification-First Workflow gives teams and agents a clear, machine-readable, auditable path from data model intent to safe query execution.

apps/docs/content/docs/orm/temp-next/why-prisma-next.mdx

@@ -0,0 +1,71 @@
+---
+title: Why Prisma Next?
+description: Explain why Prisma Next uses a contract-driven, verification-first approach.
+url: /orm/temp-next/why-prisma-next
+metaTitle: "Why Prisma Next contract-driven verification-first architecture"
+metaDescription: "Understand how Prisma Next reduces compatibility ambiguity with Data Contracts, Database Signing, and Verified Runtime Queries."
+---
+
+Prisma Next exists to remove ambiguity in how applications and databases stay compatible over time.
+
+Traditional generated-client workflows hide important behavior in generated runtime code. Prisma Next takes the opposite approach: it makes compatibility explicit, verifiable, and machine-readable through a Data Contract.
+
+## Why contract-driven
+
+A contract-driven model solves three core problems:
+
+1. **Ambiguous compatibility**
+Without a shared Data Contract, it is harder to prove that app code and database state agree.
+
+2. **Opaque behavior**
+Generated code can hide assumptions and make change impact harder to inspect.
+
+3. **Weak automation surface**
+Agents and tooling work better with deterministic Contract Artifacts than with implicit runtime behavior.
+
+With Prisma Next, the Data Contract is the explicit system boundary. Every participant reads the same artifact and validates against the same hashes.
+
+## Why verification-first
+
+Prisma Next applies verification before risky actions:
+
+- Before Database Signing, Schema state is checked against the Data Contract.
+- Before runtime execution, Storage Hash and Profile Hash are checked against the Contract Marker.
+- If verification fails, execution halts with explicit mismatch signals instead of silently continuing.
+
+This is the core idea behind a Verification-First Workflow: safety checks happen before mutations and before query execution, not after incidents.
+
+## Example: verification gate before execution
+
+```ts title="verification-gate.ts"
+type ContractHashes = { storageHash: string; profileHash: string };
+type Marker = { storageHash: string; profileHash: string } | null;
+
+function assertVerified(contract: ContractHashes, marker: Marker): void {
+  if (!marker) throw new Error('contract/marker-missing');
+  if (contract.storageHash !== marker.storageHash) throw new Error('contract/hash-mismatch');
+  if (contract.profileHash !== marker.profileHash) throw new Error('contract/hash-mismatch');
+}
+
+// Runtime flow:
+// 1. load contract hashes
+// 2. read marker from database
+// 3. assertVerified(...)
+// 4. execute Plan only if verification passes
+```
+
+## Why this matters in practice
+
+- Teams can reason about change with explicit lifecycle checkpoints.
+- Platform and data workflows become more auditable and deterministic.
+- Agent-assisted development becomes safer because the artifacts are machine-readable.
+- Runtime behavior is predictable because queries are executed only in a verified state.
+
+## Prisma Next vs Prisma ORM (high-level positioning)
+
+Prisma Next is not a rebrand of Prisma ORM. It is a different architecture:
+
+- Prisma ORM emphasizes generated client methods.
+- Prisma Next emphasizes Contract Artifacts, Database Signing, and Verified Runtime Queries.
+
+The goal is not to hide complexity. The goal is to make correctness and compatibility explicit.

apps/docs/package.json

@@ -37,6 +37,7 @@
     "fumadocs-ui": "catalog:",
     "jotai": "catalog:",
     "lucide-react": "catalog:",
+    "mermaid": "^11.12.3",
     "motion": "catalog:",
     "next": "catalog:",
     "next-themes": "catalog:",

apps/docs/source.config.ts

@@ -1,27 +1,28 @@
-import remarkDirective from 'remark-directive';
+import remarkDirective from "remark-directive";
 import {
   remarkDirectiveAdmonition,
   remarkMdxFiles,
-} from 'fumadocs-core/mdx-plugins';
-import { remarkImage } from 'fumadocs-core/mdx-plugins';
+  remarkMdxMermaid,
+} from "fumadocs-core/mdx-plugins";
+import { remarkImage } from "fumadocs-core/mdx-plugins";
 import {
   defineConfig,
   defineDocs,
   frontmatterSchema,
   metaSchema,
-} from 'fumadocs-mdx/config';
-import lastModified from 'fumadocs-mdx/plugins/last-modified';
-import { z } from 'zod';
-import convert from 'npm-to-yarn';
+} from "fumadocs-mdx/config";
+import lastModified from "fumadocs-mdx/plugins/last-modified";
+import { z } from "zod";
+import convert from "npm-to-yarn";
 
 // You can customise Zod schemas for frontmatter and `meta.json` here
 // see https://fumadocs.dev/docs/mdx/collections
 export const docs = defineDocs({
-  dir: 'content/docs',
+  dir: "content/docs",
   docs: {
     schema: frontmatterSchema.extend({
       image: z.string().optional(),
-      badge: z.enum(['early-access', 'deprecated', 'preview']).optional(),
+      badge: z.enum(["early-access", "deprecated", "preview"]).optional(),
       url: z.string(),
       metaTitle: z.string(),
       metaDescription: z.string(),
@@ -37,11 +38,11 @@ export const docs = defineDocs({
 
 // v6 docs collection
 export const docsV6 = defineDocs({
-  dir: 'content/docs.v6',
+  dir: "content/docs.v6",
   docs: {
     schema: frontmatterSchema.extend({
       image: z.string().optional(),
-      badge: z.enum(['early-access', 'deprecated', 'preview']).optional(),
+      badge: z.enum(["early-access", "deprecated", "preview"]).optional(),
       url: z.string().optional(),
       metaTitle: z.string().optional(),
       metaDescription: z.string().optional(),
@@ -63,25 +64,26 @@ export default defineConfig({
       remarkDirectiveAdmonition,
       [remarkImage, { useImport: false }],
       remarkMdxFiles,
+      remarkMdxMermaid,
     ],
     remarkCodeTabOptions: {
       parseMdx: true,
     },
     remarkNpmOptions: {
       persist: {
-        id: 'package-manager',
+        id: "package-manager",
       },
       packageManagers: [
-        { command: (cmd: string) => convert(cmd, 'npm'), name: 'npm' },
-        { command: (cmd: string) => convert(cmd, 'pnpm'), name: 'pnpm' },
-        { command: (cmd: string) => convert(cmd, 'yarn'), name: 'yarn' },
+        { command: (cmd: string) => convert(cmd, "npm"), name: "npm" },
+        { command: (cmd: string) => convert(cmd, "pnpm"), name: "pnpm" },
+        { command: (cmd: string) => convert(cmd, "yarn"), name: "yarn" },
         {
           command: (cmd: string) => {
-            const converted = convert(cmd, 'bun');
+            const converted = convert(cmd, "bun");
             if (!converted) return undefined;
-            return converted.replace(/^bun x /, 'bunx --bun ');
+            return converted.replace(/^bun x /, "bunx --bun ");
           },
-          name: 'bun',
+          name: "bun",
         },
       ],
     },