fix: SerialMate v0.1.1 接收路径修复——时间戳改 link 线程到达时刻打戳、接收日志批量插入+5000行上限+积压折叠、通道配置缓存；自测扩至 selftest_gui 69 项，新增 ISSUE 报告与 _sim_periodic 复现脚本；重打包

SerialMate/AGENTS.md

@@ -54,7 +54,7 @@ SerialMate/
    保证内容贴顶（卡片被拖高后富余高度收在卡底，勿删——否则拉伸被各行均分,
    标题上方出现空隙）；发送卡行序：板型管理行(下拉+新建+删除+配置+重载) /
    预设行(下拉+填入+直接发送) / 模式行(下拉+存为板型+存入预设) / 输入行 /
-   周期行；帧日志 payload 高亮走 `_append_rx_frame`（html.escape 后拼 span
+   周期行；帧日志 payload 高亮走 `_append_rx_frame`（`_esc_log` 转义后拼 span
    背景，toPlainText 内容不变，selftest 的日志断言因此不受影响）；预设下拉
    显示"名称 · 命令"，存入命令走 `_add_command_named`（弹窗核 `_add_command`
    包装，测试用核函数），预设直发走 `_send_preset_direct`（经输入框复用
@@ -65,6 +65,21 @@ SerialMate/
 2. **回调线程边界**：SerialLink 的 on_status/on_frame/on_raw/on_tx 全在后台线程
    触发，一律 `events.put(...)` 投递，主线程 30ms QTimer 轮询 `_drain_events`
    分发（与 DLPilot `_poll_dlpc` 同模式），禁止回调里直接碰 GUI。
+   **时间戳由 link 后台线程打**（字节到达/写入串口时刻）：四个回调签名均带
+   尾参 ts 并随事件入队（事件元组尾部即 ts，如 `('frame', fr, ts)`）——GUI
+   消费侧只经 `_timestamp(t)` 格式化、不现取（消费时刻打戳会随 UI 卡顿成批
+   挤压失真，v0.1.0 教训，见 `ISSUE_rx_timestamp_and_lag.md`）。
+2b. **接收日志治理**：日志行只入 `_rx_buf`（`_append_rx`/`_append_rx_frame`
+   负责转义），`_drain_events` 末尾 `_flush_rx` 一次 appendHtml——每行必须包
+   `<p style="margin:0">`（**`<br>` 连接只算 1 个 block，会让
+   maximumBlockCount 裁旧行失效**，offscreen 实验验证过）；转义用 `_esc_log`
+   （空格转 `&nbsp;`，防富文本折叠连续空格破坏 TX 行对齐）；`_update_counters`
+   由 drain 末尾统一调一次，勿回到每帧调用。事件积压超 `FOLD_QSIZE`(200) 时
+   该批帧走 `_absorb_frame`（曲线照常入库、计数器照常，日志折叠为带首尾到达
+   时刻的计数摘要行，消化到阈值内自动恢复逐帧）。
+2c. **通道配置缓存**：`_on_frame` 帧路径只读 `self._ch_cfg`（`_on_channel`
+   用户改动配置时经 `_collect_channels` 重建），禁止每帧遍历 UI 控件读配置
+   （高频时放大 UI 线程占用，v0.1.0 延迟累积的帮凶之一）。
 3. **半双工节奏**：link 工作线程每个循环周期最多出队写一帧（20ms 间隔），
    RS485 总线多帧连发留应答间隙，勿改成批量 drain 一次写。
 4. **帧构成语义**：帧由 `FrameLayout` 令牌序列定义（`HDR ID LEN PAYLOAD CRC`
@@ -181,6 +196,57 @@ tag/release 命名 `SerialMate-vX.Y.Z`，zip 命名
 
 ## 7. 进度记录
 
