Merge pull request #1006 from cipherstash/feat/stack-prisma-bake-eql-3-0-6

feat(stack-prisma): bake EQL 3.0.6 into the migrations

Author: auxesis

.changeset/eql-3-0-5-migration.md

@@ -50,7 +50,7 @@ Any RLS policy, view, or constraint that calls an `eql_v3` function is dropped
 by the same CASCADE and needs recreating too. **The rename itself needs no
 action — the alias makes it non-breaking.**
 
-Two artefacts carry the new bundle:
+Two artefacts carry the new invariant:
 
 - A new upgrade edge, `20260814T0000_upgrade_eql_v3_3_0_5`, carrying the
   invariant `cipherstash:upgrade-eql-v3-bundle-3.0.5-v1`. Databases already
@@ -60,27 +60,31 @@ Two artefacts carry the new bundle:
   phase that copies a new migration package into your repo runs only from
   `migration plan`, so without it the 3.0.5 directory never reaches disk and
   `migrate` is a silent no-op that leaves the database on the older bundle.
-- The baseline install migration `20260601T0100_install_eql_v3_bundle`, whose
-  baked bundle moves to 3.0.5 and which gains a fourth no-SQL carrier op for
-  the new invariant. Fresh databases therefore land on 3.0.5 from the single
-  all-additive genesis edge, keeping `db init` (additive-only policy) working.
+- The baseline install migration `20260601T0100_install_eql_v3_bundle`, which
+  gains a no-SQL carrier op for the new invariant. The baseline itself bakes
+  eql-3.0.6, not 3.0.5: it was re-emitted again for 3.0.6 before any release
+  carried the 3.0.5 bytes (see the 3.0.6 entry). Fresh databases land on 3.0.6
+  from the single all-additive genesis edge, keeping `db init` (additive-only
+  policy) working.
 
 **Action required.** The baseline's bytes — and so its `migrationHash` — have
-changed. If your project already has a `migrations/cipherstash/` directory
-generated against `@cipherstash/stack-prisma@1.0.0` or `@1.1.0`, delete that
-directory and re-run `prisma-next migration plan` (or `migrate`); the 1.1.0
-Prisma Next 0.17 upgrade re-anchored the same artefacts, so a space vendored
-against either release is stale here. The seed phase regenerates
+changed. This is one change, shared with the 3.0.6 entry: npm never shipped
+the 3.0.5 baseline on its own. If your project already has a
+`migrations/cipherstash/` directory generated against
+`@cipherstash/stack-prisma@1.0.0`, `@1.1.0` or `@1.1.1`, delete that directory
+and re-run `prisma-next migration plan` (or `migrate`); the 1.1.0 Prisma Next
+0.17 upgrade re-anchored the same artefacts, so a space vendored against any
+of them is stale here. The seed phase regenerates
 it byte-identical to the shipped artefacts. Your database keeps its markers, so
-already-applied invariants are not re-run — the only new work is the 3.0.5
-upgrade edge.
+already-applied invariants are not re-run — the only new work is the 3.0.5 and
+3.0.6 upgrade edges.
 
 If you skip the delete, nothing warns you: a vendored baseline is stale but
 internally intact, so it passes every integrity check. On an existing database
 the upgrade still applies correctly; on a **fresh** one, `db init` refuses with
 `Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is
 not allowed by policy.` — an error that names neither the directory nor the
-remedy. See "Upgrading from 1.0.0" in the package README.
+remedy. See "Upgrading from 1.0.0 or 1.1.x" in the package README.
 
 **Why the baseline was re-emitted rather than left frozen.** These artefacts are
 content-addressed and normally append-only: an EQL bump ships as a new upgrade
@@ -93,4 +97,6 @@ collect every head-ref invariant from the genesis edge it walks. The
 append-only alternative would duplicate the full ~2.6 MB bundle into a new
 genesis edge on every EQL release, permanently; re-emitting was taken instead
 while 1.0.0 was two weeks old with negligible adoption, and is a decision to be
-re-argued on adoption numbers rather than repeated by default.
+re-argued on adoption numbers rather than repeated by default. This re-emit
+never reached npm: 1.1.0 and 1.1.1 shipped the eql-3.0.4 baseline, and the
+3.0.6 re-emit replaced these bytes before a release carried them.

.changeset/eql-3-0-6-migration.md

@@ -0,0 +1,56 @@
+---
+'@cipherstash/stack-prisma': minor
+---
+
+Move the bundled EQL v3 migrations to **eql-3.0.6**. This release changes only
+the version stamp: `eql_v3.version()` returns `'3.0.6'` and the `eql_v3` schema
+comment reads `'3.0.6'`. No function, operator, domain or index behaviour
+changes.
+
+Two artefacts carry the new bundle:
+
+- A new upgrade edge, `20261002T0000_upgrade_eql_v3_3_0_6`, carrying the
+  invariant `cipherstash:upgrade-eql-v3-bundle-3.0.6-v1`. Existing databases
+  re-install through it on the next `prisma-next migration plan` followed by
+  `prisma-next migrate`. **`migrate` alone is not enough**: only
+  `migration plan` copies the new directory into your repo.
+- The baseline install migration `20260601T0100_install_eql_v3_bundle`, which
+  now bakes 3.0.6 and gains a fifth op, a no-SQL carrier for the new
+  invariant, so fresh databases land on 3.0.6 from the single all-additive
+  genesis edge and `db init` keeps working.
+
+**Upgrading a 1.0.0 or 1.1.x database installs the EQL bundle twice.** Those
+releases shipped eql-3.0.4, so `migrate` walks the 3.0.5 upgrade edge and then
+the 3.0.6 one, re-installing the ~2.6 MB bundle once for each in the same run.
+That costs time, not correctness: the database ends on 3.0.6 with every
+invariant recorded. The 3.0.5 edge is kept rather than folded into this one
+because the frozen-history guard treats every committed edge as published, and
+a database built from `main` may already have walked it and recorded its
+invariant. As with every EQL upgrade, each re-install opens with
+`DROP SCHEMA IF EXISTS eql_v3 CASCADE`: re-run your grant script, and recreate
+functional indexes and anything else depending on `eql_v3` (see the 3.0.5
+entry).
+
+**Action required: the one in the 3.0.5 entry, once.** npm has only ever
+shipped the eql-3.0.4 baseline (1.0.0 on 30 July, 1.1.0 on 19 August, 1.1.1 on
+20 August), so this release changes the published baseline once, not twice. If
+your project has a `migrations/cipherstash/` directory generated against any
+earlier version, delete it and re-run `prisma-next migration plan`. Your
+database keeps its markers, so already-applied invariants are not re-run. If
+you skip the delete, a fresh `db init` refuses with
+`Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is
+not allowed by policy.` — see "Upgrading from 1.0.0 or 1.1.x" in the package
+README.
+
+**Why the baseline was re-emitted rather than given a second genesis edge.**
+In this repository the baseline was already re-emitted once, for 3.0.5, and
+that decision said the trade must be re-argued on adoption numbers at the next
+bump. This is that bump, and the trade came out the same way.
+`@cipherstash/stack-prisma` had 144 npm downloads in September 2026 (52 in the
+last week), fewer than the ~253 monthly downloads at which the 3.0.5 re-emit
+was judged a small, knowable blast radius. The 3.0.5 re-emit never reached
+npm, so what this one rewrites is unpublished. And since 3.0.6 changes only
+the version stamp, the append-only alternative, a second `from: null` genesis
+edge, would add another permanent ~2.6 MB copy of the bundle for no change in
+behaviour. Once this package has real adoption, the second genesis edge is the
+right shape.

.changeset/prisma-skill-eql-306.md

@@ -0,0 +1,7 @@
+---
+'stash': patch
+---
+
+`skills/stash-prisma`: the stale-`migrations/cipherstash/` table now describes
+eql-3.0.6. The baseline bakes 3.0.6, 1.1.x shipped 3.0.4 as 1.0.0 did, and an
+existing database upgrades through both the 3.0.5 and 3.0.6 edges.

.changeset/stack-prisma-upgrade-from-1-0-0.md

@@ -2,7 +2,7 @@
 '@cipherstash/stack-prisma': patch
 ---
 
