Keep the next tag resolving instead of removing it (#231)

Follow-up to #230, applying the operator ruling of 2026-08-25: removing
`next` would break every `prisma@next` instruction immediately (`npm
install prisma@next` fails with no matching version), while a manually
re-pointed tag that lags between moves still resolves a complete,
working release — exact pins make every published version internally
coherent.

- `scripts/cutover-dist-tags.sh` now points `next` at the current
release (8.0.0-rc.10) on `prisma` and `@prisma/cli`, and at 0.2.3 on the
engine, instead of removing the tag.
- `docs/oss/versioning.md` records the policy: `next` is kept alive,
moved by hand, allowed to lag, and retired with an announcement once
`8.0.0` stable ships. New text should say plain `prisma`.

Docs and a maintenance script only — no published behavior changes until
the operator runs the script.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Author: wmadden-electric

.drive/projects/prisma-cli-v8/deferred.md

@@ -4,6 +4,28 @@ Work identified during a slice that is not part of that slice's
 contract. Each entry: what, why it was deferred, where it lands.
 Nothing here is tracked outside this file.
 
+## After the latest cutover (2026-08-25, PR #230)
+
+- **A stale product `dev` dist-tag can block a release publish.** The
+  publish run checks the dev channel before the release leg, and the
+  dev channel resolves each product's `dev` tag with no fallback — so
+  when prisma/prisma released rc.7 without publishing a dev build
+  (their workflow's two publish kinds were alternatives), our rc.10
+  release run died in the dev conformance check with an
+  engine-pin-mismatch nothing in this repo caused. Unblocked by a
+  manual `npm dist-tag add @prisma/orm-toolchain@8.0.0-rc.7 dev`; a
+  separate agent is porting composer's dual-publish (composer #241) to
+  prisma/prisma, which removes the trigger. Open decision for THIS
+  repo: whether a dev-channel failure should stop the release leg at
+  all, or the release should publish and the run report the dev
+  failure after — the current ordering makes another repo's stale tag
+  this repo's release blocker.
+- **The `@prisma/cli` deprecation call is open.** Rollout-plan step 5
+  listed a deprecation notice pointing installers at `prisma`; the
+  package is now the scoped twin the workflow actively publishes, so
+  deprecating it may no longer make sense. Operator decision; needs npm auth either way
+  (`npm deprecate @prisma/cli@"<8.0.0" "..."`).
+
 ## After S7's first real publish
 
 - **The publish/Release shell in `publish.yml` should become a tested

docs/oss/versioning.md

@@ -40,7 +40,7 @@ This is enforced, not remembered: the conformance checks refuse to publish a rel
 The npm registry exposes the CLI packages under these dist-tags:
 
 - **`latest`** — what a bare `npm install` gets: the newest release, RC or stable. A merged release PR publishes here automatically (operator cutover ruling 2026-08-25; before it, `latest` stayed on the pre-8 CLI and the RC line lived on `next`).
-- **`next`** — retired by the cutover: it froze at the last pre-cutover RC and the publish path no longer moves it (operator ruling 2026-08-25). Keeping it synced to `latest` was considered and dropped — re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm has no token permission narrower than package write, so a standing sync would mean a standing publish-capable token. The operator re-points or removes the tag by hand (`scripts/cutover-dist-tags.sh`); text that says `prisma@next` should move to plain `prisma`.
+- **`next`** — kept alive but no longer moved by the publish path (operator ruling 2026-08-25). Removing it would break every `prisma@next` instruction immediately, and an automated sync to `latest` would need a standing token — re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm has no token permission narrower than package write, which is publish-capable. So the operator points it at the current release by hand (`npm dist-tag add prisma@<version> next`, same for `@prisma/cli` and the engine), accepts that it lags between such moves — a lagging `next` still resolves a complete, working release — and retires it with an announcement once `8.0.0` stable ships. New text should say plain `prisma`.
 - **`beta`** — reserved for hand-cut previews ahead of significant changes, published by dispatching the workflow with that dist-tag. Routine releases do not use this tag.
 
 - **`dev`** — every routine push to `main` publishes `<base>-dev.<run>` here automatically (operator ruling 2026-08-13, superseding the earlier "no dev channel" ruling). The suffix derives from the workflow run number and is stamped ephemerally in CI, never committed, so release versions remain exactly what a commit says. The channel exists so a product's new version reaches a working CLI without a human: an auto-merging pull request moves the version, runs the full quality and conformance checks, and its merge ships the dev build. Today a daily scheduled run is what notices a product release; the immediate path needs a notification step in each product repository, which neither has yet. See [release automation](./release-automation.md). Only a real release — a merged `rc.N` bump publishing under `latest` — is a human act.