`@cipherstash/stack-prisma@1.1.0` cannot be installed into existing Prisma Next apps — and `stash init` breaks their toolchain trying

[coderdan]

Background

Prisma Next is Prisma's new TypeScript-native ORM. Mid-pre-release, Prisma renamed and renumbered its whole package family: apps built on the earlier fork depend on @prisma-next/* (last publish 0.16.0; many apps sit on 0.14.0), while the current fork publishes as @prisma/orm-* (0.17.0, since renumbered to 8.0.0-rc.* to align with Prisma 8). The two families are not interchangeable — different package names, different config validation, each shipping its own prisma-next CLI binary. @cipherstash/stack-prisma (renamed from @cipherstash/prisma-next at 1.1.0) is CipherStash's adapter for this ORM.

Problem

The 1.1.0 rename moved the adapter across the fork boundary, and nothing guards the gap:

1. @cipherstash/prisma-next@1.0.0-rc.4 (old name) targeted @prisma-next/*@0.14 — it worked in apps on that fork.
2. @cipherstash/stack-prisma@1.1.0 (new name) declares peerDependencies: { "@prisma/orm-target-postgres": "0.17.0" } and hard-depends on @prisma/orm-framework@0.17.0, @prisma/orm-toolchain@0.17.0, @prisma/orm-family-sql@0.17.0 (verified via npm view). No build exists for the @prisma-next/* family. An app on the old fork simply has no compatible adapter version under the release's pinning scheme.
3. Worse than "cannot install": npx stash@1.1.0 init --supabase in such an app auto-detects Prisma Next (via prisma-next.config.*, src/commands/db/detect.ts:146-177) and silently installs @cipherstash/stack-prisma@1.1.0 — dragging in @prisma/orm-toolchain@0.17.0, whose prisma-next binary then shadows the app's own at node_modules/.bin/prisma-next. The 0.17 toolchain rejects every config the app's @prisma-next/postgres@0.14 defineConfig produces (CONFIG.VALIDATION_FAILED: "Config.extensionPacks is no longer supported; rename it to Config.extensions") — so the app's own contract emit / db init / db update break on the untouched plaintext baseline, before any encryption work starts. Recovery: git checkout package-lock.json && npm ci.
4. Detection knows about both forks — the retired @prisma-next/cli scope is explicitly in its dependency checklist (detect.ts:175) — but the install step maps every Prisma Next detection to the single 0.17-only adapter (src/commands/init/steps/install-deps.ts:37) with no fork check and no warning.
5. Related paper cut: init's printed next steps still say "add cipherstash to extensionPacks in prisma-next.config.ts" (src/commands/init/providers/prisma.ts:27) — the exact key the 0.17 fork's validator rejects; on 0.17 it must read extensions.

Impact: any user with an existing Prisma Next app on the @prisma-next/* fork who runs stash init gets a broken project and no encryption. Nothing catches it — the install succeeds, and the failures surface later as confusing Prisma config errors with no mention of CipherStash. Found by the 2026-08-19 skilltester round (next-prisma surface, honest-fail verdict): the agent independently reproduced the peer/fork split and declined to fake an integration.

Affected versions: @cipherstash/stack-prisma@1.1.0, stash@1.1.0.

Proposal

1. Interim (cheap): fork-guard the install — before installing stack-prisma, check which family the app depends on (@prisma-next/* vs @prisma/orm-*); on the retired fork, refuse loudly with the migration story ("your app is on the retired @prisma-next/* packages; stack-prisma requires the @prisma/orm-*@0.17 toolchain — migrate the app first or pin @cipherstash/prisma-next@1.0.0-rc.4"). A loud refusal beats a shadowed binary.
2. Decide and document the support matrix: either ship a stack-prisma build for the @prisma-next/* family, or declare it unsupported and say so in the README, the stash-prisma skill (front-loaded version matrix — today the skill only mentions the retired scope in passing), and the init guard from step 1.
3. Fix the extensionPacks → extensions wording in init's next-steps output (item 5 above).
4. Track the peer against Prisma's renumbering: @prisma/orm-* latest is already 8.0.0-rc.4; an exact 0.17.0 peer pin will strand users again at Prisma 8 GA.

Evidence

• cipherstash/skilltester branch 20260819-02-claude: apps/next-prisma/.cipherstash/bug-stack-prisma-framework-incompatible.md (implementer repro, exact commands + output) and assessment.md (independent assessor reproduction: peer inspection, .bin/prisma-next symlink target, baseline contract:emit failure).
• npm view @cipherstash/stack-prisma@1.1.0 peerDependencies dependencies — verified 2026-08-19.
• stash@1.1.0 tarball source refs above (sourcemaps).

Relationship to other work

• Rename package names for 1.0 #842 (closed) did the 1.0 package renames this rename belongs to.
• fix(stack-prisma): db init fails PN-RUN-3020 on fresh databases — EQL install op is classed data under an additive-only policy #850, stash encrypt backfill cannot run in a Prisma Next project #851 (closed) are earlier stack-prisma/Prisma Next integration defects on the current fork — different failure class.
• The skilltester next-prisma baseline is being migrated to @prisma/orm-*@0.17.0 so future rounds evaluate the supported fork; this issue covers real users' existing apps.