fix(release): drop the component/package-name fields that wedge release-please

[forkwright]

Finding

Release Please has aborted every single run since PR #58 merged
2026-07-28T21:12:21Z — a full month, entirely unrelated to today's Actions
outage/billing lockout (hamma is public). hamma has zero git tags and zero
GitHub Releases while .release-please-manifest.json and CHANGELOG.md
both already declare v0.2.0 shipped.

Evidence

gh api repos/forkwright/hamma/tags and .../releases both return [].
PR #58 ("chore: release main") still carries the autorelease: pending
label today — it was never flipped to autorelease: tagged, which only
happens when release-please successfully creates the release.

The run immediately after the merge (id 30399683185, 2026-07-28T21:12:24Z,
conclusion=success) and the most recent run before this PR (id
33002219225, 2026-08-26T18:53:53Z, run after PR #117's healer merged)
both log the identical sequence:

✔ Building releases
❯ Found pull request #58: 'chore: release main'
✔ Building release for path: .
⚠ PR component: undefined does not match configured component: hamma
...
❯ Building candidate release pull request for path: .
❯ Found pull request #58: 'chore: release main'
⚠ There are untagged, merged release PRs outstanding - aborting

Traced against googleapis/release-please v17.6.0 (the pinned action
version) source:

• Manifest.createReleases() → buildReleases() → per-strategy
  buildRelease() (src/strategies/base.ts:640-656) parses the merged
  PR's branch name via BranchName.parse(). hamma's branch is
  release-please--branches--main — matches DefaultBranchName
  (src/util/branch-name.ts), which never sets .component (only
  AutoreleaseBranchName/ComponentBranchName do, neither of which this
  repo's shape produces, since separate-pull-requests: false always
  yields the plain branch pattern).
• That undefined is compared against getBranchComponent()
  (src/strategies/base.ts:191), which returns
  this.component || getDefaultComponent() — ignoring
  include-component-in-tag entirely — and falls back through
  package-name when component is unset. hamma's config set both to
  "hamma", so this always resolves to "hamma".
• "hamma" !== undefined → buildRelease() returns early with no
  release built → createReleases() creates nothing, silently.
• Manifest.createPullRequests() (src/manifest.ts:920-933) then finds
  the same still-autorelease: pending PR chore: release main #58 via
  findMergedReleasePullRequests() and aborts opening a new PR too — the
  exact log line above.

This is not a one-off: every future hamma release PR will produce the
identical component-less branch name, so this wedges every release
forever, not just this one.

Fleet comparison (gh api repos/forkwright/<repo>/contents/release-please-config.json):
akroasis, epistole, harmonia, gnomon, and thumos all carry neither
package-name nor component in their package block, and all have real
tags. hamma is the only one of the six checked that sets both — and the
only one stuck.

include-component-in-tag: false is already set, so removing both fields
changes no observable tag/branch/PR-title format: PR #58's actual body
(<summary>0.2.0</summary>, no hamma: prefix) and branch name were
already component-less before this fix — getComponent() already
returns '' when include-component-in-tag is false. The bug is purely
in getBranchComponent()'s separate, unguarded fallback.

Why this matters

A missing release is worse than a failing one to notice, but this is
actively worse than "release-please is idle": it looks like nothing is
wrong (CHANGELOG.md and the manifest both say 0.2.0 shipped), until
someone tries to depend on hamma via a tagged version, or cargo add --git ... --tag v0.2.0, and there is nothing there.

Desired correction

Remove package-name/component from release-please-config.json's .
package block so getBranchComponent() resolves to the same empty value
the branch name already carries.

Done when: the next release-please run after this merges creates the
v0.2.0 tag + GitHub Release for PR #58 and flips its label from
autorelease: pending to autorelease: tagged, without manual
intervention. This is unverified — see below.

Not verified, and why

I could not run release-please locally (npx/network package execution
is outside what this lane is authorized to do) or dispatch this fix on a
feature branch to test it: the reusable workflow's release-please job
does no repo checkout and reads release-please-config.json from the
main branch via the GitHub Contents API regardless of which ref
triggers the run (confirmed in both run logs above — Fetching release-please-config.json from branch main), so a feature-branch
workflow_dispatch would not exercise this change at all. The diagnosis
above is source-traced against the exact pinned release-please version,
not guessed, but the merge itself is the first real test.

I also verified, and did not perform, the alternative direct fix:
create the v0.2.0 tag at PR #58's merge commit
(6cc5781693ab276cc0f53369c86ac0062087cbf7, confirmed on main via
git merge-base --is-ancestor) and the matching GitHub Release from
CHANGELOG.md's 0.2.0 section — both blocked by this session's own
sandbox policy (direct tag-push and gh release create were both
refused). If the config fix above does not self-heal on the next
run, that manual recipe is the fallback and is fully worked out; it
needs write authority this session doesn't have.

Watch the first release-please run after this merges and confirm the
tag/release/label actually land.

[forkwright]

Merged, and it worked as diagnosed — but it unmasked a second defect, so hamma is still at zero tags. Recording where it stands, because the failure moving is itself the evidence the analysis was right.

Before: every run aborted silently at ⚠ There are untagged, merged release PRs outstanding, having skipped the release on PR component: undefined does not match configured component: hamma.

After — run 33009946044, 2026-08-26T20:21:00Z, the first run post-merge:

##[error]release-please failed: Resource not accessible by integration
- https://docs.github.com/rest/releases/releases#create-a-release

It is now past the component check and genuinely attempting create-a-release. What remains is a token-permission failure at the final step.

What I ruled out, so nobody re-walks it:

candidate	result
caller's permissions: block	contents: write, id-token: write, pull-requests: write
the fleet reusable's own block	contents: write, pull-requests: write
repo Actions setting	default_workflow_permissions=read, can_approve_pr=true — identical to koinon, zetesis, sphragis
caller config drift	diffed against koinon's caller: byte-identical apart from the archive filename
rulesets / tag protection	none on hamma, none on harmonia (control)
repo secrets	none on hamma — and none on harmonia or epistole either
is the reusable broken fleet-wide?	no — harmonia v0.4.2 and epistole v0.2.4 both published today at 14:19Z through this same reusable

So the configuration is indistinguishable from repos that cut releases hours ago, and the difference is not in any of the usual places.

The one asymmetry I could not eliminate: hamma has zero tags and zero releases, where every working repo already had both. Whether creating a repository's first release differs in permission terms is not something I could establish from here, and I would rather name it as an open question than assert it.

Stopping the diagnosis here rather than drilling further. The next step is a permissions probe against the create-release endpoint specifically, not more config comparison.

Do not revert this PR. The component/package-name removal is correct and should stay — reverting returns hamma to a silent abort, which is strictly worse than a loud permission error.