plugins/hooks
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
222 Commits 12 Branches 0 Tags
master
Commit Graph
222 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
admin bab45c0656 Merge pull request '釋出：逐支點名抽自接線那一邊，內建項提醒收成一行' (#94) from develop into master 
Reviewed-on: #94
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-07 05:45:01 +00:00
admin e0de77230f Merge pull request '內建項收成一行，不逐筆吐' (#93) from fix/collapse-builtin-reminders into develop 
Reviewed-on: #93
 2026-09-07 05:42:26 +00: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
admin 28fd6664b6 Merge pull request '釋出：逐支點名改成從接線那一邊抽名單' (#92) from develop into master 
Reviewed-on: #92
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-07 04:46:57 +00:00
admin 7a569f4e46 Merge pull request '逐支點名改成從接線那一邊抽名單，五支 CLI 都驗得到' (#91) from fix/per-hook-inventory-every-cli into develop 
Reviewed-on: #91
 2026-09-07 04:43:49 +00:00
jiantw83andClaude Opus 5 f83e1c542f fix(wire-cli): 逐支點名改成從接線那一邊抽名單，五支 CLI 都驗得到 
第十支 hook 上線之後實測發現：claude 與 kiro 的盤點點名得出它，codex、
copilot、antigravity 三段的盤點卻各自只驗自己寫死的那兩支。那三支的接線
盤點看不出第十支在不在，而 smoke 那一行還自稱「十支 hook」——兩句話都是
真的，範圍不同，讀的人分不出來。

根因是「接線寫了哪幾支」與「盤點驗了哪幾支」本來是兩份手寫清單。加一支
hook 要記得回來改第二個地方，而漏改的那一天不會有任何東西叫。

改成從接線那一邊實際會寫出去的內容抽名字，兩邊只留一份清單：

- codex 讀的是從 hooks/hooks.json 推導出來的複本，所以名單取自來源那一份，
  十支全驗；推導漏掉一支時，盤點說得出漏了哪一支。
- copilot 與 antigravity 只接得上兩道閘門，名單取自各自的條目產生函式。
- copilot 原本一支 hook 都沒點名，只驗「hooks 鍵在」——鍵在而某一支條目掉了
  照樣回 present，那正是這一整支腳本一直在防的形態。

codex 接線後的驗證也一起改：原本只確認那兩道閘門有接上，現在逐支對照來源。
推導是整份複製再改 matcher，漏掉任何一支都算推導壞了。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 12:39:07 +08:00
admin d5c4f924ee Merge pull request '釋出：工作階段開始時帶出助理的未讀提醒' (#90) from develop into master 
Reviewed-on: #90
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-07 04:17:16 +00:00
admin 6948593316 Merge pull request '工作階段開始時把助理的未讀提醒帶到前景' (#89) from feat/session-start-reminders into develop 
Reviewed-on: #89
 2026-09-07 04:14:13 +00: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
admin e77c0afb4b Merge pull request '釋出：兩支技能補收尾事件，異常目錄頁改成 H2 區塊條列' (#88) from develop into master 
Reviewed-on: #88
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-07 01:25:40 +00:00
admin 248bc90fc2 Merge pull request '異常目錄頁改成 H2 區塊條列，寫入語意委派共用工具' (#79) from feat/contents-list/main into develop 
Reviewed-on: #79
 2026-09-07 01:22:56 +00:00
jiantw83andClaude Opus 5 5493539046 Merge develop 
三份 manifest 取 develop 的版號再往上升一版。

行為清單那一節第二次解：另一張同樣動這一節的先合併了，所以基底換過，重新
比對一次。這一次 develop 那一邊多了收尾事件的說明，分支這一邊還是「目錄頁
從表格列改成大標題區塊」。逐列用差異區間比對過，兩邊在共同基底上動到的位置
仍然完全不重疊，所以照基底的座標把兩組改動一起套回去。

合完之後三方的內容都在：這張的區塊語意、另一張的收尾事件、develop 的根目錄
解析。技能本文這一次自動合併就過了，沒有衝突。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 09:16:22 +08:00
admin b7f9f1293e Merge pull request 'jsc-hooks 兩支技能補上收尾的 skill-end 事件' (#78) from feat/hooks-skill-end into develop 
Reviewed-on: #78
 2026-09-07 01:14:07 +00:00
jiantw83andClaude Opus 5 3f0e5df673 chore(plugin): 版號讓到 0.4.7 
0.4.6 讓給另一張同時要合併的。兩張都動到行為清單同一節，順序定下來之後
這一張排第二，版號跟著讓開。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 09:11:21 +08:00
jiantw83andClaude Opus 5 7f6e0d9299 Merge develop 
三份 manifest 取 develop 的版號再往上升一版：分支停在一個比 develop 舊的版號。

行為清單那一節四列兩邊都改過，但改的是不同層面：分支改「目錄頁怎麼寫」——索引
從表格列變成一個報告一個大標題區塊、寫入語意委派給共用工具；develop 改「根目錄
怎麼解」——前置步驟解出兩條字面絕對路徑再拿去叫工具。逐列用差異區間比對過，
兩邊在共同基底上動到的位置完全不重疊，所以照基底的座標把兩組改動一起套回去，
不是取其中一邊。

技能本文那一段同理：分支把整段改寫成區塊語意，develop 只在指令路徑前面補了
根目錄前綴。取分支那一版再補上前綴。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 09:10:57 +08:00
jiantw83andClaude Opus 5 f1255038f6 Merge develop 
三份 manifest 取 develop 的版號再往上升一版：分支停在一個比 develop 舊的版號，
取它等於把版號往回退。

行為清單兩支技能的節整節取 develop 那一版，再把分支新增的收尾說明逐段原文
接回去。develop 那一邊在這條分支開出去之後改寫了根目錄解析與外部呼叫兩欄，
分支那一邊只在關鍵步驟與可驗證跡象兩欄的尾端附加收尾事件的說明——兩件事互不
相干，取任一邊都會弄丟另一邊。

解這一段時弄壞過一次：第一版拿字元級差異把新增片段逐塊疊回去，中文被切碎重組，
「決定結局的那支工具的結束碼」變成「決定結局的那工具的結束碼」，關鍵步驟那一
整列還整列消失。行為清單檢核抓到表格只剩四列才發現。改成整節從 develop 重取、
只接分支相對它自己基底的那一段尾端附加，切點在共同前綴的盡頭，不切中文。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-07 09:08:36 +08:00
admin c16d30a0cf Merge pull request '釋出：status 加 --verdict，把狀態與成敗兩種語意分開' (#87) from develop into master 
Reviewed-on: #87
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-04 11:17:03 +00:00
admin 27a3865e87 Merge pull request 'status 加 --verdict，把狀態與成敗兩種語意分開' (#86) from feat/wire-cli-status-verdict-flag into develop 
Reviewed-on: #86
 2026-09-04 10:09:51 +00:00
jiantw83andClaude Opus 5 d6f1e0e7ba feat(接線): status 加 --verdict，把狀態與成敗兩種語意分開 
status 的結束碼帶的是狀態：0 是接好、1 是接好但這支 CLI 做不到、5 是有東西
沒接。那是給人看的三分法，本身沒有錯。

問題出在被當成檢查用。助理的內建檢查項照結束碼判成敗，非零就是那一筆失敗、
失敗次數加一。於是有先天限制的那一支 CLI 每一輪都讓那一筆失敗一次，一天 96
次，而沒有人修得動——那支 CLI 擋不下技能叫用是它的架構限制，不是接線缺漏，
16 個接線項目全部就位。

那個計數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。被一個修不動
的數字填滿，就等於用假的壞掉把真的壞掉蓋掉。

修在這一邊而不是修在讀的那一邊：狀態與成敗是兩種語意，混在同一個通道上才是
根因。這個旗標把成敗那一種單獨拉出來，status 保持原樣給人看。

--verdict 之下輸出一字不變——degraded 那一行照印，人看得到——只有結束碼換一套
語意：該接的都接了就回 0，先天限制不算；真的缺項目照樣回 5。

只有 status 收這個旗標，別的子命令帶了回 2：另外三個子命令的結束碼本來就是
成敗語意，多一個旗標只會讓人以為它們也有兩套。

實測：五支 CLI 兩種模式各跑一次，只有帶先天限制那一支從 1 變 0；輸出逐字
相同；暫時拿掉一個接線項目之後 --verdict 回 5，還原後回 0；旗標的三條錯誤
路徑都回 2。

三份 manifest 版號 0.4.4 升到 0.4.5。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-04 18:04:51 +08:00
admin 03451f49f9 Merge pull request '釋出共用函式庫的收尾修正至 master，版本 0.4.3 升到 0.4.4' (#85) from develop into master 
Reviewed-on: #85
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-03 05:37:26 +00:00
admin 8e37ab3191 Merge pull request '共用函式庫補上 stdin JSON 的載入期預設值，四條收尾路徑不再吐未設定訊息' (#84) from fix/stdin-json-default-in-shared-lib into develop 
Reviewed-on: #84
 2026-09-03 05:35:21 +00:00
jiantw83 1684e5636d chore(plugin): 三份 manifest 升版至 0.4.4 
共用函式庫的收尾修正要靠版號才傳得到機器端。

三份 manifest 由 sync-skill-manifest.sh 同步，只動版本欄位。
 2026-09-03 13:06:35 +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
admin 76288785ca Merge pull request '釋出跨外掛路徑的實體解析修正至 master，版本 0.4.2 升到 0.4.3' (#83) from develop into master 
Reviewed-on: #83
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-03 04:41:52 +00:00
admin 2704a7fa8f Merge pull request '跨外掛路徑改實體解析，修好失效的版本閘門，並讓接線腳本不再可能把連結指向自己' (#82) from fix/physical-path-resolution-across-plugins into develop 
Reviewed-on: #82
 2026-09-03 04:40:20 +00:00
jiantw83 e5a9b05164 chore(plugin): 三份 manifest 升版至 0.4.3 
路徑解析的修正要靠版號才傳得到機器端，版本前置檢查才會要求更新。

三份 manifest 由 sync-skill-manifest.sh 同步，只動版本欄位。
 2026-09-03 12:19:27 +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
admin 7b17c5e4f8 Merge pull request '釋出 hook 接線的路徑修正與本機事件流至 master，版本 0.3.8 升到 0.4.2' (#81) from develop into master 
Reviewed-on: #81
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-03 03:17:13 +00:00
admin f0fd92eb33 Merge pull request 'hooks-install 的腳本呼叫改用執行期解出的字面絕對路徑，讓無人看管的輪次不再卡在第一支腳本' (#80) from fix/literal-absolute-paths-for-hooks-wiring into develop 
Reviewed-on: #80
 2026-09-03 02:52:04 +00:00
jiantw83 70526244c7 chore(plugin): 三份 manifest 升版至 0.4.2 
hooks-install 的路徑處理與行為清單都變了，版號要帶得出這批變更，版本前置檢查才會要求機器端更新。

三份 manifest 由 sync-skill-manifest.sh 同步，只動版本欄位，內容一致。

受影響的是靠版號判斷要不要更新的每一台機器。
 2026-09-03 10:32:22 +08:00
jiantw83 221dca70e6 fix(behaviors): repair 的可驗證跡象補上收尾事件 
行為清單檢查拿 HEAD 的內容跑就過不了，它點名 repair 那一列的可驗證跡象沒寫到收尾的 skill-end 事件。這是既有欠帳，跟這一批的路徑處理沒有關係，所以單獨一筆，之後要回退哪一邊都不會牽連另一邊。

補上的內容照準則寫：收尾在本機事件流留下這一輪的 skill-end，status 從 ok、blocked、failed、degraded、aborted 五個裡取一個，中途停下的那幾輪也照寫——只有 start 沒有配對的 end，會被讀成中斷。

受影響的是驗收 repair 有沒有跑完的人，還有把行為清單檢查掛在流程裡的每一個存放庫。
 2026-09-03 10:32:22 +08:00
jiantw83 358c30c7b8 fix(hooks-install): 腳本呼叫一律寫成執行期解出的字面絕對路徑 
無人看管的輪次會在第一支腳本就被擋下，整輪還沒開始就結束。2026-09-02 到 09-03 以非互動模式比照排程環境實測七種寫法，結論很乾淨：權限層比對的是還沒展開的字面字串，帶變數或帶波浪號的路徑一律解不出來，一律要人核准；路徑中段的萬用字元也不匹配，所以帶版本號的快取路徑放不進允許清單。連 readlink、ls 這種只讀指令都要有自己的規則。放寬允許清單救不了這件事，只有把路徑寫成字面絕對值才跑得動。

技能因此多兩節。路徑守則寫明每一次腳本呼叫都要是字面絕對路徑，並說清楚為什麼不能為了可攜性換回變數寫法——變數寫法買不到可攜性，只買到一輪還沒跑到第一階段就死掉。前置步驟把可攜性挪到執行期：兩個根目錄各以 readlink 解一次，只在這裡解，之後不重解，也不為此新增腳本。主代理人解完把兩條字面路徑交給每一個 sub agent，sub agent 自己不解。技能內九處腳本呼叫都改成由這兩個根目錄開頭。

兩條 readlink 各自在同一步用 [ -d ] 查過印出來的目錄真的存在。JSC_HOME 沒設時第一條會印出 /current、結束碼 0，非空又是絕對路徑，只查前三項擋不下來。

解兩個根目錄不是重複。連結農場根目錄給跨 domain 呼叫用；jsc-hooks 的實體根目錄只給接線腳本用，而這一條的理由與權限無關：那支腳本從自身位置推出自己的根目錄，又會改寫自己正踩著的那條連結。走連結跑下去，連結會被指向自己，全機器的 hook 一起失效——這件事實際發生過。

存放庫自帶的 hook 設定檔刻意保留變數寫法，技能文件也把這個例外寫明。那是檔案內容，由 hook 自己的 shell 在執行當下展開，不經過權限層，也不是誰在提示裡打出來的路徑；改成實體路徑等於把某一台機器的路徑寫死進要發佈的檔案。

行為清單的 hooks-install 四列跟著校準。

受影響的是每一個跑 hooks-install 的人，最直接的是排程觸發、沒有人在旁邊核准的那些輪次。
 2026-09-03 10:32:22 +08:00
jiantw83 bd1a705ea8 chore(plugin 版本): 三份 manifest 升版至 0.4.2 
What：
三份 plugin manifest 的版號由 0.4.1 同步升到 0.4.2，README 的技能目錄確認沒有新增或移除小節。

Why：
版本閘門比對相依版本時看的是 manifest 版號。改了內容卻不升版，安裝端拿到新檔案卻還是舊版判定，落後的一方擋不下來。

How：
以 jsc-meta 的技能清單同步工具一次改三份，結束碼 0，避免三份版號各自手改而對不起來。

Who：
安裝或更新 jsc 技能組的操作者。
 2026-09-02 18:02:20 +08:00
jiantw83 02caedf91e feat(異常目錄頁): 索引改成 H2 區塊條列並委派共用工具 
What：
異常目錄頁的版面從 markdown 表格改成一筆異常一個 H2 區塊，標題就是那一筆的異常頁頁名，時間、頁名、存取庫名稱、觸發 hook、退出碼、摘要六個欄位改成標題底下的一層條列，頁上不再留任何表格。失敗回報腳本不再自己讀回舊頁、附加新列、整頁寫回，改成只組出自己那一個區塊，交給 jsc-gitea 的目錄頁工具做讀回、比對與整頁寫回。範本、技能敘述、行為清單與說明文件一併對齊。

Why：
目錄頁有十幾份，各自在自己的腳本裡寫一套「讀得回舊內容才寫」的判斷，錯一次就少一筆紀錄，而且每一頁長出來的樣子都不一樣。版面與寫入語意收回一份正本之後，改一次全部跟著改。表格欄位遇到換行或半形豎線還會被切斷，條列沒有這個問題。

How：
失敗回報腳本移除目錄專用存取庫的解析與整頁組裝，改為組出區塊檔之後呼叫共用工具的 upsert，並依它的結束碼分流：3 是目錄頁的存取庫沒設定，找不到那支腳本也走同一條，兩者都只寫異常頁、跳過目錄頁、仍回 0；其餘非零一律以 4 回報。摘要不再替換半形豎線，改成把換行併成一行。傳進去的欄位序號 2 指舊表格版持有內容頁連結的那一欄，只供舊頁自動轉條列時取標題用。

Who：
使用 jsc-hooks 失敗回報流程的操作者，以及所有讀異常目錄頁追問題的人。
 2026-09-02 18:01:33 +08:00
jiantw83 44d1d00c0c chore(plugin 版本): 三份 manifest 升版至 0.4.2 2026-09-02 16:05:54 +08:00
jiantw83 4afb282c78 feat(狀態回報): 兩支技能的收尾寫一筆 skill-end 
hook 在原理上看不到技能的成敗：它接在技能工具呼叫上，而實際工作發生在
之後的模型輪次。start 由技能用量 hook 順手發，end 只能由技能自己寫。
有 start 沒有配對的 end，就是那一輪中止了。
 2026-09-02 16:05:54 +08:00
admin 9adb39d21a Merge pull request '技能與 hook 的執行結果寫進本機事件流，供助理排空' (#77) from feat/status-event-stream into develop 
Reviewed-on: #77
 2026-09-02 07:48:47 +00:00
jiantw83 106922d530 chore(plugin 版本): 三份 manifest 升版至 0.4.1 2026-09-02 15:40:17 +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
admin 97c56212df Merge pull request '接線盤點列舉每一個接線點，模型能力鎖不再被誤判成沒接線' (#76) from fix/wire-status-itemize-all-hooks into develop 
Reviewed-on: #76
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-02 07:32:01 +00:00
jiantw83 c0ce4c5c3c chore(plugin 版本): 三份 manifest 升版至 0.4.0 2026-09-02 14:57:04 +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
admin 56aa3e832f Merge pull request '連結一律寫成 [文字](絕對網址)，並在寫入前驗證連得到' (#75) from feat/link-verification/main into develop 
Reviewed-on: #75
 2026-09-02 06:46:41 +00:00
jiantw83 9136894837 chore(plugin 版本): 三份 manifest 升版至 0.3.9 2026-09-02 14:27:18 +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
admin f9f2d08b6b Merge pull request 'release: wiki 目錄頁專用存取庫、HASH 完整 40 碼、閘門依 CLI 分流' (#74) from develop into master 
Reviewed-on: #74
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-02 04:20:34 +00:00
admin 2a6097528a Merge pull request 'feat(wiki): 異常目錄頁改走專用存取庫，並修正目錄列連結恆空' (#73) from feat/wiki-contents-repo/main into develop 
Reviewed-on: #73
 2026-09-02 04:20:18 +00: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
admin ccbf0b8ef7 Merge pull request '能力閘門依 CLI 分流並隔離狀態檔，判不出能力一律擋下' (#72) from fix/sdlc-gate-cli-isolation into develop 
Reviewed-on: #72
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
 2026-09-02 03:11:42 +00: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