Module peers 

Peers: the clients attached to one shared server. Every MCP session, the owner’s stdio one and every one that arrived over HTTP, is a peer from the moment it attaches; initialize gives it a name (the client’s own clientInfo), and peers.announce lets it say what it is working on. The board lives in the server’s memory and nowhere else: it ends with the process, and nothing here touches the repository.

Why it is in memory and stays there

A peer board is about now: who is attached, what they said they are doing. Writing it into the repository would make it a record of something that has already stopped being true, and the layer’s records are for what survives the session. The board ends with the process, which is exactly right for a fact about the process.

What a peer may say

An announcement is informational and enforces nothing. Its whole purpose is that another agent working in the same checkout can read it and choose not to collide — the coordination is between the peers, not imposed by the server.

A peer may hold several claims at once, each under a name of its own. One connection is not always one piece of work: a session that fans work out to subagents shares its MCP session with all of them, so they are one peer here while being several workers there. Before named claims the board could hold only the last thing said, and each announcement silently erased the one before it — the other peers stopped being told about scope that was still very much being written. Announcing under the same name updates that claim; announcing under a new one leaves the others standing; announcing without a name is the peer’s one unnamed claim, which is all a single session ever needs.

use majordomus_cli::peers::{ClientInfo, PeerBoard, Transport};

let board = PeerBoard::new();
let id = board.attach(Transport::Stdio);
board.identify(&id, ClientInfo::unknown());

let announced = board
    .announce(&id, "landing the quality gate", vec!["apps/majordomus-cli".into()])
    .expect("the peer is attached");
assert_eq!(
    announced.peer.announcement.as_ref().map(|a| a.intent.as_str()),
    Some("landing the quality gate")
);
assert_eq!(board.list().len(), 1);

// a session that ends is no longer counted; what it announced stays readable, so the
// next worker can still see the claim and avoid it
board.detach(&id);
assert_eq!(board.len(), 0);
assert!(!board.list()[0].attached);

Structs

Announced

What announce answers: the peer as recorded, and who else is on that ground.

Announcement

One claim a peer has made: what it is working on, and where.

ClientInfo

What a client said about itself in initialize.

Overlap

Two peers that claimed the same ground.

OverlapPath

One pair of claims that contain one another.

Peer

One peer as the board lists it.

PeerBoard

The peers of one server process.

PeerCheckout

Which checkout of the repository a peer is attached to.

PeerId

A peer’s identity for the life of the server: p1, p2, … in attachment order. p1 is the session that started the server.

Enums

Transport

How a peer reached the server.

Functions

claims_meet

Do two claimed paths meet? Equal, or one inside the other.

epoch_seconds

The inverse of rfc3339: 2026-08-29T10:40:00Z back to Unix seconds.

overlaps_among

Every pair of claims that meet among an arbitrary set of peers, each pair once.

parse_rfc3339

Seconds since the epoch of YYYY-MM-DDTHH:MM:SSZ, the one shape rfc3339 writes, and its inverse. Anything else is None: a reader that guessed at other shapes would turn a malformed time into a plausible one.

rfc3339

A SystemTime as RFC 3339 in UTC, to the second (2026-09-05T12:34:56Z).