Proposal: WorkHub as a unified conversational entry point for all work

[ARE404]

Problem

Maka currently organizes work through Projects and Sessions. This gives each task a clear context, permission boundary, execution history, and recovery path, but it also requires users to manage routing themselves.

When working on several things, users must repeatedly remember:

• which Project contains the work;
• which Session should receive the next message;
• where the previous conversation stopped;
• whether a new Session should be created;
• which Sessions need to be checked for progress.

This is navigation and context-management work rather than the user's actual work.

The cost is particularly visible for non-technical users and on mobile devices, where navigating a hierarchy of Projects and Sessions is more expensive.

Desired outcome

Maka should provide one permanent conversational entry point where users can understand and advance all their work without manually selecting a Session first.

The proposed user-facing name is WorkHub. "Unified Session" refers to the current experiment, while "Work Orchestrator" describes the internal coordination role.

From WorkHub, a user should be able to:

• ask what work is currently active;
• ask for the progress of a particular Work;
• continue an existing Work using natural references such as "continue the login issue";
• start a new Work without manually creating a Session;
• coordinate multiple Works and their dependencies;
• answer permission requests and clarification questions in place;
• enter the underlying Session whenever detailed control is needed.

The user should manage goals and priorities. Maka should manage routing.

Proposed user experience

WorkHub should behave like an ordinary Maka conversation rather than a separate administrative dashboard.

A user message can produce one of four outcomes:

1. Discussion

   Exploratory or ambiguous conversation remains in WorkHub. Maka does not create a Work merely because a topic was mentioned.

2. Resume an existing Work

   When the intended Work can be identified with sufficient confidence, Maka binds the message to the Session that owns that Work.

3. Create a new Work

   When the user expresses a clear execution goal and no suitable Work exists, Maka creates a normal Session and presents it as a new Work.

4. Clarify

   When multiple targets are plausible, especially before file changes or external side effects, Maka asks the user to select the intended Work instead of silently guessing.

Each Work is displayed as an independent message block. Project and Work information should remain visible but visually secondary. WorkHub should otherwise reuse the normal Session layout, message components, composer, permissions, and interaction cards.

Product and architecture principles

Sessions remain authoritative

This proposal does not replace or merge ordinary Sessions.

Each Session continues to own its:

• conversation and execution history;
• model and permission mode;
• Project and filesystem scope;
• tool calls and artifacts;
• interruption and recovery state;
• archive and deletion semantics.

WorkHub is an orchestration and projection layer over those Sessions.

Routing is bounded

A model must not invent Session identities or freely choose arbitrary execution targets.

Existing deterministic filtering should produce a bounded set of Work candidates. Semantic intent recognition may select from those candidates, request clarification, create a new Work, keep the message as Discussion, or coordinate several explicit Works.

When the cost of a wrong binding is asymmetric, Maka should prefer one clarification question over confident misrouting.

One executable turn has one Work authority

A message that changes files or produces external effects must be bound to one Work before execution.

Requests involving several Works should be decomposed into explicit Work turns and coordinated through the existing Graph dependency model.

The feature must remain reversible

Users can always open an ordinary Session and continue working there.

Disabling WorkHub restores the ordinary navigation behavior without deleting the Works, Sessions, or history created through it.

Alternatives or workarounds

Improve Session search and navigation

Better search and faster switching reduce the number of clicks, but users still need to understand the Session structure and decide where every message belongs. This reduces switching cost without removing routing as a user responsibility.

Merge all Sessions into one context

A single transcript would appear seamless, but it would mix unrelated context, permissions, recovery state, and deletion semantics. It would also create an indefinitely growing model context.

Add a work-status dashboard

A dashboard helps users inspect progress, but users must still leave it and find the appropriate Session before they can continue working. It solves visibility without providing one place to advance the work.

Why WorkHub

WorkHub combines global work visibility with a conversational control surface while preserving independent Session authorities.

Users can understand, continue, create, and coordinate all their work in one place without managing the underlying Session routing.

Experimental implementation

A working experiment currently demonstrates:

• a permanent unified entry;
• Discussion without eager Session creation;
• creating and resuming Work;
• bounded target recognition;
• clarification and retargeting;
• Project / Work attribution;
• independent permission handling;
• low-noise lifecycle projection;
• Graph-based coordination across Works.

The experiment is evidence of feasibility, not a predetermined final implementation.

Illustrated overview:

https://github.com/ARE404/maka-agent/blob/codex/unified-session-experiment/UNIFIED_SESSION_EXPERIMENT.zh-CN.md

Experimental branch:

https://github.com/ARE404/maka-agent/tree/codex/unified-session-experiment

Scope

The intended product contract covers all Maka Workspaces registered in the application.

The first production implementation may be delivered in smaller slices, but it should not establish a model that makes cross-Workspace work impossible later.

Non-goals

• Removing ordinary Sessions.
• Combining every Session transcript into one model context.
• Sharing permissions implicitly across Works.
• Allowing an LLM to invent execution targets.
• Hiding irreversible effects after a Work is redirected.
• Solving cloud or cross-device synchronization in the first milestone.

Open questions

1. When WorkHub is enabled, should it become Maka's default application entry point?
2. What evidence and confidence should be required before automatically binding to an existing Work?
3. Which operations should always require explicit target confirmation because they may modify files or produce external side effects?
4. What is the smallest production milestone that preserves the intended cross-Workspace model?
5. Which product metrics can demonstrate that WorkHub actually reduces navigation, Session management, and context-switching burden?

Feedback on the user model, terminology, safety boundaries, and rollout scope is welcome.

[likun666661]

I think there may be a deeper simplification behind WorkHub.

If we start from the agent loop, a Session is primarily a container for an ordered set of messages plus an execution boundary. Once Work becomes the durable user-facing concept, it is worth asking whether Session still needs to be a primary domain entity at all.

A possible alternative model is:

• Event: an immutable fact appended to the log
• Work: a durable projection of events around a user goal
• Run / Attempt: one concrete agent-loop execution
• Context Snapshot: the exact events selected for a Run
• Authority Snapshot: the filesystem, permission, model, and tool scope for that Run

