mtfyun/nodeagent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
231 Commits 1 Branch 14 Tags
main
Commit Graph
61 Commits
Author SHA1 Message Date
jkooe cf51e0415a fix(scripts): 自重启任务纳入卸载清理 —— 修「僵尸任务反复拉起已删文件」 
真机发现：`system.agent.restart` 每次重启注册 `nodeagent-selfrestart-<毫秒>`，
而 TASK_WHITELIST 只有 nodeagent/na-gui/nodeagent-console → 卸载后这类任务残留，
会持续尝试拉起已被删除的 agent.mjs。

但它不能当垃圾随手清：**Running 的那一个往往就是当前 agent 的父任务**
（删了会连带杀掉 agent）。故只纳入「卸载清理」判定集合，由调用方在停掉
agent 之后使用。

匹配用严格命名空间 `^nodeagent-selfrestart-\d{6,}$`（纯数字时间戳形态），
不做任何通配；`nodeagent-selfrestart-abc`/前缀不全/带额外后缀一律不认，
单测同时钉死「第三方任务（Adobe/OneDrive）绝不出现」。
 2026-10-27 13:06:51 +08:00
jkooe 419f6dca13 fix(agent): 看门狗日志按 1MB×4 轮换 —— 修常驻被控端的无界增长 
startup-guard.log 一直是 appendFileSync 无限追加。看门狗常驻被控端，
「坏版本 + supervisor 反复重启」时写得很快，磁盘写满会连带把 agent 的
审计写入一起拖死（看门狗自己就在同一台机器上）。

- core（零依赖纯函数）：shouldRotate（严格大于阈值，NaN 不触发）+ rotationTargets；
- guard：超阈值先丢最旧 .N → 逐个后移 → 当前滚为 .1，滚动与写入均失败静默
  （日志问题绝不能反过来拦住被控端启动）；
- 单测 +3：阈值边界（含恰好等于/Nan）、命名序列、真实滚存三轮（验证只留 3 份、
  当前日志重新开始、未超阈值只追加）。
 2026-10-27 08:04:20 +08:00
jkooe 451d44af72 fix(release): 版本号已钉在树中时不再卡在「nothing to commit」 
发版脚本无条件执行 `git commit`。v2.1.0 的流程是先把版本号作为
`chore(release)` 提交进树、之后才发版 —— 此时 `git add -A` 后暂存区为空，
`git commit` 以 "nothing to commit" 非零退出，发版停在最后一步，且报错来自
git 而非发布逻辑，容易误判为工作区问题。

改为：暂存区为空则跳过 commit，标签与 Release 照常创建。
向后兼容 —— 版本号需要变更时行为完全不变。
 2026-10-27 00:00:26 +08:00
jkooe b7f44f7a64 feat(scripts): na-gui 陈旧计划任务白名单清理（ARCH B-P1-6） 
历史版本在被控端上注册过 na-gui 等旧名计划任务，漏删会留下「端口被占、
新版本起不来」的幽灵任务。误删用户自己的任务则是比漏删严重得多的
生产事故 —— 故只按白名单删。

- scripts/lib/scheduled-tasks.mjs（新）：TASK_WHITELIST（nodeagent /
  na-gui / nodeagent-console，只增不改）+ planTaskCleanup 纯函数
  （查询结果注入，白名单外一律不删、精确匹配大小写敏感、重复名去重）。
- scripts/uninstall.ps1：卸载末尾按白名单逐个注销（-ccontains 存在性
  检查 + 动作进日志）。
- scripts/control.ps1：新增 cleanup 子命令（ValidateSet + Clear-StaleTasks），
  Uninstall-Agent 复用同一白名单；control.cmd 菜单加第 8 项
  （CRLF 安全插入，纯 ASCII 不变）。
- tests/unit/na-gui-cleanup.test.mjs（新，10 例）：白名单命中才删 /
  白名单外零动作 / 空列表 / 重复名 / 脏输入 + ps1 源码守卫与跨端
  一致性守卫（白名单 mjs 与 ps1 漂移即红 —— 注入故障实测 2 处变红，
  恢复后全绿）。
 2026-10-26 01:01:05 +08:00
jkooe aad137f04a fix(startup-guard): 强制向被看守进程注入 NODEAGENT_HOME = --data-dir 
全局一致性审查发现：Windows 计划任务的 New-ScheduledTaskAction 无法
携带环境变量，若安装进程持有进程级 NODEAGENT_HOME，agent 运行时的
agentDir()（LKG/状态文件所在地）会与守卫的 --data-dir 漂移 ——
守卫读不到 LKG/状态文件（安全退化为 no-lkg 放行，但看门狗白养）。

由 spawnEnv 在 spawn 时把 data-dir 显式注入被看守进程，三端行为与
supervisor 环境解耦且一致（Linux unit / macOS plist 的
EnvironmentVariables 本就是同值，双保险，幂等无害）。
新增 spawnEnv 单测；真机验证子进程可见注入值。
 2026-10-26 00:17:15 +08:00
jkooe cb468df7da feat(agent): 看门狗自动恢复 LKG —— 启动连续失败 N 次从 LKG 恢复（决策 R-1） 
scripts/startup-guard.mjs + scripts/lib/startup-guard-core.mjs（新增）：
- 被控端启动连续失败 N 次（默认 3）自动从 LKG 指纹匹配的备份恢复入口脚本
- 30s 启动宽限期 + 端口探活，避免计划内重启与 supervisor 重启撞车被误计数
- 无 LKG / 无指纹匹配只记日志放行，绝不擦除 install-dir
- 恢复成功或服务已就绪均归零失败计数；被控端启动成功后 resetStartupGuardState 归零
  （apps/agent/src/index.ts 为本任务对 agent 的唯一改动点）

三端 supervisor 接入：
- Windows install.ps1：计划任务包一层 guard，RestartCount 3→10（保证阈值可达）
- Linux install-linux.sh：systemd unit 的 ExecStart 包一层 guard
- macOS launchd：无安装器，docs/DEVELOPMENT.md §7.4 给出完整接法

docs：DELIVERY-PIPELINE §6 由「不做自动回滚」收窄为
「手动 rollback + 看门狗自动恢复 + 边界明示」，附录 C 同步；
DEVELOPMENT.md 新增 §7.4 三端 supervisor 接入说明。
 2026-10-26 00:09:56 +08:00
jkooe 2bf45fdf98 feat(pipeline): 交付流水线规范落地 —— 门禁 + LKG 回滚锚点 
将《代码审计 → 上线 完整交付方案》v1.0 适配到 nodeagent，产出
docs/DELIVERY-PIPELINE.md，并落地其中可执行的部分。

## 为什么要适配而不是照搬
原方案面向 Web/容器服务（有服务端、有镜像、有多环境）。nodeagent 是
跑在用户机器上的跨机接管框架，无服务端、无容器、无多环境。照搬会产生
「跑得很好但守不住任何东西」的假门禁。故每个阶段给三档判定：
适用 / 改造后适用 / 不适用（但必须给替代，不允许只写 N/A）。

