Commit Graph

87 Commits

Author SHA1 Message Date
fbdfdcc81d fix(deploy): staging 拷贝失败必须当场 exit 2(这次实测打出了假的 [ OK ])+ 登记同类未堵点
一次在沙箱里跑的 `bash deploy/redeploy-plugin.sh pi`(本意是修生产缺文件)被权限拒绝,
结果暴露出脚本自己的一个假绿:

    mkdir: cannot create directory '…/.20260914-201204.staging': Permission denied
    cp: cannot create directory '…' : Permission denied
      [ OK ] 已拷入 node_modules(生产不借用仓库的依赖)      ← 一个字节都没拷
      [FAIL] staging 里没有入口 src/index.mjs

**一段输出里两个互相矛盾的信号,而且 OK 在前** —— 这正是本仓库反复记录的那个病
("从失败里产出一份看着正常的报告"),这次是部署脚本自己得上了。

改动:`mkdir`/`cp` 当场判失败并按约定 exit 2(环境/权限问题,不是检查问题);
`node_modules` 那一份**拷失败就不再打 OK**(依赖进不了 staging 会在重启时才炸,
而那时旧版已经被换掉了)。实测同一路径:现在**立刻** exit 2、零个假 `[ OK ]`。

成功路径未受影响(脚本其余部分与 `[ OK ]`/`[FAIL]` 约定不变)。

`docs/DEBTS.json` 登记同类未堵点 `redeploy-script-unguarded-steps`:
`deploy/redeploy-gateway.sh:84` 的 `run "cp -r …"` 无守卫,而该脚本只有
`set -uo pipefail`(**无 `-e`**)、`run()` 内部 `eval` 的失败既不中断也不被调用点接收
⇒ 前端产物没拷进去也继续往下走。**没有当场改那个文件**:另一条会话正在改它,
改它等于把冲突塞给一条我看不见的路径(`install.sh` 已有 `set -euo pipefail`,无需处理)。
登记的 `due` 就是"下次改任一 deploy 脚本时"。

验证:`npm test` 463/463、`check-shared-libs.sh` exit 0、`--self-check` 全过、`bash -n` OK。
2026-09-14 20:13:57 +08:00
d616582e96 fix: 回滚 user-question.js 那一搬(它把 check-shared-libs 打红两处),并把 drift 的非运行时差异摘出来
pi 逐处对文件后指出:我按"本平台不可达 ⇒ 搬去 test/lib/"把 `lib/user-question.js`
搬走,打红了 `deploy/check-shared-libs.sh` 两处(实测确认,脚本真退出码 1):

    共用模块缺失:plugins/pi-mail-bridge/lib/user-question.js
    共用测试已分叉:test/user-question.test.mjs(opencode vs pi)

根因不是取舍而是口径:**`lib/` 上挂着两条方向相反的不变量** ——
① 共用模块四方逐字节同源(`check-shared-libs.sh`,连相对路径一起钉);
② 本平台生产可达(我新加的规则)。而 `user-question.js` **是 dsh 桥的生产代码**
(`plugins/dsh-mail-bridge/src/index.ts` 引用它)⇒ 两条必然冲突。
**`lib/` 首先是四桥共用命名空间,其次才是"本平台可达"**;可达性只能当**报告**,
不能当搬家判据。教训的形状:**一条新判据上线时,先找它可能与哪些既有不变量冲突** ——
我只看⻅了自己那条。

改动:
- `user-question.js` 与它的测试回到 `lib/`、`test/`(路径也与 dsh 侧一致),
  两边逐字节相同已复验;`check-shared-libs.sh` 退出码 0。
- `reach.mjs` 增加 `sharedLibNames()`:直接从 `check-shared-libs.sh` 的 `ALL_LIBS`
  读共用清单做豁免(不手抄常量),并把"进快照但本平台不可达"降级为**报告**。
- `layout-boundaries.test.mjs` 增加回归判据:共用模块必须留在 `lib/`、
  测试相对路径与 dsh 一致、两侧逐字节相同。
- 删掉 `reach.mjs` / `docs/DEV-TOOLING.md` 里那句**无据的机制说明**
  ("user-question 走前缀动态 import"):`localRefs` 的三条正则只认引号字面量,
  对模板字面量形状是**盲的** ⇒ 那句若为真,搬走的就是生产代码而两条判据都会绿。
  pi 读了 `src/` 下九个文件都找不到引用,我也确认是记忆偏差;理由改用 `addressing.js`
  (传递可达、`src` 直接引用数为 0)—— 它已足够证明"直接引用数不是可达性"。

顺带按 pi 的第二条建议:`deploy/check-deploy-drift.mjs` 判据 ① 把
**非运行时差异**摘出来(`jsonTestOnlyChange`,只豁免 `scripts.test` 一类字段,
只对"两边都在、仅内容不同"的文件生效)。理由:一条**永远黄、没人打算为它动手**的判据
唯一的下场是被学会忽略,那时真正的运行时漂移会被一起忽略。
⚠️ 摘的条件很窄 —— **把运行时差异误判成非运行时比恒黄更坏(那是假绿)**,
所以 `main`/`start`/`dependencies` 变了、或解析不了,一律仍算运行时;
纯函数加了六个反/正样本的判据(含三个"必须算运行时"的)。

(该文件同时有另一条会话的改动,未提交、我未触碰;本次只加了我这一段。)

验证:`npm test` 463/463;`check-shared-libs.sh` 退出码 0;`--self-check` 18 条全过。
2026-09-14 20:11:58 +08:00
6b1cca0fe4 docs(dev-tooling): 加一条提交纪律 —— 多 agent 共用工作区,提交前先看 git status 里有没有别人的文件
这个工作区是多条会话共用的:2026-09-14 20:02~20:04 另一条会话正在改
deploy/install.sh、deploy/prune-deploy-artifacts.sh、deploy/redeploy-gateway.sh
(-trimpath 那组加固),而我同时在同一个仓库里连续提交。
`git add -A` 会把别人没写完、没审过的改动一起做进我的提交,且从 git log 看不出归属。
规矩:显式列出要提交的路径;提交信息里不把别人的改动算成自己的。

(本次三次 pi-bridge 提交都是显式路径,事后用 git show --stat 核对过没有混入。)
2026-09-14 20:05:15 +08:00
e49f0a8f6a docs(dev-tooling): 写点三处**不同的入口假设**、过宽过窄、因果无关判据、锚点、lib/ 边界 + 一条被自己纠正的观察
按 pi 的两条建议补:

1. "漏过三次"改成**列出三次的位置与各自不同的入口假设**(他指出的问题:原写法
   会让读者以为"同一处错了三次"):① `writeSession` 只包 `writeFileSync`;
   ② `mk()` 的 `mkdtempSync` 在 try 之外;③ 兜底层放在 `main()` 而 `selfCheck()` 是导出的。
   三次都概括成一句:**"我以为的入口/哪一行"决定了覆盖范围**。
2. "判据只能发现已知成因"作为实例加进同节,并配对写出**因果无关**的运行期判据
   (`test/lib/run-suite.mjs` 数结果行 / 跨文件重名实测不被拦)。

新补四条(本轮新踩出来的):
- **判据过宽和过窄都是坏的**(那条 import 判据自己同时踩过两边);
- **判据的锚点必须与结论一一对应**(重名检查锚结果行 vs 锚"名字出现过",
  噪声与效应恰好同阶 ⇒ 4 看起来还能解释);
- **`lib/` 与 `test/lib/` 的边界**(部署脚本是 `cp -a` + `rm -rf test`,
  没有 `EXCLUDE_DIRS` 这种变量;★ 别写成"被 src/ 直接 import"—— 直接引用数不是可达性);
- **附一节"被自己的结论半路纠正的观察"**:那条 `result IS NULL` 的挂起请求看着像
  授权链缺口,实际是网关按设计处理的(`PermissionWaitWindow = 10min` + 推导出的
  "失效时刻")。教训写成"先查完'是否已由另一层按设计处理掉'再下结论"——
  这类误判会以"我发现了新问题"的语气传播,比沉默更贵。
2026-09-14 20:00:52 +08:00
d735e674e1 docs(dev-tooling): 判据纪律那节 —— 三种"看起来验过了"的失效形态 + 变异纪律 + 两条实现纪律
pi 复核后提出的收尾:跨文件的教训现在没有容器(实证散在三个文件的头注释里)。
先 `ls docs/` 看过:`docs/DEV-TOOLING.md` 已经有"三条判据,以及它们各自防的那个错"
那一节,主题完全相同 —— 所以**并进去而不是新开一篇**(这是 pi 明确要求的形状)。

写的是**可迁移**的那部分,实证不复述、只给索引:

- 三种失效形态:**钉装饰**(断言落在注释上)、**分支退化**(绑在会变的环境上)、
  **跑不到的分支**(断言在、区分力不在 —— 短路是无声的,比退化更狠);
- 变异纪律 5 条:先证明能还原再注入、只对已干净提交的文件做、还原路径不得依赖被测资源、
  判据不得用被测物证明自己、别只看过滤后的输出(也**不要**为此引入手抄的期望数常量);
- 两条实现纪律:测试文件之间不许互相 import(会二次注册整套用例,实测 475→459);
  写点覆盖范围不得取决于入口(这条在这套代码里被漏过三次);
  以及"判据过宽和过窄都是坏的"—— 那条"测试文件互相引用"判据自己同时踩过两边。
- 索引指出:`check-deploy-drift.mjs` 的运行输出**就是**部署状态的判据来源,
  **不要**抄成哈希清单往外发(发给 jianf 的那份在两次提交后就作废了)。
2026-09-14 19:52:41 +08:00
pi
94ba4b9c58 跨端: 鸿蒙端功能同步第一步——日历(只读月视图)上架,入口进底部导航
用户:「要给鸿蒙端做功能同步」。按 API 面盘点(WebUI 62 个 API 函数 vs 鸿蒙 38 个),
最大的用户面缺口是**日历**:纯逻辑(model/Calendar.ts)与判据早就在,一直没页面。

新增:
- api/CalendarApi.ets:GET /calendar/events?from=&to=(与 WebUI 同参;区间按**网格**取,
  不是月首月末 —— 首尾格子会显示邻月,只查当月会让那些格子永远空着)
- pages/CalendarPage.ets:月网格(翻月/回今天)、点某天看当天日程、事件点、今天/选中两态、
  加载失败说出来。**没做**:写侧(增删改)、农历重复、.ics、滑动翻页 —— 逐条写在文件头
- model/Calendar.ts:补 localIsoOf / hhmmAtOffset / deviceOffsetMinutes(偏移是入参 ⇒ 三时区可真跑)
- model/Models.ets:CalendarEvent / CalendarListResponse(字段对齐服务端 JSON)
- NavItems:加「日历」,底部成为 通信/日历/联系人 三项(与 WebUI 同序)
- MainPage:日历是**常驻 pane**(visibility 控制),首次可见才拉数据;today 走
  @Prop @Watch(visible) 在 pane 变可见时重算 ⇒ 结算欠账 calendar-today-recompute
  (DEBTS 15 笔 → 14 笔,余额里不再计这一笔)

判据:harmony-calendar 新增 6 条(网格/表头同源、事件归日走 localIsoOf、三时区钟点、
today 重算路径、翻月走 addMonths、变异自检);harmony-nav ② 分派与 ④ 让位跟着改成结构性判据
(④ 原来那个 400 字符窗口一加 pane 就红 —— 窗口式判据的又一次现身);harmony-logic 两处
「只剩两个平级页签」跟着改成三项。

真机实测(harmony-emu + hvigorw assembleHap + hdc install + uitest click + dumpLayout):
9 月网格星期对齐(周一起始,2026-09-01 落在「二」列)、事件点恰好在有日程的那 6 天
(11/17/18/24/25/30)、点 09-17 列出当天两条日程且钟点是本地时间(DB 里 02:20Z/08:30Z
→ 界面 10:20/16:30)。
2026-09-14 18:38:51 +08:00
12294835da fix(余额): 圆角差异条目补两侧数值 + 策略现在就定(设备只做验证、不做决策)
pi 2026-09-14 两条。

1. **别让设备当"以谁为准"的决策者**:这个工作区起不了模拟器,把决策挂在设备上
   就是一笔**永远不还**的账。观测能告的只是"并排看是否感知不一致",而策略现在就能写 ——
   已写进条目(提案,待人追认):**语义配对成立 ⇒ 数值按两端各自成立(WebUI 的 rem 基准
   vs 鸿蒙 vp/系统档),默认以 WebUI 为准**;只有鸿蒙平台规范明确要求系统档时才反向。
   设备**只做验证,不做决策**。`kind` 从 env 改回 **scope**:这里等的是"有人拍一下",
   不是"环境到位";并写明**实现者不能自己拍**(同 `unknown-preset-approval`)。

2. **补两个数**(没有数就既不能裁定也不能验证):
   · WebUI:`0.875rem`=14px / `0.5rem`=8px;
   · 鸿蒙:**本工作区读不到数值** —— `toolchains/id_defined.json` 该条目只有 name/type,
     SDK 的 `ets-loader/sysResource.js` 只有**资源 ID 125829709 / 125829702**,
     实体值在**系统资源包**里(编译进 resources.index / 随设备)。
   这个"只能读到 ID、读不到值"的事实写进条目,免得下一个人以为去查一下就有。
2026-09-14 17:52:15 +08:00
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
6fc8099b33 跨端: feat(日历): today 不许跨调用残留(常驻 pane 跨零点);扫描口径去注释+去字符串现在就定
pi 2026-09-14 骨架前最后两条。

