## Summary The `eql_v3` encrypted-JSONB (SteVec) surface ships a full **hand-written SQL** implementation (`src/v3/jsonb/*.sql`: domains `eql_v3.json`, `eql_v3.ste_vec_entry`, `eql_v3.ste_vec_query`, plus operators/functions/aggregates/blockers), but it has **no generated Rust / TypeScript / JSON-Schema bindings**. Every other v3 payload family has committed Rust bindings from which `ts-rs` derives `.ts` and `schemars` derives JSON Schema, all drift-gated. The SteVec payload is the one v3 family `ts-rs`/`schemars` never touched. ## Evidence - No `JSONB` row in `eql-domains::CATALOG` (`crates/eql-domains/src/lib.rs`). - No `crates/eql-bindings/src/v3/jsonb.rs`; not in `inventory::all()`. - `ScalarKind::Jsonb` / `Fixture::Jsonb` exist only as placeholder enum variants; `ScalarKind::rust_type()` **panics** ("no generated surface yet"). - No `bindings/v3/*` TS or `schema/*.json` for the SteVec payload types. ## Root cause (how it was missed) Deliberate SQL split, **un-tracked bindings consequence**: - **2026-06-02** (`a23d0939`): `ScalarKind::Jsonb`/`Fixture::Jsonb` added as peers of `text` — "planned, no SQL surface yet." - **2026-06-11** (`4e351883`): SteVec SQL landed on a deliberately separate hand-written track ("no codegen, no CATALOG row" — `docs/superpowers/plans/2026-06-09-eql-v3-jsonb-domain.md`). - **2026-06-24→29** (`d4bbc0a6`, `9e4b0292`): the bindings pipeline was built **later** and scoped to `CATALOG`. JSONB, intentionally kept out of `CATALOG`, fell outside its universe. - `text` graduated into the materializer; JSONB was reclassified "out of scope." No follow-up named the SteVec **payload binding** as a deliverable. Critically: the drift gate `crates/eql-bindings/tests/catalog_parity.rs` iterates `CATALOG`, so it **structurally cannot flag** a payload that is not in `CATALOG` — the gate that should have caught this was blind to it by construction. ## Generator target The exact shape once existed in the ported `eql-types` crate — `crates/eql-types/src/v2_3.rs` (dropped in `67493453`): `SteVecPayload` / `SteVecElement` / `SteVecTerm` (untagged `{hm} | {oc}`). It matches the current v3 SQL in `src/v3/jsonb/types.sql`. ## Proposed approach Make JSONB a first-class `DomainFamily` in `CATALOG` (removes the blind-spot root cause) with a `Shape` discriminant that dispatches to a **dedicated SteVec bindings emitter** — the flat scalar path stays untouched; `Term` semantics are not distorted. SQL stays hand-written (shape-gated skip in the SQL generator). Design spec: `docs/superpowers/specs/2026-07-01-jsonb-domain-bindings-design.md` ## Scope - `Shape` enum + `Domain.shape` in `eql-domains`; `JSONB` family + `CATALOG` append; retire `rust_type` panic; `JSONB_FIXTURES`. - `OreCllw` + `Selector` term newtypes; documented untagged-term caveat in `mod.rs`. - Dedicated SteVec emitter in `eql-codegen` → `crates/eql-bindings/src/v3/jsonb.rs`; `inventory.rs` includes JSONB domain types. - Shape-gated SQL-gen skip; shape-aware `catalog_parity.rs`; committed `bindings/v3/*.ts` + `schema/*.json`; conformance test against real fixtures. Out of scope: generating JSONB **SQL** (stays hand-written), the `k`-tagged `EqlEncrypted` composite, JSONB in the scalar all-pairs matrix.