Monitor branch protection and open Dependabot alerts

[tschm]

Adds two metric groups, both on the existing per-repo loop in github.py.

Branch protection

jq_branch_protected, jq_branch_required_reviews, jq_branch_allows_force_push.

Every other metric on this board reports what happened. This one reports what is allowed to happen — the thing you change once and it holds. On the current 25-repo fleet it already finds:

• exactly one repo (Jebel-Quant/rhiza) protects its default branch
• and that one still allows force pushes — a green tile on a branch anyone can rewrite

Dependabot

jq_dependabot_alerts_enabled, jq_dependabot_open_alerts{severity}.

Four repos in the fleet have alerts switched off entirely. One (tschm/proximal) has an open low-severity alert that nothing on the board showed before.

The part worth reviewing

Both endpoints return 404 in two different situations, and conflating them makes the board lie in opposite directions:

Endpoint	404/403 can mean	Handled as
branches/{b}/protection	unprotected or token lacks admin	metric absent, never 0
dependabot/alerts	no open alerts or feature disabled	separate _enabled gauge; counts absent when off

Exporting 0 for unknown protection would put every repo on the "unprotected" list on the strength of a permission gap — a finding the board invented. absent and 0 are distinguishable in PromQL; two zeros are not.

Likewise "nothing to fix" and "nobody is looking" must not render as the same green tile.

Severities are zero-filled so a repo that clears its criticals reports 0 rather than dropping out of the query and stranding its last value on the graph.

Cost

~2 extra calls per repo: a pass over 25 repos goes from ~450 to ~700 calls, 37s to 40s. That fits only because #14 moves JQ_GITHUB_INTERVAL to 600s — this should merge after #14, or the refresh goes further over an already-exceeded budget.

Testing

4 new tests covering both unknown-vs-zero distinctions; full suite of 48 passes. Verified against the live fleet — the numbers quoted above are from the running collector, not fixtures.

🤖 Generated with Claude Code

[tschm]

Pushed two more commits: the collector can now say unprotected, and the board shows it.

The metric was half-blind

branch_protection treated both 404s as unknown. But the bodies differ — GitHub answers an unprotected branch with "Branch not protected", and a permission gap with something else. Collapsing them meant protection was exported only where it existed: 22 of 25 repos had no series at all, which is indistinguishable from a fleet nobody had looked at.

Now unprotected is a fact (jq_branch_protected 0) and only genuine gaps stay absent. The two private repos are the only unknowns left — free-plan private repos cannot use protection at all.

Four tiles in Fleet at a glance

Tile	Live value
Default branches unprotected	22
Protected but force-pushable	1
Dependabot off	4
Open Dependabot alerts	1

Each links to a drill-down table in the existing collapsed row.

Two of these exist to stop a tile lying by omission. Protected but force-pushable is the case a protection count hides — the single repo that protects main also allows rewriting it. Dependabot off sits beside the alert total because four repos contribute a truthful 0 to a number that would otherwise read as an all-clear.

A bug worth flagging

The tiles first used count(x == bool 0). A bool comparison yields 1/0 for every series, so count returns the series total — it reported 23 unprotected of 23, and 25 Dependabot-off of 25. Wrong, and plausible enough to ship. Now sum(x == bool 0), matching the idiom the existing tiles already use, and verified against live Prometheus.

Not on the public board

fleet-public.json is unchanged, deliberately. A world-readable list of which repos are unprotected and which have open advisories is a target list.

45 tests pass; check-dashboard.py validates both dashboards.