Fleet Resync Owed by 2.0.577: Five Verbatim GOVERNANCE.md Sections and AGENTS.md's Where the Rules Live Went Stale

[ptr727]

Filed so the obligation has a home. Until now it existed only in the bodies of #1395 and #1397 and
in #1311's step 17 and 18 comments, none of which a downstream repo or a later session reads.

What went stale

f8e7491d (#1397, released as 2.0.577) changed carried content at verbatim fidelity, which
spec/files.json byte-locks, so every carrying repository's copy is now wrong rather than merely
old.

Surface	Fidelity	Changed by
GOVERNANCE.md > Workflow YAML Conventions	verbatim	#1395
GOVERNANCE.md > Verification Discipline	verbatim	#1330, #1333
GOVERNANCE.md > Communicating with the User	verbatim	#1382
GOVERNANCE.md > Durable Knowledge and Self-Improvement	verbatim	#1382
GOVERNANCE.md > Release Model	verbatim	#1395
AGENTS.md > Where the Rules Live	verbatim	#1378, #1395

Also changed, at intent fidelity, so a carrier adapts rather than copies: WORKFLOW.md
(sections 2, 3, 4, 5 and 6 all reshaped), CODESTYLE.md, AUDIT.md,
.github/copilot-instructions.md, the AGENTS.md preamble, and OPERATIONS.md.

GOVERNANCE.md > Running the Linters Locally (Known-Working Invocations) also changed and is
not carried, so it is out of scope here.

Correction to what #1397's body claimed

That pull request's body, and #1311's step 17 and 18 comments, each say spec/files.json declares
"both edited GOVERNANCE.md sections" at verbatim fidelity. That sentence was written for #1395
alone and was carried into the promotion body without being re-derived against all sixteen
commits. Six GOVERNANCE.md sections changed, five of them verbatim, and AGENTS.md has a
verbatim changed section too. The resync scope is wider than those bodies state, and this table
is the scope rather than that sentence.

Scope

24 repositories are cataloged in registry/repos.json, 23 of them downstream of this hub. Which
of those actually carry each surface is what AUDIT.md determines per repository, so the target
set is the audit's output rather than a list guessed here.

How to run it

Per repository, from a hub checkout fetched immediately before reading it, resync-a-repo, which
runs AUDIT.md end to end for the findings and then applies them in the order RESYNC.md sets. A
resync is a branch and a pull request in the target repository, never a direct write, and the audit
itself is read-only.

Note for whoever picks this up: the three registered ProjectTemplate-*-resync worktrees and the
ProjectTemplate-hac-orchestrator clone on this host are all stale hub copies (at 0c4e148,
f3b4cc9 and 3a4c02a). Fetch before reading any of them, per GOVERNANCE.md "Repository
Boundaries and Write Safety", since a stale clone answers confidently rather than failing.

Known interactions

#1145 (a resync leaves registry/repos.json describing the pre-resync repository), #727 (an intent
finding verified satisfied cannot be cleared, so a correct resync never runs clean), and #1139 (a
resync pull request is the first review a downstream repo's own long-standing files have had) each
bear on this run and are not resolved by it.

[ptr727]

Pilot started, audit run 2026-09-07T02:37:02Z | hub f8e7491, three repositories chosen to cover
both workflow models: Utilities (release, csharp/nuget) at main@ab346a4, PlexCleaner
(release, csharp/docker/python) at main@b37279e, and HomeAutomation-Config (operational,
source-only) at main@d68f8d2.

The scope table above is the promotion's delta, not any repository's resync scope

This is worth correcting here, because the table invites being read as a work list and it is not
one.

A repository trails from wherever it last converged, not from the previous release, so the audit
finds sections 2.0.577 never touched. Measured, per repository:

Repository	Verbatim sections stale	Beyond this issue's table
Utilities	6 in GOVERNANCE.md, 2 in AGENTS.md	PR Review Etiquette, Context and Delegation Discipline
PlexCleaner	6 in GOVERNANCE.md, 2 in AGENTS.md	PR Review Etiquette, Context and Delegation Discipline
HomeAutomation-Config	8 in GOVERNANCE.md, 2 in AGENTS.md	the two above, plus Operational Repositories and Repository Boundaries and Write Safety

So the table states what this promotion made stale, and the audit per repository states what that
repository is owed, which is the wider number in every case measured so far. The How to run it
section already says the target set is the audit's output; this says the same is true of the
surface list within each repository.

The three also each carry a stale .github/skills/ tree: 19 files trailing and 2 absent on
Utilities, with the absences being the baseline having grown (backlog-burndown/SKILL.md and
workflow-ci-contract/references/architecture.md) rather than a standup gap.

