jkooe
|
9bba53d5c0
|
fix(ci): 修 Rust Shell 工作流 —— resources 只声明构建期必产出的文件
CI 失败根因(本地已复现确认):`tauri-build`(build.rs) 会在**编译期校验**
`tauri.conf.json` 的 `bundle.resources` 声明文件是否存在。
我之前声明了两项:`sidecar.mjs`(CI 未生成)+ `resources/node`(Node 运行时未下载)
→ build.rs 直接失败("failed to run custom build command")。
修复:
- `tauri.conf.json` 的 resources **只留 sidecar.mjs**,并写明为何不能声明未就绪的文件
- `rust.yml` 在 clippy/test **之前**加「构建 sidecar」步骤(`pnpm --filter nodeagent-console sidecar:build`)
- console-plan.md:⑤ 不再把 node 记为已完成(未验证的不写成做完),
补「已知待办」(Node 运行时随包分发 + GUI 端到端人工验证)与「构建约束」说明
本地复现验证:删掉 `sidecar/dist/` → `cargo check` 复现同一错误;恢复 → 通过 ✓
|
2026-10-10 15:25:12 +08:00 |
|
jkooe
|
53bf5a0634
|
feat(console)!: Rust 壳改用 Node sidecar(选项 D 完成)—— 退役 crates/nodeagent-client
## 动机(消除「两套协议实现」)
原设计让 Rust 壳自己实现 client,与 TS 版(@nodeagent/client)并存 → 改一处漏一处时
构建过、单测过,只在真机暴露。现 Rust 壳只做**进程管理 + 消息转发**,协议实现只剩 TS 一份。
## ④ Rust 壳改造
- 新增 `src-tauri/src/sidecar.rs`(~290 行):Sidecar 管理器 —— spawn node、
行分隔 JSON-RPC 的请求/响应匹配(oneshot + 超时兜底)、通知回调(state/log/agent_event)、
`resolve_node`/`resolve_sidecar` 路径解析(env → Tauri resource → 开发期系统 node)
- 重写 `lib.rs` 为薄转发层:`ensure_sidecar` 懒启动;**5 个 command 签名与 3 个 event 名
(na-state/na-log/na-event)一律不变 → 前端零改动**;`get_capabilities`/`get_state`
读本地缓存以**保持同步签名**;`RunEvent::Exit` 时优雅 shutdown(kill_on_drop 兜底不留孤儿)
- `Cargo.toml`:移除 nodeagent-client 依赖、加 tokio;**版本 0.1.0 → 2.0.0**
(原先与 tauri.conf.json 的 2.0.0 不一致,属版本号统一范围)
## ⑤ 打包配置
- `tauri.conf.json`:`bundle.resources` 声明 sidecar.mjs 与 node;
`beforeBuildCommand` 串上 `sidecar:build`(否则 resource 缺失)
## ⑥ 退役
- 删除整个 `crates/`(12 文件,含 nodeagent-client 与其 probe 示例)
- `rust.yml` 由「Rust client 单测」改为「**Rust 壳单测(真跑 sidecar)**」:
装 Tauri 系统依赖 + Node + pnpm,跑 clippy `-D warnings` 与 `cargo test`
- `package.json`:`test:rust` 改指 console 壳;移除 `probe`
(其「对真机逐项核对字段」的用途已由 CLI `nodeagent invoke` 覆盖)
- 引用清理:README(数字与协议客户端说明)、console 前端两处注释、
console-plan(开头加「原方案已被取代」提示 + 补改造详情)、ROADMAP 历史描述加退役批注
## 验证
- **`cargo test` 3/3 通过**(真跑 Node sidecar 子进程:spawn/请求-响应/错误不崩)——
这是关键:sidecar 管理器**不依赖 Tauri GUI**,故核心逻辑可在 CI 真实验证,不必等人工开窗口
- `cargo check` 零警告;clippy 标准与 CI 一致
- 273 单测 / 7 包构建 全绿
- ⚠️ **仍需人工验证**:Tauri GUI 端到端(开窗口 → 连被控端 → 点界面),沙箱跑不了图形应用
|
2026-10-10 15:16:24 +08:00 |
|
jkooe
|
d065242413
|
docs/ci: README 数字校正 + checkout 升 v5
- README:统计口径已过期(43 能力 · **32** MCP 工具 · **114** 单测 · **26** E2E),
校正为实测值:43 能力 · 38 MCP 工具 · 215 单测 · 30 E2E · 11 Rust 单测。
另补「桌面控制台」小节(架构图、页面表、构建命令、平台门控说明)与构建步骤说明
—— 新组件入库后不同步 README,读者会以为仓库里没有它。
- CI:actions/checkout@v4 → v5,消除 runner 上的 Node.js 20 弃用告警。
仅升被标记的这一个;setup-node / pnpm-action 未被标记,不做未验证的连带升级。
|
2026-10-07 10:18:52 +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
|
6b2b3828a5
|
fix(ci): 产物包检查改为反向断言 —— 包内**不得**含 PSK.txt(原来是断言应该有)
045e3b0 起 PSK.txt 已不再打进公开 zip(现生成给本机,打进公开资产=泄露密钥),
但 CI 的必含清单里还列着 PSK.txt → 每轮必红,且方向完全反了。
现在:必含 7 项 entries;并反向断言不含 PSK.txt / *.key / *.pem / certs ——
把「公开资产不带钥匙」这条性质变成 CI 守护项,而不是相反的束缚。
|
2026-10-07 02:27:58 +08:00 |
|
jkooe
|
9ee75cf694
|
ci: 清理步骤加 continue-on-error(前置失败不应连带掩盖真实结论)
|
2026-10-07 02:15:05 +08:00 |
|
jkooe
|
cd278ffda8
|
fix(ci): 5.1 执行的内联脚本一律 ASCII-only(同一个 BOM 坑,臣在 CI 步骤里原样复现)
第二轮 CI 暴露:『install.ps1 安装链路』失败,报 string is missing the terminator。
根因不是被测脚本(BOM 守卫同轮通过),而是**步骤自身的 run: 块里有中文** ——
GitHub 把 run 块写成**无 BOM** 的临时 .ps1,5.1 按 GBK 读 → 中文乱码 → 引号边界崩。
这与 2026-10-04 install.ps1 无 BOM 导致的事故是同一机制,臣在 CI 里原样踩了一遍。
修正:
- 所有 shell: powershell(= 5.1)/ shell: cmd 步骤的内联脚本改为 ASCII-only
(中文只留在步骤名,那是元数据不参与执行)
- BOM 守卫的 throw 消息也一并英文化(它上一轮是侥幸没过炸)
- 清理步骤加 continue-on-error,避免前置失败连带掩盖真实结论
保留:shell: pwsh 步骤的英文/中文不受影响(7+ 认 UTF-8 无 BOM)。
|
2026-10-07 02:14:27 +08:00 |
|
jkooe
|
817ec3645b
|
fix(ci): BOM 守卫步骤改用 shell: powershell(cmd 套 -Command 多行引号会全乱)
第一轮 CI 暴露:该步骤自身写法错,不是脚本错。shell: cmd + powershell -Command "..."
带多行/内层引号,经 cmd 转义后变成:
Missing closing '}' / '$errs' is not recognized / -and was unexpected
全是指 step 自身,与被测 .ps1 无关。
修正:直接用 shell: powershell(runner 上的 powershell 就是 5.1,正是要测的目标)+ run: | 块,
与旁边已通过的 install 冒烟步骤同一形态。
|
2026-10-07 02:04:43 +08:00 |
|
jkooe
|
af1cd39fdf
|
ci: 补全 Windows 真机验证(单测步骤 + 5.1 BOM 守卫 + install.cmd 双击链路冒烟)
三处改动都源自真机事故复盘:
1. **单测步骤**(并入 ci/workflow-unit-tests 分支 4d73d6e 的实质贡献 —— 该分支基于
09-29 老 main,直接 merge 会回退上万行,故只取其提交内容手工并入)
2. **PowerShell 5.1 解析守卫**:install.ps1 无 BOM 时 5.1 按 GBK 解析 → 中文注释
破坏字符串边界 → 整份脚本 ParseError(2026-10-04 真机踩过)。此前 CI 冒烟用
pwsh(7+ 认无 BOM UTF-8)**所以 CI 绿、真机炸** —— 现在这道守卫只问一件事:
5.1 能否读懂,而这就是真机的核心约束
3. **install.cmd / control.cmd 双击链路冒烟**:这是用户唯一的上手入口,
编码或语法坏了只有真机 cmd.exe 能测出来
(workflow 作用域已于 2026-10-07 由皇上授权后推送)
|
2026-10-07 01:55:14 +08:00 |
|
jkooe
|
9e357cf7cc
|
Create windows-e2e.yml
|
2026-09-27 02:23:42 +08:00 |
|