主题
00 · 备份与环境基线
执行日期：2026-08-07 检查点：A 状态：✅ 完成，验收通过
这一步不产生任何科学结果，但决定后面所有结果能不能回滚、能不能对照。 计划里的硬规定：备份未验证通过之前，不许动
results/。
一、跑之前定下的目标与预期
| 项 | 内容 |
|---|---|
| 目标 | 把 R9 现有代码与全部结果冻结成可回滚的快照 |
| 备份对象 | WSL 主工作区 · F 盘副本（含 .git）· 交付物脚本与 PPT |
| 方法 | tar 归档 + zstd 压缩，不跟随软链 |
| 预期 | 三个归档全部 zstd -t 通过；软链保持为软链；关键文件抽查命中 |
| 验收标准 | 缺一项即视为备份失败，重做 |
为什么强调"不跟随软链"：工作区里有两个软链指向 D:\mrdata\ （结局数据目录 + 暴露工具表）。若 tar 跟随展开，会把整个结局数据集拖进备份， 体积暴涨且毫无意义 —— 那些是只读原始数据，本来就不需要随代码一起备份。 GNU tar 默认不跟随，但必须验证而不是假定。
二、实际执行
2.1 备份前的现状实测
| 项 | 实测 |
|---|---|
| WSL 工作区 | /home/research/mr-pipeline-r9/，总计 6.3 G |
其中 results/ | 6.3 G（30 个子项） |
results/ldsc_R9_dm | 5.6 G —— 占全部的 89% |
results/hyprcoloc_R9_dm | 562 M |
results/_region_cache | 69 M |
| 其余全部 | 合计 < 80 M |
| F 盘副本 | F:\project\mr-pipeline-r9\，123 M（无完整 results/，只有 results_key 摘要） |
| 交付物 | 结果稿脚本\ 456 K + 汇报PPT\ 146 M |
D:\mrdata\backup\ | 不存在，本次新建 |
| D 盘可用空间 | 6.2 T |
软链清单（全目录 find -type l 实测，共 2 条）：
data/exposure/protein_info.csv -> /mnt/d/mrdata/exposure/protein_info.csv
data/outcome -> /mnt/d/mrdata/outcome2.2 压缩工具选择
本机有 zstd、无 pigz／pbzip2，16 核。选 zstd -T0 -3 而非 gzip： 6.3 G 打包耗时 22 秒（gzip 单线程通常需数分钟）。
bash
tar -I "zstd -T0 -3" -cf /mnt/d/mrdata/backup/mr-pipeline-r9_full_20260807.tar.zst mr-pipeline-r9三、结果：产物与验收
3.1 三个归档
| 文件（绝对路径） | 内容 | 大小 | 条目数 |
|---|---|---|---|
D:\mrdata\backup\mr-pipeline-r9_full_20260807.tar.zst | WSL 全量（代码 + 6.3 G results） | 2.8 G | 1,810 |
D:\mrdata\backup\F_mr-pipeline-r9_20260807.tar.zst | F 盘副本（含 .git 287 条目 + 11 个未提交改动） | 115 M | 566 |
D:\mrdata\backup\F_deliverables_20260807.tar.zst | 结果稿脚本\ + 汇报PPT\ | 142 M | 76 |
3.2 验收结果（全过）
| 检查项 | 结果 |
|---|---|
zstd -t 流完整性 | 三档全 OK |
| 软链保持为软链（未被展开） | ✅ 2 条均以 lrwxrwxrwx 形式在档 |
config.yaml | 命中 |
analysis/01_screen.R | 命中 |
outcome_manifest.csv | 命中 |
results/screen_R9_dm/ | 37 条目 |
results/ldsc_R9_dm/ | 30 条目 |
R/adapters/assert_eaf.R | 命中（T1D EAF 修复的核心断言文件） |
四、★ 备份时查出的两件事
4.1 WSL 与 F 盘代码完全同步（用 cmp 逐字节比，不是 ls）
| 类别 | 数量 |
|---|---|
| 共有且逐字节相同 | 108 |
| 内容不同 | 0 |
| 仅 WSL 有 | 23（全是 .bak-* 与 __pycache__） |
| 仅 F 盘有 | 6（全是 .bak） |
意义：新目录计划从 WSL 备份解出。若 F 盘领先，解出来的就是旧代码 —— 这正是 2026-07-31「F 盘副本比 WSL 落后必须回灌」那次踩过的坑的镜像版本。 本轮实测确认不存在该风险。
为什么必须用 cmp 而不是 ls：文件名、大小、时间戳三者全同而内容不同， 是完全可能的（同一行改一个字符，大小不变）。只比目录列表等于没比。
4.2 ⚠️ F 盘 git 仓有 11 个未提交改动 —— 打 tag 前需先决定
M R/adapters/read_dispatch.R ?? R/adapters/assert_eaf.R
M R/adapters/read_tsv.R ?? tools/verify_eaf_all_outcomes.R
M analysis/01_screen.R ?? tools/verify_harmonise.R
M analysis/17_replicate_external.R ?? tools/verify_input_sanity.R
M config.yaml ?? tools/verify_t1d_eaf.R
M outcome_manifest.csv这批正是 2026-08-05 T1D 源等位频率反转修复的产物 （outcome_manifest.csv 的 eaf_orientation 字段 + 启动期 1000G 断言 + 一批 verify 脚本）。 当前最新提交是 8fbea25。
- 备份完整性不受影响 ——
tar是文件级的，工作区实际内容与.git都已在档 - 但
git tag pre-v3-rerun若打在8fbea25上会名不副实（tag 说是"重跑前最后状态"， 实际差 11 个文件） - → 是否先 commit 再打 tag，待决定；未经授权不擅自 commit
五、环境基线：基因组版本（重跑前必须钉死）
重跑涉及坐标的每一处判断（尤其 MHC 的 26–34 Mb）都依赖这张表。
5.1 主坐标系 = GRCh38 (hg38)
| 数据 | build | 出处 |
|---|---|---|
| 暴露 UKB-PPP | GRCh38 | config.yaml:216；位置列取 GENPOS (hg38) |
| 结局 FinnGen R9 / R13 | GRCh38 | config.yaml:257、USAGE.md:286 |
| deCODE（外部复制） | 常为 GRCh38 | USAGE.md:289 |
| IAMDGC 全量（AMD） | hg38，已核实 | 08_replicate_iamdgc.R:5 |
| 视网膜 eQTL | hg38 | 文件名 Retina_merged3_hg38_FastQTL_nominal_chr*.txt.gz |
5.2 两个例外
例外 1 · LD 参考面板是 GRCh37/hg19，但不需要转
/mnt/d/mrdata/ldpanel/EUR（config.yaml:51、_ld_io.R:4，实测 rs429358 = 19:45411941）。 全局 match_by: "rsid" —— LD 只与 SNP 身份有关、与坐标无关，按 rsID 匹配即可。 13_figure_locus.R:140 已把这句写进英文图注，审稿人会问的点提前堵上。
例外 2 · Mahajan T2D（DIAMANTE noUKBB）原始文件是 GRCh37 且无 rsID，必须转
共定位按 chr:pos 合并，直接挂原文件会全表失配且静默 （_region_io.R:118-120 有显式警告）。处理用 tools/lift_mahajan_hg38.R 的两跳桥接， 不依赖 liftover 链文件：
Mahajan chr:pos(hg37) --[1000G EUR.bim]--> rsID --[FinnGen R9]--> chr:pos(hg38)两端都是实测坐标表，比链文件保守：对不上的直接丢弃，不做插值。 自检位点 rs7903146(TCF7L2) 应落在 hg38 10:112998590。 产物 Mahajan_hg38_forcoloc.tsv.gz 被 05 / 24 / 26 / 27 / 35 五个脚本的 FILE_OVERRIDE 引用。
全局 liftover: enabled: false（config.yaml:144）—— 主链不需要， 唯一需要转的 Mahajan 是单独预处理的。
5.3 ⚠️ 一个必须记住的陷阱：UKB-PPP 一张表里两套坐标并存
它的变异 ID 列名是 Variant ID (CHROM:GENPOS (hg37):A0:A1:imp:v1) —— 是 hg37； 而位置列 GENPOS (hg38) 是 hg38。config.yaml:231-233 明确规定只从 ID 列取 A0/A1， 前两段坐标弃用。取错列全盘皆错，且不会报错。
5.4 对 MHC 判定的意义
v3 定的 chr6:26–34 Mb 是 GRCh38 坐标，与主坐标系一致，可直接使用。 此前实测 hg19 与 hg38 选出同一批 26 个蛋白（差集为空）—— 这不是巧合： MHC 区在两个 build 间的位移是 ~0.1 Mb 量级，远小于 8 Mb 的窗宽。
★ 本节写于当天上午，同页 §6 当天下午已推翻其口径
§6 逐字核实 Sun 2023 原文后，v4 改为使用工具表自带的 MHC 列 （= 原文的 25.5–34.0 Mb），命中 27 个蛋白，不是本节的 26 个。 差的那一个是 SCGN（落在 25.5–26.0 Mb，Zheng 口径漏掉）。
本节保留原样以记录判断过程（我在此判错过 3 次）， 但实际执行一律以 §6 与 analysis/_mhc.R 为准。
六、工具溯源：Sun 2023 原文 Methods 逐字核实（2026-08-07 补）
起因：config.yaml:157-158 称 UKB-PPP 上游 clumping「±1 Mb，排除 HLA」， 并自注「未直接读到原文全文」。若属实，MHC 区的工具来源与其他区不同质 —— 这比"要不要排除 MHC"更基础，必须在第 1 步之前查清。
方法：从 Europe PMC 取 PMC10567551（Sun BB et al., Nature 2023;622:329–338， PMID 37794186）全文 XML（205 KB）自己下载、自己读，不用摘要工具转述。
6.1 原文怎么说（Methods · "Definition and refinement of significant loci"）
"We used a conservative multiple-comparison-corrected threshold of P < 1.7 × 10⁻¹¹ (5 × 10⁻⁸ adjusted for 2,923 unique proteins) to define significance. We defined primary associations through clumping ±1 Mb around the significant variants using PLINK, excluding the HLA region (chromosome 6: 25.5–34.0 Mb), which is treated as one locus owing to complex and extensive LD patterns. Overlapping regions were merged into one, deeming the variant with the lowest P value as the sentinel primary associated variant."
cis 的定义（Results，原文两处）：
"…1,954 of 2,922 proteins having a cis association (within 1 Mb from the gene encoding the protein)." "A total of 1,955 of the 14,287 primary associations were in cis and 12,332 were in trans (>1 Mb from the gene encoding the protein). In total, 60%, 86% and 92% of the cis associations were within the gene, 50 kb and 100 kb from the gene start site, respectively."
★ 数据来源验证通过：本地工具表 protein_info.csv 实测 cis/trans == "cis" 共 1,955 行 / 1,954 个唯一蛋白 —— 与原文两个数字逐位吻合。
6.2 「excluding」是什么意思 —— 此前理解偏了
原文措辞确实是 "excluding the HLA region"，所以 config.yaml 的字面转述没错。 但含义不是"把 HLA 的变异或蛋白删掉"，而是：
该区不参与 ±1 Mb 的滑窗 clumping，整个 25.5–34.0 Mb 被当作「一个 locus」处理。
结果是：MHC 区的蛋白照常有工具，工具也照常在表里（实测 27 条 cis 记录）。 先前担心的"MHC 蛋白被上游删掉了"不成立。
6.3 ★ 但「规则不同质」成立，而且能实测出来
工具表自带 Region ID / Region Start / Region End 三列，实测：
- 27 条 MHC cis 记录的
Region ID全部 = 3760（同一个区域） - chr6 上有 580 行的区域边界恰好是 25.500–34.000 Mb（宽 8.500 Mb） —— 即原文那句硬编码的 HLA 区块
- 部分行的边界更宽（22.658–34.000、23.016–35.170、23.412–37.878 Mb 等）， 是该区块与相邻 ±1 Mb clump 合并后的结果（对应原文 "Overlapping regions were merged into one"）
对照非 MHC 区：每 ±1 Mb 一个 clump 区域，一个蛋白可有多个 primary。
| 非 MHC 区 | MHC 区 | |
|---|---|---|
| 区域怎么划 | ±1 Mb 滑窗 clumping | 整块 8.5 Mb（合并后最宽 ~15 Mb）当一个 locus |
| 哨兵怎么选 | 该区域内 P 最小者 | 整块内 P 最小者 |
| 一个蛋白可有几个 primary | 多个 | 该区块内只有一个 |
推论（可写进 Limitations）：若某 MHC 区蛋白的最强信号距其基因 > 1 Mb， 它会被标为 trans，该蛋白就根本不出现在 1,954 个有 cis 关联的蛋白里 —— 这是一种不可见的选择性缺失，从下游数据中看不出来。
实测缓解：已入选的 27 条 MHC cis 哨兵，"距基因"列多数为 0（落在基因内）， 其余最大仅 4,997 bp。即在已入选者当中，哨兵都紧贴基因，与其他区的 cis 工具可比。 → 该问题降级为「已检查、影响有限」，但不可见缺失部分应在 Limitations 如实写明。
6.4 ★ 三个坐标口径的实测差异（决定 in_MHC 怎么算）
| 口径 | 区间 | cis 行数 | 唯一蛋白 |
|---|---|---|---|
工具表自带 MHC 列（作者标记） | — | 27 | 27 |
| 坐标 25.5–34.0 Mb（Sun 2023 原文） | chr6 | 27 | 27 |
坐标 25.0–34.0 Mb（代码 35/37 现状） | chr6 | 27 | 27 |
| 坐标 26.0–34.0 Mb（Zheng 2020） | chr6 | 26 | 26 |
- 作者
MHC列与 25.5–34.0 Mb 坐标双向差集为空 → 证实作者就是按原文那个区间打的标 - 与 Zheng 口径只差一个蛋白：
SCGN（位置 25.660 Mb，落在 25.5–26.0 Mb 之间） SCGN不在旧的显著集里 → 两个口径在显著集上给出完全相同的 11 个 MHC 蛋白
6.5 由此产生的三条更正
| 此前说法 | 更正 |
|---|---|
| 「工具池内 26 个 MHC 蛋白」 | 27 个（作者口径）。26 是 Zheng 口径，少一个 SCGN |
「35_reverse_mr.R / 37_drug_target_phewas.R 写 25e6 是坐标写错」 | 收回。25.0–34.0 在本数据上与作者口径结果完全相同，不是 bug；且 25.5 才是原文值，比 26 更贴近来源 |
| 「上游排除 HLA → MHC 蛋白工具可能不同质甚至缺失」 | 一半对：不是删除，工具都在；但哨兵选择规则确实不同质（见 6.3），且存在不可见的选择性缺失 |
6.6 对第 1 步的直接结论
in_MHC 直接采用工具表自带的 MHC 列，不自己按坐标重定义。理由：
- 它是数据提供方按其实际施加的规则打的标记 —— 是事实，不是我们的再定义
- 与原文坐标 25.5–34.0 Mb 实测等价，既符合原文又可核
- 同时另存
in_MHC_zheng（26–34 Mb）供与 Zheng 2020 等文献口径对照 —— 差别仅SCGN一个
这比原计划「抽一个坐标 helper 统一四处」更简单也更可靠：不需要我们自己划线。
6.7 顺带复现的旧数字（尚未重跑，仅读旧结果）
并发症五个结局的显著集：Retinopathy 24 · Maculopathy 19 · Nephropathy 9 · Neuropathy 5 · NeovascGlaucoma 0 = 57 对 / 31 个唯一蛋白 —— 与既有记账一致。 其中 MHC 蛋白 11 个（两口径相同），独占 30 / 57 = 53% 的显著对。
七、怎么解读 / 去向
| 问题 | 回答 |
|---|---|
| 这一步能下什么结论 | 工程性结论：快照可回滚；WSL 与 F 盘代码同源；坐标系已钉死。方法学结论一条：MHC 区工具的哨兵选择规则与其他区不同质（§6.3），已实测其影响有限但存在不可见缺失 |
| 进正文还是补充 | 备份与同步核验都不进（属 Data/Code availability 与可复现性材料） |
| 哪部分进补充方法 | §5 基因组版本与跨 build 对齐（审稿人常问）；§6.1 工具定义与 cis 判定的原文依据 |
| 哪部分进Limitations | ★ §6.3 —— MHC 区「整块一个 locus」导致的哨兵规则不同质与不可见选择性缺失 |
| 后续依赖 | §6.6 定下第 1 步 in_MHC 直接用工具表自带 MHC 列（原计划的坐标 helper 改为交叉验证用）；§8.2 的 config.yaml 改写留到第 1 步 |
八、遗留待决
- F 盘 11 个未提交改动是否先 commit 再打 tag（见 §4.2）
config.yaml:157-162的instrument_definition需改写 —— 它现在自注 「未直接读到原文全文」，且把 "excluding the HLA region" 转述成容易误解的「排除 HLA」。 §6 已读到原文，应据实重写并去掉那句自注。留到第 1 步一并改。- 计划第八节的两件事仍未做：逐字读 Yuan 2023 STAR Methods · 阳性对照。 （C1R 漏斗数字核实一项，因 §6 已建立"自己下 XML 自己读"的可行路径， 同法可解 —— C1R 是 medRxiv 预印本，可试 Europe PMC 或 bioRxiv API。）
本节原有第 3 条「⚠️ 应在第 1 步之前读 Sun 2023 原文 Methods 确认」—— 2026-08-07 已完成，结论见 §6，该条结案。