 Leo
|
17a74d7d3a
|
每一則回覆都自己說出拖了多久（inkstone/ISEP#63 → comment 5106）
leo 2026-08-27：「前面說過每個回覆要戴上已經花了總時長，這為什麼沒出現？」
「這應該寫在 ISEP，隨時看自己拖了多久」
重點在後面那句：不是要總管記得戴，是要它長在機器上。
總管當時答「我沒做，現在開始戴」——而那正是這條規則第一次失效的方式。
一支閘掛兩個事件，是同一件事的兩半（票上點名的失效模式就在這裡）：
UserPromptSubmit → 注入算好的那一行（模型不必自己算，也算不準）
Stop → 查核這一回合的回覆裡到底有沒有那一行，沒有就擋一次
只做前半＝又一個會被忽略的提醒；只做後半＝罰它做一件拿不到資料的事。
判準不是關鍵字黑名單，是「那個被要求的輸出元素在不在」——
whitelist-of-one：要求一個機器產生的標記在場，不是猜哪些字不該在場。
換講法照樣要帶標記，多寫什麼都不會觸發。
時長從這段對話的第一則訊息算起，理由寫在 hooks/lib/countdown.py 檔頭：
「任務」在機器上沒有起點，而 CLAUDE.md 規則三點七「一段對話＝一個 release」
剛好讓對話起點就是這個交付的起點——這個數字沒有人要維護，也不會說謊。
resume 取較早的那個：接關不是重新開始。
連帶修好票上的兩個卡點（prod-write-guard）：
卡點一 發一則 Telegram 跟部署工作流在閘眼裡一模一樣 ⇒ 判準改看打的是哪一個
named webhook（路徑形狀＋名字），放行範圍只有 notify_leo 一個名字
卡點二 連「把卡點寫進票裡」都被同一支閘擋（同款第八次）⇒ 剝掉內文再判，
起始行保留，所以真的在部署的寫法照樣擋
（修這支的過程又撞了一次同款——那就是這一格最好的證據）
測試：countdown 20/20、prod-write-guard 29→37/37，全程離線
（時鐘定住、狀態走環境變數、不打網路）。
實測：起點 06:28 台北、現在 08:03 ⇒ 期望「已過 1 小時 35 分」，實得同一字串。
plugin.json 0.9.0 → 0.10.0（版本沒動＝沒有人吃得到）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-28 00:03:38 +00:00 |
|