@cipherstash/stack 1.0.0-rc.0 → 1.0.0-rc.1

package/CHANGELOG.md

@@ -1,5 +1,70 @@
 # @cipherstash/stack
 
+## 1.0.0-rc.1
+
+### Minor Changes
+
+- 5fe9a2f: Encrypted-JSON querying on the v3 Supabase surface (#650). A `types.Json`
+  column now supports exact encrypted containment — `contains(col, subDocument)`
+  (ste_vec `@>` via PostgREST `cs`, with the sub-document storage-encrypted
+  against the column) — and JSONPath selector predicates: `selectorEq(col, path,
+value)` and `selectorNe(col, path, value)` (dot-notation paths; `ne` includes
+  rows where the path is absent, mirroring the Drizzle selector's semantics).
+  Raw `.filter(col, 'cs', subDocument)` and `not(col, 'contains', …)` route
+  through the same encrypted path. Selector ordering is not expressible over
+  PostgREST yet (needs an EQL-bundle overload — see
+  cipherstash/encrypt-query-language#407); the Drizzle integration's
+  `ops.selector()` covers ordering today.
+
+  In core, `QueryTypesForColumn` gains the `searchableJson` arm (a `types.Json`
+  column no longer resolves to `never`, so typed adapter key sets can include
+  it), and the JSONPath selector-path helpers the Drizzle adapter introduced in
+  #651 moved to `@cipherstash/stack/adapter-kit` so both adapters share one
+  validation surface (`@cipherstash/stack-drizzle` re-exports them unchanged).
+
+  The bundled `stash-supabase` and `stash-encryption` skills are updated to
+  document the new querying surface (including the array-leaf and SQL-NULL
+  semantics, and the operand-exposure caveat) — skills ship inside the `stash`
+  tarball, hence the patch.
+
+### Patch Changes
+
+- e297f64: Docs: EQL v3 is now the sole documented approach. The `stash-encryption`,
+  `stash-drizzle`, and `stash-supabase` skills and the `@cipherstash/stack`
+  README teach only the v3 typed surface (`EncryptionV3`, `types.*` concrete
+  domains, `@cipherstash/stack-drizzle/v3`, `encryptedSupabaseV3`); EQL v2
+  shrinks to one short Legacy section per document. Two explicit exceptions are
+  called out: DynamoDB still requires the v2 schema surface (#657), and the
+  encrypt rollout tooling (`stash encrypt backfill`/`cutover`,
+  `@cipherstash/migrate`) currently targets v2 columns (#648) — its guidance is
+  kept under a version callout. Also corrects the legacy `@cipherstash/drizzle`
+  README's pointer to the removed `@cipherstash/stack/drizzle` subpath (now the
+  separate `@cipherstash/stack-drizzle` package).
+- 40ab142: Docs: stop teaching the deprecated `LockContext.identify()` as the primary
+  identity-aware-encryption path (#591). The `stash-encryption` and `stash-supabase`
+  skills and the `@cipherstash/stack` README now lead with the current pattern —
+  authenticate the client with `OidcFederationStrategy`, then bind the claim per
+  operation with `.withLockContext({ identityClaim })` — and demote
+  `LockContext.identify()` to a clearly-marked deprecated note (per-operation CTS
+  tokens were removed in protect-ffi 0.25). Skills ship in the `stash` tarball, so
+  this keeps the bundled guidance correct for the 1.0 surface.
+- 7b53141: Three correctness fixes surfaced while documenting the v3 surface:
+
+  - **Supabase `matches()` now rejects a short free-text needle.** A needle
+    below the tokenizer's `token_length` blooms to zero tokens, so `bloom @> {}`
+    matched (and the caller decrypted) every row — a fail-open exposure. The
+    guard (`matchNeedleError`) was wired into the Drizzle adapter only; the
+    Supabase adapter now applies it at the same term-resolution choke point, so
+    both first-party surfaces reject identically. (Authoritative FFI-level backstop
+    for the `encryptQuery` paths tracked in cipherstash/protectjs-ffi#138.)
+  - **Supabase `.withLockContext()` accepts the plain `{ identityClaim }` form**,
+    not only a `LockContext` instance — matching the stack-level operations and
+    the documented identity-aware example (widened to `LockContextInput`).
+  - **`EncryptionErrorTypes` is now `as const`**, so the `StackError` union
+    actually discriminates: `switch (error.type)` narrows and `error.code` is
+    reachable on the relevant branches. Without it every `type` was `string` and
+    the documented exhaustive error handler did not compile.
+
 ## 1.0.0-rc.0
 
 ### Major Changes