Module install 

Wiring borg into a harness, and seeing whether it works: borg install|uninstall <harness|all> [--apply] [--home DIR], borg status, borg doctor.

The wiring is exactly what each adapter README describes, written into the engineer’s user config, as each harness’s module says (harness/): command hooks merged into a JSON file (Claude Code’s ~/.claude/settings.json, each running <this borg> hook claude <event>), or a compiled-in adapter copied whole (omp’s extension, opencode’s plugin), plus the borg skill wherever the harness loads skills (install/skill.rs). An installed borg needs no checkout.

Someone else’s config is precious, so: the default is a dry run that prints the exact diff; --apply first writes a timestamped backup next to every file it changes; merging keeps every other key and hook as it was; re-running changes nothing; uninstall removes only what install adds (borg’s own hook commands, and adapter and skill files whose content is this borg’s). --home replaces HOME and ignores every config-dir variable (the harnesses’ and $BORG_HOME/$BORG_CONFIG, see home_overrides), so a test can never reach a real config or store.

Re-exports

pub use crate::harness::Level;

pub use change::Action;

pub use change::Change;

pub use change::apply;

pub use change::diff;

Modules

change

One config file as it is and as it would be (Change), its diff, and writing it: a timestamped backup first, then an atomic replace that keeps the file’s permissions. borg install (install.rs, install/skill.rs) and borg mesh join write every file through here.

setup

borg setup: from a fresh install to a working borg in one guided command.

skill

The borg skill (skills/borg/): how borg works and how to set it up, for the drone itself. Compiled in and copied by borg install into every harness that loads skills (dir), one Change per file, with an adapter file’s rules: each file is copied whole, a symlinked file is replaced (never written through), and uninstall removes only a file whose content is exactly this borg’s, without a backup (borg recreates it exactly), then the skill’s directories once empty. A skill directory that is itself a symlink is the engineer’s (ln -s into a checkout): left alone. borg status and borg doctor report a missing or stale skill (an older borg’s, or edited). borg cannot tell an older borg’s text from an edit, so install backs up either one beside it: after an upgrade that changed the skill, uninstall leaves those backups and the directory holding them.

Structs

Stats

Targets

Where the harnesses read their user config.

Functions

alias_hints

Hints for emails in the stores that share a git user.name (identities: name, email pairs) but are not yet one engineer under the config’s engineers (collective.rs “Engineers”).

collective_checks

Checks on the collectives config and stores.

collectives

Every collective with its store: those in the config, or the one “default” without a config.

home_overrides

Variables --home removes, so every path borg resolves falls under the given HOME: the store ($BORG_HOME, default HOME/.local/share/borg), the collectives config ($BORG_CONFIG, default HOME/.config/borg/collectives.json) and the vector model ($BORG_VECTOR_MODEL, default under HOME/.local/share/borg/models). For status and doctor $BORG_BIN goes too (a real binary to check); install (and borg setup, which installs) keeps it, since there it only names the binary to wire, not a place to write. Harness config-dir variables need no removing: Targets::under never reads them.

main

borg install|uninstall|status|doctor; returns the exit code.

plan

What action would change for h: its hook config or adapter first, then each skill file (install/skill.rs); plus notes: things deliberately left alone, and on install the steps the harness itself asks of the engineer (Harness::install_notes).

sibling

borg-<part> beside this borg, else on PATH: main.rs runs it, borg setup runs borg-mesh.

stats

store_emails

Every engineer email a store records (lessons’ authors and joiners, episodes), as written.

utc

UTC YYYYMMDDTHHMMSS for an epoch-ms time (no time crate for one format).

which

wiring

How h is wired under t, in one line: its hooks or adapter, then its skill.

wiring_checks

Checks on the wiring alone (pure: no PATH, no processes), so they can be tested on fixtures. borg_found: whether the adapters can find a borg ($BORG_BIN or PATH).