feat: register isphere contact search tool

This commit is contained in:
zhaoyilun
2026-07-09 23:36:10 +08:00
parent 2621d34336
commit 2832e286e7
9 changed files with 266 additions and 26 deletions

View File

@@ -14,20 +14,21 @@ Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-repor
## Current completed state
- Go MCP foundation exists: `cmd/isphere-mcp`, `internal/mcpserver`, `internal/helperclient`, and `internal/tools` build a stdio MCP server.
- The current MCP surface exposes five read-oriented tools:
- The current MCP surface exposes six read-oriented tools:
- `win_helper_version`
- `win_helper_self_check`
- `win_helper_scan_windows`
- `win_helper_dump_uia`
- `isphere_receive_messages`
- `isphere_search_contacts`
- C# `ISphereWinHelper` exists under `native/ISphereWinHelper` and uses the `isphere.helper.v1` stdin/stdout JSON contract.
- `scripts/verify-win-helper.ps1` and `scripts/verify-go-mcp.ps1` provide repeatable local checks for the helper, five-tool MCP surface, default empty-source `isphere_receive_messages`, and synthetic configured-source receive smoke.
- `scripts/verify-win-helper.ps1` and `scripts/verify-go-mcp.ps1` provide repeatable local checks for the helper, six-tool MCP surface, default empty-source receive/contact calls, and synthetic configured-source receive/contact smoke.
- N12-pre and N12R documents define safe offline evidence intake and internal-sandbox live UIA capture procedures.
- N13/N14/N15 produced selector catalog/report validation infrastructure, but those are supporting validation assets only.
## What cannot be claimed externally
- The project has not yet implemented business MCP tools for contact search, group search, message sending, file receiving, or file sending; `isphere_receive_messages` has an operator-local encrypted log-file loader but not a production ingestion path.
- The project has not yet implemented business MCP tools for group search, message sending, file receiving, or file sending; `isphere_receive_messages` and `isphere_search_contacts` have operator-local encrypted log-file support but not a production ingestion path.
- The project has not completed production iSphere integration.
- The project has not proven a stable real message source for the full business workflow beyond decrypted PacketReader log evidence and synthetic/redacted tests.
- The project has not implemented real message sending or real file upload.
@@ -40,7 +41,7 @@ Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-repor
- The helper protocol boundary is explicit and keeps Windows/UIA work separate from the Go MCP service layer.
- The current code can support future MCP business tools by routing low-level Windows/UIA fallback work through a bounded helper layer.
- The project has repeatable verification scripts for the helper/MCP foundation and the current five-tool surface.
- The project now has a corrected business contract and plan for core MCP communication tools, plus a registered first read tool that can use `ISPHERE_PACKET_LOG_FILE` for operator-local encrypted PacketReader log lines.
- The project now has a corrected business contract and plan for core MCP communication tools, plus registered receive/contact read tools that can use `ISPHERE_PACKET_LOG_FILE` for operator-local encrypted PacketReader log lines.
## N13/N14/N15 positioning
@@ -48,7 +49,7 @@ N13/N14/N15 are pre-business validation results. They can help identify UI eleme
## Current loop
Current loop: `Stage C / Loop C7 - log-backed contact candidate extraction`.
Current loop: `Stage C / Loop C9 - group source evidence precheck`.
Plan file: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`.
@@ -68,11 +69,11 @@ Current loop output so far:
5. C5: safe `ISPHERE_PACKET_LOG_FILE` loader for operator-local encrypted PacketReader log lines.
6. C6: fixture-backed operator smoke for configured receive source.
7. C7: log-backed contact candidate extraction from sender/receiver JIDs.
8. C8: `isphere_search_contacts` MCP registration and six-tool verification.
## Next business mainline
1. Implement Stage C Loop C7: extract searchable contact candidates from log-backed messages.
2. Register `isphere_search_contacts` after contact source tests pass.
3. Add group/file read tools after their source decisions are recorded.
4. Add `isphere_send_message` and `isphere_send_file` after source discovery and connector selection.
5. Keep UIA selector/report work as fallback support, not as the primary roadmap.
1. Run Stage C Loop C9: verify whether current decrypted log evidence contains group/groupchat identifiers before implementing `isphere_search_groups`.
2. Add group/file read tools after their source decisions are recorded.
3. Add `isphere_send_message` and `isphere_send_file` after source discovery and connector selection.
4. Keep UIA selector/report work as fallback support, not as the primary roadmap.

View File

@@ -90,10 +90,11 @@ The verification confirms:
- C# helper can be built.
- Go MCP binary can be built.
- MCP initialize/list/call flow works through the SDK harness.
- Exactly five tools are exposed: four WinHelper observation tools plus `isphere_receive_messages`.
- Exactly six tools are exposed: four WinHelper observation tools plus `isphere_receive_messages` and `isphere_search_contacts`.
- `win_helper_version` returns `ISphereWinHelper`.
- `isphere_receive_messages` is callable and returns an empty `messages` array from the default empty source.
- A synthetic configured-source smoke check proves `ISPHERE_PACKET_LOG_FILE` can drive `isphere_receive_messages` end-to-end with one redacted fixture message.
- `isphere_search_contacts` is callable and returns JID-derived contact candidates from the same configured synthetic message fixture.
- Verification uses synthetic/local helper checks and does not load raw N12-pre evidence.
- Contact/group/file/search/send business tools remain later-stage work.
@@ -152,7 +153,7 @@ E:\coding\codex\isphere-ai-bridge\isphere-mcp.exe
## 8. Allowed tools
These five tools are currently allowed:
These six tools are currently allowed:
| Tool | Source/op | Purpose |
| --- | --- | --- |
@@ -161,6 +162,7 @@ These five tools are currently allowed:
| `win_helper_scan_windows` | helper `scan_windows` | Read visible window metadata or likely iSphere candidates. |
| `win_helper_dump_uia` | helper `dump_uia` | Read a UI Automation tree for a specified window handle. |
| `isphere_receive_messages` | log-backed `EncryptedPacketLogSource` | Read normalized messages from the configured PacketReader log source. The default server source is empty until a loader is wired. |
| `isphere_search_contacts` | log-backed message JIDs | Search contact candidates extracted from sender/receiver bare JIDs in the configured message source. |
Allowed parameters:
@@ -169,16 +171,18 @@ Allowed parameters:
- `win_helper_scan_windows`: `include_all_visible` only.
- `win_helper_dump_uia`: `hwnd`, `max_depth`, `include_text`, `max_children` only.
- `isphere_receive_messages`: `limit` only.
- `isphere_search_contacts`: `query`, `limit` only.
## 9. Current tool surface and next-stage route
The current runbook verifies five tools:
The current runbook verifies six tools:
- `win_helper_version`
- `win_helper_self_check`
- `win_helper_scan_windows`
- `win_helper_dump_uia`
- `isphere_receive_messages`
- `isphere_search_contacts`
`isphere_receive_messages` currently has parser/source/tool registration and an empty default server source. Raw N12-pre evidence remains under ignored `runs/` paths and is not committed. The current command entry point can read an operator-local encrypted PacketReader log-line file via `ISPHERE_PACKET_LOG_FILE`; this is still not a production ingestion claim because raw evidence remains local and uncommitted.

View File

@@ -18,7 +18,7 @@ Schema notes: `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md`
| MCP tool | Primary source | Fallback source | Evidence file | Decision status | Next implementation slice |
| --- | --- | --- | --- | --- | --- |
| `isphere_receive_messages` | decrypted `PacketReader.ProcessPacket` XMPP `<message>` stanzas via `internal/isphere.EncryptedPacketLogSource` | decrypted `Smark.SendReceive` transport stanzas; decrypted `SaveToDB` `Chat_OnMessageArrived` traces; wrapped `MsgLib.db` after DB wrapper is solved | `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md#field-mapping-evidence` | C5 env loader wired through ISPHERE_PACKET_LOG_FILE; default source remains empty when unset | fixture-backed configured-source operator smoke |
| `isphere_search_contacts` | bare sender/receiver JIDs extracted from normalized log-backed messages | decrypted roster/contact stanzas from `Smark.SendReceive`; `MsgLib.db` contact/conversation tables after DB wrapper is solved; UIA helper source if display names are missing | `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md#log-decryption-result` | C7 source extraction unit-verified with JID-only display/account fallback | register MCP tool from C7 source |
| `isphere_search_contacts` | bare sender/receiver JIDs extracted from normalized log-backed messages | decrypted roster/contact stanzas from `Smark.SendReceive`; `MsgLib.db` contact/conversation tables after DB wrapper is solved; UIA helper source if display names are missing | `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md#log-decryption-result` | C8 MCP tool registered and verify-go-mcp covers default/configured contact smoke; JID-only display/account fallback | enrich display names from roster/db/uia evidence |
| `isphere_search_groups` | decrypted XMPP group/message stanzas if groupchat/group JIDs appear | `MsgLib.db` group/conversation tables after DB wrapper is solved; UIA helper source if group display names are missing | `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md#field-mapping-evidence` | candidate pending group stanza evidence | third |
| `isphere_receive_files` | decrypted `PacketReader.ProcessPacket` file-transfer message stanzas plus `zyl\importal\<hash>` cache mapping | decrypted `Smark.SendReceive` and `SaveToDB` traces for file-reference reconciliation | `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md#field-mapping-evidence` | candidate pending cache-reference mapping | fourth |

