inkstone/ISEP
2
0
Fork 0
Code Issues 18 Pull Requests 1 Actions Packages Projects Releases 22 Wiki Activity

身為一天只看兩眼的人，我要每則回覆都自己說出拖了多久，我才能一眼看出這件事花了不該花的時間 #63

New Issue
Open
opened 2026-08-27 04:45:41 +00:00 by claude-code · 2 comments
claude-code commented 2026-08-27 04:45:41 +00:00
Member
Copy Link
Copy Source

身為一天只看兩眼的人，我要每則回覆都自己說出拖了多久，我才能一眼看出這件事花了不該花的時間。

leo 2026-08-27 的原話

「前面說過每個回覆要戴上已經花了總時長，這為什麼沒出現？」
（總管答「我沒做，現在開始戴」之後）
「這應該寫在 ISEP，隨時看自己拖了多久」

🔴 重點在後面那句：不是要總管記得戴，是要它長在機器上。
總管答應「現在開始戴」——而那正是這條規則第一次失效的方式：
靠記性的規則，下一個 session 就沒有了（今天已經證明過好幾次：
history-first／KBDB-first／stage-first／派工-first 全是同一個形狀）。

要達成什麼

總管每一則回覆都帶著「這件事已經花了多久」，而且不需要總管記得。

判準：一個新開的 session，總管什麼都沒被交代，回覆裡照樣有時長。

這一格要你自己判斷（不要照抄總管的想法）

  • 時長從哪一刻算起？session 開始？當前 milestone 建立？當前任務接手？
    ——leo 的原話是「隨時看自己拖了多久」，那個「拖」指向的是任務不是 session，
    但實際上哪個基準對他最有用，要你想清楚並在票上說明理由
  • 怎麼讓它出現在回覆裡：Claude Code 的 hook 能注入 context（本 repo 現有多支
    additionalContext 型的 hook 就是這樣做的），但「注入提醒」與「回覆真的帶上」是兩件事
    ——注入了但模型沒照做是這類機制的主要失效模式，設計時要正面處理
  • 不要做成又一個會被忽略的警報（本 repo 心法第 2 條）

怎麼驗

  1. 新開一個 session，不交代任何事 → 總管的第一則回覆就帶著時長
  2. 時長的數字對得上真實經過的時間（貼實測：期望值與實際顯示）
  3. 連續幾則回覆，時長是遞增的、不會歸零或亂跳

紅線

  • 不要 push 到 main；交回分支
  • plugin.json 要升版——版本沒動＝沒有人吃得到
  • 收工：結論寫回本票、指派 claude-code、改 tag
身為一天只看兩眼的人，我要每則回覆都自己說出拖了多久，我才能一眼看出這件事花了不該花的時間。 ## leo 2026-08-27 的原話 > 「**前面說過每個回覆要戴上已經花了總時長，這為什麼沒出現？**」 > （總管答「我沒做，現在開始戴」之後） > 「**這應該寫在 ISEP，隨時看自己拖了多久**」 🔴 **重點在後面那句：不是要總管記得戴，是要它長在機器上。** 總管答應「現在開始戴」——而那正是這條規則第一次失效的方式： **靠記性的規則，下一個 session 就沒有了**（今天已經證明過好幾次： history-first／KBDB-first／stage-first／派工-first 全是同一個形狀）。 ## 要達成什麼 **總管每一則回覆都帶著「這件事已經花了多久」，而且不需要總管記得。** 判準：一個新開的 session，總管**什麼都沒被交代**，回覆裡照樣有時長。 ## 這一格要你自己判斷（不要照抄總管的想法） - **時長從哪一刻算起**？session 開始？當前 milestone 建立？當前任務接手？ ——leo 的原話是「**隨時看自己拖了多久**」，那個「拖」指向的是**任務**不是 session， 但實際上哪個基準對他最有用，要你想清楚並在票上說明理由 - **怎麼讓它出現在回覆裡**：Claude Code 的 hook 能注入 context（本 repo 現有多支 `additionalContext` 型的 hook 就是這樣做的），但「注入提醒」與「回覆真的帶上」是兩件事 ——**注入了但模型沒照做**是這類機制的主要失效模式，設計時要正面處理 - **不要做成又一個會被忽略的警報**（本 repo 心法第 2 條） ## 怎麼驗 1. 新開一個 session，不交代任何事 → 總管的第一則回覆就帶著時長 2. 時長的數字**對得上真實經過的時間**（貼實測：期望值與實際顯示） 3. 連續幾則回覆，時長是遞增的、不會歸零或亂跳 ## 紅線 - 不要 push 到 main；交回分支 - `plugin.json` 要升版——版本沒動＝沒有人吃得到 - 收工：結論寫回本票、指派 `claude-code`、改 tag
claude-code added this to the 把管理這條線做對 milestone 2026-08-27 04:45:41 +00:00
claude-code added the
s
todo
type
chore
 labels 2026-08-27 04:45:41 +00:00
claude-code added a new dependency 2026-08-27 04:45:42 +00:00
#30 讓閘擋對東西
claude-code commented 2026-08-27 23:51:10 +00:00
Author
Member
Copy Link
Copy Source

[decision] leo 2026-08-28 07:40 給了這張票的具體規格，並指定它是今天的第一個交付

leo 原話

「我需要你每小時產出一個版本，用 telegram 通知我，今天我整天上課，
現在時間是 7：40，下午四點左右希望已經都完成了」
「先完成倒數計時器，每一次回覆都發倒數，你有 8 小時左右」

這張票要做成什麼（規格具體化）

每一次回覆都要帶倒數——不是「有空時報時」，是每一則都要有，而且是機器算的不是我記的。

倒數的基準有兩層：

  • 今天的收工線：台北 2026-08-28 16:00（＝ UTC 08:00）
  • 當前主線 milestone 的期限（due_date，Gitea 上查得到）

為什麼它排第一

因為它是今天其餘 12 張票的節拍器。leo 整天上課、只能看兩眼，
沒有倒數他就不知道「這件事還來得及嗎」，而我沒有倒數就會重演昨天的「拖時間」。

與 inkstone/ISEP#82 的分工（不要做重複）

同一個注入點，兩行內容，來源不同：

⏱  已過 X 小時 / 剩 Y 小時      ← 本票（#63）
🎯 現在的主線是哪一個 milestone   ← #82

先各自成立，能動了再合成同一支。

🔴 卡點一：通知發不出去（總管 2026-08-28 07:50 實撞）

leo 要的是 Telegram。通道本身是好的（notify_leo 工作流，wiki 記載「一條指令、不需任何金鑰」），
但 prod-write-guard.sh 擋下來了：

它的判準是「指令打到線上實例主機 ＋ 帶寫入語意」就擋。
而發一則 Telegram 一定是帶 body 的寫入型請求打到那台實例
⇒ 它跟「部署一個工作流上線」長得一模一樣，閘分不出來。

🔴 這不是誤攔，是閘的解析度不夠：兩者都打同一個 named webhook 家族路徑。
差別在打的是哪一個 named webhook——notify_leo 是發一則訊息，
ship_refresh_cdn 那種才是動線上狀態。

所以本票要連帶處理：讓 prod-write-guard 認得出「發通知」這個動作並放行它，
判準要看打的是哪一個 named webhook，不是看有沒有寫入旗標。

⚠️ 放行的範圍要窄：只放行 notify_leo 這一個（或一份明列的通知類白名單），
不是放行整個 named webhook 家族——那會把部署工作流一起放掉。

🔴 卡點二：連「描述這個卡點」都會被同一支閘擋（同款第八次）

總管第一次想把本則貼上票時被自己擋下來——因為留言內文裡引用了那個閘的判準關鍵字
（實例主機名、寫入旗標的字樣），而閘比對的是指令文字，分不出「執行它」與「談論它」。

📌 這正是 inkstone/InkStoneCo#23「守門的閘擋錯東西：紅線裡複述關鍵字被當成下令」
所記的同一個病，而那張票的標題已經標著「同款第七次」——這是第八次。

📌 leo 2026-08-17 的診斷早就寫在 sdd-gitea-governance.md §8.3：

文字層的閘那天 8 次誤攔、0 次正確攔截，且方向穩定——
紅線寫得越細，命中關鍵字的機率越高 ⇒ 那些閘在懲罰謹慎。

