Module worktree_copy_install_log 

The append-only install log of one stage: per-batch intents and creations, with resumption. What: The append-only install log inside one transaction’s private stage: one synced JSON line per batch of intents and one per batch of proven creations. Why: The journal header changes only with the phase, so the per-batch records live here; bytes written then grow with the entry count instead of with the square of it.

In TS you’d write (pseudocode):

await using opened = await openInstallLog(stageContainer);
await opened.log.appendIntents(paths);

Structs

InstallLog

What: The append handle of one log. Why: Each append is synced before the caller mutates the destination, so a crash leaves the claim on disk.

InstallLogRecords

What: The records an existing log holds. Why: An interrupted installation resumes from exactly these claims and creations.

OpenedLog

What: An open log together with what it already held. Why: The caller seeds its claim and creation sets from the recorded part before it installs anything.

Constants

INSTALL_LOG_NAME

What: The install-log file name inside a stage container. Why: Recovery finds the log by this name, so both wrappers must agree on it.

Functions

open_install_log

What: Opens the log of one stage, returning what it already records and truncating any unfinished append. Why: Resumption must see every claim and creation, and new records must start on a fresh line.