Leo
b1830053e5
inkstone/ISEP#65：leo 發現「寫完 ISEP#30 那條規則之後，同一天總管又犯了 8 次」， 派來查「現行閘為什麼抓不到」。查證結果分兩層： ━━ 真正在跑的閘其實是 dispatch-format-guard.sh，不是 no-ticket-no-dispatch.sh ━━ no-ticket-no-dispatch.sh 的殼驗證早就是已知行為（只驗有沒有一行【工單】）， 但 ISEP#30 已經為此新增了 dispatch-format-guard.sh 做內容判定，測試 19/19 通過。 問題是它有兩個沒被那 19 條測資蓋到的洞： 1. **regex 洞（本體 bug）**：頂層 CLAUDE.md 規定的合格格式帶全形括號—— 「【工單】owner/repo#N（→ comment M）」。_COMMENT_RE 只吃「→ comment M」 本體，兩側括號沒被算進去，殘留括號讓 _REF_RE 比不過，於是**規則自己定義 的合格範例會被自己的閘擋下**（半形括號 `(...)` 同樣會中）。用今天派我這張 票的那份派工單原句實測，改之前 exit=2「票號形狀不對」。 2. **零容忍過頭**：純禮貌收尾（「謝謝」）跟「記得先讀 CLAUDE.md」這種真內容 一樣被當「派工單不只有票號」擋下。ISEP#65 test 4 明講這四種不該擋 （只有票號／空行／「謝謝」／括號包住的 comment 格式），優先做成低誤鎖。 判斷：不改 no-ticket-no-dispatch.sh、不另立第三支閘——dispatch-format-guard.sh 已經是「另立一支」的正確位置，這兩個洞在它自己的地盤上補。 修法： - _COMMENT_RE 兩側括號（全形／半形）都設可選 - 新增 _COURTESY_CLOSERS 白名單（謝謝／多謝／感謝／辛苦了…）＋ _is_courtesy_closer()， 只在圍欄外生效，判準仍是「整行清乾淨標點後完全相等」不是「包含」—— 白名單不是黑名單，猜漏頂多誤鎖一次，不會反過來放走真內容（③g 測資證明） 測試：hooks/tests/dispatch-format-guard.test.sh 19→33 條，全過。新增： - ③b/③c 全形／半形括號格式（規則自己的例句） - ③d/③e/③f ISEP#65 test 4 的三種不該擋 - ③g 白名單邊界（禮貌詞混真內容裡照樣算數，防止白名單被誤用成漏洞） - ⑮b–⑮i：leo 點名的「寫完規則後又犯的 8 次」當回歸樣本，內容是從 ISEP#60/#61/#64、Arcrun#142/#144/#165、arcrun-rag#104、InkStoneCo#102 的真實票內文摘錄（見 hooks/tests/fixtures/README.md 記載來歷）， 不是想像出來的例子；8 種形狀全部驗證會被擋 reply-identity.test.sh 11/11 仍全過（共用 dispatch_parse.py 沒有回歸） 升版 0.5.0 → 0.5.1（改完不升版沒人吃得到；check-version-consistency.sh 在本分支照慣例是紅的，tag 於 merge 時打）。 另查：.shell-payload/ 整個被 gitignore（scripts/vendor-to-shell.py 產物）， 不是 git 分發的一部分——「這支閘會不會被吃到」取決於消費端有沒有重跑 plugin update／vendor-to-shell.py，不是這個 repo 委交的內容缺漏，故不在 本票改動範圍內，僅記錄供總管排查用。 未動 no-ticket-no-dispatch.sh（判斷見上，職責保持不重疊，兩支閘互斥見 dispatch_parse.py 的 has_ticket_marker 分岔）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ISEP — InkStone Environment Plugin
leo 2026-08-20：「你把全部環境設定放在一個 claude code plugin，同一個 plugin 你用，薄殼也用，保證兩邊同步⋯⋯ 以後有任何變化，增加 command, hook⋯⋯都增加在這裡，再去跟它同步。」 「我要你幫雲端做薄殼，永遠都有問題，你要做的就是這組設定你自己可以 dogfooding。」
這個 repo 解什麼
在此之前，同一套環境有兩份：
真身 InkStoneCo/.claude/ ← 本機在跑的
薄殼 由 generate-shell-payload.py 產生一份，塞進 GitHub 私 repo ← 雲端在跑的
兩份必然漂移。inkstone/InkStoneCo#57 記著實測結果：薄殼比真身少 7 支閘，
其中兩支是前一天才立的。#14 更早：雲端 33 支 guard 一支都沒生效。
⇒ 現在只有一份：本 repo 就是唯一真相源，本機與雲端裝同一個 plugin。 ⇒ 而且總管自己也用它——壞掉的時候是我先踩到，不是雲端替我踩。
裝什麼
| 數量 | 是什麼 | |
|---|---|---|
hooks/ |
48 支 ＋ hooks.json |
全部機械閘（PreToolUse／Stop／SubagentStop／SessionStart／PostToolUse 共 59 條註冊） |
commands/ |
7 支 | /wiki-recall /ship-check /cp-write … |
skills/ |
2 支 | |
scripts/ |
23 支 | ticket／github-arm.sh／gitea-bootstrap.sh … |
不放：.env（金鑰，違 D36「金鑰只有一個家」）、wiki/、docs/、_archive/
——那些是知識不是環境。
路徑規約（薄殼一直壞掉的根）
hook 一律用官方的 ${CLAUDE_PLUGIN_ROOT}，不准寫死絕對路徑、也不用 $CLAUDE_PROJECT_DIR
去指 hook 自己：雲端的 cwd 不是真身，寫死就斷。
腳本內部要指專案檔案（wiki、docs）時才用 $CLAUDE_PROJECT_DIR——那是對的，
因為那些東西本來就住在被操作的那個 repo 裡。
改東西的規矩
🔴 只改這裡，然後兩邊 /plugin update。
不要再改 InkStoneCo/.claude/hooks/——那個目錄退場中。
這些閘各自在管什麼
不用點開任何 .sh——docs/hooks-inventory.md 一支一行白話，按「你會在什麼時候撞到它」分組。
測試手冊在 docs/TESTING.md，治理規範在 docs/governance/。
🔴 派工前先讀 docs/governance/dispatch-and-reply-format.md——
派工單只給票號（其餘全部寫進票或共通規定），票上的每一則留言第一行要表明身份。
兩件事都有機械閘（dispatch-format-guard.sh／reply-identity-guard.sh）。
版本
「ISEP 現在是哪一版」只有一個地方答得出來：Gitea Releases。 每一版的內容、改了什麼、驗過什麼都寫在那裡的 release note，不寫在這份 README。
這份 README 本來寫死過「狀態：0.1.0」，但 repo 一個 tag 都沒打（release_counter=0）——
leo 當場指出這是違規：宣稱交付卻沒有 tag 撐它（inkstone/ISEP#6）。
現在改成結構性防漂移：.claude-plugin/plugin.json 的 version 欄位永遠跟最新 tag 一致，
scripts/check-version-consistency.sh 會擋下兩者對不上的狀態，
hooks/release-tag-guard.sh 則在打 tag 的當下直接擋住不一致的 tag——
細節與判準都寫在那兩支腳本開頭的註解。