import type { DatabaseHandle } from './db.js';
/**
 * Atomically rewrite every row keyed on `oldId` to use `newId` instead. This
 * is the primitive behind `move_note`: by updating node / edge / chunk / sync
 * / community rows in place, inbound edges survive the rename without the
 * delete-then-upsert dance that the indexer's deletion-detection loop would
 * otherwise do (which drops every inbound edge).
 *
 * Tables touched, in transaction order:
 *
 *   1. `chunks`  — composite PK `${nodeId}::${chunkIndex}`. Rewrite both the
 *                  id and node_id in one statement.
 *   2. `edges`   — both `source_id` and `target_id`; no FK enforcement.
 *   3. `sync`    — the path column shares the node-id namespace.
 *   4. `nodes`   — the text PK. SQLite rowid is separate and unchanged, so
 *                  `nodes_fts` (content='nodes', content_rowid='rowid') and
 *                  `nodes_vec` (keyed by rowid) stay valid with no action.
 *   5. `communities` — `node_ids` stored as a JSON array; we deserialize,
 *                  swap `oldId` → `newId` in each row that contains it, and
 *                  re-serialize. O(|communities|) rather than O(|rows|).
 *
 * `chunks_vec` is rowid-keyed; `chunks.rowid` doesn't change when we UPDATE
 * the composite id, so no vec-table action is needed.
 *
 * Stub absorption (e.g. `_stub/<oldStem>.md` → `newId`) is deliberately NOT
 * handled here — that is vault-semantic coupling. Callers should run
 * `migrateStubToReal` from `nodes.ts` as a separate step if they want the
 * renamed target to absorb any surviving forward-reference stub.
 */
export declare function renameNode(db: DatabaseHandle, oldId: string, newId: string): void;