stash eql migration: migration-first, ORM-agnostic EQL v3 install (fixes prisma-next superuser-on-Supabase)

[coderdan]

Problem

EQL install differs per integration, and prisma-next's approach breaks on Supabase:

• Drizzle (v3) delegates EQL install to the CLI (stash eql install), which owns four pre-built SQL variants + runtime Supabase selection + grants. Works everywhere.
• prisma-next owns install by inlining the full v2 bundle into a baked baseline migration (migrations/…/ops.json → installBundle op). That bundle has 9 CREATE OPERATOR CLASS/FAMILY statements → requires superuser → fails on Supabase (Supabase's postgres role is not a superuser). It also applies no grants and has no target awareness (the descriptor is static, so there's no apply-time "is this Supabase?" seam).

Root cause confirmed by reproducing the bundle diff: the CLI's cipherstash-encrypt.sql has 9 operator classes/families; cipherstash-encrypt-supabase.sql has 0 (that's the only difference, ~210 lines). The CLI picks the right one at install time via resolveBundledFilename.

Decisions (owner: @coderdan)

1. prisma-next is v3-only. v2 was never released for prisma-next, so drop it entirely. Both Drizzle and prisma-next migrations target EQL v3. (prisma-next's move to v3 is PR Feat/prisma next eql v3 #655, in-flight.)
2. Migration-first, ORM-agnostic install via a new CLI command:

   stash eql migration --drizzle | --prisma  [--supabase]  [--out <dir>] [--name <name>] [--dry-run]
   

   • Emits an EQL-install migration file in the target ORM's format (preferred over direct-to-DB execution, which stays as stash eql install for quick/dev).
   • Single source of install SQL: the CLI's bundled v3 SQL (loadBundledEqlSql({ eqlVersion: 3 })). --supabase appends the v3 grants (supabaseGrantsFor(3) → eql_v3 + eql_v3_internal GRANTs to anon/authenticated/service_role). (The v3 bundle itself is a single file used for all targets — its operator classes do not trip the superuser wall the way v2's 9 do.)
   • --drizzle → reuse the existing Drizzle custom-migration emission.
   • --prisma → new emitter writing a Prisma-Next migration.ts (the framework Migration shape) into the user's migrations dir.
3. prisma-next stops owning install. Its baked-in installBundle baseline (the inlined bundle in ops.json) is removed; users generate the install migration with stash eql migration --prisma [--supabase], exactly as Drizzle users would. This is the change that makes prisma-next Supabase-safe.

Sequencing (3 PRs)

1. PR1 — stash eql migration --drizzle [--supabase] (v3), off main. Independent of prisma-next; Drizzle v3 is already on main. Adds the eql migration command (registry + dispatch + generation), reusing loadBundledEqlSql/supabaseGrantsFor. --prisma is registered but returns "not yet available (tracked here)" until PR3. Tests + stash/stash-drizzle/stash-cli updates + changeset. Merge this.
2. PR2 — rebase Feat/prisma next eql v3 #655 (feat/prisma-next-eql-v3) on the merged PR1.
3. PR3 — --prisma emitter + remove prisma-next's baked baseline, stacked on Feat/prisma next eql v3 #655. Emits the v3 install migration in the framework Migration shape; drops the installBundle op from the descriptor/ops.json; updates the prisma-next skill/example to run stash eql migration --prisma.

Notes

• Grants: Drizzle/prisma-next apps connect directly as postgres, so the anon/authenticated/service_role grants matter only when the same tables are also reached via PostgREST/RLS. --supabase includes them for parity with stash eql install --supabase; harmless (idempotent) otherwise.
• This unifies EQL-install SQL under one CLI source of truth (no vendored fork per ORM), which also removes prisma-next's "indivisible bundle" maintenance burden.

Part of the stack 1.0 + EQL v3 GA push.

[coderdan]

PR1 is up: #691 (stash eql migration --drizzle, off main). Once merged → rebase #655 → PR3 adds --prisma + removes prisma-next's baked baseline, stacked on #655.

[coderdan]

PR2 done + PR3 (--prisma emitter) design

PR2 — rebase complete. #655 (feat/prisma-next-eql-v3) rebased onto #691. Old tip 06df3474 → new b6ff7c43, force-pushed with lease, zero content conflicts (691 is CLI-only; 655 is prisma-next). Verified on the rebased tip: builds clean, prisma-next 599 unit pass, cli 557 pass. PR3 branch feat/eql-migration-prisma is off it.

Finding that resizes PR3: #655 ships two baked baseline migrations, both wired in control.ts — the v2 installBundle and a new v3 installBundleV3 (migrations/20260601T0100_install_eql_v3_bundle, sourcing @cipherstash/eql/sql readInstallSql()). So "remove the baked baseline" = remove both and rework the contract-space head-ref/invariants that carry them. That's delicate surgery on the model #655 just built (CJ's domain).

Emitter design fork (need a call): the emitted prisma-next migration must carry the v3 install SQL, but prisma-next's public ./migration export only exposes cipherstashAddSearchConfig — not the install SQL (it's baked from a devDependency, @cipherstash/eql/sql, on purpose). Two ways:

• A (CLI is the source, per this issue's principle): the CLI bakes its own bundled v3 SQL (loadBundledEqlSql({eqlVersion:3}) — already in feat(cli): add stash eql migration --drizzle (v3, migration-first EQL install) #691) into the emitted migration. Keeps one source of truth; needs the emitted artefact to be a framework migration.ts + emitted ops.json (via MigrationCLI.run) or a directly-written ops.json. Caveat: reconcile the CLI's cipherstash-encrypt-v3.sql vs prisma-next's @cipherstash/eql/sql — they must be the same eql release.
• B (prisma-next exposes the SQL): add a public export so the emitted migration imports it. Simpler emit, but puts the SQL back in prisma-next's surface — against this issue's "CLI is the single source" goal.

Recommend A. Open question is the emit format (write migration.ts and have the user run the framework emit, vs. the CLI producing ops.json directly) and the SQL-version reconciliation — both touch CJ's contract tooling, so worth a quick sync with him before the removal half.