关键替换：
- 容器镜像扫描 → 交付物 PE 架构断言（arm64 包误装 x64 node.exe 的真实事故）
- DAST → 协议健壮性测试（本项目对外输入面是 WebSocket RPC，非 HTTP）
- dev/staging/prod → 真机矩阵（Win x64/arm64、macOS、Linux）
- 金丝雀 → 设备分批自更新（先一台试点，latest.json 灰度）
- Prometheus → system.metrics（闭环率/P95/拦截率）+ 发布后复核清单

## 本次落地
1. 覆盖率门禁 scripts/ci/check-coverage.mjs
   - 全量**只观测不阻断**（实测基线 66.9%，照搬 80% 全量不现实）
   - 变更文件行覆盖率 ≥70% 阻断；单测 import 的是 dist/，需 src→dist 映射
   - 无覆盖数据的变更文件不阻断，单列供人工判断（算 0% 会让重构无法合入）
2. 提交信息校验 scripts/ci/check-commit-msg.mjs
   - 项目实际已在用 Conventional Commits，但无强制 → 变成会红的门禁
   - 不引 commitlint+husky：本项目只需类型白名单，几十行即可且 CI 本地都能跑
3. .github/workflows/quality-gate.yml：gitleaks + pnpm audit + typecheck + 覆盖率 + 提交规范
4. CI artifact retention-days 30 → 7（公开可下载，留存越久暴露面越大）
5. LKG（最后已知可用版本）apps/agent/src/lkg.ts
   - 只在**启动成功后**才写，不在更新写完时写（否则等于把未验证版本当已知可用）
   - 暴露为 system.info.lkg，matches=false 表示当前版本尚未被证明能启动
   - 控制端据此暂缓向其余设备放量

## 刻意不做的事：自动回滚
远程设备上无法区分「更新坏了」与「网络抖动」；自动回滚可能形成回滚循环；
被控端自作主张改自己会让控制端失去掌控。故 LKG 只提供确定的回滚目标，
决策权留给控制端。已在文档中写明取舍理由。

## 实测证据
- 覆盖率门禁三条故障注入均 exit=1（阈值100 / 全量99 / lcov缺失），正常 exit=0
- 提交规范反例 3 类均红，Merge 与无 scope 正确豁免，历史 20 条提交一次通过
- LKG 新增 8 条单测（含篡改 hash 必须检出 matches=false）
- 既有契约测试在新增 lkg 字段后立刻报红（SystemInfo 缺声明），补接口后转绿
  —— 这本身是门禁有效的实证
- 全量单测 341 → 349 全绿
 2026-10-17 03:13:18 +08:00
jkooe b9236dfaf1 chore(privacy): 公开仓库隐私脱敏 —— 清除可定位到个人与设备的字面量 
按 security-reports/ 的隐私审查台账逐项收口。纯脱敏与表述泛化，
不含任何业务逻辑变更；实测结论与排查步骤一字未动。

P1（可定位到具体设备/个人）
- scripts/verify-b2.mjs：NA_URL 去掉硬编码缺省值（原指向一台真实机器），改为必填。
  这是全仓库唯一「拿着就能连到某台真机」的常量。
- 测试账户名 pdverify → na-test（docs/VM-VERIFICATION.md 7 处、docs/console-plan.md 1 处）
- 虚拟机与宿主的真实网段 → RFC 5737 文档保留段 192.0.2.x（含 CLOSE_WAIT 记录）
- 跨项目名与私人称呼 → 中性表述（docs/PRD.md、docs/DEVELOPMENT.md、docs/console-plan.md 等）

P2（低风险设备指纹）
- 虚拟化产品及其 CLI / 访客工具名 → 中性表述（12 个文件 + 1 个工作流注释）
- 测试目录 C:\nodeagent-test → C:\na-test
- NAS 设备型号与系统名 → NAS 设备 / NAS 系统（docs/DEPLOY-LINUX.md、scripts/install-linux.sh、README.md）
- 真机 CPU 型号、真机物理分辨率、代理软件品牌与监听端口、杀软品牌 → 泛化
- 单元测试示例段去掉真机 IP 尾八位：acl-v11 / net-scripts 的 fixture 与断言同步更新
- .gitignore 补 config.json / agent.json（含真实密钥与节点地址，绝不入库）
- 顺带移除混入技术文档的「不构成投资建议」字样（与文档主题无关）

验证：pnpm test:unit 340/340 通过；独立扫描器对 235 个跟踪文件做 17 类模式
全量扫描，命中 0。
 2026-10-13 22:35:40 +08:00
jkooe 00992e5c1c feat(linux): Linux 被控端适配 —— 安装器 + systemd 自启 + 平台守卫 + 部署文档 
面向「服务器型被控端」（命令/状态/文件/审计；无 GUI），实测环境 Debian 12（fnOS 底座）。

## 新增
- `scripts/install-linux.sh`：一键安装器（对齐 Windows `install.ps1` 的语义）
  · 自动获取 Node 运行时（系统无 Node 22+ 时下载 linux-<arch>，走 npmmirror）
  · **systemd 服务**（系统级 / 用户级+linger / `--no-service` 三种模式），开机自启
  · 幂等：复用既有密钥（并自动备份 agent.json）；卸载保留配置（`--purge` 才删）
  · `--node-id/--port/--allow-input` 等参数；缺 `ip`/`ifconfig` 时 IP 展示多级回退
- `apps/agent/src/util/platform.ts`：**统一平台守卫**
  · `assertPlatform(cap, ...allowed)` / `assertGuiPlatform` / `assertWindows`
  · 抛 `E_UNSUPPORTED_PLATFORM` 并带上「支持哪些平台」，让"未实现"不再伪装成"参数错/环境缺依赖"
- `docs/DEPLOY-LINUX.md`：部署指南 + **实测能力清单** + 故障排查表

## 修改
- `screen.ts` / `record.ts` / `clipboard.ts` / `audio.ts` / `input.ts`：入口接入平台守卫。
  修复前的表现是**误导性错误**（`screen.capture` 在 Linux 上报 `region 宽高必须 ≥ 1`，
  像是参数没传对），现在是 `screen.capture 未在 Linux 上实现（仅支持 Windows / macOS）`。
- `scripts/verify.mjs`：v2.1 / v2.3 补 `E_UNSUPPORTED_PLATFORM → skip`
  （v2.2 早已处理；此前把"平台不支持"记成失败）
- `README.md`：文档区链入 DEPLOY-LINUX

## 实测（Docker · Debian 12）
- 安装流程端到端：装文件 → 写配置(600) → 提取密钥 → 启动监听 → **幂等复装密钥不变** ✓
- 验收：**9 通过 / 1 失败 / 6 跳过**（对比 macOS 15/0/1）
  · 1 失败 = 容器缺 `procps`（`process.list` 返回空），非代码问题；NAS 自带该包
  · 6 跳过 = GUI 类能力（平台诚实拒绝）
- 单元测试 325 全绿；7 包构建通过

## 途中修正的三个"差点误判"
1. **Alpine 误判**：`spawn /bin/bash ENOENT` 是**镜像没 bash**，不是 Linux 不支持
2. **`set -e` 静默退出**：`LAN_IP=$(ip ...)` 在无 `ip` 的环境失败会**直接终止脚本**
   （`2>/dev/null` 把原因吞了，表现为"跑到一半就没了"）→ 已改多级回退
