Module entry 

The per-invocation decision the thin executable performs. What: Decide what one git invocation of the native wrapper does, and perform it. Why: The executable stays thin: it gathers process facts, asks this module for an action, and performs it. The decision itself is testable without replacing the test process.

In TS you’d write (pseudocode):

// const action = planInvocation(args, env, inputs); perform(action);

Constants

MANAGEMENT_COMMAND

The management namespace: git cli-git ... is handled by the wrapper, never by Git.

Functions

plan_invocation

What: Decide the action for one invocation from injected process facts. &[OsString] borrows the arguments after the program name; &[(OsString, OsString)] borrows the environment as name/value pairs. Why: Order matters. The recursion check runs before anything else. Wrapper controls written before the subcommand are removed first, because Git’s own reading of the arguments stops at them and would hide the subcommand from every later decision. The management namespace is answered by the wrapper. Every other command goes through the wrapped-command lifecycle with real Git behind it.

run_process

What: Run one invocation with the real process facts and return its exit code. i32 is a signed 32-bit integer, the type of process exit codes. Returns only when Git was not started; a forwarded command never returns. Why: This is everything the executable’s main does; keeping it in the library lets the same code be measured by tests and mutation runs.