feat: round 1 — FTS5 search, attachments, import target choice, embedding reuse, UI scale, localized tool descriptions, Telegram/Discord Rust kernels, local voice transcription - #459

Add a desktop UI scale preference with five presets (90%-150%), stored
as desktop.ui_scale. The main window applies the saved factor via
webPreferences.zoomFactor at creation and re-applies it on
did-finish-load, so the choice survives a restart without a first-frame
flash. Non-desktop platform adapters report the default scale and reject
writes; the settings row only renders on Electron.

Closes ChatLab#445

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Tool and parameter descriptions were handed to the LLM in Chinese on every
runtime regardless of locale: the English metadata table in
packages/tools/src/tool-metadata.ts had no caller, the desktop translateTool
looked up i18n keys that exist in no locale file, and the MCP server had no
locale at all.

Fill the table for every tool whose definition text is Chinese (37 entries,
only translating what the definitions write in Chinese so the two copies
cannot drift), and route the four consumers through getLocalizedToolMetadata:
the cross-chat agent adapters, the CLI Web agent adapter, the desktop shared
tool adapter (replacing the dead translateTool), and the MCP server, which
now resolves its locale from config.locale.lang or the system locale for both
the standalone binary and the chatlab mcp subcommand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Adds scripts/bench-message-search.mts: builds a deterministic synthetic
chat database with better-sqlite3 and CHAT_DB_SCHEMA (no parser), then
measures the core searchMessagesByKeywords() path over a fixed twelve
query set (1 cold run on a fresh connection + N warm runs each).

Records p50/p95, total, and the sha256 of the full sorted hit-id set so
before/after runs can be compared for recall. When @openchatlab/core
exports ensureMessageSearchIndex the index is built after inserting and
its duration recorded; otherwise the run reports searchIndex: null and
measures the LIKE-only baseline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Queries 9 and 10 used 周末/打球, which only ever co-occur in the same
sample sentence, so 'any' and 'all' produced an identical hit set. Using
天气/打球 keeps the SQL shapes but makes the two modes differ in recall.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Declares message_fts as an FTS5 external-content table over message.content
with trigram tokenization, plus insert/update/delete triggers, appended to
CHAT_DB_INDEXES so bulk importers still defer index work until after the
rows are written and browser opens create it automatically.

search-index.ts owns the query-path helpers: ensureMessageSearchIndex()
creates and backfills the index inside a transaction, canUseFtsKeywords()
rejects keyword sets the trigram tokenizer cannot match (< 3 code points),
and buildFtsMatchExpression() turns keywords into a quoted MATCH expression.

Coverage is measured against the FTS5 docsize shadow table: an
external-content table answers COUNT(*) from the content table, so it
cannot distinguish an empty index from a populated one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

buildMsgConditions gains a keywordMode: 'fts' emits
`msg.id IN (SELECT rowid FROM message_fts WHERE message_fts MATCH ?)`
instead of the LIKE scan. The three entry points — searchMessagesByKeywords,
searchMessagesLikeAsync and searchMessagesLike — pick it when the index
exists and every keyword clears the trigram floor, so all three runtimes get
the same routing from one place. `forceLike` opts a caller back out.

`sort: 'relevance'` orders by bm25 on the indexed path (the page joins the
FTS table because bm25 needs it in the FROM list; COUNT keeps the
IN-subquery) and falls back to timestamp order everywhere else.

searchMessagesLike now delegates to searchMessagesByKeywords, which also
fixes its unescaped LIKE pattern: a keyword containing % or _ used to match
messages it should not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…tion

Migration v11 calls ensureMessageSearchIndex, so existing sessions get the
index (and its backfill) the first time a current runtime opens them; the
four desktop locales gain the matching migration strings.

The streaming importer bulk-inserts before message_fts exists, so it
backfills once after CHAT_DB_INDEXES and reports the cost as a new
searchIndexMs stage timing. The incremental and push importers call the
same helper after their writes: normally two COUNT(*), a rebuild only when
the index was missing.

The four tests that asserted message_fts was absent now assert it is
present and covers every message. The two v8 fixtures build from
CHAT_DB_TABLES so they still describe a pre-index database, and a new
v10 -> v11 test proves messages written before the upgrade are findable
through the index afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The browser has no migration runner, so a session imported before the index
existed only gets it when a database open applies CHAT_DB_INDEXES. The open
path now backfills it there, between new 'search-index-checking' and
'search-index-ready' stages, and the import path backfills after its own
CHAT_DB_INDEXES rather than leaving the cost to the first search.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

search_messages now asks for sort: 'relevance', so the AI receives the
best-matching messages instead of the most recent ones, and its description
says what actually happens (index above three characters, substring
matching below). deep_search_messages passes forceLike, which finally makes
it the distinct exhaustive path its name claims — until now it was the same
query as search_messages.

The desktop worker forwards sort/forceLike through to
searchMessagesLikeAsync so the Electron path behaves like the CLI one, and
the cross-chat agent prompt no longer tells the model that keyword search is
"literal LIKE".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

getPendingMigrationInfos now returns version 11, so the pending-migration
test asserts its own localized message instead of stopping at v10.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The streaming-import benchmark guarded against message_fts existing at all.
It now checks the opposite property that matters: after an import the index
must cover every message, since the rows are written before it exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…e changes

Tests import the built output, so an outdated build silently runs old MCP
code. Say so in both language guides, as suggested in review.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

did-finish-load fires again when the renderer is reloaded after a crash;
reading the setting at that point keeps a scale changed since startup.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…ession

The same private chat exported from both accounts carries identical
messages under different owners and disjoint platform message ID spaces.
Appending the second export to the first session stores every message a
second time (6 of 6 duplicated, 12 rows for 6 messages).

Refs ChatLab#358

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Add AutoImportOptions.forceCreate, which plans a separate session with
create reason 'user-choice' regardless of what automatic matching would
find. Expose the existing analyzeAutoImportFile preview through the
desktop worker (chat:analyzeAutoImport) and a CLI Web
/_web/import/analyze-target route so the renderer can preselect the
target automatic matching would pick.

Transport: chat:importWithOptions accepts a `target` option and maps it
to explicitSessionId / forceCreate; /_web/import accepts targetMode and
targetSessionId; /_web/import/batch accepts only auto and new, since
appending several files to one chosen session has no defined meaning;
clb import gains --new-session, mutually exclusive with --session-id.

Refs ChatLab#376

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Single-file imports now open ImportTargetModal once the format is
settled: keep automatic matching (preselected, showing which session it
would append to and why), append to a session picked from the existing
session list, or create a separate session. ImportOptions gains a
`target` field that each adapter forwards to its backend, and a new
analyzeAutoImport service method previews the automatic decision so the
dialog can preselect it.

Web WASM has no incremental import, so its adapter reports a create
decision and the dialog stays hidden there; batch, directory, archive and
multi-chat imports keep their existing automatic behaviour.

Closes ChatLab#376

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The same private chat exported from both accounts carries identical
messages under different owners and independent platform message ID
spaces. Appending the second export to the first session stored every
message again, because a message that already has a platform ID was only
compared by content against ID-less rows.

An append the user chose (explicitSessionId) is now marked
crossSourceAppend. When the exporting account differs from the session's
owner, the incoming platform message IDs are namespaced with a scope
derived from that account, and dedup compares the content fingerprint
against every candidate at the same timestamp and sender rather than only
ID-less ones. The namespace is derived from the source, so re-importing
the same export stays idempotent, and the session keeps its own owner so
the namespace does not drift.

Imports without that flag, and appends whose export shares the session's
owner, keep comparing platform IDs exactly as before.

Closes ChatLab#358

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Define `messages[].attachments[]` (kind, path, name, mimeType, size,
durationMs, width, height) in the ChatLab format specification, and turn
the reserved-field paragraph in the import specification into a pointer
to that structure.

The format version stays 0.0.2: attachments is an optional field that
older readers can ignore.

Refs ChatLab#170

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…inputs

Merging or re-importing a session produces a new chat database, so its
vectors live under a new db_path_hash and every chunk is embedded again
even when the text has not changed at all.

Before embedding a batch, look for an already indexed chunk in another
chat database whose embedding input is byte-identical, and copy its
vector instead. The key is embedding_input_hash, which every chunk row
already stores, so existing indexes are reusable without a backfill;
model, strategy, chunker identity and dim must all match for the copied
vector to mean anything.

