ci(release): inherit secrets so the npm environment token reaches the publisher

[javiertoledo]

The 0.3.1 run got further than the last one — package-release passed, so #59's fix works — and then split:

	Result
GHCR	✅ six images promoted at 0.3.1 and sha-73f88778a5a3
npm	❌ nothing — @theagilemonkeys/facility is absent from the registry
tag	❌ none; record-release needs both publishers

publish-npm / publish failed at Bootstrap the package once with a granular token with NPM_BOOTSTRAP_TOKEN is required for the first package publication, and NODE_AUTH_TOKEN printed blank rather than *** — an empty value, not a masked one.

Why

The token is fine. NPM_BOOTSTRAP_TOKEN exists in the npm environment (created 2026-07-31), the environment allows only main, and the publish job correctly declares environment: npm.

The gap is the reusable-workflow boundary: ci.yml calls release.yml with no secrets: key. A called workflow does not receive environment-scoped secrets by declaring the environment alone — without secrets: inherit on the caller, every environment-scoped secret resolves to an empty string rather than erroring. GitHub's docs omit this; it is tracked in actions/runner#1490 and github/docs#44458.

So the job authenticated with nothing and failed the way it would if the secret had never been created.

Why inherit is not a widening here

• The environment still gates the token: it materializes only in the job naming environment: npm, which keeps the branch policy and approval as the real control.
• gh api repos/theam/facility/actions/secrets and the org-secrets endpoint both return empty — there is nothing else for inherit to forward.
• Explicitly mapping NPM_BOOTSTRAP_TOKEN: from the caller cannot work: the calling job does not declare the environment, so it would forward an empty string too.

publish-images needs no change — it uses GITHUB_TOKEN, which called workflows always receive.

Verification

node --test scripts/*.test.mjs → 88/88. The new test asserts secrets: inherit on the caller and environment: npm on the callee; removing either makes it fail, checked both ways. Both workflows parse, and secrets is accepted on the publish-npm job.

I cannot prove this end to end from a PR — publish-npm only runs on a push to main, so the release run is again the first real exercise.

Before merging

The six GHCR images already carry 0.3.1 from 73f8877. scripts/images.mjs:160 refuses to move an existing tag to a different digest, and .dockerignore does not exclude .github, so rebuilding after this commit may produce different digests and wedge promote. Delete the six 0.3.1 package versions first, so this merge can publish a coherent 0.3.1 to both registries.

Follow-up worth considering, not included here

docs/releasing.md tells maintainers to retry the failed jobs in the same run. That cannot work when the failure is in the workflow itself, since a re-run uses the workflow files from the run's own commit — true for both 0.3.1 attempts. The runbook deserves that caveat.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f6cf4a97b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".