1. **`today` 必须"显示时求值"**:顶层是「通信 / 日历 / 联系人」三个平级 pane,日历**常驻**,
   而 `today` 是唯一随时间变的输入。建页取一次 ⇒ 跨午夜后标记停在昨天,**判据全绿**
   (模型没错,是喂进去的值过期了)—— 与 `Calendar.ts` 防的"上次渲染残留"同一件事,
   只是残留在**调用侧**。
   · 纯逻辑侧判据(新增第 10 条):连续两次不同输入各自独立(不许跨调用残留)、
     推进一天后值必须变、**不传就不许有今天**(不许内部兜底取系统时间 —— 那正是"取一次"的写法);
   · 调用侧义务(pane 变可见时重算,不许只在 aboutToAppear)进余额:
     `calendar-today-recompute`(kind=scope),到期前提写明"骨架写完后立刻"。

2. **`code()` 去注释、不去字符串**:任何只是**提到**被禁写法的字符串会被自己判红。
   两条路("报错文案不引被禁模式" vs "只在表达式位置匹配")现在就定,选后者:
   先**整段去掉字符串字面量**再匹配 —— "提到"不再误红,"真的用它取日期键"照样红。
   副作用写在旁边(正则近似、非解析器;转义/跨行模板处理不干净 ⇒ 是采样不是完备性证明),
   并写明:**出现同族误红时不许"再改一次扫描口径"把判据往宽里挪**。
2026-09-14 17:44:52 +08:00
e94e4dcd39 跨端: feat(P6): 日历纯逻辑 model/Calendar.ts + 6 条可跑判据(第 1 步的逻辑那一半,不需要设备) 2026-09-14 17:41:43 +08:00
9fd89308ab fix(判据): 自指豁免改成"按次数"登记;标签缩回"已登记词表"并把它自己的盲区登记成欠账
pi 2026-09-14 两点,本质是同一件事:**判据自己的盲区,又成了新的"只写在某处"**。

1. **自指豁免从"整文件放行"改成"登记一个次数"**:整文件放行的后果很具体 ——
   `debt-visibility.test.mjs` 成了唯一一个"可以在里面声明边界而不被抓"的文件,
   而它恰好是定义词表的那个(将来有人在这里写一句真实的「这里没判/已知缺口」,① 不会红)。
   现在把 N=9 当普通登记值:N 处是**词表定义与报错文案**,第 N+1 处就是新边界声明 ⇒ 红。
   变异确认:在本文件里再加一处 ⇒ 红;撤回 ⇒ 绿。
   pi 那句话我照抄进注释:"用自己定义的词表数自己无意义"推出的是"**这 N 处**无意义",
   不是"**这个文件**无意义"。

2. **标签缩回断言范围**(§17 的收法一):判据名从"有边界声明就必须登记"改成
   "用**已登记词表**声明边界的文件,必须在余额里有对应的一笔(词表外的说法不在范围内)"。
   并且**词表键控这个盲区本身按我自己的新规则进了余额**:
   `boundary-vocabulary-incomplete`(已知未覆盖:`TODO`/「这里没判」/「跳过」等同义说法抓不到),
   到期前提是"发现词表外说法时扩词表并登记那一处"。
   —— 这条是被**本判据自己的分支 ③** 逼出来的:它先报"debt-visibility.test.mjs 有边界声明,
   但没有任何一笔余额的 where 指向它"。判据咬到了判据自己身上,正合其意。

余额:`debts=13 (static-only=5==登记 ✓ / other=8 by go-test)`。
2026-09-14 17:39:47 +08:00
d34342b49b feat(判据): §16 本身变成判据 —— 判据目录里的"未覆盖/未验/已知缺口"声明必须在余额里有对应的一笔
pi 2026-09-14:§16 一直是"靠记得问"的纪律,按 §15 它该有判据;这是同一形状的**第五次**,
这次落在规则自己身上。

新判据 `test/debt-visibility.test.mjs`(三支,均已变异验证):

1. **出现次数必须与登记一致**:某文件里新多出一处边界声明 ⇒ 红,
   报错按 §14 写「正确修法(先补一笔余额,再改次数)」与
   「最常见的错误修法(只把数字调大/把声明删掉)」。变异:给 harmony-logic 加一处 ⇒ 红。
2. **每一笔余额必须带到期前提与位置** ⇒ 变异:清空 static-criteria 的 due ⇒ 红
   (「那不是欠账,是"我们知道"」)。
3. **有边界声明的文件必须被某笔余额的 where 引用**(两处挂钩,不是各写各的)。

**自指豁免**(按文件 + 理由):本文件**定义**了那套措辞,用自己定义的词表数自己是无意义的
—— 而且它**第一次跑就把自己抓出来了**(11 处),证明计数是活的,不是走过场。

顺带把 `static-criteria` / `observability-output` 的 `where` 与具体文件挂钩(5 个静态判据文件)。
2026-09-14 17:38:33 +08:00
6eef1fd91c fix(余额): 两条"已知未覆盖的回滚路径"进余额(绿判据的名字在默认路径上不打印)
pi 2026-09-14:这不是新规则,是我自己刚立的 §16 往上递归一层。

- 判据**绿**的时候名字不打印(默认路径只出 `RESULT pass=N fail=0`),
  所以「另两条路未覆盖」这句话写在标签/注释里 = **默认路径上看不见** ——
  正是 §16 要挡的那一类;与 overlay 那条同族:**希望别人知道的边界只存在于源码里**。
- 登记两笔,`where` 明确写「这是**已知未覆盖的回滚路径**,不是未验的运行时性质」
  (两件事不同,不混一格):
  · `nav-dark-route-b-unguarded`:引入深色主题 / 第一次给导航组件加 `dark:` 变体时堵;
    堵法按**文件窄豁免**,不许写成「导航目录不许出现 dark:」。
  · `nav-blur-route-c-unguarded`:第一次给导航元素加工具类模糊时堵。

余额:`debts=12 (static-only=5==登记 ✓ / other=7 by go-test)`。
2026-09-14 17:36:54 +08:00
1fcb754b61 fix(判据): 两条反向断言"标签比断言宽"——缩回真实范围并记下三条逃逸路(各注变异确认);overlay 运行期边界进余额
pi 2026-09-14:变异证明的是"我注入的那两条会被抓",不是"回滚会被抓" —— 对。

1. **标签缩回断言的真实范围**(选 pi 的 (a)):两条判据原先叫"导航不得变暗 / 不得自叠模糊",
   实际各只扫了一条路。按 pi 预测的三条逃逸路各注一次变异,**三条全部逃掉**(导航变黑/变模糊,
   判据照样全绿):`.dark .nav-rail{background-color}`(选择器作用域)、组件 `dark:bg-slate-900`
   (Tailwind 产的不是 `.dark{--nav-}`)、组件 `backdrop-blur-lg`(不在那条选择器下)。
   现在名字就是它们真正断言的东西,**未覆盖的路逐条写在注释里**(含变异表),
   并写明要堵时按文件窄豁免写、别一刀切。
   理由:**标签比断言宽的判据,会在它没测的那条路上被回滚时给绿,而人信的是标签。**

2. **overlay 的运行期边界进余额**(`overlay-follows-app-theme`):机制依据(`applyTheme →
   setColorMode`、资源按应用配置解析)我认,但它是**运行期**性质、注释里的"未验"没人判 ——
   按我自己刚立的纪律:只活在注释里的边界 = 没人判的边界。到期前提写死:上设备后翻转
   colorMode,断言遮罩跟着「应用」主题变;证伪则改为从应用主题派生,**不是**回双常量。
2026-09-14 17:35:53 +08:00
9af4fde706 docs(计划): P2a/P2b 归属入册(鸿蒙侧,参照物是 WebUI 已成的形态);产物自证两条报错补"最常见的错误修法"
1. **归属弄反了**(pi 2026-09-14):联系人卡片视图 / 收件箱按会话折叠 / 删平级 tab
   **全在鸿蒙侧落地**;WebUI 的 `ContactPanel.tsx`(列表/卡片两视图)、`lib/mailGroups.ts`
   (按会话折叠)都是**参照物**,WebUI 根本没有平级会话入口。已写进计划文档,
   并写明「收件箱只取 50 封」那件事**不与 P2a 互相阻塞**(它是 WebUI 现存缺陷,单独查)。

2. **§14 落到产物自证这一族**:`build-stamp` / `packaging` 的报错原先只有「正确修法」
   (重构建 / 重打包),补上**最常见的错误修法** —— 别改 `BUILD_INFO.json` 的
   `gitRev`/`srcHash`、别改断言或塞一份手抄 dist:那是把判据废掉。
2026-09-14 17:33:05 +08:00
e35ea479b5 fix(余额): 子集关系打进字符串本身(读到 9≠5 的人不该需要读信才知道为什么);映射欠账加"不许绕过映射"到期前提
pi 2026-09-14 两点。

1. `debts=9(registered) measured_static=5==登记 ✓` 让读的人先看到 9≠5,而
   "本相位只有 static 有权威实测"只写在**信里**、不在那一行里 —— 那一行**没有一个字在判它可读**。
   现在:`debts=9 (static-only=5==登记 ✓ / other=4 by go-test)(…)`。
   理由与 §12 同源:**余额里任何需要靠注释才能读对的地方,就是下一个假绿。**

2. `blurStyleFor` 那笔欠账的到期前提再加一条:**调用点出现时**,判据要同时判
   「调用点不许自己再换算一次 px→档」—— 否则调用点到位、消费侧计数转绿,
   而换算被绕过(直接传算好的档位),映射那条行为判据照样全绿 —— 钉了个没人走的路。
2026-09-14 17:27:14 +08:00
512b3f8f80 fix(更正): 我登记的"不存在映射表"是错的(blurStyleFor 一直在,缺的是调用点);豁免按文件+次数抓出来的
pi 2026-09-14 三条接续,其中 §3 那一条**抓出了我自己的一个错误结论**。

1. **§3 交叉提醒(豁免按"文件 + 次数")→ 直接翻出我漏掉的东西**:
   把 `bgBlur` 的豁免改成计数后,逐处核对出现次数时发现 `model/Appearance.ts` 里
   **有一个 `blurStyleFor(bgBlur)`** —— **px → 系统材质档的映射表早就在那儿**
   (文件注释还写着「判据可以直接跑它」),只是**没有任何调用点**。
   而我先前把"鸿蒙没有消费点"登记成了"**不存在映射表 ⇒ 钉映射判据是假判据**",
   **那是错的**,并且已经写进了两处文档(CRITERIA.md §10、计划文档 §7.12)。
   ⇒ 两处都**更正**了,并写明发现方式(计数机制把它翻出来的)。
   正确的登记:**映射表存在且可判;缺的是调用点** —— 这两件事分开判。

2. **映射表按"它是行为"来钉**(新判据,26/26 绿):分档边界 0/8/20、
   **单调性**(px 变大档次不许倒退)、**NaN 不许落到最厚那一档**(比较全 false 时掉到最后一档
   是最坏方向)。`blurStyleFor` 是纯函数 ⇒ 与 Wallpaper 一样能直接用 node 跑,不需要设备。

3. **§1 痕迹的"输出那条腿"仍无人判 —— 我把它登记成欠账而不是假装钉了**:
   页面层(`MainPage.ets`)有没有真的拿 `presetSubstitutedFrom` 打日志,现在**没有判据**。
   我没有在本轮补上,原因是它要动 `.ets`(按环境约定,写 `.ets` 前要先按 ArkTS 纪律加载规范),
   而 P6 第 1、2 步正好要动那个文件 —— 所以登记成 `docs/DEBTS.json` 的
   `observability-output`(余额 1、到期前提写明"页面接上日志时同时补判据"),
   **不是"未完成"含糊过去**,而是"什么时候还"写清楚了。

4. **§2 §10 那格从"无人类批准"收口成"待批准"**:仍进余额 —— `unknown-preset-approval`,
   到期前提是"有人追认或驳回『未知 id 显示 aurora 而不是空白』这个方向",
   并写明**我作为实现者不能自己追认自己**。

5. 顺手把 pi 那条建议入册(`CRITERIA.md` §14):**登记/清册类判据的报错要同时写
   "正确修法"与"最常见的错误修法"** —— 因为读到红的人第一反应通常是改那个数字。

余额现在一处可见:`RESULT phase=install static=5 debts=9(…) probe=ok`。
2026-09-14 17:20:18 +08:00
d25770ea2f fix(欠账): Skip 进余额且条件必须是测量;豁免按文件+次数;三笔欠账合成一处可读余额
pi 2026-09-14 三条(他接受了我对"恒红=相位错"的反驳,但指出 Skip 带来的两处漏洞)。

1. **Skip 必须进余额、条件必须是测量**:
   - **条件**:跳过与否由 `measureMailStatusDebt` **实测**(详情路径的 status 是否真的
     等于按读者派生),不是常量、不是"我们还没迁完"这种没人会更新的事实;
   - **余额**:`docs/DEBTS.json` 是**唯一登记**,Go 侧判据 `TestDebtLedgerMatchesMeasurement`
     **自己测量**后与登记比对(第一版我让余额由另一条判据写入 ⇒ **排序依赖**,
     Go 同包内按源文件顺序跑,登记那条先跑就读到 0 —— 排序依赖是隐蔽的假绿,已抽成自足函数);
   - **可见性**:`go test` 跑通时**不打印包的输出**,我第一版把余额打在 TestMain 里,
     常态运行一个字都看不见 —— 正是 pi 说的"不显形"。所以常态可见的那份打在
     electron 套件的 RESULT 行:`RESULT phase=install static=5 debts=7
     (static-criteria:5,mails-status-derived:1,gesture-semantics:1) probe=ok`。

2. **豁免从"按文件"改成"按文件 + 次数"**:`migrate.go` 这类比较**上限 2 处**(附理由),
   多一处即红。我在读侧清册上自己修过这个洞,豁免那格却退了一格 —— pi 指出得对。

3. **三笔欠账合成一处**:原先各自表达(`RESULT static=5` / `t.Skip` 无余额 /
   文档里的到期前提无余额),**没有一处能一眼看全**。现在统一登记在 `docs/DEBTS.json`
   (id / 余额 / 到期前提 / 判据位置),两端读同一份:Go 侧比对实测,electron 侧打进 RESULT 行。
   还清那天:登记要跟着清 —— 不清则由 `TestDebtLedgerMatchesMeasurement` 报
   "**欠账已还清**,但登记还记着 N"(还清是可测事件,这正是那条判据存在的意义)。
2026-09-14 17:17:37 +08:00
eeb8f277fd test(mails.status): "正当"落成可判约束(只许比 archived);欠账补一条"还清即转绿"的判据
pi 2026-09-14 的三点接续。

1. **§1「正当」不能只是标注,要是可判的约束**:按文件+计数登记挡得住"新增一处",
   挡不住"**已登记的那一处改变性质**"。已判出来:**任何与 m.status 的比较只允许比
   'archived'**(全局属性),与 'read'/'unread' 比较 ⇒ 红(per-reader 属性必须走 mail_reads)。
   第一次跑就抓到第三处:`migrate.go` 的 `WHERE m.status = 'read'` ×2 —— 它是**回填**,
   职责就是读那个遗留值,所以按文件登记**窄豁免**(allowedCompareExempt,带理由),
   而不是"凡是迁移都放行"。

2. **§2 欠账要有"还清即转绿"的判据**:新增 `mail_status_derived_test.go`,三态形状
   (与套件探针同族)—— 欠账未清 ⇒ `t.Skip` 并写明还欠什么(**不假红也不假绿**);
   还清 ⇒ 开始实跑并断言"详情路径的 status == 按读者派生的值",**转绿即可测事件**;
   迁一半(只改 GetMailByID 漏 GetThread)⇒ 红。
   实测当前状态:`--- SKIP ... 详情路径返回行级 status="read",而按读者派生说 "unread"`。
   **没写成"现在就红"**:恒红的门 = 挂在错误相位的门(CRITERIA.md §11 已为它付过学费)。
   另按他的更正把 `migrate.go` 的理由写准:不是"跑过即结束",而是
   **"全新安装/空库路径必须存在"**(措辞会影响下一个人敢不敢删它)。

3. **§3 (b) 的语义契约补归属**:归属 = dsh(鸿蒙侧实现者),WebUI 侧不需改动;
   落点 = 跨端对齐判据那一族(形状与"预设清单逐项一致"同构,比语义不比数值);
   **如实标注当前未建**及原因(鸿蒙侧还没有日历页/手势代码 ⇒ 此时"两端逐项相同"只有一端存在,
   建出来就是假判据);到期前提 = P6 第 3 步出现手势代码时立即建,此前是**登记的欠账**。
2026-09-14 17:11:36 +08:00
12a45af9ee docs(登记): 哨兵的缺省语义进 §10;版本偏移的可见后果进差异表;"指针可以,断言不行"入册
pi 2026-09-14 的三点接续:

1. **"不存在的 id 当哨兵"这个手法本身是一次缺省语义决策**,我原先只把它当技巧用,
   没登记它的前提。已按他给的形状进 §10:**未知预设 id → 静默替换为 aurora | 方向:宽(静默)
   | 依据:产品决定(背景不该因未知 id 变空白)**。并写明它**不是"给一个安全的空值",
   而是"静默给别人的档"** —— 用户不会看到错误,但会看到别人的档。
   他指出的真实后果也记了(§10.2 + 计划文档差异表):**服务端/WebUI 先加第 7 档、
   鸿蒙还是旧构建时,旧端静默显示 aurora**,用户以为选的是新档;
   **这不是 bug,是批准过的缺省决策的可见后果** —— 不记,将来必被当 bug 报。
   他给出的可选取舍(兜底改成"不属于六档的显式层")我**不改**:代价是未知 id 显示空白,
   与"背景不该变空白"这条产品决定冲突。取舍与理由都写下来了。
   顺带记清一个连带事实:**用真实档当兜底,必然让那一档逃出行为判据**
   (aurora 丢分支不可观测)—— 这条边界已在判据注释里,不假装全覆盖。

2. **WebUI 侧不写"鸿蒙不消费"**(他否掉了我问的那件事):那会把**另一端的实现状态**
   写成**这一端的断言**,而它会过期。规则立成 §13:**注释里可以放指针,不要放断言**;
   断言留在"事实所属的那一端"(鸿蒙侧已写+已登记 §10),另一侧只放指针。
   与"按 id 联接不按相邻配对"、"'与 X 一致'先确认 X 侧有判据"同族。

3. **两处"只写不读"登记到同一处**:鸿蒙 `bgBlur` 与 WebUI `LEGACY_BACKUP_KEY` 都进 §10 表
   (§10.1 说明为什么必须同处:分居两处时审计容易只找到一处就以为找全了)。
   并**如实标注**:他建议的判据形态("登记为只写不读的字段,写侧必须能指出理由与批准人")
   目前只是**文档级约束**,还没有机器判据 —— 要变成"做错会红"得先有一张可扫的字段清册。
2026-09-14 17:09:26 +08:00
b7f624bc45 fix(已读/手势): 读侧也拒绝空读者;mails.status 读者/写者登记成"新增即红";阈值契约显式选 (b)
pi 2026-09-14 的三条裁定,逐条落地。

1. **§2 读侧守卫**(他只钉了写侧,读侧是另一半,而且更隐蔽):`reader` 在查询里是**过滤条件**,
   空串不写坏数据也不报错,只会**算出一个错误的数** —— `unreadFor('')` 的
   `NOT EXISTS(... reader_name = '')` 恒真 ⇒ `CountUnread(ctx,"")` 把**所有**邮件算成未读
   (用户看到"全都没读"),`ListInbox(...,"read")` 恒空。
   二选一里选 **①报错**(当前没有任何调用方需要"汇总"语义;选②就要立刻定义"汇总"是什么,
   而那是个还不存在的需求 —— 将来要就新增一个名字里带汇总的函数,别让空串偷偷兼职)。
   `requireReader` 装到 `ListInboxScoped`/`CountUnread`/`CountUnreadInSession`,
   判据两条:空 reader 三个入口都**必须报错**且**不返回数**;正例防止写成"一律拒绝"。
   变异验证:撤掉 `CountUnread` 的守卫 → `CountUnread("") 必须报错,实际返回 0`。

2. **§1 `mails.status` 收口**:先做他要求的第 1 步(枚举读者,他没有 shell)。
   枚举结果:**没有**"零功能读者"那条路 —— 行级值仍会进邮件 JSON(`GetMailByID`、
   `GetThread` 都 select 它),`migrate.go` 的两处是**一次性回填**(正当),
   `unreadFor`/`readStateFor` 只用它判 `archived`(正当,且已注明"不再作为未读判据")。
   所以走第三步:**登记欠账 + 增量判据**。
   - 「只为兼容保留」**没有**当结语:`mail_status_readers_test.go` 是一张**机器检查的清册**,
     按**文件 + 次数**登记(repo.go 13 / thread.go 1 / migrate.go 4),
     **新增一处读取就红**并强制当场回答"这处合不合规";写入点同样登记
     (多一处 `UPDATE mails SET status` 就红)。
   - **第一次跑就抓到第二处写入**:`MarkAllInboxReadForSession`(整会话批量已读)里还有一句
     `UPDATE mails SET status='read'`,我原先只看到 `MarkMailRead` 那一处 ——
     这正是"新增即红"的价值:靠人 grep 会漏,靠判据不会。
   - 收口路径(写进判据注释):行级 `'read'` 迁到 `markReadFor`;
     但在"详情/线程仍返回行级 status"两处读者迁移**之前**不能只删写入
     —— 那会让 JSON 里的 status 永远是 unread,是另一种错误事实。
   变异验证:在已允许的文件里新增一处读取 → 清册对不上,红。

3. **§3 阈值契约显式选 (b)**:不要求数值一致(`40px`/`600ms` 在触摸屏与鼠标、手机与大屏上
   的人体工学合理值天然不同,强行同值会两边都不舒服),契约改钉**语义层**(左滑/右滑=什么、
   边界是否回弹、"快滑"是感知档)。并写清推论:选了 (b) ⇒ **鸿蒙不得引用 WebUI 的三个数**
   (引了就等于偷偷选了 (a),还是"我抄的那一份"那种)。
2026-09-14 17:08:31 +08:00
5e74e0312e test(预设): 补行为判据 —— "清单里有、渲染器没有"必须红(值判据只挡住一半)
pi 2026-09-14 指出:我那条"两端预设清单 id/顺序逐项相等"只挡得住**一半** ——
它挡"清单漏一档",挡不住"清单有、渲染器没有"(第 7 档两边都加、忘了给
`layersFor` 加分支 ⇒ 值判据全绿,用户看到的却是 aurora)。症状与"信息对等缺口"
一模一样,只是路径换了。核对:他说得对,`layersFor` 的兜底就是 `aurora`,
所以丢分支是**静默**的。

新增 `test/harmony-presets.test.mjs`(4 条,`--experimental-strip-types` 直接执行
纯逻辑 `model/Wallpaper.ts` —— 与 `harmony-logic` 同一先例,**能真跑**):

1. 六档 × 两主题:不抛异常、非空、每层 kind/色标/网格字段有效;
2. ★ **清单里有、渲染器没有 → 红**:手法是拿一个不存在的 id 调一次当作"兜底长相",
   任何一档丢了分支就会与兜底逐字节相同 ⇒ 红。**并写明已知边界**:`aurora` 自己
   就是兜底档,它"丢分支"在行为上不可观测(由值判据 + 第 3 条兜住);
3. 六档两两不同(复制分支没改参数 → 红);
4. 深色档必须与浅色档不同("深色没换色" → 红)。

**不需要设备 ⇒ 按 pi 的提醒不登记进 `static` 欠账**(那会虚增余额)。
两条变异都验过:删 `mesh` 分支 → 行为判据报"画出来的和兜底档一模一样";
清单加第 7 档不加分支 → **值判据与行为判据同时红**(两条一起才闭合)。
安装相位 14/14 绿。

另按 pi 要求处理两处登记:
· §7.12 那行"px ↔ 档位"改成**核实后的真相**:`bg_blur` 在鸿蒙侧只有搬运没有消费
  (`Appearance.ts` clamp 存下、`AppearanceStore` 同步,**没有任何页面读它**),
  所以不存在映射表可钉 —— 钉一张不存在的表是假判据;并写明"若将来开始消费它,
  那时必须补映射判据",作为"人工约定、当前无判据"的登记处。
· 预设 id/顺序那条**标清钉的是产品要求**(顺序=用户看到的选项次序),理由写进判据注释。
2026-09-14 17:05:15 +08:00
863b583838 fix(已读/文档): 空 reader 报错(把约定变成做错会红);P6 方案补分支声明与可验收性;"与 X 一致"入册
pi 2026-09-14 对 P6 方案的五条,逐条处理(都不改方向)。

1. **§4 已读按读者的强制点** —— 他说得对,但实际情况比他担心的更靠前也更靠后:
   HTTP 层取的是 `user.Username`(**不是请求参数**,所以根本不可能"省略 reader"),
   但 **repo 函数本身接受空串**:`MarkMailRead(ctx, id, reader)` 会照写一行
   `reader_name=''` —— 不属于任何人,却会让"未读"统计出偏差,而且没有任何东西会红。
   已加守卫(空/纯空白 → 报错,不兜底)+判据(不仅"不许插垃圾行",且**必须返回错误**;
   另含正例,防止把守卫写成"一律拒绝")。变异验证:撤掉守卫 → `空 reader("")必须报错`。
   顺带一条给他的更正:同一个函数结尾还有 `UPDATE mails SET status='read'`(**行级**全局写),
   所以"按读者"这个性质只对**用 `mail_reads` 派生的数据**成立(`CountUnread`/`ListInbox` 是),
   读 `mails.status` 的客户端仍然是邮件级语义 —— 两件事在同一个函数里,容易被看漏。

2. **§2 手势阈值**:核实结果 —— **WebUI 侧没有被任何判据钉住**(`CalendarView.tsx:204`
   裸字面量 `Math.abs(dx) < 40 || Math.abs(dx) < Math.abs(dy) * 1.5 || !fast(600ms)`)。
   所以撤掉"与 WebUI 一致"的写法,改标 **「待两边对齐」**(文档两处),并把他给的推广写成
   规范 `CRITERIA.md` §12:**凡"与 X 一致"的判据,前置条件是 X 侧那个值自己有判据钉住**,
   否则测的是"我抄的那一份" —— 与"两张表各缺一半时必须按 id 联接"同一族。

3. **§1 分支声明(最要紧的一条)**:写进 P6 分期段 —— 本步实现的是**窄屏那条**
   (**容器自身带圆角 + 那一层能裁剪**);宽屏那条(起始侧/结束侧分开给)**不适用**,
   因为它的理由是"中间是分隔线、四角全给会露底色",而手机是单栏、中间没有分隔线。
   并写死这句:**"给对边"是跟着"中间有没有分隔线"来的,不是无条件的三件套。**
   同时核实并写清现状:鸿蒙侧**还没有日历页**(全 ets 树无任何 calendar 提及)⇒ P6 是整页新建。

4. **§3 可验收性**:P6 三步各加一列 —— 第 1、2 步**本工作区可验收**(读 `.ets` 层结构),
   并明确"**第 2 步不需要设备,不许登记成 `static` 欠账**"(那会虚增余额);第 3 步
   **必然进欠账**(要设备:能装、能点),到期前提见探针表。

5. **§5 路由**:不再把 WebUI 改动挂成"等 pi"(他这条链上没有 shell)。按他给的三级路由执行:
   优先在鸿蒙侧引用**已有令牌**解决;必须动 WebUI 时找 gui-lab 或按先例自己改。
