[scuttletoby]

Why

The first run of Fork follow upstream (started by hand right after FORK_PUSH_TOKEN moved into the fork-push Environment, #36) ended in startup_failure with no log. Cause: its release job grants actions: read, but fork-release.yml's tests job asks for actions: write (for fork-tests.yml's fleet_watch). GitHub refuses a run whose called workflow asks for more than the caller grants, even for a job that would be skipped. fork-release.yml already knew this rule one level down (comment at its tests job); the caller above it was never updated, and nothing could see it because the workflow had never run (the token was missing until now).

Fix

• fork-follow.yml release job: actions: write (with a comment saying why). No job gets more than it already declares: fork-release.yml's top level keeps its other jobs at actions: read.
• New fork-reusable-permissions.test.py: walks every fork-*.yml and its local reusable calls (nested too) and fails when a called job asks for more than its caller grants. It first proves itself on made-up workflows (nested, skipped job, {}, write-all). Listed in .github/fork-ci-tests.txt.

Red on the old file, green on the fix:

FAIL .github/workflows/fork-follow.yml:release -> .github/workflows/fork-release.yml job tests asks actions: write > read (caller grants less)
ok   every called fork workflow asks for at most what its caller grants

State question

Runs again / stops half-way / old state: the change is only a token grant and a static test; fork-follow's own plan (none / release / rebase / advance / stage) handles reruns as before. Nothing has been pushed by fork-follow yet, so there is no half-done state to meet.

General vs project

General: the test checks any fork workflow's reusable calls; no project facts.

🤖 Generated with Claude Code

[scuttletoby]

lens: correctness+security (follow perms) · reviewer: opus high (t3lens66) · read at: 751b379

covered: fork-follow.yml, fork-release.yml, fork-tests.yml, release-desktop.yml read at head; the diff; the new test; fork-ci-tests.txt and how fork-tests runs it.

checks:

• Cause: run 43572280371 ran on 9834ae7. There release granted actions: read, and fork-release.yml tests asked for actions: write (added in fork: Fork tests on the repository's own fleet runners, chosen per run (CI_RUNNERS) #13 the same day). GitHub refuses a called job that asks for more than its caller grants before any job starts, even when that job would be skipped. That matches startup_failure with no log. The move into the fork-push Environment is not a start-up cause: environment: fork-push is a literal on the normal jobs plan and advance, not set from env, and the uses: job has no environment. I proved it with the new test: it FAILs on the old fork-follow.yml and passes at head.
• Other reasons it could still fail to start: none found. I checked every local call statically (fork-follow -> fork-release -> fork-tests and 4x release-desktop). No input is passed that the callee does not declare, no required input or secret is missing, no boolean/string type mismatch, and no secret is passed that the callee does not declare (13 by name at each step, no secrets: inherit). Nesting is 3 levels, well under GitHub's limit. Each if: on a uses: job is a valid job-level if. Concurrency groups differ (fork-follow / fork-release / fork-tests--), so a caller and its callee cannot block each other. Every callee job without its own permissions inherits a top level of read or less, and that is within the new grant. Not live-proven: fork-release has never run through workflow_call either, so the next scheduled or dispatched run is the first real test.
• Security: GitHub uses each job's own permissions, so the higher grant only lets jobs that ask for actions: write get it: fork-release tests and fork-tests fleet_watch. Every other job under the release call stays at its workflow's top level (read, or contents: write for publish only, as before). In a release run (inputs.ref set), the route step is skipped, so fleet_watch is 'false' and the job never runs. When it does run, it checks out only fork-fleet files from the caller's commit, not the candidate. fork-follow runs only on schedule or workflow_dispatch from the series branch. No pull-request code reaches this token. FORK_PUSH_TOKEN is not passed to the release call (secrets by name, no inherit). Only the plan and advance jobs in fork-push can read it. The guard job still refuses a repository-level copy.
• Test file: listed in fork-ci-tests.txt and run by fork-tests workflows (fork-ci-tests.cjs runs it with python3, and PyYAML is installed when missing). Run locally with GH tokens unset: selftest 4/4 ok, tree ok, exit 0. Model: job permissions, then the callee's top level, then the inherited grant; {} maps to none, read-all/write-all expand, @ref is stripped, a missing file is a problem, remote calls are skipped. Mutation runs: removing the check, ignoring job permissions, breaking write-all, or removing the walk into callees each fail the selftest. Three mutations still pass it (findings 1-2).
• What happens when this runs again, stops half-way, or meets existing/old/empty state (rerun, half-applied, legacy data, empty history)? Empty history: on the first-ever run, the release job is validated even when skipped (action advance/none). That was the failure, and it is fixed. Rerun: a startup_failure run cannot be re-run; a new dispatch or schedule uses the merged file, and guard still ties plan to the attempt. Half-way: this diff does not change the order of release, publish and advance. Old state: none; this is a pure permission change, and the test is read-only, uses a temporary folder and has no state.

finding: minor · .github/scripts/fork-reusable-permissions.test.py:116 · The selftest never proves the second-level (leaf) check. Case 1 already fails at the first level (mid tests asks actions: write while the caller grants read), and leaf never exceeds what mid grants. Failure scenario: change line 76 to check only len(chain) == 1, and the selftest and tree check still pass, so a regression that drops nested checking would ship green. The real tree depends on that level (fork-release -> fork-tests fleet_watch). Fix: add a case where the first level is within the grant but leaf asks for more (for example, mid tests grants contents: read and leaf asks contents: write).
finding: minor · .github/scripts/fork-reusable-permissions.test.py:75,128 · Two rules have no case that proves them. (a) A callee job with no permissions inheriting the callee's top level: replace (top if top is not UNKNOWN else granted) with granted and everything still passes, which would miss a callee whose top level asks for write. (b) {} versus not set: make {} return UNKNOWN and case 3 still fails for the other reason (the caller's top level, read, is used). Failure scenario: either rule regresses silently. Fix: add a case for each.
finding: minor (plausible, not verified on GitHub) · .github/scripts/fork-reusable-permissions.test.py:70-76 · The callee's own top-level permissions is compared only through jobs that inherit it. A callee whose top level asks for more than the grant, while every job sets lower permissions, passes here. I believe GitHub can also refuse that ("The workflow is requesting ..."). Separately, a caller with no permissions anywhere (UNKNOWN) skips its whole subtree silently, line 52. Today every fork-*.yml has top-level permissions and no callee's top level is above its grant, so no live impact. Fix: also compare top with granted when chain is set, and FAIL (rather than skip) when a root that calls other workflows has no permissions.

findings: blocker 0 · major 0 · minor 3

verdict: SAFE. The change is correct, the cause matches, and I found no other start-up blocker. The extra grant reaches only the two jobs that already declared it, and neither runs candidate or PR code in a release run. The minor findings are test-strength gaps and can follow in a later PR.

[scuttletoby]

lens: correctness+security (follow perms) · reviewer: opus high (t3check66) · read at: 5d084d7

covered: the fix diff 751b379..5d084d7 (test file only); the test file in full at head; the top-level and job permissions of fork-follow.yml, fork-release.yml, fork-tests.yml and release-desktop.yml at head; round-1 findings in #66 (comment).

checks:

• Run at head (python3 -B, GH tokens unset, fresh clone): selftest 8/8 ok, tree ok, exit 0. The real fork workflows still pass: fork-follow release grants actions+contents write; fork-release top (actions read, contents read) and fork-tests top (contents read) are within it; release-desktop top (actions read, contents read) is within what fork-release's desktop jobs get.
• Round-1 finding 1 (leaf level never proved): fixed. Case "only the second level asks more" fails when the job check is limited to the first level (mutation run: selftest FAIL, exit 1).
• Round-1 finding 3 (callee top level; caller with no permissions): fixed. New top-level check (lines 71-73) is proved by case 6: removing it fails the selftest. New "calls ... without permissions" rule (lines 88-90) is proved by case 8: removing it fails the selftest. Both match GitHub: a called workflow's top level is checked against the caller's grant ("The workflow is requesting ..."), and a job's own permissions win over its workflow's top level.
• Round-1 finding 2: (b) {} fixed, case 7 fails when {} is read as "not set" (mutation run: FAIL). (a) only half fixed, see finding 1.
• Can the new rules fail a valid setup? Only the "no permissions anywhere" rule can: GitHub would accept such a caller with the repository default. That is intended (the check cannot know the default), it only applies to a fork-*.yml job that calls a local workflow, and every such job at head has permissions. Callees never hit it, because they always get a known grant. {} grants nothing and is not treated as "not set". No false failure found in the real tree.
• Can a real startup_failure pass? Not for the shapes in the real tree today. Two rules have no selftest case that would catch a regression (findings below); remote uses: calls and non-fork-*.yml roots are still out of scope, as before.
• What happens when this runs again, stops half-way, or meets existing, old or empty state? Again: same result, the test is read-only and every case uses its own temporary folder. Half-way: nothing is written, so nothing is left behind. Old state: a future fork-*.yml that calls a local workflow without any permissions now fails here, on purpose, with a clear message. Empty: a workflow with no jobs or no permissions is handled (UNKNOWN, no crash).

finding: minor · .github/scripts/fork-reusable-permissions.test.py:140 · Case 5 says it proves "callee job without permissions takes the callee's top level", but it now fails only through the new top-level check, not through inheritance. Mutation: change line 78 to (top if top is not UNKNOWN and not chain else granted) (callee jobs take the caller's grant instead of their own workflow's top level): selftest 8/8 and tree still pass. Failure scenario: fork-release's desktop jobs have no permissions, so release-desktop is really called with fork-release's top level (actions read). After that regression, release-desktop asking actions: write would pass here (checked against fork-follow's write grant) but GitHub would refuse the run at start-up. Fix: a case where mid's top level is lower than the grant, a mid job with no permissions calls leaf, and leaf asks for more than mid's top level but not more than the grant.
finding: minor · .github/scripts/fork-reusable-permissions.test.py:71 · The new top-level check is proved only at the first level. Mutation: if len(chain) == 1: on line 71: selftest and tree still pass. Failure scenario: a nested callee's top level (like fork-tests under fork-release) asking more than its grant would pass here. Fix: one case where leaf's top level asks more than mid's job grants while every leaf job asks less.

findings: blocker 0 · major 0 · minor 2

verdict: SAFE. Round-1 findings 1, 2(b) and 3 are really fixed, each new guard has a case that fails without it (except as above), the rules match GitHub, and the real fork workflows pass. The two minors are test-strength gaps of the same kind as before and can follow later.

[scuttletoby]

Re-check minors (6874501422) fixed in the same round, commit above:

• Minor 1: the inheritance case now isolates inheritance (callee top level fits the grant; a job without permissions that wrongly took the caller's write-all would let the leaf's actions: write through). Mutation "effective = caller grant" now fails only this case.
• Minor 2: new case: a second-level callee's top level asks more while its jobs ask less. Mutation "top-level check only at the first level" now fails only this case.
  All 9 selftests + real tree ok.