develop is as stale as main on all three

Re-run with --branch develop, the finding counts came back 37/41/46 DRIFT against 37/41/46 at
main. No convergence is part-way done on any of them, so each resync branches from a develop
that carries the full drift.

Shipping shape

One pull request per drift class, the mechanical carry class first: the .github/skills/ tree
via scripts/carry.py apply, plus the stale verbatim sections re-vendored in place. The
intent-fidelity files are judged by meaning rather than copied and are a separate change, and the
live settings defects are a separate apply again.

First one open: ptr727/Utilities#466.

#1401 was filed from this pilot: the verbatim section re-vendor is the one step in RESYNC.md
section 3's apply order with no tested tool behind it, and the throwaway script written for it
here had a defect that only a separately written postcondition assertion caught.

[ptr727]

Pilot complete, and paused here on the maintainer's call to regroup before carrying the remaining
repositories. audit run 2026-09-07T02:37:02Z | hub f8e7491.

What landed

Repository	Pull request	Outcome
Utilities (release, csharp/nuget)	ptr727/Utilities#466	merged, 37 DRIFT + 2 LETTER to 8, all remaining intent
PlexCleaner (release, csharp/docker/python)	ptr727/PlexCleaner#954	merged, 41 DRIFT + 2 LETTER to 12
HomeAutomation-Config (operational, source-only)	ptr727/HomeAutomation-Config#160	open, blocked by #1403 until that fix reaches main

Every carried-tree and verbatim-section finding cleared in all three, measured with
spec/audit.py --branch before and after rather than asserted. What remains in each is the
intent class, which is judged by meaning and is a separate change, plus the live settings
defects.

The mechanical procedure worked and is repeatable: scripts/carry.py apply for the tree, then a
surgical replacement of only the sections spec/files.json declares verbatim, verified by
asserting that the preamble, the section set, the section order and every intent section are
byte-unchanged. That verification caught a real defect in my own replacer on its first run, which
is what #1401 is about.

What the pilot was actually for

The carry is cheap. The review of what the carry lands is not. Of the effort spent, almost
none went to the carries and nearly all went to defects the carries exposed.

spec/files.json byte-locks this content, so a downstream repository can fix none of it. Every
finding below was filed here.

Issue	What
#1401	The verbatim section re-vendor is the one step in RESYNC.md's apply order with no tested tool behind it
#1402	check_interface() false-flags a correct release gate written as a folded scalar, from #949's fix dropping every block-scalar body
#1403	A carried skill named hub-only repo-config/ paths, failing the downstream prose gate. Fixed, #1414
#1404	pr_review.py read unresolved=0 with an open qodo thread, because qodo posts under a second login the allowlist does not know
#1405	backlog-burndown's abandoned-group cleanup leaves a pushed branch on the remote, which every later round reads as a live file claim
#1406, #1407, #1408	Per-unit trackers created for three units that had none
#1412	A dead-path violation CI reports cannot be reproduced locally, so the fix loop is push and guess
#1413	Tracker for the branch-protection reference, holding seven findings, two of which can cause a wrong destructive action
#1416	Three follow-ups from the reviewer-rules change

Three findings that change how the rest of the resync should run

1. The reviewers repeat the hub's defects, not the repository's. CodeRabbit raised 15 findings
across the two public pull requests, every one against carried hub content and none against the
carry. Three appeared in both repositories at identical file and line, which proves they are
properties of the hub text. The other twelve did not, which proves the reviewer does not return the
same set twice, so each further repository surfaces a partly new set. Triaging them per repository
answers the same defect repeatedly and improves no repository, which is why they were declined
under the carrying-repository rule and gathered on the per-unit trackers, indexed on #1138.

2. Advisory review is not available fleet-wide, so most of the remaining repositories will not
surface anything. Ten of the 22 cataloged repositories are private, where neither CodeRabbit nor
qodo runs at all and Copilot alone is the complete reviewer set. Of the twelve public, five sit at
or above CodeRabbit's star gate and auto-review, and seven review only on request. The maintainer's
call is not to prompt the remaining pull requests, so the triage burden for the rest of the fleet
is bounded to those five.

3. develop was as stale as main in all three, so no convergence was part-way done anywhere
and each resync branched from a fully drifted base.

What should happen before the remaining 19

The hub defects above are the resync's real cost, and fixing them makes every later carry cheaper
rather than re-surfacing them one repository at a time. #1401 in particular would give the apply
order its missing tool, and #1412 would make a downstream gate failure diagnosable before a push
rather than after one.

The scope correction in this issue's earlier comment still stands: this issue's table is the
promotion's delta, and what each repository is owed is the audit's output for that repository,
which was wider in all three.