Module capture_invocation 

The invocation capture: repository layout, symbolic HEAD, conclusion kind, ref backend and base. What: The transaction facts recorded before any Git mutation: the repository layout, the symbolic HEAD target, the conclusion kind, the ref storage backend, and the preparation base. Why: Every later read of HEAD inside a transaction uses the recorded base or the landed commit, never live HEAD, because another landing may have moved it since the invocation started. The layout query and the base read run as separate steps, so pruning sees the transaction before the base is read (src/policy-engine/commit-transaction-capture.ts, captureInvocationLayout and captureInvocationBase).

In TS you’d write (pseudocode):

const layout = await captureInvocationLayout({ gitPath, cwd, amend });
const capture = await captureInvocationBase({ gitPath, cwd, layout });

Structs

InvocationCapture

What: Every invocation fact, including the preparation base. Why: InvocationCapture in the incumbent is the layout plus the base read after it.

InvocationLayout

What: Facts about the repository one invocation selects, recorded before the transaction publishes anything. Why: InvocationLayout in the incumbent: every field except the preparation base.

Functions

base_revision

What: The revision the transaction reads as its baseline tree: the base commit, or the empty tree when unborn. Why: Every baseline read of the transaction uses this one revision.

capture_invocation_base

What: Completes the capture with the preparation base: the target’s commit now. Why: Read after the layout and after the capture sequence is taken, so the base is never older than the sequence the transaction records.

capture_invocation_layout

What: Captures every invocation fact except the preparation base, before any Git mutation. Why: One layout request reports the paths, and the independent probes follow it.

resolve_conclusion_kind

What: Resolves the commit kind from the amend flag and the owning worktree’s conclusion state. Why: An amend always wins; otherwise the first present marker in the incumbent’s order decides. A marker whose every lookup place is empty on the files backend is absent without asking Git; any entry in any place, of any content, is resolved by rev-parse --verify, so a marker naming a missing object stays a conclusion.

resolve_ref_commit

What: Resolves a ref to its commit, or to an unborn base when it names nothing. Why: The preparation base is the target’s commit at invocation, and an unborn target starts from the empty tree.

resolve_ref_format

What: Reads the ref storage backend. Why: A Git that cannot report it (before 2.45) is the files backend.

resolve_ref_format_with

What: Reads the ref storage backend, from the configuration snapshot when it proves files. Why: rev-parse --show-ref-format prints reftable only for a repository whose configuration names extensions.refStorage, so a snapshot read without global options that has no such key proves files without starting Git; any other snapshot, and a missing one, asks Git.

resolve_symbolic_head

What: Resolves the symbolic HEAD target in the owning worktree. Why: The HEAD file answers when it is one of the two plain spellings on the files backend, read afresh on every call so the landing’s re-read stays a read at landing time; anything else asks Git, where exit 1 from symbolic-ref --quiet means detached and any other failure is an error.