audit.py still compares bypass_actors after #545 stopped declaring it, so every repo with a bypass is permanently not operational

[ptr727]

spec/audit.py compares bypass_actors against a payload that deliberately no longer declares it, so every repository carrying a bypass reports a DEFECT that the sanctioned tool will not fix and that no payload change can clear. Since a DEFECT makes a repository not operational, a maintainer who deliberately keeps an admin bypass can never have an operational repository.

Audited against hub main 7194f91. Found on Blog while verifying its convergence after ptr727/Blog#11.

The three parts disagree

The payload no longer declares the field. #545 removed it, on the reasoning that who may bypass a ruleset is a per-repository human decision rather than a value the fleet config hands out:

$ git show origin/main:repo-config/develop.json | jq -c '.bypass_actors // "field absent"'
"field absent"

configure.sh was rewritten to match, and says so. Apply reads the live list and writes it back unchanged, and check reports without asserting:

note "ruleset '$rname' bypass list: ${bypass:-none} (not managed by this script)"

spec/audit.py still compares it, so an absent field is read as None and diffed against whatever is live:

RULESET_SUBSET = ["name", "target", "enforcement", "bypass_actors", "conditions", "rules"]
...
sub = {k: payload.get(k) for k in RULESET_SUBSET}

What that produces

$ python3 spec/audit.py --branch develop Blog
 DEFECT ruleset: develop diverges from repo-config/develop.json (normalized diff)
 DEFECT ruleset: main diverges from repo-config/main.json (normalized diff)

Blog's live rulesets carry [{actor_id: 5, actor_type: RepositoryRole, bypass_mode: always}] on both branches, which is exactly what the old payload granted every repository before #545 removed it. The payload now declares nothing, so the diff is guaranteed and permanent.

The escape routes are all closed by design. Re-vendoring the payloads does not help, because the field is meant to be absent. Running configure.sh apply does not help, because it now preserves the live list on purpose. The only remaining move is deleting the bypass by hand in the UI, and #545's own argument is that this is the maintainer's decision, which the audit then overrules by calling any answer except "empty" a DEFECT.

Scope

Every fleet repository, not only Blog. #545 records that "every fleet repo sampled carries exactly that entry on both branches", which is the population this now fires on.

The severity is what makes it urgent rather than cosmetic. This is DEFECT, not DRIFT, so it flips operational to not operational fleet-wide on a field the fleet just decided it does not manage.

Which rule gives

A governance call, so not proposing a resolution, but the shapes seem to be:

• Drop bypass_actors from RULESET_SUBSET, matching what configure.sh already does, and report the live list the way configure.sh does rather than judging it. This makes all three parts agree, and keeps the field visible.
• Keep comparing, but only when the payload declares the field. This preserves the ability to pin a bypass list for a repository that wants one, while an absent field means unmanaged rather than "must be empty".
• Declare an empty bypass_actors: [] in the payloads, which would make the audit correct as written, but it reverses Take the ruleset bypass list out of the fleet config entirely #545: an empty list is a managed value, and applying it would revoke the grant the fleet just decided not to touch.

The second looks closest to both intents, since it distinguishes "the fleet pins this" from "the fleet does not manage this", but that is a preference and the call is yours.

🤖 Generated with Claude Code

[ptr727]

Live confirmation from Blog, which has now re-vendored the post-promotion payloads and configure.sh at hub main 7194f91 (ptr727/Blog#13). Both tools were run against the same repository, minutes apart:

$ repo-config/configure.sh check ptr727/Blog release
 ruleset 'develop' bypass list: RepositoryRole 5 always (not managed by this script)
 ruleset 'main' bypass list: RepositoryRole 5 always (not managed by this script)
Configuration matches on ptr727/Blog.
exit 0

$ python3 spec/audit.py --branch develop Blog
 DEFECT ruleset: develop diverges from repo-config/develop.json (normalized diff)
 DEFECT ruleset: main diverges from repo-config/main.json (normalized diff)

Same repository, same live rulesets, same hub revision, opposite verdicts. The carried payloads byte-match the canonical, so re-vendoring is not the gap: the disagreement is entirely bypass_actors being absent from the payload and present in RULESET_SUBSET.

[ptr727]

Maintainer's intent, recorded here because it decides which of the three shapes above is right and it is not written down anywhere the next agent would find it.

The repository owner is automatically an admin and holds bypass capability by virtue of that, so a bypass_actors entry naming the admin role grants nothing the owner did not already have. The reason it left the payloads is not that the grant was unwanted, it is that code should not be in the business of granting bypass at all. A config file that hands out an exemption is a config file that can widen one by accident, and the blast radius is every repository it applies to.

That reading closes the question this issue leaves open. The problem is not which value bypass_actors should hold, so declaring bypass_actors: [] in the payloads is the wrong fix even though it would make the audit pass: an empty list is still code deciding the field, which is the thing being removed. The fix belongs on the reading side, meaning audit.py stops asserting a field the fleet has decided it does not manage, matching what configure.sh already does.

It also means the two DEFECTs on Blog are not work owed by Blog. Nothing an agent can do clears them, and nothing a maintainer does to the live list makes the audit correct in general, since a repository that deliberately keeps a bypass would still report not operational.

Worth stating one caveat plainly, since this issue should not rest on an unchecked assumption. GitHub's own documentation, quoted in #545, says a ruleset applies to administrators by default and the bypass list starts empty, so an admin is eligible for bypass and is exempt only once added. Whether the live entry is redundant with owner capability or is the thing actually conferring the exemption is a question about GitHub's behavior, not about this repository, and it does not change the conclusion either way: the field is unmanaged by the fleet, so the audit should report it rather than judge it.

[ptr727]

Fixed on develop by 82e3658 (#551), which landed after this was filed. Verified against develop @ 2951273:

• spec/audit.py:49 now reads RULESET_SUBSET = ["name", "target", "enforcement", "conditions", "rules"] — bypass_actors is gone from the comparison.
• spec/audit.py:42-47 carries the reasoning this issue and its comments arrived at: who may bypass a ruleset is a per-repository human decision taken in the UI, configure.sh writes the live list back unchanged on apply and reports it without asserting on check, and "two tools comparing one field under opposite policies is the defect, rather than the field's value."
• grep bypass repo-config/*.json repo-config/operational/*.json returns nothing, so neither payload declares a list.

The fix went to the reading side rather than to bypass_actors: [], which is what the deciding comments on this thread asked for. Closing as resolved.