In this model, Session can remain as a compatibility or UI projection, but it no longer has to be the storage or authority primitive.

The underlying structure would not really be a single transcript. Physically, it can be an append-only sequence, but logically it is a temporal causal graph. Events need typed relationships such as:

• reply_to
• caused_by
• retrieved_from
• derived_from
• supersedes
• depends_on
• belongs_to

For example, if message C was generated because message B was retrieved into the previous context, that should be represented through a persisted Context Snapshot rather than inferred later from transcript proximity. This would make agent behavior auditable and replayable.

From this perspective, WorkHub routing becomes a large-scale Event Log search problem, but I think it should be split into two distinct retrieval stages:

1. Global Work/reference resolution

   Search a bounded, privacy-filtered routing index using BM25, semantic retrieval, entity matching, graph proximity, Work Focus, and temporal signals. Produce a lightweight intent projection such as: “I think you mean Work X, with this goal and scope.”

2. Scoped execution-context retrieval

   Only after the Work is selected or confirmed, search the detailed events inside that authority scope, expand causal neighbors, reduce superseded state, and produce the immutable Context Snapshot used by the next agent Run.

This separation matters because global target identification and execution-context construction have different safety requirements. A global message search should not automatically become execution authority or inject unrelated raw history into the agent context.

User confirmation can then be risk-based:

• low-risk, high-confidence references may bind automatically while showing the selected Work;
• ambiguous or high-side-effect actions should first return the candidate projection for confirmation;
• the confirmed binding itself should be appended as an event.

Time also needs richer treatment than a general recency score. Recent conversational messages may decay quickly, while decisions, unresolved permissions, and architectural constraints remain important. The system should distinguish event time from ingest time and understand supersedes relationships so that historical evidence is searchable without being mistaken for current truth.

So the deeper question may be:

Could Work be a projection over an append-only temporal causal graph, with Session reduced to a derived view, rather than Work being a wrapper around Session?

Even if Session is removed as a concept, its operational responsibilities do not disappear. Execution isolation, permissions, cancellation, recovery, and concurrency would move explicitly into Run, Authority Snapshot, and causal-branch primitives.

For an MVP, the existing one-Work/one-Session implementation may still be the practical path. However, keeping workId independent from sessionId, and defining Event, Run, Context Snapshot, and typed causal relationships early, would avoid making the eventual architecture depend on Session as the permanent information boundary.

[Astro-Han]

Thanks, this pushed me to go read the actual source code.

The read side of your framing already runs inside Maka. The execution domain is an append-only per-run ledger with a monotonic sequence, plus a projection cache keyed by session and event type. The same events/projections pair shows up again for task runs and workflow plans. Canonical terminal turn status is computed from the immutable runtime event ledger, not read from a stored snapshot. For a completed run, the canonical read model itself declares source: 'runtime_events'; the stored session_messages table works as an in-flight and compatibility fallback.

What does not exist is the recall layer. No full-text, BM25, or semantic index anywhere in the tree. Search today is a bounded substring scan. That gap is roughly WorkHub sized: a read model that can answer where things stand without opening every session.

The write side is where Session stops being a cache and becomes the authority. Sessions own the model, connection, backend, archive state, the permission boundary, and the working-directory binding. Those are not projections. File contents, external system state, and manual edits live outside the event ledger, and no replay rebuilds them.

One detail in the code makes this concrete: root turn admissions per session must form a single linear chain, and branching is a hard error. A recall layer can rank events, but it cannot decide who appends the next root turn. That arbitration is the real thing a Session-less design has to re-home, not the display layer.

So on the read side, Session as navigation should fold into a projected WorkHub over the event feed. On the write side, the question is not whether Session disappears, but which authority takes over lifecycle, boundary evolution, recovery identity, and turn-append arbitration. For an MVP, WorkHub as a projection over Sessions is the smallest viable step, and keeping workId separate from sessionId leaves the deeper model open.

---

中文版：

顺着你这个角度去看代码，读侧的部分其实 Maka 已经在做了。执行域就是按 run 追加的不可变事件表，配一张按 session 和事件类型缓存最新值的投影表，task run 和 workflow plan 也走同一套 events/projections 结构。turn 的终态（完成/失败/中断）是从不可变运行时事件里现算出来的，不读现成快照；已完成 run 的权威读模型自己也声明 source: 'runtime_events'，session_messages 只是保底/兼容的投影缓存。

真正缺的是召回层。整个仓库没有全文索引、没有 BM25、没有向量索引，现在的搜索就是个限范围的子串扫描。这个洞正好是 WorkHub 该填的：不用打开每个 session 就能回答"现在到哪了"的读模型。

写侧才是 Session 从缓存变成权威的地方。模型、连接、backend、归档状态、权限边界、工作目录绑定都挂在 Session 上；这些不是投影。文件内容、外部系统状态、用户手动改的东西都不在事件账本里，重放重建不出来。

代码里有个更直接的证据：每个 session 的 root turn 受理必须构成唯一一条线性链，分叉直接报错。召回能排候选，但仲裁不了"下一条 root turn 谁写"。这才是去 Session 之后真正要迁移的东西，不是展示层。

所以读侧，Session 作为导航应当融进事件流上的 WorkHub 投影；写侧，问题不是 Session 要不要消失，而是生命周期、边界演进、恢复身份、turn 追加仲裁这些职责交给谁。MVP 里 WorkHub 作为 Session 之上的投影是最小可行的口径，workId 与 sessionId 解耦，后面那条更难的路才走得通。

---

Note: this reply was drafted with AI assistance, reviewed by the author against the source, and edited by hand before posting.

[Astro-Han]

Reading this together with the proposal and Li's event-log framing, here is our take and where it agrees or splits with the other two.

Our proposal: a Hub main agent, not a new Work entity.

