[aywrite]

resolve_ref.sh takes a pull request number, fetches refs/pull/<n>/head and
builds it. Here that has always been safe: the match workflows are dispatch
only, declare contents: read and name no secret. Nothing enforced any of
that, and the tools this script sits beside are now used outside this
repository, where a pull_request_target wiring would hand a fork arbitrary
code execution with a write token.

The script now refuses unless the trigger is one where the ref was chosen by
somebody who can already push: workflow_dispatch, push, schedule or
release. It also runs when GITHUB_EVENT_NAME is unset, which means it is
not on a runner at all.

pull_request is deliberately not on the list. A fork's pull_request run
gets a read-only token and no secrets, so it is arguably safe, but allowing it
would break the rule the guard states and nothing here needs it.

What it does not check, and why

Not permissions, and not secrets. Neither is readable from inside a job: the
permissions: block is exposed to nothing running there, and a secret is in
the environment only when a step above passes it, so its absence proves nothing
about what else the job could be handed. A script that tested for
GITHUB_TOKEN and called that a permission check would be describing its own
environment and naming it something it is not.

The trigger is readable, and it is the part that carries the risk. The runner
sets GITHUB_EVENT_NAME on every job, an env: block cannot override a
GITHUB_ name, and a workflow entered through workflow_call sees the
caller's event, so the check holds when the release workflow calls
strength.yml.

So the guard does not say the job is unprivileged. A workflow_dispatch
workflow that granted contents: write and passed a secret would pass it.
That is the workflow's to declare, and docs/DEVELOPMENT.md now says so, and
names the permissions: contents: read at the top of both match workflows as
the part a reader has to write for themselves.

288 tests pass, seven of them new. The existing helper now sets
GITHUB_EVENT_NAME explicitly rather than inheriting it, without which the
file would fail in CI, where the tests themselves run under pull_request.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XhA13EsiXpMQ5vea2P3Fc9

---

Generated by Claude Code

[github-actions]

Speed against 69da4704

Both sides built and run on this runner in this job, the way
scripts/speed.sh measures a perf commit. The change is between
medians, and the spread beside it is what the change has to be
read against. The node counts are the search's: they move when
the search does, and a speed change leaves them alone.

round     base nps  candidate nps
    1      7535788        7711769
    2      7632628        7682643
    3      7679929        7674840
    4      7721465        7683177
    5      7736009        7743223
    6      7699415        7681499
    7      7693337        7664638
    8      7667980        7695234
    9      7710908        7672725

             nodes    time  median nps  fastest nps
base       3868987  0.50 s     7693337      7736009
candidate  3868987  0.50 s     7682643      7743223
change                           -0.1%        +0.1%

the change is inside the spread, so the medians make no claim; the
fastest column is the steadier comparison when the machine was not
quiet

Speed: -0.1% (bench nps, 9 interleaved rounds vs 69da4704, spread 2.6%)