2026-09-14 17:03:16 +08:00
05e9583fe5 test(预设): 钉住两端预设清单的 id 与顺序;更正"模糊只由壁纸层负责"这条被撤回的口径
pi 2026-09-14 的三处答复,逐条处理:

1. **§1 预设渲染(他担心的信息对等缺口)实际不存在**:鸿蒙侧 `model/Wallpaper.ts` 已有
   `PRESET_IDS = ['aurora','dusk','mint','sand','ink','mesh']` + 标签 + 归一化 + `layersFor`,
   计划文档 §P4 行也早写着"预设 6 档都能画出来 ✅"。所以 P4c(上传入口)不必让位。
   **但缺口在判据上**:原先只钉了"服务端默认预设要在鸿蒙清单里"与"预设色板的值两边相同",
   **id 集合与顺序没钉**。新增判据:`PRESET_IDS` 必须与 WebUI `PRESETS` 的 id **与顺序**逐项一致
   (顺序也是契约:顺序不同会让两端的选择界面看起来"选错了")。变异验证:把 aurora/dusk 对调 → 红。

2. **§3 模糊口径**:他说判据"现在是后者"(只有导航必须有材质)—— 实际**两条都在**
   (`harmony-appearance.test.mjs`:壁纸层不许有 `backgroundBlurStyle`、也不许有任何 `blur(`;
   导航条必须有 `.backgroundBlurStyle(Theme.navMaterial)`)。所以这里不需要改代码。
   需要改的是**文档里的规则原文**:`docs/HARMONY-ALIGN-PLAN.md` 第 9 行那句
   "模糊只由壁纸层负责"是**被撤回的原话**(它其实是 WebUI 的架构结论:WebUI 壁纸自带
   `filter: blur()`,所以浮在它上面的面再 `backdrop-filter` 就是糊第二遍),已换成两段式规则
   "同一张底只许被模糊一次 / 模糊该出现在背后是可变内容的层",并把撤回本身留痕。

3. **§3 补的第二件(语义转换)**:§7.12 的表里新增一行 —— WebUI 的 `bg_blur` 是**像素半径**、
   作用在壁纸图层;鸿蒙**没有对应物**,栏上的系统材质档位是唯一一次模糊,壁纸层不糊。
   写清"不是同一个物理量,`bg_blur=8px` 与档位对不上不是 bug",否则以后必被当 bug 报。
2026-09-14 16:59:16 +08:00
ec5ee5eb9b docs(mirror): 补一条实测 —— 上游匿名可完整克隆,「凭据过期」不是镜像掉队的原因
GIT_TERMINAL_PROMPT=0 GIT_ASKPASS=/bin/true git -c credential.helper= clone --depth 1
https://gitea.jianfgit.xyz/jianf/MailUI4Agents.git  → 成功,HEAD 就是最新提交。
这条当初是最像的一个假设(镜像项目一般靠存起来的凭据去拉上游),实测排除。
2026-09-14 16:11:00 +08:00
0309d09ac2 docs: gitcode 镜像仓为什么不会自己更新(附实测证据与触发方式)
用户(2026-09-14):「git@gitcode.com:JianFeeeee/MailUI4Agents.git 这个镜像仓
怎么也没更新?」

查下来三件事,写进文档免得下一个人再查一遍:

① 它是 gitcode 的**导入/镜像项目**,上游就是我们自己的 Gitea
   (`import_url=https://gitea.jianfgit.xyz/jianf/MailUI4Agents.git`,
   从项目页的 Nuxt payload 里读出来的)。
② **推不进去**,两条路都是服务端拒绝:
   SSH  `<CH.00905401> This operation is not allowed because the repository is an
        image repository.`
   HTTPS 403 `<CH.00905403>`(同样的措辞)。
   「image repository」是它那边的「镜像项目」类型,不是容器镜像;语义是**单向**的。
③ **没有自动同步,也没有 API**:那个页面自己写着「对于滞后的提交,你可以通过
   拉取更新从源项目获取最新的代码」—— 是手动一键操作。6 种猜测的 API 端点全部 404。

我们这边实测是好的:上游公网可达(直连 101.201.37.155 拿到 info/refs,HEAD
就是 d78f19f)、公网 DNS 有记录、匿名可克隆。镜像停在 c19eea5(09-12),落后 114 个提交,
纯粹是那边没人点「拉取」。

本机无法代点:动作要以仓库所有者身份登录,而共享浏览器 profile 里只有 gitcode 的
匿名 Cookie,没有登录态。文档里给了网页入口和「想自动化就只能换成普通项目由我们推」
这条替代路(会改 URL,属对外契约变更,要先问)。
2026-09-14 16:10:24 +08:00
456ae5a66d 跨端: pi 五条评审落地 —— 产物自证替代时间戳代理、静态判据可到期、判据能读一层标识符、值/来源配对规则、归因不许动别人的树
pi 2026-09-14 的评审(`9839f8a9`)五条,逐条落地;其中 §6 的两条是**核对后已成立**,不重复劳动。

## 1 产物自证:`dist/BUILD_INFO.json`(pi §1)

原来那条判据是"`dist` 比 `src` 新"——**代理变量**,pi 指出两层都靠不住:看不见"构建是否
成功"(实测过),而"`dist` 比 `src` 新"也不等于"dist 是从这份 src 构建的"(`checkout`/`cp`/时钟
都骗得过 mtime;我确实用 checkout 造过一次假红)。现在改成**内容自证**:
`scripts/build-info.mjs` 在构建最后一步写 `{gitRev, gitDirty, srcHash, srcFiles, buildCmd, builtAt}`,
判据重算当前指纹再**精确比对**(`test/build-stamp.test.mjs`)——"代理"两个字没有了,
报错能直接读出两边指纹。`release-linux.sh` 打完包把同一份信息打进日志(一个包自带
"它对应哪个源码状态")。`gitDirty` **只展示不判定**:共享工作区常年是脏的,拿它当红/绿依据
会天天误报。

实测三变异:改 src 内容不重建 → 红(两个指纹都打出来);BUILD_INFO 记成别的提交 → 红;
**`touch`(只动 mtime)→ 绿** —— 旧判据在这里是**假红**,新判据不误伤,这是它严格更好的地方。

## 2 静态判据的**欠账**与到期(pi §5)

"暂时"不是状态、是待办,规范里写下的"暂时"没有任何机制回来读它。改成可机检的形状:
`run-all.mjs` 登记 `STATIC_ONLY`(5 条:`.ets` 只能验形态)+ **必填到期前提**(探针,真跑
`hdc list targets`);汇总打 `RESULT static=N`(**欠账余额**);**前提一旦为真,这些判据当场
变红**并要求"改成行为判据或换更准的前提"。实测:探针恒真 → 5 条同时报"到期";把前提写成
`'vibes'`(未知探针/陈述)→ 套件红。这是"自报条数 < 登记条数"的**时间版本**。

## 3 判据能解析一层标识符(pi §3)

Go 默认值判据原来"值不是字面量 → 判据读不懂 → 红",长期结局是有人做一次无害重构
(`BgDim: defaultDim`)就把判据逼宽、再下一步少核一个字段。现在:字面量直接用;
标识符在**同一文件**查 `NAME = <字面量>`;查不到(跨包/计算/iota)才报"读不懂"。
实测:`BgDim: defaultDim` + `const defaultDim = 12` → **绿**(无害重构不再误伤);
`const defaultDim = baseDim + 0` → 红且报文说"读不懂"。**只解析一层**:再深就是"执行 Go"了。

## 4 §6.7 的可机检分流规则(pi §2)

新增 §6.7.0:**值 → 行为判据,来源 → 静态判据**,理由写成覆盖问题(行为判据只覆盖它跑到的
路径 ⇒ 原理上判不了"有没有别的路绕过去";来源约束要的是全程序可达性 ⇒ 只有读代码能答)。
两条推论:静态判据判值永远差一个反例、行为判据判来源永远差一条路径;**不是强弱,是分工**,
缺任一条那一对就是假判据。附本仓已有的完整样例(P5 命中区:值判据"≥44"+ 来源判据
"应用点必须引用常量"),新增 §6.8 记欠账机制、§8 记共享树归因纪律。

## 5 值/来源配对补齐 + 让位派生(pi §6 的两条)

- 命中区原来只有值那一半:补**来源**判据(`.ets` 里出现 `minHeight: 44` 这类裸数字 → 红,
  报文点出"值判据管数字够不够大、来源判据管用的是不是同一个数字")。变异:写死 44 → 红。
- "`76` 应从条高派生":**核对后已成立**(`NAV_CONTENT_RESERVE = NAV_BAR_HEIGHT +
  NAV_BAR_BOTTOM + 8`,判据也按常量算)。顺手把裸的 `8` 起名 `NAV_CONTENT_GAP`
  (这一族里唯一还需要人判断的数),并加判据钉住**派生关系**:写回字面量 `76` → 红。

## 6 `legacy.bak` 的生命周期(pi §4):**有意永久残留**,并说清代价

pi 质疑成立:判据钉死"没有任何代码读它"⇒ 也没有任何代码能删它。**否决了"点重置外观时删"**:
最可能点重置的人正是外观被接管的那个人,而这份备份是他唯一的旧值,那时删等于把恢复数据
毁在最需要的时刻。所以定为"有意永久残留"(没有代码路径能判定何时安全删除——那取决于人),
并把代价量出来写进 §7.12:值受 `MAX_DATA_URL_BYTES`(2.4MB)约束,**最坏是一张用户原图的
整份副本**,共享机器上即一份别人的外观;要清就手工 `removeItem`。判据钉住这行**同时**给出
"为什么不删"与"怎么删"(变异:删掉删除方法 → 红)。

## 7 归因方法(pi §6 第三条):认错并写成纪律

我当天归因 `narrow-layout` 的 3 条红时用了 `git stash push -- MailView.tsx`,动的是**并发写
作者的未提交改动**。结论对、方法不行:它写共享工作区(别人崩溃/`git add -A` 就丢他的活),
而且只影响 tracked 文件(untracked 的 WIP 还在 ⇒ "干净了"是假干净,结论也可能假)。
纪律写进 CRITERIA.md §8:只读手段(`git show HEAD:path > /tmp/...`、`git worktree add`)或直接问作者。

## 验证

`npm test` 全绿(14 个判据文件 + vitest 266 + typecheck),`RESULT static=5`;
`hvigorw assembleHap` BUILD SUCCESSFUL;`scripts/release-linux.sh` 重打 deb(日志带产物指纹)。
提交前两道**真红**按预期挡了我:改了 src 未重建 → build-stamp 红;重建了 dist 未重打包 →
packaging 红。**未验**(照旧不写成已完成):鸿蒙侧视觉/交互观感、运行期换肤重算(静态判据,
到期前提见 `RESULT static=5`)。

注:本次 `dist`/deb 是在**共享工作区**上构建的,树里含并发写作者未提交的
`CalendarView.tsx`/`index.css` —— 产物里的 `gitDirty: true` + `gitRev` 正是为此留的,
复核时先看那一行。
2026-09-14 16:00:34 +08:00
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
ccd0a39e76 docs(P5): 悬浮玻璃导航落地记录 + 视觉验收的**实测**阻塞(不是"还没做")
- §5.4 的 P5 行由「⬜ 未做」改为「✅ 主体完成」,并写明**未验项与原因**。
- 新增 §7.21:改了什么(NavItems.ts 放尺寸常量让判据判**数值**;内容按 index 挂载;
  内容底部让位 76vp —— 不让位则最后一行压在条底下,看得见点不到)、判据 6 条、
  4 种变异、以及**判据自己修的两处**(非贪婪正则撞对象字面量的 `}`;色值检查读了含注释的原文)。
- §7.21 末节把"观感验不了"逐层测清楚:①模拟器要写工作区外的
  /root/.Huawei/…/Log/qemu.log,本会话 workspace-write 判 Permission denied;
  ②放宽权限需审批而**这条链上没有人类**,工具明确拒绝;③不需要权限的替代路
  (HOME 挪进工作区,复制实例 + 符号链接镜像,2.7GB)过了写入这关却卡在**许可协议**,
  重放 y 等于替用户同意法律协议 —— 不做,已停止模拟器并删除暂存副本。
  → 要解除需人二选一:放行工作区外写入,或由人在本机起模拟器后把画面交回。

验证:hvigorw assembleHap BUILD SUCCESSFUL;npm test 14 个判据文件里 13 绿
(唯一红的 narrow-layout 由并发写作者的未提交 MailView.tsx 改动引起 —— 用 git stash 验过:
剥掉那个改动即 52 通过,与 P5 无关,未动他人的文件)。
2026-09-14 15:35:48 +08:00
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
d1e0ba32f9 跨端: 壁纸遮盖色改用页面底色系(mask 两套主题都深,浅色下方向与 WebUI 相反);模态遮罩保持 mask
pi 提了一个**方向性**疑问,让我先把值读出来再定 —— 读完确认**他是对的**,而且这是"机制上确定不同"。

## 实测(两张 SDK 表交叉验证,不靠记忆)

`ets/build-tools/ets-loader/sysResource.js` 给名字→id,`previewer/.../resources.txt` 给 id→值:

| 令牌 | 浅色主题 | 深色主题 |
|---|---|---|
| `ohos_id_color_mask_regular`(原 `Theme.overlay`) | `#99182431` **深蓝灰** | `#b2000000` 黑 |
| `ohos_id_color_background` | `#ffffffff` **白** | `#ff18181a` 近黑 |

⇒ mask 的 light/regular/thick 是**浓度档**(同一深色的三个 alpha),不是深浅两套值:
它在**两套主题下都是深色**(模态遮罩语义)。而 WebUI 的 `--bg-scrim` 浅色是**白**
(原话「浅色下用白把花哨的图案洗淡」)—— 壁纸遮盖用 mask 就是**反方向**:
浅色主题下把预设压暗,而 WebUI 是把它洗淡。