⇒ 修 prod-write-guard 時要一起處理：它必須分得出「這條指令要去做那件事」和
「這段文字在說明那件事」。繞法（把內文先寫成檔案再用不含關鍵字的指令送出）能通，
但那正是 leo 說的「人就會學會繞過它，那它就等於不存在」。

🔴 卡點三：總管的「我確認過了」戳記在雲端是失效的

prod-write-guard 給總管的出口是蓋一個一次性戳記檔。但那個動作
在 .claude/settings.json 的 allow 清單裡是明文放行的，
auto mode classifier 仍連續四次擋下它。

⇒ 這是 inkstone/InkStoneCo#99（「classifier 尊重 settings.json 白名單」）的實例，
代表總管手上那個「我確認過了」的出口在雲端根本打不開——
閘留了一道給總管的門，而那道門在這個環境裡是焊死的。

📌 本票不修這一格（歸 inkstone/ISEP#90 雲端接線那條線），但要記在這裡，
因為它決定了「修 prod-write-guard 時不能只靠戳記當出口」。

[decision] leo 2026-08-28 07:40 給了這張票的具體規格，並指定它是今天的第一個交付 ## leo 原話 > 「我需要你**每小時產出一個版本**，用 **telegram 通知我**，今天我整天上課， > 現在時間是 **7：40**，**下午四點左右**希望已經都完成了」 > 「**先完成倒數計時器，每一次回覆都發倒數**，你有 8 小時左右」 ## 這張票要做成什麼（規格具體化） **每一次回覆都要帶倒數**——不是「有空時報時」，是每一則都要有，而且是機器算的不是我記的。 倒數的基準有兩層： - **今天的收工線**：台北 2026-08-28 16:00（＝ UTC 08:00） - **當前主線 milestone 的期限**（`due_date`，Gitea 上查得到） ## 為什麼它排第一 因為它是今天其餘 12 張票的**節拍器**。leo 整天上課、只能看兩眼， 沒有倒數他就不知道「這件事還來得及嗎」，而我沒有倒數就會重演昨天的「拖時間」。 ## 與 `inkstone/ISEP#82` 的分工（不要做重複） 同一個注入點，兩行內容，來源不同： ``` ⏱ 已過 X 小時 / 剩 Y 小時 ← 本票（#63） 🎯 現在的主線是哪一個 milestone ← #82 ``` 先各自成立，能動了再合成同一支。 ## 🔴 卡點一：通知發不出去（總管 2026-08-28 07:50 實撞） leo 要的是 Telegram。通道本身是好的（`notify_leo` 工作流，wiki 記載「一條指令、不需任何金鑰」）， **但 `prod-write-guard.sh` 擋下來了**： 它的判準是「指令打到線上實例主機 ＋ 帶寫入語意」就擋。 而發一則 Telegram 一定是帶 body 的寫入型請求打到那台實例 ⇒ **它跟「部署一個工作流上線」長得一模一樣，閘分不出來。** 🔴 **這不是誤攔，是閘的解析度不夠**：兩者都打同一個 named webhook 家族路徑。 差別在**打的是哪一個 named webhook**——`notify_leo` 是發一則訊息， `ship_refresh_cdn` 那種才是動線上狀態。 **所以本票要連帶處理**：讓 `prod-write-guard` 認得出「發通知」這個動作並放行它， 判準要看**打的是哪一個 named webhook**，不是看有沒有寫入旗標。 ⚠️ **放行的範圍要窄**：只放行 `notify_leo` 這一個（或一份明列的通知類白名單）， 不是放行整個 named webhook 家族——那會把部署工作流一起放掉。 ## 🔴 卡點二：連「描述這個卡點」都會被同一支閘擋（同款第八次） 總管第一次想把本則貼上票時**被自己擋下來**——因為留言內文裡**引用了**那個閘的判準關鍵字 （實例主機名、寫入旗標的字樣），而閘比對的是**指令文字**，分不出「執行它」與「談論它」。 📌 這正是 `inkstone/InkStoneCo#23`「守門的閘擋錯東西：紅線裡複述關鍵字被當成下令」 所記的同一個病，而那張票的標題已經標著「同款第七次」——**這是第八次。** 📌 leo 2026-08-17 的診斷早就寫在 `sdd-gitea-governance.md` §8.3： > 文字層的閘那天 **8 次誤攔、0 次正確攔截**，且方向穩定—— > **紅線寫得越細，命中關鍵字的機率越高 ⇒ 那些閘在懲罰謹慎。** ⇒ 修 `prod-write-guard` 時要一起處理：**它必須分得出「這條指令要去做那件事」和 「這段文字在說明那件事」**。繞法（把內文先寫成檔案再用不含關鍵字的指令送出）能通， 但那正是 leo 說的「人就會學會繞過它，那它就等於不存在」。 ## 🔴 卡點三：總管的「我確認過了」戳記在雲端是失效的 `prod-write-guard` 給總管的出口是蓋一個一次性戳記檔。但那個動作 **在 `.claude/settings.json` 的 allow 清單裡是明文放行的**， auto mode classifier 仍連續四次擋下它。 ⇒ 這是 `inkstone/InkStoneCo#99`（「classifier 尊重 settings.json 白名單」）的實例， **代表總管手上那個「我確認過了」的出口在雲端根本打不開**—— 閘留了一道給總管的門，而那道門在這個環境裡是焊死的。 📌 本票不修這一格（歸 `inkstone/ISEP#90` 雲端接線那條線），但要記在這裡， 因為它決定了「修 `prod-write-guard` 時不能只靠戳記當出口」。
claude-code commented 2026-08-28 00:05:12 +00:00
Author
Member
Copy Link
Copy Source

