MailUI4Agents

jianf/MailUI4Agents

Fork 0

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	71a3c35610	按 pi 复核改五处：判据的"值/行为"原则、真正的构建门、typecheck 进门、Go 判据零匹配、迁移归属 pi 用反例与变异逐条点了五处，全部先跑变异再改（结论都写在原地）。 ## 1 判据③：形状正则已删（它永远差一个反例）实测 pi 的反例 —— `const k = PREFIX + accountId; return PREFIX;`（拼了但没返回）—— 对第三版判据仍然全绿：第三版锚的是"函数体里存在这样的表达式"，不是"返回的表达式"。三版的骗法各一个（签名里的参数 / 提了一下没用 / 拼了没返回），都在判"源码里有没有那个形状"，而缺陷是"算出来的值对不对" ⇒ 权威交给行为判据（`test/stores/background.test.ts` 直接断言 `storageKey('a') !== storageKey('b')`、`=== 'agentmail.background.acct-a'`、不退回全局键），正则那条删掉并把反例写在原地（否则下一个人会好心加回来）。保留"键必须来自 storageKey()"那条：那是来源约束，不是值对不对，正则在这里合适。鸿蒙侧只能静态判（`.ets` 本机没有运行时），已把这条限制写进判据说明。推广进规范：CRITERIA.md §6.7 + run-all 自检关键词（10 → 11）。 ## 2 真正的门：`scripts/release-linux.sh` - 实测 pi 提的变异：`touch dist/index.html` 时 stamp 判据是绿的 —— 它抓不到"构建失败但碰过 dist"。 stamp 是探测器（抓"src 改了产物没跟上"），门是喂退出码，两者不互替（§6.7.1）。 - `build:linux` 里没有管道（`&&` 链，退出码本来就传），但那次的哑巴失败是我在命令行手打 `npm run build 2>&1 \| tail -4 && …` 造成的；同时发现它跑的是裸 `vite build`，跳过 `gen:bg`。 - 于是把配方收成 `scripts/release-linux.sh`：`set -euo pipefail` + 走 `npm run build` + 再打包。 - 判据是行为的：注入失败的构建（`AGENTMAIL_BUILD_CMD='exit 7'`）→ 断言退出码非 0 且打包那步没跑（标记文件不存在）。变异：脚本改成 `\|\| true` → 红 ✓。 ## 3 typecheck 进 `npm test` 链 `npm run typecheck` 原本就有，但没人跑。先修掉它唯一的报错（我自己留下的未使用 import），现在干净； `test` = run-all + vitest + typecheck。它恰好检查没被任何测试 import 的文件（vitest 只解析被测到的图）—— 也就是那次 `is not exported by` 的形状。 ## 4 Go 源码判据：零匹配 / 读不懂都要红改成三分：切不出函数体 → 红；字段在但值不是字面量 → 报「判据读不懂」（变异：`BgDim: defaultDim` → 红 ✓）；字段不在 → 红。静默放行是这类判据最危险的失败方式。措辞更正：这条核对的是"与这份服务端源码的契约"，不是"在跑的服务端二进制是 12/4" （与"dist 是产物"同构）；文档同步改。 ## 5 迁移归属：定向做不到，就把"不可恢复"降级成"可恢复" 查实：`accountStore` 的 `activeId` 是派生视图状态、不落盘（`persist(accounts)` 只存数组），所以本机没有"上次活跃账号"标记可定向 —— 旧值的作者事后无法还原，定向迁移在原理上做不到。升级前用 B、升级后先登录 A ⇒ A 接管 B 的外观，一次性错档，触发条件就这一条。两件能做的都做了：写了回读校验（写不进去就不删旧键，避免净损失；变异：改成先删后写 → 2 条红 ✓）、删前另存 `agentmail.background.legacy.bak`（只写不读 ⇒ 不引入新的继承源，判据钉"只写不读"）。 §7.12 把本地这半与显形方式写进同一行。 ## 验证 `npm test` 退出码 0：14 个判据文件全绿 + vitest 265 通过（+2 迁移行为测试）+ typecheck 干净； `hvigorw assembleHap` BUILD SUCCESSFUL；安装包经新脚本重打（dist 与包同批）。	2026-09-14 15:41:52 +08:00
JianFeeeee	dbdb2f5039	跨端: 修打包坑（构建失败被管道吞掉）+ dist 新鲜度判据；判据从"窗口式"改成同表达式接手 pi 的 WebUI 开项途中踩到三个坑，都已修好并配判据（承接 e94313f）。 ## 坑 1：`npm run build 2>&1 \| tail -4 && electron-builder …` 吞掉构建失败 pipeline 的退出码是 `tail` 的 → 构建失败、`&&` 照样往下走、electron-builder 拿旧的 dist 打了新包。而所有判据都是绿的： - vitest 绿（见坑 2）；packaging 绿（它比 dist vs 安装包，两边都是旧的，自然一致）。新增判据：dist 必须比 src 新（build-stamp）。变异：`touch` 一个 src 文件 → 红；重新 `npm run build` → 绿。错误信息写明"注意别把它的退出码丢在管道里"。已重构建 + 重打包（deb 与 app.asar 同批，15:19）。 ## 坑 2：测试通过 ≠ 能打包真正的失败：`AGGREGATE_ID` / `isUsableAccount` 被我当成 `accountStore` 的导出（它们住在 `lib/accounts.ts`）。vitest 263 条全绿，生产构建直接报 `"AGGREGATE_ID" is not exported by "src/stores/accountStore.ts"` —— 测试运行时对缺的具名导出是宽容的（拿到 undefined）。生产构建是一道独立的门。 ## 坑 3：判据写成"窗口式"，被自己的变异测试抓住两次 `appearance-defaults` 的"取键函数必须把账号拼进去"： 1. 第一版从 `export function` 切到 `}` → 参数表里的 accountId 满足了正则，把实现退回全局键仍然全绿（假判据！）； 2. 第二版只取函数体 → `return accountId ? PREFIX : PREFIX;`（提了一下没用）又骗过去； 3. 第三版要求同一个表达式里既有常量又有账号的插值/拼接：两种退化都红，合法的 `PREFIX + accountId` 写法仍然绿。三种变异都验过（红/红/绿），还原后基线绿。 ## 文档 §7.12 两行改为「已修」并写明依据（默认值＝服务端契约；缓存键差异已消除，旧全局键只作一次性迁移源）；新增 §7.20 记这三个坑与推论（产物是 gitignore 的， "源码修好"≠"用户手上那个包修好"）。 ## 验证 `npm test` 退出码 0（13 个判据文件全绿 + vitest 263 passed）； `hvigorw assembleHap` BUILD SUCCESSFUL；`npm run build` + electron-builder 均 exit 0。	2026-09-14 15:20:30 +08:00
JianFeeeee	e94313f66a	跨端: 接手 pi 的两个 WebUI 开项——默认值统一到服务端契约 12/4；缓存键按账号（含一次性迁移） pi 问"这两个开项谁执行"，我接了（他那边无 shell，我这边改过 WebUI）。两件都是他读源码读出来的实缺陷。 ## 1 默认值：不是审美，是服务端契约（pi 更正了自己上一封） `server/internal/models/models.go` 的 `DefaultAppearance()` 明写 `BgDim: 12, BgBlur: 4`，且注释宣称"与客户端 backgroundStore / themeStore 的默认值一致"——而 WebUI 的 `backgroundStore.ts` 是 `dim: 24, blur: 8`，那句注释是假的；`lib/appearance.ts` 的 `clamp(..., 12, 4)` 又是另一套。同一份代码里两个"默认值"，走哪条路就落哪个数。后果不是"两处代码不一样"这么轻：服务端"没有记录"时客户端以本地为准推上去，于是新账号的初始外观由第一个同步它的客户端决定（先 WebUI 登录存 24/8，先鸿蒙登录存 12/4）——同一个账号，压暗强度取决于谁先到。改法：新增 `src/lib/appearanceDefaults.ts` 作为唯一来源（DEFAULT_DIM/DEFAULT_BLUR/ 上限），`backgroundStore` 与 `lib/appearance` 都引用它，字面量全部消失。 ## 2 缓存键按账号（含旧全局键的一次性迁移） `STORAGE_KEY = 'agentmail.background'` → `storageKey(accountId)` = 前缀 + 账号；写盘只走 `storageKey()`；旧全局键只作为迁移源：当前账号首次读到它时接管并存进自己的键，然后立刻删除（否则下一个账号继续从它"继承"，等于把刚修的缺陷留在原地）；未登录时不迁移（旧值不能送给一个还不知道是谁的账号）。配套顺序：`appearanceSync` 在账号切换时先 `reloadForAccount()` 再 `pull()` —— 服务端"没有记录"时 `pull()` 会"以本地为准推上去"，那时"本地"必须已经是本账号的值。 ## 3 判据（新增第 13 个判据文件 appearance-defaults） `test/appearance-defaults.test.mjs`：去 Go 源码里读 `DefaultAppearance()` 的四个字段，再比对三处（WebUI 常量、store 的 DEFAULT_BACKGROUND 不许有字面量、鸿蒙 Appearance 的字段默认值）；另两条钉"键按账号、不许退回全局键、旧键必须被删除"与"重读在 pull 之前"。这样服务端那句注释是可核对的，不是承诺。顺带更正：`Wallpaper.ts` 里"WebUI 默认 24"的注释已过时 → 改 12 并写明缘由； `harmony-appearance` 里"WebUI 是全局键"的前提失效 → 改为断言两端都按账号分键。 ## 验证 `npm test` 退出码 0（13 个判据文件全绿 + vitest 263 passed，原 258 + 新增 5 条行为测试：键隔离、迁移一次并删除、未登录不迁移、默认值=12/4）。	2026-09-14 15:17:01 +08:00

