mtfyun/nodeagent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
183 Commits 1 Branch 14 Tags
2437b0e863d4647075f4eaf06b918dd55b06d03e
Commit Graph
183 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
jkooe 2437b0e863 fix(console): unverbatim 用 to_str 而非 to_string_lossy（不损坏非 UTF-8 路径） 
to_string_lossy 会把非法字节替换成 U+FFFD 再重建路径 —— 那是损坏路径，
比不净化更糟：原本只是 node 报 EISDIR，改完变成指向一个不存在的目录。

改为 to_str()：非 UTF-8 → None → 原样返回（Windows 上是含未配对代理项的路径，
Unix 上是含非法字节的文件名），绝不悄悄改写。

新增守卫 unverbatim_对非_utf8_的_verbatim_路径必须原样返回不得损坏（#[cfg(unix)]）：
构造必须同时含 \\?\ 前缀与非法字节才有区分力 —— 不带前缀时新旧实现都走
「原样返回」那一步，测不出差异。
注入故障（退回 to_string_lossy）实测该守卫如期变红；还原后 sha256 逐字节一致。
pnpm test:rust 18/18（+1），clippy 零告警。
 2026-10-13 20:21:51 +08:00
jkooe 56f64e1cc1 docs(console): 把 verbatim 路径的证据精确到「脚本参数」这一维 
真机二维四格实验（ProcessStartInfo，精确对应 Command::new(prog).arg(script)）：
  G1 plain-prog + plain-script    -> exit 0，正常
  G2 plain-prog + VERBATIM-script -> exit 1，EISDIR lstat 'C:'
  G3 VERBATIM-prog + plain-script -> exit 0，正常
  G4 VERBATIM-prog + VERBATIM     -> exit 1，EISDIR lstat 'C:'

结论：炸的是「脚本参数」带 verbatim，不是「可执行文件」带 verbatim。
旁证：真机上被控端与 sidecar 的 program 都带 \\?\ 却长期存活。

因此改准注释口径：净化 script 是关键修复，净化 node 属防御性
（守住「凡交给外部进程的路径都干净」这条单一纪律，不靠记位置）。
行为零变化（纯注释 + CHANGELOG）。
 2026-10-13 20:16:07 +08:00
jkooe eec76ed91e fix(console): 交给 node 的路径去掉 Windows verbatim 前缀（真机 sidecar 秒退根因） 
真机现象（Windows 11 ARM64，控制台 v2.0.3）：点「检查更新」立刻报
「sidecar 已退出（stdout 关闭），请重试」—— sidecar 在请求进行中真的退出了。

真机 A/B（同一个 node.exe、同一份 sidecar.mjs，只换脚本参数写法）：
  C:\…\sidecar.mjs        → 2.5 秒返回结果，进程常驻
  \\?\C:\…\sidecar.mjs    → 0.47 秒退出，exit 1，零 JS 执行

根因：Tauri 的 resource_dir() 在 Windows 上返回 canonicalize 后的 verbatim 路径，
把它当参数交给 node，node 启动期 realpathSync 把 `\\?\C:` 拆成 `C:` →
EISDIR ... lstat 'C:' → exit 1，一行 JS 都来不及执行。
本地/CI/开发模式全测不出：开发期走 CARGO_MANIFEST_DIR 的普通路径，只有打包后才暴露。

修法：
- 新增 unverbatim()：剥 \\?\UNC\ → \\、剥 \\?\ → 无前缀，纯字符串处理，全平台可调用
- 新增 sidecar_command()：唯一把路径交给 node 的地方，单测断言其最终 program/args
- resolve_node / resolve_sidecar / resolve_bundled_agent 全部出口加闸
- Sidecar::spawn 与 AgentManager::start 进程边界对 node/script/data_dir 三条路径净化
- autostart::app_exe() 净化（该路径进计划任务 -Execute）

回归：新增 3 条守卫；注入故障（去掉 sidecar_command 的 unverbatim）实测第三条如期变红，
还原后 sha256 逐字节一致。pnpm test:rust 17/17（14 → +3），clippy 零告警。
 2026-10-13 20:11:03 +08:00
jkooe 6adf11c85a fix(test): 两条守卫在 Windows 上必红（CRLF 与路径分隔符） 
CI run 38380306200（提交 73ed06f）Windows 单元测试 319/321，macOS 全绿。

① 仓库内全部版本号互一致 → 报 undefined apps/console/src-tauri/Cargo.lock
   根因：actions/checkout 在 Windows 默认 core.autocrlf=true → CRLF，
   而 Cargo.lock 的版本提取把 \n 写死。**同一隐患也在生产代码里**：
   version-write.mjs 另有一条 name…\nversion… 正则读旧值，CRLF 下返回
   undefined → 把 Cargo.lock 记入 skipped 并跳过 → 发版后滞留旧版本
   （正是本模块要消灭的分叉，且不报错）。
   修法：读旧值收敛到 readCargoTomlVersion / setCargoLockVersion().before
   单一真源，删掉重复正则；新增 splitLineEol() 拆「正文+行尾」后改写
   （不能写 ("".*)$ 兜行尾 —— JS 的 . 不匹配 \r）。

② W-01 根因守卫 → 把唯一真源自己判成违规（util\quote.ts）
   根因：file.slice(dir.length+1) 在 Windows 得到反斜杠路径，与白名单
   的 util/quote.ts 比不中 → 守卫自己错。
   修法：新增 relPosix() 归一成 /。

新增 4 条守卫：Cargo.lock / Cargo.toml 的 CRLF 纯函数用例、
CRLF 工作区上真跑 writeVersionEverywhere 再读回文件、
以及用 path.win32 形态字符串在 macOS 上直接测 Windows 分支。
注入故障实测 4 条如期变红；test:unit 325/325（321 + 4）。
 2026-10-13 18:57:04 +08:00
jkooe 73ed06f5f1 fix(console): 修复 sidecar 退出后被复用（Windows 更新超时根因） 
现象（Win11 ARM64 真机）：点「检查更新」等满 45 秒报「check_update 超时」。
对照：同一台机器手工拉起 sidecar 跑同一请求 6.989s 成功；现场 node.exe
只有被控端一个 —— 控制台的 sidecar 进程根本不存在。

根因：ensure_sidecar 只判「缓存里有没有实例」，不判「那个实例还活着没」。
往已退出进程的管道写，在 Windows 上未必立刻报错（缓冲区吞下即返回成功），
于是请求既不报错也永远等不到响应，只能干等到 request 的超时。

修法：
- Sidecar 增 dead: Arc<AtomicBool>，三处置死（stdout EOF / 写入或 flush 失败
  / shutdown 主动关闭）；stdout 关闭时唤醒所有在等的请求，让它们立刻失败。
- 新增 is_alive()：dead / child.try_wait() / 已被 take 走，拿不准一律按不可用。
- request() 入口先判存活，不可用即秒失败。
- ensure_sidecar 取到缓存实例先判存活，已退出则丢弃重建。
- 新增 3 条单测（含「对已退出的 sidecar 发请求必须秒失败」——给 30s 超时但
  断言耗时 < 5s，因为修复前的表现正是干等到超时）。注入故障实测守卫变红。
- pnpm test:rust 14/14；test:unit 321/321。

属控制台上壳变更，不触发 release patch；但需重建控制台安装包才能让用户拿到修复。
 2026-10-13 17:59:49 +08:00
jkooe 79969e9d5d chore(release): v2.0.3 v2.0.3 2026-10-13 17:36:54 +08:00
jkooe a1c51d62a0 docs(changelog): 记入本批三类改动，并统一版本叙述为 v2.0.3 
- 安全加固批次：18 条实机复现缺陷（含两条 P0 的完整根因与修法、崩溃链共同根因）
- 控制台单实例保护（症状：Windows 端两个被控端 / 旧服务端在跑时控制台起不来）
- 发版脚本漏改 Cargo 清单导致的版本号分叉
- 版本叙述统一：注释里原先散落 v2.0.4，与下一版号不符，全部改为 v2.0.3

⚠️ 本批含被控端变更，发版时 `pnpm release patch`（→ v2.0.3）必须执行。
 2026-10-13 17:16:51 +08:00
jkooe bce11514a9 fix(release): 发版脚本漏改 Cargo 清单导致版本号分叉 
release.mjs patch --dry-run 实测：只改 8 个 package.json + 1 个 tauri.conf.json，而
apps/console/src-tauri/{Cargo.toml,Cargo.lock} 里**同样存着 2.0.2** —— 发版后必然滞留，
与 tauri.conf.json 悄悄分叉，且**不报错**（Tauri 打包以 tauri.conf.json 为准）。

