2026-04-22

流程教訓：5 分鐘回報空轉

今日回看 long-task watchdog repair 事件，確認最後卡住的真正原因不是技術 blocker，而是假進度空轉。
具體表現：checkpoint / watchdog 催辦持續送達，但 long task 本體沒有新的檔案變更、驗證輸出、決策產出或 blocker 狀態改變。
當時實際新增內容只剩：
- 更新 lastMilestoneAt
- 更新 lastObservedActivityAt
- 回應 reminder / watchdog 催辦
- 重複回報「仍無新證據」
已確認以上都不應再被視為 long task 新進展。
因此今日已把規則正式補入 WORKFLOW.md：
- No-Fake-Progress Rule
- Long Task Stop-Clock Gate
新規則重點：
- 狀態同步不算進度
- 連續 3 次 checkpoint 無新證據即視為空轉 / 停滯
- 一旦空轉，必須改判 paused / blocked，或停止週期性續報，不得再靠 reminder / watchdog 續命

今日確認 /tmp/fileXXXXXX 樣本至少有一批是真正可執行 ELF binary。
已保留樣本：/home/alice/tmp-file-samples/filedOXXPd
驗證結果：
- 可直接執行
- --version 顯示 ls (GNU coreutils) 9.4
- 與 /usr/bin/ls 非同檔（hash 不同）
目前最準確判斷：
- 不是本機 /usr/bin/ls 被直接改掉
- 更像是某個外部程式 / 執行框架把自帶的 ls 落地到 /tmp/fileXXXXXX 後執行
尚未確認：到底是哪個程式 / runtime 建立了這批臨時執行檔
目前此案狀態：
- 流程面已修規則
- 技術面暫停，待新 session 繼續追查來源

第一階段已完成：skills/watchdog-discord-route/ 已自可用 skills 路徑移出，改封存到 disabled-skills/watchdog-discord-route/。
第二階段已完成：watchdog 相關殘留 docs / prompts / state / scripts 已集中移到 disabled-watchdog/。
看板中的 watchdog 相關進行中項目已自主列表移除，避免後續再被當成現行工作流入口。
目前保留方式：採封存而非硬刪除，之後若要追查舊設計或故障證據，仍可從封存區回看。

依總管指示，已避免直接修改 OpenClaw core / dist，改採可維護、可升級、可抽換的 skill 路線。
已新增 skills/long-task-governor/，內容包含：
- SKILL.md
- task-record-template.md
- checkpoint-template.md
- _meta.json
skill 目標：把 general_chat vs long_task 判準、狀態機、checkpoint 規格、no-fake-progress、stop-clock gate 收斂到外掛式 workflow layer。
已同步更新 WORKFLOW.md，要求：只要不是 ordinary single-turn general chat，就必須套用 long-task-governor。