|
|
d202f2ceec
|
feat(ohos): screensue 改用 Web 组件渲染 HTML（RichText 撑不住）
用户实测截图：推送内容把整段 HTML 源码当字符串显示（含 <style>、@keyframes、
内联 <svg>、radial-gradient）。RichText 只认极小标签子集，这些一律不渲染。
用户明确要求「引入 webview」。
## 修法
- 新增 `common/ScreensueHtml.ets`（从 BridgeCaps 抽出：后者加进 HTML 逻辑后
超 520 行，越了工程「单文件 ≤400 行」的约定；且「screensue 怎么解析/渲染」与
「设备能力怎么实现」本是两件事）。
- `ScreensuePage.ets`：HTML 走 **Web**，纯文本仍走 Text。
- 加载用 `loadData(base64)`：encoding 非 base64 时按 URL 规则转义，几 KB 的
完整文档会撞长度/转义问题。自写 `base64Utf8`（UTF-8 手编字节，含代理对合成）
—— 直接把 UTF-16 码元交给 Base64Helper 会让中文变乱码。
- 非完整文档补一层 shell（meta viewport + 主题前景色），完整文档原样加载。
## 顺带修掉一个真实缺陷（实测发现）
`looksLikeHtml` 旧判据要求「首个非空字符就是 '<'」。而 agent 传参常把整段文档
连引号一起给（`'<html>…'`）——截图里那个孤立的 `'` 就是这么来的，判据因此
**判否并退回纯文本**，所以看到的是源码。改为扫第一个「像标签开头」的 '<'
（跳过引号/前导文字），且只在其后紧跟字母或 '/' 时才算，避免误判 "a < b"。
Node 复刻同一算法验证了 7 个样例（含截图实况、<3 表情、比较符）。
## 安全（我因为引入 WebView 而必须自己把关）
内容来自 agent（第三方）。显式关闭：
`javaScriptAccess(false)` / `fileAccess(false)` / `domStorageAccess(false)` /
`onlineImageAccess(false)` / `zoomAccess(false)`。
★ **javaScriptAccess 的默认值是 true** —— 不显式关掉等于让远端内容在客户端执行脚本。
已实测取证：推入带 `<script>` 与 `<img onerror>` 的页面，屏上稳定显示 `JS-OFF`，
两条执行路径都没跑起来。
## 另一个实测发现的缺陷
`onControllerAttached` 只在挂载时触发一次，而 ScreensuePage 在 `if (visible)`
里常驻 —— 连续两条 screensue 只改 @Prop、组件不重建，Web 一直显示**上一条**
内容（实测：倒计时变成 33s 但画面还是旧 HTML）。改 `@Prop @Watch('onDataChanged')`
显式重载，并记录 attached 状态避免过早 loadData（会抛 17100001）。
## 验证（模拟器真机链路）
把工程内连接指向本机服务、开启「允许 agent 控制本机」授权，经
`device_ctl_cmdrun` → 设备桥 → screensue 推入用户截图里那段原样 HTML：
- 渲染成功：radial-gradient 背景、内联 SVG 兔子、CSS 发光文字、两行文案
（修复前同一段内容显示为满屏标签源码）
- 连推第二条 → 画面正确刷新为 SECOND PUSH
- JS 探测 → JS-OFF（脚本被拦）
模拟器只能装 unsigned 包（signed 报 READ_PASTEBOARD 授权失败，与既有记录一致）。
|
2026-09-18 12:01:33 +08:00 |
|
|
|
ccc2ac2d4d
|
fix(stop): 停止按钮真正生效——停止 ≠ 空中断；鸿蒙 screensue 支持 HTML
两处鸿蒙端缺陷 + 一个跨端（WebUI/GUI/鸿蒙）的停止语义缺陷。
## 症状（实测取证）
1. **鸿蒙终止按钮按下没反应**。POST /chat/interrupt 带空 body，接口回 200
`{"status":"interrupted"}`，但 journalctl 零中断日志、生成继续跑到自然结束。
2. **鸿蒙 screensue 不解析 HTML**，把标签当普通字符串显示。
## 根因
停止按钮走的是「空内容中断」，而 interceptLoop 有一行
`if text == "" { continue }` —— 空内容被判为「无事发生」直接丢弃。
所以停止指令从未到达调度器；接口那个 200 是不诚实的。
另查明两条会放大症状的既有问题（停止后仍在跑）：
- `chatStreamWithFallback`：流式连接失败时无条件回退非流式 `Chat`。
上下文已取消时这等于**再发一次完整请求**（停止后模型继续生成）。
- `stepLLM`：`context.Canceled` 一律 `outcomeContinue` 重跑本步。
这是给「被更高中断抢占」用的（现场要交出去、稍后继续），
但用户按停止是「不要了」，重跑就是停止没生效。
## 修法（按用户明确的设计）
停止 = ①立即结束当前 LLM 推理（不重试、不恢复）；
②对**停止那一刻已排队**的 x 条消息，后续在 pre-action 阶段依次短路。
- scheduler：新增 `armStop`（登记快照配额并返回当时排队深度）/`takeStop`/
`consumeCancel`。配额取快照值（停止后新到的输入不受影响），
重复按停止取 max 不累加（两个客户端同时按不该翻倍）。
- `interceptLoop`：读 `stop` 标记。停止时 armStop + cancelCurrentLLM；
**纯停止不再进中断队列**（旧实现把它当空中断入队，所以停完还会活）。
带注释的停止（`/stop 换个话题`）仍走中断路径。
- `stepLLM`：取消 + `takeStop()` → 直接 `outcomeDone`（不再重跑）。
- `stepPrepare`：`consumeCancel()` 命中即在 pre-action 短路收尾。
- `chatStreamWithFallback`：以 **ctx.Err()** 为判据拒绝回退（不是「错误是不是
Canceled」——很多 provider 用 Canceled 表示「不支持流式」，那种必须继续回退，
否则会把探测误判成取消；这条区分是跑全量测试时才暴露的）。
- WebUI handler / CLI `/stop`：空消息时带 `stop:true`。
## 鸿蒙端
- `BridgeCaps.ets`：新增 `looksLikeHtml`（首字符 '<' + 字母开头标签名，
避免误判 "<3" 这类文本）、`screensueHtml`、`escapeHtmlText`。
- `ScreensuePage.ets`：HTML 走 **RichText**（只解析 HTML 子集、无脚本无网络），
纯文本仍走 Text。不用 Web 组件：agent 下发的是第三方内容，
Web 默认带 javaScriptAccess/fileAccess，等于让远端内容在客户端执行脚本。
注入主题前景色，避免 RichText 用系统默认色导致深色主题下黑字不可见。
- `ChatSession.ets`：`interruptChat` 改发 `{stop:true}`（含类型声明，
ArkTS 禁止无类型对象字面量），并在本地即时复位忙态 + 提示「已停止」。
## 验证
- 新增 `stop_semantics_test.go`：停止终结任务不重试（provider 调用次数恒为 1）、
配额是快照（x 条短路、随后新到的不受影响）、重复 arm 取 max。
- `go test ./internal/... ./cmd/...` 全绿。
- 鸿蒙 HAP 构建通过；unsigned 包已装进模拟器（signed 包受
READ_PASTEBOARD 授权限制装不上，与既有记录一致）。
|
2026-09-18 11:26:12 +08:00 |
|
|
|
831bd2290b
|
fix(ohos): 聊天改用 seq/after 增量轮询，修「不滚动/己方消息不显示/新消息不加载」
jianf 报的三个现象其实同一个根因：WebUI 前端在 commit 9711177 已改为
「暴露数据查询 API + 前端轮询 patch 视图」，聊天记录走 /chat/history?after=<seq>
增量游标 + seq 对账；鸿蒙端一直只做**首屏全量加载**，没跟上这套口径。
1) 页面不加载新的聊天信息（根因）
鸿蒙只在 aboutToAppear 拉一次 /chat/history?limit=40，之后除了 SSE 就没有
任何拉取。SSE 只在「本端发起的那一轮」推事件，其他端/其他渠道（QQ、
WebUI 浏览器）发来的消息永远不会出现在鸿蒙页面上。线上实测：鸿蒙
IP（61.54.104.206, auth=api-key）最后一次请求停在 9/17 22:34，此后
只有浏览器 session 在轮询。
2) App 发出的消息不显示
原来靠 mergeHistoryWithLocal 按「正文内容」去重：本地乐观 user 消息
与服务端回显内容一致就被判重复丢弃；同一句话发两次同样误删。
改为按 seq 对账（新增 reconcileServerMsgs，对齐 WebUI applyServerMessages）：
服务端带 seq → 有则原地更新、无则认领本地无 seq 的同类乐观消息；
旧后端无 seq 才退化为内容比对。
3) 加载完不滚动、停在最新消息处
@Watch 只在值**变化**时触发，不触发初始值。ChatPage.aboutToAppear 里
loadHistory() 是异步的，若它在 ChatStream 构造之前就完成，
requestScroll 递增的 chatScrollRev 就成了「挂载前已发生的变化」——
onScrollReq 永不被调，于是停在顶部/中间。
修：ChatStream.aboutToAppear 见已有消息就自己滚一次；scrollToBottom
的重试从 50/260ms 扩到 50..800ms（长历史布局慢，两次不够），
并用世代号作废旧一轮定时器，避免与新滚动打架。
配套：
- Model.ChatMessage 加 seq；ChatHistory 解析 seq 与 last_seq（游标缺失时
回退本页最大 seq，保证不倒退）。
- 新增 pollIncremental()：after 增量 + limit=1 尾部探测（工具卡/最终文本是
原地改写已有 seq，不产生新 seq，只靠 after 拿不到），3s 节奏与 WebUI 一致。
- startPolling 挂在 connect() 而非 loadHistory 末尾：首屏失败也能自愈。
- disconnect() 停轮询。
验证：hvigor assembleHap BUILD SUCCESSFUL；make check-client-versions 一致；
go build/vet/test 全量零失败。
|
2026-09-18 10:49:30 +08:00 |
|
|
|
1f5af1dccf
|
feat(cli,ohos): 补齐两处能力缺口——CLI /memory context|tools、鸿蒙 camerasue 录像回传
核对「CLI 与 WebUI 插件能力对齐」时发现两个此前遗漏的缺口，一并补齐。
1) CLI /memory 缺 context 与 tools（internal/plugins/cli/plugin.go）
WebUI 有 GET /api/v1/memory/context 与 /api/v1/memory/tools，CLI 只有
query/graph/text。IndexerAPI 本就对内部插件开放（BuildContext/
FormatContext/GetToolDefinitions/BuildToolPrompt），不是 SDK 缺口。
补上后与 WebUI 同源：context 打印「实际会注入什么上下文」，
tools 打印工具定义 + 工具提示词。
waiter 同步接上两条远端路由与 help 文案。
2) 鸿蒙 camerasue 录像（BridgeCaps/BridgeRouter/DeviceBridge.ets）
此前 `camerasue <N秒>` 直接返回「暂不支持录像回传」。查 SDK 后发现
cameraPicker 本身就有 PickerMediaType.VIDEO 与 PickerProfile.videoDuration
—— 录像完全可行，只是回传通道没接。
现改为：VIDEO 模式取回 mp4，经 DeviceBridge.sendDataChunked 按
cmd_data_start/分块/cmd_data_end 回传（与 GUI/CLI 录像路径一致），
网关聚合后落盘成文件、agent 拿路径；照片仍走小体积 base64 内联。
上限 64MB、时长 1~300s，超限明确报错而不是把 WS/上下文撑爆。
依赖方向处理：BridgeCaps 需要「往本请求回传字节」，但 DeviceBridge 为取
CapResult 已 import BridgeCaps，反向 import 会成环。改为 BridgeRouter
注入 DataChunkSender 回调（它同时持有 deviceBridge 与 reqId），
BridgeCaps 不碰 socket。新增 CapResult.chunked 标记「结果已由能力分块
发完」，DeviceBridge 据此不再回 cmd_result，避免网关把已完成请求与后续
分块错配。
验证：hvigor assembleHap BUILD SUCCESSFUL（ArkTS 编译通过，改动文件零告警）；
make check-client-versions 一致；go vet 干净；全量 go test ./internal/... ./cmd/... 零失败。
|
2026-09-18 10:04:53 +08:00 |
|
|
|
95b1950bb3
|
fix(ohos): 历史刷新不再整表替换，避免刚发出的消息凭空消失
sync_required 触发的 reloadHistory 会与刚发出的 POST 竞争：若历史快照
里还没有这条 user 消息，整表替换会让它消失（“客户端侧发出的消息不显示”）。
改为合并：历史为权威，但保留本地两类消息追加在末尾——
- user 且 source 为空（乐观消息）且内容未出现在历史里；
- assistant 且 !isFinal（仍在流式输出）。
|
2026-09-15 12:09:58 +08:00 |
|
|
|
307a6faee7
|
fix(ohos): 设置页插件/工具数不显示 + 聊天自动滚底时机
设置页计数（实测：后端返回 plugins=35/tools=260，卡片却一直显示 '-'）：
- 根因是 ArkUI 的 @Builder 按值传参是“快照”语义——父组件因
@StorageProp 变化重渲染时不会用新值重跑 builder，数值永远停在
首次渲染的 0。把 KPI 小卡从 @Builder 方法改为独立 @Component
（@Prop 单向下发），父组件重渲染时子组件拿到新值并重绘。
- 已上模拟器验证：设置页显示 插件 35 / 工具 260。
聊天自动滚动：
- scrollToBottom 原来只在 50ms 后滚一次；长历史/长思考卡的布局在
消息数组更新后的若干帧才稳定，一次滚动会落在“当时”的底部，
最后一条被输入区挡住。改为 50ms 与 260ms 各滚一次，480ms 后
恢复正常滚动态。
|
2026-09-15 11:56:18 +08:00 |
|
|
|
15497ee0a2
|
feat(ohos+waiter): 补 camerasue 能力；修 waiter 本地斜杠命令被当聊天文本
ohos camerasue：
- LOCAL_DEVICE_CAPS 增 camerasue；BridgeRouter 增 camerasue 路由。
- 实现走系统相机选择器 cameraPicker（三方应用无法无界面直驱摄像头），
结果落应用沙箱（saveUri=filesDir），不写系统媒体库、不需 READ_IMAGEVIDEO。
- 录像（camerasue <N秒>）明确返回“暂不支持录像回传”，而不是回一个超长
base64 撑爆上下文；二进制分块回传待接线。
waiter 本地/远端命令语义统一：
- 修 bug：/settings、/settings set、/plugin install/remove/info、
/memory query、/knowledge delete 本地分支发的是 cmd[1:]（丢掉前导 /），
于是 CLI 插件不认、被当成聊天文本丢给 LLM。改为原样发（保留 /）。
- 补 /stop、/interrupt：/help 一直写着但 handleBuiltin 没实现，会落到
“当普通消息发给 Agent”。远端走 POST /chat/interrupt，本地交给 CLI 插件。
- 补 /plugin disable|enable：远端插件管理 REST 动作，本地 CLI 插件。
- /help 文案改为“local 与 remote 行为一致”并列出新命令。
|
2026-09-15 11:12:27 +08:00 |
|
|
|
065732f42e
|
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 |
|
|
|
a9ad97240b
|
fix(ohos): 未连接后端时给出不可错过的连接入口
问题：全新安装（未配置后端）时，聊天页只有空列表+输入框，用户找不到
任何连后端的入口；设置页的连接入口在列表里也容易被略过。
改动：
- 聊天空态按连接状态分流：未连接显示「尚未连接后端服务」+「去设置连接」
按钮；已连接显示「开始新的对话」。
- 跨页信号（AppStorage：K_HAS_CONN / K_REQUESTED_TAB / K_SETTINGS_SUB）：
按钮 → Index 切到设置 Tab → SettingsPage 直接打开「后端连接」二级页。
- 设置页在未连接时主动把连接表单推到面前：窄屏 onNavigationModeChange(Stack)
直接 push，宽屏右栏默认页从「运行状态」改为「后端连接」。
- 连接增删改切后广播 K_HAS_CONN，聊天空态即时切换文案与入口。
已在手机（窄屏）与折叠展开（宽屏）模拟器验证：空态按钮可达、点击后
落到带「+ 添加」的连接表单；冷启动点设置 Tab 亦自动打开连接页。
|
2026-09-15 10:52:48 +08:00 |
|
|
|
37d6796230
|
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 |
|
|
|
f3fa0e8f5b
|
feat(ohos): 运行态面板 —— 阶段管道 + 中断队列（落在设置页二级明细顶部）
接上一条腿：桌面版已同步，这次补鸿蒙端缺的运行态面板。
落点按之前的建议放在「设置 → 运行状态」二级明细页最前：明细卡回答「内核有哪些
东西、多少」，运行态回答「现在在干什么」，后者是进这个页面最先想看的。
## 新增
- `common/StageTrail.ets`：阶段轨迹单例（SSE 驱动）。由 ChatSse 的 stage 分支
喂入，面板读取。**不并进 StatusStore**：轨迹来自 SSE 流，与 /status、/kernel
的轮询是两条独立数据源，生命周期与失败模式都不同（SSE 断连不该让状态卡变空，
状态轮询失败也不该清掉轨迹）。七阶段归并成五格，同阶段同一条累加计数，
2.5s 无新事件自动回空闲。
- `components/RuntimePanel.ets`：等大表框面板。
- 四个数字块（排队/中断/栈/子代理）
- 阶段管道：每格 = 阶段名 + 本阶段本轮事件；当前阶段整框点亮
- 中断队列：5 格（L4/L3/L2/L1 + 排队），级别色贯穿框头/槽位/描边；
有积压整框描边点亮；排队队列虚线框区分（另一类别，不是另一优先级）
- 格槽固定可见：深度为 0 时也有形状，不会剩一片空白
## 改动
- `StatusStore`：新增 `/runtime` 采集与 `RuntimeSnapshot`/`RuntimeQueue`
（明细与运行态分开取、分开存）；失败保留上一次快照，旧后端无此端点时
面板显示「运行态数据不可用」。
- `ChatSse`：stage 分支先喂轨迹，再管聊天侧角标。
- `SettingsPage`：`stageTrail.init()`。
- `StatusCards`：二级明细顶部渲染 `RuntimePanel()`。
## 关于宽度
模拟器（API 24，1256x2760 ≈ 360vp 宽）上 5 框一行会让「内核独占」这类标签被
挤成省略号，所以按项目已有的 `isWideScreen` 分两支：宽屏 5 框一行，手机 3+2
（补一个占位格保证框宽对齐）。两档都是等大框。
## 验证
- `hvigorw assembleHap` → **BUILD SUCCESSFUL**；`clean` 后全量重建，
本次新增/改动的 6 个文件 **零 ArkTS 告警**。
- 未上机实测：本机签名 profile 无法授予 `ohos.permission.READ_PASTEBOARD`
（module.json5 里已有的一项，非本次改动），`hdc install -r` 报
`error: install failed due to grant request permissions failed`。
没有为此卸载设备上的应用（会丢用户已存的连接配置），也没有改权限列表
（属产品决定）。要上机的话，我可以临时去掉那一条权限打个一次性包验证。
|
2026-09-14 19:05:46 +08:00 |
|
|
|
2163a7a092
|
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.f89e57a` + `HomeAgent · f89e57a`；管道
`输入=输入 | 行动=思考 | 工具=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 |
|
|
|
62e1e02036
|
docs(ohos): README 两处事实修正（产物路径前置条件、≤400 行约定的边界）
1. **安装小节的产物路径**：`entry/build/` 是纯构建产物、不入库，干净 clone 或清理过
工作区时该文件不存在。补明"必须先跑完第 2 步"，并说明目录名随
`-p product=<名字>` 变化、同目录还有 unsigned 版（`hdc install` 要用 signed）。
本次实际构建校验过路径：`entry/build/default/outputs/default/entry-default-signed.hap`。
2. **≤400 行约定补边界**：不到 400 行的文件不要为了拆分而拆分 ——
`@Component` 的 `build()` 只允许一个根节点，多节点 `@Builder` 改组件会多出一层
Column 包裹，布局等价是推理出来的、不是看出来的，每拆一次都要付一次
"未上机验证"的账。并记下 `pages/Index.ets`(396) 属于"不越线就不动"的一类。
无代码改动，纯文档。
|
2026-09-13 22:42:37 +08:00 |
|
|
|
8a58cde3ee
|
docs(ohos): 本地构建前置条件 + 运行时验证清单 + 工程结构表刷新
1. **oh_modules 前置条件**：该目录被 .gitignore 忽略但必须存在 —— hvigor 不会
自动 ohpm install，移走后构建直接报 arkts-no-untyped-obj-literals（依赖类型
声明缺失）且不重建目录。写明"clone 后先 ohpm install，别当垃圾清掉"，
同时说明 entry/build 与 .hvigor 是纯产物、可随时删（冷构建 ~8s）。
2. **hvigorw 绝对路径**：仓库里的 ./hvigorw 是符号链接，启动脚本按
$(dirname $0) 定位，会报 File not found: <repo>/cmd/ohos/hvigor/bin/hvigorw；
统一改用 <command-line-tools>/bin/hvigorw（本机 /opt/huawei/command-line-tools/bin/hvigorw）。
3. **运行时验证清单**：把"构建通过 ≠ UI 行为不变"这件事写进仓库而不是留在邮件里
（流式对话/思考卡与工具卡/附件上传/设置与设备与插件的二级页/宽屏分栏），
并注明无提权环境起不来模拟器时需在真机补验证。
4. 工程结构表按前几轮拆分后的实际情况刷新（common/components/pages 新增文件与职责），
并记下"单文件 ≤400 行、页面只做壳"的约定。
无代码改动，纯文档。
|
2026-09-13 22:35:29 +08:00 |
|
|
|
e733d05a5e
|
refactor(ohos): DevicePage 560→307 行（入口列表/四个面板/模型拆分）
- common/DeviceModel.ets（73）：device_id 兜底（桥 id 优先 → 持久化 → 生成并落盘，
顺序与原 aboutToAppear 一致）、/device/online 响应解析、四个二级页路由 id
- components/DeviceRootEntries.ets（92）：一级入口（本机/通道两组 NavRow 列表）；
宽屏高亮自己读 AppStorage 的 isWideScreen，页面只给 activeSub 与 onOpen
- components/DevicePanes.ets（316）：DeviceLocalPane（基本信息 + 授权开关）、
DeviceCapsPane（能力清单）、DeviceGatewayPane（网关信息 + 刷新）、
DeviceListPane（在线设备列表）、DeviceKvRow；每个面板自带 SubPageLayer
页面保留导航栈、openSub/closeSub、授权开关、toast、refreshDevices 与
SubDestination 分发。所有文案、图标、颜色、过渡与失败分支逐字保留；
面板内容多了一层无 padding 的 Column 根节点（@Component 的 build() 只允许
一个根），宽度 100% + Start 对齐，与 SubPageLayer 内容槽的布局一致。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
|
2026-09-13 22:34:20 +08:00 |
|
|
|
8a9fc05451
|
refactor(ohos): DeviceBridge 409→296 行（协议类型与帧构造移到 BridgeProtocol）
- common/BridgeProtocol.ets（168）：hello/bind/cmd_result/cmd_data_start/
cmd_data_end/event/status 七个消息结构、CHUNK_SIZE、BridgeCmdHandler 回调类型，
以及 bridgeHelloFrame / bridgeBindFrame / bridgeResultFrame /
bridgeDataStartFrame / bridgeDataEndFrame / bridgeEventFrame /
bridgeStatusFrame / bridgeChunkSlices 八个纯构造/切片函数
- common/DeviceBridge.ets（296）：只剩 socket 生命周期、重连代际、绑定状态机
与命令分发
**DeviceBridgeClient 的对外方法名与签名一字未改**（isConnected / getDeviceId /
setCmdHandler / setStateListener / connect / updateAuthorized / disconnect /
sendResult / sendDataChunked / sendEvent / sendStatus / send），
`send*` 仍是"拼帧 + 发出去"两步，拼帧那一步搬走；分块发送的
"start → chunks（失败即 break）→ end"顺序与 `bytes.slice` 语义保持不变。
外部只有 deviceBridge 单例被 import（BridgeRouter / DeviceBridgeSession /
DevicePage），无其它符号依赖。
验证：hvigorw assembleHap BUILD SUCCESSFUL；diff 中 DeviceBridge.ets 无
状态机/回调/重连逻辑改动。
|
2026-09-13 22:28:53 +08:00 |
|
|
|
31bbde9cdd
|
refactor(ohos): Attachment 463→344 行（纯函数与字节解码移出 components）
- common/AttachmentMeta.ets（106）：parseAttachment / attachmentFromChannelOutput /
fileNameOf / formatBytes / oneDecimal / extLabel / sanitize，纯函数无平台依赖
- common/AttachmentImage.ets（37）：loadPixelMap（沙箱 file:// 与远端 /files 两条路径）
components/Attachment.ets 只留 UI：AttachmentCard 与 AttachmentDetailContent。
**两者的导出名、@Prop 形状与 import 路径均未变**（ChatPage 仍从
'../components/Attachment' 取 AttachmentDetailContent），组件内部的布局、
过渡、提示文案与失败分支逐字保留，仅函数体搬走。引用方 5 处 import 路径同步更新。
验证：hvigorw assembleHap BUILD SUCCESSFUL；diff 中 Attachment.ets 只有
"-删除纯函数 + import 改写"，无属性/布局改动。
|
2026-09-13 22:27:34 +08:00 |
|
|
|
e0514c3692
|
refactor(ohos): ChatPage 1962→207 行（状态机/SSE/气泡/输入区拆分）
- common/ChatStore.ets（388）：消息数组、分页游标、新消息入场标记、
SSE 连接与重连、防抖刷新（50ms）统一成一个单例状态机
- common/ChatSse.ets（192）：SSE 事件 → 状态的翻译层，逐分支照搬
channel_output/agent_output/reasoning/delta/tool_call/stage/agent_error/
sync_required；通过 ChatStreamSink 接口写入，避免与 ChatStore 形成循环依赖
- common/ChatSession.ets（176）：POST /chat 与 POST /chat/file 的发送、
超时兜底、POST 响应与 SSE 的合并判定
- common/ChatFormat.ets（223）：mime 推断、ForEach 键 structSig、工具卡
状态/颜色、渠道判定与头像配色
- common/ChatHistory.ets（96）：历史载荷与 tool_calls 解析
- components/ChatBubble.ets（247）：气泡（头像/渠道名/思考卡/工具卡/附件卡/正文）
- components/ChatToolCard.ets（253）：思考卡 + 工具卡
- components/ChatStream.ets（210）：消息列表 + 顶栏遮罩 + 底部淡出 + 触顶懒加载
- components/ChatComposer.ets（357）：输入行、选图/选文件、沙箱落盘、发送
- components/ChatAttachBar.ets（139）：加号菜单 + 待发送附件条
响应式语义刻意保持不变：数组不进 AppStorage，改用自增版本号 K_CHAT_REV
通知订阅组件重取快照（ChatStream 把它镜像进 @State messages，ForEach 每次
拿到的仍是新数组引用，与拆分前 this.messages = this.messages.slice() 等价）；
structSig 仍不含 content，正文靠 MarkdownView 的 @Prop 流式更新；
markNew 仍不切片、入场动画交给紧随其后的 refresh()；
animateTo 只能存在于组件里，所以折叠翻转的动作留在 ChatStream 内。
验证：hvigorw assembleHap BUILD SUCCESSFUL；SSE 各分支、ensureToolCall、
markNew、sendChat/sendWithAttachment 的守卫顺序均与原实现逐条比对过，
守卫从"页面方法内"移到输入区组件时保持了原有先后（连接判定先于清空输入）。
|
2026-09-13 22:19:05 +08:00 |
|
|
|
f79e0f82dd
|
refactor(ohos): SettingsPage 1463→389 行（模型/条目卡/四个面板拆分）
- common/SettingsModel.ets（313）：设置载荷解析、分类归并、分页切片、
路由常量，纯逻辑无 UI
- components/SettingsEntryCard.ets（215）：单条设置卡（值编辑/保存）
- components/SettingsRootEntries.ets（100）：一级入口行 + 状态汇总卡
- components/SettingsHome.ets（95）：一级页壳（顶栏/浮层/提示条）
- components/ConnectionsPane.ets（347）：后端连接 CRUD（自带二级页壳）
- components/AppearancePane.ets（265）：主题/背景/透明度（自带二级页壳）
- components/BackendSettingsPane.ets（172）：分类与条目两个二级面板
页面保留 @State 集合、加载/保存编排与 SubDestination 分发；数组仍走
@Link 直传（未引入 AppStorage 数组）。相册选择、重启前台桥等既有行为
与提示文案逐字保留。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
|
2026-09-13 22:18:56 +08:00 |
|
|
|
131c1ff0e9
|
refactor(ohos): PluginsPage 995→374 行（接口/状态/列表/详情/浮层拆分）
拆分方向按职责切，页面只留导航与数据编排：
- common/PluginApi.ets（174）：fetchPluginRows / fetchPluginDetail
- common/PluginStatus.ets（78）：状态判定、文案、颜色、副标题
- components/PluginListView.ets（166）：列表卡 + 列表
- components/PluginDetailPane.ets（291）：详情面板
- components/PluginsOverlays.ets（65）：安装表单
- components/ToastBar.ets（48）：提示条，PluginsToast 与 SettingsPage 的
toast 合并成这一个组件（此前两处各写一份）
UI 结构与文案逐字保留（含 92%/layoutWeight 等既有布局修法）。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
|
2026-09-13 22:18:49 +08:00 |
|
|
|
414e6a1627
|
refactor(ohos): StaticMarkdown 604→332 行（Markdown 解析抽到 common/MarkdownParser）
把"文本 → 块/片段"的纯解析逻辑（MdBlock/MdSpan、parseBlocks、parseInline、
表格/分隔线/有序列表判定）整体搬到 common/MarkdownParser.ets（282 行），
StaticMarkdown.ets 只留 StaticMarkdownView 组件（332 行）。
解析规则逐字保留，未改任何排版行为；MdBlock/MdSpan 原本只被
StaticMarkdown.ets 使用（唯一引用方是 components/MarkdownView.ets，
它只用 StaticMarkdownView）。
验证：hvigorw assembleHap BUILD SUCCESSFUL。
|
2026-09-13 22:18:43 +08:00 |
|
|
|
8f40b91dea
|
feat(ohos): 设备桥会话管理、状态/设备信息载荷与能力路由完善
- 新增 `DeviceBridgeSession.ets`：会话生命周期（创建/复用/回收）与 TTS 会话显式 shutdown；
- `BridgeCaps`/`BridgeRouter` 与内核实际支持的本机命令保持一一对应，补齐 status/deviceinfo；
- 页面与状态存储调整（DevicePage/Index/SettingsPage/StatusStore/SubPage）、新增 ScreensuePage；
- module.json5 与 string.json 同步（新增页面与文案）。
|
2026-09-12 20:21:01 +08:00 |
|
|
|
02cc74ce11
|
fix(proc): 子进程崩溃自愈 + 集中台账 + 注册面摘除
根因：子进程插件被 kill 后，内核只发了一个无人订阅的事件，
工具/stage handler/IO 通道全留在注册表里指向死进程，
模型继续调用只吃 ErrProcessExited，没有任何路径把插件拉回来。
## 四层修复
### 1. 专职 waitLoop（进程收割）
- 每个子进程配一根 waitLoop goroutine，是 cmd.Wait() 的唯一调用点
- 不再依赖 stdout EOF 判定死亡（孙子进程继承 stdout 时 EOF 永不到来）
- 手工 os.Pipe 替代 cmd.StdinPipe/StdoutPipe，避免 waitLoop 与
os/exec 的内部关闭竞争
- host.go: Host.Supervisor()，Host.Close() 先 StopAll 再拆段
### 2. 集中台账 Supervisor
- proc/supervisor.go: 插件 Spawn 握手成功即 track，进程退出即 untrack
- StopAll: 并发发 plugin.stop 走优雅路径，到期仍在的一律 Kill
- 关停后才完成握手的进程被立即结束，不会活过内核
- 消除「孤儿进程持共享段映射 → SIGBUS」的隐患
### 3. 注册面摘除（detachPlugin）
- 新增 StageHost.UnregisterPluginStages：摘除指定插件的全部 stage handler
- 新增 Registry.pluginChannels 台账：记录每个插件注册的 IO 通道
- 三条路径统一走 detachPlugin：Disable / ReloadOne / RemovePlugin
- StopAndUnload 漏了 IO 通道也一并补上
### 4. 自动重启
- onProcCrash 从「只发事件」改为「摘注册面 → 从注册表移除 → 异步排重启」
- scheduleProcRestart: 窗口 5 分钟内最多 3 次，线性退避 1s/2s/3s
- 超限停手留日志；重启前复核是否已被 Disable 或被其他路径加载
- 崩溃计数窗口过期自动归零
### 5. 主动停止 vs 崩溃的区分
- proc.Plugin 新增 stopping 标志：Stop()/Close() 里 Set(true)
- handleExit 读 stopping 标志，主动停止不上报 onCrash
- 防止重载/禁用/卸载被误判为崩溃触发多余重启
### 6. Linux Pdeathsig 兜底
- procattr_linux.go: SysProcAttr.Pdeathsig = SIGKILL
- 兜 homed 自身被 SIGKILL/OOM 时子进程变孤儿的场景
- macOS/Windows 无等价物，空实现
### 7. pluginmgr 升级
- PluginManager 接口新增 PluginRuntime / ListPluginRuntimes
- plugin_list 输出运行态：loaded / alive / pid / crash_count / channel
- 新增 plugin_status: 全量运行期快照 + dead/unhealthy 汇总
- 新增 plugin_restart: 无条件重启单个插件（plgreload 不动未改二进制的插件）
### 测试
- process_test.go: 3 例（grandchild stdout 感知 / Supervisor track-untrack /
StopAll 无孤儿）
- crash_recovery_test.go: 8 例（detach 三项齐全 / 通道重注册 / 崩溃不阻塞 /
退避阈值 / 窗口过期 / 关停中跳过 / PluginRuntime 通道识别）
- stages_plugin_test.go: 4 例（stage 按插件摘除 / 空 stage 清理 / 空名 no-op /
工具+stage 双摘后可重新注册同名）
|
2026-09-03 12:37:58 +08:00 |
|
|
|
48b5c2401c
|
feat(ohos): MotionBase 统一按压动效 + 分层图标随主题切换
## 动效统一
各组件重复实现按压反馈（@State pressed + scale + animation + onTouch 四件套），
时长各写魔数导致全局手感不一致。
- 新增 components/MotionBase.ets：通用动效的"父组件"。ArkUI V1 的 @Component
struct 无法继承他人 build，改用组合表达继承——调用组件把内容经 @BuilderParam
内容插槽传入，MotionBase 在包装节点统一挂动效修饰器。
pressEnabled 默认关（纯展示容器零开销）；fillWidth=false 供气泡内卡片按内容
自适应宽度；flexWeight 供等分排列按钮参与剩余空间分配。
onPress 只作按压瞬时轻量钩子，导航/提交语义仍由调用组件 onClick 负责，
避免"按下即触发"的手感偏差。
- Constants.ets 新增动效 token：ANIM_FAST(150) / ANIM_NORMAL(220) /
ANIM_ENTER(280) / ANIM_SLOW(400) / PRESS_SCALE(0.97)。
取值依据：状态切换 150-250ms（>300ms 显拖沓），大位移进出场 300-400ms
才不突兀；曲线统一 EaseOut 起步快收尾缓。
- NavRow / StatusSummaryCard / AttachmentCard / 插件卡片等公共组件接入
MotionBase，移除各自的按压四件套。组件专属动效（聊天输入框上弹、加号菜单
浮起、折叠面板展开、toast 进出场）保留在各组件内，不塞进父组件。
## 图标与启动页随主题切换
原先直接指向位图 app_icon.png，浅色底被烧进图标，深色模式下桌面与启动页跳脱。
- 改用分层图标 layered_image：foreground 为字形，background（沉淀色）在
base/ 与 dark/ 各一份，随系统主题切换。app.json5 与 module.json5 的
icon 均指向 :layered_image。
- startWindowIcon 改用透明底 start_icon.png，配合 start_window_background
的 base(#F1F3F5) / dark(#000000) 两份取值，浅深模式遮罩与图标都能对上。
## 验证
清空 entry/build 后全量重编：hvigorw assembleHap BUILD SUCCESSFUL（9.8s），
零 ArkTS 错误。提交内容已确认不含 build/ oh_modules/ .hap 与签名材料。
|
2026-08-30 17:23:40 +08:00 |
|
|
|
8510a2f2eb
|
fix(ohos): 移除硬编码后端凭据，地址规范化默认 https
- Model.ets: defaultConnection 不再内置 url/apiKey，改为空白模板
- 新增 normalizeBaseUrl：补协议（默认 https）、去尾斜杠、去误粘的 /api/v1
裸域名走 http 会被反代 302 到门户站，客户端只拿到 404，表现为"连接直接失败"
- ConnStore: 增删改与读取存量数据时统一规范化 url
- 去掉 ensureDefaultConnection，首启不再预置连接，未配置时走统一提示
|
2026-08-29 13:49:30 +08:00 |
|
|
|
46e942f0c2
|
feat(ohos): 鸿蒙端聊天历史分段懒加载 + 首次提交完整工程
原有 cmd/ohos/HomeAgent 是未入库的鸿蒙原生 ArkTS 工程，本次随改动一并入库，
保证他人 clone 后可直接编译（含 .gitignore 排除 build/oh_modules/签名材料，
提供 build-profile.json5.example 模板）。
本次功能改动（与 WebUI / GUI 三端对齐）：
- /chat/history 首屏只拉最新 CHAT_PAGE_SIZE(40) 条，1.26MB → 48.5KB
- 抽出 parseHistoryPayload() 复用解析，记录 chatOffset/chatHasMore
- 新增 loadOlderChat()：向上滚动触顶（yOffset<60）懒加载更早页
- 工具调用 args/result 与 reasoning_content 完整还原，不做裁剪
构建验证：hvigorw assembleHap BUILD SUCCESSFUL（7.8s，ChatPage 零告警）
|
2026-08-29 10:25:12 +08:00 |
|
