Skip to content

Agents moved a repo's version floor four times under a retired cadence rule; prose alone did not hold #1124

Description

@ptr727

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

  1. 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.
  2. 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.
  3. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions