Every finding from the re-review of the round-2 fix.
The round-2 comment fix shipped four line numbers that its own two added lines
invalidated (:186/:456/:617 and :144 were already 188/458/619 and 146 in the
committed file) — "broke a number while fixing numbers", in the commit that was
fixing a number. Root cause: I transcribed them from the review report, which
described the PRE-edit file, instead of re-deriving from the post-edit tree. The
fix is not better numbers: docker-build.yml is ~1150 lines and any edit above a
citation silently invalidates it, so the sites are now named by JOB
(`toolchain-preflight`; `test`/`migrations`/`functional-e2e`), which the YAML
itself defines and an edit cannot shift. Comment says so, so the next editor
does not reintroduce line numbers.
Round 2 split the per-unit warrants in the record but left `docs/ci-cd.md`
asserting the retracted one — one wrong copy became two divergent copies. Both
now state it the same way and per unit: the fence shows `issues: read`; what
shows `pull-requests: read` is the `=success`, reachable only via `complete=yes`.
The ⚠️ was over-generalized in round 1 and over-reassuring in round 2: it said
"the other five are ordinary" and then justified two. Split — docker-build and
pr-checks are `on: pull_request` and ARE exercised by an editing PR; ci-image
(`push`, self-path-filtered), dependency-scan and renovate (`schedule` /
`workflow_dispatch`) are NOT, and their first run is post-merge or next schedule.
`ci-image.yml`'s comment claimed the other five "persist no credential
(`persist-credentials: false`)". `renovate.yml` sets no such key — it persists
nothing because it never checks out. Four of five set the flag.
THE BOUNDARY, not the site. Round 2 fixed the one stale-claim site the review
named. A grep by SUBJECT rather than by the corrected wording found the same
superseded inventory in two more records, both of them ones a future editor
resolves from the catalog when reasoning about forgery routes:
* `ci.gate-trigger-base-resolved` — "Gitea injects GITEA_TOKEN into EVERY job,
defaulting to read/write, so push- and workflow_dispatch-triggered workflows
alike are routes". Now scoped to the workflows that exist today, with the
note that the SHAPE is still open and that is what the new guard covers.
* `release.verdict-status-check` — the same inventory in the H10 gate's own
record.
* `release.main-direct-push-disabled` — dated parenthetical, conclusion
unaffected, corrected in passing.
Guards: `test_..._declares_exactly_the_units_...` now states what it does NOT
catch — it TRANSCRIBES the unit set rather than deriving it from the job's API
calls, so a new `gh` call needing an undeclared unit leaves it green. Same
honesty the sibling expression test already carries. And
`test_every_tracked_workflow_declares_a_permissions_block` gained an
anti-vacuity assert: `tracked_children` matches direct children only, so a moved
`.gitea/workflows/` gave an EMPTY population and the test passed having examined
nothing — the #778 shape its own docstring invokes. Measured before the guard
(`git mv .gitea/workflows .gitea/wf-renamed` -> 1 passed); measured after -> red,
and green again on restore.
Correcting round 2's commit message: it said both new tests run over the
git-derived `_workflow_files()` population. Only the second does; the first
addresses `review-verdict.yml` directly.
Also scoped the record's new measurement heading — it re-probes ONE item of the
1.25.4 caveat (the `permissions:` question) and does not discharge the scope
enum, the `reqRepoWriter` gate or the `write:package` 403, which stay dated.
Decisions-Edit: yes
Refs: #748
timothy
efe711c5a9