guard postguard-js's 20 required contexts against its ruleset (the other half of #318)

[rubenhensen]

Question

#318 closed the registry half for postguard: the ruleset-drift job in build.yml reads the live effective rules on main and compares them against the REQUIRED_CHECK constant in pg-core/tests/ci_wiring.rs. postguard-js has the same gap and 20 times the surface — and it is the repo where the wiring guard (postguard-js#222) found both of its own premises stale, so the registry side there is the least-verified part of the fleet.

The credential question is already answered and is not the blocker. #318 measured it: postguard-js is public, so rules/branches/main answers 200 to the built-in GITHUB_TOKEN at any permission level and across repositories — a job in postguard can read postguard-js's ruleset with no secret at all. scripts/ruleset-drift.sh already takes RULESET_REPO and RULESET_EXPECTED and was exercised against postguard-js's live 20 contexts while #318 was open.

What to settle

The real question is where the expected list of 20 lives, because there must be exactly one copy and today it is a REQUIRED_CONTEXTS constant inside packages/pg-js/tests/ci-wiring.test.ts in the other repo:

1. A job in postguard-js reading its own constant. No cross-repo coupling, one source of truth, but it needs a workflow edit in a repo with eight workflow files — and the dobby-coder App cannot push those, so it lands as a hand-applied patch, which is the exact failure class Gates should assert their own workflow wiring, so an unapplied patch fails loudly #272 exists for.
2. A job in postguard fetching ci-wiring.test.ts from raw.githubusercontent.com and parsing REQUIRED_CONTEXTS out of it. Free (public, no credential), one source of truth, one place to read results — but it parses another repo's TypeScript by regex, so a reformat there reds a gate here. Note that lands on exit 2 (undetermined), not exit 1 (drift), which is the honest outcome but still noise.
3. postguard-js commits the list as data (e.g. .github/required-contexts.json) that both its own test and a drift job read. Robust to reformatting and readable by anyone, at the cost of a new file and a change in that repo anyway.

Also decide whether one job should cover both repos or each repo guards itself, now that the cost that motivated "one per repo" (a cross-repo credential) turned out to be zero.

Done when

postguard-js's main ruleset requiring its 20 contexts is asserted somewhere that runs on every merge, with the expected list stored exactly once, and mutation-verified red — the standard #272/#222/#318 all held themselves to.

Part of #247 (workstream C).

[rubenhensen]

Premise update from #317, resolved a few minutes ago in a parallel session: postguard-js is now two rulesets, and that changes what this guard should pin.

main                 (14326269)  pull_request: 1 review              bypass = Team `developers`/always
main: required checks (20686395)  20 contexts + deletion + non_fast_forward   bypass_actors: []

#317 split them precisely so the contexts bind everyone while solo merges keep moving — the same shape postguard has. Two consequences here:

1. Pin (context → ruleset_id) pairs, not just the set of context names. The split creates a drift vector that a set-comparison cannot see: move a context from 20686395 to 14326269 and the required list is byte-identical while that context becomes advisory for ten people. rules/branches/main already returns ruleset_id per rule — the same response this repo's scripts/ruleset-drift.sh reads — so catching it costs nothing extra.
2. That partly answers what #332 is weighing. Your measurement in #333 is that the Actions token gets the context list but never bypass_actors. True — but "the contexts still live in the ruleset that has no bypass" is checkable by id without ever reading the bypass field. It is weaker than asserting bypass_actors: [] directly (someone could add an actor to 20686395 itself and this would not see it), and it is strictly stronger than a context-set check, at zero credential cost.

Worth knowing while you write it: current_user_can_bypass is not a substitute on this repo either — you already found it reads never on postguard-js despite Team developers holding bypass_mode: always. And the 20 context strings plus their integration_id: 15368 carried over verbatim in the split (both halves were generated from the live ruleset with jq, not retyped), so anything already pinning those names is still accurate.

[rubenhensen]

Refinement from #317, which landed hours after this was filed and changes what "the expected list" has to contain.

#317 split postguard-js's protection into two rulesets: main (14326269) now holds only the 1-review rule with the Team developers bypass, and a new main: required checks (20686395, bypass_actors: []) holds the 20 contexts. bypass_actors is ruleset-level, not per-rule — which means a context is only as strong as the ruleset carrying it.

So a guard comparing context names alone has a blind spot, and it is the one that matters here: a context moved from the non-bypassable ruleset into the bypassable one leaves the required list byte-identical while silently going advisory. Exactly the #299 shape, one level up.

Pin (context → ruleset_id) pairs, not a flat list of 20 names. rules/branches/main already returns ruleset_id on every rule, so this costs nothing extra — scripts/ruleset-drift.sh already extracts and reports the set of source ruleset ids, it just does not assert on them yet.

That also makes this ticket the cheap approximation of #332: pinning the ruleset id pins the ruleset whose bypass list was vetted, without ever reading bypass_actors and therefore without the admin credential. It does not detect a bypass actor added to the vetted ruleset — only #332 can do that — but it does detect the move, which is the cheaper and likelier drift.

The same gap exists in what #318 shipped for this repo, and is recorded on the map rather than quietly fixed: ruleset-drift.sh compares names only, on the since-disproved reasoning that it should not care which ruleset supplies a rule. Whoever takes this should fix both halves in one change — the script is already parameterised by RULESET_REPO/RULESET_EXPECTED, so the pair-matching goes in one place and serves both repos.