-Document the 1.0.0 → 3.0.5 upgrade in the package README: why
+Document the upgrade from 1.0.0 or 1.1.x in the package README: why
 `migrations/cipherstash/` must be deleted and regenerated, what each Prisma Next
 command does if it is not, and the exact `db init` refusal
 (`Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is

docs/plans/2026-08-13-eql-monorepo-absorption.md

@@ -186,6 +186,8 @@ The entire diff is one rename — `eql_v3.ste_vec_contains` → `eql_v3.jsonb_do
 
 That re-emit is the part worth recording, because the append-only rule says not to. No upgrade edge can ever be walked by `db init`: every one of them is a self-edge, `checkIntegrity` requires a self-edge to carry a `data`-class op, and `db init` runs `allowedOperationClasses: ['additive']`. A fresh database therefore has to collect every head-ref invariant from the genesis edge, so a new required invariant either lands on the baseline or arrives on a second `from: null` edge duplicating the full ~2.6 MB bundle — permanently, once per EQL release. Re-emitting was chosen while `@cipherstash/stack-prisma@1.0.0` was 14 days old with ~253 monthly downloads, i.e. while the blast radius was small and knowable, and the changeset carries the delete-and-re-plan instruction. **Once this package has real adoption the second genesis edge is the correct shape** and the size cost is the price of not orphaning consumers; the trade should be re-argued on adoption numbers at the next bump, not defaulted to.
 
+**Re-argued at 3.0.6, and re-emitted once more — still one change on npm.** The next bump changed only the version stamp (`eql_v3.version()` and the `eql_v3` schema comment), but it still moved the digest (`accde003…` → `9b6dab78…`), and the Version Packages PR (`cipherstash/stack#938`) failed the lockstep test because no migration baked it. The trade came out the same way, on the numbers it was meant to be argued on: `@cipherstash/stack-prisma` had 144 npm downloads in September 2026 (52 in its last week), below the ~253/month at which the 3.0.5 re-emit was judged small and knowable; and a second genesis edge would have added another permanent ~2.6 MB bundle copy for a release with no behavioural change. A new `20261002T0000_upgrade_eql_v3_3_0_6` edge carries existing databases. One fact the 3.0.5 record did not have: that re-emit never reached npm. 1.0.0 ships baseline `fc495f7f…` and 1.1.0 and 1.1.1 ship `1030654387…`, both baking the eql-3.0.4 bundle, and none of the three ships the 3.0.5 edge (checked against the unpacked tarballs). So the 3.0.6 re-emit rewrote an unpublished baseline, not a second published one: npm consumers see the 3.0.5 and 3.0.6 re-emits as one baseline change, in the same release that first ships both upgrade edges. The 3.0.5 edge is kept anyway — the frozen-history guard treats every committed edge as published, and a database built from `main` may already have walked it — so a database on eql-3.0.4 installs the bundle twice on upgrade, a time cost rather than a correctness problem. The append-only rule, and the second genesis edge once adoption is real, still stand for the next bump.
+
 The narrower lesson for the absorption: **absorbing a repo swaps "last published release" for "current HEAD" across every consumer**, and nothing in the dependency graph announces that. Only a digest pin caught it here. Any other package this repo absorbs by workspace link deserves the same check — diff the built artefact against the published tarball — before the link is treated as neutral.
 
 ### Three imported release workflows violate the no-caching rule — by omission, not by setting

examples/prisma/migrations/cipherstash/20260601T0100_install_eql_v3_bundle/migration.json

@@ -5,8 +5,9 @@
     "cipherstash:install-eql-v3-bundle-v1",
     "cipherstash:upgrade-eql-v3-bundle-3.0.2-v1",
     "cipherstash:upgrade-eql-v3-bundle-3.0.4-v1",
-    "cipherstash:upgrade-eql-v3-bundle-3.0.5-v1"
+    "cipherstash:upgrade-eql-v3-bundle-3.0.5-v1",
+    "cipherstash:upgrade-eql-v3-bundle-3.0.6-v1"
   ],
   "createdAt": "2026-07-14T20:10:24.325Z",
-  "migrationHash": "bad30c9b3d2ad383d853cda0209eb14a031f2d107ba9cbdfb26b95d58e9aff37"
+  "migrationHash": "2fdc7cafd2c6011b5129267cd77e640077fdc6401cba5a987c3f0bb412dad05c"
 }

examples/prisma/migrations/cipherstash/20260601T0100_install_eql_v3_bundle/ops.json

@@ -0,0 +1,9 @@
+{
+  "from": "0c0734babd6eeb868fee1f281ca96963022475611560e9f170f465daa35f8599",
+  "to": "0c0734babd6eeb868fee1f281ca96963022475611560e9f170f465daa35f8599",
+  "providedInvariants": [
+    "cipherstash:upgrade-eql-v3-bundle-3.0.6-v1"
+  ],
+  "createdAt": "2026-10-02T04:18:42.588Z",
+  "migrationHash": "b16c9fc5fbe87f2ec03bcae3fc3d619cb4aac0c5781da7ba2105d3e11a6e0a3a"
+}

examples/prisma/migrations/cipherstash/20261002T0000_upgrade_eql_v3_3_0_6/migration.json

@@ -1 +1 @@
-{"hash":"0c0734babd6eeb868fee1f281ca96963022475611560e9f170f465daa35f8599","invariants":["cipherstash:install-eql-v3-bundle-v1","cipherstash:upgrade-eql-v3-bundle-3.0.2-v1","cipherstash:upgrade-eql-v3-bundle-3.0.4-v1","cipherstash:upgrade-eql-v3-bundle-3.0.5-v1"]}
+{"hash":"0c0734babd6eeb868fee1f281ca96963022475611560e9f170f465daa35f8599","invariants":["cipherstash:install-eql-v3-bundle-v1","cipherstash:upgrade-eql-v3-bundle-3.0.2-v1","cipherstash:upgrade-eql-v3-bundle-3.0.4-v1","cipherstash:upgrade-eql-v3-bundle-3.0.5-v1","cipherstash:upgrade-eql-v3-bundle-3.0.6-v1"]}