保留的 JavaScript 模块引用验证¶

跟踪 #4092（属于 #4027）以及 #4091 中的决策。这用于验证现有工具的数据投影，无需代码模式主机或 SDK。机器可读结果固定基础修订版本、已执行源哈希、样本、tokenizer 和资源观察。

真实应用与问题¶

官方 Obsidian 1.14.4 ASAR，27,477,966 字节，SHA-256 146ef8470d8cbb4a6db209bdc19bf2bad13350444186c0fd93c31087b142b92f。 官方 gzip 的 SHA-256 为 d1ed428c363968774f0f3906e67d8a53a058ece0b6cdd924b07865977b2ada21。 选择 package.json 和 main.js；其余 36 个已列入清单的文件保持明确未选中。不执行任何目标代码。

问题：检索 main.js 精确路径下每个保留的 javascript-module 身份、其保留源范围观察计数，以及不同的支持状态。将现有模块页面加上完整条目读取，与一个过滤后的类型化引用视图进行比较。所有六个已完成的查询样本都使用同一个保留父项。所有 23 个选中行、身份、计数和支持状态均匹配。公共 CLI 内联输入和 MCP 保留输入产生完全相同的视图和 Evidence ID。这确立了生产者事实一致性，而非独立提取器的正确性或运行时加载的证明。

已完成的读取成本¶

顺序交替为：现有/引用、引用/现有、现有/引用。时间包含验证器侧的事实规范化和等价性检查；字节/Token 统计紧随时序读取。初始工件分析和摘要耗时 20.978 秒，属于共享准备，而非查询速度改进。保留的源仍然不完整；未知计数和源选择独立于已耗尽页面被保留。未引入查询缓存。

Token 是使用 tiktoken 0.12.0 对序列化值计算的 cl100k_base 计数，而非托管模型用量。目录投影包含 name/description/inputSchema；两个工作流都使用变更后的同一目录。每个请求/回复各计一次。输出模式、特定于主机的渲染/重放、推理、最终答案、代理成功率和模型延迟均未测量。这是一项已完成的数据检索比较；它不确立整体代理加速，也不确立目录大小变化前后的改进。旧版条目读取是串行的；未测量并发的旧版基线。所选发现同时包含分析和视图工具模式。构建/文件系统处于热状态或不受控制，因此首次查询不是操作系统冷启动分析测量。共享主机调度不受控制：一次较早的成功探测具有明显更高的墙钟/CPU 时间。其样本单独保留；两次运行都不构成可移植的延迟保证。

完整最终验证器范围使用 35.797 秒墙钟时间、35.197 秒 CPU 和 1,938,313,216 字节峰值 cgroup 内存。这包括共享分析、两个查询分支、临时导出、CLI 一致性和 tokenization；CPU/内存未按分支隔离。cgroup 内存包含已计费的文件缓存，并且不是各进程 RSS 的总和。整个范围有一个 CPU、8 GiB 硬内存上限、6 GiB 提前停止且无交换空间。已验证负载清理；未发生 OOM/容量事件。较早的一次全响应传输失败和中间探针单独记录在 JSON 中，且不计入性能成绩。

一项审查后续测试在真实 Obsidian 引用读取和 CLI 一致性之后，演练了一个停滞的 tokenizer。已提交的 POSIX 故障夹具将一个辅助进程 fork 到独立进程组，忽略 SIGTERM 并停滞。在调用者选择的 2,000 ms 截止时间下，共享的 owned-command 监督器报告了 OwnedCommandFailure，原因 timeout，且无清理失败。验证器按预期失败，其完整自有范围已被清理，且选定的临时根目录为空。单独的健壮性运行使用 55.080 秒墙钟 / 45.246 秒 CPU / 1,563,475,968 B 峰值 cgroup 内存，已验证清理且无 OOM。它不计入效率成绩。较早的 20 ms 直接子进程超时探针并未证明后代清理；它仍是一个单独的先前尝试。分离辅助进程的场景在 Linux 上执行，而非 Windows 或 macOS。

一项确定性 CI 回归还断言同一源范围内有两条保留观察，排除一个不可用位置，并检查与完整条目视图的一致性；该计数有意衡量观察次数，而非唯一源位置。

复现¶

使用固定的 Node/npm 工具链和 npm ci，然后运行 npm run build:cached。在检出目录之外下载/解压指定版本的应用，并检查其摘要。使用操作者选择的绝对工件路径运行：

node scripts/verify/javascript/module-references.mjs \
  --artifact /absolute/path/obsidian-1.14.4.asar \
  --source-path package.json --source-path main.js \
  --path main.js --kind javascript-module --rounds 3 --cli-parity \
  --tokenizer-python /absolute/path/to/tiktoken-venv/bin/python

可选的 Python 解释器需要 tiktoken 0.12.0；省略该标志即可跳过 Token 计数。它设有 60 秒的墙钟时间截止期限，可通过正整数 --tokenizer-timeout-ms 配置。tokenizer 使用现有的自有命令监督器，该监督器具备原生身份检查，并会清理后代进程继承的 run-token。输入数据与临时证据使用现有的私有运行时根目录。清理尝试会保留主要错误；未完成的命令清理会保留其所有者及私有文件，以便恢复。--mode legacy 或 --mode references 仅运行一条分支。全新运行会重新分析工件，并可能产生不同的父身份/资源覆盖范围；验证器要求其配对运行中的事实一致。受测运行额外使用了保留的 8 GiB cgroup 观察器 及其相邻的 resource_payload.py；观察器哈希记录在 JSON 中。应用程序、完整捆绑包、原始观测数据或周围环境均不会被归档。自有命令清理成功后，临时导出/内联的证据文件即被移除。

对于 Linux 后代超时检查，请创建一个由操作者选定的私有目录，并将 REA_TOKENIZER_PROBE_RECORD 设置为该目录内的一个文件。使用 --mode references --rounds 1 运行相同的真实工件命令，将 tokenizer 替换为 scripts/fixtures/tokenizer-family-wrapper.py 的绝对路径，并添加 --tokenizer-timeout-ms 2000。预期会出现超时失败。显式标记确认分离的辅助进程已启动；资源观察器必须单独验证整个自有作用域为空，且所选临时根目录中不得包含任何验证器文件。记录的 PID 只是观测结果，并非向该进程发送信号的授权。