admin/isphere-ai-bridge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: verify five-tool mcp surface

Browse Source
This commit is contained in:
zhaoyilun
2026-07-09 23:16:02 +08:00
parent 57eb7a5fc7
commit 220f3f68c1
4 changed files with 147 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/current-status-card.md
View File

@@ -14,21 +14,22 @@ 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 only four read-only helper tools:
- The current MCP surface exposes five read-oriented tools:
- `win_helper_version`
- `win_helper_self_check`
- `win_helper_scan_windows`
- `win_helper_dump_uia`
- `isphere_receive_messages`
- 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 and first-phase Go MCP server.
- `scripts/verify-win-helper.ps1` and `scripts/verify-go-mcp.ps1` provide repeatable local checks for the helper, five-tool MCP surface, and empty-source `isphere_receive_messages` smoke call.
- 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 receiving, message sending, file receiving, or file sending.
- The project has not yet implemented business MCP tools for contact search, group search, message sending, file receiving, or file sending; `isphere_receive_messages` is registered but still lacks a production loader/configuration path.
- The project has not completed production iSphere integration.
- The project has not proven a stable real message source for the full business workflow.
- 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.
- N12-pre offline evidence is not N12 pass.
- N13/N14/N15 selector/report work is pre-business evidence, not finished contact/message/file capability.
@@ -38,8 +39,8 @@ Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-repor
- The repository has a Go MCP + C# WinHelper foundation for controlled Windows-side read-only observation.
- 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 first-phase helper/MCP foundation.
- The project now has a corrected business contract and plan for core MCP communication tools.
- 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 for receiving messages from a future configured source.
## N13/N14/N15 positioning
@@ -47,7 +48,7 @@ N13/N14/N15 are pre-business validation results. They can help identify UI eleme
## Current loop
Current loop: `Stage C / Loop C1 - log decryptor and PacketReader parser`.
Current loop: `Stage C / Loop C4 - operator verification and docs`.
Plan file: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`.
@@ -58,18 +59,17 @@ Loop rule:
3. Verify, commit exact paths, then update the next loop based on actual results.
4. Continue automatically while the next step is clear; ask the user only when blocked or when business direction changes.
Current loop output:
Current loop output so far:
1. `internal/isphere/logcodec.DecryptLine` for DES/CBC/PKCS7 Base64 log lines.
2. `internal/isphere/packetlog.ParseMessageLog` for redacted `PacketReader.ProcessPacket` XMPP `<message>` stanzas.
3. Passing unit tests with synthetic/redacted fixtures only.
4. Updated Loop C2 plan before source abstraction starts.
1. C1: `internal/isphere/logcodec.DecryptLine` and `internal/isphere/packetlog.ParseMessageLog` for redacted PacketReader message logs.
2. C2: `internal/isphere.EncryptedPacketLogSource.ReceiveMessages` source abstraction with synthetic/redacted encrypted fixtures.
3. C3: `isphere_receive_messages` MCP tool registration and server tool list update.
4. C4: updating repeatable operator verification and docs for the five-tool surface.
## Next business mainline
1. Complete Stage C Loop C1: log decryptor + PacketReader parser.
2. Rewrite and execute Loop C2: log-backed `ReceiveMessages` source abstraction.
3. Register `isphere_receive_messages` only after parser/source tests pass.
4. Add contact/group/file read tools after their source decisions are recorded.
5. Add `isphere_send_message` and `isphere_send_file` after source discovery and connector selection.
6. Keep UIA selector/report work as fallback support, not as the primary roadmap.
1. Finish Stage C Loop C4: verify and document the five-tool MCP surface.
2. Implement the next loop: safe configurable source loader or fixture path for `isphere_receive_messages`, without committing raw evidence.
3. Add contact/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.