We want to keep the existing Session/Project model untouched and add one permanent conversational entry: a single global main agent living in a persistent Hub session. The user talks only to this agent. Work is not a new domain abstraction; it is whatever the main agent decides to orchestrate. Each work is executed by subagents (existing Sessions are simply treated as agent units too), each gets a sandbox and an automatically scoped task, failures are handled by the main agent (retry, reroute, degrade) instead of being pushed to the user, and the user sees results only. The UI is a conversation stream, mobile-first, with work details hidden until asked.

Where we agree with the WorkHub proposal:

• Sessions stay authoritative. Existing Sessions and Projects are untouched; the Hub is an alternative view on top of them, so both data models stay interoperable.
• One entry point, and the system owns routing.
• Confirmation is risk-based: automatic when low-risk, explicit when ambiguous or high-side-effect.

Where we differ from the proposal:

• Work is not an entity with its own id, lifecycle, and dependency graph. That abstraction layer is not needed if the main agent orchestrates everything.
• The work boundary is defined by the subagent sandbox scope, not by a Work object.
• Mobile-first: the Hub is an IM-style surface; drilling into the underlying Session is not a primary interaction.

Where we agree with Li's event-log view:

• Session is not the center of the user's world. The main agent (and the event stream under the Hub) is.
• The underlying storage is an event log, and the Hub conversation itself is one.
• Confirmation is risk-tiered.

Where we split with Li:

• Li puts large-scale retrieval at the center: one big event log, organized by semantic/keyword search, Context Snapshots, Authority Snapshots, and typed causal relationships.
• We put orchestration at the center. Retrieval is supporting machinery (locating a task like "continue that login issue", rebuilding context), not the organizing principle. Authority is not decomposed into explicit snapshots; it stays in the Runtime's permission and confirmation mechanism and in the main agent's orchestration.
• Li treats the Session as removable in principle; we keep it (untouched, as a view) because removing it would break the existing data model.

What all three share: users should not manually manage Session routing; the bottom layer is an event stream; confirmation should be risk-based and reversible.

Open questions for the discussion: is Work worth keeping as its own entity, or is a main agent's orchestration view enough? And is large-scale retrieval the core mechanism, or is orchestration?

---

中文版：

结合李坤那条事件流的视角，我把我们的方案跟两边摆在一起，说说异同。

我们的主张：一个 Hub 主 Agent，不造 Work 实体。

现有 Session/Project 完全不动，在上面加一个永久对话入口：全局唯一的主 Agent，住在常驻的 Hub 会话里，用户只跟它说话。Work 不是新的领域实体，只是主 Agent 眼里的一个编排容器。每件工作由子 Agent 干（历史 Session 也统一当作 Agent 单位），每个子 Agent 拿到沙箱、范围自动划定，出错由主 Agent 自己编排（重试、换路、降级），不推到用户面前，用户只看结果。界面就是对话流，移动优先，细节默认藏着。

和 WorkHub 提案一致的地方：

• Session 依然权威。现有 Session/Project 不动，Hub 是叠在上面的另一层视图，两套数据互通。
• 单一入口，路由归系统。
• 确认按风险分级：低风险自动，含糊才问。

和提案不一样的地方：

• Work 不做成有 id、生命周期、依赖图的实体，这层抽象没必要。
• 工作的边界由子 Agent 的沙盒范围定义，不是由 Work 对象定义。
• 移动优先：Hub 是 IM 形态，钻进底层 Session 不是主要交互。

和李坤一致的地方：

• Session 不是用户世界的中心，主 Agent（和它背后的事件流）才是。
• 底层是事件流，Hub 会话本身就是一条事件流。
• 确认按风险分级。

和李坤分岔的地方：

• 李坤把大规模检索当核心：一条大事件流，靠语义/关键词搜索、Context 快照、Authority 快照、类型化因果关系组织一切。
• 我们把编排当核心：检索只是支撑（定位、恢复上下文），不是组织原则；权限不拆成显式快照，留在 Runtime 的权限/确认机制和主 Agent 的编排里。
• 李坤原则上可以去掉 Session；我们保留它不动它，因为去掉会破坏现有数据模型。

三方共同点：用户不该手动管 Session 路由；底层都是事件流；确认要风险分级、可逆。

想请大家讨论：Work 值不值得做成独立实体，还是主 Agent 的编排视图就够？核心机制到底是检索还是编排？

---

Note: this reply was drafted with AI assistance, reviewed by the author, and edited by hand before posting.

[UncertaintyDeterminesYou4ndMe]

A few thoughts from the user side of this — put up for discussion, not as conclusions.

1. Users recall work by topic.

Nobody remembers "the third session in Project X". What sticks is "the login bug", "that refactor", plus loose associations: an error message, a filename, a person's name. Session IDs and Project hierarchy are the system's coordinates. The proposal's own example — "continue the login issue" — works because the user is addressing by topic; the proposal treats that as a UI convenience, and I wonder if it should be a modeling constraint instead.

If it is a modeling constraint, topics and sessions are N:M. A topic can span sessions — a bug gets fixed, regresses two weeks later, gets re-fixed in a new session, and in the user's mind that is one thing. A session can touch several topics. Topic lifecycle is also independent of session lifecycle: an archived session does not mean a finished topic.

2. This makes me lean toward a middle position on the entity question, though I have not validated it against the actual data model.

Roughly: Work as a light entity that anchors identity and continuity, with execution responsibilities staying where @Astro-Han located them — root-turn arbitration, permissions, recovery identity in Session/Run. Compared to the 1:1 framing, this can express "resume a topic whose session is archived": open a new execution container seeded with the topic's context. Compared to no entity at all, the topic's continuity — what was tried, decided, superseded — gets a durable home instead of being re-derived by retrieval on every reference. It also lines up with @likun666661's point about decoupling workId from sessionId early.

If the premise in section 1 holds, there is one retrieval implication: the routing index would need to be keyed on the associations users recall by — files touched, error strings, entities — rather than mainly session titles and recency. "The thing that was throwing 401s" should resolve even when no title mentions 401.

3. A possibly adjacent opportunity — the same substrate could remember the user.

