兩支閘改看「指令要動的那個 repo」，不看 hook 自己的環境／cwd（inkstone/ISEP#109 → comment 6629）

① line-needs-own-worktree.sh：出路 `WORKTREE_OK=1 git -C … checkout …` 改認指令字串裡的字面前綴
   （舊版讀 hook 自己的環境變數，PreToolUse hook 跟指令不是同一個行程，那行永遠走不通）。
   判準是位置不是字：前綴必須掛在會移動 HEAD 的那條 git 指令上。
   lib/checkout_target_dir.py 加 `--escape NAME=1`；push_target_dir._classify 在 strip_env 時
   把前綴留在 verb 事件裡（find_push_target 行為不變，主線閘 10＋19 條照綠）。
② github-contact-guard.sh：remote 名在「這條指令實際會推的那個 repo」裡解（沿用 lib/push_target_dir.py
   解 cd 鏈／-C／子殼），解不出來才退回 cwd。判準仍是 remote URL 主機，不是「有 -C 就放行」。

測試：A24 59→69（E 群把閘印的那一行原樣餵回去；舊閘 3 條紅）、
      A39 14→26（payload 帶 cwd、cwd≠目標 repo；舊閘 7 條紅＝4 誤攔＋3 漏擋）。
盤點表：61 支／85 條，改判準不加閘，當場數的。
版本：待總管定版。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178ef1fGw3XeZtpN7LaZrm4

system-dev/wiki/mistakes.md

@@ -373,3 +373,41 @@ leo 當場：「**這些為什麼不寫到票裡？**」
 正確做法: 匿名優先、匿名被拒（401／403／404）且環境拿得到 token 才帶 token 再問一次（`fetch_gitea()`）；
       假伺服器要有 private 模式（匿名 404、帶 token 200）照真 Gitea 回；真跑兩條都跑（帶 token 讀到、拔 token 退回）。
       收到「X 讀得到／X 不存在」這種宣稱先打一次再動手——那是一個 curl 的成本。
+
+## ⚠️ MISTAKE: 閘看的是 hook 自己的環境／cwd，不是指令要動的那個 repo
+
+票: `inkstone/ISEP#109`（comment 6587／6629）
+日期: 2026-09-07
+
+症狀: 同一天兩支閘同一個病。① `line-needs-own-worktree.sh` 印的出路
+      `WORKTREE_OK=1 git -C … checkout …` 照貼三次三次被擋。
+      ② `github-contact-guard.sh` 把 `git -C <InkStoneCo> push origin x` 判成「remote origin 指向 GitHub」擋下
+      （總管站在薄殼 cwd；InkStoneCo 的 origin 明明是 Gitea），連 `-C` 都沒看；
+      同日 arcrun-hand 在 `Arcrun#176` comment 6614 撞到同一支。當天只能改用完整 Gitea 網址推，
+      而那種形狀分類器又時過時不過。
+
+實查: ① hook 讀的是 `$WORKTREE_OK` 這個**環境變數**。PreToolUse hook 跟指令不是同一個行程，
+         指令字串裡的 `WORKTREE_OK=1` 是給 git 的前綴賦值，hook 的行程裡永遠沒有它
+         ⇒ 那條出路在 Claude Code 底下**結構上**走不通，不是偶爾。（`NOT_MY_BRANCH_OK` 同形狀，見下）
+      ② hook 拿 **payload 的 cwd** 去 `git remote get-url origin`，而 `-C`／`cd … &&` 改的是
+         指令自己的目錄。`main-and-prod-push-guard.sh` 08-23 就為同一個病接了
+         `lib/push_target_dir.py`（`inkstone/ISEP#30` comment 3949）——**同一族的另一支沒跟上**，
+         跟 `leo21c-write-guard.sh` 那條坑一模一樣（修一份不會帶動另外兩份）。
+      修之前拿新測試跑舊閘：① 3 條紅；② **7 條紅——4 條誤攔之外還有 3 條漏擋**
+      （站在 Gitea 那份 `git -C <薄殼> push origin x` 舊版放行）。cwd 不只讓它誤擋，也讓 D20 有洞。
+
+原因: 兩支都在回答「這條指令會動到哪個 repo」，卻拿「hook 自己站在哪」當答案。
+      本機一份目錄時兩者恰好相等，所以測試全綠；雲端薄殼＋真身兩份目錄一分開就露餡。
+      而「出路走不走得通」那一格從來沒被測過——測的只有「擋不擋」。
+
+正確做法:
+  - 出路要是 hook **讀得到**的形狀：認指令字串裡的字面前綴（判準是位置——前綴必須掛在會移動 HEAD
+    的那條 git 指令上；印個字、掛在別的指令上、寫在引號裡都不算），或 `gate-ok` 同款的戳記檔。
+  - 「這條指令在哪個 repo 執行」一律走 `hooks/lib/push_target_dir.py`／`checkout_target_dir.py`
+    解 cd 鏈與 `-C`，解不出來才退回 cwd（退回的方向是照舊，不是放寬）。改判準時 `grep -l` 找同一族
+    （`main-and-prod-push-guard`／`github-contact-guard`／`line-needs-own-worktree`／`not-my-branch-guard`）一次看齊。
+  - 測試要有一條「把閘印出來的那一行原樣餵回去」（A24 (61)–(63)），還要有 payload 帶 `cwd`、
+    cwd 與目標 repo **不同**的案例（A39 後 12 條）——本機一份目錄的測試驗不出這個病。
+
+📌 沒在本票修的同形狀：`not-my-branch-guard.sh` 的 `NOT_MY_BRANCH_OK=1 git commit …` 同樣只讀環境變數
+   （第 28 行），沒實測、沒動——它認的動作是 commit，不是 push_target_dir 那條線的事，另報。