Repository navigation
Promote repo-side fixes to main — no plugin change - #95
Merged
Merged
Conversation
fixes #65 re.subn was called with count=1, which caps the REPORTED substitution count at 1 — so `n != 1` could only ever catch zero matches. A second occurrence of the pattern (a version string quoted twice in the README, say) would be left un-edited and ship in a release the bumper reported as successful. Dropping the cap makes the guard mean what it says. Removing it is safe because every edit is computed before any file is written, so a duplicate aborts with nothing touched — same reasoning as the fix praxen landed. Adds tests/test_bump_version.py: single match substitutes, zero matches abort, duplicate aborts. Negative-verified — the duplicate case fails red against the old count=1 version. Found while porting the script to praxen (praxen#233 review). Signed-off-by: Steve Wilson <steve.wilson@exabeam.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Every finding from the 2026-08-12 scan is now a GitHub issue (#6, #71, #82, #86, #88-#93, plus 001/007/009 fixed in 0.7.0), so the in-repo table was a second copy of status with nothing to add. It had already drifted, which is the argument: nine of thirteen rows still read 'awaiting triage' after several had been fixed or filed. Status in two places diverges — the same failure mode this repo has now found three times in its own docs. What is deliberately kept: the dated artifacts under results/ remain the authoritative record of what was found (severity, evidence, file:line citations) and are never edited after the fact, which is what CONTRIBUTING's release-gate rule actually asks for. The gate verdict and RAISE posture stay on the page as the scan's headline. Traceability preserved before deleting: every finding ID now appears in its issue, so PRAX-2026-08-12-0NN stays searchable. Four issues (#82, #86, #88, and #6) did not name their ID and were tagged first — deleting the table before that would have severed the link between a finding and its issue. Signed-off-by: Steve Wilson <steve.wilson@exabeam.com> Co-authored-by: Claude Fable 5 <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.
Promotion
dev → main. Merge commit, never squash (gh pr merge --merge), then fast-forwarddevback up.No version bump, deliberately
plugin/is byte-identical to 0.7.0 — verified:git diff origin/main origin/dev -- plugin/is empty. Nothing a user installs changes.Bumping anyway would push an update to every installed copy that re-downloads identical content and changes nothing, which is the opposite of the 0.6.6 rule ("a plugin update is only delivered when the version moves" — the point being that a bump is how you deliver a change, not a ritual per merge). The plugin stays at 0.7.0; the CHANGELOG records both items under
[Unreleased]so they ride the next real bump rather than vanishing between releases.What lands on main
The Praxen triage table is deleted (#94). This is the reason for promoting now rather than waiting — the table is on the public repo page, and it had drifted: nine of thirteen rows still read "awaiting triage" after several had been fixed or filed. Every finding from the 2026-08-12 scan is now a GitHub issue, so the in-repo table was a second copy of status with nothing to add and a standing invitation to be wrong in public.
Kept on the page: the gate verdict and RAISE posture, and the determination that this scan is 0.7.0's gate artifact. Kept on disk: the dated files under
security/praxen/results/, which remain the authoritative record of what was found — severity, evidence,file:linecitations — and are never edited after the fact. That is whatCONTRIBUTING.md's release-gate rule asks for; the table was only ever an index over it.Traceability was preserved before the deletion: four issues (#82, #86, #88, #6) didn't name their Praxen finding ID and were tagged first, so
PRAX-2026-08-12-0NNstays searchable. Deleting first would have severed the only link between a finding and its issue.bump_version.py's duplicate guard can now fire (#65, #85).re.subn(..., count=1)capped the reported count at 1, so then != 1check could only ever catch zero matches. A version string appearing twice would have had the first bumped and the second silently left stale, with the bumper reporting success. Also adds that script's first tests — negative-verified against the old code.Verification
268 tests pass · AI BOM current ·
plugin/diff against main empty · no dangling references to the deleted section or its anchor · every relative link in the changed file resolves.After merge
Fast-forward
dev(git merge --ff-only origin/main && git push origin dev) to hold the main-is-ancestor-of-dev invariant. No install smoke needed — the payload didn't change, so there is nothing new for a clean-install or upgrade leg to exercise.🤖 Generated with Claude Code