write scope is enumerated and conditioned, not forbidden

AGENTS.md's Security section stated one rule where the repository needs two. What must be absolute is that no credential is stored — not in the repository, its settings, or an environment. What a job's run token may do is a separate question, and collapsing the two forbade every job that writes anything while protecting nothing extra: the reason the section gives is that a verdict must not be forgeable by what a contributor submits, and a job that fires only after merge and publishes prose is not reachable by that.

Write scope is therefore permitted under four conditions, all four required: push to a protected branch and never pull_request; publishing rather than adjudicating, with no required check, registry, protected setting or claim class downstream; the run token rather than a stored credential; and the grant written on the job rather than as the workflow default. The jobs holding it are enumerated in that section, and the enumeration is the protection — the same shape as the specification list in tests/path_gate.py, and reviewable for the same reason.

wiki-sync is the first such job. Nothing else in the repository holds write scope, and merging stays with GitHub's auto-merge under branch protection.

tests/workflow_scope.py enforces it, in the python job: conditions 1, 3 and 4 over every workflow, both of the enumeration's failure directions, and condition 2 in the one form a script can see — a write-granting job's context is not a required check. That nothing consequential is downstream of what such a job writes stays a review matter, and the section says so rather than implying the gate reads intent.

Source: the maintainer's ruling during the wiki-in-repo and sync round, on the conflict that round filed rather than absorbed.