mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-11 13:17:07 +00:00
kevinveenbirkenbachandClaude Opus 5
effbd839c9
Every pull_request run of this workflow has ended in startup_failure - ten of
ten across feature/swarm-nfs, feature/svc-net-tor and feature/ai-agent-employees,
including runs that predate the current work. No jobs, no logs, no check runs,
because run-graph validation rejects the workflow before any job is created:
entry-pull-request-change.yml (Line: 130, Col: 3): Error calling workflow
'ci-orchestrator.yml'. The workflow is requesting 'issues: write', but is only
allowed 'issues: none'.
ci-orchestrator.yml requests issues:write at workflow level (:69) and on its
report-main-failures job (:283). The caller declares an explicit permissions
block listing only actions/contents/packages/security-events, and an explicit
block pins every unlisted scope to none. A called workflow may request only a
subset of its caller's declared set, so the graph is invalid. Introduced by
8b58b67121, a three-caller fan-out where only two callers were patched.
The grant goes on the job rather than at workflow level. Job permissions REPLACE
the workflow block instead of merging with it, so the four existing scopes are
restated verbatim alongside the new one.
Do not move this block to workflow level. That block also governs the
pull_request_target half of this file, whose build-ci-images-fork and
images-mirror-missing-fork jobs check out fork-controlled refs with
allow_unsafe_checkout, one of them with secrets: inherit. Widening that token is
the only way this change becomes a security problem.
The scope itself carries no new capability on this path: report-main-failures is
gated on github.ref == refs/heads/main and is unreachable from a PR ref, forks
get a read-only token for pull_request regardless of the declared ceiling, and
same-repo PR authors already hold issue rights. The block already granted
actions:write and packages:write, both broader than issues:write.
Not provable locally - act does not evaluate nested permission escalation, so
this needs a push to confirm.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>