stash-prisma-next: column-type table lists 6 of ~30 constructors, plus two wrong API names #756

Three defects in the shipped stash-prisma-next skill, all found the same way during an integration eval against stash@1.0.0-rc.4 / EQL v3 3.0.2: an agent followed the skill, hit a wall, and recovered by reading node_modules type declarations. Grouping them because they share a root cause — hand-written prose that has drifted from a machine-readable source sitting right next to it.

1. The column-type table is a sample presented as a catalog

The table under "Declare encrypted columns in schema.prisma" lists six types:

TextSearch()   DoubleOrd()   BigIntOrd()   DateOrd()   Boolean()   Json()

There is no "…and the rest" caveat and no pointer to the full list. But EQL v3 installs 52 public.eql_v3_* storage domains (10 type families × capability suffixes), and the adapter exposes a constructor per usable domain.

IntegerOrd is not mentioned once — grep -c IntegerOrd SKILL.md → 0.

That is the specific gap that bit. The app under test stores money as integer cents (its ORM's Decimal scalar was unusable, so the column is an Int). The correct domain is IntegerOrd / eql_v3_integer_ord, whose plaintext type is JS number. Of the six types the skill does list, the only numeric options are:

• DoubleOrd — float semantics for an exact-cents column
• BigIntOrd — plaintext type is JS bigint, so it rejects the app's number values

Both agents on that surface had to open @cipherstash/prisma-next/dist/column-types.d.ts to find the right type. That file derives its catalog from DOMAIN_REGISTRY at runtime — so the complete list already exists in machine-readable form and the doc simply isn't using it.

Suggested fix: generate the table from the registry, with each row carrying the constructor, its public.eql_v3_* domain, its plaintext TypeScript type, and its query capabilities. The plaintext-type column is the one that would have prevented this — it is what distinguishes IntegerOrd from BigIntOrd, and it is absent from the current table entirely.

2. extensionPacks: should be extensions:

The wiring section shows:

export default defineConfig({
  extensionPacks: [cipherstash],
})

@prisma-next/postgres/config names the field extensions:. Found by reading config.d.mts.

3. prisma-next migration apply does not exist

Filed with fuller detail alongside the indexing issue, repeating here since it is the same skill: the skill prescribes npx prisma-next migration apply twice, including the flat assertion "EQL installs via prisma-next migration apply, never stash eql install", and rc.4's own init --prisma-next help text repeats it.

The CLI has a migration group (plan, new, show, status, log, list, graph, check) and a separate top-level migrate. There is no apply subcommand. Confirmed at Prisma Next 0.14.0 and 0.16.0.

Why these three together

Each is prose that contradicts a machine-readable source shipped in the same package: the domain registry, config.d.mts, and prisma-next --help. The same round turned up a fourth of the same shape in stash-encryption (the claim that managed installs "disable the _ord_ore domains" — they are not disabled; only the btree opclass is skipped).

Generating these fragments rather than hand-maintaining them would close all of them at once, and would keep them closed.

Related: #753 (indexing skill), #754 (edge / raw-SQL skill).