core.hooksPath 是共用 checkout 的絕對路徑：從 worktree 推送時 pre-push 跑的是舊版 run-guards.sh

[kiki830621]

Problem

core.hooksPath 設成共用 checkout 的 .githooks 絕對路徑。從另一個 git worktree 推送時，git 在 worktree 的根目錄執行 hook，但 hook 檔本身取自共用 checkout——而共用 checkout 的 main 可以落後被推送的程式碼很多個 commit。

結果：pre-push 用舊版的 run-guards.sh 檢查新版的程式碼。

觸發過的實例（2026-09-29，#664 推送）

• 共用 checkout 的 main 落後 origin/main 26 個 commit；兩邊的 pre-push 相同，但 run-guards.sh 差 95 行
• worktree 的程式碼已含 [refactor] 既有的 Python／shell 領域邏輯移植成 Swift（swift-is-the-implementation-language 的既有檔清單） #629（plugin/tests/rule-coverage.sh 移植成 akashic-guards rule-coverage 後刪除）
• pre-push 的 swift build、全套 swift test 都通過，到守衛階段失敗：bash: plugin/tests/rule-coverage.sh: No such file or directory，推送被拒
• 以 git -c core.hooksPath=<worktree>/.githooks push 改跑被推送程式碼自己的 hook 才通過

Impact

兩個方向都會發生，第二個比較糟：

1. 假失敗（這次）：舊 hook 呼叫已被刪除或改名的東西，推送被擋，花一輪全套測試（約 12 分鐘）才看到
2. 假通過：被推送的程式碼新增了守衛（例如 Semantic Scholar API：Akashic 共用的金鑰與存取方式（往回、往前、相似作品、作者著作、書目查詢） #664 的 network-confinement），舊 hook 不知道它存在，就不會跑——gate 看起來綠，其實沒檢查新規則

Expected

pre-push 檢查的是被推送的那份程式碼自己的 hook 與守衛。

可能的方向（未決，僅供 diagnose 參考）

• core.hooksPath 改為相對路徑 .githooks（git 以各 worktree 的根目錄解析），或
• hook 內以 git rev-parse --show-toplevel 定位 run-guards.sh，而不是 $(dirname "$0")

另：#693 第 3 點處理的是同一個絕對路徑出現在公開文件裡的隱私面；本 issue 是它的功能面，兩者可以一起改，但判準不同。

Refs #664

---

Current Status

Phase: verified（R2：HIGH 0、MEDIUM 0；兩則 LOW 是 CLAUDE.md 的措辭，在 #703 的修正輪一起改）
Last updated: 2026-09-30 by idd-update

Blocking

• （無）待使用者 /idd-close

Commits

• f7cf1677（實作）
• 354e2a2e（R1 修正）；tag idd-697-verified

[kiki830621]

Verify R1（#697）

這一輪

六席：requirements、logic、security、regression、devil's advocate、Codex。本輪與 #698、#704、#706 同一次驗證，全輪 47 則：HIGH 0、MEDIUM 4、LOW 20、INFO 23。四則 MEDIUM 都屬 #697。devil's advocate 在真 git（絕對 core.hooksPath、linked worktree、本機 bare remote）上確認機制本身對：不會迴圈、cwd 是工作樹根目錄、exec 保住 argv／stdin／結束碼（第 46 則）。

修正 commit：354e2a2e（hook、測試、CLAUDE.md、README、changelog）。修正加了新的測試格與 hook 邏輯（unset CDPATH、/bin/bash），所以進 R2。

做了什麼

• 測試分得開 exec 與一般呼叫（MEDIUM 第 2、4 則）：舊測試的 stub 回 42，set -e 把結束碼傳出來，只拿掉 exec 一字時四個斷言全綠。實際的失敗在工作樹 hook 通過時：一般呼叫會讓共用那份在 stdin 已被讀走之後重跑整套 gate。測試改成七格，第 2 格就是這個情形（stub 回 0，斷言共用那份沒有呼叫 swift、沒有警告、stub 恰好跑一次）。另加參數轉交、.githooks/ 在而 pre-push 不在、真 hook 複本不迴圈、CDPATH 四格。
• 負控表照實改寫：R1 報告的第一列寫「拿掉 exec → 紅 3 項」，量的其實是換掉整行。重跑七個負控，每一次都先確認輸出有 Executed 1 test：只拿掉 exec 一字 → 第 2、6 格紅；其餘六個各自打中對應的格。其中一次（兩邊 pwd -P 都改 pwd）第一次跑是綠的——那一次緊接在停掉一個卡住的舊負控 runner 之後，最可能是舊 runner 的 EXIT trap 在中途把 hook 還原了，原因沒有查明；單獨重跑是紅。
• 在這台機器上生效（MEDIUM 第 1、3 則）：我在 R1 之後問了使用者，使用者裁決把 core.hooksPath 從共用 checkout 的絕對路徑改成相對路徑 .githooks，同日已改（git config，只影響這個 repo 的本機設定）。之後每個 worktree 推送都跑自己那一份；這次整合推送是第一次實際驗收，結果貼在推送之後的 comment。
• CDPATH（LOW 第 9、13、18 則）：比對前 unset CDPATH，第 7 格釘住。
• 直譯器（LOW 第 19 則、INFO 第 35 則）：改跑用 /bin/bash，與 shebang 相同。
• CLAUDE.md（LOW 第 7、10、17 則）：hooksPath 三值分析補一段 2026-09-30 補記，矩陣照舊保留。
• README（LOW 第 23 則）：寫明相對路徑的代價——工作樹沒有 .githooks/pre-push 時 git 什麼都不跑、也不出聲。

