mtfyun/nodeagent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
145 Commits 1 Branch 14 Tags
765ad08ee6426bf2cec19c7cee6c4e40fdf810a0
Commit Graph
43 Commits
Author SHA1 Message Date
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
jkooe 3316f08c92 fix: 修复 Windows 安装后无法启动 —— PowerShell 写入的 JSON 带 UTF-8 BOM 
真机报错：启动失败: Unexpected token '', "{"a"... is not valid JSON
根因：Windows PowerShell 5.1 的 Set-Content -Encoding UTF8 会写入 BOM（U+FEFF），
      Node 侧 JSON.parse 拒绝解析带 BOM 的文本。

双管齐下修复：
1. 写端 install.ps1：改用 [System.IO.File]::WriteAllText + UTF8Encoding($false)
   写出无 BOM 的 UTF-8
2. 读端容错（兼容已被写坏的配置）：
   - apps/agent/src/config.ts：读配置时剥离开头 BOM
   - packages/client/src/config.ts：同上

验证：构造带 BOM 的 agent.json（ef bb bf 开头），agent 可正常启动；
单元 26/26、E2E 21/21 全绿
 2026-09-27 19:32:53 +08:00
jkooe b350a41803 fix(install.ps1): 安装后验证端口监听，并在连接命令中填入真实 IP 
真机安装反馈暴露两处缺陷：
1. 只打印计划任务状态（Ready）就宣告完成，未确认端口真的在监听 ——
   用户按提示连接时会超时，却得不到任何线索。
   现改为轮询等待端口进入 Listen（最多 15s），失败时打印任务最后运行结果
   与三步排查命令（手动启动任务 / 查进程 / 前台运行看报错）。
2. 连接提示里的 <THIS-IP> 是字面占位符，用户照抄会失败。
   现改为填入实际探测到的本机 IPv4。
 2026-09-27 19:29:56 +08:00
jkooe 665c0e85c4 feat: Mac 控制端一键安装（pack:mac + install-macos.sh） 
Mac 是控制端，不需要 Windows 安装包，但此前必须 cd 到仓库敲
node apps/cli/dist/index.js，太啰嗦。

新增：
- pnpm pack:mac（scripts/pack-macos.mjs）：把 CLI 与 MCP 打包为带 shebang 的
  可执行单文件（195KB / 772KB），免 node_modules
- scripts/install-macos.sh：安装到 ~/.local/bin（已在 PATH）+ 打印 MCP 配置片段
- Mac 端不打 Node 运行时（控制端本机已有 Node，体积从约 50MB 降到约 1MB）

修复：execFileSync 不能接收带参数的命令字符串（改用 execSync）

验证：./nodeagent --help 与 MCP tools/list(18) 可直接执行；
install-macos.sh 安装后可在任意目录调用 nodeagent
 2026-09-27 19:24:57 +08:00
jkooe 4c9b44288c fix(pack): esbuild 输入改用绝对路径，支持从任意目录调用 
此前 pack.mjs 用相对路径 apps/agent/dist/index.js 作为 esbuild 输入，
从项目目录外调用（node <abs>/scripts/pack.mjs）时报
Could not resolve apps/agent/dist/index.js。

改为基于 __dirname 的绝对路径；README 补充两种调用方式并注明需在项目目录执行。

验证：cd /tmp && node <abs>/scripts/pack.mjs 可正常产出 32MB 安装包
 2026-09-27 19:21:21 +08:00
jkooe 192e08b171 feat: Windows 便携安装包构建（免装 Node.js） 
新增 pnpm pack:win（scripts/pack.mjs），一键产出 nodeagent-win-x64.zip：
- esbuild 打包被控端为单文件 bundle（含全部依赖，约 800KB）
- 自动下载 Node.js Windows x64 运行时（npmmirror，node.exe）
- 组装便携包并打 zip（node.exe + agent.mjs + install.ps1 + uninstall.ps1）

改造 install.ps1：
- 优先使用包内 node.exe + agent.mjs（便携包模式）
- 否则回退系统 Node.js + 仓库构建产物（开发模式）
- 无 Node.js 的 Windows 机器也能一键安装

配套：
- .gitignore 忽略 release/（产物体积大，不入库）
- README 安装说明改为「安装包（推荐）/ 开发模式」两方式

验证：打包产物 32MB；解压后 agent.mjs 可独立运行（19 项能力、wss 监听）；
esbuild bundle 通过 banner 提供 createRequire 兼容 CJS 依赖（node-forge）
 2026-09-27 18:03:04 +08:00
jkooe f4c605cc6d test+fix: 单元测试套件 + 两处细节修复 
单元测试（新增，node:test 零依赖）：
- tests/unit/: ulid / hmac / ed25519 / acl / validate 共 26 项用例
- 覆盖最关键的安全函数：签名验签、ACL 授权、参数校验
- 新增 pnpm test:unit；CI 增加单元测试步骤

细节修复：
1. screen.info 的 scale 硬编码为 1 → 改读注册表 HKCU AppliedDPI，
   真实反映 Windows DPI 缩放（100% -> 1.0, 150% -> 1.5）
2. verify.mjs 升级：支持多设备配置（resolveTarget）+ ed25519 模式 + Hub 中转
   （此前直接用旧的扁平配置 + 仅 psk，配了多设备会取不到 host）

