feat: capability-based peer discovery (Wave 2)

[Jing-yilin]

Wave 2 — Capability Search

Builds on top of #52 (Wave 1 batch).

Changes

src/peer-db.ts — new findPeersByCapability(cap)

• Exact match: findPeersByCapability('code:review')
• Prefix match: findPeersByCapability('code:') returns all code:* capabilities
• Sorted by lastSeen descending

src/index.ts — capability filter on existing surfaces

• p2p_list_peers agent tool: new optional capability parameter
• p2p-peers CLI command: new --capability <cap> flag
• Both surfaces show capabilities in their peer output lines

test/agentid-peer-db.test.mjs — 4 new tests for findPeersByCapability

Test results

120/120 tests pass (116 from Wave 1 + 4 new)

Usage examples

# CLI
openclaw p2p-peers --capability code:review
openclaw p2p-peers --capability code:

# Agent tool
p2p_list_peers({ capability: 'lang:translate-ja' })

[Jing-yilin]

Codex Review

[Medium] The advertised --capability flag was added to the slash command, not the actual CLI

The PR description and examples call out openclaw p2p peers --capability ..., but the Commander CLI surface is still the separate p2p.command("peers") action. That code path was not updated with an .option("--capability <cap>"), so the real CLI will still reject the flag and its output still omits capabilities. The new filtering logic only exists on the api.registerCommand({ name: "p2p-peers" }) slash command.

Refs: src/index.ts:333, src/index.ts:347, src/index.ts:478

[Medium] Capability search can return peers that no longer advertise that capability

findPeersByCapability() assumes the stored capability list is current, but upsertDiscoveredPeer() only overwrites existing.capabilities when the incoming array is non-empty. If a peer first announces ["code:review"] and later announces [], the old capability is retained, so capability searches keep returning that peer indefinitely. I reproduced this locally against dist/peer-db.js after npm run build.

Refs: src/peer-db.ts:108, src/peer-db.ts:257

---

Reviewed by Codex