- 版本写入抽成 scripts/lib/version-write.mjs（纯函数、可测），release.mjs 调用它。
  抽出来的理由：埋在脚本里时单测只能断言「源码里出现过某个字符串」—— 那种守卫注入
  故障都不会变红（铁律：守卫要落在最终产物字节上）。
- Cargo.toml **只在 [package] 段**改（非 package 段里也可能有独占一行的 version = "…"）；
  Cargo.lock **按 [[package]] 块 + crate 名定位**（全文盲替换会改坏 thiserror 2.0.21
  这类依赖版本）。
- release.mjs 的「脏文件白名单」改为取自**实际改写结果**（changed），不再手写文件名列表 ——
  手写的那份一旦与写入逻辑漂移，要么拦下本该放行的（发版卡死），要么放过不该放行的
  （静默推走改动）。
- 新增 tests/unit/version-write.test.mjs（9 条）：在临时目录铺**真实文件**并 git init/git add
  （versionTargets 走 git ls-files，不真进索引就会假绿），跑完读回文件断言；另含一条
  **仓库版本号一致性守卫**，发版漏项会直接变红。
- 注入 4 处故障实测：编排漏 Cargo / Cargo.toml 全文盲替换 / Cargo.lock 按位置盲改 /
  仓库版本分叉 —— 全部变红，还原后全绿。
 2026-10-13 17:16:46 +08:00
jkooe 530bb4fca7 fix(console): 加单实例保护，修「Windows 端起了两个被控端」 
真机现象两桩：① Windows 上同时跑着两个被控端；② 旧的服务端还在跑时控制台起不来。
根因同一个：控制台没有单实例锁，再启动一次就是第二个进程 → 第二个 AgentManager
→ 抢同一个 8765 端口 → 后起的那个起不来。另有一条陈旧的 na-gui 计划任务指向测试
部署目录，也在抢同一个端口。

- 引入 tauri-plugin-single-instance（**必须注册为第一个插件**）。
- 第二次启动**不是**静默退出，而是「聚焦既有窗口 + 发 na-second-instance 事件」让前端
  刷新状态。这是刻意的：自启动实例是**无窗口**的，若第二次启动静默退出，用户双击图标
  只会看到「什么都不发生」—— 那比缺陷本身更难排查。带自启参数（AGENT_ONLY_FLAG）时跳过显示。
- 端口占用的报错补上「怎么找出占用者」：netstat -ano | findstr :<port> /
  lsof -nP -iTCP:<port> -sTCP:LISTEN，并新增一条单测。
 2026-10-13 17:16:41 +08:00
jkooe ae02252a1d fix(agent): 修复 18 条实机复现缺陷（2×P0 / 5×P1 / 10×P2 / 1×P3） 
一轮「静态审查 + 真机实测」的完整普查。基线 v2.0.2 / ad90634 上 unit 291 + e2e 30
全绿 —— 也就是说 18 条**全部落在既有覆盖之外**。报告见 bug-report-2026-10-13.html。

P0 两条：
- W-01：window.focus 把 JSON.stringify(title) 插进 PowerShell **双引号**串（PS 里 `\` 不是
  转义符、双引号串还会展开 $(...)）→ 命令注入。真机实测最险的是它**静默**：接口返回的是
  「正常业务错误」E_EXECUTION_FAILED: 未找到匹配的窗口，而 payload 已经把文件创建出来了。
  新增 apps/agent/src/util/quote.ts 作 psLit/shLit 单一真源，14 处注入点收敛（window.focus /
  uiaFind / ocrFind / system.ts 计划任务参数 / ps-helper.ts 的 -File 裸拼 …）。
- A-01：ACL 省略 clients 时 aclPolicy.clients.find 抛错，而这段落在 if (hasAcl) 块**之外**
  无条件执行 → 配置少写一个字段，每条 invoke 都崩掉被控端。
  ⚠️ 静态审查当时判它是「fail-open 放行」，实测是崩溃（更严重）。

崩溃链共同根因：ws.on('message') 用 void handleMessage() 且无 .catch，全仓又没有任何
process.on('unhandledRejection') —— Node ≥22 遇未处理 rejection 直接终止进程。两条畸形报文
（hello {protocol:123} / auth {hmac:1}）就能在**认证之前**打死被控端（verifyNonce 有 try/catch，
psk 默认路径的 verifyHmac 没有）。index.ts 新增进程级兜底：日志每次打、审计按 10s 限流
（否则畸形报文可高频刷爆 audit.log），且明确不退出进程（可用性优先，取舍写在注释里）。

其余 15 条：
- clients: [] → fail-open 全放行（判据改为「对象是否存在」而非「数组长度」）
- macOS screen.find 的 text 拼 bash → $(...) 实测执行（走 shLit）
- 控制台审计筛选项与协议 enum 漂移，除 invoke 外全 E_PARAM_INVALID
  → 新增 packages/protocol/src/audit-types.ts 作唯一真源，manifest enum 由它派生 + 编译期双向守卫
- monitor.start 的 target 注入、monitor id 路径穿越（读/删）→ psLit + guardPath
- keys{} + client_id:"constructor" 崩 → hasOwnProperty（原型链取值）
- 事件订阅跨控制端可见/可删、event.watch 绕开 fs_roots → 有状态资源落 owner + 统一白名单
- screen.capture 的 region 无上界 → assertRegionSane() 且**提前到枚举显示器之前**（fail fast）
- ipMatchesCidr('8.8.8.8','10.0.0.0/') → true（空掩码被 Number('') === 0 当 /0）
- CLI --timeout 静默失效（strict:false 下未声明选项被当 boolean，值掉进 positionals）
- 拒绝类事件不写审计 → 补 request.rejected / agent.error

回归：unit 321/321（+21）、e2e 33/33（+3 组硬化用例）、rust 11/11。
e2e 新增用例的姿势：每场景**独占端口 + 独立临时 NODEAGENT_HOME**（首版复用端口，
连上了上一块的残留实例，把对照组误判成「实现有缺陷」）。
新增守卫均按铁律注入故障实测：确认会变红、还原后复核一致。
 2026-10-13 17:16:36 +08:00
jkooe ad90634a18 fix(test): 兜底守卫的片段排除在 Windows 上失效（跨平台路径分隔符） 
CI（Windows E2E，run 38166982975）在「单元测试」步骤红：

  not ok 102 - 兜底：capabilities 下命中坐标信号的新文件必须引用 PS_DPI_AWARE
    - apps\agent\src\capabilities\win-ps\prelude-image.ts（命中 "CopyFromScreen"）

而本机 macOS 全绿 —— 又是一例「本地全绿 ≠ Windows 绿」。

根因：`rel = relative(ROOT, full)` 在 Windows 返回 `apps\agent\…`，而排除规则写的是
`rel.includes('capabilities/win-ps/')`（**硬编码 "/"）→ 在 Windows 上恒为 false
→ 片段文件被误报成违规。排除本身是**对的**（prelude-* / body-* 由 WIN_HELPER_PRELUDE
在最前面统一注入 DPI 感知，其序位已由第 5 条断言），错的只是判断依赖了平台分隔符。

修法：
- 新增 `toPosix()`：把任意平台路径归一为 posix 形态（附注释说明为何必须显式归一）；
- 把「是否排除」收敛成纯函数 `isWinPsFragment(relPath, name)`，**函数内自带归一化** ——
  调用方传什么形态都正确，且可在本地直接断言；
- `walk` 内改用归一化后的 `rel` 并调用该函数。

新增守卫（第 9 条）：直接喂 Windows 反斜杠路径断言排除逻辑，把这类差异钉进
「本地可验」的范围。已用 `path.win32.relative()` 在本地**真实复现** CI 场景
（修复前 false → 误报；修复后 true → 正确排除），并注入故障实测该守卫会红。

测试：dpi 守卫 9/9；pnpm test:unit 291/291。
 2026-10-12 03:17:44 +08:00
jkooe 02887e265b fix(agent): 图形能力在高 DPI（200% 缩放）下坐标错位 
真机（Parallels 27 + Win11 ARM64，主机 200% 缩放、物理 3600×2020）暴露：
被控端 PowerShell 助手进程**默认 DPI 不感知**，同一进程里并存两套坐标系 ——

| 调用 | 不感知时 |
|---|---|
| Screen.Bounds / VirtualScreen | 逻辑 1800×1010 |
| CopyFromScreen | 按物理裁剪 → 缺省只截到屏幕左上 1/4 |
| SetCursorPos | 被系统 ×2 |
| UIA（screen.find） | 物理（与进程是否感知无关） |

净效果：screen.find 给出的物理矩形**不能**直接喂 input.mouse.*，必须人工除以 scale
（上一轮靠这个临时绕法才点中主题按钮 —— 能绕，但属用户侧的隐式约定，必须消灭）。

- 新增 apps/agent/src/util/dpi.ts：PS_DPI_AWARE（SetProcessDPIAware 前置段）。
- 注入全部坐标相关脚本：screen.ts / input.ts / window.ts（WIN_HELPER_PRELUDE，覆盖
  window.list 与 window.focus）/ record.ts；并把它从 win-ps/prelude-ocr.ts 的 try{} 里
  移出 —— 放在 try 内一旦抛错就被 catch 吞掉，助手会静默退回不感知。
- screen.ts 显式改用 $d.Bounds.Width（已是物理），scale 仅作参考。
- 新增守卫 tests/unit/dpi-awareness.test.mjs（8 项）：断言**实际下发的脚本文本**，
  而非「源码里出现过常量」—— 首版按源码扫描，注入故障实测不会变红；改为断言
  buildInputPsScript / buildListDisplaysScript / buildCaptureScript / WIN_HELPER_PRELUDE
  的脚本串后，二次注入故障精准变红。

真机终验（零换算）：
- screen.info 3600×2020，与裸 GetSystemMetrics 一致；
- input.mouse.move(x,y) 读回物理光标 == (x,y)（4 处抽样全中）；
- screen.find 物理矩形中心**直接** click → 主题单选 UIA selected 正确翻转且可逆。

文档：VM-VERIFICATION.md 新增 §10（坐标口径缺陷本体 / 复验配方 / 输入注入失效的逐条
排除与判决证据 / 两条 prlctl 通道的语义差异）；console-plan.md 补 ARM64 真机安装冒烟与
界面实点记录（含新发现 P2：控制台无单实例保护）。

⚠️ CHANGELOG 备注：本批**属被控端变更**，与上一节「本轮不升版本号」的结论不同 ——
发版必须升 PATCH（→ 2.0.3），否则 agent.mjs 会谎报一个并不包含本修复的版本。

测试：dpi 守卫 8/8；pnpm test:unit 290/290。
 2026-10-12 03:11:34 +08:00
jkooe c20e71bddc docs: 补齐 Windows 端控制台文档（含三次 run 的失败-修复-实证全过程） 
README / CHANGELOG / docs/console-plan.md 三处同步：

- README：补 Windows 双架构安装包实测体积、第三条断言（解开安装包查内容）、
  以及实测解出的 node.exe 体积与 PE Machine。
- CHANGELOG：新增「Windows 端控制台安装包」整节，含双架构理由、
  为什么用原生 ARM runner、cfg!(windows) 分支首次被编译器看到、
  以及三次 run 的完整过程（体积断言写错 → `&` 调 GUI 程序不等待 → 双绿）。
- docs/console-plan.md：断言表 2 条 → 3 条；新增三节实测记录；
  产物形态表补实测体积；8.2 指标验收的「Win 安装包 < 40MB（待实测）」补上实测值。

另修复：`## 界面观感约定（2026-10-11）` 标题被上一轮编辑误吞
（正文直接从「两轮纯界面调整」开始），已恢复。

留下两条可迁移教训：
1. 体积阈值属于「中间逻辑自洽」式断言 —— 判据要落在产物内容上；
   且压缩容器与未压缩目录的体积不可直接比。
2. `msiexec.exe` / NSIS 安装包是 GUI 子系统程序，PowerShell `&` 调用
   既不等待也不设 $LASTEXITCODE → 必须 Start-Process -Wait -PassThru。
 2026-10-12 00:20:50 +08:00
jkooe e616e80819 fix(ci): 取安装器退出码改用 Start-Process -Wait，& 调 GUI 程序不等待也不设退出码 
第二个 run（38152850819）两 job 仍同点红，但已是另一处原因，且同样是
「静默失效」：日志里 `msiexec /a 失败（退出码 ）` —— $LASTEXITCODE 是空的，
而整步从开始到抛错只过了 0.8 秒。

根因：msiexec.exe 与 NSIS 安装包都是 **GUI 子系统程序**，PowerShell 用 `&`
调用时**既不等待其结束、也不设置 $LASTEXITCODE**（于是 $null -ne 0 判真，
在安装器还没跑完时就当场抛错）。arm64 那条没有 MSI、直奔 NSIS，
失败形态一模一样，正是同一根因的第二个样本。

修法：
- 两处都改 Start-Process -Wait -PassThru，读 $p.ExitCode（确定性等待）。
- 参数拼成**单个字符串**传入，避免 -ArgumentList 数组被 PowerShell 自动加引号
  而破坏 NSIS `/D=` 的「必须原样、不加引号、且是最后一个参数」语义。
- 新增 Wait-PayloadRoot：安装器可能「自己先退出、由子进程继续装」，
  给最多 30 秒收敛时间再判定「找不到 node.exe」，避免竞态误报。
- 打印安装器实际退出码，便于下次一眼看出是哪一类失败。
 2026-10-12 00:05:01 +08:00
jkooe 71f2cd2597 fix(ci): 控制台 Windows 断言改为解开安装包查内容，不再用体积阈值 
首个 run（38151366534）两个 job 双双失败，且失败点完全一致：
第 14 步「断言安装包存在且体积合理」。构建链路本身全绿 ——
tauri build（msi 34.2MB / nsis 19.5~23.2MB）、产物自举
（打包内 node v22.23.3 真跑起打包内 sidecar）都成功，
是守卫自己错了。

错在哪：断言写成「安装包体积 > 50MB」，理由是「含 Node 运行时约 80MB」。
这把**未压缩的目录形态**（.app ≈ 92MB）当成了**压缩安装包的体积** ——
LZMA 下 node.exe 自身就能压到 1/3~1/4，阈值必然误杀。
更根本的是：体积阈值属于「中间逻辑自洽」式断言，包大不等于
node.exe 真在里面，且压缩率会随版本漂。

改为解开安装包、查内容（msi 走 msiexec /a 管理安装，nsis 走
/S 静默安装），一次钉死三件事：
  ① node.exe / sidecar.mjs / agent.mjs 三样随包资源必须都在；
  ② node.exe 的 PE Machine 必须等于目标架构（最终产物的架构断言，
     对治「arm64 包里装的是 x64 node.exe」那类只在真机暴露的事故）；
  ③ node.exe 解压后 > 40MB，挡住占位文件。
附带收益：真装一遍本身就是安装器冒烟。

另加 timeout-minutes: 8，避免静默安装万一卡住把 job 拖满 60 分钟。
 2026-10-11 23:48:29 +08:00
jkooe 1471708f35 ci: 新增 Windows 控制台安装包构建（x64 + arm64 双架构） 
在此之前，控制台的 Windows 侧只被验证到「prepare:node + 自举」（见 windows-e2e），
**从未真跑过 tauri build**。而 Rust 里那些 cfg!(windows) 分支（taskkill 收进程树、
PowerShell 计划任务、node.exe 路径解析）在 macOS 上只被类型检查、
从未被编译成 Windows 目标，更没有产物级验证 —— 本工作流是它们的第一道真闸。

为什么必须双架构
----------------
被控端发布包出过「arm64 包里装的是 x64 node.exe」的事故：在 ARM Windows 上
**能 listen、但 TLS 握手不完成**，且 macOS 侧 100% 复现不出。
控制台同理 —— 它内含 node 运行时，且要用它**托起本机被控端**（即 TLS 服务端）。
故 x64 / arm64 必须各出一套。

为什么用原生 ARM runner 而不是交叉编译
------------------------------------
`windows-11-arm` 是 GitHub 的 ARM64 Windows runner（公共仓库免费，本仓库为 public），
在它上面 arm64 是**原生构建**。若改走 x64 机器交叉编译，需要 VS 的 ARM64 工具链，
且 prepare-console.mjs 的自检要**真执行** node.exe（x64 机器跑不了 arm64 二进制），
会逼着引入「跳过自检」这类削弱验证的开关 —— 宁可等原生 runner。

两条断言是必需项，不是顺手检查
----------------------------
1. **构建机架构 ⇄ 目标架构**：ARM runner 镜像里确实存在 x64 模拟的组件
   （社区实测 python 即为 AMD64）。一旦 Node 也是模拟版，process.arch 会是 x64
   → 把 x64 的 node.exe 打进 arm64 安装包 → 真机上能启动、TLS 握手不完成，而 CI 全绿。
2. **随包 node.exe 的 PE Machine**：与 pack.mjs 的双架构校验同源思路 ——
   不只看「脚本跑完了」，而是直接读最终要打进那个包的二进制头。
   中间逻辑再自洽，也可能因上游给了错架构的二进制而产出错包。

另断言安装包体积 > 50MB：含 Node 运行时（约 80MB），体积过小意味着运行时没打进去
—— 那种包能装、但一启动就找不到 node。

产物：x64 出 msi + nsis（企业批量部署 + 普通双击各一），arm64 只出 nsis
（WiX 的 arm64 MSI 支持面较窄，不值得为它引入不确定性）。
 2026-10-11 23:25:16 +08:00
jkooe 456e452b30 test(console): 补两条「静默失效」守卫 —— CSS 变量闭合 + 首帧底色一致 
主题改动引入了一类新的静默失效：**拼错的 CSS 变量名不报错**。
`var(--na-sunkenTypo)` 类型检查过、构建过、运行也不抛 —— 颜色只是落回继承值，
界面「看着对但就是不对」，与本项目历来吃亏的失效模式同源。故补守卫：

7. 扫 src/** 全部 var(--na-*) 使用点，与 cssVars() 的键集合比对
8. index.html 的首帧兜底色 ⇄ 调色板 bg

第 8 条是因为首帧防闪脚本是全应用**唯一允许的色值重复处**（其执行时点早于任何模块加载，
重复无法消除）；既然允许重复，就必须有东西盯着它，否则改调色板忘了同步
→ 深色用户每次启动闪一帧白。

注入故障实测两条都会红：
  var(--na-sunken) → var(--na-sunkenTypo)   第 7 条红
  var(--na-sunken) → var(--na-sunkenx)      第 7 条红
  index.html #f4f4f5 → #ffffff              第 8 条红
复原后 8/8 绿，文件逐字节还原。

第 7 条顺带暴露过一次**守卫自身漏报**：正则原写 [a-z0-9-]+，遇到 `sunkenTypo`
这种含大写的拼错会在 `T` 处停下导致整个模式不匹配 —— 写错的变量名反而逃过检查。
放宽到 [^)\s,;]+ 后才真正生效。
教训：**注入故障不只验证守卫有没有，还要验证它覆盖了目标形态**。

单测 280 → 282。
 2026-10-11 14:34:41 +08:00
jkooe 4e6eb32929 style(console): 配色收敛为「简约白 / 高级灰」两套中性灰阶主题 
原配色是深色 + 品牌青绿（#63e2b7）+ naive-ui 默认绿主色 —— 颜色种类多。
改为两套**只用中性灰阶**的主题，侧栏底部一行切换，选择存 localStorage：

  简约白  页底 #f4f4f5 ／ 侧栏 #fafafa ／ 卡片 #ffffff
  高级灰  页底 #1d1f22 ／ 侧栏 #181a1d ／ 卡片 #24262a

几处刻意的选择：

1. 白主题页底**不是纯白**。卡片本身是白的，两者同色就只能靠 1px 分线撑层次，
   整页发「糊」；压一档浅灰后层次为「页底 < 侧栏 < 卡片」，且仍是白为主。
2. 主色位（naive-ui 的 primary）改**中性灰** —— 主按钮、开关激活态、进度条、
   勾选框全吃这一个值。原来它们是绿色/青绿，正是「配色不简单」的主因。
3. 语义色（成功/警告/错误/信息）**降饱和而非去掉**。这是运维工具，
   「运行中 / 出错」必须一眼可辨，全部灰化会导致误读。故它们只出现在徽章与
   告警这类**小面积**上，底色观感仍是「白 + 灰」。
4. **色值只定义一份**：src/theme/index.ts 的 Palette 既生成 naive-ui 的
   themeOverrides，又由 App.vue 运行期注入成 --na-* CSS 变量。
   若「TS 调色板」与「CSS 写死色值」各存一份，换主题时会**一半新一半旧、
   不报错、类型也抓不到** —— 正是本轮要消灭的失效模式。
   为此清掉散在 8 个文件里的 17 处写死色值（日志三流着色、代码块底色、
   节点选中边框、历史悬停…），复扫后自定义样式里硬编码色为 0。
5. 主题**只存 localStorage**，不落 Rust 侧 settings：那套 Settings 是给
   「仅服务模式」（无窗口、常驻托盘）也生效的偏好用的；主题是纯图形偏好，
   没有窗口时毫无意义 —— 为一件纯前端的事去动 Rust 命令面与契约守卫不划算。
6. index.html 内联一小段脚本做**首帧防闪**（否则深色用户每次启动闪一帧白）。
   此处**刻意重复 2 个底色值**，已在 index.html 与 theme/index.ts 两处注明
   「改底色时同步」—— 因为在它执行之前没有任何模块可依赖；
   除此之外全应用再无第二份色值。

验证：vue-tsc 0 错 ｜ 契约守卫 6/6 ｜ 单测 280/280 ｜ .app 重打通过（92.22 MiB）｜
两套主题均以真实采集数据回填渲染核对 —— 截图脚本顺带读回 --na-bg 与 body 背景，
确认主题真的切过去了，而不是「看起来像」。
 2026-10-11 14:29:50 +08:00
jkooe 591e44721a style(console): 界面一律不使用图标 —— 导航改纯文字，并关闭内置插画/图标 
触发原因是一次真实的渲染事故：侧栏那些 emoji 图标在非系统字体栈的渲染器里
退化成**豆腐块**（本机截图对比可见）。试过给图标指定 Apple Color Emoji、
全局字体栈加 !important、乃至 font-variant-emoji —— 分别无效或更糟
（最后一招把 ASCII 数字也拆成了 emoji 呈现）。而「哪套字体栈一定带 emoji」
跨平台并不成立，与其赌字形，不如不用。

  emoji 图标          → 路由表 meta.icon 字段整体移除，侧栏改纯文字
  n-empty 空态插画    → 16 处 :show-icon="false"（空态里的插画比图标更「图形」，
                        分布在 9 个页面，是最容易漏掉的一类）
  n-alert 类型图标    → 7 处（naive-ui 的 showIcon 默认 true，不显式关就在）
  n-popconfirm 询问图标 → 3 处
  夹在文案里的 ⚠      → TerminalView 的「高权限操作，请谨慎」保留纯文字

严重程度不靠图标也能读：n-alert 仍由 type 的底色/边框区分。

顺带清掉随包的模板残留资产：
  public/vite.svg、public/tauri.svg —— public/ 下的文件会被整体复制进产物，
  此前等于把 Vite / Tauri 的 logo 一并发出去了（且 index.html 的 favicon 正指向它）；
  src/assets/vue.svg —— 无人引用；
  index.html 的 <title> 还是模板默认的「Tauri + Vue + Typescript App」。
  原生窗口标题取自 tauri.conf.json（"nodeagent 控制台"），故此前不影响观感，
  但与 dev 态浏览器标签页不一致，一并改齐。

「不属界面图标、刻意未动」的三类写明在 CHANGELOG 里：
托盘图标（菜单栏没图标就点不到，关窗后应用无法寻回，属功能必需）、
被控端 CLI 自身打印的文本标记（⚠️/ℹ️/✅，是程序输出内容，非界面元素）、
控件的结构性部件（下拉箭头、折叠箭头、输入框清除钮、表格排序箭头）。

验证：vue-tsc 0 错 ｜ 契约守卫 6/6 ｜ 单测 280/280 ｜ 前端产物内已无任何 svg 与 logo 字样 ｜
macOS .app 重打通过（92.21 MiB，前端在无 public/ 下亦正常构建）。
 2026-10-11 13:50:49 +08:00
jkooe 2528f6b709 docs: 归档「控制台去命令行化」—— CHANGELOG / console-plan / README 
CHANGELOG：新增 [未发布] 章节，并按「刻意不升版本号」写明理由 ——
本轮新增的全是控制台功能，被控端能力集合未变；而 bundle-agent.mjs 会把根
package.json 的 version 注入 agent.mjs（__AGENT_VERSION__），
一旦为控制台功能升号，被控端就会谎报一个它并未包含的版本。故维持 2.0.2。

console-plan：新增「本机服务托管」章节，含需求逐条落点对照表、
消灭命令行窗口的三条措施、四条实测踩出来的约束、播种防降级的规则、
「不靠单一信号判实例在跑」的交叉判定、以及仍需图形环境人工实点的清单。

README：控制台页面表 7 → 9（补「本机服务」与「服务日志」），
打包命令改为 pnpm --filter nodeagent-console bundle，
体积数字修正 —— 原文写的 .app ≈ 6.8 MiB 是 Node sidecar 方案之前的旧数，
现为 .app 90.8 MiB / .dmg 33.78 MiB，并补「无需预装 Node」「自启与图形能力
要求登录用户会话」两条注意事项。
 2026-10-11 11:42:27 +08:00
jkooe ad569d4e6d ci: 控制台资源断言 2→3，并补 @nodeagent/agent 构建前置 
控制台随包分发的资源由 2 份增至 3 份（sidecar.mjs / node / agent.mjs）：
- rust.yml 的资源项断言同步改为 3，且不再只数个数 ——
  改为断言目标名确实包含 sidecar.mjs 与 agent.mjs、以及 node/node.exe 二者任一。
  只数个数的话，「三份但错了一份」照样过。

顺序依赖（本地验证发现不了的一类）：
prepare:node 现在还要 esbuild 打包被控端，故 @nodeagent/agent 的 dist 成为新的
前置产物。本地验证时 dist 早就在，会把这层依赖完全掩盖 —— 故在 steps 里显式写全
构建步骤，并加注释说明为什么顺序不能调。

rust.yml 的 paths 触发器补 scripts/lib/bundle-agent.mjs 与 apps/agent/**：
改这两处同样会让控制台打包结果变化，不触发就等于零覆盖。

windows-e2e.yml 同步：Windows 分支现在也覆盖 agent.mjs 的准备与解析。
 2026-10-11 11:42:14 +08:00
jkooe 2eb6a6f8bb feat(console): 本机被控端托管 —— 启停/重启/日志/自更新/托盘/开机自启 
目标：双击应用即用，全程不碰命令行。

  要求                落点
  不再打开命令行窗口   agent.rs 的 CREATE_NO_WINDOW + 自启拉控制台而非裸 node
  启动/停止/重启       AgentManager 五态状态机 + 界面按钮 + 托盘菜单
  检查更新             check_update / download / apply_update
  日志功能             stdout/stderr 双泵 + 环形缓冲 + 实时推送 + 过滤/导出
  后台运行             托盘常驻，关窗最小化而非退出
  开机自启             macOS LaunchAgent / Windows 计划任务

新增「本机服务」页（/local，默认首页）与「服务日志」页（/logs）。
默认路由由 /nodes 改为 /local：打开应用先看到本机被控端的启停面板，
而不是先要求用户填一个连接地址。

四条实测踩出来的关键约束（均已在代码里注明原因）：

1. 退出监控用轮询 try_wait，绝不把 Child 交给 wait()
   —— wait() 会取得 Child 所有权，此后 stop() 再也拿不到它去 kill。
2. 日志游标用独立单调 seq，不用位置下标
   —— 环形缓冲淘汰旧行后位置下标会漂移，前端增量拉取静默错位（不报错）。
3. start() / restart() 的接收者必须是 self: &Arc<Self>
   —— 监控任务要持自持引用。
4. macOS gui/<uid> 的 uid 运行时 id -u 现取，不硬编码 501。

播种（seeding）防降级：只有「随包版本 > 已安装版本」才覆盖数据目录里的脚本，
且版本比较按数值逐段（2.0.10 > 2.0.9）。若写成「同版本才跳过」，
用户自更新过被控端后下次开控制台会被静默降回旧版。

「实例是否在跑」不靠单一信号：管理器状态与 TCP 端口探测交叉判定，
以区分「本控制台托管的实例」与「手工安装的非托管实例」并给出不同处置。

消灭黑窗有三条措施，第 2 条最易漏：Rust 的 std::process::Command 默认不设
CREATE_NO_WINDOW，于是「界面上点一下启动」= 屏幕上闪一个控制台窗口。

控制台现在随包分发被控端脚本（资源 2 份 → 3 份：sidecar.mjs / node / agent.mjs），
用户装完控制台本机被控端即已就绪。

新增 tests/unit/console-commands.test.mjs（6 用例）钉住三类「不报错的失效」：
invoke ⇄ generate_handler! 双向、emit ⇄ listen 双向（这类失效会让界面永不刷新且零报错）、
bundle 资源名 ⇄ Rust resolve_* 字面量、sidecar 方法名、路由表 ⇄ 实际 view 文件。
已注入故障实测会红（改命令名与事件名 → 当场 2 条失败），非空转守卫。

验证：cargo check 0 错 0 警 / cargo test --lib 10·10 通过（含真起 node 子进程）/
clippy -D warnings 通过 / vue-tsc 通过 / 单测 280·280（274 → 280）/
verify-bundle 真 spawn 打包内 node 跑通打包内 sidecar。

⚠️ 托盘、关窗最小化、开机自启、界面点按钮仍需图形环境人工实点。
 2026-10-11 11:41:56 +08:00
jkooe a0be43d76c refactor(pack): 被控端 esbuild 配置抽为单一实现 
`agent.mjs` 现在有两个消费方：
  1. scripts/pack.mjs            → Windows 便携包 / 自更新载荷（Release 资产）
  2. scripts/prepare-console.mjs → 桌面控制台的随包资源（控制台要能托起本机被控端）

若各写一份 esbuild 配置就是「两套真相」——改了一处漏另一处时构建过、单测过，
只在真机产物里暴露（本项目已多次吃过这类亏）。故配置只此一份。

bundle-agent.mjs 导出 repoRoot / repoVersion / gitShortCommit / bundleAgent，
沿用原有全部约束：JS API（pnpm 隔离布局下 .bin/esbuild 在 Windows 不存在）、
不注入构建时间（否则每次打包字节不同，指纹比对失真）、
define 用 JSON.stringify 得纯双引号。

本次对 pack.mjs 的输出无语义变化（同一份 options 原样迁移）。
 2026-10-11 11:41:38 +08:00
jkooe 9ae1326be2 docs(readme): 版本基线更新到 v2.0.2 
v2.0.0（10-10）那条基线已过期。现基线：v2.0.2（2026-10-11，资产修复 ——
v2.0.1 的 arm64 包内实为 x64 node），51 项能力 · 274 单测（本地实跑全绿）。
 2026-10-11 10:45:48 +08:00
jkooe 1ab9ed22c7 docs(vm): 图形能力实测归档 + §9 复验配方 
- §7 图形能力行：⏳ 待登录态 → ✅ **登录态下全通**（真实桌面截图 1800×1010 / window.list /
  screen / audit verify），并注明「会话 0 的失败是身份问题，非产品缺陷」
- 修正重复的 §7 编号（→ §8），复位一处错位的表格行
- §6 补三条排查项：x64 Node 的 Prism 现象、`screen.capture` 的会话身份、
  **微软账户不支持传统 autologon**（MSA 凭据走 CloudAP，`LogonUser` 恒返回 1326）
- 新增 §9「图形能力复验配方」：本地账户 autologon → 计划任务 Interactive 启动 →
  三件核对 → 证书指纹变更的处置 → 验证完的安全清理
 2026-10-11 10:32:48 +08:00
jkooe 5e6231493e fix(pack): Windows 打包条目带目录前缀 —— 与 macOS 产物结构不一致 
CI 在 f85acad 上红了：`✗ zip 内未找到条目 node.exe: release/nodeagent-win-x64.zip`
（而本地 macOS 全绿 —— 方向恰好相反）。根因是两平台用了不同打包器：

- macOS/Linux: `cd <dir> && zip -r <out> .`       → 条目是裸名 `node.exe`
- Windows    : `Compress-Archive -Path '<dir>\*'` → 条目带前缀 `<dir>/node.exe`

两处一起修：

1. `scripts/lib/zip-pe-arch.mjs`：条目名匹配改用 **basename**，兼容两种打包方式。
   已用构造的带前缀 zip 实测通过，并注入错架构验证守卫仍会红。
2. `scripts/pack.mjs`：Windows 分支改用 .NET `ZipFile::CreateFromDirectory`
   —— 它打包**目录内容**，条目同样是裸名，从根上消除两平台产物结构差异。
   否则 CI 校验的产物与发布产物**不同构**，校验本身的价值打折；
   且「解压后双击 install.cmd」的说明会因多一层目录而失配。

教训：**「本地全绿」≠「Windows 绿」** —— 平台差异只有真 runner 能暴露（第 N 次实证）。
 2026-10-11 10:32:41 +08:00
jkooe f85acad5db chore(release): v2.0.2 v2.0.2 2026-10-11 10:18:28 +08:00
jkooe f558e3e7df chore(release): 交付物架构断言 + CHANGELOG 归置 v2.0.2 
已公开发布的 nodeagent-win-arm64.zip 内装的其实是 x64 的 node.exe
（两包内 node.exe 字节完全相同，PE Machine 均为 0x8664），该包在 ARM Windows 上
能启动、能 listen，却 TLS 握手不完成 —— 被控端实际不可用，而 macOS 侧 100% 复现不出。

- 新增 scripts/lib/zip-pe-arch.mjs：纯内置 zlib 手解 zip、读 PE 头判架构。
  不依赖 unzip / Expand-Archive（Windows runner 上没有 unzip）。
  含 CLI 自检入口，已注入故障实测会红（arm64 包去要 x64 期望 → 退出码 1）。
- release.mjs：生成资产前调用之，不符即中止发版 —— 拦在 tag/push 之前，
  是「交付物本身」的断言，与 pack.mjs 的「流程内部」断言分两层。
- windows-e2e.yml：把原先内联的 PowerShell 校验实现改为复用同一模块，
  消除两套实现各自漂移的可能。
- CHANGELOG：[未发布] 归入 v2.0.2。
 2026-10-11 10:17:30 +08:00
jkooe 87b74fd015 docs(vm): B5 按实测改写 —— arm64 包原生可用 / win-x64 包 TLS 握手不通 
原 B5 的假设是「x64 包在 ARM 上也许能跑」，本轮实测证伪：能启动、能 listen，
但 TLS 握手不完成（E_TIMEOUT），被控端实际不可用。补对照数据与复验步骤；
同步更新检测表、前置准备（③④ 改用 arm64 包）、结论标注规则与新增 §7 实测记录。
 2026-10-11 09:48:10 +08:00
jkooe b2404291b0 fix(pack): arm64 包内实为 x64 node —— 缓存名不含架构 + 补 PE 架构断言 
release.mjs 先打 x64 时会把运行时缓存为 node-runtime.zip（该名不含架构），
随后打 arm64 时误判「已缓存」直接复用 → arm64 包内 node.exe 实为 x86-64
（两份公开包内 node.exe 字节完全相同，sha256 同为 fdddbf45…，PE Machine=0x8664）。
该包在 ARM Windows 上能启动、能 listen，但 TLS 握手不完成（控制端只见 E_TIMEOUT），
且 macOS 侧完全复现不出。

- pack.mjs: 缓存名改为 node-runtime-<arch>.zip（按架构隔离）
- pack.mjs: 解包后断言 node.exe 的 PE Machine 与 --arch 一致（防呆 C，已注入故障实测会红）
- ci: windows-e2e 补「双架构包 PE 架构校验」，直读最终 zip 内 node.exe 的 PE 头
      （此前 CI 只打 x64 且只验 x64，arm64 打包零覆盖 —— 该 bug 必然逃过 CI）
- docs: CHANGELOG 记录 ARM64 真机对照实测

真机实测（ARM64 Windows 虚拟机，同机同参对照）：
  arm64 → TLS 握手成功 + PSK + 51 项能力两端一致 + exec/审计全通
  x64   → E_TIMEOUT（复现「能 listen 但 TLS 握手不完成」）
 2026-10-11 09:42:32 +08:00
jkooe e816c1fd39 fix(ci): Windows 上补 sidecar:build —— 新加的步骤漏了前置产物 
本轮新增的「控制台 Node 运行时（Windows 分支）与自举验证」一步在真实 runner 上失败：
  ✗ 未找到 D:\a\nodeagent\nodeagent\apps\console\sidecar\dist\sidecar.mjs
根因：prepare-console.mjs 的前置检查要求 sidecar 已构建，而该步被排在了构建 sidecar 之前
（rust.yml 里恰好已有「构建 sidecar」在前，所以那边没暴露）。

教训（本地跑过 ≠ CI 跑得过，又一例）：本地验证时 sidecar/dist 早已存在，
把「步骤之间的产物依赖」这一层完全掩盖了。**新增 CI 步骤时，应逐条核对
「该步依赖的产物由哪一步生成、顺序是否确实在其后」，而不是在已有产物的本地环境里跑一遍就认为通过。**
 2026-10-11 09:00:09 +08:00
jkooe a6be917637 docs: 记录控制台 Node 运行时分发与体积口径调整 
- console-plan.md：
  · §8.2 打包体积指标口径由「Mac .app < 30MB」改为「**分发件** Mac .dmg < 40MB」
    —— 原数字是 Tauri + Rust client 时代定的（当时应用内不含 JS 运行时）；
    改 sidecar 方案后应用必须自带 Node 运行时，.app 因此到 90.8MB，但用户下载的 dmg 仅 33.8MB。
    已明确标注「口径调整，待确认」。附本机 Electron 运行时本体 207MB 的实测对照。
  · 新增「Node 运行时分发」节：做法、三处实测约束（编译期契约 / strip 须重签 / 映射须对齐
    resolve_node）、验证方式（verify-bundle 真跑产物）、实测体积。
  · 「已知待办」由两条收敛为一条（剩 GUI 端到端人工验证，需图形环境）。
- CHANGELOG.md：新增 [未发布] 节，记录运行时分发功能与两处规避（SIGKILL 137、编译期契约）。
 2026-10-11 08:55:45 +08:00
jkooe 8664ec2926 ci: 覆盖 Node 运行时准备与「产物自举」（Linux + Windows 双覆盖） 
新增 runtime 准备脚本后，两件事此前零覆盖：脚本本身在 Windows 上的分支、
以及「打包产物能不能真跑」。补上：

- rust.yml：prepare:node 真跑（验证脚本可用 + 产物自检）→ 断言注入片段声明两份资源
  → `verify-bundle --runtime` 真 spawn 运行时跑 sidecar 走一次 JSON-RPC。
  paths 触发加上 scripts/prepare-console.mjs。
  注：Linux 上不走 strip 分支（macOS 专属），故「strip 必须 adhoc 重签」由 macOS 本机实测覆盖。
- windows-e2e.yml：新增一步跑 prepare:node + verify-bundle --runtime —— 该脚本在 Windows
  上走的是「复制 node.exe、无 strip」的另一条分支，此前从未被真实 runner 验证过。
 2026-10-11 08:55:38 +08:00
jkooe 22bc732334 feat(console): 控制台随包分发 Node 运行时（目标机器无需预装 Node） 
控制台的 sidecar 是 .mjs，此前只能在装了 Node 的机器上跑（resolve_node 会回退系统 node）。
新增 scripts/prepare-console.mjs 把 Node 运行时准备为 Tauri resource，随包分发给最终用户。

- prepare-console.mjs：复制本机 node → apps/console/src-tauri/runtime/，macOS 上 strip -x
  （108MB→86MB）**并 adhoc 重签**，再生成注入片段 tauri.bundle.gen.json；带幂等（同源跳过）
  与**产物自检**（真跑一次 node，失败即删除产物并报错，避免坏产物被静默复用）。
- apps/console/scripts/verify-bundle.mjs：验证「打包产物能否自举」——真 spawn 打包内的 node
  去跑打包内的 sidecar 并走一次真实 JSON-RPC 握手。
- package.json：新增 prepare:node / verify:bundle，bundle = sidecar:build → prepare:node →
  tauri build --config → verify:bundle（一条命令产出可分发件并自证可用）。
- src-tauri/.gitignore：忽略 /runtime/（~86MB）与生成的注入片段（生成物不入库）。

三处实测踩出来的约束（均已写进脚本注释与 console-plan.md）：

1. **macOS 上 strip 会使 Mach-O 代码签名失效 → 内核直接 SIGKILL(exit 137)**，且无任何有用报错。
   实测对照：原样复制 ✓ ／ strip 不重签 ✗(137) ／ strip + `codesign --force --sign -` ✓。
   故 strip 之后的 adhoc 重签是**必要配套**，不是可选优化。
2. **Node 运行时不得声明进默认 tauri.conf.json** —— bundle.resources 是编译期契约
   （tauri-build 校验声明的文件必须存在），声明「运行期才就绪」的资源会让 cargo check/test
   在 build.rs 阶段直接失败（2026-10-10 已踩）。故一律走 `tauri build --config` 注入。
3. **resource 映射必须与 resolve_node 对齐** —— `runtime/node → node` 使产物落在
   Contents/Resources/node，正是 src-tauri/src/sidecar.rs 里 resolve_node 查找的路径。

实测（macOS arm64）：.app **90.8 MiB**（原 6.75 MiB，增量即运行时 86MB）／
.dmg **33.78 MiB**（分发件，仍低于 40MB 目标）；应用进程实测可启动且无崩溃输出。
对照：本机实测 Electron 运行时本体（Electron Framework.framework）207MB —— 不到一半。
 2026-10-11 08:55:31 +08:00
jkooe 4f4d8913b5 chore(release): v2.0.1 v2.0.1 2026-10-11 08:02:19 +08:00
jkooe f4ae20969a chore(release): release.mjs 支持双架构（同时出 x64 + arm64 包）+ CHANGELOG v2.0.1 
## release.mjs
- 打包阶段改为循环 `pack.mjs --arch x64|arm64`（原先只出 x64）
- 资产新增 `nodeagent-win-arm64.zip`；`latest.json` 新增 `zip_arm64` 字段
  （**只增不减**，符合 VERSIONING 的兼容铁律；旧控制端忽略即可）
- RELEASE_NOTES 提示按架构选包（x64 包在 ARM Windows 上 TLS 握手不通）
- 顺手修一处改名遗漏：`zipPath` → `zipX64` 后，产物存在性检查仍在用旧名（会 ReferenceError）

## CHANGELOG
补 v2.0.1 段：3 个修复（control.ps1 解析期错误 / 连接保活缺 pong / v26 清理阈值过粗）
+ 2 项新增（`pack --arch`、`verify-b2.mjs`）+ 新增文档 `VM-VERIFICATION.md` + 真机验证状态表
 2026-10-11 08:00:52 +08:00
jkooe 7d13a48caa docs(changelog): v2.0.0 的「已知限制」更新为「验证状态已补齐」（2026-10-11 VM 真机验证） 2026-10-11 07:53:42 +08:00
jkooe 40b7db16c1 docs(roadmap): §五/§九 的 7 处历史「未做」标注实际状态（避免误导为待办） 
这些行是当时的计划快照，内容其实都已实现（screen.find 属性化、条件组合、方向二/三、ed25519 默认化
以及 v1.5 真机验证）。不改写历史结论，只更新事实以免读者误判为未完成。
 2026-10-11 07:53:10 +08:00
jkooe 765ad08ee6 docs(roadmap): §九 台账 —— v1.5/v26 真机验证标记完成（VM Win11 ARM） 2026-10-11 01:13:36 +08:00
jkooe fbcb8f8408 fix(v23): 连接保活补 pong 检测（治僵尸连接占名额）+ B2 三防护真机验证通过 
## 真机发现（Parallels Win11 ARM，B2 验证过程中撞到）
心跳只发 `ping()` 而**不检查 pong**，且 ws 库默认不会因「ping 无 pong」断开 ——
客户端进程已死（TCP 未发 FIN）时，连接会一直挂在 `states` 里占 `max_connections` 名额。
叠加「有任务/订阅时清扫保守跳过」的既有策略 → `states.size` 虚高 → **把正常控制端挡在外面**
（本次实测就把自己锁在外面了）。

## 改法
- `attachConnection` 里加 `ws.on('pong')`：**客户端回应也算活跃**（更新 lastActiveAt）
- 心跳里：若某连接静默超过 `idle_timeout_ms * 2` → `ws.terminate()`（标准 ws 保活）
  → 僵尸连接不会再永久占位

## B2 三场景真机验证（全部通过）
- ① **握手封禁**：配 `max_attempts=3` → 3 次错误密钥被拒后，**正确密钥也被拒** ✓
- ② **连接上限**：配 `max_connections=6` → 第 1~6 个成功、**第 7 个被拒** ✓
- ③ **空闲断开**：配 `idle_timeout_ms=20000` → 静默 **40 秒**被断开 ✓
  （符合 20s 阈值 + 30s 清扫周期）
- 新增 `scripts/verify-b2.mjs`（三模式：idle / maxconn / ban），全部走**真实连接**

## 验证过程中另修的两个自测问题（都记进文档）
1. 脚本默认 URL 写成了 `ws://` —— 被控端 `tls:true`，**必须 wss**（否则 socket hang up）
2. 测 `max_connections` 时值太小会**把自己锁在外面**；且被拒连接会被计入握手失败形成恶性循环
   → 结论：测试要留余量，并给自己配 `auth_ban.whitelist`

## 收尾
测试用的 `security` 段已用**备份恢复**（`agent.json.before-b2`）；pong 修复已 `deploy` 到 VM
（指纹 abca2b8168f0）。
 2026-10-11 01:13:12 +08:00
jkooe ab7a2b147b fix(v26): 自重启任务清理阈值改为「本 agent 启动时刻」（真机实测 1 小时粗阈值仍会累积） 
## 真机发现（Parallels Win11 ARM）
restart 两次后仍有 **2 个** selfrestart 任务（旧的 Ready 未被清）。诊断确认：
- 清理**条件**能选中它 ✓（非匹配问题）
- **手工删除**成功 ✓（非权限问题）
→ 算时间戳才明白：那是「1 小时」粗阈值的**必然结果** —— 旧任务创建于 00:44，
  第二次 restart 在 00:56（仅隔 12 分钟），清理那一刻它**仍是 Running**（cmd 还持有上一次的 agent），
  不满足「非 Running 或早于 1 小时」→ 保留。

**但规则本身是缺陷**：频繁 restart（间隔 < 1h）时旧任务照样累积 ——
v26 想治的僵尸只是从「永不清理」变成「1 小时后才清」。

## 改法（语义更精确）
```powershell
# 旧：$cut = (Get-Date).AddHours(-1)                    ← 粗略
# 新：$cut = (Get-Date).AddMilliseconds(-<agent uptime>) ← 「本 agent 的启动时刻」
```
凡在**我启动之前**就运行的任务，必然不是我的宿主（我的宿主刚刚才创建）→ 可安全删除。

## 验证（真机闭环）
1. `nodeagent deploy release/agent.mjs` → 指纹校验 + 备份 + 上传 + 重启 + 校验 ✓
   （顺带把 deploy 机制也验了）
2. `restart` → **任务只剩 1 个**（Running，当前宿主）→ **旧任务被精确清理** ✓✓
3. 单测：断言必须是「agent 启动时刻」阈值，且**禁止回退到 AddHours(-1)**；
   守卫 9/9 + 全量 274 绿；7 包构建通过
 2026-10-11 00:50:51 +08:00
jkooe 047cc9efd2 docs(vm): 补 ARM64 包的解决方案（pack.mjs --arch arm64） 2026-10-11 00:32:54 +08:00
jkooe d8f21f4e68 feat(pack): 支持 --arch（x64 / arm64）—— ARM Windows 上 x64 包不可用（真机实证） 
## 背景（Parallels Win11 ARM 真机验证的结论）
x64 包（内含 x64 Node）在 ARM Windows 上：**能启动、能 listen 8765，但 TLS 握手 60s 不完成**
（Prism 模拟下协议层异常）→ 协议层完全不可用，且现象具有误导性（端口是通的）。
换同版本 ARM64 Node 后**完全正常**（握手成功、连接、51 项能力）。

## 改动
`scripts/pack.mjs` 新增 `--arch <x64|arm64>`（默认 x64，向后兼容）：
- Node 下载 URL、包目录、产物名全部按架构生成
- 产出：`nodeagent-win-arm64.zip`（ARM Windows 用）/ `nodeagent-win-x64.zip`（默认）
- 加了架构校验（非法值直接报错）

## 验证
- `node --check` 语法通过
- 实跑 `node scripts/pack.mjs --arch arm64` → 产出 31.4 MB 包，
  内含 ARM64 `node.exe`（85.6 MB 解压后）+ `agent.mjs`
 2026-10-11 00:30:43 +08:00
jkooe 54f7f4c7ab test(vm): Parallels Win11 ARM 真机验证 —— A 组 15/0 + v1.5 四项全过 + 锚点端到端通过 
## 环境
Parallels 27 + Win11 ARM，VM 10.211.55.9（共享网络）；被控端 `-NodeId win-arm -AllowInput`。

## ⭐ B5 结论（与预期不同，但更有价值）
| 组合 | 结果 |
|---|---|
| `win-x64` 包（内含 x64 Node） | ⚠️ **能启动、能 listen 8765，但 TLS 握手 60s 不完成** → 协议层不可用（Prism 下） |
| **换 ARM64 Node（同版本 v22.20.0）** | ✅ **完全正常**：握手成功、连接、51 项能力 |

× 结论：`nodeagent-win-x64.zip` 不能在 ARM Windows 上实用；ARM 上需 ARM64 Node。

## 验证结果
- **A 组（verify.mjs 17 项）**：✅ 15 通过 / 0 失败 / 1 跳过（29.5s）
- **B1 v1.5 四项**：✅ 全过 —— 字符串热键 / 预设别名（`copy→ctrl+c` 映射正确）/ 长按 /
  后台定向投递（**explorer 命中 138 窗口**、WindowsTerminal 10 窗口）
  → **v1.5.0「未经真机就发版」的债，至此还清**
- **B4 锚点端到端**：✅ collect(62 条) → 上传云盘 → verify 判定「链已增长」+ 精确明细
- B2/B3：⏸ 阻塞（需 restart，而计划任务启动失败 —— 手工跑却完全正常）

## 本轮真机抓到的 2 个真 bug（都已修）
1. `control.ps1:100` 的 `$scheme:` 被 PowerShell 当 drive 引用 → **解析期错误 → 整个脚本不可用**
   （stop/start/status 全废）；已修 + 加守卫（扫全部 .ps1 的 `$ident:`）
2. `anchor-audit.mjs` 调用**不存在的** `audit head` 子命令 → 改为 `invoke system.audit.head`
   （这种「能力存在但 CLI 无子命令」的错配，不真跑一次发现不了）

## 文档
`docs/VM-VERIFICATION.md` 补「实际验证结果」节 + 5 条新增排查项（安装/密钥/CLI 语法/计划任务）
 2026-10-11 00:18:43 +08:00
jkooe c8aba83589 fix(control): control.ps1 的 $scheme: 被当 drive 引用 → 整个脚本不可用（真机踩到） 
## 现象（Parallels Win11 ARM 真机）
`control.ps1 -Action stop/start/status` 一律报：
  所在位置 control.ps1:100 字符: 36
  +  Write-Host "  协议     : $scheme://0.0.0.0:$Port"
  变量引用无效。':' 后面的变量名称字符无效。

## 根因
PowerShell 把 `$scheme:` 解析为 **drive 引用**（如 `env:`），而 `scheme` 不是 drive → 语法错误。
且这是**解析期**错误 → **整个脚本无法运行**（不是只有那一行），stop/start/status 三个子命令全废。
修法：写成 `${scheme}://`（用花括号界定变量名）。

## 改动
- `scripts/control.ps1:100`：`$scheme://` → `${scheme}://`，并加注释说明为什么必须用花括号
  （注释里刻意**不写**危险字面量 —— 否则会被新守卫命中，这点在验证时真踩到了）
- 新增守卫（`tests/unit/security-hardening.test.mjs`）：扫全部 `.ps1/.psm1`，
  禁止 `$ident:` 形式（白名单 `env`/`nuget`/`psitem`/`PSScriptRoot`）

## 验证
- 守卫 **9/9 绿**；全量单测 **274 绿**；ps1-encoding 保持通过（BOM 未被破坏）
- **注入故障实测**：把 `${scheme}` 回退成 `$scheme:` → 守卫**立即红**（失败数 1）→ 恢复后绿
  （按项目纪律：没验证过会红的守卫等于没有）
- 全仓重扫同类模式：**仅此 1 处**
 2026-10-11 00:05:42 +08:00
jkooe 3b05f5b373 fix(docs): VM 标注插错位置 —— 移到 §九 台账的正确条目之后 
上一提交的锚点匹配过宽（匹配到版本台账表里的「ci: 补全 Windows 真机验证」行），
导致标注插在了错误位置。现改为精确锚点「清理策略**真机验证**」，并复核只出现一次。
 2026-10-10 23:39:48 +08:00
jkooe 7eb773099f docs(roadmap): 补上「VM 可补验证」标注（上一提交因文本未匹配而未生效） 2026-10-10 23:38:17 +08:00
jkooe ba57d99806 docs: 新增 VM 验证清单（Parallels 27 + Win11 ARM）—— 真机不可用时的替代路径 
## 背景
Windows 被控端离线导致 4 项验证卡住（v1.5 四项 / v23 三防护 / v26 清理 / 锚点端到端）。
Parallels Desktop 27 可跑 **Windows 11 ARM** 虚拟机（Apple silicon 只支持 ARM 版 Windows，
x86_64 仅 Pro/Business 的早期预览），可提前跑掉**架构无关**的验证项。

## 清单内容（docs/VM-VERIFICATION.md）
- **能补 / 不能补的矩阵**：协议层与输入层可验；**杀软交互、显示/DPI、性能指标不可替代**
- 前置准备：桥接网络（否则 UDP 广播发现测不了）、优先 ARM64 Node、run-portable/install 二选一
- **逐条命令**（均已对着源码核实参数）：
  - A 基础验收：直接复用既有 `scripts/verify.mjs`（17 项 + Markdown 报告）
  - B1 v1.5 四项：`key press "ctrl+shift+esc"` / `copy` / `--hold 800` / `--route post --pid N`
    （对应 args 的 hotkey / preset / hold_ms / route+target_pid 四个分支）
  - B2 v23 三防护：`agent.json` 的 `security.auth_ban` 与 `idle_timeout_ms` + 三场景判定
  - B3 v26 清理：`restart` 后 `schtasks /query`，**重点看"当前宿主任务必须仍在"**（否则即误杀）
  - B4 锚点端到端：`anchor-audit.mjs collect` → 云盘 → `verify`
  - B5 额外结论：**win-x64 包在 ARM Windows 上能否跑**（走 Prism；跑通则写进 README）
- **结论标注规则（强制）**：VM 验过的写「VM 已验」；杀软/显示/性能**不得**因 VM 通过就标已验；
  并注明「VM 与真机架构不同（真机 x86_64），VM 通过不自动推出真机通过」
- **已知 VM 环境差异表**（排查先看）：广播发现需桥接、坐标为逻辑验证、性能数字不可采信等

README 文档区与 ROADMAP §九 均已链入。
 2026-10-10 23:38:02 +08:00
jkooe 28ce95f045 feat(audit): 审计锚点外部化落地 —— 判定逻辑收敛为 protocol 纯函数 + 控制端工具 + 云盘链路 
## 为什么（一句话）
锚点的安全性完全来自「它在攻击者碰不到的地方」。与被审计日志同机的锚点等于没锚：
被控端一旦被 root，重写日志后顺手改掉锚点即可。

## 本次改动

### ① 判定逻辑收敛（消除「两份真相」）
把 `compareWithAnchors` 的三条判定抽到 **`packages/protocol/src/audit-anchor.ts`** 的
**纯函数 `judgeAnchors(head, anchors)`**（无 IO，不知路径）：
- agent 端 `compareWithAnchors` 改为「读文件 + 调 judgeAnchors」
- 控制端脚本同样调用它
→ 同一份日志不可能出现「被控端说一致、控制端说被改」的分歧
- 附带 `parseAnchorsFromJsonl`（坏行跳过，一行坏数据不毁整份锚点）
- agent 侧类型改为 re-export，既有导入路径不变（**9 个原有锚点单测全绿，行为零变化**）

### ② 控制端工具 `scripts/anchor-audit.mjs`
- `collect`：拉链头 → 生成一行锚点 JSONL（并打印 `ANCHOR_JSON=` 便于 automation 取用）
- `verify`：读锚点文件（可从云盘下载）+ 拉链头 → 判定，`ok:false` 时**退出码 2** + 醒目告警
- 走 CLI 而非自己实现连接（复用其多设备配置/证书钉住/daemon，避免又一份实现）
- 支持 `--head-file`：**离线也能验证判定链路**（本轮即用它做了 fixture 验证）

### ③ 云盘链路
- 建 `…/Project/NodeAgent/anchors/`（与全量备份分开目录）
- 每日 automation 更新为「拉链头 → 上传云盘（一天一个带日期的文件）→ 简报」，
  并规定每月首日额外做一次「下载历史锚点 → 链外比对」

## 验证
- **纯函数重构零行为变化**：原有 audit-anchor 单测 9/9 全绿；全仓 273 单测全绿；7 包构建
- **工具离线验证**（fixture）：一致 → 「与锚点完全一致」退出码 0；
  篡改 → 「链头哈希与锚点不一致」退出码 2；三个错误分支均给出明确提示
- 云盘：`anchors/` 目录创建成功（1/1 步），目录内容已复核
- ⚠️ 端到端（真拉链头 + 真上传）**待被控端上线**；脚本的 CLI 分支已做错误处理验证
 2026-10-10 19:14:09 +08:00
jkooe 2fe717cb62 fix(ci): 修 clippy 的两个错误（含一个真实并发问题）+ 本地补齐 lint 验证 
## CI 失败的真实原因（上一轮我误判为 resources，实为 clippy）
`-D warnings` 下两个错误：
1. **`clippy::await_holding_lock`（sidecar.rs，真问题）**：
   `if let Some(child) = self.child.lock().unwrap().take() { child.kill().await }`
   —— MutexGuard 存活到 if 块结束，**跨 await 持有 std Mutex**：不仅触发 lint，
   真会阻塞 executor。已改为「先取出 child（锁随即释放），再 await kill」。
2. `clippy::doc_lazy_continuation`（lib.rs 文档注释）：列表与后续段落之间缺空行。

## 我的验证方式错在哪（已修正）
上一轮我本地只跑 `cargo test`，**没跑 clippy** —— 而 CI 是 `clippy -D warnings` + `test`
两道闸。本地与 CI **标准不一致**，于是"本地绿、CI 红"。
本轮起：**本地按 CI 的完整命令集验证**（clippy --all-targets -- -D warnings → cargo test）。

## 验证
- `cargo clippy --all-targets -- -D warnings` → **零警告**
- `cargo test` → **3/3 通过**
 2026-10-10 15:33:11 +08:00