Files
ISEP/hooks/tests/fixtures
Leo b1830053e5 dispatch-format-guard 修兩處:規則自己的合格範例會被自己擋,禮貌收尾不該算違規
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>
2026-08-27 14:25:17 +08:00
..

測資的來歷

real-violation-isep30.txt真的發生過的那一份派工單,一字未改(只把家目錄路徑 換成 /Users/x 去識別)——它就是產生 inkstone/ISEP#30 這條線的那一次派工。

leo 2026-08-27 要的測資是「今天實際發生的 5 次違規派工」 (arcrun-rag#104Arcrun#142Arcrun#127Arcrun#144InkStoneCo#55)。

🔴 其中 4 份拿不回來了。 它們住在那幾次派工的 prompt 裡,agent 結束就沒了—— 這件事本身就是這條規則的證據(4327:「那個 agent 被停掉/換人接手, 那段事實就消失了」)。所以這裡只放拿得到的那一份真跡, 其餘的覆蓋率改用「一條規則一個最小案例」來補(見 dispatch-format-guard.test.sh B 群)。

不要用想像出來的例子替補那 4 份,那會讓測試看起來比實際更綠。


第二批:real-content-*.txtinkstone/ISEP#65

leo 2026-08-27 又在同一天抓到總管寫完規則之後又犯了 8 次(八條線的派工單, 每一條都帶了「這個 session 才知道的事」):ISEP#60#61#64Arcrun#142#144#165arcrun-rag#104InkStoneCo#102

🔴 原始的違規派工 prompt 本身一樣拿不回來(同一個道理:agent 一停就蒸發), 但這 8 次的內容已經被總管補寫回各自的票ISEP#65 body 明講)。 這裡的 8 份 real-content-*.txt從那些票的真實內文摘錄(一字未改地複製, 只是截取一段,並在最前面加回 【工單】owner/repo#N 讓它符合派工單的殼)—— 不是想像出來的例子,是真的存在於 Gitea 上、總管真的寫過的句子,只是原本的位置 錯了(在 prompt 裡,不在票上)。

用途:驗證 dispatch-format-guard.sh 修完 ISEP#65 之後,這 8 種「票號 + 這個 session 才知道的事」的形狀全部會被擋下——不是只驗一個最小案例。