fix(stack): address code-review findings on the v3 integration harness (round 2)

- types.ts: exclude ORE (`*_ord_ore`) columns from `V3OrderableKeys` at COMPILE
  time (they are orderAndRange-capable but not sortable through a jsonb path), so
  `.order(oreCol)` is a type error matching the runtime rejection — no more
  green-typecheck-then-500. Pinned with a `@ts-expect-error` in the type tests.
- relational: re-add the deleted `not(between())` precedence test — `between`
  emits a two-clause conjunction and the passthrough `not` relies on
  `v3Dialect.range` parenthesising it; the only surviving `not` test wrapped a
  single-clause `eq` and could not catch a paren regression. Asserts ROW_C is
  kept, which the buggy `value < bound` form would drop.
- relational: run-scope the table names (`_${RID}`) and DROP them in teardown,
  like the family suites — a fixed name races a concurrent run's `beforeAll` DROP
  on a shared/persistent DB.
- supabase adapter `expectRejected`: stop counting an arbitrary throw as a valid
  rejection (it matched its own sentinel by message substring). Now a thrown
  rejection must carry the `[supabase v3]` marker; a stray TypeError/network
  error rethrows and fails the test.
- query-builder-v3: drop the cached `selectKeyToDb` field (a side effect of
  `buildSelectString` read later by `postprocessDecryptedRow`) — derive it inline
  from `this.selectColumns` so a reused builder can't postprocess with a stale
  select map.
- vitest.shared.ts: add the bare `@cipherstash/stack` runtime alias (last, so the
  subpaths still win) — both sibling tsconfigs map it, and without it a bare-
  specifier importer would resolve to `dist/`, re-coupling `pnpm test` to a build.
- integration workflows: broaden the path filters to the source layers the
  adapters' encoding rests on (`src/encryption`, `src/schema`, `packages/schema`)
  so a break there triggers the live wire/round-trip suites.

Note: the `orderColumnName` bare-fallback finding was investigated and found to
be a non-issue — `validateTransforms` runs before the query executes and rejects
the column with a domain-specific message, so the bare name is only an
intermediate value on an about-to-be-rejected request. Corrected the misleading
comment instead of adding a throw (which regressed that message).

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

Author: coderdan

.changeset/supabase-v3-order-by-ope-term.md

@@ -26,7 +26,9 @@ The guard is now on the ordering FLAVOUR, not on encryption:
 - **`ore` present → rejected.** The `ob` term is an array of ORE blocks whose
   comparison needs the superuser-only operator class, which no jsonb path can
   reach. (Such a column cannot hold data on managed Postgres anyway: its domain
-  CHECK raises `ore_domain_unavailable`.)
+  CHECK raises `ore_domain_unavailable`.) ORE columns are now excluded from
+  `order()` at COMPILE time too, not only at runtime — `.order(oreColumn)` is a
+  type error, matching the rejection.
 - **neither → rejected.** Storage-only, equality-only and match-only columns
   carry no ordering term.
 
@@ -38,6 +40,8 @@ numeric and date domains, and per-character (16 hex chars each) for text, so
 lexicographic order reproduces plaintext order including the prefix case
 (`ada` < `adam`). `ope-term.integration.test.ts` pins that shape.
 
-`V3OrderableKeys` widens to match, so `order()` on an ordering column
-typechecks. `is(col, true)` is unaffected — it stays plaintext-only, and now has
-its own `V3PlaintextKeys` rather than borrowing the orderable set.
+`V3OrderableKeys` widens to admit OPE-backed ordering columns (`*_ord`,
+`text_ord`, `text_search`) while still excluding ORE (`*_ord_ore`) columns, so
+`order()` typechecks exactly where it works. `is(col, true)` is unaffected — it
+stays plaintext-only, and now has its own `V3PlaintextKeys` rather than
+borrowing the orderable set.

.github/workflows/integration-drizzle.yml

@@ -18,6 +18,12 @@ on:
     branches: [main]
     paths:
       - 'packages/stack/src/eql/v3/**'
+      # Source layers the adapter's encoding/round-trip rests on: a break here
+      # (not just under src/eql/v3) can produce wrong rows, so trigger the live
+      # suite that would catch it.
+      - 'packages/stack/src/encryption/**'
+      - 'packages/stack/src/schema/**'
+      - 'packages/schema/**'
       - 'packages/stack/integration/**'
       - 'packages/test-kit/**'
       - 'packages/cli/src/installer/**'
