Fix: Inherit caller permissions in reusable release workflow (fixes #17)

[swashbuck]

Fixes #17

Fix

• The reusable release workflow no longer declares permissions on its release job, so the job inherits whatever the calling workflow grants. Callers that follow the documented permissions block can start again; callers publishing to GitHub Packages keep working by granting packages: write themselves.
• Corrected the README note that said publishing fails with a 403 when the caller omits packages: write "even though the reusable workflow declares it". The reusable workflow no longer declares it.

Background

packages: write was added to the job in #9 so GitHub Packages publishing would work. GitHub does not let a called workflow's job request more permissions than the caller grants, so every caller using the four documented permissions was rejected before any job was scheduled, with a startup failure and no logs. adapt_framework has not released since 13 April 2026 for this reason.

Testing

1. Merge, then push any commit to master in adapt_framework, whose caller grants contents, issues, pull-requests and id-token only. The Release job should now start and run semantic-release, rather than ending as a startup failure.
2. For a repo publishing to GitHub Packages, confirm a caller granting packages: write in addition still publishes successfully.

Note

The job permissions block was added in b54bf20 to satisfy a code scanning alert about a workflow without a permissions block. That alert may reappear for this file and need dismissing, since a reusable workflow cannot safely pin its own permissions.

---

Posted via collaboration with Claude Code