## 改法

- 新增 `Theme.wallpaperScrim = $r('sys.color.ohos_id_color_background')`(页面底色系:
  浅色白、深色近黑,**自动换向**,与"朝底色淡化"同一意图);预设档与图片档的遮盖层都用它。
- `Theme.overlay`(mask)**只留给模态弹层**(那里语义确实是压暗背后)。
- 不复用 `pageBg` 的原因写进注释:页面底在背景开启时会被换成**透明**
  (`bgActive ? Color.Transparent : Theme.pageBg`),而遮盖层**永远要一个真实颜色** ——
  两个用途生命周期不同,共用一个名字迟早坏一头(这个仓库撞过四次的模式)。

## 判据(从 SDK 读真值再判,不写死结论)

断言「mask 两套主题都深」「页面底色系浅白深黑」「WebUI 的 `--bg-scrim` 浅色是白」,
再落到代码:两处遮盖层必须用 `wallpaperScrim`、弹层仍用 `overlay`、两个令牌不许混用。
**这样"令牌选错方向"以后不能靠记性避免。**

变异:遮盖退回 mask → 红 1 条;只改一层 → 红 2 条。

## 文档

§7.17b-2 记这次读数(表格 + 两张表怎么读 + 为什么不复用 pageBg + 变异结果);
§7.12 有意差异表加一行(遮盖色令牌:两个语义两个令牌,"不允许混用")。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0
(12 个判据文件全绿 + vitest 258/258;harmony-appearance 23 → 24 条)。
2026-09-14 15:10:15 +08:00
71585dc42b 跨端: 预设档补遮罩(WebUI 的 --bg-dim 不分档位)+ 主题变化时重算"我们自己算的值";缓存键差异记入表
pi 读 WebUI 源码后发现两处两边不一致,都处理了。这一提交同时改 harmony 与 electron,故自报家门。

## 1 预设档遮罩:**补上**(选"与 WebUI 一致",因为那服务的是可读性)

pi 的证据:WebUI 的 `applyBackground()` **无条件**写 `--bg-dim`(默认 24),
`.app-backdrop::after` 是 `rgb(var(--bg-scrim) / var(--bg-dim))` —— **遮罩不区分档位**;
它的注释写着目的「背景越花,正文越需要一层遮罩才读得动」。
而鸿蒙当时只在 image 档压(`resolveBackground` 里那行注释还写着"preset 档不用"),
且我们已经让出了页面底 → 正文直接压在原色渐变上,**比 WebUI 更艳更亮、更不好读**。

现在两档用**同一个浓度**(同一个服务端字段),页面在预设分支的渐变之上加一层
系统遮罩色 × 浓度(浅色由系统洗白、深色压黑,不自己写 alpha)。

判据:旧断言"preset 档不压暗"**反过来**(留着理由),另加一条钉"两档同一浓度"+
"两处遮盖层都在"+"WebUI 确实无条件写 --bg-dim"(这条差异有据可查)。
变异:预设档不压 → 红 2 条;页面预设分支的遮盖层被删 → 红。

## 2 多账号缓存键:**鸿蒙是对的,不许退回**(pi 点名)

WebUI 的键是全局常量 `agentmail.background`,后果是切到服务端没有记录的账号时
`saved=false` 分支会把**上一个账号的外观** push 上去(新账号"继承"了外观,还写进了服务端)。
这条差异进 §7.12「有意差异」表,**明确写"鸿蒙是对的"**,
判据防的就是"将来有人为了两边一致把它改回去":取键函数的**正文**里必须拼账号 id
(按块取,不是看调用点出现过 `accountId` 就当数 —— "判结构要配对/解析"那条对我自己也适用),
且不许出现 WebUI 那个全局键。变异:`prefKey` 去掉账号 → 红 2 条。

## 3 "未做" → 按 pi 的三档口径改成**已知不一致**,并把系统侧的接法做掉

pi 指出这不是"没做":色板确实按主题算了,只是没接环境变化事件 ——
现象是运行期切系统深浅色时"系统语义色/材质立刻跟随、我们自己算的色板不重算"的**撕裂**。
他给的规则我记成了通用规则(会咬到 P5/P6):**系统自动跟随的东西不会顺带把
"我们自己计算/缓存的值"一起更新** —— 凡随主题变化的自算值都要挂在**同一个主题变化事件**上。

照做:`applicationContext.on('environment')` → `onConfigurationUpdated` 里
**只在 `colorMode` 真换向时**重算(`applyAppearance()`),页面销毁 `off` 退订。
状态 = **未验**(只有真机/模拟器能验:切一次系统深浅色看预设是否跟着换)。

SDK 锚点与两个编译错都记进 §7.17b:`EnvironmentCallback.onConfigurationUpdated(config: Configuration)`
(`Configuration` 从 `@kit.AbilityKit` 取,**不在** `common` 命名空间下)、
`Configuration.colorMode` 是**枚举 | undefined**(字段写成 `number` 直接编译失败)、
`on('environment')` 返回 **number 型 callbackId**。变异:不订阅 → 红。

## 4 文档

- §7.12 加两行:缓存键(含 WebUI 侧开项)、遮罩浓度默认值那两套(`24/8` vs `12/4`,
  按 `clamp` 的 12/4 对齐,因为服务端缺字段时落地的是它)。
- §四 验收纪律改成**四档口径**:没做 / 未验 / 已知不一致(要写触发条件与现象)/
  机制上确定不同(必须判),并把 pi 那条"自算值必须挂主题事件"的可复用规则写进去。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0
(12 个判据文件全绿 + vitest 258/258;harmony-appearance 20 → 23 条)。
2026-09-14 15:04:07 +08:00
4babc96f8b test(criteria): runner 不再手写 --test(由内容推导)+ 自检 4「这条判据能不能红」;规范补两档
pi 提的三条,第一条落地前先按他的要求**贴真实样本实测**,结论与他的猜测不同(记在代码里)。

## 1 runner 内部那个"配错 flag = 绿" —— 实测后换了个形状

pi 的猜测:给自定义 `check()` 的判据传 `--test`,runner 会报"0 个测试"并以 0 退出。
实测(node v22.22.2,两条真实样本):

- `node --test <自定义 check() 判据>`:**退出码照样传出来**(文件 exit 1 → 命令行 exit 1),
  没有被吞;
- 但 `node --test <什么都不做的文件>` 报 `# tests 1 / # pass 1` ——
  **pass 计数不是"检查跑过"的证据**。

所以"解析 pass 计数、0 就判红"这条路两头不讨好:抓不到空判据(它报 1),
还会在 `narrow-layout` 上误报(它的汇总行是"窄屏布局:全部通过",里面没有数字)——
正是 pi 提醒的"别照抄我的正则,先贴样本"。

换成两条**结构证据**:

- **`--test` 不再手写**:由文件内容推导(源码里 `from 'node:test'` 就走 node:test),
  清单里出现手写 `--test` 直接红 —— 配对错误不再靠记性维护;
- **自检 4**:每条判据文件里必须存在"能红"的路径(`test(` / `check(` / `process.exit(1)`),
  外加"跑完必须有输出"。一个都没有 = 它永远不会红,与"全通过"长得一模一样
  (这是"判据自己不会跑"家族的第 6 个宿主,家族表和六种宿主都写进规范了)。

变异:清单手写 `--test` → 红;加一条"什么都不做、退出 0"的判据 → 红;
静默成功(有能红路径但一行不输出)→ 红。

## 2 规范 §3 补一档:变异红了还要看**红在哪**(pi)

"只报红了不算,要能指名红的是哪几条";**红在解析/加载失败上不算红**(先让变异
"语法正确、语义错");变异作用于被剥掉的注释也不算。

## 3 `CRITERIA.md` 的可见性(pi 提的位置问题)

它管两个客户端的判据,却躺在 electron 的测试目录里。已在
`docs/HARMONY-ALIGN-PLAN.md` §四(验收纪律)加指针,并顺手把 pi 点名过的两条口径写死在那儿:
**"未验"只能用于"步骤做过、结果没看",功能不存在必须写"没做"**;
**"机制上确定不同"要判、不许记成"未验"**(深色档预设那次)。

## 验证

`npm test` 退出码 0(12 个判据文件全绿 + vitest 258/258)。
2026-09-14 15:00:26 +08:00
22c9be7181 跨端: 预设色板两套(pi:这不是"观感未验"而是机制上确定不同)+ 手写色清册跨文件 + TMPDIR 按会话分家 + 提交归属可判
pi 读完 `model/Wallpaper.ts` 后指出四处,全部处理。这一提交同时改了
`client/harmony/` 与 `client/electron/`(跨端改动),所以 subject 按新约定自报家门。

## 1 预设色板不随主题 —— **类别判错了:不是"未验",是机制上确定不同**

我上一版把"深色档预设"记成"观感未验"。pi 指出:WebUI 的 `.bg-preset-*` 写的是
`rgb(var(--c-blue-100))`,而 `--c-*` 在 `.dark` 里整体换了一套(blue-100 → `30 43 67`),
所以 **WebUI 的预设自动随主题变**;这边只有浅色那套 = 深色主题下"浅色渐变垫在深色系统表面之下",
正是这一整轮在治的病。**它不需要真机就能判**(机制写在代码里)—— 我把可判的东西
记成了"未验",这跟上一轮把"没做"写成"没验"是同一类错。

选 pi 倾向的那条(跟随主题,与 WebUI 一致):

- 色板两套:`LIGHT_*` 取 CSS `:root`、`DARK_*` 取 CSS `.dark`;`paletteFor(dark)` 选一套,
  `layersFor(id, dark)` 按主题出层;
- `isDarkMode(theme, systemColorMode)` 放在纯逻辑里:选了 dark/light 就照办,
  `system` 看系统当时的 `colorMode`(锚到 SDK:`COLOR_MODE_DARK = 0` / `COLOR_MODE_LIGHT = 1`;
  读不到按浅色,与 WebUI 的 `:root` 默认一致);
- 系统深浅从 `resourceManager.getConfigurationSync().colorMode` 读
  (`Context` 基类没有 `config`;`UIAbilityContext.config` 要转型;两个枚举取值一致,都核过 SDK);
- 判据:两套值与 `:root`/`.dark` **逐个相等**;每个预设的深浅两套**必须真的不同**
  (否则"两套"是抄了两遍);网格线色也要换;`isDarkMode` 五种输入。
- **未做**:运行期间改系统深浅色不会自动重算(要重进页面)——系统侧正确做法是订阅
  `applicationContext.on('environment', …)`,记在 §7.17b。

变异:`DARK_BLUE_100` 偏一位 → 红;`paletteFor` 永远返回浅色(= 我原来那个状态)→ 红;
`isDarkMode` 把系统深浅记反 → 红;页面把深浅写死成 false → 红。

## 2 手写色清册**跨文件按类扫**(原 A2 只保护 `Theme.ets`)

`Wallpaper.ts` 也有手写色。若对照是"按名字枚举"的,第 15 个色就会逃掉 ——
与 A2 要防的是同一件事,只是换了文件。现在一份清册按类扫:全 `ets/` 树里每个
`X: string = '#RRGGBB'` 都必须登记(Theme 的品牌/业务语义色,或预设色板 ——
后者常量名必须带 `LIGHT_`/`DARK_` 前缀,值由 CSS 两段比对负责)。反向也判清册过期。

变异:`Theme.ets` 加未登记色 → 红;`Wallpaper.ts` 加未登记色 → 红;
加一个"看着合规"的 `DARK_EXTRA` → 红。

## 3 `TMPDIR` 互踩(pi 提出)

这个 worktree 可能同时有多个 agent 跑构建,而 fpm 会把 291MB 的 `linux-unpacked`
**整份复制**进 `TMPDIR` —— 撞车就是随机的产物损坏。`whoami` 区分不开(大家都是 root),
所以按**会话**分家:`TMPDIR=$PWD/.tmp/${DSH_SESSION_ID:-$(id -un)-$$}`
(进了 `npm run build:linux` 与 BUILD.md 的手敲命令;普通终端退化成"用户+PID")。

## 4 提交归属变成**跑判据就看得出来**(pi 给的形状)

新的 `test/commit-hygiene.test.mjs`:扫最近 40 条提交,**同时改两侧目录**的提交
必须在 subject 里自报家门(`跨端:`)。两条防腐:基线 = 该判据文件自己的引入提交
(**历史不改**,规则管从今往后);分类逻辑拿合成输入自检
(未标注的混合提交必须判红、标注过的不许红)——否则"解析没跑起来"时它会全绿。
变异:`COMMIT_HYGIENE_BASELINE` 指到老提交 → 历史里那两个被卷进去的提交立刻判红。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0
(12 个判据文件全绿 + vitest 258/258;`commit-hygiene` 在本提交落地后基线生效)。
2026-09-14 14:57:18 +08:00
0ce8b29546 test(criteria): 判据规范 CRITERIA.md(邻接不是结构·第三次露头)+ 废弃 API allow-list 结构化 + 扫描范围自检
pi 的两条增量,都不需要他再确认。

## 1(pi 建议):生成清单 + 空 allow-list 的结构性风险

他的推演:SDK 升版会往清单里加新条目 → 某天早上套件**突然红**,且红在与本次改动无关的
代码上;这时人的第一反应是把名字塞进 allow-list —— 而 allow-list 一旦这么用,
就不再是"研究过的例外",只是"红的止痛药"。所以条目结构化:

```js
const ALLOW = [ /* { name, replacement, why } */ ];
```

