Skip to content

docs(now): retract "master has no branch protection" -- wrong endpoint - #2294

Merged
gHashTag merged 1 commit into
masterfrom
fix/docs/branch-protection-claim
Aug 20, 2026
Merged

docs(now): retract "master has no branch protection" -- wrong endpoint#2294
gHashTag merged 1 commit into
masterfrom
fix/docs/branch-protection-claim

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Refs #2292

Retracts a false BINDING honesty limit I landed in 9fec1a9ba (PR #2293) an hour ago.

The false claim

That entry states "master has no branch protection", citing:

$ gh api repos/gHashTag/t27/branches/master/protection
404 Branch not protected

/branches/{branch}/protection reports only legacy branch protection. A repository protected by rulesets returns 404 from it while being fully protected. I read a 404 as "unprotected" when it means "not protected by that mechanism".

What is actually true

$ gh api repos/gHashTag/t27/rulesets
id=14813367  name=t27-master-protection  target=branch  enforcement=active

$ gh api repos/gHashTag/t27/rules/branches/master --jq '.[].type'
deletion
non_fast_forward
pull_request
required_status_checks

Master is protected: PRs required, force-push and deletion blocked, four required contexts — check-now-freshness, validate, check, check-linked-issue.

The observation survives, better explained

PR #2291 merged at 03:57:13Z while its own corpus-ratchet run started at 03:57:16Z — three seconds before the gate it was adding began to run. Not because nothing is required, but because corpus-ratchet is not one of the required four. Neither are coverage or withdrawn-live, which is precisely why all three sit red on master while PRs keep merging.

This sharpens the original finding rather than softening it. The cargo test -p t27c step was added to a workflow outside the required set, so even had it been green it could never have blocked a merge. It was wrong on its numbers and wrong in its placement, and the second error would have outlived fixing the first.

Not done here, on purpose

Adding corpus-ratchet to the ruleset would make W632 (BLOCKING) real — but it is currently failing on master, so requiring it would block every PR in the repo. That has to follow the ratchet in #2292, not precede it.

Honesty limits

The previous NOW entry asserts, in a BINDING honesty limit, that master
has no branch protection, on the strength of
`GET /repos/gHashTag/t27/branches/master/protection` returning
`404 Branch not protected`.

That endpoint reports only legacy branch protection and 404s for a
repository protected by rulesets. Master IS protected, by the active
ruleset t27-master-protection: PRs required, deletion and non-fast-forward
blocked, and four required status contexts (check-now-freshness, validate,
check, check-linked-issue).

The observation behind the claim survives and is better explained. PR
#2291 merged three seconds before its own corpus-ratchet run began not
because nothing is required, but because corpus-ratchet is not one of the
required four -- which is also why coverage and withdrawn-live sit red on
master while PRs keep merging.

This sharpens rather than softens the original finding: the cargo test
step was added to a workflow outside the required set, so even green it
could never have blocked a merge. It was wrong on its numbers and wrong
in its placement, and the second error would have outlived fixing the
first.

Adding corpus-ratchet to the ruleset is deliberately not done here: it is
currently failing on master, so requiring it would block every PR. That
must follow the ratchet in #2292, not precede it.

Refs #2292
@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-20 04:08:26 UTC

Summary

Status Count
Total Open PRs 19
PRs with Failing Checks 5
PRs with All Checks Green 14
READY 7
FAILING 5
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=cbbfac87dff3 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit 98c44f6 into master Aug 20, 2026
20 of 23 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants