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>
6 lines
309 B
Plaintext
6 lines
309 B
Plaintext
【工單】inkstone/Arcrun#165
|
||
|
||
不要先修，先查清楚再說——現在連斷在哪都還沒人講得出來。
|
||
已知的現場（總管 2026-08-26 用 MCP 實查，不是讀 code 推的）：同一個知識庫
|
||
（youlin／yuga3bse），同一套 MCP 工具，四次查詢分數與筆數都對不上。
|