-
v0.16.1 — 修好「派不出工」的死鎖 Stable
claude-code released this
2026-08-28 12:38:19 +00:00 | 0 commits to main since this release🔴
v0.15.0上線之後，這個環境完全派不出任何工。 這一版修它。撞到的長相
派給 isep:isep-hand → roster-guard：「名單上沒有這個人」 派給 isep-hand → Claude Code：「Agent type not found」兩種寫法都不通，而且自己做也不行——
subagent-first-guard要求先派過工。雙向死鎖。根因
Claude Code 給 plugin agent 的
subagent_type帶前綴（isep:isep-hand），而agents/*.md的 frontmattername沒有前綴（isep-hand）。roster.find()用完全相等比對 ⇒ 它永遠不可能認得真實的值。修法是允許
<plugin>:<name>，冒號後面那半才拿去比；裸名字仍然收（人會照roster list直接貼），不存在的仍然擋（剝前綴不能變成放行任何東西）。🔴 為什麼 24 條測試一條都沒抓到
因為它們全部餵手寫 payload，沒有一條用真實的
subagent_type形狀。測試驗的是「這支閘的邏輯對不對」，沒有驗「它接到的東西長什麼樣」。已補第 19 條專測它，而且做了有鑑別力的對照：
舊 roster.py ＋ 新測試 → 第 19 條紅（24 通過 / 1 失敗） 修好後 → 25/25 全綠📌 第一次做對照時我把測試檔一起
git stash了 ⇒ 對照組只跑了 24 條，等於沒對照到。只還原roster.py、保留新測試，才是真的對照組。順手補上
gate-ok漏掉的rostergate-ok是v0.12.0做的（把七種形狀各異的逃生口收斂成一個名字），但v0.15.0新增roster-guard時沒有同步那份清單 ⇒ 撞上死鎖時連留痕的出口都沒有，只能手工建檔。⇒ 新增一支會擋人的閘時，它的逃生口要同時進
gate-ok，否則出口只存在於那支閘的錯誤訊息裡。這一版是怎麼被做出來的（留痕）
派不出工、又不准自己動 code ⇒ 蓋了
gate-ok solo戳記自己修。理由命中CLAUDE.md寫的兩種正當情形：hook 自己、緊急止血。總管自己驗的
roster-guard 25/25（新增第 19 條，對照組驗過有鑑別力） 隔離重跑全套 36 支全綠 / 0 紅 gate-ok roster 實跑蓋得出戳記、用法列表印得出來📌 票：
inkstone/ISEP#86的迴歸｜PR：#108Downloads
-
2026-08-28 01:32:11 +00:00 | 2 commits to main since this release兩張票一批（
inkstone/ISEP#93／#89）。① 逾期與掉在地上的棒子，會主動叫（
#93）開場跑一次（不輪詢、不掛排程、子 session 不叫），撈三類：逾期的 milestone、在等 leo 的票、掉在地上沒人接的棒子。實跑撈得出今天那五個逾期 milestone、8 張在等 leo 的票、20 根掉在地上的棒子。
沒東西時說「查過了，沒有」；撈不到資料時說「我沒查到」而不是「沒有事情逾期」——那兩句在機器上是不同的事。
② wiki 太長時有人整理（
#89）最重要的設計決定是 只搬不改：正文一個字都不動，機器只做「搬去 archive ＋ 產目錄 ＋ 標記重複次數」。「合併同類、濃縮成一行」要重寫正文，而重寫的當下沒有人會發現弄丟了什麼——所以合併留給人，機器負責把該合併的那批點名出來。
拿現在的
mistakes.md複本實壓過（真的 wiki 一個字沒動）：7,681 行 → 1,199 行 260 條一條都沒少 （用內文雜湊逐條對帳） 80 個查詢命中 80/80，定位成本 2,956 → 131 行，快 22.5 倍verify反向測過：真的弄丟一條時它抓得到——抓不到的對帳表比沒有更糟。📌 順帶一個數字：
mistakes.md裡有 73 條自己寫著「同款第 N 次」「又犯一次」，佔 28%。用標題相似度只找得到 1 對，人下的判斷準得多——所以機器只負責點名，不負責合併。🔴 這一版的交付過程，工人把昨天的教訓當場用上了
hooks.json這次自動合併成功、沒有衝突標記。工人沒有停在那裡，因為總管上一版才記過「對照組相符只證明兩邊條件一樣，不證明條件是對的」——「自動合成功」本身就是一個看起來很綠的訊號，跟「合對了」是兩件事。它做了集合對照：
merged 82 ＝ main 79 ＋ 它的 3 從 main 掉了 0 條 ／ 從它那邊掉了 0 條 ／ 兩邊都沒有卻冒出來 0 條並把逐支點名的指令和這段理由寫進
README.md——下一個合這個檔的人不必再自己想到。🔴 今天第四次「假紅」，這次根因是測試互相污染
合併後連續跑全套，
test-release-tag-guard與test-stage-before-prod-guard是紅的。單獨跑：8/8 與 13/13 全過，離開碼 0。根因是這批測試共用
/tmp底下的戳記檔，連續跑時前面的會影響後面的。清乾淨再逐支跑：36 支全綠、零紅。⇒ 今天四次假紅的形狀完全相同：拿一個沒驗過的判準去讀輸出（輸出格式／測試污染／參數帶錯／再一次測試污染）。四次裡有三次是總管自己犯的。
🔴 有一格驗不了，明講
#93的驗收第 4 條「Telegram 真的收得到」過不了，而原因不在這次的程式碼：leo21c上的工作流定義整批失效（notify_leo404，連ship_refresh_cdn的執行紀錄都寫著「圖定義已失效」）。修它要寫 leo 的個人帳號，leo21c-write-guard.sh明文禁止 ⇒ 真人閘，總管也解不了。該票已 指派給 Leo ＋ 掛
Human。通道修好後不必改任何程式碼，重跑scripts/isep-nag --notify就能補驗。📌 票：
inkstone/ISEP#89／#93｜PR：#106＋#107｜里程碑：SOP 變成閘（12/13）Downloads
-
2026-08-28 01:22:47 +00:00 | 9 commits to main since this release三張票一批（
inkstone/ISEP#86／#87／#88），都是派工這條線上的紀律。① 工人有名字
以前派工是派給一個沒有名字的臨時工——票上看不出來誰做的，每次都要重新交代它是誰。
現在
agents/有七位具名工人（isep-hand／arcrun-hand／arcrun-rag-hand／inkstoneco-hand／mira-hand／collector-hand／scout），各自寫明：你是誰、負責哪個 repo、開工前先讀什麼、你的紅線是什麼。指名錯了或沒指名，閘會擋下來並印出整份名單；指對了就把那位的檔案原文注入。🔴 用的是 Claude Code plugin 原生的
agents/目錄，所以「指名派給誰」就是既有欄位，派工單格式一個字都沒改。加一個工人 ＝ 加一個.md，不必碰任何 hook。② 沒調查過就寫不出診斷
leo 2026-08-27 列的今日錯誤之一是「票裡寫未經調查的診斷」。這一版讓它寫不出來：想在 Gitea 上留一段像診斷的話，得先滿足三個結構訊號——這個 session 有沒有派人查過那張票、這段話裡有沒有走得過去的出處（
檔案:行號／commit／留言號／票號／網址）、有沒有份量。🔴 零關鍵字比對，字面比對只往放行的方向做。60 字的門檻是量出來的不是猜的——真的一段診斷 73 字、最短的合理回覆 6 字；第一版寫 120，那段真的診斷就漏抓了。
③ 回覆 subagent 也只給票號
v0.5.0把派工單壓成只剩票號，但那道閘只掛在「新開一個 subagent」那條路上。回覆一個正在跑的工人走的是別的通道，完全不經過攔截點 ⇒ 第一次乾淨，第二次又把一長串要求塞進訊息裡，而那些話一樣沒留在票上。這一版沒有另造閘，而是把所有通往 subagent 的路收成一張表（
Task／Agent、SendMessage、雲端的建 session／送訊息／排程、claude -p），共用同一個判斷函式。擋下來時把那段內容原文印出來，方便直接貼上票。刻意不管兩個方向：工人往上回報（那是交件不是派工）、子 session 送出的回覆（但它自己往下派工時照樣管）。
總管自己驗的
main 上 34 個測試套件全綠 / 0 紅 dispatch-format 52/52（原 33，新增三群 19 條）｜roster-guard 24/24｜diagnosis-evidence 26/26 實數：58 支 .sh／79 條註冊／49 支腳本／7 位具名工人🔴 這一版收斂時的兩件事，都值得記
①
hooks.json的衝突不是二選一。 兩邊在同一個陣列位置各加了一支閘（roster-guardvsmainline-focus-guard），選一邊就會讓一支閘靜靜消失——JSON 照樣合法、載入照樣成功、不會有任何東西喊一聲。正解是展開成兩個項目，並且用「逐支數註冊次數」複驗，不是只看 JSON 合不合法。② 今天第三次「假紅」，而這次是我自己。 我兩次把
gitea-arm-check與main-and-prod-push-guard-cross-repo判成「本來就紅、不是我弄的」，還開了對照組跑乾淨的 main——對照組也紅，於是我更確信了。實際上兩邊都紅只是因為我兩次都沒帶對參數（前者要 repo 根目錄、後者要絕對路徑）。帶對之後兩支全綠。⇒ 對照組相符只證明兩邊條件一樣，不證明條件是對的。 今天三次假紅（輸出格式判準、測試互相污染、參數帶錯）形狀完全相同：拿一個沒驗過的判準去讀輸出。
📌 票：
inkstone/ISEP#86／#87／#88｜PR：#105｜里程碑：SOP 變成閘（10/13）Downloads
-
2026-08-28 01:05:46 +00:00 | 12 commits to main since this release這一版一次進來三件，都是「該發生卻不會自己發生」的事。
① 舊票每天有固定管道被撈出來（
inkstone/ISEP#83）leo 2026-08-27：「現在每天都在追新的，所以要用 Routine 去消化舊的，可以有多個條件」。
實查：這個組織 243 張 open issue、10 個 open PR，而每天在動的只有掛在主線上的那些。
scripts/debt-worklist每天撈一份可領清單，成包領取（互相指著／原生相依的必然同包），排序用多條件——出事的／擋住別人的／答應過人家的／放最久的／最快做完的。🔴 兩件只有跑真實資料才會現形的錯，工人自己抓到並修掉：
- 第一版用「單向文字引用」成包，對真實資料跑出來 121 張黏成一坨（大家都順手引用同一張 hub 票）＝沒有人領得動
s/stage的票被列成可領——那是等 leo 驗，正確動作是催不是領，混進去會讓人重做已經做完的事
並且它接上了
v0.13.0的「主線唯一答案」，不自己養第二套判斷：沒標主線時照實說「現在沒有標主線」，不編一條出來。② 一次交貨由哪些版本組成，退版退得回去（
inkstone/ISEP#84）scripts/release-manifest。三條硬規則長在工具裡不是文件裡：凍結前每一格真的去 Gitea 抓過（抓不到不給凍結）／凍結後不准再加／退版一定吐整份，--only <單一 repo>直接擋下（那會產生一組從來沒測過的組合）。③ 結案要留下帳（
inkstone/ISEP#85）三個數字自己算：訂的期限／實際耗時／偏差 %。差超過 ±25%（提早太多也算，那是當初估太鬆）就要從七個封閉集合裡挑一個原因，而且代號要有時間軸撐得住——判準一句自然語言都不讀，只看時間戳、指派欄位、標籤、票的歸屬。
真實資料重演（唯讀）：今天那五個逾期的 milestone 都算得出數字——
arcrun-rag#47+592%、Arcrun#46+592%、Arcrun#50+131%、Arcrun#51+178%、ISEP#43+66%。④ 下游做完時頂層跟著關（
inkstone/ISEP#92）這一格早上就併進 main 了，但版本沒動＝更新是 no-op＝等於沒交付，所以它跟這一版一起送達。
總管自己驗的
29 個測試套件綠 / 3 紅🔴 那 3 個紅我逐一做了對照組，因為「我弄壞的」和「本來就紅的」不能混為一談：
紅的 在乾淨 main 上 判定 gitea-arm-check也紅 不是本次造成 main-and-prod-push-guard-cross-repo也紅（14/5） 不是本次造成 dispatch-format-guard第一次測是綠的 差點誤判成「我弄壞的」 第三個隔離重測後兩邊都是 32/33——第一次的「綠」是測試互相污染造成的假象。根因是那支測試用固定路徑當豁免戳記，多份一起跑會互相刪掉（工人並行重現過：一份 33/33、一份 32/33）。今天四條線並行，這個假紅還會再出現，而它長得跟「閘壞了」一模一樣。
🔴 這一版的收斂過程，總管犯了一個值得記的錯
解衝突時我用
tail -6看 git 的衝突清單，把開頭截掉了，於是漏看兩個檔（plugin.json與README.md）。是後來全樹掃grep -rln '^<<<<<<<'才抓到。⇒ 截斷輸出來省事，代價是漏掉的那部分你不會知道自己漏了。 同一天我還用錯的 grep 判準把 12 個綠的測試判成紅（它們只是輸出格式不同），那也是同一族——拿一個猜的判準去讀別人的輸出。
📌 票：
inkstone/ISEP#83／#84／#85／#92｜PR：#101／#98／#104｜里程碑：SOP 變成閘（7/13）Downloads
-
v0.13.0 — 現在的主線是哪一個，有唯一答案 Stable
2026-08-28 00:49:45 +00:00 | 32 commits to main since this release你會看到什麼不一樣
每一則回覆的那一行倒數，現在多了第三段：
⏱ 已過 0 分｜距收工線（台北 16:00）剩 7 小時 16 分｜主線 SOP 變成閘 剩 71 小時 16 分為什麼需要這一格：2026-08-27 實查，這個組織同時有 14 個 open milestone，其中「Mira 現代化」這一個名字同時存在於 5 個 repo，還有 5 個已經逾期。SOP 要求「有主線時只做主線的事」、也要求每回合把主線目標推到眼前——但**「那個主線」在現場根本沒有指涉對象**。要注入不知道注哪一個，要擋跳線也不知道拿哪一個當基準。
現在它是一個查得到的事實：
scripts/mainline。而且派工會被擋：主線期間派一張不屬於主線的票，擋一次並問你是補收還是新事項（
mainline-focus-guard，至多擋一次）。總管自己驗的
mainline-focus-guard 24/24 countdown-guard 20/20 ← 無迴歸（它是 v0.10.0 帶進來的那一行） 實數：54 支 .sh／71 條註冊／40 支腳本🔴 這一版的工人做了一件我沒要求的事，值得記
它不只跑自己工作區的檔案，而是從
git archive還原推上去的那顆 commit 來跑——理由是「工作區裡的檔案不是別人裝到的東西」。因此它驗到了一格我不會想到的：檔案權限。
scripts/mainline與mainline-focus-guard.sh都是100755——沒有執行位元的話，SessionStart 那條對所有人都會失敗，而那種失敗是安靜的。它自己找到並修掉七個問題，其中兩個是自己的測試誤紅（拿整份輸出比對關鍵字，被描述欄裡的同一個字串誤判），還有兩個是盤點表既有的假綠。
🔴 一個仍然存在的假綠，記在這裡
scripts/check-version-consistency.sh只比對版本號字串，不比對內容。所以「main 的內容已經比上一顆 tag 多了東西」這件事它會說「✅ 一致」。這正是出貨心法寫死要擋的那一格（「把『版號沒變但內容變了』餵進去，管線要擋下來而不是跳過」），而它跳過了。本版沒有修它——記在這裡，因為總管今天就是靠人眼發現的。
📌 票：
inkstone/ISEP#82｜PR：inkstone/ISEP#99＋#102｜里程碑：SOP 變成閘（13 張，這是第 4 張）Downloads
-
2026-08-28 00:39:09 +00:00 | 37 commits to main since this release這一版修的是雲端 session 專屬的四個缺陷。它們活這麼久的共同原因是：每一個都不會自己喊痛。
你會看到什麼不一樣
① 未推警察不再每次收工都誤攔
判準從「這條分支有沒有設定 upstream」改成「遠端有沒有這顆 commit」。雲端開 session 時生出來的工作分支天生沒有 upstream，而它的內容就是遠端 main ⇒ 舊版每個 session、每次收工都誤報一次。今天實測誤報了八次。② 總管的「我確認過了」出口，在雲端根本打不開
三支閘（推 main／推 prod／出 stage）都用同一個寫法算戳記時間，而那個寫法在 Linux 上取不到秒數——它取到的是一整段檔案系統資訊。下一行的數字檢查必然失敗 ⇒ 戳記永遠不被接受。⇒ 也就是說：閘留了一道給總管的門，而那道門在每一個雲端 session 上都是焊死的。 它們在雲端等於純擋，而閘不會告訴你門是壞的。
今天總管為了發一則通知蓋了兩次戳記都無效，一度以為是權限問題，還去翻了白名單設定——那一整段時間是被這個 bug 吃掉的。
🔴 這個 bug 活這麼久的真正原因：既有三支測試（29／16／10 條）只驗了「擋得住」，一條都沒驗過「放得開」。新增的
gate-ok測試補的正是那一半。③④ 兩件本來看不見的事，現在開場就講
信標多報三件：這台機器載的 plugin 落後幾版、有沒有舊複本遮蔽正門、有沒有已退役機制的殘骸還在長。判準是「這一份 plugin 的檔案有沒有提到它」，不是關鍵字比對。總管自己驗的（合併後在 main 上重跑，不是聽工人說）
gate-ok 17/17 ← 新增，補「門打不打得開」那一半 unpushed-police 10/10 ← 新增 isep-presence-beacon 14/14 ← 新增 countdown-guard 20/20 ← 無迴歸 pr-verdict-guard 52/52 ← 無迴歸 prod-write-guard 37/37 ← 無迴歸 ──────────────────────────── 合計 150 條全綠盤點數字在合併後的樹上重數：53 支
.sh／68 條註冊／39 支腳本。🔴 診斷過程本身出過一次錯，記在這裡
總管一度宣稱「那個取時間的寫法從來不會被執行」，證據是量到 exit=0。工人訂正了：那個 0 是管線造成的假象（
$?拿到的是管線最後一段的離開碼）。重新驗過的正確描述是：那個旗標是布林旗標、不接格式字串，格式字串被當成額外的檔名運算元 ⇒ 只要目標檔存在，指令就成功 ⇒ 後備寫法不執行。而戳記檢查時目標檔必定存在 ⇒ 在真實情境下 100% 失效。
⇒ 結論沒變，但證明過程錯了一次，是工人抓到的。記下來是因為：那正是「量離開碼時中間接了管線」這個坑，而總管在同一天警告過別人不要犯。
📌 票：
inkstone/ISEP#90｜PR：inkstone/ISEP#96＋#100｜里程碑：SOP 變成閘（13 張，這是第 3 張）Downloads
-
v0.11.0 — PR 不會再躺兩個星期沒人理 Stable
2026-08-28 00:28:58 +00:00 | 48 commits to main since this release你會看到什麼不一樣
收工那一刻會清點：還有哪些 PR 沒有結論——open、沒有人被指派、也沒有「要求修改」的 review，就擋一次並點名是哪幾個（含開了幾天與網址）。已經合併但分支還留著的也一起點名。
背景：2026-08-27 實查，最久的三個 open PR 躺了兩星期，而當時 46 支閘一支都沒有在管 PR。票看起來「已交付」，東西卻沒進 main、沒進版本 ⇒ leo 手上永遠不會出現它。
🔴 擋的是遺忘，不是等待
這一格有前車之鑑：治理規範的分歧書 §B4 記過一個被否決的設計（「待審佇列非空就不准收工」）——那會讓總管永遠停不下來，因為 leo 在上課、沒人 merge，佇列本來就不會空。
所以四層都用來放掉「等待」：有人被指派或掛
Human（棒子在他手上）／有「要求修改」的 review（結論已經給了）／這一回合碰過它／響過就退讓（每個 PR 各自 1→4→8→16，不可能鎖死）。「碰過」不讀任何一句話，只看三件機器事實：
updated_at變了／上次收工時還不存在（不在它誕生的那一回合就開罵）／這一回合的工具呼叫出現它的識別碼。配套：
scripts/pr-verdict三種結論各是一個動作，不是三個步驟讓人記得做：
pr-verdict merge <owner/repo#N> 併 ＋ 刪分支 ＋ 當場複驗分支真的不見了 pr-verdict reject <owner/repo#N> 理由寫進票 ＋ 關 PR ＋ 刪分支 pr-verdict changes <owner/repo#N> 修改要求寫進票 ＋ 以票號通知總管自己驗的
pr-verdict-guard 52/52 countdown-guard 20/20 （合併後重跑，無迴歸） prod-write-guard 37/37 （合併後重跑，無迴歸）盤點數字在合併後的樹上重數，不是相加推的：53 支
.sh／68 條註冊／38 支腳本。並且逐檔比對過遠端與本機測過的那份 sha256 逐位元相同——不是「API 回 200」就算。
🔴 這一版的交付過程本身撞到一個死鎖，值得記下來
這條分支推不上去：
github-contact-guard用「payload 釘住的工作目錄」去解 remote 名，而雲端 session 的那個目錄是 GitHub 薄殼 ⇒ 任何推 Gitea 的動作都被判成推 GitHub。而修這一族 cwd bug 的 PR（
inkstone/ISEP#90）自己也被同一個 bug 擋住。最後改走 Gitea 的檔案 API 送上一條乾淨的新分支（全程只打
git.uncle6.me，完全沒有接觸 GitHub ⇒ 那道閘的目的一點都沒有被規避，被繞過的只有它查錯 repo 的那個 bug）。原本的#95因此作廢，內容原封搬到#97。📌 票：
inkstone/ISEP#81｜PR：inkstone/ISEP#97｜里程碑：SOP 變成閘（13 張，這是第 2 張）Downloads
-
v0.10.0 — 每一則回覆都自己說出拖了多久 Stable
2026-08-28 00:12:25 +00:00 | 56 commits to main since this releaseleo 2026-08-28 07:40：「先完成倒數計時器，每一次回覆都發倒數，你有 8 小時左右」
這是今天八個版本的第一個，也是其餘十二張票的節拍器。
你會看到什麼不一樣
- 每一則回覆開頭都會有一行
⏱ 已過 X｜距收工線剩 Y——數字是機器算的，不是我記的 - 算不出來時整段不顯示，不編數字
- 它同時掛在兩個地方：訊息進來時把算好的那一行送到眼前，收工時檢查那一行在不在，不在就擋一次
- 只有前半 ＝ 又一個會被忽略的提醒；只有後半 ＝ 罰它做一件拿不到資料的事
判準不是關鍵字黑名單
查的是「那個被要求的東西在不在」（一個機器產生的標記），不是「有沒有講不該講的話」。
換個講法照樣要帶標記 ⇒ 閃不過；多寫什麼都不會觸發 ⇒ 不誤攔。連帶修好兩個今天實撞的卡點
① Telegram 發不出去：發一則通知和部署一個工作流，在舊判準眼裡長得一模一樣（都是帶 body 打到那台實例）。
改成看打的是哪一個 named webhook——只放行notify_leo一個名字，不放行整個家族。
實測notify_leo_deploy這種前綴相同的不算通知，照擋。② 連「描述這個卡點」都被同一支閘擋（同款第八次）：把卡點寫進票時，內文引用了判準關鍵字就被咬。
改成剝掉內文再判，起始行保留——所以真的在部署、只是把 payload 藏進內文的寫法，仍然照擋。📌
inkstone/InkStoneCo#23的標題寫著「同款第七次」。這是第八次，而它終於被修在機制上而不是又記一筆。總管自己驗的
countdown-guard 20/20 （其中 7 條專測「不該擋」） prod-write-guard 37/37 （原 29，新增 8 條含兩個卡點的真跡重演）不是轉述——總管自己 clone 下來跑過一次，數字相同。
🔴 有一格沒驗，明講
「新 session 裡這支閘真的會被叫到」沒有驗——subagent 開不了新 session，而發版的這個 session 載入的是舊版 plugin（0.3.9，落後六版，
inkstone/ISEP#67）。⇒ 依 leo 2026-08-17 的分界，這一版是 report 不是 deliver 的完整態：腳本層面全綠，但「裝上去真的會動」要下一個新 session 打開才算數。
📌 票：
inkstone/ISEP#63｜PR：inkstone/ISEP#94｜里程碑：SOP 變成閘（13 張，這是第 1 張）Downloads
- 每一則回覆開頭都會有一行
-
v0.9.0 — 搜尋不是證據 Stable
2026-08-27 13:41:19 +00:00 | 58 commits to main since this release這一版擋的是「用一條已被否定的路去證明另一件事」——今天總管犯了四次，其中一次退回了一張已經做完、有測試的票。
你會看到什麼不一樣
- 只有兩個條件同時成立才響：① 要送出去的留言裡貼了一個值（entry id 或
kb://位址），而它這個 session 只在kbdb_search的回應裡出現過 ② 這個 session 從沒用產品檢索路徑拿過那筆 - 閘裡一個措辭關鍵字都沒有——比對的是從工具掉出來的值。8-17 已經證明文字層的閘只會誤攔
kbdb_search完全沒變難用：查 wiki、找 record_id、看某筆在不在，全部放行
總管自己驗的：31/31 測試通過（11 條「不該擋」＋5 條「該擋」＋訊息＋登記處）。那條線還拿今天的真跡重演——
Arcrun#167comment 4865 那則錯誤退回，原文照貼 → 擋。Downloads
- 只有兩個條件同時成立才響：① 要送出去的留言裡貼了一個值（entry id 或
-
v0.8.0 — 搜尋戳記證明「看過」，不是「跑過」 Stable
2026-08-27 13:24:29 +00:00 | 60 commits to main since this release這一版讓「開票前搜過了」不能再是一句空話。
你會看到什麼不一樣
- 以前
ticket where只要跑過就拿得到戳記——把輸出丟進/dev/null照樣能開新票。今天就是這樣開出一張重複票，而命中的第一名講的是同一件事、已經開了 13 天 - 現在戳記證明的是「這份輸出到過人眼前」。丟掉了就擋下來，並且把剛才被丟掉的命中清單重新印一次
總管自己驗的：17/17 測試通過；重演今天那次違規（
where … >/dev/null後開票）→ 擋下，訊息直接列出命中的票。Downloads
- 以前