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