State the check mode's real coverage, which is wider than the payloads - #543
Merged
Conversation
The header claimed check verifies exactly what the payloads declare and that anything not in settings.json is unaudited. Both halves understate it: the script also asserts has_discussions and default_branch, which apply computes rather than reads from a file, and the two Dependabot security features, which apply enables and no payload declares. This is an over-correction of the previous defect rather than a new one. The header used to over-promise, claiming every applied ruleset and setting must match while the code compared a fraction. Rewriting it to say "exactly what the payloads declare" fixed the over-claim by introducing an under-claim, and a coverage note that is wrong in either direction misleads whoever reads it to decide what still needs checking by hand. It now names the three groups check actually asserts and says which one is payload-driven, so the single genuine gap, a static setting absent from settings.json, is stated rather than implied. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the repo-config/configure.sh header comment so check mode’s documented coverage matches what the script actually validates (payload-driven rulesets/static settings, derived settings, and Dependabot security toggles), and clearly states the single remaining gap.
Changes:
- Reword
checkmode header to describe the three asserted groups (payload-driven + derived + security toggles). - Clarify which assertions are payload-driven vs asserted-by-name, and narrow the “unaudited” statement to static settings absent from
settings.json.
ptr727
added a commit
that referenced
this pull request
Aug 3, 2026
The report cited #536, #540 and #543 through `issue-*` link labels while their definitions pointed at `/pull/` URLs, so the label contradicted what it resolved to. #456 is a real issue and keeps its label. The External group is alphabetized, which the ordering had drifted from once `pr-545` was appended. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the finding on the promotion #542. A promotion's head is
develop, which is protected, so the fix lands here and #542 picks it up when this merges.The finding
Correct on the facts.
check_settingsassertshas_discussions(computed fromprivate) anddefault_branch(whenmainexists), andcheck_securityasserts the two Dependabot features. None of those comes from a payload.Why it happened, which is the part worth recording
This is an over-correction of the defect #540 fixed, not a new one.
The header used to over-promise: "every applied ruleset, setting, and security feature must match", while the code compared a fraction. #540 rewrote it to "exactly what the payloads declare", which fixed the over-claim by introducing an under-claim.
A coverage note that is wrong in either direction misleads the person reading it to decide what still needs checking by hand. Over-claiming tells them to skip something unverified. Under-claiming tells them to re-check something already covered, and erodes trust in the rest of the note. Landing on the true statement took two passes and a reviewer, which is the honest record.
The change
The header now names the three groups
checkactually asserts, says which one is payload-driven, and states the single genuine gap rather than implying a larger one:applycomputes, asserted by namesettings.json, because only that group is payload-drivenVerification
bash -nclean,prose_lintclean, and a livecheckagainst this repo still passes with all three groups asserted.