feat(skills): stash-zerokms and stash-auth — canonical keyset and authentication skills - #834
Conversation
🦋 Changeset detectedLatest commit: 0325015 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Warning Review limit reached
Next review available in: 5 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThe PR adds canonical authentication and ZeroKMS skills, updates EQL v3 Stack contracts and documentation, corrects Prisma Next migration and adapter guidance, and distributes the new skills through CLI and wizard installation flows. ChangesStack contracts and authentication
Canonical authentication and ZeroKMS skills
Skill distribution through integration tooling
Prisma Next migration and adapter guidance
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.changeset/stash-auth-skill.md:
- Around line 22-25: Update the lock-context description in the changeset to
match the corrected model: describe it as governing claim-bound retrieval of a
value’s data key, not selecting which encryption key the value uses. Preserve
the distinction between auth strategy identity and lock-context behavior, using
skills/stash-auth/SKILL.md and packages/stack/src/wasm-inline.ts as the
authoritative wording.
In @.changeset/stash-zerokms-skill.md:
- Around line 15-17: Qualify the revocation description to state that it blocks
future access or seed issuance without re-encryption, rather than claiming
immediate and complete revocation of already-derived keys or plaintext. Apply
this wording to the hierarchy explanation in .changeset/stash-zerokms-skill.md
(lines 15-17) and the corresponding explanation in skills/stash-zerokms/SKILL.md
(lines 79-82).
In `@packages/stack/src/types.ts`:
- Around line 135-138: The client documentation is inconsistent about its
default keyset and multi-keyset behavior. In packages/stack/src/types.ts lines
135-138, qualify the one-client-per-tenant guidance so it applies to
encrypt/query or keyset-less operations; in skills/stash-zerokms/SKILL.md lines
178-193, describe the client as having one default keyset while explicitly
preserving decryption across granted keysets.
In `@skills/stash-auth/SKILL.md`:
- Line 161: Update every copied npx command in SKILL.md, including the command
near NOT_AUTHENTICATED and the locations around the other referenced sections,
to invoke stash with the repository-supported pinned version instead of
resolving the mutable package. Keep the surrounding authentication and
credential-operation instructions unchanged.
In `@skills/stash-deployment/SKILL.md`:
- Around line 58-70: Add an explicit text/plaintext language tag to the fenced
blocks containing the deployment diagram and error output in the documentation,
including the second block around the additional referenced section. Leave the
block contents unchanged.
- Around line 299-308: Update the executable production database migration
examples to avoid mutable latest CLI resolution: replace the unversioned `npx
`@prisma/cli`` and `npx prisma-next` invocations with exact-version commands or
the repository’s pinned pnpm invocations, while preserving the existing
connection creation, migration update, and removal sequence.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d56f719d-39be-485e-a328-ff0401890a54
📒 Files selected for processing (18)
.changeset/auth-strategy-jsdoc-unwrap.md.changeset/keyset-default-doc-precision.md.changeset/stash-auth-skill.md.changeset/stash-deployment-skill.md.changeset/stash-zerokms-skill.mdAGENTS.mdpackages/cli/src/commands/init/doctrine/AGENTS-doctrine.mdpackages/cli/src/commands/init/lib/__tests__/install-skills.test.tspackages/cli/src/commands/init/lib/install-skills.tspackages/cli/src/commands/init/lib/setup-prompt.tspackages/stack/src/encryption/index.tspackages/stack/src/types.tspackages/stack/src/wasm-inline.tspackages/wizard/src/__tests__/install-skills.test.tspackages/wizard/src/lib/install-skills.tsskills/stash-auth/SKILL.mdskills/stash-deployment/SKILL.mdskills/stash-zerokms/SKILL.md
freshtonic
left a comment
freshtonic
left a comment
There was a problem hiding this comment.
Approve
Reviewed the full diff at 4379e7a7 (11 commits on docs/stash-deployment-skill). Since skills ship into the stash tarball and get copied into customer repos, I focused on accuracy: I read both new skills and all five corrected ones myself, and fact-checked every code-checkable claim against the actual repo + dependency source. No skill teaches anything the code refutes, wiring/parity is fully correct, and all 14 CI checks pass. This is a careful, well-sourced correction of a previously-wrong customer-facing model.
Verified against the code (clean)
Source doc-fixes. The native authStrategy JSDoc now unwraps create()'s Result (if (strategy.failure) throw …; authStrategy: strategy.data) — matching @cipherstash/auth 0.42.0's Result<Strategy, AuthFailure> return type and the WASM docs. config.keyset and the WasmEncryptionClient lock-context wording are corrected to the client-default-keyset and retrieval-binding models.
Auth-strategy claims (stash-auth). Confirmed against @cipherstash/auth types: the Result trap, all eight enumerated AuthFailure codes exist (no fictional code), auto selecting the access-key arm on access-key presence so access-key-set + CRN-missing yields MISSING_WORKSPACE_CRN, and the WASM entry's authStrategy/accessKey mutual exclusion — enforced both at the type level (?: never) and at runtime (throws).
prisma-next catalog (stash-prisma-next). The headline #756 fix — the full 31-constructor catalog — is exact against packages/prisma-next/src/v3/catalog.ts: 41 eql_v3_* domains minus the 10 *_ord_ore variants the adapter deliberately doesn't expose = 31 constructors, every name matching (including the IntegerOrd=number vs BigIntOrd=bigint distinction that the integer-cents trap turned on). defineConfig genuinely comes from @prisma-next/cli/config-types (no bare prisma-next package exists), and extensionPacks (CLI config) vs extensions (postgres() runtime) are each used correctly.
--prisma retirement. Registry summary, flag description, the migrationPrismaUnavailable message, and the init next-steps are all updated consistently to "not needed → run prisma-next migrate" with no leftover "#690"/"soon"; the command still fails cleanly via CliExit(1). schema.prisma comment renames match the real constructor names.
Skill consistency + wiring. stash-edge honestly names the old "credential-identity rule" as wrong and rewrites it (anchor link updated to match the new heading); all five corrected sites replace "index terms derive from the client key / decrypt-but-never-match" with the per-keyset model and defer to the canonical skills. Both new skills carry valid frontmatter with name: matching the directory, no Linear IDs. SKILL_MAPs are order-identical across CLI + wizard (guarded by an order-sensitive parity test), and BASE_SKILLS / SKILL_PURPOSES / both test suites / AGENTS.md list + check table / the doctrine are all updated in lockstep. Changesets are accurate and appropriately scoped (two stash minor for the new skills, @cipherstash/stack patch for the doc-fixes).
Scope note on the cryptographic model
The ZeroKMS server-side claims — the four-level key hierarchy, proxy re-encryption, per-keyset (not per-client) index-term derivation, and the retrieval-binding lock-context mechanism — live in the ZeroKMS server + native client, not this repo, so I couldn't independently re-derive them here. What I could check is consistent: the FFI types corroborate that encrypt/query use the client's bound keyset (no per-operation keyset on EncryptOptions/EncryptQueryOptions), and nothing in the repo contradicts the decrypt-follows-payload split. These claims rest on the PR's stated verification against the ZeroKMS server implementation and whitepaper. Two things lower the risk: the lock-context correction is observationally equivalent (decrypt requires the same context under either description), and the keyset correction moves the diagnostic in the safer fail-loud direction (a keyset mismatch surfaces as total failure, not a silent search miss).
Non-blocking
- Stale internal comments. Two JSDoc comments still say the Prisma emitter is "not yet available (#690)", now contradicting the shipped "not needed" message:
packages/cli/src/commands/eql/migration.ts:61and the doc block atpackages/cli/src/messages.ts:75-78. Internal only — not user-facing, not in any skill — but worth sweeping since the rest of that surface was updated. - The
messages.tsconstant is still namedmigrationPrismaUnavailablethough the message now says "not needed" rather than "unavailable" — a slightly misleading internal name.
Excellent, rigorous work — correcting a wrong model that had already propagated across five shipped skills, with the replacement checked against the server implementation and the client libraries, is exactly the right treatment for artifacts that land in customers' repos. LGTM.
…skill Install it for every integration (both SKILL_MAPs + BASE_SKILLS). The skill is the single source of truth for the ZeroKMS access model: the four-level key hierarchy, keysets scoping every encrypt/decrypt/query, clients and grants, the workspace vs client default keyset distinction, per-payload decrypt routing, failure surfaces, and a diagnostic runbook. Also corrects the config.keyset doc comments in @cipherstash/stack: omitting the option resolves to the client's default keyset (the keyset the client was created against), not the workspace default per se. Refs #832 (per-operation keysets, filed while verifying the FFI surface).
The service-token model (all CipherStash requests carry a CTS-minted JWT; the token's services claim names the regional ZeroKMS endpoint), the three separable auth concerns, the @cipherstash/auth strategies and the create()-returns-Result trap, credential discovery vs the WASM entry's explicit config, the four CS_* variables and stash env, client lifetime with user-scoped strategies, lock context and its deprecations, and the never-read-~/.cipherstash rule. Installed for every integration. stash-zerokms gains the companion section: ZeroKMS accepts only CTS service tokens, runs in multiple regions, and its endpoint is determined by CTS — bulk deferred to stash-auth. Also fixes the native entry's authStrategy JSDoc examples, which passed create()'s Result straight into config.authStrategy — the exact mistake #794 calls out. They now unwrap, matching the wasm-inline docs and the integration tests. Closes #794.
…nline lock-context wording stash-zerokms now covers the device client: stash auth login generates a device identity, provisions a client on the workspace default keyset (one per device per workspace), and persists a standard client key to the profile's secretkey.json — same key, different encapsulation than the hex CS_CLIENT_KEY form. Profile files stay CLI-only. stash-auth now states the OIDC federation prerequisite: the JWT's issuer must be registered with the workspace (Clerk, Supabase, Auth0, or Okta, via the dashboard's OIDC providers page); an unregistered issuer fails with 'No OIDC provider found for issuer'. Multiple providers per workspace, subject to billing/plan. The WasmEncryptionClient doc comment said a lock context decides 'which key the value is encrypted under' — key material is identical either way; the binding gates retrieval of the data key by the claim in the caller's service token. Reworded to match stash-auth's canonical model.
… regions CipherStash runs in multiple regions and the set is subject to change — stash-auth now carries the current seven (matching the CLI's picker) plus the instruction to retrieve the live list with `stash auth regions` (--json for machines), deferring command details to stash-cli. stash-zerokms points at both.
…ound The token exchange section now frames the services claim as a built-in service-discovery mechanism the user never configures, with the one fact that matters surfaced: a CipherStash-issued service token is only valid for services in the region it was issued for.
The shared-client hazard isn't 'whoever arrived first' — the strategy caches one federated CTS token and returns it until expiry (getJwt is not consulted while the cache is warm; pinned by test_caches_token_after_initial_federation), so a shared client rides whichever user's token is currently cached, flipping identity at each re-federation. States the design fact (the strategy is one-user-scoped) and the mitigation (one client per request/user).
…non-retroactivity, keyset-binding qualifier - The stash-auth changeset still carried the pre-correction 'which key a value is encrypted under' framing; now states the retrieval-binding model. - Revocation claims bounded: blocks all future key operations immediately and without re-encryption, but is not retroactive — with the per-value granularity point that the blast radius is exactly what the revoked client already accessed. - types.ts keyset JSDoc: 'bound to one keyset for its lifetime' qualified — encrypt/query always use it, decrypt follows each payload's own keyset subject to grants — matching the skill.
…, defer to canonical sources The 'credential-identity rule' (index terms derive from the client key; mismatched credentials decrypt but silently never match a query) was wrong in stash-edge (the canonical section), stash-cli (backfill precondition + stash env warning), stash-postgres, and stash-supabase. All now state the keyset model — per-keyset index key, loud total failure without a grant — and defer to stash-zerokms / stash-auth. stash-encryption's edge note claimed identity-bound encryption is 'configured via config.authStrategy' (the #794 conflation); it now states the lock-context gap (#797) and the retrieval-binding model, and its auth, lock-context, and keysets sections point at the canonical skills. stash-prisma-next's auth section points at stash-auth. stash-edge keeps a short retrospective naming the old wrong rule so agents who saw it in older copies aren't left guessing.
…mport, bundling claim, stale constructor names Line-by-line verification against @cipherstash/prisma-next confirmed the skill's constructors, domain table, operator surface, rawSql shape, EQL v3 function names (checked against the pinned @cipherstash/eql 3.0.2 bundle), and CLI commands are all current. Two real errors fixed: - defineConfig comes from @prisma-next/cli/config-types, not a nonexistent 'prisma-next' package (verified against examples/prisma). - The bundling section pointed edge runtimes at wasm-inline; the adapter is native-only, so it now says that instead of sending agents down a dead end. Adds the column-types subpath (TS-authored contracts) to the exports table. Drive-bys surfaced by the same review: stash init --prisma-next's next steps still said cipherstash.Encrypted*() (pre-rename constructor names), and the example schema's header comment did too.
Prisma Next installs the EQL bundle through its own migration framework (the extension pack's migrations/cipherstash/ contract space), so the promised Prisma emitter (#690, closed) is not coming and was never needed. The registry copy, code comment, error message, and stash-cli skill now state the mechanism and route to prisma-next migrate.
…og (#756) The column-type table was a six-row sample presented as the catalog — IntegerOrd wasn't mentioned once, and the missing plaintext-type column is exactly what distinguishes IntegerOrd (number) from BigIntOrd (bigint) in the integer-cents case #756 reports. The table is now the complete exposed surface (plaintext type x capability tier), derived from DOMAIN_REGISTRY, with the capability semantics spelled out (*Ord includes equality; TextMatch is free-text only; *OrdOre deliberately unexposed) and the envelope pairing restated per family. Of #756's other two points against rc.4: 'migration apply' was already fixed on main (#765), and the extensionPacks-vs-extensions claim does not hold at @prisma-next/cli 0.16.0 — extensionPacks is the CLI config field (types-DnpnkEgM.d.mts) and extensions is the postgres() runtime option; the skill uses both correctly. Closes #756.
4379e7a to
33d2958
Compare
…tionPrismaUnavailable The --prisma path now reports 'not needed' (Prisma Next installs EQL through its own migration framework), but two internal JSDoc blocks still described the emitter as a pending follow-up, and the messages.ts constant was still named migrationPrismaUnavailable. Comments now describe the routing behaviour; the constant is migrationPrismaNotNeeded. Internal only — no user-facing change.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/cli/src/messages.ts (1)
82-82: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winKeep Prisma Next migration comments synchronized with the new routing contract.
The implementation now routes Prisma Next through its own migration framework, but nearby comments still describe obsolete or inconsistent commands.
packages/cli/src/messages.ts#L82-L82: Replace the “emitter isn't built yet” comment with the current “emitter not needed; route to Prisma Next migrations” behavior.packages/cli/src/commands/init/providers/prisma-next.ts#L17-L17: Updatemigration plan|applyto match the emittedmigration plan && migrateguidance, or verify and use the canonical command in both places.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/cli/src/messages.ts` at line 82, Synchronize Prisma Next migration guidance across packages/cli/src/messages.ts at line 82 and packages/cli/src/commands/init/providers/prisma-next.ts at line 17: replace the obsolete “emitter isn't built yet” explanation with the behavior that the emitter is unnecessary and migrations route through Prisma Next, and make both comments use the canonical “migration plan && migrate” command guidance consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@skills/stash-cli/SKILL.md`:
- Line 443: Update the keyset precondition documentation to state that backfill
may use native auto-authentication and fall back to the local development
profile when access-key environment variables are absent. Refer to the
credentials as “resolved credentials,” and separately recommend explicitly
exporting the target environment’s CS_* variables for CI and production.
In `@skills/stash-postgres/SKILL.md`:
- Around line 410-416: Update the same-keyset requirement in the paragraph
beginning “Every writer and reader” to apply specifically to every writer and
query reader, or explicitly scope it to encrypted search. Preserve the existing
keyset behavior and guidance for decrypt operations.
In `@skills/stash-zerokms/SKILL.md`:
- Around line 43-61: Update the canonical keyset guidance around config.keyset
to distinguish inaccessible or disabled keysets, which fail loudly, from
reachable-but-different query keyspaces, which may return zero rows while
decrypt still succeeds via the payload’s keyset; when omitted, use each client’s
default keyset. Propagate this distinction to
.changeset/stash-zerokms-skill.md:20-26,
.changeset/skills-keyset-auth-wording-pass.md:8-17,
skills/stash-edge/SKILL.md:163-191, skills/stash-supabase/SKILL.md:59-64,
skills/stash-cli/SKILL.md:443 and 488-496, and
skills/stash-postgres/SKILL.md:410-416, preserving the reachable-keyset mismatch
diagnostic and scoping same-keyset requirements to encrypted-search readers.
---
Nitpick comments:
In `@packages/cli/src/messages.ts`:
- Line 82: Synchronize Prisma Next migration guidance across
packages/cli/src/messages.ts at line 82 and
packages/cli/src/commands/init/providers/prisma-next.ts at line 17: replace the
obsolete “emitter isn't built yet” explanation with the behavior that the
emitter is unnecessary and migrations route through Prisma Next, and make both
comments use the canonical “migration plan && migrate” command guidance
consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ebb512a2-0e3d-49a9-8025-04c7a7b30773
📒 Files selected for processing (30)
.changeset/auth-strategy-jsdoc-unwrap.md.changeset/eql-migration-prisma-not-needed.md.changeset/keyset-default-doc-precision.md.changeset/prisma-next-skill-accuracy.md.changeset/skills-keyset-auth-wording-pass.md.changeset/stash-auth-skill.md.changeset/stash-zerokms-skill.mdAGENTS.mdexamples/prisma/prisma/schema.prismapackages/cli/src/cli/registry.tspackages/cli/src/commands/eql/migration.tspackages/cli/src/commands/init/doctrine/AGENTS-doctrine.mdpackages/cli/src/commands/init/lib/__tests__/install-skills.test.tspackages/cli/src/commands/init/lib/install-skills.tspackages/cli/src/commands/init/lib/setup-prompt.tspackages/cli/src/commands/init/providers/prisma-next.tspackages/cli/src/messages.tspackages/stack/src/encryption/index.tspackages/stack/src/types.tspackages/stack/src/wasm-inline.tspackages/wizard/src/__tests__/install-skills.test.tspackages/wizard/src/lib/install-skills.tsskills/stash-auth/SKILL.mdskills/stash-cli/SKILL.mdskills/stash-edge/SKILL.mdskills/stash-encryption/SKILL.mdskills/stash-postgres/SKILL.mdskills/stash-prisma-next/SKILL.mdskills/stash-supabase/SKILL.mdskills/stash-zerokms/SKILL.md
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/cli/src/commands/init/doctrine/AGENTS-doctrine.md
- packages/wizard/src/tests/install-skills.test.ts
- packages/stack/src/wasm-inline.ts
- AGENTS.md
…und keyset, decrypt follows the payload's Corrects the claim (made canonical yesterday in stash-zerokms and echoed in stash-edge, stash-supabase, stash-cli, stash-postgres, stash-deployment and two changesets) that a keyset mismatch always fails loudly and that 'decrypt works but search returns zero rows' can never be key-related. Per the runtime contract (packages/stack/src/types.ts): a client is bound to one keyset — encrypt and encryptQuery always use it — while decrypt follows each payload's keyset, subject to grants. So one silent case exists: a reader granted the writer's keyset but bound to a different one decrypts fine while its query terms derive under its own keyspace and return zero rows with no error. All sites now distinguish unreachable keysets (loud) from reachable-but-different bound keysets (silent search miss), scope the same-keyset rule to writers and query readers, and put the bound-keyset check first in the zero-rows diagnostic. Also documents the backfill credential resolution order in stash-cli: CS_* variables when present, else the ~/.cipherstash profile via native auto auth (CodeRabbit's third finding). Addresses CodeRabbit review on #834.
2 participants
Adds two new agent skills —
stash-zerokmsandstash-auth— as the canonical sources for the ZeroKMS access model and the authentication model, installed for every integration, plus a verified accuracy pass over the existing skills. Closes #794. Closes #756.stash-zerokms— keysets, clients, and key managementThe keyset/client model had no canonical home, and several shipped skills describe it incorrectly (the "credential-identity rule" — index terms deriving from the client key so mismatched credentials "decrypt but silently miss queries"). This skill is the verified model, checked against the ZeroKMS server implementation and the whitepaper:
stash auth loginprovisions (a standard client key, differently encapsulated in the profile), per-payload decrypt routing, the disabled-keyset kill-switch, the ZeroKMS management API with scopes, failure surfaces, and a diagnostic runbook separating the keyset gate from the lock-context gate.The skill sites that carried the wrong model are corrected in this PR:
stash-edge's "Credential-Identity Rule" section (the canonical wrong one — replaced with the keyset model plus a short retrospective naming the old rule), the backfill precondition andstash envwarning instash-cli, the writer/reader notes instash-postgresandstash-supabase, andstash-encryption's claim that edge identity-binding is "configured viaconfig.authStrategy" (the #794 evidence item — the edge entry simply lacks lock context, #797). Each now states the keyset / retrieval-binding model and defers tostash-zerokms/stash-authas canonical. Covered by its ownstashpatch changeset.stash-auth— credentials, auth strategies, and lock context (#794)stash auth regionsas the live source.@cipherstash/authstrategies, including:auto's requirement of bothCS_CLIENT_ACCESS_KEYandCS_WORKSPACE_CRN(missing CRN with the key set failsMISSING_WORKSPACE_CRNrather than silently falling back to the profile), the Result trap (create()returnsResult<Strategy, AuthFailure>— unwrap beforeconfig.authStrategy), theAuthFailurecodes, and the OIDC federation prerequisite (the JWT's issuer must be registered with the workspace; Clerk, Supabase, Auth0, Okta; multiple providers per workspace subject to plan).authStrategy+accessKeyenforced on the WASM entry), the fourCS_*variables andstash env, and the client-lifetime hazard stated mechanically: the strategy caches one federated CTS token, so a shared client rides whichever user's token is cached — one client per request/user.~/.cipherstash, and a note that Proxy authentication is a different path (dedicated skill to come).Accompanying source fixes (
@cipherstash/stack, patch)config.keysetdoc comments: omitting the option resolves to the client's default keyset (the keyset the client was created against), not "the workspace's default keyset" per se.authStrategyJSDoc examples passedcreate()'sResultstraight intoconfig.authStrategy— the exact mistake Add a stash-auth skill covering credentials, auth strategies, and lock context #794 calls out; they now unwrap, matching the wasm-inline docs and integration tests.WasmEncryptionClientdoc comment's lock-context wording corrected to the retrieval-binding model.stash-prisma-nextverified against main (#756)The skill was verified line-by-line against
@cipherstash/prisma-nexton main (constructors, domains, operator surface,rawSqlshape, EQL function names against the pinned@cipherstash/eql3.0.2 bundle, CLI commands). Fixes, targeting the forthcoming release:IntegerOrd(number) fromBigIntOrd(bigint) and preventsstash-prisma-next: column-type table lists 6 of ~30 constructors, plus two wrong API names #756's integer-cents trap. Capability semantics stated (*Ordincludes equality;TextMatchis free-text only;*OrdOredeliberately unexposed).defineConfigimport corrected to@prisma-next/cli/config-types(noprisma-nextpackage exists).wasm-inline— the adapter is native-only.stash init --prisma-nextnext-steps no longer name the pre-renamecipherstash.Encrypted*()constructors;stash eql migration --prismanow says "not needed — prisma-next installs EQL through its own migrations" instead of "coming soon (stash eql migration: migration-first, ORM-agnostic EQL v3 install (fixes prisma-next superuser-on-Supabase) #690)".On #756's other two points:
migration applywas already fixed on main (#765), and theextensionPacks:→extensions:claim doesn't hold at@prisma-next/cli0.16.0 —extensionPacksis the CLI config field,extensionsis thepostgres()runtime option; the skill uses both correctly.Wiring
Both
SKILL_MAPs (CLI + wizard, order-identical for the parity test),BASE_SKILLS,SKILL_PURPOSES, the AGENTS doctrine,AGENTS.md(skills list + two new canonical-source rows in the check table), and the test expectation lists. Changesets:stashminor ×2,@cipherstash/wizardpatch ×2,@cipherstash/stackpatch ×2.Verification
skill-map-paritye2e: passed. Biome: no errors on touched files (pre-existing warnings only).@cipherstash/stackbuilds (DTS regenerates).cipherstash-client0.42.0 and@cipherstash/auth0.42.0,protect-ffi0.31.0, the CTS authorize endpoint, andstack-auth's strategy/refresher sources (including the token-caching tests behind the client-lifetime section).Related: #832 (per-operation keysets, filed from this investigation).
Summary by CodeRabbit
Summary by CodeRabbit
New Features
stash initand integration setup now include authentication, deployment, and ZeroKMS skills.Enhancements
Documentation