wmadden-electric · Sep 24, 2026
@@ -111,14 +111,14 @@ Command (via `expect`): `node <bin> orm init --skip-install` on a fresh pre-init
 |---|---|---|---|
 | F1 | ⚠ should fix | `CLI.INIT_EMIT_FAILED` reports the wrong cause. Init captured the trailing stderr line "Prisma agent skills are out of date … Run: prisma skills sync" as the cause, and dropped the real error `CLI.CONFIG_UNREADABLE … prisma7Schema is not a function`. A user following init's advice runs `prisma skills sync`, which fails with the same hidden error. | `S4.log`, `S7.log`, `S6.log`, `S6-skills-sync.log` |
 | F2 | ⚠ should fix | Known limitation, but the messages around it are not survivable. (a) `contract emit` says "prisma7Schema is not a function … Fix the error in the file", which points at the file init just wrote instead of at the too-old `@prisma/orm-postgres`; nothing tells the user which package version is needed. (b) Re-running init on the initialised project (S8) fails with `CLI.INIT_PRISMA7_CONFIG_UNREADABLE` whose nextAction says to rename `prisma.config.ts` to `prisma7.config.ts` by hand, which would overwrite the existing, working `prisma7.config.ts`. That advice should check whether `prisma7.config.ts` already exists. | `S6.log`, `S8.log` |
-| F3 | ⚠ should fix | `--confirm prisma7-app` is not honoured in an interactive session: the consent prompt is still shown, prefilled with the token, and Enter alone is rejected; the user must retype the token. With a non-interactive stdin under a TTY the command hangs on the prompt. Scripts that pass `--confirm` for a documented reason (the `--help` example does) get a prompt anyway. | `S7-attempt1-hung-on-prompt.log`, `S7-attempt2-script-enter.log`, `S7.log` |
+| F3 | ✅ resolved | `--confirm prisma7-app` is not honoured in an interactive session: the consent prompt is still shown, prefilled with the token, and Enter alone is rejected; the user must retype the token. With a non-interactive stdin under a TTY the command hangs on the prompt. Scripts that pass `--confirm` for a documented reason (the `--help` example does) get a prompt anyway. **Resolved 2026-09-24** in `@prisma/cli-engine` 0.6.1 (prisma/prisma-cli#283): a matching `--confirm` now grants the consent before any prompt is rendered, in every session. This repo pins 0.6.1. | `S7-attempt1-hung-on-prompt.log`, `S7-attempt2-script-enter.log`, `S7.log` |
 | F4 | ⚠ should fix | `README.md` is written on the Prisma 7 path with the generic scaffold text: "Generated by `prisma orm init` with the Minimal template", "First run: 1. `pnpm run db:init` — applies your contract to the database (creates tables, signs the marker)", lists scripts `db:init`, `db:update`, `migration:plan`, `db:seed` that do not exist in `package.json`, and says Prisma is scaffolded in `prisma/db.ts` and `src/lib/prisma.ts`, which do not exist. For a Prisma 7 project `db:init` is the opposite of what the next steps say (`db sign`, no schema changes). The script's expected file list did not include README.md either. | `S4-files.log` |
 | F5 | ⚠ should fix | `tsconfig.json` merge changed the user's `module: nodenext` / `moduleResolution: nodenext` to `module: preserve` / `moduleResolution: bundler` with only the message "Updated tsconfig.json with required compiler options." This project's `src/index.ts` still runs under tsx, but a Prisma 7 project that relies on NodeNext semantics (explicit `.js` import extensions, ESM/CJS detection by `package.json` type) has had its resolution mode silently switched. The JSON document lists `tsconfig.json` under `filesWritten` but does not say what changed. | `S4-files.log` |
 | F6 | ℹ note | `.gitignore` merge appended `node_modules/` and `dist/` although `node_modules` was already present; the result has both `node_modules` and `node_modules/`. Cosmetic. | `S4-files.log` |
 | F7 | ℹ note | `.env.example` and the "Also write a .env file" question are produced even though `.env` already exists with `DATABASE_URL`, and the next steps still start with "Set DATABASE_URL in your environment". On the Prisma 7 path the database URL is already configured by definition (the Prisma 7 config reads it), so this step is noise. | `S4.log`, `S7.log` |
 | F8 | ℹ note | Human-output wording: "⚠ Scaffold written. Finish the steps above to complete setup." is printed before the steps; the `db sign` step renders as a full sentence followed by ".: prisma db sign"; the install list shows `prisma@latest (dev)` rather than the resolved `8.0.0-rc.15`. | `S7.log` |
 | F9 | ℹ note | S1's `CLI.INIT_MISSING_FLAGS` in a Prisma 7 project does not mention that the project was detected as Prisma 7 or that `--from-prisma7-schema` exists; a CI user gets the generic "supply --target and --authoring" advice. Behaviour is as the script expects (no silent entry into the Prisma 7 path). | `S1.log` |
-| F10 | ⚠ should fix (pre-existing) | After a successful interactive run (`--skip-install`, exit 0 path) the process prints Done and the next steps but does not exit while the terminal stays open (idle 10 minutes, killed). Reproduced on the plain `--target postgres --authoring psl` path too, so not introduced by this branch. The failure path (S7, exit 5) exits normally. Verify in a real terminal. | `S9.log`, `S9-hangcheck-expect.log`, `S9-hangcheck-plain.log`, `S9-hangcheck-nontty.log` |
+| F10 | ✅ resolved | After a successful interactive run (`--skip-install`, exit 0 path) the process prints Done and the next steps but does not exit while the terminal stays open (idle 10 minutes, killed). Reproduced on the plain `--target postgres --authoring psl` path too, so not introduced by this branch. The failure path (S7, exit 5) exits normally. Verify in a real terminal. **Resolved 2026-09-24** in `@prisma/cli-engine` 0.6.1 (prisma/prisma-cli#283). Cause: the engine awaited the stdin iterator's `return()`, which Node's stdin cannot settle while it is awaiting a keystroke, so the bin's own `process.stdin.unref()` never ran. The engine no longer waits. Re-verified on this repo's main with 0.6.1: the guided `orm init --skip-install` run exits on its own under a pseudo-terminal after its four prompts. | `S9.log`, `S9-hangcheck-expect.log`, `S9-hangcheck-plain.log`, `S9-hangcheck-nontty.log` |
 | F11 | ℹ note (QA environment) | Init's `pnpm add` inherits whatever workspace pnpm finds by walking up from `cwd`. Inside this repository that meant the repo's `trustPolicy: no-downgrade` rejected `prisma@7.10.0` (`ERR_PNPM_TRUST_DOWNGRADE`). A user's own project would not hit this, but a Prisma 7 app that lives inside a monorepo with a strict trust policy would; `prisma-8.md` already mentions catalogs but not trust policy. | `S4-attempt1-install-failed.log` |
 
 Nothing under `packages/`, `docs/`, or `projects/` was modified except this report. `wip/qa/` is left in place; the `@prisma/dev` database process (started 07:14 local) is still running from `pnpm db:start`.