plugins/hooks
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
196 Commits 12 Branches 0 Tags
80665f06bd2799dd30f3f0ce3feca56e22c17cf7
Commit Graph
44 Commits
Author SHA1 Message Date
jiantw83andClaude Opus 5 80665f06bd fix(comment-scope): 色碼不再被當成議題編號 
寫一份含樣式表的網頁檔時，註解範圍守門連著兩次擋下來，說有議題編號，指
的其實是樣式表裡宣告墨色的那一行自訂屬性。

錯在兩層。一是註解行判定：SQL 的行首註解是兩個減號，樣式表的自訂屬性開
頭也是兩個減號，判定不管後面接什麼，整份樣式表的變數宣告就被當註解送去
比對。二是議題編號那條樣式咬的是井號接數字，色碼開頭剛好是數字，於是指
著色碼喊編號。

兩層各補一刀。行首兩個減號要求後面接空白：真的註解都留那個空白，自訂屬
性沒有，判定就分得開。白名單再多剪一條，把井號後面含十六進位字母的色碼
先剪掉；議題編號是純十進位，這一刀剪不到真的編號。剪而不是整行放行，維
持原本「同一行可能一半合規、一半違規」的處理方式。

驗過三種情形：含色碼宣告的樣式表不再命中；樣式表註解裡寫井號接兩位數字
照舊命中；SQL 註解裡夾議題編號照舊命中。語法檢查也過。

影響提交前那道註解範圍掃描。吃虧最深的是前端與資料庫這兩類檔案——之前它
們一碰色碼就得靠人判斷是不是誤報，現在守門擋下來的都值得看一眼。

三份 manifest 同步升到 0.5.2，跳過已在別處佔用的版號，避免撞號。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-08 15:01:49 +08:00
jiantw83andClaude Opus 5 1f9f329cd3 fix(session-reminder): 內建項收成一行，不逐筆吐 
實測踩到：這台機器的佇列八筆全是委派清單種入的內建項，於是每一個工作
階段開頭固定吐八行一模一樣的東西。那不是提醒，是噪音——而這一支自己的
註解裡就寫著「對著一個刻意的決定每個工作階段催一次，那是噪音不是提醒」。

逾期與使用者自己登錄的提醒照舊逐筆點名：人看到就做得了。內建項改成一行
總數，並在那一行講明它會一直出現，直到那幾筆接上入口或被改掉——講明它是
常態，讀的人才不會每次都當成新消息。

分種類的判定在寫佇列那一邊，那裡讀得到 spec_key；這裡只照它標好的種類
決定怎麼印，維持「只印不判」那條界線。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 13:39:57 +08:00
jiantw83andClaude Opus 5 cd4cd8b936 feat(hooks): 工作階段開始時把助理的未讀提醒帶到前景 
助理算得出哪幾筆到期、哪幾筆逾期，但那些結果只寫在監控頁上——人要自己
去翻，或自己跑一次狀態查詢。這一支把它帶到前景。

session-reminder.sh 只讀助理那一輪寫好的提醒佇列，一個判定都不做。
自己拿 due 欄與 next_run 去跟現在比就是第二套到期判定，跟助理那一套遲早
對不上，而對不上的那一天兩邊都說自己是對的。它也要快：這一支跑在每一個
工作階段的開頭。

只印佇列換來一個新的失效模式，正面處理：助理停了，佇列就不再更新，而一份
舊佇列讀起來跟新的一模一樣。所以佇列檔頭帶那一輪的時間戳與 epoch，這裡
算出它多舊；超過心跳門檻或心跳不新鮮，就明說這批提醒是多久以前算的、
助理現在的心跳是什麼狀態。門檻與狀態都取 heartbeat.sh 印的那一行。

佇列空又過期的那一種分兩路：待辦簿有東西才說話，零筆就安靜——人自己按停
也算零筆那一種，對著一個刻意的決定每個工作階段催一次是噪音不是提醒。
助理狀態目錄根本不存在時整支安靜退出，那台機器從沒啟動過助理。

一個工作階段只提一次，記號是 sessions/{代號}.reminded。接不到 session id
的 CLI 全部共用 default，所以 session-timer.sh 的 restart 分支順手清掉那個
記號——不清的話那支 CLI 從第二個工作階段起再也收不到提醒。清除掛在那裡
不掛在這裡：「這是不是新的工作階段」的判準只有那一支知道。

接線與檢核一起改，不留一支沒人驗的 hook：hooks.json 與推導出來的
codex-hooks.json 各加一條、kiro 的 agentSpawn 加一條、claude 的 status
逐支列舉加一項、冒煙測試加一條並把預期條數從 17 改成 18、執行期錯誤掃描
的 jsc 判定加一支腳本名，還有散在文件與回報字串裡的「九支 hook」十處
全部改成十支。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 11:14:41 +08:00
jiantw83 858d3521bd fix(lib): 補上 stdin JSON 的載入期預設值，收尾不再吐未設定訊息 
有幾條路徑在收尾時會往標準錯誤吐一行「參數未設定」，掃描結果其實是對的，但那行訊息讓人以為掃描失敗。註解範圍掃描的流程規定「安靜地回 0 才算通過」，這一行正好讓「安靜」這個判準失效。

根因在共用函式庫：hook_trace 裝的 EXIT trap 會在腳本結束時經由 emit_event 呼叫 session_id，而它第一件事就是讀 stdin JSON 那個變數。腳本在讀取標準輸入之前就離開時，那個變數還沒人設過，開了 set -u 的腳本收尾就報錯。

訊息裡的檔名有誤導性：dash 回報行號用被 source 檔的行號、檔名卻用呼叫端的名字，所以看起來像是呼叫端的第 30 行出錯，實際上在函式庫裡。用一支探針腳本確認過行號的來源。

修法是在共用函式庫載入期給那個變數一個預設值，寫在任何讀取它的函式之前。修在共用處而不是各腳本各補一次：讀它的是共用函式，補在共用處才涵蓋每一條離開路徑，也涵蓋往後新增的腳本。用帶預設的展開而不是直接指派空字串，呼叫端已經帶值進來時原樣保留。

這個缺陷不只一處。凡是「有 set -u、裝了 hook_trace、又在讀取標準輸入之前離開」的路徑都會中，實測四條路徑修前都吐、修後都安靜。

驗證三項：掃描回 0 且標準錯誤零位元組；陽性對照仍正確回 2 並印出命中，證明掃描還有作用；事件記錄仍然正常，且事件裡的工作階段欄位取自標準輸入而不是預設值。事件驗證用隔離的環境做，沒有污染正式事件流。
 2026-09-03 13:06:35 +08:00
jiantw83 95c7bb1eee fix(lib): 跨外掛路徑解析改實體解析，修好版本閘門 
版本閘門對 11 個 domain 全部回「查詢失敗」，等於完全失效——它擋不下任何版本落後的技能呼叫，而且是無聲的：report 照印表格，只是每一列都寫查詢失敗。

根因是 jsc_gitea_sh 回傳的路徑帶著 ..，而那些 .. 要穿過 current/jsc-hooks 這條符號連結。兩種解析方式對它的答案不同：核心與 [ -f ] 用實體解析、跟著連結走，判定檔案存在；shell 的 cd 用邏輯解析、純文字消去 ..，落到一個不存在的目錄。所以 [ -f ] 檢查通過、路徑交了出去，gitea.sh 的 cd 卻失敗，回結束碼 2 與空輸出，呼叫端就判成查不到。

