v2.11.9

Fixed

npm install monomind is audit-clean again (#266).

A clean install reported four high-severity sharp<=0.35.4-rc.0 advisories, pulled in transitively through @huggingface/transformers. @huggingface/transformers is bumped ^3.8.1 → ^4.3.0.

Why nothing smaller worked: 3.8.1 declares sharp: ^0.34.1, so no version inside its range is safe. Neither a root overrides entry nor a sibling floor could fix it — a sibling floor made npm nest a second vulnerable copy rather than dedupe. 4.3.0 declares sharp: ^0.35.4.

Verified with the issue's own repro — a clean consumer install of monomind@2.11.9 resolves sharp@0.35.4 and npm audit reports 0 vulnerabilities.

Real-world exposure was low (both advisories require processing untrusted image input, and monomind only ever hands transformers text), but the dependency-graph risk and the audit noise were real.

Two follow-on fixes required by the v4 bump:

• embedding-operations.ts now pins dtype: 'q8', matching memory-bridge.ts. Since v4 the default is fp32 (onnx/model.onnx), which the provisioning step never fetches — leaving it unset would have failed every load under local_files_only and silently degraded semantic search to the 128-dim hash fallback.
• The Second Brain Model doctor check looked for .cache/Xenova, a model the bridge no longer uses, so it reported "Embedding model not downloaded yet" with a fully provisioned cache on disk. It now checks the model actually in use, and its fix hint names monomind doc eval --provision-model instead of monomind doc search, which passes local_files_only and never downloads anything.

Note for existing installs

The model cache lives at a version-keyed path inside node_modules, so this bump orphans any warm cache. Re-provision once with monomind doc eval --provision-model (~270MB). Until then semantic search falls back to keyword matching — which monomind doctor now reports accurately.

Full Changelog: v2.11.8...v2.11.9