docs(ci): measure the last lockfile merge-driver row instead of removing it

[os-warren]

Part of #6391

⭐ The falsification attempt succeeded on the workflow and FAILED on the .gitattributes line, so this PR records the measurement instead of shipping the removal. The card asked for a four-part removal; the fourth part turns out to be live, and the doc pin binds all four together. That makes the removal a decision, not a cleanup, and it is escalated rather than guessed at.

⚠️Framing: this is not a gate weakening and not a mechanism removal — nothing is deleted here. It is the measurement the card asked for, written into the files so it is not re-derived a fourth time.

Step 1 — the sweep of changeset-release.yml

Every git in the file, enumerated rather than grepped for absence: the two git config lines, git status --porcelain twice, and git checkout -- . + git clean -fdq in "Restore the pre-version tree".

Merge family, with a control term on every zero-hit (a zero-hit with no control is not a reading):

term	hits	control	control hits
rebase	0	base	2
cherry-pick	0	pick	4
apply	0	app	8
revert	0	rev	5
git am	0	git	10

merge itself hits 28 times: 26 are prose about the version-PR merge (a human/server-side act) and the remaining 2 are the driver configuration.

Confirmed rather than assumed, both as the card asked:

• git checkout -- . (~:1018) is not a merge. It sits in "Restore the pre-version tree" and takes tracked paths from the index to undo what pnpm changeset:version wrote. A discard.
• git config (~:525–526) is the configuration itself, not an invocation.
• There is no pull_request trigger, so actions/checkout@v7 never checks out a GitHub-computed merge ref either.

⭐ Step 2 — reading changesets/action@v1 itself

The load-bearing question, unanswerable from the workflow. Read at the tag the workflow pins, which currently resolves to v1.9.0 (a45c4d594aa4e2c509dc14a9f2b3b67ba3780d0d), with src/git.ts and the executed dist/ bundle agreeing line for line.

The action's complete git surface (uppercase words are placeholders — GitHub's body sanitizer eats angle-bracket ones, even inside a fence):

git checkout BRANCH / git checkout -b BRANCH
git reset --hard SHA
git add .
git commit -m MESSAGE
git push origin HEAD:BRANCH --force
git push origin TAG
git config user.name / user.email

The version-branch update is prepareBranch — checkout, then git reset --hard github.context.sha — followed by commitAll and a force-push. It never merges, rebases or three-ways anything. A force-push resolves no merge, so the driver has no occasion to fire. Zero merge-family verbs across src/ and dist/, again with hitting controls (push, checkout, reset, commit, status).

Its alternative commitMode: github-api path is not selected here (default is git-cli); it builds the commit through the GitHub API, and the bundle reads no .gitattributes and implements no merge driver at all.

So rows 1–3 of the card are confirmed: the CI half of this mechanism is dead.

⛔ Why the removal did not ship: the .gitattributes line is live

The card treats pnpm-lock.yaml merge=pnpm-merge as the last piece of a mechanism nothing exercises. It is not. The attribute is repository-wide, and its live consumer is the contributor path this very guide section already points at: CONTRIBUTING.md → Configure Git Merge Driver for pnpm-lock.yaml tells contributors to set the same driver, and then to git merge upstream/main — a real local merge on the attributed path.

Measured in a scratch repository, one variable changed between two otherwise identical runs:

.gitattributes	result of the same conflicting local merge
withpnpm-lock.yaml merge=pnpm-merge	driver fires, lockfile regenerated, merge succeeds
without it	CONFLICT (content), conflict markers left in pnpm-lock.yaml

Deleting the attribute would not retire dead configuration — it would convert a clean auto-resolve into a hand-resolved lockfile conflict for every contributor who followed CONTRIBUTING.md. A hand-edited pnpm-lock.yaml is a high-blast-radius artifact.

The pins force the two halves together: dropping the CI config makes ci-cd-pipeline-doc.test.ts demand the attribute's removal in its own failure message. So the CI half is dead and the repository-wide half is live, and the pin cannot express that. Resolving it needs a ruling — see the report on #6391.

What the table is down to

One row, changeset-release.yml — after the two removals that landed as #6367 (from #6358) and #6389 (from #6369). That row survives here, but its stated reason was wrong and is corrected: it read "version bumps rewrite the lockfile on the release branch", and a rewrite is not a merge. The guide gains the third ⛔ note in the existing series ("pushing is not merging", "a server-side merge is not a local one", and now "a rewrite is not a merge, and a force-push resolves none").

Changes

1. .github/workflows/changeset-release.yml — the measurement recorded beside the step, including the ⛔ note that it must not be deleted on "it is dead" grounds without the attribute question being settled. The config is unchanged.
2. content/docs/guide/ci-cd-pipeline.md — row reason corrected, the measurement and the contributor-path finding recorded, third ⛔ note added.
3. Changeset with empty frontmatter (CI/doc-only; nothing published).

Untouched, deliberately: .gitattributes, CONTRIBUTING.md, scripts/__tests__/ci-cd-pipeline-doc.test.ts, and dependabot-auto-merge.yml (#6392 landed its own PR #6423).

Verification

Run on the final commit e5ad9e9d8:

• pnpm exec vitest run scripts/__tests__ — the whole tree as required, not a subset: 81 files, 2317 tests passed.
• scripts/__tests__/ci-cd-pipeline-doc.test.ts isolated — 34 passed, both directions of the pin and the .gitattributes assertion green.
• pnpm check:control-bytes — OK (5320 files) · pnpm check:pre-install-import-graph — OK (this gate reads changeset-release.yml, so the added comment block is directly implicated; the install boundary is unmoved) · pnpm docs:check-links — valid across 17 scan roots.

---

Generated by Claude Code