fix(eql): name stack-encrypt 0.2.0 and verify the feature from the packaged crate

The `stack-encrypt` feature depends on stack-encrypt by path and version.
Every in-tree job builds the path; the published crate resolves the
version from crates.io. The version said 0.1.0, which shipped without
`Describe`, `Description` and `Label` — so the feature compiled here and
could not compile for any consumer, or for docs.rs, which enables it.
Nothing noticed, because `cargo publish` verifies the default feature set
and this feature is off by default: the dry run in CI passed, and
release-plz would have published it.

Three changes close that. The requirement names 0.2.0, the version the
descriptor rework releases as (ad62087 on the base branch; cargo refuses
a requirement the in-tree path dependency does not satisfy, so the bump
had to land there first). The dry-run step and release-plz both pass
`--all-features`, so the verify builds the feature from the PACKAGED
manifest, where there is no path and stack-encrypt comes from the registry
— the build a consumer gets. And `release-plz.yml`'s eql-bindings job now
runs after the stack-* crates job: on a push that releases both, the crate
eql-bindings resolves exists by the time it looks.

The dry-run step is red until stack-encrypt 0.2.0 is on crates.io. That is
the true state of this branch, and it clears when #1050 merges and the
crates publish.

Found by the Codex review of #971 (the path dependency hid a registry
mismatch). Refs #1049.

Author: coderdan

.github/workflows/release-plz.yml

@@ -2,8 +2,9 @@ name: "Release crates (crates.io)"
 
 # Publishes two crates.io release lines via release-plz (crates.io Trusted
 # Publishing over OIDC — no CARGO_REGISTRY_TOKEN): `eql-bindings` from
-# packages/eql (`release`), and `stack-auth` + `stack-profile` from the root
-# workspace (`release-crates`, described above its own jobs at the end).
+# packages/eql (`release`), and the stack-* crates from the root workspace
+# (`release-crates`, described above its own jobs at the end). `release` runs
+# after `release-crates`: see the comment on its `needs:`.
 # Everything from here to `permissions:` is about the EQL line.
 #
 # THE FILENAME CANNOT CHANGE: crates.io binds the publisher to it.
@@ -85,8 +86,20 @@ jobs:
 
   release:
     name: "Release"
-    needs: [eql-armed]
-    if: needs.eql-armed.outputs.armed == 'true'
+    # AFTER `release-crates`, not beside it. eql-bindings' `stack-encrypt`
+    # feature names a stack-encrypt VERSION, and `cargo publish` resolves it
+    # from crates.io, so on a push that releases both, publishing in parallel
+    # races this job's resolution against the other job's upload. Ordered,
+    # the stack-* crates land first and this job's verify finds them.
+    # `always()` because `release-crates` is skipped on every push that moves
+    # no stack-* crate, and a skipped dependency would otherwise skip this job
+    # too; its FAILURE still stops this one, since the crates it needed did
+    # not publish.
+    needs: [eql-armed, release-crates]
+    if: >-
+      always()
+      && needs.eql-armed.outputs.armed == 'true'
+      && (needs.release-crates.result == 'success' || needs.release-crates.result == 'skipped')
     # GitHub-hosted, matching this repo's other publishing jobs.
     runs-on: ubuntu-latest
     timeout-minutes: 30

.github/workflows/test-eql.yml

@@ -604,9 +604,21 @@ jobs:
       # a real path dependency without a version — on the PR rather than at
       # release time. No token needed. `--allow-dirty` tolerates any files the
       # preceding regenerate-and-diff steps leave in the working tree.
+      #
+      # `--all-features`: the verify step compiles the DEFAULT feature set
+      # unless told otherwise, and the `stack-encrypt` feature is off by
+      # default — so this step passed while that feature did not build against
+      # the crates.io stack-encrypt the manifest names. Every other job here
+      # compiles stack-encrypt by PATH, from the tree, and cannot notice; the
+      # packaged manifest has no `path`, so this verify resolves stack-encrypt
+      # from the REGISTRY, which is the build a consumer and docs.rs get.
+      # release-plz does the same at publish time (`publish_all_features` in
+      # packages/eql/release-plz.toml). The step is RED while the stack-encrypt
+      # version eql-bindings names is not yet on crates.io: that is the true
+      # state of the tree, and it clears when that crate ships.
       - name: Verify eql-bindings packages cleanly for crates.io
         run: |
