@dylanl1/dsh-plugin-pdf 0.1.2 → 0.1.3

package/docs/RETRIEVAL_EXPERIMENT.md

@@ -11,9 +11,10 @@ annotation, navigation and multi-step history pipeline. Model edits continue to
 the shared draft directly; saving still requires confirmation. No second document,
 draft or anchor registry is introduced.
 
-The first implementation indexes extracted text, reports OCR/quality/empty-page
-coverage separately, and never claims images or formulas have been understood.
-Page-image retrieval and reranking remain extension work, not release claims.
+The original 2026-10-25 implementation indexed extracted text and reported
+OCR/quality/empty-page coverage separately. Its measurements below do not cover
+the later OCR and image-description pipeline. Raw page-image vector retrieval
+and reranking remain extension work, not release claims.
 
 1. [x] Validate the supplied local MLX embedding runtime with synthetic bilingual data.
 2. [x] Original-offset chunks, BM25, cosine ranking and protected reciprocal-rank fusion.
@@ -55,6 +56,24 @@ all 37 browser cases; these changes do not alter production behavior.
 
 ## Runtime decision
 
+Current source keeps the two indexing switches as persistent preferences per
+PDF path. Engines and their connections are selected globally in PDF settings;
+the Search panel saves only each document's OCR and image-description switches
+and leaves costly updates to the user. Native text, OCR and image
+descriptions have independent caches. Changing one content source reuses the
+others, and matching document-encoding identities reuse vectors across query or
+batch-size changes. Disabling semantic indexing takes effect immediately;
+otherwise pending choices replace the active plan only after a successful update.
+
+The built-in OpenAI-compatible adapter now supplies `documentFingerprint`.
+Old vector keys are not migrated or matched by guesswork, so the first upgrade
+may recompute document embeddings. Existing aggregate `PageContent` records
+remain readable and are split into per-source records when reused; subsequent
+compatible records can be reused normally. Third-party providers without a
+document fingerprint retain their conservative model key when its identity is
+unchanged. The historical benchmark results below predate these policy and cache
+changes; they are not new measurements of them.
+
 The supplied `mlx-lm-local-demo` has a cached
 `mlx-community/Qwen3-Embedding-0.6B-8bit` model. Its installed convenience helper
 truncates to 512 tokens by default. The standalone
@@ -68,9 +87,12 @@ The tested model revision is `b8d7100604f51da6d14eab4dd1805f596fa1ce3f`, produci
 instruction; document encoding does not. The launcher permits at most 8 inputs,
 8,192 tokens per input and 16,384 padded tokens per batch. The adapter also bounds
 each original input to 16,000 UTF-16 units. Character limits do not replace the
