fix(effort): restrict share denominators to the banded population - #179
Merged
Conversation
The band shares divided banded churn by ALL window churn: total_churn had no eh_bands_v1 join and total_commits counted every window commit, so lockfile, docs and config churn deflated every share and the red-effort ceiling under-fired monotonically with non-code churn — a repository passed the gate more easily the more lockfile churn it carried. The denominators now carry the same banded restriction as the numerators, so each share reads as a share of code-health-scorable activity; the improving/degrading decomposition and the commit-share Wilson interval ride the same corrected population. On this repository the corrected shares sum to 100.0 where they previously summed to 34.6.
… basis The previous ceiling (15.0) was calibrated against the deflated shares — this repository's window is roughly two-thirds non-code churn, so every band read ~2.89x low and the gate passed only because of the defect just fixed. On the corrected basis today's degrading red share measures 28.98 (raw red 37.91, improving 8.92 exempt). The ceiling tracks that measured worst with margin; the thresholds comment records the restore intent toward a corrected steady state once the campaign churn rolls out. Approved by the maintainer.
…inator # Conflicts: # CHANGELOG.md
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
2 participants
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.
Summary
Validated High finding, alone in its PR because it changes effort-exposure output on every repository with non-code churn:
band_churnjoined the banded-paths table whiletotal_churnandtotal_commitsdid not, so lockfile/docs/config churn deflated every share — the gate got monotonically more permissive the more lockfile churn a repository carried (executed example: band-consistent 60.0 vs computed 6.0 against a ceiling of 30). Both denominators now carry the banded restriction; the improving/degrading decomposition reconciles against the same population (pinned by tests) and the commit-share Wilson interval rides the corrected n. The production-SQL fixture pins the report's scenario exactly.The honest consequence, disclosed: this repository was passing its own red-effort gate only because of the bug — corrected shares sum to 100.0 where they summed to 34.6, and today's degrading share reads 28.98 vs the old 15.0 ceiling (calibrated on the deflated basis). The maintainer-approved second commit re-bases the ceiling to 30.0 on the corrected basis, with the restore intent documented in the thresholds file — same pattern as every basis-change re-base this campaign.
Verification