chore(ci): delete release.yml, a workflow that never ran

[os-support-ai]

Fixes#5405

.github/workflows/release.yml had 0 workflow runs, ever. It is deleted here, along with the two places on content/docs/guide/ci-cd-pipeline.md that documented it as a release path.

The deletion is one git rm. Establishing that the file is dead is the work, so all three checks were re-run independently, each with its own counter-probe.

1. total_count: 0 — re-confirmed, and it means "never", not "not lately"

probe	result
runs for release.yml (by filename)	total_count: 0
runs for workflow id 223155593 (same workflow, addressed by id)	total_count: 0
counter-probe — identical call for changeset-release.yml	total_count: 3902
counter-probe — identical call for a bogus workflow name	HTTP 404, not 0
retention probe — stale.yml, daily cron since 2026-01-15	216 runs
retention probe — shadcn-check.yml, first page reaches back to	2026-02-09

The bogus-name probe is what turns the zero into a reading: an unknown workflow 404s, so 0 cannot also be the "not found" signal. The retention probes close the other gap — a zero would be worthless if Actions were ageing run records out. They are not: records here reach back six months to workflow creation, and stale.yml has one run for very nearly every day since it was created. The zero spans the repository's entire life.

(The card quoted 3901 for changeset-release.yml; it now reads 3902. The counter moved between the card and this PR, which is itself a small confirmation that the method reads live data.)

2. Nothing pushes v* tags

• 2896 tags exist on the remote and zero begin with v, case-insensitive — checked locally after git fetch --tags and again remote-side with git ls-remote, so the answer does not depend on my local ref state.
• Counter-probe on the same glob form: v* returns 0 while @object-ui/app-shell@11* returns 5 local tags / 10 remote refs. The filter resolves; the zero is not a broken pattern.
• Every tag is a Changesets per-package tag, across 44 package namespaces. Nothing else creates tags: grepping the workflows, scripts/, and every package.json for git tag, --tags, --follow-tags, refs/tags, gh release create and the usual release CLIs finds no tag-creating step outside the Changesets action.
• One honest edge, reported rather than smoothed over: packages/vscode-extension/PUBLISHING.md instructs a human to create a GitHub release tagged vscode-extension-v0.1.1. That name does match v* — the glob anchors on the leading v only. It is manual, automated nowhere, and has never been executed (zero such tags, local and remote). Had it ever been executed, this workflow would have misfired rather than helped: its ${GITHUB_REF#refs/tags/v} strips the leading v of vscode-..., so it would have built the entire monorepo and published a release titled Release scode-extension-v0.1.1.

3. Nothing references it

A repo-wide grep for release.yml (excluding node_modules, .git, dist) returns exactly two unqualified mentions, both on content/docs/guide/ci-cd-pipeline.md. Every other hit is changeset-release.yml. No badge names it (the README badges are CI and CodeQL), no workflow_run listener exists anywhere in the repo, and no script mentions it. It also cannot have been a required check by construction: a push: tags trigger produces no pull-request context.

Both doc mentions go here — the workflow-inventory row and the ### Tag Release section. That edit is required rather than housekeeping: scripts/__tests__/ci-cd-pipeline-doc.test.ts pins that page to .github/workflows/ in both directions, so a page still naming a deleted workflow fails.

The edit is deliberately subtractive. The page's own tests exist because unpinned prose claims on it drift, so this adds no new editorial sentence about there being only one release path — the surviving ### Changeset Release section is the claim, and the forward pin already forces any future workflow to be documented in that spot.

The fork: obsolete, not intended-but-broken

These have opposite fixes, so here is the evidence for obsolete.

• It is not misconfigured or unparseable. GitHub registered it and reports it state: active with a workflow id, so it would fire if a v* tag were pushed. The trigger never fires because this repo emits @object-ui/PACKAGE@VERSION tags, not v-prefixed ones.
• The job it would do is already being done. Its only real step is "Create GitHub Release", and GitHub Releases are being created — by github-actions[bot] through the Changesets action on changeset-release.yml, tagged @object-ui/types@17.5.0 and friends, most recently 2026-08-14. Deleting this removes a duplicate, not a capability.
• Its own TODO was overtaken by reality. Its npm publish step is still commented out under "Uncomment the following steps when ready to publish to npm", while the repo has been publishing to npm through Changesets for months.
• Its version model never matched this repo. It assumes a single v + semver for the whole repo pointing at the root CHANGELOG.md; this repo releases a 39-package fixed group with per-package versions.

A note on one thing I could not use as evidence: git log attributes both release.yml and changeset-release.yml to the same 2026-08-10 commit, which is an artifact of this being a shallow clone (grafted at 660 commits), not real history. The creation dates above come from the Actions API instead — release.yml on 2026-01-13 among the repo's first workflows, changeset-release.yml two days later on 2026-01-15.

Also noted while verifying, and not changed here: changelog.yml likewise shows 0 runs. That is explained without any defect — it listens for release: published, and releases published by GITHUB_TOKEN deliberately do not trigger further workflow runs. It is out of scope for this PR and no claim about it is made here.

Tests

All at fe329892d, the final commit, on an otherwise clean tree.

• pnpm exec vitest run scripts/ from the repo root — 58 files, 1549 tests, all passed. That is the real blast radius: 20+ scripts read .github/workflows/, so the whole scripts/ suite was run rather than only the one obviously-related file.
• Gates re-derived from the paths this PR actually touches, all exit 0: check-control-bytes (4483 files scanned), check-doc-links (13 scan roots), check-changeset-presence, check-changeset-no-major, check-doc-component-types (which does cover .md, not only .mdx — 183 doc files, 887 type literals).
• check-doc-snippet-types was reasoned about rather than run: it compiles against built dist/, and this diff removes no code fence at all, so that file's set of compilable snippets is byte-identical to main.

Reverse verification of the doc pin

A green pin proves nothing until it is shown to be able to fail, so, from the committed state: re-introduce one unqualified mention of release.yml on the page with the workflow still deleted.

Predicted direction was red, and red is what happened — 1 failed / 31 passed:

× never names a workflow file that does not exist
AssertionError: ci-cd-pipeline.md documents release.yml, which is not in
.github/workflows/: expected [ 'changelog.yml', ...(20) ] to include 'release.yml'

Restored with git checkout HEAD -- ..., confirmed byte-identical to the commit, re-run green at 32/32. No rebuild is involved in either leg: this test reads the doc and the workflow directory from disk with fs.readFileSync, so there is no dist/ resolution that a stale build could make vacuously green.

Scope

Touches exactly three paths: the deleted workflow, the doc that described it, and a changeset. changeset-release.yml (#5404) and ci.yml (#5403) are deliberately untouched — neither is modified by this branch. The changeset carries empty frontmatter, the repo's first-class way to declare "this publishes nothing": no released package's src/ changed, which check-changeset-presence confirms independently.

Not enabling auto-merge — the PM lands this.

---

Generated by Claude Code