# 目录恢复范围

扫描 21 个 DLL/EXE，观察到 9243 个不同源码路径、10878 个字符串位置。安装程序范围有 2687 个文件、643 个目录。

源码树来自 PE 中残留的源码位置字符串，文件正文没有还原；不应建立同名空 .cc 文件后称为源码恢复。安装清单是实际存在的文件路径，两者分开交付。每个路径的 `locations[].file` 和 `role` 可追溯来源。ASCII/UTF16 精确偏移与样本 SHA256 在 JSON 中。所列范围已遍历，不意味着原始源码仓库或编译文件全集完整。

## 扫描范围

`observed-source-tree.json` 的 `artifacts` 列出全部 21 个 DLL/EXE、角色、字节数和 SHA256。角色是文件名启发式分组，不是来源证明：`tabbit-core` 2 个，`chromium-likely` 7 个，`graphics-likely` 7 个，`runtime` 3 个，`installer` 1 个，`updater` 1 个。安装目录没有找到 PDB/DWO/DEBUG 调试文件。

## 根仓库全集对比

固定 tag 的 Chromium 根仓库 Git 树（commit `a654841425914cbb703a2931e07b70a83aedbafd`）有 **502,668 个文件、44,435 个目录**。本机 21 个 DLL/EXE 中观测到的 9,243 条源码路径只占根仓库文件的 **1.84%**，不能称为全集。

`chromium-tree-comparison.json` 将全部 9,243 条路径与根仓库文件树逐条比较：**6,928 条存在**，**2,315 条不在根仓库**。缺失路径包含第三方/DEPS 外部依赖、V8、部分网络库以及 Tabbit 产品路径。根仓库文件数也不是实际 Windows build 的已编译文件数；仓库还包含测试、文档、生成工具和非本平台文件。

## 固定上游路径比对

`upstream-path-comparison.json` 对 `chrome/`、`tab/` 及产品关键词命中的 2,526 条候选路径，向固定 Chromium `154.0.8037.58` 的 GitHub mirror 发起 HEAD 请求。结果：2,360 条存在，166 条返回 404，0 条未知。404 中 **150 条**位于 `chrome/` 或 `tab/`，在目录浏览器中作为“Tabbit 新建路径”候选；其余 16 条是第三方/依赖路径，不进入主筛选。404 只是 finding aid，不是完整源码 diff。

## 为什么路径会留在 PE 中

`section-distribution.json` 将 10,878 个源码路径字符串位置逐项映射到 PE section：全部位于只读数据区 `.rdata`，其中 ASCII 10,868 个、UTF-16LE 10 个。它们不是 PDB 调试目录，更像编译期 `__FILE__`、`CHECK/DCHECK`、日志、错误上报、崩溃定位和 Rust panic location 保留的字符串字面量。

预处理器把 `__FILE__` 或 source-location 宏替换成路径字符串，字符串进入 `.rdata`；即使安装包没有发布 PDB，这些运行时可用的定位字面量仍然存在。反向影响是：文件可能被包含或参与编译却没有留下路径字符串，因此 `.rdata` 路径集合不能当作完整编译单元清单。