Repository navigation
Hub-Owned Carried Content Gets Its First Real Review Only When a Downstream Repo Carries It #1138
Description
Grouping issue, filed as part of a catalog pass over the 2026-08-28 to 2026-08-31 resync and MTP conversion campaign. This issue records the shared cause and adopts the affected issues as sub-issues. It proposes no fix.
The shared cause
Hub-owned content under .agents/skills/, GOVERNANCE.md, WORKFLOW.md, AGENTS.md and AUDIT.md is authored, reviewed and merged here against a diff that is usually small. The whole tree only ever reaches a reviewer as new files, in full, when a downstream repository carries it for the first time. So the first real review of hub canonical content happens in a repository that cannot act on the result: the tree is manifest-owned, scripts/carry.py check compares source and target digests, and a local edit becomes drift on the next fidelity check.
Two consequences follow, and both are visible in the children below.
Every carrier re-discovers the same defect. #1121 records two of its findings as already filed, both of them #1089's, raised independently against a third downstream repository. #1113 records the same for two more of #1089's findings against a second one. #1119 states the forward case in as many words: D1.6 is carried by every C# and Python repository, each remaining MTP migration re-vendors the paragraph, and each of those pull requests is set up to draw the same finding against the same sentence and spend a decline on it.
The finding arrives without a verifier. #1131 files 16 findings against the carried skills tree with one verified and the rest reported as the reviewer stated them, and says why: an earlier batch of unverified claims on #1116 needed six of ten retracted. The reviewer reads hub content in a repository whose session has no hub checkout and no standing to test the claim.
Children
| Issue | Surfaced by | Content |
|---|---|---|
| #1078 | ptr727/PhotoCleaner#87 | comment-and-doc-style title-case example contradicts its own rule |
| #1089 | ptr727/ESPHome-Config#115 | 5 defects: shell-codestyle, repo-worktree, standup-a-repo, merge-and-release |
| #1092 | ptr727/ESPHome-Config#116 | 7 defects: merge-and-release, python-codestyle, GOVERNANCE.md, WORKFLOW.md |
| #1113 | ptr727/Utilities#451, #453 | 19 defects across the guard, resync, drive-pr, git-commit, pr-review, AUDIT.md, GOVERNANCE.md |
| #1119 | ptr727/PhotoCleaner#95 | D1.6 Codecov file-finder sentence, and every carrier will be told so |
| #1121 | ptr727/Financial-Modeling#204 | 6 defects: dotnet-codestyle, python-codestyle, local-strict-review, operational-vs-release-workflow |
| #1131 | ptr727/NxWitness#550 | 16 CodeRabbit findings against the carried skills tree |
What a fix at this level would have to address
Not the individual defects, which the children already carry, but the ordering: whether hub canonical content can be put in front of a reviewer here, in full, before a downstream repository is the one to find it.
Related but separately caused: #1075 and #1120 (the carried declaration drifting from the docs) and #1118 and #1129 (verbatim fidelity admitting no per-carrier variance) each have their own grouping issue.
Activity
Review Hub Canonical Content Here, Before a Carrier Is the One to Rea…
Read the Review-Loop Skills Whole, and Fix What Would Fail If Followed (
Fix Carried Text a Downstream Repository Cannot Fix in Its Own Copy (#…
Promote develop to main: carried-text fixes a downstream repository c…
ptr727 commentedon Sep 7, 2026
CodeRabbit reviewed the carried Skills tree in two downstream repositories during the #1399 resync
pilot, on ptr727/Utilities#466 and ptr727/PlexCleaner#954. Both carries were byte-clean against
the hub, so every finding is against hub-authored text, not against either repository.
This is #1138 measured rather than asserted, and the measurement says something the single-repo
case could not.
The finding sets barely overlap
15 distinct findings across the two pull requests. Three appear in both, at identical file and
line:
audit-a-repo/SKILL.md:21dotnet-codestyle/references/testing.md:33operational-vs-release-workflow/references/release-publish-mechanics.md:138backlog-burndown/SKILL.md:145,:378,:417pr-review-conduct/SKILL.md:69repo-worktree/SKILL.md:186drive-pr/SKILL.md:80,:93,:105local-strict-review/SKILL.md:58pr-review-conduct/SKILL.md:189skill-lifecycle/SKILL.md:18workflow-ci-contract/SKILL.md:31Identical file and line in two unrelated repositories proves the finding is a property of the hub
text. A 3-of-15 overlap proves the reviewer does not return the same set twice, so each further
repository carrying this tree surfaces a partly new set of hub defects, and no single repository's
review is a complete read of it.
What follows for the fleet
Triaging these per repository answers the same hub defect once per carrier and improves no carrier.
The maintainer's call, taken on this evidence, is that the resync carries are not held for them:
each is declined in its own pull request under the carrying-repository rule, ownership sitting
here, and gathered onto the per-unit trackers instead.
The second call bounds how many more arrive. Advisory review is not available fleet-wide:
So the remaining resync pull requests are not to be prompted. The five above the gate surface
what they surface at no cost, and prompting the other seven multiplies a triage burden for defects
already known here.
Disposition
Each finding is filed on its unit's tracker, and this comment is the index of the run that produced
them. Three units have no tracker yet and need one:
.agents/skills/audit-a-repo/SKILL.md,.agents/skills/dotnet-codestyle/references/testing.md, and.agents/skills/operational-vs-release-workflow/references/release-publish-mechanics.md, which isthe same three that appeared in both repositories.