plugins/hooks
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
167 Commits 12 Branches 0 Tags
9adb39d21ae3ed6e3d3641fd4f3958140b16104a
Commit Graph
32 Commits
Author SHA1 Message Date
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 1d86359767 fix(接線盤點): status 列舉每一個接線點，不再只挑四支 
README 早就寫明「每個接線點印一行 item」，程式卻只列 comment-scope、
lang-guard、restart-gate 與 write-guard 三種模式，共六項。sdlc-gate 的三個
接線點、session-timer 的兩個、skill-usage 與 version-guard 都沒列出來。

漏列的後果不是少幾行字。reason 那行寫的是「全部九支 hook」，拿這份輸出
驗收接線的人會把沒列到的當成沒接——模型能力鎖就是這樣被誤判成沒接線的。
體檢技能也讀這支的輸出，同樣看不到那四支。

一支腳本接在多個接線點時，每個點各自列一項。只驗腳本名的話，「腳本在、
某個接線點沒接」會被算成完整接線，那正是最難查的一種。
 2026-09-02 14:57:04 +08:00
jiantw83 096a85e638 feat(link): 連結一律寫成 [文字](絕對網址)，寫入前先驗證連得到 
取消 [[頁名]] 與 [[顯示文字|頁名]] 兩種同 wiki 寫法，不再分「同存取庫」與
「跨存取庫」兩條規則。那種寫法只在自己那個 wiki 內解析，寫錯不報錯，畫面上
看起來像普通文字或死連結，巡不到也修不了。

連結寫進頁面前先過 jsc-gitea 的 link-check.sh，結束碼 0 才寫。驗證一律走 API，
不看網頁狀態碼：私有存取庫的網頁網址對未登入請求一律回 404，拿狀態碼判會把
好連結判成壞的。認證失敗回 7，與死連結的 1 分開，免得金鑰一過期就把還在的頁
整批判死。
 2026-09-02 14:27:18 +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 fbf0aec9f7 fix(smoke): 擋人斷言改依各 CLI 的形態判定 
What：
- wire-cli.sh 的 smoke 區段新增四個共用小函式：smoke_deny_rc 給結束碼、smoke_deny_mark 給擋人標記、smoke_deny_ok 做判定、smoke_deny_desc 產生失敗訊息。
- smoke_rs_case 與 smoke_vg_case 的判定改走 smoke_deny_ok，五個呼叫點的預期值由結束碼 2 改成字面值 deny。
- 三份 manifest 的版本一起提升，由 sync-skill-manifest.sh 同步。

Why：
- 兩個函式把「擋下」寫死成結束碼 2，但擋下的形態是由 deny.sh 依 CLI 決定的。claude、codex、copilot 與認不得的代號走 stderr 加結束碼 2；antigravity 改印一行 stdout 的 deny JSON，kiro 只能注入警告，這兩支的結束碼都固定 0。
- 結果是這兩支的 smoke 各有五條判定失敗，回報成執行期錯誤。但擋人訊息其實都正確印出來了，配套的訊息斷言也全部通過，壞的只有結束碼那一項比對——是斷言認錯形態，不是 hook 失效。
- 不能改成一律放寬到 0。那兩支上放行也是 0，放寬之後「該擋沒擋」與「正確擋下」完全同形，這道斷言等於作廢。

How：
- 形態表在 smoke 這側鏡射一份，事實來源仍是 deny.sh 的 case。表只有一份，改一支不會忘了另一支。
- 判定同時比結束碼與擋人標記；預期放行的案例反過來要求標記不得出現，所以「該擋沒擋」與「不該擋卻擋了」兩個方向都守得住。
- 走 stderr 的三支標記為空字串，判定行為與原本完全相同，不產生回歸。
- 斷言條數不增不減，兩個預期條數常數都不必動。
- 反向測試確認斷言仍然有效：拿掉 deny.sh 裡 antigravity 的 deny JSON 輸出，做出該擋卻靜靜放行的情境，smoke 正確判失敗。結束碼相同，靠擋人標記才分得出來。

Who：
接線後的冒煙測試在 antigravity 與 kiro 上判定失敗，追出來的是斷言本身的缺陷。
 2026-09-01 11:48:13 +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
