Fix/token permissions id 20260911

[hyperpolymath]

Summary

Changes

RSR Quality Checklist

Required

• Tests pass (just test or equivalent)
• Code is formatted (just fmt or equivalent)
• Linter is clean (no new warnings or errors)
• No banned language patterns (no TypeScript, no npm/bun, no Go/Python)
• No unsafe blocks without // SAFETY: comments
• No banned functions (believe_me, unsafeCoerce, Obj.magic, Admitted, sorry)
• SPDX license headers present on all new/modified source files
• No secrets, credentials, or .env files included

As Applicable

• .machine_readable/STATE.a2ml updated (if project state changed)
• .machine_readable/ECOSYSTEM.a2ml updated (if integrations changed)
• .machine_readable/META.a2ml updated (if architectural decisions changed)
• Documentation updated for user-facing changes
• TOPOLOGY.md updated (if architecture changed)
• CHANGELOG or release notes updated
• New dependencies reviewed for license compatibility (MPL-2.0 / MPL-2.0)
• ABI/FFI changes validated (src/interface/abi/ and src/interface/ffi/ consistent)

Testing

Screenshots

[coderabbitai]

Warning

Review limit reached

Next included review available in 59 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: d12cf17e-81b3-4fea-aa87-b814527961a2

📥 Commits

Reviewing files that changed from the base of the PR and between 58a0a95 and a465947.

📒 Files selected for processing (6)

• .github/rulesets/Immutable-Tags.json
• .github/rulesets/Optimus-Branch.json
• .github/settings.yml
• .github/workflows/dependabot-automerge.yml
• .github/workflows/rhodibot.yml
• .github/workflows/rust-ci.yml

---

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.}

[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

[hyperpolymath]

Closing this PR unlanded, as part of a decision on the whole fix/token-permissions-id-20260911 family (21 PRs). Not a rejection of least-privilege permissions — a decision to fix the generator instead of 21 branches.

Why the family is not landable

The sweep narrows contents: write to contents: read at the workflow level on workflows that genuinely write — git push, gh pr merge --auto, gh release create, create-pull-request. Where the writing job has no permissions: block of its own and authenticates with GITHUB_TOKEN, the narrowing silently removes a permission the workflow needs.

It is silent in the worst way. The diff is valid YAML and fails no check, so the PR shows green; the damage fires on the next write, which may be weeks later and in a different workflow than the one reviewed. Where the push is written git push … || echo "::warning::", a denied push emits a warning rather than a failure and the run stays green forever.

In several files the sweep rewrote the value and left the justifying comment attached to it, so the patch states its own requirement and then removes it:

 permissions:
-  contents: write # needed to enable auto-merge
+  contents: read # needed to enable auto-merge

Root cause — in the rule, not in these branches

hypatia's workflow_audit.ex:463 tests:

Regex.match?(~r/^permissions:/m, content)

anchored at column 0. A job-level permissions: block is indented, so the rule structurally cannot see it. It can therefore only ever rewrite workflow-level permissions, and cannot tell a workflow that needs the write from one that does not. The rule runs across the estate, which is why this arrived as a 21-PR family rather than one bad patch.

The estate already gets this right in three places (standards/signed-push-smoke.yml, KnotTheory.jl/release.yml, gitbot-fleet/inbox-steward.yml), all using per-job elevation — so this is generator inconsistency, not policy.

What happens instead

• The narrowing is not reverted. Least privilege at the workflow level is correct and is kept.
• The family will be regenerated once the anchored regex is fixed, with the write scope elevated per job on the jobs that actually write. When a job-level block is added it must restate every scope the job was inheriting, because a job-level permissions: block replaces the workflow-level block rather than merging with it.
• Two default branches already broken by the landed sweep are repaired directly, under a narrower ruling: fix(ci): restore the write scope Dependabot auto-merge needs, per job rsr-template-repo#91 (the scaffolding template, so the defect propagates) and fix(ci): restore the write scope the release job needs, per job smtp-notify-action#17 (fails only after an immutable tag is published, leaving a tag with no release).

Nothing here is lost: the intended permissions hardening is deferred to a correct generator, not abandoned.

🤖 Generated with Claude Code

https://claude.ai/code/session_014QN8x5x4kNKY8EYCFsCmWB