#211 fixed a materialization guard that still required the pre-#205 sdk path, so both drive flows aborted at step one on a correctly materialized repo. That was the tenth instance of one bug class: a path literal that survives a move because it does not look like a path.
The maintainability lens raised this during that review and it was deliberately left out of scope:
Nothing in this fix prevents the same miss recurring the next time a required path moves.
Why the class keeps escaping
#205 updated fourteen packages/ references in drive.yaml and missed one. The missed one was not hiding — it was in the most-read line of the file. It escaped because it is a bare word in a shell for-loop list:
for required in AGENTS.md docs/RFC-0001-... ops/DIRECTIVES.md kernel sdk; do
A search for sdk/ does not match it. A search for \bsdk\b matches dozens of false positives (sdk-dev, the sdk suite, prose). That asymmetry is the whole problem, and it is why nine were found by three different mechanisms in #205 and the tenth still got through to main.
The same shape appears in the review comment for that PR: cd sdk and working-directory: surface were among the nine, for the same reason.
Two options
A — single source of truth. Extract the required-paths list to a checked-in file both flows read. One place to update, and drive-cloud.yaml stops carrying a hand-escaped copy of the same script. Larger change; fixes the duplication too.
B — a CI assertion. Fail if workflows/ contains a path literal naming a top-level directory that does not exist in the tree. Cheap, and it catches the class rather than this instance — including the next move, which will not be sdk.
B is the smaller change and the one that would actually have caught #211 before merge. A is the better end state and subsumes it.
Note on who should do this
I am not implementing it. RFC-0001's settled decision #6 says an agent can never widen its own permissions or edit the gates that judge its work, and both options are exactly that: a check that would gate my own PRs. Filing it for a human or an agent operating under a different mandate.
Evidence: #211, and the nine earlier instances in #205.
#211 fixed a materialization guard that still required the pre-#205
sdkpath, so both drive flows aborted at step one on a correctly materialized repo. That was the tenth instance of one bug class: a path literal that survives a move because it does not look like a path.The maintainability lens raised this during that review and it was deliberately left out of scope:
Why the class keeps escaping
#205 updated fourteen
packages/references indrive.yamland missed one. The missed one was not hiding — it was in the most-read line of the file. It escaped because it is a bare word in a shell for-loop list:A search for
sdk/does not match it. A search for\bsdk\bmatches dozens of false positives (sdk-dev,the sdk suite, prose). That asymmetry is the whole problem, and it is why nine were found by three different mechanisms in #205 and the tenth still got through to main.The same shape appears in the review comment for that PR:
cd sdkandworking-directory: surfacewere among the nine, for the same reason.Two options
A — single source of truth. Extract the required-paths list to a checked-in file both flows read. One place to update, and
drive-cloud.yamlstops carrying a hand-escaped copy of the same script. Larger change; fixes the duplication too.B — a CI assertion. Fail if
workflows/contains a path literal naming a top-level directory that does not exist in the tree. Cheap, and it catches the class rather than this instance — including the next move, which will not besdk.B is the smaller change and the one that would actually have caught #211 before merge. A is the better end state and subsumes it.
Note on who should do this
I am not implementing it. RFC-0001's settled decision #6 says an agent can never widen its own permissions or edit the gates that judge its work, and both options are exactly that: a check that would gate my own PRs. Filing it for a human or an agent operating under a different mandate.
Evidence: #211, and the nine earlier instances in #205.