Author

SHA1

Message

Date

JianFeeeee

71a3c35610

按 pi 复核改五处：判据的"值/行为"原则、真正的构建门、typecheck 进门、Go 判据零匹配、迁移归属

pi 用反例与变异逐条点了五处，全部**先跑变异再改**（结论都写在原地）。

## 1 判据③：形状正则已删（它永远差一个反例）

实测 pi 的反例 —— `const k = PREFIX + accountId; return PREFIX;`（拼了但没返回）——
对第三版判据**仍然全绿**：第三版锚的是"**函数体里存在**这样的表达式"，不是"**返回的**表达式"。
三版的骗法各一个（签名里的参数 / 提了一下没用 / 拼了没返回），都在判"源码里有没有那个形状"，
而缺陷是"算出来的值对不对" ⇒ **权威交给行为判据**（`test/stores/background.test.ts` 直接断言
`storageKey('a') !== storageKey('b')`、`=== 'agentmail.background.acct-a'`、不退回全局键），
正则那条删掉并把反例写在原地（否则下一个人会好心加回来）。
保留"键必须来自 storageKey()"那条：那是**来源**约束，不是值对不对，正则在这里合适。
鸿蒙侧只能静态判（`.ets` 本机没有运行时），已把这条限制写进判据说明。
推广进规范：CRITERIA.md §6.7 + run-all 自检关键词（10 → 11）。