-server's token check. Model metadata and response revision must match the selected
-encoding identity; an arbitrary endpoint with an OpenAI-shaped response alone is
-not sufficient.
+server's token check. This launcher reports model metadata and the response
+revision; the adapter learns `/models`' `embedding.revision` and includes it in
+the internal cache fingerprint, while checking response consistency within each
+operation. A reported model revision change automatically separates old indexes;
+no user-configured revision is needed. The generic service adapter also accepts
+standard OpenAI-compatible model lists and embedding responses without those extensions.
 
 Synthetic runtime probes encoded 2,028 tokens across long inputs, including
 different tails after token 512; those tails produced distinct vectors (L2
@@ -92,19 +114,62 @@ their dependencies, with the pinned model cached. The launcher binds only
 separate process whose startup/shutdown remains the operator's responsibility,
 not a cross-platform bundled embedding runtime.
 
-In PDF settings select **Local Qwen3 embedding**. The built-in defaults target
-`http://127.0.0.1:8001/v1/embeddings` and the revision above. `embeddingEngine: none`
-is the default: ordinary use starts no model and performs no download. The
-conversation model is not assumed to support embeddings. A third-party engine
-uses the same typed registration contract; see [engine extensions](ENGINE_EXTENSIONS.md).
+In PDF settings select **Embedding service**. Qwen3 is the default
+configuration example: the built-in defaults target
+`http://127.0.0.1:8001/v1/embeddings` and the model above. The stable engine ID
+remains `local-qwen3-embedding` so existing configurations keep working; the
+descriptor uses `execution: 'service'`. The same settings accept a local HTTP
+service or a third-party HTTPS service implementing OpenAI-compatible `/models`
+and `/embeddings` endpoints. Configure that service's model, vector dimensions
+and limits; optional `apiKeyRef` points to a DSH Host credential. Custom model
+metadata is not required; reported limits and truncation are checked against the
+configuration. The adapter includes a learned service revision in the cache
+fingerprint and checks revision consistency within the operation, so reported
+version changes automatically separate old indexes. Cache identity is managed
+internally; there is no `modelRevision` setting. If a service changes the model
+behind the same name without reporting a new revision, use **Recompute entire
+index** under **Search → Current PDF index** to refresh one PDF, or **Clear all
+index caches** in PDF settings to reset this profile's retrieval caches and old
+searches. The profile reset drains background work before clearing, then resumes
+still-open PDFs with their active plans; pending choices still need an explicit
+update. Other documents rebuild on their next open or search, leaving PDFs,
+drafts and saved policies unchanged.
+`queryInstruction` defaults to an empty string for every model; configure it according to the model's
+requirements. To reproduce this Qwen3 experiment, enter
+`Given a search query, retrieve relevant passages from the document that answer the query`.
+The benchmark runner supplies that instruction explicitly. Clearing the setting
+disables the instruction.
+
+`embeddingEngine: none` is the default: ordinary use starts no model and performs
+no download. The conversation model is not assumed to support embeddings. Other
+protocols can use the same typed registration contract; see
+[engine extensions](ENGINE_EXTENSIONS.md). The measurements below use only the
+local launcher, not a third-party service.
+
+The current Host prepares opened PDFs in the background when their active plan
+enables an available embedding engine. Reader opens and `pdf_open` share this
+path. Preparation always includes native text, can recognize scanned/damaged
+text, and can generate whole-page image descriptions according to that plan's
+two independent switches. It embeds the resulting text and reuses the same
+index, caches and build jobs as search; it does not generate query vectors.
+Opening or searching does not activate pending choices. Opening does not wait
+for preparation, and an early search may still need the remaining work. Remote
+services may receive clean page images and extracted or generated text during
+preparation, before any query. The task panel retains green **Index ready**
+records until acknowledged with **Done** or the Host removes the closed PDF's
+task; acknowledging feedback does not remove index readiness. Other short-lived
+save notices retain their existing timers.
+The historical benchmarks below do not measure this opening/background behavior.
 
 ## Data flow and ownership
 
 ```mermaid
 flowchart LR
-  Tool["pdf_find_related"] --> Host["Authorized Host adapter"]
+  Tool["pdf_semantic_search"] --> Host["Authorized Host adapter"]
+  Open["Reader / pdf_open<br/>Shared document ownership"] --> Background["Enabled embedding<br/>Background preparation queue"]
+  Background --> Host
   Host --> Copy["Existing shared working copy"]
-  Host --> Index["Retrieval service<br/>Page-local exact text chunks"]
+  Host --> Index["Shared derived index<br/>Page-local exact text chunks"]
   Index --> Lexical["BM25 postings"]
   Index --> Vectors["Typed embedding provider<br/>Document / query encodings"]
   Lexical --> Fuse["RRF + branch coverage protection"]
@@ -122,9 +187,18 @@ typed provider registry. Host adapters own DSH authorization, provider selection
 storage, model-facing search sessions and evidence signing. There is no second
 document table or anchor store.
 
+Resident indexes and in-flight build steps are shared across authorized Sessions
+within one Host instance by source-byte digest, page count, retrieval
+scope/versions and embedding fingerprint/registration generation. Session-local document IDs, paths and
+`contentVersion` are not shared-index keys. Each caller still validates its own
+document binding and authorization; drafts, queries, continuation handles, results
+and evidence references stay Session-scoped. Shared derived data grants no access
+to the underlying file. Ready indexes remain bounded LRU residents and may be
+evicted; this is not a permanent on-disk index.
+
 ### Public tool continuation
 
-Start `pdf_find_related` with `documentId`, `query` and its optional `terms`,
+Start `pdf_semantic_search` with `documentId`, `query` and its optional `terms`,
 `mode`, `topK`, `fromPage` and `maxPages`. The response contains `searchId: "rel_…"`
 and a boolean `hasMore`. While `hasMore` is true, call the same tool with only
 `{"searchId":"rel_…"}`. Do not repeat the query, document or options. The public
@@ -133,15 +207,17 @@ request, source/engine constraints and internal continuation progress.
 
 `building` and `incomplete` still report progress and coverage without globally
 ranked candidates. Only `complete` returns rankings for the requested scope and
-sets `hasMore: false`. Inspect `effectiveMode`, `fallbackReason` and `coverage`
-before describing the result as semantic retrieval or complete text coverage.
+sets `hasMore: false`. Inspect `effectiveMode` and `coverage` before describing a result as complete
+text coverage. The current semantic-search tool requires an available embedding
+engine; it does not expose the experiment's automatic lexical fallback.
 
-The exact, case-sensitive `pdf_search` uses the same initial-call pattern, with
+The exact, case-sensitive `pdf_keyword_search` uses the same initial-call pattern, with
 its optional `fromPage` and `offset`, then only `{"searchId":"txt_…"}` on that
 same tool. Its results are paginated matches; `hasMore: false` means that search
 has finished. It does not use related-index build statuses. Neither search ID is
-a page-list cursor, and `pdf_bookmarks`, `pdf_locate` and `pdf_context` retain
-their existing cursor contracts.
+a page-list cursor, and list tools such as `pdf_bookmark_list` retain their own cursor contracts.
+The former locate/context model entrances are replaced by keyword search and
+`pdf_evidence_read`; evidence replay remains source-bound.
 
 Search IDs are opaque, session-scoped and tool-scoped. Reset, TTL expiry or budget
 eviction invalidates them; unknown or expired IDs require a new initial call.
@@ -161,7 +237,7 @@ and index caches; matching text/model fingerprints can still reuse vectors.
 A reference denotes its entire stored quote, not an implicitly selected answer.
 Check that scope before marking it. A reference annotation target may include
 an exact `quote` to select a unique substring inside that parent reference;
-`pdf_navigate` accepts the same `refId` and `quote` to preserve the selected range.
+`pdf_page_jump` accepts the same `refId` and `quote` to preserve the selected range.
 The shared resolver revalidates the source and full page before deriving native
 geometry for that subrange. Missing or ambiguous quotes fail without a draft
 edit. Omitting `quote` deliberately keeps the full parent range; annotation does
@@ -175,36 +251,77 @@ missing geometry. OCR-derived candidates are not promoted to native coordinates.
 
 ## Budgets and lifecycle
 
-- Index only after an explicit search; embedding is disabled by default.
+- Embedding is disabled by default. Opened PDFs with an enabled, available active
+  plan are prepared in the background; explicit searches reuse its progress and cache.
+  Background preparation runs at most one document at a time and tracks up to 64
+  open documents, with excess documents left to on-demand retrieval.
+- Only UI/model owners keep preparation eligible. Last-owner close or cancellation
+  detaches that Session's preparation without stopping other authorized subscribers
+  to the same build. Shared work aborts once no subscribers remain. Disabling a
+  document's index, changing its active plan or source, and provider unload fence
+  obsolete work. Editing global defaults or a pending policy does not switch the
+  active plan. Source changes can queue a replacement; unchanged annotation edits do not.
+  Failed preparations do not retry indefinitely. Rebuild suspends and drains this
+  queue before clearing caches, then resumes eligible still-open documents.
 - The default search scope is the whole document; `fromPage/maxPages` restrict
   the scope, not the amount processed per call. This intentionally changes the
-  old `pdf_find_related` page-window meaning of `maxPages`.
+  old `pdf_semantic_search` page-window meaning of `maxPages`.
 - Process at most 20 pages and 4 embedding batches per indexing step, yielding
   between work units. The model continues with only `searchId` while `hasMore`
   is true; short public handles do not remove the internal bounded steps.
 - Host retains query continuation state and validates scope, query, source and
   engine generation. Incomplete coverage produces progress, not a global
   best-match or no-answer claim.
-- Runtime defaults cap indexes at 5,000 chunks each, 8 resident indexes, an
-  estimated 64 MiB total index budget, 2 simultaneous build jobs and 8 admitted
-  queries. Active indexes cannot be evicted mid-query; each build step retains
-  its own document lease. These are
-  admission limits, not a guarantee of total process RSS; larger scopes may need
-  to be split explicitly.
+- Production keeps at most four immutable-plan runtimes. Each has at most two
+  resident indexes, an estimated 64 MiB index budget, two simultaneous build jobs
+  and eight admitted queries; each index is capped at 20,000 chunks. Across four
+  runtimes this permits at most eight indexes and 256 MiB of indexed-data budget,
+  allocated as data becomes resident rather than reserved up front.
+  Build/query admission limits are per runtime, not Host-wide limits of two/eight;
+  background document preparation still runs one document at a time. The generic
+  retrieval service's standalone defaults remain eight indexes and 64 MiB per
+  instance; production limits each instance to two indexes while preserving that
+  original per-plan memory budget. Active indexes
+  cannot be evicted mid-query; each build step retains its own document lease.
+  These are admission estimates, not a guarantee of total process RSS; larger
+  scopes may need to be split explicitly.
+  Lexical estimates count one posting per distinct term/chunk pair. Resident
+  cosine-search vectors use normalized Float32 storage shared by identical text;
+  persisted vectors use versioned little-endian Float32/Base64 records with an
+  integrity checksum. At a compatible cache key, existing numeric-array records
+  migrate on a valid hit without requesting another embedding; this does not
+  migrate the old built-in adapter's keys across the document-fingerprint change.
 - The separate `pdf_retrieval_<profile>` Storage Domain stores derived text and
   vectors with default limits of 64 MiB serialized data, 12,000 records and 7 days.
   Individual records are limited to 2 MiB. Cache loss/corruption can be rebuilt
   and must not damage drafts. The cache may contain document text; it is local
   plugin storage, not an encrypted vault or an authorization token.
+- Derived record keys use filename-safe `retrieval_<digest>` identifiers, as
+  required by DSH's per-record JSON backend. Persistence is verified against the
+  real backend, including closing and recreating the domain and retrieval
+  service. An earlier colon-prefixed key was rejected by that backend; affected
+  installations need one initial build because those records were never saved.
+- After restart, the service restores text and vectors and reconstructs its
+  in-memory search structures; it does not persist Session authorization or query
+  cursors. The task panel distinguishes restoration, native page extraction and
+  new embedding requests, and reports reused/newly computed passage counts.
+  Missing, expired, evicted or invalid records are rebuilt individually. Unchanged
+  valid records require neither source extraction nor document embedding.
 - Reuse vectors by text/model identity after source revalidation; annotation-only
   edits do not rebuild the text index.
+- Extraction-version changes invalidate cached page text and quality metadata.
+  The native-quality revision excludes PDFium's recognized U+0002 line-wrap
+  hyphen marker from invalid-control-character warnings; actual Unicode mapping
+  errors still report a warning. Existing indexes re-extract page metadata, while
+  unchanged text can reuse its document vectors.
 - A save can change PDF bytes. Page text is verified/re-extracted for the new
   source, while unchanged text may reuse vectors. Changes in weights, tokenizer,
   query instruction, dimensions or provider configuration change the model
   fingerprint; unloading/re-registering also fences the runtime generation.
-- Closing a session or unloading the plugin cancels queued work and fences late
-  results. Cancellation of an HTTP request does not imply a running external model
-  computation has stopped immediately.
+- Closing a Session cancels its queued work and fences its late results without
+  cancelling another Session's shared build subscription or ready index. Plugin
+  unload cancels all work. Cancellation of an HTTP request does not imply a running
+  external model computation has stopped immediately.
 
 Native PDFium calls and active Metal kernels are not preempted halfway through;
 their bounded operation retains its execution slot until it finishes. No claim
@@ -212,19 +329,24 @@ is made that all CPU/GPU usage ends as soon as a caller receives cancellation.
 
 ## Coverage and limits
 
-The production indexing adapter deliberately requests native text with automatic
-character-repair OCR disabled. Opening/searching a long book must not silently
-launch hundreds of OCR jobs. Empty pages and undecodable characters appear in
-coverage/warnings. Explicit OCR and page-image tools remain available separately,
-but their output is not automatically ingested into this index.
-
-Text around a formula or figure can retrieve its page; this does not mean the
-formula, table or graph has been understood. Image-only content is reported as
-not indexed. The synthetic complex-page cases record this missing coverage rather
-than inventing images, layout evidence or OCR accuracy. No multimodal index,
-reranker, semantic answer validator, cross-document search or automatic section
-reconstruction is included. No-answer queries can still return ranked candidates;
-the agent must read context and cannot infer that a result proves the answer.
+Native extraction requests `{ recover: false }`, disabling the Reader's fixed
+character-repair path. This does not disable the active indexing plan's selected
+OCR engine: its text-recognition switch handles missing/damaged native text, and
+its independent image switch adds generated whole-page descriptions. Both may
+run during background preparation and incur model calls. Ad-hoc OCR or page-image
+tool output is not automatically inserted; indexing uses its own validated source
+pipeline. Empty or failed representations remain visible in coverage/warnings.
+
+Native text can retrieve a formula's or figure's page without understanding it.
+Enabled OCR and description engines can add searchable derived text, with source
+and approximate page/region evidence; they do not provide native text coordinates
+or guaranteed formula, chart or table understanding. With those options disabled,
+image-only content remains uncovered. The original synthetic complex-page cases
+measure that older native-text-only scope, not the accuracy of later enrichment.
+There is no raw-image vector index, reranker, semantic answer validator,
+cross-document search or automatic section reconstruction. No-answer queries can
+still return ranked candidates; the agent must read context and cannot infer that
+a result proves the answer.
 
 Production ranking cooperatively yields and rechecks cancellation/source fences
 after 64 BM25 build chunks, 1,024 lexical posting contributions or 32 vectors.
@@ -298,8 +420,9 @@ The scale corpus repeats the 28 small passages, uses about 158,780 text characte
 at 1,000 pages and reuses already computed document/query vectors. Those timings
 exclude embedding, PDF extraction and disk IO; they do not represent an arbitrary
 1,000-page textbook. The theoretical 1,000 × 1,024 × Float32 vector payload is
-4,096,000 bytes, but the benchmark reuses arrays and production uses JavaScript
-numbers, so this is not a measured cache-memory bound.
+4,096,000 bytes, but that benchmark reused arrays and the then-current service
+stored JavaScript numbers. This is not a measured memory bound for the current
+Float32 storage or its production runtime budgets.
 
 The same runner also calls the actual retrieval service, with a synthetic page
 provider and a structured-clone in-memory KV adapter:
@@ -363,7 +486,6 @@ After starting the cached local model:
 ```sh
 npm run bench:retrieval -- \
   --embedding-endpoint http://127.0.0.1:8001/v1/embeddings \
-  --model-revision b8d7100604f51da6d14eab4dd1805f596fa1ce3f \
   --repeats 3 --out /tmp/retrieval-qwen.json
 ```
 

package/docs/UX_TYPOGRAPHY.md

@@ -4,7 +4,7 @@ This is the typography contract for the PDF reader UI. PDF page content is rende
 
 ## Typeface and language
 
-- Inherit the application font from DSH so the reader stays aligned with the host UI. Let the operating system provide native Chinese glyph fallback; do not hard-code a second font stack in the plugin.
+- Use the shared `--pdf-font-ui` system sans-serif stack, matching Codex's default UI font stack. On macOS the system supplies San Francisco and native Chinese fallback; other platforms use their native UI fonts. Do not inherit the host's chat or code font for plugin UI.
 - Chinese and English use the same semantic size and weight. Do not add locale-specific size overrides or tracking: mixed-language controls should remain aligned.
 - Keep tracking at the platform default for body text and Chinese. Only introduce display tracking after checking both scripts together.
 - Use a monospace face only for code or machine-readable data whose character alignment matters. Page numbers, dates, and counts stay in the UI font with tabular numerals.
@@ -17,7 +17,7 @@ This is the typography contract for the PDF reader UI. PDF page content is rende
 | `label` | 13px / 1.4 | Compact controls, field labels, sidebar section headings |
 | `body-compact` | 13px / 1.5 | Dense result summaries, dictionary meanings, and examples |
 | `body` | 14px / 1.5 | Default reader UI, buttons, inputs, and comment text |
-| `section` | 16px / 1.4 | Translation terms and prominent section headings |
+| `section` | 16px / 1.4 | Prominent section headings |
 | `title` | 20px / 1.3 | Major dialog or panel title only |
 
 Use regular (400) for reading, medium (500) for quiet emphasis, semibold (600) for headings and primary actions, and bold (700) only for strong status emphasis. Avoid intermediate weights such as 550 or 650; use the closest supported semantic weight.
@@ -36,4 +36,4 @@ Long explanatory/helper copy may use 1.6 leading for easier reading; the compact
 
 ## Source of truth
 
-The semantic CSS variables live in the plugin stylesheet's `:root` in `src/client/reader.css` so both the reader and its evidence cards can consume them. Component styles should use those variables instead of introducing new pixel sizes. When adding a new text role, choose an existing token first; extend the scale only for a demonstrated need.
+The font family and semantic CSS variables live in the plugin stylesheet's `:root` in `src/client/reader.css` so the reader, settings, evidence cards, and body-mounted tooltips can consume them. Set the family on these UI roots, not on every descendant: PDF text-layer spans must retain their document-defined fonts, and raw structured output keeps its monospace font. Component styles should use those variables instead of introducing new pixel sizes. When adding a new text role, choose an existing token first; extend the scale only for a demonstrated need.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dylanl1/dsh-plugin-pdf",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "type": "module",
   "description": "PDF reading, annotations, navigation and selection translation for DeepSeek Harness",
   "license": "MIT",
@@ -86,12 +86,12 @@
   },
   "peerDependencies": {
     "@deepseek-ai/cordis": "*",
-    "@deepseek-ai/dsh-attachment": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
-    "@deepseek-ai/dsh-fs-local": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
-    "@deepseek-ai/dsh-sandbox": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
-    "@deepseek-ai/dsh-storage-domain": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
-    "@deepseek-ai/dsh-subprocess": "0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
-    "@deepseek-ai/dsh-tools": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3",
+    "@deepseek-ai/dsh-attachment": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
+    "@deepseek-ai/dsh-fs-local": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
+    "@deepseek-ai/dsh-sandbox": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
+    "@deepseek-ai/dsh-storage-domain": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
+    "@deepseek-ai/dsh-subprocess": "0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
+    "@deepseek-ai/dsh-tools": "0.2.0-rc.1 || 0.2.0-rc.2 || 0.2.1-alpha.1 || 0.2.1-alpha.2 || 0.2.1-rc.2 || 0.2.1-rc.3 || 0.2.1-rc.5",
     "@deepseek-ai/schemastery": "*"
   },
   "peerDependenciesMeta": {
@@ -118,7 +118,7 @@
     }
   },
   "dependencies": {
-    "@deepseek-ai/dsh-util-workspace-path": "0.2.1-rc.3",
+    "@deepseek-ai/dsh-util-workspace-path": "0.2.1-rc.5",
     "@pdf-lib/fontkit": "1.1.1",
     "pdf-lib": "1.17.1",
     "zod": "~4.4.3"
@@ -131,10 +131,10 @@
     "node": ">=22"
   },
   "optionalDependencies": {
-    "@dylanl1/dsh-plugin-pdf-native-linux-x64": "0.1.2",
-    "@dylanl1/dsh-plugin-pdf-native-linux-arm64": "0.1.2",
-    "@dylanl1/dsh-plugin-pdf-native-darwin-x64": "0.1.2",
-    "@dylanl1/dsh-plugin-pdf-native-darwin-arm64": "0.1.2",
-    "@dylanl1/dsh-plugin-pdf-native-win32-x64": "0.1.2"
+    "@dylanl1/dsh-plugin-pdf-native-linux-x64": "0.1.3",
+    "@dylanl1/dsh-plugin-pdf-native-linux-arm64": "0.1.3",
+    "@dylanl1/dsh-plugin-pdf-native-darwin-x64": "0.1.3",
+    "@dylanl1/dsh-plugin-pdf-native-darwin-arm64": "0.1.3",
+    "@dylanl1/dsh-plugin-pdf-native-win32-x64": "0.1.3"
   }
 }

package/dist/types/adapters/host/dsh/image-auxiliary.d.ts

@@ -1,20 +0,0 @@
-import { type ImageUnderstandingBackend } from '../../../modules/image-understanding/index.js';
-import type { SessionOcrAttachmentStore, SessionOcrLlm } from './ocr-session-llm.js';
-export interface AuxiliaryVisionModel {
-    provider: string;
-    model: string;
-    reasoningEffort?: string;
-}
-export interface AuxiliaryVisionDependencies {
-    /** An explicit Host profile selection; never inferred from the current session. */
-    selectedModel(): AuxiliaryVisionModel | undefined;
-    getLlm(): Pick<SessionOcrLlm, 'resolveModelInfo' | 'stream'> | undefined;
-    getAttachments(): Pick<SessionOcrAttachmentStore, 'saveImage'> | undefined;
-    maxOutputTokens?: number;
-}
-/**
- * Opt-in second-model image description for sessions whose own model is text-only.
- * It returns text with explicit provenance; it never changes the session model or
- * claims that OCR and visual reasoning are equivalent.
- */
-export declare function createAuxiliaryVisionBackend(dependencies: AuxiliaryVisionDependencies): ImageUnderstandingBackend;