新增 jsc_abs_path，用 cd -P 加 pwd -P 把路徑正規化成不含 .. 的實體路徑。挑這個做法是因為兩者都是 shell 內建，不必在 PATH 上找執行檔——這些函式會在 cron 那種只剩幾段 PATH 的環境下跑，少一個外部相依就少一個解不出來的理由。jsc_gitea_sh 的四條候選改成尾端統一正規化，正規化失敗就退回原樣路徑，「找得到」的判準不變。

wire-cli.sh 的 HERE 與 ROOT 一併改成實體解析。那是同一個根因的另一種發作方式：ROOT 會被 ln -sfn 當成目標，而這支腳本常常就是經由那條連結被叫起來的，邏輯解析會讓 ROOT 等於連結自己，連結被改成指向自己，全機器 hook 一起失效。這件事實際發生過。原本靠兩道防線擋著：事後的 [ -f ] 檢查，以及文件要求呼叫端先解出實體根目錄。前者要等連結已經被寫壞才攔得到，後者靠人記得。改成實體解析之後這個失敗模式不可能成立。

行為契約第 10 列跟著改：從實體根目錄跑 wire-cli.sh 的規定保留，但性質從必要條件降成多一層保險，並寫明保險為什麼還值得買——舊版腳本還在別的機器上跑。

驗證用同形佈局做：暫存區搭一套一樣形狀的連結農場，先塞原版重現失敗、再塞改版確認修好。真實環境的連結與快取全程沒有動過。
 2026-09-03 12:19:27 +08:00
jiantw83 a3ef205489 feat(狀態回報): 技能與 hook 的執行結果寫進本機事件流 
現行紀錄只記「被叫用」，欄位是 ts、cli、session、skill，沒有成敗也沒有
結束碼。跑完整輪的技能與開場就中止的技能，在紀錄裡長得一模一樣。hook
成功時更是完全不留紀錄，只有錯誤路徑會寫 wiki，而那條路徑刻意不自動觸發。

事件流走本機檔案，不直接寫 wiki。hook 每次提示都跑，網路寫入會拖垮宿主
CLI；失敗的 hook 自我回報還會疊出迴圈，既有的錯誤回報因此不接在失敗的
hook 上，這裡沿用同一條線。助理巡檢時排空、彙整、寫頁。

hook 端用 EXIT trap 接，一支只加一行。這幾支的 exit 點很多，階段閘門一支
就有五十幾個；逐點改要動到每一條判定路徑，而那些路徑正是閘門的判準，為了
加一行紀錄去動閘門，風險遠大於收益。trap 涵蓋每一條離開路徑，含中途失敗。

狀態預設由結束碼推，推不出來的由 hook 自己覆寫。相依版本檢查與兩道閘門有
這種情形：antigravity 走 deny JSON、kiro 只印警告，兩者擋下時結束碼都是 0，
單看結束碼會把擋下記成放行。

技能的 start 由既有的技能用量 hook 順手發，不必改任何技能文件。end 只能由
技能自己在收尾步驟寫——hook 觸發時技能的實際工作還在後面的模型輪次，看不到
成敗。有 start 沒有配對的 end，就是那一輪中止了。
 2026-09-02 15:40:17 +08:00
jiantw83 f4871afd19 feat(wiki): 異常目錄頁改走專用存取庫，並修正目錄列連結恆空 
What：ERROR_CONTENTS 改由 wiki-repo CONTENTS 解析，ERROR_{HASH} 仍走
wiki-repo ERROR，兩者是兩個不同的存取庫。目錄列的連結改用 wiki-url 的絕對網址。
註解掃描的頁面編號樣式補上 40 碼與 H 加 7 碼兩種形狀。

Why：目錄列的網址原本在異常頁寫入之前就取，而頁名的雜湊帶時間戳、每次都是全新頁，
那時查一定是 404，又被吞掉，所以那一格一直都是空的。註解掃描原本只收 8 碼純十六進位，
舊演算法有十三個首碼會改寫成 H 開頭，等於對絕大多數舊頁編號漏偵測。

How：降級語意分兩層——異常頁的存取庫解不出來就整支安靜降級，只有目錄頁解不出來就
只寫異常頁、跳過索引，兩種都維持 exit 0。「只有 exit 4 才准建新頁、7 與 8 一律中止」
那段原樣保留，那是防止把金鑰失效讀成頁面不存在、拿範本蓋掉整頁既有列。

Who：jsc-hooks
 2026-09-02 11:30:49 +08:00
jiantw83 78dcb5e33b fix(sdlc-gate): 能力閘門依 CLI 分流，判不出能力就擋下 
What：
- current_model_report() 的偵測鏈依 CLI 分流，一支只讀自己的紀錄。claude 讀 transcript 與 hook stdin，codex 讀 hook stdin 與自己的 session 記錄，copilot、antigravity、kiro 本機沒有可讀的模型紀錄，判不出是哪一支 CLI 時不採用任何自動來源。JSC_MODEL 人工覆寫五支都保留，而且一律排在最後。
- session_id() 的退路鏈補上 CLAUDE_CODE_SESSION_ID，cli_name() 補上 CLAUDECODE 與 CLAUDE_CODE_SESSION_ID。
- 階段鎖狀態檔改成 sessions/{CLI 代號}-{sid}.stage。舊路徑仍讀得到，unlock 不帶參數時新舊兩份一起清，也收一個狀態檔路徑當參數。
- check 改成 fail-closed：判不出 CLI、判不出模型、模型不在能力標籤表上，三種一律以 exit 2 擋下該輪提示。每一則擋下的訊息都印出兩條逃生門。
- write-guard.sh 的 stage 模式改讀 lib.sh 的路徑函式，擋人訊息把實際讀到的狀態檔路徑寫進解除指令。
- codex_session_file() 取「全樹最新一支」的做法改掉。
- wire-cli.sh 的冒煙夾具跟著補：模型來源四條各自指定 CLI 代號，另加三種擋下情形、check 的 fail-closed、階段鎖的 CLI 區隔與舊格式相容，這一組的判定條數由四條增為十二條。
- README 的 hooks 表、狀態檔分界表與環境變數表跟著改。

Why：
- 使用者回報兩件事：在 claude 底下被 codex 的模型判定，而且這道閘門應該只鎖能力標籤、不鎖模型。查下來根因是同一個——閘門完全不分辨自己跑在哪一支 CLI 上。
- 偵測鏈不分流，claude 拿不到 transcript 就一路掉進 codex 的 session 記錄，拿別支的模型判這一支。順帶每一輪都對一個上千個檔、兩百多 MB 的目錄樹跑一次 find，宿主 CLI 跟著卡。
- session_id() 讀的變數名在目前的 claude 上並不存在，sid 一路退回 default。cli_name() 犯同一類錯：只認 plugin 接線才有的變數，技能以 Bash 工具呼叫腳本時取不到，一律判成 unknown。
- 前三項合起來的後果是：技能呼叫 lock 算出的檔名，跟 hook 算出的檔名永遠不同。階段鎖上了也對不上，所以這道閘門在 claude 上一直沒有真正生效。
- 狀態檔不分 CLI，各支就共用同一支 default.stage，一支上的鎖擋到另一支。那不只擋提示，write-guard.sh 的 stage 模式連 Write、Edit、MultiEdit 一起擋。