-          cargo publish -p eql-bindings --dry-run --allow-dirty
+          cargo publish -p eql-bindings --dry-run --allow-dirty --all-features
 
   codegen:
     name: "Encrypted-domain codegen"

AGENTS.md

@@ -504,6 +504,27 @@ monorepo, which is where the silent failures are.
   changes what the whole EQL CI surface compiles against, and with the skip in
   place the release-stopper is closed without it. If wanted, the pin belongs
   upstream and arrives by subtree pull.
+- **`eql-bindings`' `stack-encrypt` feature names a stack-encrypt VERSION, and
+  the published crate is built against that version, not the tree.** The
+  dependency is `path` + `version`: the path is what every in-tree job
+  compiles, the version is what crates.io resolves once `cargo publish` strips
+  the path. The two agree only if the stack-encrypt on crates.io at that
+  version has the API `src/encryption.rs` uses — and nothing in a path build
+  can tell. stack-encrypt 0.1.0 shipped without `Describe`, and the feature
+  would have published against it while every test passed. Two guards compile
+  the feature FROM THE PACKAGED CRATE against the registry: `cargo publish
+  --dry-run --all-features` in `test-eql.yml`'s `rust-crates` job, and
+  `publish_all_features = true` in `packages/eql/release-plz.toml`. Without
+  `--all-features` both verify the default feature set, which is the feature
+  off. Consequences: the stack-encrypt a bump of that requirement names must
+  reach crates.io before eql-bindings does (the root release-plz line is
+  publish-only — a stack-* version moves by a hand-edited `Cargo.toml`, and
+  cargo refuses a requirement the in-tree path dependency does not satisfy, so
+  the bump lands in the stack-encrypt PR first); the dry-run step is RED on a
+  PR that names an unpublished stack-encrypt, correctly, until it ships; and
+  `release-plz.yml`'s `release` job runs after `release-crates` so that on a
+  push releasing both, the crate eql-bindings resolves exists by the time it
+  looks.
 - **`eql-bindings` resolves by path from `languages/typescript/packages/protect-ffi`, never from
   crates.io**, and `scripts/lint-no-eql-registry-pins.mjs` (`pnpm run
   lint:eql-pins`) is what keeps it that way. The two halves of EQL are the Rust

docs/plans/2026-09-12-eql-stack-encrypt-derives.md

@@ -41,9 +41,12 @@ Validation completed:
 - Root workflow wiring guards pass. Encryption integration dependencies live in
   the separate `eql-encryption-tests` crate, preserving lean default tests.
 
-Release prerequisites remain: publish the suite crates, regenerate both EQL and
-FFI lockfiles against registry dependencies, run the clean-package verification,
-and perform live ZeroKMS authorization checks. Local tests use real cryptography
+Release prerequisites remain: publish `stack-encrypt` 0.2.0 (the version the
+feature names; 0.1.0 shipped without `Describe`, and the packaged-crate
+verification below is red until 0.2.0 is on crates.io), and perform live
+ZeroKMS authorization checks. The clean-package verification is now in CI:
+`cargo publish --dry-run --all-features` on every PR, and `publish_all_features`
+in release-plz at publish time. Local tests use real cryptography
 with the suite's test key source, which cannot establish authorization behavior.
 No existing-column or mixed JS/Rust producer compatibility is claimed.
 
@@ -347,8 +350,10 @@ See Cargo's [dependency publication rules](https://doc.rust-lang.org/cargo/refer
 Coordinate suite publication prerequisites first, then the EQL release using
 this repository's existing lockstep process. The existing EQL CI job already
 runs `cargo publish -p eql-bindings --dry-run --allow-dirty`; preserve that gate
