docs(github-project): read effective branch rules, not just classic protection

[CybotTM]

The defect

SKILL.md's "Security & Compliance Quick Checks" and checkpoint GH-31 both read branch rules from gh api repos/OWNER/REPO/branches/main/protection. That endpoint is blind to rulesets, and its two failure shapes are asymmetric — one looks like an absence, the other looks like an answer:

Classic endpoint says	Reads as	Reality on the same repo
required_status_checks: null	nothing is required	23 required contexts
required_approving_review_count: 0	no review required	1 required approval

Measured on netresearch/t3x-nr-llm, where classic protection and two active rulesets coexist. Acting on the classic reading alone, I wrote into that repository's OpenSSF compliance document that it required neither an approving review nor any status check. Both statements were false, and nothing in the API response hints that a second source exists.

Changes

references/security-config.md gains an "Effective Branch Rules" section. Read both sources; GitHub composes them and applies the most restrictive result. Bypass actors live on the ruleset, not on the branch, and the REST API returns actor_id as an unresolved number — so "repository role id 5", not a guessed "admin".

GH-31 becomes a command checkpoint. It passes when either classic protection or a pull_request ruleset requires thread resolution. As a gh_api check against the classic endpoint it fails a correctly configured ruleset-only repository at severity error — a false negative on the checkpoint that exists to catch unresolved bot findings.

GH-30 keeps its classic read (enforce_admins is genuinely a classic field) but its description now says so and points at the ruleset's own bypass_actors.

GH-32's llm_review step 2 checked the same field from the same blind endpoint; it now checks both.

Two audit recipes, same origin

• A required context that is skipped on every commit enforces nothing. Observed: fuzz / Fuzz Tests was required and always skipped, because the job producing it passed no inputs to its reusable workflow. The job that actually ran the suite was a different context and was not required at all.
• Check-run names are prefixed by the calling JOB name, not the workflow. Two jobs on the same reusable produce fuzz / X and fuzz-mutation / X — different contexts that look interchangeable. The section gives the run→jobs loop to measure it instead of inferring.

A note on the word budget

SKILL.md is at 499 of its 500-word limit on main, so the file cannot accept a net addition — my first push failed Skill Validation at 593 words.

This PR therefore adds nothing to it. The quick-check gains the rules/branches call and loses the bypass_pull_request_allowances call, which reads the same blind endpoint and whose correct replacement (ruleset bypass_actors) is documented in the reference. Net 496 words.

That budget is also why the material went into the existing security-config.md instead of a new reference file: a new file needs a new pointer row in the table, and there is no room for one. Worth knowing as a maintainer — at 499/500 the next contributor hits the same wall, and the only ways through are trimming existing prose or raising the cap.

Verification

OK: SKILL.md is 496 words (under 500 limit)
Errors:   0

• validate-skill.sh (the script CI runs) reports 0 errors locally.
• yaml.safe_load parses checkpoints.yaml; 29 mechanical checkpoints.
• GH-31's target passes bash -n, and both of its branches evaluated against a live repository (classic=true ruleset=true).

The 10 warnings the validator reports (README template sections, untested scripts, runnable commands in llm_reviews) are pre-existing on main and untouched here.

One limit worth stating: I have no ruleset-only repository to demonstrate the old checkpoint's false negative end to end. The blindness itself is shown by the table above — the classic endpoint reporting 0 while a ruleset requires 1 on the same branch.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud