test(12): H-LAYOUT 与「包内容」两个假设均被证伪 —— 剩余自变量收敛到「谁在发 HTTP」

实验 A/B (scripts/experiment_layout_verify.py --solve, 真解题):
  按本次构建槽位序 vs 仓库旧模板 -> 两组 9/9 全 12  => 槽位序不是自变量
严格对照(决定性): 同一批取值、同一长度 920、只颠倒槽位序 -> 6/6 全 12

实验 C: 本会话真机真实 collect(TDC.getData(true), 1012 字符) 原样交 Python 发
  -> 4/4 全 12  => 包内容不是自变量

附带关键事实: 12 只在「答案正确」后才判; 答错一律 50/9。
  滑块题型下按点选坐标答(必错)两组都是 50, 无区分度; 换成真解后立刻全 12。
  这解释了早期多轮对照为何无效 —— 今后做 12 的 A/B 必须真解题。

账本: §三 新增两条证伪; 新增已知 #39(12 的判定前提) 与 #40(剩余自变量+收口实验)。

har/1ms_dianxuan/PROGRESS.md

@@ -68,6 +68,8 @@
 | 35 | **运行时反证通过：静态导出的 require 序 == 运行时真实 require 序（逐项一致）** | 在真机 iframe（`tdc.js` 实际执行的上下文，`window.TDC.getData` 就在这里）里包一层 `Function.prototype.apply`，模块工厂调用形状 = **4 参 `[object,object,object,function]`**（require 是最后一个），按工厂实例分组记账。触发一次刷新后取运行时串，用 `tools/cdp_script_source.js`（Debugger.scriptParsed + getScriptSource）取到**运行时真正执行的那份 tdc.js**（exactly-once，不能用重新 fetch 代替——#29 每次返回不同构建），两边串：<br>静态 = 运行时 = `[8,9,10,13,14,15,16,17,18,19,20,21,23,24,25,30,31,32,34,36,37,1,38,39,40,41,42,43,44,47,48,49,50,51,56,57,58]`（37 项，逐位相同）<br>→ 由此可判定：之前"部分槽语义对不上"是**标注启发式**的问题，**顺序本身正确**。工具：`scripts/experiment_require_order.py` | 确证 |
 | 36 | **「清单项 → cd 槽」的精确规则（同一构建端到端校验确立）** | 装配循环（线上构建 `@4362`，370 条）分支树已读通：<br>`if(!item) continue;` `v,w,kind = item.get();`<br>· **`kind===2`（`@4820`）**：把 `r3` 清空转存 `r4`（`@4860`），`r4` 在收尾 `@4905` 二次加工后**拼回**，因此**仍产出 1 槽**（实测第 0 项，随机串 `vXc29RxhvT34Q…`）<br>· `v===null/undefined`（`@4799`）→ `out += "null"`<br>· `typeof v==="number"`（`@4738`）→ `out += (v||0)`<br>· **`kind===1`（`@4724`）→ `out += v` 原样拼**：返回值是 JSON 碎片串；**只按括号外的逗号**切槽 —— `'[]'`/`'[360,360]'`/`'["zh-CN","zh"]'` 内的逗号不构成新槽，而 `"641547489,1791732001"` → 2 槽<br>· 其余（`@4703`）→ `out += '"' + v + '"'`<br>· 收尾 `@4753`：`typeof w === "number"` 才再 +1 槽（实测 kind=2 的第二元素是 null，不触发；此路径本次未命中）<br>→ **37 项 → 38 槽**，仅第 33 项（模块 1）占 2 槽。工具：`tools/tdc_slotmap.py`（`--items` 运行时取样 + `--plain` 明文对拍） | 确证 |
 | 37 | **按构建生成 collect 的工具链已跑通（含回环自测）** | `tools/tdc_collectgen.py`：静态导出槽位序 → 按 #36 规则算「项→槽」→ 重排 → 该构建密钥加密。<br>实测（同一构建）：37 项 → **38 槽**，明文 686B / collect 920 字符；**解密回环逐字节一致**，cd 与真机样本逐槽相同。<br>规则修正（重要）：`kind=1` 的串**只按括号外逗号**切槽 —— `'[]'`/`'[360,360]'`/`'["zh-CN","zh"]'` 内的逗号不构成新槽；`kind=2` 的项**仍产出 1 槽**（转存 r4 后在收尾 @4905 拼回）。<br>回归：`tcaptcha/tests/test_collectgen.py`（已并入 selftest） | 确证 |
