docs(obs): record why CI is red — approval-policy on the one conformance entry

The gate job reported failure while the local run was rc 3 with nothing failed. Measured cause is a single sensitive path (the KNOWN_EXTERNAL_MONITORS entry) with no non-author approving review, which ci/approval-policy.sh blocks fail-closed by design. Also records the general trap: approval-policy short-circuits to N/A off a pull_request event, so a clean LOCAL gate is a false reassurance for any branch touching a sensitive path. Only the PR run tells the truth. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-10-01 22:12:19 -05:00
1 changed files with 30 additions and 0 deletions
@@ -257,3 +257,33 @@ succeeds, not the day a listener exists.
 - **The radarr `/signalr` finding is the coordinator's measurement, not mine** — I reproduced neither
  the 206/209 sample nor the jackett 0-in-13,612. They are recorded as reported.
 - **L2/L3 conformance still did not run** (`CLUSTER_AVAILABLE` unset). Nothing is certified.
 ### Round 2 addendum — CI is RED, by design, and the local gate cannot see why
 After pushing round 2, `gate / gate (pull_request)` reported **failure after 1m42s** while the local
 toolbox run was rc 3 with nothing failed. Measured cause, singular:
    sensitive paths touched:
      conformance/tests/l0-static/servicemonitor-ports-resolve/check.sh   (matched conformance/**)
    approving reviews: (no reviews at all)        author=gitea-admin
 `ci/approval-policy.sh` is fail-closed and exits 1 when a PR touches a `sensitive_paths` glob with no
 `APPROVED` review from a non-author — "a change to the gate cannot be gated by the gate". The single
 `KNOWN_EXTERNAL_MONITORS` entry is what trips it. **Nothing in L0/L1 failed.**
 **The local gate structurally cannot catch this, and said `approval-policy: green (N/A)`.** The stage
 short-circuits to N/A when `GITHUB_EVENT_NAME` is unset, which it always is off-CI. So for any branch
 touching a sensitive path, a clean local gate is a FALSE REASSURANCE — the PR run is the only honest
 signal. That is a general trap, not specific to this change, and it is worth knowing before someone
 concludes a red PR means broken code.
 To clear: a non-author approving review, then **re-run the gate** — approval does not re-trigger the
 status check, so the required context stays red until the job runs again. `required_approvals=1`
 already applied to every PR here, so the human was needed regardless; the conformance entry only
 turns the tick red while that is pending.
 The alternative is to drop the register entry, which means dropping `podmonitor.yaml` with it (the
 check fails without the declaration). I did not take it: the entry is the "declare the limit"
 mechanism the check explicitly asks for, it is shrink-only so it cannot rot quietly, and
 `flux-podmonitor.yaml` is the same case already in the register. But it is a real trade and the
 reviewer should make it knowingly.