A branch-scoped repository write guard must recognize Git’s transient detached-HEAD states…

A branch-scoped repository write guard must recognize Git’s transient detached-HEAD states during rebase and map them back to the recorded branch; otherwise it can deadlock recovery by blocking both conflict-resolution commands and rebase abort. This applies when the rebase metadata names an already-authorized branch and the issue/PR linkage is still valid; it must not treat arbitrary detached HEADs as authorized.

Evidence/example — 2026-09-11

While resolving a migration-number conflict on an issue-linked PR, Linear Progress Sync 0.3.14 accepted the active branch before rebase, then rejected every Git write after rebase detached HEAD. Its prescribed kickoff also rejected the necessarily unclean conflict state, and even rebase abort was blocked. GitHub’s update-branch API could not resolve the semantic generated-artifact conflict. Source: local plugin guard behavior, active-state readback, and Git/GitHub command results. A robust guard should inspect rebase-merge/head-name (or equivalent Git plumbing), require it to equal the active branch, and allow bounded recovery/resolution commands while preserving all other linkage checks.