P2P Pairing Skills — CC sender + peer responder (MC #102988)
ALAI Company Mesh — P2P Pairing Skills (CC sender + peer responder)
Built: MC #102988 (responder side), 2026-06-05. Extended by MC #102990 (bidirectional), MC #102993 (timeout guard), MC #102996 (autonomous file-mesh loop), and MC #103009 (native-channel decision). Evidence: /tmp/alai/p2p-pairing-evidence/mesh-msg-122e962e-c969-41f1-8f1f-8af6d035e3ca-response.md
2026-06-05 decision (MC #103009): For in-session orchestrator→worker work, use native
Agent(run_in_background:true)+SendMessage. It is instant, harness-delivered, auto-wakes the worker, avoids polling/TTL expiry, and avoids CEO relay. The file-mesh skills documented here remain for cross-machine or deliberately separate terminal sessions only. Evidence:/Users/makinja/system/evidence/mc103009-durable-p2p-messaging-decision-20260605.mdand/tmp/alai/p2p-pairing-evidence/mc103009-sliceB-worker-1.md.
What this is
These skills let two separate Claude Code sessions pair-program / cross-verify over the ALAI Company Mesh (SQLite-backed message bus at ~/system/databases/company-mesh.db). One session SENDS prompts; the peer session WATCHES and RESPONDS. Use this mesh mode only when native in-session Agent/SendMessage is not applicable.
| Side | Skill | Role |
|---|---|---|
| CC agent (this orchestrator) | p2p-pair (~/.claude/skills/p2p-pair/SKILL.md) |
SENDER — company-mesh.js send, await, materialize evidence |
| Peer agent (2nd terminal / pi) | p2p-pair-responder (~/.claude/skills/p2p-pair-responder/SKILL.md) |
RECEIVER — drain inbox, respond, mark processed |
Both registered in skill-registry.db at level 3.
Transport (shared, do not reinvent)
node ~/system/tools/company-mesh.js send|status|await|respond|list— message primitives.- Daemon
com.alai.company-mesh-pi-responder(company-mesh-pi-responder.js): polls the DB every 10s, writes a trigger file to/tmp/alai/pi-mesh-inbox/<message_id>.jsonwhen a message targets the peer agent. It NOTIFIES only — it does not execute prompts. - Helper
~/system/tools/run-p2p-mesh-drain.sh— single-pass inbox lister (john-bash-block auto-allow pattern). - Policy
~/system/lib/p2p-pair-policy.js; context hook~/.claude/hooks/p2p-pair-context-injector.py.
How to pair (operator flow)
- CEO opens a SECOND terminal with a peer Claude Code session.
- Peer session: invoke
p2p-pair-responder("p2p watch" / "enter watch mode"). It drains the inbox on entry, then loops. - This (sender) session: invoke
p2p-pair("pair with pi" / "mesh send") to send a prompt with an explicit end-state (PASS/PARTIAL/BLOCKED/ANSWERED/DECLINED). - Daemon writes the trigger file within ~10s; the watching peer detects it, does the work, responds via
company-mesh.js respondwith evidence, and moves the trigger to/tmp/alai/pi-mesh-inbox/processed/. - Sender's
awaitreturns the peer's end-state + evidence_paths.
Hard contract (post-2026-05-31 incident)
- A handshake ANSWERED does NOT mean follow-on prompts will be handled — the peer MUST be in continuous-watch mode. On 2026-05-31, 6 prompts (#102638–643) expired because the peer was not watching.
- Responder drains the WHOLE inbox on entry (mass-drain) and keeps looping until empty; explicit exit "p2p exit watch".
- Do not mass-dispatch from the sender unless the peer is confirmed in watch mode.
Verification (MC #102988 round-trip)
Real mesh round-trip: send mesh-msg-122e962e (thread mesh-thr-f8f00656) → daemon trigger file written → responder steps executed → respond end_state=ANSWERED with evidence → thread status=answered, turn_count=1. Inbox drained (0 unprocessed, 3 processed). NOTE: a genuine two-live-session test requires CEO to open a real peer terminal; all primitives verified against the live mesh DB.