View File

@@ -990,7 +990,7 @@ Implemented and verified in this loop:
- 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**
- [x] **Step 1: Write failing tool test**
Create `internal/tools/isphere_contacts_test.go` and run:
@@ -1000,15 +1000,15 @@ go test ./internal/tools -run TestISphereSearchContactsToolReturnsJIDContacts -v
Expected initial failure: contact tool registration does not exist.
- [ ] **Step 2: Implement contact tool registration**
- [x] **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**
- [x] **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**
- [x] **Step 4: Run full verification and commit**
Run:
@@ -1023,6 +1023,54 @@ Expected: all exit 0. Remove any generated root `isphere-mcp.exe` after build. C
---
## Loop C8 Result
Implemented and verified in this loop:
- `internal/tools.RegisterISphereContactTools(server, source)` registers `isphere_search_contacts` over the same receive-message source used by `isphere_receive_messages`.
- `internal/mcpserver.NewServerWithReceiveSource` now exposes six tools: four WinHelper tools, `isphere_receive_messages`, and `isphere_search_contacts`.
- `scripts/verify-go-mcp.ps1` now expects six tools, allows `search` as a legitimate read capability term, and verifies both default empty contact results and configured synthetic contact extraction.
- `isphere_search_contacts` currently returns JID-derived `local_readonly` contacts with minimal audit metadata; richer names remain deferred until roster/db/uia evidence is validated.
- Verification completed for C8 with affected package tests and `powershell -NoProfile -ExecutionPolicy Bypass -File scripts/verify-go-mcp.ps1`; full verification is run again before commit.
---
## Loop C9: Group source evidence precheck
**Goal:** Before implementing `isphere_search_groups`, verify whether the current decrypted log evidence contains group/groupchat identifiers that can support a real source decision instead of guessing.
**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 a small ignored metadata summary under `runs/` if needed; do not commit raw evidence.
**Planned behavior:**
- Inspect existing ignored N12-pre decrypted metadata or selected decrypted log samples under `runs/` for groupchat stanzas, room/group JIDs, or group display-name clues.
- If evidence exists, write a C10 implementation loop for group candidate extraction.
- If evidence does not exist, mark `isphere_search_groups` blocked on additional roster/group evidence and choose the next read slice (`isphere_receive_files` or contact enrichment) instead.
- [ ] **Step 1: Inspect current source evidence for group identifiers**
Use existing ignored metadata/log summaries under `runs/` and committed schema notes. Do not commit raw logs.
- [ ] **Step 2: Update matrix and next loop**
Record whether group extraction can proceed from current evidence. Rewrite C10 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 C9 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.