feat(desktop): add experimental WorkHub orchestration

[ARE404]

Summary

This PR implements the experimental WorkHub proposal from #3253: one opt-in conversational entry point that can route across a user's existing work without requiring them to manage Sessions directly.

• adds a client-global WorkHub entry with durable Work state across Runtime Hosts and Workspaces
• routes explicit targets deterministically, resolves recent references and structured Work memory, and falls back to bounded semantic clarification
• creates and drives hidden Sessions while preserving ordinary Session navigation and a clear return path
• adds Work-aware message identity, filtering, anchor rail navigation, status, permission controls, notifications, model selection, Skills, slash commands, and attachments
• coordinates dependent work through the existing Agent Graph execution model
• keeps clarification resolution, retries, interaction handling, permission changes, and restart recovery idempotent

Validation

• npm run build — passed, including the production Desktop renderer build and third-party notice check
• Desktop suite — 1,079/1,079 passed, including the WorkHub Chinese routing, clarification, memory, graph, attachment, permission, title, and result-projection coverage
• Runtime Host suite — 1,045/1,045 passed when run independently; its root-suite failure was a parallel-run timeout
• Eval JavaScript suite — 75/75 passed; the subsequent Python contract tests are blocked on this machine because its Python does not support the repository's int | None syntax
• manual Desktop acceptance in Chinese with three independent Works covered explicit routing, pronouns, previous-focus routing, memory recall, ambiguity correction, filtered Composer behavior, anchor navigation, Session return, and an A → B dependency graph that completed 2/2 nodes

Experimental limitations

• when similar expressions have been corrected to different Works, the 13:03 routing baseline does not yet guarantee that the newest correction wins every strict WH-06 variant
• unrelated requests submitted while the previous Work is still actively running can still over-bind to the focused Work; sequential acceptance scenarios pass
• two renderer React feat: surface capability audit records #185 crashes were observed during long manual streaming runs; reloading restored the durable WorkHub state

Refs #3253

[Astro-Han]

I think the Hub direction is genuinely valuable. When several Sessions are active, remembering where each conversation lives and switching between them becomes work of its own. A permanent place where users can continue what they are doing without managing Session navigation would solve a real problem.

My concern is the size of the first architectural step, not the product direction.

The model described in #3286 can start fairly small. Hub sits above the existing Sessions and routes messages for the user. On this branch, a Work is still just { workspaceId, sessionId }. The underlying Session owns the working directory, model, permissions, transcript, execution, lifecycle, and recovery. There is no separate Work authority yet, and I am not sure the first version needs one.

The initial Hub could focus on a short loop:

• keep one permanent conversational entry;
• find or create the target Session;
• ask when the target is unclear;
• submit the Turn to that Session;
• show the result and let the user open the Session when needed.

That is already a useful product. It lets us test whether people can work across several Sessions without thinking about where every message should go.

The current PR goes much further. It adds durable Work blocks, structured routing memory, learned corrections, a separate coordination graph, a full WorkHub snapshot database, model and permission controls, attachments, colors, filters, Anchor Rail changes, metrics, and notifications. Some of these will probably be useful, but they do not all need to become part of the first contract.

The issue is not simply the 8,920 added lines. Each new representation becomes something we have to keep correct.

workhub.sqlite, for example, stores another copy of Turn status, final responses, routing state, and coordination state. Runtime Host and Session already own most of those facts, so this introduces synchronization and migration work early. The Hub view should be rebuilt from the Session catalog, Runtime events, transcripts, and pending interactions wherever possible. If a small amount of Hub-only state cannot be derived, we can persist that part without saving the whole UI snapshot.

Coordination has a similar issue. The PR describes it as using Agent Graph, but the implementation maintains its own nodes, edges, dependency scheduler, blocked state, stop behavior, and recovery logic while target Sessions run with orchestrationMode: 'default'. I would leave multi-Session coordination out of the first version. When we add it, it should use the Runtime Agent Graph instead of creating another graph authority.

Routing may also be trying to learn too much too early. During manual validation at 82e1a3f9, an unrelated payment-idempotency request was routed into the existing login-refresh Session. The local semantic score had already selected resume_work, so the bounded model router was skipped. For now, explicit selections, exact names, and unambiguous recent references can route directly. Everything else can ask the user. It is less automatic, but safer while we learn what users expect.

I would keep “Work” as product language rather than make it a domain type. In code, the target is a Session. Hub is a surface, a router, and a projection over Sessions. It does not need its own lifecycle, model, permission boundary, execution graph, or copy of Session history.