If Work is a projection over the event log, memory about the user could be another projection over the same log. WorkHub happens to be the one surface that sees every clarification answer, every correction, every confirmed binding — the raw material for user-scoped memory: preferences, conventions, how this user names their topics. The confirmed binding appended as an event, as likun proposed, would double as labeled data for reference resolution. User-scoped memory would need the same supersedes treatment as events, since preferences change.

I have not thought through the privacy and scoping questions this raises, so I am offering it as a direction, not a design.

Two questions I would add to the open list:

• In real usage data, does the N:M topic/session pattern show up often enough to justify an independent Work entity in the first milestone?
• If WorkHub accumulates user-scoped memory, where should it live so that disabling WorkHub (the reversibility requirement) keeps predictable semantics?

---

中文版:

下面是从用户这一侧看的几个想法,先抛出来讨论,不下结论。

1. 用户靠主题回忆工作。

没有人记得"Project X 下的第三个 Session"。留在记忆里的是"登录那个 bug""那次重构",外加一些松散的关联物——一条报错、一个文件名、一个人名。Session ID 和 Project 层级是系统的坐标。提案自己的例子 "continue the login issue" 能成立,就是因为用户在按主题寻址;提案把它当成交互便利,我在想它是不是应该当成建模约束。

如果当成建模约束,主题和 Session 的关系是 N:M。一个主题可以跨多个 Session——bug 修了、两周后回归、又开新 session 重修,在用户心里是同一件事;一个 Session 也可能碰到多个主题;主题的生命周期也独立于 Session,Session 归档不等于主题结束。

2. 顺着这个前提,我在实体之争上目前倾向一个中间形态,还没对照真实数据模型验证过。

大概的形态是把 Work 做成轻实体,只当身份和连续性的锚点;执行职责留在 @Astro-Han 定位的地方——root turn 仲裁、权限、恢复身份在 Session/Run。和 1:1 框架比,它能表达"续接一个 Session 已归档的主题",也就是带着主题上下文新开一个执行容器。和完全不做实体比,主题的连续性——试过什么、决定过什么、什么被推翻了——有个持久的归属,不用每次引用都靠检索重建。这也和 @likun666661 说的尽早解耦 workId 与 sessionId 对得上。

如果第 1 节的前提成立,检索上跟着一个推论——路由索引要建在用户用来回忆的关联物上,碰过的文件、报错串、实体,不能主要靠 session 标题和时间新旧。"那个一直报 401 的问题"应该能命中,即使没有任何标题提到 401。

3. 一个可能顺带的机会——同一个底座可以记住用户本人。

如果 Work 是事件账本上的投影,对用户的记忆可以是同一账本上的另一个投影。WorkHub 恰好是唯一看得到全部信号的界面,每一次澄清的回答、每一次纠正、每一次确认的绑定,都是用户级记忆的原料:偏好、习惯、这个用户怎么给主题起名。像李坤提的那样把确认的绑定作为事件落账,同一条数据也能当指称消解的标注样本。用户级记忆同样需要 supersedes 语义,因为偏好会变。

隐私和作用域的问题我还没想清楚,所以只当方向提,不当设计提。

想往开放问题清单里加两条:

• 真实使用数据里,主题跨 Session 的 N:M 情况出现得够不够多,值不值得第一个里程碑就引入独立的 Work 实体?
• 如果 WorkHub 积累用户级记忆,它应该存在哪里,关闭 WorkHub(可逆性要求)时的语义才可预期?

---

Note: this reply was drafted and posted by Claude (Fable 5) on behalf of the author, and the author reviewed the content before it was posted. / 本评论由 Claude Fable 代发,内容经作者审阅。

[likun666661]

After reading the proposal and replies, I think the model becomes simpler if Session is treated as a topic / execution thread rather than the durable user-facing identity.

My preferred layering is:

• Hub main agent: understands intent, decomposes goals, and orchestrates Works.
• Work: a stable user goal and cross-run identity. It is also the unit for global retrieval, recall, and status projection.
• Session: one topic / execution-authority thread under a Work, owning scoped context, permissions, working-directory binding, root-turn arbitration, and recovery.
• Run: one concrete execution attempt.
• Events: the underlying facts from which state is projected.

This implies Work 1:N Session and Session 1:N Run. A long-lived Work may naturally use separate Sessions for research, implementation, testing, release, or changes in scope, permissions, and context, while still remaining the same user goal.

From this perspective, retrieval and orchestration are not competing organizing principles. Global retrieval resolves a natural user reference to a Work. The Hub main agent orchestrates Works. Once a Work has been selected, an appropriate existing or new Session provides the bounded execution authority.

For the MVP, WorkHub can remain a projection and orchestration layer over existing Sessions, with Sessions staying authoritative on the write side. However, workId should be independent from sessionId from the beginning.

I therefore think Work should remain a lightweight but real entity: a stable ID, goal, state, related Sessions, dependencies, and summary. It does not need to own filesystem permissions or turn arbitration; those remain Session / Run responsibilities. This gives the main agent a stable handle for recall, lifecycle management, dependency coordination, and auditability without requiring Session to disappear.

This is the direction I favor.

---

中文总结：我倾向把 Session 看成 Work 下的 topic / 执行线程。Work 是稳定的用户目标、跨运行身份和检索召回单元；更上层由 Hub 主 Agent 编排 Work；真正执行时，再落到某个已有或新建的 Session，由 Session / Run 承担权限、上下文边界、恢复和写入仲裁。因此关系更适合建模为 Work 1:N Session，而不是 Work 1:1 Session。MVP 不需要移除 Session，但应从一开始让 workId 与 sessionId 独立。

Note: this follow-up was drafted and posted with AI assistance on behalf of the author.

[Sun-GLiang]

Building on the previous replies, I lean toward a lightweight Work 1:N Session model.

I agree with @UncertaintyDeterminesYou4ndMe’s premise that users recall work by topic rather than Session coordinates, with @likun666661 that workId should remain independent from sessionId, and with @Astro-Han that Session should remain authoritative for permissions, working-directory scope, recovery identity, and root-turn arbitration.