3. **slim 镜像缺 procps** → `process.list` 空列表，被误读为"Linux 特性"
 2026-10-13 21:15:59 +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 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 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 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 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 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 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 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 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 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 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 e23788d717 refactor(versioning): 统一版本号 —— semver 为唯一版本号，开发批次代号并入其归属版本 
## 问题（皇上指出）
项目里两套编号并行，无法判断哪个是"当前版本"：
- **发布版本**（semver）：v1.1.0 ~ v1.6.0、v2.0.0
- **开发批次代号**：v1 ~ v26（README 路线表 / 代码注释 / 文档）
时间线证据：v1.1.0 首发（09-29）时批次已推进到 v12.4 —— **二者从来不是一对一**（26 批次只发过 10 版）。

## 规则（新增 docs/VERSIONING.md §0 版本号唯一性规范）
- **唯一版本号 = semver `vX.Y.Z`**，两个来源必须永远一致：git tag 与 package.json（构建期注入 agent）
- **批次代号不是版本号**，不再单独出现；需要区分同版内多批改动时用**功能名**
- 附「批次 → 归属发布版本」映射表（按 tag 时间线与功能内容推定，并注明以 CHANGELOG 为准）

## 统一动作
1. **批次 v23 ~ v26 → v2.0.0**（22 文件 / 53 处）—— 它们确实属于 v2.0.0
2. **臣的批次号 v1.7 / v1.8 → v2.0.0**（27 文件）—— 未单独发版
3. **简写补全三段式**：v1.5 → v1.5.0、v1.6 → v1.6.0
4. **README 路线表**：`**v1**` → `**批次 1**`；表头加「批次 ≠ 版本号」说明并链到 §0；
   补齐批次 16~29 与 **v2.0.0 发布行**；删掉过时的「待办」行（提到的分支早已删除）
5. `docs/VERSIONING.md` 里**故意保留** 3 处批次号 —— 那是规范说明本身

## 保留项（真实发布版本，不动）
v1.1.0 / v1.2.1 / v1.3.0 / v1.4.0~v1.4.3 / v1.5.0 / v1.6.0 / v2.0.0（10 个 tag）

## 验证
- 版本号一致性：package.json = tag = 8 个 workspace = tauri.conf.json = **2.0.0** ✓
- v1.7/v1.8/v23~v26 全仓残留 **3 处**（均在 VERSIONING.md 规范说明中，属预期）
- 7 包构建 · 单测 273 · e2e 30 · ps1-encoding 24 全绿
 2026-10-10 14:27:12 +08:00
jkooe 5b69d6cec9 refactor: 项目结构与命名规范化（重写前的最后一次常规提交） 
## 改名
`scripts/run-temp.cmd` → `scripts/run-portable.cmd`
理由：它是**正式功能**（免安装、免管理员的便携启动方案），"temp" 易被误认成临时文件。
程序内文案同步：TEMPORARY launcher → PORTABLE launcher；
打包产物 README 的"【临时试用，不装也行】" → "【免安装试用，不装也行】"。

## 移动
`PRD.md` → `docs/PRD.md`
理由：文档统一放 docs/（README/CHANGELOG 按惯例留在根）。

## 同步的引用（共 11 处）
- scripts/pack.mjs：产物文件名校验 + 生成 README 的 3 处指引文案
- scripts/run-portable.cmd：自身用法注释 6 处
- README.md：目录树 + 文档链接
- docs/DEVELOPMENT.md：配套文档链接（`../PRD.md` → `PRD.md`，现已同目录）+ 目录树

## 验证
- 全仓 `run-temp` 残留 **0**；`./PRD.md`/`../PRD.md` 旧路径残留 **0**
- 7 包构建通过；单测 273 全绿；ps1-encoding 24 全绿
- `pack.mjs` 实跑通过，`run-portable.cmd` 已正确进入 Windows 产物
- `.cmd` 保持 ASCII + CRLF（94 行）；PRD.md 无内部相对链接需调整
 2026-10-10 13:39:42 +08:00
jkooe 11127b1a89 chore(privacy): 杀软实名与网卡名示例泛化（安全报告第十三轮 P2 两项） 
## 甲1 杀软实名泛化（6 行）
`主流杀软 / 杀软 / 360` → 「主流杀毒软件 / 杀软」：
- docs/REMOTE-LIMITS.md：标题 + 正文 + 表格两处（保留"会拦什么"的实操信息，去掉具体厂牌）
- scripts/release.mjs:278：Release 正文模板里的信任区提示
- apps/cli/src/cmd/ops.ts:398：部署失败排查提示

## 甲2 网卡名示例泛化（13 行）
「Ethernet」→ `Ethernet`（示例）／泛化为"中文网卡名"（讲原理时）：
- docs/REMOTE-LIMITS.md 网络适配器表格、ROADMAP 该项标记为已完成
- scripts/rescue-network.ps1 参数说明、automation.ts 的 interface 描述
- apps/agent/src/capabilities/network.ts 注释：改为"脚本里的非 ASCII 字符（如中文网卡名）"
  —— **保留"为什么"的教训，去掉具体实况**
- tests/unit/net-scripts.test.mjs：8 处测试数据与正则断言同步改为 Ethernet

## 验证
工作区残留「主流杀软/杀软/Ethernet」= **0 处**；单测 273 全绿；7 包构建通过。
 2026-10-10 12:26:41 +08:00
jkooe 2cb0ed148e chore(privacy): 源码与测试里的真机常量脱敏（机器名 / 真机内网 IP） 
路线图 §七 序 7「源码真机常量注入化」的脱敏部分。

## 改了什么
- apps/agent/src/capabilities/network.ts：注释里的真机机器名 → 泛化为「机器名+纯数字」
  （保留"为什么不能拼 USERDOMAIN/USERNAME"这个教训本身，去掉具体机器名）
- scripts/rescue-network.ps1：.EXAMPLE 里的真机内网地址 → 文档示例段 192.168.1.100；
  网卡名示例由中文默认名改为 'Ethernet'（既避免像真机、又更通用）
- packages/protocol/src/acl.ts：注释里的真机 Mac 地址 → 192.168.1.100
- tests/unit×4：测试数据里的真机 IP 统一换成 192.168.1.x 示例段

## 过程中的两个教训（都记在代码注释里了）
1. **正则转义形态漏替换**：断言里写的是 `192\.168\.0\.88`（转义点），第一轮只替换了
   裸形态 `192.168.0.`，导致脚本值变了、断言没变 → 3 个测试红。
2. **机械替换会破坏「跨网段」这类语义测试**：acl 的 `/24 网段匹配` 用例里有一条
   本意是「**不同网段不匹配**」，替换后两侧变成同段 → 断言必红。已改回不同网段
   并在注释里标注原因，防止下次再被批量替换破坏。

## 验证
单测 269 全绿（复跑）；e2e 30 全绿。
 2026-10-10 00:39:28 +08:00