jiantw83andClaude Opus 5 15f7dcc5fb test(smoke): 接線腳本冒煙補上相依版本檢查的十三條判定斷言 
接線腳本的 smoke 多一個沙箱，逐條跑相依版本檢查的判定路徑並比對結束碼：
相依落後的擋人與訊息內容、相依相等與超前的放行、豁免技能在相依落後時
照樣放行、同一個 plugin 底下非豁免技能照樣被擋、四種 fail-open、
逃生門蓋過相依落後，另加一條回歸——多行縮排的 manifest，jsc.requires
的最後一個鍵也要解得到。

原本的 hook 模式只驗那支腳本跑得完，相依版本這一段一條判定路徑都沒走到。
新的擋人情況判錯方向，不是把每一次技能呼叫鎖死，就是整道護欄形同虛設，
沒有斷言就看不出來。多行縮排是真實 manifest 的樣子，解析漏掉最後一個鍵
會讓落後的相依靜靜被放行，那一條非釘住不可。

沙箱自備一份暫時的 HOME，註冊檔路徑由 $HOME 決定，不覆寫就會讀到使用者
真正的安裝清單。假的 installed_plugins.json 與各 plugin 的 manifest 都放進
那份 HOME，註冊欄位故意寫成很新的版本、installPath 底下的 manifest 寫舊版，
把「只認 installPath 底下那份檔案」的規則一起釘住。GITEA_HOST 一律清空，
放行的案例才不會往下走到遠端比對真的連網。擋人的兩條另外比訊息字串，
比的是同一次執行留下的輸出。新增計數器 smoke_n_vg 與預期值
SMOKE_EXPECT_VG，一併納入總數、逐類比對訊息與結果摘要，判定路徑增減時
只改腳本裡的預期值。

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

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-31 13:41:25 +08:00
jiantw83andClaude Opus 5 3ae6dba13f fix(smoke): 模型來源判定補上計數器，冒煙預期條數對回實際路徑 
重定基底到 develop 後，冒煙測試併入了 sdlc-gate.sh 取模型代號的四條來源
判定，但那支輸出函式沒有自己的計數器，四個預期值也沒跟著加。結果是實際
印出六十四條結果行、四類計數器只算到六十條，收尾的自我斷言當場判定不符，
smoke 一律以 exit 4 收場。