`replacement` 非空是硬断言("暂时不想改"不是放行理由,"替代品要求的 API level 高于基线"才是)。
**刻意不断言"名单必须为空"** —— 那会挡住合理放行;断言的是"有名字、没替代品 → 红",
于是侵蚀发生时红的是**放行这件事本身**,而不是某天的新 SDK。
变异:塞一条 `{ name:'px2vp', replacement:'', why:'暂时不想改' }` → 红。

## 2(pi 建议):扫目录的判据要防"空判据"

他问废弃 API 判据扫哪些目录(怕只扫 `pages/`,`common/` 里的旧写法逃掉)。
答案:扫的是**整个 ets 目录递归**(实测 25 个文件,含 `pages/ common/ model/ api/ entryability/`)。
顺手加了防退化的自检:文件数 ≥ 20,且 `pages/ common/ model/ api/` 四个目录都必须扫到
—— 目录改名/只扫一个子目录会让这条变成空判据而依然全绿。
变异:把扫描范围改成只扫 `pages/` → 红。

## 3(pi 建议):把"邻接不是结构"写进判据规范

同一个坑在本仓露头三次:① 窗口式正则被一行注释挤爆(原注释自嘲过);
② 括号配对取代窗口;③ 链式修饰符让"看前一个字符是不是 `}`"静默失效。
共同形式值得升格成规则,于是新建 `client/electron/test/CRITERIA.md`(七条),
并在 `run-all.mjs` 加**自检 3**:规范文件必须在、且必须点到关键条目。
WebUI 侧 `background.test.mjs` 的窗口式存量按 pi 的说明**记着不动**(那是他的地盘)。

规范里另外两条是本仓自己踩出来的:剥注释读代码 vs 读原文读理由(混用必红);
以及**验证要按真实入口跑** —— 我用 `node --test test/run-all.mjs` 验自检 3 时它"依然绿",
其实是 runner 把内部的 `process.exit(1)` 吞了;换成 `npm test` 走的那一行就红对了。
变异:删掉规范里的一条关键规则 → `npm test` 那条路 exit 1。

## 验证

`npm test` 退出码 0(11 个判据文件全绿 + vitest 258/258);`hvigorw assembleHap` 未受影响。
2026-09-14 14:51:30 +08:00
c4ee5f3ebe docs(harmony): 记下 §7.17 那批代码的提交归属(并发写入者的 git add -A 把它们并进了 WebUI 提交)
P4b 的实际代码(`model/Wallpaper.ts`、`MainPage` 的壁纸层与页面底让出、判据、本节文档)
落在 `c9717da` 与 `1717863` 里 —— 那两个提交的信息写的是 **WebUI** 的事:
并发写入者与我共用同一个 git 身份,它 `git add -A` 时把我尚未提交的工作区一起提交了。
代码是好的,归属是错的;`962df62` 里有完整的"改了什么/为什么/怎么验",但 diff 只有判据文件。

所以补一条 7.17a:说清哪几个提交、为什么信息对不上、以及按路径 add 更稳。
不留这条的话,`git log -1 -- .../Wallpaper.ts` 会指向一个 WebUI 提交,
后来人只能靠猜。

`npm test` 退出码 0(11 个判据文件全绿 + vitest 258/258)。
2026-09-14 14:49:40 +08:00
1717863c87 fix(webui): 手势与横向滚动分家 + 纵向滚动边缘淡出
用户给了两条具体信息(这比我自己猜五轮都管用):
「横向滚动条会与切换视图的手势冲突,我觉得周视图需要卡严条件,
  同时我说的其他硬截断是对应内容项上下滑动会直接被切断」。

## ① 手势卡严(周视图)

冲突是真的:周视图窄屏下必须横向滚(`overflow-auto` + `min-w-[36rem]`),
而我又给整页加了左右滑动翻页 ⇒ 同一次横滑既想滚又想翻,两边都不好用。

规则定死:**手势从可横向滚动的区域里起手,就归滚动条,完全不参与翻页判断**
(触点沿祖先链查找 `overflow-x: auto/scroll` 且真的能滚的容器)。
想翻页就从别处滑(例如上方标题栏)。

## ② 纵向滚动边缘淡出

滚动条本身是"一刀切":卡片滚到边缘被硬生生截断 —— 这就是用户说的"直接被切断"。
给纵向滚动容器(`.overflow-y-auto`)加 12px 上下渐隐遮罩,切得有交代。

只作用在**纵向**容器:横向滚动有自己的滚动条,加纵向遮罩会跟它打架。

## 过程记录(值得记)

这两条改动**第一次没有生效**,因为部署失败了:`/tmp` 是 tmpfs 且已 100% 满,
而部署脚本把构建产物写到硬编码的 `/tmp/agentmail-gateway-build-*` ⇒
`no space left on device`。我差点把"旧构建上的测量结果"当成"改动无效"。
清理后(清掉我自己的探针脚本/截图/旧构建,约 950MB)部署成功。
⚠️ `/tmp` 现在仍占 91%(`gocache` 4.5G 等不全是我的),**下次部署可能还会撞上**;
脚本改成尊重 `TMPDIR` 才是根治(未做)。
2026-09-14 14:35:43 +08:00
a6b5e52f45 test(harmony): 判据按 pi 复核意见补强 —— 手写色登记表、玻璃叠用形状、按标题取小节、遮罩必须被用、废弃 API 清单从 SDK 生成
pi 逐行读了 `cross-client-theme.test.mjs` 与 `Theme.ets` 后指出五处(第一处是真缺口),
外加一条建议。全部处理,并且**每一处都用变异验证过**。

## 一(真缺口):枚举 11 个"必须是系统资源"的名字,挡不住第 12 个新写死的手写色

`static readonly brandSecondary: string = '#123456'` 这种新增**三条判据都碰不到**:
A(不在名单里)、B(六位、不是半透明)、裸色值那条(只管 `pages/`)。
原理与当初 14 处 Google 色逃出去是同一条 —— **枚举挡实例,类才挡漂移**,
只是这次枚举的单位是**名字**。补 `A2` 条:

- 枚举 `Theme.ets` 里所有 `static readonly X: string = '#……'`,未登记的 → 红;
- 名单里已不存在的名字 → 红(名单不能烂成化石);
- `Theme.ets` 里的「手写色登记表」段必须逐个列出这些名字(理由不能只存在于记忆里);
- 自检:把一个**新的**手写色塞进源码字符串,确认这条抓得到。
  `Theme.ets` 因此新增登记表(17 项,每项一行理由,按品牌 / 业务语义 / 档位胶囊分组)。

变异:Theme.ets 加 `brandSecondary` → 红。

## 二:C 的"玻璃只有一处"**说错了自己断言的东西**

`assert.equal(glassCalls.length, 1)` 断言的是"全仓共一处",**不是**"没有嵌套":
同页两个**并列**玻璃面(没问题)会让它红,真嵌套它没在判。P5 正是悬浮玻璃导航,
到时若把 1 改成 2 就等于不判。改成形状判据:

- 收集每个调用点所作用的**组件块**(按括号配对回溯;注意 ArkUI 修饰符是链式的,
  `X.blur(A).blur(B)` 前面是 `)` 不是 `}` —— 第一版只看一个字符,对这种写法**静默失效**,
  是判据自检抓出来的);
- 判两种叠法:同一组件上叠多次(同一块)、以及套在另一层玻璃的子树里;
- 每一处玻璃都要在 `GLASS_REGISTRY` 里登记(附一句为什么),名单里的位置若已不存在 → 红。

变异:链式叠两层 → 红;通信页多开一处未登记玻璃 → 红;导航条块内嵌玻璃 → 红。

## 三:文档小节用 `indexOf('有意差异')` 会**拿错段落**

别的段落正文里出现这四个字,切片就从那里开始,后面所有断言都在**别的段落**上判。
改成**按标题**定位(正则匹配 `^#{2,4}…有意差异…$`),并加了表头列名断言
(WebUI / 鸿蒙 / 为什么)—— 拿错段落时表头不会是这个形状,于是它自己会红。

顺带修掉一个**我自己的**同类毛病:品牌色那行原来用"关键词 + 80 字符窗口"判,
窗口宽度在赌表格单元格字符数(该行两格之和 > 80)。改成**按行取**那一行再断言。
另外把偏移算术的切片换成**按行**切片(偏移差一个字符就会把最后一行拦腰截断,
现象是"品牌色那行只剩 57 字符"这种看着像文案、其实像切片的怪事)。

变异:文件前面插入含「有意差异」的段落 → 仍绿(按标题定位生效);
再改坏真表里的品牌色行 → 红(确实读的是那一张表)。

## 四:`Theme.overlay` 只判了"存在",没判"被用"

没使用点的令牌是自证。补断言:它必须在 `Theme.ets` **之外**有真实使用点
(实测 `SettingsPage.ets` / `MailDetailPage.ets` 两处自绘弹层在用),
并把 `overlayColor`/`overlayAlpha` 消失的理由写进 §7.12 —— 否则下一个人会当成漏改补回来。

## 五:材质档次是这次替换里唯一"判据绿但可能观感错"的地方

`COMPONENT_THICK` 的依据(对 THIN / BACKGROUND_* / ULTRA_THICK 的取舍)写进 §7.12,
并把"材质档次在导航条上的实际观感"列为**模拟器起来后第一个要看的项**(间距是数字,材质是判断)。

## 六(建议):废弃 API 判据**类化** —— 清单从 SDK 生成

原来是手写"不得再用全局 `promptAction.showToast`"(只挡已踩过的那个)。
现在从 SDK 生成:顶层(花括号深度 0)被标 `@deprecated` 的 `declare function`
—— 实测 68 个名字(含 `animateTo` / `getContext` / `px2vp`),配一份**空**的 allow-list。
深度判定是必要的:`declare namespace fileIo { declare function open() }` 里的 `open`
是命名空间成员,算进来会造一堆假红。只算全局调用(排除 `x.name(`)。

变异:调 `px2vp(10)` → 红;`this.px2vp(10)`(成员调用)→ 绿(假阳性自检)。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0
(11 个判据文件全绿 + vitest 258/258)。cross-client-theme 13 → 14 条,harmony-system-api 4 → 5 条。
2026-09-14 14:26:45 +08:00
43aca575c7 docs(harmony): 阶段表标状态(P2/P4 ✅、P3 主体完成、P5/P6 未做),并写明状态口径 2026-09-14 14:19:43 +08:00
2a6ad93ec0 feat(harmony): P4 —— 外观(主题 + 壁纸)跟着账号走
服务端 2026-09-13 起就是外观的权威(账号级 `/api/v1/me/appearance`),WebUI 接好了,
**鸿蒙这边此前完全没接**。这一期补上,并把"谁覆盖谁"的规则做成可判据的纯逻辑。

## 改了什么

- `api/AppearanceApi.ets`:`GET/PUT /me/appearance`、`POST /me/appearance/image`、
  `GET /me/appearance/image`(图片带认证取回本体:不用 `?token=`,也不让 Image 直连 http)。
- `api/ApiClient.ets`:新增 `getBytes()`(按 ARRAY_BUFFER 收)—— 复用 `request<T>` 会当场炸,
  因为它假定响应是 JSON(`JSON.parse`)。
- `model/Appearance.ts`(纯逻辑,判据直接执行):归一化 / PUT 报文 / **合并决策** /
  模糊值→系统材质档次 / 主题→系统色彩模式 / 遮罩浓度 / 状态文案。
- `common/AppearanceStore.ets`:落地副作用 —— 主题交给**系统**(`setColorMode`,不自己维护
  深色色值)、壁纸取回 `PixelMap`、缓存**按账号**分键(`appearance.<accountId>`)。
- 入口两处:`MainPage`(进主界面就应用 —— 只在设置页生效的话"一进主界面就变回去",
  WebUI 侧踩过)与 `SettingsPage` 新增「外观」段(三档主题 + 同步状态「已同步 / 仅本机」)。

## 为什么这么写(两条最贵的规则)

1. **服务端"没有记录"时以本地为准**(`saved === false`):服务端这时回的是一份*默认值*,
   拿它覆盖本地 = 把用户已有的主题/壁纸抹掉(WebUI 原话:每个老用户升级后第一次登录
   都会发现被重置)。正确动作是把本地那份推上去。
2. **降级必须可见**(`local-only` → 显示「仅本机」):否则用户以为换设备也能带走。

## 判据(新增 11 条,已接进 run-all;套件 10 → 11 个判据文件)

归一化(脏值/越界/小数/NaN 退回默认);`image` 档无图 → 退回 `none`;PUT 报文蛇形字段名;
★服务端无记录 → 以本地为准且**一个字段都不能被默认值顶掉**;服务端有记录 → 以服务端为准但
**不擦掉**本地那张服务端还没有的图;离线状态可见且三种状态文案互不相同;
★模糊值→系统材质档次(与 SDK 的 `BlurStyle` 成员**逐一比对**);
主题→色彩模式(数值与 SDK 的 `ConfigurationConstant.ColorMode` **逐一比对**);
★路径必须**相对基地址**(WebUI 那条"整套同步从来没生效过而单测全绿"的坑);
缓存键**带账号**;两处入口都真的应用。

变异验证(6 种,均判红):默认值覆盖本地 / 不管"image 档但服务端无图" / 材质档次自造名字 /
路径多写 `/api/v1` / 缓存键不带账号 / 深浅色彩模式数值写反。

## 判据抓到的两个真 bug

- `snapshotFromResponse` 在字段缺失时给 `bgDim = 0`,而 WebUI 语义是退回 12 ——
  ArkTS 反序列化把缺失字段留成**类里写的默认值**,"字段不在"与"字段是 0"分不开。
  已把默认值对齐 WebUI 的 `clamp(..., dflt)` 语义(并让 `saved` 默认 false = 安全的那一侧)。
