AskaEth/Cyrene-For-Android
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 5 Wiki Activity
239 Commits 3 Branches 5 Tags
f8ac95ceed083dd43d7ab205b9efae1bf4fc2462
Commit Graph
239 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
AskaEth f8ac95ceed docs(05): W52 待办变化 —— S4/S5/S9 移出待办，并标明仍未验/未做的三项 
- S4 → W52A（真机未验，只有单测+走查）；S5/S9 → W52B（真机通过）；W52C/W52DE 三项真机通过。
- 仍在待办：保活→前台服务/通知/13+ 权限流 未验；INTERNET 显式声明未做；构建锁协议未写死；
  主人待拍板的保活第 3 件（收到消息弹系统通知 + 接上 proactive 判据）。
- 另记：登出条目观感已实机确认（红字「退出登录」+ 箭头离开方框图标，一眼是登出）。
 2026-10-06 16:15:02 +08:00
AskaEth 46855af2dd docs(05): W52/E 复验补记 —— 「重试」不出现的根因是判据极性接反（已修，真机端到端通过） 
根因：判据参数语义是「有没有东西」，调用点传了 isEmpty() ⇒ 唯一会求值的场景里结论恒假。
抓到方式：一次性诊断日志（三个输入全真而结论为假 ⇒ 只剩极性）。修在 0054a3a。
教训：判据单测全绿 ≠ 接线正确——极性/语义类错只有调用点会露，而调用点在 Compose、无 UI 测试装置 ⇒
只能靠真机验收。这是设备验收抓住单测抓不到的错的第二例。
 2026-10-06 16:14:44 +08:00
AskaEth 0054a3a97a fix(chat): 首屏失败的「重试」按钮永远不出现 —— 判据极性接反（W52/E 真机验收暴露） 
改了什么：
- ChatScreen 里 shouldOfferRetryOnEmpty 的第三个实参从 `state.items.isEmpty()` 改成
  `state.items.isNotEmpty()`。

为什么：判据是 `!loading && hasError && !hasItems`，参数语义是「列表里**有没有**东西」；调用点传的是
`isEmpty()`（极性相反），于是「列表为空」这个**唯一会求值**的场景里结论永远是 false ⇒ 按钮永远不出现。
判据单测用的是正确语义（不含调用点），所以全绿——这条只有真机才会露出来。

怎么定位的：先加一条一次性诊断日志把 UI 实际看到的三个输入打出来（`loading=false hasError=true
items=0 retry=false` —— 三个输入全真而结论为假 ⇒ 只可能是极性），核对判据本体后确认；定位完日志已删。
真机复验：断网冷启动 ⇒ 「消息没能加载出来」+「重试」；恢复网络后点它 ⇒ 发出
`GET /api/v1/sessions/web/messages` 且离线期间落库的那条出现在屏幕上；按钮随列表非空消失。
 2026-10-06 16:14:27 +08:00
AskaEth 126a706422 docs(05): 锚点补记三十 —— W52 五项落地（已合并推送/101 suite 1270 tests 真跑绿）+ 真机验收结果 
- 五项各自的机制与判据要点（S4 一格一份 ViewModelStore 与四条豁免、S5/S9 纯账本与既有 interrupt 出口、
  登出条目、降级气泡屏蔽服务端动作、保活开关与 Start/Stop/Leave 判据）。
- 真机验收：设置页两行 / 抽屉「正在思考…」/「停止」发既有 interrupt 帧 / 降级气泡无删改入口 **通过**；
  **首屏失败「重试」未通过**（断网冷启动下按钮没出现，根因未定位，写了下一步的诊断办法）。
- 保活开关→服务、S4 回收 未验（时间不够），如实标注。
- 三条教训：① 判据第一步要防「别的 App 抢前台」（gms 账号页把我们的 dump 全吃了）；
  ② 更正 INTERNET 那条：release 的 INTERNET 来自 okhttp-android 传递依赖，建议显式声明；
  ③ 构建锁协议有洞（有人整文件删除导致别人的行没了）。
 2026-10-06 16:10:37 +08:00
AskaEth 579eccdfd1 merge: W52K —— 「后台保持连接」开关 + 前台服务（默认关；开了才有常驻通知） 2026-10-06 16:02:42 +08:00
AskaEth 0243fb78d4 feat(设置): 新增「后台保持连接」开关与前台服务（默认关） 
现状是一件保活都没做：Android 12+ 会把 cached 进程冻结，进程级共享的那条 WS 连接
（AppContainer.chatSocket）久了就断。这一批只解决「进程别被冻」这一件事，连接本身的生死
仍然归 SessionsViewModel（登录连、登出关），本服务不碰它、也不订阅任何帧。

- core/keepalive/KeepAliveService：dataSync 型前台服务，职责只有让进程活着。常驻一条 LOW
  级静默通知（不响不震、setOnlyAlertOnce、点一下回 App），渠道只在服务真的起来时才建。
- core/keepalive/KeepAlivePolicy：起停判据抽成纯函数。shouldKeepAliveRun 三个条件缺一不可
  （开关开 / 已登录 / 通知权限在）；keepAliveAction 再补上「开关开着但登录态未定（自举中）
  一律不动」——不补的话热启动会看到通知闪一下，而中间那段进程正好没人保护。判据刻意**不**查
  「现在跑着没有」：那份进程内记忆会被「系统收掉服务却不走 onDestroy」写坏，于是该起的时候
  一声不响地没起（保活最不能出的错）；重复 start/stop 本身是无害的。
- CyreneApp：全 App 唯一一处按判据起停，开关或登录态一变就重判一次 ⇒「启动时开着且已登录就
  在跑」「登出即停」「关开关即停」三件事不需要各自一条路径。
- 设置页新增一行（默认关），文案如实写清代价（常驻一条通知 + 多耗一点电）与当下真实状态；
  Android 13+ 申请 POST_NOTIFICATIONS，被拒则开关弹回关闭并说明原因，绝不假装开着。
  实现落在新文件 KeepAliveRow.kt：SettingsScreen.kt 只加一行调用（放在「关于」之前，不碰
  最底下的登出块），避开 W52C 正在编辑那一段。
- KeepAliveService.onTimeout：targetSdk 37 下 dataSync 前台服务 24 小时内累计跑满 6 小时会被
  系统回调，不自己停就 ANR 崩掉整个 App —— 照办 stopSelf，不绕（绕它要么换类型要么加心跳，
  都超出本功能边界）。
- Manifest：FOREGROUND_SERVICE / FOREGROUND_SERVICE_DATA_SYNC / POST_NOTIFICATIONS + service
  （exported=false、foregroundServiceType=dataSync）。

测试：新增 3 个文件 13 条 —— 默认关、三条件缺一不可、四入参全表一致、文案四档各不
相同且「跑不了时一个字都不提已开」、渠道重要级只许 LOW/MIN。基线 93 suite/1205 tests 全部保持
通过，本树 96 suite/1218 tests/0 失败。
 2026-10-06 15:59:28 +08:00
