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.

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_symbolic_head

What: Resolves the symbolic HEAD target in the owning worktree. Why: Exit 1 from symbolic-ref --quiet means detached; any other failure is an error.