-and also verify the new feature from the packaged artifact. Do not alter release
-arming/trusted-publishing configuration as part of adding derives.
+and also verify the new feature from the packaged artifact (done: the step and
+the release-plz publish both pass `--all-features`, which is what makes the
+verify compile the feature against the registry `stack-encrypt`). Do not alter
+release arming/trusted-publishing configuration as part of adding derives.
 
 Add rustdoc/examples, a compatibility/profile note, and a root
 `.changeset/` entry for `@cipherstash/eql` (minor if additive; reassess if phase 1

packages/eql/Cargo.lock

@@ -34,11 +34,20 @@ serde_json = "1"
 ts-rs = { version = "10", features = ["no-serde-warnings"] }
 schemars = "1"
 # stack-encrypt lives in this repository (packages/stack-encrypt). The path
-# builds against it in-tree; the version is what crates.io resolves for the
-# published eql-bindings, so stack-encrypt must be released first.
-stack-encrypt = { path = "../../../stack-encrypt", version = "0.1.0", optional = true, default-features = false }
-# The vitaminc line stack-encrypt is built on: its PRF traits are re-exported
-# through stack-encrypt, and two vitaminc lines in one graph do not interoperate.
+# builds against it in-tree; `version` is what crates.io resolves for the
+# PUBLISHED eql-bindings. So the stack-encrypt this names must be on crates.io
+# before eql-bindings is, and must carry the API `src/encryption.rs` compiles
+# against (`Describe`, `Description`, `Label`, `target::transcode`). 0.1.0 did
+# not: it shipped before they landed, and the path build cannot notice,
+# because it compiles whatever the tree holds. Two guards compile this feature
+# from the PACKAGED crate against the registry stack-encrypt instead:
+# `cargo publish --dry-run --all-features` in test-eql.yml at PR time, and
+# `publish_all_features` in ../../release-plz.toml at release time.
+stack-encrypt = { path = "../../../stack-encrypt", version = "0.2.0", optional = true, default-features = false }
+# The vitaminc line stack-encrypt is built on. `PrfValue` is named from this
+# crate directly (stack-encrypt re-exports only `IntoPrfContext` and
+# `PrfContext`), and two vitaminc lines in one graph do not interoperate, so
+# the requirement is stack-encrypt's.
 vitaminc-prf = { version = "0.5.0", optional = true }
 base64 = { version = "0.22", optional = true }
 hex = { version = "0.4", optional = true }

packages/eql/crates/eql-bindings/Cargo.toml

@@ -176,8 +176,15 @@ column, and record which.
 
 Stack Encrypt lives in this repository (`packages/stack-encrypt`), and the
 feature depends on it by path and version: in-tree builds use the path, and the
-published `eql-bindings` resolves the version from crates.io. Publish the
-matching `stack-encrypt` before releasing an `eql-bindings` that needs it.
+published `eql-bindings` resolves the version from crates.io. The two agree only
+when the `stack-encrypt` on crates.io at that version has the API this feature
+uses, which a path build cannot check — 0.1.0 shipped without `Describe`, and
+every in-tree test passed against the newer tree. So the feature is also built
+from the packaged crate against the registry: `cargo publish -p eql-bindings
+--dry-run --all-features` in CI, and `publish_all_features` in
+`packages/eql/release-plz.toml` at release time. Bump the requirement in
+`Cargo.toml` only together with (or after) the `stack-encrypt` release that
+carries what the feature needs; the dry run is red until that release exists.
 
 ```bash
 # From packages/eql. The mise tasks are what CI runs (test-eql.yml, `rust-crates`).

packages/eql/crates/eql-bindings/README.md

@@ -37,3 +37,15 @@ publish = true
 # semver_check is noisy for a pre-1.0 crate and duplicated by the PR review;
 # disabled to match cipherstash-suite.
 semver_check = false
+# Verify the packaged crate with EVERY feature on. `cargo publish` verifies the
+# default feature set, and eql-bindings' `stack-encrypt` feature is off by
+# default, so a plain publish compiles none of the code that depends on
+# stack-encrypt. It would ship a feature that does not build against the
+# crates.io stack-encrypt its `version` names: docs.rs enables the feature and
+# goes red, and a consumer enabling it fails to compile. The in-tree path
+# dependency cannot catch this — it builds against whatever
+# packages/stack-encrypt holds, released or not. With `--all-features` the
+# verify step resolves stack-encrypt from the REGISTRY and refuses to publish
+# an eql-bindings whose feature does not build there. The PR-time twin is the
+# `cargo publish --dry-run --all-features` step in test-eql.yml.
+publish_all_features = true

packages/eql/release-plz.toml

@@ -188,6 +188,9 @@ const PERMISSIVE_NEEDS = {
   gate: { result: 'success', outputs: { ffi: 'true', auth: 'true' } },
   'publish-ffi': { result: 'success' },
   'publish-auth': { result: 'success' },
+  // release-plz.yml's `release` runs after the stack-* crates job and accepts
+  // a skipped one; held to success here, like the other upstream results.
+  'release-crates': { result: 'success' },
   release: { result: 'success', outputs: { published_packages: '' } },
   'eql-assets': {
     result: 'success',