## 2 真正的门：`scripts/release-linux.sh`

- 实测 pi 提的变异：**`touch dist/index.html` 时 stamp 判据是绿的** —— 它抓不到"构建失败但碰过 dist"。
  stamp 是**探测器**（抓"src 改了产物没跟上"），门是**喂退出码**，两者不互替（§6.7.1）。
- `build:linux` 里**没有管道**（`&&` 链，退出码本来就传），但那次的哑巴失败是我在命令行手打
  `npm run build 2>&1 | tail -4 && …` 造成的；同时发现它跑的是**裸 `vite build`，跳过 `gen:bg`**。
- 于是把配方收成 `scripts/release-linux.sh`：`set -euo pipefail` + 走 `npm run build` + 再打包。
- 判据是**行为**的：注入失败的构建（`AGENTMAIL_BUILD_CMD='exit 7'`）→ 断言退出码非 0
  **且打包那步没跑**（标记文件不存在）。变异：脚本改成 `|| true` → 红 ✓。

## 3 typecheck 进 `npm test` 链

`npm run typecheck` 原本就有，但没人跑。先修掉它唯一的报错（我自己留下的未使用 import），现在干净；
`test` = run-all + vitest + typecheck。它恰好检查**没被任何测试 import 的文件**（vitest 只解析被测到的图）——
也就是那次 `is not exported by` 的形状。

