ci(changelog): drop the lockfile merge driver this job never invokes

[os-warren]

Fixes #6358

Disposition 2 (delete the driver configuration) — but ⚠️ not for the reason the card and my dispatch order expected. The route hinged on a reading I was told to re-derive, and re-deriving it flipped which fact the deletion rests on.

The two questions, measured separately

(1) Does the workflow run at all? — It CAN. The "waits on release events" reading is stale.

The card repeats #5409's cause: "it waits on release events this repo's own releases can never emit." That is no longer true of the file. The release: types: [published] trigger was already removed on 2026-08-23 (by #5409's own resolution), and changelog.yml's on: block today is:

on:
  workflow_dispatch:

A maintainer can start it at any time, and both the file header and ci-cd-pipeline.md say it is meant to be run at release time as part of cutting a release. I did independently confirm the run count — the Actions API returns total_count: 0 for this workflow — but "never dispatched" is not "cannot run". So the zero is real while the cause attached to it is stale, and disposition 2 cannot be justified on question (1).

(2) Even when it runs, does the merge driver fire? — No. This is the reason acted on.

A merge driver is invoked by git only when git actually has to merge the attributed path. This job never merges. Its complete step list is: checkout → (the driver config) → git-cliff → git add CHANGELOG.md → git commit → git push. Grepping the whole file for a merge occasion returns only the driver config itself and a pull-requests: read permission:

$ grep -nE 'merge|rebase|pull|cherry|revert' .github/workflows/changelog.yml
23:  pull-requests: read
35:      - name: Configure Git merge driver for pnpm-lock.yaml
...

There is no merge, rebase, pull, cherry-pick or revert, and the job never touches pnpm-lock.yaml at all — it stages exactly CHANGELOG.md. The documented rationale for the step — "commits back to a branch that may have moved" — does not reach a driver: a push to a branch that moved is rejected, not merged, and nothing in this job resolves that rejection.

So the step was dead configuration, not a missing-toolchain bug. Adding corepack enable + actions/setup-node (disposition 1) would have pinned a toolchain for a command that cannot run.

What made it dead, recorded in place

The deletion leaves a comment in changelog.yml stating the mechanism, so the next reader does not restore it from the instinct that added it — including the note that if a real merge is ever added to this job, the driver needs corepack enable + actions/setup-node ahead of it the way the two siblings do.

⚠️ Declared surface expansion: one doc file, forced by a pin

My dispatch order said one file only (.github/workflows/changelog.yml). That constraint is mechanically unsatisfiable for disposition 2, and I am declaring the second file rather than shipping a knowingly red PR.

scripts/__tests__/ci-cd-pipeline-doc.test.ts pins the "Lockfile Merge Driver" table in content/docs/guide/ci-cd-pipeline.md against the workflows that actually configure merge.pnpm-merge, in both directions. Deleting the step makes changelog.yml a phantom row. Measured, exit code captured by redirect before any pipe:

state	exit	result
baseline, before any edit	0	34 passed
workflow edit only (one file)	1	phantom: changelog.yml
workflow + doc row removed	0	34 passed

The failing assertion's own message dictates the remedy:

the "Lockfile Merge Driver" table names workflows that do NOT configure merge.pnpm-merge: - changelog.yml … Either the step was dropped from that workflow … or the row is stale and should go.

There is no one-file path to disposition 2. Keeping the pin green from the workflow side alone would require leaving the literal string merge.pnpm-merge in the file (the pin is a grep), which would make the gate assert a falsehood — so the explanatory comment deliberately avoids spelling the config key.

The doc change is three edits in that one file: the phantom table row, the now-false sentence in the changelog.yml section, and — the same defect class — the instruction that produced the dead copy in the first place. It read "Adding a workflow that merges or pushes? Add the step…"; pushing is not merging, and that word is why this workflow carried a driver with nothing to resolve.

Gates

Derived by hand from objectui's own package.json and .github/workflows/ — ⚠️ scripts/pm/dispatch-gates.mjs lives only in objectstack and would answer about the wrong tree. Union re-run at final commit e49c5af24 on a clean tree, each exit code captured by redirect before any pipe:

gate	exit	its own verdict line
check-pre-install-import-graph	0	OK — 16 pre-install step(s) in 15 job(s) run 16 scripts/ gate(s); 18 module(s) walked
ci-cd-pipeline-doc.test.ts	0	Test Files 1 passed (1) / Tests 34 passed (34)
check-control-bytes	0	OK (scanned 5238 tracked text file(s); skipped 85 binary)
check-doc-links	0	Links are valid across 17 scan roots.
check-doc-fence-languages	0	every TypeScript block in 223 document(s) is fenced ts/tsx/typescript
check-changeset-presence	0	No source of a released package changed in this range, so no changeset is owed.
check-shell-escape-residue	0	OK (4/4 root(s) resolved … 0 occurrence(s) outside a fence)
scripts/__tests__/ (unit)	0	Test Files 79 passed (79) / Tests 2279 passed (2279)

No changeset — on the gate's own verdict, not an assumption. No skip-changeset label: that mechanism does not exist in this repo, and creating one by applying it would mint a repo label the next reader would take for real.

check-pre-install-import-graph, reverse-verified. My dispatch order flagged it as the gate most likely implicated. Predicted direction stated in advance: population unchanged, because changelog.yml contains no node scripts/* step in either state. Confirmed by restoring origin/main's copy of the file (mutation confirmed on disk by grep before measuring, restore then verified byte-identically: HEAD blob d6d4b5515… equals disk blob, git diff HEAD empty):

before: 16 pre-install step(s) in 15 job(s) run 16 scripts/ gate(s)
after:  16 pre-install step(s) in 15 job(s) run 16 scripts/ gate(s)

Identical, as predicted. That gate's INSTALL_RE is in fact documented to exclude this exact git config merge.pnpm-merge.driver "pnpm install …" line from counting as an install, so the step never entered its population.

Not touched, deliberately

changelog.yml's triggers, #5409's subject, .gitattributes, and the two sibling workflows. The .gitattributes line stays: two workflows still configure the driver, so the attribute is still live and the doc test's first assertion (configuring.length > 0) still holds.

---

Generated by Claude Code