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.md and /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>.json when 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 respond with evidence, and moves the trigger to /tmp/alai/pi-mesh-inbox/processed/ . 
 Sender's await returns 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.