A repository write guard must resolve active-task state and current branch from the actual…

A repository write guard must resolve active-task state and current branch from the actual target worktree, not the primary checkout associated with the parent session. In multi-worktree environments, anchoring both checks to the primary checkout can reject valid writes even when the target worktree has a correct issue/branch/PR binding. A safe guard should canonicalize the command’s effective working directory to its worktree root and load that worktree’s active state; it should still fail closed when the target itself is unbound or mismatched.

Evidence/example — 2026-09-09: A Shield PR conflict-resolution command targeted a linked COR-4098 worktree whose local active.json correctly named COR-4098 and its PR branch. The PreToolUse guard instead evaluated the primary checkout, which was on main with stale COR-4117 active state, and blocked git merge. The prescribed kickoff dry run would have tried to switch the primary checkout to a branch already checked out in the linked worktree and create a duplicate kickoff commit/PR, so it was not safe to execute. Source provenance: local linear-progress-sync 0.3.14 guard code, active-state readbacks, git branch/worktree metadata, and the hook rejection.