Crate git_policy_cli 

What: Internal native cli-git implementation, not yet the production executable. Why: The Rust rewrite preserves Git’s own argument, repository and transaction semantics.

In TS you’d write (pseudocode):

// Internal modules used by the forthcoming native entry point and consumer verification.

Layout: Every folder below is one subsystem, and its mod.rs declares the modules inside it. A glob re-export beside each folder keeps the old flat paths (crate::module_name) working. README.md (“Source layout”) says where a new file belongs.

Re-exports

pub use invocation::*;

pub use config::*;

pub use command::*;

pub use policy::*;

pub use markdown::*;

pub use dependent_version::*;

pub use standards_review::*;

pub use candidate::*;

pub use commit::*;

pub use shadow::*;

pub use transaction::*;

pub use landing::*;

pub use service::*;

pub use push::*;

pub use lfs::*;

pub use merge::*;

pub use conflict::*;

pub use worktree::*;

pub use worktree_copying::*;

pub use subvolume::*;

pub use repair::*;

pub use health::*;

pub use repo_read::*;

pub use index::*;

pub use lock::*;

pub use process::*;

pub use foundation::*;

Modules

candidate

Candidate content: what a commit or push would add, read from the index or objects, and the scanner run over it. What: Candidate content: what a commit or push would add, read from the index or objects, and the scanner run over it. Why: Policies judge candidates, so the readers and the scanner adapter share a folder.

command

Per-command handling: the option grammar of each Git command the wrapper understands, and the rules that rewrite, refuse or hint at a command. What: Per-command handling: the option grammar of each Git command the wrapper understands, and the rules that rewrite, refuse or hint at a command. Why: The wrapper judges commands one by one, so everything that is about a single Git command lives together.

commit

The wrapper’s commit path: arguments, preparation, convergence, conclusion and timing. What: The wrapper’s commit path: arguments, preparation, convergence, conclusion and timing. Why: A commit is the central transaction of the wrapper.

config

Reading and validating cli-git.config.jsonc and the Git configuration one invocation is judged by. What: Reading and validating cli-git.config.jsonc and the Git configuration one invocation is judged by. Why: Settings reach every other subsystem through these modules, so they are easy to find in one place.

conflict

Conflict handling around commits and checkouts: side flags, saved copies of conflicted files and leftover markers. What: Conflict handling around commits and checkouts: side flags, saved copies of conflicted files and leftover markers. Why: These modules answer one question, what happens to a file that has conflict state.

dependent_version

The dependent-version policy: manifest and import facts, the release plan and the policy over them. What: The dependent-version policy: manifest and import facts, the release plan and the policy over them. Why: One policy with many small helpers is easier to read as a folder than as a prefix.

foundation

Small shared building blocks: private files, scratch locations, JSON, time, random ids, paths and bounded parallelism. What: Small shared building blocks: private files, scratch locations, JSON, time, random ids, paths and bounded parallelism. Why: Subsystems depend on these and they depend on no subsystem.

health

The doctor report and the checks of hooks and configuration it runs. What: The doctor report and the checks of hooks and configuration it runs. Why: A report reads many subsystems but is one feature.

index

In-process reading and writing of the Git index file and its extensions. What: In-process reading and writing of the Git index file and its extensions. Why: The index format is one specification with many parts.

invocation

What one invocation does from arguments to Git: the decision, real Git resolution, forwarding, startup and management words. What: What one invocation does from arguments to Git: the decision, real Git resolution, forwarding, startup and management words. Why: The thin executables call into this folder first.

landing

What the commit service does to land a commit: the serialized step, the index lock hold, preparation, replay and after-commit work. What: What the commit service does to land a commit: the serialized step, the index lock hold, preparation, replay and after-commit work. Why: The landing is the service’s core and changes together.

lfs

Git LFS support: pre-push planning, pointer scanning and bounded uploads. What: Git LFS support: pre-push planning, pointer scanning and bounded uploads. Why: LFS is an optional feature with its own vocabulary.

lock

Locks and their owners: the index lock, stale reference locks, and the claims that let one command work on a worktree. What: Locks and their owners: the index lock, stale reference locks, and the claims that let one command work on a worktree. Why: Every lock question has one answer in one place.

markdown

The markdown/autofix policy and its in-process linter. What: The markdown/autofix policy and its in-process linter. Why: The linter runs on a guarded thread and has its own configuration, so it stays apart from the other policies.

merge

Merges: the word-level second pass, isolated merges and pull handling. What: Merges: the word-level second pass, isolated merges and pull handling. Why: Merge code shares fixtures and a journal, so it is kept together.

policy

The policy engine: the registry, triggers, events, the passes over candidates and direct fixes. What: The policy engine: the registry, triggers, events, the passes over candidates and direct fixes. Why: Policies are the reason the wrapper exists, so the engine and its shared pieces have one home.

process

Processes: identities, trees, sockets, signals and quiet-time ledgers. What: Processes: identities, trees, sockets, signals and quiet-time ledgers. Why: The facts about processes are shared by locks and pushes.

push

Pushes: the automatic push after a commit, manual push handling, bounded Git queries, retries and progress watching. What: Pushes: the automatic push after a commit, manual push handling, bounded Git queries, retries and progress watching. Why: Push has a long lifecycle with many waits.

repair

Package-manager and toolchain repair after a worktree is created. What: Package-manager and toolchain repair after a worktree is created. Why: Repair runs after worktree creation and has its own report.

repo_read

In-process repository reads: objects, packs, refs, layout and configuration without starting Git. What: In-process repository reads: objects, packs, refs, layout and configuration without starting Git. Why: Reading without a Git process is one capability.

service

The resident commit service: protocol, server, client, journal, provisioning and logging. What: The resident commit service: protocol, server, client, journal, provisioning and logging. Why: The service is a second program with its own life.

shadow

The shadow repository and the replay of captured changes onto it. What: The shadow repository and the replay of captured changes onto it. Why: Commit preparation works on a shadow, so its helpers stay together.

standards_review

The standards-review shadow run: its request, the patch it covers, its one HTTPS call and the result it appends. What: The standards-review shadow run: its request, the patch it covers, its one HTTPS call and the result it appends. Why: The review is optional and self-contained, so its modules sit together.

subvolume

Btrfs subvolume worktrees and the filesystem primitives under them. What: Btrfs subvolume worktrees and the filesystem primitives under them. Why: Platform-specific code is easier to audit in one folder.

transaction

Durable transaction state: owner records, journal, phases and recovery. What: Durable transaction state: owner records, journal, phases and recovery. Why: Every durable state shares one fail-closed recovery.

worktree

Worktree commands: add, remove, clean, convert, trash, snapshots and the placement ladder. What: Worktree commands: add, remove, clean, convert, trash, snapshots and the placement ladder. Why: Worktree lifecycle code shares plans and journals.

worktree_copying

Copying the ignored state of a linked worktree into a new one, with staging, journal and recovery. What: Copying the ignored state of a linked worktree into a new one, with staging, journal and recovery. Why: The copy is a transaction of its own with many small steps.

Macros

service_error

What: Writes one formatted line at the err priority, with its time. Why: Something the service needed failed; journalctl --priority=err shows it.

service_log

What: Writes one formatted line to the service’s log, with its time. Why: Every line the service writes states its own time (stamped_line); the macro is the one way to write a line with arguments.

service_warn

What: Writes one formatted line at the warning priority, with its time. Why: Something did not go as intended and the service went on; journalctl --priority=warning shows it.