Measured while landing #10499 + #10498 (PR #11090). Filed unassigned, recording only — and filed largely so that the recommended disposition is on the record, because the obvious action here is the wrong one.
The measurement
packages/create-objectstack/CHANGELOG.md, lines 643-644 and 743-744, state the pre-#10498 pnpm boundary in two historical release entries:
allowBuilds pnpm >= 10.31
onlyBuiltDependencies pnpm 10.0–10.30
The measured boundary is 10.26.0 (#10498, established with per-version clean installs on isolated stores). PR #11090 corrected the live copies — the blank template's pnpm-workspace.yaml comment and template-consistency.test.ts's header, title and failure message — and left these two alone.
⛔ Recommended disposition: leave them exactly as they are
A CHANGELOG is an append-only record of what shipped. Those entries are not wrong as history: at the time of those releases, the scaffolded file really did say >= 10.31. Rewriting them would make the repo claim it shipped something it did not, which is a worse defect than the stale number — and it would destroy the only record of when the boundary was believed to be 10.31, which is exactly what someone debugging a user's old scaffolded project would need.
The corrected numbers reach users through #11090's own changeset, going forward, which is how a changelog is supposed to acquire a correction.
Why file at all, then
Because 10.31 is now a grep-able wrong number sitting in the tree, and the repair that just landed makes it more likely someone finds it: a future sweep for the retired boundary — human or agent — will hit these two entries and "finish the job". This card is the standing answer to that sweep. It is the same shape as the tombstone lesson this lane keeps relearning: a retired value surviving in a place that legitimately preserves it is not a residue to clean up, and a check that cannot tell the two apart will keep re-reporting it.
If a sweep wants to be thorough, the right instrument is a scoped one — correct live copies, exclude CHANGELOG.md and content/docs/releases/** by construction — not a repo-wide replace.
What this is not
Duplicate search run before filing (it could not be run at PR report time — the API was rate limited): nothing covers this. The nearest neighbours are #10498 (the live template comment, fixed by #11090), #10405 (closed, the omission that created the divergence) and #11048 (the open decision about the >=10.15 engines floor, a different question about a different key).
Related: #10499 · #10498 · #11090 · #11048
Measured while landing #10499 + #10498 (PR #11090). Filed unassigned, recording only — and filed largely so that the recommended disposition is on the record, because the obvious action here is the wrong one.
The measurement
packages/create-objectstack/CHANGELOG.md, lines 643-644 and 743-744, state the pre-#10498 pnpm boundary in two historical release entries:The measured boundary is 10.26.0 (#10498, established with per-version clean installs on isolated stores). PR #11090 corrected the live copies — the blank template's
pnpm-workspace.yamlcomment andtemplate-consistency.test.ts's header, title and failure message — and left these two alone.⛔ Recommended disposition: leave them exactly as they are
A CHANGELOG is an append-only record of what shipped. Those entries are not wrong as history: at the time of those releases, the scaffolded file really did say
>= 10.31. Rewriting them would make the repo claim it shipped something it did not, which is a worse defect than the stale number — and it would destroy the only record of when the boundary was believed to be 10.31, which is exactly what someone debugging a user's old scaffolded project would need.The corrected numbers reach users through #11090's own changeset, going forward, which is how a changelog is supposed to acquire a correction.
Why file at all, then
Because
10.31is now a grep-able wrong number sitting in the tree, and the repair that just landed makes it more likely someone finds it: a future sweep for the retired boundary — human or agent — will hit these two entries and "finish the job". This card is the standing answer to that sweep. It is the same shape as the tombstone lesson this lane keeps relearning: a retired value surviving in a place that legitimately preserves it is not a residue to clean up, and a check that cannot tell the two apart will keep re-reporting it.If a sweep wants to be thorough, the right instrument is a scoped one — correct live copies, exclude
CHANGELOG.mdandcontent/docs/releases/**by construction — not a repo-wide replace.What this is not
content/docs/releases/**— no hits there, and that surface is release-owned regardless.findingonly, unassigned, nodomain:*, nopm:queue— grading belongs to triage.Duplicate search run before filing (it could not be run at PR report time — the API was rate limited): nothing covers this. The nearest neighbours are #10498 (the live template comment, fixed by #11090), #10405 (closed, the omission that created the divergence) and #11048 (the open decision about the
>=10.15engines floor, a different question about a different key).Related: #10499 · #10498 · #11090 · #11048