docs: REVIEW-LOG「1.2.0 发布实录」（run 33796263718 / 33797741834、资产 SHA、装机 cmp、真实库 I7 行 94/94/0/0）+ DESIGN-COMMANDS I7 节措辞

发布链实录：三资产与 v1.1.3 同一套，sha256sum -c 两项 OK，leakscan 12 模式 0 命中；
PATH 与 NSIS 两处装机后 pm --version 1.2.0、三份 pm.exe 同 sha。突变 m1–m5 在全量
440 例上复核，各判红恰一例。DESIGN-COMMANDS 的 I7 节把「相册为空的 root」一句改准
（相册层为空；备份盘作为主库镜像同样按本判据对账它自己那份）。

Author: skymanbp

docs/DESIGN-COMMANDS.md

@@ -587,6 +587,6 @@ P7-I 之后的第二次第一方全量自审（ultracode 多代理工作流，10
 
 | 命令/入口 | 变化 | 出处 |
 |---|---|---|
-| `pm doctor` | 多一类 **I7 行**（`Pm.Doctor.i7Findings`）：按 I7 校验 **相册 ⊆ 成片 ∪ inbox-origin**。已解释两条，都以**内容**为准——① 索引里有同 sha 的成片；② journal 里有一条 Copy 记录，dst 恰是这条相册路径、sha 与盘上现字节相同、src 在**库外**（`pathAtOrUnder` 三态，只有明确的 `Just False` 算库外；`_inbox` 的源后来被移进 `_done` 不影响判定——证据是记录不是源文件）。两条都不成立 → 逐条 **Warn** 列给人（同 Q1：只报告、不处置，I1 不猜来源），退出码随之为 1。收尾一条 Info 汇总「N 张 = 成片副本 x · inbox 来源 y · 未解释 z」。相册层只判照片（`KindPhoto`）；相册为空的 root（备份盘之外的 vault root、空库）一行不打 | DESIGN §2 I7 |
+| `pm doctor` | 多一类 **I7 行**（`Pm.Doctor.i7Findings`）：按 I7 校验 **相册 ⊆ 成片 ∪ inbox-origin**。已解释两条，都以**内容**为准——① 索引里有同 sha 的成片；② journal 里有一条 Copy 记录，dst 恰是这条相册路径、sha 与盘上现字节相同、src 在**库外**（`pathAtOrUnder` 三态，只有明确的 `Just False` 算库外；`_inbox` 的源后来被移进 `_done` 不影响判定——证据是记录不是源文件）。两条都不成立 → 逐条 **Warn** 列给人（同 Q1：只报告、不处置，I1 不猜来源），退出码随之为 1。收尾一条 Info 汇总「N 张 = 成片副本 x · inbox 来源 y · 未解释 z」。相册层只判照片（`KindPhoto`）；相册层为空的 root（vault root、空库）一行不打（备份盘是主库的镜像，同样按本判据对账它自己那份） | DESIGN §2 I7 |
 | `pm doctor --repair` | **与 I7 无关**：`applyRepairs` 只认 C2 / R2 / Q-DONE-LOST / C5 四种 fRow 且要求 detail 以 oid 开头，I7 行进不了任何修复推导。相册文件永远由人处置 | — |
 | `pm doctor`（fail-closed） | journal 有告警（撕裂尾 / 中段损坏）或快照是坏代回退时**整条判据不判**，只打一行 Info 说明。判据里有一条否定式（「journal 里没有别的来源记录」），折叠不全时会把正常照片报成违例——核不了 ≠ 已覆盖 | 同 1.1.3 `planStale` 的纪律 |

docs/REVIEW-LOG.md

