inkstone/ISEP - ISEP - Gitea: Git with a cup of tea

inkstone/ISEP

Fork 0

Commit Graph

Author	SHA1	Message	Date
Leo	f1b2ed909f	測試沙盒傳錯參數時，會把整個 tech_projects 複製進暫存區（inkstone/ISEP#122）本輪跑迴歸測試時實撞兩次，兩次都把這台機器的磁碟寫滿： $ bash hooks/tests/main-and-prod-push-guard.test.sh "$PWD" REAL="$1" 要的是「那支 hook 的檔案路徑」，我傳了 repo 根目錄 ⇒ hook_sandbox 不驗參數，直接 cp -R "$(dirname "$1")" ⇒ dirname 變成 ~/Documents/tech_projects（上一層） ⇒ 整個 tech_projects（所有 repo、所有 worktree）被搬進 mktemp 實測：第一次 13 GB ＋ 10 GB，第二次 23 GB。磁碟可用 25 GB → 462 MB，cp 一路吐 "No space left on device"。兩次都是我手動 rm -rf 才回來的（27 GB）。 🔴 而它印出來的只有一句「❌ 沙盒建不起來」—— 沒說是參數傳錯，也沒說它已經把磁碟寫滿了。 ⇒ 這跟本票在講的是同一句話：閘/工具給的下一步，沒有人照著打過一次，差別只在這次壞的不是逃生門，是「它壞掉時說的話」。改法（判準是「要求某個東西在場」，不是關鍵字比對）： ① $1 要指到一個真的檔案（空字串、目錄、不存在的路徑都不算） ② 它的上一層目錄名要叫 hooks（沙盒的前提就是複製一整個 hooks/）任一不成立 ⇒ 在 mktemp 之前 return 1，並印出走得通的那一行。順手補上 docs/TESTING.md 之前沒寫過的一件事：有五支測試要傳參數，而不傳的後果不是報錯是假綠——prod-write-guard.test.sh 的 HOOK="$1" 空掉時每一條都執行空指令回 0 ⇒「該擋」全變成「實得 pass」，19 條假紅（傳對參數：通過 37 ／失敗 0）。測試：hooks/tests/hook-sandbox.test.sh 10 條（A30），通過 10 失敗 0 ①③⑤⑥ 驗的是「收手在複製之前」，不是「訊息好不好看」 ⑧⑨⑩ 驗正常用法沒被弄壞、複本裡沒混進 hooks/ 以外的東西既有兩支沙盒測試複驗： scripts/test-main-and-prod-push-guard.sh 13/13 hooks/tests/main-and-prod-push-guard.test.sh 通過 10 ／失敗 0 hooks/tests/main-and-prod-push-guard-cross-repo.test.sh 通過 19 ／失敗 0 📌 這顆跟 0.22.0 的三件事無關，是本輪路上撞到的。要拆票或丟掉這顆都行，它獨立於前面兩顆，而且只動 hooks/tests/（沒有任何 hook 的執行行為改變）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-02 11:54:50 +08:00
Leo	950c3e1919	測試不再偽造「有一筆推 main 在等總管裁」（inkstone/ISEP#59）現象（實測，不是推論）：跑完 main-and-prod-push-guard 那三支測試之後 $ git status --short M hooks/lib/__pycache__/strip_heredoc.cpython-314.pyc M pending-main-push/unnamed--ISEP.md ?? pending-main-push/unnamed--A.md 成因：這支閘擋下推 main 的同時，會把那次請求寫成 `<hooks 的上一層>/pending-main-push/<誰>--<repo>.md`，而三支測試的測資本來就全是推 main。於是每跑一次測試，工作區就多／改幾筆偽造的待裁決。兩個後果，後者比較貴： ① `git add -A` 很容易把它們帶進 commit（08-27 那次真的帶進去了，事後才拔掉） ② 總管的迴圈讀那個目錄，讀到的每一筆都該是真的在等他裁—— 測試每跑一次就偽造一筆 ⇒ 下一筆真的請求會混在雜訊裡。這跟「永遠在響的警報」是同一個病。改法（產品程式碼一行都沒動）： - 新增 hooks/tests/lib/hook-sandbox.sh：把整個 hooks/ 複製到暫存區再跑複本。閘算 pending 目錄的位置靠的是 `$0` 的上一層 ⇒ 請求寫進暫存區。刻意不在閘上開一個「寫去哪」的環境變數——那種開關同時是一條把紀錄關掉的路。 - 三支測試改測沙盒複本，並各補兩條斷言： ① repo 的 pending-main-push 一個位元都沒動 ② 沙盒裡真的有留下請求（只驗 ① 的話，把留紀錄的功能整個關掉也會綠） - pending-main-push/ 不再進版控（它是本機狀態不是原始碼），只留一份 README 說明規約；既有的兩筆與那顆被追蹤的 .pyc 一併 `git rm --cached`，檔案留在硬碟上不刪。實測： - 三支各自 10/10、19/19、13/13（原本 8／17／11，各多兩條新斷言） - 把 `H` 改回真跡重跑 ⇒ 新斷言兩條都紅（11/13）＋工作區又髒 ⇒ 這兩條斷言真的抓得到它要抓的東西 - 全套 16 支測試檔跑完 0 失敗，`git status` 沒有多出任何一行 - `claude plugin validate .` ✔ Validation passed 沒有升版：這次只動測試與版控範圍，沒有任何閘的行為改變，不需要靠新版本號送到任何人手上；請跟著總管下一個 release 一起出去。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 18:33:44 +08:00

Author

SHA1

Message

Date

Leo

