/**
 * First-start metadata indexing, off the main thread.
 *
 * When the server starts with an empty symbol database and METADATA_PATH set,
 * it indexes the requested models before it declares itself ready. That build
 * is synchronous end to end — a recursive readdirSync per model, node:sqlite
 * inserts, one FTS rebuild — and inline on the main thread it blocked the
 * event loop for the whole duration: every tool call, get_workspace_info
 * included, hung until the build finished, on exactly the machine where the
 * user was trying the server for the first time.
 *
 * Here the same XppSymbolIndex.indexMetadataDirectory runs on its own
 * connection. WAL mode lets the main thread keep serving from the same file —
 * the startup path never takes the EXCLUSIVE lock the build scripts use, so
 * the two connections coexist — and the main thread sees each model as its
 * transaction commits.
 *
 * Spawned by indexMetadataOffThread() (startupIndexing.ts) and posts:
 *   { type: 'progress', progress } | { type: 'done', elapsedMs, symbolCount }
 *   | { type: 'error', error }
 *
 * The progress messages exist because the parent has to answer "still loading"
 * to every symbol-backed tool for as long as this runs, and on a first start
 * that is tens of minutes. Without them the answer cannot say how far along the
 * build is, which leaves a user unable to tell a long build from a dead one.
 *
 * Bundled by build:scripts beside the other workers (tests/packaging/workerBundles).
 */
import { type IndexProgress } from './symbolIndex.js';
export interface StartupIndexWorkerData {
    dbPath: string;
    labelsDbPath: string;
    metadataPath: string;
    modelNames: string[];
}
export type StartupIndexMessage = {
    type: 'progress';
    progress: IndexProgress;
} | {
    type: 'done';
    elapsedMs: number;
    symbolCount: number;
} | {
    type: 'error';
    error: string;
};
//# sourceMappingURL=startupIndexWorker.d.ts.map