AskaEth/Cyrene-For-Android
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 5 Wiki Activity
267 Commits 3 Branches 5 Tags
14955ef6c05973825e0fe8a32f4578d9f169ca23
Commit Graph
267 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
AskaEth 14955ef6c0 feat(chat): 分享确认面板的正文预览可以展开 / 收起 
问题：W54D 把正文那一窗改成「三行 + 内部滚动」之后「读不到整段正文」是解决了，但一次只看得见
三行。主人拍板「可以滚动 可以展开」——两个都要，所以这一轮补上后半。

改法（只动 ShareConfirmPanel.kt 与它的测试，ChatScreen / ChatViewModel 与接线一字未碰）：
- 正文卡片里加一枚「展开 / 收起」（`Text` + `clickable`，不用 `TextButton`：按钮自带高度会把
  这一行撑高一截）。它挂在「分享的文字」那一行的右端，不挂在正文末尾——展开后正文可能好几屏，
  末尾那枚「收起」要滚到底才找得到。
- 收起态一个字没变：三行窗（SHARE_PREVIEW_TEXT_LINES = 3）+ 内部滚动。
- 展开态：正文那一窗撤掉自己的上限（`heightIn(max = Dp.Infinity)`，正是首帧那个状态），整段交给
  外层预览区滚；外层上限由 150dp 抬到 240dp（SHARE_PREVIEW_EXPANDED_MAX_HEIGHT）。展开态**只留
  这一层**滚动是刻意的：两层都设上限时手势先被内层吃掉、内层滚到底才轮到外层，两层上界还互相
  牵制，最容易出的错就是「明明展开了还剩半截读不到」。
- 控件**只在正文排下来超过三行时出现**。判据是行数 > SHARE_PREVIEW_TEXT_LINES，不是
  `hasVisualOverflow`：这一窗的高度不受限（`verticalScroll` 给子项的就是无上限约束），`Text` 自己
  永远报「没有溢出」，拿它当判据会在最长的那种正文上漏掉控件；行数则与上限无关，首帧就可用。
- 展开态为什么是 240dp：这个上限管的是**整个预览区**，下面还压着描述输入框（最多 4 行）与两枚
  按钮，面板贴着屏幕底、键盘一弹可用高度只剩半屏上下。150 → 240 在默认字号档上把正文窗从三行抬到
  十行上下；再往上（例如整屏的六成）先被顶掉的会是按钮。⚠️ 这个数**没在真机上量过**，是按这笔账
  取的保守值，观感由主人验收，要调只改这一个常量。
- 两条判据都做成纯函数（`sharePreviewTextOverflowsWindow` / `sharePreviewMaxHeight`），调用点只读
  结论，单测钉的就是它们。

上一批留下的「首帧回流会不会看得出来」疑点，复核结论：**留着，且确认它看不见**（理由已写进
`ShareConfirmBody` 的 KDoc）：① 首帧那一下撑不动任何别的东西——正文块是预览区里的最后一个元素，
可视像素只由外层那层独立的上限裁剪决定，上面图片/文件的位置一分不动；② 展开态本来就没有这一层
上限，不存在「量完再回落」；而展开 / 收起那一帧的尺寸变化是用户动作的**目的**，不是回流。真正多
出来的是控件本身（第二帧才出现，因为行数是排完才知道的），它与标签同用 `footnote2`、行高不变，
也顶不动任何东西。组合期 `rememberTextMeasurer` 那条路要外包 `BoxWithConstraints` 拿宽度、还要
自己复现字号与字体缩放，等于把排版做两遍——为一个看不见的跳动换掉结构不划算，不做。

已知取舍（如实记下，没修）：转屏（Activity 重建）后展开态回到收起。它现在活在
`remember(preview.text)` 里，跨转屏要活下来只有两条路——进 `ChatUiState`（W54C 给「已取走的分享」
与描述走的就是那条路，但那是 ChatScreen / ChatViewModel 的地盘，本批红线不许碰），或
`rememberSaveable`（本仓一次都没用过的新写法，且弹层窗口带不带 saveable registry 没在真机上验过）。
两条都没走，留一条 ⚠️ 在代码里 + 留给主人定。

测试：新增 3 条（纯函数判据）——「什么时候该出现展开控件」（0/1/3 行不给、4 行起给，并接一份
40 行的真分享走一遍）、「展开态给多高」（150 / 240 两个字面量 + 展开严格更高 + 不超过收起态的
两倍）、「两句标签不同且非空」。展开与滚动本身单测够不着（本模块没有 Compose UI 测试的依赖），
如实说明；既有断言一条未放松。

验证：`./gradlew.bat assembleDebug testDebugUnitTest --tests "*ShareConfirm*"` → BUILD SUCCESSFUL
（ShareConfirmTest 15 条 = 既有 12 + 新增 3、ShareConfirmDraftTest 3 条，0 失败 / 0 错误）；
全量 `./gradlew.bat testDebugUnitTest` → BUILD SUCCESSFUL，112 suite / 1361 tests / 0 失败。
 2026-10-06 21:43:12 +08:00
AskaEth 9ff2de3a1d merge: W55 —— 解析器剥掉落单标签（修后端畸形 <p><p>正文</p> 导致标签字面显示在气泡里） 2026-10-06 21:26:34 +08:00
AskaEth f3c1121887 merge: W54D —— 分享确认面板正文预览改成三行窗口 + 内部滚动（发送前能读到整段正文） 2026-10-06 21:26:33 +08:00
AskaEth a861881ec4 merge: W54C —— 转屏不再静默丢掉已取走的分享（面板状态与描述移进 ChatUiState，take 仍只发生一次） 2026-10-06 21:26:29 +08:00
AskaEth b3ded77c23 merge: W54A —— 通知一事一条（通知 id / PendingIntent requestCode 按消息稳定派生，修她连说几句时后到覆盖先到） 2026-10-06 21:26:26 +08:00
AskaEth 464e91621e fix(parse): 容错落单的段落标签，绝不把 <p> 当正文渲染 
真机实测：后端产出的某条消息第三段是 `<p><p>那现在…？</p>`（两个开标签、一个闭标签）。
P_BLOCK_RE 是非贪婪的，先把外层 `<p>` 配到那个 `</p>`，内层那个裸 `<p>` 就成了「块内容」；
而 appendAnnotations 只认 `<action>` / `<narration>` / 星号，不认裸 `<p>`，于是它作为普通文本
落进气泡正文，屏幕上直接显示 `<p>那现在…`。

改了什么：新增 stripLooseTags，在切出 `<p>` 块之后按区剥掉「落单标签」——
- 消息里已有完整 `<p>…</p>` 块时，块内块外多出来的每个 `<p>` / `</p>` 一律剥掉，块外没被
  ROLE_RE 认领的 `<action>` / `</action>` 同样剥掉；
- 一个完整块都没有时，维持既有「未闭合 `<p>` 整段回落字面文本」的契约（编辑框靠它保证不
  静默改字），只再剥两类连「被截断的结构」都算不上的东西：落单的 `</p>` 与后面什么都没有的空开标签。
判据只认完整匹配已知标签词表的形状，`1 < 2` / `<3` / `a<b` / `<p2>` / `<P>` / `<p`(残缺) 一律原样保留。

为什么选择「剥」而不是「原样显示」：这些是服务端产出的标记、不是她说的话；渲染成正文等于往
气泡里塞一串用户既看不懂、也改不掉的字符，而剥掉只是少显示几个本就不该出现的字符，正文一个字
都不动。这只是客户端的容错，不代表服务端这样发是对的。

流式：stablePrefixEnd 不动。扣留点取「第一个没闭合的开标签」，而前缀里的每个开标签必定在同一个
前缀内配到闭标签，所以「是不是落单」在它被产出的那一刻就已定死，中间态剥掉、收口也不用改口；
放宽扣留（把重复的 `<p><p>` 当外层冗余）反而会让 `<p>甲<p>乙` 在中间态把 `<p>甲` 当字面文本吐上屏，
等 `</p>` 到了再跳成 `甲乙`。新增测试钉住这条：逐字符喂实测畸形串时，任何一帧都不许漏出标签，
且已显示的正文只许增不许改口。

测试：assembleDebug 通过；ChatContentParserTest 55 项全绿（新增 17 项）；全量 110 suites /
1349 tests / 0 failures / 0 errors（主仓同 HEAD 基线 110 suites / 1332 tests，本次 +17 项）。
 2026-10-06 21:26:07 +08:00
AskaEth ec89d828d1 fix(chat): 分享确认面板的正文预览改成三行窗口 + 内部滚动 
问题：正文那一窗此前是 maxLines = 3 + 省略号，超过三行的分享正文在按「发送」之前根本读不到。
面板里再没有第二处放着这段正文（输入框只剩「用户附加的描述」，初值恒为空），截断就等于
「要发出去的那段正文看不见」——而这正是用户点「发送」时唯一要确认的东西。