+| 39 | **12 只在"答案正确"之后才判**（排查方法学上的关键事实）| 答错一律 50/9：本轮滑块题型下（我们按点选坐标答，必错）两组都是 50；换成真解（text/icon）后立刻全是 12。→ **任何用"答错"做的对照实验都没有区分度**，这解释了早期多轮对照为何无效。今后做 12 的 A/B 必须 `--solve` 真解题 | 确证 |
+| 40 | **"谁在发 HTTP"是 12 的剩余唯一自变量**（结论，待最后一步坐实）| 证据链：① 槽位序证伪（§三）；② 包内容证伪（本会话真实 collect 由 Python 发仍 12）；③ 已知 #26：宽松 aid 190758559 上 **httpx + 无 cookie + 无头保真** 也能 0 —— 说明"请求侧细节"对宽松 aid 无所谓，但对 195672344 不够。④ 真机同 aid 只出 50/9/0（#25）。→ 剩余差在**会话↔请求方绑定**。**收口实验**：把同一 sess/eks/tkid + 同一 collect，分别由浏览器发与 Python 发，比较 errorCode | 结论（待收口） |
 | 38 | **纯离线生成还没打通（诚实标注）** | 当前 `--from-sample` 依赖**一份同机的真机明文**做重排；`--values`（语义名→值）需要调用方提供取值字典。**仍缺**：纯算地为每个语义名算出值（多数是静态环境量可配置，但 canvas/WebGL 指纹只能取自真实环境）。这一步完成前，不能声称"纯离线过风控"。 | 状态说明 |
 
 ---
@@ -101,6 +103,9 @@
 | **"密钥字必须靠 Node 插桩才能拿到"** | `tcaptcha/tdc_key.py` 纯 Python 零 Node 复算，6/6 构建与 Node 逐字一致（已知 #22）→ Node 降级为兜底 |
 | **H3（captcha 域腾讯云登录 cookie）能解决 12** | 用**抓包里的真实 cookie 值**（uin/skey/qcmainCSRFToken/intl）重跑，仍 12（`scripts/experiment_h3_cookie_ab.py --only b`，2026-10-11）→ 与早期结论一致，H3 确凿排除 |
 | **HTTP/TLS 传输指纹是 12 的自变量** | `curl_cffi`(impersonate=chrome: JA3/JA4 + HTTP/2 + Chrome 头序) + 真实 cookie，仍 12（`scripts/experiment_transport_ab.py --only b`）→ 传输层排除 |
+| **collect 的"内容/取值"是 12 的自变量**（2026-10-12 **证伪**）| 用**本会话真机真实产物** （`TDC.getData(true)`，1012 字符，取值/顺序/密钥全对）原样交给 Python 发：**4/4 全是 12**。→ 包内容**不是**自变量；只剩 **"谁在发这个 HTTP"**（会话↔请求方绑定）|
+| **H-LAYOUT：collect 的 `cd` 槽位序是 12 的自变量**（2026-10-11 晚提出，2026-10-12 **证伪**）|
+两个独立实验都**否定**它：<br>① A/B（`scripts/experiment_layout_verify.py --solve`）：按本次构建槽位序生成的 collect vs 仓库旧模板，**两组 9/9 全是 12**；<br>② **严格对照**（决定性）：同一批取值、**同一长度 920**、只把槽位序**完全颠倒**，两组 **6/6 全是 12**。<br>→ **槽位序不影响 verify 结果**。已知 #31（槽位序按构建随机化）与 #34/#35/#36/#37（可静态导出）**仍然成立且是有价值的资产**，但它们**不是 12 的原因**。|
 | **请求头保真度是 12 的自变量** | 按真实抓包逐 endpoint 保真：资源 GET 用 `Sec-Fetch-Dest=script/image` + `Mode=no-cors` + `Storage-Access=active` + cookie，POST 用 `empty/cors` + Origin 且**不带** cookie；仍 12 |
 | **collect 明文结构/取值是 12 的自变量** | ~~我们的 collect 明文与 1ms 真实成功样本逐字节同构（同 1353B、同字段序、同取值，仅回填轨迹/时间戳/盐），仍 12~~ ⚠️ **该否定实验本身有缺陷（2026-10-11 晚推翻）**：所谓"同字段序"只是与**模板来源的那一次**样本比，而 `cd` 槽位序**按会话随机**（已知 #31），所以它没检验到真正会变的维度。修正后重开为：**"cd 槽位序必须与本次会话构建一致"是 12 的头号可疑自变量**（已知 #32）|
 | **H5：1ms 后端用 `identity_context` 把会话标记为可信** | 拿抓包里**签名过的** `identity_context`(599B `emctx1.*`) 先调 `POST /api/v1/captcha/params`（响应与不带时**完全相同**，无额外 token）再解题，仍 12 → H5 排除 |