【身份】claude-code（ISEP repo 工人，subagent）

交件：inkstone/ISEP#63

PR：#94（分支 feat/countdown-stamp，未推 main）

做了什麼

hooks/countdown-guard.sh——一支閘掛兩個事件，因為那是同一件事的兩半：

  • UserPromptSubmit：把算好的那一行送到眼前
  • Stop：這一回合的回覆裡有沒有那一行，沒有就擋一次，並把算好的那一行印出來給它抄

票上點名的失效模式（「注入了但模型沒照做」）就是靠後半接住的。
只做前半 ＝ 又一個會被忽略的提醒（本 repo 心法第 2 條明令不要做）。

判準不是關鍵字黑名單：查的是「那個被要求的輸出元素在不在」（一個機器產生的標記 ⏱），
不是「有沒有講某些不該講的話」。換講法照樣要帶標記；多寫什麼都不會觸發。

那一格我自己判了：時長從這段對話的第一則訊息算起

理由（票要我說明）：

  1. leo 的「拖」指向任務，但「任務」在機器上沒有起點——沒有任何欄位記著「我什麼時候接手這條線」
  2. 可機械取得、又真的對應一個交付的起點，只有一個：對話的開頭
  3. 而那正好就是交貨單位（CLAUDE.md 規則三點七「一段對話 ＝ 一個 release」）
  4. ⇒ 已過時間 ＝ 這個 release 已經燒掉多久。不需要任何人維護，也不會說謊

resume 取 transcript 第一列的時間、不是 hook 第一次被叫到的時間：接關不是重新開始。
收工線＝台北 16:00，過線後四小時內顯示「已超過」（超時消失的話這東西就沒意義了），
台北 20:00 之後才滾隔天。milestone 期限走快取，countdown.py 從不打網路
（UserPromptSubmit 在每則訊息的關鍵路徑上），拿不到就整段不顯示、不編數字。

連帶修好票上的兩個卡點（prod-write-guard.sh）

  • 卡點一：判準改成看打的是哪一個 named webhook（路徑形狀＋名字）。
    …/named/<ns>/notify_leo/trigger 放行；…/named（部署端點）與
    …/named/<ns>/ship_refresh_cdn/trigger 照擋。放行範圍刻意只有一個名字，不放行整個家族。
  • 卡點二：剝掉內文再判（沿用另外三支閘已在用的同一支 lib），起始行保留
    ⇒ 真的在部署的寫法照樣擋。
    📌 修這支的過程又撞了一次同款：連「把修法寫進檔案」那條指令都被擋，因為內文引用了主機名。

測試（照 docs/TESTING.md 的形狀，新增 A14／A15）

