Issue 1：字体包永远解析不到 / Issue 2：本地渲染 Worker 子进程崩溃

[wangyufeng336]

标题： Every fonts-open family fails "X is needed by this authored font" even after hypit packages install

环境： @hypit/hypit 0.1.10（npm 最新版）· macOS 26.6 (25G72) arm64 · Node v26.5.0

复现：

1. .svml 里用任意 fonts-open 字体（比如 family="inter"）
2. hypit check 报 @fontsource-variable/inter is needed by this authored font. Install it once with: hypit packages install @fontsource-variable/inter@5.3.0
3. 照着跑 hypit packages install @fontsource-variable/inter@5.3.0 → 显示 ✓ Machine package is ready
4. 再跑一次 hypit check → 一模一样的报错，像什么都没装过

根因： fonts-open/src/surface.ts 通过 resolveNodePackageResource 解析字体文件，最终落到 package-loader-node 的 declaredExternalPackageRoot——它要求从请求方文件（fonts-open/src/...）向上遍历祖先目录，找一个在 dependencies 里声明了这个字体包的 package.json。但 fonts-open/package.json 的 dependencies 只列了内部 @hypit/* workspace 包，从不声明任何字体包。而 hypit packages install 把包装进了完全不相关的另一棵目录树（机器级 packages home），fonts-open/src 向上遍历永远够不着那里。这个坑对目录里近 90 种字体都成立，不是 Inter 专属。

建议修复： 要么让 resolveFontPackageFile 直接用 externalPackageInstallRoot(machinePackagesRoot, packageName, version) 定位（它已经知道包名，需要补上锁定版本），要 fonts-open 自己够得着的祖先链上。

标题： hyperframes.local render always fails: Cannot find package '@hypit/hyperframes' (render worker subprocess missing Distribution module-resolution bootstrap)

环境： 同上

复现： 用官方 hypit runtime init 生成的默认 Profile（hypihub.default + media.local + hyperframes.local），hypit doctor 全绿的情况下，任何一次 hypit build 渲染都会在第一步视觉渲染上必现崩溃：
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@hypit/hyperframes' imported from
.../packages/provider-hyperframes-local/src/render.ts

根因： capture-process.ts 用 spawn(process.execPath, ["--import", tsxLoader, captureWorkerPath], ...) 另起一个全新 Node 子进程跑真正的渲染。但 @hypit/hyperframes 这类 @hypit/* 包名只能通过 Hypit 自定义的模块解析钩子（installDistributionPackageResolution）找到，而这个钩子只在顶层 CLI 入口 bin/hypit.mjs 里注册了一次；子进程的 spawn 参数里完全没有重新注册这个钩子，所以子进程一加载 render.ts 顶部的 import ... from "@hypit/hyperframes/project" 就崩。这是无条件必现的，跟具体 Source/Run 内容无关。

已验证的绕过方法（不改动任何已安装文件）： 常驻 Worker 进程（hypit runtime status 显示的那个）才是真正执行 spawn 的地方，得让它带着补丁重启：
hypit runtime down
NODE_OPTIONS="--import=/path/to/bootstrap.mjs" hypit runtime up
bootstrap.mjs 复刻 bin/hypit.mjs 里那两行注册调用即可。只在 hypit build 那条命令上设置 NODE_OPTIONS（不重启 Worker）没用，因为 Worker 早就在跑、环境变量是启动时定的。

建议修复： capture-process.ts 的 spawn 参数里加一个额外 --import，指向一个执行同样两行注册逻辑的小模块（或者把 bin/hypit.mjs 那段注册逻辑抽成两边都能复用的入口）。

[rponeawa]

Thank you for the report. Both are confirmed and fixed.

Issue 1 (fonts) is fixed by #208, tracked as #206. Issue 2 (capture child process) is fixed by #209, tracked as #207.

Your independent reproduction on 0.1.10 / macOS was useful: #206 was filed against 0.1.8 on Windows, and seeing the same behavior on a different platform and a newer version confirmed it was neither platform-specific nor already addressed. Your root-cause reading matches what we measured for both.

On Issue 1, the fix went into the external version lookup in package-loader-node rather than into resolveFontPackageFile, so it covers any optional upstream asset resolved through the machine package root instead of fonts alone.

Both will reach users in the next npm release. Your NODE_OPTIONS restart of the Worker is a sound workaround until then, and thank you for noting that setting it on the build command alone does not work.

[rponeawa]

Both fixes are published in 0.1.11.

npm install -g @hypit/hypit@0.1.11

Verified against that published version, installed from npm:

• Issue 1 — a Source using family="inter" now passes hypit check from a fresh npm installation, with no hypit packages install step in between. Fixed by fix: resolve optionally declared upstream assets from the machine package root #208.
• Issue 2 — the capture child resolves @hypit/hyperframes/project through the preloaded resolver the distribution now ships. Fixed by fix: give the HyperFrames capture process the Distribution resolver its parent has #209.

The NODE_OPTIONS Worker restart is no longer needed; hypit runtime down and a plain hypit runtime up will pick up the new behavior.

Thank you for the report. Reproducing both on 0.1.10 / macOS is what established that neither was platform-specific or already addressed, and your root-cause reading matched what we measured in both cases. Closing as released.