@@ -147,29 +152,27 @@ TencentCaptchaClient(telemetry_mode="python_keyed")     # 默认
      ④ 仓库在用的模板槽位序 == `签到成功-1.har` 那一次（已知 #32），而 `generate_collect_success()`
         只回填轨迹/时间戳/entry_url —— **槽位序仍是那一次的**。
 
-   * **H-LAYOUT（头号假设，可证伪）**：服务端按"**本次会话构建**"的槽位表解释 `cd`。
-     我们用**别的会话的槽位序**发出的 collect 会被读成"自相矛盾的环境"
-     （如 `cd[1]` 该是 `[360,360]` 却是 `"MacIntel"`）→ 风控判 **12**，与答案对错无关
-     （答案错理应是 50/9）。
-     这条同时解释了旧账本的所有负结果：换 IP / 换遥测后端 / 换传输指纹 / 换 cookie / 长静默
-     **都不动槽位序**；而宽松 aid（190758559 / 雨云）**不交叉校验布局**，所以 0。
+   * ~~**H-LAYOUT（头号假设）**：槽位序错导致 12~~ → **已证伪（2026-10-12，见 §三）**：
+     按构建槽位序 vs 旧模板 **9/9 都 12**；同一批值只颠倒顺序（同长度 920）**6/6 都 12**。
+     **槽位序不是 12 的自变量。**
+
+   * **当前最可能的自变量（按成本排序）**：
+     (a) **collect 的内容/取值本身**（不是顺序）：真机那份 38 槽里含 canvas/WebGL/时间戳等
+         **当次会话真实产物**；我们用"旧模板的值"无论怎么排都不是**本会话**的值。
+         判定实验：**在真机 iframe 里直接 `TDC.getData(true)` 拿到本会话的 collect，
+         原样交给 Python 发**（不重排、不改值）——若 Python 也 0，则是"值"的问题；
+         若仍 12，则排除包内容，只剩"请求方/会话绑定"。
+     (b) **会话↔请求方绑定**：sess/eks/tkid 与"发出这个 HTTP 的一端"存在绑定
+         （同包浏览器发 0、Python 发 12）。判定实验 = 上面 (a) 的同一发即可区分。
+
+   建议下一步（一条命令，能同时判定 a 与 b）:
+     真机 iframe: `TDC.getData(true)` -> collect     (本会话真实产物)
+     同一 sess/eks/tkid, 分别用浏览器发 / 用 Python 发, 比较 errorCode。
+
+   * 附带事实（重要，改变了排查方向）：**12 只在"答案正确"之后才判**。
+     答错一律 50/9（本轮两组在滑块题型下都是 50）——所以任何拿"答错"跑出来的对照都无效。
+     这解释了为什么早期很多对照实验没有区分度。
 
-   * 下一步三件事（按顺序做）：
-     (a) **决定性实验 A（最便宜，先做）**：真机页面里 hook 掉 `cap_union_new_verify` 的发送，
-         让 widget 把 collect **组好但不发**；再把这一包原样交给 **Python** 发。
-         若 Python 也 0 → "谁在发 HTTP"彻底无关，12 只剩"包内容"一个自变量 → 坐实 H-LAYOUT。
-         若 Python 仍 12（而同一包在浏览器里是 0）→ 说明还有"会话↔连接"绑定，需换实验 A'。
-     (b) **拿到本次构建的槽位表** —— 已打通静态提取（已知 #33/#34）：
-         顶层 62 个模块工厂注册表 → 清单模块 `arr[arr.length] = require(N)` 的**顺序即槽位序**
-         → `tools/tdc_layout.py <tdc.js>` 直接导出。
-         ⚠️ 残留：逐槽**语义标签**还没全对齐（已精确命中 `cd[3]←c.navigator.userAgent`、
-         `cd[5]←c.navigator.languages`，其余若干槽仍对不上）。
-         两个待收口点：① `get` 闭包"取值寄存器"的判定规则要覆盖全部模块形状；
-         ② **运行时反证**：在真机页面里包一层 `require`，把清单模块实际按顺序请求的 id 打出来，
-            与静态导出串对拍（一条命令就能证伪/证实静态提取）。
-     (c) **验证**：collect 按 (b) 的槽位序重排后重发 195672344，期望 **12 → 0**。
-         注意：既然 tdc.js 按请求随机（#29），Python 客户端必须用**它自己那次 prehandle 拿到 sid
-         之后请求的那份 tdc.js** 的槽位表，不能用缓存/模板。
 2. **可复现靶子（新增资产）**：aid 190758559 / `mliev.login.wang` 短信登录 —— **可反复测**，
    用来回归"纯算链路是否完好"（1ms 每天只能试一次，不适合做回归）：
    ```bash