- 主题落地按"0=浅色、1=深色"写的 `setColorMode` —— **正好反了**
  (SDK:`COLOR_MODE_DARK = 0`、`COLOR_MODE_LIGHT = 1`),选深色会切成浅色。
  靠判据去 SDK 枚举文件读数比对发现;映射已搬进纯逻辑 `colorModeValue`,
  从"某处有个 setColorMode 调用"变成"可判据的行为"。

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0(11 个判据文件全绿 + vitest 258/258)。
套件自检又抓到一次"判据写好没接进套件"(新文件第一版漏了 run-all),已修。

**未做**:壁纸**上传**入口(选图 → `POST /me/appearance/image`)—— 需要 picker,API 与命名已就位。
**未验**:壁纸在真机上的渲染 —— 需真机或模拟器。
2026-09-14 14:19:26 +08:00
73f886aea5 feat(harmony): P2b+P3 —— 「收件箱」改成「通信」(内部三栏 + 徽标 + 悬浮加号),发件箱与授权栏落地
用户:「收件发件授权改为一个导航项,通过内部导航区分,然后新建作为他们内部的一个悬浮的圆形加号」。
所以这一期不是"再加两个页面",而是对齐信息架构。

## 鸿蒙侧

- 底部第一项 **收件箱 → 通信**(`CommPage`),内部三栏 收件箱 / 发件箱 / 授权;
  页签下划线式(不是浮动白胶囊 —— WebUI 侧用户原话「通信页面的二级页面与其他位置极其割裂」)。
- **徽标**:收件箱红(未读)、授权橙(**待决策**)、发件箱无;0 不显示,>99 写 `99+`。
  合并成一个导航项后,底部看不到"授权有 3 个在等我",这个信息不能丢 —— 它比未读更急。
- **悬浮圆形加号**挂到通信页这一层(三个栏都要能新建);`⚙` 也搬上来(否则切栏就够不到设置)。
- **收件箱不再混权限邮件**(`splitByPermission`),未读按筛后算 ——
  WebUI 实测过"一个会话 17 封权限邮件挤掉另外两个会话"。
- **发件箱**:`GET /me/mail/sent`,与收件箱同构(同一套折叠/行),行上主角是**收件人**;
  空态有说明(主句与 WebUI 逐字一致「暂无邮件」+ 一句"这里放什么")。
- **授权栏**(P3 主体):`GET /permission/pending`(不从收件箱筛)+ `POST /permission/decide`。
  拒绝**可填备注且备注真的送出**;请求**过期**时当场说清「审批不会让那次调用继续」。
- 顺手删掉死代码:收件箱里「写邮件」的 `bindSheet`(`composeVisible` 从未置 true,谁也打不开)。

## 判据(harmony-logic 19 → 28 条)

页签键/顺序从 WebUI 源码抽取比对(`uiStore.ts` 的 `CommTab` + `CommTabs.tsx` 的 `TABS`);
页签状态机(键↔下标往返、脏键/越界/非整数 → 回收件箱);徽标规则(数字来源、0 不显示、
99+ 上限、红/橙与 WebUI 类名对应);分家语义(决策过的不再算待决策、空串与 null 同义);
三栏空态互不相同且主句与 WebUI 一致;接线(三个 pane 真的渲染、加号是圆形且在通信页、
"先分家再折叠"、接口路径与决策体三字段、拒绝传备注、过期分支)。

判据抓到一个**真 bug**:`commTabFromIndex` 只判范围,`1.5` → `COMM_TABS[1.5]` = `undefined`
(表现"点哪都不亮")。已加 `Number.isInteger`。

变异验证(六种):授权徽标看未读 / 权限邮件不分出去 / 类型名拼错 / 决策过仍算待决策 /
收件箱不分家 / 发件箱空态去掉说明 —— 全部判红。

## 排序说明

**日历暂时没有入口**:P6 的内容(网格 + 事件读写 + 滑动翻页)还没做,
先放一个点进去空着的入口比暂时没有更糟 —— 有意排序,记在 §7.15 以免被当成漏做。

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0(10 个判据文件全绿 + vitest 258/258)。
**未验**:页签/徽标/悬浮加号在真机上的观感与点击 —— 需设备或模拟器(模拟器要人在命令行启动)。
2026-09-14 14:13:45 +08:00
c6aaf8c468 refactor(harmony): 23 处废弃 API 换成 UIContext 写法(全局 promptAction.showToast 自 API 18 废弃)
SDK 里写得很清楚:`@ohos.promptAction.d.ts` 的全局 `showToast` 标着 `@deprecated since 18`,
替代品是 `UIContext.getPromptAction()`。仓库里有 23 处这种调用(6 个页面,历史遗留)——
这一轮既然在按"用系统方案"整理鸿蒙侧,就一次扫干净,并加判据挡住回潮。

- `promptAction.showToast(...)` → `this.getUIContext().getPromptAction().showToast(...)`(23 处)
- 清掉不再需要的 `promptAction` import(多个 → 只留 `router` 等)
- 新增判据:不得再用全局写法。防的不是这次,而是**新增页面照抄旧代码**这条回退路径 ——
  它编译照样通过、只在真机上行为不同。自检同时验"认得出旧写法"与"不误伤新写法"。
- 顺带把权限徽标那条"点它弹说明"的判据改成钉**非废弃**写法(原来是 `promptAction.showToast(`)。

变异验证:把 `SettingsPage` 的一处改回全局写法 → 判红并点出文件。

验证:`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0(harmony-logic 20 条)。
2026-09-14 14:05:35 +08:00
36f3183bba feat(harmony): 系统方案第一批 —— 表面/文字/圆角交给系统、删手写玻璃、每项一张卡;跨端判据改"意图相同"
jianf:「鸿蒙也同步,但是鸿蒙要求用系统方案」。按 pi 对齐的形状(A/B/C + 品牌色防线)落地。

## 鸿蒙侧改了什么

- `Theme.ets` 的表面/文字/分隔/遮罩/圆角**来源换成系统**:
  `pageBg→sys.color.ohos_id_color_background`、`surface→…_list_card_bg`、
  `surfaceMuted→…_sub_background`、`border→…_list_separator`、三级文字 `→…_text_primary/secondary/tertiary`、
  `overlay→…_mask_regular`、`radiusCard/Control→sys.float.ohos_id_corner_radius_card/button`。
  于是这些维度自动跟随深色模式与无障碍设置 —— 这正是"手抄 WebUI 色值"做不到的事。
- **删掉手写玻璃** `#B8FFFFFF`/`#B80F172A`:那两个值等于"我们替系统猜了深色该怎么做"。
  换成一个**档次**声明 `navMaterial: BlurStyle = BlurStyle.COMPONENT_THICK` + 导航条上的
  `.backgroundBlurStyle(...)`;深浅两套颜色与模糊半径由系统按主题给。
  遮罩的两段式(色 + 透明度)同样删掉:拆两段本就是为了"随主题换向",而这件事系统已经做了。
- **每项一张卡/气泡**:收件箱行、会话组头、联系人列表行改成卡片(圆角 + 卡片底色 + 行间距),
  联系人列表那条贯通分隔线删除。
- 仍然自己写的只有两类:**品牌色**(`accent = #2563EB`,跨客户端身份)与**业务语义色**
  (权限三档、预算三档 —— 系统只有 warning/alert 两个情绪色,凑不出三档,硬套会丢语义)。

## 判据:从"取值相同"改"意图相同"(两侧一起改)

- 品牌蓝**唯一保留取值钉**,并新增防线:不得退化成 `$r('sys.color.*')`
  (系统强调色随主题/厂商皮肤变,"两个客户端是同一个产品"就靠不住了)。
- 圆角/材质/遮罩:改成"WebUI 自声明令牌 + 鸿蒙来自系统 + 差异被记录"(§7.12 有意差异表)。
- 新增 A(系统拥有的维度唯一来源是 `$r('sys.*')`,且不得退回 string/number)、
  B(旧机制不得回来:`navBg*`、8 位半透明色、`rgb(`/`rgba(`、写死的 14/8)、
  C(玻璃位置必须调 `backgroundBlurStyle` 且**只许一层**)。
- pi 指出的洞已补:裸色值判据原来只扫 `#RRGGBB(AA)`,抓不到 `rgba(`/`0xRRGGBBAA` ——
  而这几种恰是"改用系统材质"时最容易混进来的形态。现在四种一起扫,且**先剥注释**
  (注释里正当地引用旧写法不该被judged红)。
- pi 的 §5 建议也已落地:新增"版本库不得跟踪缓存/构建产物"判据(`.tmp/` 那次 554 个文件的事故判据化),
  并放行 `server/internal/static/static/placeholder.html`(go:embed 落点的有意占位,删了 Go 侧编不过)。

## 变异验证(能红,且红在对的地方)

| 变异 | 结果 |
|---|---|
| 品牌蓝 → 系统强调色 | 红 3 条 |
| 手写玻璃 `navBgLight` 回来 | 红 2 条 |
| 导航改用写死半透明色、不调 `backgroundBlurStyle` | 红 2 条 |
| 卡片上再开一层模糊 | 红 1 条("玻璃应只出现在一处,实际 2 处") |

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 退出码 0
(10 个判据文件全绿:跨端 13 条、系统资源名 4 条、harmony-logic 19 条… + vitest 258/258)。
**未验**:观感(卡片间距、系统材质在导航条上的实际效果、深色模式)—— 需真机/模拟器;
模拟器要人在命令行跑一次 `harmony-emu start`。`sys.*` 名字全部对着 SDK 名表核过,且判据持续盯着。
2026-09-14 14:04:04 +08:00
4d226be056 test(harmony): 「用系统方案」的地基 —— 系统资源名与 BlurStyle 取值离线可校验(判据先于替换)
jianf 追加要求「鸿蒙要求用系统方案」(§二·五)。难点是**没有设备**:
`$r('sys.color.写错了')` 编译期不报、只有真机运行到那一行才炸 —— 这块会变成谁都验不了的区域。

SDK 里其实带着答案:`sdk/default/openharmony/toolchains/id_defined.json` 列了全部系统资源名
及其类型(本机 API 26:7826 条,color 1059 条);BlurStyle 取值在 `component/common.d.ts` 的
`declare enum BlurStyle` 里。两边都能离线查,所以"名字写对没有"可以变成构建期判据。

新增 `test/harmony-system-api.test.mjs`(4 条,已接进 run-all):

1. SDK 名表/组件声明找不到时**判红并给出替代做法**(会静默跳过的判据等于没有这条判据 ——
   本仓库已栽过四次同类问题);
2. 源码里每个 `$r('sys.<type>.<name>')` 必须存在且**类型相符**;
3. 每个 `BlurStyle.<MEMBER>` 必须在 SDK enum 里;
4. 替换计划要用的那批系统色**先核过再写代码**,并且钉住一条边界:名表里没有
   `brand`/`confirm`/`success` —— 权限三档、预算三档这些**业务语义色没有系统对应物**,
   继续用自定义令牌,不许"为了系统化"把 plan 档画成 warning 色(那是丢语义换形式)。

变异验证:拼错色名 `ohos_id_color_list_cad_bg` → 报「查无此名」并指出文件;
写错 `BlurStyle.COMPONENT_不存在` → 报出可用取值。顺带修掉解析精度问题:
早先的宽松正则把文档里的 `T`、`R` 也当成了枚举成员,现在精确到 `,`/`=` 分隔符。

验证:`npm test` 退出码 0(10 个判据文件全绿 + vitest 258/258)。
2026-09-14 13:56:43 +08:00
5ce711fbcd test(suite): 自检 3(判据不得埋在 process.exit 之后)+ TMPDIR 固化 + API 同名不同义表
## 自检 3(pi 提议)

自检 1/2 管"文件没接线",管不到"检查写在 `process.exit()` 之后"—— 而那正是实际发生的
第 4 例(4 条玻璃判据被并发写入落到文件末尾)。成因是**结构性**的(并发写入总是往文件末尾
追加),所以它一定会再发生,而它下一次仍然不报错。静态扫一遍即可:`process.exit(` 之后
若再出现 `check(`,直接判红并指出文件。变异验证:往 `theme.test.mjs` 尾部追加一条 check → 判红。

## TMPDIR 固化(pi 建议,采纳)

"记得加 TMPDIR"这种约定活不过两次踩坑(hvigor、fpm 各一次)。所以不再靠口径:
- `npm run build:linux` 自带 `mkdir -p .tmp && TMPDIR=${TMPDIR:-$PWD/.tmp}`;
- `BUILD.md` 的 deb 一节写明这条前置与原因(`/tmp` 是 tmpfs、占内存、常年近满)。

## `docs/API.md`:`total` 不是总封数 + 同名不同义表

`GET /me/mail/inbox` 的 `total` 是**未读总数**(`repo.CountUnread`),不是本页/全部邮件数 ——
鸿蒙端曾因此写出「共 7 封」和「未读 7」两行自相矛盾的字。在人类接口开头加了醒目提示,
并新增一张表:`total`(未读数)/ `status`(邮件=unread|read,会话=active|archived)/
`status` 与 `is_read` 同义不同名。

## 验证

`npm test` 退出码 0:9 个判据文件全绿 + vitest 258/258(安装包已按判据要求重打,
AppImage 与 deb 均为最新)。
2026-09-14 13:53:34 +08:00
b3f404838b feat(harmony): P2a 收尾 —— 撤掉平级「会话」tab + 权限"强制力"上界面,判据 14→19
## 撤 tab(按 pi 的顺序:先补视图与折叠,再撤入口)

底部只剩 **收件箱 / 联系人**。「会话」不是第三个地方,而是同一批数据的两种看法:
收件箱那栏按会话折叠(组头就是会话),联系人那栏的卡片视图是会话的进度视角。
依据是"信息没丢",并且把它做成了判据:**卡片字段集与 WebUI `WorkCard` 完全相等**
(多一个少一个都红)—— 其中 `status`(active/archived) 与 `from_agent` 参考实现也不显示;
哪天 WebUI 补上,这条会红,提醒跟着补,而不是悄悄少一块。