改法：正文那一窗高度恒为三行、内部可滚，外层预览区那 150dp 的上限原样不动，所以面板不会被
长正文撑高（图片 / 文件芯片 / 按钮的位置都不变）。滚到底后余量交给外层 scroll，嵌套滚动本身
就有，不用额外接线。

上限为什么不是写死的 dp：Miuix 的 footnote1 只给了 13sp 的字号，lineHeight 是 Unspecified，
行高由系统字体的 ascent/descent 决定、随「大字体」设置一起缩放。写死 dp 在默认字号档上勉强
对得上，到大字号档就会矮一截、把末行的字切一半。所以改为量：从 TextLayoutResult 上取第三行的
底边当上限，量到之前先按无上限排一次（heightIn(max = Dp.Infinity) 在确认过 Compose 的
Density.roundToPx 对 Infinity 的处理后是安全的，即「没有上限」）。

SHARE_PREVIEW_TEXT_LINES 由 private 改 internal，只为让单测能把「这一窗是三行」钉成字面量
（本模块没有 Compose UI 测试的依赖，滚动行为单测够不着）。

测试：新增两条——正文远超三行时纯函数层仍原样交付**完整**正文（一个字不少、不加省略号），
以及三行上限的字面量；既有断言一条未放松。
 2026-10-06 21:11:30 +08:00
AskaEth 1142bf5ed1 fix(share): 转屏不再静默丢掉「已取走、还没确认」的那份分享 —— 面板状态移进 ChatViewModel 
分享进来的内容被 `ShareIntake.take()` 取走之后没有归还路径，而它此前只挂在一格
`remember(sessionId)` 上：Activity 因转屏 / 深浅色切换重建时那次组合整份丢掉，那份分享
**既不在待发队列里、也不在界面上**（用户什么都没看到，也没有任何提示）；用户已经输入到
一半的那句描述同样丢。

改法：把「已取走、正等确认的那份分享 + 用户补的描述」移进 `ChatUiState.shareConfirm`
（`ShareConfirmDraft`），那一格由 VM 持有，而 VM 活在 `ChatSessionSlots` 的 `ViewModelStore`
里、由 AppContainer 撑着 —— 比组合与 Activity 都活得久，所以重建之后面板照旧长出来，
描述也跟着回来（描述与正文绑在同一个值里，两者同生共死）。

`take()` 仍然只发生一次：认领那一步收进 `ChatViewModel.claimSharedContent`，闸门是纯函数
`shareConfirmClaim`，且**在 `take()` 之前** —— 手上已经有那份内容时一个字节都不动队列
（既不取新的一条，也不会把用户正看着的那份顶掉）。重建后的新一帧照样会走到判据这里，
而那时手上已经有东西（它活在 VM 里）⇒ 不会再取第二次。判据、出队、落地之间没有挂起点，
所以也不存在「取走了却没记住」的窗口。

顺带把这一格计入 `holdsUnsentWork`：这份内容已经没有退路，那一格被回收就等于把它删掉。
`ShareLanding` / `ShareIntake.take()` 里「取走之后直接发」的旧说法一并改成「交给确认面板」。

新增 ShareConfirmDraftTest：钉住「重建后的第二帧不再调 take、队列里那条也不许被取走」、
「内容与描述原样还在」、「队列为空时不造一个空面板」。
 2026-10-06 21:09:15 +08:00
AskaEth 53339b369a feat(notify): 她主动说的话改成「一事一条」——通知号按消息派生，后到的不再顶掉先到的 
改前所有她主动说的话共用一个固定的通知 id，而同 id 的 `notify` 是**替换**：她连说几句时后来
的那条把先来的顶掉，用户拿起手机只看到最后一句，前面几句一声没响就没了（这正是 W50 判据下游
的落地形状）。

改成按消息派生：
- `ProactiveNotify.kt` 新增纯函数 `proactiveNotificationId(key)`：把**去重键**（`proactiveNotifyKey`
  的输出）折成通知号。刻意与去重键同源——去重说「这是同一条」、派生说「这是同一条 ⇒ 同一个号」，
  两处口径一旦分成两套，就会出现「认得出是同一条、却排出两条通知」的形状漂移（实时帧与落库帧
  两条路都会到，这条尤其要命）。
- 两个坑都真的堵上：① 号必须 > 0，而 `hashCode()` 可以是负的、甚至正好是 `Int.MIN_VALUE`
  （`abs(Int.MIN_VALUE)` 在 int 域里仍是它自己）⇒ **先展宽到 `Long` 再取绝对值**，不引任何新依赖；
  ② 不撞既有 id：全仓只有保活那条常驻通知（id = 1）与它 `PendingIntent` 的 request code = 0 是
  占用者，派生的号从 1000 起步、宽度 2×10⁹，落点与它们**结构性**不相交。
- `ProactiveNotifier.post` 的签名带上这个号（`post: (text: String, notificationId: Int) -> Unit`），
  `AppContainer` 的装配 lambda 同步改；`ProactiveNotification.kt` 删掉恒定的
  `PROACTIVE_NOTIFICATION_ID` / `PROACTIVE_OPEN_REQUEST_CODE`，通知 id 与 `PendingIntent` 的
  request code **一起**随消息走（只换 id 不换 request code，点后到的那条通知会串到先到那条的
  `PendingIntent` 上）。
- 撞号仍会发生（`String.hashCode()` 只有 32 位）：后果与改前一样是「后来者替换先来者」，已在
  `proactiveNotificationId` 的 KDoc 里如实写清概率，以及为什么接受这一侧。**没有**放松任何既有断言。

测试：新增 `ProactiveNotificationIdTest`（同一条派生两次同号 / 两条不同消息不同号 / 任何输入恒 > 0，
最后一条用 hashCode 正好是 `Int.MIN_VALUE` 的字符串 `polygenelubricants` 钉住前提）；另在
`ProactiveNotifierTest` 加一条端到端的号断言（两条路都到的第一条只发一次且号不变、第二条是另一个
号）。`ProactiveNotificationShapeTest` 里那条「不与保活那条相撞」改成扫一遍真实形状的键。

验证：`./gradlew.bat assembleDebug` → BUILD SUCCESSFUL；`./gradlew.bat testDebugUnitTest` →
BUILD SUCCESSFUL，111 suite / 1336 tests / 0 失败（基线 110 suite / 1332 tests，本批净增 4 条）。
 2026-10-06 21:08:23 +08:00
AskaEth e5e61e131d docs(05): 锚点补记三十四 —— 压缩后续接（W54 三支并行在飞：通知一事一条/转屏丢分享/预览可滚动；第二批进程级订阅待开）+ 主人三条拍板（预览要滚动+展开、提示词已贴等回执、推送待研究）+ 环境核对 2026-10-06 21:02:43 +08:00
AskaEth 33c320219a docs(05): 锚点补记三十三 —— 续接锚点（仓库现状/本轮八项已完成及其真机证据/保活长跑在跑/待主人拍板四条/环境与两个会踩空的地方/两条教训） 2026-10-06 20:59:32 +08:00
AskaEth 827f0e61a4 docs(05): 锚点三十二补第 6 节 —— 分享面板语义改对并上机验过（预览留正文 / 输入框空+占位符 / 正文+空行+描述 拼接端到端验过）+ 保活长跑因装包重起（新基线 20:13:35 / pid 25584） 
另记两条：① 预览正文仍只有 3 行 ⇒ 发送前读不到全文，属观感取舍待主人定；② adb am start 的 --es 值会被空格拆开（我那次 URL 就是这么丢的，不是 App 吞的）。
 2026-10-06 20:13:52 +08:00
AskaEth 30c53451dc merge: W53X3 —— 分享面板的输入框改成「用户附加的描述」（默认空 + 占位符），正文留在预览区；发送时把分享正文与描述拼起来（空行分隔） 2026-10-06 20:10:03 +08:00
AskaEth 514901c12d fix(share): 确认面板的输入框改成「用户附加的描述」——不再预填分享正文，发送时由正文+描述拼成 
W53X 的第一版把那个输入框当成了分享正文的可编辑副本（`shareConfirmDraft(share)` 直接返回分享
正文、由 ChatScreen 预填进去），在真机上就渲染成「同一句话排两遍」：预览的「分享的文字」块一遍、
输入框里又一遍，而输入框里那句还看着像一段只读展示。主人澄清语义：那个框是**用户要附加的描述**
——「这次要发什么」归预览，「你想补一句什么」才归这个框，两件事被合成一件才是根因。

改成：
- 输入框初值**恒为空**（`shareCaption` 在取走一份分享时显式归零），占位符改成「加一句描述…」
  （与输入栏那句「和昔涟说点什么…」同一个 `useLabelAsPlaceholder` 写法）；预览区一个字没动
  （图片缩略图 / 文件 chip / 分享正文都留着，那才是这次要发出去的东西）。
- 新增纯判据 `shareConfirmBody(share, caption)` = 分享正文 + 用户描述：两段都在时用**一个空行**
  分隔，只有一段就只用那一段，都空就是空串（两侧空白按 `ShareRules.extract` / `sendShared`
  的口径归一，中间一个字不动，也不加任何来源标记——那是项目红线）。
- 删掉 `shareConfirmDraft`（名字说「草稿/正文」、行为是「把正文当输入框初值」，留着就是骗人）；
  `shareConfirmCanSend(share, caption)` 改成**直接问 `shareConfirmBody`** 非空、或另有图片/文件，
  于是「发送」可点与否与 `sendShared` 开头那条早退同源；描述为空时不再误把「纯文本分享」判成不可发。
- ChatScreen 的发送口由 `share.copy(text = shareDraft)` 改成
  `share.copy(text = shareConfirmBody(share, shareCaption))`；接线语义（`take()` 只发生一次、
  面板渲染位置、WindowDialog 选型）一字未动。

测试：`ShareConfirmTest` 跟着改到新语义，拼接规则**穷举**钉住（都有 / 只有正文 / 只有描述 / 都空，
分隔符写成字面量 `"\n\n"`），并钉住「都空且无文件 ⇒ 不能发」与「可点 ≙ 拼出来的正文非空或另有
附件」（同源性）。10 条测试全绿。

验证：`./gradlew.bat --console=plain assembleDebug testDebugUnitTest` → BUILD SUCCESSFUL，
110 suite / 1332 tests / 0 失败（基线 110 / 1330，本批净增 2 条）。
 2026-10-06 20:09:35 +08:00
AskaEth 59012f711b docs(05): 更正分享面板的语义 —— 输入框是「用户附加的描述」而不是分享正文的复刻 
主人澄清：那个输入框（我这边先误判成「预览多余」）应当是用户附加描述的输入框。正确形态：
预览留着分享正文（它才是要发的内容）、输入框默认留空 + 占位符、发送时「分享正文 + 用户描述」拼接
（两段都在时空行分隔）、都空且无文件时按钮不可点。我先前那条「删预览正文」的指令方向反了，已更正，
W53X2 回来即按更正执行。
 2026-10-06 20:06:00 +08:00
AskaEth 863ac93b25 docs(05): 锚点补记三十二 —— 续接锚点（主人两条新指令：复验分享面板「正文两次」、开跑保活长时间后台）+ 环境状态 + 两条各自照抄即可的跑法 2026-10-06 20:03:56 +08:00
AskaEth d8e44c6692 docs(05): 锚点补记三十一 —— W53 四项落地（后台通知/退出确认框/保活文案与入口/分享确认面板）+ 真机验收全过 
- 三支各自的机制与判据要点，含两条「子代理纠正任务书」的记录（Miuix 0.9.3 没有 extra.* 包；
  proactive 判据后端放在 data 里而不是帧壳顶层——我读后端源码核过）+ 我自己补的那处
  （AppPresence 补同源 StateFlow 当 key，修「去系统设置授权后回来服务没起」）。
- 真机验收逐条证据（后台通知的形状与点它回主会话、退出确认框、保活文案与「去系统设置」、
  分享面板确实没被直接发出、INTERNET 来源是源码）。
- 仍未验/已知缺口如实列出（两条路去重只有单测、通知 id 覆盖、Activity 销毁后收不到帧、
  转屏丢已取走的分享、S4 对照组没跑干净）。
 2026-10-06 19:00:03 +08:00
AskaEth 62f552f87f merge: W53X —— 分享进来先弹确认面板（预览图片/文件 + 可附文字 + 发送/取消），不再一到就发 2026-10-06 18:55:36 +08:00
AskaEth 77fbedc350 fix(keepalive): 权限「去系统设置里授权后回来」这一档现在真能把服务起起来（补 W53S 登记的那一格） 
问题（W53S 标出、我核过代码确认）：CyreneApp 里那个起停前台服务的 LaunchedEffect 的 key 只有
`keepAliveEnabled` 与登录态，而通知权限是**现读**的 ⇒ 用户在系统设置里授权后回到 App 时它不会重跑，
设置页已经显示「已开」而服务其实没起（要等下次启动或再动一次开关）。

修法：给 AppPresence 补一条**与既有 `appInForeground` 同源**的 StateFlow（`onStart/onStop` 里
从同一个集合重算，布尔 getter 语义一字未动），让那个 effect 收它当 key —— 「回到前台」正是
「从系统设置返回」必经、且必然变化的那一位。没有新增任何依赖。
 2026-10-06 18:55:20 +08:00
AskaEth 0a43cedea9 docs(share): 补上「为什么是 WindowDialog 而不是 OverlayDialog」的硬理由 
查了 Miuix 0.9.3 的源码（下载 sources jar 核对，不是猜）：`OverlayDialog` 靠
`MiuixPopupUtils.DialogLayout` 把自己登记进 `LocalDialogStates` / `LocalRootDialogStates`，
而这两个 `staticCompositionLocalOf` **只有 Miuix 的 `Scaffold` 会 provide**
（`basic/Scaffold.kt` 的 Surface 里那层 CompositionLocalProvider）。

本面板的调用点在 `ChatScreen` 那个 `Scaffold` 的**外面**（与附件预览 / 编辑 / 删除三个弹层
同一处）⇒ 换用 `OverlayDialog` 会拿到一个没人读的默认空列表：**不报错、也不显示**，
分享进来会变成「什么都没发生」。这条写进 KDoc，免得后人只看到 W53S 用了 `OverlayDialog`
就顺手把这里改过去（两处调用点的处境不同：那个确认框长在设置页的 Scaffold 里）。

只改注释。验收：./gradlew.bat --console=plain assembleDebug testDebugUnitTest → BUILD SUCCESSFUL，
102 suite / 1278 tests / 0 失败。
 2026-10-06 18:54:43 +08:00
AskaEth b06688f1db feat(share): 分享进来先确认再发 —— 新增确认面板 
主人 2026-10-06 拍板：分享进来的内容不再「一落地就发」，要像其他 IM 一样先给一个
确认面板。此前 ChatScreen 的分享落地 effect 取走内容后**直接**调 sendShared，
用户没有任何确认机会；现在它把取走的那一份放进 Compose 状态，面板靠它渲染。

新增 `ui/chat/ShareConfirmPanel.kt`（Miuix 自己的 `WindowDialog`，不是 Material3）：
- 预览：图片缩略图（与待发草稿预览同形）+ 文件芯片（显示名 / 体积）+ 分享正文（三行，
  全文在下面那个输入框里，可编辑）；
- 输入框：初值就是分享进来的正文本身，**一个字符都不加**（不拼来源标记——那是红线）；
- 「取消」= 本次分享作废（不发送、也不塞回待发队列）；「发送」才走既有 sendShared。

为什么这么接线（都在 ChatScreen 那一小段里）：
- **取走只发生一次**：`ShareIntake.take()` 只在 `shareConfirm == null` 时被调用，而
  `shareConfirm == null` 同时是这个 effect 的键 ⇒ 面板一关就再跑一遍判据、把面板开着时
  攒下的下一条分享接上（不加这个键，那一条会一直躺在队列里等连接状态碰巧再变一次）；
- 面板开着时新来的分享**原地留在队列里等**，不覆盖用户正看着的那一份；
- 告知按**真正发出去的那一份**算（`share.copy(text = 输入框内容)`）：正文可能刚被用户改过，
  拿改之前那份去算会说出「正文较长、本想作为文件发送」这种与事实不符的话。

未动：shareLanding / shareNoticeFor / shareWaitingNotice 的语义，sendShared 里
「超长正文 → 文件」那条裁决，ShareIntake 的提取与暂存，W49/W50/W51 的判据。

判据抽成纯函数并单测（`ShareConfirmTest`，8 条）：预览该显示哪几样（图片数 / 文件 / 正文是否
非空）、输入框初值、以及「发送」可点 ≙ 真的会有东西发出去（与 sendShared 开头那条早退同一条）。

验收：./gradlew.bat --console=plain assembleDebug testDebugUnitTest → BUILD SUCCESSFUL，
102 suite / 1278 tests / 0 失败（基线 101 / 1270）。
 2026-10-06 18:53:41 +08:00
AskaEth 6505512c0a merge: W53S —— 退出登录加 Miuix 确认对话框；保活那行补「24 小时累计 6 小时」上限事实 + 权限被拒时的「去系统设置」入口 2026-10-06 18:53:34 +08:00
AskaEth bbd02fc279 feat(settings): 退出登录加二次确认；保活那行补系统上限并给「去系统设置」入口 
两件事都在这一个切片里，都只碰 ui/settings/**。

一、「退出登录」的确认框
- 现状：W52C 把它改成整行可点的 BasicComponent（红色标题 + Remove 图标），而它紧挨着
  「版本」那一行，两条长得几乎一样 ⇒ 误触代价是一次真登出（AuthManager.logout 会吊销
  服务端 refresh 并把本机凭据整份清空，没有撤销）。W52C 自己把这条风险标了出来。
- 改成：点条目只立一个本页的 remember 状态（不进任何 VM），弹出的确认框里
  「取消 / 点框外 / 系统返回键」三个出口都只是关掉框，一个字都不改；只有确认那一路
  才调 onLogout —— 行为链路与加框之前完全一致。
- 控件用的是 Miuix 自己的 OverlayDialog（top.yukonga.miuix.kmp.overlay），由本页 Scaffold
  自带的 MiuixPopupHost 承载：标题 / 说明 / 内容分槽，正是为这种事准备的。
  （注意 Miuix 0.9.x 并没有 extra.* 包，对话框只在这两个包里，别照旧版 import 去猜。）
- 说明文案如实带上代价：退出后本机登录信息整份清空，服务器地址也要重填。

二、「后台保持连接」那行
- 补事实：dataSync 型前台服务在 targetSdk 37 下，24 小时内累计最多 6 小时会被系统回调
  onTimeout（KeepAliveService 到点自停以免 ANR）⇒「全天候保活」做不到。原先这句只写在
  KeepAliveService 的代码注释里，用户看不到；现在写进开关下面那行字，且落在「关 / 开」
  两档——只写在「已开」那一档等于默认所有人都已经开过一遍，而默认态恰恰是关的。
- 补入口：权限把功能挡住的两档（刚被拒 / 开关开着但权限被撤）原先只说「到系统设置里允许」，
  用户得自己摸进去找。现在这两档下面多一个「去系统设置」按钮，直接跳到本 App 的通知设置页
  （ACTION_APP_NOTIFICATION_SETTINGS + EXTRA_APP_PACKAGE；厂商砍了这个页面就退到应用详情页，
  两次都失败就什么都不做，绝不崩）。按钮出现的条件与那两句文案一一对应，两处不会分叉。
- 顺手复核：点了按钮从系统设置回来时，由 ActivityResult 回调现读一次真实授权，把过期的
  「刚刚被拒」清掉 —— 比挂生命周期钩子直接，也不需要它。
- 测试：KeepAliveSummaryTest 原有的 4 条断言一条没动（新增事实挂在「关 / 开」两档，正好
  不吃「已开」与「起不来」那两条）；新增两条 —— ① 关 / 开两档都必须写明 24 小时窗口与
  6 小时上限；② 权限挡住的那两档都必须把用户指向系统设置（与按钮的判据同源）。

验收：./gradlew.bat --console=plain assembleDebug testDebugUnitTest
     BUILD SUCCESSFUL；101 suite / 1272 tests / 0 失败（基线 101/1270）。
 2026-10-06 18:52:31 +08:00
AskaEth 53c7494389 merge: W53N —— 她主动说的话在后台/不在聊天页时发系统通知（只这一档；读回 proactive 判据 + 按 id 去重 + 点通知切主会话） 2026-10-06 18:52:20 +08:00
AskaEth 611bc5f58a feat(W53N): 她主动说的话在后台/不在聊天页时发一条系统通知（只这一档，普通消息不弹） 
改了什么：
1. WsEvent：把落库帧上被丢掉的 `proactive` 判据**读回来**（新增 MessagePersisted.proactive）。
   此前 PersistedData 只解 message，而生产 Json 是 ignoreUnknownKeys=true ⇒ 这个键既不解也不报错，
   「她主动说的话走了 IM 桥那条落库路」在客户端完全不可见。两层落点都认（data.proactive 与帧壳
   顶层 proactive 取或，契约只说了「帧顶」）；值用**宽容读法**（只认字面 true），形状不认识时按
   「不是 proactive」——判错成真会给普通消息弹通知，判错成假只是漏一次提醒，方向必须偏不打扰。
2. core/notify（新）：判据 + 去重 + 落地
   - shouldNotifyProactive(appInForeground, viewingTargetSession)：语义只有一条——**这条消息此刻
     会不会正好被用户看到**。四档组合都写进 KDoc（含「不在前台、聊天页却还挂着」那一档）。
   - RecentProactiveNotices：进程级、容量 64、按插入序淘汰。记的是「**到达过**」而不是「弹过」，
     因为「用户正看着」那一次也算这条已经到达（他看过了，另一条路再补一帧时不该为一句看过的话弹）。
   - ProactiveNotifier：两条路共用一处；顺序是 归属 → 有没有字 → 记账/查重 → 判时机。
   - proactiveNotifyKey：落库行 id > IM 消息号 > 时间字面量 > 正文（服务端一个键都不给时的兜底）。
     实时帧的 data.id 与落库帧的 message.id 是**同一个值**，去重就靠它。
   - proactiveNotificationText：复用权威解析器 domain.parse 剥标记（不再写第二份剥标签正则）、
     折成一行、超 120 字截断；截断不劈开代理对（emoji）。
3. 前台判定不引新依赖：MainActivity 的 onStart/onStop 按**实例**登记到一个进程级集合
   （配置变更时新实例的 onStart 先于旧实例的 onStop，布尔量在那里必然误判成「后台」）；
   聊天页那一半由 ChatScreen 的组合报告（DisposableEffect）。两者在 AppContainer 那层汇合。
4. 通知本体：自建渠道 `proactive`（DEFAULT，**要提醒人**，与 keep_alive 的 LOW 分开）、通知 id=2
   （与保活那条 id=1 分开，同 id 是替换会把常驻通知顶掉）、标题「昔涟」+ 正文是她的原话、
   setAutoCancel、PendingIntent.FLAG_IMMUTABLE（且 request code 与保活那条分开：两者的 Intent
   filterEquals 相等而 PendingIntent 判据不含 extras，同 code 会复用先建的那个、丢掉这个 extra）。
   通知权限现读（复用 core.keepalive.notificationsAllowed），没授权就不发。
5. 点通知 ⇒ 打开 App 并切回主会话：Intent extra → 进程级待落地意图（ProactiveTapIntake，通知可能
   在 App 没起来 / 没登录时被点）→ ChatHomeScreen 落地成「关掉设置/管理/关于/抽屉 + select(web)」，
   走的是用户点抽屉里那一行的同一条路，不引导航库。

为什么这样切：通知逻辑**绝不碰连接**（那条共享连接的所有权仍只在登录态那一处），只在帧**已经到达
之后**做判断；判断与去重全是纯函数/纯类，可单测；Android 落地只有一层薄薄的通知构造。

验证：W53N worktree（基线 f8ac95c）`assembleDebug testDebugUnitTest` 全绿 —— 109 suite / 1320
tests / 0 失败（基线 101 / 1270 / 0，新增 8 suite / 50 tests）。真机弹通知、点通知的落地未验（留给主人）。
 2026-10-06 18:51:24 +08:00
AskaEth 659ab83f00 docs(05): 锚点三十补第 7 节 —— 新登记「分享确认面板」（主人 2026-10-06 提） 
现状已核实：分享一进来就在 ChatScreen 的 ShareLanding.Send 支被立刻发出（ShareIntake.take() → sendShared），
用户没有任何确认机会。主人要的是像其他 IM 一样：能预览（图片/文件名与大小）、能附文字（预填分享自带的文本）、
由用户点发送才真发、可取消。已指派 W53X 且写明边界（不动 shareLanding/sendShared 语义、take 只许一次）。
 2026-10-06 18:47:02 +08:00
AskaEth ed0824f335 docs(05): 锚点三十补第 6 节 —— INTERNET 显式声明的验收证据 + 构建锁协议写死三条 
锁协议：① 一行一个占用者；② 只删自己那行，绝不整文件删除（这批真踩到）；③ 改/删前先读一遍。
 2026-10-06 18:43:14 +08:00
AskaEth f3d8d28cf7 fix(manifest): 显式声明 INTERNET（不再搭在 okhttp-android 的传递清单上） 
原来 release 能联网是靠 com.squareup.okhttp3:okhttp-android:5.5.0 的清单把 INTERNET 合并进来的；
换掉/排除那个依赖，release 会静默失去网络权限（debug 侧 AGP 也注入同一份，所以本地怎么试都看不出来）。
现在显式写进源码。验收：:app:processReleaseMainManifest 的 merger 报告里该权限已是
ADDED from app/src/main/AndroidManifest.xml（并 MERGED from okhttp-android）⇒ 来源是源码。
 2026-10-06 18:43:13 +08:00
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