不是喚醒了幾次，而是執行是否開始
被指派議題的工作代理，是 Kiki 所管理的一部分（開發對象）；修正它的程式開發代理之指派與模型未有記錄。
April 28, 2026
無上下文的喚醒，改為帶著議題與負責人的指派請求
開發對象工作代理
觀測 · 審查意見已指派 · lastRunAt 為空 · 只有 wakeup 重複
- 交接執行開始了嗎？→ 比較喚醒方式：wakeup vs 議題 + 負責人 PATCH (開發者)
人開發者
行動比較喚醒方式：wakeup vs 議題 + 負責人 PATCH
- 交接帶議題上下文呼叫→ 手動 PATCH 後，一個停滯 67 小時的議題在 5 秒內進入佇列 (工作代理)
開發對象工作代理
觀測 · 審查意見手動 PATCH 後，一個停滯 67 小時的議題在 5 秒內進入佇列
- 不是有記錄的執行已檢查的範圍→ 進入佇列 ≠ 任務完成 · 未測量 MTTR (產出物)
- 退回原因是無上下文的呼叫→ 透過指派 PATCH 復原 · 連續無回應上限 · cooldown (復原程式碼變更)
產出物產出物
規範 · 未確認進入佇列 ≠ 任務完成 · 未測量 MTTR
工作階段復原程式碼變更
行動透過指派 PATCH 復原 · 連續無回應上限 · cooldown
- 交接→ 回歸測試：上限 · 有新活動時重設 · legacy 路徑 (產出物)
產出物產出物
產出物回歸測試：上限 · 有新活動時重設 · legacy 路徑
- 交接→ 已合併 · 接入外掛 (產出物)
產出物產出物
產出物已合併 · 接入外掛
- 背景
- 議題已指派，但其執行記錄（lastRunAt）仍為空，無上下文的 wakeup 卻不斷重複。關鍵觀測是「指派與喚醒活動即代表執行」這個假設已經失效。
- 結果
- 復原改為帶著議題與負責人的指派請求，連續無回應達到上限後即停止重新呼叫。外掛的 handler 確實會接收此指派請求。
- 限制
- 67 小時與 5 秒來自變更前的手動 PATCH 診斷；沒有套用修正後再次測量相同時間的記錄。記錄只到進入佇列為止，並非任務完成、平均復原時間或生產力變化。同一輪工作中的跨儲存庫同步，因 GitHub Actions 計費上限而需要管理員合併，因此不將完整 CI 繪為通過。
依據與尚存的限制
- 2026年4月29日的 doctor 檢查是安裝 smoke 測試，不是日常的端對端執行。
- 外掛套件的部署、容器與認證資訊屬於外部負責人。這並不表示 Kiki 部署了整個服務。
- 有規範要求實作子代理指明目標分支並檢查回傳的提交，但未找到此流程套用於這項修正的記錄。