feat: extract contacts from message logs

docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md

@@ -929,7 +929,7 @@ Implemented and verified in this loop:
 - `Limit <= 0` returns all matches; positive `Limit` truncates.
 - This loop does not register the MCP tool yet; registration comes after source behavior passes tests.
 
-- [ ] **Step 1: Write failing contact extraction test**
+- [x] **Step 1: Write failing contact extraction test**
 
 Create `internal/isphere/contacts_test.go` and run:
 
@@ -939,11 +939,11 @@ go test ./internal/isphere -run TestSearchContactsFromMessagesMatchesBareJIDs -v
 
 Expected initial failure: contact search types/functions do not exist.
 
-- [ ] **Step 2: Implement contact extraction/search**
+- [x] **Step 2: Implement contact extraction/search**
 
 Create `internal/isphere/contacts.go` with minimal pure Go logic over normalized messages. Use synthetic/redacted fixtures only.
 
-- [ ] **Step 3: Run full verification and rewrite Loop C8**
+- [x] **Step 3: Run full verification and rewrite Loop C8**
 
 Run:
 
@@ -958,6 +958,71 @@ Expected: all exit 0. Remove any generated root `isphere-mcp.exe` after build. R
 
 ---
 
+## Loop C7 Result
+
+Implemented and verified in this loop:
+
+- `internal/isphere.SearchContactsFromMessages(messages, query)` extracts unique contact candidates from normalized message sender/receiver bare JIDs.
+- Contacts currently use bare JID as `ContactID`, `DisplayName`, and `Account`; `Source` is `local_readonly`, `Confidence` is `0.6`, and `RawRef` is `message_jid` until richer roster/display-name evidence is validated.
+- Query matching is case-insensitive over bare JID/display name and `Limit` truncates deterministic sorted results.
+- Verification completed for C7 with the loop-specific test; full verification is run again before commit.
+
+---
+
+## Loop C8: Register `isphere_search_contacts` MCP tool
+
+**Goal:** Register the contact search MCP tool on top of the C7 contact extraction behavior while keeping the tool read-only and clearly marked as JID-derived/local-readonly until richer contact evidence is available.
+
+**Planned files:**
+- Create: `internal/tools/isphere_contacts.go`
+- Create: `internal/tools/isphere_contacts_test.go`
+- Modify: `internal/mcpserver/server.go`
+- Modify: `internal/mcpserver/server_test.go`
+- Modify: `scripts/verify-go-mcp.ps1`
+- Modify: `docs/go-mcp-runbook.md`
+- Modify: `docs/current-status-card.md`
+- Modify: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`
+
+**Planned interface:**
+- Tool name: `isphere_search_contacts`.
+- Input: `query`, `limit`.
+- Source: contact extraction over the same env-configured message source used by `isphere_receive_messages`.
+- Output shape: `ok`, `contacts`, `next_cursor`, `audit` minimal fields aligned with `docs/mcp-core-tools-contract.md`.
+- Default empty source returns `ok: true`, `contacts: []`.
+
+- [ ] **Step 1: Write failing tool test**
+
+Create `internal/tools/isphere_contacts_test.go` and run:
+
+```powershell
+go test ./internal/tools -run TestISphereSearchContactsToolReturnsJIDContacts -v
+```
+
+Expected initial failure: contact tool registration does not exist.
+
+- [ ] **Step 2: Implement contact tool registration**
+
+Register `isphere_search_contacts` with source injection for tests. Use C7 source behavior and return a contract-shaped map with minimal audit metadata.
+
+- [ ] **Step 3: Wire server and verification**
+
+Register contact search in `mcpserver.NewServerWithReceiveSource` or an equivalent shared source path. Update server tool-count tests and `scripts/verify-go-mcp.ps1` to expect six tools and call `isphere_search_contacts` against both default empty source and synthetic configured fixture.
+
+- [ ] **Step 4: Run full verification and commit**
+
+Run:
+
+```powershell
+git diff --check
+go test ./...
+go build ./cmd/isphere-mcp
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/verify-go-mcp.ps1
+```
+
+Expected: all exit 0. Remove any generated root `isphere-mcp.exe` after build. Commit exact C8 paths only and rewrite the next loop from actual results.
+
+---
+
 ## Self-Review
 
 - Spec coverage: the plan follows the user's cyclic requirement: plan first, implement one loop at a time, update the next loop after each result, and ask only on blockers.