f1b2ed909f

測試沙盒傳錯參數時，會把整個 tech_projects 複製進暫存區（inkstone/ISEP#122）

本輪跑迴歸測試時實撞兩次，兩次都把這台機器的磁碟寫滿：

  $ bash hooks/tests/main-and-prod-push-guard.test.sh "$PWD"
      REAL="$1" 要的是「那支 hook 的檔案路徑」，我傳了 repo 根目錄
    ⇒ hook_sandbox 不驗參數，直接 cp -R "$(dirname "$1")"
    ⇒ dirname 變成 ~/Documents/tech_projects（上一層）
    ⇒ 整個 tech_projects（所有 repo、所有 worktree）被搬進 mktemp

  實測：第一次 13 GB ＋ 10 GB，第二次 23 GB。
        磁碟可用 25 GB → 462 MB，cp 一路吐 "No space left on device"。
        兩次都是我手動 rm -rf 才回來的（27 GB）。

🔴 而它印出來的只有一句「❌ 沙盒建不起來」——
   沒說是參數傳錯，也沒說它已經把磁碟寫滿了。
   ⇒ 這跟本票在講的是同一句話：**閘/工具給的下一步，沒有人照著打過一次**，
     差別只在這次壞的不是逃生門，是「它壞掉時說的話」。

改法（判準是「要求某個東西在場」，不是關鍵字比對）：
  ① $1 要指到一個真的檔案（空字串、目錄、不存在的路徑都不算）
  ② 它的上一層目錄名要叫 hooks（沙盒的前提就是複製一整個 hooks/）
  任一不成立 ⇒ 在 mktemp 之前 return 1，並印出走得通的那一行。

順手補上 docs/TESTING.md 之前沒寫過的一件事：**有五支測試要傳參數**，
而不傳的後果不是報錯是假綠——prod-write-guard.test.sh 的 HOOK="$1" 空掉時
每一條都執行空指令回 0 ⇒「該擋」全變成「實得 pass」，19 條假紅
（傳對參數：通過 37 ／ 失敗 0）。

測試：hooks/tests/hook-sandbox.test.sh 10 條（A30），通過 10 失敗 0
      ①③⑤⑥ 驗的是「收手在複製之前」，不是「訊息好不好看」
      ⑧⑨⑩ 驗正常用法沒被弄壞、複本裡沒混進 hooks/ 以外的東西
既有兩支沙盒測試複驗：
      scripts/test-main-and-prod-push-guard.sh                    13/13
      hooks/tests/main-and-prod-push-guard.test.sh          通過 10 ／ 失敗 0
      hooks/tests/main-and-prod-push-guard-cross-repo.test.sh 通過 19 ／ 失敗 0

📌 這顆跟 0.22.0 的三件事無關，是本輪路上撞到的。要拆票或丟掉這顆都行，
   它獨立於前面兩顆，而且只動 hooks/tests/（沒有任何 hook 的執行行為改變）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-02 11:54:50 +08:00

Leo

950c3e1919

測試不再偽造「有一筆推 main 在等總管裁」（inkstone/ISEP#59）

現象（實測，不是推論）：跑完 main-and-prod-push-guard 那三支測試之後

    $ git status --short
     M hooks/lib/__pycache__/strip_heredoc.cpython-314.pyc
     M pending-main-push/unnamed--ISEP.md
    ?? pending-main-push/unnamed--A.md

成因：這支閘擋下推 main 的同時，會把那次請求寫成
`<hooks 的上一層>/pending-main-push/<誰>--<repo>.md`，而三支測試的測資本來
就全是推 main。於是每跑一次測試，工作區就多／改幾筆**偽造的待裁決**。

兩個後果，後者比較貴：
  ① `git add -A` 很容易把它們帶進 commit（08-27 那次真的帶進去了，事後才拔掉）
  ② 總管的迴圈讀那個目錄，讀到的每一筆都該是真的在等他裁——
     測試每跑一次就偽造一筆 ⇒ **下一筆真的請求會混在雜訊裡**。
     這跟「永遠在響的警報」是同一個病。

改法（產品程式碼一行都沒動）：
- 新增 hooks/tests/lib/hook-sandbox.sh：把整個 hooks/ 複製到暫存區再跑複本。
  閘算 pending 目錄的位置靠的是 `$0` 的上一層 ⇒ 請求寫進暫存區。
  **刻意不在閘上開一個「寫去哪」的環境變數**——那種開關同時是一條把紀錄關掉的路。
- 三支測試改測沙盒複本，並各補兩條斷言：
  ① repo 的 pending-main-push 一個位元都沒動
  ② 沙盒裡**真的有**留下請求（只驗 ① 的話，把留紀錄的功能整個關掉也會綠）
- pending-main-push/ 不再進版控（它是本機狀態不是原始碼），只留一份 README 說明規約；
  既有的兩筆與那顆被追蹤的 .pyc 一併 `git rm --cached`，檔案留在硬碟上不刪。

實測：
- 三支各自 10/10、19/19、13/13（原本 8／17／11，各多兩條新斷言）
- 把 `H` 改回真跡重跑 ⇒ 新斷言兩條都紅（11/13）＋工作區又髒
  ⇒ 這兩條斷言真的抓得到它要抓的東西
- 全套 16 支測試檔跑完 0 失敗，`git status` 沒有多出任何一行
- `claude plugin validate .` ✔ Validation passed

沒有升版：這次只動測試與版控範圍，沒有任何閘的行為改變，
不需要靠新版本號送到任何人手上；請跟著總管下一個 release 一起出去。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-27 18:33:44 +08:00

2 Commits