Say which commit each gate number belongs to

A gate record is a measurement of one tree. Three lines in the log read as
if they described today's checkout, and one of them quoted a count taken
before a later commit fixed the thing it counted.

Each line now names the commit it was measured against, the command that
produces the number, and what is in the file set — the pyright figure covers
46 Python files because that commit touched no frontend file.

CHECKLIST.md

@@ -333,7 +333,7 @@
   - [x] p1-6.4 注释压到 ≤1 行
     - 口径：`tokenize` 找连续 `#` 行块。全仓 **39 块 / 86 行 → 0 块**，每块压成一行，压的时候留承重那句，实测数字与错误原文不删（`Unable to allocate 582. MiB for an array with shape (5632, 9024, 3)`、`288,266 rows for 165,973 atoms`、`[^[^\W\s]` 在 3.14 会吃掉 CJK）
     - docstring 不动（全仓多行 docstring 114 条，与父提交同数）：docstring 是模块与函数的契约，不是注释；p1-4 review 用的口径也是「新增多行 docstring 数不得增加」。第一轮 review 抓到搬家途中塌了 3 条——`store_search.py` 的 `search_atoms`（那条「每个过滤条件都是同一条字面 SQL 里的 `? IS NULL OR` 谓词」规则和 `as_holder` 的共享规则）和 `FtsPage`、`bench/run.py` 的模块 docstring——已按原文补回，行数仍全部在 500 以内
-  - 门禁：`pytest -q` **269 passed**；`ruff check backend/src/ely_eye backend/tests bench` All checks passed；mypy 冷缓存 **24 errors / 9 files**（基线 24/6，training.py 那 6 条随拆分落到 4 个新文件，净新增 0）；`pyright` 查 46 个改动文件 → **4 errors**，与 HEAD 单个 `training.py` 在包副本里量到的 4 条同源（qwen_vl_utils 元组返回、两处 `save_pretrained(Path)`、`bitsandbytes` 未解析）；go build/vet/test + gofmt 干净；`npm run build` + eslint 干净
+  - 门禁：`pytest -q` **269 passed**（那是 `9cb46c1` 当时的套件规模，p2-1 加完测试已到 287）；`ruff check backend/src/ely_eye backend/tests bench` All checks passed；mypy 冷缓存（`.venv/bin/python -m mypy --cache-dir <新目录> backend/src bench`）**24 errors / 9 files**，与父提交同命令量到的 **24 / 6** 净新增 0——同样 24 条错，`training.py` 拆开后落到 4 个新文件里，所以文件数从 6 变 9；`pyright` 查该 commit 改动的 **46 个文件**（`git show --name-only 9cb46c1` = 46 个 `.py` + 1 个 `.md`，**0 个前端文件**）→ **4 errors**，与 HEAD 单个 `training.py` 在包副本里量到的 4 条同源（qwen_vl_utils 元组返回、两处 `save_pretrained(Path)`、`bitsandbytes` 未解析）；go build/vet/test + gofmt 干净；`npm run build` + eslint 干净
   - herdr review（同一个 `p1review` pi，`strata/qwen3.8-flash-next-abliterated-iq3_s:high`）三轮：**round 1 FAIL 4** → **round 2 FAIL 1** → **round 3 PASS**。round 1 它自己跑出门禁、行数、搬体同一性、死代码、注释压缩、v1/v2/v3 全部承重，报的 4 条里 1 条是真产品缺陷：拆文件时掉了一些多行 docstring（全仓 114→111），掉的是契约不是装饰——`search_atoms` 的「每个过滤条件都是同一条字面 SQL 里的 `? IS NULL OR` 谓词」规则和 `as_holder` 共享规则、`FtsPage` 的游标理由、`bench/run.py` 的五臂说明（commit `28959c5` 按原文补回，114 条同父提交）；其余 3 条是我写错的数：`store_search.py`/`bench/run.py`/`query_set.py` 行数、`cli.py` 调用点数（实为 11 个调用点亗 7 个方法）。round 2 剩 1 条：`migrations.py` 行号引成了 248/250，在 commit 里那是 PRAGMA 和空行——**根因是我在工作区量的，而 pi-lens 会在本轮之外重排文件把行号推下 9 行**；从此行号一律 `git show <sha>:path | grep -n` 从 commit 量（commit `9682657`）。round 3 它逐条重验：迁移阶梯 181/186/239/241/243 全中（并指出 `:243` 本身不带版本 token，`grep "v1\|v2"` 拓不到），CHECKLIST 那一行其余引用全部重验（`checks_cartridge.py:128`、`cartridge_assets.py:100/127/158`、`contradictions.py:114/135`、`config.py:20/27`、`cache_fabric.py:21`、`benchmarks.py:85`、`bench/build_screenspot.py:1/28`），`git diff --stat 28959c5..9682657` 只动一行，门禁重跑 269 passed / ruff / filesize_check 全绿
 
 ---
