Promotion candidates and two interface gaps found resyncing NxWitness

[ptr727]

Found while resyncing ptr727/NxWitness against hub f3b4cc9. Filing rather than
changing anything here, per the resync's own "fix systemic drift in the hub instead"
rule. Nothing in this issue is a defect in NxWitness.

Context

NxWitness's AGENTS.md predates the AGENTS.md/GOVERNANCE.md router split, so it
still carries topical rule text inline. Running the
carried-instruction-file-guard distinctive-phrase probe over it against the hub
canonical (AGENTS.md, GOVERNANCE.md, CODESTYLE.md, WORKFLOW.md,
OPERATIONS.md, README.md) turned up rules that are absent from all six and
that read as fleet-wide rather than repo-specific. Those are listed below as
promotion candidates.

A caveat on the probe's reach: the hub has moved much rule text into
.agents/skills/*/SKILL.md, and the probe was scoped to the six Markdown files.
Candidates 5 and 7 are marked accordingly and want a second check against the named
Skill before anyone acts on them.

Promotion candidates

1. The develop-leads-main-by-a-minor version cadence, with bump-version-X.Y
   as the PR convention. Release-model mechanics that GOVERNANCE.md "Release
   Model" does not state.
2. The maintenance-promotion version hold: git checkout main -- version.json
   when promoting a maintenance fix that must not carry develop's minor bump.
3. The one-time floor bump carve-out, a deliberate maintainer-directed version
   floor move during a build/release overhaul, stated as an exception to the
   routine cadence.
4. Mirror to develop any change that lands on main outside the
   feature -> develop -> main flow, with git diff origin/develop origin/main as
   the concrete pre-work staleness check. The case is a security PR or hotfix
   landing on main directly; GOVERNANCE.md "Branching Model" does not give this
   check.
5. Closes #N belongs on the develop -> main promotion PR, not on the
   feature PR or the develop PR, so the issue closes when the work actually
   reaches main.
6. The title-case bind-word list (a, an, the, and, but, or, of, in, on, at, to, by, for, from) plus the hyphenated-compound rule. Check
   comment-and-doc-style SKILL.md first.
7. file does not report CRLF for JSON, as a caveat on byte-checking line
   endings. GOVERNANCE.md:185 covers the Python read/write flattening mechanism
   but not this detection failure. Relevant now that the fleet is normalizing to
   LF.
8. The three-rounds heuristic: three review rounds on the same style category
   means the rule is wrong, not the author, so flip the rule once and stick to it.
   Check pr-review-conduct SKILL.md first.

One negative candidate

NxWitness's AGENTS.md "PR Review Etiquette" opens with a blockquote reading
"Mandatory in every derived repo ... carried verbatim". That directive belongs
to the pre-Skill carry model the hub has since retired. It should be deleted on the
downstream side rather than promoted, and it is worth checking whether any other
repo still carries the same blockquote and would re-assert a model the hub no
longer runs.

Two interface findings that look like drift and are not

spec/audit.py reports these against NxWitness:

DRIFT  interface: .github/workflows/publish-release.yml missing required job 'publish'
DRIFT  interface: .github/workflows/merge-bot-pull-request.yml missing required job 'merge-bot'

Both requiredJobKeys contracts in spec/files.json resolve, through
requireTokensInJob, to calling a hub-hosted task workflow
(build-release-task.yml, merge-bot-task.yml). NxWitness has not adopted either,
and spec/divergences.json already says of the release chain that "adoption is a
separate, later change per repo". NxWitness's own jobs are plan, get-version,
build-base, validate, build-docker, github-release, docker-readme-repos,
docker-readme for the publisher, and merge-dependabot, merge-codegen,
disable-auto-merge-on-maintainer-push for the bot merger. That shape is its
documented multi-image, shared-base fan-out.

So the finding is accurate about the contract and misleading about the remedy: a
repo could satisfy it by renaming a job, which would report conformance without
adopting anything. Worth considering whether a pre-adoption repo should report
these as a pending adoption class rather than DRIFT, the way the manifest
already distinguishes a LETTER from a DRIFT.

Not filed here

NxWitness's own convergence issue is separate and uses
python3 spec/audit.py --issue NxWitness. No audit report or registry change is
being written back to this repo as part of that resync.

[ptr727]

Two more, found completing the AGENTS.md split in ptr727/NxWitness (see ptr727/NxWitness#551). Both are rules that existed in NxWitness's pre-split AGENTS.md, are absent from the current hub canonical and from every carried Skill, and read as fleet law rather than repo-specific.

9. Leave human-authored comments exactly as written

NxWitness's pre-split AGENTS.md, under "Comments":

Leave human-authored comments and emojis exactly as written - do not reword, trim, reflow, or "clean" them, even if they seem to bend a rule. Revise only agent-authored comments, and match the surrounding voice when you do.

Not in GOVERNANCE.md "Documentation Style Conventions", and not in comment-and-doc-style SKILL.md. The developer-typed-Unicode carve-out in that Skill is adjacent but governs characters, not authorship.

This one has teeth because the carried rules actively push the other way. comment-and-doc-style tells an agent "Keep it short: one line is the default" and "Never let a comment grow across edits", so an agent editing near a maintainer's deliberately two-line comment has a rule telling it to collapse the comment and none telling it to leave a human's alone. That is a silent, low-grade erosion of maintainer-authored text, and it is the kind that nobody notices until a comment they wrote is gone.

Carried locally into NxWitness's CODESTYLE.md for now so the rule is not lost while this is considered, but it belongs fleet-wide.

10. Sweep stale review threads after the final push

Same file, under "PR Review Etiquette":

After the final push on a PR, sweep older threads from earlier rounds whose code paths no longer exist; otherwise stale unresolved markers remain in the review UI.

Not in GOVERNANCE.md "PR Review Etiquette" and not in pr-review-conduct SKILL.md. Both cover answering and resolving a thread on the current round; neither covers a thread from round 1 whose code no longer exists by round 4. The observable result is a pull request that reads as having unresolved feedback when it does not, which is exactly the state the Merge Gate is trying to measure.

Note on how these surfaced

Neither was caught by the distinctive-phrase probe I ran before the split, and neither was caught by the 29-phrase preservation checklist I built from the pre-split file. Both were found by an adversarial review pass reading the original unit by unit rather than by keyword. That is worth recording on its own: a phrase probe answers "is this text in the hub", and it does not answer "is this rule anywhere", so a rule that was reworded out of existence passes both checks. The unit-by-unit read is what a split actually needs.

[ptr727]

Correction: six of the ten candidates above are wrong

I filed these without checking them against the .agents/skills/ tree, and most of them do not survive that check. The original probe was scoped to the six top-level Markdown files and explicitly flagged several candidates as needing a second look at the named Skill first. I did not do that second look before filing. Re-measured against the carried skills in ptr727/NxWitness at the tip of ptr727/NxWitness#551, which carries .github/skills/ at hub f3b4cc9:

#	Candidate	Verdict
1	bump-version-X.Y develop-leads-main cadence	Contradicted. operational-vs-release-workflow/SKILL.md:98-102 says the floor is edited "never on a fixed cadence or mechanically after a release", with "no post-release bump and no develop-ahead requirement".
2	git checkout main -- version.json maintenance hold	Contradicted, same rule. It is the mechanism for the cadence in 1.
3	Maintainer-directed floor-bump carve-out	Contradicted, same rule. The floor is edited in the PR that introduces the work.
4	Mirror main -> develop, with the git diff origin/develop origin/main check	Partially covered. SKILL.md:44 covers checking develop before branching. The other half, mirroring a change that landed on main outside the normal flow back into develop, is genuinely absent. Narrowed candidate, still open.
5	Closes #N on the promotion PR	Already in the hub, operational-vs-release-workflow/SKILL.md:62-65, with the same rationale.
6	Title-case bind-word list	Already in the hub, comment-and-doc-style/SKILL.md:234-235, with the identical word list (a, an, the, and, but, or, of, in, on, at, to, by, for, from).
7	file does not report CRLF for JSON	Already in the hub, comment-and-doc-style/references/line-endings.md:100.
8	Three-rounds heuristic	Substantially covered, pr-review-conduct/SKILL.md:129-132 ("Bouncing the same point across rounds is the signal to escalate the rule itself"). NxWitness adds only a numeric threshold and "flip the rule once and stick to it", which is a refinement rather than a missing rule. Low value.
9	Leave human-authored comments exactly as written	Confirmed absent. Not in comment-and-doc-style/SKILL.md, its three reference files, GOVERNANCE.md, or CODESTYLE.md.
10	Sweep stale review threads after the final push	Confirmed absent. Not in pr-review-conduct/SKILL.md, drive-pr/SKILL.md, or GOVERNANCE.md.

So the actionable list is 9 and 10, plus the narrowed half of 4. Items 1, 2 and 3 are the opposite of a promotion candidate: they are a downstream repo carrying a rule the fleet has since ruled against, and NxWitness#551 correctly drops them. Worth knowing that a repo was running a develop-ahead version cadence that current fleet law forbids, in case another repo still is.

The process failure, which is the more useful finding

A distinctive-phrase probe over the six Markdown files answers "is this text in these files". It does not answer "is this rule anywhere in the fleet", because most rule text now lives in .agents/skills/. Probing the Markdown files alone and filing on the result produces exactly this: a promotion candidate for a rule the hub already states, sometimes verbatim.

Two things would have caught it. The probe should cover .agents/skills/** alongside the Markdown files, since that is where the rules moved. And a promotion candidate should be re-measured against a repo that actually carries the skills tree before it is filed, which is cheap once carry.py apply has run.

Worth considering whether carried-instruction-file-guard should say this outright. Its step 2 says to grep "the hub's canonical copy of the same file", which was accurate before the Skill split and now points at the smaller half of the corpus.