fix(hooks): resolve pre-push workspace root from the main clone, not the worktree

[ProtocolWarden]

The bug

.hooks/pre-push derived the workspace root from git rev-parse --show-toplevel:

repo_root="$(git rev-parse --show-toplevel)"
workspace_root="$(cd "$repo_root/.." && pwd)"

--show-toplevel returns the worktree root. In a git worktree checkout that is <clone>/.claude/worktrees/<name>, so $repo_root/.. was the worktrees directory — not the workspace holding the sibling repos.

Two things broke as a result, both only from a worktree:

1. Boundary-artifact discovery globbed a directory containing nothing but other worktrees, so every worktree push failed closed on missing REPOGRAPH_BOUNDARY_ARTIFACT_FILE; failing closed — before the audit ever ran.
2. custodian-multi resolution missed every fallback: a worktree has no .venv of its own, and $workspace_root/Custodian/.venv/ pointed inside .claude/worktrees/. With no PATH entry the hook died on custodian-multi not found. That's the exact state of the WSL fleet box, where <clone>/.venv/bin/custodian-multi is the only custodian present.

The fix

--git-common-dir always resolves to the original clone's .git:

main_repo_root="$(cd "$(dirname "$(git rev-parse --git-common-dir)")" && pwd)"
workspace_root="$(cd "$main_repo_root/.." && pwd)"

dirname + cd normalizes all three forms git emits — .git at a clone's top level, ../.git from a subdirectory, absolute from a worktree — because cd interprets a relative path against cwd, which is exactly what git means by it. This avoids --path-format=absolute (git 2.31+), so the hook keeps working on older git rather than introducing a needless version floor.

Also added $main_repo_root/{.venv,.warehouse-venv}/bin/custodian-multi to the binary candidates. For a plain checkout main_repo_root == repo_root, so they're harmless duplicates of the existing entries.

The audit target stays "$repo_root" — we audit the content being pushed, which is the worktree.

What I deliberately left alone

The command -v custodian-multi PATH-first ordering. I checked whether reordering would help: it changes nothing in either environment today. Windows has no repo venv, so PATH is the only candidate; WSL has no PATH entry, so the venv candidate already wins.

Verification

Resolution probed from all three repo shapes:

invoked from	main_repo_root	artifact
worktree	…/GitHub/OperationsCenter	found
plain clone, top level (how git invokes hooks)	…/GitHub/OperationsCenter	found
plain clone, subdirectory	…/GitHub/OperationsCenter	found

workspace_root for a plain clone is byte-identical to before, so non-worktree pushes are unaffected.

End-to-end run of the real hook from a worktree with REPOGRAPH_BOUNDARY_ARTIFACT_FILE unset now prints boundary artifact: …/PrivateManifest/dist/boundary_disclosure_artifact.json and proceeds to the audit, instead of failing closed at discovery.

bash -n clean. (shellcheck isn't installed in either environment, so it wasn't run.)

custodian-multi against this branch: 0 findings, clean.

No log.md entry

.hooks/ is in the pre-commit guard's TRIVIAL exemption, so a hook-only commit doesn't require one. Skipping it also avoids a guaranteed top-of-file conflict with #487, which is open concurrently — the same conflict problem the oc-watchdog/* exemption comment in .hooks/pre-commit describes. The root cause is documented inline at the point of use instead.

🤖 Generated with Claude Code