Although topic-to-Session relationships may eventually be N:M, I would initially constrain each Session to one Work. A long-lived Work could still use separate Sessions for research, implementation, testing, and integration without sharing one continuously growing transcript.

There is already a related mechanism in Agent Graph: one Graph can coordinate multiple child Sessions, project their committed RuntimeEvents into records, and select final resultIds. However, Graph workId currently identifies a scheduled work item bound through an operator provision to a target Session. It is not yet a durable user-facing Work identity that groups independently created Sessions and owns their shared lifecycle, summary, and current state.

That leaves a narrower missing contract:

How should independently executed Sessions and Runs contribute results to one durable Work projection?

A completed Run—or an explicit checkpoint from a long-lived Session—should not directly overwrite Work state. Its conclusion may be based on stale code, incomplete evidence, or assumptions contradicted by another Session. Instead, it could emit a proposed Work update containing a small, bounded envelope:

• provenance: workId, sessionId, and runId;
• the base Work version and relevant execution baseline;
• declared scope, touched resources, and known dependencies where observable;
• Artifacts and validation evidence;
• proposed findings, decisions, blockers, or lifecycle transitions.

The Hub can coordinate this promotion, meaning incorporation into the durable Work projection. When promotion requires repository or environment validation, it should be evaluated by an integration Session with the appropriate execution authority. The resulting accept, supersede, defer, or reject decision should itself be recorded as an event.

Work snapshot
  → scoped Session / Run
  → proposed Work update
  → version, conflict, and evidence checks
  → promotion decision event
  → refreshed Work projection

This contract governs durable Work knowledge and lifecycle state. Repository changes remain under Session authority and may still require a separate merge or integration path.

For an MVP, I would keep the contract deliberately small:

1. Result envelope: provenance, base version, proposed changes, Artifacts, and validation evidence—not the full transcript.
2. Promotion policy: require explicit integration for state-changing proposals. Automatic promotion can initially be limited to append-only, reversible, and objectively verifiable facts.
3. Stale results: staleness alone should not invalidate a proposal. Revalidate it against the current baseline; retain non-conflicting facts, while overlapping changes or semantic contradictions are re-executed, superseded, or routed through an integration Session.

More precise dependency tracking, automatic conflict detection, and richer promotion policies can remain later extensions rather than requirements for the first WorkHub milestone.

This makes retrieval and orchestration complementary rather than competing concerns: retrieval resolves the Work, the Hub coordinates execution, Session retains execution authority, and promotion determines what becomes durable Work state.

Would it make sense for the first milestone to define only this minimal proposed-update envelope and require explicit integration for lifecycle-changing promotions, while leaving automatic conflict resolution for a later phase?

---

中文

结合前面的回复，我倾向采用轻量的 Work 1:N Session 模型。

我赞同 @UncertaintyDeterminesYou4ndMe 提出的前提：用户按主题而不是 Session 坐标回忆工作；赞同 @likun666661 提到的 workId 应与 sessionId 解耦；也赞同 @Astro-Han 对 Session 写侧职责的判断：权限、工作目录范围、恢复身份和 root-turn 仲裁仍由 Session 承担。

主题与 Session 最终可能呈现 N:M 关系，但初期可以先约束一个 Session 只归属于一个 Work。一个长期 Work 仍可分别创建调研、实现、测试和集成 Session，而不必共享一条持续膨胀的 transcript。

Agent Graph 中已经存在一个相关机制：一个 Graph 可以协调多个 child Session，将其已提交的 RuntimeEvent 投影为 records，并选择最终的 resultIds。不过，目前 Graph 中的 workId 标识的是一项调度任务，该任务通过 operator provision 绑定到目标 Session；它还不是一个能够归纳多个独立 Session，并拥有统一生命周期、摘要与当前状态的持久用户级 Work 身份。

因此仍然缺少一个范围更明确的契约：

相互独立执行的 Session 和 Run，应如何向同一个持久 Work 投影贡献结果？

一次 Run 完成后——或者长期 Session 产生明确 checkpoint 时——不应直接覆盖 Work 状态。其结论可能基于过期代码、不完整证据，或者与其他 Session 的结论冲突。它可以先提交一份范围有限的候选 Work 更新，其中包括：

• 来源信息：workId、sessionId 和 runId；
• 所基于的 Work 版本及相关执行基线；
• 声明的执行范围，以及能够观测到的受影响资源和已知依赖；
• Artifact 和验证证据；
• 建议写入的发现、决策、阻塞项或生命周期迁移。

Hub 可以协调晋升过程，即决定候选结果是否进入持久 Work 投影。当晋升需要验证仓库或执行环境状态时，应由具备相应执行权限的集成 Session 完成检查。最终的接受、取代、暂缓或拒绝决定本身也应记录为事件。

Work 状态快照
  → Session / Run 范围内执行
  → 提交候选 Work 更新
  → 版本、冲突和证据检查
  → 记录晋升决策事件
  → 刷新 Work 投影

这份契约管理的是持久的 Work 知识和生命周期状态。仓库修改仍受 Session 权限边界约束，并可能需要独立的合并或集成流程。

对于 MVP，我倾向先保持契约足够小：

1. 结果信封：包含来源、基础版本、候选变更、Artifact 和验证证据，而不是完整 transcript。
2. 晋升策略：改变 Work 状态的候选更新需要明确集成；自动晋升初期仅限追加式、可逆且能客观验证的事实。
3. 过期结果：过期不等于无效，应基于当前基线重新验证。无冲突事实可以保留；重叠修改或语义冲突则重新执行、明确取代，或交给集成 Session 处理。

更精确的依赖追踪、自动冲突检测和丰富的晋升策略可以作为后续扩展，而不是第一个 WorkHub 里程碑的前置条件。

这样看，检索与编排不是相互竞争的核心机制：检索负责定位 Work，Hub 负责协调执行，Session 保留执行权威，晋升机制决定什么可以成为持久 Work 状态。