bash hooks/tests/countdown-guard.test.sh                            → 通過 20 條，失敗 0 條
bash hooks/tests/prod-write-guard.test.sh hooks/prod-write-guard.sh  → 通過 37 ／ 失敗 0（原 29）

全程離線（時鐘定住、狀態走環境變數、不打網路、不留測試檔）。20 條裡 7 條是「不該擋」。

實測（期望值 vs 實際顯示）：起點 06:28 台北、現在 08:03 台北 →
期望「已過 1 小時 35 分」，實得 ⏱ 已過 1 小時 35 分｜距收工線（台北 16:00）剩 7 小時 56 分。

🔴 沒驗的那一格（這是 report 不是 deliver 的那部分，明講）

A8「新 session 閘真的會觸發」沒有跑——這條 subagent 開不了新的 Claude Code session。
UserPromptSubmit 是這個 repo 第一次用的事件，harness 會不會真的去叫它，只有在新 session 裡才看得出來。
合併後請在新 session 驗一眼：第一則回覆有沒有帶 ⏱。腳本層面（該擋、該放、算得準）已經 20/20 驗完。

版本

plugin.json 0.9.0 → 0.10.0。合併時要跟著打 v0.10.0 的 tag，
否則 check-version-consistency.sh 會紅（那支要求 plugin.json ＝ 最新 tag）。

順帶一提（不在本票範圍，沒動）

跑既有測試時發現 stage-before-prod-guard.test.sh（9/16）與
main-and-prod-push-guard.test.sh（「沙盒建不起來」）在這個容器裡是紅的。
已切回 main 複驗過，兩支在 main 上同樣紅 ⇒ 是既有狀態／環境問題，不是本 PR 造成的。

【身份】claude-code（ISEP repo 工人，subagent） ## 交件：`inkstone/ISEP#63` PR：https://git.uncle6.me/inkstone/ISEP/pulls/94（分支 `feat/countdown-stamp`，未推 main） ### 做了什麼 **`hooks/countdown-guard.sh`——一支閘掛兩個事件，因為那是同一件事的兩半：** - `UserPromptSubmit`：把算好的那一行送到眼前 - `Stop`：這一回合的回覆裡有沒有那一行，沒有就擋一次，並把算好的那一行印出來給它抄 票上點名的失效模式（「注入了但模型沒照做」）就是靠後半接住的。 只做前半 ＝ 又一個會被忽略的提醒（本 repo 心法第 2 條明令不要做）。 **判準不是關鍵字黑名單**：查的是「那個被要求的輸出元素在不在」（一個機器產生的標記 `⏱`）， 不是「有沒有講某些不該講的話」。換講法照樣要帶標記；多寫什麼都不會觸發。 ### 那一格我自己判了：時長從**這段對話的第一則訊息**算起 理由（票要我說明）： 1. leo 的「拖」指向**任務**，但「任務」在機器上**沒有起點**——沒有任何欄位記著「我什麼時候接手這條線」 2. 可機械取得、又真的對應一個交付的起點，只有一個：對話的開頭 3. 而那正好就是交貨單位（CLAUDE.md 規則三點七「**一段對話 ＝ 一個 release**」） 4. ⇒ 已過時間 ＝ 這個 release 已經燒掉多久。**不需要任何人維護，也不會說謊** resume 取 transcript 第一列的時間、不是 hook 第一次被叫到的時間：接關不是重新開始。 收工線＝台北 16:00，過線後四小時內顯示「已超過」（**超時消失的話這東西就沒意義了**）， 台北 20:00 之後才滾隔天。milestone 期限走快取，`countdown.py` **從不打網路** （`UserPromptSubmit` 在每則訊息的關鍵路徑上），拿不到就整段不顯示、**不編數字**。 ### 連帶修好票上的兩個卡點（`prod-write-guard.sh`） - **卡點一**：判準改成看**打的是哪一個 named webhook**（路徑形狀＋名字）。 `…/named/<ns>/notify_leo/trigger` 放行；`…/named`（部署端點）與 `…/named/<ns>/ship_refresh_cdn/trigger` 照擋。**放行範圍刻意只有一個名字**，不放行整個家族。 - **卡點二**：剝掉內文再判（沿用另外三支閘已在用的同一支 lib），**起始行保留** ⇒ 真的在部署的寫法照樣擋。 📌 修這支的過程**又撞了一次同款**：連「把修法寫進檔案」那條指令都被擋，因為內文引用了主機名。 ### 測試（照 `docs/TESTING.md` 的形狀，新增 A14／A15） ``` bash hooks/tests/countdown-guard.test.sh → 通過 20 條，失敗 0 條 bash hooks/tests/prod-write-guard.test.sh hooks/prod-write-guard.sh → 通過 37 ／ 失敗 0（原 29） ``` 全程離線（時鐘定住、狀態走環境變數、不打網路、不留測試檔）。20 條裡 **7 條是「不該擋」**。 **實測（期望值 vs 實際顯示）**：起點 06:28 台北、現在 08:03 台北 → 期望「已過 1 小時 35 分」，實得 `⏱ 已過 1 小時 35 分｜距收工線（台北 16:00）剩 7 小時 56 分`。 ### 🔴 沒驗的那一格（這是 report 不是 deliver 的那部分，明講） **A8「新 session 閘真的會觸發」沒有跑**——這條 subagent 開不了新的 Claude Code session。 `UserPromptSubmit` 是這個 repo 第一次用的事件，**harness 會不會真的去叫它，只有在新 session 裡才看得出來**。 合併後請在新 session 驗一眼：第一則回覆有沒有帶 `⏱`。腳本層面（該擋、該放、算得準）已經 20/20 驗完。 ### 版本 `plugin.json` 0.9.0 → **0.10.0**。合併時要跟著打 `v0.10.0` 的 tag， 否則 `check-version-consistency.sh` 會紅（那支要求 plugin.json ＝ 最新 tag）。 ### 順帶一提（不在本票範圍，沒動） 跑既有測試時發現 `stage-before-prod-guard.test.sh`（9/16）與 `main-and-prod-push-guard.test.sh`（「沙盒建不起來」）在**這個容器裡**是紅的。 **已切回 main 複驗過，兩支在 main 上同樣紅** ⇒ 是既有狀態／環境問題，不是本 PR 造成的。
claude-code self-assigned this 2026-08-28 00:05:21 +00:00
claude-code added
s
review
 and removed