@@ -31,6 +37,12 @@ on:
     # Repeated verbatim: GitHub Actions does not support YAML anchors/aliases.
     paths:
       - 'packages/stack/src/eql/v3/**'
+      # Source layers the adapter's encoding/round-trip rests on: a break here
+      # (not just under src/eql/v3) can produce wrong rows, so trigger the live
+      # suite that would catch it.
+      - 'packages/stack/src/encryption/**'
+      - 'packages/stack/src/schema/**'
+      - 'packages/schema/**'
       - 'packages/stack/integration/**'
       - 'packages/test-kit/**'
       - 'packages/cli/src/installer/**'

.github/workflows/integration-supabase.yml

@@ -14,6 +14,12 @@ on:
     paths:
       - 'packages/stack/src/supabase/**'
       - 'packages/stack/src/eql/v3/**'
+      # Source layers the adapter's encoding/round-trip rests on: a break here
+      # (not just under src/supabase) can produce wrong wire output or rows, so
+      # trigger the live suite that would catch it.
+      - 'packages/stack/src/encryption/**'
+      - 'packages/stack/src/schema/**'
+      - 'packages/schema/**'
       - 'packages/stack/integration/**'
       - 'packages/test-kit/**'
       - 'packages/cli/src/installer/**'
@@ -26,6 +32,12 @@ on:
     paths:
       - 'packages/stack/src/supabase/**'
       - 'packages/stack/src/eql/v3/**'
+      # Source layers the adapter's encoding/round-trip rests on: a break here
+      # (not just under src/supabase) can produce wrong wire output or rows, so
+      # trigger the live suite that would catch it.
+      - 'packages/stack/src/encryption/**'
+      - 'packages/stack/src/schema/**'
+      - 'packages/schema/**'
       - 'packages/stack/integration/**'
       - 'packages/test-kit/**'
       - 'packages/cli/src/installer/**'

packages/stack/__tests__/supabase-v3.test-d.ts

@@ -18,6 +18,7 @@ const users = encryptedTable('users', {
   active: types.Boolean('active'),
   nickname: types.TextEq('nickname'),
   bio: types.TextMatch('bio'),
+  score: types.IntegerOrdOre('score'),
 })
 
 type UserRow = InferPlaintext<typeof users>
