docs: require Trusted Publisher grant before first CI publish#129
Conversation
Deploying fs-packages with
|
| Latest commit: |
d8b9e85
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://5e3ca4aa.fs-packages.pages.dev |
| Branch Preview URL: | https://docs-trusted-publisher-gate.fs-packages.pages.dev |
Goosterhof
left a comment
There was a problem hiding this comment.
✅ Approve-worthy
0 blockers · 0 concerns · 0 nits · 1 praise · 0 inline
Round 1 · CI green (check, Cloudflare Pages both pass).
Single-line addition of step 6 to the ## Adding a Package runbook in CLAUDE.md, codifying that the npm Trusted Publisher grant must be wired before a package's first CI publish. Verified against origin/main:CLAUDE.md — the diff appends to the existing 5-step list, and the PR body's scope claim ("adds step 6") matches the hunk exactly with no understatement.
The captured detail is correct and load-bearing: npm masks "no publish permission" as E404 rather than 403, so the failure reads like a missing-package problem when it's actually a missing-grant problem — that's the non-obvious diagnostic that justifies the doctrine entry, and the two-time recurrence (fs-cached-adapter-store; fs-theme/fs-translation) earns the promotion from spy memory into the front-door runbook. Pointing the reader at a known-good template (fs-loading) is the right operational hook.
Automated war-room agent review — posted because this PR carries the Agent Review Requested label.
Review Loop · 10/10 · PASSfs-packages #129 · AC anchor: none (no issue_key / plan_dir / PR AC section) · head Tip No findings — clean against the review checklist. Actionmerge-ready |
jasperboerhof
left a comment
There was a problem hiding this comment.
Auto-approved — review-loop verdict PASS, CI green, no human blocker, no open MAJOR+ threads. See the verdict comment + inline notes.
A manual 0.1.0 bootstrap creates the npm package but not the OIDC Trusted Publisher grant, leaving the package stuck at the bootstrap version with every later CI bump failing E404 (npm masking permission-denied as not-found). Make the per-package TP config an explicit mandatory step in the Adding a Package runbook. n=2: fs-cached-adapter-store (2026-05-27), fs-theme + fs-translation (2026-06-15). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e6bc81c to
d8b9e85
Compare
What
Adds step 6 to the
## Adding a Packagerunbook inCLAUDE.md: wiring the npm Trusted Publisher grant is a mandatory gate before a package's first CI publish.Why
publish.ymlauthenticates purely by OIDC (no stored token). For the mint to carry publish rights, the npm package must have a Trusted Publisher config (GitHub Actions · script-development/fs-packages · publish.yml · env npm-publish).A manual
0.1.0bootstrap creates the package but NOT the TP grant — so without this step the package sits stuck at the bootstrap version and every later CI bump failsE404 PUT … Not found. npm returns 404, not 403, for "no publish permission" (it masks existence), so the error reads like a missing-package problem when it's actually missing-permission. It is structural, not a transient CI bug — re-running won't self-heal it.Recurrence
fs-cached-adapter-store— 2026-05-27fs-theme+fs-translation— 2026-06-15 (both stuck at0.1.0since April; siblingfs-loadingrepublished 0.1.0→0.1.4 cleanly across the same window because it had TP wired)Both resolved by wiring TP, re-running the failed Publish job, and approving the
npm-publishenvironment gate. theme/translation are now live at0.1.1with provenance.🤖 Generated with Claude Code