-
claude-code released this
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