@@ -362,7 +362,7 @@
     - 产品的图片腿不是开关：`retrieval.py:136` `if image is None and not thin: return {}`，稀疏页薄到 2 条以下才问图。所以这几行测的是「腿可用」，不是强行常开融合。
     - **没达到的验收线，写在这里**：用户定的验收是 recall@10 ≥0.90（n≥300）。测出来最好的一行是 **0.858**（dense 腿开、页 30、p50 416.0ms），默认配置 **0.848**（p50 67.6ms），CURRENT.md 里按 10 个 atom 问是 0.832；仓内 Mem0/Zep 式对照在 holder 作用域是 **0.866**。差距集中在图（image 0.750、ui_screenshot 0.500–0.583、video 0.583–0.708），文字的题（code 0.953、pdf 0.919）已经过了线。诚实结论：**延迟达标（281 倍于基线、p50 71.7ms），召回没达标**，剩下 4 个点是跨模态召回，不是索引规模问题。
   - 数字逼出来的决定：**dense 腿默认关**（`config.py:32 dense_embeddings_enabled=False`）。同一 300 条 holder 作用域探针上（LEGS.md），开腿 recall@10 0.832→0.845、MRR 0.683→0.663、p50 67.5ms→474.8ms。多 1.3 个点的召回、慢 7 倍、首位质量还降——默认值就该是关，腿留着（已增量、已入库）等更大的语料或更好的嵌入模型。
-  - 门禁：`pytest -q` 全绿；`ruff check` 干净；mypy 冷缓存 **24 errors / 9 files**，与 p1-6 基线（`9cb46c1` 同口径 24/9）**净新增 0**——p2-1 一度引入 +2（`vector_index.py` 与 `quant_probe.py` 的 `import sqlite_vec` 没有 stub），根因修法是在 `pyproject.toml` 的 `[[tool.mypy.overrides]]` 里声明 `sqlite_vec` 无 stub，而不是在代码里加 `# type: ignore`；`./node_modules/.bin/pyright` 对改动文件 0 errors；`bench/filesize_check` 干净；go / npm 未动。
+  - 门禁：`pytest -q` 全绿（**287 passed**）；`ruff check` 干净；mypy 冷缓存 **24 errors / 9 files**（命令 `.venv/bin/python -m mypy --cache-dir <新目录> backend/src bench`），与 p1-6 基线（`9cb46c1` 同口径 24/9）**净新增 0**——p2-1 一度引入 +2（`vector_index.py` 与 `quant_probe.py` 的 `import sqlite_vec` 没有 stub），根因修法是在 `pyproject.toml` 的 `[[tool.mypy.overrides]]` 里声明 `sqlite_vec` 无 stub，而不是在代码里加 `# type: ignore`；修在 **`71733d8`**，所以 `6cc5640` 那棵树上量到的是 26/11（review 第一轮量的就是那棵树）；`./node_modules/.bin/pyright` 对改动文件 0 errors；`bench/filesize_check` 干净；go / npm 未动。
   - 顺带修的测量缺陷：`copy_store()` 只拷 SQLite，所以任何要跑视觉腿的 harness 都得自己带上 `objects/`（25 GB，探针里用符号链接）与 `cache/clip_image_index.npy`；`bench/scale_check.py` 原本直接打开冻结基线库、把它**原地迁移**了，现改成在副本上测（`--scratch`）。产品 CLI 不在这条规则里：p2-1.4 建图片索引时 `ely-eye index-visual` 就把冻结基线从 schema 7 升到了 8，所以 p1-4.8 那两条钉的是**当前**的 mtime / sha256 / schema，并指名是哪一步改的。
 - [ ] **p2-2** 安全与隐私
   - [ ] p2-2.1 FastAPI 鉴权 + Origin 校验