@@ -605,3 +605,5 @@ N1 无对应源突变（是用例自身的健壮性），以反向核验代替
 **1.1.3 发布实录（2026-09-02 深夜）**：单提交 497477d（代码 + 版本串五处 + release-notes + 文档）→ sancheck 135 文件 0 命中 → rangescan 1 提交 0 命中 → 快进 → push main → main run 33706827825 绿（build ≈ 9 min，缓存热）→ `git tag -a v1.1.3 497477d` + push → tag run 33707446216 build + release 双绿 → release v1.1.3 三资产（zip 12397499 B、setup 8382336 B、sha256.txt）→ 回下载 `sha256sum -c` 两项 OK（zip `5613b26d…`、setup `b44b2448…`）→ 仓内 leakscan 12 模式 0 命中 → PATH `%APPDATA%\local\bin` 的 pm.exe / pm-ui.exe 用 zip 覆盖后 cmp 逐字节相同 → NSIS 静默装 DisplayVersion 1.1.3、安装目录 pm-ui.exe 与 zip 恰差 3 字节（同 1.0.0 起的 bundle-type 标记）→ `pm --version` 1.1.3 → 真实库 `pm plan list`：6 份草稿「已失效（源已不在）」、dedupe「已执行（余 8 项待裁决）」，零计划文件删除。装好的 pm-ui 1.1.3 真机拉起并连上 serve（状态页截图 scratchpad shots/plans-real113.png）；计划页真机截图因前台锁（用户正在用机器，SetForegroundWindow 四次被拒）未取到，版式以 Edge headless 桩截图为准（同一份 gui/ui、同一 Chromium 内核）。两本手册按 1.1.3 重生成（v8 71 页 / 图册 16 页，Gmail 服务端核过两附件）。**事故登记**：第一版 tour 脚本用 `FindWindow(null, "pm")` 按标题找窗口，撞上 VS Code 的一个 170×47 子窗口并向它发了「5」与 End 两个按键——若当时某编辑器有焦点可能被插入一个 "5"，已告知用户核查；脚本改按 pm-ui 进程主窗口句柄。
 
 **1.2.0 I7 判定侧（2026-09-03，用户裁定「实现 DESIGN-COMMANDS §10.3 第 2 项的消费侧」）**：**缺口**——§10.3 第 2 项正文承诺「ingest 的 journal 来源登记喂 I7：doctor 把 inbox 来的照片归为已解释而非违例」，落实表却是「判定侧 ⏸ 未做」，`src/Pm/Ingest.hs` 头注同写「消费侧尚未实现」，DESIGN §2 的 I7 校验列与 §14 的「相册↔成片 例外文件」行也各挂着同一条待办——四处指向同一个零代码的判定。**实现**：`Pm.Doctor.i7Findings`（内核只读，无新 Op、无新记录类型——I2/I4 面零变化）。已解释两条都以内容为准：① 索引里有同 sha 的成片副本（设计内冗余的定义就是同一份字节）；② journal 里有一条 Copy 记录，dst 经 `foldPath` 与这条相册路径相等、`opSha` 与盘上现字节相同、`opSrcAbs` 经 `pathAtOrUnder` 得到**明确的** `Just False`（库外）。三处判据各有独立的错误后果，逐条都留了突变配对：库内源（`pm album add` 的形态）若算进来，「相册 ⊆ 成片」就成了同义反复；sha 不等的记录说的不是这份字节；`pathAtOrUnder` 答不上来（卷已拔走 / ACL 拒）不算库外——把查不出的记录当成来源证明正是布尔探针塌态那一类错误，反方向只多一条待人工核查的 Warn。认 Intent 而不等 Done：Intent 就是来源记录本体（P6-D），「这份字节确实是那次拷贝落下的」由 sha 相等作证；journal 是可手编输入，路径字段先过 `opPathsOk`（同 `classifyPending`）。**fail-closed**：journal 有告警或快照是坏代回退 → 整条判据不判、只打一行 Info（判据含否定式「journal 里没有别的来源记录」，折叠不全时会把正常照片报成违例），与 1.1.3 `planStale` 同一纪律。**修复面**：I7 行进不了 `applyRepairs`——白名单只认 C2/R2/Q-DONE-LOST/C5 且要求详情以 oid 开头，用例里 `--repair` 跑完 orphan 文件字节未变。**结构**：`Pm.Doctor` 不能 import `Pm.Album`（Album → Cli → Doctor 成环，同 1.1.2 拆 `Pm.Derived` 的那个环），层名 `相册`/`成片` 因此从 `Pm.Album` 收进 `Pm.Types` 单一定义、`Pm.Album` 按原名再导出（Convert/ServeAi/ServeVault 三处改为经 `Pm.Types` 取，冗余 import 清零）；Doctor.hs 742/750。**测试**：IngestTests 新增 3 例——ingest `--apply` 端到端后**把源删掉**（skill 的 `_inbox→_done` 那一步）再 doctor，仍判「inbox 来源 1 · 未解释 0」exit 0；成片同 sha 副本已解释 + 无解释项逐条 Warn、exit 1、`--repair` 不动盘；三处判别（src 在库内 / sha 与盘面不符 / journal 中段损坏 → 不判）。突变 m1（删 inbox 那条）/ m2（删成片同 sha 那条）/ m3（删 sha 相等）/ m4（不问库内库外）/ m5（去掉 fail-closed 闸）各判红恰一例。既有 `SweepTests.caseDoctorDeepSummary` 的夹具两张照片从相册层改放成片层——相册层上无源的照片按新判据**正是**违例，其 `exit 0` 断言会变成对另一件事的断言（同 1.1.3 把 `caseDeleteAndPrune` 的草稿补上源文件的先例）。440/440，GHC 警告 0。**真实库实测**（只读）：`pm doctor` → `[I7] 相册 ⊆ 成片 ∪ inbox-origin: 94 张 = 成片副本 94 · inbox 来源 0 · 未解释 0`，exit 0——DESIGN §14 曾登记的「1 个例外文件」在 09-02 的 EXIF 改正批之后已不复存在，该行按实测改写。**残余**：`pm convert` 以相册里的非 jpg 为源时，派生 jpg 只落相册（源在相册那一支），既无成片副本也不是库外来源——真实库现无此形态（未解释 0），若日后出现会以 I7 Warn 现身、由人裁决，不在本轮扩判据。