jkooe 8b97fc6106 feat(v24): 零信任优先安装 —— 拿到控制端公钥就走 ed25519，否则明确告警 
## 为什么不是直接改 auth_mode 默认值
ed25519 的**私钥必须在控制端**，被控端安装时拿不到公钥。硬改默认值会让新装的控制端
连不上（还得手工改配置回退）—— 比「有条件就走零信任 + 无条件时明确告警」更糟。
所以这里的"默认"是**优先顺序**，不是死值。

## 做法
install.ps1 新增 -ClientAclFile（默认探测脚本同目录 client-acl.json，内容即
`nodeagent keygen` 打印的那一条 acl.clients JSON）：
- 有且含 client_id+pubkey → auth_mode=ed25519，写 acl{default_effect=deny, clients=[…]}，
  绿色确认 + 打印 --auth-mode ed25519 连接示例
- 无 / 缺字段 → 保持 psk，但输出**醒目黄色告警**：说明 client_id 可自报的固有风险
  + 三步切换指引（keygen → 存 client-acl.json → 重跑 install.cmd）
install.cmd 无需改动（install.ps1 自行探测）。

## 验证（真机，不是推理）
- **PowerShell 5.1 语法校验**：PARSE_OK，BOM 保留（EF BB BF）
- **等效逻辑三 CASE**：
  A 有文件 → auth_mode=ed25519 + default_effect=deny + clients 完整（allow/deny/note 保留）
  B 无文件 → auth_mode=psk 且**不写 acl 字段**
  C 缺 pubkey → WARN 并回退 psk（不写半截 ACL）
- 编码守卫：ps1-encoding 24 例全过（BOM + 无 U+FFFD）
- 新增 tests/unit/install-zerotrust.test.mjs（8 例源码断言：参数、探测路径、
  useZeroTrust 条件化、deny 兜底、字段校验、告警文案、连接示例、ConvertTo-Json -Depth 6）

## 文档
docs/SECURITY.md 新增 §4.7 并更新 §5 清单 —— 把 v23 的三项（握手封禁/会话上限/
安装期密钥）与本次 ed25519 默认化一并标为已完成，只留「审计链外部锚定」待做。

## 数据
单测 250 → **258** 全绿；7 包构建通过。
 2026-10-09 23:53:28 +08:00
jkooe 933863529a docs: 包内 README 密钥说明与实际一致 
README 原写「PSK.txt 里是预共享密钥」，但 PSK.txt 自 045e3b0 起已不再随包
分发（该 zip 会作为公开 Release 资产，打进密钥等于公开）。说明与事实不符，
首次上手者会找不到这个文件。

改为按实际取值顺序描述：① 本目录已有 PSK.txt 则用之
② 已有 %USERPROFILE%\.nodeagent\agent.json 则复用其中 key
③ 都没有则自动生成随机密钥；并指明密钥会打印在屏幕上、
可用 run-temp.cmd status 查看。
 2026-10-09 23:15:56 +08:00
jkooe 4cb8ad566b feat: run-temp.cmd —— 免安装、免管理员的临时启动方案 
问题：Windows 端 agent 离线时，control.cmd 依赖已安装的计划任务
（Start-ScheduledTask），未安装就完全起不来；而 install.cmd 需要管理员
权限并写防火墙规则，临时试用太重。

run-temp.cmd 直接 node.exe agent.mjs —— agent 本身零配置，
首次运行会自动生成 %USERPROFILE%\.nodeagent\agent.json（随机 PSK +
自签证书）并开始监听，故无需任何前置步骤。

用法：
  run-temp.cmd            前台启动（Ctrl+C 停）
  run-temp.cmd background 最小化后台启动
  run-temp.cmd status     查看进程 / 监听 / 配置与密钥
  run-temp.cmd stop       结束

实现要点：
- agent **不解析命令行参数**（argv 出现 0 次），端口只来自 agent.json
  → 脚本不再传 --port（传了也会被忽略，属误导），脚本内 PORT 仅用于状态检查
- CMD 批处理规避：start "title" 后必须套 cmd /c ""..."" 才不吞标题；
  子程序用 goto 而非 call（call :LABEL 会在末尾 exit /b 时连带退出）
- 进程检测用 Win32_Process 查 CommandLine，而非 Get-Process.Path
  （后者在非管理员下拿不到 Path 属性）

pack.mjs 同步：
- 把 run-temp.cmd 纳入文件清单
- 新增 CRLF 守卫（此前只查非 ASCII）→ LF-only 的 .cmd 在部分
  Windows 环境会解析异常
- 两个守卫均已注入故障实测会红（LF-only 94 处 / 非 ASCII 偏移 1677）
- 包内 README 增补临时试用说明
 2026-10-09 23:12:14 +08:00
jkooe 921ff89edf feat(v23): 连接层三项防护 + 安装期密钥改 stdin（堵住最后一条密钥暴露面） 
## ① 安装期密钥不再走命令行（路线图方向三，最后一条暴露面）
此前 install.cmd 用 -Key 传参，**同机其他用户可从 Win32_Process.CommandLine
明文读到**。现改为管道喂 stdin：
- install.ps1 新增 -KeyFromStdin：先判 [Console]::IsInputRedirected 再读
  （没管道时不阻塞）、Trim 去 CRLF、hex 16-128 校验；优先级 -Key > stdin > 复用既有 > 新生成
- install.cmd：echo %PSK%| powershell ... -KeyFromStdin（管道符前不留空格，
  否则空格会被 echo 进密钥 —— 老坑）

## ② 握手失败封禁（此前只计数，攻击者可无限重试）
- 同来源连续失败达 max_attempts（默认 5）→ 拉黑 ban_ms × 2^(N-max)，指数退避封顶 24h；
  封禁期过计数保留，继续翻倍
- 5 个失败路径统一记账（挑战过期/nonce 不匹配/未注册/Ed25519 失败/PSK 失败）；
  **认证成功即清零**（不误伤手滑的控制端）
- 白名单来源永不封禁；归一化剥离 ::ffff: 前缀（否则同来源被当两个键）
- 在连接入口挡（TLS 之后、业务握手之前），错误响应带 retry_after_ms
- 封禁状态放 core（handleAuth 在内），AgentCore 暴露 banRemainingMs/states

## ③ 连接上限 + 空闲断开
- max_connections 默认 8（超限 close 1013）；idle_timeout_ms 默认 30 分钟
- 空闲清扫**保守**：只要还有任务在跑或还有事件订阅就不断 —— 不把挂着长任务
  等结果的控制端踢下线（新增 runningTaskCount / watchCount 两个判据）
- states 由 WeakMap 改 Map（需要 size 与遍历），close 时手动 delete 防泄漏
- 新增审计类型 session.idle_close（console 的 AuditType 同步，契约测试守住）

## 验证
- 单测 **227 全绿**（新增 security-hardening 6 例：退避公式翻倍/封顶、IP 归一化、
  白名单、hex 校验、配置形状）；e2e **30** 全绿
- **本地真机三场景**：正确密钥可连 → 连续错误被拒 → 封禁期连正确密钥也被拒 ✓
- ⚠️ 待 Windows 真机：install.cmd 双击首装（改了安装入口，必须验管道喂钥）
 2026-10-07 21:23:37 +08:00
jkooe 0a5fa715d4 ci/test/chore: Rust CI + e2e 契约守卫 + 发版闸门加固 
【新增 .github/workflows/rust.yml】crates/ 此前**零 CI 覆盖**（唯一工作流只在
windows-latest 跑 pnpm 那套，不碰 Rust）。新工作流走 Linux 快车道，只跑该 crate：
- clippy --all-targets -- -D warnings（告警即失败；该 crate 既定标准是零告警）
- cargo test（9 单测 + 2 E2E）
- **工具链锁死 1.98.1** 而不跟 stable 漂 —— 否则 lint 集合随工具链漂移，
  「本地全绿」与「CI 绿」会分叉（本仓库已因同类原因吃过 8 轮 Windows CI 的苦头）。
本步当场抓到一处真实 lint：discovery.rs 的 sort_by(|a,b| b.f.cmp(&a.f)) → sort_by_key(Reverse(..))。

【tests/e2e/run.mjs】新增 testContractShapes：对**真实被控端**调 7 项只读能力，
断言返回字段 ⊆ manifest returns_schema（含数组首元素）。与单测侧的 console-contract
合起来构成闭环：
    agent 实现 ──e2e──▶ 协议契约 ──unit──▶ 前端类型
只调无副作用能力（不写文件/不装软件/不动输入），避免 E2E 产生难回收的变更。
**已注入故障实测会红**：给 system.info 塞 injected_drift_field → 精确报出契约外字段。

【scripts/release.mjs】发版闸门补第二层。原闸门只查 git ls-files --others（未跟踪文件），
但紧接着的 `git add -A` 会提交**已修改的跟踪文件**，而它们不在原闸门视野里 —— 真例：
`pnpm install` 把某应用依赖写进跟踪中的根 pnpm-lock.yaml（+1401 行），发版时静默推走
且闸门不响。现补「脏文件白名单」：除脚本自己改的文件外，任何脏跟踪文件一律中止发版。
另：Tauri 的版本号不在 package.json 而另存于 src-tauri/tauri.conf.json（且它才是打进
.app 的版本），原先漏更新 → 现一并纳入版本号写入，避免「包里是旧版本号」。

【package.json】补 test:rust 与 probe 脚本（probe 需 crates/ 在库内，现已满足）。
 2026-10-07 10:14:29 +08:00
jkooe 9efd290061 fix(pack): 打 zip 改为平台分流（Windows 无 Info-ZIP），顺带修 ls/du 
Windows CI 连续暴露的第三类问题：
- zip -q -r ... -x PSK.txt → Windows runner 没有 Info-ZIP，命令不存在
- 同文件里还有 ls -la 与 du -sh，在 Windows 上同样不可用

修法：
- zip：Windows 用 PowerShell 的 Compress-Archive（先删 PSK.txt 再压，因为它没有 -x 排除项）；
  macOS 继续用 zip
- 列目录改用 Node readdirSync+statSync；体积用 statSync 计算（不再依赖 du）
macOS 路径复跑通过（zip 31M），195 单测 / 29 e2e 绿。
 2026-10-07 02:41:18 +08:00
jkooe 4140b8e32c fix(pack): 改用 esbuild 的 JS API，不再 spawn node_modules/.bin/esbuild 
Windows CI 的产物包步骤暴露：pnpm 的隔离布局下那个 .bin shim 在 Windows 上不存在 →
  spawnSync D:\a\nodeagent\node_modules\.bin\esbuild ENOENT
（macOS 上一直正常，所以此前从未发现。）
改用 await import('esbuild') + esbuild.build({...}) 后只依赖 require 解析，跨平台一致。
本地复跑 pack:win 通过（bundle 1010.8kb / zip 32M），195 单测 / 29 e2e 复跑全绿。
 2026-10-07 02:35:23 +08:00
jkooe b809aaa92e fix(install): 双击入口的密钥生成路径是坏的 —— 改为交给 install.ps1 处理 
**Windows CI 的双击链路冒烟抓到的真 bug**（第四轮 CI 暴露）：
install.cmd 在「没有 PSK.txt」时自己用 cmd 生成密钥：
  for /f ... in ('powershell ... -Command "... ($b ^| ForEach-Object ...) ..."')
经 cmd 的 for /f 投递时需要 ^| 转义管道，而 ^ 未被消费、原样漏进 PowerShell →
  Unexpected token '^' in expression or statement
**必炸**：PSK.txt 已不在分发 zip 里（045e3b0），所以「首次双击安装」恰好走到这条路径。

修复：cmd 不再自己生成密钥 —— install.ps1 本来就有完整逻辑
（先复用既有 agent.json 的 key，没有再现场生成，且 PowerShell 引号安全）。
install.cmd 按有无 PSK 决定是否传 -Key。

顺带：本文件的 CRLF 曾被工具写坏，已恢复并复核（ASCII 0 非 ASCII、107 CRLF、无裸 LF）；
编码守卫单测 22 项通过，全量 195 单测 / 29 e2e 绿。
 2026-10-07 02:23:20 +08:00
jkooe 79a0c15214 fix(release)+chore: 发版前增设未跟踪文件安全闸；gitignore 保护在建工程 
① 安全闸：发版前若存在未跟踪文件即中止并列明，绝不盲目 add。
   成因：2026-10-07 的 add -A 与 commit -am（-a 同样会带入全部已跟踪修改）
   两次把无关文件带入发版提交并推到公开仓库。
② .gitignore 加入 /crates/、docs/console-plan.md、docs/ROADMAP.md ——
   皇上在建的 Rust 客户端与控制台方案（自述「待皇上评审」）暂不入库，防再次误提交。
 2026-10-07 01:42:44 +08:00
jkooe 7689a1f80c fix(v22): 构建改为**确定性** —— 去掉注入的构建时间，否则「指纹比对是否最新」永远失真 
## 现象（真机执行 `deploy --check`）
明明被控端就跑着 v1.4.2、本地也是 v1.4.2，却报「版本不一致」：
    本地 : 47326da097c7  (976 KB)
    远端 : 6499b3f7ad3c  (node v22.20.0)

## 根因
打包时注入了 `__BUILD_TIME__`，于是**同一份代码每次打包的字节都不同** →
内容哈希无法充当「构建身份」，`--check` / 部署后校验只能靠"这次上传的文件"比对，
跨批次就必然误报。

## 修复
- `pack.mjs` 不再注入构建时间（版本与 commit 仍是确定性的）
- `system.info.build.built_at` 改用**入口文件的 mtime**（mtime 不在文件内容里，
  因此不破坏字节确定性，同时仍能反映构建时刻）

## 验证
- 连打两次包（间隔 2s），指纹完全相同：`b13ce7d3ba74d0e0b293649f` ✓
- 真机更新：指纹 b13ce7d3ba74、42 项能力、证书钉住一致 ✓
- **再次执行 `--check` → 「✓ 已是最新，无需更新」**（此前同版本却报不一致）✓

## 意义
产物变为**可复现**（reproducible）：同一 commit 打出同一份字节，
sha256 可以放心用作分发与更新的身份标识 —— 这对一条「下载即执行代码」的更新通道很关键。
 2026-10-05 11:27:28 +08:00