A run that only copied vectors proves nothing about the local model, so
it no longer clears the model preload error.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

carryOver enables the merged session and queues its build as soon as at
least one source session is indexed with the current model, so the user
does not have to ask for the index again: chunks whose embedding input
is unchanged copy the source vectors and only the new messages are
embedded.

The worker client tracks the merged session as an active build for the
duration, the way build does. Nothing polls status after a merge, so
without it the idle timer could terminate the worker while the build was
still running.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The merge route knew which sessions were merged but had no way to tell
anyone, so the new session started with no vectors at all.

Remember the source sessionId on each exported merge handle and, once the
merged output has been imported, call onMergedSessionImported with the
new session and its sources. Desktop and CLI Web wire it to the semantic
index, which carries the existing vectors over. The callback runs in the
background: the merge response must not wait for an index build, and a
failure there must not fail the merge.

Closes ChatLab#378

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Attachments parsed from an export now have somewhere to live:

- shared-types gains `ParsedAttachment` and `ParsedMessage.attachments`
- `message_attachment` (schema version 11) stores one row per attachment,
  indexed by message; `meta.source_dir` records the directory the export
  file was imported from so relative paths stay resolvable
- `ensureAttachmentSchema` backs both the Node migration and the browser
  runtime, which replays DDL on open instead of running migrations
- the message inserters switch to `INSERT ... RETURNING id` so attachment
  rows are written in the same transaction as their messages; incremental
  and push imports only write attachments for messages that survive dedup
- `getMessageAttachments` / `fetchMessageAttachments` read them back per
  page, and `resolveAttachmentPath` resolves a relative path against the
  source directory while refusing anything that escapes it

Refs ChatLab#170

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…tagram exports

Media messages keep their text marker and now also carry the file:

- ChatLab JSON/JSONL read `attachments`, skipping malformed entries; when a
  media message has none and its content is a bare file path, one attachment
  is inferred from it (issue ChatLab#170: WeFlow-converted WeChat exports). URLs are
  never inferred, so an export cannot make the app fetch a remote address.
- Telegram maps photo/file plus media_type, file_name, mime_type, duration
  and dimensions; Discord maps every attachment (url, fileName, fileSizeBytes)
  with the kind taken from the existing extension rules; Instagram maps
  photos, videos and audio_files.
- The Rust chatlab kernel gains the same attachment parsing and inference, so
  the native path no longer drops the field, and the browser runtime maps
  attachments from both its TS parser and the WASM kernel.

Closes ChatLab#170

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Attachment chips appear under each message in the chat record, batched one
query per page of messages:

- desktop registers the privileged `chatlab-media://` scheme and serves the
  file through `net.fetch` only after the shared path resolver confirms it
  sits inside the directory the export was imported from; the chip reveals
  the file in the OS file manager
- CLI Web serves the same files from `GET /_web/sessions/:id/attachments/:id`
  and its chips download; images render inline and browser-playable audio
  gets a player on both runtimes
- a runtime without attachment file access (Web WASM) shows the chip alone

Path resolution and content type live in one node-runtime service so both
entry points refuse the same paths.

Refs ChatLab#170

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…cords

Built with wasm-pack 0.15.0 (the version CI installs) so the Web WASM
parser path carries attachments like the napi kernel does.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

The pull document still described attachments with filePath / dataUri from
the reserved-field era; the structure is now defined in the format spec.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…uffers

Transformers.js 4.2.0 has no language detection: with no language token it
warns and transcribes as English, so Chinese voice messages came back as
nonsense. Resolve the language from the session's own text messages before
the audio reaches Whisper, and add the single-attachment PCM entry point the
desktop and CLI Web runtimes need once they decode audio in the browser.

- core: detectSessionLanguage / resolveTranscriptionLanguage (CJK vs Latin
  character ratio over the 300 most recent text messages)
- node-runtime: transcribeAttachmentPcm, with a 30-minute PCM ceiling and a
  coded error for non-audio attachments; transcribePcm no longer accepts auto
- config: [transcription] model / language, read as the CLI flag defaults

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Voice transcription needs the same worker plumbing the semantic index already
has (tsx bootstrap, correlated postMessage, graceful runtime close before
terminate), plus a transfer list so PCM buffers are handed over rather than
copied. Move the feature-agnostic half to worker/thread-transport.ts and keep
createSemanticIndexWorkerThreadTransport as the semantic index's entry point;
its behaviour, options and exported types are unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Whisper's log-mel feature extraction runs in JavaScript and the model holds
about a gigabyte of ONNX tensors, so transcribing on the main thread would
freeze the Electron main process and the CLI Web server for the length of the
clip. Run it in a worker thread instead, started by the first request and
closed again after five idle minutes so a user who never records voice pays
nothing. PCM samples are copied once and handed to the worker through the
transfer list, leaving the caller's buffer intact.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The renderer can decode audio Chromium understands but the Node decoders do
not, so the desktop path is: decode in the renderer, send 16 kHz mono PCM over
IPC, transcribe in a worker thread, store the transcript. Settings, the pending
queue and the PCM write path are shared with the CLI Web routes in
node-runtime/src/services so the two entry layers cannot drift; the handlers
only open the session database and check their arguments.

An attachment id from another session is not in the session's own database, so
it fails as not found rather than writing across sessions. Buffers that are not
a whole number of floats, or longer than the 30 minute cap, are rejected before
the worker is started.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The CLI Web page decodes a voice attachment with Web Audio and posts the raw
16 kHz mono Float32 samples to /_web/sessions/:id/attachments/:id/transcribe,
which runs Whisper in a worker thread and stores the transcript. Settings and
the pending queue are served next to it, and the whole group shares the write
path with the desktop IPC handlers.

Thirty minutes of samples is about 115 MB, past both Fastify's 1 MB default and
this repo's 50 MB server limit, so the endpoint raises its own bodyLimit and
registers the octet-stream parser the raw body needs. Auth is unchanged: the
CLI's bearer hook is an onRequest hook on the whole instance and already covers
every /_web/ path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Chromium reads mp3, m4a, ogg-opus, wav and flac, which the Node decoders
cannot, so the page decodes a voice attachment with Web Audio and hands the
backend mono 16 kHz PCM. Desktop goes over IPC and CLI Web over /_web, and the
adapter absorbs the difference; Web WASM has no backend, so it simply has no
transcription capability and useTranscriptionService() returns null there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The session tools panel gets a "transcribe voice" entry that lists the voice
attachments with no transcript yet and works through them one at a time:
decode in the page, send the PCM, store the result. Cancel takes effect between
two attachments — the one in flight is awaited — and a run that finishes with at
least one transcript reloads the session the same way an incremental import does.

The entry only appears where the platform adapter exposes a transcription
capability, so Web WASM never shows it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Settings > AI gains a voice-to-text section with the two values the backend
already stores: the Whisper size and the default language. The download sizes
and the "base or larger for Chinese" advice sit next to the size picker, since
that is where a user decides whether the larger model is worth the disk.

Both the section and its anchor are conditional on the platform having a
transcription capability, so Web WASM shows neither.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…closed

Emitting `transcribed` only from the footer button missed Esc, the overlay and
the modal's own close control, so a session whose voice messages had just been
transcribed kept showing the old placeholders until the page was revisited.
Moving it onto the close watcher covers every path.

While in there: an attachment interrupted mid-decode by Cancel goes back to
pending rather than being reported as a failure, so "transcribe the rest" picks
it up, and the settings pickers relabel when the interface language changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The AI settings section grows a third row next to model and language, so a
user whose chat is in traditional characters (or who wants simplified in a
chat that mixes both) can pin the script instead of relying on the guess.
"Auto" stays the default and follows the conversation's own text.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The tools panel is always in header mode for regular users (the side layout
is debug-only), and header mode lists only the short header subset, so the
transcription entry added to the full list was unreachable. Build the header
subset from the capability-filtered tool list instead of a second array.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Decoding inside an OfflineAudioContext at Whisper's sample rate lets Chromium
resample once during decode, instead of decoding at the device rate and
resampling again in a second offline pass, and it holds no audio hardware.
Measured on a 16 kHz clip, both paths differ from the raw samples by at most
5e-5, so this is a simplification rather than a quality fix.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>