 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
|
a776e9f608
|
feat(settings): 设置页「她忙时发消息」追加第三档「并行」——忙时不打断、另起一路（chat.parallel=true）
主人要求：在既有的「追加队列 / 打断」之下再追加一档「并行」。三档语义互补——追加队列进队列等
（默认档，逐字节不变）、打断先发 interrupt 再发这条、并行不打断、另起一路同时处理。
改了什么：
- AppSettings：InterruptMode 加第三个值 Parallel(wireScope = null, wireParallel = true)，并给枚举
补出第二根线 wireParallel（wireScope 只管 interrupt 的 scope，表达不了「要声明并行」这件事）。
既有两个值的 name 与落盘键 interrupt_mode 一个字未动——改名会让已存偏好读不出来并静默回落默认档。
落盘字符串 → 档位的映射抽成顶层纯函数 toInterruptMode（AppSettings 本体要 Android + DataStore，
单测里起不来），新增的第三个名字能正确读回，未知字符串仍回落 AppendQueue（既有行为未变）。
- 判据抽成纯函数 parallelForSend(mode, busy) 与 parallelWireValue(declare)：前者与
interruptScopeForSend 共用同一个忙判据（ChatUiState.busyMode != null），只在会话正忙时为真。
规范 §2.2 没写空闲时要不要也声明——空闲时这条本来就是它自己的回合，声明与不声明在服务端是同一
件事，故取与打断同一个判据（最小惊讶：空闲时三档逐字节完全相同）。
- 两条互斥由枚举取值本身保证，不是靠约定：并行档 wireScope 是 null ⇒ 绝不发 interrupt；另外两档
wireParallel 是 false ⇒ 绝不带 parallel 键。默认档「追加队列」线上零差异由此结构性成立。
- 发送路径接线：ChatViewModel.deliver 只读一次偏好、同时喂给两个判据（读两次会在用户切档的瞬间
出现「既打断又并行」）；ChatSocket.sendChat 与 ChatRequest 各加一个 parallel 参数，false 一律
翻成整键省略——显式 false 会被序列化成 parallel:false，那是「显式否认」而不是「未声明」，
默认档就不再逐字节不变。
- 设置页：新选项标题「并行」，summary 说清后果——不打断她正在说的这一句、两路各算一遍会多花一份
算力与 token（主人裁决：峰值 token 近翻倍可接受，但用户有权知道）。UI 仍是 Miuix，与同栏另外
两条逐字同形，勾选标记位置相同。
- 分享路径同样不套用这一档偏好（W26 的 allowInterrupt 因此更名为 applySendPreference，它现在管
的是整档偏好）：分享是批量投递，逐条索要并行会被服务端 2 路额度把同一次分享劈成两种待遇，且每
条各算一遍；用户也没按过发送键说这条要并行。单张图时同样不声明，规则才能一句话说清。
为什么：主人 2026-10-05 的裁决（真两路并行）需要客户端有一个显式声明入口；W30 已备好 chat.parallel
的线上形状（默认 null = 整键省略），本次只把设置页这一档与发送路径接通，上行仍是纯增量——没选
「并行」的用户线上一个字节都不变。
验收：assembleDebug 通过；testDebugUnitTest 通过（1022 测试 / 0 失败 / 0 错误；基线 1004，新增 18：
ParallelForSendTest 13 条 + InterruptScopeTest 1 条 + InterruptModeTest 4 条）。
|
2026-10-05 09:37:26 +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
|
276b01113b
|
refactor(ws): 进程内共享一条 ChatSocket，访问 N 个会话不再留 N+2 条连接
改了什么
- AppContainer：删掉「每次调用都新建」的 createChatSocket()，改成进程内唯一的 val chatSocket
（by lazy）。三个调用方全部改取它，工厂方法一并删掉——不留「还能再造一份」的入口。
- ChatViewModel / SessionsViewModel / AdminViewModel：原本各自建一条连接，现在都改为订阅同一条。
- 连接的开与关收敛成唯一一处主人：SessionsViewModel 的登录态订阅
（LoggedIn 则 connect()、LoggedOut 则 close()）。
* ChatViewModel 不再 connect()（它随切会话就被销毁，不该掌握连接的生死）；
* AdminViewModel 不再 connect() / close()，包括原来「viewer 时关掉自己那条连接」那条分支——
这三帧服务端本就 fail-closed，本类另有逐帧角色门，断开连接多挡不掉什么，却会掐掉别的屏幕。
* AdminViewModel 登出仍然只丢日志基线（行为不变）。
- 三个 VM 的 onCleared 一律不再 close（共享连接不能被任何 VM 关闭，否则切会话 / 关管理页会把
主会话流式、抽屉未读、管理页三帧一起掐断）。
- KDoc 同步改：AppContainer（为什么可以共享 / 为什么必须唯一 / 开与关的主人是谁）、ChatSocket
（它不是某个屏幕的私有连接、谁都不许 close；events 的 replay 恒为 0 从「安全」升为「必需」）、
三个 VM 的类注释与 onCleared。
为什么行为不变
- 服务端广播、不按会话订阅：改前 N 条连接各收全部帧，改后一条连接收全部帧，每个 VM 收到的帧集合
逐帧相同——这是本次重构安全的唯一依据。isForSession、各事件分支、重连与退避逻辑、下行帧语义、
UI 一个字都没动。
- baseUrl / token 每次重连现读，connect() 幂等（wantConnection 已置位即返回），所以登出重登、
换账号都不需要重建实例。
- 连接数量：改前访问 N 个会话 = N+2 条连接、N+2 个 OkHttpClient（每个连接自带一个），改后恒为 1 条。
如实记一处非逐帧等价的细节（已核过，无功能影响）：改前每条连接各自握手，服务端每次都会回一帧
history；改后只有首次连接会收到。晚于连接建立才创建的 VM 因此少收一帧 history，而该帧对非主会话
经 historyForSession 过滤后本来就是空（只用来收掉 loading），对主会话与 REST 首屏是同一份内容的
冗余来源，且新 VM 的 pending 为空、reconcilePending 是空操作。
验证：assembleDebug + testDebugUnitTest 全绿（891 个用例，0 失败 0 错误 0 跳过）。
|
2026-10-05 08:03:09 +08:00 |
|
|
AskaEth
|
85a922c01b
|
docs(ws): 更正 SessionInterrupted.dropped 的过时 KDoc（本端全部路径下它恒为 0）
原来的注释写「当前任务取消、pending 清空，dropped 为丢弃条数」——那是 `interrupt` 只有一种形状
（等价于今天的 `scope:"all"`）时的口径。契约 v0.56 起 `scope:"current"` 只取消在跑回合、**保留**
待处理队列，该档 `dropped` 恒为 0。
而本端「追加队列」档一个 interrupt 都不发、「打断」档发的是 `current`（见 feats/W25，cfdc094），
所以 `dropped` 在客户端的全部现实路径里恒为 0 —— 「已打断，丢弃 N 条」那句话在本端根本不可达。
注释里写明这一点，免得后来人照着一句不可达的文档去实现一个用不上的计数。
只改注释，无行为变化。
|
2026-10-04 22:40:07 +08:00 |
|
|
AskaEth
|
b7ac6b8853
|
merge: W27 —— 删只被测试养的 availablePages + 图片 base64 上限公式去重 + 03 四处文档更正
|
2026-10-04 22:37:25 +08:00 |
|
|
AskaEth
|
eacc65acc9
|
fix(chat): 四件可见修复 —— 回退正文不再丢 / 错误横幅可关 / 分享不自杀 / 清两处死码
1) stream_chunk 不再被静默丢掉（整段正文丢失风险）
- ChatViewModel.onEvent 新增 WsEvent.StreamChunk 分支，把 delta 照 MessageDelta 的同一形态喂进
流式解析器。
- 依据：后端契约写明「未映射/无法确定的事件仍走 stream_chunk + stream_end（非流式回退路径）」
（Cyrene_v2/Docs/api-client.md §3.1）。原先它落到 onEvent 末尾的 else -> Unit 被静默吞掉 ——
服务端一旦走进回退路径，整段回复正文一个字都不显示，而且没有任何信号说明正文丢了。
- stream_chunk 不带 index（那是 message.start 的字段），所以不读 index；解析器与 MessageDelta
一样按需创建，按「同一个当前流」处理。
- 未改 WsEvent 的解析形状，只加消费分支。
2) 错误横幅可以关掉了（两个 dismissError 不再是死方法）
- ChatViewModel.dismissError / SessionsViewModel.dismissError 原本全仓零调用方，现各接上关闭
入口，并各补 KDoc 写明边界：清掉的是本端已经显示的那条错误，不代表服务端那边没事；不做自动
消失。
- ChatScreen.kt 的 private Banner 增加可选 onDismiss，有它时右侧挂 MiuixIcons.Basic.Close
（带 contentDescription）；只有 state.error 那条传 viewModel::dismissError，分享 / 附件 /
定位那几条如实告知保持原样（它们自己会收走）。
- SessionDrawerContent.kt 的错误行改成行内布局 + 右侧关闭按钮，样式随它已有的行（footnote2、
同一水平内边距、同款 IconButton 灰度）；新增参数 onDismissError，由 ChatHomeScreen 接
sessionsViewModel::dismissError。
- 错误内容本身、错误出现的时机、是否自动消失，一概未动。
3) 多图分享不再互相打断
- 根因：W25 把「她正忙时按发送」接到发送路径后，deliver 每次投递前都会发一条 interrupt 帧
（scope=current）；而分享 N 张图 = N 次投递，第 2 条起就把前一条刚起的回合取消掉了，
最后只有最后一张被回答。
- 改法：emitAndDeliver 增加 allowInterrupt: Boolean = true（默认值保持现状），deliver 按它决定
是否调 interruptRunningTurn()；sendShared 的两条投递都传 false。
- 只有一张图也传 false：分享是「一次把东西倒进去」的批量动作，自己打断自己一定是错的；
「分享从不打断」是一句话，「超过一张才不打断」得先解释那个分界。
- 单条发送（send）的口径一字未动。
4) 两处死代码
- 删掉 ChatViewModel.clearDraftDocuments()（复核为全仓零调用方）。没选「在输入栏加清空全部入口」：
附件芯片本来就每枚带叉、上限只有 5 枚，逐个移除已经覆盖全部场景；输入栏里再加一枚清空按钮是
噪音，而留着一个没人接的公开方法只会让人误以为它是活的。
- 删掉 ChatScreen 的 onLogout 参数（函数体内一次都没用到）与 ChatHomeScreen 的对应传参。
真正的登出路径（CyreneApp -> ChatHomeScreen -> SettingsScreen）原样可用。
验证：assembleDebug 与 testDebugUnitTest 均 BUILD SUCCESSFUL；单测 892 条、0 失败 0 错误、0 跳过
（本次未新增测试：① 的判定是 when 的一个分支、抽不出自然的纯函数，不为测试把架构拧弯）。
|
2026-10-04 22:36:47 +08:00 |
|
|
AskaEth
|
805d8b530a
|
refactor+docs(W27): 删掉只被测试养着的 AdminAccess.availablePages，让 ChatImageBudget 的公式只留一处，并就地更正 devdocs/03 四处过时表述
清理（零行为变化）
- 删 domain/admin/AdminAccess.kt 的 availablePages()：全仓（含 app/src/test）调用点 0 处 ——
main 里只有它自己的声明、测试里 2 处（AdminAccessTest 那 1 条用例一并删掉）。它早已被
ui/admin/AdminHomeScreen.kt 的做法取代：遍历 AdminPage.entries + 每行 canAccess 决定是否禁用。
- ChatImageBudget.SERVER_MAX_CHARS 原来把 base64Chars 的 ((n+2)/3)*4 又内联重写了一遍，
改为 base64Chars(SERVER_MAX_DECODED_BYTES) + PREFIX_ALLOWANCE_CHARS（一处公式、一处真相）。
代价：该常量由 const val 变 val（const 不允许调用函数）。取值逐位不变 = 6990572，由
ChatSendPolicyTest 的独立重算断言与 ChatDtoRealPayloadTest 对服务端真实文案的断言继续钉住。
文档（devdocs/03，一律删除线保留原文 + 更正括注，不动别人的回执段落）
- §4 重连补全：02/A5 的 after 正向增量已接入（loadAfter + ChatViewModel.catchUp，28c3142）。
- §4 忙碌/队列 UI 映射：客户端只发 scope:"current"，该档 dropped 恒为 0、all 从不发，
所以「已打断，丢弃 N 条」在今天的客户端里不可达。
- §5 mode 回落：mode 已落库（后端 b686d5f），MessageBubble 按 mode 分支。
- §4 打断模式：补上 W25 接线的依据 cfdc094 / feat/W25-interrupt-scope。
devdocs/05 追加 W27 小节；另记下 data/ws/WsEvent.kt:272 的同类过时 KDoc（不在本轮允许改动的
文件清单里，未动）。
验证：assembleDebug 通过；testDebugUnitTest 891 条 / 0 失败 / 0 错误（改动前 892，删掉 1 条）。
|
2026-10-04 22:35:20 +08:00 |
|
|
AskaEth
|
cfdc094c30
|
fix(chat): 设置项「她正忙时按发送」不再空转 —— 发送前按偏好决定是否先打断
设置页那个开关此前没有任何发送路径读它：interruptMode 全仓只出现在 AppSettings
（定义 / 读写）与 SettingsScreen（渲染文案），于是把它切成「打断」后行为与「追加队列」
一模一样，ChatSocket.sendInterrupt 更是零调用方（死 API）。这正是一直挂在文档
devdocs/02 协同项 A2 上的欠账（后端 v0.56 已支持 scope，客户端没接）。
现在按契约 v0.56 §3.1 接上，判据抽成与发送路由同类位置的纯函数
interruptScopeForSend(mode, busy: Boolean)：String?
1. 追加队列（默认档）⇒ 恒定返回 null，一个 interrupt 帧都不发，线上请求与今天逐字节相同；
2. 打断（wireScope = "current"）且会话正忙 ⇒ 这条消息之前先发 interrupt{scope:"current"}
（只取消在跑回合、保留待处理队列，队列里的消息按编排器续跑，一条都不丢）；
3. 打断但会话空闲 ⇒ 不发（命中空闲会话是 no-op，白发一条帧只多一次往返，还会在 logcat
里制造「这里打断过」的假象）。
「正忙」只认服务端 session_busy 帧给的 busyMode != null，不用 queueDepth——队列深度
非零不等于有回合在跑（pending_ack / pending_drain 也会动它）。
接线点在 ChatViewModel.deliver() 的通道分支之前（app/src/main/kotlin/top/yeij/cyrene/
ui/chat/ChatViewModel.kt）。放在那里而不是 emitAndDeliver 开头是刻意的：上面每一段本端
拒绝（附件超限 / 图片处理失败 / 附件上传失败 / 引用不合法）都会「回滚、什么都不发」，
先打断她的回合再什么都不发是凭空的破坏。每次投递只经过那里一次，所以一次投递最多一条
打断帧，任何后续分支与重试都不会重复发。
偏好每次发送现读（不缓存、不订阅 Flow）：「在设置页切成打断、然后立刻发的那一条」正是
本次要修的场景，缓存值要等 Flow 推到才更新，冷启动那一下必然没到——那就等于留了一个
静默不生效的窗口。读失败（IO / 损坏）回落默认档，也就是最少动作的那一档，与 AppSettings
把未知取值解成默认档是同一条纪律。
打断帧发不出去（只有「WS 未连接」一种原因）静默、不阻断本次发送：本次消息的成败与它
无关（REST 通道不看 WS 连接），且一直有既有的回执 / 回滚路径如实上报；反过来「打断失败」
没有对应得上的动作（重试等于把消息再发一遍，正是幂等键在防的事），喊一声只会误导。
于是打断没生效 = 行为退回默认档，是用户看得懂的状态，不是被藏起来的事。
测试：新增 InterruptScopeTest 8 条（两档 × 忙闲四格穷举 + 默认档零行为变化 + 偏好回落
方向），全仓 884 → 892。assembleDebug 与 testDebugUnitTest 全绿（0 失败 0 错误）。
设置页那两条文案原本就与 scope:current 的真实语义相符（「已排队的消息保留，继续依次
回答」），未改一个字。
文档：02 的 A2 状态表、05 的 A2 条目都写着「客户端尚未接入该字段」；03 里「打断模式 →
UI 限制一次只发一条」的前提（interrupt 会清空 pending）也随之失效，三处一并补记更正。
|
2026-10-04 22:29:57 +08:00 |
|
|
AskaEth
|
b5c0b13210
|
fix(chat): 「会话已删」那句解释必须由不会被销毁的那一层持有
真机验收 404 兜底时发现的真问题：**切换本身是对的，但用户看不到任何解释**。
- logcat 链路完整：`GET /sessions/web:{已删}/messages?limit=50` → `404` →（约 0.9 秒后）
`GET /sessions` → 界面切回主会话。也就是说「退回主会话 + 如实说一句」里的**前半句成了**。
- 但**后半句一个字都没显示**：那句横幅原来挂在 `ChatUiState.sessionGone` 上，而
`onSessionGone` 一被调用，`activeSessionId` 就被收敛回主会话、`ChatScreen` 的 `key` 随之变化，
承载它的那个 `ChatViewModel` 连同状态**立刻被销毁** —— 横幅来不及组合出来就没了。
（这正是「把一次性告知放在会被销毁的状态里」的经典坑，值得单记一条。）
改法：
- `ChatUiState.sessionGone` 保留，但只当**触发信号**（KDoc 已改写说明这一点）；
- 文案由 `ChatHomeScreen` 的 `remember` 持有（它活得比会话 VM 久），通过新的
`sessionNotice: String?` 参数注入 `ChatScreen`，仍然走页面上那同一排 `Banner`，
8 秒后自己消失（它描述一次刚发生的动作，不是持续状态）；
- `onSessionGone` 里**先**立起告知、**再**刷新列表——顺序反了同样什么都看不到。
验证：装机复测通过，红字横幅如期出现在主会话页顶部
（证据 `app/build/e2e-shots/w7-gone-2.png`），logcat 链路 404 → `GET /sessions` 完整。
assembleDebug 与 testDebugUnitTest 全绿（884 测试 / 0 失败，与改动前同数：本次只动了接线与文案，
没有可新增的纯函数）。
|
2026-10-04 22:20:59 +08:00 |
|
|
AskaEth
|
1794e53d1c
|
merge: W24 —— 编辑弹层只显示纯文本（原文含标记时如实告知会被替换，绝不静默丢旁白）
|
2026-10-04 22:08:08 +08:00 |
|
|
AskaEth
|
2d382b11cd
|
merge: W23 —— 接入契约 v0.63 的 documents[].reason（只在下发时原样显示，不做整句判断）
|
2026-10-04 22:08:06 +08:00 |
|
|
AskaEth
|
66c2291312
|
feat(chat): 编辑框只显示纯文本 —— 真有标记时才剥，且弹层明说会替换掉什么
主人拍板：编辑单条消息时输入框里只放纯文本，不再让用户对着 <p> / <action> / <narration> 改字。
红线是「不许静默丢东西」，所以这次不是「把标记一剥了事」：
- 新增纯 Kotlin 模块 domain/chat/MessageEditText.kt（无 Android / Compose 依赖）。
原文不含已知标签时逐字节恒等：不 trim、不折叠连续空行、不换换行符；含标签时用
domain/parse（项目里唯一的解析器，不另写正则，免得两套口径分叉）按原始片段顺序拼出可见纯文本，
正文与旁白/动作一并保留，气泡之间空一行；一个气泡都解析不出就回落成原文（宁可不剥）。
hasMarkup 只在「保存真的会替换掉什么」时为 true。
- MessageActionState.Edit 新增 markupReplaced；startEdit 只算一次 editableMessageOf
（不放进 state.update 的 lambda 里），draft 拿纯文本、markupReplaced 拿原文带不带标记。
- MessageEditDialog：markupReplaced 为 true 时在计数行下方多一行小字，写明「保存后这条消息只剩
你写的这段文字，原来的旁白与动作会被替换掉」；为 false 时一行都不多显示。计数与保存禁用逻辑不变。
- 保存提交的就是 draft 本身，不把标记猜着装回去：任何回填都要先猜「旁白该插回哪一句之间」，
猜错就是静默移动她说过的话，用户还看不出发生了什么（理由写在 submitEdit 与弹层的 KDoc 里）。
- 新增 MessageEditTextTest（21 例）：纯文本恒等（空串、首尾空白、连续三个换行、CRLF、
以及 1 < 2 / <div> / <P> / <p2> 这类「有尖括号但不是标记」的普通文本）、线上真实标记串、
纯旁白、带属性的 p 标签、head/tail 旁白的先后顺序、气泡间只空一行、畸形未闭合不丢字。
为什么这仍然值得做：主会话 64 条 user 消息全是纯文本，所以对今天的真实数据这是一条恒等变换——
它是防御性口径，不是修一个正在发生的 bug；也正因如此，纯文本路径必须逐字节不变。
|
2026-10-04 22:07:40 +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
|
e5fa1b871f
|
接入契约 v0.63 的 documents[].reason：把「读不到的原因」原样送到附件预览弹层
后端 902b6ee / 契约 v0.63 给 historyMessage.documents[] 的元素加了可选字段 reason：
只在 status == "unreadable" 时下发（Go omitempty，extracted 时整个键缺席），内容与后端
注入模型清单里的那 10 条是同一份字符串，最长的一条 40+ 字。
改了什么
- DocumentRefDto 加 reason: String? = null。documents[] 在 WS 握手 history、
message_persisted、GET /messages 三处共用这一个 DTO，所以一处解析三条路全覆盖。
KDoc 写明三条口径：可选、只在 unreadable 时下发、是后端原话所以客户端原样显示，
且绝不做整句相等判断（需要分支只允许用稳定子串）。
- DocumentChipModel 加 reason，由 DocumentChips.of(ref) 取 ref.reason 去掉首尾空白后
非空才留，否则归一成 null——一句空话会顶掉弹层里的通用说明，比没有更坏。
芯片外观一个字没改：detail / statusLabel 保持现状（unreadable 仍显示「读不到」）。
理由：那句话太长，塞进一行芯片只会被 Ellipsis 切掉半句，比不显示更糟。
- DocumentPreviewGate.plan 增加 reason 参数：非空白时直接作为正文区那句说明原样返回
（NotText(reason)），压过本端按 mime / 扩展名的裁决；DocumentTarget.previewPlan 顺着
chips.reason 把它带进裁决。预览弹层本身一行代码都没改——它渲染的就是 plan.message
那句话，所以 reason 从 DTO 到用户看见的那句话整条链路上没有任何改写或截断。
- 配套单测 17 条。
为什么这么改
- 服务端那句原因已经断言「无法抽取正文」，它比本端按类型编的通用说明（只知道类型、
不知道到底为什么）准确；替它改写、归纳或截断就是丢掉服务端唯一一次说清原因的机会。
- 它也不该与正文并存：服务端说正文抽不出来，本端再把字节当 UTF-8 渲染，产出的正是
正文闸要消灭的「看着像文件坏了」。
- reason 缺席时（契约 v0.63 之前的历史消息）产出与改之前逐字相同：兜底那句话、判据、
文案全都不动。
测试（新增 17 条）
- DocumentDtoTest +5：unreadable 带 reason 逐字解出；extracted 元素没有该键 -> null；
v0.62 风格的缺键载荷 -> null（不解码失败、不替服务端编一句话）；清单外的未知分类原样
保留；显式 null -> null。
- DocumentChipTest +5：reason 带进模型；句中标点与换行原样、只去首尾空白；空白串 ->
null；绝不进芯片副行（detail 逐字不变）；待发附件恒为 null。
- DocumentPreviewTest +7：reason 逐字成为正文区那句话（含未知分类，不丢不改不换兜底）；
只 trim 一次再原样显示；缺席时与改前逐字相同（拿 refusalMessage 对比）；
空白 reason 不改任何行为；text mime + reason 不再假装有正文。
- assembleDebug 通过；testDebugUnitTest 848 个测试 0 失败 0 错误 0 跳过。
已知代价（已写进 KDoc，供人拍板）
服务端判为读不到、但字节其实下得动的附件（例如超限的纯文本）会失去 App 内预览，
「用其它应用打开」与「保存到下载目录」两条出口照旧完整可用——与「未知 mime 判为非文本」
是同一笔不对称账。
|
2026-10-04 21:57:14 +08:00 |
|
|
AskaEth
|
8938fffd08
|
feat(chat): 重试记忆的槽加 10 分钟时间上界 —— 别把用户新打的同内容当成重试
多槽让失败记录跨很多次发送存活，于是开了个单槽时代没有的窗口：用户几小时前失败过一句
「你好」，之后新打一遍「你好」（心里当的是一条新消息），指纹却与那条旧记录一字不差，
keyFor 命中旧键 ⇒ 服务端回 duplicate ⇒ 这条新消息根本不发出去，屏幕上看着像「按了没反应」。
给每个槽加一道时间上界，窗口就被限死在 10 分钟内；而「刚失败完，用户马上再按一次发送」
这个真正需要幂等的场景一秒都没被削掉。
- RetryKeyMemory: 新增公开常量 SLOT_TTL_MILLIS = 10 分钟（测试拿它做断言，不硬编码）；
RetryKeySlot 增 atMillis；remember(fingerprint, localId, atMillis) 与
keyFor(fingerprint, nowMillis, mint) 都在入口先按时间淘汰过期槽、再做自己那件事，
写入时最后才看条数上限（过期槽不占 8 条的额度）；同指纹重复失败更新键与时刻而不是留两条；
forget(localId) 与时间无关，签名与行为不变；FIFO 上限 8 与 TTL 两条规则同时生效。
- 边界口径：正好等于 TTL 不算过期（判据是 now - atMillis > TTL，严格大于），理由写在类注释里，
测试把它钉住。
- ChatViewModel: 只改两个调用点，喂 System.currentTimeMillis()（emitAndDeliver 的 keyFor、
rememberRetryKey 的 remember；forget 的三处不动），并按新语义更新相关 KDoc。
- RetryKeyMemoryTest: 既有用例补上时刻；新增 7 条覆盖「过期槽不复用且被淘汰」「TTL 边界」
「remember 刷新时间戳」「过期的 A 不影响新鲜的 B」「TTL 先于 FIFO 上限生效」。
|
2026-10-04 21:37:45 +08:00 |
|
|
AskaEth
|
ea16f48be2
|
merge: W19 — 单条消息的编辑与删除（D3）
|
2026-10-04 21:28:22 +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
|
48e41886ba
|
feat(documents): App 内预览对非文本拒收 —— 跟上 v0.61 的 .pdf
后端 v0.61 把文档白名单 22 → 23 项（新增 .pdf）并改成（扩展名, 字节嗅探）成对裁决，
读侧 MIME 如实下发 application/pdf。而 W11 的附件预览是把字节当 UTF-8 文本渲染的
（那时白名单里除 .pdf 外全是文本类）⇒ 一旦点开别的端发来的 PDF 附件，预览就是一整屏
二进制乱码，像文件坏了。这次堵的是这个兼容洞，不是新功能。
- 选文件器加 application/pdf：原先刻意不列（那时必被后端 415 拒），现在 PDF 在选择器里
不该是灰的，服务端收得下。
- 新增 DocumentPreviewGate（纯函数）：mime 非空时只看服务端那次字节嗅探（以 text/ 开头
判为文本，其余一律非文本，未知 mime 也判非文本——两侧代价不对称，误判成文本正是本闸
要消灭的乱码）；mime 缺失/空白时按扩展名兜底（白名单里只有 .pdf 是非文本），这条兜底
服务的是待发附件（它只有本地 URI 与显示名）。大小写不敏感并剥掉 ; charset 参数。
- 弹层新增 plan 参数：判为非文本时正文区留空、只留一句人话并指路两条出口——弹层照常打开，
文件名/体积/字数/状态与两条出口一个不少，也绝不假装加载失败（字节其实是取回来的，
只是本端不渲染它）。
- 两条出口刻意未动：打开用 DTO 的 mime（PDF 就该交给 PDF 阅读器，不用通配符），保存继续
传 */*（W11 实测结论：SAF 会按 mime 给文件名补扩展名）。
- 测试 766 → 775（DocumentPreviewTest 新增 9 条：闸的判定矩阵、扩展名兜底与大小写、
未知 mime 拒收、待发附件接线、以及 PDF 的打开类型不是通配符）。
未做（缺口留给主代理登记 02）：DTO 只有 status=unreadable，没有服务端那句原因文案
（含「图片型/无文本层 PDF，需要 OCR」）⇒ 客户端沿用既有通用文案「读不到」，
不自己拼一句假装是服务端说的。
|
2026-10-04 21:16:29 +08:00 |
|
|
AskaEth
|
d3fc0c8005
|
feat(chat): 重试记忆改多槽 —— 每条失败各留自己的幂等键
RetryKeyMemory 从单槽改成多槽（slots: List<RetryKeySlot>，上限 MAX_SLOTS = 8，FIFO 淘汰最旧）。
单槽只记得最近一次失败那条，而用户的重试顺序不必和失败顺序一致：他重试 A 又失败、再回头去重试
更早失败的 B 时，B 的槽早被顶掉，那次重发只能铸新键 —— 而 B 那次失败完全可能是「服务端已经收下、
客户端没看见」，于是又落成第二条消息，正是本机制要消灭的重复。
- remember：同指纹先摘掉旧的、再追加到末尾（同一条又失败一次是更新它的键，不是并列两条），
超过上限从头部丢最旧的，且刚写进去的那条一定留得住。
- forget：按 localId 清；一条都对不上就原样返回同一个实例；同 localId 万一有多条则一并清掉。
- keyFor：命中只消费那一条、其余槽全部保留；未命中铸新键且一条槽也不清 —— 单槽时代「未命中也要
清空」在多槽下会把别的失败记录一起抹掉，这条已显式写进 KDoc 以防后人照着旧注释改回去。
- ChatViewModel：代码逻辑一个字节没动（三个调用点的签名都没变），只把提到「单槽」「下一次发送就
被消费」的 KDoc 改成与新实现一致；值比较指纹、正文不归一、晚到的 message_persisted 刻意不清键
这几条 W15 纪律原样保留。
- 测试：RetryKeyMemoryTest 由 10 条重写为 16 条。删掉「未命中即清空记忆」那两条旧断言（新语义下
不再成立），新增：两条失败各自原样重试都落回自己的键（两种重试顺序各一条）、重试 A 不抹掉 B 的槽、
同指纹重复 remember 只留一条且键是最新的、超上限 FIFO 淘汰最旧且刚写的仍在、未命中时全部槽保留、
命中消费后其余槽保留。
验证：assembleDebug 与 testDebugUnitTest 均通过（--rerun-tasks 全量重跑）：760 → 766 测试 / 0 失败 / 0 错误。
|
2026-10-04 21:11:45 +08:00 |
|
|
AskaEth
|
46ac15a538
|
merge: W16 — 会话内消息搜索（顶栏入口 + 搜索面板 + 点结果定位）
|
2026-10-04 20:45:09 +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
|
af11a94614
|
fix(chat): 手动重试同一条内容时复用原幂等键，改过的内容照旧铸新键
W13 顺手查出的「文档与实现不符」：PendingMessage 的 KDoc 一直写着「重试复用同一个
localId」，而 emitAndDeliver 每次发送都新铸 localId —— 若某次失败其实是「服务端已经收下、
客户端判成失败」（队列满 / 超时 / 回执丢失），用户手动重试就会铸新键、被服务端当成第二条
消息落库，用户看到重复。这正是幂等键（契约 v0.56 §3.13 / 协同 G4）要防的事。
- 新增 domain/chat/MessageFingerprint.kt：正文 + 图片本地 URI + 附件本地 URI 的内容指纹。
用纯值相等而不是哈希（摘要碰撞会让两条不同消息共用一个键，后一条被服务端判重丢掉），
正文一个字都不归一（只改一个空白字符也算改过 —— 归一正是会把两条真实消息并成一条的操作）。
附件只看本地引用：displayName / sizeBytes 是元数据，同一份文件两次查询之间可能一次报得出
一次报不出。
- 新增 domain/chat/RetryKeyMemory.kt：单槽重试记忆，三个纯函数（remember / keyFor / forget）
加一个判定结果类型。remember 只在回滚时调用；keyFor 是唯一的消费点，指纹相等即复用、
不等则铸新键（两支架都消费掉记录）；forget 按 localId 清，避免两条同时在飞时互相踩。
- ChatViewModel：所有回滚路径（发送失败、队列满被拒、附件与图片上传失败、图片处理失败、
附件超限……）本来就汇到一个 rollback，现在在那里按指纹记下那条的键；队列满判定的 Rollback
档同样记、Adopt 档清。emitAndDeliver 改用 keyFor 取键。完成回执与 duplicate / 收编按
localId 清（正常那一路在发送时已消费，这几步是兜底）。落库消息到达时刻意不清：一条晚到的
message_persisted 恰恰是「服务端其实收下了」的证据，留着键才能让重试真正幂等。
- duplicate 路径复用既有 alignDuplicate / applyQueueFull 的 Adopt 档，没有另造对齐逻辑。
- 测试 706 → 729（+23，0 失败）：指纹 13 条（正文空白 / 换图 / 增删与换序附件 / 元数据不算
内容 / 快照语义），重试记忆 10 条（复用只在指纹相等时发生、用掉即消费、编辑后不再复用、
forget 只清得动那一条、以及 duplicate 收口的端到端那条）。
|
2026-10-04 20:27:00 +08:00 |
|
|
AskaEth
|
f10984622c
|
merge: W14 — 点气泡里的图片进全屏查看，并接上「用其它应用打开 / 保存到下载目录」
|
2026-10-04 19:48:52 +08:00 |
|
|
AskaEth
|
557ef3f524
|
feat(chat): 点气泡里的图片进全屏查看，并接上「用其它应用打开 / 保存到下载目录」
气泡里的图以前点了没有任何反应。现在点图进一个铺满全屏的弹层：fit-center 渲染、双指捏合
缩放（以双指中点为不动点）与单指拖动平移、双击在 1x 与 2x 之间切换（以双击点为不动点）。
位移与缩放全部按内容边界钳制——fit 态下拖不动（内容没超出容器）、放大后拖不到露出空白、
缩放恒在 1x..3x（下界比任务书的 0.5x 更紧：1x 就是「整张图刚好放得下」，再缩只是变小加留白）。
双击或关闭即复位（缩放状态活在弹层的组合里）。退出有右上角关闭按钮与系统返回键。
弹层底部两条出口与 W11 的附件预览同源，缓存与落盘复用 DocumentCache：图片也落在
cacheDir/documents/ 下，所以 FileProvider 的暴露面一个字节都没变（file_paths.xml 只改了注释，
没有新增暴露路径）。
- 用其它应用打开：声明图片自己的 mime（字节嗅探优先，其次平台声明的 image/ 前缀、名字扩展名，
兜底 image 通配），经 FileProvider 交出去并带 FLAG_GRANT_READ_URI_PERMISSION；系统里没有
应用能开时如实说一句并指路保存，绝不静默失败。
- 保存到下载目录：CreateDocument 一律传通配类型，否则 SAF 会按具体 mime 给文件名补扩展名
（W11 实机抓到的 .md 变 .md.txt 那个坑；图片这边同样会变成 x.jpg.png）。
字节来源分三条，判定只发生在一处（ImageSource.of）：服务端能力 URL（GET /api/v1/files/{name}，
读侧免鉴权，所以用一条裸 OkHttp 客户端，而不是挂了 AuthInterceptor 的那条链——把 token 发给
一个免鉴权端点只多一个泄漏面）、内联 data: URI（字节就在字符串里，不联网）、本地 content 或
file 协议 URI（现读并拷进缓存，因此自己刚发的那张本地图也能交给别的 App）。
缓存名从服务端 URL 推，但要先过安全闸：单段、非 . / ..、不含分隔符与 NUL、不含百分号、扩展名
在图片白名单里；任何一条不满足就回落到按字节内容寻址——绝不拿一个不可信的名字拼路径。
加载态 / 失败态 / 就绪三者分明：取字节失败给一句话加一个重试入口；字节拿到了但解码不出来
（例如服务端被代理换成了 HTML 错误页）另给一句话，绝不画成一张空白图。重试把两条路都重来一遍。
测试 634 到 676（+42）：来源判定、缓存名的安全闸、字节嗅探、打开与保存的类型选择、失败文案、
缩放平移的全部数学，以及图片缓存层的命中 / 回落 / 失败不留残留文件 / 真的走一次本地 HTTP
（JDK 自带的 HttpServer，验 200 / 404 / 0 字节三种响应）。纯装配部分（Dialog、手势识别、
Intent 投递、SAF 落盘）没有单测，留给实机验收。
|
2026-10-04 19:48:18 +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
|
ffa7ed2661
|
fix(chat): 保存附件时不要被 SAF 补成双扩展名
实机复现（2026-10-05）：把服务端附件 `809320…e.md` 保存到下载目录，落盘成了
`809320…e.md.txt` —— 因为 `CreateDocument` 传的是服务端**字节嗅探所得的基类型**
（`.md` 也会报 `text/plain`），而 SAF 的 Downloads provider 会按该 mime 给文件名**补扩展名**。
改为传 `*/*`：没有可补的扩展名，原扩展名因此保真。
**「用其它应用打开」那条路刻意不改** —— 那里要的正是「能读懂这段内容的类型」，照旧用嗅探所得的 mime。
实机复核：同一枚附件保存后落盘为 `809320…e.md`（95 字节，与源一致），不再出现 `.md.txt`。
|
2026-10-04 19:27:53 +08:00 |
|
|
AskaEth
|
60b0eacafd
|
merge: W11 — 附件芯片可点开预览 + 「用其它应用打开 / 保存到下载目录」两条出口（FileProvider）
|
2026-10-04 19:22:25 +08:00 |
|
|
AskaEth
|
27b6910009
|
feat(chat): 附件芯片可点开预览，并给「用其它应用打开 / 保存到下载目录」两条出口
点一枚附件芯片此前完全没有反应。现在点它会开一个 App 内预览弹层，弹层里再给两条出口。
- FileProvider（authority = ${applicationId}.fileprovider，res/xml/file_paths.xml 只暴露
cacheDir/documents/）：把 file:// 交给别的 App 在 API 24+ 会抛 FileUriExposedException，
必须走 content://；因此 cacheDir 下真正要交出去的那一层才被开出来。
- 新增 data/repository/DocumentCache.kt：缓存路径推导 / 命中判定 / 原子落盘是可单测的纯逻辑；
DocumentCacheStore 把「服务端按存储名下载」与「本地待发附件」两条来源汇成同一份文件 + 字节。
服务端存储名是内容寻址（sha256[:32]+ext）且读侧响应 immutable，所以命中即永不失效、命中时
一个请求都不发；先写 .part 再改名、失败删干净——半截文件被下一次「命中」当成完整内容，
是最坏的一种静默错误。
- 新增 domain/chat/DocumentPreview.kt（纯逻辑）：截断（首 256 KB 或 5000 行，先到者为准；
字节切点不切坏多字节 UTF-8）、正文分块（200 行一块）、来源判定（服务端 vs 本地，只有一处）、
打开用的 MIME（只用 DTO 里字节嗅探所得的 mime，绝不按扩展名猜）、「没有 App 能开」的裁决与
文案、取字节失败的分类文案。
- 新增 ui/chat/DocumentPreviewDialog.kt：Compose Dialog + Miuix 内容。正文用 LazyColumn 分块渲染
（5000 行不塞进单个 Text），每块各自 SelectionContainer；加载态与失败态分明（失败给重试，
绝不渲染成空文件）；截断明写「只显示前 N，完整内容请用…」，不静默截断；复用 DocumentChips
显示类型/体积/字数/状态，不另写一套标签；status 为 unreadable 不挡预览（那是模型读不到，
文件本体一直在）。
- ui/chat/MessageBubble.kt：芯片整枚可点（点击区是那枚芯片本身，不是里面的两行文字），
并带 contentDescription「查看附件 <name>」。
- ui/chat/ChatScreen.kt：预览状态 + 取字节 + SAF 保存 + ACTION_VIEW 打开。没有 App 能开时
如实告知并指路保存，绝不静默失败。
契约缺口（需登记 02）：服务端按内容寻址落盘，DTO 里没有原始文件名，保存到下载目录只能用
<32hex>.<ext>——弹层里已把这一点写在界面上，没有替用户编一个假名字。
测试 567 → 610（+29 DocumentPreviewTest / +14 DocumentCacheTest），0 失败 0 错误。
|
2026-10-04 19:21:31 +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
|
ca5596a732
|
fix(chat): 附件芯片改换行排布 —— 多附件不再被裁到屏幕外
主人 2026-10-04 在主会话里发现「用户消息显示有问题」：带 2~3 个附件的用户消息里，
第一枚芯片就吃掉了整排——服务端存储名是 32 位十六进制 + 扩展名（如 `36a4aba0…5524808.txt`），
一枚约 267dp，而芯片排是「横向可滚的单行 + `widthIn(max = 320.dp)`」，于是第二枚只剩一条边
露在屏幕外。看的人不知道还有别的附件，也看不出那一行可以滚。
改为 `FlowRow` 换行排布（用户消息整排贴右 `alignEnd`），N 枚芯片全部可见；代价是 5 枚会占
2~3 行——比「藏起来」值。去掉随之失效的 `CHIP_ROW_MAX_WIDTH` 与两个 import，
并同步 `ChatScreen` 里待发芯片排的注释（同一处行为）。
实机复核：主会话那条三附件消息现在渲染为三行，三枚芯片与各自的
「TXT · 4 B · 4 字 · 已读入」全部可见（截图 `app/build/e2e-shots/chips-after.png`）。
|
2026-10-04 19:08:26 +08:00 |
|
|
AskaEth
|
29733914a4
|
docs(documents): 契约 v0.59 已发布 —— 更正 W6 那批「未发布/待发布」的过时注释
Cyrene_v2/Docs/api-client.md 已发布 v0.59（§1.2「文档存储与摄取契约」+ 端点表 16/17），
而 W6 那批文件的 KDoc 仍写着「契约尚未发布 / 待发布」，会误导后来人以为形状没有契约背书。
已逐条核对：我们实现的形状与已发布契约**完全一致** —— multipart 部件名 `file`、
201 首次 / 200 + `deduped:true` 去重、单文件 20 MiB、单回合 ≤5 条、上行只收 `name`、
`url` 是相对路径、`mime` 是嗅探基类型、`documents` 数组含 `chars`/`truncated`/`status`、
0 个附件时该键省略、4 个错误码。白名单在契约里也已更正为 22 项（与代码一致）。
纯注释更正，零行为变更。
|
2026-10-04 18:53:10 +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
|
a6b4bae2a0
|
merge: W4 — 概览页「按路径」分组折叠（可读性）
|
2026-10-04 18:09:18 +08:00 |
|
|
AskaEth
|
a80dac7a7e
|
merge: W6 — 文档进对话数据层（/documents + chat.documents，v0.59 形状）
|
2026-10-04 18:08:20 +08:00 |
|
|
AskaEth
|
f91a8558ea
|
feat(admin): 概览「按路径」改成分组可折叠列表 —— 26 条路径不再挤成一行
`perPath`（真实响应 26 条）此前被 `formatCounts` 压成一行右对齐文本，手机上极密。
本次只改呈现层，取数（DTO / Retrofit / ViewModel）一字未动。
- domain/admin/AdminPathStats.kt（新增，纯函数）：分组键 = **剥掉 `/api/v1` 后的首段**
（`/api/v1/admin/llm/catalog` → `/admin`，`/sw.js` → `/sw.js`，`/` → `/`）。
规则是纯字符串推导、**没有任何路径清单**：服务端加路由不用改客户端
（`/api/v1/quantum/*` 自动成 `/quantum` 组）；逐段比较，`/api/v1x/foo` 不会被误剥成 `/x`。
剥离只作用于分组键，行里显示的仍是完整路径。
排序：组按命中次数倒序、组内同样倒序，**两处同数都按路径升序**——指标页每次刷新都会重排，
没有稳定次序读者就跟丢了。`hits`（次数）与 `pathCount`（条数）分开，是组头的两个数。
长路径（段数 > 4）展示时折叠中间段、保留尾部 3 段：`…/admin/observability/metrics`；
尾部才是区分同类路径的部分，整串在手机上会被尾部省略号吃掉、两条路径就长得一样了。
- ui/admin/AdminOverviewScreen.kt：「按路径」从 `countRows` 里挪出来单独成块——
区块标题给「26 条 · 326 次」，卡片内一行一组，组头「N 条 · M 次」+ 可旋转箭头，
整行可点即展开/收起；组内一行一条路径，右侧计数右对齐、路径等宽字体 + 中间省略。
**条数 > 4 的组默认收起**（真实数据里 15 条 admin 路径收成一行组头），小分组默认展开省一次点击；
折叠状态只记**用户动过的组**（`remember { mutableStateMapOf() }`，放在 LazyColumn 之外），
刷新拿到新数据不会被上一轮点按锁死。
只用 Miuix 现成组件（`PreferenceCard` + `BasicComponent` + `HorizontalDivider` +
`MiuixIcons.ChevronForward` 旋转 90°），**没有自造折叠控件**；路径行用内容重载自己画 Text
才能拿到 `maxLines = 1` + `MiddleEllipsis`（收 `String` 的那个重载只会尾部省略）。
失败态不变：`metrics` 缺席时整块不渲染（上面那张「指标不可用」卡已经说明了原因），
只有 `perPath` **请求成功且为空**时才给「暂无路径统计」。
测试：353 → 370 全绿（+17，AdminPathStatsTest）：空输入 / 单条（不产生组头）/ 真实 26 条 →
10 组且总次数 326 = 同一份真实响应里的 `totalRequests`（分组不吞路径也不重算次数）/
未知前缀自动成组 / 基址逐段剥离的边界（`/api/v1x/foo`、基址本身）/ 组与组内的排序与并列次序 /
长路径折叠（两条兄弟路径折叠后仍不同）/ 折叠默认值的阈值边界（4 条展开、5 条收起）/
显式切换双向覆盖默认。
未验证（无模拟器、也不许碰 adb，只有构建 + 单测）：
- 观感（组头取 `primary`、路径等宽字号取 `footnote1`、子行缩进 12dp、箭头旋转）**没有截图**，
取舍待主人拍板；
- `BasicComponent` 对长路径会不会折行没有实机确认，所以路径文本额外做了「段级中间折叠」，
不依赖库的省略行为；
- 深色模式未单独验证，颜色全部取自 `MiuixTheme.colorScheme`（与页面其它卡片同源）。
|
2026-10-04 18:07:22 +08:00 |
|
|
AskaEth
|
557cdb213d
|
merge: W5 — 新建会话时选角色（POST /sessions {personaId}）
|
2026-10-04 18:07:03 +08:00 |
|
|
AskaEth
|
095d6e781e
|
feat(data,domain): 文档进对话数据层（v0.59 待发布形状 + 该不该走文件判定）
契约 v0.59 尚未发布（api-client.md 最新仍是 v0.58），形状依据
devdocs/02 回执五「契约形状修正」，并用后端已落库切片逐字段核对：
407c934（S1 存储端点）、a4789ec（S3-B 网关入口）、5b2b385（S3.5 多值化）。
新增：
- data/api/DocumentsApi.kt：POST /api/v1/documents（multipart 字段 file）、
GET /api/v1/documents/{name}（Bearer owner|admin；@Streaming 取字节）
- data/api/dto/DocumentDto.kt：文档形状的唯一落点（v0.59 若不同只改这里）
- data/repository/DocumentRepository.kt：200 + deduped:true 当成功；url 是相对
路径故不做图片那套绝对化校验；不做本地白名单/大小上限（服务端才是裁决者）
- domain/chat/DocumentDelivery.kt：该不该走文件的判定 + chat.documents 载荷构造
- domain/chat/DocumentStatus.kt / DocumentFailure.kt：状态与四个错误码的可分支映射
改动：
- ChatDto.ChatRequest 增 documents（默认空列表 ⇒ 旧请求逐字节不变，有字面量钉子）
- MessageDto.HistoryMessageDto 增 documents（缺键与空数组都解成空列表，覆盖
后端「0 个」尚未定死的两种形状；WS message_persisted / history 回放共用该 DTO）
- ChatSendRouting.channelFor 增 hasDocuments（默认 false）：带附件强制 REST，
因为 WS 帧 4096 字节硬上限超限是直接断连，且文档一律走 REST
为什么不做 UI/VM：UI 与 ViewModel 文件由并行的分享入口模块占用，接线由主代理统一做。
测试：353 → 413（+60：DTO 12 / Repository 17 / Delivery 21 / Failure 10），
assembleDebug 与 testDebugUnitTest 均通过。
|
2026-10-04 18:06:27 +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 |
|