feat: register isphere group search tool

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

@@ -1164,7 +1164,7 @@ Implemented and verified in this loop:
 - 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**
+- [x] **Step 1: Write failing tool test**
 
 Create `internal/tools/isphere_groups_test.go` and run:
 
@@ -1174,15 +1174,15 @@ go test ./internal/tools -run TestISphereSearchGroupsToolReturnsJIDGroups -v
 
 Expected initial failure: group tool registration does not exist.
 
-- [ ] **Step 2: Implement group tool registration**
+- [x] **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**
+- [x] **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**
+- [x] **Step 4: Run full verification and commit**
 
 Run:
 
@@ -1197,6 +1197,54 @@ Expected: all exit 0. Remove any generated root `isphere-mcp.exe` after build. C
 
 ---
 
+## Loop C11 Result
+
+Implemented and verified in this loop:
+
+- `internal/tools.RegisterISphereGroupTools(server, source)` registers `isphere_search_groups` over the same receive-message source used by receive/contact tools.
+- `internal/mcpserver.NewServerWithReceiveSource` now exposes seven tools: four WinHelper tools, `isphere_receive_messages`, `isphere_search_contacts`, and `isphere_search_groups`.
+- `scripts/verify-go-mcp.ps1` now expects seven tools, verifies default empty group results, and verifies configured synthetic groupchat extraction.
+- `isphere_search_groups` currently returns JID-derived `local_readonly` groups with unknown member/owner fields and minimal audit metadata.
+- Verification completed for C11 with affected package tests and `powershell -NoProfile -ExecutionPolicy Bypass -File scripts/verify-go-mcp.ps1`; full verification is run again before commit.
+
+---
+
+## Loop C12: File receive source evidence precheck
+
+**Goal:** Before implementing `isphere_receive_files`, verify whether current decrypted PacketReader/Smark/SaveToDB evidence and extracted cache paths contain enough file-transfer metadata to support a real read-only file listing/download-reference source.
+
+**Planned files:**
+- Modify: `docs/source-discovery/capability-source-matrix.md`
+- Modify: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`
+- Optionally create ignored metadata under `runs/`; do not commit raw evidence.
+
+**Planned behavior:**
+- Inspect committed schema notes and ignored N12-pre metadata/log summaries for file-transfer subjects, file names, cache/hash paths, download refs, or attachment-like fields.
+- If evidence exists, write C13 around file metadata extraction from normalized messages/cache references.
+- If evidence is insufficient, mark `isphere_receive_files` blocked on additional file-transfer/cache mapping evidence and move to source hardening/docs instead.
+
+- [ ] **Step 1: Inspect current source evidence for file-transfer identifiers**
+
+Use committed schema notes and ignored summaries/log scans. Do not commit raw logs or decrypted content.
+
+- [ ] **Step 2: Update matrix and next loop**
+
+Record whether file receive implementation can proceed from current evidence. Rewrite C13 accordingly.
+
+- [ ] **Step 3: Verify docs-only change and commit**
+
+Run:
+
+```powershell
+git diff --check
+go test ./...
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/verify-go-mcp.ps1
+```
+
+Expected: all exit 0. Commit exact C12 paths only.
+
+---
+
 ## 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.