Module post_commit 

The post-commit gate over a landed commit: its events, its blocking and the backup it allows. What: The post-commit policy gate over a landed commit’s own changes. Why: The incumbent (src/policy-engine/post-commit-lifecycle.ts) checks the committed bytes of every path a landed commit changed, and only a gate that passes lets the commit reach auto-push. The push itself is the service’s work item, handed over by commit_command.rs after a passing gate. A blocked gate keeps the commit local and names it in a commit-landed event; the command exits 2. The landed commit is an input, so the integrator can call this after any landing.

In TS you’d write (pseudocode):

const result = await runPostCommitLifecycle({ rawArgs, transformedArgs, gitPath, cwd, landedOid, ... });

Structs

PostCommitGate

What: The settled gate: the landed commit, every event it produced, and whether the backup must not run. Why: events already carries the commit-landed event when blocked is true, so the caller renders one list.

PostCommitRequest

What: The inputs of one post-commit gate. Why: The landed commit names the delta; the global prefix and the environment make every query read the repository the commit landed in.

Constants

POST_COMMIT_BLOCKED_EXIT_CODE

Exit status the command returns when the gate blocks the backup, as the incumbent’s PolicyDecisionError(2).

Functions

run_post_commit_gate

What: Run the post-commit policies over the landed commit’s delta. Why: Only a gate with no blocking event, no failure and no pending correction lets the backup run; a warning-only result is allowed, as in the incumbent. A landed name that is not an object name is an engine failure, so the commit is kept and reported.