The stash-encryption skill states, in the Ord vs OrdOre callout:
the ORE domains are backed by an ORE operator class whose installation requires superuser — unavailable on managed Postgres (including Supabase), where the install bundle skips the ORE opclass and disables the _ord_ore domains it cannot support.
The first half is correct. The second half is not: the domains are not disabled. Only the custom btree operator class is skipped.
Verified
Local Supabase as postgres (rolsuper = f), EQL v3 3.0.2:
ord_ore domains present : 9 -- all public.eql_v3_*_ord_ore exist
eql opclasses present : 0 -- pg_opclass has no eql_v% entries
ore_block_256 operators : 6 -- comparison operators intact
usable as column type : true -- CREATE TABLE ... (v public.eql_v3_numeric_ord_ore) succeeds
The guarded DO block skips the CREATE OPERATOR CLASS on insufficient_privilege (42501) and moves on; nothing drops or disables the domains themselves.
So what is missing on a managed role is index support, not the type. An _ord_ore column can be declared and written there — its ordering just will not be index-backed.
Why it matters beyond wording
The inaccuracy propagated into an implementer's code during an rc.4 integration eval: the agent read the skill, concluded the domains were unavailable on Supabase, and encoded that assumption in its schema comments. It also reached our own assessment rubric, where it had been scoring runs against an expectation the product does not meet — fixed on our side in cipherstash/skilltester#30.
"Disabled" and "not indexable" lead to different designs. A developer who believes the domain is unavailable will pick a different column type; one who knows it is available-but-unindexed can make an informed trade.
Suggested wording
the ORE operator class requires superuser and is skipped on managed Postgres (including Supabase). The _ord_ore domains remain available and usable as column types — what you lose is index-backed ordering, since the opclass that would support it is absent. Prefer Ord (OPE-backed) on managed Postgres, which indexes on any role.
Found in the 2026-07-22 rc.4 eval. Same shape as #756 — prose that has drifted from what the installer actually does. Related: #753, #754, #756, #757.
The
stash-encryptionskill states, in theOrdvsOrdOrecallout:The first half is correct. The second half is not: the domains are not disabled. Only the custom btree operator class is skipped.
Verified
Local Supabase as
postgres(rolsuper = f), EQL v3 3.0.2:The guarded
DOblock skips theCREATE OPERATOR CLASSoninsufficient_privilege(42501) and moves on; nothing drops or disables the domains themselves.So what is missing on a managed role is index support, not the type. An
_ord_orecolumn can be declared and written there — its ordering just will not be index-backed.Why it matters beyond wording
The inaccuracy propagated into an implementer's code during an rc.4 integration eval: the agent read the skill, concluded the domains were unavailable on Supabase, and encoded that assumption in its schema comments. It also reached our own assessment rubric, where it had been scoring runs against an expectation the product does not meet — fixed on our side in cipherstash/skilltester#30.
"Disabled" and "not indexable" lead to different designs. A developer who believes the domain is unavailable will pick a different column type; one who knows it is available-but-unindexed can make an informed trade.
Suggested wording
Found in the 2026-07-22 rc.4 eval. Same shape as #756 — prose that has drifted from what the installer actually does. Related: #753, #754, #756, #757.