登记簿，活文档。 一行 = 一个已知的方法学或代码缺陷。
| 日期发现 | 现象 | 影响范围 | 状态 | 报告 | 修复提交 |
|---|---|---|---|---|---|
| 2026-08-29 | 二值 CE 在图密度 >0.23（19 导头皮）时退化为密度的函数，与递归结构无关 | PanelC / ds005620 全部分析（DIAG-002 §9） | 已确认，导致换用颅内 SPES 数据（PRIOS） | DIAG-002 | 无代码修复，属方法学限制 |
| 2026-08-29 | 条件转移熵在慢波主导信号上因残差趋零而虚高 | PanelC / ds005620（DIAG-002 §1-5） | 已确认，同上 | DIAG-002 | 预白化验证过但真实数据未达阈值，见 §8 |
| 2026-09-02 | 零模型允许「从未被刺激的电极」发出边，观测图不允许；corr(源占比, CE_excess)=+0.97 |
PRIOS §6.4 逐条件检验；主检验偏差小部分相消 | 已复核 | DEF-001 | 见下方"修复"列 |
| 2026-09-02 | 节点集用全通道而非预注册规定的双角色电极 | PRIOS 全部结果（节点数、密度阈值、上一条缺陷的严重程度） | 已复核 | DEF-001 §5d、DEC-001 | 见下方"修复"列 |
| 2026-09-02 | 固定 d*=0.05 让零模型基线随节点数从 0.52 漂到 0.98，正负空间不对称 | PRIOS 跨密度稳健性分析 | 已确认，未修复（留给未来数据集） | DEC-001 | 无——事后改会构成挑参数 |
| 2026-09-02 | PRIOS 逐次运行结果不完全可复现：n_sig（显著边数）与下游 ce_excess 在同一份代码、同一份数据上每次运行都有小幅漂移 |
PRIOS 全部结果的精确数值（不影响方向与判决，见下方说明） | 已修复 | 无独立报告，见下方 | prios_分析.py 第 145-158 行；回归测试 test_reproducibility.py |
code/pipelines/prios/prios_分析.py：
1. weighted_graph 增加 src_idx 返回值（被刺激过的电极下标集合）
2. null_stats 增加 src_idx 参数，限制候选边槽
3. 节点集从「全部共同通道」改为「双角色电极」（matched 导出的源与共同通道的交集）
4. metrics 同时算新旧两种零模型，键名 _srcfix 后缀区分，两版并存不覆盖
验证：纯随机图仿真复现了真实数据里的偏差模式（code/simulations/零模型源限制偏差检验.py）；
六被试重跑后自洽检查通过（源占比恒为 1.00 时新旧零模型逐位相同，差 0.0000）。
结果：主检验 p 从 0.0625 → 0.0938 → 0.2188（三个版本，方向不变，判决不变）。
迁移后为核实搬迁没有改变计算结果，重跑了一次 PRIOS 主分析——同一份代码、同一份数据，
sub-PRIOS01 清醒条件的显著边数从迁移前的 1181/1196 变成迁移后的 1185，
ce_excess 也有小幅漂移（约 0.01–0.05 量级），但节点数、方向、判决全部不变。
根因已用对照实验坐实：PYTHONHASHSEED 固定时（跑两次都设 PYTHONHASHSEED=0），
两次结果逐位相同（n_sig=1168 两次都一样）；不固定时（Python 默认每进程随机取种）
第三次跑出 n_sig=1176。即代码某处的字符串 set/dict 迭代顺序影响了计算结果，
而这个顺序被 Python 的哈希随机化打乱。
这不是本次迁移引入的——移动文件、改导入路径不会影响这件事；三次独立运行 （迁移前两次、迁移后一次）在移动前就已经互不相同，证明这个问题一直都在， 只是没人测过是否可复现。
影响评估：只影响精确数值，不影响任何已发布结论——三次独立运行里节点数、 效应方向、显著性判定全部一致，PRIOS 报告的"不确认、不证伪、功效不足"判决不受影响。
具体是哪一行：prios_分析.py 里 matched = {p: ... for p in set(cnt["clin"]) & set(cnt["prop"])}——
pair 是字符串二元组，set(...) & set(...) 的迭代顺序看这些字符串的哈希值，
被 PYTHONHASHSEED 打乱。matched 的键序变成 pairs 的顺序，传进
weighted_graph()；weighted_graph 内部对 pairs 的循环共享同一个有状态的
np.random.default_rng(seed)，谁先被处理谁先消耗掉哪一段随机数——顺序一变，
build_epochs 里的降采样（试次数超过上限时）就抽到不同的试次子集，
下游 N1 峰值、显著性判定、n_sig 全部跟着变。
修法：把 set(...) & set(...) 包一层 sorted(...)（第 156 行），
两个调用处的 list(matched) 也改成 sorted(matched)（第 174 行）——
双保险，就算以后 matched 的构造方式再变，调用处仍然显式排序。
回归测试：code/pipelines/prios/test_reproducibility.py。真起两个不同
PYTHONHASHSEED 的子进程各跑一次 sub-PRIOS01，断言全部字段逐位相同。
撤掉修复验证过会变红：git stash 掉修复后跑，exit=1，
报的第一处差异是 .conds.clin.d.0.02.cm: 0.0916 != 0.0896；
git stash pop 恢复后再跑，exit=0。
六被试全量重跑，确认判决不变：方向在全部 18 个「（旧零模型/修正零模型/
本次修复后）× 6 个密度」组合里保持一致，均值全部为正；sub-PRIOS01/04/05 的
清醒−麻醉差值符号与修复前完全一致，其余三个被试差值符号也未翻转。
主检验（d*=0.05）从 4/6 同向、p=0.2188 变成 4/6 同向、p=0.4375——
同向人数没变，p 因为 Wilcoxon 用的是差值大小的秩、不只看符号，
换了一组更精确（不受随机哈希污染）的数字后秩序跟着微调，不是新的发现。
未处理，按任务要求留白：docs/studies/03-prios/PRIOS完整方法学与结果报告.md
与 缺陷报告_零模型源限制_2026-09-02.md 里引用的具体数字（p=0.2188 等）
是这次修复之前的版本，此次任务的指令是"不要改动已发布的结论文档正文"，
所以没有同步。这意味着现在报告里的数字和修复后的可复现结果对不上——
要不要把报告更新成新数字，需要你另外拍板；这次重跑的输出没有落盘（只用于
核对判决方向，核对完即删），如果决定要更新，需要重新跑一次。