AskaEth d6b0c7cb20 merge: W52A —— 常驻 VM 保留最近 3 格 + LRU 回收（S4）：一格会话一份 ViewModelStore 
冲突仅一处（deleteSession 的 onSuccess 同一锚点）：W52B 的 forgetBusy 与 W52A 的 reclaim 是同一件事
的两半，两侧都留 —— 一个让还活着的 VM 别再发注定 404 的补拉，一个把那一格的内存交出去。
 2026-10-06 15:58:06 +08:00
AskaEth 37289391f8 merge: W52B —— 抽屉能看出哪个会话正在跑（S9）+ 行内「停止」入口（S5） 2026-10-06 15:56:23 +08:00
AskaEth bbc47dbd31 feat(chat): 常驻 ChatViewModel 加 LRU 回收（S4）—— 一格一份 ViewModelStore，最近 3 格之外整格交出去 
S4 的病根：每个访问过的会话各留一个常驻 VM（都订阅那条共享连接 ⇒ 每次重连各自发一轮
after 补拉）、各留一份消息列表（含内联 base64 图片），而删会话也不回收。此前**没有按会话
交出一格的手段**：所有 VM 塞在 Activity 级那一个 ViewModelStore 里，而它只有整体 clear()，
W48 只能做到「让 key 换一代、旧实例继续留着」—— 旧实例照样活着、照样收帧。

这次把「哪几格留着」这件事单独拎出来：

- 新增 `core/session/ChatSessionSlots.kt`（进程级，挂在 AppContainer 上，与 GoneSessions
  同一层）：一格一份 ViewModelStore。`ChatScreen` 改成
  `viewModel(viewModelStoreOwner = <槽位>, key = chatViewModelKey(...))`，所以「交出去一格」
  就是那一份 store 自己的 `clear()` ⇒ 那一格的 `onCleared()` + `viewModelScope` 取消
  （订阅、补拉、在飞的请求一起停）。共享连接的生死一个字节都没碰：主人仍是
  SessionsViewModel，`ChatViewModel.onCleared` 照旧**不** close（现在它会真的被调到，
  所以这句注释也一并写成事实）。
- 新增判据 `core/session/chatSessionEvictions`（**纯函数**，VM 与测试共用）：
  「最近」的口径 = **最后一次成为当前会话的时刻**（由 ChatScreen 在组合到某个会话时写入）；
  候选要同时满足「不是主会话 ∧ 不是屏幕上那一格 ∧ 没有没交代完的事」，按最旧的先走，
  保留最近 `keep` = 3 格（主人口径，含被豁免的那些占的名额——不然「最多 3 格」会变成
  3 + 豁免数）。两条豁免名额之外的豁免各自都有硬理由：屏幕那一格死了会「不再更新、连
  发送都静默不发」，还有没交代完的事那一格（草稿 / 排队等连接的发送）死了内容**回不来**。
- 删会话时那一格当场交出去（`SessionsViewModel.deleteSession`，与 W51 的
  `goneSessions.mark` 相邻：一个是「别发注定 404 的补拉」，一个是「这一格本来就不该留」）；
  登出 / 换账号时 `clear()` 一格不留（与快照 / 已读游标 / GoneSessions 同档纪律）。
- 「还有没交代完的事」收的是**现读的探针**而不是打开那一刻的快照：回收发生在别的会话被
  打开的那一刻，而那正是用户可能刚在前一格打了草稿、还没切走的时候。

刻意不动的红线：W48 的 `chatViewModelKey` 拼法一个字没改（新槽位的 key 里同样带账号指纹，
两道闸门各管一段）；W49 的节流判据、W50 的 ProactiveIngest 判据、W51 的 reconnectPull
判据都没碰，也没有把「连接恢复」做成整表重拉。

测试：新增 `ChatSessionEvictionTest`（14 例，穷举判据的每一条边界：N=3、最旧先走、主会话 /
屏幕上那一格 / 有草稿的豁免、豁免占名额、并列退回账本顺序、结论是带账号指纹的槽位 key）
与 `ChatSessionSlotsTest`（9 例，钉住「没被收的一格还是原来那一格（切回来状态还在）」与
「被收的一格下次拿到的是新的一格」、空槽位会被下一次回收扫掉、探针现读的效果）。

同批把已经说错的注释改成事实：GoneSessions / AppContainer.chatSocket / ChatHomeScreen /
ChatScreen 里那几处「VM 活在 Activity 级 ViewModelStore 里、切走 / 删会话都不回收」。
 2026-10-06 15:56:13 +08:00
AskaEth 84f343ce5f feat(sessions): 抽屉里看得见「哪个会话正在生成」，并给一个能停的入口（S5 + S9） 
S9 登记的是「这个会话正在生成」既看不见、也没有可查的状态面：`session_busy` /
`session_idle` / `turn_begin` 都带 sessionId 且在广播，但 `SessionsViewModel.onEvent`
一个都不认。S5 要的「能看见 + 能停」正是同一份状态的下游。

看得见（S9）
- 新增 `ui/sessions/SessionBusy.kt`：把下行帧折成「本端已知在跑的会话」账本，判据是纯函数
  `applyBusyFrame`（可单测，先例 `silentRefreshStep`）。点亮只认 `session_busy` 与
  `turn_begin` 这两条活帧——握手不回放该状态，所以没收到过帧的会话一定不显示（宁可没有）；
  收尾认 `session_idle`（无条件）、`turn_end`（只收本端认得的那一路，收完一路不剩才灭灯）、
  `session_interrupted`（`activeTurns > 0` 时**不**灭——`scope:"current"` 只停一路，无条件灭
  就是 v2 前端审计记成「会错」的 A7 那条）。
- `SessionsViewModel` 用一路订阅把账本接进来，并在**离开 Connected 时当场作废**：掉线期间
  服务端那边跑完了什么本端收不到，留着就是一盏永远不灭、按钮永远点不动的灯。
- 抽屉那一行：忙碌时摘要行下面多一行「正在思考…」（与聊天页 `busyLabel` 逐字相同）。
  另起一行而不顶掉摘要，也不从 `endActions` / 标题列里分走任何一个 dp。

能停（S5）
- 新的上行动作 `SessionsViewModel.stopGenerating(sessionId)`，走**既有的** interrupt 出口
  （`WsOutbound.Interrupt` 本来就带 sessionId，既有的帧表达得了「停某一个会话」，没有新造帧）。
  恒发 `scope:"current"`：本端从不发 `all` 是一条既有不变式，而 `all` 会静默清空待处理队列
  （那份队列是用户自己敲进去的），本端也没有「丢弃 N 条」的告知面。
