LABELS.md

@@ -27,10 +27,8 @@ and the reconciler recomputes it from GitHub's own facts.
 `state:needs-human` means exactly one thing — a human could merge this now —
 so it requires zero blockers and head-current approvals; anything less and
 the reconciler takes it back. The author sets it at handoff (the one
-hand-set state). On a same-repository head, the `labeled` event fires the
+hand-set state); the `labeled` event fires the sweep that validates the
-sweep that validates the write within seconds; on a fork head whose
+write within seconds.
-`pull_request_target` token is read-only, validation waits for the scheduled
-sweep cadence (#241).
 
 ## PR blockers — what is in the way? (facts, as many as apply)
 

docs/CONSUMERS.md

@@ -482,21 +482,17 @@ repositories allow check data to be read regardless, but a private consumer
 needs the explicit reads above; without them the failure appears as an empty
 `state:*` axis on the board rather than a red workflow run. The labels
 caller's `actions: write` is different — it is required everywhere, public
-repos included: the trigger job's dispatch is a write. Without it, issue and
+repos included: the trigger job's dispatch is a write, and without it every
-same-repository PR event runs go red at the trigger. Fork-headed PR runs do
+event run goes red at the trigger.
-not enter that write path on this Forgejo; they remain green and depend on a
-healthy scheduled sweep.
 
 **The failure mode to know before bumping**: a consumer that bumps its pin
-to a #209-carrying tag without adding the sweep caller gets a loud red trigger
+to a #209-carrying tag without adding the sweep caller keeps green-looking
-on every issue and same-repository PR event (workflow-not-found; likewise on a
+silence nowhere — the trigger job goes **red on every PR and issue event**
-sweep caller missing its `bootstrap` input, or a labels caller missing
+(workflow-not-found; likewise on a sweep caller missing its `bootstrap`
-`actions: write`). Fork-headed PR runs deliberately skip that trigger and stay
+input, or a labels caller missing `actions: write`), and event-woken sweeps
-green, so their correctness is proven by the sweep caller's presence and its
+stop until the caller lands. That loudness is deliberate: never read
-latest scheduled run, not by the PR check alone. Never read a green
+silence, or a green `scope` alone, as health. Make the adoption one atomic
-`fork_head` disposition as evidence that the scheduled sweep exists. Make the
+PR — pin bump, sweep caller file, `actions: write` line together.
-adoption one atomic PR — pin bump, sweep caller file, and `actions: write` line
-together.
 
 The `issues:` trigger is available at `0.2.0` and later — `0.2.0` is the
 first tag carrying ceremony#32. A consumer pinned to `0.1.0` omits it. Adopt
@@ -547,9 +543,9 @@ carrying the split:
    `actions: read` today (crew does); the trigger job's dispatch is a
    write. The sweep caller keeps `actions: read`.
 
-Bump without the sweep caller and the trigger job goes red on every issue and
+Bump without the sweep caller and the trigger job goes red on every PR
-same-repository PR event; fork-headed PRs stay green but receive no labels
+and issue event — the loud failure mode above — so never split these
-without the scheduled sweep. Never split these four edits across PRs.
+four edits across PRs.
 
 `pull_request_target` is intentional: same-repository PRs keep the base
 repository's write token without executing PR code. This Forgejo still gives