ci(cli): dispatch Homebrew tap via primitive-ci GitHub App, not PAT

[prim-8]

Why

The CLI Release workflow's Trigger Homebrew tap update step authenticates to primitivedotdev/homebrew-tap with the HOMEBREW_TAP_BOT_TOKEN PAT. That PAT lacks the contents:write / repository_dispatch permission on the tap, so every release publishes to npm and creates the GitHub tag/release fine, then 403s on the dispatch:

gh: Resource not accessible by personal access token (HTTP 403)
POST repos/primitivedotdev/homebrew-tap/dispatches

Observed on the 1.2.0 release: run 27247901978. npm publish + GH release succeeded; only the tap bump was lost.

What

Switch the dispatch to the org's blessed App-token path, mirroring the tap's own update-formula.yml (homebrew-tap PR #15 — "use GitHub App via OIDC+SM instead of PAT"):

1. OIDC → assume the IAM role (vars.AWS_HOMEBREW_TAP_ROLE_ARN)
2. Pull the primitive-ci App credentials from Secrets Manager (staging/github-ci-app)
3. Mint a short-lived installation token via create-github-app-token, scoped to repositories: homebrew-tap
4. POST the cli-release dispatch with that token

Also drops the silent "PAT not configured → skip" branch, so a misconfigured dispatch fails loudly instead of being masked (which is how this bug went unnoticed). The two new actions are pinned to SHA per repo convention. The workflow already declares id-token: write.

No GitHub secrets

The only sensitive material — the primitive-ci App private key — is pulled from AWS Secrets Manager at runtime; nothing credential-bearing is stored on the GitHub side. The role ARN cannot come from SM (the role must be assumed before SM is reachable), but an ARN is an identifier, not a credential, so it's supplied as a non-secret Actions variable (vars.AWS_HOMEBREW_TAP_ROLE_ARN) rather than a secret. This also keeps the AWS account ID out of the public workflow source.

Required before this can pass (org/AWS admin — not in this PR)

• Set the AWS_HOMEBREW_TAP_ROLE_ARN variable (not secret) on this repo
• Extend that IAM role's trust policy to permit this repo's OIDC subject (repo:primitivedotdev/sdks:*)
• Confirm the primitive-ci App is installed on homebrew-tap with contents: write (it already makes the formula PRs, so this should already hold)

Once green, delete the now-unused HOMEBREW_TAP_BOT_TOKEN secret.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR replaces the broken HOMEBREW_TAP_BOT_TOKEN PAT (which 403'd on every release) with a short-lived GitHub App installation token minted at runtime via OIDC → AWS Secrets Manager → actions/create-github-app-token. It also removes the silent "skip if no token" branch so any credential misconfiguration now fails the workflow visibly.

• Three new steps are added before the Trigger Homebrew tap update step: assume an IAM role via OIDC, pull the primitive-ci App credentials from Secrets Manager, and mint a scoped installation token — all pinned to commit SHAs per repo convention.
• The private key is masked line-by-line with ::add-mask:: before being written to GITHUB_OUTPUT as a multiline heredoc, which is the standard pattern for passing PEM material to create-github-app-token.
• Two concerns flagged in earlier review threads — the staging/github-ci-app Secrets Manager path in a production workflow, and the vars.AWS_HOMEBREW_TAP_ROLE_ARN variable reference that will silently resolve to empty if the admin registers it as a Secret instead of a Variable — remain open and should be resolved before merging.

Confidence Score: 4/5

Safe to merge once the two open thread issues are resolved: confirm the correct SM path for production credentials, and verify the role ARN is registered as a repository Variable (not a Secret) so OIDC assumption doesn't silently fail.

The credential-fetch chain is well-structured and the PAT removal solves the confirmed 403. However, two defects flagged in prior threads are still present in the code: if vars.AWS_HOMEBREW_TAP_ROLE_ARN is registered under Secrets instead of Variables it resolves to empty and the OIDC step fails (or worse, attempts an unauthenticated call), and the staging/github-ci-app path may point at the wrong App credentials for a production release.

.github/workflows/cli-release.yml — specifically the role-to-assume variable namespace and the Secrets Manager secret path used in the credential fetch step.

Important Files Changed

Filename	Overview
.github/workflows/cli-release.yml	Replaces HOMEBREW_TAP_BOT_TOKEN PAT with OIDC→AWS SM→GitHub App token flow; removes the silent-skip branch so misconfigurations now fail loudly. Two issues flagged in prior review threads remain open: the staging/github-ci-app SM path in a production workflow and the vars.AWS_HOMEBREW_TAP_ROLE_ARN vs secrets. namespace mismatch.

_{Reviews (3): Last reviewed commit: "ci(cli): source role ARN from a non-secr..." | Re-trigger Greptile}

[greptile-apps]

Staging secret in production release workflow

The secret path staging/github-ci-app is used to mint the GitHub App token for a production CLI release. If this is intentional (i.e., staging/ is just an AWS Secrets Manager namespace convention shared with the tap workflow), it's fine — but if there's a separate production/github-ci-app secret with different credentials or a scoped installation, this step would silently authenticate with the wrong App and could produce a token that lacks contents:write on homebrew-tap. Is staging/github-ci-app the correct Secrets Manager path for a production release, or does this workflow need a production-scoped credential (e.g., production/github-ci-app)?