ci: publish to npm via trusted publishing (OIDC)

[jason-lafferty-cko]

Why

The 5.5.0 release failed in build-release run 36687599619 with 404 Not Found - PUT https://registry.npmjs.org/checkout-sdk-node. That is how npm reports a rejected publish token. The job was still authenticating with the long-lived NODE_AUTH_TOKEN secret, which npm no longer accepts.

The package already has a trusted publisher configured on npmjs.com for checkout/checkout-sdk-node, workflow build-release.yml, environment production. The workflow just never moved over to it.

What

• Bind the deploy job to the production environment and grant id-token: write (plus contents: write for the GitHub release step).
• Remove NODE_AUTH_TOKEN and publish with npm publish --provenance --access public. npm exchanges the GitHub OIDC token with the registry itself.
• Upgrade npm in the job to >= 11.5.1, which trusted publishing requires.
• Move to actions/checkout@v4 and actions/setup-node@v4 on Node 22. The old pins run on Node 20, which the runners now warn is deprecated.

Before merging

• The production environment must exist on this repo so the OIDC claim matches the trusted publisher.

After merging

Re-run the failed 5.5.0 release, or push a package.json change, and confirm 5.5.0 lands on npm with a provenance badge. Once it does, the NODE_AUTH_TOKEN repo secret can be deleted.

🤖 Generated with Claude Code

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-release.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The diff correctly migrates npm publish from a long-lived token to OIDC trusted publishing, with all the necessary permissions, environment binding, and npm upgrade in place. The change is technically sound, but going live depends on the npm trusted publisher configuration matching exactly (package name, repo, workflow, environment).

For you to decide

• The production environment must exist on the GitHub repo AND the npm trusted publisher must be configured with environment: production — if either side is missing or mismatched the publish will still fail with a 403/404.
• npm is pinned to 11.21.0 with --ignore-scripts, which is reasonable for reproducibility, but this pin will silently fall behind security fixes; reviewer should decide if periodic updates are required.
• The registry-url is still set on setup-node (needed for OIDC token exchange via the NPM_CONFIG_USERCONFIG that setup-node writes), which is correct — confirmed the workflow does not also pass NODE_AUTH_TOKEN, so there is no credential conflict.
• Node version bumped from 18 to 22 and checkout/setup-node bumped to v4; these are incidental to the OIDC fix and could affect build output if any dependency or test behaves differently on Node 22 — reviewer should check CI test results.
• The diff is partial (test/build steps not fully shown), so it cannot be confirmed whether the full workflow still passes its integration tests before the publish step.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-release.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[jason-lafferty-cko]

On the advisory points:

• The trusted publisher on npmjs.com is already configured as checkout/checkout-sdk-node, build-release.yml, environment production. The production environment on this repo is being created before merge, tracked in the PR checklist.
• npm is now pinned to 11.21.0 with --ignore-scripts (99350d6).
• actions/create-release@v1 is unchanged here. We can swap it for a maintained action in a follow-up once 5.5.0 is out.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud