Expand description
borg as a library: the conscience, its learning loop and the expert index, shared by the
borg CLI (main.rs) and the eval harness.
Internal API, no semver. It exists for borg’s own crates (borg-mesh, borg-web, the evals),
which pin it = to the same version. Any release may change or remove any item; depend on the
borg binary and its documented files instead.
Modules§
- absorb
- Absorbed lessons: long-term knowledge an outside store now holds, so Borg stops delivering it.
- assimilate
borg assimilate: bootstrap the collectives from the engineer’s existing history, so Borg is useful on day one instead of after weeks of live capture.- assimilate_
dir borg assimilate --from-dir <dir>: a team’s written knowledge becomes lessons of its collective.- clock
- Wall-clock units and formats, each defined once: a day, the civil calendar, how long ago.
- collective
- Separate minds: which collective a repo belongs to, or none.
- completions
- The command table of the borg CLI, and
borg completions <bash|zsh|fish>: a shell completion script for borg, printed to stdout. - conscience
- The conscience: challenges learned from engineers’ corrections, asked at decision points when what the drone is working on matches.
- escalation
- The queen’s attention reward: did an escalation spend the engineer’s minutes well?
- expert
- L2 of the expertise ladder: a version-keyed expert index of another repo (PLAN.md, “Expertise and the queen”).
- facets
- Facets: one lesson phrased several ways, so keyword search finds it from different angles (document expansion, “doc2query”; internal evaluation “facets”, not published).
- harness
- The coding agents borg runs in (“harnesses”), each one module behind one trait.
- hook
- The hook: every harness’s events, one canonical, Claude-shaped event each (session_id, cwd, prompt,
tool_name, tool_input, error, last_assistant_message, transcript_path, stop_hook_active), answered
Claude-shaped ({“decision”:“block”,“reason”} at stop,
hookSpecificOutputwith context at a prompt or tool call); adapters translate both ways (harness/). What differs per harness comes from itsHarness: capabilities, the turn’s work and the drone’s last message, never its name. - install
- Wiring borg into a harness, and seeing whether it works:
borg install|uninstall <harness|all> [--apply] [--home DIR],borg status,borg doctor. - learn
- The conscience’s live learning loop.
- listen
borg listen: a session that listens is woken when a message for it (msg.rs) arrives while it is idle. Run inside a session, it opts that session in (<store>/listen/<session>.json, never synced) untilborg listen --off, the session’s end, or its presence record’s prune (presence.rsprune). A plain session is never woken.- live
- Delivery modes: when the conscience judges the work (docs/delivery.md).
- memory
- Usefulness as the memory dynamics of a collective brain (internal evaluation “phase-r”, “R1 design”, not published).
- memory_
export borg memory: the evidence behind each lesson, for an outside store to take over long-term knowledge.- msg
- Messages between sessions:
<store>/messages.jsonl, one line perborg tellorborg ask, from a session on any harness (or the engineer’s terminal) to the sessions on this machine (local, writtenlocal@<node>), every session of the collective on every member’s machine (collective, or its synonymall, writtenallas it always was), one session on one node (<session>@<node>), or the engineer (engineer[:<email>]): anAddress, parsed in one place. Local first: alocalline never leaves this machine (borg-mesh lines.rstravelskeeps it here), and a drone named on the command line is this machine’s when one here matches; a colleague’s session is reached by its node, bycollective, or as the sender of what a reply answers. A 0.4.0 reader parseslocal@<node>as the sessionlocalof that node, which no session is: it reaches nobody there. Plain lines, each naming its node, so the mesh can union them like the other synced logs; on one machine they need no mesh. Aborg pause,borg resumeor a remoteborg nois a message too, of a privilegedKindthat counts only under an admitted role (steer.rs). - notes
- Reasoning travels with the code: a redacted excerpt per landed commit, as a git note.
- ope
borg debug ope: off-policy estimates of the usefulness belief’s hand-set weights, from the outcome log alone. Reports, never applies: no constant changes.- outcome
- What happened after the conscience asked a lesson: the signal for down-weighting lessons that are generic or do not help, and for trust per engineer × area (trust.rs).
- prefilter
- The free gate before the Stop model call (internal evaluation “stop-prefilter”, not published).
- presence
- Who is working where, right now: one tiny record per drone session, for
borg top(top.rs) and for steering (steer.rs) to name a drone. - protocol
- What each mesh protocol changed, and what this node knows of its peers’ versions: the one place that says what is going on when the team runs more than one borg.
- queen
- The queen: the rare, budgeted escalation to a human engineer (PLAN.md “Expertise and the queen”; internal evaluation “expertise” §2, L4, not published).
- reach
- Who should hear a lesson: its reach.
- reexec
- A long-lived process follows a reinstall in place:
cargo installrenames a new file over the old, and an old image would go on running the code it was started with. - review_
fix borg review-fix: the bugs a review step found and a fix step fixed, inside a session, before anything was committed. Most bugs are caught there (a build → review → verify → fix workflow), and a commit-based signal (regress links: a later commit from another session) never sees them.- select
- Which of a graded check’s applies to ask, to hand over free, to judge blindly as a placebo, or to
leave for later: the lesson selection policy. It replaces attention.rs, which stays one release as
the
Attentionsub-policy. - stats
- What Borg did, counted: the collective’s usage statistics.
- steer
- Steering: pause, resume and veto, the privileged kinds of a message (msg.rs
Kind). - sweep
- Transcript capture: the engineer’s corrections and answers read from each harness’s own transcript,
the durable record, beside the hooks’ live capture. A hook can go quiet when a harness changes (Claude
Code 2.1.312 stopped sending its
PostToolUseFailurefor a rejected tool call, while its transcript still names the engineer’s words); the transcript cannot. - top
borg top [--dir DIR] [--once] [--json]: the drones of each collective, one screen.- trust
- Trust per engineer × area, earned from outcomes (PLAN.md “Assimilation”, step 4).
- update
- Whether a newer borg is released, and
borg update [--check] [--quiet] [--json], which installs it. - vectors
- Vector recall for the Stop step (internal evaluation “vectors”, not published).
- veto
borg no: the engineer’s veto, the strongest negative signal.- why
borg why: the reasoning behind code, on demand (PLAN.md “Recall mechanics”).