逐則處置

則	席	嚴重度	內容	處置
1、3、31、36	requirements、regression、logic、security	MEDIUM／INFO	在回報的設定下沒有效果：hook 檔取自共用 checkout	修：core.hooksPath 依使用者裁決改成相對路徑；推送後附驗收
2、4	logic、devil's advocate	MEDIUM	測試分不出 exec 與一般呼叫；負控表第一列描述錯	修（354e2a2e）：見上
5、20	Codex、regression	LOW	沒有驗證參數轉交；沒有真 hook 複本那一格	修：第 1、6 格
6	requirements	LOW	.githooks/ 在而 pre-push 不在的分支沒有測試	修：第 4 格
7、10、17	requirements、logic、regression	LOW	CLAUDE.md 的 hooksPath 分析沒跟著更新	修：補記段落
9、13、18	logic、security、regression	LOW	CDPATH 讓改跑靜默失效	修：unset CDPATH＋第 7 格
19、35	regression、security	LOW／INFO	exec bash 走 PATH，與 shebang 不同	修：/bin/bash
23	devil's advocate	LOW	相對路徑在工作樹沒有 hook 時靜默零執行	修：README 寫明
14	security	LOW	改跑前沒確認工作樹的 .githooks 與 hook 檔屬於同一個 repo（hook 若被設成 global core.hooksPath 才有意義）	不修：本 repo 的設定是 repo-local；記在這裡
34	security	INFO	信任錨點移到被推送的樹本身，.githooks/pre-push 可以自我核准	寫進 changelog〈誠實邊界〉：與相對路徑相同，pre-push 是品質閘不是安全邊界
27、42	requirements、regression	INFO	手動從子目錄執行時警告說錯	寫進 changelog〈誠實邊界〉，不影響結果
26、46	Codex、devil's advocate	INFO	沒有可確定的缺陷；機制在真 git 上驗過	不動

推送驗收（2026-09-30）

整合推送 2e9d5c67..315515ed 從 worktree 推出，沒有用 -c core.hooksPath 覆寫——git 以相對路徑解析到推送的那個工作樹自己的 .githooks/pre-push。守衛階段印出 negative control 75/75 與 49/49，這兩個格數只存在於這次推送的新 harness（共用 checkout 那一份兩者都沒有），所以跑的確實是被推送的程式碼自己的 hook 與 run-guards.sh。

[kiki830621]

Verify R2（#697）

這一輪

六席：requirements、logic、security、regression、devil's advocate、Codex，六席都有結果。本輪與 #703（R1）、#689／#690（R3）同一次驗證，全輪 42 則：HIGH 2、MEDIUM 8（都屬 #703 與 #689）、LOW 16、INFO 16。

屬 #697 的：HIGH 0、MEDIUM 0、LOW 2（第 14、25 則）、INFO 6（第 27、28、31、35、39、42 則）。

判定：verified（HIGH 0、MEDIUM 0）。tag idd-697-verified 打在 354e2a2e。

R1 的四則 MEDIUM 都已關閉：logic 與 devil's advocate 各自把七格測試改寫成 shell 在 scratch 重跑，逐一改動 hook——只拿掉 exec 紅第 2、6 格；換成 : 紅第 1、2、7 格；拿掉 "$@" 紅第 1 格；拿掉 -f 紅第 4 格；拿掉 unset CDPATH 紅第 7 格；兩邊 pwd -P 改 pwd 紅第 5 格（重跑五次都紅，changelog 記的「第一次是綠」沒能重現，與「舊 runner 的 EXIT trap 中途還原」的推測相容）。devil's advocate 另以真 git（相對 core.hooksPath、worktree、從子目錄推）驗證只跑一次 gate、各在自己的工作樹（第 31、42 則）。

逐則處置

則	席	嚴重度	內容	處置
14、25	requirements、regression	LOW	CLAUDE.md 仍有幾處把「指向主 repo」寫成現況（「現況是第 2 列」）	在 #703 的 R1 修正輪一併改（同一個 worktree），不另開
28、39、42	requirements、regression、devil's advocate	INFO	相對路徑的代價（工作樹沒有 hook 時什麼都不跑）影響所有既有 worktree；測試都以絕對 $0 呼叫 hook，實際生效的是相對 $0（手動驗過）	代價已寫進 README 並經使用者裁決；相對 $0 沒有測試格，記在這裡
35	security	INFO	信任錨點移到被推送的樹	changelog〈誠實邊界〉已寫
27、31	Codex、logic	INFO	沒有缺陷	不動