jkooe f88738d36d fix(v22): 修正构建期注入的版本号带多余引号（真机暴露） 
## 现象
真机 `nodeagent info` 显示 `被控端版本 : v"1.4.0" @ "e841fbb"` —— 值里带了引号。

## 根因
esbuild 的 `--define:K=V` 中 **V 是按 JS 表达式解析的**。原先写成
`--define:__AGENT_VERSION__='"1.4.0"'`（单引号包裹），单引号被当成**字符串内容**，
于是运行时值变成 `"1.4.0"`（含引号）。产物内联可见：
`return false ? "dev" : '"e841fbb"';`

## 修复
改用 `JSON.stringify(v)`（纯双引号）→ 产物内联为 `return false ? "dev" : "1.4.0";` ✓
真机复核：`被控端版本 : v1.4.0 @ 50ac4b9  构建 05abbbc79abf` ✓

## 附带真机确认（v1.4.0 部署）
- 推送式部署 + **指纹校验通过**（能力 42 项、PID 16664）
- **证书指纹 TOFU 钉住生效**，且普通 agent 更新**不影响**钉住（证书未变 → 仍一致 ✓）——
  这正是设计意图：只有证书重建才会触发 E_CERT_MISMATCH
- **Windows 音频能力真机跑通**（Core Audio COM 路径）：`✓ 已应用：🔇 静音 · 音量 77%`，
  且能**读回真实状态**（确定性设置而非切换）—— 这补上了此前只在 macOS 验证的空缺
 2026-10-05 02:45:51 +08:00
jkooe 0d59d6032b feat(v21): 第一批安全加固 —— 证书指纹钉住 + 来源网段白名单 
对应审查建议的 P0 两条：这两项是**真实可利用的攻击路径**，其余（发现最小化/失败封禁等）
留待后续批次。

## ① 证书指纹钉住（TOFU）—— 挡同网段中间人
自签证书没有 CA 链，历史上客户端只能 `insecure` 接受任意证书 → 攻击者可**透明中继**：
拿不到钥匙（挑战-应答挡得住冒名），但能读到截屏/剪贴板/键入/exec 输出。

- 被控端：`install.ps1` 打印证书指纹（sha256 of DER）供**带外核对**；
  `system.info.build.cert_sha256` 与 `auth_ok.build.cert_sha256` 上报
- 控制端：首次连接自动钉进 `nodes.<名>.cert_sha256`；之后**严格比对**，
  不一致即 `E_CERT_MISMATCH`(-32422) 拒连，并提示 `--forget-cert` 重钉
- 额外做**交叉确认**：实际握手证书 vs auth_ok 自报，不一致同样拒绝（防自报被篡改）
- 指纹基于 **DER**（不是 PEM 字节），保证与 Windows .NET `GetRawCertData()` 同值

**踩坑记录（写进代码注释，避免后人重走）**：
1. `ws` 客户端的 `upgrade` 事件**只传 IncomingMessage**，拿不到 socket
2. socket 要在 `open` 之后从 `ws._socket` 取（TLSSocket）
3. Node ≥15 的 `getPeerCertificate()` 返回**对象**，DER 在 `.raw` 上（老版本才是 Buffer）
   —— 现已双兼容

## ② 来源网段白名单 `allow_from` —— 收敛暴露面
被控端默认监听 `0.0.0.0`（远程接入所需），但**换到不可信网络就自动暴露**。

- 支持 CIDR / 单 IP / `*`；**未配置 = 放行全部**（保持向后兼容，不打断现有部署）
- 拒绝发生在**业务握手之前**（不做 TLS/挑战应答，省资源），并记 `net.deny` 审计
- 判定按**前缀比特**而非字符串相等：Node 在 IPv6 监听上把 IPv4 客户端报成
  `::ffff:a.b.c.d`，已归一化（单测覆盖）
- `system.info.network.allow_from` 上报状态；`nodeagent info` 一眼看出是否已收敛

## 验证（本地真跑，非纸面）
- 白名单不含本机 → 连接被拒（agent 侧 WARN + 审计留痕）✓
- 白名单含本机 → 连上，并**自动钉住**指纹 ✓
- **换掉被控端证书后重连 → `E_CERT_MISMATCH` 拒绝**（期望 2ed4957b… / 实际 ca8dc20c…）✓
- 新增 e2e 用例（自起 TLS agent）覆盖上述四种情形 + agent 自报与实际证书一致性 ✓
- 新增单测 9 例（CIDR 前缀匹配 / IPv4-mapped 归一 / IPv6 zone / PEM≡DER / 篡改即变）
- 全量：单测 **159**（150→159）· e2e **29**（28→29）全绿

## 文档
新增 `docs/SECURITY.md`：信任模型（钥匙=root）、认证现状与**已知限制**（ACL 身份维度仅在
ed25519 有效）、本次两项加固的用法、尚未收敛的 6 项、应急处置表。
 2026-10-05 02:25:19 +08:00
jkooe 045e3b08b1 fix(sec): 安装包不再打包 PSK.txt（该 zip 会作为公开 Release 资产发布） 
## 问题
`nodeagent-win-x64.zip` 里含 `PSK.txt`（64 位预共享密钥）。而这个 zip 正是 GitHub
Release 的公开资产 —— 等于**把被控端的预共享密钥公开**。若谁用该 Release 包安装，
其密钥即为公开值，同网段的任何人都能凭此接入。

## 修复
- `pack.mjs` 打 zip 时用 `-x "PSK.txt"` 排除（并注明原因，防日后被加回）
- 不影响安装：`install.cmd` 在 PSK.txt 缺失时**本地自动生成**密钥（只留在被控端安装目录），
  这正是它头注释里既有的行为
- 新增单测守卫：断言打 zip 命令必须带 `-x PSK.txt`（防止回归）

## 兼容性
PATCH 级：仅打包内容变化，不涉及协议/能力/参数。已安装的机器不受影响。
 2026-10-05 00:25:44 +08:00
jkooe 1c26dc4e3f fix(release): sh() 容错 stdio:'inherit' 的 null 返回（发版首跑即炸） 2026-10-05 00:13:45 +08:00
jkooe 6faf807108 chore(release): fetch/push 统一走重试（本机 GitHub 连接间歇抖动） 2026-10-05 00:02:48 +08:00
jkooe 21d568d90d chore(release): 发版脚本加 push 重试（本机到 GitHub 连接会间歇抖动） 2026-10-04 23:57:35 +08:00
jkooe cedc46d090 feat(v20): 版本纪律 + 发版自动化（对齐「做好版本功能 + GitHub 同步资产」） 
## 一、版本功能（防新旧混用）
1. **单一版本源 + 构建注入**：根 package.json 的 version、git sha、构建时间经 esbuild
   `--define` 注入 agent；`system.info.build` 新增 `version/commit/built_at`（原有 `hash` 指纹不变）。
   开发态用 typeof 探测（未注入也不崩）。
2. **握手携带版本**：`auth_ok` 新增可选字段 `agent_version` / `build` / `protocol`（只增不减 → 旧控制端忽略即可）。
3. **能力级兼容比对**：新增纯函数 `capabilityDiff(local, remote)` ——
   - `missingOnRemote`：本地有远端没有 → **远端较旧**，提示更新被控端
   - `unknownLocally`：远端有本地没有 → **本控制端较旧**（不影响既有功能）
   控制端不比版本号而比**能力集合**：版本号可能相同而内容不同，能力集合不会骗人。
