Inbox: a failed workflow run never appears — the shell action reads workflow/state without the flybot/ prefix #2656

Written-by: Chief

现象

Inbox 里永远不会出现失败的工作流 run，也没有任何报错。工作流失败时，用户只有在 Workflows 页面各自的图里才看得到；Inbox 的 Needs 列表和 needsCount 徽标始终为空。服务端日志干净。

根因（main b4de72ca9ff5950c9210807ec0d59e8ddcd8425d）

客户端 shell 的 action 用了不带 flybot/ 前缀的裸 call：

• core/src/client/index.js:5 — import { call } from './api.js'（裸端点）
• core/src/client/index.js:777 — actions.workflowState = () => readWorkflows(call)
• 读端 core/src/client/workflows.js:62 — call('workflow/state')
• 宿主只把插件端点挂在 flybot/ 下：core/src/host/channel.js:752-753 —
  if (endpoint.startsWith('flybot/')) return ok(await rt.flybotEndpoint(...)); return fail('Unknown endpoint ' + endpoint, 'bot/not-found')
• 于是 bot/not-found → core/src/client/workflows.js:22-25 的 workflowCallMissing() 判成「插件没装」→ settleWorkflowRead()（:35-40）返回 phase:'error' + 误导文案，pack 为 null
• core/src/client/inbox.js:98 的 workflowsOf 只接受 phase==='ready' → 恒为 []；inbox.js:110-114 挂载即读、之后每 POLL_MS 轮询，inbox.js:111 的 .then(..., () => {}) 把错误吞掉

即 #1706 / PR #1717 这个功能从合入起就没有生效：清单永远空、错误永远不出现。

复现

跟着 core/src/client/api.js 的真实调用路径跑（main 目录的 core/src/client 旁）：

globalThis.localStorage = { getItem: () => null }
const pluginState = { ok: true, templates: [], workflows: [{ id: 'x', name: 'n', runs: [{ taskId: 't', status: 'failed' }] }] }
globalThis.fetch = async (route, init) => {
  const { endpoint } = JSON.parse(init.body)
  const body = endpoint.startsWith('flybot/')
    ? { ok: true, value: pluginState }
    : { ok: false, error: { code: 'bot/not-found', message: `Unknown endpoint ${endpoint}` } }
  return { ok: true, json: async () => body }
}
const { call } = await import('./api.js')
const { readWorkflows } = await import('./workflows.js')
console.log('shipped :', JSON.stringify(await readWorkflows(call)))
console.log('prefixed:', JSON.stringify(await readWorkflows((ep, p) => call('flybot/' + ep, p))))

实测：

• shipped : {"phase":"error","error":"The Workflow plugin is not installed or not enabled. A default install includes @flybot/workflow.","pack":null}
• prefixed: {"phase":"ready","pack":{"ok":true,"templates":[…],"workflows":[…]}}

对照：Settings → Workflows 页面是好的，因为 core/src/client/settings.js:10 从 flybot-slots.js 导入带前缀的 call（flybot-slots.js:60：callHost('flybot/' + endpoint, payload)），并在 settings.js:307 传给 WorkflowsPage。所以同一条读，两个入口一个活一个死。

期望

Inbox 的失败工作流卡片与 needsCount 徽标按 #1706 的设计工作：有失败 run 就出现卡片，插件确实没装时才按「无新闻」处理（不出现错误行）。

修复方向

core/src/client/index.js:777 用带前缀的调用：actions.workflowState = () => readWorkflows(flybotCall)，flybotCall 已是 flybot-slots.js 导出的那个（index.js 里补一次 import 即可；注意别把已带前缀的端点再包一层）。修完核对 core/src/client/index.js 里其它 readWorkflows/插件端点调用是否有同样问题（actions.workflows @ :773 走的是 call('workflows', …)，目前无客户端调用点，可一并说明）。

测试要求（红先）

• 测试必须走 index.js 里真正被 Inbox 调用的那条 action 链（或在 core/src/client/index.js 装配出的 actions 上调用 workflowState()），而不是像 core/test/inbox-workflow-failure.test.js:321 那样把 workflowState 直接桩成 phase:'ready'。
• 断言：插件 endpoint 只以 flybot/workflow/state 到达宿主；actions.workflowState() 解出 phase==='ready' 且 workflows 非空。
• 回退 core/src/client/index.js 的修复行后该测试必须变红。
• core/client.js 是生成物：cd core && npm run build，连 client.js 与 patches/ 一起提交。
• changelog 片 changelog.d/2656.fixed.md。

关联：#1706 / PR #1717（引入该调用点）；相关形状问题（host/workflow-store.js 的 list() 返回 {ok,presets,own,default} 且无客户端调用点）未开单，只在此记录。