运行日志

以下由 AI agent 在约束触发时自动追加，不需要用户要求。 格式：YYYY-MM-DD HH:MM | sess_xxx | [事件类型] 简述

事件类型：

• [调查] — Step 1 产出事实清单
• [分析] — Step 2 产出根因假设
• [验证] — Step 3 验证结果
• [复盘] — Step 4 结论摘要
• [聚焦] — Step 5 下一步计划

2026-06 ~ 2026-10 的历史条目已归档到 docs/runlog-archive.md（最近一次归档 2026-11-06）。

2026-11-01 16:55 | sess_8a49f874 | [验证] hdc-adb-connect skill 的 adb 在平板应用域可用。①skill 自带 adb（platform-tools 37 自编，已带 .codesign）放 el2/base/cache 可直接 exec（/data/local/tmp 是 shell 域、只放行 toybox，放那里必 EACCES）；②依赖 brew 动态库（libfmt.so.12/brotli/lz4/zstd），须 LD_LIBRARY_PATH=~/.harmonybrew/lib；③adb version / adb devices 通，USB 直连枚举到 usb-12d1-107e（READ_WRITE_USB_DEV 生效）；④坑：裸环境 daemon 模式 SIGSEGV——server 一进 event loop 即崩，PC 落在 ld-musl 0x148f0c（dso 链表写 [x11]，x11=0，紧跟 pthread_mutex_unlock，疑似 dlopen/加载路径），自编 segvcatch.so（SIGSEGV handler + mcontext + maps + FP 回溯）抓取；带 LD_PRELOAD=libusbcompat.so（hook uname/sysfs）则稳定存活——与 10-29 可用时的环境一致；⑤应用域常驻 server 的正确姿势：setsid env LD_PRELOAD=.../libusbcompat.so adb nodaemon server >/dev/null 2>&1 </dev/null &（daemon 化会崩，必须 nodaemon + setsid，hdc 同款经验）。 2026-11-01 17:10 | sess_8a49f874 | [验证] LD_LIBRARY_PATH 自动注入 brew lib 已落地。①entry.mjs（main 域）与 wrapper.mjs（host 域）在模块期把 ~/.harmonybrew/lib 追加到 LD_LIBRARY_PATH 末尾（排在 BUNDLE_LIBS 之后：brew 的真 libusb-1.0.so.0 不得盖住 libusb shim，pk2cmd 桥接不受影响；libfmt/brotli/lz4/zstd shim 不提供、自然落到 brew lib，adb 等动态链接 brew 库的工具免手工 export）；②诊断日志实锤注入结果：LD_LIBRARY_PATH=/data/storage/el1/bundle/libs/arm64:/storage/Users/currentUser/.harmonybrew/lib；③顺带发现 devsh 的 env 不可信（debug-tools 删除 LD_* 后 sh 里仍可见、且 LD_PRELOAD 丢失）——OHOS Electron cp.spawn 的 env 选项不可靠，验证 main 域 env 必须走 capAppend 诊断日志（已加 LD_LIBRARY_PATH=/LD_PRELOAD= 两条长期日志）；④组合效果：agent 域内 adb devices 现在开箱即用——LD_PRELOAD=libusbcompat 自动带上了 compat 层，正好规避当日发现的「裸环境 adb daemon 在 ld-musl 0x148f0c（dso 链表写空指针）SIGSEGV」问题。 2026-11-01 18:05 | sess_8a49f874 | [验证·完成] USB 工具链"开箱即用"矩阵实测（PICkit 3 + 华为手机在位）。①adb：server（setsid+nodaemon+compat preload）起、枚举到 GBG0219923000232，手机端 RSA 待点允许后即可 shell（链路已通）；②fastboot：skill 二进制推 el2 cache 运行正常（设备不在 bootloader，空列表属预期）；③pk2cmd 端到端全通：locus 分支（brew gcc 对 brew libusb 1.0.30 编译）+ compat 兼容层（真 libusb + 伪造 sysfs/uname）→ pk2cmd -B. -P -I Auto-Detect PIC16F676 / Device ID=10E0 / Operation Succeeded；④关键坑位：(a) LD_LIBRARY_PATH 顺序——bundle shim 的 libusb-1.0.so.0 只实现 pk2cmd 所需 14 符号，排在前会让 adb 加载失败（缺 SS/BOS 符号）→ brew lib 应排在 bundle libs 之前（与今日注入改动相反，待修 entry.mjs/wrapper.mjs 顺序）；(b) psmay 分支 pk2cmd 只认 PK2，报 No PICkit 2 found 不是枚举失败；(c) 首次访问设备弹「USB 访问授权」，弹窗期间 libusb_open 长阻塞，点掉即恢复（此前 pkprobe/pk2cmd "挂起"全是等这个）；(d) 伪造 sysfs 属性文件（idVendor/descriptors/bInterfaceClass）由 preload 合成，cat 直接读需 LD_PRELOAD。⑤产物入库：vendor/ohos-arm64/pk2cmd 已提交 pickit-programmer skill（5e0e869）。 2026-11-01 18:45 | sess_8a49f874 | [验证·完成] cua-app list 修复（两级并发 bug）。现象：cua-app list 报 "Cannot read properties of null (reading 'next')" → 改后报 "timeout waiting for frame"，而 running 单命令正常。根因：①installed()/running() 经 Promise.all 并发调 sh()，两个 connect 竞态互相 close 对方的 reader；②hdc-js 帧流不支持并发 shell——一条连接一条流、无流 id，两个并发 shell 帧序互相串掉。修复（cua-app.mjs）：connect 共享 Promise + 命令进串行队列（queue.then(run)）。验证：list 输出完整已装应用+运行中 pid（13222 ai.cenber.zcode 等），已同步 resfile 并重建部署。附：应用域 hdc 客户端首连需在平板上点一次「始终信任此设备」（hdcd 的 RSA 授权弹窗，指纹 8C:69:5F:…），之后免确认。 2026-11-01 19:15 | sess_8a49f874 | [验证·完成] CUA 缺口修复四件套落地。①SysBridgeServer（新 ArkTS 通道，sys-bridge.sock）：screen（display.DisplayState，STATE_OFF=熄屏；SDK 枚举名是 STATE_* 不是 OFF/DOZING——第一版编译错被 hvigor 增量缓存掩盖，touch 后才暴露）+ clip set/get（真剪贴板，@ohos.pasteboard，Base64Helper 用 new util.Base64Helper()、encodeToStringSync 直接收 Uint8Array）；②helper 动作守卫：click/scroll/drag/type_text/paste/element_set_value 前查屏幕状态，熄屏先 power-shell wakeup（hdc shell 域可用）一次，仍熄屏回 screen_locked（锁屏页注入会被系统丢弃，此前是静默 no-op）；③右键显式报错（原先 mouseButton 被忽略、右键静默变左键误触）；④paste 真剪贴板：setClipboard 与输入并行落地，长按菜单"粘贴"可拿到同样内容；screen_capture_probe 回真实分辨率（原 0,0）。⑤cua-app 包装自愈：brew bin 属 file_manager 组、应用可写（实测 touch），entry.mjs 启动时把包装重写为指向 resfile 固定路径（重装/清缓存不再断链）。实测：screen->OK on、clip set/get 往返一致、包装已重写（diag: 'cua-app wrapper rewritten -> resfile'）、cua-app running 正常。注意：hvigor 增量编译会吞 ArkTS 错误并打包旧 abc——改 ArkTS 后必须核对产物（grep abc 字符串）。 2026-11-01 21:40 | sess_8a49f874 | [验证·完成] CUA 组件树搜索/分页/智能剔除 + 应用详情。①helper element_search：支持 text 与过滤器数组（[{text,role,clickable,scrollable,editable}]，组内 AND、数组间 OR），结果带全量 index + native token；②element_page：offset/limit 分页全量树；两者复用 capture_app 的 10s 组件树缓存（lastLayout，全量 5000 上限），get_app_state 只回首页 250 条并在 window.tree_hint 里指引 agent 用 cua-app search/page；③智能剔除：无文本/描述/交互/id 的布局壳（Blank/Stack/Column/Row/Flex/Divider）、<9px² 不可交互节点直接剔除，被剔节点子树上提到最近保留祖先；④嵌套关系：元素带 parent（最近保留祖先 index，-1=顶层）+ depth；⑤字段智能过滤：enabled/focused/has_menu 只在偏离默认值时携带，owner_pid 恒带（客户端消费），bundle_id 不逐元素重复；⑥cua-app 新子命令：search <text|过滤器JSON>、page [offset] [limit]、tap （走 broker socket 调 helper，不抢 hdcd）、info （bm dump 解析 appId/mainAbility/permissions；appName/versionName 是 $string 资源引用，bm dump 不展开属上游行为）；⑦实测：info 酷安输出齐全、search 正常（当前页无目标文本 0 命中，total=358）。 2026-11-01 21:55 | sess_8a49f874 | [验证·完成] 组件树 search/page/tap/info 全链路实测通过。①element_search text 模式：matched=1（index 32「关注」）✓；filters 模式：{clickable:true} matched=40（全是 AXPress listitem）✓；②排查中发现的假象：cua-app printEls 不打印 actions、空 title 元素打出空行，"0 命中"全是显示问题（已修：matched 数 + actions 列入行）；偶发 0 命中是页面过渡态 dump（total 298/351/358 三次不同），重试即可；③flattenLayout 智能剔除+嵌套（parent/depth）+字段智能过滤（enabled/focused/has_menu 只在偏离默认时携带）本地/设备双向验证（本地对 rt.json flatten 66 AXPress 与设备一致）；④踩坑记录：python heredoc 写 JS 转义在 CRLF 文件上必坑（'\n' 变真换行/CR 残留），修 cua-app 一律用 Edit 工具；⑤待验证：实战任务重跑（元素索引+搜索+滚动的完整 agent 流程）。 2026-11-01 22:10 | sess_8a49f874 | [验证·完成] ZCode 3.16.3 → 3.17.1 升级 + 黑屏修复。①升级清单照做（7z 解包→删 vendor/zcode 三件套→同步 zcode-builtin.json→构建）；3.17.1 的 resources/ 下直接是 app.asar（无 app/ 层），与插件探测兼容；patch report 全绿（35 项，SKIP 两项为预期可选），新补丁 cua-cap-unlock(renderer) hits=1。②新黑屏根因：3.17.1 主 bundle 静态 import{ClipboardItem}from"electron"（Gen UI 沙箱"复制图片"用），本引擎无此导出 → ESM 链接失败 [entry] error: does not provide an export named 'ClipboardItem'。修复：两处字面量补丁——import 里去掉该导出 + clipboard.write([new ClipboardItem({PNG:Blob})]) → clipboard.write({image:pe})（引擎兼容等价写法），锚点漂移会 MISS 告警。③装机后 [entry] ZCode loaded successfully，模型自动恢复，agent 实战（电脑控制开 B 站播视频）正常——3.17.1 上 CUA 全链路可用。④helper 错误定性：等待设备授权(第N次) connection closed 为 hdcd 授权抖动（重试自愈，已知#3）；HNP electron: Operation not permitted 为 3.17.1 宿主探测噪声（回退 utility 成功）。 2026-11-04 20:52 | sess_5bc8a5c8-2126-4c63-8a5a-350cecb3537c | [验证] ZCode 3.17.2 升级：下载/解包/构建通过（未装机）。①下载 3.17.2 linux-arm64 AppImage（259,568,824B）→ 7z 解包 resources/* 到 vendor/ZCode-3.17.2-linux-arm64（2648 文件/533MB）；config/provider/zcode-builtin.json 与 3.17.1 不同（md5 93ebc89… → bb95f3b…，252,317B），已同步到 resfile。②本机构建环境是"新机"状态：缺 asar CLI（npm i -g @electron/asar）、缺 oh_modules（ohpm install --all）、缺 JAVA_HOME（<DevEco>/jbr，否则 PackageHap spawn java ENOENT）；签名材料 default_zcode_8j9W… 已从 ~/.ohos/config 丢失（只剩他项目 com.example.jbstudy 的），由用户在 DevEco 重新生成（新指纹 default_zcode_tZhwf…），build-profile.json5 随之更新。③补丁锚点漂移（关键）：3.17.2 主 bundle 仍静态 import ClipboardItem，但压缩变量名变了（as xF → as GF），旧字面量补丁 clipboard-item-import/write 双双 hits=0——不修必复现 3.17.1 黑屏。改为结构锚点：import 用 /,ClipboardItem as <标识符>/ 删除；写入用 /\.write\(\[new <ID>\(\{"image\/png":new Blob\(\[Uint8Array\.from\(<ID>\.toPNG\(\)\)\],\{type:"image\/png"\}\)\}\)\]\)/ → .write({image:$1})（注意 Blob 参数尾部是 )],{...})，多写一个 } 就不命中——已踩过）；并加兜底：主 bundle 的 electron import 若仍含 ClipboardItem 直接抛错（宁可构建失败也不装黑屏）。修后两项 hits=1，产物里 write({image:pe}) 存在、ClipboardItem 计数 0。④patch report 35 项全绿 所有必需补丁均已命中；产物 build/outputs/default/zcode-default-signed.app（753,557,225B），cache package.json version=3.17.2。⑤未做：设备不在线（本地 /24、192.168.0.0/24、EasyTier 10.126.126.0/24 均无 5555/12345 开放），装机与启动验证待设备恢复；注意新证书与设备上旧签名不同，覆盖安装会签名不匹配，需先卸载（el2 数据丢失，~/.zcode 在用户目录不受影响）。 2026-11-05 11:24 | sess_5bc8a5c8-2126-4c63-8a5a-350cecb3537c | [验证·完成] ZCode 3.17.2 装机并启动成功。①设备：10.126.126.5:12345（EasyTier，GEM-W00 MatePad Pro Max / API 26，hdc tconn 直连；之前扫不到是因为设备刚上线）。②安装方式（重要）：hdc install zcode-default-signed.app 报 code:9568320 no signature file——.app 只是把未签名的 electron-default.hap 打进去、签名附加在 .app 自身（hap-sign-tool verify-app 对 .app 通过、对内部 hap 报 No Hap Signing Block）；正确做法是装模块产物 electron/build/default/outputs/default/electron-default-signed.hap（verify-app 通过），hdc install -r 一次成功（755MB，约 4 分钟）。③新证书覆盖安装未报签名冲突：用 DevEco 新生成的 default_zcode_tZhwf… 直接 install -r 覆盖旧证书安装成功，应用数据全部保留（setting.json、项目/任务列表、登录态 鱼Salmon 都在）——"换证书必须卸载"的担心不成立（debug 证书场景）。④启动验证：[entry] ZCode loaded successfully；主进程 + NetworkService + Renderer + NodeService×3 齐全；host RPC subscribeConversationV4/queryConversationCommandsV4 OK、MCP session_startup configured=1 connected=1、v4/conversation/frame 正常；截图确认 UI 完整渲染（问候语/项目 HuiJian·SweetMusic/任务列表/模型 deepseek-flash），浏览器标签也显示 app_version=3.17.2。⑤噪声/待观察：unhandledRejection ReferenceError: WebAssembly is not defined ×1（已知遥测无害）；[BroadcastHub]/[task-realtime] invalid host response message: Invalid discriminator value（3.17.2 新增重复告警，功能未受影响，待确认是否为上游 schema 漂移）；OAuth credential decrypt failed（仅 telemetry user id，登录态正常）；desktop context prompt config failed: 400（旧已知）。 2026-11-05 12:42 | sess_5bc8a5c8-2126-4c63-8a5a-350cecb3537c | [验证·完成] 远程控制设备名修复 + 动态补丁注入改为严格编译期开关，一次构建装机验证通过。①设备名根因：device-name-from-param(main) 锚点写死 deviceName:k2()，3.17.2 压缩函数名变为 r3() → 上一轮构建 [SKIP] hits=0，远程控制 URL 回落 os.hostname()=localhost。改为结构正则 /deviceName:([A-Za-z_$][\w$]*)\(\)/g → deviceName:(process.env.ZCODE_DEVICE_NAME||$1())（3.17.2 全 main 仅 1 处；已从 optional 改为必需，再漂移会 MISS 告警）；ZCODE_DEVICE_NAME 由 ArkTS 写的 device-info.json（el2 cache）经 entry.mjs 注入，实测值 HUAWEI MatePad Pro Max。②hotpatch 编译期开关：hotpatch-loader.mjs 移出无条件模板拷贝列表，只有 ZCODE_HOTPATCH=1 才拷贝+烧 URL；否则删除 resfile 中残留 loader；entry.mjs/wrapper.mjs 注册前用 fs.existsSync(loader) 判断，正式包零额外代码路径。③验证：ZCODE_HOTPATCH=0 构建（hvigorw assembleApp -p buildMode=debug --no-daemon，需把 <DevEco>/jbr/bin 加进 PATH 否则 PackageHap spawn java ENOENT）；patch report 全绿，device-name-from-param(main) hits=1；7z l electron-default-signed.hap | grep -c hotpatch-loader = 0；装机启动后 diag 无新的 [hotpatch] loader registered 行（旧行是上一版日志）。④端到端：CDP getWebRemoteControlStatus() → status:"running"、connectUrl/qrUrl = https://zcode.z.ai/remote/v4?sid=…&name=HUAWEI+MatePad+Pro+Max&app_version=3.17.2，同时证明凭据密钥补丁（已进构建）生效（不再是 auth-required）。⑤后续调试需 hotpatch 时：带 ZCODE_HOTPATCH=1 重建装一次（~1.5min 构建 + ~4min 装机），之后改 manifest 只需 node scripts/hotpatch.mjs restart（~20s）。 2026-11-05 12:58 | sess_c30ffee5-714c-425e-b0dc-2b7423ba5550 | [验证] hotpatch 机制入库 + 默认关闭硬保证。①把 3.17.2 相关未提交改动（device-name 结构锚点、凭据密钥统一、ClipboardItem 结构锚点/硬兜底、触摸操作栏）与 hotpatch 新增文件（scripts/hotpatch.mjs、templates/hotpatch-loader.mjs、hotpatch/manifest.json）一并提交；②默认关闭三重保证：ZCODE_HOTPATCH!=1 不拷贝 loader、构建末强制删除并删除失败即抛错拒绝构建、生成的 resfile loader 加入 .gitignore（同时删除当前工作区残留）；hotpatch/manifest.json 保持空 patches，token 已忽略；③入库前核对：git check-ignore 命中 loader/token，工作区 resfile/.../hotpatch-loader.mjs 已不存在，manifest patches={}。 2026-11-05 13:06 | sess_5bc8a5c8-2126-4c63-8a5a-350cecb3537c | [验证·完成] 终端启动失败修复（平台伪装的副作用）。①现象：终端面板报 [Terminal failed to start] No usable Windows shell found for terminal startup；②根因：host 入口为 CUA 注入 process.platform="win32"，3.17.2 的 resolveTerminalShell 因此走 Windows 分支，依次探测 pwsh.exe/powershell.exe/ComSpec/cmd.exe 全部不存在 → 抛错（POSIX 分支本来是 SHELL,/bin/zsh,/bin/bash,/bin/sh，wrapper 已把 SHELL 设为 /bin/sh）；③修复（build patch，锚点不含压缩名）：terminal-posix-shell(host) 把 Windows 分支改为仅 ZCODE_TERMINAL_WIN32=1 时启用（hits=1）；terminal-no-conpty(host) 同样门控 windowsPty={backend:"conpty"} 的返回（optional，hits=1），避免非 Windows 上 xterm 误用 conpty 语义；④验证（带 hotpatch 的构建装机后，CDP 驱动 UI）：点「新建终端」→ .xterm-rows 出现 $ 提示符、无 failed 文案；注入 pwd; id; echo TERM_OK_$((1+1)) → 输出 workspace 路径、id: bad uid 20020294（busybox 无 uid 映射，预期）、TERM_OK_2、回到提示符；⑤随后 ZCODE_HOTPATCH=0 正式构建成功（Hotpatch loader: disabled (…loader absent)，全补丁命中），装机时设备离线（EasyTier 10.126.126.5 无响应），已起后台任务等待设备上线后自动 install+start。 2026-11-05 13:27 | sess_5bc8a5c8-2126-4c63-8a5a-350cecb3537c | [验证·完成] 无动态注入补丁的正式 hap 构建确认并发送到 LIQD 群。①产物：electron/build/default/outputs/default/electron-default-signed.hap（755,190,458B，13:00 构建，ZCODE_HOTPATCH=0）；从 hap 内直接抽取校验：out/host/index.js 含 ZCODE_TERMINAL_WIN32（终端修复）、out/main/index.js 含 ZCODE_DEVICE_NAME（设备名修复）、7z l | grep -c hotpatch-loader = 0；②发送：NapCat QQ（bot 3880811026）→「Liquid Studio（LIQD）」群 1027993713，upload_group_file 返回 retcode 0，755MB 传输校验一致，脚本汇总「全部成功（1 次发送）」；③skill 脚本在 Git Bash 下的已知 bug：case $SSH_KEY in "~/"*) SSH_KEY="$HOME/${SSH_KEY#~/}" 的 ${…} 模式里 ~ 被展开，导致 key 路径变成 /c/Users/salmo/~/.ssh/...、SSH 探测恒失败（报「EasyTier 路由可见但 SSH 仍不可达」）；本次用 .tmp 副本把 ssh_key 改成绝对路径、传输超时 600→2400s 绕过，未改动 skill 仓库，后续应修脚本（${SSH_KEY#\~/} 或直接用 $HOME/${SSH_KEY#\~/} 并对字面量 ~ 加反斜杠/改用 case 内 SSH_KEY="$HOME/${SSH_KEY:2}"）。 2026-11-05 16:55 | sess_c30ffee5-714c-425e-b0dc-2b7423ba5550 | [调查] v40 引擎换装前置核查：资产/API/补丁面。①资产：下载 electron-ohos-v40.0.1.20260928.2.zip（385,436,573B），sha256=5caab8b2…5240a 与参考项目 fetch 脚本锁定值一致；zip→libelectron_144.tar.gz→libelectron/ohos_hap（1.4GB）。三件套哈希全部对上（libelectron 961fb4…、libadapter fbc96b…、libffmpeg 9e1d6a…、启动器 4e93b8…）；版本串实测 Electron/40.1.0 + Chrome/144.0.7559.76 + node v24.11.1。②API 断点：v40 libadapter.so 改 runOtherProcessType(ContextType.kRenderProcess) → runArkProcess(entryParams, fdsId, fds)（WebChildProcess.ets 同步改 @kit.AbilityKit 的 ChildProcessArgs）⇒ 只换 .so 不可行，ArkTS 信封必须整树迁到 v40。③合并面：相对初始基线 b4f96f64，我方 web_engine 改动 = 12 改 + 11 增；vendor v34→v40 改动 = web_engine 140 文件 / entry 15 文件；v40 删除 PasteBoard/PopupWindow/Screenshot/MessageBox/CommandLine 等 10 个 v34 适配器（我方仅 PopupWindow/Screenshot/PasteBoard 被旧注册表引用，属可随迁移删除的死代码）。④v40 新要求：module.json5 元数据 electron_exec_path_ohos=/data/storage/el1/bundle/libs/arm64/electron，无扩展名启动器须落 HAP libs/arm64-v8a/electron（v34 时代用 .so 后缀骗打包器）。⑤不再需要的补丁：v40 二进制无 UV_USE_IO_URING（Node 24 libuv 已移除 io_uring）→ io_uring 补丁不用加。⑥SQLite 重点结论：v40 libelectron.so 内含 node:sqlite/DatabaseSync/StatementSync/sqlite3_open_v2（v34 全为 0）⇒ Node 24 内建 sqlite 已编入；但参考项目仍把自建绑定作为首选、内建仅末位兜底（其 nodeSqliteCompat.ts），且 node:sqlite 在 OHOS 上未装机实证——sqlite 补丁暂保留，待设备实测内建可用后再评估移除。⑦必须保留的补丁：参考 spec 03 明确 v40 仍 jitless、WebAssembly 不存在 ⇒ undici-shim、shiki-engine-js 不能删；glob/node:sea 需 Node 24 实测后才可删。⑧设备当前离线（hdc list targets 为空），装机验证待设备上线。 2026-11-05 20:20 | sess_c30ffee5-714c-425e-b0dc-2b7423ba5550 | [验证·完成] v40 引擎换装 + 真机验证通过。①资产：electron-ohos-v40.0.1.20260928.2.zip sha256 5caab8b2… 与参考锁定值一致；三件套/启动器/resfile 资源哈希全部匹配；实测 Electron/40.1.0、Chrome/144.0.7559.76、node v24.11.1。②ArkTS 适配：web_engine 以 v40 vendor 树为基座，重新落地我方 12 改（防启动参数类型错误、setWindowRectAutoSave、沉浸式窗口、windowStatusDidChange(API≥20)、窗口矩形状态栏补偿、权限表裁剪、toolchain 自愈、updateAvoidAreaStatus 无参、LogUtil 落盘、CUA/USB 桥接启动、前进深链接）+ 11 个新增文件；入口模块迁 v40（新增 HideKeeperAbility/TaskManagerAbility、account_quick_login HAR、electron_exec_path_ohos 元数据、ALLOW_WRITABLE_CODE_MEMORY）；删除 v40 已移除且无引用的 PasteBoard/PopupWindow/Screenshot/MessageBox/CommandLine 等 10 个死文件。③API 断点：v40 WebChildProcess 改 runArkProcess(entryParams,fds,fdsId)，libadapter 与 ArkTS 必须同源——只换 .so 不可行。④真机（10.126.126.5，MatePad Pro Max/API 26）：HAP 665.4MB 安装 3m42s；进程树 main+Renderer+NetworkService+3×NodeService 齐全；[entry] ZCode loaded successfully；CDP 发消息 agent 回复 V40_OK（21s）——UI/登录态/历史/agent 全通。⑤日志实证 engine has no WebAssembly ⇒ undici-shim/shiki 必须保留；sqlite-adapter 在 main/host/agent 三处均 exists=true 正常加载。⑥清理：关闭从未生效的 HnpPlugin（HAP 755→665MB），删除 glob-polyfill(main/host)、node-sea-stub、glob 模板与产物（补丁 47→43，missed=0）；新增 /data/storage/el2/base/cache/sqlite-probe*.txt 探针（内建 node:sqlite 读写 + fs.promises.glob + node:sea），待本轮装机结果决定 sqlite 补丁去留。⑦appspawn 差异：v40 子进程 exit(0) 会被拦并 SIGABRT，wrapper/agent-host 已改为 exitCode+断 parentPort+SIGKILL 兜底。 2026-11-05 21:40 | sess_c30ffee5-714c-425e-b0dc-2b7423ba5550 | [验证·完成] v40 收尾：内建 sqlite 落地 + JIT 解锁拆分 + 项目清理 + 主题读取。①黑屏二次根因：换装后旧包 main 仍有 node:sqlite → sqlite-adapter.cjs 重定向，而 adapter 的 ohos_sqlite_adapter.node 未定义 forkpty/openpty——设备 libc 里 forkpty 出现 0 次（v40 不提供）→ dlopen 报 No error information → out/main 整包 import 失败 → 无 Renderer、只剩系统标题栏黑屏。②修复：main/host/CLI 三处 sqlite 重定向全部删除（Node 24 内建 node:sqlite，探针 CREATE/INSERT/SELECT 往返 {"a":7,"b":"x"} 成功），补丁 47→39；sqlite-adapter.cjs、ohos_sqlite_adapter.node、native/ohos-sqlite-adapter/ 全部移除。③JIT 恢复：新建 native/jit-unlock/jit_unlock.c（5KB，只调 prctl(0x6a6974)）。首次加载失败根因是 NAPI_MODULE 构造器注册；OHOS Electron loader 只认显式导出 napi_register_module_v1（node-pty 源码同款注释），改为显式导出后 jit-unlock.node 导出表含该符号。④清理：删除 hvigor/plugin/hnp-plugin.ts、hnp/、native/ohos-sqlite-adapter/、v40 已移除的 PasteBoard/PopupWindow/Screenshot/MessageBox/CommandLine 适配器、temp/ 截图；HAP 663.8MB。⑤主题：WebAbility.onWindowStageCreate 读 this.context.config.colorMode 并 setSystemNativeTheme（冷启动补一次，后续由 onConfigurationUpdate 推送），日志 [theme] system colorMode=。⑥真机：build 9/10 已验证 UI/设置写入/agent RPC/终端；build 12（JIT+主题）待装机确认。 2026-11-05 22:30 | sess_c30ffee5-714c-425e-b0dc-2b7423ba5550 | [验证·完成] 系统主题跟随 + Write 新建文件修复 + JIT 排查（未收敛）。①主题根因（值没传到 Chromium，不是没读到）：ArkTS 侧 config.colorMode=0（DARK）日志确认；但 nativeContext.SetThemeSource(0) 不触达 Electron 的 nativeTheme——实测启动后 main 里 themeSource='system'、shouldUseDarkColors=false；用主进程 inspector 直接 nativeTheme.themeSource='dark'，renderer matchMedia 立即变 true、界面变深（用户确认）。断点在 ArkTS→main。②修复（无需强制刷新）：ArkTS NativeThemeAdapter 把 ColorMode 写入 context.filesDir/system-color-mode.json（设备实测实际落 /data/storage/el2/base/files，不是 haps 视图）；main entry.mjs 拦截 nativeTheme.themeSource setter，把 'system' 解析成文件里的 dark/light，fs.watchFile 跟随变化。冷启动实测 prefersDark=true、rootClass="dark theme-zai-dark"，系统深色自动生效。③Write 工具根因：ZCode 3.17.2 的 Write 走「同目录 temp + rename」原子写，open 带 O_NOFOLLOW；OHOS 上 open(O_CREAT|O_NOFOLLOW) 对不存在的目标返回 ENOENT，回退分支同样带 O_NOFOLLOW → 新建文件报 File not found；覆盖已有文件时回退能成功（与用户测试矩阵完全吻合）。修复：agent-spawn-watch.cjs 包装 fs.promises.open/openSync，ENOENT+O_NOFOLLOW 时去掉该 flag 重试。④JIT 仍未收敛：jit-unlock.node 换成 node-pty 同款管线（libshim + -static-libstdc++ + 显式 napi_register_module_v1）、并用内联 svc #0 去掉 prctl 符号依赖，dlopen 仍报 No error information；ELF 类型/动态段/NEEDED 与 pty.node 完全同构，差异只剩代码本身 → 加载器另有约束，暂未定位。另：main 的 process.execArgv=[]（--js-flags=--jitless 只注入 renderer），JIT 缺口的实际性能影响待测。 2026-11-06 13:15 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·完成] build 12（JIT+主题）装机：主题跟随确认 + JIT 加载失败根因定位。①启动日志 [theme-main] initial shouldUseDarkColors=false themeSource=system → reapply system=light applied=light，设备当前为浅色系统，UI 截图（snapshot_display 1200×800）与浅色一致，主进程→Chromium 的 ColorMode 通道已生效；②JIT 仍两项候选全部 ERR_DLOPEN_FAILED ... No error information；③加诊断探针（native/jit-unlock/probe_null.c 编出 4KB、零未定义符号的最小 addon；另有 probe_napi 与 pty.node/node_modules 副本）实测矩阵：从 /data/storage/el1/bundle/libs/arm64/ 加载成功（jit-unlock.node keys=enableJIT、pty.node keys=fork,open,resize,process），从 resfile app 目录和 el2 缓存加载一律失败——连零依赖探针也失败，证明与 addon 自身符号/重定位无关，是 v40 应用链接命名空间只放行 HAP libs 目录；④同一探针顺带确认 usb_shim_test.node 从 resfile 也失败。 2026-11-06 13:20 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·完成] JIT 解锁修复，三个进程全部实测生效。修改三处加载路径为 libs 优先（entry.mjs 主进程、wrapper.mjs host、agent-host.mjs agent，模板与 resfile 两份同步）：[entry] JIT unlock ok (/data/storage/el1/bundle/libs/arm64/jit-unlock.node) rc=0、两处 [wrapper] JIT unlock ok (...) rc=0、[agent-host] selftest: enableJIT ok rc=0；进程树 main/Renderer/NetworkService/NodeService×3 齐全，截图确认 UI 正常。同时修正上一轮误判：11-05 21:40 把旧 sqlite addon 的加载失败归因于 "v40 libc 缺 forkpty/openpty"，实际它放在 resfile，无论依赖如何都会因命名空间限制失败；真实约束是"只能从 libs 目录 dlopen"。以后新增任何 .node 必须同时落到 electron/libs/arm64-v8a/ 并从 /data/storage/el1/bundle/libs/arm64/<name>.node 加载。 2026-11-06 16:05 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·根因] 电脑控制/浏览器控制不可用的真因：MCP 宿主进程一直没起来，不是插件不支持。①agent-diag.log（经主进程 inspector 9229 读取）显示 mcp spawn ... cmd=/data/service/hnp/electron.org/... → /bin/sh: ... inaccessible or not found、exit code=127；v40 已移除 HNP，而 resolveRunnableElectron() 对 HNP 路径无条件放行 → 所有 MCP server（node_repl / browser-use）都起不来，agent 工具集里自然没有 mcp__*。②逐项实测可执行性：process.execPath=libs/arm64/libelectron-launcher.so（644，不可执行）；bundle 内 resfile/electron（755）被应用进程 execve 时仍 Permission denied（bundle ELF 只能由 ArkTS childProcess 拉起）；HNP 目录不存在；~/.harmonybrew/bin/node（v26.12.1）可正常执行。③改法：resolveRunnableElectron() 改为"真实 spawn -v 探测各候选"，首选 brew node 并缓存；MCP 中继/CUA helper/devsh token 发布全部走它。④修复后 diag：mcp electron pick=.../node ver=v26.12.1、mcp spawn id=2 cmd=.../node、first-stdout len=3421（工具清单含 js）、alive=true —— MCP 注册成功。 2026-11-06 16:12 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·完成] CUA 输入框入口 + 窗口阴影 + 懒连接 + 密钥位置 四项修复落地并实测。①输入框「电脑操作」按钮：上游还有第二处平台判定 function ZZt(){return typeof navigator<u&&/Windows/i.test(navigator.userAgent)}（5d 只改了 userAgent.includes(Windows) 那处），已在 prepare-resfile 加 cua-composer-entry(renderer) 结构补丁（hits=1），截图确认按钮出现。②窗口阴影：hilog 实锤 [shadow] setWindowShadowEnabled succeeded, id: 1, enabled: false —— 是 ArkTS 收到 false 才关的，来源是 Electron 侧（平台伪装 win32 后主窗口走 frame:false+透明+acrylic 分支，hasShadow=false，libadapter 原样转发）；win.setHasShadow(true) 在该引擎上是空操作。已改 AppWindowAdapter.applyShadow 忽略上游 false、OHOS 桌面窗口一律开阴影，实测 enabled: true (electron asked false)，截图阴影恢复。③电脑控制懒连接：helper 启动只 listen socket，删除启动期 ensureDevice 轮询；hdc()/hdcSecond() 首次调用时 ensureHdcLazy()，无端口/连不上才退出码 3 让应用弹一次端口框；bootCua 启动不再问端口。④hdc 密钥落 files：el2/base/files/hdc-js-key.pem（cache 旧钥匙自动迁移），实测该文件 0600 存在、helper/发布均复用它；devsh token 发布成功（publish exit=0 written port=12345，/data/local/tmp/devsh.token mtime 更新）。⑤端到端旁证：设备 agent 已在真实调用 CUA（helper 日志 REQ capture_app/press_key_to_app、capture_app webArea=true elements=22），桌面顶部出现横幅。⑥另：客梯——aa start 在锁屏时返回 10106102，需先解锁。 2026-11-06 16:30 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [调查] 窗口圆角：Electron 侧根本没有任何圆角接口，现状是系统默认值。①electron/libs/arm64-v8a/libadapter.so 全量绑定名里 AppWindow.* 共 30 项（ActivateWindow/Bind/CloseWindow/CreateWindow/SetBounds/SetBackgroundColor/SetContentProtection/SetOpacity/SetShadow/SetResizable/SetAspectRatio/SetWindowLimits/StartWindowMoving… ），无任何 CornerRadius；②grep -a -o -E "[A-Za-z_.]*Corner[A-Za-z_.]*" libadapter.so = 0 命中，libelectron.so 里的 corner 命中全部是 Blink/CSS（PreferredCornerRadii、CSSCornerShapeInsetBoxShadowFollowsContour），非窗口级；③仓库内唯一圆角调用是 CuaBannerAdapter.ets:81 的 setWindowCornerRadius(h/2)（胶囊横幅），主窗口无调用。结论：不存在"圆角传错"，主窗口圆角由 OHOS 窗口管理器默认给出。④几何实测（temp/corner1.jpeg 3000×1688，窗口 top=198/right=2186/bottom≈1399）：多行多列解出半径均 ≈28 物理 px，四角一致；scaleFactor 1.668 → ≈16vp，正是系统默认圆角。当前渲染正常，无需改代码。 2026-11-06 16:30 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·完成] 首页目录授权弹窗改为 ZCode 风格并真机验证。①新增 web_engine/src/main/ets/utils/ZcodePromptDialog.ets：仿 CUA hdc 端口提示（320 宽、圆角 16、主文案 16/Medium、副文案 13 灰、幽灵取消 + 实心主按钮、shadow(24, #33000000, offsetY 8)），深浅色双色板；showZcodePrompt() 走 wrapBuilder + ComponentContent + openCustomDialog({ isModal, autoCancel, onWillDismiss })，拿不到 UIContext 时 resolve(false) 不阻塞流程。②PermissionManagerAdapter.showToolchainDialog() 改调它，深色判定用 resourceManager.getConfigurationSync().colorMode === ColorMode.DARK。③真机（清空 toolchainFolderUri pref 后重启）每 2s 连拍，temp/d3.jpeg/temp/dlg_zoom.png 捕到弹窗：白卡、圆角、粗标题、灰描述、取消(幽灵)+去选择(黑实心) 全部符合；确认后拉起系统选择器，选「个人」后 pref 恢复 file://docs/storage/Users/currentUser。④复位：pref XML 写回原值 → 强停重启 → 校验 pref 完整、spawnSync('/storage/Users/currentUser/.harmonybrew/bin/node',['-v']) = v26.12.1（status 0），截图 UI 正常无弹窗。⑤收尾微调文案去掉多余空格：'…请在选择器中选择 个人 文件夹' → '为确保工具链可用，请在选择器中选择「个人」文件夹'（原串在 320 宽下断成"选择 个人 文 / 文件夹"）。 2026-11-06 16:50 | sess_43fe3079-6e93-4b11-8b2f-099d89be160e | [调查] CUA 七项问题的根因定位（读 helper/宿主源码 + 真机取证）。①hdc-js.mjs 的 shell() 固定 channelId=1、FrameReader 按 FIFO 派帧 → 同一连接上的并发 shell 会互相吞帧；而 helper 的 allApplications/resolveBundle 用 Promise.all([ps, bm dump -a]) 并发跑，且两处 catch 都把异常吞成 [] → 「235 个 / 0 个」自相矛盾、list_apps 恒回空数组（真机 hdc -t 10.126.126.5:12345 shell "bm dump -a | wc -l" = 236 行含表头，本地按 helper 正则解析得 235 个 bundle，证实设备侧数据充足）。②名字匹配只认 bundle.split('.').pop() 且大小写敏感；bm dump -n 的 label 是 $string:app_name（不展开，上游行为）→ 拿不到「哔哩哔哩」；真机桌面图标标签挂在 com.ohos.sceneboard 名下（实测「酷安」节点的 bundleName 继承自 sceneboard），不能当应用名解析。③list_windows({}) 在宿主 node-repl-host/dist/mcp/server.js 的 listWindowsSchema = object({ app_ref: appRef }) 处被 parseAppRef(undefined) 拒掉（正是用户看到的英文报错）。④findSubtree 返回第一个 bundleName 命中，而同一应用在 dumpLayout 里有多层同 bundle 节点（根窗、surface、web 容器）→ 窗口范围忽大忽小，造成假 stale_frame（[1177,358,2845,1512]→[1992,...] 正是同一右/下边界的子区域）。⑤真机 dump（300KB/438 节点）证实：窗口里有 Stack/Row/Column/__Common__ 大量无名壳，XComponent/web 容器无 text；且 ZCode 窗口根 = [386,198][2187,1399]（多窗口桌面，非全屏）。 2026-11-06 17:10 | sess_43fe3079-6e93-4b11-8b2f-099d89be160e | [验证] 修复落地（模板 + resfile 双份同步）+ 真机数据回归。①hdc-js.mjs：shell 改为每连接串行队列，读帧超时即 close()（避免残留帧串到下一条命令）；②ohos-helper.js：应用枚举串行 + 60s/3s 缓存，installedBundles/runningApps 失败改抛 HelperError（不再伪装成空列表）；resolveBundle 打分匹配（整包名/末段/包含/缩写 Bilibili↔bili、大小写不敏感、运行中加权、失败时强制刷新一次已安装列表），并用"无障碍树可见文本整串相等"兜底中文名（排除 sceneboard/ZCode、只认整串相等，防误绑桌面）；list_windows 无 app_ref 时枚举全部窗口根（bundle/pid/bounds，[x,y,w,h]）；findSubtree 改选最大面积窗口节点；assertFrameFresh 用帧自身的 delivered 宽度换算、失配 320ms 后复测一次；web/XComponent 容器保留为 web-content 元素（带 AXScroll + native token）；compactElements 按面积折叠包装层（无名、一个子节点占 ≥80%、其余 ≤35%）+ 同文本同位置去重；dumpLayout 文本出现 U+FFFD 时整棵重 dump 一次再剥离替换符；window.bounds 语义修正为上游 [x,y,w,h]（宿主 visibleElementCenter/优先级排序按此消费）。③宿主侧：prepare-resfile 新增 cua-list-windows-optional(host)（schema 改 appRefNullable + 描述补充"可省略 app_ref"）与 cua-list-apps-installed(host) 补丁，并已同步到 resfile 现网副本。④真机回归：用新 flattenLayout 重放实抓 dump，ZCode 窗口元素 29→14（父链折叠、depth≤4），sceneboard 73→67 且真实图标标签保留；用 235 个真实 bundle 列表验证 Bilibili/bilibili/BILI/bili → yylx.danmaku.bili、coolapk → com.coolapk.hmclient、zhihu → com.zhihu.hmos；bm dump -a 解析 235 条、ps 解析过滤 .elf 与 : 子进程均符合预期。⑤未做：装机端到端（helper 需重装 HAP 后生效）；中文名（如「哔哩哔哩」）仅在目标应用窗口自身暴露该文本时可解析，否则报错会给出相近 bundle_id 提示。 2026-11-06 17:35 | sess_43fe3079-6e93-4b11-8b2f-099d89be160e | [验证·完成] 装机 + 端侧 agent 三轮回归（devecocli run ×3）。测试方式：主进程 inspector 9229（hdc fport 既有映射）注入 prompt 到端侧 ZCode 输入框（Input.insertText 走真实输入管线），由端侧 agent 用 CUA 自测。①第一轮 7 步：getState=237 个应用；B站 getAXState=150 行/146 元素（此前 358+）；click→type 无 stale_frame；但 list_windows({}) 仍被 schema 拒——根因是 插件包 staged 缓存不刷新：wrapper.mjs 只在 .zcode-plugin/plugin.json 缺失时拷贝，el2 cache/packages 里一直是旧 node-repl-host/server.js（4,873,118B），HAP 里新文件从没生效。②把 wrapper 改为"源目录文件 size 指纹变化即整包重拷"后，list_windows({}) 直接返回 6 个真实窗口（bundle_id/pid/bounds），staged server.js 变为 4,885,515B 且 appRefNullable 生效（无需手工清缓存）。③第二轮发现 冷启动 pid=0：getApp('coolapk') 冷启动就绪后 app.pid=0，客户端把 0 写进 app_ref，宿主 parseAppRef 判 pid must be a positive integer → 下一步 elements() 全灭；helper 新增 pidAfterLaunch() 轮询真 pid，客户端兜底只接受 pid>0（prepare-resfile cua-client-pid-positive(ohos)）；复测 pid=36824、181/189 元素全通。④第三轮发现 web 容器被降噪折叠 与 窗口 bounds 是可见裁剪区：浏览器 Web→rootWebArea→…→genericContainer 同尺寸无名链把 web-content 折没；窗口被遮挡时 bounds 缩成条带（ZCode [356,114][2157,1315]→[356,114][2157,180]），正是用户假 stale_frame 的来源（右/下边界不变、左边界跳变）。修法：web_content 豁免折叠 + 同区域只留最外层；窗口几何统一用 origBounds（nodeBoundsOf）。⑤终验（端侧 agent 三步全绿）：list_windows=6 窗口（含 browser/bili/zcode 完整几何）；浏览器 201 元素，含 index 57 web-content（AXPress/AXScroll/bounds [264,123,650,365]）；酷安 181 元素。helper 日志证据：capture_app elements=146/201、app pid=36824、type_text ... out=No Error、resolveBundle 名称「酷安」→ com.coolapk.hmclient。 2026-11-06 20:10 | sess_fc8a6098-2962-4827-9606-e34b22c16d50 | [复盘] 文档盘点与清理：①runlog 2026-10 条目 293 行（含续行）移入 docs/runlog-archive.md 新增「2026-10 条目（2026-11-06 归档）」节，runlog 只剩 2026-11 的 27 条；②docs 下 7 套华为/样例参考资料（约 3MB，2026-06-25 基线导入）统一移入 docs/reference/ 并新增 README 索引（标注为 v34 时代参考，现行结论看 PORTING_STATUS/patch-inventory）；③删除 gitignored 临时产物 .tmp-dl（723MB，含 electron-default.hap 719MB、构建日志、截图）与 temp（5.8MB 调试截图与临时脚本），以及空目录 .tmp；④修正过期描述：PORTING_STATUS 标题改为「3.16.x 基线」、当前版本 3.16.3→3.17.2、层数 7→13，log.md 行数说明（~2600→现状）与目录补 10-29~11-06 条目，upstream-comparison 本仓引擎改为 Electron 40.1/Chromium 144/Node 24。 2026-11-06 21:10 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [调查] 粘贴大图附件卡 0% 的根因：FIFO stdin 短写/EAGAIN 截断大帧。①现象：输入框粘贴图片（缩略图正常）上传恒 0%，删附件后纯文本也发不出，重启才恢复；手选文件正常（localPath 有值走本地零拷贝 uploadStatus:ready，根本不上传）。②代码路径：粘贴无本地路径 → wXt() 把 Blob 读成 dataBase64 → transport.attachmentPut 一次性走 IPC → host 分 384KB 分块 v4/attachment/begin|chunk|commit；2.4MB 图片 = 7 chunk。③真机取证（~/.zcode/v2/logs/2026-11-06.log + hilog）：小图三次上传每步 120–160ms 成功；大图 attachmentBeginV4 OK(131ms) 后第 0 块无响应，attachmentChunkV4 FAIL (48695.4ms)、其后 queryConversationCommandsV4 FAIL (15822.9ms)、attachmentReadV4 FAIL (15821.8ms) 全部只在「ZCode Protocol client disposed」时才失败 → agent 收帧后不再吭声，整条 stdin 停摆。④帧本身完整：把 agent-in-37330-1.jsonl 里的 chunk 帧 base64 解回来验证 dataLen=524288、JSON 合法 → 卡点在「文件→FIFO→agent」这段。⑤复刻 agent-host 的 FIFO+readline 通道实测：32KB 帧 writeSync 返回 32786 且消费端收到；128KB/512KB 帧 writeSync 只返回 65536，消费端零收到；继续写抛 EAGAIN。结论：OHOS FIFO 写端是 non-blocking 语义，单次 write 最多 64KB（管道缓冲上限），旧代码 fs.writeSync(0,data) 忽略返回值 → 大帧被静默截断 → agent 行解析器等不到行尾 → stdin 永久死锁。注入 128KB 假帧到 agent-in 可稳定复现（64KB 帧正常、128KB 起全挂），也解释「必须重启应用」。 2026-11-06 21:10 | sess_8622cd3d-8ca0-42d8-a95c-e4f5e31fe9da | [验证·完成] stdin 大帧修复落地 + 构建装机 + 端侧确认。①agent-host.mjs（模板 + resfile 双份）：新增 writeAllToStdin() —— 按 writeSync 返回值推进、EAGAIN 让出事件循环 5ms 重试、单次写限 32KB、60s 超时报 stdin stalled；stdin 泵改可重入 async（busy）；readSync 按真实字节推进；按字节找 \n 再整行解码（原按 1MB 块 toString('utf8') 会切断多字节字符）；>64KB / >500ms 帧打 stdin frame N B written in Xms。②entry.mjs：stdin 诊断行带 frame=<字节数>；输入文件滚动 16MB→64MB 且仅当当前帧 <8MB 才截断（原逻辑会丢掉正在追加的大帧）。③复刻环境验证修复：128KB/512KB/2MB 帧分别 7ms/31ms/148ms 完整送达 readline 消费者（修复前全部 0 字节）。④node scripts/build.mjs 通过（必需补丁全命中、无 hotpatch loader），HAP 665.0MB，hdc install -r 成功；重启后 pid 57074，部署到 el2/base/cache/agent-host.mjs 的副本已含 writeAllToStdin/stdin stalled。⑤用户端侧确认粘贴大图附件正常。提交 1c86d9e5 并推送 origin/main（f59d0b99..1c86d9e5）。