feat!: remove EQL v2 repo-wide (umbrella, #707)

.changeset/adapter-release-readiness.md

@@ -0,0 +1,50 @@
+---
+'@cipherstash/stack': minor
+'@cipherstash/stack-supabase': minor
+'stash': patch
+'@cipherstash/wizard': patch
+---
+
+Finish the EQL v2-removal release gates and adapter correctness pass.
+
+- **Supabase encrypts leaves nested inside a PostgREST boolean group.** This
+  is a disclosure fix, not a formatting one. The `.or()` string parser had
+  no group recursion, so `.or('and(createdAt.gte.2026-01-01,note.eq.x)')`
+  came back from the top-level split as one part and the leaf parser cut it
+  at the first dot into the pseudo-column `and(createdAt`. That name matched
+  no encrypted column, so the whole expression took the verbatim branch: the
+  operand `2026-01-01` reached PostgREST **as plaintext, against an
+  encrypted column**, under the JS property name `createdAt` rather than the
+  DB column name `created_at`. Every encrypted leaf nested inside `and(...)`
+  / `or(...)` / `not.and(...)` leaked its operand to the database and
+  returned wrong results. Nested groups and `referencedTable` are now
+  preserved while each encrypted leaf is substituted in place.
+- Supabase never sends nullish encrypted search operands as plaintext, honours
+  escaped LIKE metacharacters, rejects CSV result mode before decryption, and
+  diagnoses the removed object-form factory call. The bundled `stash-supabase`
+  skill no longer lists `csv()` among the transforms passed through to
+  Supabase — it throws, and the skill now says so and shows serializing the
+  decrypted rows instead.
+- Native, WASM, and Supabase model decryption reconstruct valid date and
+  timestamp values consistently, including nested paths, aliases, and bulk
+  results, while leaving invalid values unchanged. That last clause is a
+  behavioural change on the native typed client and the Supabase adapter,
+  which previously pushed every date-like column through `new Date(...)`
+  unconditionally: a stored value that does not parse used to come back as an
+  Invalid `Date` and now comes back as the raw string, matching what the WASM
+  entry already did. The declared column type is still `Date`, so code that
+  assumed `instanceof Date` held for every date column — or called a `Date`
+  method on it unguarded, so that `.getTime()` used to yield `NaN` and now
+  throws a `TypeError` — has to handle the raw value.
+- `stash init` names the concrete `public.eql_v3_*` domain family and gives
+  `public.eql_v3_text_search` as a valid Supabase example.
+- CLI and wizard skill selection stay in parity for every integration,
+  including the Prisma Next skill, and verify that each selected skill has a
+  `SKILL.md`.
+
+The final 1.0 integration surface is `Encryption` from
+`@cipherstash/stack/v3`, the `@cipherstash/stack-drizzle` package root, and
+`encryptedSupabase` from `@cipherstash/stack-supabase`. DynamoDB decrypt
+operations retain `.audit()` on the typed `Encryption` client. Existing EQL v2
+ciphertext remains readable through the core client; authoring and adapter
+writes use EQL v3.

.changeset/backfill-missing-column-message.md

@@ -0,0 +1,12 @@
+---
+'stash': patch
+---
+
+`stash encrypt backfill` now distinguishes a missing encrypted column from a
+legacy EQL v2 one. The domain probe returns the same "not v3" answer for both,
+so a user who had simply not added the `<col>_encrypted` column yet was told
+they were on a legacy EQL v2 column and advised to migrate a domain that did not
+exist. The command now reports that the column is absent, points at adding an
+`eql_v3_*`-domain column and applying the migration, and mentions
+`--encrypted-column` for non-standard names. The EQL v2 message is unchanged for
+columns that really are present.

.changeset/cli-near-miss-statement-trim.md

@@ -0,0 +1,15 @@
+---
+'stash': patch
+---
+
+Trim the leading comment block from near-miss statements reported by the Drizzle
+migration rewriter (`stash eql migration --drizzle`, `stash eql install`).
+
+The broad near-miss scan is anchored on the previous `;`, so a
+`SET DATA TYPE … USING …` it could not safely repair was quoted back to the user
+with every preceding comment and blank line glued to its front — in a file
+opening with a comment block, that meant the whole header. The reported
+statement is now the offending statement alone. Detection is unchanged; only the
+text shown to the user is affected.
+
+Keeps this rewriter in sync with its sibling in `@cipherstash/wizard`.

.changeset/cli-v2-cutover-prompt-correction.md

@@ -0,0 +1,15 @@
+---
+'stash': patch
+---
+
+`stash init`'s setup prompt no longer tells agents to declare an EQL v2 cutover
+column with a `types.*` domain.
+
+The `types.*` factories are EQL v3 only — a v2 column is an `eql_v2_encrypted`
+composite — so an agent following the old step-4 guidance would author a schema
+that cannot describe the column it just cut over to. The prompt now says
+explicitly not to use `types.*` for a v2 column, and points at the deprecated
+`@cipherstash/stack/schema` builders with decryption through
+`@cipherstash/stack`, which is the actual read path for legacy v2 rows.
+
+Superseded later in this release: `stash encrypt cutover` and all v2 mutation guidance are removed; legacy v2 remains read-only.

.changeset/decrypt-chaining-docs.md

@@ -0,0 +1,73 @@
+---
+'stash': patch
+'@cipherstash/stack': patch
+---
+
+Correct the shipped documentation for `decryptModel` / `bulkDecryptModels`.
+
+Three places in `skills/stash-encryption` and four in `packages/stack/README.md`
+said these return "a plain `Promise<Result<...>>` (not a chainable operation)"
+and that there is therefore "no `.withLockContext()` to chain". They return an
+`AuditableDecryptModelOperation`, which is thenable and carries both
+`.withLockContext()` and `.audit()` — the same `.audit()` chain the
+audit-on-decrypt work advertises. The skill contradicted itself: its own
+reference table already listed the correct return type.
+
+The skill ships inside the `stash` tarball and `installSkills()` copies it into
+customer repos, so this was steering agents away from an API that exists. The
+README ships in the `@cipherstash/stack` tarball.
+
+The equivalent statement about the **WASM entry** is correct and unchanged —
+`@cipherstash/stack/wasm-inline` really does return a plain promise from decrypt,
+with no lock-context argument.
+
+Also fixes the setup prompt `stash init` writes for coding agents, which
+referenced `protectOps.eq` — an API that does not exist anywhere in the repo.
+Every step naming an integration-specific API now branches on the project's
+actual integration, instead of naming Drizzle's and Supabase's and leaving the
+other two to guess:
+
+- **Query paths.** `createEncryptionOperators(client)` (conventionally `ops`)
+  for Drizzle, the `encryptedSupabase` wrapper's own filters for Supabase, the
+  `eql*` column operators for Prisma Next, and `client.encryptQuery(...)` for a
+  plain Postgres project.
+- **Schema authoring.** The `types.*` column factories for Drizzle, a concrete
+  `public.eql_v3_*` domain such as `public.eql_v3_text_search` in migration SQL
+  for Supabase, the `cipherstash.*`
+  field constructors in `schema.prisma` for Prisma Next, and `encryptedTable`
+  for plain Postgres. Prisma Next was previously sent at `types.*` /
+  `encryptedTable` — the client `stash schema build` explicitly refuses to
+  scaffold for that integration.
+- **Read paths.** `decryptModel(row, usersSchema)` where that applies, and the
+  wrapper's transparent decryption where it does not.
+- **Skill pointers.** A plain Postgres project installs no integration-specific
+  skill, so each "see the integration skill" was a pointer at a file that was
+  never written. Those now point at `stash-encryption`, which it does get.
+
+`client.encryptQuery` is also shown taking the schema objects themselves
+(`{ table: usersSchema, column: usersSchema.email }`) rather than an
+object-shorthand that read as three required strings — `queryType` is inferred
+from the column's configured indexes.
+
+The cutover and complete-rollout **plan templates** now split EQL v3 from v2.
+Both described the v2 rename swap (`<col>` → `<col>_plaintext`, twin → `<col>`)
+as the only cutover path, so on the default v3 install `stash plan` drafted a
+plan built around `stash encrypt cutover` — a command that refuses v3 columns
+outright ("there is no rename step") and refuses entirely on a v3-only
+database, where `eql_v2_configuration` does not exist. The implement prompt
+already carried this split; the plan templates did not. The version is
+per-column, so the templates tell the agent to establish it per column rather
+than deciding once for the whole plan.
+
+The "already encrypted" stop-and-ask now recognises `eql_v3_*` domains
+alongside the legacy `eql_v2_encrypted` udt, so it can fire on the default
+path at all.
+
+**`stash init` now detects already-encrypted columns on EQL v3.** Database
+introspection marked a column as CipherStash-managed only when its udt was
+exactly `eql_v2_encrypted`. v3 columns carry per-domain types
+(`eql_v3_text_search`, `eql_v3_integer_ord`, …), so on the default path every
+encrypted column was reported as plaintext — shown with its `dataType` and left
+unticked in the column picker, inviting a re-run to encrypt it a second time.
+The picker also labelled any encrypted column with the literal string
+`eql_v2_encrypted`; it now shows the column's real domain.

.changeset/domain-carrier-not-public.md

@@ -0,0 +1,18 @@
+---
+'@cipherstash/stack': patch
+---
+
+The phantom domain carrier on encrypted v3 columns is no longer part of the
+public surface.
+
+Recovering a column's domain after declaration emit requires the type parameter
+to appear bare somewhere in the instance type, which is what makes typed
+`encryptQuery` callable against the published package. That carrier was a
+plainly named `__domain` property, and this build has no `stripInternal`, so
+`@internal` was documentation rather than enforcement: it appeared in
+autocomplete on every column and could be read from consumer code, typed
+`D | undefined` while being `undefined` at runtime in every case.
+
+It is now keyed by a `unique symbol` that is not exported, so it is unnameable
+outside the package while remaining exactly as inferrable. Nothing is emitted at
+runtime and no call site changes.

.changeset/drizzle-encrypted-indexes.md

@@ -2,7 +2,7 @@
 '@cipherstash/stack-drizzle': minor
 ---
 
-New `encryptedIndexes` helper on the `/v3` entry: spread
+New `encryptedIndexes` helper on the package root: spread
 `...encryptedIndexes(t)` in `pgTable`'s third-argument callback and it derives
 the recommended functional indexes for every encrypted column in the table —
 named `<table>_<column>_<capability>`, tracked by `drizzle-kit generate` like

.changeset/dynamodb-eql-v3.md

@@ -6,15 +6,17 @@
 `encryptedDynamoDB` now accepts EQL v3 tables.
 
 Pass a table built with `encryptedTable` + the `types.*` domains from
-`@cipherstash/stack/v3` (or `@cipherstash/stack/eql/v3`) to any of
-`encryptModel`, `bulkEncryptModels`, `decryptModel`, `bulkDecryptModels`. Both
-the typed client from `EncryptionV3` and the nominal client from
-`Encryption({ config: { eqlVersion: 3 } })` are accepted.
+`@cipherstash/stack/v3` to any of `encryptModel`, `bulkEncryptModels`,
+`decryptModel`, or `bulkDecryptModels`. Build the typed client with
+`Encryption({ schemas: [table] })`.
 
-EQL v2 tables continue to work unchanged — this is additive, and no existing
-caller needs to change. The table decides which wire format is used, so a
-DynamoDB table populated under one version must keep being read with that
-version.
+EQL v2 tables continue to be **readable** — `decryptModel` /
+`bulkDecryptModels` still accept one, so existing items stay accessible. Writing
+through a v2 table is a separate matter: `encryptModel` / `bulkEncryptModels`
+narrowed to EQL v3 tables in this same release, so a caller that still encrypts
+through a v2 table does need to change. The table decides which wire format is
+used, so a DynamoDB table populated under one version must keep being read with
+that version.
 
 This fixes a latent bug that made v3 unusable: the write path detected an
 encrypted value by its `k: 'ct'` tag, but EQL v3 scalars carry no `k`
@@ -33,8 +35,8 @@ Notes on capability:
   path — `{ 'profile.ssn': types.TextEq('profile.ssn') }`. The model is
   matched by dotted path, so `{ profile: { ssn } }` resolves, and the nested
   attribute keeps its `__hmac` for key conditions.
-- Audit metadata on `decryptModel` / `bulkDecryptModels` requires the nominal
-  client; the `EncryptionV3` client has no audit surface on decrypt.
+- The typed `Encryption` client supports `.audit()` on `decryptModel` and
+  `bulkDecryptModels`, including when used through the DynamoDB adapter.
 
 The DynamoDB adapter also gains its first test coverage — across the v2 and v3
 paths, where it previously had none.
@@ -71,4 +73,4 @@ type, where a declared column `email` becomes `email__source` (plus
 `email`. `decryptModel` / `bulkDecryptModels` invert it via `DecryptedAttributes`.
 `AnyEncryptedTable`, `DynamoDBEncryptionClient` and `AuditConfig` are now
 exported from `@cipherstash/stack/dynamodb` so these signatures can be named.
-The EQL v2 overloads are unchanged.
+The EQL v2 **decrypt** overloads are unchanged; the v2 encrypt overloads are removed in this release.

.changeset/dynamodb-skill-wasm-caveat.md

@@ -0,0 +1,17 @@
+---
+'stash': patch
+---
+
+The `stash-dynamodb` and `stash-encryption` skills documented EQL v2 decrypt as
+unconditionally supported, without noting that `@cipherstash/stack/wasm-inline`
+is EQL v3 only. Since that is the documented entry for Deno, Bun, Cloudflare
+Workers and Supabase Edge Functions — runtimes commonly paired with DynamoDB — a
+reader following the skill hit a runtime refusal with no forewarning. Both skills
+now state that legacy v2 items are readable on the native `@cipherstash/stack`
+entry only.
+
+The `stash-dynamodb` API reference also claimed audit metadata forwards to
+ZeroKMS "regardless of client shape". It does not: the wasm-inline client's
+operations return a plain promise with no `.audit()`, so its audit metadata is
+dropped (logged at debug). The reference now says so, and says the operation
+still succeeds.

.changeset/dynamodb-v2-read-table-forwarding.md

@@ -0,0 +1,27 @@
+---
+'@cipherstash/stack': patch
+---
+
+Fix `encryptedDynamoDB`'s EQL v2 read path, which failed against a v3-configured
+client — the case the v2 read support exists for.
+
+`decryptModel` and `bulkDecryptModels` forwarded the table to the encryption
+client unconditionally. The second argument is only meaningful to the typed EQL
+v3 client, which resolves it against its own reconstructor map; a legacy v2
+table is not in that map, so the call failed with:
+
+```
+[eql/v3]: decryptModel received a table this client was not initialized with
+```
+
+That contradicted the adapter's documented contract — writes are EQL v3 only,
+but decrypt keeps accepting a v2 table so previously stored items stay readable.
+In practice the failure hit exactly the customers the compatibility promise was
+written for: upgraded to a v3 schema, with v2 items still in the table.
+
+The table is now forwarded only when it is an EQL v3 table. A v2 table takes the
+table-less form, and the client derives the table from the payloads themselves.
+
+Both paths are covered by a credential-free test asserting what the adapter
+forwards, so a regression no longer depends on a live-credential integration run
+to surface.

.changeset/dynamodb-wasm-v2-read.md

@@ -0,0 +1,39 @@
+---
+'@cipherstash/stack': patch
+---
+
+`encryptedDynamoDB` now refuses a `@cipherstash/stack/wasm-inline` client paired
+with a legacy EQL v2 table, instead of failing at the first read with a
+misleading error.
+
+The adapter's v2 read path deliberately calls `decryptModel(item)` with **no**
+table — a v2 table means nothing to a v3 client's reconstructor map, and the
+native clients derive the table from the payloads anyway. `WasmEncryptionClient`
+cannot do that: its decrypt requires the table and resolves date fields from a
+per-table map, so the omitted argument surfaced as
+`TypeError: Cannot read properties of undefined (reading 'tableName')` thrown
+from deep inside the client — on the documented entry for Deno, Cloudflare
+Workers and Supabase Edge Functions, which satisfies the adapter's client type
+structurally and so was accepted with no cast.
+
+The pairing is now rejected at the call site, with a message naming both the
+combination and the fix. The message is operation-neutral: the guard runs on all
+four operations, so a plain-JS caller reaching the write path with a v2 table
+gets a message that does not claim a read it never attempted.
+
+`encryptModel` / `bulkEncryptModels` now also tolerate a client whose encrypt
+returns a plain promise. They chained `.audit()` onto the result
+unconditionally, which the wasm-inline client does not carry — so **every EQL v3
+write through this adapter on that entry** failed with
+`client.encryptModel(...).audit is not a function`, surfaced as a
+`DYNAMODB_ENCRYPTION_ERROR` and so indistinguishable from a real encryption
+fault. The read path already handled this; the write path now matches, via the
+same fail-closed check that rejects a malformed result rather than passing an
+unencrypted item through as a success. Audit metadata still has nowhere to go on
+that client, so it is dropped and logged at debug — the write itself succeeds.
+
+Three comments in this package claimed audit metadata was forwarded "regardless
+of client shape" and that "every client this package ships carries `.audit()` on
+decrypt". Neither was true of the wasm-inline client, whose decrypt returns a
+plain promise — the metadata is dropped, observably (it is logged at debug), and
+the comments and the debug message now say so.

.changeset/encrypt-client-guard-parity.md

@@ -0,0 +1,20 @@
+---
+'stash': patch
+---
+
+`stash encrypt backfill` now names the cause when the encryption client has no
+initialized encrypt config, instead of reporting a missing table.
+
+The guard that refuses an unusable client file existed twice — once in
+`loadEncryptConfig` (`stash db push` / `db validate`) and once, hand-copied, in
+`loadEncryptionContext` (`stash encrypt backfill`). The copies had already
+drifted: for a client whose `getEncryptConfig()` returns nothing, `db push`
+exited 1 with `Encryption client in <file> has no initialized encrypt config`,
+while `encrypt backfill` fell through to `Table "users" was not found in the
+encryption client exports. Available: (none)` — naming the symptom rather than
+the cause, which is precisely the failure the guard was added to eliminate.
+
+Both loaders now call one shared guard, so a single file cannot produce two
+different diagnoses, and the refusals are pinned at both public entry points.
+The un-replaced `stash init` scaffold is unaffected — it was already refused by
+both, with the same message.