- 抽屉行里「停止」与「置顶」共用**同一个 endActions 槽位**：抽屉固定 300dp，`BasicComponent`
  把内部可用宽度的 60% 当 `endActions` 硬上限，现有的三个 40dp 动作已经贴着边，
  再并一个会把图标挤到裁剪。这一轮结束（灯灭）置顶立刻回来。

纪律
- `onEvent` 里只**前置**一次折帧，`when` 的分支一个字节没动 ⇒ W49 的节流静默重拉与
  [persistedRoute] 的两档语义不变；无关帧（流式 delta）原样返回同一张表，不重推状态。
- 新增 18 条单测钉住上述每一条（含「turn_id 认不得就不灭灯」「并行两路都要收」「stream_end
  不灭灯」「停止不发 all」）。
 2026-10-06 15:55:04 +08:00
AskaEth aace581fb0 merge: W52C —— 退出登录从小图标按钮改成带文字的危险行条目，图标换 Remove 2026-10-06 15:50:31 +08:00
AskaEth 27116fa434 merge: W52DE —— 降级气泡不再给删改入口（proactive-local: 前缀屏蔽服务端动作）；空态补一枚显式「重试」 2026-10-06 15:50:30 +08:00
AskaEth 85818105ce feat(settings): 退出登录从小图标按钮改成带文字的危险行条目，图标换 Remove（W52C） 
设置页最底部原来是一枚居中、无文字的图标按钮，图标用的还是「返回」箭头（MiuixIcons.Back），
真机上看着就是返回键——主人为此翻半天才找到登出在哪。这是本次改动的由来。

- 改成 Miuix 行条目（BasicComponent + 外层 PreferenceCard，与同页其它条目同形），文字「退出登录」，
  标题与图标都用 MiuixTheme.colorScheme.error 危险色。
- 图标换成 MiuixIcons.Remove：Miuix 里没有专门的登出/退出字形（Basic 只有 7 个图标），
  extended 里只有它画的是「箭头离开方框」，语义最接近「退出」；Back 是本条要修的毛病，
  Import 方向相反（箭头进方框＝导入/登录），Delete/Refresh 之类会被误读成删号或重来。
- 图标 contentDescription 置 null：文字已经把这条读出来了，图标再报一遍只会让读屏重复。

行为一字不变：仍然点了就登出（onLogout 一路接到 CyreneApp 里的 authManager.logout()），
没有新增确认流程。
 2026-10-06 15:48:54 +08:00
AskaEth 74a46bd2e3 fix(chat): 降级气泡不再给删改入口（W52/D）；空态补一枚显式「重试」（W52/E） 
## D —— W50 留下的窄尾巴：服务端不存在的那条气泡没有动作入口

`proactive_message` 落库失败那一档，客户端会画一条**只活在本端内存里**的气泡，它的 id 由本端自铸
（`proactive-local:` 前缀，见 `ProactiveIngest`）。而删除入口的判据 `canDeleteMessage` 只看 role ⇒
它是 assistant 行、长按能删 ⇒ 拿一个服务端没见过的 id 打 `DELETE`，最好的结果是 404。

修法按主人拍的口径收在 **UI 层**：新增 `ui/chat/MessageServerActions.kt`，在角色口径之上再叠一道
「这条消息在服务端存在吗」（判据只有 `id` 前缀这一条），组合成
`canEditMessageOnServer` / `canDeleteMessageOnServer`；气泡（菜单 + 「⋯」两个入口）与 VM 里那道闸
（`startEdit` / `startDelete`）**共用同一份**，不存在两套口径。
- **不动** `ChatDisplayItem`、数据模型与 `mergeMessages` 语义（原方案要加「是否服务端行」标志位，
  会连带动气泡渲染，超出范围）。
- 动作菜单里**只有**编辑与删除两个（一个 PATCH、一个 DELETE），都是打服务端的 ⇒ 降级气泡整菜单不出现，
  正是要的效果。**文本选择 / 复制不受影响**：它走 `SelectionContainer` 那条独立的路，`onLongPress`
  为 null 时反而不再与选字抢长按。

## E —— 首屏失败时给一个显式「重试」

登记在案的缺口：**REST 首屏失败、而 WS 从头到尾没断过**。这时没有任何状态变化可挂（连接没变过、
也没有断线窗口要补），屏幕会停在空态，直到用户切走再回来或上拉。

- `ChatViewModel.retryFirstPage()`：**只是转调** W51 提好的 `loadFirstPage()`（首屏唯一的一份实现，
  与连接恢复时补的那一次共用），**一个状态位都不自己写** —— `firstPageState` 的两个出口仍然只有那一处，
  W51 的 `reconnectPull` 判据依赖这条纪律。刻意**不是**定时器：项目从 W38 起就定死「状态驱动，不按时间轮」，
  而且反复重试会把「首屏失败」这个事实擦成 `Loading`。
- 空态那一档拆成两种真相（纯函数 `shouldOfferRetryOnEmpty`：不在加载中 + 挂着一个错误 + 列表为空）：
  「还没有消息」照旧；「消息没能加载出来」配一枚 Miuix `TextButton`（`CenterHint` 多一个可选 `onRetry`）。
  其余时刻一个像素都不多画。

## 测试

- 新增 `MessageServerActionsTest`（6 条）：钉住降级气泡两个入口都没有（并断言**旧判据确实说「能删」**，
  把「为什么需要这道闸」写进断言）、前缀与角色无关、只认**开头**的前缀、服务端行行为逐字不变、
  未知 role 仍 fail-closed。
- 新增 `FirstPageRetryTest`（5 条）：正题一格成立；正常空会话 / 首屏在飞 / 屏幕上有东西（含乐观与流式气泡）
  都不给；三个布尔八种组合穷举，钉住「有且只有一格成立」。
- `./gradlew.bat --console=plain assembleDebug testDebugUnitTest`：**95 suite / 1216 tests / 0 失败 / 0 error**
  （基线 93 / 1205，+2 suite +11 tests，全为新增）。
- 真机验收未做（任务书禁碰 adb）：按钮的位置与观感、以及长按降级气泡能选字，只能真机看。
 2026-10-06 15:47:49 +08:00
AskaEth d0b8c5f2f7 docs(05): 写死纪律——不准用 WaitFor 等子代理（会把回合锁住，主人无法插话） 
为什么：主人当场打断我的 WaitFor 并明确「纪律是不准用 WaitFor」。这条在后端仓库 AGENTS.md §10 里原本
就有，本项目文档此前没写、我因此重犯了一次。正确做法：派完就结束回合，等待期间只做不冲突的并行工作
或停手。
 2026-10-06 15:46:40 +08:00
AskaEth 4fce12249e docs(05): S7② 与 S3 的真机验收结清（S7② 通过；S3 在「在线冷启动进有内容次级会话」场景下否证） 
S7②（通过）：补洞请求打在已摘除的会话上 ⇒ 404 ⇒ sessionGone；那句 8 秒的告知抓到（[33,378][1047,480]）；
select(主会话) 的副作用 POST /sessions/web/read 两轮都观测到。⚠️ 同时**修正我自己写的判据**：原先要求
「read 出现在 GET /sessions 之前」——实测顺序不确定（两条协程各起），该顺序判据不成立；真正该验的
「refresh 失败时也能回去」本轮没做。

S3（否证）：screenrecord + ffmpeg fps=8 抽帧 + 逐帧量两块区域的深色墨迹（不改生产代码）。时间线是
启动画面（新版图标）→ 「加载中…」 → 内容，**没有出现「还没有消息」空态**。局限：8fps 采样（<125ms
的闪烁会漏）、单场景、单 build，不写成「S3 不存在」。

方法论：别用墨迹的 x 宽度猜那是哪句话——我一开始据此误判，抽帧一看是「加载中…」。
 2026-10-06 14:24:45 +08:00
AskaEth 9f04fc4304 docs(05): S7②/S3 第二轮受阻记录 —— 模拟器劣化与主机被占、不依赖 dump 的验证套路、收工状态 
为什么：这一轮 S7② 仍未验（进次级会话那一步没成），但花掉的时间都是环境问题而非代码问题，
必须把「先看主机在跑什么」「盲点 + 用服务端流水判结果」这两条写下来，下一轮别再重摸。
 2026-10-06 14:16:55 +08:00
AskaEth 0583b1bc31 docs(05): 补记 S7② 为什么这轮没验成 + 下次的干净起手（含判据与两个坑：表单错位、dump 陈旧缓存） 
为什么：S7② 需要「App 停在已删会话里」才能造场景，而登录表单被前几轮实验搞乱（地址栏残留 W48 的
坏值、字段错位），input text 落不进目标字段；uiautomator dump 还会返回陈旧缓存（同一交互前后两张
dump 的地址栏展开态互相矛盾）。把判据与干净起手写下来，下一轮别再重摸。
 2026-10-06 13:57:53 +08:00
AskaEth b604fefbd4 docs(05): 锚点补记二十九 —— W51 合并、S2/S7① 设备验收结论，并更正补记十九里 S7 那句写错的前提 
改了什么：
- 新增锚点补记二十九：W51 做了什么（S2 的纯判据与「首屏从没成功过」这个判据为什么这么定、S7① 的
  GoneSessions、S7② 真正的缺口是「出路不能依赖网络」）；设备验收结论（S2 通过：恢复网络后客户端自己
  补拉并显示出消息；S7① 通过：删掉会话后真踢一次 WS，重连窗口里没有注定 404 的补拉，而握手证明通路
  活着）；以及 S3 / S7② **未验**（如实写明，不写成「没问题」）。
- 更正补记十九里 S7 那句「`sessionGone` 位没有消费者」：消费者一直都在（ChatScreen.kt:165-166 →
  ChatHomeScreen.kt:109 的 onSessionGone），由 b5c0b13（2026-10-04、该行所依据提交 ff699f5 的祖先）
  引入，已用 git merge-base --is-ancestor 验证。这句是我写错的，W51 的任务书因此也带着错前提。
- 记下这次同类教训（第二次）：真机「没生效」时**先核设备上 APK 的 lastUpdateTime 与本地 APK 的时间**
  —— 我就是拿上一版 APK 测了半天；另记「撤 adb reverse 不会掐断已建立连接，要真抖 WS 用假后端的
  /__control/ws-close」。
 2026-10-06 09:20:40 +08:00
AskaEth 620a4e77fa merge: W51 —— 次级会话连接恢复自己补拉（S2）；已删会话不再发注定 404 的补拉、sessionGone 的出路不再依赖网络（S7） 2026-10-06 09:04:09 +08:00
AskaEth 9980fb2b28 fix(chat): 次级会话补上「连接恢复自己补拉」（S2）；已删会话不再发注定 404 的补拉（S7） 
## S2 —— 次级会话没有握手 history 这第二条安全网

- 新增纯判据 `ui/chat/ReconnectPull.kt`：连接恢复那一刻该补哪一段
  （Forward / FirstPage / Nothing）。判据只看四样：会话 id、首屏状态、掉线游标、
  「本端已知它没了」。
- `ChatViewModel`：把 init 那次首屏 `loadLatest` 提成 `loadFirstPage()`，init 与补拉
  **共用一份代码**（补出来的结果必须与首屏逐字段同形）；新增 `FirstPageState` 作为判据输入。

为什么这么定：
- **为什么不是照抄主会话的 history**：服务端固定回放主会话（`ws_hub_conn.go`），要它回放
  次级会话就是改契约面。次级走的是本项目已有的那条 REST 口径（拉最新一页）。
- **为什么用「首屏从没成功过」而不是「本端有没有数据」**：服务端真的没有消息时列表**也是空的**，
  拿空列表当判据会让每一个空次级会话在每次重连都被整表重拉 —— 那正是 S4/S7 这一类问题的成因。
- **为什么 Loading 不算失败**：首屏还在飞时再发一次同样的请求会与它抢跑，还会改掉
  「history 帧一到就 loading=false」那段时序（S3 本轮**一个字节都不动**）。
- **为什么主会话排除在外**：它有 history 兜底，在那里再补一条 REST 就是给同一件事造第二套口径。
  主会话的兜底行为因此**逐字不变**（有洞走 Forward，其余 Nothing）。
- 补拉那一次把 `loading` 翻回真：屏幕上原本是「还没有消息」停在原地，如实应该是「加载中…」。

## S7 ① —— 注定 404 的补拉不再发生

- 新增 `core/session/GoneSessions.kt`（进程级、**不持久化**、登出/换账号时清空）：本端已知
  「服务端没有这个会话」的 id 集合。写入口是 `SessionsViewModel.deleteSession` 成功那一刻
  （本端唯一的删除入口），读入口是**每一个** `ChatViewModel`。
- 判据第 1 条：已知它没了 ⇒ 什么都不发。于是本地删过的会话从此**零次**注定失败的往返；
  已经 404 过的会话从「每次重连各撞一次」收敛成**恰好一次**（`sessionGone` 同时成为补拉的闸）。

## S7 ② —— sessionGone 的出路不再依赖网络

那个位的消费者**一直都在**（`ChatScreen` 按它触发的 `LaunchedEffect` → `ChatHomeScreen` 的
`onSessionGone`：一句如实告知 + 带回主会话），所以本轮补的是它真正的缺口 —— 原来只靠 `refresh`
**成功**之后的 `resolveActiveSession` 回落（拉失败、或列表为空时刻意不回落 ⇒ 什么都不动）。
于是「已切回主会话」在网络不稳 / 服务端抖一下时是一句**做不到的话**，用户被留在已经没了的会话上、
没有任何出路。现在先在本端 `select(主会话)`（与用户点抽屉里那一行走的是**同一条**路，不另造机制），
`refresh` 退回本职：与服务端对齐、把抽屉里那条去掉。

## 未做 / 未验

- **没有真机验收**（任务书禁碰 adb）：S2 的「连接恢复后次级会话自己补上」只有纯判据单测。
- 「REST 首屏失败、但 WS 从头到尾没断（因此没有任何状态变化可挂）」这一格**不在本轮范围内**，
  仍是已知缺口。
- 全程未碰 S3、主会话兜底与游标口径、W48 的 VM key、W49 的节流判据、W50 的主动消息消费路径。
 2026-10-06 09:03:22 +08:00
AskaEth a9cc3c5737 chore(gitignore): 忽略仓库根的 IMG_*.png（主人从手机丢进来的素材，只用不存） 
为什么：主人明确「原图不进仓库」——换图标用的 IMG_20261006_081803.png（5.8MB）留在工作树即可，
加一条只作用于仓库根的忽略规则挡住误提交（只挡 IMG_*.png，不影响别处的图片资源）。
 2026-10-06 08:57:27 +08:00
AskaEth a025624798 feat(icon): 应用图标换成主人提供的新版画作（昔涟特写） 
改了什么：
- mipmap-{mdpi,hdpi,xhdpi,xxhdpi,xxxhdpi}/ic_launcher.png：新画作按 48/72/96/144/192 缩放（lanczos）。
- 同目录 ic_launcher_round.png：同一画作按圆形 alpha 掩膜裁出（ffmpeg geq），供圆形掩膜的启动器。
- 同目录 ic_launcher_foreground.png：自适应图标前景按 108dp 画布全出血（108/162/216/324/432 像素）。
  第一版把画心缩到 76/108，实测在这台启动器上会露出背景一圈；改成铺满画布后任何掩膜下都不会露底。
- values/colors.xml：ic_launcher_background #F8F8F8 → #FFE6E0（用 ffmpeg 对源图左上角 300×300 取平均色得到，
  与画作底色同调；前景已铺满，这个底色只在极端掩膜下才可能露出）。

为什么：主人把新版图标源图放在仓库根（IMG_20261006_081803.png，5033×5033、5.8MB），要求替换应用图标。
**源图不进仓**（仍是未跟踪状态），只提交生成物；构建与安装均通过，实机底栏图标已是新版。
 2026-10-06 08:30:53 +08:00
AskaEth 1d150cce85 docs(02): 客户端答复 —— 回执二十四·补：①推迟照办、②未读口径确认（维持 omitempty）、两条澄清，并反问 .end 能否带结果摘要 
改了什么（只加了我们这一节，未碰他们那一节）：
- ① 工具回看面推迟：照办。明确写死两条口径——不把「toolCalls[] 缺席」当「这轮没调工具」；
  不再按消息字面 join turnId（两者不是同一套标识）。也说明我们**不提前写**那个解析器。
- ② 未读面：回答他们的问题——**维持 omitempty 即可**，因为对我们权威来源是列表面（GET /sessions 恒带
  unreadCount），增量键只是省一次重拉的优化；接入口径按他们说的「键在才改、缺席什么都不做」。
  同时如实说明本端**还没消费**这个键（今天走的是 W49 的重拉，已实机验收），免得他们误以为已生效。
- 两条澄清：GET /api/v1/messages/{id} 我们从未用过（只有 PATCH/DELETE，SessionsApi.kt:130,137）；
  tool_execution (a) 维持收到。
- 反问一件与回看面无关的事：能否给 tool_execution.end 加可选 resultSummary（截断、缺席语义）——
  因为 .end 只带 tool/phase/id、update 又没有生产者，实时工具卡的结果区结构性为空；这是投入最小的一条。
  明确说「不做也接受，但请明说」，我们要的是确定而不是一定要这个键。
- 告知 W50/W48/W49 已落地并实机验收（不需要他们动作）。

为什么：他们那条回执标红了「别把缺席当没调过」，并直接问我们要不要区分「确实 0 / 不知道」——
这两个都是会决定他们改不改代码的问题，必须当场答清。
 2026-10-06 08:24:50 +08:00
AskaEth b23948bed0 docs(05/07): 锚点补记二十八 —— W48/W49 设备验收通过（换环境串味 / 抽屉未读角标） 
改了什么：
- 05 新增锚点补记二十八：W48 的判别法（先清空服务端主会话再换账号，否则两账号同一份历史看不出串味）与结果
  （A 的本地气泡与持久行在 B 账号下都 0 次、抽屉残留 0 次）；W49 的机制证据（抽屉关着时客户端自己在
  消息到达后 60ms 发出 GET /api/v1/sessions）与可见结果（次级会话行 未读 1、正在看的主会话无角标）；
  并更正一处认知：红点是抽屉内会话行的未读角标，菜单图标上没有点。
- 07 的坑清单补两条：① 登录页地址栏留空时 App 会回落到上次记住的地址（我因此白追一小时「请求怎么打到
  真后端」）；②「登出」是设置页最底部的图标按钮（图标是 MiuixIcons.Back、只有 contentDescription），
  截图上像「返回」很难找。

为什么：这批验收原来只有单测覆盖，结清后 05 的待办里不再挂着它；两条坑都是这次真实花掉时间的，
写下来避免下次重演。
 2026-10-06 08:24:00 +08:00
AskaEth c905a47d6f docs(05/07): 锚点补记二十七 —— W50 落地并设备验收通过；细节单开 07（证据与避坑） 
改了什么：
- 05 新增锚点补记二十七：结论（afee5f6 已推 / 1193 测试真跑 0 失败 / APK 尺寸）、四条硬要求逐条
  对应实现处、红线核对、设备四条判据全绿、环境坑一句话版、真后端那条主动路径是活的（副产品）、
  待办变化（W48/W49 验收环境已就绪；W50 的窄尾巴）。
- 新增 devdocs/07-W50-主动消息-验收与避坑.md：验收判据与逐条证据、完整环境坑（含绕法与命令）、
  复现整套验收的最短路径、随批次修掉的 timestamp 解码缺陷、以及「落库失败档」那条尾巴的收口建议。

为什么单开 07：05 已 1400+ 行，验收的操作细节与避坑属参考材料而非状态；05 只留结论与指针，
下一个我读 05 就能接手，需要动手复现时再翻 07。
 2026-10-06 08:11:26 +08:00
AskaEth afee5f612d merge: W50 —— 她主动说的话实时进主会话（proactive_message 消费 + 帧解码修复 timestamp 类型不符） 2026-10-06 07:51:26 +08:00
AskaEth 8b5d15bdb6 fix(chat): 她主动说的话实时进主会话（W50 proactive_message 消费 + 帧解码修复） 
缺口：她主动说的话既是实时帧、也是主会话历史里的一条 assistant 行，而安卓端实时看不到 ——
ChatViewModel.onEvent 里没有 ProactiveMessage 分支（落到 else -> Unit），另两个下行消费者也不认它；
而且帧里只解了 messageId（IM 侧的号），落库行的 id / createdAt 被 ignoreUnknownKeys 静默丢弃。
后端这条 Web 路由只发这一帧、不补 message_persisted，所以没有别的路能把它带进来。

一、帧解码（data/ws/WsEvent.kt）
- ProactiveData 与 ProactiveMessage 补上 id 与 createdAt（落库行的权威 id 与时间戳，同现同省）。
- 顺带修掉一个把整帧弄没的缺陷：载荷里的 timestamp 服务端是 Go time.Time，线上是 RFC3339 字符串，
  而本端按 Long? 解 ⇒ 解码抛异常、被 parse 的 runCatching 吞成 null，帧在成形之前就没了
  （所以只加一条 onEvent 分支根本碰不到它）。改成按线上的字面量收，数字形状也照样读出。

二、为什么按已落库行并入，而不是画一个只活在 UI 的气泡
真相是服务端历史里的那一行，实时帧只是它早到一步的副本：按 HistoryMessageDto.id 走既有的
mergeMessages 并入 ⇒ 实时能看到，且刷新 / 重开 / 切会话拉历史之后她的话仍在；同一条
（实时帧 + 握手回放 + 分页）无论到几次都只有一行，不需要任何额外去重。
判据抽成纯函数 proactiveIngestFor（ui/chat/ProactiveIngest.kt），可单测。

三、为什么必须自己钉死主会话
proactive_message 帧壳不带 sessionId（服务端构造这一帧时没设它，且该键是 omitempty），
而 isForSession 对空 sessionId 的口径是放行 ⇒ 这一帧会投给每一个活着的 ChatViewModel。
不钉就会在每个次级会话里都冒出一条她的话（比看不到更糟）。判据是等值比较、不是前缀：
主会话 web 与次级会话 web:xxx 是两个会话。

四、无 id 时为什么退化而不是丢弃
id 与 createdAt 一起缺席 = 服务端那一步落库失败了（它自己就说了这条没有历史行）。这时画一条
本地气泡，如实显示、不假装已落库：本地 id 用帧里已有的稳定键（IM 消息号，其次时间字面量），
同一个键第二次到达（重推 / 重放）也只是 upsert，不会成两个气泡。KDoc 写明它不在历史里、
刷新 / 重开后不会再有。
无 id 且无正文（帧里没有任何可显示的东西）才整帧跳过 —— 那一条画的是空气泡，只会让人以为出了别的事。

五、抽屉红点（复用 W49 那条路，不新写取数路径）
服务端不为这条路补 message_persisted ⇒ W49 的「非激活会话落新消息 ⇒ 节流静默重拉」不会被触发，
主会话的红点会停在她开口之前。SessionsViewModel 用同一个 persistedRoute 把这一帧接进同一条路
（复用 requestSilentRefresh 与既有的 InactiveSessionMessage 成因，不动节流判据本身）：
停在别的会话 ⇒ 节流静默重拉一次（红点亮）；正看着主会话 ⇒ 与 message_persisted 同一档
「看到即已读」，免得抽屉为她刚说的话亮一个红点。无 id 那一档不拉（历史里没有行，未读面上无事可做）。

测试
- 新增 WsEventProactiveFrameTest：真实帧形状（id / createdAt / RFC3339 的 timestamp）、数字形状容忍、
  落库失败那一档、以及「帧壳没有 sessionId ⇒ 会话闸对每个会话的 VM 都放行」这条事实。
- 新增 ProactiveIngestTest：归属（次级会话不并入、id 按等值比）、身份（有 id = 已落库行）、
  退化（本地气泡 / 空帧跳过）、不重复（重发与历史页都收敛成一行）。
- InactiveSessionPullTest 补一条钉子：她主动说的话该走拉列表还是「看到即已读」这条路。
 2026-10-06 07:50:33 +08:00
AskaEth 5520d6015d docs(05): 更正代理旧路径引用（工具已在 devtools/ws-block-proxy/，历史条目不改写） 2026-10-06 07:45:31 +08:00
AskaEth 4c938c7330 docs(devtools): 假后端补「主动消息」验收配方（proactive_inject.py + README 场景五） 
改了什么：
- 新增 devtools/fake-backend/proactive_inject.py：按真后端 SendProactive 的顺序
  （先落库、再发帧）造一条主动消息 —— 落一行 assistant 历史行，再广播带同一 id/createdAt 的
  proactive_message 帧。--without-id 是另一档（落库失败）：不落行、帧上不带 id。
- README 新增「场景五」：完整命令序列 + 帧形状 + App 侧三条判据；端点速查/形状出处/已知不确定
  各补一条。
- 更正两处过时内容：§1 的工作目录还是旧 worktree 名 Cyrene-Android-FB；§8 说「客户端 W41 起先探
  /health」——W45 已把那整套删掉（SendFallback.kt:120），这个端点客户端不再消费。
- 记录踩到的坑：ws_probe.py --listen N 单独用只有 1 秒（ws_probe.py:201 是 min(listen, 1.0)），
  不带 --send/--ping 时连接会先关掉，之后所有广播都是 delivered=0。

为什么：
- 真后端没有任何 HTTP 入口能按需触发一次主动推送（backthink 只由心跳/事件决定，路由里只有一个
  GET /admin/backthink），所以「她主动说的话」在客户端这一段的验收只能自己造帧。真后端只把
  proactive_message 广播给在线连接、没有离线补发，帧壳又不带 sessionId（客户端必须自己钉主会话）
  —— 形状抄错或漏掉落库那条腿，验出来的结论就是假的。落成脚本 + 文档，下次不必重推。
 2026-10-06 07:44:31 +08:00
AskaEth d9b7c22ecb docs(05): 锚点补记二十六——续接锚点（现状/环境/设备驱动协议/W50 在飞与合并检查清单/W38~W49 索引/待办排序/与后端状态/方法论教训），供下一会话直接接手 2026-10-06 07:38:29 +08:00
AskaEth d5d2feee36 docs(05): 锚点补记二十五——W48（账号指纹进 VM key 修 S1 + 搜索 VM 同类缺陷 + 5 处错注释 + 代理挪进 devtools）与 W49（非激活会话节流静默重拉修 S6，3 秒窗口 + 结构性 trailing + 一处刻意偏差）落地；合并后 1177 测试全绿 2026-10-05 22:30:08 +08:00
AskaEth 5dc6408bb9 merge: W49 —— 非激活会话落新消息时节流静默重拉（3 秒窗口 + 结构性 trailing），让抽屉红点在不开抽屉时也能出现 2026-10-05 22:28:39 +08:00
AskaEth 93cf3e359a fix(sessions): 非激活会话落新消息时自愈式节流重拉，抽屉红点不再等用户开一次抽屉（S6） 
现象：App 停在主会话时，次级会话落了新消息 ⇒ 抽屉红点不出现，必须打开一次抽屉
（那次静默 refresh）才补上。

根因：message_persisted 只在 sessionId == activeSessionId 时才推进 / 更新，非激活
会话那一帧直接 return；而会话列表更新的触发点此前只有抽屉打开 / 新建 / 删除 / init
四处，于是「别的会话攒了新消息」没有任何人会去发现。

为什么是客户端自愈而不是等后端：这一帧不带 unreadCount（契约面缺一个增量），而本端
没有逐条时间线 —— 自己累加出来的数会与编辑 / 删除 / 别端操作漂移，那是造数不是修复。
帧壳本身已经说清「某个会话有新消息落库」这件事，所以本端只是据此去问一次服务端，
走的是与抽屉打开时那次完全相同的路径（refresh(silent = true)，含已读游标遮罩），
只是不需要用户先开一次抽屉。后端把增量补上之后这条路可以退成不必走，但在此之前它
是唯一能把红点点亮的路。

节流窗口 3 秒，理由：
- 够快：3 秒落在「看起来就是刚发生的」这个感知里；5 秒往上就开始像卡了一下才补上；
- 够粗：一次静默重拉是两个请求（refresh 里还跟着一次角色目录），而播出方是按每条
  消息推帧的 —— 3 秒能把人手连打 5 条（约 2~4 秒）或一轮回复的连续落库收进同一个
  窗口，收到 1 秒就会漏成两三次请求；
- 不另立尺子：3 秒正是本项目已有的「等够久才值得为一次等待开口」那个量级
  （ChatScreen 的 SHARE_WAIT_NOTICE_MILLIS）。

trailing 怎么保证：窗口内的第二条起不拉，但排一次「窗口到点补拉」（等待时长 =
窗口 - 已过时间），到点直接拉一次并把窗口重开；同一时刻最多一个补拉任务（已排上时
后续成因只更新账本、不重排），所以最后一条之后必定还会再拉一次，红点不会停在旧值。
另外「正好等于窗口」算窗口已过（>= 而不是 >），补拉到点那一刻不会被自己刚开的窗口
挡回去。

哪几种情况不拉：当前打开的那个会话落新消息（那条路本来就有「看到即已读」，多拉一次
列表就是白花两个请求）；同一窗口内的后续消息；窗口内且补拉已经排上。另外切会话那条
路刻意不接进来 —— select 紧接着就发推进已读游标的请求，此时重拉会与还没落地的游标
抢跑、把刚清掉的角标闪回来（抽屉打开时那一次紧跟在游标之后，本来就会补上这一拉）。

判据抽成纯函数（新增 InactiveSessionPull.kt）：persistedRoute 决定这一帧走哪条路，
silentRefreshStep 决定这一刻该不该拉、拉完账本怎么走；时钟由调用方喂，不用 sleep
也就能穷举边界。

顺带把身份变化（重登成另一个账号 / 换了服务器地址）也接进这条路径，用 ContextChanged
绕过节流窗口 —— 那份列表换了主人，等满一个为「别的会话又攒了几条」而设的窗口没有
道理；登出时把账本与补拉任务一起作废（否则补拉会带着一个已经没有令牌的身份发请求）。
抽屉打开时那次 refresh、activeSessionId 的推进、已读游标的既有行为都没动。

验证：gradlew.bat assembleDebug testDebugUnitTest —— BUILD SUCCESSFUL；
1171 条单测 failures 0 / errors 0 / skipped 0，其中新增 InactiveSessionPullTest 13 条。
 2026-10-05 22:28:19 +08:00
AskaEth e589ab303d merge: W48 —— 聊天页 VM key 带上账号指纹（修换环境后仍显示上个环境的会话）+ 注释纠错 + 把 WS 拦截代理挪进 devtools 2026-10-05 22:26:44 +08:00
AskaEth 40dac87dda docs(05): 补记二十四附——本轮两个决定（P1 主动消息消费我方接、tool_execution 选 a 并要 toolCalls[] 回看面带输出）与推送暂不接的口径 2026-10-05 22:26:09 +08:00
AskaEth 766843fdbd docs(02): 客户端答复回执二十二·补的四问——主动消息「不会两次」但真缺口是「我们没消费那帧 ⇒ 实时看不到」；tool_execution 选 (a) 并附取舍；纠正「每屏一条 WS」过时前提；推送暂不接并说明「应用内提示」在客户端零实现 2026-10-05 22:25:59 +08:00
AskaEth 4f860aa499 fix(chat): W48 聊天页 VM key 带上账号指纹，修换环境后仍显示上个环境的会话 
缺陷：换账号或换服务器后，聊天页仍然摆着上一个环境的消息。成因是 ChatScreen 里那个
ChatViewModel 的 owner 是 Activity 级的 ViewModelStore，而登出只是把 ChatHomeScreen
移出组合、并不清理那个 store（ChatViewModel.onCleared 是空的，全仓也没有 ViewModelStore.clear()）。
key 里只有 sessionId 时，换环境再进来 viewModel() 会把上一个环境那个还活着的实例原样取回来，
它继续收着那个环境的帧，屏幕上就是别的服务器的消息。主会话的 id 恒为 web，两次登录必然撞上
同一个 key，所以这不是理论风险。

为什么 VM key 要带账号指纹：指纹回答的是「这份本地状态属于哪个环境」。把它抽成纯函数
accountFingerprint(baseUrl, username)，与 SessionPreferences 判断快照作废、
SessionsViewModel 落盘快照用的是同一份口径（SessionsViewModel 原本就地拼的那串改成调用
同一个函数，免得两套判据分叉——分叉的那一侧就是漏出去的那一侧）。同一个环境里切会话，
key 未变，各会话的状态照旧各留一份（这正是「切回来状态还在」依赖的）；环境一变（换了服务器
或换了账号），key 就变，取到的一定是新实例。

会话内搜索那个小 VM 是同一类残留：它持有的命中就是消息正文，换环境后在主会话上重开搜索，
面板里就是别的服务器的消息。它的 key 同样带上指纹。

为什么本轮不回收旧 VM：要真正回收掉上一个环境那个实例，得自定义 ViewModelStoreOwner 或直接
清 store，而「切回来状态还在」这条体验正绑在 store 不清这件事上，属于要主人拍板的设计取舍。
本轮只保证换环境后取到的是新 VM，回收这件事不动。

顺带的零成本纠错（只改注释的成因描述，行为一字未动）：ChatHomeScreen / ChatScreen /
ChatViewModel 里几处「onSessionGone 一被调用，那个会话的 VM 连同它的状态立刻被销毁」是错的——
变的是 key，被销毁的只是承载横幅的那段组合；VM 实例仍在 Activity 级的 store 里活着并继续收帧。
「横幅必须挂在上一层」那条结论本身是对的，原样保留；改的只是它前面的理由。
同时把 devtools 里那个窄代理的路径写对（此前注释指向一个并不存在的路径）。

开发工具挪出会被 clean 扫掉的位置：app/build/e2e-shots/ws_block_proxy.py 躺在 gitignored 的
app/build/ 里，一次 gradlew clean 就没了。挪进 devtools/ws-block-proxy/（与 fake-backend
同级同风格）并配 README，写清用途、用法（python ws_block_proxy.py 18098 10942，配
adb reverse tcp:10942 tcp:18098）与它最有价值的判据：调试时 Web 前端直连后端、不经过
adb reverse，所以代理日志里的每一行都只可能来自 App。脚本行为未改，也没有硬编码任何凭据。

新增单测 ChatViewModelKeyTest 钉住拼法：同账号同地址 => 同 key；换地址 / 换账号 / 换会话
=> 不同 key；username 缺失时退化成 baseUrl 一段，换地址仍然分得开。

验证：gradlew.bat assembleDebug 与 gradlew.bat testDebugUnitTest，
BUILD SUCCESSFUL；单测 1164 条，failures 0、errors 0、skipped 0。
 2026-10-05 22:25:57 +08:00
AskaEth a4ac11a1c1 docs(05): 锚点补记二十四——流程教训：动 02 之前除 git status 还要 diff 它最新几十行（我差点在没读后端回执的情况下给后端写信）；并登记后端正在等我们回的四件事与「每屏一条 WS」这个过时前提 2026-10-05 22:23:44 +08:00
AskaEth 7d1c56e03b docs(02): 给后端一份「我方实际依赖的线形状」清单（clientMsgId 幂等是我们敢重发的唯一安全基础、REST stream 回执必须仍是小 JSON、鉴权失败只认 401…）+ 两条已登记缺口的提醒 + 告知客户端已不再调 /health + 提供 CyreneRoute 日志作为联调取证 2026-10-05 22:22:58 +08:00
AskaEth c09c40388b docs(05): 锚点补记二十三——登记在飞的两个 worktree（W48 修 S1+注释纠错+工具归位；W49 修 S6 客户端自愈）与合并纪律 2026-10-05 22:21:49 +08:00
AskaEth 324be57c7a docs(02): 客户端登记——「非激活会话红点不实时增长」缺一个未读增量面（message_persisted 不带 unreadCount），并说明我方先用客户端自愈顶着、它不能替代增量面 2026-10-05 22:21:48 +08:00
AskaEth df8df67742 docs(05): 锚点补记二十二——③ 结案：阶梯机制正常（两次有效观测 route=Rest 且落库），W45 那轮异常未复现也因当时无 CyreneRoute 日志而无法定论；并写死一套可靠的设备驱动协议（确认前台→确认文字落点→从 dump 取发送键坐标） 2026-10-05 22:12:16 +08:00
AskaEth f2075c1f49 docs(05): 锚点补记二十一——移除键补验有效（附我复用旧坐标点空的教训与布局回流说明）；③ 的第一次尝试没跑成（CyreneRoute 为空、代理无 POST、库无该条 ⇒ 发送没触发），并写明下一轮必须三步确认的做法 2026-10-05 22:10:00 +08:00
AskaEth df20a21fb5 docs(05): 锚点补记二十——W42 图片多选设备验收通过（多选器是真多选、计数「添加（2 项）」正确、输入栏出现两枚带移除键的缩略图），并登记移除键位置这处观感待主人定 + 两个未验的邻近格 2026-10-05 22:05:21 +08:00
AskaEth 669d05b781 docs(05): 锚点补记十九——子会话流程变成清单（S1~S9，每条带文件:行号与归类），先纠正我自己两条错前提，附 12 步设备验收骨架、优先级建议与 ws_block_proxy.py 不在 git 里的提醒 2026-10-05 22:01:20 +08:00
AskaEth ff699f5079 docs(05): 锚点补记十八——W47 静默按事故复位（清零点收进一个纯判据、事故=队列空到空），含为什么不选「只在成功时清零」与三条验收体验 2026-10-05 20:25:58 +08:00
AskaEth 3a07e94180 merge: W47 —— 队列静默改为按事故复位（队列排空即清零），不再只在补发成功时清零 2026-10-05 20:25:23 +08:00
AskaEth ce50bd2c24 feat(chat): 静默告知改为按事故复位，队列排空即清零 
W43 的静默规则只在「补发真的成功一次」时把 queuedResendFailures 清零。若一段坏网络的
队列以回滚或被收编收场（一次都没成功发出去），这一格就永远挂着 ⇒ 之后连接恢复、再断
一次、用户又发消息时，那句解释再也说不出口。那不是减少噪音，是把解释永久关掉（主人
2026-10-06 裁决：哪个体验好用哪个）。

改成按事故复位：一个「事故」= 队列从空到非空、再回到空，结束就复位，不管它是怎么结束
的——发出去了、回滚了（内容退回输入栏）、还是被收编了（气泡换成权威消息）。清零点因此
有两个：补发成功一次（原样保留），以及队列排空（既有钩子 forgetQueuedNoticeIfDrained，
回滚那条路也走这里，它是队列清空的唯一两个入口之一）。

这样不会在长期断网时刷屏：阈值仍是 3；「一批从空到非空只说一次」仍由 queuedNoticeTold
管着；纯网络故障下消息会堆积在队列里 ⇒ 队列不清空 ⇒ 不算新事故、计数不复位 ⇒ 不会每条
消息都弹一次横幅。而事故一旦结束，下一次断线又能重新解释。

判据提为纯函数 queuedResendFailuresAfterDelivery（VM 与测试共用，跟
queuedSendNoticeAllowed 同一个写法），单测钉住：队列排空即复位（哪怕这一批一条都没成功
发出去）、队列还有货则计数保留、补发成功照旧清零、一个事故里失败 0/1/2 次仍允许告知而
到阈值静默、下一个事故重新告知。静默不动队列：那条既有用例（判定那一刻队列仍在、下一步
仍是发这条）一字未改。

只动告知判据与它的记账。队列与出队逻辑、sendRouteFor / 三档路由 / W38 分享落地 / W45
直接试 REST / W46 的 CyreneRoute 日志全部未碰。

验证：gradlew.bat clean assembleDebug 与 gradlew.bat testDebugUnitTest，
failure / error 均为 0。
 2026-10-05 20:25:00 +08:00
AskaEth 798c6ee907 docs(05): 锚点补记十七——W45 阶梯设备验证通过（route=Rest、代理见 200、落库 1 条），附我连续三次误判的共同点与三条设备验证纪律，以及工具卡缺口的根因与登记位置 2026-10-05 19:53:16 +08:00