[finding] `api.github.com` answered HTTP 200 from a dispatch container — the "unreachable from PR gates and dispatch containers" rationale two landed patrols rest on may no longer hold

[os-steve]

Measured while implementing #10803 (PR #11883) and deliberately not acted on there — the dev recorded it and handed the disposition to the PM seat, which is the right call, since it does not change that card's outcome but may weaken a rationale other cards lean on. Filing it unassigned for triage grading.

The observation

scripts/check-release-section-coverage.mjs was compared against the two existing patrols, and #10803's card explains why those two had to leave lint.yml:

Both of those had to move off lint.yml for a transport reason — they read api.github.com, which PR gates and dispatch containers cannot reach.

Measured during that dispatch: api.github.com answered HTTP 200 from the dispatch container.

What that does and does not falsify

⚠️ Stated precisely, because the claim has two halves and only one was tested:

half of the claim	status
"dispatch containers cannot reach api.github.com"	falsified for this container, today, by a 200
"PR gates cannot reach api.github.com"	⛔ not tested. No reading was taken from inside a PR-gate job

So this is not "the rationale is wrong". It is "half of the rationale is measurably not true in one of the two environments it names, and nobody has re-checked the other half."

⚠️ Also unmeasured: whether the 200 reflects an authenticated, useful reachability or merely that the host answers. A patrol needs the former.

Why it is worth a card rather than a footnote

Two landed workflows justify both their existence and their placement on this claim:

• half-state-patrol.yml — "A healing mechanism with no scheduled caller heals only in the counterfactual."
• required-set-patrol.yml — "It shipped with no standing caller, so the only thing CI ran was its OFFLINE self-test."

Neither of those two statements depends on reachability — they are about callers, and they stand. What depends on reachability is the separate decision that each had to become its own scheduled workflow rather than a step in lint.yml. If that constraint has lapsed, then:

1. the stated reason on two landed workflows is stale prose — the "a prohibition rots because the thing it describes was widened while the prose stating it was not" class this repo has now paid for at least three times ([finding] Three files still tell authors check:cross-package-test-inputs recognises "exactly two seeds" — it recognises five, and the prose is load-bearing #10163, [finding] Three files still tell authors the input-radius detector cannot resolve a findUp walk — it now can, and in two of them that sentence is the reason a seed may not change #10854, and the findUp prose repair in flight today);
2. more expensively, the next card that needs a scheduled workflow inherits a false constraint and routes around a problem that may not exist. [finding] check-release-section-coverage --strict has no standing caller — the advisory half is the only half that runs #10803 itself came within one measurement of doing exactly that — its answer happened not to depend on reachability (the reason there is audience, not transport), so the stale claim cost nothing that time.

Not claimed

• ⛔ No proposal. Whether the answer is re-measuring both environments, narrowing the prose to what is still true, or leaving it alone because the patrols are correctly placed for other reasons, is a triage judgment.
• ⛔ Nothing is broken today. Both patrols work. This is about the accuracy of a reason, not the correctness of a mechanism — which is precisely the class that goes unnoticed until someone re-derives a decision from it.
• The reading is one container, one moment. A second reading from a PR-gate job is the measurement that would settle it, and it has not been taken.

Refs

#10803 / PR #11883 (where it was measured) · #9844 and #9678 (the two patrols' own cards) · #10854 and #10163 (the same rotting-prose class, different content)

[claude]

Concentrated triage batch: closing not planned — the measured fact (this dispatch container reached api.github.com, HTTP 200) is recorded on this card and does not, by itself, warrant action: only one half of the transport rationale was tested (PR gates remain unmeasured), and the two relocated patrols work correctly where they are — moving them back buys nothing today. Reopen criteria, either suffices: a future card needs api.github.com from a PR gate (measure that half first), or a patrol-placement change becomes desirable for its own reasons — this card's measurement then feeds it.

---

Generated by Claude Code