A repository is asked to reconcile or audit itself against the hub. Nothing it can read says what that word means.
$ git show origin/develop:AGENTS.md | grep -c 'the hub'
5
$ git grep -c 'the hub' origin/develop -- '*.md' | awk -F: '{s+=$3} END {print s}'
50The word carries the whole instruction and is defined in none of the 50 places it appears. AGENTS.md "Fleet Bootstrap" comes closest, naming github.com/ptr727/ProjectTemplate as where the canonical rules live and using "the hub" in the next clause as though the reader has already made the connection. A repository that carries that section can just about infer it. A repository that does not carry it has nothing at all.
The gap is the repositories the router cannot reach
AGENTS.md "Fleet Bootstrap" already routes correctly by repository state, sending a repository with no instruction set to STANDUP.md, a partial one to the baseline, and a current one to AUDIT.md. The routing is right. The problem is that the router is byte-locked inside the file a bare repository does not have, so the case it handles first is the case that cannot read it.
The practical cost is that onboarding a repository with no history means explaining by hand, every time, what ProjectTemplate is, where it lives, which file to open, and what "the hub" refers to.
The same gap, inverted, for the review loop
GOVERNANCE.md "Expected Review Loop" states the procedure precisely: request a review on every push, verify head-SHA coverage, triage, reply and resolve, escalate when stuck. It never presents its name as the way to ask for it.
So the loop has a rigorous definition and no invocation. Every request for it is improvised, and the scope an agent reads out of the phrasing moves with the phrasing, which is why "run the review" and "close out Copilot" and "do the review dance" produce three different amounts of work. A defined term is what makes close the review loop on #123 a complete instruction rather than a starting point for interpretation.
Two things to settle
Where the definitions live. The natural home is the byte-locked Fleet Bootstrap section, and a repository with no carried instruction set is precisely the one that lacks it, which leaves this repository's own README.md as the only surface a stranger to the fleet reads first. That argues for the definitions living where an unprimed reader lands rather than where the rules live.
Whether the entry point is named per task. The bootstrap section routes by repository state, which is the right axis for onboarding and the wrong one for "audit yourself against the hub", where the reader already knows their state and wants the file.
Sequencing
An edit to the byte-locked section lands with #552, which already holds that section open on a conflict between the template-reference check and the byte-locked text, rather than as a separate change against the same bytes.
Filed from the onboarding-feedback pass in #576, where it is recorded as a TODO.md entry.
A repository is asked to reconcile or audit itself against the hub. Nothing it can read says what that word means.
The word carries the whole instruction and is defined in none of the 50 places it appears.
AGENTS.md"Fleet Bootstrap" comes closest, naminggithub.com/ptr727/ProjectTemplateas where the canonical rules live and using "the hub" in the next clause as though the reader has already made the connection. A repository that carries that section can just about infer it. A repository that does not carry it has nothing at all.The gap is the repositories the router cannot reach
AGENTS.md"Fleet Bootstrap" already routes correctly by repository state, sending a repository with no instruction set toSTANDUP.md, a partial one to the baseline, and a current one toAUDIT.md. The routing is right. The problem is that the router is byte-locked inside the file a bare repository does not have, so the case it handles first is the case that cannot read it.The practical cost is that onboarding a repository with no history means explaining by hand, every time, what ProjectTemplate is, where it lives, which file to open, and what "the hub" refers to.
The same gap, inverted, for the review loop
GOVERNANCE.md"Expected Review Loop" states the procedure precisely: request a review on every push, verify head-SHA coverage, triage, reply and resolve, escalate when stuck. It never presents its name as the way to ask for it.So the loop has a rigorous definition and no invocation. Every request for it is improvised, and the scope an agent reads out of the phrasing moves with the phrasing, which is why "run the review" and "close out Copilot" and "do the review dance" produce three different amounts of work. A defined term is what makes
close the review loop on #123a complete instruction rather than a starting point for interpretation.Two things to settle
Where the definitions live. The natural home is the byte-locked Fleet Bootstrap section, and a repository with no carried instruction set is precisely the one that lacks it, which leaves this repository's own
README.mdas the only surface a stranger to the fleet reads first. That argues for the definitions living where an unprimed reader lands rather than where the rules live.Whether the entry point is named per task. The bootstrap section routes by repository state, which is the right axis for onboarding and the wrong one for "audit yourself against the hub", where the reader already knows their state and wants the file.
Sequencing
An edit to the byte-locked section lands with #552, which already holds that section open on a conflict between the template-reference check and the byte-locked text, rather than as a separate change against the same bytes.
Filed from the onboarding-feedback pass in #576, where it is recorded as a
TODO.mdentry.