 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
|
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 |
|
|
AskaEth
|
9f054aad28
|
fix(admin): 后台思考 conclusion 的 <p>/<action> 标记被原样显示
现象：后台思考页把服务端 conclusion 里的 Web 端标记当纯文本打印，真机截图里
能看到 `<p></p><p></p><p>亲爱的…</p>` 和 `<action>轻轻戳了戳你</action>` 这样的
原始标记，部分记录开头还有一串空 `<p></p>`。
为什么：backthink 的 conclusion 与聊天消息是同一套标记，而 AdminBackthinkScreen
只是把它拼进 body 字符串，从未解析。
改法：复用项目已有的 domain/parse/ChatContentParser.parse()（不新写正则），
在 domain/admin/AdminFormat.kt 加纯函数 conclusionParagraphs()——按
head → 正文 → tail 产出段落、丢弃无有效片段的空段落（这才是消掉空 <p></p> 的关键）；
UI 侧新增 AdminRichTextCard，Text 正常渲染，Action/Narration 走聊天页同一套
灰斜体旁白样式（对齐 MessageBubble.AnnotationLine 的既有约定）。
AdminTextCard 行为不变（表头抽成共享的 AdminCardHeader），已回访记忆页确认无回归。
测试：新增 7 例（AdminFormatTest 13→20，用真实抓取的 conclusion 做夹具，并断言
渲染模型里不残留 <p>/</p>/<action>/< 或 > 任何一项），全套 88 例全绿。
|
2026-10-04 13:02:09 +08:00 |
|
|
AskaEth
|
a7b3452e6d
|
feat(admin): 新增 C-2 管理员只读监控（概览/人格/记忆/后台思考）
侧边栏「管理员监控」进入的独立管理区 + 独立 Scaffold，四页全部只读，
不调用任何 /admin/* 写端点。
- data：AdminApi（5 条只读 GET）+ AdminDto + AdminRepository，
经 ApiClientFactory 创建以复用既有 token / 401 处理
- domain：AdminAccess.kt 为权限真源（纯函数，便于单测）；
AdminFormat.kt 把 RFC3339 与 Unix 毫秒两种时间形状分开解析
- ui：AdminHomeScreen 做成可加页的壳（加页 = AdminPage 加一条枚举），
四个子页 + 统一失败态；列表项一律 PreferenceCard + BasicComponent
- RBAC：后端契约要求客户端自行降级（api-client §2.0），按矩阵分档——
viewer 只能进概览/人格；入口禁用 + ViewModel 短路（不发请求）+
服务端 403 也渲染「无权限」态，三层 fail-closed；
任何失败都不渲染成「暂无数据」
为什么：M0–M5 + 设置页 C-1 已完成，C-2 是路线上的下一项；后端 5 个读端点
均已实现（非 501），且手机端后续要走「全功能管理」（后端工作小结 主线②，
凭据前置已完成），故管理区做成可扩展的壳而非只读死胡同。
测试：74 个单测全绿，其中新增 29 个
（AdminAccessTest 9 / AdminFormatTest 13 / AdminDtoDecodingTest 7）
|
2026-10-03 21:31:09 +08:00 |
|
|
AskaEth
|
84de51c7b7
|
feat: 初始化 Android 客户端（M0 骨架 + M1 登录 + M2 基础模块）
M0：Gradle 9.7.1 / AGP 9.2.1 / Kotlin 2.4 / Miuix 0.9.3，minSdk 33，compileSdk 37。
M1：登录页（服务器地址可配、服务端/本地错误分流、EncryptedSharedPreferences、自动登录与静默重登、401 登出）。
M2 基础模块：消息内容解析器（<p>/<action>/<narration> + 流式增量）、WebSocket 客户端、REST 数据层与分页去重。
45 个单元测试全绿，真机验证通过（登录页 + 启动图标）。
devdocs/ 收录设计文档、前后端协同事项与细化方案。
|
2026-09-08 20:40:58 +08:00 |
|