Found while resyncing a downstream repo against hub 79f4f17, and re-verified against 20616e0.
The defect
GOVERNANCE.md "Hub-Hosted Tooling" states the rule:
Name the tool by its path in that checkout and name the target explicitly, since a tool that defaults to the current directory or the current repository resolves somewhere either way, and a result computed against the wrong repository is well-formed.
The carried repo-config/README.md does neither, in the same carried instruction set. Every invocation in it names the script bare:
7: `configure.sh apply owner/repo release|operational`
7: `configure.sh check owner/repo release|operational`
7: `configure.sh check operational`
26: `configure.sh apply` (x2)
26: `configure.sh check`
Line 7's three name a target, line 26's do not. The two bare mentions at lines 5 and 7 that name the file rather than invoke it are fine as they are.
Why it matters more than style
The file it sits in is the one telling the reader the script is not carried here and must be run from a hub checkout. That is exactly the moment the reader has two candidate meanings for configure.sh, a path in the hub checkout and a path in the repo they are standing in, and the sentence resolves neither.
Line 26 is the sharper case, because it also omits the target. The same file's own bullet warns that the command "defaults to whichever repository the shell is sitting in", so a reader following line 26 literally applies fleet settings and rulesets to whatever repo their shell happens to be in. That is a write, and per the rule above the wrong-repository result is well-formed rather than an error.
The retirement of the carried copies makes this more reachable, not less: before, a bare configure.sh at least resolved to something in the repo the reader was standing in. Now it resolves to nothing there, so the only correct reading is the hub path the text does not give.
Suggested fix
Give every invocation the path, and give line 26's the target too:
repo-config/configure.sh apply owner/repo release|operationalrepo-config/configure.sh check owner/repo release|operational
Leave the bare mentions that name the file rather than invoke it, and leave the deliberate hazard example at line 7 (configure.sh check operational) reading as a hazard, though it takes the path like the rest.
Downstream state
The repo this was found in carries a local correction, because repo-config/README.md is intent fidelity and so is judged by meaning rather than byte-matched. That divergence is deliberate and has to be maintained by hand until this is fixed here, at which point the local correction is dropped and the file re-vendors clean.
Reported by an agent during a downstream resync. Hub read at 20616e0.
Found while resyncing a downstream repo against hub
79f4f17, and re-verified against20616e0.The defect
GOVERNANCE.md"Hub-Hosted Tooling" states the rule:The carried
repo-config/README.mddoes neither, in the same carried instruction set. Every invocation in it names the script bare:Line 7's three name a target, line 26's do not. The two bare mentions at lines 5 and 7 that name the file rather than invoke it are fine as they are.
Why it matters more than style
The file it sits in is the one telling the reader the script is not carried here and must be run from a hub checkout. That is exactly the moment the reader has two candidate meanings for
configure.sh, a path in the hub checkout and a path in the repo they are standing in, and the sentence resolves neither.Line 26 is the sharper case, because it also omits the target. The same file's own bullet warns that the command "defaults to whichever repository the shell is sitting in", so a reader following line 26 literally applies fleet settings and rulesets to whatever repo their shell happens to be in. That is a write, and per the rule above the wrong-repository result is well-formed rather than an error.
The retirement of the carried copies makes this more reachable, not less: before, a bare
configure.shat least resolved to something in the repo the reader was standing in. Now it resolves to nothing there, so the only correct reading is the hub path the text does not give.Suggested fix
Give every invocation the path, and give line 26's the target too:
repo-config/configure.sh apply owner/repo release|operationalrepo-config/configure.sh check owner/repo release|operationalLeave the bare mentions that name the file rather than invoke it, and leave the deliberate hazard example at line 7 (
configure.sh check operational) reading as a hazard, though it takes the path like the rest.Downstream state
The repo this was found in carries a local correction, because
repo-config/README.mdisintentfidelity and so is judged by meaning rather than byte-matched. That divergence is deliberate and has to be maintained by hand until this is fixed here, at which point the local correction is dropped and the file re-vendors clean.Reported by an agent during a downstream resync. Hub read at
20616e0.