 Claude Code
|
da9bd53cae
|
沒人會叫的事會自己叫＋讀不完的必讀檔要被整理（inkstone/ISEP#93、inkstone/ISEP#89）
兩張票放同一條分支：都是「該發生卻不會自己發生的事」，觸發點都在 session 邊界。
## inkstone/ISEP#93 —— 逾期和掛著沒人接的事會主動叫
- scripts/isep-nag 撈三種沒人會叫的事（逾期 milestone／等 leo 的票／掉在地上的棒子）
- scripts/isep-notify 發 Telegram，而且**發不出去的時候不會安靜**
- hooks/overdue-nag-guard.sh SessionStart 跑一次（不輪詢、不 fan-out、不掛 Actions）
- hooks/tests/overdue-nag.test.sh 35 條，全程離線
實跑撈得出票上點名的那五個逾期 milestone（08-24 三個、08-26 兩個）。
沒東西可報時會說「查過了，沒有」——安靜跟壞掉長得一模一樣。
🔴 工單補的那個限制（今天實測出來的）已經處理：
「能不能發得出去」取決於這個 session 載到的 ISEP 是哪一版
（prod-write-guard v0.10.0 才認得出 notify_leo 不是部署，而 hook 註冊路徑
在 session 啟動當下就寫死了）。所以 isep-notify 會**先拿真的要送的那一則
去問這個 session 註冊的那支閘**，把判定寫成檔（誰都查得到），然後：
· 放行 ⇒ 送，並驗內層 data.data.ok（外層 200 不算送到）
· 會擋 ⇒ **不繞路**，改貼回票上並把原文印在眼前
用 git 歷史裡的真跡（c263866 那一版閘）測過「會擋」那條路。
⛔ 實測發現通道本身現在是斷的：實例上找不到 notify_leo 工作流（404）。
不是閘、不是網路、不是金鑰。詳情與修法寫在 docs/TESTING.md 最後一段。
退路兩次都走通了（inkstone/ISEP#93 comment 5182、5184）。
## inkstone/ISEP#89 —— wiki 太長時有人整理
- scripts/wiki-compress audit／plan／apply／verify／bench 五個動詞
- hooks/wiki-size-guard.sh SessionStart 點名太長的檔；寫檔時擋「沒走流程的壓縮」
- hooks/tests/wiki-compress.test.sh 25 條，全程離線、不碰真的 wiki
設計上最重要的一條：**只搬不改**，正文一個字都不動。
「合併同類、濃縮成一行」要重寫正文，而重寫的當下沒有人會發現弄丟了什麼。
所以機器只做「搬 ＋ 目錄 ＋ 標 ×N／↻」，合併留給人。
拿現在的 mistakes.md 複本實壓過（不動真的 wiki）：
7,681 行 → 1,199 行
260 條一條都沒少（verify 用內文雜湊逐條對帳）
80 個查詢命中率 80/80，定位成本 2,956 → 131 行，**快 22.5 倍**（bench）
verify 反向測過：真的弄丟一條時它抓得到（抓不到的對帳表比沒有更糟）。
## 盤點數字
在這棵樹上當場數的，不是拿上一版加減推的：
ls hooks/*.sh | wc -l → 55（was 53）
grep -c '"command":' hooks.json → 71（was 68）
plugin.json／README／hooks-inventory 三處同步改。
**版本號沒動**（0.11.0），待總管定版。
|
2026-08-28 01:04:16 +00:00 |
|
Leo