ci: publish GitHub Releases for every released package

[palicko]

Why

The Releases page stopped updating after @webikon/webentor-core@0.15.3 (2026-07-02), while tags and npm publishes kept advancing:

Releases (last):  @webikon/webentor-core@0.15.3
Tags:             core-v0.15.4 … core-v0.15.7
npm:              0.15.4 … 0.15.7  (0.15.7 = latest)

Those existing Release names are the changesets convention (@scope/pkg@version) — the changesets action created them. When the pipeline was revamped (changesets → check-versions + publish-npm.mjs + release-tags.sh), nothing replaced that behaviour. Grepping release.yml and publish-npm.mjs for gh release / softprops / action-gh-release / createRelease returns zero hits — the new flow only pushes git tags.

What changed

scripts/release-tags.sh now ensures three things per released package instead of one:

1. the namespaced git tag,
2. a GitHub Release on that tag, carrying that version's CHANGELOG section as notes,
3. the split-workflow dispatch — mirrored packages only.

Coverage widened beyond mirrored packages

Package	Tag	Release	Split dispatch
core	core-v*	✅	✅
configs	configs-v* (new)	✅	— not mirrored
codemods	codemods-v* (new)	✅	— not mirrored
setup	setup-v*	✅	✅
starter	starter-v*	✅	✅

configs and codemods are npm-published but had no tags at all, so they get their own namespaces with no dispatch. The theme is deliberately excluded — it ships inside webentor-starter and has no independent distribution.

Naming

Release titles come from each package's own manifest name field rather than a hardcoded template. That reproduces the pre-changesets scheme exactly for the npm packages and yields the natural composer analogue for the PHP-only ones:

@webikon/webentor-core@0.15.7        (was: @webikon/webentor-core@0.15.3)
@webikon/webentor-configs@1.1.0
@webikon/webentor-codemods@0.3.1
webikon/webentor-setup@1.1.0
webikon/webentor-starter@2.1.2

Tags keep the <ns>-v<version> form the split workflows key off — only the Release title uses the package name.

Idempotency

The tag and Release checks are independent on purpose: a version whose tag already exists but whose Release is missing gets the Release backfilled on the next run. Merging this therefore creates the five missing Releases for the current committed versions. Split dispatch stays gated on a freshly created tag, so mirrors are never re-pushed.

Historical versions (core-v0.15.4 … 0.15.6) are not covered by this — they need a one-off backfill pass, kept out of this PR since creating Release objects notifies watchers.

Robustness

Changelog slicing tracks code fences, so a future entry containing a fenced # comment cannot silently truncate the notes. No changelog currently has fenced blocks, but a truncated release note fails silently, so it is worth the one extra line.

Verification

DRY_RUN=true bash scripts/release-tags.sh against live origin state:

core-v0.15.7 already exists on origin.
[dry-run] Would create release core-v0.15.7 titled "@webikon/webentor-core@0.15.7".
[dry-run] Would tag configs-v1.1.0.
[dry-run] Would create release configs-v1.1.0 titled "@webikon/webentor-configs@1.1.0".
[dry-run] Would tag codemods-v0.3.1.
[dry-run] Would create release codemods-v0.3.1 titled "@webikon/webentor-codemods@0.3.1".
setup-v1.1.0 already exists on origin.
[dry-run] Would create release setup-v1.1.0 titled "webikon/webentor-setup@1.1.0".
starter-v2.1.2 already exists on origin.
[dry-run] Would create release starter-v2.1.2 titled "webikon/webentor-starter@2.1.2".

• bash scripts/test-release.sh --tags → PASS (the harness already covered this script in dry-run).
• bash -n clean.
• Notes extraction checked against all five changelogs, including the starter's ### heading level and the codemods entry's nested sub-bullets.
• Fence guard verified on a fixture: a # comment inside a fenced block does not end the section, and the preceding version's entry is still correctly excluded.

AGENTS.md "Release Workflow" updated to document all of the above.

https://claude.ai/code/session_015gnVTZywLgQYkM6Epr2uW2