100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AskaEth	e4915a6904	docs(02): 收下后端回执十一（四点确认 + knowledge 缺陷已立案 + IM-1/U1 在实施） ... 后端会话直接写进了本机 devdocs/02（与主树共用同一份文件），这里把它落成一次提交， 免得长期挂在工作区、也便于将来对时间线。 回执十一的四点：sess-* 不加 404 例外（与我们的答复一致）；documents[].reason 他们不会擅自改文案 （要改会同时升契约并回执）；404 session_not_found 的用法确认；日期更正已互相认账。 另两条与我们相关的： - 我们登记的 knowledge 工具失败（E2E-DOC 那条，纯文本也复现）他们已按更正后的口径立案排查， 修复推库后会补一条回执（含根因文件:行）。他们同时要求「无论回合因何结束都落一条可见的 assistant 消息」，边界保留：被 interrupt 取消 / 被 stale gen 取代 / 静默内部流程仍不落库。 - IM-1（各适配器入站内联受支持格式的文件字节）与 U1（llm_usage 落库 + 只读汇总端点 GET /api/v1/admin/llm/usage，后续契约 v0.64）在实施中 —— 后者对我们只有将来做管理页时才算增量。 本次提交只增文档，无代码改动。	2026-10-04 22:01:01 +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	a84d473e2f	docs: 收下后端回执十（契约 v0.63：documents[].reason + messages 对已删会话回 404）+ 答复 sess-* 提问 + 锚点补记两条新待办	2026-10-04 21:51:08 +08:00
AskaEth	9f92a8ade5	docs(05): 恢复锚点更新 —— 记上凭据落地位置（dev-secrets.local.md，gitignore）、新 HEAD、模拟器启动参数	2026-10-04 21:50:31 +08:00
AskaEth	d2169c6174	chore(gitignore): 忽略 dev-secrets.local.md（本机开发凭据，主人授权落地但不进仓库）	2026-10-04 21:48:37 +08:00
AskaEth	92ee7fedbd	docs(05): 落「恢复锚点」（当前状态 / 已完成模块清单 / 待办 / 家务）—— 便于上下文压缩后接续	2026-10-04 21:46:56 +08:00
AskaEth	647cf47cf2	docs(05): 更正 ① W16 搜索的结论 —— 本来就是好的，先前「设备上不可用」是我的测量假象（含教训：动代码前先用像素确认症状）	2026-10-04 21:46:26 +08:00
AskaEth	3ff4f45166	docs: 更正文档里的日期标注 —— 本轮都发生在 2026-10-04 深夜，之前误写成 10-05（含后端回执九那一行）	2026-10-04 21:42:37 +08:00
AskaEth	c67aa2da48	docs(05): 存档本轮装机验收的设备证据（W18/W15/W19 通过、W16 确认不可用、四条新坑）	2026-10-04 21:41:45 +08:00
AskaEth	e8c6389fde	docs(02): 收下后端 GC 策略与回复 + 更正 knowledge 工具失败的范围（纯文本也复现）+ 一条 adb reverse 方法论	2026-10-04 21:41:20 +08:00
AskaEth	df6378395e	merge: W21 — 重试记忆加 10 分钟时间上界（多槽不会跨小时误撞旧键）	2026-10-04 21:40:23 +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	7a6f6b0863	chore: .gitignore 补 .kotlin/（Kotlin 构建产物，之前没忽略，git add -A 会误扫）	2026-10-04 21:29:14 +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	5d8ab15c0e	docs(02): 登记 unreadable 缺原因字段 + 文本层 PDF 的措辞别扭（均已如实处理，未替服务端编话）	2026-10-04 21:18:05 +08:00
AskaEth	1f9d1dde01	merge: W18 — App 内预览对非文本拒收（跟上 v0.61 的 .pdf）	2026-10-04 21:17:21 +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	020687a82b	docs(02): 收下后端回执八（v0.60 存储端点 / v0.61 PDF 文本层 / K1 API Key 落盘 / 两条行为变化）	2026-10-04 21:13:14 +08:00
AskaEth	440e441b31	merge: W17 — 重试记忆改多槽（每条失败各留自己的幂等键）	2026-10-04 21:12:19 +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	b579732db6	docs: 落 W15/W16 批次（重试复键的取舍、会话内搜索的形状）+ 六条契约口径登记	2026-10-04 20:50:23 +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	8b907036db	merge: W15 — 手动重试同一条内容时复用原幂等键（改过的内容照旧铸新键）	2026-10-04 20:28:40 +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	76d49b73d1	docs(05): 落 W13/W14 批次与实机验收、W13 的两条文档不符、W14 取字节无 logcat 的证据改法、回执七要点	2026-10-04 19:52:57 +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	9e039863fa	docs(02): 收下后端的回执七（大附件护栏修复上线、API Key 仅内存表、IM 文件边界、v0.60 预告）	2026-10-04 19:43:52 +08:00
AskaEth	9854cc477d	merge: W13 — 队列满时定位并处置那条待发气泡（pending_full / 定向 chat_busy 的 clientMsgId）	2026-10-04 19:42:49 +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	8633ec9f06	docs(05): 落 W11/W12 批次与实机验收、SAF 双扩展名 bug 的修复、GMS ANR 与 dump 重试两个新坑	2026-10-04 19:28:53 +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	a0d6e3479f	docs(02): logs REST 已接上（闭环）+ 五条契约口径建议补写 + 铸不出 viewer 账号的验收缺口	2026-10-04 19:20:15 +08:00
AskaEth	a7dbee847e	merge: W12 — 「最近日志」接上 logs REST 引导读取（补齐只显示进页面之后那段日志的缺口）	2026-10-04 19:19:18 +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	c94ea09b59	docs(02): 登记纯附件回合（Android 端首测）没有助手消息 + 两次 knowledge 工具失败	2026-10-04 19:12:52 +08:00
AskaEth	e59ef08cf9	docs(05): 落 W8–W10 批次状态、模拟器与该轮自动化的坑、契约 v0.59、附件预览欠账	2026-10-04 19:09:10 +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	2369dd2115	meta(docs): devdocs/ 纳入版本库 —— 交接与协同文档不再只存在于本机 ... 主人 2026-10-04 指示「项目仓库也可以写进去」。因此把 devdocs/ 从 .gitignore 移除并首次入库： - `05-开发进度与交接.md` —— 跨会话交接锚点：当前状态、易忘的实现约定、踩过的坑、实机验收方法 - `02-前后端协同事项.md` —— 与后端会话的**交换文档**（两边都会读写：我们登记缺口，对面写回执） - `01/03/04/06/07` + `DESIGN.md` —— 路线、客户端细化方案、构建环境、迁移说明、给后端会话的交接 **凭据扫描已过**：无账号口令、无 token/refreshToken 明文、无 API key 或私钥。 文档里只记「登录凭据不写进文档，问主人」这条口径本身。 （此前忽略它的理由已不成立：文档现在承担跨会话交接与前后端协同两件正事， 只留在本机磁盘会随机器丢失，而这批内容的价值恰恰在「后来人读得到」。）	2026-10-04 19:00:18 +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	f24877d53b	merge: W8 — 设置页「版本」行可点进「关于」页（含作者署名）	2026-10-04 18:35:11 +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