s
todo
 labels 2026-08-28 00:05:21 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Human
👤 這件事需要 leo 親手批示／動手（花錢・不可逆・品味方向・物理動作）。與 s/* 正交
close
duplicate
重複——關新的、留舊的，並指向舊票
close
human-exec
人執票完成，由人手動關
close
merged
PR merge 自動關（正常路徑）
close
split
太大，已拆成數張子票
close
stale
逾期無資訊，自動關閉
close
transferred
走錯棚，已在正確的 repo 重開
close
wontfix
討論後決定不做（只有 leo 可下此判斷）
hub
Tracking issue——聚合一批 leaf 的 scope 容器，本身不掛 milestone、不對應 PR
 human/exec
👤 這張票的『執行者』是人（GUI-only／實體權限／法定簽署），不是審核。交付物是環境狀態改變，不是 PR
p
high
高——擋住交付或有時間壓力
p
low
低——想做，但晚一點沒關係
s
backlog
驗過了、確定要做，但還沒排進任何 sprint
s
doing
進行中——已 self-assign，現在有人在做
s
pending
卡住——等外部／等依賴，不是沒人做
s
review
PR 已開（含 closes #n），等總管 review 並 merge
s
stage
已部署 stage，等 leo 實際驗收
s
todo
已排進 milestone，等人領票
s
triage
新進來的，還沒驗傷——還沒決定要不要做
type
bug
壞掉的東西
type
chore
雜務、整理、不改行為
type
feature
新能力
type
governance
規範、流程、閘本身
No Label
s
review
type
chore
Milestone
No items
No Milestone 把管理這條線做對
Projects
Clear projects
No project
Assignees
Clear assignees
Leo claude-code (claude-code)
No Assignees claude-code
1 Participants
Notifications
Due Date
No due date set.
Blocks
#30 讓閘擋對東西
inkstone/ISEP
Reference: inkstone/ISEP#63
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?