Core 是 Worker 内核，不是 Workflow 语言运行时
`sdk-core` 轮询 Server、维护 state machines、发 activation 给语言层。语言层才真正执行 TypeScript/Python/.NET 用户代码。
交互式时序图
切换链路并点击图中的步骤，可以看到方法调用、责任边界和对应源码位置。
组件关系图
这不是数据库 ER，而是源码实体之间的关系图。点击节点查看它在链路里承担的职责。
Event History 骨架
最小 happy path 中，Workflow 命令和 Activity 结果都会变成后续 replay 可以消费的事件。
1 · WorkflowExecutionStartedServer 持久化启动事件。Core 初次解析后生成 `initializeWorkflow` activation job。
2 · WorkflowTaskScheduledServer 安排一次 WorkflowTask，让 Worker 有机会运行 Workflow 代码。
3 · WorkflowTaskStartedWorker poll 到任务。Core 以 WFT started 作为 replay 分块边界之一。
4 · WorkflowTaskCompletedCore 把语言层命令交给 Server，Server 记录 WFT 完成事件。
5 · ActivityTaskScheduledServer 处理 `ScheduleActivityTask` 命令后写入调度事件，并生成 ActivityTask。
6 · ActivityTaskStartedActivity Worker poll 到任务后，Server 记录开始执行。
7 · ActivityTaskCompletedActivity 返回结果后，Server 记录结果 payload 和 identity。
8 · WorkflowTaskScheduledActivity 完成会创建新的 WorkflowTask，让 Workflow replay 到结果处并继续执行。
replay 时，Core 不是把整段 history 一次性丢给语言层，而是由 `HistoryPaginator` 和 `HistoryUpdate` 组织成一个或多个完整的 WFT sequence。`WorkflowMachines.apply_next_wft_from_history()` 按事件顺序推进状态机；遇到命令事件时会和之前语言层生成的命令队列匹配，不匹配就变成 nondeterminism。
三条源码结论
这些判断直接来自当前拉取的源码，不是概念性描述。
Replay 是“事件驱动状态机 + 语言层重跑”
Core 先应用已存在的 history，再让语言层重跑代码生成命令。命令事件会消费 Core 队列中的期望命令，用来检测非确定性。
Activity 结果先回 Server，再回 Workflow
Activity Worker 完成后调用 Core，Core 调 Server。Server 写 `ActivityTaskCompleted` 后创建新的 WorkflowTask，Workflow 下次 activation 才收到 `ResolveActivity`。