Guard the module count in Header.ps1's description - #103
Merged
Conversation
A count audit across every documented surface found exactly three stale
numbers, and all three sat outside what section 174 can reach:
- the GitHub repo description advertised a 167-action toolkit against a
live 201 (fixed via the API; repo metadata is not in the tree, so no
test can ever see it)
- the wiki said 189 available actions (separate repository, fixed there)
- Header.ps1's .DESCRIPTION claimed 78 modules against a live 81
Every file section 174 does cover was correct, including the README's
action, module and structural-test counts and the Pester badge, which was
verified against a live count of exactly 312. The guard works; the rot
appeared precisely where it does not look.
Header.ps1 is worth adding because its preamble is the text that lands at
the top of the generated monolithic and therefore inside the shipped EXE.
The assertion is scoped to the text before the first .CHANGELOG. Everything
after it is version history, where "64 modules, 1873 tests" is a true
statement about v1.20.4 -- a whole-file check would demand falsifying the
changelog to go green. A separate assertion fails loudly if that .CHANGELOG
marker ever disappears, so losing the scope boundary cannot silently turn
this into a false-positive machine.
Mutation-verified three ways: a stale preamble count is caught, the
historical entries are correctly left alone, and removing the scope marker
fails rather than scanning history.
Structural tests 5493 -> 5495.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
What prompted this
The GitHub repo description was advertising a 167-action toolkit against a live 201 — the
single most-read line about the project, understating it by 17% in search results. That raised the
obvious question of what else had drifted, so I swept every count on every documented surface.
The audit result
Exactly three stale numbers existed, and all three sit outside what Section 174 can reach:
CLI-Automation.md)Header.ps1.DESCRIPTIONEvery file Section 174 already covers was correct — README's action, module and structural-test
counts,
34-Help,RackStack.psd1, and the dist manifests. The Pester badge claims 312 and thelive count is exactly 312. The guard works; the rot appeared precisely where it doesn't look.
Why Header.ps1 belongs in the guard
Its preamble is the text that lands at the top of the generated monolithic, and therefore inside the
shipped EXE.
The assertion is scoped to the text before the first
.CHANGELOG. Everything after that isversion history, where
64 modules, 1873 testsis a true statement about v1.20.4. A whole-filecheck would demand falsifying the changelog to go green — the same shape as the doc-tree corruption
caused by a blanket substitution back in July. A second assertion fails loudly if that
.CHANGELOGmarker ever disappears, so losing the scope boundary can't silently turn this into a false-positive
machine.
Tests
Mutation-verified three ways:
64 modulesentries left in place → correctly not flagged (positive control).CHANGELOGmarker removed → caught, fails rather than scanning historyStructural tests 5493 → 5495. Full gate: 42 passed / 0 failed / 0 warnings, suite 5495/5495.
Known remaining gap
The GitHub description and topics can't be guarded from inside the repo. Noted for manual check
whenever the action count changes — same class as the Scoop bucket's manual version bump.
On merge
No version bump — this does not cut a release.