+
+**1.2.0 发布实录（2026-09-03）**：单提交 d35ebd1（代码 + 版本串五处 + release-notes + 文档）→ push main → main run 33796263718 绿 → `git tag -a v1.2.0 d35ebd1` + push → tag run 33797741834 build + release 双绿 → release v1.2.0 三资产（zip 12403697 B、setup 8385828 B、sha256.txt 183 B，与 v1.1.3 同一套）→ 回下载 `sha256sum -c` 两项 OK（zip `55a3bfe6…`、setup `48e4bd8e…`）→ 仓内 `scripts/leakscan.py` 对三件（zip 内 pm.exe / pm-ui.exe + setup）12 模式 0 命中 → zip 内 `pm.exe --version` = pm 1.2.0。装机：PATH `%APPDATA%\local\bin` 的 pm.exe / pm-ui.exe 用 zip 那份覆盖后 `cmp` 逐字节相同、`pm --version` 1.2.0；NSIS 静默装 `/S /D=%LOCALAPPDATA%\pm-ui` 退出码 0、DisplayVersion 1.2.0、安装目录 pm.exe 的 sha == zip（`bb62542e…`，三份 pm.exe 同一 sha）、pm-ui.exe 与 zip 恰差 3 字节（bundle-type 标记，同 1.0.0 起）。真实库冒烟（装机后的 1.2.0，只读）：`pm doctor` exit 0、末两行 `[VERIFY-AGE] 4633 条目; 无验证时间戳条目 0` 与 `[I7] 相册 ⊆ 成片 ∪ inbox-origin: 94 张 = 成片副本 94 · inbox 来源 0 · 未解释 0`；`pm doctor --vault`「无发现」exit 0（vault root 无相册层，I7 一行不打）。突变复核在**全量 440 例**上重跑：m1–m5 各判红恰一例（m1/m2 判 I7 的两条端到端用例，m3/m4/m5 判「三处判别」那例）。**未做**：两本手册 PDF 未按 1.2.0 重生成——仓内无生成脚本（PDF 本身 gitignore），历来由用户在仓外重做。