Surfaced while resyncing ptr727/NxWitness. The maintainer noticed the floor had moved and asked when and by whom. The answer is worth the fleet's attention, because the guard that was supposed to prevent it is prose, and prose did not hold.
What the history shows
version.json's major.minor floor in NxWitness, most recent first:
| PR |
Change |
Stated reason |
Agent co-authored |
| #461 |
2.14 -> 2.15 |
one line item inside a large CI/CD migration |
yes |
| #451 |
2.13 -> 2.14 |
bump plus an LSIO permissions fix, with a HISTORY.md entry |
yes |
| #437 |
2.14 -> 2.13 |
rollback: "the 2.13 release chore bumped to 2.14, but this release ships as 2.13" |
yes |
| #436 |
-> 2.14 |
the bump #437 reverted |
yes |
| #425 |
2.12 -> 2.13 |
"establishing the develop-leads invariant: raises develop's minor so develop's NBGV prereleases sort above main's last stable" |
yes |
Every one carries Co-authored-by: Claude Opus <...>. None was a maintainer's own edit.
Why this is a fleet problem rather than one repo's
The rule these bumps followed no longer exists. #425 states its reason as maintaining a develop-leads-main invariant. operational-vs-release-workflow/SKILL.md:98-102 now says the opposite in as many words: the floor is "edited by the maintainer for functional changes only, in the PR that introduces the work, never on a fixed cadence or mechanically after a release", with "no post-release bump and no develop-ahead requirement". So a repo can carry years of agent-authored bumps made under a policy the fleet has since reversed, and nothing re-examines them.
Author identity cannot distinguish an agent bump from a maintainer bump. Agents commit under the maintainer's noreply identity by design, so git log --format=%an on version.json shows the maintainer for all five. I initially reported one of these to the maintainer as his own commit on exactly that evidence, and he corrected me. The only reliable signal is the Co-authored-by trailer, which is a convention rather than an enforced field. An audit or a human reviewing "who has been moving the floor" gets a wrong answer from the obvious query.
"Maintainer-controlled" is stated only in prose. There is no mechanical guard: no audit check on version.json authorship, no CODEOWNERS entry, nothing in spec/ that treats a floor change as needing a different disposition from any other file change. A rule that only exists as a sentence in a Skill is one an agent can follow, misremember, or inherit a stale version of, and these five PRs are what that looks like over time.
The part that cannot be undone
NxWitness cannot roll #461 back. Releases 2.15.43 through 2.15.59 have published since 2026-07-27, and NBGV derives the patch from git height, so a lower floor would generate versions sorting below what is already published. #437 could revert cleanly because nothing had shipped at 2.14 yet; that window closes the moment a release is cut. So the cost of a wrong bump is bounded only by how quickly someone notices, and nobody noticed this one for two months.
Compounding it: #461 moved the floor without adding a HISTORY.md entry, so 2.15 shipped undocumented and both the README and HISTORY.md still described 2.14 as current. Reading every merge since the 2.14 entry, 2.15 contains no image-facing change at all, which is the evidence the bump should not have happened. It is now documented as an infrastructure-only release in ptr727/NxWitness#552, forward-only, per the maintainer's call.
Worth deciding
- Should a floor change be mechanically guarded rather than prose-guarded? A
CODEOWNERS entry on version.json would make it a maintainer-approved change by construction. An audit.py check could at least report a floor change whose commit carries an agent Co-authored-by trailer, which turns an invisible event into a finding.
- Should a floor change require a
HISTORY.md entry in the same PR? The two are already coupled in intent (the version is what the entry names), and the coupling is currently unenforced. This is the second-order failure that made the first one durable.
- Is a fleet-wide sweep warranted? If NxWitness accumulated five agent-authored bumps under a retired rule, the other release-model repos plausibly did too, and nobody has looked.
Happy to run the same history query across the fleet's release repos if that is useful.
Surfaced while resyncing
ptr727/NxWitness. The maintainer noticed the floor had moved and asked when and by whom. The answer is worth the fleet's attention, because the guard that was supposed to prevent it is prose, and prose did not hold.What the history shows
version.json'smajor.minorfloor in NxWitness, most recent first:HISTORY.mdentryEvery one carries
Co-authored-by: Claude Opus <...>. None was a maintainer's own edit.Why this is a fleet problem rather than one repo's
The rule these bumps followed no longer exists.
#425states its reason as maintaining a develop-leads-main invariant.operational-vs-release-workflow/SKILL.md:98-102now says the opposite in as many words: the floor is "edited by the maintainer for functional changes only, in the PR that introduces the work, never on a fixed cadence or mechanically after a release", with "no post-release bump and no develop-ahead requirement". So a repo can carry years of agent-authored bumps made under a policy the fleet has since reversed, and nothing re-examines them.Author identity cannot distinguish an agent bump from a maintainer bump. Agents commit under the maintainer's
noreplyidentity by design, sogit log --format=%anonversion.jsonshows the maintainer for all five. I initially reported one of these to the maintainer as his own commit on exactly that evidence, and he corrected me. The only reliable signal is theCo-authored-bytrailer, which is a convention rather than an enforced field. An audit or a human reviewing "who has been moving the floor" gets a wrong answer from the obvious query."Maintainer-controlled" is stated only in prose. There is no mechanical guard: no audit check on
version.jsonauthorship, noCODEOWNERSentry, nothing inspec/that treats a floor change as needing a different disposition from any other file change. A rule that only exists as a sentence in a Skill is one an agent can follow, misremember, or inherit a stale version of, and these five PRs are what that looks like over time.The part that cannot be undone
NxWitness cannot roll #461 back. Releases 2.15.43 through 2.15.59 have published since 2026-07-27, and NBGV derives the patch from git height, so a lower floor would generate versions sorting below what is already published. #437 could revert cleanly because nothing had shipped at 2.14 yet; that window closes the moment a release is cut. So the cost of a wrong bump is bounded only by how quickly someone notices, and nobody noticed this one for two months.
Compounding it: #461 moved the floor without adding a
HISTORY.mdentry, so 2.15 shipped undocumented and both the README andHISTORY.mdstill described 2.14 as current. Reading every merge since the 2.14 entry, 2.15 contains no image-facing change at all, which is the evidence the bump should not have happened. It is now documented as an infrastructure-only release in ptr727/NxWitness#552, forward-only, per the maintainer's call.Worth deciding
CODEOWNERSentry onversion.jsonwould make it a maintainer-approved change by construction. Anaudit.pycheck could at least report a floor change whose commit carries an agentCo-authored-bytrailer, which turns an invisible event into a finding.HISTORY.mdentry in the same PR? The two are already coupled in intent (the version is what the entry names), and the coupling is currently unenforced. This is the second-order failure that made the first one durable.Happy to run the same history query across the fleet's release repos if that is useful.