|
|
329a2e2e81
|
test(设备证据): 第一次真机读回通过闸（前台=ours）—— 收两份真实证据
1. fixtures/aa-dump-l-ours-foreground.txt：**真实**的我们前台样本（此前那条正例是**对调状态合成的**，
这份是真的）——闸判 ours、mayAssertOn=true。
2. fixtures/ui-layout-ours.json： 实采的控件树（33,899 B），
带 bounds/backgroundColor/text 等属性 —— 这是把 harmony-appearance / appearance-defaults /
cross-client-theme 三条从验形状升成真机读回的原料。
顺序按 pi 的更正：**先拿窗口（探测说静默）再 aa start**，然后取 dump 过闸。
|
2026-09-15 12:09:37 +08:00 |
|
|
|
5337d51bfb
|
test(设备闸): 补第二份真样本（单 mission，我们不在列表里）+ 把"状态对调"那条从弱断言改成**严格正例**（pi §4②）
- 新样本 `fixtures/aa-dump-l-single-theirs.txt`：由真样本删掉我们那块得到，形状与 pi 12:03 的活 dump 一致
（单 mission、`state #FOREGROUND` 是对方）⇒ 正确判决 **`other`**，不是 `unverified`
—— 否则会把"别人占着前台"和"没读到"混成一种；
- `#FOREGROUND` 全删 ⇒ `unverified`（缺证据不猜）；
- ★ 原"状态对调"那条我原先只断言 `ours || unverified`（当时心虚写宽的）。pi 指出：
**只判"读不出来就不许过"是不够的，还得有正例证明"读出来了真的能过"** —— 否则这道闸的失效方式是
"永远说未验"（更安静的失效，而且欠账永远还不完）。已改成严格断言 `ours` + `mayAssertOn === true`。
- 登记 5→7（我一度写成 8：我只加了 2 条，5+2=7 —— 相等契约下这种手误会被套件当场抓住，这正是它该干的事）。
|
2026-09-15 12:08:09 +08:00 |
|
|
|
88fa5cb149
|
test(设备闸): 收一份**真实**的 aa dump -l 作为样本（来源与时间写在下面）
为什么要收它：`DeviceProbe.parseForeground` 原先是按**猜的**格式写的（`bundleName: xxx`），
而真机上的形状是 `bundle name [xxx]`，且**多个 mission 并存**、前台由各 mission 的
`state #FOREGROUND` 决定。两种错法都能发生：
- 按 `bundleName:` 解析 ⇒ 全部匹配不到 ⇒ 闸永远返回 `unverified`（方向安全，但等于没法用）；
- 只取**第一个** `bundle name` ⇒ 取到的是**别的 app**（这份样本里 `#31 com.example.homeagent`
就排在我们 `#32 com.jianf.agentmail` 前面）⇒ **假绿**。
样本内容（采集于 2026-09-15，`hdc -t 127.0.0.1:5555 shell "aa dump -l"`）恰好是**争用发生后的那一刻**：
我们的 mission 在，但**前台是别的 app** —— 正是这道闸要挡的输入，而且是真实形状而非构造的。
采集背景（同一分钟内）：`aa start` 报 success，随即 dump 显示我们 FOREGROUND（84231），
约一分钟后再次 dump（本样本）**前台已被对方拿回**（`#31` FOREGROUND）——
所以"争用"不是理论风险，它在一分钟内就发生了。
|
2026-09-15 12:02:58 +08:00 |
|