## 4 Go 源码判据：零匹配 / 读不懂 都要红

改成三分：切不出函数体 → 红；字段在但值不是字面量 → 报「**判据读不懂**」（变异：`BgDim: defaultDim` → 红 ✓）；
字段不在 → 红。静默放行是这类判据最危险的失败方式。
**措辞更正**：这条核对的是"与**这份服务端源码**的契约"，不是"在跑的服务端二进制是 12/4"
（与"dist 是产物"同构）；文档同步改。

## 5 迁移归属：定向做不到，就把"不可恢复"降级成"可恢复"

查实：`accountStore` 的 `activeId` 是**派生视图状态、不落盘**（`persist(accounts)` 只存数组），
所以**本机没有"上次活跃账号"标记可定向** —— 旧值的作者事后无法还原，定向迁移在原理上做不到。
升级前用 B、升级后先登录 A ⇒ A 接管 B 的外观，**一次性错档**，触发条件就这一条。
两件能做的都做了：**写了回读校验**（写不进去就不删旧键，避免净损失；变异：改成先删后写 → 2 条红 ✓）、
**删前另存** `agentmail.background.legacy.bak`（只写不读 ⇒ 不引入新的继承源，判据钉"只写不读"）。
§7.12 把本地这半与显形方式写进同一行。

## 验证

`npm test` 退出码 0：14 个判据文件全绿 + vitest **265** 通过（+2 迁移行为测试）+ typecheck 干净；
`hvigorw assembleHap` BUILD SUCCESSFUL；安装包经新脚本重打（dist 与包同批）。

2026-09-14 15:41:52 +08:00

JianFeeeee

dbdb2f5039

跨端: 修打包坑（构建失败被管道吞掉）+ dist 新鲜度判据；判据从"窗口式"改成同表达式

接手 pi 的 WebUI 开项途中踩到三个坑，都已修好并配判据（承接 e94313f）。

## 坑 1：`npm run build 2>&1 | tail -4 && electron-builder …` 吞掉构建失败

pipeline 的退出码是 `tail` 的 → 构建失败、`&&` 照样往下走、electron-builder
**拿旧的 dist 打了新包**。而所有判据都是绿的：
- vitest 绿（见坑 2）；packaging 绿（它比 dist vs 安装包，两边都是旧的，自然一致）。

新增判据：**dist 必须比 src 新**（build-stamp）。变异：`touch` 一个 src 文件 → 红；
重新 `npm run build` → 绿。错误信息写明"注意别把它的退出码丢在管道里"。
已重构建 + 重打包（deb 与 app.asar 同批，15:19）。

## 坑 2：测试通过 ≠ 能打包

真正的失败：`AGGREGATE_ID` / `isUsableAccount` 被我当成 `accountStore` 的导出
（它们住在 `lib/accounts.ts`）。vitest 263 条全绿，生产构建直接报
`"AGGREGATE_ID" is not exported by "src/stores/accountStore.ts"` ——
测试运行时对缺的具名导出是宽容的（拿到 undefined）。**生产构建是一道独立的门。**

## 坑 3：判据写成"窗口式"，被自己的变异测试抓住两次

`appearance-defaults` 的"取键函数必须把账号拼进去"：
1. 第一版从 `export function` 切到 `}` → **参数表里的 accountId 满足了正则**，
   把实现退回全局键仍然全绿（假判据！）；
