The record's bold sentence said the base-ref checkout means the workflow "cannot be
rewritten by that same PR to weaken its own judgment". That is true of the SCRIPTS the job
executes and false of the workflow itself: Gitea resolves a `pull_request` workflow
definition from the PR's own head, so a PR editing `review-verdict.yml` runs its rewritten
copy — which can delete the checkout outright, or just post `review-verdict/h10=success`
and stop. Branch protection requires the context, not an author, and carries
`required_approvals: 0` (#672).
The scoping already existed further down, under "What is deliberately NOT claimed". That
is not good enough for this particular sentence: it is bold, it is the paragraph a reader
resolving this record from the catalog lands on, and someone who stops there leaves with
the opposite of the truth. A caveat only works if it is reached.
So the headline now says what the checkout binds (the scripts, from the already-reviewed
base) and a following paragraph states the head-resolution hole directly, with the
superseded claim quoted so a reader who remembers it can see it was retracted rather than
wonder whether two records disagree. The later paragraph loses its duplicated opener and
points at it instead.
Docs only; no behaviour change. Same failure class the rest of #649 kept turning up — a
claim stronger than the code — reached this time through prose rather than a test.
Refs #649, #672
Decisions-Edit: yes
timothy