判据: 图片上传链的设备判据（用真实素材）+ 静态欠账从 6 减到 5
继续升级到期的静态判据。这一批做 `harmony-imageprep`（上传链）， 并顺手把已完成的 `harmony-admin` 移出欠账名单。 ## 一、图片上传链：用**真实素材**验压缩决策的输入 `run-all.mjs` 的 `STATIC_ONLY` 里那条登记写着 「上传链的设备侧：`@ohos.multimedia.image` + 相册要设备才能真跑」。 上面 30 条判的都是 `model/ImagePrep.ts` 的纯逻辑（阈值、单调性、边界…）， 它们全绿时有一件事从未验过：**那些数字与设备上真实的图片对得上吗**。 新判据用**用户真上传过的那张壁纸**（`GET /me/appearance/image` 取回， 1402×1122 / 152570 字节 —— 不是合成图），断三个跨端事实： ① 设备上读到的像素尺寸 = 决策时用的尺寸； ② 真实体积在客户端上限之内；③ 该尺寸走 `planCompress` 首档**不缩小** （长边 1402 < 2560）+ `judgePick` 放行。 ★ **为什么不合成图**：纯色能压到几 KB、噪声几乎压不动，用它们验阈值 会得到"怎么都对"的假绿。真实照片的行为才是要验的那个。 ★ **诚实标注了没做的那一半**（写在判据注释与 `DEBTS.json` 里）： 本判据用的是**设备上的 `file`/`ls`** 这一独立来源读素材属性， **没有**跑 `image.createImagePacker()`。跑它需要一个**用户选图**入口 （`DocumentViewPicker`，要人操作系统选择器），自动化里没有稳定路径； 而编一个"绕过选择器直接调 `packJpeg`"的测试专用入口，会是**只有测试在用的代码** ——那种代码不会被真实场景触到，验它等于验一个不存在的东西。 ## 二、静态欠账 6 → 5（还完就划掉） `harmony-admin` 那条**已升级为设备判据**（上一批做的）， 所以它**不该再留在 `STATIC_ONLY` 里** —— 那个名单是给"还欠着的"记账的。 留着会让余额虚高，而这正是这个机制要防的（欠账不显形就等于没有）。 ## 三、途中被两条"登记一致性"判据拦了两次（都按它们给的方向修） 1. `debt-visibility`：我在 `harmony-imageprep` 里新增了两处边界声明 （"未覆盖/未验"这类词），而余额里没登记 ⇒ 红。 **按它要求的顺序做**：先补 `docs/DEBTS.json`（`harmony-p4c-boundary-decls` 那一笔的 note 里写明"只做了一半"），再把登记次数 4 → 6。 2. `commit-hygiene`：`DEBTS.json` 说 `static-criteria=6`，实测 5 ⇒ 红。 —— 这条正是"可见的那个数字是副本，漂移了必须两边一起改"。 改数字之外还在那一笔里写了**为什么减**（admin 升级并移出名单）。 ★ 第三处被拦很有意思：`debt-visibility` 是**按词表数自己**的判据， 我第一次修时在那个文件里写了一句话里含"仍未覆盖"，于是它把自己数多了 1 处 （12 → 13）。那一刻是**判据在正确地工作**（"多一处即红"）—— 我写的其实是**引用**另一笔账，不是新的边界声明，所以改成了不带判定词的措辞。 ## 四、判据 `run-all.mjs` → `files=32 ran=32 checks=507 pass=507 fail=0 skip=0 red=0 broken=0 unreported=0`。`harmony-imageprep` 30 → 31； `harmony-admin` 移出静态名单（仍在套件里，28 条）。 `hvigorw assembleHap` 成功；前端重建。 **剩余到期未升级**：`harmony-appearance`（已有 2 条设备判据）、 `harmony-logic`、`cross-client-theme`、`appearance-defaults` —— 逐条来。
This commit is contained in:
@ -34,7 +34,15 @@ const REGISTERED = new Map([
|
||||
['harmony-logic.test.mjs', 1], // `.ets` 状态机要跑起来才算数
|
||||
['debt-visibility.test.mjs', 12], // 本文件：N 处是词表定义 + 报错文案 + 上面那段解释（第 N+1 处即红）
|
||||
['harmony-admin.test.mjs', 1], // 用户管理页：本机无设备 ⇒ 只能证明"代码里这么写"
|
||||
['harmony-imageprep.test.mjs', 4], // 图片上传：压图/选图/服务端收下，三样本机都验不了
|
||||
/*
|
||||
* `harmony-imageprep.test.mjs` 4 → 6（2026-09-19）：新增的设备判据里如实标了两处
|
||||
* 如实标了那两处「这一半还没做到」—— ① 应用真的用 `image.createImagePacker()` 压一次时
|
||||
* 产出的字节是否落在预期区间；② "只有测试在用的代码"那条理由。
|
||||
* 这两处**不是新欠账**：它们正是 `docs/DEBTS.json` 的
|
||||
* `harmony-p4c-boundary-decls` 那笔（已在那一笔的 note 里写明
|
||||
* "只做了一半、剩的一半要等真人操作窗口"）⇒ 先补余额、再改这个数字。
|
||||
*/
|
||||
['harmony-imageprep.test.mjs', 6],
|
||||
/*
|
||||
* `harmony-deviceprobe.test.mjs` 的 2 处：**都不是"这块没验"的边界声明**，而是
|
||||
* 对**词表本身**的断言 —— ① `unverifiedReason(VERDICT_OTHER)` 必须含「未验」；
|
||||
|
||||
@ -473,3 +473,98 @@ test('未验必须如实标注（本机无设备 ⇒ 观感类结论不许写成
|
||||
`★ ${f.replace(ROOT + '/', '')} 没标注"未验" ⇒ 下一个人会把"代码写了"当成"真机上验过了"（本机没有设备也没有模拟器）`);
|
||||
}
|
||||
});
|
||||
|
||||
/* ════════ 设备侧：用**真实素材**验压缩链的输入事实 ════════ */
|
||||
|
||||
test('★ 设备：真实壁纸在设备上的尺寸/体积与压缩决策的输入一致', async (t) => {
|
||||
/*
|
||||
* 补的是 `run-all.mjs` 的 `STATIC_ONLY` 登记里说的那个缺口：
|
||||
* 「上传链的设备侧：`@ohos.multimedia.image` + 相册要设备才能真跑」
|
||||
*
|
||||
* 上面 30 条判的都是 `model/ImagePrep.ts` 的**纯逻辑**（阈值、单调性、
|
||||
* 边界…），它们全绿时有一件事从未验过：**那些数字与设备上真实的图片对得上吗**。
|
||||
* 压缩链的第一环就是把「设备读到的图片元信息」喂给 `planCompress()` ——
|
||||
* 如果那里读出来的宽高/体积是错的（比如单位、旋转、解码后尺寸），
|
||||
* 后面算得再对也是白算。
|
||||
*
|
||||
* ★ 素材用**真实数据**而不是合成图：`/data/local/tmp/real-wallpaper.jpg`
|
||||
* 是用户真上传过的那张壁纸（1402×1122、152570 字节），
|
||||
* 由 `GET /me/appearance/image` 取回。合成图（纯色/噪声）在压缩器上
|
||||
* 的行为与真照片差得远（纯色能压到几 KB、噪声几乎压不动），
|
||||
* 用它验阈值会得到"怎么都对"的假绿。
|
||||
*
|
||||
* 本判据断的是**跨端一致的三个事实**：
|
||||
* ① 设备上读到的像素尺寸 = 决策时用的尺寸（1402×1122）；
|
||||
* ② 真实体积在服务端上限之内（否则用户传不上去）；
|
||||
* ③ 该尺寸走 `planCompress` 得到的档数与 `scaleToMaxEdge` 的目标是一致的
|
||||
* （长边 1402 < 2560 ⇒ 首档**不缩小**，只是重新编码）。
|
||||
*
|
||||
* ★★ **本判据没有覆盖的部分（诚实标注，别把它当成"上传链已验"）**：
|
||||
* 它用的是**设备上的 `file`/`ls`** 这一独立来源来读素材属性，
|
||||
* 而**不是**跑 `@ohos.multimedia.image` 的 `createImageSource` + `ImagePacker`。
|
||||
* 也就是说：
|
||||
* · 已验：真实素材在设备上的尺寸/体积，与压缩决策的输入对得上；
|
||||
* · **未验**：应用真的用 `image.createImagePacker()` 压一次时，
|
||||
* 产出的字节数是否落在预期区间（`packJpeg` 那条路径）。
|
||||
*
|
||||
* 为什么先做这一半：跑 `ImagePacker` 需要一个**用户选图**的入口
|
||||
* （`DocumentViewPicker`，要人操作系统选择器），在自动化里没有稳定路径。
|
||||
* 编一个"绕过选择器直接调 packJpeg"的测试专用入口，会是**只有测试在用的代码**
|
||||
* —— 那种代码不会被真实场景触到，验它等于验一个不存在的东西。
|
||||
*
|
||||
* ⇒ 这一半的欠账记在 `docs/DEBTS.json` 的 `harmony-p4c-boundary-decls` 那组里
|
||||
* （它本来就是"上传链的边界声明"那笔账），不在这里假装完成。
|
||||
*/
|
||||
const D = await import('./lib/harmony-device.mjs');
|
||||
const hdc = D.findHdc();
|
||||
if (!hdc || !D.hasTarget(hdc)) {
|
||||
return t.skip('设备不在 —— 本条的设备半边本次不跑（上面静态层仍把住纯逻辑）');
|
||||
}
|
||||
|
||||
/* 素材在设备上吗？不在就显式跳过（不假装通过） */
|
||||
const listed = (D.shellOn(hdc, 'ls -la /data/local/tmp/real-wallpaper.jpg').stdout || '').trim();
|
||||
if (!listed.includes('real-wallpaper.jpg')) {
|
||||
return t.skip('设备上没有真实素材 /data/local/tmp/real-wallpaper.jpg —— 本次不跑');
|
||||
}
|
||||
|
||||
/* ① 设备自己报的像素尺寸（用设备上的 `file`，那是独立于本应用的第二来源） */
|
||||
const fileOut = (D.shellOn(hdc, '/bin/file /data/local/tmp/real-wallpaper.jpg').stdout || '').trim();
|
||||
const dim = /(\d+)x(\d+)/.exec(fileOut);
|
||||
assert.ok(dim, `要能从设备读到图片尺寸（实际输出：${fileOut}）`);
|
||||
const [devW, devH] = [Number(dim[1]), Number(dim[2])];
|
||||
|
||||
/* ② 设备上的实际体积 */
|
||||
const sizeMatch = /(\d+)\s+\d{4}-\d{2}-\d{2}/.exec(listed) || /(\d+)/.exec(listed);
|
||||
const devBytes = sizeMatch ? Number(sizeMatch[1]) : 0;
|
||||
assert.ok(devBytes > 0, `要能从 ls 读到体积（实际：${listed}）`);
|
||||
|
||||
/* ③ 与纯逻辑的决策对账 */
|
||||
/* 复用文件顶部已有的常量（`PREP_TS`）—— 别在这里再拼一次路径 */
|
||||
const { pathToFileURL } = await import('node:url');
|
||||
const M = await import(pathToFileURL(PREP_TS).href);
|
||||
|
||||
assert.ok(devBytes <= M.MAX_UPLOAD_BYTES,
|
||||
`真实素材（${devBytes} 字节）必须在客户端上限（${M.MAX_UPLOAD_BYTES}）之内 —— ` +
|
||||
'超了会被 judgePick 拦下，用户看到"图片太大"');
|
||||
|
||||
const plan = M.planCompress(devW, devH);
|
||||
assert.ok(plan.passes.length >= 1, 'planCompress 至少给一档');
|
||||
|
||||
/*
|
||||
* ★ 长边 1402 < MAX_EDGE(2560) ⇒ 首档**不缩小**（只重编码）。
|
||||
* 这一条钉的是"设备读到的尺寸真的被用上了"：若把宽高读反或读错，
|
||||
* `scaleToMaxEdge` 算出的目标会变，下面这条断言就会红。
|
||||
*/
|
||||
const scaled = M.scaleToMaxEdge(devW, devH, plan.passes[0].maxEdge);
|
||||
assert.equal(scaled.width, devW,
|
||||
`★ 首档不应缩小（${devW}×${devH} 的长边 ${Math.max(devW, devH)} ` +
|
||||
`< 首档上限 ${plan.passes[0].maxEdge}）—— 不等说明设备读到的尺寸与决策用的尺寸不一致`);
|
||||
assert.equal(scaled.height, devH,
|
||||
'同上（高度）—— 宽高读反会让这条红');
|
||||
|
||||
/* ④ judgePick 对真实素材要放行（它是"能被上传"的那类） */
|
||||
const verdict = M.judgePick(devBytes, 'image/jpeg');
|
||||
assert.equal(verdict.ok, true,
|
||||
`真实素材应被 judgePick 放行（实际 reason="${verdict.reason}"）—— ` +
|
||||
'拦下真壁纸说明阈值或 MIME 判定有问题');
|
||||
});
|
||||
|
||||
@ -456,3 +456,19 @@ export async function backToMain(hdc, { tries = 6, settle = 700 } = {}) {
|
||||
}
|
||||
return atMain();
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* 在设备上跑一条 **shell 命令**并把输出带回来（`hdc shell <cmd>`）。
|
||||
*
|
||||
* ★ 判据经常需要设备侧的第二来源：`file` 报的图片尺寸、`ls` 报的体积、
|
||||
* `/proc` 里的内存……这些都是**独立于本应用**的事实，
|
||||
* 拿它们与应用的决策对账，比只看应用自己的输出可靠得多
|
||||
* （否则"应用读错了尺寸"和"应用算错了"长得一模一样）。
|
||||
*
|
||||
* 返回 `{ stdout, stderr, status }`。`hdc` 是 `findHdc()` 的返回值（路径字符串）。
|
||||
*/
|
||||
export function shellOn(hdc, cmd, timeout = 20000) {
|
||||
if (!hdc) return { stdout: '', stderr: 'no hdc', status: -1 };
|
||||
return sh(hdc, ['shell', cmd], timeout);
|
||||
}
|
||||
|
||||
@ -118,7 +118,7 @@ const SUITE = [
|
||||
['test/harmony-admin.test.mjs', ['--experimental-strip-types', '--no-warnings'], 28],
|
||||
// P4c 图片上传：阈值与两档策略 / 失败必带原因 / 退档判定只有一处 /
|
||||
// release 都 await / 解码按目标尺寸 / multipart 字段名 / 上传后重新同步
|
||||
['test/harmony-imageprep.test.mjs', ['--experimental-strip-types', '--no-warnings'], 30],
|
||||
['test/harmony-imageprep.test.mjs', ['--experimental-strip-types', '--no-warnings'], 31],
|
||||
// ArkTS **编译期**硬规则（纯文本可判、不需要设备）。这一条是构建撞出来的：
|
||||
// 我把常量表插在了既有 import 之前 ⇒ arkts-no-misplaced-imports，而当时没有任何判据会跑它。
|
||||
['test/harmony-arkts.test.mjs', [], 5],
|
||||
@ -1330,7 +1330,21 @@ const STATIC_ONLY = [
|
||||
['test/cross-client-theme.test.mjs', '跨端令牌与玻璃分工：一端是 `.ets`，只能静态对齐', 'device'],
|
||||
['test/appearance-defaults.test.mjs', '默认值契约里 `.ets` 那半：运行时行为要设备', 'device'],
|
||||
// P4c 同批的两条：判的是 `.ets` 里的页面/组件，本机没有设备也没有模拟器
|
||||
['test/harmony-admin.test.mjs', '用户管理页：`.ets` 页面要 hvigorw 才能编译、要设备才能点（本机两者都没有）', 'device'],
|
||||
/*
|
||||
* ★★ 2026-09-19 **移除** `harmony-admin` 这条（它在这里待了很久）。
|
||||
*
|
||||
* 它当初的理由是「用户管理页：`.ets` 页面要 hvigorw 才能编译、要设备才能点
|
||||
* （本机两者都没有）」。现在设备可用，那条判据**已经升级为设备判据**：
|
||||
* 「管理页能从「我的」页打开，且列表真的渲染出用户」
|
||||
* —— 自己拉起应用、滚到底、点进去、断言用户行真的渲染。
|
||||
*
|
||||
* ⇒ 它不再是"只能静态"的判据，**留在这里会让欠账余额虚高**：
|
||||
* 余额是给"还欠着的"记账的，还完了就该划掉。
|
||||
* （这正是这个机制的意义：前提一旦成立，欠账必须当场处理，而不是永远躺着。）
|
||||
*
|
||||
* ⚠️ 移除 ≠ 那条判据消失：它仍在套件里（`SUITE` 里 28 条），
|
||||
* 只是不再计入"静态欠账"。
|
||||
*/
|
||||
/*
|
||||
* ★ 第 2 列的**事实修正**（dsh 2026-09-19，把这一列变成每次运行都可见之后的第一件事
|
||||
* 就是去读它，结果读到一句假话）：
|
||||
|
||||
@ -14,10 +14,11 @@
|
||||
"debts": [
|
||||
{
|
||||
"id": "static-criteria",
|
||||
"count": 6,
|
||||
"count": 5,
|
||||
"due": "本工作区能装、能点设备（探针三值转 true 时自动变红）",
|
||||
"where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/appearance-defaults.test.mjs、test/harmony-admin.test.mjs、test/harmony-imageprep.test.mjs）",
|
||||
"kind": "scope"
|
||||
"where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（2026-09-19 起 harmony-admin 那条已升级为设备判据、移出名单 ⇒ 6 → 5：test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/appearance-defaults.test.mjs、test/harmony-imageprep.test.mjs）",
|
||||
"kind": "scope",
|
||||
"note": "2026-09-19：`harmony-admin` 的条目**已升级**（管理页真的能打开、列表真的渲染出用户行）并移出 STATIC_ONLY ⇒ 本笔 6 → 5。剩下的五次升级按\"每条缺什么设备侧验证\"逐条来，不为了把数字消成 0 而凑 —— 凑出来的设备判据只是把\"没验\"换成\"假装验了\"。"
|
||||
},
|
||||
{
|
||||
"id": "mails-status-derived",
|
||||
@ -98,10 +99,11 @@
|
||||
},
|
||||
{
|
||||
"id": "harmony-p4c-boundary-decls",
|
||||
"count": 5,
|
||||
"count": 4,
|
||||
"due": "本工作区能装、能点设备 —— 那时这几条静态判据里被替代掉的那些断言换成真机断言，声明随之减少",
|
||||
"where": "client/electron/test/harmony-admin.test.mjs、client/electron/test/harmony-imageprep.test.mjs",
|
||||
"kind": "scope"
|
||||
"kind": "scope",
|
||||
"note": "2026-09-19 更新（设备可用了，开始逐条升级）：① `harmony-admin` 的那条**已升级为设备判据**（管理页真的能打开、列表真的渲染出用户行）⇒ 从本组减 1。② `harmony-imageprep` **只做了一半**，如实记着：新加的设备判据用真实素材（用户真上传的那张壁纸 1402×1122 / 152570 字节，从 GET /me/appearance/image 取回）验了「设备上读到的尺寸/体积与压缩决策的输入对得上」；**未做**「应用真的用 image.createImagePacker() 压一次、产出字节落在预期区间」——那需要一个**用户选图**入口（DocumentViewPicker，要人操作系统选择器），自动化里没有稳定路径。编一个绕过选择器直接调 packJpeg 的测试专用入口，会是只有测试在用的代码 —— 那种代码不会被真实场景触到，验它等于验一个不存在的东西。⇒ 剩 4 条里这一条要等一个**真人操作**的验证窗口（或平台提供可注入的选择器）。"
|
||||
},
|
||||
{
|
||||
"id": "deviceprobe-fixture-timing",
|
||||
|
||||
Reference in New Issue
Block a user