schedule cannot activate outside the web bundle: pending (waiting for service: sessionController)

[shujie2015-a11y]

环境

master 477b4f4205（= tag dsh-v0.1.7-rc.2），macOS，node v24.19.0。

复现

任何不含 web 层的 profile 挂上官方 opt-in 的 schedule 行即复现（以 headless 为例）：

- insert:
    - id: schedule
      name: '@deepseek-ai/dsh-schedule'

然后 dsh --profile headless "reply with OK"，stderr：

dsh: warning: 1 entry did not activate
schedule (@deepseek-ai/dsh-schedule): pending (waiting for service: sessionController)

同一行在 web profile 无告警（web 提供该服务）。

根因

1. rc.2 把 schedule 由函数插件改为 Service 类：packages/schedule/schedule/src/index.ts:100-101
static inject = ['agents','sessions','tools','storageDomain','sessionController','sessionPersistence']。
   alpha.2（tag 00102833）同文件是 export const inject = ['agents','sessions','tools','sessionPersistence']——无 sessionController。
   引入提交：7a362b263b（PR Bug 报告：(1) spill 截断标记已写入但完整内容仍被持久化；(2) 超长工具结果未计入上下文计量，误导问题排查 #4335 feat/schedule-storage-phase1）。
2. sessionController 全仓唯一提供者 packages/api/session-controller/src/index.ts:136，
   只有 web bundle 挂：packages/bundle/web-app/cordis.patch.yml:102-103；
   grep -rn sessionController packages/bundle 在 base/tui-app 零命中。
3. ⇒ 非 web 组合挂该行恒 pending，schedule_create/list/delete 三工具消失（不阻断启动）。

影响面

出厂 tui/headless bundle 不含该行（默认无感）；web 面 rc.2 已自行 disabled: true
（web-app/cordis.patch.yml:125-128，提交 cad6fef2fd）。仅手工在非 web profile 挂该行的用户中招。

请确认/建议

• (a) 若有意 web-only：请在 schedule README 的 Known Limitations 写明「需 web 层的 sessionController」；
• (b) 若非 web 面也应可用：补等价 Session 恢复能力，或把 sessionController 改为可选注入；
• 不建议让用户自行补挂 @deepseek-ai/dsh-api-session-controller——实测它自身
  pending (waiting for services: fileUploads, workspaceRegistry)，需连带整串 web API 行。

[PerryLink]

你的三点根因我逐条核过了，全部成立——而且我还发现一个更尖锐的地方

你给的环境就是当前最新的那棵树（477b4f4205 = dsh-v0.1.7-rc.2），我按你给的路径逐条对：

你的论断	核对结果
rc.2 把 schedule 改成 Service 类，inject 里多了 sessionController	✅ packages/schedule/schedule/src/index.ts:101：static inject = ['agents', 'sessions', 'tools', 'storageDomain', 'sessionController', 'sessionPersistence']
sessionController 唯一提供者	✅ packages/api/session-controller/src/index.ts:136：super(ctx, 'sessionController', { namespace: 'session' })
只有 web bundle 挂它	✅ packages/bundle/web-app/cordis.patch.yml:102-103（id: session-controller / @deepseek-ai/dsh-api-session-controller）；packages/bundle 下再没有第二个
⇒ 非 web 组合挂该行恒 pending	✅ 结论成立（pending (waiting for service: sessionController)），且不阻断启动

那个更尖锐的地方（建议你在报告里加一句）

你写"web 面 rc.2 已自行 disabled: true"——我核到了，就是 packages/bundle/web-app/cordis.patch.yml:125-127：

- id: schedule
  name: '@deepseek-ai/dsh-schedule'
  disabled: true

把这两件事放在一起看，结论比"非 web 面不可用"更难看：

sessionController 只在 web bundle 里存在，而 schedule 这一行恰恰在 web bundle 里被默认 disabled: true。

⇒ 也就是：按出厂配置，schedule 在任何组合里都不会以启用状态出现；而用户一旦手工启用它，就只能在没有 sessionController 的（非 web）组合里启用——因为唯一有该服务的组合把这一行关掉了。这不是"少写了一处挂载"，而是两个决定互相抵消。

我认为这句话能显著提高你这条报告的优先级，建议放在"根因"小节末尾。

对你两个选项的回应

• (a) 写进 Known Limitations：这是最低成本且必要的一步，我支持。但要写清"需要 web 层的 sessionController"，而不是笼统写"需要 web"——因为读者要能据此判断自己能不能用。
• (b) 让非 web 面也能用：更根本。你给的两个方向里，**"把 sessionController 改为可选注入"**比"补等价 Session 恢复能力"现实得多（后者等于在非 web 面重建一套会话控制器）。不过要先回答一个设计问题：schedule 到底是不是 web-only 功能？ 如果是，就选 (a)；如果不是，就得先说明它在无 web 时的会话归属语义。
• 你不建议用户自行补挂 @deepseek-ai/dsh-api-session-controller——这个判断我同意，应当保留在报告里（它会诱导用户去挂一个面向 web 传输层的 API 服务，属于错误的自救路径）。

一点补充建议

把复现收敛成一条可粘贴的最小 profile（你已经给了 headless 的那个 insert 片段，很好），并附上 dsh --profile headless --dump-config 里 schedule 那一行的最终状态——这样维护者不用重建环境就能确认 inject 与提供者缺失的组合。

这条报告的完成度很高：机制、引入提交、唯一提供者、影响面、诉求都齐了，我唯一补的就是上面那个"两个决定互相抵消"的观察。

[shujie2015-a11y]

谢谢 @PerryLink 的逐条核对，尤其「两个决定互相抵消」这处——唯一提供 sessionController 的 web bundle 又把 schedule 那行 disabled: true，所以出厂配置下 schedule 在任何组合里都不会以启用状态出现；我认同这条并进根因更准确。

本机临时处置（不自行补挂 @deepseek-ai/dsh-api-session-controller）：~/.dsh/profiles/{tui,headless}/cordis.patch.yml 里 schedule 行已摘掉、原位留注释指向本条讨论，等结论再决定是否挂回。

想请维护者给一个明确答案：schedule 是否按设计只在 web 面可用？

• 是 ⇒ 按 (a) 写进 Known Limitations（写明「需 web 层的 sessionController」）即可，我这边保持现状；
• 否 ⇒ 倾向 (b) 中成本较低的「sessionController 改为可选注入」；补一套非 web 的会话控制器代价过大，且需先说明无 web 时 schedule 的会话归属语义。

最小复现（headless 的 insert 片段）与 --dump-config 里该行的最终状态见正文。