docs: 架构定稿——四段流水线、两个库与待定问题

负责人 2026-10-16 定：数据流为「医院原始资料->中间文件->给专家的资料库 & 标准答案库」；
两个库和中间文件都用文件夹，SQLite 只用于调模型账本；调模型用 PolyGateway；CEUS 直接逐个
迁移；数据格式和口径以 40 例交付包为准。存储与迁移方案先由两个中立子 Agent 独立评审。

- design 0002：八条决定及负责人原话（化名与打乱顺序一条为 Agent 提出）
- explanation/结构.md 对照 ClinDB 的结构文档重写：切分原则、完整范围、12 个模块与依赖、
  边界、两个库与 CEUS 中间文件的内容、目录与检查、规模、推进顺序
- research-wiki/待定问题/：绿框、参数冻结、排除标准、跨表不一致四个问题；定了就删
- AGENTS.md：事实来源加「交付资料的格式和口径以最新交付包为准」
- .gitignore 与 pre-commit 拦截 library/、answers/、work/

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

research-wiki/待定问题/01-医生画的绿框能否作为输入.md

@@ -0,0 +1,27 @@
+# 01 医生画的绿框能否作为输入
+
+提出：2026-10-16 中立评审（架构评审 B），负责人同意留待以后定。
+
+## 问题
+
+交付的 CEUS 视频里，医生已经在病灶上画了绿框。旧项目的 ROI（病灶区域）主要来自这个绿框：非提示帧上最终轮廓 = MedSAM2 结果 × 0.25 + 绿框先验 × 0.75，提示帧上 100% 是绿框（旧代码 `reference/CADx-4-CAD/app/domain/ceus_roi/polygons.py:531-541`，配置 `config/ceus_roi_default.yaml` 的 `roi_shape` 段）。
+
+## 为什么要紧
+
+- 决定论文能不能说「AI 自动分割病灶」。如果 ROI 实际上是医生画的，论文要么如实写「医生给定病灶位置」，要么补一组「只用绿框 vs 融合 MedSAM2」的对比。
+- 决定 CEUS 迁移时融合权重怎么定。
+- 负责人 2026-06-09 曾说「生产环境不预给 ROI」（记忆），而现在的交付视频都带绿框，两者需要对齐。
+
+## 选项
+
+1. 绿框是合法输入（相当于医生框选病灶，系统负责后续定量），论文如实写明。
+2. 绿框只作第一帧种子，其余交给分割模型，需要重新定融合权重并验证。
+3. 不用绿框，系统自己找病灶（难度和工作量都大得多）。
+
+## 倾向
+
+暂无。
+
+## 等谁定
+
+负责人，可能要问临床方：今后真实使用时医生是否愿意先框一下。

research-wiki/待定问题/02-CEUS参数何时冻结与开发测试集.md

@@ -0,0 +1,25 @@
+# 02 CEUS 参数何时冻结，开发集和测试集怎么分
+
+提出：2026-10-16 两位中立评审都提到，负责人同意留待以后定。
+
+## 问题
+
+CEUS 定量有很多参数（拟合质量门、暗区阈值等），旧项目的拟合参数标注为「工程验收占位，代表性开发集标定后一次性锁定」（旧 `config/ceus_roi_default.yaml` 的 `fitting` 段）。会诊的提示词和流程也要调。如果一边在 40 例上调这些参数、一边看同一批 40 例的诊断准确率，就是隐性泄露：结果会偏乐观，审稿人会质疑。
+
+## 为什么要紧
+
+决定论文里的准确率能不能信。必须在看诊断结果之前定。
+
+## 选项
+
+1. CEUS 参数只按它自身的质量指标调（拟合是否通过、与医生 AT 的误差），不看诊断结果；40 例整体当开发集，等后续病例（约 200 例）再报正式结果。
+2. 从现有病例中留出一部分作测试集，锁定后不再碰。
+3. 不切分，只如实记录在这批病例上试过多少种配置（旧项目当时的做法，旧 `research-wiki/explanation/evaluation.md` 第 7 节自认「理由只够一半」）。
+
+## 倾向
+
+评审 B 倾向选项 1。负责人未定。
+
+## 等谁定
+
+负责人，可能要和临床方商量（旧项目里这件事挂在 Linear《研究规则》上）。

research-wiki/待定问题/03-病例排除标准.md

@@ -0,0 +1,27 @@
+# 03 病例排除标准
+
+提出：2026-10-16 中立评审（架构评审 B），负责人同意留待以后定。
+
+## 问题
+
+40 例里有几类特殊病例，怎么处理需要事先写定：
+
+- 旧代码 CEUS 追踪失败 6 例：3 例分屏识别失败，3 例在左半边找不到绿框（其中 1 例已确认造影画面在右半边）。来源：远程 `data/交付包_20260908_40例_result/结果清单_20261016.md`，2026-10-15 读过。
+- 交付说明标明 3 例用肝实质替代正常胰腺作参照、1 例没有参照（`data/交付包_20260908_40例/交付说明_40例_20260908.md`）。
+
+## 为什么要紧
+
+如果看了诊断结果之后再决定排除哪些病例，就是选择偏倚。标准必须在看结果之前写定。
+
+## 选项
+
+- 技术失败的病例：修好算法再纳入 / 记为「超声不可评价」但仍参与会诊 / 排除。
+- 参照组织特殊的病例：纳入并分层分析 / 排除依赖参照的指标 / 整例排除。
+
+## 倾向
+
+暂无。
+
+## 等谁定
+
+负责人，可能要和临床方商量。

research-wiki/待定问题/04-交付数据的跨表不一致.md

@@ -0,0 +1,19 @@
+# 04 交付数据的跨表不一致
+
+提出：2026-10-15 深读旧项目时发现（「资料与答案隔离」那条线），负责人尚未看过。
+
+## 问题
+
+40 例交付包里，有 6 例在临床工作簿和超声报告工作簿之间对不上：年龄 6 例不一致，诊断 2 例不一致，性别 4 例不一致（性别按临床表 1=男、2=女 推断，编码未经确认）。超声与 MR 两份报告表之间诊断 40/40 一致，所以对不上的只在临床表这一侧。核对脚本只输出计数，2026-10-15 运行。
+
+## 为什么要紧
+
+- 可能是临床表的编号和报告表不是同一个病人。如果是，临床专家看到的是别人的资料，诊断金标准也可能取错。
+
+## 选项
+
+问医生：这 6 例临床表的编号是否对应同一个病人；以哪份表的诊断为准。
+
+## 等谁定
+
+临床方回答，负责人转达。

research-wiki/待定问题/README.md

@@ -0,0 +1,7 @@
+# 待定问题
+
+还没定、但迟早要定的问题，一个问题一份文件，文件名 `NN-简短主题.md`。
+
+- 每份写清：问题是什么、为什么要紧（不定会影响什么）、有哪些选项、目前的倾向（注明是谁的倾向）、证据在哪、等谁来定。
+- **定了就删掉这份文件**：结论写进 `design/` 的新决策文档（或负责人认可的其他位置），删除和写入放在同一个提交里，提交说明写明去向。
+- 编号只增不复用。