ci: harden release workflow secrets

[Astro-Han]

Summary

Harden the #977 PR-C release workflow slice: reduce the default build.yml token permissions, keep write scopes only on release-writing jobs, move macOS certificate import after dependency install/build checks, and clean up the Apple API key file after the last notarization use.

Why

The release workflow previously granted contents: write at the top level, so read-only selector work inherited a broader token than needed. It also imported the macOS signing certificate before bun install, bun run build, and the runtime import guard, widening the unlocked-keychain window around dependency and build-time code.

Related Issue

Closes part of #977.

Human Review Status

Pending

Review Focus

Please focus on GitHub Actions release semantics: job-level permissions replacement, actions: read remaining on build-electron for cross-run artifact download, certificate import still running during finalize for DMG signing, and the phase gates on Apple API key cleanup.

Risk Notes

• build-electron still carries contents: write for all phases because the job owns submit/finalize/full publishing paths; splitting the job by phase is intentionally out of scope for PR-C.
• The signing certificate cleanup is unchanged and still relies on the ephemeral GitHub runner. This PR shortens the pre-signing exposure window but intentionally leaves the keychain unlocked after cert import. In finalize, cert import still runs before the notarization wait because the same shared job path is used; narrowing that further would require splitting cert import/re-import or keychain cleanup around the DMG signing step.
• finalize intentionally still imports the signing certificate. The app re-sign is skipped with --config.mac.sign=./script/skip-mac-sign.cjs, but electron-builder.config.ts keeps dmg.sign: true, so the DMG packaging step still needs a signing identity.
• dev-dep-audit currently fails on existing lockfile advisories (34 vulnerabilities: 1 critical, 33 high). This is the known non-required visibility check added by PR ci: harden dependency audit checks #990; the live dev-merge-gate ruleset does not include dev-dep-audit.
• Full release smoke was not run locally because it requires GitHub-hosted macOS release secrets and notarization.
• Screenshots/recordings skipped: no visible UI changed.

How To Verify

RED check: failed for the expected release workflow contract mismatch before the workflow edit
Command: bun test test/github/build-workflow.test.ts
Result: release workflow configuration test failed because top-level permissions were still actions:read + contents:write

Focused workflow tests: 8 passed
Command: bun test test/github/build-workflow.test.ts test/github/bun-version-workflow.test.ts

Whitespace check: passed
Command: git diff --check

Static sanity: passed
Command: rg -n 'permissions:|contents: write|actions: read|Import code signing certificate|Delete Apple API Key|apple-api-key\.p8' .github/workflows/build.yml
Result: top-level permissions are read-only, only create-snapshot-tag/build-electron/cleanup-snapshot-tag declare contents:write, and both API key cleanup steps delete the fixed runner temp key path.

Ruleset readback: passed
Command: gh api repos/Astro-Han/pawwork/rulesets/15292177 --jq '{name,enforcement,required: [.rules[] | select(.type=="required_status_checks") | .parameters.required_status_checks[]?.context]}'
Result: required contexts are analyze-js-ts, e2e-artifacts, smoke-macos-arm64, typecheck, unit-app, unit-desktop, unit-opencode, unit-ui; dev-dep-audit is not required.

PR CI readback: expected advisory failure only
Result: required CI checks passed on the first PR head; dev-dep-audit failed with the existing 34 lockfile advisories from PR #990's non-required visibility check.

Screenshots or Recordings

Not applicable. No visible UI changes.

Checklist

How to use this checklist:

• Tick a box by replacing [ ] with [x]. Do not edit, add, or remove items.
• The bot-applied label items can only be honestly ticked AFTER the PR is opened and the labeler / priority-triage bots have run — return to the PR description and tick them then.
• Most items are required. The few that are conditional are explicitly marked (conditional); for those, leave unticked if they truly do not apply and explain why in Risk Notes. All other items must be ticked before requesting human review.

• Type label — this PR carries exactly one of bug, enhancement, task, documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.
• Routing labels — this PR carries at least one of app, ui, platform, harness, ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.
• Priority label — this PR carries exactly one of P0, P1, P2, P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.

[coderabbitai]

Warning

Review limit reached

@Astro-Han, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 18 minutes and 23 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 4a9e2076-889c-4548-acd6-fa7b979c7381

📥 Commits

Reviewing files that changed from the base of the PR and between d358b18 and cfedcaa.

📒 Files selected for processing (2)

• .github/workflows/build.yml
• packages/opencode/test/github/build-workflow.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/i977-pr-c-release-hardening

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

Suggested priority: P3 (only low-risk paths changed (.github/workflows/build.yml, packages/opencode/test/github/build-workflow.test.ts)).

P1/P0 are reserved for maintainer confirmation. Please relabel manually if this is a release blocker, security issue, data-loss risk, or updater/runtime failure.

[gemini-code-assist]

Code Review

This pull request updates the release workflow tests in build-workflow.test.ts to verify new steps, including dependency installation, certificate importing, Apple API key cleanup, and notarization submission/finalization. It also refines the assertions for job permissions. The review feedback suggests ensuring that steps like installDependenciesStep, submitNotarizationStep, and finalizeNotarizationStep are explicitly asserted as defined before checking their index order to prevent silent test gaps or unclear failures. Additionally, a redundant assertion checking that the submit step's condition does not contain 'full' should be removed as it is already covered by an exact-match assertion.

[Astro-Han]

Review follow-up:

• Addressed the Gemini inline test-contract comments in 236a0b2 by asserting the referenced workflow steps exist before index comparisons and removing the redundant submit-phase full negative assertion. The three review threads are resolved.
• Confirmed dev-dep-audit is not part of the active dev-merge-gate required contexts. Its failure is the known PR ci: harden dependency audit checks #990 visibility-check failure on existing lockfile advisories (34 vulnerabilities: 1 critical, 33 high), not a new failure from this release workflow change.
• Updated the PR body and [Task] CI hardening: 2025/2026 best-practice audit follow-up #977 with the finalize certificate rationale: app re-signing is skipped in finalize, but DMG signing still needs an identity because dmg.sign: true remains active. Further shrinking the post-import keychain window would be a separate follow-up because it requires keychain cleanup/re-import around DMG packaging rather than the current PR-C minimum.