不看唤醒了多少次，而看运行是否已开始
被分配 issue 的工作智能体属于 Kiki 所管理的对象（开发对象）；修复它的编程智能体的分配与模型没有记录。
April 28, 2026
无上下文的唤醒，改为携带 issue 与负责人的分配请求
开发对象工作智能体
观测 · 审查意见已分配 · lastRunAt 为空 · 只有 wakeup 重复
- 交接运行是否已开始？→ 比较唤醒方式：wakeup 对比 issue + 负责人 PATCH (开发者)
人开发者
行动比较唤醒方式：wakeup 对比 issue + 负责人 PATCH
- 交接携带 issue 上下文调用→ 手动 PATCH 后，停滞 67 小时的一个 issue 在 5 秒内排入队列 (工作智能体)
开发对象工作智能体
观测 · 审查意见手动 PATCH 后，停滞 67 小时的一个 issue 在 5 秒内排入队列
- 不是记录在案的执行已检查的范围→ 已排队 ≠ 任务完成 · 未测量 MTTR (产物)
- 退回原因在于无上下文的调用→ 通过 assignment PATCH 恢复 · 连续无响应上限 · 冷却期 (恢复代码变更)
产物产物
规范 · 未确认已排队 ≠ 任务完成 · 未测量 MTTR
工作会话恢复代码变更
行动通过 assignment PATCH 恢复 · 连续无响应上限 · 冷却期
- 交接→ 回归：上限 · 新活动时重置 · legacy 路径 (产物)
产物产物
产物回归：上限 · 新活动时重置 · legacy 路径
- 交接→ 已合并 · 接入插件 (产物)
产物产物
产物已合并 · 接入插件
- 背景
- issue 已经分配，但其运行记录（lastRunAt）一直为空，只有无上下文的 wakeup 不断重复。关键观测在于，“分配与唤醒活动即意味着运行”这一假设已经失效。
- 结果
- 恢复改为携带 issue 与负责人的分配请求，连续无响应达到上限后停止重新调用。插件 handler 确实会收到这一分配请求。
- 局限
- 67 小时和 5 秒来自变更前的手动 PATCH 诊断；没有在修复应用后重新测量同一时间的记录。记录止于排入队列，不代表任务完成、平均恢复时间或生产力变化。同一轮工作中的跨仓库同步因 GitHub Actions 计费上限而需要管理员合并，因此未将完整 CI 画作通过。
依据与尚存的局限
- 2026年4月29日的 doctor 检查是安装冒烟测试，而非日常的端到端运行。
- 插件包的部署、容器和凭据归外部负责人所有。这并不意味着 Kiki 部署了整个服务。
- 有一条规范要求实现子智能体指明目标分支并核对返回的提交，但未找到该流程用于此次修复的记录。