Module policy_pass 

One complete pass: built-in policies, fixed transforms, optional policies. What: One complete policy pass over the shipped policies: the built-in policies, then the fixed argument transforms of a forwarded command, then the optional policies. Why: Every lifecycle runs the same three stages in the same order, and each stage can end the pass. Keeping the sequence in one place means a wrapped command and a direct git cli-git check cannot drift apart in what they run or when they stop.

In TS you’d write (pseudocode):

// const result = await runPolicyEngine({ args, trigger, config, selectedPolicyIds });

Structs

PassResult

What: What one pass produced. A struct is a record with named fields; Vec<T> is an owned list. #[derive(...)] asks the compiler to generate copying, debug printing and ==. Why: The caller needs the arguments to forward, every event in emission order, and how the pass ended.

Functions

policies_of_kind

What: The shipped policies of one kind, in registry order. optional selects the policies that are off unless the configuration lists them; Vec<PolicyId> is the owned result. Why: The registry is the only list of policies; the two stages are its two halves, so a policy added there lands in exactly one stage without a second list to update.

run_policy_pass

What: Run one pass for request over checks. <F: RepositoryFacts> says the function works with any one facts provider F; &mut ShippedChecks<F> lends the shipped policies and their provider for writing, because checks cache repository facts. Why: The order is the installed wrapper’s. Built-in policies read the command before it is rewritten. The fixed transforms run only for a forwarded command. Optional policies run last. A stage that did not complete ends the pass with the arguments it was given, and nothing after it runs.