docs: address CodeRabbit follow-ups on the merged tree

Link flag semantics to the CLI references from the tutorial and the migrations
guide, use the project-scoped Postgres flow in the Prisma 8 agent prompt, drop
the leftover .env write from the NestJS guide, and label the verbatim
prisma-cli migrate hints.

Author: ankur-arch

apps/docs/content/docs/(index)/full-stack-tutorial.mdx

@@ -170,7 +170,7 @@ my-app
 
 :::warning[The module name must be unique in your workspace]
 
-`deploy` looks the module name up in your workspace and reuses the project this module deployed before rather than creating another. If a `my-app` project exists whose hosted state the CLI cannot verify (one deployed from a different checkout, for example), the deploy stops with `HostedStateBootstrapError` and names a project id you did not choose. Deploy under a different name with `--name`, or rename the module in `module.ts`:
+`deploy` looks the module name up in your workspace and reuses the project this module deployed before rather than creating another. If a `my-app` project exists whose hosted state the CLI cannot verify (one deployed from a different checkout, for example), the deploy stops with `HostedStateBootstrapError` and names a project id you did not choose. Deploy under a different name with [`--name`](/cli/deploy#flags), or rename the module in `module.ts`:
 
 ```npm
 npx prisma@latest deploy module.ts --name my-app-tutorial
@@ -210,7 +210,7 @@ npx prisma@latest contract emit
 npx prisma@latest migration plan --name add-user-role --from <timestamp>_init
 ```
 
-`--from` names the migration you are building on, and here it is required. Without it, `migration plan` starts from the [ref](/cli/migration-ref) named `db`. `db init` sets that ref when you initialize a database directly, but a Composer deploy never does, so a plan without `--from` in this project would start from an empty database and describe every table again. Teams that want plans to chain on their own point the ref at the applied migration once (`migration ref set db <timestamp>_init`) and advance it after each deploy.
+`--from` names the migration you are building on, and here it is required: a Composer deploy never sets the `db` ref that `migration plan` chains from by default, so a plan without it would describe every table again. The [`migration plan`](/cli/migration-plan) and [`migration ref`](/cli/migration-ref) references cover the default, the ref, and how to keep plans chaining on their own.
 
 The plan is your change and nothing else. Review it like any other diff, with [`migration show`](/cli/migration-show) or by reading the generated package:
 

apps/docs/content/docs/(index)/prisma-orm/index.mdx

@@ -43,7 +43,7 @@ Create a new [framework] application with Prisma 8, seed it, and run it locally.
 If I have not told you which framework, stop and ask before scaffolding. Valid --template values: next, hono, nuxt, astro, nest, svelte, tanstack-start, elysia.
 
 1. Scaffold the app: `npx create-prisma@latest create my-app --template [framework] --provider postgres --yes`. Then run `npx prisma@latest init` in the project directory so the Prisma agent skills are installed and stay current, and use them.
-2. Get a database connection string: use the one I give you, or create a Prisma Postgres database with `npx create-db@latest` and show me the claim URL it prints. Export it as `DATABASE_URL` in the shell; the generated scripts read the environment variable.
+2. Get a database connection string: use the one I give you, or create a Prisma Postgres database in the project the app will deploy to: check `npx prisma@latest auth whoami` (if I am not signed in, stop and ask me to run `npx prisma@latest auth login`), then `npx prisma@latest project create my-app` and `npx prisma@latest postgres create mydb`, which prints the connection string once. Export it as `DATABASE_URL` in the shell; the generated scripts read the environment variable.
 3. From the project directory, apply the starter contract: `npm run db:init`. Sample users are seeded automatically on the app's first query; there is no separate seed script.
 4. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx prisma@latest migration plan`, then `npx prisma@latest db migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
 5. Update the seed script under `src/prisma/` and the app routes to query the new schema, start `npm run dev` in the background (with `DATABASE_URL` exported), and verify with a request against the running app. For the `nest` template, if routes return 500s with `reading 'findAll'` in the logs, add explicit `@Inject()` tokens as shown in https://www.prisma.io/docs/guides/frameworks/nestjs.md.

apps/docs/content/docs/guides/frameworks/nestjs.mdx

@@ -45,11 +45,10 @@ cd my-nest-api
 
 Answer the prompts for contract authoring style and package manager. The scaffold generates the NestJS app with Prisma 8 wired in, installs dependencies, and emits the contract your queries are type-checked against.
 
-Next, set the database connection. Use your own PostgreSQL connection string, or create a Prisma Postgres database with `npx create-db@latest`; it prints a connection string and a claim URL you can open to keep the database. Export the variable, and write it to `.env` for the deploy step later. The generated scripts read the environment variable, not `.env`:
+Next, set the database connection for the local steps. Use your own PostgreSQL connection string, or create a Prisma Postgres database with `npx create-db@latest`; it prints a connection string and a claim URL you can open to keep the database. Export the variable in the shell you work in; the generated scripts read the environment variable, not `.env`:
 
 ```bash
 export DATABASE_URL="<your connection string>"
-echo "DATABASE_URL=\"$DATABASE_URL\"" > .env
 ```
 
 ## 2. Initialize the database

apps/docs/content/docs/orm/migrations/applying-a-migration.mdx

@@ -65,6 +65,8 @@ npx prisma@latest db migrate --db $DATABASE_URL
 1 pending — run `prisma-cli migrate --to 925198f3cc27`
 ```
 
+The output above is verbatim. `prisma-cli migrate` is the binary's internal name for the command; run it as `npx prisma@latest db migrate --to 925198f3cc27`.
+
 Read the markers on the right: `@db` is where the database is, `@contract` is where your emitted contract is, and `(db)` is the [ref](/orm/migrations/the-migration-graph#name-important-states-with-refs) of that name pointing at the same node.
 
 `db migrate --show` is the read-only dry run: it draws the path from the database's position to the target and stops. Nothing touches the database:
@@ -91,21 +93,15 @@ After applying, `migration log` shows the database's own record of what ran: an
 
 ## Choosing a target
 
-With no `--to`, `db migrate` advances toward your emitted contract. To aim somewhere specific, `--to` accepts the same reference grammar as everywhere else: a ref name, a contract hash or prefix, a migration directory name, or `<dir>^` for the state before a migration:
+With no `--to`, `db migrate` advances toward your emitted contract. To aim somewhere specific, name the target with `--to`, for example a ref:
 
 ```npm
-npx prisma@latest db migrate --to prod --db $DATABASE_URL          # a ref
-npx prisma@latest db migrate --to sha256:e6b5c28 --db $DATABASE_URL # a hash prefix
-npx prisma@latest db migrate --to 20260707T1005_init --db $DATABASE_URL
+npx prisma@latest db migrate --to prod --db $DATABASE_URL
 ```
 
 If the graph has branched and more than one tip is reachable, `db migrate` stops and asks for an explicit `--to`. That's the graph protecting you: two feature branches may both be valid futures, and picking one is a human decision.
 
-`--advance-ref` moves a named ref to the post-apply state in the same step. Advancing one called `db` is what keeps [`migration plan`](/orm/migrations/generating-a-migration#the-db-ref-skipping---from) incremental:
-
-```npm
-npx prisma@latest db migrate --advance-ref db
-```
+`--advance-ref` moves a named ref to the post-apply state in the same step, which is what keeps [`migration plan`](/orm/migrations/generating-a-migration#the-db-ref-skipping---from) incremental. The [`db migrate` reference](/cli/db-migrate#options) has the full `--to` grammar (refs, hashes, migration names, `<dir>^`) and the flag contract.
 
 ## When something goes wrong
 
@@ -117,6 +113,8 @@ The runner stops at the first failing operation and tells you which one, why, an
   Fix: Fix the issue and re-run `prisma-cli migrate --to <contract>` — previously applied migrations are preserved.
 ```
 
+That hint is the CLI's literal output; `prisma-cli migrate` is its internal name for `db migrate`, so re-run `npx prisma@latest db migrate --to <contract>`.
+
 Three properties make failure boring instead of terrifying:
 
 - **On PostgreSQL, a failed run leaves nothing behind.** The entire `db migrate` run executes inside one transaction, so when an operation fails, everything from that run rolls back and the database is exactly where it was before you started. Migrations applied in *earlier* runs are untouched. That's what "previously applied migrations are preserved" means.

apps/docs/content/docs/orm/migrations/rollbacks-and-recovery.mdx

@@ -85,6 +85,8 @@ A failed `db migrate` run stops at the failing operation and reports it precisel
   Fix: Fix the issue and re-run `prisma-cli migrate --to <contract>` — previously applied migrations are preserved.
 ```
 
+The hint is the CLI's literal output: `prisma-cli migrate` is its internal name for `db migrate`, so the command to re-run is `npx prisma@latest db migrate --to <contract>`.
+
 The playbook:
 
 1. **Read which check failed.** The error names the operation and the specific precheck or postcheck, in plain language. Here, rows with `NULL` still exist, so tightening the constraint would fail.