# R5.1 任务报告：纯 Kafka 刷新顺序与稳定身份收口

## 上下文

- [HWLAB #2498](https://github.com/pikasTech/HWLAB/issues/2498)
- [AgentRun #297](https://github.com/pikasTech/agentrun/issues/297)
- [AgentRun #299](https://github.com/pikasTech/agentrun/issues/299)

## 根因与修复

1. AgentRun 初始生命周期事件可能先于正式用户输入事件发布，导致源端已经形成用户/代理反序。AgentRun PR #298（merge `85a913`）把用户输入作为 `agentrun.event.v1` 正式事件，并保证它先于同轮 run-created。
2. stdio producer 在分配 `frameSeq` 后并发 fire-and-forget `producer.send`，同 partition 可出现 `5→4`、`7→6` 等真实 Kafka 反序。AgentRun PR #300（merge `07aa6b56335c710e9a0ea1b592a30f03a8ea9a15`）增加每个 publisher 独立的 Promise tail；失败不毒化后续发送，关闭阶段排空当前与 retired publisher。未增加全局队列或下游重排。
3. Web optimistic/live identity 与 retention replay identity 不一致，使刷新后同一消息不能稳定收敛。HWLAB PR #2507（merge `537dce97cc457...`）统一采用 trace 派生的正式 messageId，未增加正文、时间戳或 DOM 去重。

以上变更均由 PR merge 后的自动 CI/CD 链路交付；AgentRun 与 HWLAB 的 Argo 状态均为 `Synced/Healthy`、runtime `1/1 ready`、source relation `exact`。

## 纯 Kafka 实时验收

- Observer：`webobs-mrgs7bsm-a21bc8`
- Command：`cmd-mrgs7itk-cc7434`
- Session：`ses_4b7ed4bf-65a0-4dcc-8024-cd4162f26b52`
- Trace：`trc_mrgs848auq9lmk`、`trc_mrgs97sctjnqo6`
- Report SHA256：`329f422acf7f2c3ab34ce20adc78120d60804fb14f37e1ecbb59952f374e905d`

两轮 stdio `frameSeq` 分别为 `1..36` 与 `1..23` 严格递增；AgentRun → HWLAB 的 event/sourceEventId lineage 与 Kafka/SSE fingerprint 精确一致。A/B subscriber 的 replay-live handoff 中 buffered、live-delivered、deduplicated 均为 0；页面只建立一个 session-scoped EventSource，两个 terminal 均由同页正式 reducer 渲染，禁用请求为 0。

## 同 session 刷新验收

- Command：`cmd-mrgsc5ps-34fdcd`
- Report SHA256：`d80f149b73c5536773d257a0f3c695b5cca14bdc7c84471975497cb1f911cade`
- Screenshot SHA256：`67a50a7d8bbe853694dcc084927227e09e3bf51463944faeda61c458694ff5c9`

刷新前后消息均为 4 条，稳定 identity 与 DOM 顺序完全相同：

1. `user:msg_mrgs848auq9lmk_user:trc_mrgs848auq9lmk`
2. `agent:msg_mrgs848auq9lmk_agent:trc_mrgs848auq9lmk`
3. `user:msg_mrgs97sctjnqo6_user:trc_mrgs97sctjnqo6`
4. `agent:msg_mrgs97sctjnqo6_agent:trc_mrgs97sctjnqo6`

Kafka retention matched/replayed 为 `53/53`；buffered、bufferedDelivered、liveDelivered、deduplicated 均为 0；正式 SSE business event 为 53，失败与禁用请求均为 0。

## 结论

用户第一条消息在实时与刷新后均稳定位于对应 agent 消息之前。修复发生在正式事件产生、producer 顺序和正式 identity 层，没有引入 projector/read model/snapshot/sync/gap-fill/finalizer、HTTP history fallback、下游重排或补洞。