@@ -130,6 +131,11 @@ describe('encryptedSupabaseV3 typed surface (with schemas)', () => {
     builder.order('nickname')
     // @ts-expect-error — bio is public.eql_v3_text_match: match only
     builder.order('bio')
+    // @ts-expect-error — score is public.eql_v3_integer_ord_ore: ORE-backed, so
+    // orderAndRange-capable but NOT sortable through a jsonb path (its `ob` term
+    // needs the superuser-only ORE opclass). Excluded at compile time to match
+    // the runtime rejection.
+    builder.order('score')
   })
 
   it('still allows order() on a plaintext row key', async () => {

packages/stack/integration/drizzle-v3/relational.integration.test.ts

@@ -52,9 +52,15 @@ import { makeEqlV3Column } from '@/eql/v3/drizzle/column'
 
 const sqlClient = postgres(databaseUrl(), { prepare: false })
 
-const TABLE_NAME = 'protect_ci_v3_drizzle_matrix'
-const ACCOUNT_TABLE_NAME = 'protect_ci_v3_drizzle_matrix_accounts'
-const RUN = `run-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`
+// Per-run table suffix so two runs sharing a database (a persistent/reused CI
+// database, a developer's local DB, or re-enabled file parallelism) never
+// operate on the same physical table — one run's `beforeAll` DROP would
+// otherwise blow away a table another run is mid-query on. Mirrors the family
+// suites' run-scoped naming (`rows.ts` `planTable`).
+const RID = Math.random().toString(36).slice(2, 8)
+const TABLE_NAME = `protect_ci_v3_drizzle_matrix_${RID}`
+const ACCOUNT_TABLE_NAME = `protect_ci_v3_drizzle_matrix_accounts_${RID}`
+const RUN = `run-${Date.now()}-${RID}`
 const ROW_A = 'row-a'
 const ROW_B = 'row-b'
 // A third row. With only two rows every predicate can return just [A], [B],
@@ -103,7 +109,7 @@ const accountsTable = pgTable(ACCOUNT_TABLE_NAME, {
 // known at compile time, so it exercises A3 end-to-end with ZERO casts: the
 // insert takes envelope rows and the select yields `Encrypted` values ready for
 // decrypt.
-const BIGINT_TABLE_NAME = 'protect_ci_v3_drizzle_bigint'
+const BIGINT_TABLE_NAME = `protect_ci_v3_drizzle_bigint_${RID}`
 const bigintTable = pgTable(BIGINT_TABLE_NAME, {
   id: integer('id').primaryKey().generatedAlwaysAsIdentity(),
   rowKey: text('row_key').notNull(),
@@ -218,12 +224,13 @@ beforeAll(async () => {
     .map(([eqlType]) => `"${slug(eqlType)}" ${eqlType} NOT NULL`)
     .join(',\n      ')
 
-  // DROP, not `CREATE TABLE IF NOT EXISTS`. A table left by an earlier run keeps
-  // its old columns, so a change to the catalog silently reuses the stale schema.
-  // That bit: after the `_ord_ore` domains were filtered out of `matrixEntries`,
-  // the leftover table still carried its nine ORE columns, and on managed
-  // Postgres every INSERT raised `ore_domain_unavailable` — even leaving those
-  // columns NULL, because the domain CHECK calls a function that RAISEs.
+  // Table names are run-scoped (see RID), so DROP IF EXISTS is normally a no-op;
+  // it stays as a belt-and-braces guard against an id collision. Recreating from
+  // scratch each run also means a catalog change can never silently reuse a
+  // stale schema — the bug that bit once when the `_ord_ore` domains were
+  // filtered out of `matrixEntries` but a leftover fixed-name table kept its nine
+  // ORE columns, making every INSERT raise `ore_domain_unavailable` on managed
+  // Postgres (the domain CHECK RAISEs even for a NULL value).
   await sqlClient.unsafe(`
     DROP TABLE IF EXISTS ${TABLE_NAME}
   `)
@@ -299,9 +306,11 @@ beforeAll(async () => {
 }, 120000)
 
 afterAll(async () => {
-  await sqlClient`DELETE FROM ${sqlClient(TABLE_NAME)} WHERE test_run_id = ${RUN}`
-  await sqlClient`DELETE FROM ${sqlClient(ACCOUNT_TABLE_NAME)} WHERE test_run_id = ${RUN}`
-  await sqlClient`DELETE FROM ${sqlClient(BIGINT_TABLE_NAME)} WHERE test_run_id = ${RUN}`
+  // Tables are run-scoped, so drop them outright rather than DELETE-ing rows —
+  // no other run shares them, and this leaves nothing behind on a persistent DB.
+  await sqlClient.unsafe(`DROP TABLE IF EXISTS ${TABLE_NAME}`)
+  await sqlClient.unsafe(`DROP TABLE IF EXISTS ${ACCOUNT_TABLE_NAME}`)
+  await sqlClient.unsafe(`DROP TABLE IF EXISTS ${BIGINT_TABLE_NAME}`)
   await sqlClient.end()
 }, 30000)
 
@@ -449,6 +458,25 @@ describe('v3 drizzle — relational, needle guards, pagination', () => {
     expect(rows).toEqual([ROW_B, ROW_C])
   }, 30000)
 
+  it('not(between()) negates the whole range, not just the lower bound', async () => {
+    // integer_ord: ROW_A=0, ROW_B=-42, ROW_C=2147483647. `not(between(0, 0))`
+    // must return every row whose value != 0 → ROW_B and ROW_C.
+    //
+    // `between` emits a TWO-clause conjunction, and Drizzle's passthrough `not`
+    // renders a bare `NOT <cond>`. Postgres binds NOT tighter than AND, so this
+    // only works because `v3Dialect.range` already parenthesises `(gte AND lte)`.
+    // Without those parens, `NOT gte(0) AND lte(0)` parses as
+    // `value < 0 AND value <= 0` = `value < 0` = ROW_B alone, silently dropping
+    // ROW_C. Asserting ROW_C is present is what discriminates the two — a
+    // single-bound complement would satisfy the buggy form too.
+    const rows = await selectRowKeys(
+      ops.not(
+        await ops.between(matrixColumn('public.eql_v3_integer_ord'), 0, 0),
+      ),
+    )
+    expect(rows).toEqual([ROW_B, ROW_C])
+  }, 30000)
+
   it('isNull and isNotNull work on nullable encrypted columns', async () => {
     expect(await selectRowKeys(ops.isNull(matrixTable.nullableTextEq))).toEqual(
       [ROW_A],

packages/stack/integration/supabase/adapter.ts

@@ -205,26 +205,27 @@ export function makeSupabaseAdapter(): IntegrationAdapter {
     },
 
     async expectRejected(_table: TableSpec, op: QueryOp) {
-      // The guards fire in two places: capability checks throw synchronously at
-      // call time, while a term that reaches `execute` surfaces as a Result
-      // error. Accept either; the point is that the query never runs.
+      // The rejection fires in one of two places: a capability check throws
+      // synchronously while collecting terms (marked `[supabase v3]`), or a term
+      // that reaches `execute` comes back as a Result error. Accept either — but
+      // NOT an arbitrary throw. A `TypeError` while assembling the term, or a
+      // network failure, is not the refusal this test asserts; counting it would
+      // let the test pass for the wrong reason if the real capability guard were
+      // removed. The `try` wraps only `applyOp`, and the "not rejected" error is
+      // thrown OUTSIDE it, so it can never be swallowed as a rejection.
+      let error: { message: string } | null
       try {
-        const { error } = await applyOp(op)
-        if (!error) {
-          throw new Error(
-            `Expected ${op.kind}("${op.column}") to be rejected, but it succeeded`,
-          )
-        }
+        ;({ error } = await applyOp(op))
       } catch (cause) {
-        if (
-          cause instanceof Error &&
-          cause.message.startsWith('Expected ') &&
-          cause.message.includes('to be rejected')
-        ) {
-          throw cause
+        if (cause instanceof Error && cause.message.includes('[supabase v3]')) {
+          return // a modeled capability rejection
         }
-        // A thrown guard is a rejection.
+        throw cause // an unexpected error — fail loudly
       }
+      if (error) return // an execute-time DB refusal (e.g. a PostgREST error)
+      throw new Error(
+        `Expected ${op.kind}("${op.column}") to be rejected, but it succeeded`,
+      )
     },
   }
 }

packages/stack/src/supabase/query-builder-v3.ts

@@ -146,15 +146,6 @@ export class EncryptedQueryBuilderV3Impl<
   private columnSchemas: Record<string, ColumnSchema>
   /** Column builders keyed by BOTH property name and DB name. */
   private v3Columns: Record<string, V3ColumnLike>
-  /**
-   * Result-row key → DB column name for the columns the current select
-   * produces, including caller-chosen PostgREST aliases (`ts:createdAt` keys
-   * rows by `ts`). Populated by {@link buildSelectString}; consumed by
-   * {@link postprocessDecryptedRow} so aliased date columns still get `Date`
-   * reconstruction. Empty on paths with no recorded select (an insert or update
-   * that returns rows), which fall back to the static property/DB names.
-   */
-  private selectKeyToDb: Record<string, string> = Object.create(null)
 
   constructor(
     tableName: string,
@@ -300,8 +291,13 @@ export class EncryptedQueryBuilderV3Impl<
    * `text_search`) — and every collation orders digits before letters and hex
    * letters among themselves. `match-bloom`'s sibling assertion pins that shape.
    *
-   * `validateTransforms` has already rejected every encrypted column that lacks
-   * an `ope` index, so reaching the jsonb path here implies the term exists.
+   * This runs at column-name-mapping time (`transformToDbSpace`), BEFORE
+   * `buildAndExecuteQuery` calls `validateTransforms`. For an encrypted column
+   * with no `ope` index it therefore returns a bare `dbName` here — a name that
+   * would sort by `jsonb_cmp` over the ciphertext if it reached PostgREST — but
+   * it never does: `validateTransforms` throws (with a domain-specific reason)
+   * before the query executes, so the bare name is only ever an intermediate
+   * value on a request that is about to be rejected.
    */
   protected override orderColumnName(column: string): DbName {
     const dbName = this.dbNameFor(column)
@@ -348,7 +344,6 @@ export class EncryptedQueryBuilderV3Impl<
 
   protected override buildSelectString(): DbSelect | null {
     if (this.selectColumns === null) return null
-    this.selectKeyToDb = selectKeyToDbV3(this.selectColumns, this.propToDb)
     return addJsonbCastsV3(this.selectColumns, this.propToDb)
   }
 
@@ -603,10 +598,14 @@ export class EncryptedQueryBuilderV3Impl<
     // Every key an encrypted column can appear under: the keys this select
     // actually produces (including caller-chosen aliases like `ts:createdAt`),
     // plus the static property and DB names as a fallback for paths that record
-    // no select. Aliases win — `selectKeyToDb` describes the row in hand.
+    // no select. Aliases win. Derived here from `this.selectColumns` (the row in
+    // hand) rather than cached from `buildSelectString`, so a reused builder can
+    // never postprocess a row with a previous operation's stale select map.
     const keyToDb: Record<string, string> = Object.assign(
       Object.create(null),
-      this.selectKeyToDb,
+      this.selectColumns === null
+        ? undefined
+        : selectKeyToDbV3(this.selectColumns, this.propToDb),
     )
     for (const [property, dbName] of Object.entries(this.propToDb)) {
       keyToDb[property] ??= dbName

packages/stack/src/supabase/types.ts

@@ -1,6 +1,11 @@
 import type { EncryptionClient } from '@/encryption'
 import type { AuditConfig } from '@/encryption/operations/base-operation'
-import type { AnyV3Table, InferPlaintext, QueryTypesForColumn } from '@/eql/v3'
+import type {
+  AnyV3Table,
+  EqlTypeForColumn,
+  InferPlaintext,
+  QueryTypesForColumn,
+} from '@/eql/v3'
 import type { EncryptionError } from '@/errors'
 import type { LockContext } from '@/identity'
 import type { EncryptedTable, EncryptedTableColumn } from '@/schema'
@@ -188,16 +193,26 @@ export type V3ContainsValue<
   : string
 
 /**
- * JS property names of a v3 table's columns that carry NO `orderAndRange`
- * capability — storage-only, equality-only and match-only domains. They hold no
- * ordering term, so there is nothing for `order()` to sort by.
+ * JS property names of a v3 table's columns that `order()` cannot sort by. Two
+ * cases:
+ *
+ * 1. Columns with NO `orderAndRange` capability — storage-only, equality-only
+ *    and match-only domains hold no ordering term.
+ * 2. ORE-backed (`*_ord_ore`) columns. They ARE `orderAndRange`-capable, but the
+ *    builder sorts encrypted columns through a jsonb path (`col->op`), and the
+ *    OPE term that path selects does not exist on an ORE domain — its `ob` term
+ *    needs the superuser-only ORE opclass no jsonb path can reach. So they are
+ *    excluded here to match the runtime rejection in `validateTransforms`,
+ *    rather than type-checking clean and throwing at execute time.
  */
 export type NonOrderableV3Keys<Table extends AnyV3Table> = {
   [K in Extract<
     keyof V3ColumnsOfTable<Table>,
     string
   >]: 'orderAndRange' extends QueryTypesForColumn<V3ColumnsOfTable<Table>[K]>
-    ? never
+    ? EqlTypeForColumn<V3ColumnsOfTable<Table>[K]> extends `${string}_ord_ore`
+      ? K
+      : never
     : K
 }[Extract<keyof V3ColumnsOfTable<Table>, string>]
 
@@ -212,12 +227,11 @@ export type NonOrderableV3Keys<Table extends AnyV3Table> = {
  * path `col->op`, which selects the OPE term, and OPE is order-preserving. See
  * `EncryptedQueryBuilderV3Impl.orderColumnName`.
  *
- * ORE-backed (`*_ord_ore`) columns are `orderAndRange`-capable and so pass this
- * type, but are rejected at runtime: their `ob` term needs the superuser-only
- * ORE opclass, which no jsonb path can reach. Encoding the ordering FLAVOUR in
- * the type system would mean threading it through `QueryTypesForColumn`, and
- * such a column cannot hold data on managed Postgres anyway (its domain CHECK
- * raises `ore_domain_unavailable`), so the runtime guard is where it belongs.
+ * ORE-backed (`*_ord_ore`) columns are excluded at compile time by
+ * {@link NonOrderableV3Keys} — the builder sorts through a jsonb path that
+ * cannot reach their superuser-only ORE opclass, so `.order()` on one is a type
+ * error, matching the runtime rejection in `validateTransforms` (defense in
+ * depth for the untyped `.order(someString)` path).
  */
 export type V3OrderableKeys<
   Table extends AnyV3Table,

vitest.shared.ts

@@ -46,4 +46,10 @@ export const sharedAlias: Record<string, string> = {
     repoRoot,
     'packages/stack/src/supabase/index.ts',
   ),
+  // Bare entry LAST: it is a prefix of every subpath above, and Vite matches in
+  // order, so the subpaths must win first. Both sibling tsconfigs map bare
+  // `@cipherstash/stack` → `src/index.ts`; without the runtime match here a
+  // consumer importing the bare specifier would fall through to
+  // `packages/stack/dist`, re-coupling `pnpm test` to a prior `pnpm build`.
+  '@cipherstash/stack': resolve(repoRoot, 'packages/stack/src/index.ts'),
 }