第一个里程碑是否可以只定义这份最小候选更新信封，并要求所有改变 Work 生命周期的晋升都经过明确集成，而把自动冲突处理留到后续阶段？

[ARE404]

Architecture update: a per-Runtime-Host WorkHub Coordination Session

After implementing and testing the first WorkHub MVP slices, I think we should refine the architecture before treating the current router as the final product model.

The current MVP demonstrates that Maka can:

• project existing Sessions into one surface;
• reconstruct bounded conversation history from Session transcripts;
• route explicit and contextual references;
• clarify ambiguous targets;
• create ordinary Sessions for new executable goals;
• correct a previous routing decision without introducing another durable Work authority.

However, it also exposes a mismatch:

WorkHub looks like a unified conversation, but it is currently only a projection and deterministic router.

For example, an ordinary question that does not belong to an existing Session does not receive a model answer. It remains as transient WorkHub UI state and cannot be reconstructed after leaving the surface. That is not consistent with the intended experience of one permanent conversational entry point.

I therefore propose the following direction.

1. One stable WorkHub Coordination Session per Runtime Host

Each Runtime Host should own exactly one persistent WorkHub Coordination Session.

This is a special Session role, not a new storage system or a replacement for ordinary Sessions. It should reuse the existing Session, Turn, transcript, model-execution, and recovery infrastructure.

The Coordination Session should:

• be created lazily when WorkHub is first used;
• be reused after application restart;
• own the WorkHub conversation transcript;
• remain hidden from the ordinary Session list;
• never appear as one of its own routing candidates;
• switch when the user switches Runtime Host;
• avoid cross-Runtime-Host orchestration in the first milestone.

The WorkHub surface can remain one entry in the UI while selecting the Coordination Session associated with the active Runtime Host.

2. Authority remains split by responsibility

The Coordination Session and ordinary Sessions should own different facts.

The WorkHub Coordination Session owns:

• the user's WorkHub messages;
• direct answers to ordinary questions;
• clarification dialogue;
• coordination decisions;
• delegation tool calls;
• references to target Sessions and Turns;
• summaries produced as part of the coordination conversation.

Ordinary Sessions own:

• concrete work execution;
• Project and filesystem scope;
• model and permission mode;
• root-Turn admission;
• tool calls and artifacts;
• interruption, recovery, archive, and deletion semantics;
• the authoritative execution transcript.

WorkHub projections own nothing durable.

They remain rebuildable views of ordinary Session facts, states, and bounded transcript content.

Session therefore remains the only transcript and execution substrate. The Coordination Session is authoritative only for the coordination conversation; it does not become authoritative for another Session's work.

3. Delegation should link transcripts instead of copying them

When a WorkHub message is delegated, the Coordination Session should record the user's original intent and a bounded delegation record, for example:

delegationId
coordinationTurnId
targetSessionId
targetTurnId
disposition
status

The target Session records the concrete delegated execution request and its own result.

WorkHub may display or summarize that result through a projection, but it should not copy the target Session's complete transcript into the Coordination Session.

Conceptually:

WorkHub transcript
  user intent
  -> delegation reference
  -> acknowledgement / coordination summary

Target Session transcript
  delegated execution request
  -> tools and side effects
  -> authoritative execution result

4. Every WorkHub message has one of four dispositions

“Should this be routed?” is not precise enough as a binary decision. A WorkHub input should result in one of four explicit dispositions:

answer_here
delegate_existing
create_new
clarify

Examples:

“What does React useMemo do?”
-> answer_here

“Continue the payment callback work and add retry tests.”
-> delegate_existing

“Start a new accessibility audit for Settings.”
-> create_new

“Continue the stability issue.” when several Sessions match
-> clarify

Ordinary questions are answered by the WorkHub Coordination Session. Concrete execution is delegated to an ordinary Session.

5. Two routing architectures should be tested

I do not think we should decide the model/router boundary only from intuition. We should compare two implementations on the same data.

R3-A: model-direct routing

The WorkHub model decides the disposition. If delegation is required, it selects from a bounded set of valid Session candidates supplied by the Runtime:

answer_here
clarify
create_new
delegate_existing(sessionId)

The model cannot invent a Session ID.

Potential advantages:

• stronger semantic understanding;
• better handling of paraphrases and multi-turn references;
• fewer lexical failures when Session names do not contain the terms the user remembers.

Potential risks:

• non-determinism;
• candidate-selection inconsistency;
• sensitivity to Session summaries or prompt injection;
• higher model and prompt cost.

R3-B: model-gated R2.4 routing

The WorkHub model decides only the disposition:

answer_here
clarify
create_new
delegate_existing

When the result is delegate_existing, the original user input and current Session facts are passed to the versioned R2.4 target resolver.

Potential advantages:

• deterministic and reproducible target selection;
• narrower model responsibility;
• easier explanation and regression testing;
• existing R2.4 evidence and correction behavior remain reusable.

Potential risks:

• cascading errors: the model may correctly decide to delegate while R2.4 still chooses the wrong target;
• semantic references may remain difficult for a lexical/core-evidence resolver;
• the model cannot repair a resolver failure without another clarification turn.

In this variant, R2.4 should not automatically create a Session after the model has selected delegate_existing. create_new must remain a separate disposition; otherwise the two layers can contradict each other.

The current deterministic R2.4 implementation should remain a third baseline:

Strategy	Disposition decision	Target selection
R2.4 baseline	deterministic policy	deterministic policy
R3-A model-direct	model	model, bounded to valid IDs
R3-B model-gated-R2.4	model	R2.4

6. Both variants use the same deterministic Action Gate

Regardless of which routing variant performs better, model output must not directly become execution authority.

A common deterministic Action Gate should validate every proposed action:

• the target Session exists;
• the target belongs to the active Runtime Host;
• the target is not archived;
• a Session waiting for user input does not receive another root Turn;
• the Coordination Session cannot target itself;
• Stop is bound to the exact WorkHub-owned Turn;
• new Session creation came from the create_new disposition;
• confirmation requirements are enforced for ambiguous or high-risk actions;
• hosted tool and permission ceilings cannot be expanded by the coordinator.

