ci: require reviewer approval before npm publish (GIT-94) - #29
Open
nTEG-dev wants to merge 1 commit into
Open
Conversation
The hold on releasing was an instruction. An instruction-only hold on an irreversible action has no failure signal: nothing physically prevents the action, so nothing reports when it happens without the approval. That is scar b6fa8f3c — a gate triggered only by human intent has no failure signal between uses — applied to release authority rather than to a test harness. v1.8.0 is the demonstration. The content was ruled and the gate was green, but the mechanical tier everyone assumed existed did not: `git tag` and `git push` had been allowlisted months earlier, so the tag reached the registry with no confirmation step anywhere in the path. Whether or not any individual release was authorised, a path where authorisation cannot be independently verified is the defect. Binding publish to a protected GitHub Environment makes a tag build but wait. npm publish then requires a named reviewer to approve the deployment in the GitHub UI — outside the CLI, outside any client's allowlist, and unaffected by what an agent is permitted to run locally. SETUP REQUIRED — this is inert until the environment exists: Settings -> Environments -> New environment -> "npm-production" -> Deployment protection rules -> Required reviewers -> add Chris Until then the job names an unprotected environment and publish proceeds as before, so merging this alone does not close the hole. The GitHub-side step is the fix; this commit is the wiring. Co-Authored-By: Claude Opus 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Do not merge without reading the setup step — this is inert until an environment exists in GitHub.
Why
The hold on releasing gitmem was an instruction. An instruction-only hold on an irreversible action has no failure signal: nothing physically prevents the action, so nothing reports when it happens without the approval.
That is scar
b6fa8f3c— a gate triggered only by human intent has no failure signal between uses — applied to release authority instead of to a test harness. It was filed two days ago about the clean room. It describes this.v1.8.0 is the demonstration. Content was ruled, the gate was green on the packaged artifact, and the tag still reached npm with no confirmation step anywhere in the path —
git tagandgit pushhad been allowlisted months earlier. Whether or not any individual release was authorised, a path where authorisation cannot be independently verified is the defect.What changes
publishbinds to a protected GitHub Environment. A tag then builds but waits: npm publish requires a named reviewer to approve the deployment in the GitHub UI — outside the CLI, outside any client's allowlist, and unaffected by what an agent is permitted to run locally.Setup required — merging alone does NOT close the hole
Until that exists, the job names an unprotected environment and publish proceeds exactly as before. The GitHub-side step is the fix; this PR is the wiring.
Worth doing in the opposite order: create the environment first, then merge. That way there is no window where the workflow claims a gate it does not have.
Not in this PR
permissions.askforgit push/git tag/npm publish— applied locally to.claude/settings.local.json(gitignored, not committable)🤖 Generated with Claude Code