How：
- 政策改成 fail-closed：不知道能力就擋下，知道才比對標籤。原本判不出模型只提醒不擋，那等於「換一支讀不到紀錄的 CLI 就能繞過去」，閘門形同虛設。代價是把人鎖在送不出提示的狀態，所以每一則擋下的訊息都要帶兩條逃生門，照抄就脫困。
- 逃生門的路徑照抄進指令裡。擋人的是 hook，解鎖的是人在殼層手動執行，兩邊算出來的檔名未必相同，不點名就解不到真正擋人的那一支。
- unlock 的參數只收 sessions 目錄底下的 .stage 檔，逃生門不該順便變成任意刪檔的工具。判準刻意不綁這支行程算出的 JSC_HOME：擋人的一側跟解鎖的一側未必相同，綁上去就會把照抄訊息的人擋掉，那正是這個逃生門要避免的事。
- 狀態檔用檔名前綴不用子目錄。外部工具以單層的 sessions/*.stage 盤點階段鎖，改成子目錄會讓每一支鎖從那些盤點裡整批消失。
- 舊路徑只讀不搬也不刪，unlock 一併清掉。只清新的那一份，舊格式的鎖就永遠解不開，被它擋住的人沒有逃生門。
- 變數名只補實測看得到的那幾個，而且只補 claude 這一支。其他 CLI 的變數名與環境特徵沒有實測過，猜一個填進來只會多一個錯誤來源，那幾支本來就由接線設定明確帶 JSC_CLI。
- codex_session_file() 原本寫成 xargs ls -t 再 head -n 1，那是錯的：xargs 依參數長度分批，ls -t 只在自己那一批裡排序，取到的是第一批裡最新的，不是全域最新。改成讓 find 一併印出修改時間再全域排序；沒有 -printf 就退回路徑排序，那些檔名以 ISO 時間開頭，字典序等同時間序。
- 冒煙的擋人案例連訊息一起驗，不只比結束碼。訊息漏掉逃生門一樣是綠燈，而那才是這道 fail-closed 真正的風險。
- 四支腳本併成一筆。write-guard.sh 讀 lib.sh 的路徑函式，wire-cli.sh 是驗這些行為的冒煙夾具，拆開會留下跑不過的中間版本：路徑函式與呼叫端分兩筆，中間那一筆狀態檔的讀寫兩側就對不上。
- 一次性代價：升級後每台機器第一次 SessionStart 會清一次重啟閘門。sid 換了名字，看起來像新的工作階段。只發生這一次。
- 三份 manifest 這一筆不動，版本號另外提升。

Who：
SDLC 階段能力閘門。修的是它一直沒有生效的那條路徑，順帶把 codex session 記錄的取檔方式一起修掉。
 2026-09-02 10:48:08 +08:00
jiantw83 800a899239 feat(assistant-gate): 助理運行閘門，這一版尚未接線 
What：
- 新增 hooks/assistant-gate.sh：心跳新鮮就放行，心跳不存在、過期或時間戳壞掉就擋下該次技能呼叫。
- 豁免清單十一支、逃生門一個。README 的 hooks 表與環境變數表跟著補。
- 這一版刻意不接線，接線檔一個字都沒動。

Why：
- 助理沒在跑的時候，技能會以為背景有人收尾，實際上沒有。這道閘門把那個落差擋在門外。
- 不接線是因為這台機器的穩定路徑指向開發存放庫，寫進接線檔就立刻對五支 CLI 生效。而現在還沒有心跳，接線的那一秒整組技能會全部鎖死，連修的路徑都走不到。接線的前提是助理已經在跑、心跳穩定。

How：
- 這是整組 hook 裡唯一一道 fail-closed 的閘門。其餘的原則都是資料不足就放行，這一道相反。代價是狀態檔寫不進去時全組停擺，所以逃生門與豁免清單不是選配，是能上線的前提。
- 豁免清單只收解鎖路徑，不收收尾規則。這一點與重啟閘門的方向相反：重啟閘門解鎖靠閘門外的動作，收尾規則要寫得完；這一道解鎖靠跑一支技能，清單收寬了閘門就等於沒有。
- 清單認技能名不認呼叫鏈，所以豁免技能轉呼叫的下一層也要收進來。最要緊的是 wiki 那一支：巡檢要先把結果寫上監控頁才寫心跳，只豁免助理自己會做出「沒心跳就擋 wiki、擋了巡檢跑不完、跑不完就還是沒心跳」的自咬環。
- 心跳判定回「檔案系統問不出來」時放行，不擋。那是判不出事實，不在這道閘門的職權裡；而且那一刻正是磁碟或權限壞掉的訊號，擋下去連豁免那幾支也修不動——它們同樣要寫狀態檔。磁碟壞掉要人去清磁碟，不是把技能組鎖起來。時間戳壞掉則照擋，那是確定沒有可信心跳的證據，而且修法就在豁免清單裡。
- 逃生門的判斷擺在載入共用函式庫之前。函式庫讀不到時 sh 會就地結束並回擋人的那個碼，逃生門也會跟著跑不到，人就繞不過去。
- 擋人一律經 deny.sh 輸出。三支走標準錯誤加結束碼，另外兩支靠標準輸出的內容擋，結束碼固定是零；自己印訊息會在那兩支上無聲失效。
- 心跳不存在、過期、時間戳壞掉三種情況講三種話。使用者要做的事不一樣：一個是從沒啟動過，一個是跑過停了，一個是檔案壞了要重建。

Who：
助理落地的最後一塊。接線與準則那一節另外處理。
 2026-09-01 15:19:59 +08:00
jiantw83 b5107563dd chore(manifest): 心跳腳本的版本號補上，檔頭改指正確的技能名 
What：
- 三份 manifest 的版本一起提升。
- heartbeat.sh 檔頭引用的技能名由 status 改成 assistant。

Why：
- 上一筆加了 heartbeat.sh 卻沒有動版本號。版本不動，別的 domain 就沒有辦法用相依宣告要求「要有這支腳本的那一版」——宣告寫得出來，卻保證不了內容。助理宣告的下限本來會落在一個不含這支腳本的版本上。
- 檔頭寫的技能名是助理落地初期那一支獨立技能。助理主體把三個操作收攏成一支之後，那個名字就不存在了，照著找會找不到東西。

How：
- 版本由 sync-skill-manifest.sh 同步，三份一致。
- 這一支仍然不接線，只是被助理與閘門呼叫的工具。

Who：
助理主體實作時，從相依宣告那一側回頭抓到的兩個缺口。
 2026-09-01 14:18:49 +08:00
jiantw83 b0e352ae15 feat(heartbeat): 新增助理心跳的寫入、判定與回報 
What：
- 新增 hooks/heartbeat.sh，四個子命令：write 寫心跳、check 判定新鮮、report 印現況、clear 清除。
- README 的 hooks 表補一列，事件欄註明不接線；環境變數表補上心跳門檻那一個。

Why：
- 助理是背景行程，別人要知道它還在不在跑，唯一的依據就是它留下的心跳。閘門要判、status 技能要印、巡檢要記，三邊都需要同一份判定。
- 判定散在三個地方一定會漂移，狀態跟訊息就會對不上。所以判定只寫一份，check 與 report 共用同一個探測函式。

How：
- 新鮮的判準是「檔案存在，而且時間戳距現在小於門檻」。門檻預設 300 秒，是心跳週期的五倍，一次網路或磁碟卡頓不會誤判；環境變數可以覆寫，壞值退回預設而不報錯——變數打錯字不該讓判定整個歪掉。
- 絕不看 pid 存活。五支 CLI 與容器裡的行程互相看不到彼此的 pid，看了也證明不了什麼，pid 只當擋人訊息的線索。
- check 用結束碼分四種狀態：新鮮、過期、不存在、時間戳壞掉。前三種的處置各不相同，擋人訊息要說的話也不一樣；第四種既不是「跑過停了」也不是「沒啟動過」，併進任何一邊都會讓訊息說錯話，而且絕不能退回判成新鮮。
- 寫入走暫存檔再更名。直接覆寫的話，剛好讀到寫一半的檔案會少掉時間戳，助理活著卻被判成壞了。
- 這一支不接線，只是被助理與閘門呼叫的工具。接線是後續獨立的一步，先接會在心跳還沒跑起來時就擋死整組技能。

Who：
助理落地的第一塊：先有心跳，閘門才判得動，主體才有東西可寫。
 2026-09-01 14:08:14 +08:00
jiantw83 113df37808 fix(comment-scope): 頁面編號偵測補齊三種缺漏的型別 
What：
- wiki 頁面編號的偵測樣式補上 SKILLSET、TOOLING 與 MONITOR 三種型別。
- 三份 manifest 的版本一起提升。

Why：
- 這支 hook 的職責是擋住把文件追蹤資訊寫進程式碼註解，wiki 頁面編號正是禁止項之一。
- 樣式只列到 REPORT，但實際的頁型清單早就有 SKILLSET 與 TOOLING，現在再加 MONITOR。清單漏掉的那幾種，頁面編號寫進註解就攔不到，等於這條規則對它們不存在。
- SKILLSET 與 TOOLING 的缺漏是既有落差，不是這次新增型別才產生的，一併補齊比較省事，也不會留下第二個要記得的地方。

How：
- 型別的排列順序照 gitea.sh 的 resolve_wiki_repo 走，兩邊一致才看得出有沒有漏。
- 規則正文的唯一來源仍是 jsc-review 的註解範圍文件，這裡只補偵測樣式，不重述規則清單。
- 實測過三種型別各自都攔得下來，命中的說明都是「jsc wiki 頁面編號」，不是旁邊那條前綴加流水號的樣式誤撿。

Who：
技能助理落地帶出來的頁型別需求，四個存放庫同一批改。
 2026-09-01 12:11:10 +08:00
jiantw83 eebe2a2873 feat(wire-cli): 接上四支 CLI 的 pre-tool hook 
What：
- tools/wire-cli.sh 重寫 codex、copilot、antigravity、kiro 四支的接線、purge、status 與 smoke。
- 新增 hooks/codex-hooks.json，由 hooks/hooks.json 推導產生。
- .codex-plugin/plugin.json 加上 hooks 路徑鍵，指向那份檔案。

Why：這四支其實都有能介入的 pre-tool 事件，原本卻接錯位置，抓到五個同一類的無聲失效——設定看起來正確、CLI 靜默不理、不報錯：
- codex 的 matcher 用 Skill，但 Codex 沒有 Skill 這個工具，技能是模型自己用 Bash 讀 SKILL.md 載入的。
- codex 的 hooks 鍵寫成內嵌物件，實際規格是路徑字串，內嵌物件解析不了。
- antigravity 的 PreToolUse 寫成 Flat，實際要 matcher 加 hooks 包一層的 Grouped。Flat 的那一段整個被丟掉，hook 名稱照樣登記，檔案讀起來還是對的。
- copilot 的設定寫到 $COPILOT_HOME/hooks/，那是 hook 要跑的腳本目錄、不是設定目錄，設定從來不會被讀。
- 三支新接的命令沒帶 JSC_CLI={代號}，閘門認不出自己跑在哪支 CLI 上，一次都擋不下來。

How：
- codex：PreToolUse matcher 換成 Bash。codex-hooks.json 由 hooks/hooks.json 整份複製，再把 matcher 的 Skill 改寫成 Bash，其餘事件原樣保留，Claude 那份維持唯一真實來源，第二份絕不手寫。
- copilot：pre-tool hook 併進 ~/.copilot/settings.json 的頂層 hooks 鍵，matcher 用小寫 skill，事件名只寫一種大小寫。那份檔案同時裝著 enabledPlugins 與 extraKnownMarketplaces，所以合併不覆寫：寫前備份、只動 jsc 自己那幾筆、寫後回讀核對最上層鍵與別人的條目，對不上就還原。指引檔改寫到 $COPILOT_HOME 底下。
- antigravity：寫 ~/.gemini/config/hooks.json 的 jsc 段落。PreToolUse 改成 Grouped、matcher 是錨定的 view_file，錨點不能省，省了會連 view_file_outline 一起命中；另接 Flat 的 PreInvocation，攔斜線指令那條不產生工具呼叫的路。
- kiro：hook 宣告搬到 ~/.kiro/agents/jsc.json 的 hooks 鍵，事件只用 agentSpawn、userPromptSubmit、stop，欄位是 command 與 timeout_ms，並把 settings/cli.json 的 chat.defaultAgent 設成 jsc。kiro-cli agent validate 四種情況一律回 0，所以判準看輸出、不看結束碼。
- 四支非 claude 的接線命令一律以 JSC_CLI={代號} 前綴自帶代號，接線時、status 與 smoke 各斷言一次。
- status 從只驗「鍵在不在」改成驗形狀與位置，並新增第三格 unverified，把「驗不了」跟「驗過了」分開，只有 missing 算缺項。
- smoke 新增 26 條接線形狀斷言，每條正向配一條反向，另把五支 CLI 的真實負載直接餵進 restart-gate.sh，驗解析、判定、輸出整條串得起來。前兩段分開看都會顯示正常，中間接不上照樣是全程放行，那正是先前失效的樣子。

Who：codex、copilot、antigravity、kiro 四支 CLI 的 pre-tool hook 接線修正。
 2026-08-31 19:05:48 +08:00
jiantw83 0e9308f60e feat(hooks): 技能名解析與阻擋輸出共用化 
What：
- 新增 hooks/skill-name.sh。五支 CLI 各一個子命令，從各自的負載解析出這一次要用哪一支 jsc 技能，印一行「{domain}<TAB>{技能名}」。解不出來就印空字串並回 0。
- 新增 hooks/deny.sh。依當前 CLI 產出四種阻擋形態，訊息從參數或標準輸入進。
- version-guard.sh 與 restart-gate.sh 改用這兩支，各自那份工具名判定與技能名取值一併移除。

Why：
- 兩道閘門原本都拿 Claude 的工具名 Skill 當通用條件。另外四支 CLI 的工具名分別是 Bash、skill、view_file，一律被擋在判定之外，兩道閘門在那四支上長期完全失效，而且一聲都不吭。
- 阻擋形態每支 CLI 都不一樣，判定卻是同一件事。各自留一份輸出邏輯，改了一支忘了另一支，就會做出「判定擋下、CLI 照樣放行」的無聲失效。

How：
- 技能名取值規則只留 skill-name.sh 這一份，環境變數 JSC_SKILL、SKILL 優先。claude 讀 skill 欄位、codex 認 tool_input.command 裡那條 SKILL.md 路徑、copilot 先剝一層字串化 JSON 再讀 toolArgs、antigravity 讀 toolCall.args.AbsolutePath 並另收提示字串、kiro 取提示開頭那個斜線指令。
- 閘門端用 awk 判 NF == 2 才取值。少一欄就當成解析不出來，免得沒有定位字元時 cut -f2 把整行當成技能名，拼出一個不存在的技能名去比對豁免清單。
- deny.sh 定形態：claude、codex、copilot 走 stderr 加 exit 2；antigravity 印 stdout 的單行 deny JSON 並固定回 0，因為那支 CLI 的結束碼語意兩邊文件都沒寫、絕不可靠；kiro 擋不下技能叫用，改印警告後回 0；認不得的代號走 stderr 加 2 這個保守預設。
- 訊息整段走同一條管線送進 deny.sh。分次呼叫會做出好幾份 deny JSON，antigravity 只認第一份，後面幾段使用者永遠看不到。
- 豁免清單與 fail-open 原則不變。這兩支刻意以子行程呼叫、不用 source 載入：讀不到只會讓技能名解不出來而安靜放行，不會反過來擋掉每一次呼叫。

Who：codex、copilot、antigravity、kiro 四支 CLI 的 pre-tool hook 接線修正。
 2026-08-31 19:05:48 +08:00
jiantw83andClaude Opus 5 5c2727bf56 feat(version-guard): 版本前置檢查新增相依版本落後的擋人情況 
版本前置檢查多一種擋人情況。技能所屬 plugin 的 manifest 在 jsc.requires
宣告的相依 plugin，只要有一項的本機實際載入版本落後宣告的最低版本，
就以 exit 2 擋下這一次技能呼叫。訊息逐項講明哪一個 plugin、需要哪一版、
目前哪一版、怎麼補。

相依宣告原本只有部署那一端會回報，沒有任何一道閘門擋。機器上因此會出現
版本互相搭不起來的 plugin 組合，技能跑到一半才失敗，使用者也看不出要更新
哪一個 plugin。

判定邏輯自己實作，不呼叫 jsc-cli 的 check-requires.sh。hook 一律專屬存放在
jsc-hooks，不可散落到別的 domain；jsc-cli 也已經宣告相依 jsc-hooks，
反向呼叫會做出循環相依。安裝路徑解析抽成 install_path()，與本機載入版本
共用同一條規則，各寫一份就會漂移。相依檢查排在豁免清單與逃生門之後、
遠端比對之前，全部讀本機檔案，離線的機器也判得動。豁免沿用同一份 7 項清單，
相依落後不另立短清單：這幾支同樣是更新與修復的唯一路徑，用哪一個理由擋
都是死鎖。四種情況一律安靜放行：解不出安裝路徑、讀不到 manifest、
manifest 沒有 jsc.requires、讀不到相依 plugin 的本機載入版本。五支 CLI
只有 claude 讀得到本機載入版本，fail-closed 會把另外四支整批鎖死。

所屬功能：版本前置檢查的相依版本閘門。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-31 13:41:25 +08:00
jiantw83 04225a7a2d docs(hooks): 每支腳本檔頭補上結束碼宣告，文件對齊九支 hook 的現況 
共用函式庫與各支腳本的檔頭各補一段結束碼宣告，逐個子命令寫明哪些情況放行、
哪些情況擋下。說明文件改寫成九支 hook 的現況，補上寫入與提交閘門、唯讀模式、
建議子命令與新的環境變數。異常目錄範本補上「一律附加、不整頁覆蓋」的寫入語意。

呼叫端要靠結束碼決定下一步，但多數腳本只寫用法、沒寫結束碼，
讀的人得自己翻程式碼推，推錯就把安靜降級當成失敗處理。
共用函式庫載不到時，殼層會就地結束並回非零，接在工具呼叫前的閘門遇到這一下
等於無聲擋人，腳本自己的放行路徑一條都跑不到，這件事非寫進每一支檔頭不可。
文件停在八支 hook 的舊敘述，看的人會誤判覆蓋範圍，以為每支 CLI 都擋得住。
目錄頁的寫入語意只寫在腳本裡，換一支工具來寫就會整頁覆蓋。

一支腳本一段檔頭，逐子命令列出結束碼，並各自註明共用函式庫載入失敗會回哪一個碼。
文件的行數一律引用腳本自己印出來的那一行，不另抄一份數字，
判定路徑增減時就不會漂移。覆蓋範圍逐支 CLI 分開寫，接不上的就寫接不上。
 2026-08-31 11:17:28 +08:00
jiantw83 e2b08f04a3 fix(gates): 修好會蓋掉異常目錄、把修復路徑鎖死與誤擋計畫階段的缺陷 
異常回報依 wiki 讀取的結束碼分流，只有頁面確定不存在才套範本建新頁。
版本閘門與重啟閘門的豁免清單各補上 hook 修復技能。
階段閘門把計畫階段移出擋人名單，改成只注入提醒。
錯誤掃描的自家 hook 判定補齊九支腳本，並加一條路徑判定。
修復技能與接線技能的內文改成真的走得到的路徑與真的存在的關卡數。

原本 wiki 讀取失敗會一路落到套範本那一步，金鑰失效或 API 出狀況時，
就拿一份空白範本蓋掉整份異常目錄，而寫入不做合併也不留備份，蓋掉就救不回來。
兩道閘門把唯一的 hook 修復路徑一起擋住，hook 一壞就沒有任何方法修回來，
閘門等於鎖掉解除自己的路徑。工作包閘門擋下計畫階段是誤擋：
計畫是純邏輯階段、不碰程式碼，而閘門只知道有 PR 未合併，判不出跟新計畫有沒有關聯。
自家 hook 判定只認得早期那五支，後來加的四支出錯會被當成第三方的，只回報不修正。
修復技能裡三個指向流程的路徑指到不存在的位置，照著走一定撲空；
接線流程寫四道關卡，實際上有五道，兩段中文說明也混在英文內文裡。

異常目錄改成先讀回舊頁、把新列附在文末、再整頁寫回；讀不回來就放棄寫目錄頁並回報，
寧可少一列索引，也不覆蓋別人的紀錄。兩份豁免清單各補一項，理由逐項寫在腳本檔頭。
計畫階段改印提醒後放行，放棄的在製品上限與代價一併寫在檔頭。
自家 hook 判定逐支列出腳本名，再加一條安裝路徑判定，日後新增 hook 忘了補清單也還認得出來。
三個路徑改指到擁有它的技能組，關卡數改成五道並逐關寫明結束碼，兩段中文說明改回英文。
版本閘門在同一次改動另補唯讀的建議子命令，把版本比對表收斂成一行結論，
部署技能不必自己再解一次那張表。
 2026-08-31 11:15:24 +08:00
jiantw83 b5219f6549 feat(write-guard): 新增寫入與提交閘門，把三條只寫在內文的規則落到程式層 
新增第九支 hook，共四種模式。stage 在計畫與分析階段鎖著時擋下寫檔。
review 在稽核類技能執行中擋下寫檔。commit 擋下「一次加入全部變更再提交」的
單一指令，也擋下含簡體字、亂碼或非 UTF-8 編碼的提交訊息。
release 不接 hook，由稽核技能收尾時自己呼叫，清掉認人用的那份紀錄，
讓呼叫端接手修改時不會被剛跑完的稽核擋住。

這三條規則原本只寫在技能內文，靠模型自律。稽核技能會順手改程式碼，
計畫階段會寫出不該寫的檔案，整包提交會把型別與功能分組壓成一次。
規則要真的生效，就得由程式擋。release 模式是必要的：紀錄記的是最近一次
載入的技能，不是還在跑的技能，沒有它，稽核跑完之後呼叫端每一次寫入都被擋，
閘門會把解除自己的路徑一起鎖掉。

接線設定把 stage 與 review 接在寫檔工具，把 commit 接在指令工具。
閘門只讀階段閘門的狀態鎖與技能用量的紀錄，不自己寫狀態檔；
簡繁與編碼判定整段轉呼叫語言守門，不留第二份字表。
接線腳本的接線、唯讀盤點與冒煙各補上這一支，冒煙自備暫時的狀態目錄，
逐條比對每種模式的結束碼。接線腳本另補唯讀模式，體檢類技能全程帶著它跑，
清除與接線一律拒絕並回非零，子命令打錯一個字也改不到環境。
冒煙改成自己數結果行並自我斷言，散文只引用那一行，不再各抄一份數字。

限制據實寫在檔頭：只有 claude 有寫檔前置鉤子，其餘四支 CLI 一條都接不上，
那四支上這三條規則仍只剩技能內文。
 2026-08-31 11:15:24 +08:00
admin 6b272974b5 Merge pull request 'fix/codex-model-gate' (#48) from fix/codex-model-gate into develop 
Reviewed-on: #48
 2026-08-28 10:12:31 +00:00
jiantw83 955a36adb9 fix(codex-hooks): 避免 Claude manifest 在 Codex 變成空路徑 2026-08-28 18:07:20 +08:00
jiantw83 83f6bdf21c fix(model-gate): 支援 Codex 可驗證模型來源 2026-08-28 16:45:58 +08:00
jiantw83 1477ba7b29 feat(comment-scope): 偵測審查流程痕跡 2026-08-28 09:30:18 +08:00
jiantw83 f6335180fa fix(version-guard): 依 CLI 分離遠端版本快取 2026-08-28 09:30:12 +08:00
jiantw83 7517566156 fix(restart-gate): 重啟閘門狀態檔改為一支 CLI 一份 
What：`hooks/restart-gate.sh` 的狀態檔從全機器單一檔案 `$JSC_HOME/restart-required` 改為狀態目錄 `$JSC_HOME/restart-required.d/{CLI 代號}`，一支 CLI 一份，檔名就是 CLI 代號，四行 key=value 的格式不變。新增 `cli_code()` 取當前 CLI 代號（含不能當檔名的髒值防護）與 `state_line()` 統一 `report` 的輸出格式；`require` 只寫自己那一份、hook 判定只讀自己那一份、`clear` 只刪自己那一份、`report` 一支 CLI 一行印出還沒重啟的是哪幾支。舊格式的單一檔案存在時一律擋，訊息標明是舊格式紀錄，`clear` 會一併刪掉它。檔頭註解同步改寫，新增「report 輸出格式」與「舊檔相容（過渡用）」兩節。`hooks/session-timer.sh` 程式碼不動，兩處註解補上「清除範圍只有跑到這支腳本的那一支 CLI」。

Why：這道閘門 2026-08-27 才上線，部署現場實測抓到兩個缺陷。第一，`require` 用 `>` 覆寫單一檔案，並行部署互相覆蓋——kiro 寫入 9 秒後被 codex 蓋掉，`domains=` 與 `cli=` 不再代表 kiro。第二，`clear` 用 `rm -f` 刪整個檔案，任一支 CLI 重啟就解除全部五支的閘門，其餘四支沒重啟卻不再被擋。這台機器就裝了五支 CLI，閘門在多 CLI 環境等於半失效。閘門管的是「這一支 CLI 的行程還在跑舊版」，那是每支 CLI 各自的事實，狀態檔本來就不該共用。

How：寫入、判定、清除三件事都只碰自己那一份，別支那幾份一律不看，`clear` 的範圍也就收斂成呼叫端那一支。取不到 CLI 代號時比照既有的「查不到就放行」原則：hook 模式放行，`require` 回 exit 2 並講明這次沒有掛上閘門——寫到讀不到的檔名等於沒掛，不能讓部署以為掛上了。代號會直接拿去當檔名，所以含 `/`、以 `.` 開頭、或出現 `[A-Za-z0-9._-]` 以外字元的值一律當成取不到，狀態檔就寫不到目錄外面去。舊檔沒有 per-CLI 資訊，分不出是哪一支寫的，判定寧可擋多不擋少；`clear` 只在新工作階段被呼叫，呼叫到就代表確實有一支重新啟動過了，舊檔留著會讓五支一路被擋到有人手動刪，所以一併刪掉。這段相容邏輯與可移除的時機（所有機器都跑過一次寫狀態目錄的部署與重啟之後）寫在檔頭「舊檔相容」與 README。`session-timer.sh` 不必跟著改：狀態檔的路徑、範圍與格式只留在 `restart-gate.sh`，那裡只負責判斷新舊工作階段。

Who：`jsc-hooks` 的部署後強制重啟閘門（R15），以及它與 `session-timer.sh` 的清除分工。
 2026-08-27 18:49:58 +08:00
jiantw83 dbf9aac25e feat(restart-gate): 新增部署後強制重啟閘門，並接上新工作階段自動清除 
What：新增第八支 hook `hooks/restart-gate.sh`。hook 模式在 `$JSC_HOME/restart-required` 存在時以 exit 2 擋下 jsc 技能呼叫，另有三個子命令：`require {模式} [{domain}...]` 寫入狀態檔掛上閘門、`clear` 清除狀態檔、`report` 印出狀態檔內容。`hooks/hooks.json` 把它接到 PreToolUse(Skill)，排在 `version-guard.sh` 前面。`hooks/session-timer.sh` 的 `start` 與 `restart` 在判定為新工作階段時轉呼叫 `clear`。

Why：部署換掉的是磁碟上的技能檔，正在跑的 CLI 行程載入的還是舊版——SKILL.md、hook 腳本與 tools 都在啟動當下讀進記憶體。這段落差期間跑技能，改動看起來沒生效，人會以為部署失敗又重跑一次。所以部署收尾要求重新啟動，這道閘門負責讓「還沒重啟就繼續用技能」擋在門外。

How：判定看的是「檔案在不在」，欄位只用在擋人訊息上——欄位缺了只讓訊息少幾個字，不影響判定。狀態檔用純文字 `key=value`（`at`、`mode`、`domains`、`cli`），格式與工作包狀態檔同一套，`jsc-hooks` 與 `jsc-cli` 兩邊各自實作也對得上。放行原則比照 `version-guard.sh`：只擋確定違規，狀態檔讀不到、技能名取不到、工具名不是 `Skill`、技能不是 `jsc-*:*` 一律 exit 0，沒有證據時擋下等於停掉每一次技能呼叫。九支豁免（`jsc-cli:deploy`、`jsc-hooks:hooks-install`、`jsc-gitea:wiki`、`jsc-log:worklog`、`jsc-log:learn`、`jsc-meta:*`、`jsc-ask:ask`、`jsc-git:pr`、`jsc-git:commit`）的理由是同一件事：部署後還要寫得完技能組異動報告與工作日誌，整批擋下去「先重啟」與「先寫完報告」會互相打死。後三支自己不是收尾規則的主體，是為了讓前六支走得完才補進來的——清單認的是技能名，不是呼叫鏈。清除交給 `session-timer.sh`，不由本檔自己判：新舊工作階段的判準（`sessions/{sid}.start` 在不在）只有那支腳本知道，兩邊各寫一份就會漂移；續接同一階段走不到那一段，閘門就一路留到真的重新啟動。`require`、`clear`、`report` 都不讀標準輸入，只有 hook 模式讀，工具端呼叫一律再補 `</dev/null`，理由與 `sdlc-gate.sh` 相同。接線排在 `version-guard.sh` 前面：還沒重啟的舊版比落後一個版號更該先攔。不認得的子命令一律安靜 exit 0，不中斷宿主 CLI。擋人訊息依實際 CLI 給重啟方式，並附上豁免清單與逃生門 `JSC_RESTART_GATE=off`。

Who：部署後的第一次技能呼叫，以及 `jsc-cli:deploy` 收尾寫入狀態檔的那一端。
 2026-08-27 16:34:17 +08:00
jiantw83 870f52fbaa feat(sdlc-gate): 工作包閘門加上歸屬比對與領取紀錄 
What：`hooks/sdlc-gate.sh` 新增 `wp-claim {owner}/{repo} {工作包代號} [{PR 編號}] [{分析頁}]` 與 `wp-unclaim {owner}/{repo}` 兩個子命令，`wp-lock` 新增第四個參數收工作包代號，鎖檔改為純文字 `key=value`，`wp-report` 多印第四欄工作包代號。`wp-check` 逐筆判歸屬：`prompt` 多注入一行點名不屬於這裡的 PR，`skill` 擋下 `plan`、`analyze`、`maintain` 時一併點名，`implement` 仍放行但收到同一則提醒。

Why：同一份分析常有好幾包平行進行，每包各自的 worktree 與 PR。原本的鎖檔只記存取庫與 PR 編號，看不出那支 PR 是誰的，於是任何一個工作階段都可能去改別包的程式碼、回別包的留言。

How：歸屬只比一件事——鎖檔的 `wp` 與同一個存取庫領取檔的 `wp` 取數字比一次，兩邊都有值且不相等就是別包的。`WP-03`、`WP-3`、`3` 先正規化再比，不然同一包的幾種寫法會被當成不同包。任何一邊查不到（沒有分析頁、沒寫代號、領取檔不存在）一律當查無歸屬並放行，理由與 `version-guard.sh` 一致：只擋確定違規，否則會把技能組維護自己鎖死。舊版單行 TSV 鎖檔照樣讀得動，讀出來是查無歸屬，換格式不會讓既有的鎖失效。`implement` 一律放行，連別包的 PR 未結清也放行——結清 PR 正是 `implement` 的步驟，擋它會把流程鎖死。分類迴圈用 here-document 餵資料而不用管線，管線右邊是子 shell，判到的違規會在迴圈結束時全部消失。

Who：跑 SDLC 實作階段的每個工作階段，以及 `jsc-sdlc/tools/wp-gate.sh` 的 `claim`、`lock` 與 `owns`。
 2026-08-27 11:20:28 +08:00
jiantw83 75fba4715c feat(simplified): 字表擴充到 1006 字並補齊跳過清單 
What：簡體字表由 102 字擴充到 1006 字；lang-guard.sh 的跳過清單補上
jsc-meta 的 references/ste100.md 與 tools/ste100-lint.sh。

Why：102 字的舊表覆蓋率太低——拿 21 個常見簡體詞實測只抓到 4 個，「简体字」
「举办」「觉得」「战争」「医药」這類全部漏掉，規則等於形同虛設。跳過清單則是
對稱性問題：規則文件與機檢工具本身會列舉簡體字當範例，不跳過就每次先抓到自己。

How：字表逐字檢查「簡化後才出現的字形」，剔除正體也在用的字（后、台、干、只、
里、面、制、志、出、斗、丑、了、卷、咸、云、留、言、短、困、陷、游、封、吞），
再拿 jsc 全部 11 個存取庫共 221 個檔案的既有正體中文語料回歸驗證，誤報為零。
檔頭寫明排除原則與「改完必須拿語料重驗」的要求。跳過清單比照 ste100-lint.sh 的做法。

Who：非程式碼輸出的繁中無亂碼檢查。
 2026-08-27 09:53:55 +08:00
jiantw83 bbad6566f7 feat(wire-cli): 把 lang-guard.sh 接到五個 CLI 的既有時機 
What：`hooks/hooks.json` 的 `UserPromptSubmit` 加 `lang-guard.sh prompt`、`PostToolUse` 的 `Write|Edit|MultiEdit` 加無參數模式；`tools/wire-cli.sh` 把 codex 的 `notify`、kiro 的 `userPromptSubmit` 串上 sweep，規則檔文字加上 `lang-guard.sh prompt` 的輸出，`smoke` 三種模式各跑一輪，`status` 補盤點項，寫入後驗證一併涵蓋；`tools/jsc-wrap.sh` 收尾再跑一次 sweep；`hooks/ste100-guard.sh` 的注入文字補上適用範圍與 UTF-8 無亂碼。

Why：hook 寫好了不接線等於沒寫。接的位置與 `comment-scope.sh` 完全一樣，因為兩支要解的是同一個問題——只有 claude 有 post-tool hook，其餘四個 CLI 拿不到「剛剛寫了哪個檔」，只能改掃整個工作區。各 CLI 的掃描時機本來就不同：claude 逐檔即時、codex 每輪結束、kiro 每輪提示送出時、copilot 與 antigravity 只有工作階段結束，回報時不能寫成五支一樣。

How：規則檔文字取 `lang-guard.sh prompt` 的實際輸出，不在接線腳本裡抄一份規則，抄了兩邊就會各自漂移。寫入後以 `has_lang_guard()` 比對腳本第一行實際輸出，確認規則檔真的收到那一段。`smoke` 沿用既有的 exit 2 例外：掃描模式掃到違規回 2 是設計行為，不是執行期錯誤。`jsc-wrap.sh` 的 sweep 一律加 `|| true`，包裝器原樣回傳 CLI 自己的結束碼——包裝器改掉結束碼，呼叫端的 `cmd && next` 就會誤判。

Who：`jsc-hooks` 的接線層，由 `hooks-install` 技能對 claude、codex、copilot、antigravity、kiro 五個 CLI 執行。
 2026-08-27 09:50:03 +08:00
jiantw83 e3a9c67781 feat(lang-guard): 新增第七支 hook，強制非程式碼輸出繁中無亂碼 
What：新增 `hooks/lang-guard.sh` 與機檢字表 `hooks/simplified.txt`。腳本比照 `comment-scope.sh` 的結構，一樣三種模式：`prompt` 注入規則摘要、無參數掃剛寫入的單一檔案、`sweep [dir]` 掃整個 git 工作區這次改過的檔案。偵測三項：簡體字、亂碼（U+FFFD 與雙重編碼殘骸）、非 UTF-8 編碼。命中走 stderr 並 exit 2，資料不足或找不到 git 一律安靜 exit 0，逃生門 `JSC_LANG_GUARD=off`。

Why：使用者新增的規則是「非程式碼的輸出一律套用繁中無亂碼」，範圍涵蓋程式碼註解、commit 訊息、PR 描述、wiki 頁、對使用者的回報與各種文件。這條規則原本只有 `ste100-guard.sh` 的提示層，模型看得到卻沒有人檢查，寫出簡體字或亂碼不會有任何回饋。提示層擋不住的事，就要有機檢層。

How：簡體字樣式由字表組出，字表是單一真實來源，腳本裡不留第二份；字表讀不到就安靜跳過這一項，不中斷整支腳本。亂碼一律用位元組比對（`LC_ALL=C`），不靠語系的字元範圍，因為 `grep -E` 的字元範圍在不同語系下行為不一致。掃描深度沿用 `comment-scope.sh`：檔案已追蹤就只掃 `git diff HEAD` 的新增行，不翻舊帳。二進位檔只認 NUL 位元組判定，不拿「非可列印字元」當判準，那會把所有含中文的檔案誤判成二進位。字表刻意排除繁體也在用的字（后、台、干、只、里、面、制、志），並跳過 `simplified.txt`、`ste100-guard.sh`、`lang-guard.sh` 三份以簡體字與亂碼為討論對象的檔案，避免整支 hook 每次先抓到自己。

Who：`jsc-hooks` 的 hook 實作層，供 `hooks/hooks.json` 與 `tools/wire-cli.sh` 接線給五個 CLI 使用。
 2026-08-27 09:50:03 +08:00
admin 2f74d6473c Merge pull request 'feat/comment-scope-sweep-all-clis' (#27) from feat/comment-scope-sweep-all-clis into develop 
Reviewed-on: #27
 2026-08-27 01:28:48 +00:00
jiantw83 8ede74e9e2 feat(comment-scope): 新增 sweep 模式，掃整個 git 工作區 
What：`hooks/comment-scope.sh` 由兩種模式變三種，新增 `sweep [dir]`：掃整個 git 工作區這次改過的所有檔案，命中就把報告與最多三行證據送到 stderr 並 exit 2，找不到 git 就安靜 exit 0。`prompt` 與無參數單檔掃描兩個模式的判定邏輯一行不動。

Why：只有 claude 有 PostToolUse，拿得到「剛剛寫了哪個檔」。codex、copilot、antigravity、kiro 四個 CLI 都沒有 post-tool 事件，註解範圍檢查在那邊只剩規則提示，違規註解寫進去了不會有人叫。改掃整個工作區的 git diff，時機晚一點，涵蓋範圍一樣。

How：單檔判定抽成 `scan_file()`，兩種掃描模式共用同一份禁止樣式與白名單，不會各自漂移。`sweep` 以 `git rev-parse --show-toplevel` 找庫根，所以在子目錄跑也掃得到整個庫；逐檔報告累積在暫存檔再一次輸出，因為迴圈跑在管線的子行程裡，變數帶不回本 shell。

Who：`jsc-hooks` 的 hook 實作層，供 `tools/wire-cli.sh` 接線給 codex、copilot、antigravity、kiro 四個 CLI 使用。
 2026-08-27 09:15:56 +08:00
admin 8f98e42171 Merge pull request 'feat/comment-scope-hook' (#26) from feat/comment-scope-hook into develop 
Reviewed-on: #26
 2026-08-27 00:56:46 +00:00
jiantw83 f81ceaf145 feat(comment-scope): 新增註解範圍檢查 hook 並接進 claude 的 hooks.json 
What：新增第六支 hook `hooks/comment-scope.sh`，並在 `hooks/hooks.json` 補上兩個接線點：UserPromptSubmit 走 `prompt` 模式、PostToolUse 的 `Write|Edit|MultiEdit` 走掃描模式。

Why：程式碼註解常被寫進工單編號、專案代號、負責人這類文件相關資訊，讓註解變成過期文件。過去只能靠 `/jsc-review:code-review` 事後抓，回饋太慢；把規則搬到寫檔當下，模型可以立刻修正。

How：`prompt` 模式印出規則摘要注入提示。無參數模式從 stdin JSON 取 `file_path`（或環境變數 `JSC_CHANGED_FILE`），只掃 `git diff HEAD` 的新增行，不翻舊帳；markdown、純文字、資料檔與二進位檔一律跳過。命中就把警告與最多三行證據送到 stderr 並以 exit 2 交回模型就地修正，不擋寫入。逃生門為 `JSC_COMMENT_SCOPE=off`。規則正文的唯一來源在 `jsc-review` 的 `references/comment-scope.md`，本存取庫不留副本。

Who：`jsc-hooks` 的 hook 層，服務 `jsc-hooks:hooks-install` 的接線流程與 `jsc-review:code-review` 的註解契約檢查。
 2026-08-26 19:01:36 +08:00
jiantw83 0c83495ba8 fix(version-guard): 把 jsc-ask:ask 與 jsc-gitea:wiki 加進豁免清單 
What：版本守門 hook 的豁免清單新增 jsc-ask:ask 與 jsc-gitea:wiki 兩支技能，並在檔頭註解補上理由。

Why：jsc-cli:deploy 要問使用者 install/update/uninstall，一定會呼叫 jsc-ask:ask；ask 問完又一定寫回 wiki 才算完成。這兩支只要版本落後就被擋下，訊息還指回 /jsc-cli:deploy，deploy 卡在問不出模式那一步，形成死鎖，跟直接擋 deploy 是同一種問題。

How：在 case "$skill" 的豁免比對加上 jsc-ask:ask 與 jsc-gitea:wiki 兩個樣式，維持原本 exit 0 的略過行為；檔頭豁免清單註解同步補上兩條說明，講清楚死鎖成因。

Who：hooks/version-guard.sh 的外掛版本守門功能，影響 jsc-cli:deploy 的部署流程。
 2026-08-26 18:40:11 +08:00
jiantw83 221742486b fix(sdlc-gate): 工作包鎖檔改依索引區分，避免平行工作包互相覆蓋並修正提示文字 2026-08-26 17:59:21 +08:00
jiantw83 b9ad321930 feat(sdlc-gate): 新增工作包 PR 閘門，未結清就擋下別的階段技能 2026-08-25 18:59:29 +08:00
jiantw83andClaude Opus 5 fedcfc8b05 fix(hooks): 補齊稽核缺失並修掉護欄失效 
What：依 jsc-meta:skill-check 的稽核結果修正技能與工具——補上每個步驟的可檢核完成條件、
把留在內文的標準輸入輸出流程下放 tools/、修正查表與退碼路由造成的誤判。

Why：稽核發現這些缺失會讓技能在實際執行時走錯分支或靜默通過。
完成條件缺漏是最常被違反的一項；退碼誤判與查表錯誤則會讓良性狀況被當成失敗。

How：逐項對照 references/guidelines.md 的審核檢查清單修正，新增的工具都有
documented exit codes，並以真實執行驗證每條路徑。

Who：jsc-meta:skill-check 例行稽核（2026-08-25）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 14:58:54 +08:00
jiantw83andClaude Opus 5 2736555a75 feat(version-guard): 新增 report 子指令，一次比對所有 plugin 的本機與已發佈版本 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 13:03:17 +08:00
jiantw83andClaude Opus 5 60b6b8fe00 feat(version-guard): 技能使用前檢查版本，落後遠端就擋下並提示更新 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 11:52:38 +08:00
jiantw83andClaude Opus 5 830ec26f97 feat(sdlc-gate): 階段閘門改為能力標籤程式判定，模型不符即擋下該輪提示 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 16:05:18 +08:00
jiantw83andClaude Fable 5 8a95bd2b47 feat(ste100): 加入送出前自我檢查清單 
What：ste100-guard.sh 追加一行輸出，列出五項送出前自我檢查（簡體字、半形句尾標點、套路句、半形斜線並列、諂媚開場），並附常見例字。
Why：只宣告規則不足以攔下高頻違規，參考 oh-my-pi 的做法，把可自查的具體症狀直接列給模型，命中就先改再送出。
How：在既有規則宣告後追加第二個 echo，維持單行文字、exit 0，不影響任何 CLI 的接線方式。
Who：所有經 UserPromptSubmit hook 或規則檔取得 STE100 規則的 AI CLI 輸出。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-24 11:36:40 +08:00
jiantw83andClaude Fable 5 05b3779118 feat(sdlc-gate): 新增 SDLC 每 session 模型鎖 hook 
What：新增 hooks/sdlc-gate.sh，提供 lock、unlock、check、report 四個子指令；hooks.json 於 UserPromptSubmit 加掛 check。
Why：SDLC 各階段對模型能力有硬性要求，僅靠技能提示無法防止中途切換模型，需要 hook 層強制。
How：以 session 為鍵把「階段 模型」寫入 $JSC_HOME/sessions/{sid}.stage；check 依 stdin JSON、JSC_MODEL、~/.claude/settings.json 順序判定目前模型，別名互含視為相符，不符時注入繁中封鎖提醒；缺資料一律安靜降級、永遠 exit 0。
Who：jsc-sdlc 四個階段技能（plan、analyze、implement、maintain）於閘門通過時上鎖，Claude Code 的 UserPromptSubmit hook 負責攔查。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-24 11:36:05 +08:00
jiantw83andClaude Fable 5 58265e83e8 feat(hooks): ste100-guard 注入文字改為擬人台灣感版（台灣用語、全形標點、去 AI 味） 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 14:13:27 +08:00
jiantw83andClaude Fable 5 b774df23ae feat(hooks): 匯入 jsc-hooks 技能組 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-21 13:08:43 +08:00