sec(2157): the sync mints write only for the mode that writes

[LukasWodka]

What

Last of the four mints in backend#2157. standards-sync.yml minted the App's entire permission set across every repo the installation covers.

Why conditional, not a union

This workflow has two modes with genuinely different needs:

• report (schedule) — reads every repo's CLAUDE.md and classifies it. Reads only.
• --create-prs (manual dispatch) — PUTs CLAUDE.md and POSTs a branch ref in each drifted repo. Needs contents: write fleet-wide.

Scoping to the union would keep fleet-wide contents: write on every scheduled report — which is the mismatch, not the fix. So the contents scope follows the mode:

permission-contents: ${{ (github.event_name == 'workflow_dispatch' && inputs.create-prs == true) && 'write' || 'read' }}permission-pull-requests: readpermission-issues: write

On a schedule run inputs is empty, the condition is false, and the same job gets read.

Derived from the calls this token makes, one at a time

call	scope
git/ref/heads/develop, repos/{r}, contents/CLAUDE.md?ref=	contents: read
PUT contents/CLAUDE.md, POST git/refs — create-prs only	contents: write
gh pr list	pull-requests: read
gh issue comment 1602 (the drift report)	issues: write

Not pull-requests: write — pr create and both pr edit calls run on SYNC_PR_AUTHOR_TOKEN, not on this token (backend#2590). The App only lists.

Two corrections to what I said on the ticket earlier

Both from reading the file rather than my own summary:

1. The minting job is gated on schedule || workflow_dispatch (job-level if:), so it never minted on push/pull_request/issues at all. The exposure was real, but narrower than the "nearly every run" I claimed.
2. == true rather than a bare truthiness test, matching the CREATE_PRS line below it. Equivalent for a type: boolean input — but if it ever became a string, 'false' is truthy and this would mint write on every scheduled run while still looking conditional.

Closes the set, but carries no closing keyword

With #349, #352 and #353, this empties EXEMPT entirely: 4 unscoped mints and 4 exemptions → 0 and 0.

Deliberately no Closes keyword: merge order is not guaranteed, and if this landed first it would close #2157 with three mints still open. Close the ticket by hand once all four are in.

Test plan

• make lint — clean
• make selftests — 29 passed, 0 failed
• actionlint — clean (the expression parses)
• make mint-scope — 3 unscoped / 3 exempted / 0 findings on this branch alone
• Live: the next scheduled report exercises the read arm; a create-prs: true dispatch exercises the write arm. The write arm is the one that cannot be rehearsed without opening real PRs — so it should be dispatched deliberately, watched, and not left to the cron.

Part of tracebloc/backend#2157

---

Note

Medium Risk
Changes fleet-wide App token permissions for a workflow that writes repo contents in one mode; a wrong condition could break remediation or over-mint write on scheduled runs.

Overview
Scopes the org-standards sync workflow’s GitHub App installation token so scheduled report runs mint contents: read only, while a manual workflow_dispatch with create-prs: true mints contents: write for the fleet CLAUDE.md push path. The step now sets explicit permission-pull-requests: read and permission-issues: write (drift report on issue 1602), with == true on the boolean input so a future string 'false' would not silently grant write.

Completes the mint-scope burn-down by removing the last standards-sync.yml row from EXEMPT in scripts/mint-scope.py, leaving an empty map that still flags any re-introduced full-grant mints.

^{Reviewed by Cursor Bugbot for commit 785465b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saadqbal]

Conditional rather than union is the right shape here — a union would have kept fleet-wide contents:write on every scheduled report, which is the mismatch and not the fix.

I went to check inputs.create-prs == true for the classic trap and found you'd already reasoned it out in the comment. Worth stating the direction explicitly, because it's the whole point: the input is type: boolean today so == true is exact, and if it ever became a string, == true fails to read (write denied, create-prs breaks loudly) while a bare truthiness test fails to write — 'false' being truthy — minting fleet-wide write on every scheduled run while still looking conditional. You picked the direction that fails closed on a permission. That's the correct trade and the comment should survive any future refactor.

Confirmed pull_request and push events also land on read, since the condition pins github.event_name to workflow_dispatch. 👍

[saadqbal]

Re-approving. My earlier stamp was dismissed by the develop merge; I checked what moved rather than assuming — bdd979cd came in from develop, and the PR's own diff picked up scripts/mint-scope.py: the standards-sync.ymlEXEMPT row removal and the prose rewrite. Both belong here, since scoping the workflow without dropping its row would fail the staleness check.

The conditional permission-contents I verified last time is unchanged, and the == true reasoning still reads correctly against the type: boolean declaration.

One thing for the pair.#352 rewrites the same comment block and the same dict, mirror-image to this one: it says "the ONE left … standards-sync", this says "the ONE left … fr-gate". Each holds only while the other is open. So whichever lands second conflicts here — and if that resolution keeps the other's EXEMPT row, mint-scope fails on stale, which is the correct direction and is caught. What isn't caught: once both land, EXEMPT is {} while the surviving prose still says one exemption remains. The guard looks for rows that no longer mint, not for prose describing rows that don't exist. Best fixed in the second PR's conflict resolution — turn "the ONE left" into the retrospective of all four.

Given "a stale exemption is cover for the next unscoped mint in that file" is the thesis, ending the burn-down with a stale description would be a slightly ironic place to stop. 👍

[LukasWodka]

Re-requesting review: develop moved under this branch when #352 merged, and the merge conflicted in scripts/mint-scope.py's EXEMPT map.

The conflict was real rather than textual. #352 scoped fr-gate and left standards-sync as the last exempt row; this branch scopes standards-sync and left fr-gate as the last row. Each side was right about its own workflow and stale about the other's only because it was written first.

Resolved to EXEMPT = {} — the state both sides were walking toward. Taking either row verbatim would have re-exempted a workflow that is now scoped, which stale_exemptions would then correctly report as a finding.

Measured on the merged tree rather than asserted: mint-scope.py reports 17 mint steps across 37 workflow files, 0 unscoped / 0 exempted / 0 findings. make check green (29 selftests passed, 0 failed).

The prose above the map is rewritten to say the burn-down is complete and that an empty map is not an inert one — stale_exemptions still compares against the live unscoped set, so a re-introduced full-grant mint has no row to hide behind. It also says not to add a row back to green a red run.

[saadqbal]

Re-approving — and the prose resolution is better than what I asked for. I suggested turning "the ONE left" into a retrospective; "NONE ARE LEFT, and that is a burn-down completing rather than a list being deleted", with both windows and their reasons named, is the version that will still make sense to someone reading it cold in six months.

The part I'd have missed if you hadn't written it: AN EMPTY MAP IS NOT AN INERT ONE. I checked it rather than taking it, because an empty collection quietly disabling a guard is the exact shape of bug I've been finding elsewhere this week — and here it's the opposite. EXEMPT: dict = {} with offenders = [w for w in unscoped if w not in _exempt()] means an empty map is the guard's strictest state: every unscoped mint is an offender, with no row to hide behind. stale_exemptions correctly reports nothing, since there's nothing that could go stale. So the burn-down ends with the check tighter than it started, and the comment says so where the next person will look.

Green, no threads, and the #352 conflict resolved cleanly. 👍