fix(edge): EventLog orderedSeq 有序性 + Bus fanout wire order——并发 Publish 使文件行序与上线序都≠seq 序，重启重签 seq / replay 静默丢事件 / 客户端 seq<=lastSeq 永久丢弃 (#2154)

[DeliciousBuding]

摘要

一个根因，两侧损害。Bus.Publish 用锁外 atomic.AddInt64 领 seq，随后在不持任何锁的情况下做持久化，最后才 b.mu.Lock() 做 fanout / 重建索引。于是「seq 顺序」与「实际发生顺序」在两个地方分叉：

	分叉点	后果	修法
磁盘侧	rebuildIndexLocked 按文件行序 append 且不排序，而文件行序 = append 序 ≠ seq 序	① 重启重签盘上已有的 seq；② ReadFrom 二分后 seek 到该 seq 偏移再读到 EOF → 更早行上的更大 seq 被静默丢弃（实测单 cursor 最多丢 104 个）；③ orderedSeq[0] 不是最小 seq → 对日志仍覆盖的 cursor 误报 gap，逼客户端全量 resync	重建后补 sort；replay 起点改取后缀最小偏移（replayStartOffsetLocked）；新增 MaxSeq()
内存侧	领号→persist→fanout 之间整段可抢占 → wire order ≠ seq order	app/shared/src/eventClient.ts:202 是 if (envelope.seq <= lastSeq) return; —— 乱序到达的 envelope 被当成 replay 重复永久丢弃且不触发 system.gap，违背 api/events.md:67「seq 同 stream 单调」；另 Subscribe(0) 首连全量回放本来就返回未排序的 history 序	wireNext/wireCond 顺序门；replayFromHistory 无条件排序

两侧修复互补，缺一不可：顺序门让 fanout 有序，但 persist 仍在 b.mu 之外（这是刻意的，见下），所以落盘文件依然是乱序的（修复后实测仍 6/6 个文件乱序、245–300 处 inversion），磁盘侧的排序与最小偏移修复因此是载荷性的，不是 defense-in-depth。

只加 sort.Slice 修不完磁盘侧：ReadFrom 的「二分定位 → seek → 读到 EOF」算法本身就建立在「文件行序 == seq 序」上，排序后仍会丢事件。

被否决的方案（含实测数字）

把 seq stamp + persistFn + fanout 全塞进一个 b.mu 临界区（hub fanout.go 的写法直接照搬）在 happy path 上甚至更快，但会把两笔大开销关进总线锁：

• EventLog truncation 随 maxSize 线性，实测 ~16.7 ms/MiB：1 MiB→17.2ms、2→34.4、4→65.4、8→130.5、16→267.1。外推到 50 MiB 默认值 ≈ 835 ms 一次，频率约每 12.5 MiB 写入一次（≈每 25k 事件）。这 835ms 持有 b.mu 会冻结 Subscribe/Unsubscribe/AddObserver/HistoryLen（Prometheus 抓取），并让 256 槽 subscriber channel 溢出成 gap 风暴。
• persistWithRetry 退避阶梯实测 14.5 ms/条，且对确定性错误也照睡（persist.go:41-55 不区分错误类型）——调用方传个含 chan/func 的 payload 让 json.Marshal 必然失败，就能每次冻总线 14.5ms。4 个并发全失败 publish：锁外 14.6ms 总耗时（并行）vs 锁内 58.0ms（串行）。

所以改用顺序门：persist 留在 b.mu 外（慢 persist 的影响范围与今天完全一致——publisher 们在 EventLog.mu 上串行），只把「上线顺序」按 seq 排队。代价是门上的 head-of-line blocking，数字见下方「取舍」。

关联 issue

属于 #2154（Euclid 并发探索批）lane B / P1。不 close #2154——它是批次伞 issue。

可达性结论与依据

结论：两侧均可达，均已实测复现，不是 latent。 证据等级 A。

产生器只有一个，且是常态路径：Bus.Publish 用 atomic.AddInt64(&b.seq, 1) 领号（原 bus.go:151），随后在不持任何锁的情况下调 persistFn（原 bus.go:172-180），而 WithEventLogPath 把 persistFn 绑成 EventLog.Append（persist.go:87-89），直到原 bus.go:182 才 b.mu.Lock()。领号与「落盘 / 上线」之间没有跨两者的锁：Append 自己的 l.mu 只保证单行写入原子，不保证顺序。生产侧 46 处 Publish 调用点分布在 HTTP handler、run 生命周期 goroutine、MCP handler（api/handlers_*.go、lifecycle/process_executor_publish.go、mcp/tools_handlers.go），并发是常态。

实测数字（Kunpeng ARM64 4C8G，go1.26.5，GOMAXPROCS=4）

观测项	结果
512 次并发 publish 产生的日志文件中，行序 ≠ seq 序	6/6（committed 测试）；8 writers×200 时 5/5
每文件相邻逆序处数	46–56（committed 测试，6 轮共 245–311 处）；8×200 时 13–93
60 轮同形状扫描「末行不是最大 seq」	10/60（例：末行 479，max 512 → 重启重签 480..512 共 33 个已用 seq）
60 轮同形状扫描「首行不是最小 seq」	20/60
4 轮 × 9 cursor 的 ReadFrom 完整性	3/4 轮存在静默丢事件，单 cursor 最多丢 104 个
wire order：1000 条并发 publish，订阅端实收序列的 inversion 数	87（配 event log）/ 92（不配）
replay：Subscribe(0) 返回的 1000 条中 inversion 数	62

已排除的候选路径

候选	结论	依据
领号与 persist/fanout 之间无锁	✅ 唯一实测确认的产生器（两侧共用）	上表
truncate / 重写	❌ 不产生乱序，是放大器	truncateLocked 保留窗口内相对顺序不变；随后的 rebuildIndexLocked 把已有乱序固化进 orderedSeq
append 失败留下的半行	❌ 不产生乱序	半行 json.Unmarshal 失败被跳过；重试产生的重复行被 if _, exists := index[env.Seq] 去重
bus 的 seq 初值与文件内容不一致	❌ 不是产生器，是受害者	即原 bus.go:136-137
重启后 seq 空间不连续	❌ 单独不产生乱序	重启后从恢复值单调递增；只有恢复值取错（本 bug）才产生重复，且重复行相邻
多进程共用同一日志文件	⚠️ 理论上乱序更剧烈，未测试	httpserver/server.go:228 只构造一个 Bus，无此部署形态证据；修复不依赖产生器身份
旧版本写出的文件	❌ 仅代码考古，未跑旧二进制	git log -- eventlog.go 仅 4 次改动，写入形状一直是「一行一 JSON、按 Append 顺序」

红 → 绿证据

红测试不 mock 任何内部字段。磁盘侧确定性用例的乱序文件只用导出方法 EventLog.Append（即 persistFn 实际调用的那个）按 [8 3 12 5 11 4 13 6] 写出——首行 8 不是最小（min=3）、末行 6 不是最大（max=13），正是并发 Publish 被实测产生的形状。内存侧断言对象是订阅端 channel 实际收到的 envelope 序列，文件侧断言对象是从磁盘读回的行序（测试自己按行 json.Unmarshal）。

磁盘侧红（commit b54ad64）

--- FAIL: TestConcurrentPublishWritesSeqUnorderedLogFile (0.18s)
    eventlog_seqorder_test.go:212: concurrent Publish produced 6/6 seq-unordered log files, 250 inversions total
    attempt 0: orderedSeq is not sorted after rebuild from a file with 53 inversions
    attempt 0 (file inversions=53): ReadFrom(cursor=7) dropped 31 event(s), e.g. [21 26 34 35 36 37]
    attempt 2 (file inversions=47): ReadFrom(cursor=64) dropped 104 event(s), e.g. [64 65 66 67 68 69]
--- FAIL: TestRestartAfterSeqUnorderedLogDoesNotReissueSeq (0.00s)
    restarted Bus re-issued seq=7 which is already on disk (max on disk=13, published=[7 8 9 10])
--- FAIL: TestReadFromIsCompleteOnSeqUnorderedLog (0.00s)
    ReadFrom(cursor=12) on a seq-unordered log = [13], want [12 13]
--- FAIL: TestReadFromGapBoundaryUsesTrueMinSeqOnSeqUnorderedLog (0.00s)
    ReadFrom(cursor=3..7) hasGap = true, want false (smallest seq on disk is 3, first line is 8)
--- FAIL: TestOrderedSeqInvariantHoldsAcrossMutationPaths (0.00s)
    after open/rebuild: orderedSeq is not sorted: [8 3 12 5 11 4 13 6]

内存侧红（commit 4001838a，bus.go 停在磁盘侧修复）

--- FAIL: TestFanoutWireOrderMatchesSeqOrderWithEventLog (0.01s)
    with event log: wire order is NOT seq order — 64 inversion(s) in 750 delivered events;
    first few: [pos 10: seq 2 after 12, pos 32: seq 3 after 34, pos 36: seq 13 after 38, ...]
--- FAIL: TestFanoutWireOrderMatchesSeqOrderWithoutEventLog (0.00s)
    without event log: wire order is NOT seq order — 43 inversion(s) in 750 delivered events
--- FAIL: TestSubscribeZeroCursorReplayIsSeqOrdered (0.00s)
    Subscribe(cursor=0) replay is not seq-ordered: 30 inversion(s) in 750 events;
    first 24 delivered seqs = [1 4 5 6 7 8 9 10 11 2 13 14 15 ...]

「不配 event log 也乱序」这条很重要：说明窗口不只是磁盘 I/O，genID 的 crypto/rand 读 + RFC3339 时间戳本身就够调度器翻序。

绿（HEAD 8474400b）

go test ./internal/events/ -count=1 → ok 1.539s；-count=3 全绿；同包 -race 一次全绿（5.64s，无 DATA RACE）。新增 11 个测试（磁盘侧 7 + 内存侧 4）全 PASS，既有测试全 PASS。

如实说明两点，不计入红证据：

1. TestSubscribeReplayIsCompleteOnSeqUnorderedLog 修前修后均绿——sort.Search 在该 fixture 上恰好命中 seq=12，起点偏移正好够用。保留为订阅端可见契约的钉子。
2. TestPublishAndSubscribeWithCursorDoNotDeadlock 是锁序 canary，红态即绿（它防的是修复引入 AB-BA，不是复现已有 bug）。

夹具自身踩过的坑（已写进注释）：内存侧第一版先 publish 完再 drain，256 槽 subscriber channel 灌满，1000 条只收到 256 条——测的是丢包不是乱序。改为并发 drain，publisher 数按 GOMAXPROCS-1 选（给 drainer 留一个 P），断言拆成「严格递增」无条件 +「无空洞」仅零丢包时生效，避免高负载假红。磁盘侧第一版把 truncation 成本量成 1.8ms，那是 maxSize=1 的退化情形（keepBytes=0 会清空日志、只测了空文件重建），真实数字是上面的线性表——该错误数字从未进入本 PR 或 #2154 的任何已发布文本，仅存在于一个被丢弃的本地原型注释里。

取舍：顺序门的成本（实测）

ns/op = 每条事件的墙钟时间，越低越好。-benchtime 20000x -count=3 取中位数。

	baseline（乱序）	A：persist 进 b.mu（否决）	K：顺序门（已交付）
NoLog/w1	1372	1388	1397 (+2%)
NoLog/w4	553	492	2437 (4.4× 慢)
NoLog/w8	709	452	3512 (5.0× 慢)
WithLog/w1	7880	8036	8145 (+3%)
WithLog/w4	8962	9156	10417 (+16%)
WithLog/w8	9230	9256	11087 (+20%)

• A 在无 log 时更快，是因为争用的 atomic.AddInt64 共享 cache line 消失进了本来就要拿的 mutex。但这不是决策依据，决策依据是它关进锁里的 truncation（~835ms）与退避阶梯（14.5ms）。
• K 的代价是门上 head-of-line blocking（争用时每条一次 cond park/unpark）。NoLog/w4、w8 的 4.4×/5.0× 就是这个，但绝对值仍是 ~410k / ~285k events/s，比 edge 实际负载高几个数量级；生产形态（配 event log，8µs 的 append 本来就主导且本来就串行）只贵 16–20%；**单 publisher（单 run 活跃，最常见）+23% 基本无感**。
• 退化路径回到 baseline：4 个并发全失败 publish 重新并行，实测 ~15.7ms 总耗时（A 下为 58.0ms）。

本质结论：persist-before-broadcast + wire 单调 两个契约同时成立时，「慢 persist 阻塞其后事件的投递」无法消除——要么乱序上线（客户端静默丢状态），要么延迟上线。本 PR 选延迟。唯一能同时拿掉延迟的办法是像 hub 那样把 seq stamp 放进投递临界区内，但那要求 persist 不带 seq 或挪到 broadcast 之后，属于产品契约变更，不在本 lane 决定。

全部数字由 bus_publish_order_bench_test.go 复现（benchmark 不在 CI 跑，零成本）：

cd edge-server && go test ./internal/events/ -run '^$' \
  -bench 'BenchmarkPublishConcurrent|BenchmarkPersistRetryLadder|BenchmarkTruncatingAppend' \
  -benchtime 20000x -count=3

改了什么

edge-server/internal/events/ 共 5 files, +1183/−35：eventlog.go（+94 行变更）、bus.go（+167 行变更）、新增 eventlog_seqorder_test.go、bus_wireorder_test.go、bus_publish_order_bench_test.go。未动 hub、未动前端、未动 contracts/ 与 openapi（eventClient.ts 与 api/events.md 只作为证据引用，一行未改）。

磁盘侧（eventlog.go）

1. rebuildIndexLocked 补排序：扫描后 sort.Slice(ordered, ...) 再赋给 l.orderedSeq。Append 路径本来就用 appendSorted 维护有序，只有重建这条漏了；补上后「orderedSeq 升序」在全部三条变更路径（open 重建、Append、truncateLocked 后重建）成立。用 sort.Slice 而非 slices.Sort：重建本身要做全文件扫描 + 逐行 json.Unmarshal（默认 maxSize 下 37.5 MiB 量级），排序是噪声，且不引入新 import。
2. 新增 replayStartOffsetLocked(startSeqIdx)：ReadFrom 的 seek 起点改为取 orderedSeq 后缀上 index 偏移的最小值。后面的 seq >= cursor 过滤会剔掉多读进来的早期行，所以结果精确而不只是安全。代价 O(k) 次 map 查找（k = 紧接着要 json.Unmarshal 的那 k 行，µs/条 vs ns/次查找）；文件恰好有序时最小值就是 orderedSeq[startSeqIdx] 本身，起点与改前逐字节一致（这是零回归的原因）。index 缺键读成偏移 0 → 放大到全文件读：过读安全，欠读不安全。抽成独立函数同时把 ReadFrom 圈复杂度从 22 降回 20（gocyclo 阈值，内联版被 lint 拦下）。
3. 新增 EventLog.MaxSeq()：替掉 bus.go 对 orderedSeq 的跨结构体裸字段读（未持 l.mu）。
4. 注释订正（任务要求「别留假声明」）：
   • orderedSeq 原注释 sorted seqs parallel to index 是错的：index 是 map，slice 与 map 不存在 positional parallel 关系。改为「index 的去重键集，升序」+ 一段显式不变量（升序、恰为 index 键集、len 相等、谁依赖它），由 TestOrderedSeqInvariantHoldsAcrossMutationPaths 双向钉住。
   • index 原注释尾巴 (exclusive of the seq→offset map) 是无意义残留，删。
   • EventLog 类型注释补 ORDERING CONTRACT（文件是 append 序而非 seq 序 + 产生原因 + 实测数字），免得后人再把「文件有序」当前提优化回去。
   • ReadFrom 末尾原注释 the file is append-order which should already be seq-ordered 正是本 bug 的错误前提本身，改成说明这个 sort 为什么不是可有可无的兜底。

内存侧（bus.go）

5. wireNext / wireCond 顺序门：seq 仍在 persist 之前分配（persist-before-broadcast 要求落盘记录带 seq），但 fanout 前等门。deliverInSeqOrder 等到自己那轮才 append history + 推 channel，然后 wireNext=seq+1 并 Broadcast。
   • persist 失败的事件同样过门消费掉自己的 seq（不投递但推进），否则会把后面所有人永久卡死；留下的空洞就是客户端丢失信号，与 hub fanout.go「dropped frames consume a seq too」一致。
   • 门的推进放在 defer 里：panic 或 runtime.Goexit 也必须交出轮次——一个已分配却永不消费的 seq 会把整条 wire 焊死。
   • wireNext==0 作「未设基线」哨兵，基线由第一个被分配的 seq 在 b.mu 内设定（不能由第一个到达门的 seq 设定——它不一定最小，会把更小 seq 排到它后面上线，反而制造 inversion）。这样重启后 seq 被 MaxSeq 播种、或测试直接写 bus.seq（bus_recover_test.go:54）都不会卡门。
   • b.seq 从锁外 atomic 改为 b.mu 保护的普通字段；NewBus 的播种改普通赋值（b 在 NewBus 返回前不可被其他 goroutine 观测）。
6. replayFromHistory 无条件 sort.Slice：b.history 现在按门序（= seq 序）追加，所以通常走 pdqsort 的 O(n) 已排序快路径；但 Subscribe 只在「有 event log 且 cursor>0」时才经 mergeReplayWithLog 排序，cursor=0 的首连全量回放与无 event log 的 bus 之前拿到的是 history 原始顺序。
7. 锁序已核实无 AB-BA：Publish 走 b.mu → EventLog.mu；Subscribe 在 ReadFrom 里拿 EventLog.mu 并在取 b.mu 之前释放（原 bus.go:325 那段 F15 注释顺带保证了这点）。包内无任何位置在持 b.mu 时调 Publish。TestPublishAndSubscribeWithCursorDoNotDeadlock 做 30s watchdog canary。

门禁

全部在 HEAD = 8474400b 上重跑（4 核机、3 lane 并行，严格只跑本包）。

门禁	命令	结果
构建	cd edge-server && go build ./...	PASS
vet	go vet ./internal/events/	PASS
单包测试	go test ./internal/events/ -count=1	PASS (ok 1.539s)
单包 ×3	go test ./internal/events/ -count=3	PASS (ok 4.606s)
单包 race	go test ./internal/events/ -count=1 -race	PASS (ok 5.640s，无 DATA RACE)
lint（单包）	golangci-lint run ./internal/events/...	PASS（0 issues）
lint 棘轮	python3 scripts/verify/verify-edge-lint-ratchet.py	PASS（9 findings 全 baseline-registered，未新增指纹）
文档 SSOT	python3 scripts/verify/verify-doc-ssot.py	PASS（53 script paths / 45 CI files / 95 AGENTS.md paths）
空白/冲突标记	git diff --check + git diff --check origin/master...HEAD	PASS
gosec（CI 形态）	~/go/bin/gosec -fmt=json ./... 2>/dev/null | bash ../scripts/verify/verify-gosec-gates.sh	PASS（clean 0 issues）
commit message	bash scripts/verify/verify-commit-messages.sh origin/master HEAD	PASS（4 commits）

未跑（lane 纪律禁止）：全量 go test ./...、全量 golangci-lint、coverage、vitest、docker；未触碰 :3210 与 bin/edge。golangci-lint 缓存幽灵本轮未遇到，无需 cache clean。

证据等级

结论	等级	依据
并发 Publish 产生行序 ≠ seq 序的日志文件	A 实测可复现	committed 测试 6/6 轮、46–56 处/轮
→ 重启重签已用 seq	A	TestRestartAfterSeqUnorderedLogDoesNotReissueSeq 红→绿；探针 10/60 轮末行≠max（479 vs 512）
→ ReadFrom 静默丢事件	A	TestReadFromIsCompleteOnSeqUnorderedLog 红→绿；探针 3/4 轮丢事件，单 cursor 最多 104 个
→ gap 边界误报	A	TestReadFromGapBoundaryUsesTrueMinSeqOnSeqUnorderedLog 红→绿；探针 20/60 轮首行≠min
wire order ≠ seq order	A	TestFanoutWireOrderMatchesSeqOrder* 红→绿；1000 条中 87（有 log）/ 92（无 log）处 inversion
Subscribe(0) 回放未排序	A	TestSubscribeZeroCursorReplayIsSeqOrdered 红→绿；1000 条中 62 处 inversion
客户端会永久丢弃乱序事件且不报 gap	A（读代码 + 契约文本）	app/shared/src/eventClient.ts:202 + api/events.md:67。未跑前端，未做端到端观测
truncation 成本 ~16.7ms/MiB（→ ~835ms@50MiB）	A 实测（1–16 MiB 五点线性）	直接测量五点；50 MiB 是线性外推，未实测
退避阶梯 14.5ms、A 下 4 并发串行 58.0ms	A	BenchmarkPersistRetryLadder
顺序门吞吐代价（表）	A	BenchmarkPublishConcurrent*，3 轮中位数
orderedSeq 与 index 不「parallel」（原注释为假声明）	A（代码事实）	index 是 map[int64]int64；不变量测试双向钉住键集相等
生产环境确实在并发 Publish	B 代码推导	46 处调用点分布在 HTTP handler / run goroutine / MCP handler；未起真实 :3210 观测
末行≠max 10/60、首行≠min 20/60	B 一次性探针	探针已删（概率性断言会造成 CI flaky），仅数字写入注释
无 AB-BA 死锁	B 代码推导 + canary 测试	锁序逐路径核实 + TestPublishAndSubscribeWithCursorDoNotDeadlock；非穷举证明
多进程共用日志文件会乱序	C 推测未测	无部署形态证据；修复不依赖产生器身份
旧版本文件形状不同	C 仅代码考古	未跑旧二进制

未验证项 / 遗留

1. 未做端到端验证：没有起真实 edge 进程（:3210）+ SSE/WebSocket 客户端做重连/乱序观测，也没跑前端 vitest 验证 eventClient.ts 的实际丢弃行为——lane 纪律禁止。客户端危害是读代码 + 契约文本得出的（等级 A 的代码事实，但非运行时观测）。
2. 未跑下游包测试：本地只跑 ./internal/events/。httpserver/api/hub 中消费 replay 与 fanout 的测试未在本机运行。风险偏低但这次不再是零：顺序门改变了 Publish 的时序语义（新增 head-of-line blocking），任何断言「Publish 立即返回」或依赖投递交错顺序的下游测试都可能受影响。以 CI 结果为准。
3. head-of-line blocking 的尾延迟未量化：只测了吞吐（ns/op），没测 p99/p999 投递延迟。门把「乱序上线」换成「延迟上线」，延迟上界受最慢的在飞低 seq persist 支配（退避阶梯 ≤14.5ms、truncation ≤~835ms——后者今天已经以 EventLog.mu 串行的形式存在同样的冻结）。未测 GC 暂停或调度抖动导致的门等待分布。
4. 概率性统计未固化为 CI 断言：10/60、20/60 来自已删探针；committed 测试断言「对任何产生的文件/任何投递序列，不变量成立」并 t.Logf inversion 数。代价：若将来 Publish 被改成串行、乱序不再发生，TestConcurrentPublishWritesSeqUnorderedLogFile 会退化为空跑（仍绿），只有日志里的 0/N 能提示。
5. truncateLocked 短读数据丢失（pre-existing，未修）：l.f.Read(buf) 可能返回 n < keepBytes，随后只写回 buf[start:n]，会丢掉保留窗口尾部（最高 seq 段）。是丢数据而非乱序，与本 PR 不变量正交；未构造测试、未修。建议单开 issue。
6. persistWithRetry 对确定性错误也退避（pre-existing，未修，persist.go 在写集外）：json.Marshal 失败是永久性的，重试 3 次 + 睡 14ms 毫无意义，还让「调用方传错 payload」变成每次 14.5ms 的门阻塞。建议：区分 transient/permanent 错误，permanent 直接失败。这是我在取舍分析中发现的最高性价比后续项。
7. 重复 seq 的 offset 取值策略未单独测试：rebuildIndexLocked 中 index[seq] last-wins、ordered first-wins。修好后正常路径不再产生重复 seq；persistWithRetry 的重复行相邻，两种 offset 经过滤后结果相同。极端情形（同 seq 相距很远两处）未测。
8. Windows 未本机验证：只在 Linux/arm64 上跑。已知 truncateLocked 的 Truncate(0) 在 Windows 上会失败（bus_truncate_test.go 注释已说明），本 PR 未改变该平台行为。sync.Cond 无平台差异。以 CI 的 Native Windows Go 为准。
9. 可选优化未采纳：没配 persister 时 seq stamp 与 fanout 之间本无任何工作，可跳过门、直接在投递临界区里 stamp（hub 写法），把 NoLog/w4 的 2437ns 拿回到 ~500ns。代价是给总线最热函数加第二条排序路径，收益落在已远超真实负载的量级里——留给决策，已写进 bus_publish_order_bench_test.go 注释。

验证

• 已运行必要检查（见门禁表，HEAD=8474400b），未运行项已在「未验证项 / 遗留」逐条说明原因
• 已检查没有提交密钥、token、真实服务器信息、生产数据或敏感日志（改动仅 internal/events 下 2 个源文件 + 3 个测试文件；leak_guard pre-commit hook 通过）
• 如改了 API/架构/分工，已同步对应 api/、AGENTS.md 或三份主文档 —— 不适用且刻意未动：wire 契约（seq 单调）本来就写在 api/events.md:67，本 PR 是让实现去符合既有文档，不是改文档；未改 contracts/ 与 openapi；EventLog.MaxSeq() 是 internal/ 包内新增方法，无外部 API 面变化

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: ce15891e-f267-4b31-992e-1a4e4861881e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}