## 权限"强制力"上界面(WebUI 有、鸿蒙原先没有)

只显示档位会让人以为 plan 档真的管住了对方。WebUI 把说明放在 `title`(悬停提示),
**手指没有悬停** —— 所以鸿蒙拆两步:标记形状当场可辨(● 平台强制 / ◉ 覆盖不完整 /
○ 仅提示),点徽标用 toast 说完整那句话。三条纪律落进判据:

1. 档位/强制力标签与 WebUI 的 `MODE_LABEL` / `ENFORCEMENT_LABEL` **逐字一致**;
2. **说明文案从 WebUI 源码抽出字符串逐字比对**(3 档 × 3 强制力全覆盖)——
   两个客户端对同一个任务不能给两种保证;
3. 认不出的强制力归一到 `advisory`(保守方向),空/未知必须说"仅提示"。

收件箱每封邮件里没有 `permission_enforcement`(会话级字段),故那里只写中文档位 ——
凭空画一个强制力标记等于编一个"平台做到了什么"。

## 判据自己不可信的两个坑(变异测试逼出来的,各修一次)

- **断言一律读剥掉注释的源码**:把 `showToast` 注释掉,正则照样匹配 ——
  注释里有某个调用证明不了它存在。
- **"在回调里"不能靠正则窗口**:`onClick` 体掏空、或把 toast 挪到相邻的 `onHover`,
  窗口式正则都会放过。改成**括号配对**取那个 `onClick` 的 `{...}` 体,只在里面找。
  两次变异现在都判红。

`harmony-logic.test.mjs` 19 条(原 14);变异验证:改文案 / 改档位标签 / 页签改回「会话」/
注释掉 toast / toast 挪出 onClick / toast 写死文案 → 各判红。

## 文档

§7.9 记本轮;§7.10 记 jianf 追加的「鸿蒙要求用系统方案」:同意该理解,并补上**可离线校验**的
做法 —— SDK 自带系统资源名表 `sdk/default/openharmony/toolchains/id_defined.json`(7826 条),
其中正好有 `ohos_id_color_list_card_bg`(每项一张卡的底色)、`_list_separator`、
`_text_primary/secondary/tertiary`、`_emphasize`、`_warning`、`_alert`、`_mask_*`、
`ohos_id_blur_style_component_*_color`。**没有设备**,`$r('sys.*')` 写错在运行前发现不了,
所以先立一条判据:源码里的每个 `sys.*` 名字都必须在该表里查得到,再逐处替换。
`cross-client-theme` 的三个取值钉改"意图相同"**先与 pi 对齐、两侧一起改**(他已明确要求)。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL;`npm test` 9 个判据文件(background 42 /
cross-client 8 / harmony-logic 19 / nav-merge 8 / build-stamp 4 / packaging 3 …)+ vitest 258。
视觉与点击仍未验(无设备,模拟器需人在命令行启动)。
2026-09-14 13:51:35 +08:00
dfaeab0e4d docs(harmony): 记入"必须用系统方案"的要求与 WebUI→鸿蒙的做法对应表
用户:「鸿蒙也同步,但是鸿蒙要求用系统方案」。

已转给 dsh(线索 harmony-ui-alignment),并写进计划文档:

- **含义**:能交给系统的就交给系统 —— 用 ArkUI 的组件/材质/语义资源,
  而不是把 WebUI 那套"手写 rgba + 自定义模糊 + 自制卡片"照搬。
  系统材质会跟随深色模式、动效曲线与无障碍设置,手写的不会。
- **对应表**:`backgroundBlurStyle(BlurStyle.*)` 取代手写模糊;系统 `Tabs`/`TabBar`
  取代自制导航条;`List`/`ListItem` 取代 `Scroll`+`Column`;组件自身的
  `borderRadius`/`shadow` 取代 `.glass-card`;`$r('sys.color.*')` 语义色取代自切变量
  (**顺带解决 WebUI 那个"半深不浅"的病根**);`animateTo`/`transition` 取代自定义动画。
- **对既有判据的影响(重要)**:`cross-client-theme.test.mjs` 钉的是三个**取值**。
  改用系统资源后它应当变红 —— 那是预期的,届时要把它从"取值相同"改成"意图相同"
  (品牌蓝仍须一致,材质与圆角允许各自跟随系统)。**必须两侧一起改**,
  避免一边改了一半。

同时提醒 dsh 两条已同步的语义:列表项与顶部都是"每项一张卡/气泡"(不是通栏);
玻璃只出现在一层。
2026-09-14 13:45:34 +08:00
6be5a543af test(suite): 判据总入口 run-all —— 全部跑完再算退出码,并接上两条从未跑过的判据
## 为什么

`npm test` 是 `&&` 链:**前面红一条,后面全部不跑**。于是"只红一条"看起来像
"只有一个问题",实际后面那些判据连跑都没跑(`packaging` 那条能发现"界面改了没重打包"的
判据,长期因此隐身)。而且这套规矩下"全绿"可信、"红"不可信。

改成 `test/run-all.mjs`(pi 建议):每条都跑,红的收集起来最后一起报、一起退出。

- **自检 1**:清单里的文件必须存在(名字写错 = 一条判据静默消失);
- **自检 2**:`test/` 下每个 `*.test.mjs` 都必须接进清单 —— **新增判据忘了接线直接红**。
  这条自检当场抓出 `nav-merge.test.mjs`、`build-stamp.test.mjs` 两个"写好了没接线"的文件
  (8 + 4 条判据此前从未跑过,与 `cross-client-theme` 是同一族问题)。
- 变异验证:强制 `theme.test.mjs` 判红 → 后面 5 条判据照跑,汇总如实报"红 1/9"、退出码 1。

`package.json`:`"test": "node test/run-all.mjs && vitest run"`。

## 接线后暴露的两条陈旧判据(代码没错、判据钉的是旧写法),按"钉行为不钉字面"修

1. `setViewMode(target || commTab` —— 代码后来等价改写成
   `target ?? (isComm ? commTab : modes[0])`。改成钉行为"isComm 时落到 commTab",
   并额外要求桌面分支带 `target`(否则日历/联系人点不动)。
2. `MailView.tsx` 里 grep `glass-control` —— 授权多选胶囊已抽成共用组件 `ComposerChip`,
   样式其实是对的(neutral 未选中态就是 `glass-control`)。改成钉
   "MailView 用 ComposerChip" + "ComposerChip 用控件档"(文件会搬、组件不会)。
   两条都做了变异验证(去掉玻璃档 / 去掉 commTab 回退 → 各判红 1 条)。

## 生成产物再补一条判据(pi 提议)

用 postcss 真解析 `background-takeover.generated.css`:断言每条规则的选择器形状恰好是
`html[data-bg='on'] .bg-xxx`,且规则条数与源码扫到的清单条数一致。
只验"能解析"不够 —— 实测 postcss 对当年那份坏产物照样解析出 1 条规则(选择器前粘了
注释尾巴),所以卡形状与条数。变异:把坏头注释塞回生成产物 → 该条判红。

## BUILD.md:deb 结论撤回(不是 fpm)

`TMPDIR=/var/tmp/ebtmp` 在本沙箱建不出来;把 TMPDIR 指到工作区大盘后 deb 正常产出
(`release/agentmail-web_0.1.0_amd64.deb`,约 100MB)。日志关键行是 **`Errno::ENOSPC`**:
fpm 要把 291MB 的 `linux-unpacked` 整份复制进 TMPDIR,而本机 `/tmp` 是 9.8G tmpfs、
被 `/tmp/gocache`(4.5G)等占到 99%。所以「本机打不出 deb」是环境症状、不是工具链缺陷,
deb 不必从 `build.linux.target` 摘掉。排查命令写进 BUILD.md。

## 验证

`npm test` 退出码 0:9 个判据文件全绿(markdown-xss、narrow-layout、nav-merge 8、
theme、background 42、cross-client 8、harmony-logic 14、build-stamp 4、packaging 3)
+ vitest 258/258。鸿蒙侧 `hvigorw assembleHap` 仍 BUILD SUCCESSFUL。
2026-09-14 13:44:00 +08:00
e0c68d8bb2 test(cross-client): 预算条三个档位的令牌也和 WebUI 对齐 + 记录模拟器权限门
## 判据

P2a 新加的 6 个预算条令牌(`chipNeutral*` / `chipSpent*` / `chipWarn*`)此前只有鸿蒙侧
自己在用,没有任何判据钉住它们与 WebUI `BudgetChip` 的 gray-100/gray-500、
red-100/red-700、orange-100/orange-700 是**同一批值** —— 于是"鸿蒙那边自己挑了个接近的红"
没人会发现。补进 `cross-client-theme.test.mjs`(8 → 8 条,第 7 条扩了 6 个断言),
并加了反向对照(差一个色阶必须判红,实测判红)。

注意 `--c-gray-100` 等在 `.dark` 段有第二处定义,`cssVar()` 取第一处(`:root` 浅色一套),
与 `Theme.ets` 的浅色令牌对应。

## 文档

`docs/HARMONY-ALIGN-PLAN.md` §7.6:把"鸿蒙视觉/点击未验"查到根上 —— DevEco CLI 说明本机
**有**可启动的模拟器(起来后 `devecocli ui layout/click/screenshot` 能做点击级验证),
但 `harmony-emu start` 要写 `/run`、`/root/.Huawei`(工作区之外),按规矩升级重试一次后
被拒:**「权限询问无法送达:该任务链上没有人类用户」**。
即:鸿蒙的点击级验证不是"还没做",是"当前做不到"——需要人在命令行跑一次
`harmony-emu start`。此前所有阶段只能按"逻辑有可执行判据 + 接线有判据 + 观感未验"验收。
2026-09-14 13:38:35 +08:00
3729afd96f feat(harmony): P2a —— 收件箱按会话折叠 + 联系人页卡片视图(判据直接跑同一份逻辑)
按 pi 的结论落地 P2a 的前一半:**先补视图与折叠,再删平级「会话」tab**(tab 本轮保留)。

## 判据怎么"点用户真正会点的那一层"

鸿蒙侧没有设备(`hdc list targets` 为空、模拟器在本机沙箱下起不来),"点一下"暂时
无法自动验。应对不是编个能过的新判据,而是把会点的那一层的内核抽成纯逻辑:
`entry/src/main/ets/model/MailGrouping.ts`(无 UI 依赖),判据用 node 的
`--experimental-strip-types` **执行同一份代码**(`test/harmony-logic.test.mjs`,14 条),
断言的是行为而不是"源码里出现过某个字符串":

- 折叠后组头是不是**最新一封**、组内是否时间倒序、组间排序、同一时刻用 `mail_id` 倒序兜底;
- 时间解析失败**不能让顺序依赖入参**(WebUI 侧踩过的 NaN 比较坑);
- 多账号合并下同名 `session_id` 不能被错并成一组;`session_id` 缺失时各自成组;
- 预算档位与 WebUI `BudgetChip` 完全一致(剩 0 用尽 / ≤1 将尽 / 上限 0 不显示);
- 视图切换与卡片上"最新一封是人还是 Agent"的判据。

页面那一层另用源码判据钉"确实调了这些函数",两层合起来覆盖「逻辑对」+「页面接上了」。
**变异验证 4 处全部判红**:去掉组内排序(2 条红)、预算阈值 `<=1` 改 `<1`、
分组键去掉账号前缀、页面不再区分单封组。

## 收件箱折叠

- 组头取组内最新一封的别名与主题,带未读数徽标与「N 封」,点它展开/收起;
- **单封不成组、平铺**(与 WebUI `isFlatGroup` 同结论:给孤立一封信套组头只是多一次点击);
- 多账号是鸿蒙特有:分组键带账号前缀;`session_id` 缺失按 `mail:<id>` 各自成组。

## 顺带修掉一个"看起来是总数、其实是未读数"的显示

`/me/mail/inbox` 的 `total` 是 **`CountUnread`(未读总数)**,不是总封数
(`server/internal/handler/me.go`)。鸿蒙底部原写「共 N 封」⇒ 同一屏出现
「共 7 封」和「未读 7」两行自相矛盾的字。改成:未读数用服务端 `total`(权威,
原来数这一页会少报);「共 N 封」→「已加载 N 封」;**这一页取满时如实提示
「已加载 50 封(本页上限 50,可能还有更多)」** —— 客户端没有可信总封数,
就不能把 50 封说成全部(pi 提醒的"别让只取 50 封伪装成只有这么多会话")。
WebUI 侧不读这个字段,故只影响鸿蒙。

## 联系人页补卡片视图(撤 tab 的前置)

- 右上角切列表/卡片,标题「联系人」/「工作列表」(与 WebUI 同词),切换规则在
  `nextContactView()`;
- 卡片对应 WebUI 的 `WorkCard`:Agent 名 + 工作目录 + 未读徽标、会话别名、
  **主题当主角**、最新摘要 + 人/Agent 标记、`N 封 · 时间`、权限档位徽标、
  **往返预算条**(同一档位判据)。
- 平级「会话」tab 暂留:撤 tab 按 pi 的顺序排在后面单独一步(撤早了预算/status/from_agent 没处看)。

## 验证

- `hvigorw assembleHap` **BUILD SUCCESSFUL**(`.ts` 纯逻辑模块被 `.ets` 引用,实测可行)。
- `npm test` **退出码 0**:窄屏布局全通过、主题 30、背景 34、cross-client 8、
  harmony-logic 14、packaging 3、vitest 258/258;新判据已接进 `npm test`。
- **视觉与点击仍未验**(无设备):展开手感、卡片间距、组头命中区没有任何自动判据
  能代替人眼 —— 交付按"结构/逻辑已验证、观感未验"写,未写成已完成。
2026-09-14 13:36:05 +08:00