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 生命周期的晋升都经过明确集成，而把自动冲突处理留到后续阶段？