Commit Graph

3 Commits

Author SHA1 Message Date
8390890646 跨端: feat(对齐): 参照物版本登记(CalendarView.tsx @d78f19f,变了即红)+ 圆角按语义配对(数值来源不同另行登记)
pi 2026-09-14 骨架开工前两件。

1. **对齐参照物要有版本号**:WebUI `CalendarView.tsx` 可能同时在动(gui-lab 有未合入改动),
   照工作副本画完之后参照物一变,这版就成了"照一份没人认领的草案对齐的",而**没人能判它对不对**。
   新增 `docs/ALIGN-REFS.json`(blob 哈希 + 登记于哪个 commit + "以哪次为准")
   + 判据 `test/align-refs.test.mjs`:哈希变了即红,报错按 §14 写明
   「正确修法 = 读差异→判断骨架要不要改→再更新登记」与
   「最常见的错误修法 = 把新哈希抄进去(那是把闸门降级成状态记录)」。变异确认会红。
   当前登记:`d78f19f`「日历页面补上圆角」,工作副本干净 —— 若另有未合入的,合入后再对一次。

2. **圆角必须走令牌,且跨端按语义配对**:鸿蒙侧已有 `Theme.ets:105/107` 的
   `radiusCard`/`radiusControl`(**系统**资源),WebUI 是 `--radius-card: 0.875rem` /
   `--radius-control: 0.5rem`。⇒ 端**语义对齐、数值来源不同**,所以登记写成"按语义配对",
   并且判据要求每条都写明"按语义还是按数值"(否则下一个人会直接去比数字)。
   数值差异本身按形态差异进余额:`radius-card-numeric-divergence`(等设备并排看再决定以谁为准)。
   鸿蒙侧不许把 14 / 0.875 抄成裸数字 —— 与当初 14 处 Material 调色板清零同一形态,量纲换成长度。
2026-09-14 17:46:20 +08:00
69b1887eae chore(deploy): 清理部署残留(1.0GB)+ 把清理写成可复跑脚本
用户说「清理一下」。实测 /opt/agentmail 累计 1.3GB:
- 网关旧二进制 33 份 × 24MB ≈ 790MB(每次 redeploy 留一份,从 09-05 起没清过)
- 插件快照:opencode 6 份 339MB、dsh 7 份 195MB、zcode 16 份、pi 9 份
- /tmp 里的部署前数据库备份 10 份(tmpfs,占内存)

新增 `deploy/prune-deploy-artifacts.sh`(可复跑,不手敲 rm),两条硬规矩:
① **保留回滚窗口**:网关留最新 3 份、每个插件留最新 3 份快照,`current` 永远保留
(发布纪律要求有回滚目标,所以不是全清);
② ★ **绝不删正在使用的快照**:扫 /proc 的 cmdline 与 cwd,命中就跳过。

执行结果:**/opt/agentmail 1305MB → 302MB(释放 1003MB)**,7 个服务全部 active,
`current` 指向未变,`check-deploy-drift` 仍报「四个宿主都在跑当前代码」。

## 过程中的一处自纠

"在用"闸门第一版有**自我匹配**缺陷:我的测试命令把路径写在命令行里,于是扫 /proc 时
扫到了自己 ⇒ 对不存在的路径也判"在用"(与 `pkill -f` 杀掉自己那条命令同一类)。
已改为排除本进程及其祖先链,并**换正确方式重测**(路径从文件读、不进 cmdline):
在用快照判"在用" ✓、不存在的路径不误判 ✓ —— 判据两侧都验过才敢执行删除。

文档:docs/DEV-TOOLING.md 记了用法与那两条规矩。
2026-09-14 08:43:54 +08:00
33e44074e7 fix(tooling): pi-lens 的项目防护其实一直没生效(JSON 里带注释 → 整份被忽略)
## 现场

跑 `pi --help` 时有一行不起眼的警告:

    [pi-lens] ignoring invalid project config …/.pi-lens.json:
    Expected double-quoted property name in JSON at position 60

`.pi-lens.json` 是 `d50c55d` 专门加的项目级防护(关掉 pi-lens 的格式化与
autofix),但它的说明写成了 `//` 注释 —— 读 pi-lens 的源码确认:

    PROJECT_CONFIG_BASENAMES = ['.pi-lens.json', 'pi-lens.json'];  // 没有 .jsonc
    raw = JSON.parse(text);                                        // 不去注释
    // 解析失败 → 打一行警告,然后**整份忽略**

所以「已经关掉了」这个结论是**错的**,防护从落地那天起就没生效过。
而它要防的是两次已发生的真实损失:一次是 `19a3161` 把约 7000 行 biome 重排
扫进功能提交(无法审查、还掩盖了一处删行),一次是 prettier 改坏
`client/electron/index.html` 并打破 `test/theme.test.mjs` 的两条断言。

失败方式是静默的:进程照常跑,只有启动时一行警告 —— 而我正是在
`pi --help` 的输出里才看见它。

## 修

- `.pi-lens.json` 改为**严格 JSON**(只有 `$schema` / `format` / `autofix`;
  `$comment` 也不行 —— pi-lens 校验未知键,会为它刷一条
  「unknown key … ignored」的警告,而噪声会训练人忽略告警)。
- 理由移到 `docs/DEV-TOOLING.md`(含 pi-lens 的源码依据、两次事故、
  以及「为什么不是把格式化器配成本仓库风格」——试过,仍改 17 个文件)。
- `biome.jsonc`(允许注释)里加指针:它只是两道闸中的一道,真正的总开关是
  `.pi-lens.json`,而那份**必须是严格 JSON**。
- 验证:`pi --help` 现在 **0 行** pi-lens 输出;反向对照(故意塞回一行注释)
  会重新出现 `ignoring invalid project config`。

## 顺带:仓库里有一个活的凭据

`scripts/verify-l2.sh` 把**管理员 user key 硬编码**在文件里(`1759666` 起就在
git 历史里)。实测它**仍然有效**(`/auth/me` → 200),属于用户 `jianf`。

- 已改为从 `VERIFY_L2_TOKEN` 或 `/root/gotmp/verify-l2-token.txt`(600)读取,
  两者都没有时**报错退出**(反向对照验过:EXIT=2,不静默跑);
- 跑通一次确认可用(6 通过 0 失败)。

**但删掉当前这行不能把它从历史里拿掉** —— 要真正作废必须轮换那把 key。
这需要你定(它是你账号的密钥,可能还有别的工具在用),见提交后的说明。
2026-09-12 23:49:55 +08:00