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 columnBigIntOrd — 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).
Three defects in the shipped
stash-prisma-nextskill, all found the same way during an integration eval againststash@1.0.0-rc.4/ EQL v3 3.0.2: an agent followed the skill, hit a wall, and recovered by readingnode_modulestype 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: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.IntegerOrdis 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
Decimalscalar was unusable, so the column is anInt). The correct domain isIntegerOrd/eql_v3_integer_ord, whose plaintext type is JSnumber. Of the six types the skill does list, the only numeric options are:DoubleOrd— float semantics for an exact-cents columnBigIntOrd— plaintext type is JSbigint, so it rejects the app'snumbervaluesBoth agents on that surface had to open
@cipherstash/prisma-next/dist/column-types.d.tsto find the right type. That file derives its catalog fromDOMAIN_REGISTRYat 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 distinguishesIntegerOrdfromBigIntOrd, and it is absent from the current table entirely.2.
extensionPacks:should beextensions:The wiring section shows:
@prisma-next/postgres/confignames the fieldextensions:. Found by readingconfig.d.mts.3.
prisma-next migration applydoes not existFiled with fuller detail alongside the indexing issue, repeating here since it is the same skill: the skill prescribes
npx prisma-next migration applytwice, including the flat assertion "EQL installs viaprisma-next migration apply, neverstash eql install", and rc.4's owninit --prisma-nexthelp text repeats it.The CLI has a
migrationgroup (plan,new,show,status,log,list,graph,check) and a separate top-levelmigrate. There is noapplysubcommand. 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, andprisma-next --help. The same round turned up a fourth of the same shape instash-encryption(the claim that managed installs "disable the_ord_oredomains" — 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).