This still leaves room for a real Work entity later. If one user goal eventually needs to span several Sessions or Attempts and carry its own lifecycle, that will give us a concrete reason to introduce workId. We do not need to commit to that abstraction in the first implementation.

I would like to see the Hub experience land. My suggestion is to keep this branch as useful experimental evidence, then extract a smaller first PR around the Hub-to-Session routing loop. Richer routing, coordination, persistence, and UI features can follow separately once each has a responsibility that the existing Session and Runtime layers cannot own.

AI assistance disclosure: Codex was used to inspect the routing, persistence, Runtime Host, coordination, and renderer paths, run the documented Desktop validation, and help draft this comment.

中文版

我觉得 Hub 这个方向确实有价值。当多个 Session 同时存在时，记住每段对话在哪里、不断来回切换，本身就成了额外工作。如果有一个固定入口，用户可以直接继续手头的事情，不必管理 Session 导航，这解决的是一个真实问题。

我担心的是第一步的架构范围，不是 Hub 这个产品方向。

#3286 描述的模型可以从一个更小的版本开始。Hub 位于现有 Session 之上，替用户完成消息路由。目前这条分支里的 Work 仍然只是 { workspaceId, sessionId }。工作目录、模型、权限、对话记录、执行、生命周期和恢复都由底层 Session 负责。Work 还没有独立权威，我不确定第一版是否需要增加这一层。

第一版 Hub 可以先完成一个很短的闭环：

• 提供一个固定的对话入口；
• 找到目标 Session，或者创建一个普通 Session；
• 目标不明确时询问用户；
• 把 Turn 提交给该 Session；
• 展示结果，并允许用户在需要时进入原 Session。

做到这些已经是一个有用的产品。我们可以先验证，用户是否真的能够在多个 Session 之间工作，同时不用操心每条消息应该发到哪里。

当前 PR 走得更远。它加入了持久化 Work block、结构化路由记忆、纠错学习、独立协调图、完整的 WorkHub snapshot 数据库、模型和权限控制、附件、颜色、筛选、Anchor Rail、指标和通知。这些能力以后可能有用，但不需要全部进入第一版契约。

问题不只是增加了 8,920 行。每增加一种表示，我们就多了一份需要长期保持正确的东西。

例如，workhub.sqlite 保存了另一份 Turn 状态、最终回答、路由状态和协调状态，而这些事实大部分已经由 Runtime Host 和 Session 管理。这会过早带来同步和迁移责任。只要能够从 Session catalog、Runtime events、transcript 和 pending interaction 重建，Hub 就应该读取这些权威来源。确实无法推导的少量 Hub 状态可以单独保存，没有必要持久化整个 UI snapshot。

协调也有类似问题。PR 描述说它使用 Agent Graph，但代码实际上维护了自己的节点、边、依赖调度、阻塞状态、停止和恢复逻辑，目标 Session 使用的仍然是 orchestrationMode: 'default'。我倾向于第一版先不做多 Session 协调。以后需要时，应该接入 Runtime Agent Graph，而不是增加第二套 Graph 权威。

当前路由可能也尝试得太多、太早。在 82e1a3f9 的手工验收里，一条无关的支付幂等性请求被送进了已有的登录刷新 Session。本地语义评分已经返回 resume_work，因此后面的受限模型路由没有参与。第一版可以只让明确选择、完整名称和无歧义的最近指代直接路由，其他情况都询问用户。自动化程度低一点，但在我们还不了解用户对 Hub 的真实预期时更安全。

我建议把 Work 留在产品语言里，不把它做成领域类型。代码里的目标就是 Session。Hub 是界面、路由器和 Session 投影，不需要自己的生命周期、模型、权限边界、执行图或 Session 历史副本。

这也没有堵死未来。如果以后发现一个用户目标确实需要跨多个 Session 或 Attempt，并拥有独立生命周期，那时就有充分理由引入 workId。第一版不需要提前承诺这个抽象。

我希望 Hub 这个体验能够落地。我的建议是把当前分支保留为有价值的实验依据，然后从中拆出一个只覆盖 Hub 到 Session 路由闭环的小 PR。更丰富的路由、协调、持久化和 UI 能力可以分别提交。等某项能力证明无法由现有 Session 或 Runtime 层承担，再增加对应抽象。

AI 辅助披露：本评论使用 Codex 检查了路由、持久化、Runtime Host、协调和渲染代码，并执行了文档中的 Desktop 验收；Codex 也协助起草了评论。