import type { Preprocessor } from './types.js';
/**
 * journal_record pre-processing: one label per submitted record so the
 * reviewer can run the same completeness check as execute_plan (every
 * record must appear exactly once across recorded[]/failed[]).
 *
 * Candidate injection: the deterministic engine retrieves supersede/refine/merge
 * candidates per record so the implementer decides against real nodes.
 * `searchCandidatesForRecordBatch` runs health + freshness ONCE for the whole
 * batch (not once per record — nothing in the store changes between records
 * within one request, so per-record health/freshness was pure repeat work)
 * and searches every record SEQUENTIALLY (not Promise.all): the underlying
 * search opens a SQLite transaction (syncIndexIncremental → BEGIN) on the
 * store's single connection, so concurrent searches would throw "cannot
 * start a transaction within a transaction".
 *
 * `JournalIndexStore` (opened below, a derived SQLite index the store owns
 * for search/candidate ranking) and `JournalStore` (opened in
 * `applyDecisions`, the authoritative markdown-file node store) stay on
 * separate handles: `JournalStore` never opens a database connection at all
 * — it reads/writes `.mma/journal/nodes/*.md` directly — so there is no
 * SQLite handle for it to share with `JournalIndexStore`'s. Nor could the two
 * share a lifetime even if `JournalStore` did use SQLite: the index store is
 * opened, used, and closed here (candidate search happens before the
 * implementer runs), while `JournalStore` is opened later, only if/when
 * `applyDecisions` runs against the implementer's output.
 */
export declare const journalRecordPreprocessor: Preprocessor;
//# sourceMappingURL=journal-record.d.ts.map