2026-09-23 03:02:39 +00:00
2 changed files with 8 additions and 8 deletions
@@ -648,12 +648,12 @@ built-in `GITHUB_TOKEN`:
  comparison. Otherwise it runs the same shellcheck and selftests against the
  tip and moves `v1` there only if they pass.
-Both jobs request `contents: write` on the run's built-in token, but whether
+Both jobs request `contents: write` on the run's built-in token, and that
-that actually grants a push to this repo is **unobserved until the first
+grant is now **verified**: PR #28's own merge ran `release-tag` successfully
-merge** — the grant is capped by the repo's and owner's maximum token
+and moved `v1` to that merge's commit. The grant is still capped by the
-permissions, and branch/tag protections on `v1` can't be read without admin
+repo's and owner's maximum token permissions, and branch/tag protections on
-access. A rejected push is a red job, not a silent no-op, so the first merge
+`v1` can't be read without admin access. A rejected push is a red job, not a
-after this lands is the real test.
+silent no-op.
 So `v1` trails a green `main` by at most about one sweep interval plus one
 selftest run, and **a `main` that fails its gate shows up as a red sweep on every
@@ -136,8 +136,8 @@ ok "server rejection with v1 unmoved: red, not a lost lease"
 echo
 echo "=== 9. the merge job defers on a moved tip; the next sweep catches up ==="
-# The stranded trace: C1's job runs after C2 merged and defers, C2's job was
+# The stranded trace: C1's job runs after C2 merged and defers — a run that
-# cancelled in the concurrency group, and merges stop.
+# deferred and left no newer run behind it — and merges stop.
 fresh
 before=$(origin_v1)
 c1=$(commit_to_main)