feat(ci): an absent check is a red, whatever made it absent

.github/workflows/pr-00-gate.yml

@@ -14,6 +14,23 @@ name: Gate
 on:
   pull_request:
     types: [opened, synchronize, reopened, ready_for_review, labeled]
+  # ALSO ON PUSH TO MAIN, and the reason is an incident rather than a preference.
+  #
+  # This workflow used to run on `pull_request` only. On 2026-08-24 its PR run was held at
+  # `action_required` with ZERO jobs, so #90 merged with no lint, no format and no typecheck --
+  # and because pushes to main did not trigger the Gate either, main was never checked afterwards
+  # either. Six F821s sat on main and were found only because somebody ran ruff by hand.
+  #
+  # A held PR run cannot be fixed from here (no API clears it). What CAN be fixed is the silence
+  # AFTER the merge: with this trigger the same commit is checked on main, so an unverified merge
+  # becomes a red on main within one run instead of never. That is strictly worse than catching it
+  # pre-merge and strictly better than not catching it -- fail toward noise, not toward silence.
+  #
+  # It does not make the Gate a merge blocker (main has no branch protection) and it is not a
+  # substitute for `scripts/check_checks_reported.py`, which is what catches the absence while the
+  # PR is still open.
+  push:
+    branches: [main]
   workflow_dispatch:
 
 concurrency:

config/expected-checks.json

@@ -0,0 +1,37 @@
+{
+ "expected": [
+  "Bot comment handler",
+  "Cleanup bot comment label",
+  "Create issue from verification (enhanced)",
+  "Fetch PR context / Fetch PR Context",
+  "PR meta handler / Detect keepalive comments",
+  "PR meta handler / Dispatch keepalive orchestrator",
+  "PR meta handler / Resume keepalive after Gate",
+  "PR meta handler / Update PR body sections",
+  "Resolve event context",
+  "contract",
+  "cross-repo smoke",
+  "detect changed files",
+  "docker smoke",
+  "docs guard",
+  "generated delivery seal",
+  "github scripts tests",
+  "guard",
+  "issue consistency",
+  "ledger validation",
+  "privilege environment gate",
+  "python ci / Validate inputs",
+  "python ci / lint-format",
+  "python ci / lint-ruff",
+  "python ci / logs summary",
+  "python ci / python 3.12",
+  "python ci / python 3.13",
+  "python ci / select reusable CI scope",
+  "python ci / typecheck-mypy",
+  "reconcile the collection floor (main only)",
+  "summary",
+  "test-quality",
+  "unauthorized-promotion-marker",
+  "verify.py (real pytest counts + selftests + capability gates)"
+ ]
+}

docs/ABSENT_CHECK_LANE_WIRING.md

@@ -0,0 +1,77 @@
+# An absent check must reach the lanes — the one wiring step this repo cannot land
+
+`scripts/check_checks_reported.py` is in-repo, tested and callable. The lanes that actually **merge**
+are not: `~/.codex/automations/{imi-merge-verify-closer,pd-workloop-resume}/automation.toml` and
+`~/.codex/bin/handoff-prerun.sh` are the owner's files, outside any repository. So this doc is the
+handoff, in the same shape as `docs/MIRROR_SYNC_PATCH.md`.
+
+## Why the merge point is the right home, and CI is not
+
+The defect is that **an absent check is indistinguishable from a passing one.** `gh pr checks` lists
+what reported; a check that never started is simply not in the list, so a PR with no Gate reads
+exactly like a PR whose Gate passed.
+
+That cannot be fixed from inside GitHub Actions, for two reasons:
+
+1. **A workflow can be held.** Six of this repo's workflows currently sit at `action_required` with
+   zero jobs, `pr-00-gate.yml` among them. A detector implemented as a workflow can be held by the
+   same mechanism it is watching.
+2. **Ordering.** Any in-CI check runs *concurrently* with the Gate, so it cannot know whether the
+   Gate is absent or merely slower.
+
+The merge decision is the one place where "did everything report?" is both answerable and
+actionable. In this fleet that decision is the closer lane's.
+
+## Why not branch protection
+
+Because it converts this defect into a worse one. A required status check that is **held** never
+reports, so the PR can never merge — the clear path blocked by the very thing the gate measures,
+which is this workspace's most-repeated defect. On a solo-maintained repo, "unverified but movable"
+beats "permanently stuck". `main` is deliberately unprotected; this tool is what replaces the
+protection, at the point where a human or a lane can still exercise judgement.
+
+## The closer wiring (pre-merge assertion)
+
+The closer already parses `action_required`, but frames it as *"may need human approval"*. That is
+the wrong frame: the question is not whether someone should approve a workflow, it is whether **this
+PR was verified at all.** Before merging any PR, run:
+
+```bash
+python3 ~/Library/CloudStorage/Dropbox/Learning/Code/Orchestrator/scripts/check_checks_reported.py --pr <N>
+```
+
+* **exit 0** — every check that normally reports also reported here. Proceed on the usual criteria.
+* **exit 1** — one or more checks NEVER reported. Do not merge on the strength of a green list.
+  Post one inbox item naming the absent checks, and either wait for them or record explicitly why
+  the absence is acceptable (a workflow genuinely removed) before merging.
+
+This adds no queue: it is evaluated per merge attempt from live state, so there is nothing to drain
+and nothing to mark as read.
+
+## The prerun surfacing (FYI, never blocking)
+
+Add to `handoff-prerun.sh`, in the section that already prints lane state:
+
+```bash
+python3 "$ORCH/scripts/check_checks_reported.py" --sweep 2>/dev/null || true
+```
+
+`--sweep` reports every open PR with an absent check and every currently-held workflow. It is
+report-only by construction — it takes no action, has no state, and cannot accumulate. `|| true`
+because a lane round must never fail on the health reporter.
+
+## Attention cost
+
+Six workflows are held today; approving each in the Actions UI is a one-off of a couple of minutes
+in total. Ongoing, an approval is needed each time an edit re-arms a workflow — a few times a week
+at this repo's rate, so low single-digit minutes per week. The sweep makes those visible without
+queuing them, and the closer assertion makes the dangerous case (merging unverified) impossible to
+reach by accident rather than adding a step to remember.
+
+## What this deliberately does not do
+
+It does not model **why** a check is absent. A check can vanish to a held workflow, a cancellation,
+a deleted or renamed workflow, a rate limit, a mistaken path filter, or a GitHub incident. Those
+present identically to whoever is merging, and they are the same bug: something that was being
+checked stopped being checked, quietly. The next cause will be one not listed here, which is exactly
+why the tool asks only "did it report?".