Dashboard › opencode-lore › Distillation
d8517ebe-88d1-428d-b5f4-92432ed477d8["lore_tm_v1_nRNbWZsGSBGI9E8zu2iOKA9pOgMGVWlW70XdAvqvdWk","lore_tm_v1_L8fR58xCSyEK0Z21LuiKliobTEORF7ZOEyyQepy93aI","lore_tm_v1_QHADB5b517LcAlkiiB-y0EmkjHNgW-W1F3nsCAo9QYE","lore_tm_v1_Njx1UqYnZmobH3-GT4-YGozRjqPTCif-6eiwdh7l8iM"]
Date: September 16, 2026
beforeAll, so it always runs against a freshly built bundle rather than a stale pre-existing artifact.packages/gateway/dist/index.cjs and the Bun bundle artifact, ensuring assertions never run against an artifact that predates source.node_modules, including ORT WASM changes, are intentionally excluded from the source-freshness calculation.@loreai/core at runtime.@loreai/* package must be a declared runtime dependency and no internal @loreai/* package may be hidden in devDependencies, because dev dependencies are never installed for a transitively installed package.workspace:*, which pnpm pack rewrites to the exact release version.packages/gateway/test/ort-platform-package.test.ts, which binds runtime (process.platform, process.arch) package resolution to the package generator’s published names, os, and cpu; mismatch would silently lose native embeddings and trigger WASM fallback.ORT_NATIVE_TARGETS and generated ORT_NPM_PLATFORMS: 1. linux-x64, 2. linux-arm64, 3. darwin-arm64, 4. win32-x64, 5. win32-arm64; tests also require no duplicates.<os>-<cpu>, and ortPlatformTarget(p.os, p.cpu) must derive the same target used in its package name.@esbuild/<os>-<arch>: ortPackageName("linux-x64") is @loreai/onnxruntime-linux-x64, and ortPackageName("win32-arm64") is @loreai/onnxruntime-win32-arm64.linux-x64 → linux/x64, win32-x64 → win32/x64, and darwin-arm64 → darwin/arm64; Windows remains named win32.buildOrtPlatformPackages(out, "9.9.9") emits one package per ORT platform, each containing the addon at ORT_PACKAGE_BINDING_SUBPATH, with every declared package file physically present.package.json requirements: package name from ortPackageName(p.target), version 9.9.9, os: [p.os], cpu: [p.cpu], preferUnplugged: true, loreOrtNodeVersion: ortNodeVersion(), and no exports field because runtime deep-imports the .node file through require.resolve.libonnxruntime.so.1 and drops libonnxruntime.so.1.27.0; Darwin keeps the @rpath install-name library libonnxruntime.1.dylib and drops libonnxruntime.1.27.0.dylib; Windows ships both onnxruntime.dll and DirectML.dll.packages/gateway/script/vendor-ort-native.ts: SEA/fossilize binaries have no node_modules, so native ONNX Runtime files are collected as assets; runtime loading relies on ELF $ORIGIN/RUNPATH, Darwin @loader_path, and Windows same-directory DLL lookup.packages/gateway/script/vendor-ort-native.ts runs under Node via tsx, is safe to import for helper functions, and has no import-time side effects.bin/napi-v<N> directory and throws when that invariant is not met.isNativeOrtLoadError(msg: string) to packages/core/src/embedding-worker-types.ts and mirrored it in packages/core/src/embedding-worker.ts. It first identifies native ONNX Runtime references such as onnxruntime_binding.node, libonnxruntime, provider libraries, or OrtGetApiBase, then recognizes load failures including ERR_DLOPEN_FAILED, invalid ELF/Mach-O/Win32 binaries, truncated files, missing shared objects/images/modules, undefined or missing symbols, and dlopen errors.{ type: "init-needs-wasm", error: msg }, directing the main thread to respawn with WASM instead of treating the failure as an ordinary initialization error.onnxruntime-node dependency.onnxruntime-node installation, while published-package execution resolves the declared platform package.bundledOrtNodeVersion(), runtime platform/architecture compatibility, Linux glibc compatibility, exactly one N-API directory where required, path constraints, and binary magic checks for ELF, Mach-O, or Windows MZ.