Module transaction 

Durable transaction state: owner records, journal, phases and recovery. What: Durable transaction state: owner records, journal, phases and recovery. Why: Every durable state shares one fail-closed recovery.

In TS you’d write (pseudocode):

// transaction/index.ts: one `export * from './file'` per module below.

Modules

recovery_error

The fail-closed failure of reading or recovering durable transaction state. What: The fail-closed failure of reading or recovering durable transaction state. Why: Malformed, unsafe or contradictory state is never guessed at or deleted: the command stops with exit status 2 and a message naming the path, and the state stays for inspection (CommitTransactionRecoveryError in the incumbent; implementation plan, “Commit transactions and recovery”).

recovery_files

No-follow file operations recovery and landing share. What: The small file operations the shadow, the pack keep files, the conclusion copies and the worktree installs share: existence probes, an optional read, removal of one file, and the name of Git’s PID file beside a lock. Why: Each fails closed with the path and the operation named (RecoveryError), as the incumbent’s commit-transaction-recovery-files.ts does.

transaction_git

Running real Git for transaction, recovery and landing work. What: Running real Git for transaction, recovery and landing work: captured output, an optional private index and object store, extra or removed variables, and bytes on standard input. Why: Every transaction step asks Git a question or writes an object; one runner keeps every such start an argument array (never a shell string) carrying the wrapper’s child environment overlay (lock PID injection), as the incumbent’s runTransactionGit does.

transaction_journal

The schema-version-2 journal records of one commit transaction and their filenames. What: The values a commit’s preparation and the service’s landing share about the repository state they work on: the base, the symbolic head, the private index mode, the sequencer conclusion, the ref storage format and a policy-added path. Why: The records the earlier transaction wrote into its registry (preparing, prepared, ref-updated, landing and index-lock records) are gone with the transaction; only the types the service route still passes between its steps remain (src/policy-engine/commit-transaction-journal-states.ts is their incumbent).

transaction_owner

The owner record of one commit-transaction directory and its liveness rule. What: The owner record of one commit-transaction directory (owner.json, schema version 2) and the liveness rule that decides whether recovery may touch the transaction. Why: The owner record is written before the directory is published, so recovery can skip a live owner’s transaction at every phase. Both wrappers write and judge the same record (src/policy-engine/commit-transaction-owner.ts).

transaction_phase

Test-only transaction phase markers, compiled into the release executable and armed only by an environment variable. What: Test-only phase markers of the isolated merge and of a commit headed for the service, for crash and interleaving suites. An explicit environment variable arms one marker: CLI_GIT_TEST_ONLY_PHASE_SIGNAL=<phase>:kill ends the process with SIGKILL at the phase, <phase>:kill:<directory> writes <directory>/<phase>.reached first, and <phase>:pause:<directory> writes that marker and waits until <directory>/<phase>.release exists. A repeatable phase numbers its files by occurrence: <phase>-<n>.reached. Why: Crash suites need a deterministic point to kill the wrapper. The marker is compiled into the release executable, but only the explicit variable arms it, and a malformed value fails the invocation at every phase it reaches instead of being ignored (src/policy-engine/commit-transaction-test-phase.ts).