|
|
0b548b8fcf
|
test(pi-bridge): 临时目录满时不再伪装成内存缺陷 —— 前置自检 + ENOSPC 兜底
现场（2026-09-14 实测）：`/tmp` 是 tmpfs，被别人占满，`statfsSync` 实读
`bavail*bsize` 只剩 **0.70 MiB**。此时 `npm test` 红一条
not ok 323 - ★巨大的 message 行不进内存也不影响解析
error: 'ENOSPC: no space left on device, write'
那条红的**形状指向内存**（用例名里就写着"不进内存"，而它恰好是往临时目录写文件的
用例）⇒ 下一个踩到的人会去 `session-scan.mjs` 找一个**不存在**的内存缺陷。
改：
- `lib/tmp-space.mjs`：测量与判据分开，判据是纯函数 `judgeSpace`，喂字节数即可验；
读不到可用空间（null/NaN）⇒ **不判红**（不知道 ≠ 不对，否则会造出"总在亮"的红灯）。
**但 0 字节不是"不知道"** —— 第一版把 `<=0` 一并当"没测到"，于是 `bavail` 只剩
712 字节时前置自检放行、紧接着 17 条用例 ENOSPC 全红：前置自检装了等于没装。
阈值 32 MiB = 实测单条用例最大写入量（`session-scan` 那条写 3×3 MiB 行 ≈ 12 MiB）
×2 + 8 MiB 机动，不是总容量的百分比（百分比在这套测试上没有依据）。
- `test/env-preflight.mjs`（名字不带 `.test.`，不被 glob 收进用例）：
`package.json` 的 test 改成先跑它；不足时打印实测/阈值/目录并 **exit 2**
—— 与 `deploy/redeploy-plugin.sh` 的 `2=环境问题` 同一套约定，看到 2 才知道
去查机器而不是查代码。文案里明写「这是环境不足，不是断言失败」。
- `session-scan.test.mjs`：兜底翻译 ENOSPC（`node --test 'test/*.test.mjs'` 会绕过
前置脚本，这一句不管套件怎么被调起来都生效）—— 这正是治那条误导的关键。
- `test/env-guard.test.mjs`：8 条自证 —— 纯函数两头 + 边界（≥阈值算够、<阈值不够）
+ 0 字节必须红 + 读不到不判红 + 阈值有据 + 端到端 exit 2 且文案对得上。
端到端那条**不假设本机 /tmp 仍然满**：先自己量一次，够用就跳过并说明原因，
免得它退化成一条"总在亮"或"总在绿"的假判据。
顺带修 `deploy/check-deploy-drift.mjs` 两处同源问题：
- `selfCheck()` 要在临时目录造两棵小树，`/tmp` 满时抛 ENOSPC —— 而它是**未捕获异常**，
堆栈指向本文件，看起来像检查器坏了。翻译成说得清的错并让 main() 报 2。
- 新增判据 ⑥「工作区干净」—— **只提示，不参与 exit code**。判据 ① 比的是
「仓库工作区→快照」这一跳，覆盖不到「HEAD→工作区」那一跳（实证：一行未提交的
死代码被 17:20 的快照带进生产，而 ① 报的是"逐字节一致"）。做成红灯就是一条
总在亮的判据（本文件头自己骂过的病），所以只说、不判。
验证：`npm test` 453/453（新增 8 条）；`npm test` 在 /tmp 满时 exit 2 且不再跑用例；
`node deploy/check-deploy-drift.mjs --self-check` 17 条全过（含 ⑥ 的三条正反面）。
|
2026-09-14 19:29:44 +08:00 |
|
|
|
5c22daf51b
|
fix(deploy-drift): 结论区那行命令跑不起来（node → bash）+ 写明判据 ① 的量纲
两处，都在 `deploy/check-deploy-drift.mjs`：
1. 结论区打印的修复命令是 `node deploy/redeploy-plugin.sh <host>`，
而它是 **bash** 脚本 —— 照抄的人会拿到
`SyntaxError: Invalid or unexpected token`（脚本第 2 行 `#` 被当 JS 解析）。
这个坑的源头就是这一行：pi 在 2026-09-14 那轮部署请求里抄的就是它打印的输出，
抄错不是阅读问题，是判据自己印错了。改成 `bash …`。
2. 判据 ① 的注释写明它比的是**仓库工作区当前内容**，不是 git HEAD。
实证（同一天）：`plugins/pi-mail-bridge/src/pool.mjs` 里一行未提交的
`let missingSessionCount = 0;`（模块顶层、无人读）被 17:20 那次
**从脏工作区做的**快照原样带进了生产，而判据 ① 当时报的是「逐字节一致」——
工作区与快照确实一致，只是两者都不等于 HEAD。
判据没错，是量纲只覆盖「仓库→快照」这一跳，覆盖不到「HEAD→工作区」那一跳；
想连那一跳一起判得单独比 `git diff --stat`。
（那条死代码本身已由 pi 的补丁 A 从工作区删掉，pool.mjs 工作区已回到 HEAD 内容；
下次部署后 `current/src/pool.mjs` 里的它才消失 —— 在此之前判据 ① 会因此报一处
pool.mjs 漂移，那是"待部署"，不是新问题。）
|
2026-09-14 19:24:44 +08:00 |
|
|
|
51789ee72e
|
deploy: 标准目录部署 —— 运行时不再依赖源码目录
用户注意到：「当前 agentmail 是在源码目录部署的，应当改为标准目录部署」。
查证后有三处实证（都不是猜测）：
1. ★ **失败通知钩子执行的是仓库里的脚本**
（`/home/program/agentmail/deploy/service-failure-notify.mjs`，8 处引用：
4 个 drop-in + zcode/zcode-mail-bridge 单元 + agentmail-failure-flush）。
仓库一挪/一改名，故障通知就**静默失效** —— 而那条管线正是用来报告服务故障的。
2. **opencode-serve 的 cwd 就是源码目录**（`WorkingDirectory=/home/program/agentmail`）。
3. ★ **仓库里的 `deploy/*.service` 是旧的源码目录版本**（ExecStart 指向
`/home/program/agentmail/plugins/...`），而机器上的已被改过 —— 也就是说
**谁跑一次 install.sh 就会把部署退回源码目录**。drop-in 更是只存在于 /etc 里，
仓库完全没有它们。
## 改动
- **唯一真相**：`deploy/systemd/` 镜像 systemd 目录结构，收进全部单元与 drop-in
（8 个单元 + 12 个 drop-in），路径全部改到 `/opt`。
- 运行时脚本装到 **`/opt/agentmail/bin/service-failure-notify.mjs`**（自包含，
无相对导入）；`install.sh` 与 `redeploy-gateway.sh` 都会幂等地装它。
- opencode 的 cwd 改为 `/opt/agentmail`（与网关一致），已重启生效
（`/proc/<pid>/cwd` 已核）。
- 删掉 `deploy/*.service` 的旧副本，避免两个真相。
- dsh 的 `cordis.patch.yml` 注释里的安装示例也改到标准位置（运行时用的是环境变量，
那条注释是唯一残留）。
## 判据（`deploy/check-deploy-drift.mjs` 新增「标准目录部署」四条 + 自检）
① 任何 unit/drop-in 都不得引用源码目录；② 已安装单元与 `deploy/systemd/` 逐字节一致；
③ 通知脚本在标准位置且可执行；④ 各服务的 cwd/ExecStart 不在源码目录
（homeagent/dsh/zcode 是**别的产品**的标准位置，按白名单放行）。
自检两个样本：引用源码目录的必须红、干净样本必须绿（证明不是恒真）。
顺带修掉一处**真漂移**：仓库里 dsh 的 `dist/index.js` 落后于部署件（改了 src 没重建），
重建后 `check-deploy-drift` 报「四个宿主都在跑当前代码」。
## 复核
- `/etc/systemd/system/` 引用仓库：**0** 个文件；`/opt/agentmail` 下只剩旧二进制/备份里
的构建路径（Go 嵌的源码路径，无害）与一条注释。
- 四个宿主都在跑当前代码；标准目录四项全绿。
- 全部服务 active，opencode/网关 cwd 均已在安装根下。
|
2026-09-14 08:38:33 +08:00 |
|
|
|
b53afd4523
|
chore(deploy): 部署漂移检查器 —— 快照是不是还等于仓库、进程到底在跑哪份代码
「部署脚本跑过了」不等于「线上跑的是当前代码」。三种各自独立的漂移，谁都不会
在意，直到出问题时才发现线上是几天前的行为：
1. 仓库改了、快照没重新部署（快照是独立副本）
2. **软链切了、进程没重启** —— `current` 只是个符号链接，切换它不会重载
已在跑的进程，进程持有的是启动那一刻加载进内存的代码
3. 单元/配置改了、没 daemon-reload 或没重装
`node deploy/check-deploy-drift.mjs`（`--self-check` / `--json`）把三件事变成
可判定的：逐字节比内容（**不用 diff** —— 本机 PATH 上那个是鸿蒙工具链里的，
对内容不同的文件仍返回 0）、读进程真实 argv、比进程启动时刻与软链切换时刻。
## 判据必须按宿主真实的加载方式分开写（这是踩出来的）
第一版对四个宿主用同一套判据（「单元 ExecStart 指向 current」+「进程 argv 里有
快照路径」），结果 **opencode 与 dsh 双双假红**：它们的插件由**宿主进程**加载，
argv 里永远只有宿主自己的可执行文件。永假条件在检查器里表现为「稳定的红灯」，
人会学会忽略它。
| 宿主 | 谁加载 | 从哪里读 | 切换后要重启吗 |
|---|---|---|---|
| pi / zcode | 自己的进程 | unit 的 ExecStart | 要（启动时加载） |
| dsh | dsh 宿主 | profile `link:` → `node_modules` 软链 | 要（服务启动时） |
| opencode | opencode 宿主 | `opencode.jsonc` 的 `plugin:` | 不要（会话创建时惰加载） |
## 判据自检也修了一次
第一版自检「宿主表：运行时加载的宿主必须标记需要重启」写的是
`h.restartOnSwitch !== false`，而 `undefined` 也被放过 —— 于是 pi/zcode 的
`restartOnSwitch` 缺省成 undefined、落进「惰加载」分支、判据**永真**。
现在这条判据抽成纯函数 `judgeRestart`，自检用**行为用例**盖住：
旧进程 + 启动时加载的宿主必须判红、惰加载的宿主不判红、切换后启动的一律放行、
读不到启动时刻时不据此判红、容差内不判红。
## 扰动实验（在真实对象上证明判据会红）
- 改一个仓库运行文件 → pi 的「① 运行文件与仓库一致」变红，恢复即绿 ✓
- 只把 pi 的软链 mtime 拨到刚刚（模拟「切了没重启」）→ 「④」变红并指出原因 ✓
- 把 dsh 与 opencode 的软链都拨动 → **dsh 红、opencode 绿**（惰加载该保持绿）✓
全部拨动均已在实验后还原并复核为绿。
## 当前结论
四个宿主都在跑当前代码（pi/opencode/dsh 的快照自 11:45 起未变，其间无提交
动过它们的运行文件；zcode 是 18:57 的快照）。「三桥加载规范化」的切换本身
早已完成，缺的是这条可复跑的判据 —— 补齐了。
另外修了 `redeploy-plugin.sh` 的一个静默问题：`usage()` 按**行号范围**截取头部
注释（`sed -n '2,40p'`），我这次的注释把退出码那段挤到 40 行之后，`--help`
就少了半页。已同步范围并就地记下这个陷阱。
|
2026-09-12 20:39:22 +08:00 |
|
