fix(release): restore win32-x64 binary (Socket Firewall breaks pnpm install on Windows)

[ajag408]

Summary by CodeRabbit

• Chores
  • Updated repository ownership settings to reflect current maintainers.
  • Improved the release pipeline so dependency installation works more reliably across Unix-like and Windows build environments.

The win32-x64 leg of build-binaries failed at pnpm build with 'rslib' is not recognized as an internal or external command.

Root cause: sfw pnpm install (Socket Firewall) silently no-ops on the Windows runner — node_modules is never created — so the subsequent build can't find rslib (or any local bin). The 3 Unix legs (linux-x64, darwin-arm64, darwin-x64) are unaffected; Socket Firewall's sfw wrapper only breaks pnpm install on win32.

Fix: run Socket Firewall on the Unix legs only; do a plain pnpm install --frozen-lockfile on win32.

QA Proof

Root cause isolated with a throwaway workflow_dispatch/push debug workflow on Windows, changing exactly one variable (the sfw wrapper):

Install on win32	node_modules/.bin	pnpm build	pnpm exec rslib build	pnpm build (bash)
pnpm install (no sfw)	rslib.cmd present	✅	✅	✅
sfw pnpm install	missing (node_modules absent)	❌	❌	❌

• Failing run logged WARN Local package.json exists, but node_modules missing, did you mean to install? — confirming sfw skipped the install entirely.
• Environment cleared as causes: Node 24.17.0, pnpm 10.33.1, corepack 0.35.0, default shell (pwsh) — all build fine without sfw.
• The last successful release (v1.2.5) built the same rslib@0.0.11 on Windows under the pre-hardening workflow, confirming this is a regression from the sfw addition, not a toolchain issue.

Security Tradeoff

• --frozen-lockfile ⇒ all 4 platforms resolve the identical dependency set, which Socket Firewall already scans on linux + darwin×2 ("Nothing to report").
• onlyBuiltDependencies: [esbuild] applies on every platform alike.
• The supply-chain-sensitive publish job still runs under sfw, unchanged.
• Socket Firewall on these jobs runs free edition anyway (no API key reaches non-production jobs) — consistent with the monorepo baseline, which uses free-edition sfw everywhere and passes no API key.
• Net: win32 installs the same vetted, frozen deps; firewall coverage is lost only on the Windows install of an already-gated set.

What Needs to Be QA'd (release re-tag run)

• All 4 build-binaries legs green; win32 produces shield-windows-x64.exe + .sha256 with attestation
• create-release attaches all 4 binaries + checksums
• security-audit passes; harden-runner egress shows only expected hosts
• Resume hardened-release verification runbook: npm provenance, gh attestation verify per platform, shasum -c, functional smoke on the released artifacts
• Cross-artifact consistency: npm provenance SHA == binary attestation SHA == tag commit

QA Team Notification

• N/A for staging — validation is the v1.3.0 re-tag release run; npm publish gated behind production environment approval

Follow-ups (out of scope)

• Report sfw-breaks-pnpm-install-on-Windows to Socket
• Decide whether to adopt authenticated Socket org-wide (monorepo currently runs free edition with no API key)
• Optionally pin macOS runners (macos-14 / macos-13) instead of macos-latest for release reproducibility

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR updates CODEOWNERS ownership for .github/ and supply-chain-critical files, and changes the release workflow so Unix-like runners use sfw pnpm install --frozen-lockfile while Windows runners use pnpm install --frozen-lockfile.

Changes

CODEOWNERS ownership

Layer / File(s)	Summary
Ownership rules .github/CODEOWNERS	CODEOWNERS updates the .github/ owner list and the supply-chain-critical file rules.

Release workflow install

Layer / File(s)	Summary
Platform-specific install .github/workflows/release.yml	build-binaries runs sfw pnpm install --frozen-lockfile on Unix-like runners and pnpm install --frozen-lockfile on Windows.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• stakekit/shield#10: Also changes .github/CODEOWNERS owner assignments.
• stakekit/shield#20: Also updates CODEOWNERS coverage for supply-chain-critical files such as .npmrc, package.json, and pnpm-lock.yaml.
• stakekit/shield#27: Also changes .github/workflows/release.yml around the build-binaries install path for Windows runners.

Suggested reviewers

• Philippoes
• jdomingos

Poem

A bunny hopped by with a CODEOWNERS grin,
then split the install where the runners begin.
One trail said sfw, one trail said pnpm,
and the release path went thump-thump again.
🐰✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main fix: changing Windows release installs to avoid Socket Firewall breaking pnpm install and restoring win32-x64 binaries.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-win32-socket-firewall

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

220-226: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Gate the Socket setup step on the same platform check. The Windows leg still invokes socketdev/action and receives SOCKET_SECURITY_API_KEY; add if: matrix.platform != 'win32' here too so Socket Firewall stays Unix-only.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 220 - 226, The Socket Firewall
setup is still running on the Windows job, so update the Socket-related workflow
step in the release pipeline to use the same platform guard as the Unix install
path. Add the matrix.platform != 'win32' condition to the step that invokes
socketdev/action and consumes SOCKET_SECURITY_API_KEY, keeping the Socket setup
Unix-only and aligned with the existing install steps.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/release.yml:
- Around line 220-226: The Socket Firewall setup is still running on the Windows
job, so update the Socket-related workflow step in the release pipeline to use
the same platform guard as the Unix install path. Add the matrix.platform !=
'win32' condition to the step that invokes socketdev/action and consumes
SOCKET_SECURITY_API_KEY, keeping the Socket setup Unix-only and aligned with the
existing install steps.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d4ea42b1-e8e3-4db3-92ec-8a96c84389b7

📥 Commits

Reviewing files that changed from the base of the PR and between f9b0f49 and e967890.

📒 Files selected for processing (2)

• .github/CODEOWNERS
• .github/workflows/release.yml