feat: extract groups from message logs

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

@@ -1103,7 +1103,7 @@ Evidence precheck result:
 - Search query matches group JID/display name case-insensitively.
 - This loop does not register `isphere_search_groups`; registration comes after source behavior passes tests.
 
-- [ ] **Step 1: Write failing group extraction test**
+- [x] **Step 1: Write failing group extraction test**
 
 Create `internal/isphere/groups_test.go` and run:
 
@@ -1113,11 +1113,11 @@ go test ./internal/isphere -run TestSearchGroupsFromMessagesMatchesGroupchatJIDs
 
 Expected initial failure: group search types/functions do not exist.
 
-- [ ] **Step 2: Implement group extraction/search**
+- [x] **Step 2: Implement group extraction/search**
 
 Create `internal/isphere/groups.go` with minimal pure Go logic over normalized messages and synthetic groupchat fixtures.
 
-- [ ] **Step 3: Run full verification and rewrite Loop C11**
+- [x] **Step 3: Run full verification and rewrite Loop C11**
 
 Run:
 
@@ -1132,6 +1132,71 @@ Expected: all exit 0. Remove any generated root `isphere-mcp.exe` after build. R
 
 ---
 
+## Loop C10 Result
+
+Implemented and verified in this loop:
+
+- `internal/isphere.SearchGroupsFromMessages(messages, query)` extracts unique group candidates from normalized messages with `ConversationType == "groupchat"` or conference/MUC/group JID markers.
+- Groups currently use the group bare JID as `GroupID` and `DisplayName`; `Source` is `local_readonly`, `Confidence` is `0.6`, and `RawRef` is `groupchat_jid` until richer group roster/display-name evidence is validated.
+- Query matching is case-insensitive over group JID/display name and `Limit` truncates deterministic sorted results.
+- Verification completed for C10 with the loop-specific test; full verification is run again before commit.
+
+---
+
+## Loop C11: Register `isphere_search_groups` MCP tool
+
+**Goal:** Register the group search MCP tool on top of the C10 group extraction behavior while keeping display/member fields clearly marked as JID-derived/unknown.
+
+**Planned files:**
+- Create: `internal/tools/isphere_groups.go`
+- Create: `internal/tools/isphere_groups_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_groups`.
+- Input: `query`, `limit`.
+- Source: group extraction over the same env-configured message source used by receive/contact tools.
+- Output shape: `ok`, `groups`, `next_cursor`, `audit` minimal fields aligned with `docs/mcp-core-tools-contract.md`.
+- Default empty source returns `ok: true`, `groups: []`.
+
+- [ ] **Step 1: Write failing tool test**
+
+Create `internal/tools/isphere_groups_test.go` and run:
+
+```powershell
+go test ./internal/tools -run TestISphereSearchGroupsToolReturnsJIDGroups -v
+```
+
+Expected initial failure: group tool registration does not exist.
+
+- [ ] **Step 2: Implement group tool registration**
+
+Register `isphere_search_groups` with source injection for tests. Use C10 source behavior and return a contract-shaped map with minimal audit metadata.
+
+- [ ] **Step 3: Wire server and verification**
+
+Register group search in server construction. Update server tool-count tests and `scripts/verify-go-mcp.ps1` to expect seven tools and call `isphere_search_groups` against default empty source and synthetic configured groupchat 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 C11 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.