2. 第二版只取函数体 → `return accountId ? PREFIX : PREFIX;`（提了一下没用）又骗过去；
3. 第三版要求**同一个表达式里既有常量又有账号的插值/拼接**：
   两种退化都红，合法的 `PREFIX + accountId` 写法仍然绿。

三种变异都验过（红/红/绿），还原后基线绿。

## 文档

§7.12 两行改为「已修」并写明依据（默认值＝服务端契约；缓存键差异已消除，旧全局键
只作一次性迁移源）；新增 §7.20 记这三个坑与推论（产物是 gitignore 的，
"源码修好"≠"用户手上那个包修好"）。

## 验证

`npm test` 退出码 0（13 个判据文件全绿 + vitest 263 passed）；
`hvigorw assembleHap` BUILD SUCCESSFUL；`npm run build` + electron-builder 均 exit 0。

2026-09-14 15:20:30 +08:00

JianFeeeee

e94313f66a

跨端: 接手 pi 的两个 WebUI 开项——默认值统一到服务端契约 12/4；缓存键按账号（含一次性迁移）

pi 问"这两个开项谁执行"，我接了（他那边无 shell，我这边改过 WebUI）。两件都是他读源码读出来的实缺陷。

## 1 默认值：不是审美，是**服务端契约**（pi 更正了自己上一封）

`server/internal/models/models.go` 的 `DefaultAppearance()` 明写 `BgDim: 12, BgBlur: 4`，
且注释宣称"与客户端 backgroundStore / themeStore 的默认值一致"——而 WebUI 的
`backgroundStore.ts` 是 `dim: 24, blur: 8`，**那句注释是假的**；`lib/appearance.ts`
的 `clamp(..., 12, 4)` 又是另一套。**同一份代码里两个"默认值"**，走哪条路就落哪个数。

后果不是"两处代码不一样"这么轻：服务端"没有记录"时客户端以本地为准推上去，
于是**新账号的初始外观由第一个同步它的客户端决定**（先 WebUI 登录存 24/8，
先鸿蒙登录存 12/4）——同一个账号，压暗强度取决于谁先到。

改法：新增 `src/lib/appearanceDefaults.ts` 作为**唯一来源**（DEFAULT_DIM/DEFAULT_BLUR/
上限），`backgroundStore` 与 `lib/appearance` 都引用它，字面量全部消失。

## 2 缓存键按账号（含旧全局键的一次性迁移）

`STORAGE_KEY = 'agentmail.background'` → `storageKey(accountId)` = 前缀 + 账号；
写盘只走 `storageKey()`；旧全局键**只作为迁移源**：当前账号首次读到它时接管并存进自己的键，
然后**立刻删除**（否则下一个账号继续从它"继承"，等于把刚修的缺陷留在原地）；
未登录时不迁移（旧值不能送给一个还不知道是谁的账号）。

配套顺序：`appearanceSync` 在账号切换时**先 `reloadForAccount()` 再 `pull()`** ——
服务端"没有记录"时 `pull()` 会"以本地为准推上去"，那时"本地"必须已经是本账号的值。

## 3 判据（新增第 13 个判据文件 appearance-defaults）

`test/appearance-defaults.test.mjs`：**去 Go 源码里读** `DefaultAppearance()` 的四个字段，
再比对三处（WebUI 常量、store 的 DEFAULT_BACKGROUND 不许有字面量、鸿蒙 Appearance 的字段默认值）；
另两条钉"键按账号、不许退回全局键、旧键必须被删除"与"重读在 pull 之前"。
这样服务端那句注释是**可核对**的，不是承诺。

顺带更正：`Wallpaper.ts` 里"WebUI 默认 24"的注释已过时 → 改 12 并写明缘由；
`harmony-appearance` 里"WebUI 是全局键"的前提失效 → 改为断言两端都按账号分键。

## 验证

`npm test` 退出码 0（13 个判据文件全绿 + vitest 263 passed，原 258 + 新增 5 条行为测试：
键隔离、迁移一次并删除、未登录不迁移、默认值=12/4）。

2026-09-14 15:17:01 +08:00

3 Commits