Demote the unshipped 2.0.0 release to a minor

[coderdan]

Why

PR #859 merged, but the release run failed before anything published: the Publish FFI packages job died, the Release (JS changeset publish) job was skipped, nothing is on npm (every package's latest is still 1.0.0 / protect-ffi 0.31.0), and no tags were pushed. So the 2.0.0 version numbers were never consumed — and we shouldn't have gone major anyway:

• @cipherstash/stack-prisma / Prisma Next 0.17 — the only genuine surface break, but Prisma Next is pre-1.0 and only used in experimental setups. A 0.x-style "upgrade deliberately" signal fits better than a major that drags five sibling packages with it.
• clientKey hex-only — not a break. Base64 was never documented, never produced by stash env or any env var, and never part of this package's contract; the tolerance was an accident of the Rust decoder that exists to read the profile store (a path that remains unaffected).
• DynamoDB error.code narrowing — a correction (transport codes were mislabelled as encryption codes) with no known production usage.

What

• Reverts 907a68bd (Version Packages Version Packages #859): versions back to 1.0.0, consumed changesets restored, skill pins back to 1.0.0.
• .changeset/prisma-next-0-17.md: @cipherstash/stack-prisma major → minor, with the rationale added to the changeset text (the migration steps stay, clearly flagged as required).
• .changeset/stack-2-0-0-version-alignment.md → .changeset/release-line-notes.md: drops the "why this went to 2.0.0" framing, keeps the cross-changelog routing (clientKey, eql validate flag/exit-code changes), and now explains why clientKey is not a break.

No other changeset carries a major, so the fixed group's highest bump is minor.

Verified

• changeset version simulated in an isolated worktree: stash, @cipherstash/stack, stack-prisma, stack-drizzle, stack-supabase, wizard all land on 1.1.0; protect-ffi regenerates at 0.32.0; migrate/nextjs untouched; no ### Major Changes section in any new changelog entry.
• release-train.test.ts passes (20/20) — pins and manifests agree at 1.0.0 on this branch.

After merge

1. Changesets opens a fresh "Version Packages" PR at 1.1.0.
2. That branch needs the skill pins bumped to 1.1.0 (same last-minute commit as on Version Packages #859 — release-train.test.ts will fail on the release branch until it's done).
3. The release will fail again unless the FFI publish step is fixed first: the failure was npm parsing the relative tarball path ffi-dist/<name>.tgz as a GitHub owner/repo shorthand (npm error command git ls-remote ssh://git@github.com/ffi-dist/....tgz.git) — not trusted publishing, which never got exercised. The publish invocation needs a ./ prefix on the tarball paths. Worth also running npm trust list on the seven packages before retrying, since that config is still unproven.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6fe6b42

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 18 packages

Name	Type
stash	Minor
@cipherstash/protect-ffi-darwin-x64	Minor
@cipherstash/protect-ffi-darwin-arm64	Minor
@cipherstash/protect-ffi-win32-x64-msvc	Minor
@cipherstash/protect-ffi-linux-x64-gnu	Minor
@cipherstash/protect-ffi-linux-arm64-gnu	Minor
@cipherstash/protect-ffi-linux-x64-musl	Minor
@cipherstash/stack	Minor
@cipherstash/stack-prisma	Minor
@cipherstash/protect-ffi	Minor
@cipherstash/stack-drizzle	Minor
@cipherstash/stack-supabase	Minor
@cipherstash/wizard	Minor
@cipherstash/basic-example	Patch
@cipherstash/e2e	Patch
@cipherstash/bench	Patch
@cipherstash/test-kit	Patch
@cipherstash/prisma-example	Patch

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

[freshtonic]

Approve. I verified the two things a 67-file revert-and-renumber PR actually turns on — that the revert is byte-faithful, and that the version numbers being reclaimed were never consumed — and both hold. CI green.

Verified mechanically

• The revert is exact. I diffed every file 907a68bd touched between its pre-859 state and this branch: only two differ — .changeset/prisma-next-0-17.md (the deliberate major→minor edit) and .changeset/stack-2-0-0-version-alignment.md (deleted in favour of release-line-notes.md). Every package.json version, changelog, skill pin, and restored changeset is byte-identical to the pre-859 tree. Conversely, the PR's merge-base diff contains nothing outside 859's file set except the renamed notes changeset — no stray edits hiding in the bulk.
• Nothing shipped, so the numbers are free. npm view today: stash, @cipherstash/stack, @cipherstash/stack-prisma all at latest: 1.0.0; @cipherstash/protect-ffi at 0.31.0. The failed run died in the FFI publish step before touching the registry and the JS publish job was skipped, so re-cutting as 1.1.0 collides with nothing. This is the load-bearing precondition for the whole PR and it checks out.
• No : major survives in any changeset on the branch — the fixed group's highest bump is minor, matching the simulated changeset version result in the PR body.

The judgment calls

• stack-prisma breaking-as-minor: strictly, a 1.x package shipping consumer-breaking changes in a minor is a semver deviation, and anyone pinning ^1.0.0 on stack-prisma will auto-resolve into the 0.17 migration. But the mitigations are real: the rationale is printed in the changelog entry itself, the migration steps stay and are flagged as required reading, the audience is tracking a pre-1.0 upstream that moves the same way, and the alternative drags five sibling packages to 2.0.0 for one experimental integration's sake. Documented deviation over misleading precision — I think that's the right trade, and crucially it's stated where the consumer will read it, not silently assumed.
• The clientKey demotion is the strongest of the three: an undocumented tolerance that no CipherStash tool ever produced isn't a contract, and the notes changeset now says exactly that — including the one real footgun (a key pasted from secretkey.json is base64 and stops working) with both remedies.
• release-line-notes.md earns its rename: it keeps the cross-changelog routing that made the original useful (clientKey, the eql validate flag/exit-code changes) while dropping the now-false 2.0.0 framing.

After merge

The PR body's checklist is right, and half of it is already done: #921 (the ./$tgz fix) has merged to main, so the ordering constraint is satisfied. What remains before the retry: the skill-pin bump to 1.1.0 on the fresh Version Packages branch (release-train.test.ts will hold the door until it's done), and the still-unproven npm trust list check on all seven FFI publishers — flagged on #910, #921, and here, and still the most likely way the next attempt fails.