+### v0.1.1（2026-10-10，接收路径修复：时间戳失真 + 显示延迟累积）
+
+背景：FilmForge 固件联调（GD32F405 RS485 115200，M2 连续温度上报 2~10 帧/s）
+发现日志时间戳成批挤压、显示延迟越跑越大；固件侧二分验证 100% 出帧，问题
+独立存在于 SerialMate 显示层，见 `ISSUE_rx_timestamp_and_lag.md`。
+
+已完成：
+- **根因 1**（时间戳在 GUI 消费时刻打）：时间戳改在 link 后台线程打
+  （字节到达/写入串口时刻），`on_status/on_frame/on_raw/on_tx` 签名均追加
+  尾参 ts 并随事件入队；`_timestamp(t)` 变为纯格式化函数。日志时间恢复为
+  真实到达时间。
+- **根因 2**（接收日志无限增长 → UI 递减性卡顿 → 延迟累积）：
+  - 接收日志批量插入：`_drain_events` 把本轮日志行攒入 `_rx_buf`，末尾
+    `_flush_rx` 一次 appendHtml（每行一个 `<p style="margin:0">`，
+    maximumBlockCount 裁旧行照常生效；`_esc_log` 空格转 `&nbsp;` 防富文本
+    折叠连续空格）；`_update_counters` 改为 drain 末尾统一一次；
+  - 通道配置缓存 `_ch_cfg`：`_on_channel` 时重建，帧路径不再每帧遍历控件
+    （提取逻辑收敛进 `_extract_channels`）；
+  - 积压折叠：事件队列超 `FOLD_QSIZE`(200) 时该批帧走 `_absorb_frame`——
+    曲线照常入库、计数器照常，日志折叠为一行计数摘要（含首尾到达时刻，
+    如 `← 12:00:00.100~12:00:02.300 ⏳ 显示滞后, 折叠 250 帧: B=0xF0 温度
+    上报 ×250`），消化到阈值内自动恢复逐帧；
+  - 行数上限 5000（v0.1.0 末期已加的止血，本次提为常量 `RX_MAX_BLOCKS`）。
+- 自检扩充：selftest_loop 增回调 ts 断言共 18 项；selftest_gui 增时间戳
+  格式化/帧日志用到达时刻/通道缓存同步/积压折叠 8 项共 69 项；另做端到端
+  模拟（600 帧积压一次性消费）：日志压到 201 行、曲线 600 点全收、时间戳
+  单调且逐帧等于真实到达时刻。
+- README 接收显示段同步时间戳/日志治理语义；exe 重建入库（v0.1.1）；
+  zip/Release 未发布（待用户验收）。
+- **真机 M2S100"卡住"排查（2026-10-10，用户复测反馈）**：用户 v0.1.1 exe
+  发 M2S100 后 ack 与周期帧均不显示。本机分层复现均正常——裸 pyserial+
+  解析器（帧 100% 到达、ack ok、100ms 间隔稳）、offscreen GUI 全链路
+  （60 帧/6s 一帧不丢）、桌面真渲染完整用户序列（连接→M1/M2→M2S100→帧流，
+  138 帧全显示）。exe 经归档解包确认含 v0.1.1 代码。未能复现，定性为
+  用户端环境/运行态问题，待用户按状态栏"积压"指示再复现时定位。
+  排查副产品：
+  - link.py 串口参数加 `inter_byte_timeout=0.02`（Win32
+    ReadIntervalTimeout）——注意 **pyserial 的 timeout 是总超时**（150ms 内
+    必返回，不无限攒批），此参数把周期帧的 read 粒度从 ~150ms 一批改善为
+    单帧粒度（帧时间戳更准）；
+  - 状态栏计数器追加 **积压 N**（events.qsize()）——常驻分层观测：数字
+    持续增长=事件产出快于消费（GUI 侧问题），恒 0=RX 链路断（串口/驱动/
+    固件侧问题）；"卡住"时 UI 整体无响应则是主线程被阻塞，另查。
+  - 勘误：修复初期曾把 M2S100 卡住归因"read(4096) 攒批 41 秒"，该论述
+    错误（win32 timeout 为总超时），已修正注释；loop:// 虚拟口的 read
+    立即返回缓冲，**测不出真串口等待行为**，链路自检覆盖不到此处。
+  - 探测善后：COM5 FilmForge 固件曾残留 100ms 上报态（用户上次 M2S100
+    生效的证据），已发 M2S0 关闭（M2 查询=OFF）。
+
+待办 / 计划：无新增，沿用 v0.1.0 待办。
+
 ### v0.1.0（2026-09-27，首版）
 
 已完成：