fix: mend the guard, the suite, and the validator #208
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/review-defects"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
A review of the source on 2026-11-10 reproduced three defects on
main.An agent that edits a file in a submodule, in the worktree of its own
change, was refused by the main-checkout guard and told to open a
worktree it was already in, so a project with submodules could change
them only around the file-editing tools. A maintainer whose Git
configuration signs commits had every fixture commit of
bash tests/verify-agent-config.shsigned with their key, and in anagent session, where Claude Code's sandbox blocks the signing agent, saw
22 of the suite's areas stop. And a repository whose
.agents/scripts/run-sandboxed.shwas missing or had lost itsexecutable mode passed the validator, though the
run-sandboxedskillcalls the script directly.
Set aside: refusing a submodule's files everywhere with a reason of
their own, which keeps them out of the editing tools; turning off
signing in each fixture, which leaves the machine's other settings in
play; and checking the script in every repository, which would fail one
that dropped the skill.
What changed
The guard judges a submodule's file by the worktree of its outermost
superproject: the edit passes in a linked worktree and in a main
checkout off its main branch, and is refused in a main checkout on its
main branch or nested in another repository, where the refusal now names
the file by its path in the superproject. A member clone in an umbrella
is judged as before.
The suite runs Git without the machine's global and system
configuration, so its result no longer depends on who runs it.
The validator checks
run-sandboxed.shas it checks the hooks, tracked,present, and executable with Git mode 100755, in the source and in a
repository that keeps the
run-sandboxedskill.How to verify
The guard, from an empty directory, with
<checkout>this branch'scheckout:
The worktree's edit prints
exit 0, and the main checkout's is refusedwith "vendor/lib/f.c is in the main checkout … on its main branch main"
and
exit 2;mainrefuses both.The suite: with a file holding
[commit] gpgsign = trueand[gpg] program = false,GIT_CONFIG_GLOBAL=<file> bash tests/verify-agent-config.shends withits line "all … agent configuration tests passed"; on
mainits areasstop with "gpg failed to sign the data".
The validator:
git update-index --chmod=-x .agents/scripts/run-sandboxed.sh, thenscripts/verify-agent-config.shprints "run-sandboxed.sh must betracked, present, and executable, with Git mode 100755" and exits 1,
where
mainreports the source valid;--chmod=+xrestores it.The six checks of
docs/MAINTENANCE.mdpass on the tip, the suite withno test skipped; the six new submodule tests and the three new validator
tests fail on
main, and the two pins pass there. Not tried: Codex andOpenCode at run time.
Considerations
A file in a submodule beneath a submodule whose path ends in a newline
is refused everywhere, since the guard cannot resolve its superproject.
A reviewer's finding that the pin of the refusal in a main checkout and
the test of the refusal's new text send the same event is set aside: the
pin passes on
mainand on the tip, and the second test fails onmain.