- 前端：`lib/wsParse.ts` 的 `parseBackthinkItem` 现在也读原始 `PushResult` 的 route/detail/bypassed（兼容 camelCase），与历史 DTO 路径**同名同义**（空串 → undefined、未报告的 bool 不编成 false）； Backthink 页 Notice 改为如实描述。证据＝用后端两条路径的**真实序列化**喂同一个 PushResult 做逐字段比对 - 图片上限可配：`CHAT_IMAGE_MAX_BYTES`（默认 5242880 = 与 /upload 同口径；**未配置/0/负 一律用默认**， 不存在「禁用上限」）；删掉重复的字符常量，换算只留一份 `chatImageCharsFor`；补 3 条用例 （默认值==upload 预算、配 1 MiB 真生效且只有合法那条驱动回合、非正值回落默认） - `Docs/api-reference.md`：§1 端点表按 `routes.go` **补齐**（auth refresh/logout、upload、files、三支 audio、 /admin/plugins/installed、/admin/llm/catalog、observability/logs、notifications、owner-profile、reminders）， 既有编号一律未动（保交叉引用）；两张 `historyMessage` 字段表补 `personaId`（+ `clientMsgId`）； 修正 §8.1「主人档案保存仍 501」与实现不符（已真实实现） - 复核：build/vet 绿 + gateway/config 包测试绿 + 前端 tsc 0 错 + vite build 成功 - 登记：§1 各表的编号跨表重复（不重编号以保交叉引用）；`admin_plugins.go:217` 注释写错鉴权档（未改）； §6.4 的 WS 事件帧表仍未补全
- 原状：image（base64/URL 字符串）在 API 层**无长度上限**、原样落库 ⇒ 一张 5 MiB 的图 ≈ 每页历史重传 6.7 MB - 修法：入口层（handleChat，位于 stream 分叉**之前** ⇒ 同步与 stream:true 两条路径同拦）按**字符串长度零分配**判定， 超限 → 400 `image_too_large`，文案给出上限并**指路 POST /api/v1/upload**；日志只记 session/chars/limit（不打图片内容） - 上限口径：**与 POST /upload 的 maxUploadBytes = 5 MiB 取同一个答案**（否则内联 base64 可绕开上传限制）； 字符上限 = ceil(n/3)*4 + 64（覆盖 data URI 前缀），**恰好 5 MiB 的整幅图编码后 = 6,990,508 字符，绝不误拒** - 复核：6 条用例（上限与 upload 同值、边界 ==limit 通过 / +1 拒、超限**0 个回合被驱动**、 stream:true 同样被拒、恰好等于上限逐字节到达 runner、小图行为逐字节不变）； **2 条变异反证**（忘接守卫 / 边界改 `<`）均已还原 - 实测附注：WS 侧今天**已被传输层关死**（wsReadLimit=4096，8KB chat 帧直接断连）⇒ 多 MB base64 无法经 WS 进入； 若日后放宽该上限，必须在 ws 入口补同一个校验（回报里给了精确落点） - 未做（登记）：上限暂不可配置（等 config.go 空闲）、REST 请求体仍整体读入内存（MaxBytesReader 属行为变更）、 vision 层 base64 路径无长度预检（纵深防御）、历史 base64 行需离线批处理（方案已出）
AskaEth
AskaEth
AskaEth
AskaEth