The model proposes an action. The Runtime admits or rejects it.

7. Proposed experiment

The comparison should use:

• the same model and reasoning configuration;
• the same fixed Session snapshot;
• the same bounded Session summaries;
• the same WorkHub transcript prefix;
• the same Runtime states;
• the same test inputs;
• repeated runs for model-based variants;
• separate first-turn and multi-turn evaluation.

The scenario set should cover at least:

• ordinary knowledge questions;
• explicit Session names;
• semantic references without Session names;
• current and previous Work references;
• ambiguous multi-match inputs;
• explicit new Work requests;
• first-time natural-language correction;
• content-level changes such as “do not use Redis; use Postgres”;
• archived, running, and waiting Sessions;
• cross-Work comparison and status questions;
• navigation away from WorkHub and back;
• conflicting or adversarial text inside Session names and summaries.

Metrics should be reported separately:

• disposition accuracy;
• target accuracy conditional on delegation;
• unsafe-action rate;
• unnecessary clarification rate;
• unnecessary Session-creation rate;
• correction recovery;
• ordinary-answer quality;
• multi-turn consistency;
• repeated-run stability;
• latency, token usage, and model cost.

A correct routing decision and a downstream model-response failure must remain separate evaluation outcomes.

8. Relationship to the current MVP

The current WorkHub work remains useful:

• the Session projection and transcript reconstruction remain necessary;
• R2.4 remains a deterministic baseline and a candidate resolver;
• waiting-state protection and expected-Turn Stop remain part of the Action Gate;
• current routing and correction tests provide reusable evaluation cases.

What changes is the product definition:

WorkHub would no longer be only a transient router surface. It would become a persistent conversational coordinator backed by the existing Session substrate.

This proposal does not yet settle whether Work should remain 1:1 with Session, become Work 1:N Session, or eventually become an independent lightweight identity. That is a related but separate domain decision. The first experiment can continue to treat ordinary Sessions as the execution authorities without introducing a new durable Work database.

Questions for discussion

1. Is one stable Coordination Session per Runtime Host the right initial scope?
2. Should the coordinator model directly select a bounded Session candidate, or should it only decide the disposition and delegate target selection to R2.4?
3. Which actions should always require confirmation even when model and resolver agree?
4. Should WorkHub acknowledge delegation immediately, wait for the target Turn, or support both interaction modes?
5. Which read-only tools, beyond Session inspection, should the Coordination Session be allowed to use for ordinary Q&A?
6. What evidence would justify moving from the per-Runtime-Host scope to cross-Runtime-Host coordination?
7. Should the Work identity question be resolved before this architecture ships, or can it remain separate from the first Coordination Session milestone?

I suggest implementing the Coordination Session shell and both routing variants on an experimental branch, running the same evaluation suite, and selecting the production routing boundary from the results rather than assuming either model-first or policy-first routing is superior.

AI assistance disclosure: Codex helped analyze the current implementation and draft this architecture update. I reviewed and approved the proposed direction and final text.

中文

架构更新：每个 Runtime Host 一个稳定的 WorkHub Coordination Session

经过当前 WorkHub MVP 的实现和测试，我认为我们需要重新明确 WorkHub 的产品和架构定位。

目前的 WorkHub 已经能够：

• 从已有 Session 构建工作视图；
• 从 Session transcript 重建有限的历史内容；
• 将输入路由到已有 Session；
• 在目标不明确时要求用户澄清；
• 为明确的新目标创建普通 Session；
• 支持对错误路由进行纠正。

但目前存在一个明显矛盾：

WorkHub 看起来是统一对话入口，实际上却只是一个投影视图和确定性路由器。

例如，用户在 WorkHub 中提出一个与现有 Session 无关的普通问题时，当前实现不会调用模型回答，只会把它作为临时 discussion 留在页面中。离开 WorkHub 后，这段内容也无法从普通 Session 中恢复。

如果 WorkHub 的目标是真正的统一对话入口，那么它需要拥有自己的持久对话上下文。

一、每个 Runtime Host 一个 WorkHub Coordination Session

建议每个 Runtime Host 拥有一个稳定的 WorkHub Coordination Session。

它不是新的存储系统，也不是普通 Session 之外的第二套生命周期，而是复用现有 Session、Turn、transcript、模型执行和恢复基础设施的一种特殊 Session。

它应当具备以下特征：

• 第一次使用 WorkHub 时懒创建；
• 应用重启后继续复用；
• 拥有 WorkHub 自己的对话 transcript；
• 不出现在普通 Session 列表中；
• 不参与自己的路由候选；
• 用户切换 Runtime Host 时，切换到对应的 Coordination Session；
• 第一阶段不负责跨 Runtime Host 编排。

二、不同 Session 的 authority 边界

WorkHub Coordination Session 负责：

• 用户在 WorkHub 中的原始输入；
• 普通问答；
• 澄清对话；
• 路由和协调决定；
• 创建或委托操作；
• 对目标 Session 和 Turn 的引用；
• 面向用户的协调结果和总结。

普通 Session 继续负责：

• 具体工作执行；
• Project 和文件系统范围；
• 模型与权限模式；
• root Turn 仲裁；
• 工具调用和 Artifact；
• 中断、恢复、归档和删除；
• 具体工作的权威 transcript。

WorkHub 的聚合界面仍然只是可重建 projection，不拥有其他 Session 的执行事实。

因此，Session 仍然是唯一的 transcript 和执行基础设施。WorkHub Coordination Session 只对“协调对话”负责，不会成为其他工作的 authority。

三、委托使用引用，而不是复制 transcript

当用户的输入需要交给普通 Session 执行时，WorkHub transcript 应记录：

• 用户原始意图；
• 最终 disposition；
• 目标 Session；
• 目标 Turn；
• delegation 状态；
• 必要的协调回复。

