Každý klient připojený k serveru checkoutu je peer pojmenovaný vlastním initialize a majordomus_peers vypíše každého pracovníka repozitáře — jeho vlastní nástěnku i nástěnku každého dalšího checkoutu, každý peer označený worktree, ve kterém pracuje — zatímco majordomus_announce sděluje ostatním, na čem pracuje a kterých cest se chystá dotknout

Co to znamená

Když jsou v jednom checkoutu otevřeni dva nebo tři AI klienti, každý se může sdíleného serveru zeptat, kdo další tam je. Peer je relace: vlastní stdio klient serveru, každý přemostěný majordomus mcp a každý klient mluvící přímo /mcp. Je pojmenován podle toho, co jeho klient poslal v initialize (clientInfo.name a version), číslován p1, p2, ... v pořadí připojení, s transportem, časem připojení a časem posledního spatření. Klient může oznámit jednořádkový záměr a cesty relativní k repozitáři, kterých se chystá dotknout; ostatní jej vidí v majordomus_peers a v instructions, které dostanou od initialize a které uvádějí URL serveru, vlastní id volajícího a všechny ostatní peery ještě před prvním voláním nástroje.

Princip

src/peers.rs je nástěnka: připojit, identifikovat, dotknout se, oznámit, odpojit, vypsat, v paměti jednoho procesu. src/capability/builtin.rs deklaruje peers.list (dotaz) a peers.announce (schopnost druhu command, protože tu paměť mění) jako typované deskriptory s explicitními expozicemi a registr je promítá jako všechny ostatní: nástroje majordomus_peers a majordomus_announce, GET /api/v1/peers, POST /api/v1/peers/announce, operace OpenAPI, reference. Handler zjistí, kdo volá, přes caller kontextu, nastavené pro každou relaci pomocí Surface::for_peer; přes prosté HTTP žádný volající není, takže POST /api/v1/peers/announce je odmítnuto a GET /api/v1/peers odpoví bez něj. Zbytek rozhoduje druh: příkaz je vázán na POST a oznámen klientům MCP jako ne jen pro čtení, obojí kontroluje registr.

Jak to vidět

just build
# with a server running (an MCP client open, or `just serve` in another terminal):
curl -s http://127.0.0.1:8741/api/v1/peers | jq '.peers[] | {id, client, transport, announcement}'
# through MCP, in a client: call majordomus_announce with {"intent": "refactor the parser", "scope": ["lib/parse"]},
# then majordomus_peers from another client: the announcement is on the record of the first
apps/majordomus-cli/target/debug/majordomus capabilities describe peers.announce   # kind: command, http: POST /api/v1/peers/announce

Co nepokrývá

Oznámení jsou informativní: nic zde neodmítne zápis mimo oznámený rozsah. Trvalou, vynucovanou podobou „kdo kde pracuje“ je záznam úlohy shellového nástroje a start --scope / check pro každý worktree; nástěnka je živý doplněk v paměti pro klienty sdílející jeden checkout a zaniká se serverem. Nic se neukládá, nic se podle ní nesměruje a k peeru není připojena žádná role, úroveň ani persona.

Proč existuje

Operátor požádal, aby sdílený server nechal různé klienty koordinovat se hned po instalaci. Nejmenší věc, která to umí, je seznam toho, kdo je připojen a co řekl, že dělá, odvozený z handshaku, který každý klient už provádí, zpřístupněný přes registr, aby MCP, HTTP, OpenAPI a reference souhlasily. apps/majordomus-cli/tests/mcp_shared.rs nechá dva klienty oznámit se a vidět se přes skutečné roury; tests/shared_units.rs pokrývá nástěnku; test/cases/90_mcp_shared_server.sh to dělá přes bin/majordomus-mcp v repozitáři, který zapsal init shellového nástroje.