Tracker: `.github/copilot-instructions.md > Reviewing Carried Fleet Content`

[ptr727]

Tracker for .github/copilot-instructions.md > Reviewing Carried Fleet Content. Filed under the rule #1314's Merge Gate half writes into that unit: a finding classed pre-existing on carried prose is gathered onto the unit's tracker rather than dispositioned one at a time. These are the pre-existing findings the whole-unit pass raised on that unit while the change adding include regions to scripts/build_dist.py (#1317, mechanism pull request) was reviewed, read as the Copilot reviewer in a downstream repository reads it. None was introduced by the change and none blocked it. A new pre-existing finding on this unit gathers here, numbering continuing this list. This tracker closes when the unit is rewritten and each line below is settled or superseded.

1. "Follow the fidelity declared for the file." The declaration lives only in the hub's spec/files.json, which no carrier holds, and neither the unit nor the file says where or how a fidelity is declared, so a downstream reviewer cannot look one up and the instruction fails when followed literally.
2. "A byte-locked reference to shared infrastructure that this repository does not carry is intentional, not a broken link." "Byte-locked" is not a declared fidelity level, the declared vocabulary being verbatim, interface, intent, and presence, so a reader told to follow the declared fidelity cannot map this term onto any declaration.
3. "Raise substantive defects in canonical content, but locate the fix at its canonical source instead of proposing a local edit." "Canonical" appears nowhere else in the file and the unit never says what makes content canonical or where its source is.
4. "generated by the hub's scripts/build_dist.py from its .agents/skills/" uses "the hub" as a defined term the file never defines, its only other matches being inside "GitHub", so the hub-side paths are unverifiable from the unit for a reader carrying only .github/skills/.

[ptr727]

One more from the second whole-unit read on the same change, numbering continuing the list above:

5. "When the pull request changes the file the fix belongs in, comment on that file instead" cannot always be followed: a pull request review comment attaches only to a line inside a diff hunk, so a pull request that changes the file elsewhere leaves the heading's lines unreachable, and the unit gives no fallback for that case.