Module 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, hookSpecificOutput with context at a prompt or tool call); adapters translate both ways (harness/). What differs per harness comes from its Harness: capabilities, the turn’s work and the drone’s last message, never its name.

main routes and records presence; dispatch has one function per event. Hooks always fail open: any error lets the drone continue untouched.

Functions

dispatch

One hook event, canonical already (harness normalise), for the drone h runs: what borg answers (Claude-shaped), or None. One function per event.

live_check

borg check (live.rs): one check of the session’s work so far, in the background. Takes the session’s lock (or leaves: a check runs), decides again under it, then runs the stop’s check on this turn so far: the 3s wait in the .queued file as a live <ids> line, the 2s and 1s as at the stop. It writes no #borg-asked (that happens at delivery, ask_live) and no #borg-skip (that closes a stop’s turn): a gate skip is #borg-live-skip. The mark records the changes a completed check covered.

main

borg hook <harness> <event>, the event on stdin: routes the repo to its collective (an off repo leaves no trace), records presence, then answers through steering, the experts and dispatch, with the messages from other sessions (msg.rs). An unknown harness, like any failure here, lets the drone continue untouched.