可以使用类似下面的关联信息：

delegationId
coordinationTurnId
targetSessionId
targetTurnId
status

目标 Session 记录真正的执行请求、工具调用和结果。

WorkHub 可以读取或总结目标 Session 的结果，但不应把完整执行 transcript 复制到自己的 transcript 中。

四、WorkHub 输入的四种 disposition

“是否需要路由”不能只用一个布尔值表达。每条 WorkHub 输入至少应归入以下四种 disposition：

answer_here
delegate_existing
create_new
clarify

例如：

“React 的 useMemo 是什么？”
→ answer_here

“继续支付回调那个，补充重试测试。”
→ delegate_existing

“新建一个 Settings 无障碍检查。”
→ create_new

“继续稳定性问题。”
→ clarify

普通问答由 WorkHub Coordination Session 自己回答；具体执行则交给普通 Session。

五、需要实验比较的两种路由架构

我们暂时不应凭直觉决定模型和 R2.4 的边界，而应在同一批数据上比较两种方案。

R3-A：模型直接选择目标

模型判断 disposition；如果需要委托，它直接从 Runtime 提供的有限 Session 候选中选择目标：

answer_here
clarify
create_new
delegate_existing(sessionId)

模型不能自由生成 Session ID，只能选择 Runtime 提供的有效候选。

这个方案可能更擅长理解语义、指代和多轮上下文，但也可能存在不稳定、成本更高和受候选内容干扰的问题。

R3-B：模型判断 disposition，R2.4 选择目标

模型只判断：

answer_here
clarify
create_new
delegate_existing

如果结果是 delegate_existing，再把用户原始输入和当前 Session facts 交给 R2.4，由 R2.4 选择具体目标。

这个方案的目标选择更确定、更容易回归测试，但可能产生两级误差：模型正确判断需要委托，R2.4 却因为语义证据不足选错或继续澄清。

在这个方案中，R2.4 不应该在 delegate_existing 分支自动创建新 Session。新建必须来自独立的 create_new disposition，否则两层决策可能互相矛盾。

当前纯确定性的 R2.4 可以作为第三个 baseline：

策略	判断 disposition	选择目标
R2.4 baseline	确定性规则	确定性规则
R3-A model-direct	模型	模型从有界候选中选择
R3-B model-gated-R2.4	模型	R2.4

六、共同的确定性 Action Gate

无论最终采用哪种路由方案，模型输出都不能直接成为执行 authority。

所有动作都必须经过同一个确定性 Action Gate，检查：

• 目标 Session 是否真实存在；
• 目标是否属于当前 Runtime Host；
• 目标是否已经归档；
• waiting Session 是否正在等待用户输入；
• Coordination Session 是否错误地选择了自己；
• Stop 是否绑定 WorkHub 实际拥有的 Turn；
• 创建操作是否来自 create_new disposition；
• 高风险或歧义操作是否需要用户确认；
• 模型是否试图突破工具或权限边界。

模型负责提出建议，Runtime 负责决定是否允许执行。

七、实验方式

三个策略应该使用：

• 相同模型和 reasoning 配置；
• 相同的固定 Session 快照；
• 相同的 Session 摘要；
• 相同的 WorkHub transcript 前缀；
• 相同的 Runtime 状态；
• 相同的测试输入；
• 模型方案重复运行多次。

测试场景至少包括：

• 普通知识问答；
• 明确 Session 名称；
• 没有名称的语义引用；
• 当前工作和上一个工作；
• 多个 Session 都可能匹配；
• 明确创建新工作；
• 首次自然语言纠错；
• “Redis 不对，换成 Postgres”这类工作内部修改；
• archived、running 和 waiting 状态；
• 跨 Work 查询和比较；
• 离开 WorkHub 后返回继续；
• Session 名称或摘要中的干扰内容。

评测指标应分别记录：

• disposition 准确率；
• 委托后的目标准确率；
• 不安全操作率；
• 不必要澄清率；
• 不必要创建 Session 的比例；
• 纠错恢复能力；
• 普通问答质量；
• 多轮一致性；
• 重复运行稳定性；
• 延迟、Token 和模型成本。

路由正确但目标 Session 模型执行失败，不能算成路由失败，两类结果需要继续分开记录。

八、与当前 MVP 的关系

当前实现并不会全部废弃：

• Session projection 和 transcript 重建仍然需要；
• R2.4 可以继续作为 baseline 或目标 resolver；
• waiting 状态保护仍然需要；
• expected-Turn Stop 仍然属于 Action Gate；
• 当前路由和纠错案例可以复用为实验数据。

真正变化的是 WorkHub 的定义：

WorkHub 不再只是没有自己 transcript 的临时路由页面，而是由一个稳定 Coordination Session 支撑的统一对话入口。

这份架构暂时不决定 Work 1:1 Session、Work 1:N Session 或独立 Work 实体问题。第一阶段仍然可以让普通 Session 保持具体工作的唯一执行 authority，不新建第二套 Work 数据库。

希望进一步讨论的问题

1. 每个 Runtime Host 一个稳定 Coordination Session，是否是合适的第一阶段作用域？
2. 模型应该直接选择有界 Session 候选，还是只判断 disposition，再由 R2.4 选择目标？
3. 哪些操作即使模型和 R2.4 判断一致，也必须要求用户确认？
4. WorkHub 委托之后，应该立即回复“已交给目标 Session”，还是等待目标 Turn 返回结果？
5. Coordination Session 为了普通问答，可以直接使用哪些只读工具？
6. 什么条件下才需要支持跨 Runtime Host 协调？
7. Work 实体问题是否必须在 Coordination Session 上线前解决？

建议先在实验分支实现共同的 Coordination Session 外壳，再实现 R3-A 和 R3-B 两种可切换策略。使用同一套测试和数据评测后，再决定正式架构，而不是提前假设模型直接路由或 R2.4 路由一定更好。

AI 协助披露：Codex 协助分析当前实现并起草了这份架构更新；提议方向和最终文本已经过我的审阅与确认。