補上第五個計數器 smoke_n_model 與對應的 SMOKE_EXPECT_MODEL，計數放在該
函式開頭，連建不出暫存目錄那條也算得到；總數、逐類比對訊息與結果摘要一併
納入模型來源這一類。五支 CLI 的 smoke 都回 status=ok，行數與各類條數三邊
一致。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-31 11:26:11 +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
admin ca68de8540 Merge pull request 'fix(codex-hooks): 避免 Claude manifest 在 Codex 變成空路徑' (#50) from fix/codex-claude-hook-manifest into develop 
Reviewed-on: #50
 2026-08-28 10:09:31 +00:00
jiantw83 955a36adb9 fix(codex-hooks): 避免 Claude manifest 在 Codex 變成空路徑 2026-08-28 18:07:20 +08:00
Jeffery a0a15b6ce5 fix(report-error): 寫入前先確認 2026-08-28 17:58:52 +08:00
jiantw83 83f6bdf21c fix(model-gate): 支援 Codex 可驗證模型來源 2026-08-28 16:45:58 +08:00
jiantw83 49101fefdb fix(wire-cli): purge 容忍標記行空白 2026-08-28 16:03:25 +08:00
jiantw83 4e23e49159 fix(hooks-install): 使用穩定路徑寫入 hook 接線 2026-08-28 11:22:08 +08:00
jiantw83 9586e63005 test(restart-gate): 冒煙測試加驗一支 CLI 一份的範圍 
What：`tools/wire-cli.sh` 的 `smoke` 重啟閘門段從 9 條情境擴為 16 條，新增 `smoke_rs_file()` 比對狀態檔在不在。新增的情境是：只有別支 CLI 有狀態檔時放行、`require` 寫出的是當前 CLI 那一份、新工作階段開始後只清掉自己那一份、清除不動別支那一份、清除後放行、舊格式單一狀態檔存在時擋下、`clear` 一併刪掉舊檔、舊檔清除後放行。原有的豁免技能、逃生門與取不到技能名三類情境照舊，情境名稱從「狀態檔存在」改寫為「當前 CLI 那份存在」。檔頭的判定路徑清單同步改寫。

Why：只比對結束碼看不出「一支 CLI 一份」有沒有真的成立——別支那一份要留著、自己那一份要刪掉，兩件事都反映在檔案在不在，不反映在結束碼。舊版的冒煙只驗得到「狀態檔不存在」與「狀態檔存在」兩條，正好漏掉這次修掉的兩個缺陷所在的範圍：並行部署的覆寫與清除的全域解除，兩者在單一檔案的年代都跑得出 exit 0 與 exit 2 的正確值。

How：情境沿用暫時的 `$JSC_HOME`，不動使用者真正的狀態目錄——冒煙測試不該把別人的閘門拆掉。別支 CLI 的代號取 `smoke-other` 這個不在五支之列的固定值，才不會跟這一輪的 `$cli` 撞在一起。`smoke_rs_file()` 只比 `exist` 與 `absent` 兩種預期，失敗訊息直接講明「一支 CLI 一份的範圍壞了」，看訊息就知道是範圍出錯，不是腳本跑不動。舊檔那兩條情境走 `session-timer.sh restart` 觸發清除，跟真實路徑一致。

Who：`jsc-hooks` 接線工具的冒煙測試，覆蓋部署後重啟閘門的判定與清除範圍。
 2026-08-27 18:49:58 +08:00
jiantw83 e370729720 feat(wire-cli): 接線腳本納入部署後重啟閘門，七支改八支 
What：`tools/wire-cli.sh` 四處增修。`smoke` 加跑 `restart-gate.sh`，另外自備一份暫時的 `$JSC_HOME`，把八條判定路徑（狀態檔不存在、狀態檔存在且技能為 `jsc-sdlc:implement`、四支豁免技能各一條、逃生門、取不到技能名）各跑一次並比對結束碼，再驗一次清除機制真的清得掉；claude 的接線驗證與 `status` 盤點各加一個 `restart-gate` 檢查點；codex、copilot、antigravity、kiro 四支的 degraded 說法補上「部署後重啟閘門也接不上」；檔頭與各處「七支」一律改為「八支」。

Why：新的 hook 接進 `hooks.json` 只代表宣告在檔案裡。接線驗證不點名就漏得掉——`comment-scope.sh` 與 `lang-guard.sh` 當初就是為同一個原因各列一項。冒煙測試也一樣：不自備狀態檔，只走得到「狀態檔不存在」與「取不到技能名」兩條捷徑，擋人與豁免那幾條一次都跑不到，判定寫了卻沒驗等於沒寫。四個 CLI 的降級說法不補，回報就會暗示每個 CLI 都擋得下來。

How：驗的是判定結果本身，不只是腳本跑得完——每一條路徑都給定預期結束碼，對不上就計入失敗並印出前 200 字的輸出。狀態檔放在暫時目錄，冒煙測試不該把使用者真正的 `$JSC_HOME/restart-required` 拆掉。清除機制那一段刻意走 `session-timer.sh start` 這條真實路徑，不直接呼叫 `clear`：要驗的是「新工作階段會不會清」，不是「`clear` 這個子命令能不能刪檔」。每次呼叫都接 `</dev/null`：hook 模式會讀標準輸入，管線沒人關閉時整支會卡死。建不出暫存目錄也算失敗，不能靜悄悄跳過。四支非 claude 的 CLI 除了 degraded 一句，另外逐支印一行講明後果：一次技能呼叫都擋不下來，狀態檔照樣寫、下次工作階段開始照樣清，只是中間沒有判定點，重啟要靠 `/jsc-cli:deploy` 收尾的提示自己動手。

Who：`jsc-hooks:hooks-install` 的接線、冒煙與盤點三個子命令。
 2026-08-27 16:34:17 +08:00
jiantw83 3b6dd1b901 test(wire-cli): 冒煙測試補驗工作包歸屬的四條判定路徑 
What：`tools/wire-cli.sh` 的 `smoke` 新增一段，用一份暫時的 `$JSC_HOME` 狀態檔把「狀態檔不存在」「PR 屬於領取中的工作包」「PR 屬於別的工作包」「逃生門 `JSC_WP_GATE=off`」四種情境各跑一次，逐一比對結束碼；收尾那句 `status=ok` 的說明也跟著補上這一段。

Why：原本兩支 `wp-check` 冒煙都把技能名清空，只走得到「沒有未結清 PR」與「取不到技能名」兩條捷徑，歸屬比對整段一次都沒跑到。判定寫了卻沒驗，等於沒寫。

How：驗的是判定結果本身，不只是腳本跑得完——每一種情境都給定預期結束碼，對不上就計入失敗並印出前 200 字的輸出。狀態檔放在暫時目錄，冒煙測試不該在使用者真正的 `$JSC_HOME/wp/` 留下痕跡。每次呼叫都接 `</dev/null`：`wp-check` 會讀標準輸入，管線沒人關閉時整支會卡死。建不出暫存目錄也算失敗，不能靜悄悄跳過。

Who：`jsc-hooks:hooks-install` 接線後跑的冒煙測試，以及改動 `sdlc-gate.sh` 歸屬判定的人。
 2026-08-27 11:20:28 +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 0bebdef46f feat(wire-cli): 把 comment-scope sweep 接到其餘四個 CLI 
What：`tools/wire-cli.sh` 把 `comment-scope.sh sweep` 接進 codex 的 `config.toml` 根層 `notify` 與 kiro 的 `.kiro/hooks/jsc-hooks.json` 的 `userPromptSubmit`；`tools/jsc-wrap.sh` 在 CLI 結束後、回傳結束碼之前跑一次 sweep，涵蓋 copilot、antigravity 與同樣走包裝器的 codex。`smoke` 多跑一輪 sweep，`status` 多盤點 codex 的 `notify-sweep` 與 kiro 的 `comment-scope-sweep` 兩項。

Why：這四個 CLI 沒有 post-tool hook，接不到逐檔即時掃描，先前只寫得進規則提示，違規註解寫進去沒有人叫。接上 sweep 之後五個 CLI 都掃得到，差別只剩回饋速度。`smoke` 與 `status` 不同步補上，就驗不出來接線少了哪一支。

How：codex 的 notify 串成 `start; mark; sweep`，位置仍由 `replace_block_toml` 保證落在第一個表頭之前，寫入後除了既有的根層鍵檢查，再 grep 一次確認 sweep 真的串進那一行。kiro 的 `run` 尾端接上 sweep，`prompt` 與 `sweep` 各驗一個 grep，只驗腳本名會漏掉少接的那一個。`jsc-wrap.sh` 的 sweep 加 `|| true` 接住 exit 2，包裝器一律原樣回傳 CLI 自己的結束碼——包裝器改掉結束碼，呼叫端的 `cmd && next` 就會誤判。`smoke` 的 exit 2 白名單由「無參數模式」放寬到「所有掃描模式」，因為 sweep 在髒工作區本來就會回 2，那是 hook 正常工作，不是 hook 壞掉。四個 CLI 的 `reason` 與 `[jsc]` 說明改寫成各自真正的掃描時機。

Who：`jsc-hooks` 的接線工具層，供 `jsc-hooks:hooks-install` 與 `jsc-hooks:repair` 呼叫，最終服務 codex、copilot、antigravity、kiro 的使用者。
 2026-08-27 09:16:15 +08:00
jiantw83 e2232d26f1 feat(wire-cli): 接線腳本納入註解範圍 hook，五支改六支 
What：`tools/wire-cli.sh` 新增 `comment_scope_text()`、`rules_text()` 與 `has_comment_scope()` 三個函式，把 `comment-scope.sh` 的 `prompt` 模式接進 codex、copilot、antigravity 的規則檔與 kiro 的 hook JSON，`smoke` 與 `status` 兩個子命令也補上這支 hook，全腳本由五支 hook 改口徑為六支。

Why：`hooks/hooks.json` 只服務 claude；其他四個 CLI 要靠這支腳本接線，不改就完全接不到新規則。`smoke` 與 `status` 不同步補上，接線成功與否也驗不出來。

How：`comment_scope_text()` 直接取 `comment-scope.sh prompt` 的實際輸出當規則文字，不在本存取庫留規則清單副本；`rules_text()` 把 STE100 與註解範圍併進同一個 `<!-- jsc-hooks -->` 標記段落，重跑等同先移除再重裝；`has_comment_scope()` 供 `status` 判斷標記段落在不在。`smoke` 把 `comment-scope.sh` 無參數模式的 exit 2 視為設計行為，與 `sdlc-gate.sh check` 同列例外。

Who：`jsc-hooks` 的接線工具層，供 `jsc-hooks:hooks-install` 與 `jsc-hooks:repair` 呼叫。
 2026-08-26 19:01:36 +08:00
jiantw83 f1bcdc3d72 feat(wire-cli): 新增唯讀的接線盤點子命令 
What: wire-cli.sh 新增 status 子命令，只讀設定檔判斷 jsc 標記段落在不在，不寫檔也不執行 hook。每個接線點印一行 item，以 status=wired、degraded、unwired、skipped 回報。
Why: 體檢類技能要問「hook 接線在不在」，但既有三個子命令都會動到環境：不帶子命令會重新接線、purge 會刪掉、smoke 會真的執行 hook。體檢不該有副作用。
How: 沿用底下接線區塊的同一組檔案位置與標記字串，共用 has_block、toml_root_key、json_top_key 三個判讀函式。codex 的 notify 另外單獨檢查是否落在根層，標記在、鍵被歸進表裡時 codex 讀不到，等同沒接。
Who: 供 jsc-cli:doctor 呼叫的接線檢查。
 2026-08-26 10:44:47 +08:00
jiantw83 b9ad321930 feat(sdlc-gate): 新增工作包 PR 閘門，未結清就擋下別的階段技能 2026-08-25 18:59:29 +08:00
jiantw83 b45a98af87 feat(hooks-install): 安裝改為先清空所有 hook 再接線並驗執行期 2026-08-25 18:18:10 +08:00
jiantw83 c68292acbc feat(hooks): 自動接手失敗接線與修復流程 2026-08-25 16:33:38 +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
jiantw83 69eee91f27 feat(hooks-install): 將 hooks-install 的 CLI 佈線邏輯抽離為腳本 
為什麼：
`skills/hooks-install/SKILL.md` 原本直接內嵌各 CLI（codex／copilot／antigravity／kiro）的詳細佈線步驟，包含逐步設定檔修改、wrapper alias 安裝、以及 `<!-- jsc-hooks -->` 標記區塊的冪等替換邏輯，違反 jsc-meta:skill-check 稽核準則中「確定性程序邏輯應由腳本執行，不應留給子代理每次自行解讀 prose」的要求。

做了什麼：
新增腳本 `tools/wire-cli.sh {cli}`，將原本內嵌於 SKILL.md 的佈線邏輯全數抽出，並支援冪等執行（標記區塊替換、可安全重跑），輸出機器可讀的 `status=wired|degraded|skipped reason=...` 首行訊息與對應結束碼（0=wired、1=degraded、2=bad usage、3=skipped）。改寫 `skills/hooks-install/SKILL.md`，改為依偵測到的 CLI 呼叫此腳本，並讀取其 status／結束碼判斷結果，不再自行內含佈線步驟。同步更新 `README.md`：在工具表新增 `tools/wire-cli.sh` 說明列，並改寫 hooks-install skill 的描述段落，反映新的腳本驅動流程與 `status=` 回報慣例。三份外掛清單 `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 版本號自 0.0.3 升級為 0.0.4，對應此行為變更。

怎麼做：
建立獨立腳本承載原本的 CLI 佈線程序邏輯，改造 SKILL.md 為呼叫腳本並解讀其標準化輸出，同步更新文件與版本號。

影響範圍：
`skills/hooks-install/SKILL.md`、`README.md`、`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json`、新增檔案 `tools/wire-cli.sh`；影響 hooks-install skill 的執行流程與所有安裝 jsc-hooks 外掛的 CLI 佈線行為。
 2026-08-24 14:47:46 +08:00
jiantw83andClaude Fable 5 bb91cc2832 feat(wrapper): 新增無 Hook CLI 的包裝啟動器與日誌回填 
What：新增 tools/jsc-wrap.sh 包裝啟動器與 tools/scan-logs.sh 離線日誌回填腳本。
Why：copilot、antigravity 沒有 hook 系統，計時與技能用量原本完全缺漏，需要 hook 之外的落地方案。
How：jsc-wrap.sh 匯出 JSC_CLI 與 JSC_SESSION_ID，啟動前後各呼叫一次 session-timer.sh，結束時自動執行 scan-logs.sh 並原樣傳遞子行程退出碼；scan-logs.sh 解析 copilot、antigravity、codex 的原生日誌，把技能用量與階段界線補進 $JSC_HOME，重掃不產生重複記錄。
Who：無 hook 系統的 CLI（copilot、antigravity）與僅有 notify 的 codex，資料供 jsc-log:worklog 與 jsc-log:stats 使用。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-24 11:36:24 +08:00