Check whether the release plugin links compare/undefined on a first release

[Mearman]

merge-when's first release body linked to compare/undefined...v1.0.0 because a first release has no previous tag. The same plugin was fixed in merge-when and merge-when-green. This repository carries a copy of the plugin; check whether it breaks on a first release and apply the same fix if it does.

Deferred because it only matters when a first release is cut here. Revisit trigger: the next first release of a new package in this repository, or a quick read of the plugin to confirm.

Triage summary

Checked CHANGELOG.md against the actual first release this repository already cut: ## 1.0.0 (2026-09-03) (CHANGELOG.md:274) renders as a plain version string, not [1.0.0](.../compare/undefined...v1.0.0). This is the repository's own real first release, not a simulation, so it is direct evidence the headerPartial in release.config.ts (lines 49-70) already falls back to the plain-version branch ({{~else}} {{~version}} {{~/if~}}) rather than emitting a broken compare link when there is no previous tag, at least as the trigger condition actually occurred here.

I could not verify the underlying mechanism (whether @root.linkCompare is set by @semantic-release/release-notes-generator/conventional-changelog-writer itself based on previousTag presence, or by something else in this config) because node_modules isn't installed in this environment, so I can't read the installed package source. The repository's own git history is also unavailable here (shallow clone, single commit), so I can't confirm whether this headerPartial was already changed since 1.0.0 was cut.

No action needed unless a future first release (of a genuinely new package/tag sequence in this repo) reproduces the "undefined" link — this run found no evidence that it currently does.

[claude]

What this looks like: A self-filed, deferred verification task (not a bug report of an observed fault) about release.config.ts's custom headerPartial (lines 49-70), which generates the version-header compare link for CHANGELOG.md/GitHub Releases. Low severity either way — it's cosmetic (a broken link in release notes), not data-affecting, and this repository has already cut its first release, so the window where it "would only matter" has already passed.

What I checked: This repository's own CHANGELOG.md:274 already shows its real first release as ## 1.0.0 (2026-09-03) — a plain version string, with no compare link and no undefined. That's the actual first-release case the issue asks about, not a hypothetical one, so it's direct evidence this repo's copy of the plugin already falls into the correct fallback branch ({{~else}} {{~version}} {{~/if~}} in the headerPartial) rather than the merge-when bug of linking compare/undefined...v1.0.0.

I could not confirm why — I can't tell from this environment whether @root.linkCompare is computed based on previousTag presence by @semantic-release/release-notes-generator/conventional-changelog-writer itself, or by something else, because node_modules isn't installed here and I can't read the installed package source. Git history is also unavailable (shallow clone, single commit), so I can't say whether this file was ever patched after 1.0.0 shipped.

Related issues: None found — searched issues and gh search issues for "compare undefined" and "release plugin", no matches besides this one.

Suggested next step: Given the first release already happened cleanly, this looks safe to close once a maintainer is comfortable relying on the CHANGELOG.md evidence above rather than reading the plugin source directly. If stronger confirmation is wanted, the one open question is the mechanism (linkCompare's source), not the outcome.

Labelled question, since this is an investigative task with an available answer rather than a confirmed bug or feature request. No existing label like "chore" or "verification" fits better. Left issue type unset — sampled issues in this repo only use the Bug type, and this doesn't clearly match. Appended a triage summary to the issue body under the claude-triage markers.

[github-actions]

🗜️ Headroom context compression

Metric	Value
Requests proxied	28
Tokens saved	33839
Aggregate savings	2.5% of all tokens sent
Average per-request compression	3.5%