4. **CLI 体检**：`nodeagent info` / `connect` 直接显示被控端版本与能力对齐情况，
   把"调用时才炸"变成一句人话提示。

## 二、发版自动化（GitHub 资产同步）
`pnpm release <x.y.z|patch|minor|major>`：前置检查（干净/在 main/与远端同步）→ 改 7 个 package.json
→ 构建+打包 → 生成资产 → 提交打标签推送 → `gh release create` 上传。
- 资产：`agent.mjs`（**自更新载荷**）、`nodeagent-win-x64.zip`（人工安装包）、
  `latest.json`（version/commit/能力数 + 两个资产的 url 与 sha256）、`SHA256SUMS`
- `--dry-run` 无副作用演练；`--no-publish` 只到本地标签
- 能力数从 dist 动态取（避免写死漂移）；刻意排除 `.github/`（缺 workflow 权限推不了）

## 三、兼容性契约文档
新增 `docs/VERSIONING.md`：semver 各位的含义、**只增不改**六条硬规则、
升级顺序建议（**先被控端**：新被控端向后兼容旧 CLI）、两条更新路径、发版流程、排查手册。

## 验证
- 单测 147 → **149**（新增 capabilityDiff 用例：远端过旧 / 本机过旧 / 完全一致 / 真实清单自比无差异）
- e2e 28 全绿；`node scripts/release.mjs 1.0.0 --dry-run` 演练通过且工作区无副作用
 2026-10-04 23:54:51 +08:00
jkooe e95a0248da feat(v19): 拉取式自更新 system.agent.update（42 项）—— 回答「能否直接用 GitHub 做更新服务器」 
## 结论：能，而且这是「控制端与被控端不可达」场景的正解
`deploy`（推送式）要求两者可达；本能力只要求**被控端能上网**，因此跨网段/NAT/异地都能更新。
GitHub Release / raw / 自建镜像 / 任意 http(s) 地址均可 —— 地址是参数，不写死。

## 实现（apps/agent/src/capabilities/selfupdate.ts）
下载 → **校验 sha256** → 备份 → **原子替换**（同目录 rename）→ 受控重启（复用 v7）→ CLI 复核指纹
- 出口：CLI `nodeagent update --url <u> --sha256 <h> [--dry-run]` · MCP `na_agent_update`
- 审计新增 `agent.update` 事件（记录 url / 前后指纹 / 字节数 / 备份路径）

## 安全底线（否则等于开放远程代码执行）
1. **sha256 必填**，且逐字节校验通过才替换；不符即丢弃并明确报错（未改动任何文件）
2. 只接受 http/https，拒绝 file:// 等其它 scheme
3. 大小上限 64MB + 下载超时（默认 120s）
4. **先备份再原子替换**，失败可回滚（返回 backup_path）
5. `dry_run` 只下载校验、不动文件 —— 用于「先确认能不能更」
6. 不用 fetch 的内置代理（Node 未暴露 undici）：国内访问 GitHub 不稳时，
   把 url 指向**自建镜像/加速地址**即可，能力本身接受任意 http(s)

## 真机/本地验证（全程真跑，非纸面）
- e2e 新增：本地 HTTP 服务真跑下载 —— 正确哈希通过 / **错误哈希被拒** / 404 明确报错 /
  非 http(s) scheme 被拒 / 缺 sha256 协议层拒绝 ✓
- 完整流程本地实测：`dry-run 预检` → `真更新`（966KB）→ 备份逐字节一致 → 重启 →
  **复核到新指纹** → 能力 42 项 ✓
- 顺带修：返回值漏 `incoming_hash` 导致 CLI 复核被跳过（真机踩过）
- 单测 126 / e2e 28 全绿

## 已知约束（写进文档）
1. **首次仍要一次性安装**（install.ps1）—— 自更新能力本身得先在机器上，鸡生蛋无解
2. `node.exe`（Node 运行时）不在自更新范围，只换 agent.mjs
 2026-10-04 23:03:37 +08:00
jkooe e6a9a3d7ea feat(v18): 更新链路可靠化 —— 构建指纹 + 备份 + 轮询校验（附 6 个真机 bug 修复） 
## 皇上的问题
「这个版本如果有更新，可以在客户端上便捷的更新吗？」
答案：本来就有 `nodeagent deploy`（比最初的一键升级还早），但**它不可信**：
部署后只看「PID 变了 / 能力数对了」，证明不了真的换成了新代码（旧版可能能力数一样），
而且备份与失败判定都存在问题。本轮把这条链路做成**可信**的。

## 新增
1. **构建指纹**：agent 上报 `build.hash`（运行中脚本的 sha256 前 12 位）+ bytes/mtime/node/uptime。
   部署后按指纹校验「远端真的是新代码」，而非靠 PID/能力数猜。
2. **`deploy --check`**：只比对指纹不动文件（退出码 2 = 需要更新），适合脚本/巡检。
3. **`deploy --force`**：指纹相同也强制覆盖。
4. **`pnpm update:win [设备名]`**：一条命令完成「打包 → 校验产物确实更新 → 部署」
   （脚本刻意防呆：pack 后产物时间戳没变就拒绝部署，避免部署旧包 —— 真机踩过）。
5. **NODEAGENT_DEBUG=1**：CLI 打印异常堆栈（异步链问题必备）。

## 修掉的 6 个真机 bug（本轮逐个实测暴露）
1. **备份用 `Copy-Item`**（Windows 专用 shell 命令）→ macOS 被控端静默不备份。
   改为协议自带 fs.read/fs.write，跨平台。
2. **备份读取漏 `encoding: 'base64'`** → 二进制被按 utf8 读（损坏），再当 base64 写回
   → 备份文件只有 33 字节垃圾（实测：`fs.read` 返回 524288 字符而非 base64）。
3. **备份循环用 fs.read 返回的 `offset` 当前进量** → 那是「本次读取的起始位置」，
   于是原地打转 → 死循环 + 文件暴涨 + 部署卡死 200s。
   改为自算 len（对齐 cmdPush 成熟写法）+ 无进展即跳出。
4. **轮询用 withClient → 直接退出进程**：`withClientDirect` 在连接失败且是 ClientError 时
   调 `fail()` 退出 —— 轮询第一次连接必失败（agent 正在重启）→ CLI 立刻退出，
   报 E_NODE_OFFLINE，而**部署其实已成功**（本轮 3 次「失败」全是这个假象）。
   新增 `probeOnce()`：永不抛出的探测函数，专用于「等待上线/重启」类重试。
5. **盲等 9 秒**判定部署结果 → 改为**按墙钟**限时轮询指纹（90s），失败时报真实耗时。
6. **重启会切断连接**：该中断属预期，此前未处理会把成功误判为失败 → 显式吞掉并说明。

## 验证（本地全程真跑，非纸面）
用「起本地 agent → 造一个改动过的 bundle → 部署」的方式把整条链路跑通：
- 同版本 `--check` → 「已是最新」退出码 0 ✓
- 不同版本 `--check` → 报不一致退出码 2 ✓
- 完整部署 → 备份（979578B，`cmp` 逐字节一致）→ 上传 → 重启 → **指纹校验通过** ✓
- 防呆：文件过小/不存在被拒 ✓
- 单测 125 / e2e 27 全绿
 2026-10-04 22:54:45 +08:00
jkooe 9ef8978b92 feat(scripts): 网络救援脚本 rescue-network.ps1（网络变更失联后的本地恢复） 
## 为什么需要它
`system.net.apply` 是两阶段提交（未确认自动回滚），但**万一回滚本身也失败**
（本次真机事故就是：变更脚本把地址删了却没加上），机器会落到 APIPA(169.254.x.x) 而彻底失联。
那时远程已无路可走，只能本地恢复 —— 这个脚本就是为那一天准备的。

## 能力
- `-ListOnly`：先看清各网卡状态/地址/默认路由（含「已连接但无地址」的失联特征标注）
- 自动识别失联网卡（已连接但无有效 IPv4），也可 -Interface 指定
- 带 -Ip/-PrefixLength/-Gateway/-Dns 恢复静态；不带 -Ip 则切回 DHCP
- **安全顺序**（与 agent 内实现一致）：先加新地址 → 清旧地址与残留默认路由 → 补默认路由
- 自检并给出下一步命令（含可直接复制的 Mac 侧 connect 命令）

## 用法
    powershell -ExecutionPolicy Bypass -File rescue-network.ps1 -ListOnly
    powershell -ExecutionPolicy Bypass -File rescue-network.ps1 -Interface 'Ethernet' `
        -Ip 192.168.1.100 -PrefixLength 24 -Gateway 192.168.0.1
    powershell -ExecutionPolicy Bypass -File rescue-network.ps1 -Interface 'Ethernet'   # 切回 DHCP
 2026-09-30 11:10:23 +08:00
jkooe 4d1aeada07 feat(v12.4): 事件直达 MCP 宿主（实时推送）+ 修两个真 bug 
## 背景
v12 的事件订阅对 MCP 只走「被控端缓冲 + na_event_poll 拉取」。MCP 协议本身支持
服务端 -> 客户端通知，故补上实时推送：na_event_watch 的 notify=true 开启，
事件经 MCP 标准日志通知（notifications/message）即时送达宿主。

## 两条通路并存（互相兜底）
1) 推送：onEvent -> server.notification(notifications/message, logger=nodeagent.event)
   —— 宿主若不展示日志通知，则自动退化为拉取，无副作用
2) 拉取：na_event_poll（增量游标）
na_event_list 额外返回推送开关与已转发条数，便于判断该用哪条通路。

## 真机修掉的两个 bug
1. **notify 参数泄漏到能力侧**：notify 是 MCP 层开关，原样透传被被控端
   additionalProperties:false 拒绝（E_PARAM_INVALID）。改为在 toArgs 里显式构造，
   只带能力真正接受的字段。
2. **通知未声明 logging 能力导致 MCP 进程崩溃**：SDK 的 notification() 在未声明
   logging 能力时抛错，且因返回 Promise 未 catch -> 未处理拒绝直接终止进程
   （真机实测：watch 成功后一有事件，整个 MCP 服务就退出）。
   修法：capabilities 声明 logging + 通知调用补 catch（失败静默降级为拉取）。

## 端到端验证（scripts/verify-mcp-events.mjs，已收进仓库）
真实 MCP stdio 客户端驱动，对生产被控端实测：
- initialize ok；tools/list 31 个工具、事件类 4 个
- na_event_watch(notify=true) -> watch_id
- 制造 创建/修改/删除 -> **收到 3 条推送通知**（file created_or_removed / modified / ...）
- na_event_poll 返回缓冲事件（seq/watch_id/ts/action/target）
- na_event_list 显示「推送已开启（已转发 3 条）」
结论：推送 ✅ 生效；拉取 ✅ 生效

单测 89/89、e2e 21/21 全绿
 2026-09-29 15:47:34 +08:00
jkooe 2dccec9a5c feat(D): 生产化 —— 无人值守模式 / 一键升级 / 文档口径更新 
## D1 无人值守（install.ps1）
- 新增 -Unattended（S4U 登录类型）：**无需保存密码，注销/重启后仍自动运行**
- 新增 -AtStartup：追加开机触发器；任务设置补 StartWhenAvailable（错过触发后补跑）
- **诚实标注能力边界**：S4U 运行在非交互会话，GUI 能力（截屏/UIA/键鼠）不可用；
  -Unattended 与 -AllowInput 冲突时自动关闭输入控制并回写配置
- 说明文档给出两种模式的对照表（交互模式支持 GUI，但注销即停）

## D2 一键升级（nodeagent deploy）
- system.info 新增自描述字段：pid / agent_script / agent_home / node_path
- deploy 流程：读取被控端入口路径 → 备份旧文件 → 分块上传新 agent.mjs
  → 调 system.agent.restart 受控重启 → 等待恢复并复验能力数
- 真机验证：
  * 首次（旧版 agent 无自描述）：--path 指定 → 上传 853KB → PID 16492 / 31 项能力
  * 二次：自动识别路径 + 自动备份 → PID 34120 / 31 项能力（免 --path）

## D3 CI（待推送）
- windows-e2e.yml 增加单元测试步骤（3 行）；因 OAuth token 缺 workflow scope，
  该改动暂留本地未推送，需用户授权后推送

## D4 文档口径更新（README）
- 能力总览补齐 31 项（新增：自持/异步任务/窗口/录屏/剪贴板/拖拽/审计校验）
- 统计数字更正：19 项能力 -> 31，15 个 MCP 工具 -> 26，补 61 项单元测试
- 路线图补 v7~v11+；安全章节补密钥库/Audit 链/ACL 细化
- 命令速查新增：restart / deploy / daemon / fanout / bg / tasks / clip / record /
  window.* / screen.find / mouse drag
- MCP 工具表按新工具重排；安装章节新增两种运行模式对照表

单测 61/61、e2e 21/21 全绿
 2026-09-29 11:47:15 +08:00
jkooe fac51046cf feat(v10.1): CLI 常驻 daemon（nodeagentd）—— 连接池复用，批量调用提速 
## 机制
- nodeagentd 常驻进程监听 UDS（$TMPDIR/nodeagentd.sock），持有与被控端的
  长连接池（autoReconnect，每设备一条，LRU 上限 8，空闲 5min 释放）
- CLI withClient 检测 socket 存活 → 经 daemon JSON-lines 转发 invoke（虚拟 client）；
  daemon 自身错误静默回退直连，业务错误原样透传 —— 零行为变化，纯加速层
- CLI 新命令: nodeagent daemon start|stop|status；打包新增 nodeagentd 产物

## 实测（真机）
- 轻调用（info）: 752ms -> 527ms（省 TLS+hello/challenge/auth，约 30%）
- 轻调用 5 连发（clip.get）: 2.58s -> 2.41s
- 重调用（ps 远端 CPU 采样 1.4s）提速不显著 —— 瓶颈在远端执行而非握手，符合预期
- unit 26/26、e2e 21/21 全绿
 2026-09-29 10:55:38 +08:00