 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
|
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
|
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 |
|