验证：构建 + 类型检查全绿；单元 26/26；E2E 21/21；verify.mjs 13/0/3
 2026-09-27 17:04:21 +08:00
jkooe 3d0eb1c696 feat(v4): 无感体验 —— 局域网自动发现 + 断线自动重连 
自动发现（免手抄 IP）：
- 被控端 UDP 心跳广播（默认 5s 一次，目标 255.255.255.255:8766）
- 控制端 Discovery 监听 + TTL 设备表（默认 30s 过期）
- 报文不含任何凭据；可 discovery.enabled:false 关闭
- 控制端取「报文来源 IP」作为可达地址（比被控端自报地址可靠）
- CLI: nodeagent discover [--wait 5]；MCP: na_discover

断线自动重连：
- client 新增 autoReconnect（指数退避 1s→30s + ±15% 抖动）
- 重连前清空在途请求（统一 E_NODE_OFFLINE），避免悬挂
- onStateChange 回调（connected/reconnecting/closed）
- close() 会停止重连，不会关不掉

修复：UDP socket 需先 bind 再 setBroadcast（未绑定时报 EBADF）

验证：本地 E2E 19/19（新增发现 + 重连两用例）；构建与类型检查全绿
 2026-09-27 13:11:13 +08:00
jkooe 5b7e967868 feat(v3): 零信任安全 —— Ed25519 身份认证 + 能力级 ACL 
认证（两模式并存，默认 psk 向后兼容）：
- 新增 auth_mode: psk | ed25519
- ed25519：每控制端独立密钥对，挑战-应答签名验证（替代共享密钥）
- 密钥用 Node 内置 crypto 生成（零新依赖），Base64(DER) 单行格式
- 私钥存 <数据目录>/keys/ed25519.json（600 权限，永不外传）

授权（能力级 ACL）：
- acl.clients[] 按调用方登记 pubkey + allow/deny（glob 匹配）
- 判定顺序 deny → allow → default_effect（默认拒绝）
- 未注册身份 / 验签失败 → 握手拒绝；未授权能力 → E_ACL_DENIED
- auth_ok 下发 authorized 子集，CLI 以 授权/未授权 标识展示授权矩阵

接入：
- CLI: keygen（生成密钥 + 打印 ACL 配置片段）、connect --auth-mode ed25519
- MCP: 按 auth_mode 自动选择认证方式
- install.ps1: 显式写 auth_mode + 零信任指引

验证：本地 E2E 17/17（新增零信任四项断言）；手动端到端复验通过
 2026-09-27 11:01:58 +08:00
jkooe 792937c6b0 feat(v2): 图形接管 —— 屏幕感知 + 输入控制 
新增 7 项能力（总计 14）：
- screen.info / screen.capture：显示器信息、截屏（region/scale/format）
- input.mouse.move/click/scroll、input.key.type/press：鼠标键盘控制

安全设计：
- input.* 为高危能力，由被控端 allow_input 开关统一管控，默认禁用
- 未开启时返回 E_CAPABILITY_DISABLED（附开启指引）
- 文本输入经 Base64 传参、PowerShell 侧解码，杜绝内容注入
- 按键名走白名单映射（虚拟键码），非法键名直接拒绝

实现：纯 PowerShell（System.Drawing 截屏 + user32.dll SendInput），
无原生编译、无第三方依赖。

接入：
- CLI: screen / screenshot / mouse / key 命令
- MCP: na_screenshot（直接返回图像）/ na_mouse / na_key
- install.ps1: 新增 -AllowInput 开关
- verify.mjs: 新增 v2.1~v2.3 验收项

验证：本地 E2E 16/16；远程验收 12 通过 / 0 失败
 2026-09-27 03:43:10 +08:00
jkooe f1506b3fd0 test: 新增自动化真机验证体系 
- tests/e2e/windows.mjs: Windows 专属能力测试（service.list / app.list / winget 装软件 / cmd 外壳）
- tests/e2e/run.mjs: service.list 断言改为平台感知（Windows 期望成功）
- scripts/verify.mjs: 远程验收脚本，对齐 PRD FR-01~FR-08 逐条验收 + Markdown 报告
- package.json: 新增 test:windows / verify 脚本
- README: 补充自动化真机验证三层体系说明

注: .github/workflows/windows-e2e.yml 需 workflow scope，待授权后单独提交
 2026-09-27 01:24:52 +08:00
jkooe 77c024703a feat: nodeagent v1 初期开发完成 
- packages/protocol: 协议定义（信封/方法/错误码/能力schema/校验/HMAC/ULID）
- packages/client: 控制端客户端库（连接/握手/invoke/超时）
- apps/agent: Windows 被控端（监听/HMAC认证/能力分发/7项能力/进程执行）
- apps/cli: 控制端 CLI（connect/info/status/ps/services/exec/apps/install/list/invoke）
- apps/mcp: MCP server（na_* 工具，接入 WorkBuddy）
- scripts: install.ps1 / uninstall.ps1（开机自启 + 防火墙 + 密钥生成）
- tests/e2e: 端到端测试 13/13 通过（握手/能力/超时强杀/参数校验/鉴权失败/未认证）
 2026-09-27 01:06:35 +08:00