[bkd-dotcom]

The leaderboard could not publish the leaderboard

leaderboard.yml and benchmark.yml regenerated their page and pushed the result straight to main. main requires a pull request, so every run that actually had something to publish was rejected by branch protection:

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: - Changes must be made through a pull request.
remote: error: - 4 of 4 required status checks are expected.

• weekly refresh, 2026-09-07 — failed at the push
• v0.3.0 release run, 2026-09-01 — failed at the push

So the published numbers went stale rather than current: docs/LEADERBOARD.json still labelled the live row 0.7.0 after pyproject.toml had been pinned to signetry-core v0.8.0. benchmark.yml carried the identical bug and looked green the whole time — its push step exited 0 on no change to publish, so the failure only appeared once the table actually changed.

Four more defects the first one was hiding

• Both gates were masked. Each workflow ordered its gate — signetry-eval run for the governed defenses, corpus parity for detection — after the push. A rejected push aborts the job before the gate, so a broken defense or a detection regression would have surfaced as a git error, or not at all.
• CI and the page documented different commands. The workflow inlined its own copy of the generation commands while the page told readers to regenerate with signetry-eval leaderboard --markdown — which omits --with-detection and --version, and therefore produces a different page. Under a regenerate-and-diff check, that drift is a stale-page failure nobody could explain from the log.
• pyproject.toml was not a trigger path, though the pinned signetry-core is the live row's version label. That is precisely the staleness that went unnoticed above.
• git diff says nothing about an untracked file, so a page deleted from the repo and then regenerated would have sailed through a diff-based check as "current" while not being published at all.

The fix: verify, don't publish

Both workflows now regenerate their page, diff it against what is committed, and fail if the committed page is stale. permissions: drops from contents: write to contents: read, so neither workflow can write to this repository at all.

Refreshing is an ordinary pull request. A governance product whose own numbers arrive by a bot bypassing branch protection is arguing against its own thesis.

	before	after
token	contents: write	contents: read
on a change	push to main (rejected)	fail with "run make leaderboard, commit, open a PR"
recipe	inlined in CI, drifting from the page	one Makefile, shared by CI and contributors
gate	after the push, masked by its failure	if: !cancelled() && steps.regen.outcome == 'success'
triggers	schedule, release, push	+ pull_request, + pyproject.toml / Makefile paths
concurrency	shared published-numbers group	${{ github.workflow }}-${{ github.ref }}

One recipe, in a Makefile

make leaderboard              # docs/LEADERBOARD.{md,json}
make benchmark                # docs/BENCHMARK.{md,json}
make published-numbers        # both
make verify-published-numbers # exactly what CI checks

CI runs these targets rather than its own copy of the commands, so the page you regenerate locally is byte-for-byte the page CI expects. The generated headers and the in-page instructions now name make leaderboard / make benchmark — the command that actually writes the file.

check-* asserts git tracks the page before diffing it, closing the untracked-file hole.

The design is now enforced by tests, not by memory

New tests/test_published_numbers.py (11 tests) asserts that neither workflow requests write access, neither runs git push / git commit / git config user, both regenerate via make <target> and verify via make check-<target>, both gates keep the !cancelled() guard, and each committed page's header names its recipe and its verifying workflow.

Mutation-checked: re-granting contents: write, re-adding a git push, and deleting the gate guard each fail these tests. They run inside test (3.11/3.12/3.13), which is already a required check — so the regression cannot come back quietly.

Verification

Clean clone of the head commit, then exactly what CI runs:

check	result
make check-leaderboard	pass — committed page == fresh regeneration
make check-benchmark	pass
signetry-eval run	pass — every governed defense held
signetry-eval corpus --min-recall 1.0 --max-fp 0	pass — 100% recall, 0 false positives
pytest -q	108 passed
ruff check signetry_eval/ tests/	clean
actionlint on both workflows	clean

The only content change to the generated pages is the header line and the regeneration instructions — the numbers themselves are unchanged, which is the point.

Notes for review

• Branch protection is untouched. Still 4 required checks (test (3.11), test (3.12), test (3.13), cla), enforce_admins: true, strict. No ruleset was created and no bypass actor was added.
• The two new workflows are deliberately not added to the required-check set. They are path-filtered, and a required check that never runs blocks a merge forever. Staleness still blocks via the normal failed-check signal, and the design guards above live inside a check that is required.
• Safe on fork PRs: the pull_request runs take a read-only token and use no secrets.
• CHANGELOG.md gains an [Unreleased] entry rather than rewriting the released 0.3.0 section. CONTRIBUTING.md documents the refresh path in The published pages are generated, and in both "adding a case" checklists.

🤖 Generated with Claude Code

[github-actions]

Signetry Reviewer — 🟣 Escalate to a designated reviewer

Escalate to a designated reviewer — this PR touches security-sensitive surface (.github/workflows/benchmark.yml, .github/workflows/leaderboard.yml). No blocking issue was found automatically, but a human owner should sign off.

Deterministic gates (the authority)

Gate	Status
Required status check	— unknown
Secret scan	✅ clean
CI permission / OIDC	✅ no forbidden change
Dependency skew	✅ ok
All green	❌

Findings (2, 0 blocking)

• 🟡 Change touches a protected path: .github/workflows/benchmark.yml .github/workflows/benchmark.yml (via cross-check)
  • .github/workflows/benchmark.yml matches a protected pattern (.github/workflows/*). Changes here alter shared/foundational surface and warrant a designated reviewer.
  • Fix: Route to a code owner / architecture reviewer.
• 🟡 Change touches a protected path: .github/workflows/leaderboard.yml .github/workflows/leaderboard.yml (via cross-check)
  • .github/workflows/leaderboard.yml matches a protected pattern (.github/workflows/*). Changes here alter shared/foundational surface and warrant a designated reviewer.
  • Fix: Route to a code owner / architecture reviewer.

Sensitive surface

This PR changes security-sensitive paths that warrant a designated reviewer:

• .github/workflows/benchmark.yml
• .github/workflows/leaderboard.yml

Merge

A designated reviewer / code owner should sign off before merge (sensitive surface).

This review is advisory. It never merges on its own judgement — the deterministic gates + a human are the authority. Findings can have false negatives; a green bot verdict is not a guarantee.