 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
|
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
|
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
|
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
|
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
|
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
|
d546f31755
|
feat(W46): 发送路由带上原因，并加一行 CyreneRoute 诊断日志
为什么要把「原因」也带出来
- 结果只有 Ws / Rest / Queue 三档，而「为什么是这一档」在设备上完全看不见。W45 那轮真机回归
就卡在这里：那条消息进了补发队列、网络侧一条请求都没有，而「零请求 + 进队列」在判据里只可能
来自 Queue 那一档；可顶栏同时显示「重连中…」。两者都只是结论，事后无法分辨「判据读到
Offline」与「判据读了别的值」。
- 于是把判据抽成 sendRouteDecisionFor(wsDispatched, connection) -> (route, reason)：reason 就是
原来那三条规则各自的分支标识（FrameDispatched / ConnectionOffline / ConnectionNotReady）。
sendRouteFor 现在读它的 route，所以两处不可能分叉。判据、优先级、行为逐字未改。
那一行日志（tag = CyreneRoute，Log.d，只在 DEBUG 构建打）
- 打点：ChatViewModel.sendThroughLadder 一进入就一笔，覆盖阶梯的三个分支（帧交出去 / 试 REST /
直接进队列），一行 key=value、空格分隔：
wsDispatched=... socket=<ChatSocket.state.value，权威值> mirror=<顶栏读的那个镜像>
wsObject=<present|absent> route=... reason=... outcome=... fromQueue=...
- socket 与 mirror 必须同时打出来：mirror 是 collect 过来的一格，只会滞后、不会超前，两者不一致
就说明顶栏那一刻显示的是上一格 —— 这正是「顶栏重连中…」与「这条进了队列」能同时出现的形态。
- 这是开发期诊断仪，不是产品行为：字段增删不构成兼容问题、不为它写测试（要钉的是纯函数那张全表）。
不打 token / 请求体 / 正文 / localId。
顺带（同一轮的可观测性）
- ChatSocket 新增只读属性 hasLiveSocket（webSocket != null），只喂日志，不是产品逻辑的输入。
- 复核 WsState.Offline 的写点：ChatSocket 里只有两处（runConnectionLoop 的 ConfigMissing，以及
endWithAuthFailure），close() 写的是 Idle；非 401 的握手失败（代理回 503）走 Closed ->
Reconnecting，进不了这一档。
测试
- SendFallbackTest 新增两例：五档连接状态 × wsDispatched 真假的全表逐个钉住结果 + 原因，并钉住
sendRouteFor 与判定同值；另一个钉住三个 reason 都可达、没有第四种组合。全量 1155 例，
0 失败 0 错误。
|
2026-10-05 19:50:28 +08:00 |
|
|
AskaEth
|
ec8d54f3a5
|
feat(W45): 发送阶梯改成直接试 REST，删掉 W41 的连通性探测
为什么换成直接尝试
- W41 的阶梯是「WS 未就绪 ⇒ 先探 GET /api/v1/health ⇒ 通才走 REST」。
- 真机回归（devtools/ws_block_proxy.py 只掐 /ws/chat，HTTP 全放行）发现消息进了队列而不是回落
REST；而 ProbeClientTest 证明那条链在 JVM 上是通的，Unreachable 生在连接之前，三种成因
（建 client 抛 / 连上但一个字没写 / ConnectException）在外同形，那一轮无法定论。
- 结论：不该有探测。探测只是「能不能连上」的替身，而真正的 REST 请求本身就是最直接的检验
——试成了消息还顺手发出去了；试败了进队列（内容一个字节不丢，重发仍是同一个 clientMsgId）。
探测唯一省下的是「完全无网时少发一个注定失败的请求」，代价却是一个独立 client、一套独立超时
预算和一整套新的失败面。那个探针 client 还不复用连接池，每次都要现做一次冷握手，预算比主链路
紧 4 倍（2.5 秒整通 vs 10 秒连接）——今天这个 bug 的形态就长在这上面。
改了什么
- 路由：wsDispatched ⇒ Ws（成功路径逐字不变）；Offline ⇒ Queue；其余三档未就绪 ⇒ 直接试 REST。
- 直接试 REST 走既有的 REST 发送路径与请求体（同一份 chatRequest / 同一个 clientMsgId）：服务端
收下（200 stream:true / 202 queued / 200 duplicate）⇒ 完成、不进队列；网络类失败与没等到裁决
⇒ 进队列；服务端给过裁决（409 / 500 / 503 / 400 与 401）⇒ 回滚 + 既有文案，口径不变。
- 判据纯函数化：sendRouteFor 去掉探测入参；新增 restAttemptLanding（Result<ChatAck>? ⇒ 四档落点）；
ChatAck.isAccepted 从 ChatViewModel 的私有方法搬到判据文件。
- 删掉探测那一套：ConnectivityRepository / HealthApi / HealthDto / ApiClientFactory.createProbe /
PROBE_TIMEOUT_MILLIS / Reachability / reachabilityOf / ChatViewModel.probeReachability /
AppContainer 的接线（删前逐个确认过没有别的调用方）。
- 超时：一个 client、两个超时。client 上的连接超时 10 秒改成 2.5 秒；回落那一次投递的整通上限仍然
是 10 秒（REST_FALLBACK_TIMEOUT_MILLIS 一个数都没动）。
- 测试：SendFallbackTest 按新事实重写；ProbeClientTest 删掉，其中仍然成立的事实搬到新的
RestAttemptClientTest（真 OkHttp + 真 Retrofit + JDK HttpServer）。
为什么是这两个超时值
- 连接超时 2.5 秒：正常网络下一次 TCP 握手是毫秒到几十毫秒量级，2.5 秒是「人开始觉得卡」之前的
量级，也与 W41 那 2.5 秒的探针预算对齐 ⇒ 换成直接试 REST 之后「无网时用户最多等多久」没有变长
（完全无网时 ≤ ~2.5 秒进队列）。绝不许回到 10 秒：那会让每一条离线消息的用户都白等十倍的时间。
- 整通上限 10 秒：它管的是另一档——「连上了但一直不回话」（半死的代理、接住连接却不回应的
服务端），到点也按网络类失败进队列。它同时是用户干等时间的上界，不许拉长。
- 整通上限放在调用点而不是 client 的 callTimeout：这个 client 是共用的，长文本 / 内联图片那两条
本来就该走 REST 的路用的是同一个，client 级 callTimeout 会把它们一并框住，等于给一条本轮不打算
碰的路引入新失败面。
为什么 Offline 仍然不试（保留 W41 的决定）
- 该档的语义是「握手 401 且续期也失败」（终态、不自动重连），会话已知是死的：试 REST 只会拿到
401 并落到「回滚 + 一句误导人的鉴权错误」，把「已排队不会丢」换成更差的结果。W41 的理由
（不鉴权的健康端点必然回 200 ⇒ 假通）随探测一起消失了，但结论换到直接试这边一字不用改。
验证
- gradlew.bat assembleDebug：BUILD SUCCESSFUL
- gradlew.bat testDebugUnitTest：1153 个用例，failures=0，errors=0
（SendFallbackTest 14 例、RestAttemptClientTest 6 例全绿）
未做
- 没有 push。devdocs/05 的 W41 / W44 段落仍写着探测（那份由主会话维护，本轮只在回复里点出过时
的句子，没有改它）。
|
2026-10-05 18:33:32 +08:00 |
|
|
AskaEth
|
5556573986
|
feat(chat): W43 超限告知改入口中性措辞，补发反复失败就静默
① 超限告知（ShareRules.truncatedImagesNotice）改成**入口中性**措辞
原句以「分享的图片」开头，那是一句只对其中一条路成立的限定：W42 起这个函数同时被图片入口
用着（图片按钮已改多选），而图片入口里根本没有「分享」这件事。所以句子不再指认动作的来处，
只说两条路都成立的三件事：**有上限（4 张）、超出的没发、发出去的是前 N 张**。新句逐字：
「一次最多 4 张，超出的没发，只发送前 N 张」，N 就是真发出去的张数。
刻意不写「失败」「错误」：被上限截掉不是一次错误，是上限本身，那族措辞会让用户以为丢了东西。
两条路仍然共用同一句（只有一个出处），没有为此分裂成两份文案。
② 补发「多次重试失败就静默」（主人 2026-10-06 定案）
W40/W41 之后未连接时普通发送会进补发队列并给一句柔和告知，连接恢复后自动补发；主人新加的
规矩是**不要一直刷屏**：同一条（或同一批）反复重试都失败时，停止再弹告知，静静地等。
- 判据抽成纯函数 queuedSendNoticeAllowed(toldThisRound, failedResends)：**静默闸优先**，其次是
既有的「一轮从空到空只说一次」（W40 那条一字未改）。它只回答该不该说，从不碰队列。
- 阈值 QUEUED_RESEND_SILENCE_THRESHOLD = 3。理由：不许取 1~2（那等于根本没告知）；第 1 次失败
就是「刚进队列」那一刻，必须说；第 2、3 次仍允许开口（连接抖动后还是没连上，用户需要重新
知道）；第 3 次仍未成功说明已在反复失败里，再说只是把同一件事刷第二遍，从此停下。
- 记账口径：本会话的一个**补发批次**（= 队列从空到非空的那一段），与告知本身的记账同口径，
不新造第二个概念；按单条记账会漏掉「每条只失败一两次、整批却一直没发出去」这种要静默的情形。
落在 ChatViewModel 的实例字段上：VM 是按会话建的，所以天然按会话，也不引入全局单例——别的
会话的反复失败不该把本会话的告知掐掉。
- 计什么：只计「补发没能上路、内容仍留在队列里」那种失败（它是唯一会反复发生的一种）；已被
服务端裁决 / 已回滚的那两类是一次性了结（内容退回输入栏并给了明确原因），不计数。
- 清零时机：**补发真的成功一次**就归零（WS 帧交出去、或回落 REST 被服务端收下）⇒「静默之后
连接恢复并补发成功」之后，下一次离线**又能重新告知**，不会永久闭嘴。
- 静默不等于丢弃：这一个数只影响说不说，队列内容与补发的下一步一个字节都没动，连接一好照旧
按序补发（W38/W40/W41 那条硬要求照旧成立）；气泡上「排队中 · 还没连上」的小标也一直挂着。
既有的两句队列告知（排队中那一句 / 离线那一句）一字未改。
测试：ShareNoticeTest 与 ImageSendPlanTest 的超限断言改成新事实（不删断言）；新增
QueuedSendSilenceTest 钉住那条规则的四个边（第一次失败告知、阈值前仍告知、阈值后静默、成功后
清零）以及「阈值不许取 1~2」「静默不动队列」两条性质。
assembleDebug 成功；testDebugUnitTest 1150 测试 / 0 失败 / 0 错误（基线 1143，本批新增 7）。
|
2026-10-05 15:21:24 +08:00 |
|
|
AskaEth
|
5a9f52a069
|
feat(chat): 图片入口改多选，N 张图按既有切分落成 N 条消息
主人 2026-10-05 定案「那肯定要多选」：图片按钮从 PickVisualMedia（单选、回一个 Uri）换成
PickMultipleVisualMedia（系统 Photo Picker 的多选形态，仍然零权限，不退回落 SAF / 存储权限）。
文件按钮那条 OpenMultipleDocuments 一个字没动。
为什么复用分享路径那一段（不另起一套发送逻辑）：
分享落地（ChatViewModel.sendShared）早就把「一条消息只能带一张图 ⇒ N 张图 = N 条消息」做完了，
那段切分本来内联在它自己的 forEach 里，不是可复用的纯函数。这次把判据抽成纯函数 imageSendPlan
（ui/chat/ImageSendPlan.kt，跟 SharePayload.kt 与 SendQueue.kt 一样的写法，可单测），投递抽成
emitPlannedMessages（私有），输入栏那条路与分享落地那条路共用同一段：两处各写一份循环，迟早会在
「哪条带正文 / 哪条带附件 / 哪条清草稿 / 超过上限怎么办」上分叉。每张图各自的解码 / 缩放 / 重编码
与「内联还是上传」的取舍仍旧逐张走既有实现（deliver 与 deliverImage），一行没改。
为什么 N 张 = N 条（而不是一条带多张）：
契约里 chat.image 是单图字段，一次上行只能带一张，所以多选进来的 N 张只能落成 N 条消息：
第一条带正文 + 第一张图 + 全部附件，其余每条一张图，顺序 = 用户在多选器里选的顺序。契约与服务端
一个字没动。
上限与告知沿用分享路径的口径：
上限仍是 ShareRules.MAX_IMAGES（4）。超限那几张不静默丢，如实告知；那句文案抽成
ShareRules.truncatedImagesNotice，分享入口与选图入口共用同一句（逐字未改，ShareNoticeTest 钉住）。
系统选择器自己会把可选张数卡在 4 上，只有回落成 ACTION_OPEN_DOCUMENT 的设备（它表达不了最多几张）
以及「草稿里已有几张、再选几张」这两种情形会真超，那时由入口与投递两处说出同一句。
其余口径与今天一致：
输入栏最多攒 4 张（到顶后不再显示图片入口），每张各自可移除；取消选择什么都不做；
发送时第一条带正文并清草稿（N 条是一次发送，草稿只清一次），失败的那一条只把自己那一张还给输入栏。
一次发送切出的多条里只有第一条套用「她忙时发消息」偏好——第 2 条起声明打断就是打断自己刚起的
上一轮（与分享路径不声明同一条理由），N = 1 时与今天逐字节相同。
顺带：
- ChatUiState.draftImage（String?）改为 draftImages（List<String>），rollbackPending 把失败那张补回
待发列表（不再覆盖），输入栏渲染成每张各自带移除键的一排预览；
- QueueFullOutcomeTest 里断言单图的四处改成新事实（断言一条没删）；
- 新增 ImageSendPlanTest，覆盖 N = 0 / 1 / 2 / 4 / 5（超限），并钉住附件只跟第一条、顺序不重排、
超限那句与分享路径同一句。
|
2026-10-05 14:41:21 +08:00 |
|
|
AskaEth
|
9f77fb469c
|
feat(chat): W41 未连接时先探一次健康端点，通就回落 REST 发出去，不通才进队列
主人第二次定案：「未连接状态你就不能拿 httpAPI 尝试吗？」→ 明确为「可以走 health 端点
验证连通性」。W40 的「未连接就进队列」保留为最后一级，队列、气泡小标与那套柔和告知原样复用。
## 为什么先探测再决定，而不是直接排队
网关只有一条：POST /api/v1/chat 与 /ws 是同一个端口上的两条车道。握手被挡（代理不转发
Upgrade、中间设备掐长连接）时 REST 往往是通的，直接排队等于把「WS 这条车道暂时不通」当成
「后端不可用」，让用户白等一次重连——而那一刻这条消息本来就能发出去。
## 三级阶梯（判据是纯函数 sendRouteFor，见 ui/chat/SendFallback.kt）
1. WS 就绪 → 照旧走 WS。成功路径的字节与状态机一个字没变：sendThroughLadder 的第一件事
仍然是 sendChat，前面不加任何判断、不挂任何起点。
2. 未就绪 → 探一次 GET /api/v1/health（2.5 秒整通上限，只看 2xx；失败 / 超时 / 抛异常一律
按不通处理，fail-closed）。通 → 用既有的 POST /api/v1/chat 把这条发出去（短文本也走
REST）；不通 → 进队列。
3. 回落 REST 失败：网络类与超时 → 进队列；服务端给过裁决的（明确拒绝、401）与配置类错误
（证书 / 明文被禁 / 地址格式 / 解析不出来）仍旧回滚加文案，不装成「还没连上」。
4. 补发走同一个函数（fromQueue=true）：阶梯只有一份实现，两条路不会分叉成两种行为。
Offline 那一档直接进队列、连探测都不做：它的语义是握手 401 且续期也失败（会话已知是死的），
而健康端点不鉴权（Cyrene_v2/internal/services/gateway/routes.go:51）必然回 200 —— 探了只会
发出一次注定 401 的 REST，把 W40 那句「已排队不会丢」换成一次回滚加一句误导人的鉴权错误。
## 为什么重发是安全的
回落与补发用的都是那条乐观气泡的 localId，也就是上行幂等键 clientMsgId，一个字节都不新铸。
服务端按 (session_id, client_msg_id) 唯一索引仲裁：重复到达只回 chat_duplicate /
duplicate:true，不再落库、不再起回合（契约 v0.56 §3.13）。于是「超时了但服务端其实已经
收下」这种最难判的情况不需要本端猜。
## 回复怎么回来
那一刻没有 WS 连接，内容帧没人收，靠重连时的正向增量补回来（gapCursor → catchUp →
loadAfter → absorb）。本 VM 从没连上过时 gapCursor 是 null、重连那一步什么都不会拉，所以
回落发出去且服务端已受理之后补记一次游标（armGapCursorForFallback，只在它还是 null 时补）。
## 其他
- 探测结果不缓存，每条消息最多探一次（只有 WS 没把帧交出去才问）；WS 就绪那条路上一次探测
都不发。
- 补发从同步循环改成单飞协程：阶梯里要探测、要发 REST，会挂起，「两个触发点都在主线程上
所以不可能交错」这条旧论证不成立 ⇒ 改用 drainingQueue 单飞闸加串行出队，出队仍在有结论
之后。
- 离线时的上界：探测不通就直接进队列、一次 REST 都不会发，用户最多等探测那一段（约 2.5 秒）；
回落那一次 REST 另有 10 秒上限（stream:true 的回执本该毫秒级回来）。
- 新增测试 SendFallbackTest（17 例）：优先级、fail-closed、Offline 不探测、回落失败分档、
探测超时落在 2 到 3 秒、有图或有附件的消息压根不进这层阶梯。
- devtools/fake-backend 补上 GET /api/v1/health，否则本机跑假后端时这条阶梯会退化成直接排队。
|
2026-10-05 14:33:34 +08:00 |
|
|
AskaEth
|
df9fc85f76
|
feat(chat): 普通发送未连接时进队列（不再回滚），连接恢复后按发送顺序自动补发
主人 2026-10-05 裁决：普通发送在「未连接」时进队列。
此前 deliver 拿到 sent=false 就 rollback：气泡摘掉、正文退回输入栏，外加一句「还没连上，
这条没发出去，请稍后手动重试」。内容是没丢，但把「网络还没好」说成了一次要用户自己负责的
失败，而且他还得对着输入栏再发一遍。这一批按 W38「分享落地等连接」那套语义重做普通发送：
不报错、内容不丢、连接恢复后自动补发。W38 的落地时机、PendingShareHolder.take() 的原子语义、
ChatSocket 的连接状态机一个字都没动。
① 三档处置：未就绪就排队（新纯函数 wsSendOutcome，ui/chat/SendQueue.kt）
判据的输入只有两个：sendChat 的回值，以及这一刻 socket 自己的连接状态。sent=true ⇒ Dispatched
（帧已经交给 socket，成功路径一个字没动：不打标记、不说告知、不写任何状态）；sent=false 且
连接就绪 ⇒ Failed（连接是好的，那 false 只可能来自 socket 对象已空 / 已被 cancel / 序列化抛
异常，「发送失败」在这一刻是事实 ⇒ 走今天那条 rollback + SEND_FAILED_MESSAGE）；sent=false 且
未就绪 ⇒ Queued（ChatSocket.send 第一行就按状态挡掉，帧连序列化都没做、服务端一个字节都收不到，
所以既不回滚也不进 error 横幅）。未就绪四档（Idle / Connecting / Reconnecting / Offline）
一视同仁：主人的原话是「未连接就进队列」，Offline 只是不会自己变好，内容仍然一个字节都不会丢，
两档的差别只在告知措辞（这一点与 W39 给分享落地定的规矩一致）。
② 队列与补发：顺序与「只发一次」的保证点
deliver 的 WS 分支只改了「未就绪」这一支：queueForConnection 把这条留在待发态
（ChatUiState.queuedForConnection，条目只有 localId 与投递那一刻定下的并行声明；正文 / 图片 /
附件仍从那条气泡上现取，同一件事不留第二份真相源，也就不存在两条真相分叉）。触发点只有一个：
socket 状态变成 Connected 那一刻（onConnectionChanged，由状态流驱动、没有任何轮询），外加
入队之后的一次竞态兜底（连接恰好在投递与入队之间就绪时，那一次补发会扑空）。补发从队头开始，
FIFO 顺序 = 用户发送的先后顺序。
「只发一次」的保证点是「队头 + 出队恰好一次」：队头只在这一步有了结论（发出去了 / 真失败 /
气泡已经不在了）之后才被 dropQueuedSend 摘掉，所以重复的触发拿到的是同一个键、不会多出第二次
出队；flushQueuedSends 是同步函数（一个挂起点都没有），两个触发点在主线程上不可能交错。
第二道保证在服务端：补发复用同一个 clientMsgId（绝不铸第二个），真重复到达也只会被回
chat_duplicate，不会落成第二条消息。补发又失败时按今天的失败路径处理（回滚 + 文案），
绝不静默吞掉。已知边界（写在 KDoc 里）：打断声明不随补发重放——补发时在跑的那一轮早就不是
用户按发送时看到的那一个了，隔半分钟再去打断可能毁掉他没见过的一轮。
③ 状态表达：仍是六态，③ 里多一句更准的话
不新增第七态：等连接的这条走六态里的 ③ 排队中（phaseOf 的判据从「收到过入队回执」扩为
「收到过回执，或本端因未连接把它留住了」），两类排队的区别由气泡小标说清——新纯函数
pendingBubbleFooter 给 ③ 加四个字：「排队中 · 还没连上」。为什么挂在气泡上而不只是那句告知：
告知八秒就收走，而这是个会持续几十秒的状态，牌子撤掉之后光看「排队中」分不出是「她已经收下、
前面还排着队」还是「连都没连上、一个字节都没上路」。柔和告知走新通道 ChatUiState.sendQueueNotice
（与 shareNotice 分开：两条描述的是不同的动作，可以同时挂着），文案 SEND_QUEUED_NOTICE 是
「还没连上，这条排队等着，连上后自动发出」；Offline 那一档换 SEND_QUEUED_OFFLINE_NOTICE
「现在处于离线，需要重新登录或检查服务器地址；这条还没发出去，已排队不会丢」——不提「连上」
「自动发」，那一档没有会自动到来的连接。不刷屏：一轮「队列从空到空」只说一次（连续几条离线
消息不会每按一次发送就弹一遍），记账在 queueForConnection。
④ 未覆盖：REST 通道（长文 / 图片 / 附件）保持今天的行为
POST /api/v1/chat 那条路仍是失败回滚 + 既有网络错误文案，本批不动。两条理由：一是它给不出
「未连接」这个信号（拿到的只是一次网络错误，而请求可能已被服务端收到、也可能没有），
判据不可靠；二是要补发就得重跑图片重编码与附件上传换存储名，而本地 URI 的读授权可能已经失效。
代价：未连接时发长文 / 图片 / 附件仍要用户手动重发一次；影响面仅这一条通道，WS 那条（短文本，
日常绝大多数消息）已经覆盖。
⑤ 未连接时不再有的那句话
「还没连上，这条没发出去，请稍后手动重试」（W39 加的 SEND_NOT_CONNECTED_MESSAGE）与它的判据
sendFailureMessage 一并删除：回滚那条路现在只在连接就绪时才走，这句话已经没有出口，留着就是
一段描述旧行为的死文案。SendFailureMessageTest 的断言改成新事实（未就绪 ⇒ 排队，而不是回滚
加那句话）并连同新的队列判据并入 SendQueueTest，一条断言都没删。另把「空输入什么都不发生」
这条边界抽成纯函数 hasSendableContent，输入栏的 send 与投递口的 emitAndDeliver 共用同一条判据
（行为不变，只是原本写在两处的同一个 if 现在可单测，也不会再分叉）。
测试：新增 SendQueueTest（21 条：三档判据穷举 WsState.entries、两档告知措辞、队列顺序与出队
恰好一次、气泡小标与六态、空输入边界）。assembleDebug 成功；testDebugUnitTest 1118 条
（1101 减 4 加 21），failures 0 / errors 0。
|
2026-10-05 13:57:54 +08:00 |
|
|
AskaEth
|
a763592ace
|
fix(chat): 分享告知不再两句叠加；未连接与发送失败分开说；Offline 不再承诺「连上后自动发出」
三处「对用户不够诚实」的措辞缺陷，各自独立修复。行为上只多了一处「少说一句」，
其余语义一字未改。
① 分享告知两句叠加（ChatScreen.shareNoticeFor）
实机读到的原文是「有 2 个文件读不到，未发送；分享的内容是空的，没有可发送的内容」，
读起来像两个不同的问题。可这两句说的是不同的免责，而「认下了地址却读不到」本身就蕴含
「没有可发送的内容」——叠上去一个字都没多说。故丢件计数为真时不再追加「内容是空的」那句；
其余组合保持今天的行为（只有丢件计数时只说丢件计数；「读不进来」与丢件计数说的是两件事，
照样并列）。KDoc 里记下了这一档今天的真实出口：worthDelivering 要求 isEmpty 的分享必须
有丢件计数或 contentUnreadable 才值得往下走，而后者已被「读不进来」那一档接走，
所以那句加了前提之后一次都不会再出现。
② deliver 的 WS 分支：连接未就绪不等于发送失败（ChatViewModel）
sendChat 回 false 有三种成因（连接状态不是 Connected / socket 对象已空或已被 cancel /
序列化抛了异常），此前共用一句「发送失败，请重试」，用户无从分辨「这条根本没上路」
与「发出去了但失败了」，而后者在连接未就绪时不是事实。现在按失败那一刻的连接状态分开说：
不是 Connected 时说「还没连上，这条没发出去，请稍后手动重试」，仍是 Connected 时逐字保持
「发送失败，请重试」。回滚照旧（摘掉气泡、内容退回输入栏、记下幂等键），没有自动重发，
普通发送的其它语义没动。判据抽成纯函数 sendFailureMessage(WsState)，用例覆盖
WsState.entries 的每一个取值。连接状态取 socket 自己的 StateFlow——那正是 sendChat 判的值，
不用界面镜像过来的 ChatUiState.connection，免得晚一帧读到 Connected 反而说错话。
③ WsState.Offline 不再等一句永不到来的「连上」（ShareLanding / ChatScreen）
Offline 是终态（握手 401 且续不上、或缺少 token / 服务器地址），它不会自动重连。
对它说「连上后自动发出」，用户等的是一个永远不会到来的连接——拿一句不兑现的承诺糊住
一个需要他动手的状况，比不说更糟。新增 ShareLanding.TellOffline：等够久、同一轮只说一次
这些时机与可恢复的那几档完全一致，只有措辞不同：「现在处于离线，需要重新登录或检查
服务器地址；分享的内容一个字节都没发出去，不会丢」。W38 的落地时机一个字没改：
仍然不 take()、不发送，连接恢复后照旧自动补发。哪档配哪句由纯函数 shareWaitingNotice 定，
不再散在 Compose 的 when 里，于是「Offline 换口径」这件事不需要组合界面就能测。
测试：ShareNoticeTest 把「两句都在」的断言改成新事实并穷举同族组合；ShareLandingTest 新增
Offline 的差异、时机与文案用例；新增 SendFailureMessageTest 覆盖每一种 WsState。
assembleDebug 成功；testDebugUnitTest 1101 条，failures 0 / errors 0。
|
2026-10-05 13:41:52 +08:00 |
|
|
AskaEth
|
aeb37458e8
|
fix(chat): 分享落地必须等到连接就绪，超时不再等于发送失败
为什么超时不能等于发送失败
WS 还没连上时投递的分享（ACTION_SEND）此前走成了「发送失败，请重试」，内容还从待发队列里
永久消失。来处是「等连接」那句 withTimeoutOrNull 的返回值被丢掉了：超时与成功走同一条下游，
照样 take() 再 sendShared → deliver → ChatSocket.sendChat 回 false ⇒ ChatViewModel 落到
rollback(localId, "发送失败，请重试")。实机取证（2026-10-05 11:56）：GET /ws/chat status=200
前后的窗口里投递分享，界面上是失败横幅 + 正文退回输入栏，而后端零请求（POST /api/v1/chat
一条都没有，也没有任何 error 帧）——那条横幅把「一次都没尝试发出去」说成了「发送失败」。
ShareIntake.take() 是原子出队且没有归还路径：那一次「其实一次都没发出去」的失败之后，内容
既不在 holder 里、也不在服务端，只剩回滚进输入栏的那一份（多图分享里除首条之外，连输入栏
都回不去）。重试资格因此一起丢了。所以判据只有一条：没连上就一个字节都别动——不 take()、
不发送、不产生任何 error 横幅。
为什么取走时机必须晚于连接就绪
短文本走 WS chat 帧，而分享冷启动必然撞上握手还没完成；帧发不发得出去完全取决于握手结果。
所以等待里不再有「到点就照发」这一档，只有「连上才发」：连接恢复之后由连接状态自己把这条
落地重新触发一遍。
改法
- 判据抽成纯函数 shareLanding（ui/chat/ShareLanding.kt，可单测）：没有待发 ⇒ Nothing；已连接
⇒ Send（压过后两条，且返回的是单值动作，所以发送与告知不可能同时发生）；未就绪且还没等够
⇒ KeepWaiting；未就绪、已等够、还没说过 ⇒ TellWaiting；已经说过 ⇒ KeepWaiting（不刷屏）。
- ChatScreen 的那个 effect 把连接状态并进键，连接后来就绪会自动重跑、自动补发；「不会重复
发送」仍然由 ShareIntake.take() 的原子性兜住——哪怕某一次拿着已经过期的快照进来，take()
给出的也只是队列里的下一条或 null。
- 等太久只做一件事：经既有的柔和通道 ChatViewModel.showShareNotice 说一句「还没连上，分享的
内容会留着，连上后自动发出」（不是带 X 的 error 横幅），同一次等待只说一次。
- SHARE_CONNECT_TIMEOUT_MILLIS 改名 SHARE_WAIT_NOTICE_MILLIS：它不再是发送的时限，只是
「等多久才值得说那一句」；「等够久」的计时只跟「队列里有没有东西」与「连上了没有」走，
连接在 Connecting / Reconnecting 之间抖动不重置它。
- 普通发送路径（输入框、图片、附件）一行未动。
测试
- ShareLandingTest（新，7 条）：未就绪在任何连接状态下都恒不 Send（不取、不发）；未就绪且没
等够恒 KeepWaiting（也不告知）；等够了只说一次、说过了就不再刷屏；已连接恒 Send（压过告知）；
无待发恒 Nothing（任何连接状态下都不做事）；文案必须说清「还没连上」与「自动发出」，且不含
「失败」「重试」。
assembleDebug 与 testDebugUnitTest 全绿（1091 tests / 0 failures / 0 errors）。
|
2026-10-05 13:21:09 +08:00 |
|
|
AskaEth
|
6cdf111419
|
fix(share): 认下字符串形态的 EXTRA_STREAM,并在一条内容都没读进来时如实告知
为什么字符串形态必须认
真实世界里 EXTRA_STREAM 有三种形态:规范推荐的 Uri(多选时 ArrayList<Uri>)、String[]、
ArrayList<String>。Android 上确实有一部分发送方(历史遗留 / 跨平台壳应用)在用后两种,而本端
此前完全认不出:getParcelableExtra 遇到 String[] 只往 logcat 打一句 ClassCastException 再回
null,getParcelableArrayListExtra 同理。实测 am start ... --esa android.intent.extra.STREAM
uri1,uri2 投两张图进来就是这个样子。
为什么静默是 bug
上面那次分享的结局是:后端零请求、库里零新增、界面连一句软告知都没有。用户点了分享,没有任何
东西告诉他"没读进来"还是"在路上"——这是最糟的那种失败形态,所以本次一并消灭:带着内容迹象却
一条可用内容都没提取出来时,走既有的柔和通道说一句"这次分享的内容没能读进来,没有发送任何内容"。
EXTRA_TEXT 与 EXTRA_STREAM 都为空(用户确实没分享任何东西)时仍然保持静默,那条边界有测试钉住。
做了什么
- ShareIntake 改成读 EXTRA_STREAM 的原始值再按形态分派(Bundle.get 不做类型检查),Uri / Uri
数组 / String / CharSequence / 数组 / 列表一并摊平;顺带不再往 logcat 丢那两行 ClassCastException。
- 字符串形态只认 content://:那是本端新开的一条读入口,送进来的只是一段文本,没有任何框架级担保。
file:// 等于让发送方替本端指定一个本地路径、由本端拿自己的权限去读它;http(s):// 是网络地址,
收下它等于让第三方的一行文本指定一个 URL 由本应用代取。被拒的条目逐条跳过,不让整次分享失败。
- 优先顺序与去重不变:EXTRA_STREAM 的规范形态 -> 字符串兼容形态 -> ClipData(仅前者全为空时兜底),
trim / 去空 / 去重,先来的先算;重复项既不算截断,也不把真图挤到上限之外。
- 「带着内容迹象」的判据取 EXTRA_STREAM 的原始值(由调用方读了原始值判出来,含形态本端认不出的那种),
不是「认下来的地址」——否则「有值但一条都认不出」恰恰会被判成「什么都没分享」而继续静默。
- SharedContent 新增 contentUnreadable 与 worthDelivering:后者是唯一判据,ShareIntake 用它决定
要不要往下接,shareNoticeFor 用它守卫"什么都没有就一个字都不说"那条边界,两处不会走岔。
- 分类(图片 vs 文档)、落 cache、截断与拷贝失败的既有语义一概不动。
测试
- ShareExtractionTest:字符串形态的顺序与逐条跳过、两种形态并存去重、scheme 白名单表、
读不进来 / 形态认不出 / 静默三条边界。
- ShareStreamExtrasTest(新):按真实对象验形态分派(String[] / ArrayList<String> / String /
CharSequence / 认不出的形态不猜但照样算带着内容),并接到提取层验一次端到端。
- ShareNoticeTest(新):"没能读进来"成句且不说成发送失败、正常落地一个字不说、空白分享仍然静默。
assembleDebug 与 testDebugUnitTest 全绿(1084 tests / 0 failures / 0 errors)。
|
2026-10-05 13:05:20 +08:00 |
|
|
AskaEth
|
39a63f8d30
|
fix(chat): 并行路角标改以 turn_begin.kind 为准，不再拿 leg 冒充并行
leg 是服务端**会话内的路序号**：beginLegLocked 对每一条新路都自增 legSeq，
普通串行回合照样占号——会话里发第二条普通消息，leg 就是 2。而角标旧判据是
leg >= 2，于是那条串行消息被挂上「并行路 2」，凭空声称存在并不存在的并行。
「是不是并行路」真正的判据是 turn_begin.kind（turn = 普通串行回合，
parallel = 忙时另起的一路）；解析层本来就把它读出来了，只是绑定时丢掉了。
- TurnBinding 新增 parallel；withTurnBegin 收下 kind，由 isParallelLegKind
判定：只有逐字等于 parallel 才算，turn、缺席、空串、大小写不同一律不算。
- 合并规则：新建按 kind 定；同 turnId 重复到达时取或（old.parallel || 本帧
是并行），一旦为 true 就永远是 true。与 closed 同一条纪律——单调的既成事实
不许被后到的帧翻回去；也顾及 steer_ack 可能先建一条没有 kind 的占位表、
随后才由这一路自己的 turn_begin 补上并行的现实顺序。
- 降级：kind 不来的老服务端上 parallel 恒为 false，角标一枚都不挂——宁可少挂
一枚，也不拿 leg 去猜、去多说一句假话。
- legBadgeOf 改成同时看 parallel 与 leg，三处调用点（提问侧、回复侧、流式气泡）
都跟着传 parallel；文案仍是「并行路 N」。
测试：ParallelTurnsTest 补 kind=turn / kind=parallel / kind 缺席三档、重复帧的
合并（含「已收口的并行路不被重新打开也不被降级」）；TurnStreamsTest 把
「leg>=2 就挂标」的断言改成以 kind 为准，并补上那条真机回归——会话里第二条
普通消息（leg=2、kind=turn）在提问侧与回复侧都不挂角标。
|
2026-10-05 11:59:21 +08:00 |
|
|
AskaEth
|
6e00697110
|
feat(chat): 分享进来的消息加一枚「用户分享」渲染层角标
背景：ACTION_SEND 分享进来的内容在会话里与手打的完全看不出区别，主人要求「可识别」。
与后端定过的红线（devdocs/02 的 F4、ShareRules 的「为什么正文一个字都不加」）要求人类可见
标记只能放在客户端渲染层，所以本次正文、content 与任何上行字段一个字节都没动。
改了什么：
- ChatViewModel 的 emitAndDeliver 多一个 localIdPrefix 参数（默认 local-，手打那条路逐字不变），
sendShared 的每一条投递都传 share-：多张图会发多条消息，它们都是分享进来的，所以每条都带。
前缀只加在幂等键前面，后面仍是随机 UUID，唯一性不受影响。
- MessageSource.kt 新增两个常量与两个纯函数：isSharedClientMsgId 只认 share- 且要求后面还有尾巴
（恰好 share- 一律 false：本端铸键永远是 share-uuid，没有尾巴的键不是本端铸的，不能替一条
来路不明的消息声明「这是你分享的」）；isSharedMessage 在它之上加一道只认 user 侧的闸。
- MessageBubble 的 bubbleFooter 多一个 shared 参数，角标 [用户分享] 紧挨来源角标拼在角标行里，
沿用这行既有的字级与颜色，不新造样式、不用 Material3，也只对用户侧气泡出现。
- 新增 SharedMessageBadgeTest：判据的六类边界取值与角标行里的落位。
为什么用幂等键而不是正文标记：clientMsgId 由服务端原样回填，是客户端读得回来的既有字段，
「这条怎么进来的」写在它上面不用新增任何协议，也不污染用户正文。
|
2026-10-05 11:30:56 +08:00 |
|
|
AskaEth
|
f2fbdff9a7
|
W33：并行落回排队的告知加一道本端档位闸 + 忙时被拒那条横幅的只读查证
一、改了什么
加一道闸：pending_ack{reason:"parallel_limit"} 那句降级告知（「她正忙，这条没能另起
一路…」），只在本端当前的「她忙时发消息」档位确实处于「并行」档（InterruptMode.Parallel）
时才给。判据扩了既有纯函数 parallelLimitNoticeFor 的签名（reason + mode 一起判），
本端不在并行档时一律返回 null；调用点在 onEvent 的 PendingAck 分支，档位沿用
currentInterruptMode() 现读（偏好是用户在设置页当场切的东西，缓存住就留一个静默不生效
的窗口），因为 onEvent 不是 suspend 函数，这一句起一个协程去读（与 ensureMessageKnown
同一形态），不起常驻订阅。
二、为什么
pending_ack 是广播帧，每条已认证连接都收得到。极端情况下「别的端在同一会话声明并行
又落回排队、而本端并未选并行」时，本端也会收到这一帧并说那句话 —— 这就是误报。
可那件事与本端无关：用户没选并行时，他这条消息本来就是普通排队、他预期的就是排队
⇒ 落回排队不是意外 ⇒ 不说并不构成静默（与「绝不静默」不冲突）。反过来，在那个时刻
说一句「这条没能另起一路」会让用户以为是自己刚发的那条出了岔子；误报会教用户不信任
这条提示，代价比少说一句大。
三、只读查证（主人点名：忙时被拒那条横幅到底会不会出现）
结论：不缺，pending_full 不带 clientMsgId 时共三档落位，其中两档都写 error，横幅照常
渲染 ——
· 恰好一条待发气泡 ⇒ 回滚档，error = QUEUE_FULL_MESSAGE（她正忙且队列已满，这条没
发出去，请稍后手动重试）；
· 两条及以上 ⇒ 说不准档，error = QUEUE_FULL_UNKNOWN_MESSAGE（她忙不过来，这条可能
没发出去），两个气泡一个都不动；
· 两档都带 errorIsQueueFullNotice = true（柔和档配色），横幅由 ChatScreen 同一条
error 通道渲染。
只有「零条待发气泡」那一档是 Ignore，按设计什么都不写：没有气泡会挂住，也就没有要说
的，不能凭空弹一句 —— 理由在 queueFullOutcome 的 KDoc 与 QueueFullOutcomeTest 的两条
测试里（既有，非本次新增）。即「没带 clientMsgId」不等于「说不准档」，本次查证没有
发现需要改代码的地方。
四、测试
新增 3 条（ParallelLimitNoticeTest）：追加队列档 + 该 reason ⇒ 不提示；打断档 + 该
reason ⇒ 不提示；再加一条把三档一起摆出来的汇总断言（只有并行档给文案）。「并行档 +
该 reason ⇒ 提示」由既有的那条测试覆盖（现在显式传 InterruptMode.Parallel）。总测试
1030 → 1033，0 失败 0 错误。
|
2026-10-05 10:12:41 +08:00 |
|
|
AskaEth
|
e85209eebb
|
fix(chat): 忙时被拒那条横幅调柔和（只它，真错误照旧红）+ 补 pending_ack 的并行降级告知
一、忙时被拒的横幅改用柔和档颜色（它不是错误，不该刺眼）
改了什么：那句告知（她正忙且队列已满，这条没发出去，请稍后手动重试）一直走 state.error 这一条通道，
ChatScreen 里那条 Banner 的调用点对所有 error 一律用 colorScheme.error（正红）。现在给 ChatUiState
加一位 errorIsQueueFullNotice（只决定配色），忙时被拒的两条入口（WS 广播 pending_full 与定向
error{chat_busy} 的队列满处置、REST 409 chat_busy 的回滚）把这一位写成 true，ChatScreen 那一处调用
据此在 onSurfaceVariantSummary（同文件里分享/附件/定位三条告知用的那档柔和色）与 error 之间选色。
为什么：主人裁决形态不变（摘乐观气泡 + 顶部横幅如实告知 + 正文/图片/附件还给输入栏 + 重发复用幂等键），
但红色不要太醒目——忙时被拒不是坏了，是真没排上，红得像故障会吓人。而它与真错误（登录失效、网络失败、
服务端 4xx、图片与附件处理失败……）共用 error 这同一条通道，直接改那个调用点的颜色会把真错误一并调柔和，
所以先分档再选色：写 error 的每一处都显式带着这一位，边界写进了 ChatUiState.errorIsQueueFullNotice
与 Banner 的 KDoc，免得后来人统一改色。
二、消费 pending_ack 的 reason，如实告知「并行没排上、已按普通排队走」
改了什么：reason 字段在解析层早就原样保留（WsEvent.kt 的 PendingAck.reason），但一直没有任何地方消费它
——收到它时界面与普通排队毫无区别。新增纯函数 parallelLimitNoticeFor(reason)（已知值给一句话，未知值 /
缺席 / 空白给 null，不为不认识的 reason 编文案）、常量 PARALLEL_LIMIT_REASON 与 PARALLEL_LIMIT_NOTICE，
以及状态位 ChatUiState.parallelLimitNotice（与 shareNotice / attachmentNotice 同一套机制：8 秒自动收走、
用柔和色、不给关闭按钮），在 WS 的 PendingAck 分支里接上。
为什么：设置页新增并行档之后，开关 ON 不等于一定起第二路——服务端 CHAT_MAX_PARALLEL_TURNS 小于 2 或
额度已满时会让它落回排队，并回 pending_ack{reason:"parallel_limit"}。用户选了并行却看不出区别就是静默，
违反项目铁律「绝不静默」；而这条不是错误、是降级，所以措辞把三件事说清（并行没排上、这条没丢、她做完
手上这句就轮到它），配色与上面那条忙时告知同一档。
测试：新增 ParallelLimitNoticeTest 8 条（reason 的三档穷举 + 横幅温度的边界：忙时被拒为柔和、真错误不
继承那份柔和）。assembleDebug 与 testDebugUnitTest 全绿：1030 个测试，0 失败 0 错误（基线 1022，新增 8）。
|
2026-10-05 09:55:53 +08:00 |
|
|
AskaEth
|
29299b190e
|
feat(chat): 忙时并行回合的客户端半边 —— 六态 + 灰态 + (sessionId, turnId) 两级分桶 + 新帧消费（全部可降级）
依据：Cyrene_v2/DevDocs/_specs/忙时并行-规范草案.md（§1 行为 / §2 接口 / §4 主人裁决）。
后端 v0.65 尚未落地这些帧，所以本次的新键与新帧全部按可降级实现：帧不来、字段缺席时，
App 在今天的真后端上行为与改前逐字相同（下面的「降级保证」逐条给了证据）。
一、改了哪些文件
新增（纯逻辑，可单测）
- app/src/main/kotlin/top/yeij/cyrene/domain/chat/ParallelTurns.kt
两级分桶键 TurnBucket(sessionId, turnId) 与 turnBucketOf / closingBucketOf；
六态枚举 TurnPhase 与 turnPhaseOf；灰态收口判据 closesAnswering；
消息↔回合绑定 TurnBinding 及其纯函数（withTurnBegin / withSteeredMessage / closingTurn /
allClosed / bindingOfMessage）；路小标文案 legBadgeOf。
- app/src/main/kotlin/top/yeij/cyrene/ui/chat/TurnStreams.kt
StreamingLeg(bucket, StreamingState) 与 withLeg / beginLeg / finishingLeg / withoutLeg；
六态在状态上的推导 ChatUiState.phaseOf(消息 / 乐观气泡)；
路小标与「跳到提问」的查表 legBadgeForMessage / legBadgeForTurn / jumpIndexForTurn。
修改
- data/api/dto/MessageDto.kt：HistoryMessageDto 增可选 turnId（历史行 / 落库行都用它）。
- data/api/dto/ChatDto.kt：ChatRequest 增可选 parallel（REST 与 WS chat 同形）。
- data/ws/WsOutbound.kt：chat 增可选 parallel、interrupt 增可选 turnId，省略即整键不进线上。
- data/ws/WsEvent.kt：新增 turn_begin / turn.end / steer_ack 三个事件与其载荷；
session_busy / session_idle / pending_drain 增可选 activeTurns，session_interrupted 增
activeTurns + cancelledTurns，pending_ack 增可选 reason。
- ui/chat/ChatViewModel.kt：流式解析器与「本回合见过结构化正文帧」由单值升为按桶的 map/set，
新增「本会话最近见过的 turnId」锚点；消费 turn_begin / steer_ack / turn.end；
助手落库行按其 turnId 收口灰态并只摘掉它自己那一路的流式气泡；排队回执记进 queuedKeys。
- ui/chat/MessageBubble.kt：MessageBubble / PendingBubble 增 phase 与 legBadge，
正文气泡增灰态配色，新增并行路小标（可点即跳）；角标文案抽成纯函数 bubbleFooter。
- ui/chat/ChatScreen.kt：按桶取每一路的流式状态并渲染；传入六态与小标；忙碌行加「并行 N 路」。
- 新增 4 个测试文件（共 82 条）：ParallelTurnsTest、TurnStreamsTest、
WsEventTurnFramesTest、WsOutboundParallelTest。
二、为什么这么做
- 界面必须按 (sessionId, turnId) 两级分桶（规范 §1.7 第 1 件硬要求）：两路并行时两个不同
turnId 的 message.delta / thinking.delta / tool_call 会交错到达，照老代码「一律累加到当前那
一个流式气泡」会把两条回复糊成一条（规范 §1.4 点名的那件事）。现在每一路各有一份解析器、
一份思维链、一份工具卡表、一个流式气泡。
- 灰态（④ 已读、未答）的唯一权威收口事件是 turn.end（规范 §1.2）。本端另外在 stream_end
（既有的「整轮结束」帧，v0.36 起带 turnId）与「同 turnId 的助手落库行」上也收口：
前者在 turn.end 到位之前是唯一能收口的帧，后者是规范给的兜底。三者顺序不定、重复到达都无害
（纯函数幂等）。
- 六态判定与收口判据的不变量都抽成纯函数，可直接单测；判定顺序即证据强度：
被拒 > 已绑定未收口 > 已绑定已收口 > 本地乐观气泡 > 排队回执。
三、字段缺失时的降级保证（本次最要紧的一条）
- 全链路没有一处「turnId 为空就不渲染」。turnBucketOf 在帧壳没给 turnId 时先回落本会话最近
见过的 turnId、再回落匿名桶（turnId 为空串）⇒ 所有无 turnId 的帧落在同一个桶里，
那就是老代码那唯一一个流式气泡。
- turn_begin / steer_ack.turnId / turn.end 不来 ⇒ 一条绑定都建不起来 ⇒ 六态里只可能出现
①②③⑤，灰态根本不会进入；界面与改前逐字相同。
- activeTurns 缺席时不动这个计数（null 是「不知道」，0 是「确实空闲」，两件事不许互相顶替）；
pending_ack.reason 缺席就是 null，绝不伪造。
- 上行三个新字段（chat.parallel、interrupt.turnId、ChatRequest.parallel）本端今天一个字节都
不发：真并行要用户显式声明，而声明入口不在本次范围内。服务端照旧走排队 + 回合内 steer。
- 已被单测钉住的证据：
ParallelTurnsTest「所有无 turnId 的帧落进同一个桶」「两个空白 turnId 不算匹配，绝不收口」；
TurnStreamsTest「单路时长度恒为 1」「没有任何 turn 帧时已落库=②、本地气泡=①」；
WsEventTurnFramesTest「老形状的帧解出来新键一律为 null（不是 0、不是空串）」；
WsOutboundParallelTest「省略时那条帧逐字节相同，且不带该键」。
四、等 v0.65 的部分
- turn_begin / steer_ack.turnId / turn.end 的真实到达，历史行的可选 turnId，activeTurns /
pending_ack.reason / cancelledTurns 的真实取值。
- 真并行的触发入口（谁在什么时候把 chat.parallel 置 true）——本次只备好线上形状，不接 UI。
- 仍未决且影响客户端的两项：graph_update 两路互相顶掉（规范未决 10，等 design/19 裁决）；
按 turnId 单独核算用量（规范未决 14，可选）。
五、规范里与本端既有定案冲突的一处（如实登记）
规范 §1.1 ⑥「被拒」要求气泡带红色「未送达 · 会话正忙」并可重试；本端被拒（pending_full /
定向 chat_busy）的既有定案是摘掉乐观气泡 + 横幅如实告知 + 正文还给输入栏（可再按一次发送，
幂等键保证不会落成第二条消息）。既有行为由现有测试钉住，本次不改；六态判定里保留了 Rejected
档并由单测直接覆盖，只是本端的现实路径走的是回滚那一支。
验证：assembleDebug 绿 + testDebugUnitTest 绿（0 失败 0 错误 0 跳过）。
|
2026-10-05 09:10:45 +08:00 |
|
|
AskaEth
|
be1c372d99
|
fix(W29): stream_chunk 语义订正、空壳消息如实说明、分享长正文走文件、图片 URL 兜住 host
一、stream_chunk 由「增量」订正为「整段」（后端回执十三 §1）
后端确认三件事：生产里已无生产者、delta 是整段 res.Text、不会与结构化帧并存。
W26 那版照 message.delta 把 delta 追加进同一气泡是错的——真到达会把同一段内容追加成重影。
改法：同一回合内已经收到过结构化帧（message.start / message.delta）就整帧忽略；否则先用
StreamingContentParser.reset 清缓冲，再把这一整段喂进去，即用它整段替换当前流式气泡的正文。
兜底分支保留（后端明确不建议删：那是未知帧不丢内容的兼容路径）。顺带把「回退路径没有
message.start、所以 freshTurnIfFinished 不触发」这条边界在同一个分支里补上（一行级别的收口）。
二、空壳消息不再渲染成空气泡
主人报的 bug 根因在服务端（微信发来的文件没有挂到消息的 documents 上，content 也是空），
已登记后端；但客户端拿到的确实是一条什么都没有的消息，此前渲染成空气泡，用户只能猜。
新增纯函数 isContentlessUserMessage（role 是 user 且 content 空、无 image、无 documents、
无 thinking 才成立，任何一项有内容都不成立，assistant 一律不成立），成立时在气泡位置改为
一句如实说明「这条消息的内容没有被传过来」：灰底灰字（沿用文件里既有的灰态小字），措辞只陈述
本端确定的事实，不猜原因。判据放渲染层（MessageBubble），因为它纯属显示，服务端说什么就存什么，
不在组装层改 DTO。
三、分享进来的超长正文走文件（主人已拍板）
分享的文本超过现成的 TEXT_AS_DOCUMENT_RUNE_LIMIT 时，落成一份 .txt：写进分享缓存目录、
上传 POST /documents、随 chat.documents 发，正文那一栏留空。判据抽成纯函数
DocumentDelivery.planSharedText（正文是否超阈值 + 附件位是否还有空）。
附件位被分享进来的文件占满（一个回合 5 份）时不做转换：正文照正文发，并在提示里说清
「本想作为文件发送，但附件位已占满」——绝不为了塞下 .txt 挤掉用户明确要发的文件。
落盘失败同样退回内联并说一句。组合与图片的关系：那份 .txt 就落在正文原来所在的那一条上
（第一条带图，其余每条一张）。
明确不动的：用户自己在输入框里打的字那条路，长正文照旧按正文发（devdocs/05 的定案第 3 条），
这两件事不是同一件。
四、历史图片的同源绝对地址按当前 baseUrl 兜住 host（F6①）
POST /upload 的 url 是按请求时的 r.Host 拼的绝对地址且原样落库，换服务器地址后旧图取不回；
后端明确认可客户端做「保留 path、替换 host」。新增纯函数 ImageHostRebase.apply：只认
http(s)://任意host/api/v1/files/一段名字 这一种形态，替换 scheme 与 authority、path 逐字节保留；
第三方 CDN、data:、content:// 与 file://、相对路径、裸文件名、带查询串或百分号编码、多一段路径的
一律原样返回。渲染历史图片前在 ChatScreen 传入 AuthManager.currentBaseUrl，全屏查看拿到的也是
替换后的地址。逆作用写进 KDoc：换了指向不同数据的 host 会 404，那是诚实的失败，比永远取不回好。
不改落库数据、不改上传、不碰 documents。
测试：新增 ImageHostRebaseTest 与 ContentlessMessageTest，DocumentDeliveryTest 补分享长正文的判据；
stream_chunk 那条分支是 VM 里的状态机分支，没有硬抽成纯函数（不为测试拧弯架构），改动写在 KDoc 里。
|
2026-10-05 08:14:33 +08:00 |
|
|
AskaEth
|
28c314262e
|
feat(chat): 接上 A5 正向增量 after，并用 404 session_not_found 把「会话已删」如实说出来
改了什么：
- SessionsApi.listMessages 加可选 after（契约 §1 行 6）。before / q / after 三者互斥是服务端的
硬约束，本端三个调用点各只给一个；after 为 null 时 Retrofit 整个省掉这个参数 ⇒ 既有三条路径
的线上请求逐字节不变。
- MessageRepository 加 loadAfter：同一个端点，服务端按【升序】返回（与 before 的倒序相反），
仍统一转成升序的 PagedMessages。顺手去掉 toPagedMessages 参数名里那个已经不对的 newestFirst。
- ChatViewModel：
· 新增 newestKnownAt（从状态现算的 after 游标）与 absorb（只并消息与乐观气泡，不碰
loading / loadingOlder / hasMore / error —— 一次静默补拉不该把上拉位置和错误横幅掀掉）。
· 掉线那一刻记下游标、重新连上时用它做一次正向增量。记录时机必须在「掉线」而不是「重连后」：
重连的 history 帧会把最近 50 条灌进来、游标随即被推到「现在」，那时再取就取不到那个洞了。
「再拉一页最新」永远补不回中间断掉的那一段，这正是 after 存在的理由（02/A5 的欠账）。
· ensureMessageKnown 先用增量（只要新来的那几条），还认不出来才退回整页重拉。
· 循环推进抽成纯函数 loadForwardPages：游标必须严格前进（同毫秒并列且超过一页时推不动，
契约 §A5 明写的已知边界）+ 轮数上限 20，两道防死循环的闸都由单测钉住。
- 404 session_not_found（契约 v0.63）：首屏 / 上拉 / 增量三条读路径都判，非主会话就置
ChatUiState.sessionGone；ChatScreen 据此显示一句实话并回调 ChatHomeScreen 重拉会话列表
（refresh 内部会把「指向已删会话」的 activeSessionId 收敛回主会话）。
主会话不置位：那说明部署本身出了问题，该显示的是普通错误横幅，而不是一句假的「已切回主会话」。
为什么：
主人那次「图片凭空消失、别的端也看不到」的真相，就是会话在别处被删掉之后，客户端把它渲染成了
一条空会话 —— 让用户对着空白猜。现在有了机器可读的 404，就能如实说一句并把人带回主会话。
另一半是重连补洞：一直是「再拉一页最新」在顶着，断线期间超过 50 条必丢中间那一段。
验证：assembleDebug + testDebugUnitTest 全绿，846 测试 / 0 失败 / 0 错误。
较基线 831 新增 15 条（MessageAfterRepositoryTest 5 条走真 OkHttp 断言线上 URI；
ChatRecoveryTest 10 条钉住 404 判据与增量循环的两道闸）。
设备侧验证（点开看到那句实话、断线补洞）另行做，不在本次提交的断言范围内。
|
2026-10-04 22:00:55 +08:00 |
|
|
AskaEth
|
351891714a
|
feat(chat): 单条消息的编辑与删除（D3）
契约 §1 行 6a/6b 的两个端点与 §3.8 的两帧，整条链接完（不含「重发」——契约
明确没有重发端点，客户端用编辑后的内容再 POST /chat 即可，本模块不做）。
数据层
- SessionsApi 增 PATCH / DELETE api/v1/messages/{id}（与既有消息端点同源，因此
MessageRepository 能直接复用、不必动 AppContainer），MessageRepository 增
editMessage / deleteMessage，走既有 apiCall / Result 风格。
- 响应形状照契约不照旧文：PATCH 的 data 直接就是消息 DTO（没有 message 包一层），
DELETE 回 {deleted: id}；编辑内容按「非空、≤4000 rune（码点，不是 length）」
预校验，不合格一个请求都不发。
帧解析
- WsEvent 增 message_edited / message_deleted，形态照 message_persisted 那一套：
会话归属先取帧壳、其次取消息自身的 sessionId，未知键安全、未知帧与坏帧安静忽略、
永不抛。
- message_edited 的 data 就是消息本身（与 message_persisted 的 data.message 不同形），
照抄那一套会解出 null——这一点由单测钉住。
VM
- 按 id 原位改 content / 原位移除。两条路各自只有一个落地出口：本端 PATCH/DELETE 的
成功回执与随后到达的广播都调同一对纯函数，而它们幂等（同一内容做两次返回同一实例）
⇒ 「响应 + 广播」双到达收敛成一次，不需要去重表、也不会出现两套状态源。
- 编辑只对 role == user 开放、删除对 user 与 assistant 都开放，判据是同一份纯函数，
气泡（隐藏入口）与 VM（再挡一次）共用。
- 失败一律如实：弹层还开着就留在弹层里（输入不丢、可原地重试），弹层已被关掉就挂到
页面顶部那行横幅，绝不静默。
UI
- 长按气泡打开动作菜单；由于正文包在 SelectionContainer 里、长按正文同时也是选字手势
（两者抢同一个长按，谁先消费由运行时决定），另给一枚看得见的「⋯」
（content-desc 消息操作）作为同一条入口，避免只有知道的人才会用。
- 编辑弹层：原始 content 作初值 + 码点计数 + 取消/保存；删除必须二次确认。
- ChatScreen 只加 24 行接线（两个回调 + 两个弹层的渲染）。
测试 +49（766 → 815，全绿）：帧解析 14、纯逻辑 15、Retrofit 层 7、失败文案与落点 13。
|
2026-10-04 21:26:52 +08:00 |
|
|
AskaEth
|
23b46f9310
|
feat(chat): 会话内消息搜索 D2 —— 顶栏入口 + 搜索态面板 + 点结果定位
改了什么
- data/api/SessionsApi.kt：messages 端点加可选 q（契约 §1 行 6：q 是同一个端点上的
查询参数，不是新端点）。不传 q 时 Retrofit 整个省掉该参数，既有调用线上请求逐字不变
—— 这条用真 HTTP 服务端读原始 URI 钉住，而不是靠读代码相信。
- data/repository/MessageRepository.kt：新增 search()（走既有 apiCall/Result 风格，
倒序返回统一转成升序的 PagedMessages），以及 normalizeSearchQuery（只 trim：
不转义 % _ \、不改大小写 —— 这两件事服务端已做，两边都做必然错一边）。
空查询不发请求（契约里空 q = 未传，那会把整段历史当成搜索结果回给调用方）。
- ui/chat/SessionSearchModel.kt（新）：全部纯逻辑 —— 命中片段投影（先过 domain/parse
这一处解析器再拼回纯文本，绝不把标记当富文本；标记里才有的词只显示不高亮）、
结果合并去重排序（倒序，与聊天页的升序 MessageOrder 刻意相反）、游标推进、
「这条在不在窗口里」的判定、失败文案。
- ui/chat/SessionSearchViewModel.kt（新）：只属于聊天页搜索态的小 VM，带代际号，
连打两次回车时慢的那个请求回来不会顶掉新关键词的结果。
- ui/chat/SessionSearchPanel.kt（新）：全屏搜索面板 —— 自动聚焦输入框（IME 搜索键与
放大镜都能提交）+ 结果列表（角色 / 时间 / 命中片段，BasicComponent 包 PreferenceCard）
+ 往下翻加载更早的命中 + 未搜/搜索中/空结果/失败 四态分开渲染。
- ui/chat/ChatScreen.kt：只加接线 —— 顶栏搜索入口、面板叠层、返回键先关搜索、
点结果之后的如实告知。
为什么这么做
- 搜索态独立成小 VM：ChatViewModel 正被另一个并行模块改动，而搜索不改消息窗、不发消息、
不碰 WS，没有任何理由挤进去。
- 面板叠在聊天页之上而不是替换它：底下的 LazyColumn 必须保持挂载，点一条命中要
animateScrollToItem 定位，而 LazyColumn 一旦被移出组合，滚动就落空。
- 命中不在「已加载窗口」里时不插一条临时气泡，而是如实提示（比一个假的跳转诚实）：
聊天列表是升序倒过来喂给 reverseLayout 的，凭空插一条几千条之前的消息会出现在列表最底
——也就是「刚刚发出的位置」——与它自己的时间戳矛盾，还会带偏跟随底部的判断；
而把消息真的并进窗口要改 ChatViewModel，本模块不许。
- 失败绝不渲染成「没有找到」：两者都是一张空列表，但一个该换关键词、一个该修网络或权限。
- 返回键先关搜索：新处理器注册在 ChatHomeScreen 那几条之后（优先级更高），
且搜索没开时是 disabled，抽屉 / 管理页 / 设置页的既有层级不变。
测试 706 -> 737（+31：纯逻辑 25 + 数据层 6）
|
2026-10-04 20:44:03 +08:00 |
|
|
AskaEth
|
3b4a790e30
|
feat(ws): 队列满时定位并处置那条待发气泡（契约 v0.59 / 协同 G5）
WS 上行没有 REST 那样的同步回执：队列满时服务端只广播一条 pending_full，而载荷里既没有
「被拒的是哪一条」也没有任何可对齐的键，于是那条乐观气泡永远挂「发送中…」，用户不知道它
其实根本没发出去。后端 v0.59（G5）已经把这两件事补齐：pending_full 载荷新增两个可选键
clientMsgId（被拒那条消息的幂等键，未携带则整键缺席）与 messageId（仅当该消息此前已落库 /
已认领时才回填，服务端绝不在此新铸 id），并新增一条只发发送者的定向帧
error{code:"chat_busy"}，与 REST 的 409 chat_busy 同码。本端把这两条接上。
data/ws/WsEvent
- PendingFull 增 clientMsgId / messageId：缺席就是 null，绝不拍成空串（否则收编路径会去
对齐一条不存在的消息）。
- Error 帧增 code / clientMsgId / messageId，并从 data.sessionId 取会话归属（定向帧的帧壳
上没有 sessionId）。code 是开放集合：未知码原样保留，不抛、也不吞掉整帧。
未给定向 error 另立事件类——它与既有 error 是同一个 type，一个 type 无法用两个类表达；
两者语义的分叉放在下面的判定函数里，保持「一个帧类型一个事件类」的既有约定。
- PendingFullData / ErrorData 同步扩键，全部可选且默认 null。
ui/chat/ChatViewModel
- 新增纯函数 queueFullOutcome（判定）与 ChatUiState.applyQueueFull / rollbackPending
（状态迁移），两者都不碰协程，逻辑不埋在协程里、可直接单测。既有 rollback 改为委托
rollbackPending，行为逐字不变。
- 判定顺序即证据强度：clientMsgId 命中时，messageId 非空 => 收编（复用 alignDuplicate：那条
其实早就落库了，不是失败、不回滚、不把正文/图片/附件退回输入栏），缺席 => 回滚那一条并把
内容还给输入栏；clientMsgId 有值但不命中 => 放手（键只属于某一次具体发送，回滚任何一条都是
误伤）；clientMsgId 缺席（老服务端）=> 沿用 toolExecutionTargetIndex 的先例，只在待发恰好
一条时回滚它，两条及以上不猜、但也不装作没事，只如实提示一句。
- 广播 pending_full 与定向 error{chat_busy} 会同时到达发送者，两者共用 onQueueFull；
幂等靠状态本身——第一次已把气泡移出待发列表，第二次判定自然落到 Ignore，不会回滚两次、
也不会提示两遍。
- REST 409 chat_busy 的文案与 WS 侧合并成同一句（契约把两条入口定为同一个 code），
并点明「这条没发出去、请手动重试」：全链路没有自动重试。
测试 +30（634 -> 664，0 失败 / 0 错误）
- WsEventPendingFullTest：两个新键的有/无、老形状仍可解析、会话闸、无载荷与坏帧不抛。
- WsEventErrorFrameTest：chat_busy 定向帧全字段、可选键缺席为 null、未知 code 原样保留、
只带 code 的帧仍可解、只有 message 的老帧行为不变、坏帧不抛。
- QueueFullOutcomeTest：三种事实各自的判定与状态迁移（收编不动输入栏 / 回滚归还正文图片附件 /
不猜时一个气泡都不动），以及键对不上、空键、同一帧处理两次的幂等。
未验证：本端没有设备也没打过真后端，队列满的实机触发路径见交接报告；VM 里
「判定 -> 既有动作」的映射只由编译与纯函数单测覆盖（构造 ChatViewModel 需要 Android
环境的 AppContainer，单测里没有先例）。
|
2026-10-04 19:41:40 +08:00 |
|
|
AskaEth
|
642bdb13f0
|
feat(admin): 「最近日志」接上 logs REST 引导读取 —— 补齐 W10 只显示进页面之后那段日志的缺口
W10 接上的 `observability_log` 帧以「订阅那一刻的最新条目」为锚、不回灌历史，而客户端没有
`GET /api/v1/admin/observability/logs` 的接入 ⇒ 概览页的「最近日志」只能显示进页面**之后**产生的
条目。本次把 REST 引导读取补上，并把 W10 那条取舍（「一帧都没到过 → 整段不渲染」，为的是不把
「没有推送」说成「没有数据」）改成契约要求的「**REST 成功即渲染、帧是增量**」。
- **取数**：`AdminApi` + `AdminRepository` 接上该端点，显式发 `limit=200`（与客户端保留窗口、
帧的单帧上限同源）；**不暴露** `?level=`——它是服务端「最低等级」过滤，只在服务端裁剪一次，
会饿死界面上那排要来回切换的等级档，所以一律取全量、由客户端本地过滤（契约 §3.12 亦然）。
- **DTO 统一**：REST 与帧同形（后端同一个 `gateway.AdminLogEntry`），因此把
`data/ws/ObservabilityLogEntry.kt` 挪进 `data/api/dto/AdminDto.kt` 并改名 `AdminLogEntryDto`
（顺带与 `AdminMetricsDto` / `AdminTraceSpanDto` 对齐），删掉旧文件——不留下两份等价形状。
- **合并纯函数**：日志改成「去重 → 按 `time` 倒序 → 截窗口」。三步顺序不能换：窗口是**位置**
截断，先截再排会让一条更旧的条目挤掉更新的那条；排序用解析出的 epoch 秒 + **稳定排序**保住
同秒条目的到达顺序（服务端 `time` 只有秒精度）；时间判不出来的条目落到尾部但**不丢**。
trace 那条路径不动（span 有服务端写入序号，重排反而把顺序排乱）。
- **界面**：`logs` 改为可空——null = 还没有基线（不渲染）；非 null（含空列表）= REST 读过且成功
⇒ 渲染，于是「加载中 / 不可用 / 暂无日志 / 列表」四种表现分明，未知等级条目照旧一律保留。
三路的失败原因也分开记了：日志挂了不再让 trace 那块显示「不可用」（那是把一次成功说成失败）。
- **角色分档**：新增纯函数 `canReadObservabilityLogHistory`（日志历史与概览页同档，
v0.40 的 viewerAuth 只读监控档 ⇒ **viewer 也读得到**），与只发 owner/admin 的帧门刻意不对称。
⇒ viewer 看得见历史、收不到增量，界面不得因此报错或报空（区块是否渲染只看历史这条门）。
测试 567 → 591（DTO 边界、合并去重/排序/窗口、角色分档、仓库线级请求与 501/403/坏载荷）。
`assembleDebug` 与 `testDebugUnitTest` 均通过（591 测试 / 0 失败 / 0 错误）。未做真机与真后端验收。
|
2026-10-04 19:18:42 +08:00 |
|
|
AskaEth
|
ab76798bff
|
merge: W9 — 文档附件接到 UI 与发送链路（选文件 / 待发芯片 / chat.documents / 分享分流）
|
2026-10-04 18:48:42 +08:00 |
|
|
AskaEth
|
30180ab1e5
|
feat(chat): 文档附件接到 UI 与发送链路（选文件 / 待发芯片 / chat.documents / 分享分流）
把 W6 做好的「文档进对话」数据层接上 UI 与发送路径，产品决定按 05 的定案执行：
**不做长正文自动转文件**、**附件与正文各自独立存在**、上行**只给服务端存储名 `name`、≤5 条**、
带附件一律走 REST。
改了什么（按清单）：
- AppContainer：照 cachedUploadApi 的写法加 documentsApi + documentRepository，**与 chatApi 同
baseUrl / 同 token·401 策略**（上传拿到的 name 要交给同一个后端的 /chat，不同源必然 404）。
- domain/chat/DocumentAttachment.kt（新）：DraftDocument（待发附件，只带本地引用，**不带字节**）、
admit()（去重 → 20 MiB 单份预检 → 5 份上限，被挡下的**都计数**、绝不静默裁）、
readBounded()（超限回 null、IO 异常原样抛——「太大」与「读不到」必须分得开）。
- domain/chat/DocumentChip.kt（新）：附件芯片的展示换算（类型 / 体积 / 注入字数 / 状态），
unreadable（读不到）与 truncated（注入被预算截断）**两句文案分开**，未知 status 原样显示。
- domain/chat/DocumentDelivery.kt：加 planForCount(text, 份数)——同一套判定矩阵，但只看份数，
因为 VM 手上还没有字节（最多 5×20 MiB 一次性读进内存不可接受）。plan() 委托给它，行为不变。
- ChatViewModel：ChatUiState 加 draftDocuments / attachmentNotice；send() → deliver() 走
DocumentDelivery 判定 → 逐份上传（保留扩展名、200+deduped 当成功）→ payload(names) 为 null
时**提示而不截断** → sendViaRest 带 documents；失败与正文、图片一起回滚（附件还给输入栏）。
- ChatScreen：SAF OpenMultipleDocuments 入口（MiuixIcons.File + contentDescription「添加文件附件」），
MIME 列表贴近后端文本白名单的语义（含 octet-stream 以免「后端收得下、用户选不到」），
输入栏上方一排可移除芯片；发送按钮在只有附件时也可用（纯附件回合服务端支持）。
- MessageBubble：documents 渲染成芯片（名字中略保住扩展名 / 类型·体积·字数·状态），
unreadable 整枚转灰并明写「读不到」；空列表不占位。PendingBubble 显示本地待发件。
- ShareIntake + ShareRules：EXTRA_STREAM 按 ContentResolver.getType 分流——image/ 前缀走既有
图片路，其余（含 null）走**文档路**（拷进 cache、带显示名与真实字节数）。此前一律当图片拷，
一份 .md 只能得到「图片处理失败」。**Manifest 一行未改**：后端明令拒绝 html/SVG/zip/脚本，
声明全通配会造出「点进去必然失败」的入口，text/plain 已能接住 .txt/.md/.log。
测试：485 → 536（+51，0 失败 0 错误）。
|
2026-10-04 18:44:23 +08:00 |
|
|
AskaEth
|
93941cd1ea
|
merge: W10 — 接上可观测性下行帧（概览页实时刷新 metrics / trace / 日志）
|
2026-10-04 18:42:58 +08:00 |
|
|
AskaEth
|
b5e6f78910
|
feat(admin): 接上可观测性下行帧，概览页实时刷新指标 / trace / 日志
契约 v0.55 §3.12 的三帧（`observability_metrics` / `observability_trace` / `observability_log`）
此前在本端没有 handler，落到未知帧被静默丢弃，概览页只能「进页面 / 手动刷新各拉一次 REST」。
- 解析（data/ws）：三个事件类 + `dispatchObservability` 分支，载荷按契约逐字对齐
（metrics = 扁平本体、trace = `{spans}`、log = `{entries}`），帧壳 `sessionId` 有就透传。
载荷缺席时**整帧安全忽略**——metrics 回落成默认值就是一份全零快照，会把界面上的真实指标
擦成 0；未知帧、坏帧仍安静丢弃（回归用例钉住，绝不抛）。
- 消费（ui/admin）：AdminViewModel 自持一条 socket（照 SessionsViewModel 的做法：登录且
角色够档时连、登出 / 角色降档 / onCleared 关），把三帧合并进概览状态。REST 仍是兜底真源：
进页面与手动刷新照旧各拉一次全量；每次「连上」（含首次连接与断线重连）后再重读一次——
断线窗口里的帧永久丢失，而服务端只为「有在线 owner/admin 连接」的凭据保留订阅，
重读同时也重建订阅（契约 §3.12：读取即订阅握手）。
- 角色门在客户端也判（domain/admin 新增纯函数 `canReceiveObservabilityFrames`）：这三帧服务端
fail-closed 只发 owner + admin，与概览页自身的 Monitor 档是两条门，viewer 既不开连接也不合帧。
- 日志只有推送这一个来源（本端没有 logs REST 端点）：一帧都没到过时整段不渲染——不写
「暂无日志」，那等于把「没有推送」说成「没有数据」；等级过滤按契约在客户端本地做。
- 合并与过滤是 ui/admin 下的纯函数（新帧在前、按业务键去重、窗口 100/200），单测覆盖。
测试 485 → 514（+29），0 失败 0 错误；`assembleDebug` 通过。
|
2026-10-04 18:42:23 +08:00 |
|
|
AskaEth
|
3ed2377b3c
|
feat(设置): 「版本」行可点进「关于」页
设置页的「关于」分组里，「版本」此行此前点了没反应——它是全页唯一
没有 onClick 的行。现在它带 ChevronForward（与管理员入口行同一种「可
进子页」提示）并可点，进入新的「关于」页。
「关于」页只有四项：应用名（Cyrene）、版本、一句话简介、作者
（AskaEth），自己带 Scaffold + 返回按钮，观感与设置页一致。版本号复用
BuildConfig，不写死；页面里不放任何链接 / 邮箱 / 版权年份——这些信息
没有人提供过。
返回层级照项目既有的手写布尔状态 + 分层 BackHandler 模式（本项目无导航
库），新增 showAbout：
- 关于 → 设置 → 聊天；
- 设置页的处理器条件是 showSettings && !showAbout（与关于页互斥），
所以在关于页按返回只退一层，不会一步跳回聊天；
- 抽屉 / 设置 / 管理页既有层级未动。
版本文本抽成纯函数 versionText(versionName, versionCode)，设置页与关于页
共用一份格式，并由 VersionTextTest 钉住输出。
测试：485 → 487（新增 VersionTextTest 2 条），0 失败 / 0 错误；
assembleDebug 通过。
|
2026-10-04 18:31:03 +08:00 |
|
|
AskaEth
|
217cfe3d5f
|
W5: 新建会话时选角色（persona）
改了什么：
- `POST /api/v1/sessions` 支持可选 `personaId`：null（或全空白）走**不带 body** 的重载
（与选角之前逐字节相同），非空才发 `{"personaId":"…"}`；新增 CreateSessionRequest /
CreateSessionResponse.personaId / SessionSummaryDto.personaId。
- 新增**用户侧**角色目录取数：PersonaApi + UserPersonaDto + PersonaRepository（沿用 apiCall/Result）。
刻意不用 admin 的 PersonaSummaryDto/AdminApi：用户侧不下发 admin 专属 thinking，admin 端点还要管理档。
- 抽屉「＋」不再直接建会话，而是先开角色弹层（「默认角色」+ 各角色，角色名 + character 简述，
失败/加载中各自有话说）；确认后按所选创建。角色表拿不到时降级为「只有默认角色」，不挡建会话。
- 会话行摘要前缀该会话绑定的角色名：能拿到角色表就显示名字，拿不到就原样显示 id，未绑就不显示。
为什么：
- 此前 createSession 完全没有 body，新建的会话一律是默认角色，后端 v0.42 起的多角色能力用不上。
- 会话角色**创建后不可变**（`PATCH /sessions/{id}` 一旦收到 personaId 就 400），所以选角这一步
只在建会话时问一次，也必须在建会话时问。
测试 353 → 385（+32），assembleDebug 与 testDebugUnitTest 均通过。
变异验证：把仓库改回「null 也发 body」后，SessionRepositoryCreateTest 有 2 条断言 FAIL。
|
2026-10-04 18:06:11 +08:00 |
|
|
AskaEth
|
664fd8dcef
|
merge: W3 — B1 /upload（大图走上传，历史只留 URL）
|
2026-10-04 17:44:23 +08:00 |
|
|
AskaEth
|
f413f8db55
|
feat(sessions): 接上 D4 未读 —— 抽屉角标 + 已读游标（进入即读、看着就点已读）
后端 v0.37 起 `GET /sessions` 每条会话恒下发 `unreadCount`、`POST /sessions/{id}/read`
可推进**账号级**已读游标（只前进，`MAX(read_at, before)`）、成功后广播 `session_read`，
客户端一直没接。本次补齐：列表能看见未读、看完真的会消、别的端读了本端也消。
- data/api/dto/SessionDto.kt：`SessionSummaryDto.unreadCount`（**默认 0**——
`SessionPreferences` 把整份列表原样持久化，非默认值会让升级后第一次启动整份快照
解码失败、列表先空一下；默认 0 只会让角标少显示一会儿）；
新增 `ReadSessionRequest`（`before` 缺席 = 现在，`explicitNulls=false` 保证序列化成
`{}`，正是服务端接受的形状）与 `ReadSessionResponse`
- data/api/SessionsApi.kt + data/repository/SessionRepository.kt：`markRead(sessionId, before)`
—— 不传 0（服务端对 0/负数回 400），null 即「现在」
- data/ws/WsEvent.kt：新增 `SessionRead`（`{type:"session_read", sessionId, data:{readAt}}`）。
会话归属**只在帧壳**上（data 里没有 sessionId）；`readAt` 缺席回落 0，而 0 在上层是
「无从判断」——坏帧因此天然退化成什么都不改
- ui/sessions/SessionsViewModel.kt：`SessionItem` 多出 `unreadCount` 与 `lastMessageAt`
（后者只用于游标比对）；两条调和规则方向相反且都写成纯函数——
`withReadCursor(readAt)` **有依据**地清（游标只前进，本地最新消息不比游标新才算真已读；
若有更新的消息则保留旧计数，不能把真实未读藏起来），`markRead(id)` 无条件清（用户就在这一行）
- 已读策略：① `select()`（点开 = 进入）以「现在」推进——聊天页紧接着会加载并显示最新一页，
比推本地可能陈旧的 `lastMessage.createdAt` 更诚实，且先就地清零，角标不等网络往返；
② `message_persisted` 且会话是**当前打开**的那一个时，以该消息 `createdAt` 推进
（只标它及其之前，同时落库的更晚消息仍算未读），否则「自己正看着的会话」会攒出角标。
不该标的绝不乱标：别的会话攒未读是正确行为，本端不做「替服务端数未读」（增量会漂移，
抽屉每次打开都会静默重拉，以服务端为准）。失败**静默**——服务端游标是唯一真源
- `session_read` 帧按帧里的会话 id **逐行**定位（刻意不用 `isForSession`：那道闸是给
「一个 VM 只关心一个会话」的 ChatViewModel 用的，本 VM 持有整个列表，按 activeSessionId
过滤会把「别的会话被读了」这一帧丢掉，那正是最该处理的一半）
- 另记一份本地已知游标（只取服务端口径：read 响应的 readAt / 帧的 readAt / 落库消息的
createdAt），在整表替换时把「本地已知没有更新消息」的行压回 0——否则一次竞态中的
GET（快照早于本端刚发起的 read）会把角标闪回来；登出时随快照一起清（游标是账号级的）
- ui/sessions/SessionDrawerContent.kt：角标用 Miuix 自带 `Badge`（错误色药丸 + onError 文字），
且**放在标题行里**而不是 `endActions`：抽屉固定 300dp，卡片与内边距之后只剩约 244dp，
`endActions` 已有三个 40dp 图标（120dp）且被库内 60% 硬上限卡着，再塞角标会把图标挤到裁剪。
改成标题行的 `[标题][角标]` 后角标不占额外列宽；标题/摘要同时收紧为 `maxLines = 1` +
省略号（长标题不再在约 116dp 里折成两三行把卡片撑高）；`99+` 收敛、`0` 不画
测试：305 全绿（272 → +33）：角标文本（0/负数不画、99 精确、100 与 1234 收敛 `99+`）、
两条调和规则的各种边界（游标等于/新于/旧于最新消息、无消息会话、坏帧 readAt=0、
按会话逐行定位、遮罩只压记过游标的行）、`toItem` 映射、`session_read` 帧解码
（生产者逐字取自后端 `gateway/session_read.go:broadcastSessionRead`）、DTO 真载荷
（`GET /sessions` 抓包里主会话 unreadCount=6、次级=0）与**旧快照无该键仍解得开**、
read 请求体序列化（`{}` / `{"before":…}`）。
未验证（无模拟器，也不许碰 adb，只有构建 + 单测）：
- 角标与标题的**实际观感**没截图。宽度是按 Miuix 0.9.3 源码算的（抽屉 300dp − 卡片边距 24
− 组件内边距 32 = 244dp；endActions 120dp < 60% 上限，标题列约 116dp，角标约 16~32dp）。
LazyColumn 里角标与标题的具体落位（紧贴标题还是行尾）取决于 Row 的权重分配细节，两种都成立、
都不遮蔽文字，但真机上可能想微调间距
- 「进入即读」在 UI 上没端到端跑过：POST /sessions/{id}/read 是否 200、`session_read` 帧
是否真的清掉另一端的角标，只有单测与契约（后端源码）支撑，没有真机往返
- 已知近似：判断「正在看这个会话」只用 `activeSessionId`，而它是**活动页**的会话 id——
用户切到设置 / 管理页时 ChatScreen 已卸载，此时落库的消息也会被标记已读（他会回来看到，
但角标已经消了）。信息不足，如实记在这里
架构代价（需主人裁决）：`session_read` / `message_persisted` 只在 WS 上，而 `AppContainer`
只提供 `createChatSocket()`（每次新建，**没有进程级共享连接**），`ChatSocket` / `ChatViewModel`
/ `AppContainer` 都在别人的改动范围里 —— 本 VM 因此自持一条连接（登录后连、登出断开、
销毁断开）。这是既有遗留问题「每 VM 一条 socket、旧 socket 不关」之上再加一条；服务端支持
同账号多连接（多端本来如此），收不到帧也只是退回「下次 GET /sessions 收敛」。共享一条
app 级连接是更好的终局，但那要动 AppContainer / ChatSocket。
|
2026-10-04 17:42:31 +08:00 |
|
|
AskaEth
|
cc2f266564
|
feat(chat): 大图改走 /upload，历史里只留 URL
服务端把 `chat.image` **原样落库**，于是内联的 base64 会在**每一页历史**与**每一次
WS `history` 回放**里重传一遍（协同 G3）。B1 的 `POST /api/v1/upload` 早就有了，客户端
一直没用——本次把它接进发送路径。
- `data/api/UploadApi.kt` / `data/api/dto/UploadDto.kt` / `data/repository/UploadRepository.kt`：
upload 三件套。multipart 字段名 `file`（Go 只认这个名，且只把带 `filename` 的部件当文件，
已对着在线后端实测：字段名不对回 `400 {"code":"bad_request","message":"file is required"}`）；
走 `apiCall`（这台端点的状态码不承载额外语义，`413`/`415` 的区分在 `error.code` 里）。
仓库另拦两种「服务端帮不了」的情况：`url` 为空**或不是绝对 http(s) 地址**就判解析失败
——视觉层只把 `http(s)://` 当 URL，裸路径会被当成 base64，照发等于把这一轮扔进黑洞。
- `app/AppContainer.kt`：按 baseUrl 缓存接线，与 chatApi 同源（上传产物 URL 必须交给同一个后端）。
- `domain/chat/ChatImageDelivery.kt`：内联 vs 上传的**唯一判据**（纯函数）。
阈值为重编码后的 **64 KiB（含等于内联）**：内联的代价是每次历史取数再多 4/3 × B，
64 KiB 即 +85 KB/次（20 张这种图的会话每次冷启动/重连回放就多传 ≥1.7 MB），而上传只是
多一次往返（局域网毫秒级）——从第二次取数起就稳赚；≤64 KiB 的缩略图省下的量与一次往返同量级，
不值得多一个失败面。阈值必须严格小于本端 1 MiB 预算，否则上传分支是死代码（有测试钉住）。
- `ui/chat/ChatViewModel.kt`：图片发送路径分流（小图内联、大图上传换 URL 再发 REST）。
**上传失败不回退内联**：回退会把「省历史重量」当场作废、还是在用户看不见时换了一条语义不同的路；
这里按上一步骤给可重试文案，并把图与文本还给输入框（`uploadFailureMessage`，纯函数可单测）。
- `data/image/ChatImagePreparer.kt`：产物改为同时给出 `data:` URI 与**同一份**字节，
上传因此不必把刚编出来的东西再 base64 解一遍。
阈值依据、以及「URL 形态到底受不受 5 MiB 上限约束」的核查结论写在 `ChatImageDelivery`
与 `UploadRepository` 的注释里（结论：URL 形态**不受**解码后 5 MiB 约束——网关
`checkChatImageSize` 量的是 `image` 字符串长度，URL 才几十字符；URL 到视觉层才被取回，
上限是 `vision.maxFetchedBody` = 50 MiB。所以走上传**不是**为了绕开上限，本端 1 MiB 预算离
两个 5 MiB 上限都还差两个数量级）。
测试：309 全绿（272 → +37）：上传响应/错误体的真实形状（错误体是在线抓包原文）、
multipart 线级形状（部件名、filename、字节原样）、内联阈值与两条不变量、上传失败文案。
`assembleDebug` 通过。**未实测**（本端无模拟器、且不给在线后端留测试文件）：
真机上的上传成功链路与 Coil 渲染远程 URL——已静态确认 `coil-network-okhttp` 带
`META-INF/services/coil3.util.FetcherServiceLoaderTarget`（默认 ImageLoader 会自动注册网络
fetcher）、`network_security_config` 放行明文（同源 http URL 可取），但没跑过真机。
|
2026-10-04 17:40:12 +08:00 |
|
|
AskaEth
|
feeb49ebeb
|
fix(sessions): 刷新后校验当前会话是否还在，别一直指着已删会话
会话在**别处**被删掉（Web 面板 / 别的设备 / 直接调 API）时客户端无法感知：`refresh()`
成功后会整体替换 `sessions`，却**不校验 `activeSessionId` 是否还在新列表里**，
于是当前会话会一直指着一个已删会话——聊天页对着空会话，而且这个陈旧 id 会被
`prefs.setActive` 持久化下去，重启后依然是它。
本端自己的删除已经处理过（`deleteSession` 会主动切回主会话），漏的正是「别处删除」这一路。
- ui/sessions/SessionsViewModel.kt：新增纯函数 `resolveActiveSession(activeId, fetchedIds)`
—— 不在列表里就回落主会话；**列表为空时不回落**（那是异常响应，不该拿它改用户的选择）。
`refresh()` 成功分支调用它，值变化时同步持久化
测试：272 全绿（269 → +3）：已删会话回落主会话 / 仍在列表则保留 / 空列表不覆盖用户选择。
实测：会话在别处删除后 force-stop 重开（重走 init 与刷新），
`cyrene_sessions.preferences_pb` 里 **`web:<sub>` 残留彻底消失**、`active_session_id` 回落 `web`；
界面回到主会话对话，不再出现已删会话的幽灵行。
|
2026-10-04 17:10:26 +08:00 |
|
|
AskaEth
|
e642b0c18c
|
feat(chat): 加 REST 发送路径 —— 长文与图片（含 clientMsgId 幂等与归一）
客户端此前**只有 WS** 发送，而 WS 帧硬上限 4096 字节、**超限是直接断连**（不是报个错），
所以长文发不出去、图完全发不了。v0.56 给 REST 流式补齐了明确响应面与 clientMsgId，
本次照它接入。
- data/api：ChatApi + ChatDto（窄请求体，不回环整条会话）+ ChatRepository
—— **刻意不走 `apiCall`**：它把 4xx/5xx 一律折进 `Result.failure` 并丢掉状态码，
那样 `202`（已排队）与 `409`（队满）的差别会在那一刻消失；改为映射成 ChatAck 密封结果
（Accepted / Queued / QueueFull / Duplicate / Unavailable / Rejected）
- domain/chat/ChatSendRouting：纯函数路由 —— **UTF-8 字节数 ≤ 3584 且无图 → WS，否则 REST**。
阈值按**字节**不按字符（中文 1 字 3 字节）；预留 512 字节覆盖帧壳。短文本仍走 WS 是刻意的：
那条路**绕开有损总线**，而超 WS 上限的代价是**断连**而非报错，两边风险不对称
- domain/chat/ChatImageBudget + data/image/ChatImagePreparer：解码 → 等比缩放 → 重编码为
JPEG/PNG data URI；超预算自动降尺寸重来；**失败返回 null，绝不退回原图 base64**
- clientMsgId：每次发送 `"local-" + UUID`（**随机不自增**——服务端判重窗口是**整个会话历史
且无过期清理**，进程重启后复用旧值会让那条消息永远发不出去）；REST 与 WS 两路都带
- 归一：带 clientMsgId 的消息**只按 id 匹配**（文本不同也命中；匹配不到就什么都不吃，
**绝不回落到文本**——那会吃掉一条无关气泡）；不带键的老行才回落「第一条同文本」
- ack 分支：200 已受理（等 message_persisted）/ 202 已排队（出「已排队 N 条」）/
**409 既未受理也未落库 → 回滚气泡并把文本与图片还回输入框**（不能当「已排队」，
那会让气泡永远挂着「发送中…」）/ duplicate 不是错误（收气泡；本地没有该 messageId 就补拉一页）/
500、503 回滚 / 400 image_too_large 换短文案
- 接下行帧 `chat_duplicate`；图片一律走 REST（`WsOutbound.Chat.image` 仍无生产者）
测试：269 全绿（218 → +51）。含真实抓包的四段响应（200 / 202 / duplicate / 400 image_too_large，
且服务端文案里的 6990572 与本端 SERVER_MAX_CHARS 做成对断言）、路由阈值边界
（1194 汉字 = 3582 字节走 WS、1195 = 3585 走 REST，并直接断言阈值处真实
`WsOutbound.Chat(...)` 序列化后 ≤ 4096 字节）、归一规则、六种 ack 映射。
真机（真后端 127.0.0.1:10942）：**图片全链路通过** —— 选图 → 重编码（源 7.8 KB PNG →
1 KB JPEG，magic ffd8ffe0）→ `POST /api/v1/chat`（1558 字节体）→
`200 {"data":{"stream":true}}` → 气泡由「发送中…」归一为「来自 安卓」→ 昔涟回复**准确描述了那张图**。
另 WS 短文本路径未回归（无 POST，且 clientMsgId 被 v0.56 原样回填）。
未验证：`409 chat_busy` 与 `500` 非真实抓包（要填满主人后端的待处理队列、等于真跑 5 个回合，
判断不值得；形状与文案逐字取自后端源码，测试注释里已写明）；UI 上的 202/409 未端到端跑过；
降尺寸「减半重来」那步未在设备上跑过（测试图 64×64 只走到重编码）。
|
2026-10-04 16:57:22 +08:00 |
|
|
AskaEth
|
4c14028c70
|
fix(tools): 接上 tool_execution 三事件，并改用 id 关联工具卡
客户端此前**只映射了 `tool_execution.update`**——恰好是后端**没有生产者**的那一帧
（后端回执亦确认：`.start`/`.end` 有真实生产者，`.update` 运行期可能永不来）。
真正会发出的 `.start` / `.end` 落进 `else -> null` 被**静默丢弃**，所以
**工具执行状态从未到过界面**：工具卡能显示调用与参数，却永远不显示「执行中 / 完成 / 失败」。
后端 v0.50 已把 `tool_execution` 拆成三帧、载荷为 `{tool, phase, id?}`——刻意**不带
`index` / `streamId`**（WS bridge 注释明写「tool_execution.* 不属于某一次模型流」），
关联键是 **`id`**（与同轮 `tool_call.*` 同一个 provider 调用 id）。所以旧实现按 `index`
归属本身就是错的。
- data/ws/WsEvent.kt：三个事件类型承载 `tool` / `phase` / 可空 `id` / `delta`（仅 update）；
新增私有 `ToolExecutionData`（**无 `index`**）；三个帧名都进 `dispatchStreaming`
- ui/chat/ChatViewModel.kt：`ToolPhase { Running, Done, Error }` + `toolPhaseOf`；
`ToolCallState` 扩 `tool` 与可空 `phase`；新增两个纯函数
`toolExecutionTargetIndex` / `applyToolExecution`；三帧经既有 `isForSession` 会话闸
- ui/chat/StreamingBlocks.kt：工具卡标题与配色由 `phase` 驱动（`执行 <tool>…` /
`工具调用 · <tool>` / `工具调用失败 · <tool>`，失败用 error 色）
关联策略是「**不确定就不挂**」，绝不默认 0：`id` 非空 → 精确匹配，找不到返回 -1
（宁可不挂也不挂错）；`id` 缺失 → 仅当「恰好一张卡 id 为空」或「整个列表只有一张卡」
才挂，否则 -1。`applyToolExecution` 不建卡、不动别的卡；`tool` 空白保留已有名字、
`phase` 无法识别保留已有阶段、`delta` 为空不改输出。`.update` 那条路也实现并测了。
测试：218 全绿（194 → +24）。新增 10 条三帧解码（按真实 `toolExecutionData` 形状：
id 有/无、phase running/done/error、update 带/不带 delta、多余 `streamId` 被忽略、
旧单帧形状可容忍、会话闸）+ 14 条关联规则与 phase/name/delta 应用。
实机：只读 WS 探针抓到真实帧
`tool_execution.start {"id":"call_00_o9Q…","phase":"running","tool":"calculator"}` 与
`.end {…,"phase":"done","tool":"calculator"}`，`tool_call.*` 共享同一 id、执行帧确实
没有 `index`/`streamId`；屏幕录制抓到渲染出的「工具调用 · calculator」——工具名只可能
来自 `tool_execution.*`，故端到端成立。全程只见 `.start`/`.end`，印证 `.update` 无生产者。
未覆盖：`phase:"running"`（内置工具太快）与 `phase:"error"`（无法诱发）的瞬时态，
仅单测覆盖。
|
2026-10-04 16:28:22 +08:00 |
|
|
AskaEth
|
c09a21136c
|
feat(sessions): 会话列表用服务端标题 + 置顶 + 最后消息预览（A4/D5/B3）
列表此前显示的是本地硬生成的「会话 N」，因为后端 title 恒空。后端后来做了
「首条用户消息自动命名」+ PATCH 改名/置顶 + lastMessage 预览，本轮接入，
并把本地那套序号机器整块删掉。
- data：SessionSummaryDto 补 pinned / lastMessage（均带默认值，老快照仍能解）；
新增 UpdateSessionRequest / Response 与 @PATCH api/v1/sessions/{id}
- core/prefs：**整块退役**本地序号机器（order / KEY_ORDER / OrderSerializer /
decodeOrder / ensureOrder / 「会话 ?」）——有了服务端标题，本地序号永远不会一致，
且 id 没有序号时会渲染出字面的「会话 ?」
- 标题规则：服务端标题非空白即原样显示，否则兜底（主会话「与昔涟」/ 次级「新会话」）。
主会话刻意保留「与昔涟」而不采用服务端自己的「主会话」
- 顺序**完全信任服务端**（pinned DESC, main DESC, created_at ASC），客户端不重排；
因此置顶的次级会排在主会话之前——顺带修正 SessionDto 里「主会话恒首位」的过时注释
- 置顶：主会话与次级都可置顶（契约允许）；先就地翻转拿即时反馈 → PATCH →
成功后静默重拉（服务端才是顺序权威，快照顺带修正）→ 失败回滚并报错
- 改名：长按行打开对话框（预填当前标题 + n/80 计数），不做乐观更新（服务端会 trim 后
回写，等静默重拉取权威值）；**不提供「恢复自动命名」**——服务端无法表达（空白即 400）
- **刷新触发（前置条件，不是锦上添花）**：列表此前只在 VM 初始化 / 新建 / 删除时拉取，
所以自动标题与预览要重启 App 才可见。现改为**打开抽屉时静默刷新**，
且不闪「同步中…」横幅
- 顺带修同文件里两个既有缺陷：① **快照的指纹闸门其实没实现**（fingerprint 写了却从不
比较、clear() 是死代码）→ 现按 baseUrl+username 指纹过滤，并把 clear() 接到登出
（否则换账号后第一帧会闪上个账号的会话列表）；已实测确认指纹与写入时逐字节一致，
不会误丢老快照。② 预览剥标签时旁白与正文会粘连（看截图发现的排版瑕疵）→
标签改替成空格再折叠空白
测试：175 全绿（153 → +22）。含真实抓取响应体的 DTO 契约测试、标题兜底与预览规则的
纯函数测试、指纹闸门测试。
|
2026-10-04 13:55:52 +08:00 |
|
|
AskaEth
|
09a3222b7b
|
feat(enums): 接入 /meta/enums 权威枚举表，删掉客户端硬编码映射
客户端此前自带 platform / mood / mode 三张硬编码标签表，会与服务端漂移——
实测已经漂了：客户端把 `web` 显示成「Web」，权威表里是「网页」。
- data：MetaApi（GET /api/v1/meta/enums）+ MetaDto + MetaRepository，
经 ApiClientFactory 创建以复用既有 token / 401 处理
- domain/enums/EnumCatalog.kt：标签查找器，**不含任何硬编码兜底表**；
不在表内的取值一律原样返回（api-client §1.1 的未知值回落红线）；
platformLabelOrNull 供 deviceId 前缀这类「认识/不认识要走不同回落」的调用方用；
空 id 或空 label 一律不入表（否则角标会显示空白，或查空串凭空借到别人的标签）
- core/prefs/EnumPreferences.kt：last-good 快照，baseUrl+username 指纹闸门，
换服务器/账号即作废，登出清空
- EnumCatalogViewModel + LocalEnumCatalog：在 CyreneRoot 注入（与 LocalAppPrefs 同套路），
聊天角标与管理页共读同一份
- 删除 platformLabels / personaModeLabels / moodLabels；MessageSource 与 AdminFormat
改为查表，并保留各自原有的原样回落
为什么不留硬编码兜底表：没有登录就看不到任何消息，而权威表在登录前后即会拉取，
所以 last-good 快照几乎总是存在；留着硬编码表等于把「漂移」重新引进来，而且是无声的——
旧标签和新鲜标签长得一模一样。
不转换的：trace kind/status、memory scope、thinking.mode、WS session_busy 的 mode 集合——
它们都不在 /meta/enums 内，且原本就已按原样回落。
测试：115 全绿（88 → +27：MetaDtoRealPayload 8 / EnumCatalog 7 / EnumPrefs 3 /
MessageSource 8，AdminFormatTest 改写并 +1），其中 /meta/enums 与登录响应一样
用真实抓取的响应体做夹具。
|
2026-10-04 13:19:34 +08:00 |
|