57bf942474
feat(gui): 注入改 SendInput（默认）+ 用户操作时暂缓；拆解 Coopanion 桌宠动作系统
...
## 拆解 Coopanion（用户指出的参考项目）
新增 DESKTOP-PET-NOTES.md，记录 Pal-AI-Lab/Coopanion 的桌宠动作系统
（packages/cortico-world-desktop-pet）：
· 4 个工具：pet_say(气泡说话,可夹带动作标记) / pet_ask(提问,异步回答) /
pet_walk_to(走到 0-1 比例或 left/center/right/cursor,含走到鼠标位置) /
pet_act(只做动作; sit/sleep 是持续态)
· 动作词表 VOCAB：10 个表情 + 13 个动作，每个词多个中文别名，
英文 id 与中文别名进同一张 Map；未知词丢弃而非报错
· 脚本标记：【词,词】= 先做动作再换新气泡；<词> = 打字到那里时做、不换气泡。
让文字与动作在时间轴上对齐 —— 实现成本低但表现力强
· 设计要点：身体是 agent 唯一可见输出通道（用户看不见消息正文）；
互动事件不单独唤醒模型，跟着下批事件到
可借鉴（已写入文档待办）：姿态表达状态、动作与文字对齐、持续态、
动作解析容错、待机自主行为。不建议照搬：桌宠承载全部对话输出、ASR、戳摸甩。
## 注入层改 SendInput（参考它的实现）
原 PostMessage 路径只能操作原生 Win32 程序 —— Chromium/Electron 自绘界面
与游戏会忽略合成消息。这不是「平台硬限制」，是所选 API 的限制。
Coopanion 用 SendInput 注入系统输入队列，可靠性高得多。
新增三档模式 gui-prefs.deviceBridge.agentCursor：
sendinput（默认） SendInput，可靠；会动真光标，故先等用户停手
overlay PostMessage，不动用户鼠标；只能操作原生程序
real 保留旧代码路径
另有 deferMs：用户活动时最多等多久（默认 3000，上限 10000）
★ SendInput 绝对坐标是 0–65535 归一化值，不是像素。按虚拟桌面归一化
并带 MOUSEEVENTV_VIRTUALDESK，多屏下也正确（Coopanion 只按主屏归一化）。
★ 文本用 KEYEVENTF.UNICODE 逐字符发，不受键盘布局与输入法影响（比 WM_CHAR 可靠）。
## 修「用户活动感知」把自己也算进去的 bug
GetLastInputInfo 是**全局**的 —— agent 自己的 SendInput 也被算作「用户输入」。
实测：deferMs 设 0 仍被暂缓，回执写「开始时空闲仅 0ms」，即上一条命令的
注入刚把 idleMs 清零。若不排除自身注入，会永远处于「用户正在操作」状态。
按 Coopanion 的三重判定修正：
1. ownTick 自己最后一次注入时刻，之后 40ms 内的输入忽略
2. ownCursor 自己放下的光标位置，偏离 >2px 说明是用户动的
3. 无符号差值 GetTickCount 每 2^32ms 回绕，必须按无符号比较
## 修同一条命令被执行两遍
sendinput 分支把逻辑包进 runAction 箭头函数，里面的 return 只退出它自己，
于是执行完继续 fall through 到旧 real 路径。实测 8 条命令回了 16 个
cmd_result，且真光标被额外抢一次。补上外层 return。
## 判据
computeruse.test.mjs 47 条（npm test 共 131 条全绿），新增 4 条钉住本轮
踩过的坑，均做变异验证：
· 三档模式存在（overlay/real 只在条件里，不能要求赋值形式）
· 用户活动排除自身注入；且盯 send() 里的**调用点** —— 只查函数名时
删掉调用仍会误报绿（已实测并改正）
· SendInput 坐标归一化 + VIRTUALDESK
· sendinput 分支必须 return（防双执行）
## 待办（已写入 GUI-PLAN.md）
· loadGuiPrefs 不透传 agentCursor，导致 deferMs 配置读取不生效（实测）
· 显式调 SetProcessDpiAwarenessContext(-4)，不依赖 Electron 默认值
· mascot 姿态：思考/等待/出错
· 真实点击效果仍未验证（当前环境无可注入的可见窗口）
2026-10-02 15:27:33 +08:00
f0a7ce23b1
feat(gui): 模式 A agent 独立光标 + 后台注入；修坐标换算；固化计划与交接文档
...
## 模式 A：agent 独立光标（不抢用户鼠标）
现有 computeruse 走 SetCursorPos + mouse_event，agent 一干活就抢走用户
真实鼠标，用户无法同时使用电脑。现改为：GUI 自绘 agent 专属光标，实际
输入经 PostMessage 直接投递到目标窗口句柄，用户鼠标全程不动。
新增：
cmd/gui/agent-cursor.js 透明置顶层窗口 + mascot 指针 + 移动/点击脉冲
动画；记录上次命中的 hwnd 供键盘动作使用
cmd/gui/agent-inject.js Windows 后台注入：WindowFromPoint 定位、
客户区坐标换算、PostMessage 投递鼠标/键盘/
滚轮/文本；拖拽分步移动
配置 gui-prefs.deviceBridge.agentCursor.mode = "overlay"(默认) | "real"。
明确的设计边界（不是实现缺陷，是平台限制）：
· 只对「接受窗口消息的程序」可靠。原生 Win32 程序可靠；Chromium/
Electron 自绘界面、游戏、DirectX 会忽略合成消息。
· 不做真实鼠标降级。用户既选了不抢鼠标，就不该偷偷改成操作真鼠标，
失败即 status=error 并说明原因。
· 键盘类动作依赖先前的鼠标操作（后台注入不动真光标，
GetCursorPos 拿到的是用户自己的光标位置）。
端到端 8/8 正确响应；「真实点击是否落到目标窗口」因当前环境无可注入的
可见窗口而未验证，已在 GUI-PLAN.md 列为待办。
## 修坐标换算（我自己上一轮引入的 bug）
上一轮我加了 rawX / scaleFactor 的换算，理由是「SetCursorPos 期望 DIP」。
**那个前提是错的** —— Electron 主进程是 per-monitor DPI-aware，Win32 坐标
不做虚拟化。实测：
Electron screen API (DIP) : 1260 x 840 scaleFactor=2
GetSystemMetrics : 2520 x 1680
SetCursorPos(200,200) -> GetCursorPos 读回 (200,200) 恒等，不缩放
加 /scale 会把原本正确的点击改坏：200% 屏上点 (600,400) 被送到
(400,267)，越靠右下偏得越远。已改回 physical ? rawX : rawX*scale，
drag 终点同步修正（原先两处换算不一致）。
易误判之处：在普通 node 进程里测同一函数读到的是 1260x840（虚拟化值），
会以为 Win32 用 DIP —— 必须在 Electron 内测。
## 判据
computeruse.test.mjs 43 条（npm test 共 127 条全绿），新增 5 条钉住
模式 A 的核心承诺：
· agent-inject / agent-cursor 均无 SetCursorPos 调用（查前先剥注释，
因为注释里会引用该名字解释「为什么不用它」）
· koffi 指针参数用 Buffer（普通对象不写回，会拿错 hwnd）
· overlay 默认开启且可切回 real
· 自绘光标层 setIgnoreMouseEvents 穿透
核心不变量已做变异验证：注入 SetCursorPos 后判据立即转红。
另修正坐标判据方向（原判据断言 /scale 是对的，与实测相反）。
## 文档
GUI-PLAN.md 改造计划与进度的单一事实来源：已完成/待办、坐标
实测结论与踩坑、koffi 3.x 使用约定、端到端测试方法、
环境注意事项（含本机无 Go 工具链、waiter 改动未编译验证）
SERVER-HANDOFF.md 服务端需同步的部分：放开 action 白名单（schema enum
+ switch default 双重限制，不改则 11 个新动作下发不到）、
透传 tox/toy/steps/dx/ms、统一 scroll 方向语义、
写入坐标约定防重蹈
2026-10-02 14:12:32 +08:00
d6dd84e1c8
fix(gui): 启动期误判服务端未启动；keybd_event 类型名致组合键全废
...
## 修 GUI 反复误判「服务端未启动」
isServerRunning() 硬编码 http://localhost:8080/。实测该部署下服务端在
192.168.2.60:8080（homed 跑在 WSL 里）：
localhost:8080 -> 000 连不上
192.168.2.60:8080 -> 302 正常
于是每次启动都：探测失败 → 误判服务没起 → 去 startHomed() 拉起 GUI 旁
并不存在的 homed.exe（findHomed 返回 null 就 skip）→ 再 waitForServer()
干等 8s 超时 → 打印 "homed failed to start within timeout"。
gui.log 里这条 ERR 累计出现 53 次，是日志里唯一的错误项。
改法：
· serverProbeTargets() 按「connections.json 里已配置的连接（当前连接
优先）→ localhost」顺序探测，命中任一即视为在线
· 服务可达时直接 skip homed 自动拉起
· 无本地 homed 可执行文件时不再空等超时，直接说明情况
· probeOne 加超时保护，避免启动被挂住
实测：修复后启动日志为 "server reachable, skip homed autostart"，
该 ERR 不再出现。
## 修 keybd_event 类型名（组合键整体失效）
koffi 不认 Win32 的 `byte`：
"void keybd_event(byte bVk, ...)"
-> Error: Unknown or invalid type name 'byte'
"void keybd_event(uint8 bVk, ...)" -> 正常
原代码用的正是 `byte`，且整段包在空 catch 里，于是 keybd_event 恒为 null，
所有组合键（keypress/hotkey）都返回 "keybd_event unavailable"。
这个 bug 很难被发现：单键 click/move/scroll 走 mouse_event，不受影响。
端到端实测确认：修复前 hotkey ctrl+shift+t 报
computeruse hotkey: keybd_event unavailable
另外签名解析失败现在会打日志，不再静默。
## 判据
computeruse.test.mjs 扩到 38 条（进 npm test，全量 121 条全绿），新增：
· keybd_event 签名类型（且已做变异验证：改回 byte 判据立即转红）
· 服务探测不只探 localhost / localhost 仅兜底 / 仅当有 homed 才拉起
· 服务可达时 skip autostart / 探测有超时保护
2026-10-02 13:03:17 +08:00
40119e8116
feat(gui+waiter): computeruse 补高级操作、修 HiDPI 坐标；记录 PiDeck 借鉴
...
## computeruse 高级操作
此前两端（GUI 本机桥 / waiter 设备侧）都只有 9 个基础 action
（click/move/scroll/keypress/type…），与业界 computer-use 的基本盘差距明显。
现补到 18 个，两端对齐：
drag 拖拽（分步移动，见下）
hover 只悬停不点击（触发 tooltip / 悬浮菜单）
mousedown/up 按下与释放分离，可配对做「按住」
tripleclick 三击选中整行
middleclick 中键
hotkey/combo 组合键（ctrl+c 这类）
wait/sleep 显式等待，等 UI/动画完成再下一步
display 显示器几何（bounds + scaleFactor + primary），多屏定位必需
★ 拖拽**分步移动**（默认 12 步，上限 60）而不是一步到位：canvas 拖拽、
列表排序、滑动条这类应用依赖中间 mousemove 事件，一步到位会失效。
## 修 HiDPI 坐标错位（GUI 侧）
截图给模型的是**物理像素**，而 SetCursorPos / xdotool / cliclick 期望
**逻辑点(DIP)**。旧代码只加了 display bounds 的原点偏移，完全没换算
scaleFactor ⇒ 150% 缩放屏上点击系统性偏移（越靠右下偏得越多）。
现在按目标屏 scaleFactor 换算，并提供 `physical:false` 让调用方声明
「坐标已是逻辑点」以免二次换算。
## 组合键归一化（waiter 侧）
旧实现把模型给的 key 字符串原样丢给 `xdotool key`，于是 "Ctrl+C"、
"ctrl + c"、"CTRL-C" 全部失效。新增 normKeySpec：统一 + 与空格分隔、
统一小写、去重复修饰键。
顺带修 waiter 的 `type`：加 `--clearmodifiers`，避免残留的 Ctrl/Alt
把后续输入变成快捷键（旧实现一次输入就可能污染后续所有按键）。
## scroll 修正（两端）
旧实现固定滚 `click 4/5`（上/下），忽略方向语义也不支持横向。
现按 dy 正负给方向、按量级分步、支持 dx 横向滚动。
## 显式声明借鉴 PiDeck
用户要求声明 GUI 借鉴了 PiDeck 的设计与实现。做法：
1. 新增 `cmd/gui/DESIGN-NOTES.md` —— 逐项列出借鉴自 PiDeck 的设计
（三点渐次明暗 / 运行态呼吸光晕 / 工具调用分组卡）、PiDeck 的原始
实现（@keyframes 名与 CSS 片段）、HomeAgent 的落地位置、以及**动机**，
并明确区分「本仓自行决策」的部分（如「只有 1 个工具时不分组」是本地决定，
不是 PiDeck 做法）。
2. app.js / style.css 的相关代码处补出处注释。
3. 判据 computeruse.test.mjs 钉住这几条声明，防止后续丢失。
参考方式为阅读 PiDeck 打包产物 app.asar 中的 CSS 实现后**独立重写**，
未复制其代码或资源文件。
## 判据
新增 cmd/gui/computeruse.test.mjs（进 npm test），30 条断言：
· 两端各 9 项高级操作
· HiDPI 换算与 physical 开关
· 组合键归一化、type 的 --clearmodifiers
· 拖拽分步移动（两端）
· PiDeck 借鉴声明四处（含 DESIGN-NOTES.md 存在）
判据：cmd/gui npm test 全绿（114 条）。
2026-10-02 11:10:53 +08:00
bf06ad029a
feat(gui): 加载动画改三点式 + 新增系统通知
...
## 1) 加载动画：边框旋转 → 三点渐亮
旧实现是 border + rotate 的 spinner，用在 .loading(16px) /
.loading-spinner(32px) / .live-spinner(15px) 三处。在消息气泡里刺眼，
且语义不对：旋转暗示"正在加载某个确定的东西"，而 agent 思考没有进度。
参考 PiDeck（@deepseek-ai/dsh-web-frontend 与 mermaid bundle 里的
@keyframe 实现）改为「等距三点 + 透明度递减 + 轻微上浮」：
haDots 三点错峰明暗（1/0.6/0.35/0.15）
haDotFloat 单点上浮 + 缩放
haSweep 横向扫光
旧类名 .loading / .loading-spinner 保留为别名指向新动画（还有 6+ 处
调用点，逐处改 HTML 容易漏），并解除其 animation 以免残留旋转。
7 处调用点统一换成 <i>x3 结构。
## 2) 系统通知（此前完全不存在）
主进程无 Notification、preload 无接口、渲染层只有页面内 toast
（用户不盯着窗口就看不到）。补齐一条完整链路：
main.js notify:show / notify:supported 两个 IPC + 原生 Notification
preload notify.{show,supported,onClicked}
app.js notifyTurn / notifyTurnOnce / onNotifyClicked
设计取舍（都写进注释）：
· **一轮只通知一次**。SSE 的 tool_call / stage / agent_output 都可能
判定"一轮结束"，用 turnSig 去重，否则连弹好几次。
· **不在流式过程中逐 token 通知**。一轮可能几十个 delta，那是噪音；
用户要的是"有结果了"。
· **窗口在前台且聚焦时不弹**。正看着界面时弹窗只会烦人。
静默启动（窗口 hidden）正好走"要弹"这条 —— 这也是静默后唯一
能让用户知道"agent 回了"的途径。
· **挂在 SSE 的 agent_output 收尾处**，不挂 endChatTurn()：
后者开头 `if (!state.chatLoading) return`，而旁观路径
（agent 响应 memo/QQ/email，GUI 只收 SSE）chatLoading 恒 false，
根本走不到那里。挂 SSE 对"自己发"与"旁观"两条路径都生效。
· **点击通知会 show() + 回传渲染进程**，切到 chat 视图并滚到该条。
点了却不知道该看哪句话等于没通知。
· 正文超 180 字截断，避免通知被撑爆。
## 判据
新增 cmd/gui/loading-notify.test.mjs（进 npm test），24 条断言覆盖
动画关键帧/错峰 delay/别名解除/调用点结构，以及通知链路的六段
（主进程 IPC、preload 桥、去重、挂载位置、点击跳转、可用性探测）。
## 实测
重新打包安装：186 文件 0 处不匹配，exe 188834816 字节
启动正常：silentStart 生效、login 200、device/online 200、
graph/pulse 轮询、0 个 401 / JS 错误。
判据：cmd/gui npm test 全绿（84 条）。
2026-10-02 10:40:35 +08:00
8847ce4cfd
fix(gui): 修发行打包的图标与资源漏装（Linux 包会缺星图依赖）
...
## 背景
上一提交修了 electron-packager 那条路径的 exe 图标。本提交处理另外两处
同类问题——**都是静默失败**：改了没人知道，坏了要等用户装上才发现。
## 1) package.json build 段（electron-builder 路径）
· files 白名单漏了 icon.ico / icon-tray.png / icon-tray@2x.png
⇒ 这些文件不会被打进包，托盘与窗口图标在发行版里丢失
· 补 win.target/win.icon；注意 electron-builder 的 icon 路径相对
**项目目录**（package.json 所在）解析，不是相对输出目录
（最初写成 'build/icon.ico'，那会找不到文件 —— 已用存在性判据钉住）
· icon.ico 含 256x256，满足 electron-builder 对 win 图标的要求
## 2) deploy/packaging/package-linux.sh（Linux 发行实际走这条）
原实现手工 cp 七个文件：
main.js / preload.js / package.json
renderer/{index.html, app.js, style.css, mascot.svg}
实测漏掉：
· renderer/mascot.svg —— 源码里根本不存在（真名 mascot.webp）
· icon.svg / icon.ico / icon-tray*.png
· renderer/icon.svg
· renderer/vendor/* ★★ 本次本地化新增的四个第三方库
（three/OrbitControls/marked/purify）
⇒ Linux 发行包装完星图与 Markdown 渲染直接坏，
且**没有任何构建报错**
改为：
· renderer 按目录整体同步（cp -r "$gui_dir/renderer/."）
· 根级 *.svg / *.ico / icon-tray*.png 同步
· 新增必备文件校验：vendor 四库与 icon.svg 缺任一 ⇒ 报错并删目录跳过，
沿用本脚本既有的"宁可不发，也不发装了跑不起来的包"原则
## 判据
新增 cmd/gui/package-config.test.mjs（进 npm test），14 条断言覆盖三条
打包路径的配置一致性。已做变异测试：Makefile 去 --icon、files 去 icon.ico、
package-linux.sh 还原逐文件 cp，三者均判红。
判据：cmd/gui npm test 全绿（60 条）。
2026-10-02 10:25:43 +08:00
58ad6831f5
fix(gui): 静默启动开关此前是死设置，永远不生效
...
## 现象
设置页有「静默启动」开关，文案写着「启动时不显示主窗口，驻留托盘
后台运行」，勾选后启动 GUI 照样弹窗。
实测（本机，gui-prefs.json 里 silentStart=true）：窗口标题 HomeAgent
照常出现。
## 根因
silentStart 从未被消费：
· main.js 的 loadGuiPrefs() 把它读进对象
· 渲染层设置页读写它
· **但主进程没有任何地方读它做判断** —— whenReady 无条件 createWindow()
是个纯粹的界面开关，接线缺失。
## 改动
1) createWindow(show = true)：支持「创建但不显示」。
BrowserWindow 初始 show:false，非静默时经 ready-to-show 显示
（避免先显示再隐藏的闪烁）。
★ 为什么静默时**仍然创建窗口**、而不是不创建：
不创建 ⇒ 渲染进程不启动 ⇒ app.js 整个不执行 ⇒ SSE 通道、
设备桥轮询、聊天全部失效，GUI 退化成纯托盘图标；且
showMainWindow() 只做 show()、不会创建窗口，app.on("activate")
又只在 macOS 触发 —— Windows 上托盘点「显示主界面」将毫无反应，
进程变成唤不起来的僵尸。已按此结论实现（评审时确认为「创建后隐藏」）。
2) whenReady 读 silentStart 并据此 createWindow(!silent)。
与 applyAutoLaunch 里的 openAsHidden 是两条不同路径：那个告诉 OS
「开机自启时如何启动」，这里决定本进程要不要显示，对手动启动同样生效。
3) showMainWindow() 增加兜底：窗口不存在时重建；隐藏时先 show 再 focus。
消除上述「唤不起来」的隐患。
4) loadGuiPrefs() 补去 UTF-8 BOM。
★ 这是排查中发现的**第二个真实缺陷**：Windows 工具
（PowerShell Set-Content -Encoding UTF8、记事本）改过 gui-prefs.json
会写入 BOM，而 JSON.parse 遇 BOM 直接抛错 → 走 catch → 返回**默认
prefs** ⇒ silentStart/exitToTray/deviceBridge 全部被静默重置，
表现为「开关保存了但不起作用」。loadConnections 早就有去 BOM 处理、
这里没有，两个读取点不一致。
（本次实测正是被自己的判据脚本用 Set-Content 改 prefs 后踩到的。）
## 判据
新增 cmd/gui/silent-start.test.mjs（进 npm test），14 条断言：
· whenReady 确实读 silentStart 并决定 show
· 静默路径仍创建窗口（不许退化成不建窗）
· showMainWindow 能在窗口缺失时重建
· loadGuiPrefs 去 BOM，且 loadConnections 的既有处理不回退
已做变异测试：还原成无条件 createWindow()、抽掉 BOM 处理，均判红。
## 实测（本机 Electron，真实 prefs）
silentStart=true → processes=8 visibleWindows=0，日志出现
[startup] silentStart=on: window created hidden
silentStart=false → processes=4 visibleWindows=1（标题 HomeAgent）
判据：cmd/gui npm test 全绿（46 条）。
2026-10-02 09:47:11 +08:00
e3c81269b6
fix(gui): 连接配置不再被空/半截文件覆写，保存改原子写
...
## 现象
connections.json 变成 {"connections":[],"currentId":null}，
用户的连接列表全部丢失（2026-10-01 实测）。
## 根因：两个缺陷叠加
1) loadConnections() 的损坏恢复分支无法区分两种情况：
· 文件内容确实损坏 → 备份+重建（合理）
· 读到空/半截内容 → **也走同一条路，覆写成空配置**
第二类真实会发生：saveConnections() 用非原子 writeFileSync 截断重写，
落地过程存在「已截断、未写完」窗口；此刻任何一次读取拿到半截内容，
JSON.parse 抛错 → 用户配置被永久销毁，且没有二次确认。
实测（沙箱跑真实函数）：空文件 -> 返回空配置，
**并把文件改写成 {"connections":[],"currentId":null}**。
2) 损坏备份只写一个固定的 .bak，反复损坏会把上一份真实配置覆盖掉，
于是「唯一的退路」也丢了。
## 改动
1) loadConnections()：raw.trim()==="" 视为「尚未配置」，
直接返回空配置，**不覆写、不备份**（BOM/纯空白同样处理）。
2) saveConnections()：改为原子写 —— 先写同目录 .tmp-<pid>，
再 renameSync 覆盖。rename 在同卷内原子，读者只会看到改写前
或改写后的完整文件，从根上消除产生半截内容的竞态；失败时清理 tmp。
3) 真损坏的备份名带时间戳（connections.json.corrupt-<ISO>.bak），
反复损坏不再互相覆盖。
## 判据
新增 cmd/gui/connections-io.test.mjs（进 npm test）：
在 node:vm 里抽出 main.js 的**真实函数**执行，11 条断言覆盖
合法/空/纯空白/损坏/原子写残留。已做变异测试：删掉空文件守卫、
把备份名改回固定 .bak，均被判红。
## 实测（本机 Electron + 真实凭据）
正常启动：connections.json MD5 前后一致（E8DD588F...），0 个 tmp 残留
人工清空后启动：文件被自愈填充回真实配置，而非覆写成空
判据：cmd/gui npm test 全绿（32 条）。
2026-10-01 23:16:49 +08:00
ee2d43dcbc
perf(gui): 流式渲染判据改看 _streaming，不再依赖 chatLoading
...
## 现象
旁观 agent 响应其它渠道（memo / QQ / email）时，聊天页每秒全量重渲多次，
消息越多越卡。
## 根因
流式分支判据写的是 `state.chatLoading && ...`，而 chatLoading 只在
「用户从 GUI 自己发消息」（sendChat）时置 true。旁观路径（agent 响应
memo/QQ/email，GUI 仅通过 SSE 收流式帧）下它恒为 false ⇒ 判据恒假 ⇒
每个 content_delta / reasoning_delta / tool_call 帧都掉进「非流式」分支，
走**全量** innerHTML 重建。
而且它出现**三处**，只改一处无效：
· rerenderChatIfActive（决定走 renderChatStreamChunk 还是 renderChat）
· renderChat 内部的 streamingLast（决定单条消息的渲染分支）
· 工具 pill 的「进行中」收集（旁观时列表恒空，看不到 agent 在做什么）
## 实测（本机 Electron + 192.168.2.60，真实凭据，同一条消息）
修复前：1.7~2 秒内 13~26 次全量重渲，间隔 10~30ms
修复后：同一场景降到 5 次（含轮询触发的）
200 条消息时单次全量重建实测 235ms —— 这是「聊天卡得没有用的欲望」的直接来源。
## 改法
所有 SSE 流式帧创建的 assistant 消息都带 _streaming:true
（content_delta / reasoning_delta / tool_call / agent_output 五个 push 点），
收尾时才置 _final。所以正确判据是「最后一条是尚未收尾的流式 assistant」，
即用 last._streaming 取代 state.chatLoading。
保留 chatLoading 的两处语义不同，未动：
· 「思考中」占位气泡：只在用户自己发消息后等待时显示，旁观不需要
· sendChat / interruptChat 自身的并发保护
判据：cmd/gui npm test 全绿。
2026-10-01 22:02:37 +08:00
60f51f40e0
fix(gui): 设备接口补设备令牌，设备页不再恒 401
...
## 现象
GUI 设备页长期空白。日志每 15s 一条：
GET 401 /api/v1/device/online
## 根因：/api/v1/device/ 命名空间下并存两套鉴权
· /device/gateway 注册在 webui 插件，走 requireAPI，认 session cookie
· /device/online、/device/、/device/push
注册在 remotedevice 插件，走 requireToken，
**只认 X-API-Key 头或 ?token=，完全不认 cookie**
实测可区分：cookie 401 与错 token 401 的响应体都是纯文本
"unauthorized"，而 webui 鉴权返回 JSON {"error":...}。
所以 GUI 只带 cookie 时：gateway 200、online 401 —— 同一连接同一
时刻，现象自相矛盾。
## 三种能工作的客户端做法一致，GUI 两样都没做
· WebUI 浏览器：cookie 进内核，reverseToUpstream 注入
deviceGatewayToken（handler_device.go:118）
· waiter：客户端自己带 X-API-Key（gateway_discover.go:103）
· GUI：既没注入、也没自带 ⇒ 设备页恒 401，且异常被 catch
吞掉置空数组，界面与「确实没有设备」完全一样
## 改动
1) main.js：device-bridge:get 回传 token 明文（此前只有 tokenSet
布尔，渲染进程永远拿不到）。明文本就存在本机 gui-prefs.json，
不新增密钥存储面，且不落日志、不进 URL。
2) app.js：新增 isDeviceTokenPath / deviceApiKey，对设备接入面
端点附加 X-API-Key（优先连接自身 apiKey，退回设备桥 token）。
3) app.js：新增 ensureDeviceToken，并**在首次 /device/* 请求之前**
调用 —— 此前令牌加载排在 /device/online 之后，顺序正好反了。
4) app.js：401 时记下可读原因（deviceAuthHint），设备页顶部渲染
红色提示卡，不再把鉴权失败伪装成「没有设备」。
5) app.js：网关发现加缓存，并从每 15s 的 refreshAll 轮询里移出
（改为按需 + 切连接/手动刷新时重取）。网关地址是服务端配置的
慢变量，15s 拉一次没有意义；此前它与 online 同秒重复调用。
## 实测（本机 Electron，192.168.2.60:8080，真实凭据）
修复前：device/online 恒 401，设备列表空
修复后：device/gateway 1 次（之后走缓存）
device/online 每 15s，全部 200，返回 waiter-fnnas /
waiter-mainnas 两台设备
401 计数 0
判据：cmd/gui npm test 全绿。
2026-10-01 20:24:55 +08:00
53d9af446c
feat(gui): 星图接上 /memory/graph/pulse + 前端依赖本地化 + 端点对齐门禁
...
GUI 与服务端 WebUI 插件共享同一套 REST 接口，但两边独立演进、没有任何
强制手段。这次核实发现三处真实漂移（服务端 42 路由 / GUI 只用 29）。
1) 星图接上服务端专为它造的轻量活动端点
服务端 handleMemoryGraphPulse 的注释写了动机：生产实例全量图谱
408KB / 1151 节点，为了「知道哪些节点是新的」而每 N 秒拉全量是把
带宽和 JSON.parse 全花在重复数据上；pulse 只回 id+name+type+
mention_count+updated_at，几百字节 ~ 几 KB，差两个数量级。
WebUI dashboard 接了它，GUI 此前只在初始化拉一次全量且完全不轮询
⇒ 星图停在打开那一刻的快照，agent 后来学的东西它永远看不到。
现接入：/runtime 3s + /memory/graph/pulse 10s，两路轮询幂等、
切连接时停；新实体标「生长」；SSE 的 tool_call/stage/agent_output
也会触发脉冲（用工具名与回复前 60 字当 hint，让点亮落到本轮相关实体）。
pulse 检出「全量图里没有的新实体」时置脏，由下一次 renderChatStarmap
惰性重拉全量 —— 不在脉冲回调里直接拉，否则会把轻量活动源变成每 10s
拉一次 408KB 全量，正好是 pulse 端点要消除的浪费。
2) 前端依赖本地化，顺带修掉一处安全边界
四个库从 internal/plugins/webui/static/ 复制到 renderer/vendor/
（字节一致，由门禁钉住），index.html 不再引用任何公网 CDN。
与服务端同一理由（见 webui/starmap_vendor_test.go 的注释）：
HomeAgent 支持离线/内网部署，换 CDN 只是把同一个赌注重下一遍。
★ renderMd() 的净化器缺失分支不再回退到手写正则（剥 <script>/on*=/
javascript:）—— 那不是完备的 HTML sanitizer，漏 <iframe srcdoc>、
SVG 内联事件、data: URI 等，而它渲染的是模型输出与记忆文本，
都算不可信输入。现在直接退纯文本：库已本地化，走不到该分支。
3) 新增 endpoint-align.test.mjs（进 npm test / CI）
扫描 app.js 的 api("...") 与 handler.go 的 mux.HandleFunc 对账，
7 条判据。与既有判据同一路子：读真实源码，不抄逻辑重写。
反向差集只报告不门禁（管理面端点接不接是产品决策），
只硬钉「服务端已明确为其设计」的 pulse —— 即本判据的由来。
已做变异测试：改错 pulse 路径、改回 CDN 均能判红。
protocol-align.test.mjs 是真浏览器判据（需 Electron+Xvfb+真后端），
CI 明确不跑，所以这类漂移此前无人发现。
顺带：connectSSE 由隐式全局赋值改为 function 声明（加 "use strict"
会在文件靠后处 ReferenceError，报错点离调用点很远）。
判据：cmd/gui 下 npm test 全绿（4 个 .mjs / 25 条）。
2026-10-01 18:23:20 +08:00
7151f1db85
feat(gui): 协议对齐 —— 补齐 6 个只读诊断端点 + 人设/反代面板
...
GUI 原来只用 22 个端点，服务端有 47 个。补齐**只读诊断类**：
agents / network / tracker / config / persona / proxy(+services)。
## 刻意不接 /login 与 /logout
那是 cookie 会话认证流程，而 GUI 走 `X-API-Key` 头（见 `api()`）。
接了不是"对齐"，是接错。
## 三处新增
**总览诊断卡片**（renderDiagPanel）：Agent 健康、LLM 可达、网络端点数、
文件变更集、数据目录、心跳间隔。全部走 `(x && x.y)` 安全取值 ——
任一端点没取到（老内核无该路由、连接断开）只显示 "-"，不抛错。
**人设面板**（renderPersona）：实测结构是
`{current_prompt, file_override, initialized}`。我第一版按 map 遍历，
结果只会显示三个字段名 —— 真机验证时才发现。改成展示提示词全文 +
两个状态卡。**只读**，编辑涉及保存/回滚/并发覆盖，与"协议对齐"是两件事。
**反代面板**（renderProxy）：base_domain / mode / total / manual +
服务列表（`✓ gateway → 127.0.0.1:9890`）。实测字段是
`{name, host, path, url, target, ok, auth, websocket}`，不是我第一版假设的
`subdomain`。
## 加载策略
只加进 `refreshAll`，**不加** `refreshDataOnly`（后者每 15 秒一轮，
诊断数据不必高频轮询）。7 个新端点实测只 +3ms。
## 判据 protocol-align.test.mjs（10 条，真 Electron）
- 7 个 state 槽都取到真实数据
- 总览出现诊断卡片
- 人设面板**真的显示提示词内容**（不只查元素存在）
- 反代面板**真的列出服务**（查 `→` 出现）
### 判据踩的三个坑
1. **默认假 key 导致 9 项全红** —— webui 对错误凭据返回 200 + 登录页 HTML
（`looks_like_login_page` 能识别），于是所有取数失败。看起来像
「代码坏了」，实际只是认证缺失。改为默认从 `config.db` 读真 key。
2. **判据绕过了应用路径** —— 表达式里直接调 `refreshDiagData()`，
于是把应用里的 `await refreshDiagData()` 注释掉，判据**仍全绿**。
改为走应用自己的 `refreshAll()`。
3. **变异后 GUI 仍加载旧代码** —— `ensure()` 看到端口有页面就复用，
注入变异后没重启 GUI ⇒ 又一次假绿。**变异测试必须先杀掉 GUI 进程。**
变异测试（注释掉调用点）⇒ 9 项变红，坐实判据验的是真路径。
## 门禁
- `npm run test-live`：22/22 通过（12 性能+滚动 + 10 协议对齐）
- `npm test`、`make test-gui`：全通过
- `go test ./...`：43 包 ok、0 FAIL
2026-09-28 10:45:54 +08:00
17fee7fabd
perf(gui): 聊天页增量渲染 + 修「打开不在最新消息」（10× 提速）
...
用户报「聊天页面卡得让人没有用的欲望」+「打开 app 和 webui，没有停在
最新消息处，还要反复滑动」。真机实测（Xvfb + Electron + CDP）定位到两个
根因，都修了。
## 根因 1：renderChat 每次全量重建 innerHTML
200 条消息 = 3500 个 DOM 节点全部销毁重建。拆分测量：
200 条：整体 234.6ms，其中 renderMd 25.4ms（**11%**）
⇒ markdown 渲染只占 11%，**89% 在 DOM 写入与布局**。
流式追加时每个放行的 chunk 都走这条路（200 条时每 chunk 6.6ms），
聊到几百条就是 0.5 秒/次 —— 这就是体感。
**改法**：按 `data-msgkey` 复用节点，四种策略按代价从低到高：
尾部追加（最常见）→ 头部前插（loadOlderChat）→ 局部替换 → 兜底整棵重建。
`data-msgkey` = role + 序号 + 内容长度 + 首尾片段。
★ **不能靠下标定位**：`loadOlderChat` 会 `unshift` 前插消息，下标整体位移。
实测：
| 消息数 | 改前 | 改后 | 改善 |
| --- | --- | --- | --- |
| 50 | 59ms | **8.2ms** | 7.2× |
| 200 | 235ms | **23.5ms** | 10× |
| 400 | 474ms | **38.2ms** | 12× |
关键是**次线性**了：400 条只比 200 条多 15ms（改前多 240ms）。
## 根因 2：滚动没落地
scrollTo 被调: 1, 参数: {top: 23446, behavior: "smooth"}
scrollTop: 0 ← 调了，但没生效
可滚动上限: 22838
smooth 立即值 0、300ms 后只到 6894（上限 22838）⇒ **既慢又没到位**；
手动 `scrollTop = scrollHeight` **立即 22838 一次到位**。
原因：紧邻的 DOM 全量变更让 smooth 动画的起点算在**旧**布局上。
重建后本就不该有动画 —— 用户要的是「立刻看到最新」。
**改法**：`msgsEl.scrollTop = msgsEl.scrollHeight`。
## 判据 chat-perf.test.mjs（10 条，真 Electron 跑）
新增 `npm run test-live`（需 Xvfb + electron，**不进 make test** ——
它要起真浏览器、30 秒启动，不适合当门禁）。
- 性能：200 条 < 100ms（**产品体感阈值**，不是 benchmark 数字）
- 次线性：单条成本不随规模上升
- 滚动：打开即在底部、300ms 后不被带偏
- **正确性：增量不丢消息**（5 种增删改路径）—— 比性能更重要
### 写判据时踩的坑（都记在文件里）
1. **第一版测出「0ms / 0 DOM 节点」** —— `buildChatLayout()` 在**无后端连接**时
走「请先添加连接」分支、聊天区压根没建 ⇒ **测不到**而非「不卡」。
2. **`ensureGui` 定义了但从未被调用** —— 重写文件时把调用丢了，
而定义还在，看起来一切正常。
3. **`detached: true` 只脱离进程组、不脱离会话** —— 脚本结尾 `process.exit()`
把刚起来的 GUI 带走（症状：`[tray] READY` 打了，判据却报「找不到页面」）。
改用 `setsid`。
4. **`JSON.parse(e.data)` 裸调** —— CDP 的 onmessage 也会收到非 JSON 帧，
抛在回调里既冒泡不到 await 也等不到 resolve ⇒ 整个判据挂死。
5. 我自己的滚动探针 `el.innerHTML=''` 让 `scrollHeight` 变 0，
「到位」判定是假象。改用「保留内容、只改滚动方式」重测。
## 变异测试
把 `applyIncrementalChatRender(msgsEl, html)` 改回 `msgsEl.innerHTML = html`
⇒ 判据立刻红（实测 268ms + 严格线性）。
## 门禁
- `npm run test-live`：10/10 通过
- `npm test`、`make test-gui`：全通过
- `go test ./...`：43 包 ok、0 FAIL
2026-09-28 10:26:58 +08:00
1fe1b6e466
fix(gui): 401 重试无限递归 —— 我上一个优化放大的 bug
...
## 真机实测发现的
Xvfb + Electron + CDP 真跑，发现 `api()` 的 401 分支**无限自我递归**：
第1次: lock=false → 重登 → lock=false → return api() ← 递归
第2次: lock=false → 重登 → lock=false → return api() ← 又递归
…
那把锁的语义本该是「已经重登过一次，别再登」，但它在递归**之前**就被
清掉了 ⇒ 每层递归看到的都是 `false`。真机实测 **fetch 被调 13 次、
重登 12 次**才被我的探针上限截断。
## 为什么这与我的上一个提交直接相关
`74dbbb3` 把 401 分支的固定等待从 800ms 降到 30ms（修「认证过期时每个
请求白等 0.8s」）。但重试**没有次数上限** ⇒
- 改前：每 800ms 慢速空转
- 改后：每 30ms 快速烧 CPU + 反复打服务端
**我的优化把这个 bug 放大了。** 真机上探针调用 `api()` 直接挂死，
我起初还以为是我的测试写法问题。
## 修法
两处递归点（真 401 / 门户返回 200 但内容是登录页）都改成：
try {
return await api(p, o);
} finally {
window._haReloginLock = false;
}
`finally` 保证递归抛错时也释放锁 —— 否则会把后续所有请求都锁死成直接 401。
## 判据 retry-guard.test.mjs
在 `node:vm` 沙箱里跑**真实抽出的 `api()`**，用恒回 401 的 `fetch` 驱动，
统计真实调用次数。
### 写这条判据时踩的四个坑（都记在文件里）
1. **先给了假绿灯**：把 401 分支当独立函数体执行，但那块以
`return api(p,o)` 结尾、外面没有调用它的上下文 ⇒ 我从未真正进入那个
`if` ⇒ `api 递归=0` ⇒ 什么都没测到。改成跑**真实 api()** 才对。
2. **递归时忘了保持 `r.status===401`**：真实场景是「重登后凭据仍是错的」。
漏了它 ⇒ 递归那层不进 401 分支 ⇒ 又一次假绿灯。
3. **沙箱 `setTimeout` 只记录不执行**：`api()` 用它做超时控制
（`setTimeout(() => ctl.abort(), to)`）⇒ AbortController 永不被 abort
⇒ 表现为「fetch 只调 1 次、8000ms 被当成 401 等待」。
4. **沙箱缺 `clearTimeout`** ⇒ 抛 `clearTimeout is not defined` ⇒
整段在 fetch 之后就断了 ⇒ 永远走不到 401 分支。
★ 共同点：**沙箱不完整 ⇒ 静默地什么都没测 ⇒ 假绿灯**。
判据自己给假绿灯比没有判据更危险。
### 变异测试（精确锚点，验证判据真能抓）
把第一处 try/finally 退回「递归前清锁」⇒ 判据立刻红
（`fetch 被调 13 次`）；恢复后全绿。
★ 第一次做这个变异时我误判「判据漏抓」—— 实际是我的变异脚本用了模糊
锚点、**压根没改到文件**（`grep` 显示 return await 从 2 变 1，但 `sed`
命中的是另一处）。两个信号矛盾时先坐实文件状态，别急着改判据。
## 顺带把 `make test` 的门禁修好（37ae621 / 31b882a
2026-09-28 09:11:58 +08:00
37ae621605
test(gui): 行为判据 + 接进 make test（此前无人能跑）
...
## 为什么加行为判据
`sse-backoff.test.mjs` 检查源码**形状**（有没有清零、上限自不自洽）。
但形状对 ≠ 行为对：把清零写到 `reader` 取流**之后**，形状检查照样通过，
而实际仍在用旧计数重连。
新判据 `sse-backoff-behavior.test.mjs` 从**真实源码**抽出退避表达式并
在 `node:vm` 沙箱里求值，用假状态记录实际等待。实测量化：
历史累计 8 次后建连成功再断流 → 等 1000ms（改前会是 32000ms）
连续 6 次「建连成功→断流」 → 1000,1000,1000,1000,1000,1000ms
## 变异测试（都抓到）
| 变异 | 形状判据 | 行为判据 |
| --- | --- | --- |
| 清零挪进 setTimeout 内 | 通过 | **红** ← 只有行为抓得到 |
| 删掉「建连后」清零 | **红** | 通过 ← 暴露了行为判据的盲区 |
| pump 上限改回 60000 | **红** | — |
| 30ms 改回 800ms | **红** | — |
第二行促成了「行为 0」：建连后清零原本不在被验证的路径上
（抽取锚点只抓 pump 那一处），补了独立检查。
## ★ 判据本身踩的坑（都写进文件注释）
1. **别包假 setTimeout**：`exprSrc` 本身就是延迟数值
（`setTimeout(fn, <延迟>)` 的第二个参数），包一层让结果恒为 null，
三项全红。
2. **别用 `new Function`**：等价于 eval，是安全反模式。改用 `node:vm`
的 `runInNewContext`（官方受限环境，拿不到宿主作用域，带 1000ms 超时）。
3. **一个正则兼容两种幂运算形态会取错捕获组**：`Math.pow(2,x)` 比 `2 ** x`
多一层括号 ⇒ 组数差 1 ⇒ `r[length-1]` 取到 NaN。
最终形态是**定位与取值分离**：正则只定位（不捕获数字），数字单独取。
4. **`String.raw` 拼接正则不可用**：`\\.` 保持字面双反斜杠（去找字面的
"\."），且拼接后捕获组编号不可控。
## ★ 这些判据此前没有任何入口会跑
`cmd/gui` 是**纯 Electron 目录**（0 个 `.go`、无 `go.mod`），Go 通配会
跳过它 ⇒ 判据挂着也没人执行。现已接入：
- `cmd/gui/package.json` 加 `"test"`
- `Makefile` 加 `test-gui` 目标，并挂进 `test`
- 无 node 时显式 SKIP 而不是静默通过
```bash
make test-gui # 或 cd cmd/gui && npm test
```
## 顺带说明
`go test ./cmd/gui` 报 `no Go files [setup failed]` **不是回归**：
该目录 0 个 `.go` 文件，只有**显式点名**才报。仓库门禁用的三种形态
（`go test ./...`、`go test ./cmd/...`、Makefile 的 `test`）全部通过。
2026-09-28 08:16:51 +08:00
74dbbb31fe
fix(gui): SSE 退避计数从不重置 —— 消息流不稳的一个共因
...
## 现象
用户报 GUI「消息流不稳、动画不连贯、看着卡」，四类症状都有：滞后、
卡顿、闪断、资源高。定位到**同一个**共因，不是四个独立问题。
## 根因 1：退避计数只增不减
`state._sseRetryAttempts` 的自增只发生在 `connectFetchSSE` 的 catch 分支
（连接**建立**失败），而 `pump()` 中途断流后的重连**只读它算延迟，
从不清零**：
Math.min(1000 * Math.pow(2, Math.min((state._sseRetryAttempts || 0), 5)), 60000)
后果：只要历史上累计过 5 次，**之后每次断连都固定等 32s** —— 哪怕这次刚
成功连上、说明服务端和网络都好好的。而"成功连上"恰恰是最该重置的信号。
修：建连成功后清零（reader 取流之前），断流重连前再清一次。
## 根因 2：外层 60000 上限是死代码
`2^5 = 32s < 60s` ⇒ `Math.min(..., 60000)` 永远达不到，**真实封顶是 32s**。
改为 32000，让声明值与实际一致（判据会验这一条）。
catch 分支那处保留 60000：它语义不同（连接根本没建起来，attempts 已 +1，
退避本就该更长），上限放宽无害 —— 判据按各自语义分别判定，不一刀切。
## 根因 3：401 重试固定空等 800ms
`api()` 里每个 401 都走 `syncConnAuth()` + 固定 `setTimeout(800)` 才重试。
认证过期时**每个**请求白等 0.8s，并发几个就叠加成明显的「卡」。
`syncConnAuth` 本身就是 await 的，返回即代表凭据就绪 ⇒ 降到 30ms
（留一点让 setAuth 的 cookie 落盘）。
真 401 与「门户返回 200 但内容是登录页」两个分支都有这处等待，两处都改。
## 判据：cmd/gui/sse-backoff.test.mjs
`cmd/gui` 无测试框架（package.json 只有 start/dev），app.js 是 203KB 单文件。
判据从**真实源码**提取退避表达式并求值，而不是抄一份逻辑重写 ——
抄写的那份会和真实代码漂移，而漂移本身就是这个判据要防的东西。
3 项 + 变异测试（删清零 / 改回 60000 / 改回 800ms，三次全部被抓到）。
### 判据本身踩的三个坑（都记在文件注释里）
1. **正则两种形态括号数不同**：`Math.pow(2, x)` 比 `2 ** x` 多一层括号。
早先只按 pow 写，biome 规范化成 `**` 后**静默失配**。
2. **不能用 String.raw 拼接正则**：`\\.` 保持双反斜杠字面量（去找字面的
"\."），且拼接后**捕获组编号不可控** —— 实测 cap 解出 NaN。
3. **一个正则兼容两种形态会取错捕获组**（组数差 1）⇒ 改为
**定位与取值分离**：正则只负责定位（不捕获数字），数字单独取。
### 只认 pump 那处上限自洽
catch 那处 `60000` 不可达但无害（语义是"最多等一分钟"）。
判据对两处**分别**判：pump 要自洽，catch 只要有有限上限。
## 排查时坐实的两件事
- **`go test ./cmd/gui` 报 `[setup failed]` 不是仓库问题**：`cmd/gui` 有
**0 个 `.go` 文件**（纯 Electron），Go 通配会跳过它，只有显式点名才报。
`go test ./...` 实测退出码 0、43 包 ok、0 处提及 cmd/gui。
- **biome 会顺手把 `function () {}` 改成箭头函数**（本次混入 12 行）。
与本次修复无关，已从 HEAD 干净重放，最终 diff 只有 3 处实质改动
（24 增 3 删，零无关格式化）。
2026-09-28 07:59:15 +08:00
10dc1deaec
fix(gui): 设备桥 bind 结果判 ok + 暴露登记状态，与鸿蒙端对齐
...
GUI 主进程与 Go 客户端同病： 只打日志、不看 ok。
服务端 bind 被拒时回 {"ok":false,"error":"bind rejected"} 并关闭连接，
GUI 既不报错也不重连 ⇒ 设备静默失联（TCP/WS 通但从未登记进网关）。
另：成功时服务端不含 device 字段，原日志用 `msg.device || deviceBridgeId`
兜底才显得像成功，掩盖了「从未真的读 ok」。
鸿蒙端 DeviceBridge.ets:209 本来就是正确实现（检查 ok、区分 connected
与 bound），本次把 GUI 与 Go 客户端对齐到同一语义：
新增 deviceBridgeBound / deviceBridgeBindError，bind 被拒打 error 级日志
并说明常见原因（令牌不匹配 / 设备未授权）。
2026-09-26 13:49:59 +08:00
39cd42723c
feat(clients): 设备桥自动链接改用服务端发现 + 路径挂载（无 DNS 依赖）
...
配套 webui 反代改造：网关现在可由 HomeAgent 反代出去，客户端不能再靠
「门户地址同 host 拼 /api/v1/device/ws」猜地址——基域名与子域标签都是
**服务端配置**，客户端无从得知。
## 服务端：/api/v1/device/gateway 发现端点
客户端问「网关在哪」是唯一不会漂移的做法：子域标签可改（插件声明）、
基域名可改（webui.base_domain）、实例可换形态，客户端都不用跟着改。
⚠️ **不返回设备令牌**：本端点用门户凭证鉴权，而设备令牌能执行设备命令；
把令牌塞进来等于「门户只读凭证 → 设备执行权」的越权。令牌仍由客户端
自配。已有判据钉住「不得泄漏凭证字段」。
## ★ 实测发现：*.localhost 只有浏览器能解析
这是本轮最重要的发现，直接决定了设计：
| 环境 | devices.localhost 解析 |
|---|---|
| 浏览器 | ✓（RFC 6761 内置） |
| curl | ✓（内置特例） |
| getent / Go / Node | ✗（系统 nsswitch 是 files,dns，无 nss-myhostname） |
设备客户端（waiter / GUI 主进程 / 嵌入式固件）用的正是系统解析器。
实测 waiter 报「lookup devices.localhost on 192.168.2.1:53」。
因此**两处**设计变更：
1. 发现端点同时返回两种形态，并标 preferred：
- url（子域）—— 浏览器用
- url_portal（门户同源，同一 host、同一端口，走路径挂载）—— 非浏览器用，
无任何 DNS 依赖
2. SDK 的 ProxyDecl 新增 **Path**（路径挂载前缀）：让同一服务同时挂到
门户自身 host 的路径下。remotedevice 声明 Path="/api/v1/device"，
设备客户端因此能沿用**它已硬编码的路径**，不需要知道反代存在。
路径挂载语义：请求路径**原样保留**（不剥前缀），上游按真实路径注册即可。
边界卡在路径分隔符上（/api/v1/device 不匹配 /api/v1/devicefoo）。
## 客户端
- **waiter**：新增 discoverGateway()，仅在用户配了门户地址时尝试，失败回退
自配地址（老版本 HomeAgent 无该端点）。抽出 normalizeGateway() 纯函数，
显式钉住「已带子域/完整端点的地址不得被改写」。
- **GUI**：renderer 新增 loadDiscoveredGateway()，renderDeviceChannel 优先用
发现值、回退旧口径。顺带修掉此前插入函数时 anchor 不匹配导致调用点
找不到定义的问题。
- **鸿蒙**：discoverGateway() + resolveGatewayUrl()，优先 url_portal。
- 三者都**优先 url_portal**（system resolver 的现实约束）。
## 遗留路由鉴权修正
`/api/v1/device/` 的旧路径反代原被 requireAPI 包裹 —— 但其调用方是设备
（带设备令牌而非门户凭证），套上门户鉴权会把它们全挡在 401（**真实实测**：
waiter 经此路径升级握手 401）。去掉这层包装，鉴权交给上游 remotedevice
自己的 requireToken，安全性不降级。
## 判据
webui +6 条、waiter +7 条。
★ 其中一条是**真实回归**：/api/v1/device/gateway 曾被 Path="/api/v1/device"
的路径挂载接走（那服务 auth=none），于是发现请求被转给上游、回 401，
客户端再也发现不到网关。修法是发现端点先于路径挂载判定，并补判据
（走完整生产链，同时确认同前缀的真实设备路径仍归反代）。
## 真实验收（隔离实例，命名 netns + 独立 data + 18080）
真 waiter 客户端 + 真 remotedevice 网关：
device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
device bridge active: waiter-mainserver authorized=true
hello_ack / bind_ack 均经反代往返成功
说明：`bind_ack device=<nil>` 与在线列表为空的现象，**直连 9890 绕开反代
完全一致复现**，属 remotedevice 与 waiter 之间既有的握手细节，与本次
反代改造无关（反代侧职责已证：连接建立 + 双向帧往返都通）。
2026-09-26 13:49:59 +08:00
46ce92618c
chore(version): 客户端版本与内核对齐（唯一事实源 internal/meta.Version）
...
此前三份版本号互不相干：内核 1.4.0、GUI 1.0.0、鸿蒙 1.1.1。手工各改各的
必然漂移，所以把「对齐」做成机械动作而不是约定：
- deploy/scripts/sync-client-versions.sh：从 internal/meta.Version 读版本，
同步 cmd/gui/package.json 与鸿蒙 AppScope/app.json5（versionName +
versionCode=X*1e6+Y*1e3+Z）；--check 给 CI/Makefile 做漂移门禁。
- Makefile 新增 sync-client-versions / check-client-versions；build-cli 也注入
LDFLAGS，waiter 与 homed 同版本。
- 鸿蒙：新增 common/AppVersion.ets，从 bundleManager 读安装包 versionName，
BridgeProtocol/BridgeCaps 里两处硬编码 '1.1.1' 改为读它——版本只剩
app.json5 一份，杜绝第二真相。
- waiter：`-version` 打印版本，启动横幅与设备桥 hello 的 version 字段
直接引用 internal/meta，与内核天然同源。
对齐后：GUI 1.4.0 / 鸿蒙 1.4.0(1004000) / waiter 1.4.0 / 内核 1.4.0。
2026-09-15 11:03:26 +08:00
9b78edd810
feat(gui+ohos): 同步阶段管道工具格「只滚动展示最新一条调用」
...
WebUI 已改为工具格只露最新一条。桌面版与鸿蒙端是同一套运行态面板的
镜像，一并跟上，避免三端口径不一致：
- cmd/gui：renderRuntimePanel 工具格只渲染最新条目 + 本轮累计次数；
overview 是整块 innerHTML 重建，故动画类由 state.toolFlash 单次驱动，
避免任何重渲染都闪一下。
- cmd/ohos：RuntimePanel 工具格改为 latestEvent() + totalCount()，
不再 ForEach 追加。已用 hvigor 实测 BUILD SUCCESSFUL。
2026-09-14 20:09:57 +08:00
607d081afc
feat(gui+ohos): 同步 WebUI 总览改版 —— 桌面版补运行态面板，两端补内核身份与开源许可
...
WebUI 那边这几轮改完，桌面 app（Electron）与鸿蒙 app（ArkTS）要跟上。
先摸了底：**两个 app 此前都没有运行态面板**（阶段管道 / 中断队列），
所以这不是"移植"，是新做；emoji 图标两端本来就没有，无需处理。
## 桌面 app（cmd/gui/renderer）
1) 运行态面板（新）—— 与 WebUI 同一套设计语言：**等大表框**
- 数据源 /api/v1/runtime（此前只拉 /status 与 /kernel）。
- 四个数字块沿用本 app 的 statCard（排队/中断/栈/子代理）。
- 阶段管道：5 个等大框，框内是本阶段本轮发生的事件 chip；
当前阶段整框点亮。图标一律内联 SVG（含「工具会循环」标记）。
- 中断队列：5 个等大框（L4/L3/L2/L1 + 排队）一行排开，
级别名 16px/800、深度 26px/800、可见格槽（0 时也有形状）；
有积压整框描边点亮；排队队列虚线框区分（另一类别，不是另一优先级）。
- stage SSE 事件接上轨迹（rtTrailPush，同阶段同一条累加 xN），
2.5s 无新事件回空闲。
- 列宽 repeat(auto-fit, minmax(100px,1fr))：窄容器也保证 5 框一行，
不出「4 个 + 1 个」的孤行。
2) 版本身份（修一个真缺陷）
旧实现是 `s.version || "0.1.0"`：拿不到数据时**向用户展示一个不存在的
版本号** 0.1.0。改为取 /kernel 的 build（-ldflags 注入的真实版本/commit），
并在版本号下补一行「内核名 · commit」。
3) 开源许可卡（新）
协议标识 + 协议全文 + 源码仓库 + §13 说明；网络条款按标识是否含 AGPL
决定是否渲染，不硬写协议名。
## 鸿蒙 app（cmd/ohos/HomeAgent）
4) StatusStore 解析 /kernel 的 build：补 内核版本 / Commit / SDK 兼容 /
构建时间 到「内核」分组；K_VERSION 统一成 v<版本>，新增 K_BUILD 广播
「内核名 · commit」给摘要卡（版本号本身没有内核身份）。
5) 新增「开源许可」分组：许可协议 / 协议全文 / 源码仓库 / 网络条款说明。
## 验证
- 桌面：共享浏览器加载 renderer（桩掉 preload 桥）后喂真实形状数据渲染 ——
版本卡 `v1.4.0+hotfix.eec2195` + `HomeAgent · eec2195`；管道
`输入=输入 | 行动=思考 | 工具=qq_get_message x3 qq* | 输出=生成 | 结束=完成`；
队列 `L4:0 | L3:3 on=3[active] | L2:2 on=2[active] | L1:0 | 排队:2 on=2[active]`；
许可卡两个链接均为 target=_blank + rel=noopener noreferrer；无 emoji。
node --check 通过。
- 鸿蒙：/opt/huawei/command-line-tools/bin/hvigorw assembleHap **BUILD SUCCESSFUL**。
## 未做（下一条腿）
鸿蒙端的运行态面板（阶段管道 + 中断队列）**还没有**。它比桌面端贵：
需要新组件（5 框管道 + 5 框队列）、把 /runtime 快照接入 StatusStore，
以及把 SSE 的 stage 事件从 ChatSse 的 sink 引到状态侧——后者是接口改动。
「状态」Tab 此前已被有意删除（并入设置页 + 二级明细），面板落点也要定
（建议放二级明细页顶部）。桌面的实现可直接作参照。
2026-09-14 18:53:25 +08:00
4905252f06
perf(webui): /chat/history 分段懒加载 + lean 瘦身模式
...
问题：/api/v1/chat/history 无分页返回全量 1.26MB（200条），移动端/弱网首屏很慢。
实测体积构成：tool_calls args/result 占 71.8%，reasoning_content 11.6%，content 仅 3.4%。
后端 handler.go：
- 新增查询参数 limit（1..maxChatHistory）/ before（游标）/ lean（瘦身）
- 全部可选，省略时返回全量 → 向后兼容旧客户端
- 响应加 total/offset/has_more，供前端判断能否继续向上加载
- lean=1 裁剪 tool_calls 的 args/result 并置 truncated 标记、省略 reasoning_content
- ChatToolCall 新增 Truncated 字段（前端可显示'详情需展开加载'而非误判执行失败）
前端 WebUI + GUI（两端同步）：
- 首屏只拉最新 40 条（CHAT_PAGE_SIZE），1.26MB → 48.5KB（lean 26KB）
- 新增 loadOlderChat()：滚动触顶（<60px）自动拉上一页，插入后按 scrollHeight 差值补偿
滚动位置避免视口跳动
- state 新增 chatOffset/chatTotal/chatHasMore
- syncChatFromHistory 改用重叠区对齐（分段后不能再用长度比较判断新增），
找不到重叠点安全退化为全量刷新最新页
实测：无参数 1287.9KB / limit=40 48.5KB / limit=40&lean=1 26.0KB；
before 游标翻页、limit 越界/非法值、before=0 等边界均正确
2026-08-28 23:21:13 +08:00
e2da804e5b
fix(gui): SSE消息同步不及时，同步webui修复
...
- 新增 syncChatFromHistory()：增量同步，仅追加新消息不重建已有DOM→无闪烁
- handleSSEEvent 监听 sync_required 事件 → 增量补拉历史
- SSE 断连(pump退出)后先 syncChatFromHistory 补偿再重连
- startUptimeTicker 增加30s轮询兜底（补偿跨渠道消息丢失，CLI连接跳过）
2026-08-27 11:29:20 +08:00
f18587a01c
fix(remotedevice): 媒体回传落盘 + webui SSE panic + GUI 相机跨平台
...
1. remotedevice 媒体落盘（核心改动）
设备录像/照片二进制聚合后写入 <data>/device_media/<reqID>.<ext>，
cmd_result 返回 file 路径，不再 base64 内联——10s 录像数 MB 的
base64 会撑爆 LLM 上下文与工具结果管道。未配置目录时保持旧内联行为。
新增 TestWSBinaryMediaToFile 覆盖。
2. webui SSE 'send on closed channel' panic（生产单日 4924 次）
handleChatEvents 的 defer close(writeCh) 与 Subscribe 回调闭包竞态：
handler 退出后总线仍可能异步触发回调向已关闭 channel 发送。
改为 writer goroutine select on done 退出，不 close channel；
defer 中等待 writerDone 保证无残余写入。
顺带补 mockPluginMgr.StopAndUnload（614e88f 接口变更漏改测试）。
3. GUI camerasue 平台分支
ffmpeg 参数原硬编码 Linux v4l2(/dev/video0)，Windows 上必然失败。
现按平台探测：win32=dshow(枚举设备名取第一个视频设备)、
darwin=avfoundation、linux=v4l2；录像编码 Windows 交给 mp4 muxer 默认。
2026-08-26 01:25:40 +08:00
618f51a136
fix: 流式渲染回合生命周期 + LLM 瞬断重试与 SSE body 兜底
...
问题一（webui 不是真流式）：
- sendChat 的 finally 在 POST 结束(15s ackTimer abort)时就复位
chatLoading，但 agent 生成窗口 15~190s，后续 SSE delta 全部走
全量重建路径、停止按钮提前消失、用户误发重复消息。
- GUI app.js 完全没有 content_delta/reasoning_delta 监听器，
只能等聚合帧一次性显示。
修复：三端统一回合生命周期——POST 只是触发，收尾由 SSE 驱动：
- dashboard/GUI 新增 endChatTurn/armTurnWatchdog；拿到同步兜底
响应立即收尾，否则保持回合打开等 agent_output final / reset 帧 /
120s watchdog 兜底
- GUI 补齐 delta 监听器；agent_output 聚合分支 += 改覆盖；
reasoning 聚合帧改覆盖（多轮工具调用时旧逻辑会重复累加）
- agent_output 误杀分支（final 无 source 即 return 丢弃新输出）
改为内容比较去重，多轮连发时新一轮回复不再被吞
- waiter reasoning_delta reset 从清空全部消息改为 sealLastAgent
问题二（三条只成功一条）：
- handleChat 60s ctx 含排队时间，agent 串行处理下第 N 条必超时
（实测第 3 条 62s 超时 504）；放宽到 300s（客户端 abort 时立即取消）
- LLM 单 provider 瞬断无重试：process.go provider 循环内加同源
重试（2 次、退避 2s），401/403 凭证错误与用户中断不重试
- llmsproxy auto 链在非流式请求下可能返回 SSE body（上游恢复后
吐已生成的 chunk 流），非流式解析报 invalid character 'd' 丢掉
整段回复；新增 parseOpenAICompatibleSSEBody 拼接为完整响应
- 顺带修 normalizeStreamToolCalls 分片续传 bug：name 不重发时
argsRaw 被顶层 Arguments(nil) 覆盖丢失 function.arguments
验证：
- 连发 3 条 + 单条共 4 条全部成功（首条 190s 重试扛住瞬断）
- sse_body_test.go 锁定 SSE body 解析契约（content/usage/tool call 分片）
2026-08-25 12:24:11 +08:00
91eff27b0a
feat(streaming): token-level delta events + interrupt for CLI/WebUI/GUI
...
Expose the LLM token-level streaming deltas (EventReasoningDelta /
EventContentDelta) to every client channel and add user-initiated
interrupt (cancel generation / send interrupt message) to all three
frontends, preserving the existing interrupt-injection semantics.
SDK/events:
- EventReasoningDelta, EventContentDelta constants exported in the
public/internal SDK event alias tables.
CLI plugin:
- handleChat subscribes to both delta events and forwards
reasoning_delta / content_delta JSON frames (channel-filtered);
aggregated reasoning/tool_call/response frames still fire as before.
- New /stop (alias /interrupt) builtin injects an interrupt via
InjectInterrupt(cliSource, cliChannel) - matches interceptLoop
semantics: cancels an active stream and re-injects the message as
a [中断消息] for a restarted turn; with no active LLM it behaves
as a plain input.
Waiter client (line mode + TUI):
- streamRender accumulates delta chunks and redraws the current line;
a reset frame (stream abandoned, e.g. user interrupt) flushes the
partial buffer so the next turn does not concatenate onto stale
content. Aggregated frames terminate the delta line and render the
final text (old servers without deltas behave exactly as before).
- TUI merges content_delta into the in-flight agent message and seals
it (final flag) on response/tool_call/error so subsequent deltas
never append to a finished message.
WebUI:
- SSE handler subscribes to the two delta events but does NOT record
them into the replay ring - reconnection replays only aggregated
events (the final truth), avoiding duplicate delta accumulation.
- POST /api/v1/chat/interrupt calls InjectInterrupt(webui, webui)
with optional message; fronted by a Stop button shown only while
a generation is in flight.
dashboard.html / GUI app.js:
- Stop button next to Send (hidden until chatLoading); interruptChat
POSTs /chat/interrupt. Delta listeners append incrementally;
agent_output (aggregated) now replaces (not appends) the in-flight
content and marks _final; reset frames finalize the partial message.
process.go:
- chatStreamWithFallback preserves the context.Canceled/
DeadlineExceeded contract: a user interrupt returns the canceled
error (never a partial-content success) so the existing continue
branch restarts the turn with the [中断消息]. A reset
EventContentDelta is published so connected clients drop stale
partial renderings before the new turn begins.
Verified: /stop 'msg' via waiter triggers 'interrupt from cli/cli' in
interceptLoop; unit TestChatStreamCancelPreservesInterrupt confirms the
canceled error propagates instead of being swallowed.
2026-08-25 10:50:37 +08:00
17a2c7b7ee
feat: 设备鉴权迁移至客户端 + 插件卸载保护
...
安全修复（客户端鉴权）：
- remotedevice 服务端移除授权状态存储（authorized map/SetAuthorized/handleDeviceAuth）
- DeviceMeta.Authorized 改为设备 hello 自报，服务端仅透传展示
- device_ctl_* 工具移除服务端授权检查，无条件转发，设备端自行决定是否执行
- 共享设备桥库 Bridge 新增本地 authorized 状态，未授权收到 cmd 直接拒绝
- waiter: --device-authorized / device_authorized 配置控制本地授权
- GUI: 授权存 gui-prefs 本地文件；设备页仅本机可切换开关
- webui /device/auth 旧路径返回 410 Gone
- 根因：agent 可经 config_set 篡改服务端授权配置自行授权设备
插件管理强化：
- 内置插件禁止卸载（IsBuiltinPlugin + 409），外部插件卸载即时生效
- 卸载不存在插件返回 404；移除误导性 reload_required 提示
- webui 插件路由：名称白名单校验防路径穿越、保留字路径保护
2026-08-24 19:26:11 +08:00
2ff911b194
feat: SSE Last-Event-ID 断线重放 + GUI 表单防刷新
...
- webui handler: 新增 sseEventRing 环状缓冲区(200条)，断线重连按 Last-Event-ID 重放遗漏事件
- GUI app.js: doRenderAll 检测连接表单打开时改走 refreshDataOnly，修复 15s 定时器擦掉用户输入的 bug
- 附带 dashboard.html/index.html 前端调整 + handler_sse_test.go 单测
2026-08-24 16:22:28 +08:00
b0d6f10522
feat: 设备桥共享库 + CLI全能力补齐 + GUI omniparse/computeruse 重构
...
- 抽取设备桥 WS 协议层为共享库 (internal/devicebridge/client/)
- CLI 补齐 11 项 caps 能力(screensee/screensue/speakeruse/camerasue/...)
- GUI 新增 omniparse 能力(Windows UIA 窗口解析)
- GUI computeruse 改用 koffi 直接调用 user32.dll，不再依赖 PowerShell C# 编译
- GUI computeruse JSON 解析兼容非标准格式 {x:500,y:300}
- 新增 mock-server 用于本地测试设备桥协议
- 新增 GUI DLL 桥接模块 (devicebridge_dll.js)
2026-08-23 20:17:38 +08:00
fb52e4a534
gui: hello caps 补全 screensee/clipboardsee/clipboardsue 能力声明
2026-08-21 20:03:49 +08:00
ab8bcd7478
gui: 新增 clipboardsee/clipboardsue 剪切板读写能力
...
- clipboardsee: 读取设备剪切板文字(clipboard.readText), 回执 output 为文字, content=ok/empty
- clipboardsue: 写入文字到剪切板(clipboard.writeText), 回执含写入字节数+预览
- 与服务端 c021828
2026-08-21 16:43:53 +08:00
577968e9e9
gui: 新增 computeruse 能力(agent 跨平台控制鼠标键盘)
...
- executeHomeagentCmd 加 case computeruse: 参数 JSON {x,y,action,button,text,key}
- action: click/move/doubleclick/rightclick/scroll/keypress/type
- 跨平台: Linux=xdotool, macOS=cliclick(及osascript输入), Windows=PowerShell user32
- 坐标基于 screensueDisplay 目标屏幕原点偏移
- caps 增补 computeruse
已装本机 xdotool 备测
2026-08-21 16:40:18 +08:00
5fd532af38
gui: 新增 screensee 能力(agent 查看远程设备屏幕)
...
- executeHomeagentCmd 加 case screensee: desktopCapturer 截屏 → toJPEG(80) → data:image/jpeg;base64 回执
- 屏幕选择沿用 gui-prefs.deviceBridge.screensueDisplay, 越界回退主屏
- 输出格式与 camerasue 抓拍一致, 服务端视觉模型可直接分析
- 空源/空缩略图/异常均有 error 回执
对应服务端 28019a6
2026-08-21 16:40:18 +08:00
adc99b976f
gui: speakeruse 支持声卡选择(设备通道可配输出设备)
...
- playDeviceAudio 按 gui-prefs.deviceBridge.audio.device 用 aplay -D <dev> 播放
- 新增 audio:list IPC(aplay -L 枚举) + preload 暴露 audio.list
- renderer 设备通道新增 speakeruse 声卡下拉, 保存到 prefs
- 排除 hw: 裸设备(mono->stereo 需转换), 只留 default/pipewire/pulse/plughw
- 修复 USB 声卡无声音: mono WAV 播到仅立体声设备失败, 改用 plughw 自动转换
已用 mock 网关 + 源码直跑验证: voice -> via plughw:CARD=Audio,DEV=0 播放成功
2026-08-21 16:40:18 +08:00
564826f658
feat: screensue 默认 5s 超时，agent 可指定时长或永不超时
...
- GUI main.js: screensue 默认 duration 从 0(常驻) 改为 5 秒自动关闭
- 命令带数字 token 指定时长: "screensue 30 内容"=显示30秒
- 命令带 0 表示永不超时: "screensue 0 重要公告"=常驻直到用户手动关闭
- gui-prefs.screensueDuration 用户配置默认值(未配置时 5)，命令参数优先级最高
- 设置页(app.js)新增「默认时长(秒)」输入框(placeholder 提示 0=常驻)
- 回执文案区分 for Ns / persistent until closed
- 服务端 device_ctl_cmdrun 工具描述同步更新(5秒默认/指定秒数/0永不超时)
2026-08-21 12:10:28 +08:00
49ca8d6222
gui: 自动重登/定时授权/副屏修复 + 排障(大量JS报错根因是cookie过期)
...
排障: "大量JS报错"真实根因 = webui cookie 会话24h过期 → 所有 api() 请求经网关 302 → 返回登录页HTML(200非401) → renderer 拿HTML当JSON解析 → 界面持续报错/乱码
修复(api() 自动重登):
- 401 或检测登录页HTML(THEME_PLACEHOLDER/统一门户登录)时自动 syncConnAuth 重登后重试一次
- 防递归锁 _haReloginLock
- JSON解析容错(HTML不再误报)
定时撤销/恢复授权:
- prefs.deviceBridge.authSchedule {enabled, revokeTime, restoreTime}, 支持跨天(23:00-07:00)
- 主进程每分钟检查, 到点经 webui 反代 /api/v1/device/auth 撤销/恢复(防抖状态机)
- 设备页UI: 开启开关 + 撤销/恢复时间输入(保存并应用生效)
- setDeviceAuthorized 优先 authRule, 否则从 connections.json 取 URL+cookie
副屏修复:
- displays:list 对空 label(' ') trim 后显示 显示器N
- 修复 loadGuiPrefs 只返回3字段导致 screensueDisplay/exec/authSchedule 被抹掉(保存后变默认的根因)
其他:
- 移除远程调试端口(9223, 排障用)
- 保留 window.onerror/onunhandledrejection 透传(gui.log 可见 JS 错误, 便于运维)
2026-08-20 13:29:21 +08:00
6e691710b2
gui: 设备命令/能力完整实现 + 二进制分块 + 消息ID去重 + 交互优化
...
设备命令执行对齐服务端 cmd_type 契约:
- onDeviceMsg 解析 msg.cmd_type: homeagent->能力分发 / shell->白名单执行
- 统一回执 sendCmdResult(兼容双参), 全链路回执修复
- 修复 pi-lens auto-fix 把 trayLastCmd 改 const 导致的 TypeError(命令未执行/无回执根因)
homeagent 能力:
- screensue: 独立窗口显示文字/HTML, 可配默认屏幕(displays:list IPC), 支持时长参数 "screensue [秒] 内容", 默认常驻
- camerasue: 抓拍单张 jpeg(base64文本); camerasue <N秒>=录像 mp4(libx264), 二进制分块经设备通道回传
- speakeruse: 接收服务端二进制音频(WS 0x2), 聚合后播放(aplay/paplay/ffplay/afplay/SoundPlayer)
二进制分块协议(设备<->网关):
- 录像(设备->网关): cmd_data_start/0x2帧/cmd_data_end
- 音频(网关->设备): cmd_speech_start/0x2帧/cmd_speech_end
- 设备端 WS 读写侧都支持 0x2 帧; N/A 服务端 readFrame 需配套(已发群)
消息重放/交互:
- sendChat 带 client_msg_id 唯一ID(服务端可去重), 超时明确提示勿重复发送
- 托盘菜单: 信息项 enabled(不再灰字)+200ms防抖+连接缓存, 首建立即弹出
- 托盘显示连接/设备桥/远控活动状态
UI:
- 设备页本机卡片: 设备通道配置(网关/ws_token/screensue屏幕/cmdrun目录/沙箱)
- 设备列表经 webui 反代 /api/v1/device/online 拉取
- 连接管理移除 device 类型(设备独立为 GUI 组件), toggleConnType/saveConnForm 清理
- 字体对比度提升(text-muted/secondary重调色), 内联小字 10/11px->12/13px
preload: 新增 displays.list IPC
2026-08-20 09:07:41 +08:00
32f2193e35
gui: 托盘菜单增强(连接/设备桥/远控状态) + 设备页 dot 修复
...
托盘右键菜单(rebuildTrayMenu, 动态刷新):
- 后端连接: 名称 + URL + [已连接]/[未连接](authRule 判定)
- 设备桥: [已连接]/[未连接] + 设备ID + 网关地址
- 远控活动: 上次远控命令 + 结果(输出前40字) + 总次数(收到 cmd 时记录, 回执后更新)
- 刷新时机: 启动 / connections add/update/delete/setCurrent / hello_ack/bind_ack / cmd 到达与回执
- 纯文本不用 emoji
设备页方形外框修复(根因: .dot-* 只定义 background 无尺寸, 直接包文字成整块色块):
- app.js: 状态/授权改为 <span class="dot-green"></span>+文字(本机卡片+设备列表4处)
- style.css: .dot-* 补 inline-block 8x8 圆角, 空 span 呈现小圆点
2026-08-18 09:37:05 +08:00
80764b4a4a
gui: 设备桥完整链路修复(URL解耦+wss TLS+cookie回退+onDeviceMsg)
...
问题: 设备桥此前硬编码 127.0.0.1:9890 + /api/v1/device/ws 路径, 无法连远程 homed wss; startDeviceBridge 内部仍有 conn.type!=='device' 旧条件导致 prefs 驱动永不启动; onDeviceMsg 缺失导致引用未定义。
修复:
- connectDeviceWS: 支持完整 ws(s):// 端点 URL(含路径/端口), 不再硬编码 host/path; wss/https 默认 443, ws/http 默认 9890
- connectDeviceWS: TLS 支持(devTls), cookie 注入优先 connections.json 完整登录串(authRule 浏览器快照可能不完整)
- startDeviceBridge: 移除 conn.type!=='device' 拦截, 兼容 prefs 驱动 {url/token}; whenReady/device-bridge:set 已对应
- 补全 onDeviceMsg: 处理 hello_ack/bind_ack/cmd(白名单 argsSafe 执行+cmd_result 回执)
- no-proxy-server 开关(本机 clash 代理干扰 wss), 错误日志带完整响应体便于排障
卡点(已发群): 雷池 SafeLine 按 TLS 指纹(JA3)拦截 Electron BoringSSL → 403; node/python OpenSSL 同请求 101。需服务端雷池放行 /api/v1/device/ws 或 Electron 指纹白名单。
2026-08-18 08:51:56 +08:00
30e51fcb8b
feat: webui 设备网关 WS 反代(hijack 双向透传) + GUI 设备页本机卡片始终显示
...
- handleDeviceGatewayProxy: 识别 Upgrade:websocket 请求, 用 http.Transport(保留升级连接)
+ hijack 双向字节透传, 支持远程 homed 的 WS 设备通道(REST 已可用, WS 之前被 DefaultClient 卡死)
- renderDevices: 本机 GUI 设备卡片不再被 conn.type!=='device' 挡住,
由 gui-prefs 的 deviceBridge 驱动(独立于连接), renderInit 从 device-bridge:get 拉取本机身份
- 对应 pi-desktop 排查记录(WS 反代不可用/本机卡片被挡)修复
2026-08-17 18:02:16 +08:00
9eca20c6dd
gui: 性能修复(星图/reasoning/渲染循环)+设备桥配置解耦(独立prefs+IPC)
...
性能(卡死修复, 已部署本机验证 GPU 91%->14%):
- reasoning_content 懒加载: 折叠正文不再 marked.parse, 点击展开时才解析
- 星图动画仅"星图"子面板激活才跑, 12fps限制, 关抗锯齿+pixelRatio=1, 粒子3000->1200
- renderAll/refreshAll 非chat视图跳过聊天整块重建
- switchView(chat) 多段延迟滚动到底部(修复进入停在顶部)
设备桥(配置与连接解耦, 为远程homed被控做准备):
- 设备桥改由 gui-prefs.json 的 deviceBridge{enabled,gateway,token} 驱动, 不再依赖 type=device 连接
- 新增 IPC device-bridge:get/set (状态查询+动态启停), preload 暴露 deviceBridge API
- whenReady 按 prefs 启动设备桥
待后续: 设备页UI入口(renderDevices 本机卡片仍被 conn.type!==device 条件挡住, 需改为始终显示+调用 device-bridge:set)
2026-08-17 17:35:47 +08:00
c36ac7e3a2
device gateway: remotedevice 插件(设备接入网关) + GUI/waiter 受控设备桥 + 设备页/授权开关/托盘/退出进托盘 + 白屏修复(惰性Tray) + deviceinfo 工具
2026-08-17 09:34:25 +08:00
378a749aa9
gui+webui: 聊天界面升级(PiDeck风格思考/工具卡片+滴入动画) & 流式卡顿修复(防抖局部增量渲染) & 主题系统修复(启动恢复色板/弹窗溢出wrap)
2026-08-16 09:57:29 +08:00
4d38abe37b
gui: 修复总网关认证(host域cookie注入+session.fetch登录+sl-session合并) & 连接持久化完整字段+网关徽标; vendor 本地 three.js 备用
2026-08-16 08:17:34 +08:00
2dc52086a4
gui: renderChat 增加防护与日志; log:r 改 invoke; 修 SSE 流式丢失气泡; chat 布局 overflow 修复
2026-08-15 09:03:07 +08:00
098579014c
gui: 多主题外观(6色板/背景图缓存)/连接认证(总网关登录窗自动抓Cookie)/中英切换/插件禁用
2026-08-14 16:14:20 +08:00
98e7ceb343
fix: output_send 气泡时序(chatFinalIdx 插入)与 channel_output 后流式丢失
2026-08-14 00:58:41 +08:00
8160bbf3e9
fix: LLM 工具循环 400、中断消息注入、ConPTY 终端支持
...
- agent: 工具轮请求尾部补 user 占位(zen 网关强制),tool 消息正确配对
- agent: 工具提醒/中断以 system 角色注入并带 [中断消息] 前缀,不进用户履历;系统提示词说明中断消息格式
- agentcli: 基于 ConPTY 的交互式终端(ptywin fork),terminal_create/read/write/resize/close/watch
- webui: server 输出通道适配器(保留 reasoning_content/disable_thinking)
- GUI: 沉浸式标题栏、icon 圆角重制、mascot 等打磨
2026-08-14 00:48:40 +08:00
a68ff2106d
feat(sdk): add RegisterStopHandler/RunStopHandlers and wire stop cleanup into registry lifecycle
...
- SDK PluginSDK gains RegisterStopHandler(fn func()) + RunStopHandlers()
(LIFO, idempotent, cleared after running); synced to third_party copy
- Registry keeps per-plugin SDK refs (sdkRefs); StopAll/ReloadOne/
DisablePlugin run handlers before calling Stop()
- timer built-in plugin demonstrates handler-based shutdown cleanup
- z_bridge (linux/windows templates) runs handlers before plugin.Stop()
2026-08-02 10:23:40 +08:00
b635e26d75
fix(webui): capture all-channel chat history and correct input source
...
- handleChat now injects with source=webui so the LLM no longer sees
cli as the input channel
- subscribe to EventRawInput/EventAgentOutput to persist every
conversation turn from all channels (cli/qq/webui), replacing the
manual webui-only addChatMsg to avoid duplicates
- ChatMsg gains a source field; GUI shows a channel badge for
non-webui messages
2026-08-01 14:06:18 +08:00
