142 lines
4.9 KiB
Markdown
142 lines
4.9 KiB
Markdown
# MCP Core Business Plan
|
||
|
||
Date: 2026-07-09
|
||
|
||
## Business correction
|
||
|
||
项目核心不是继续做 UIA selector/report，而是通过 MCP 暴露 iSphere 的联系人、群组、消息、文件能力。
|
||
|
||
后续研发主线切换为 MCP 核心通信能力：搜索联系人、搜索群组、收发消息、收发文件。现有 UIA/selector/report 只作为底层辅助和证据，不再作为主线继续扩展。
|
||
|
||
## Core business capabilities
|
||
|
||
The product roadmap is limited to six business capabilities:
|
||
|
||
1. Search contacts.
|
||
2. Search groups.
|
||
3. Receive/read messages.
|
||
4. Send messages.
|
||
5. Receive/download files.
|
||
6. Send files.
|
||
|
||
Everything else is infrastructure or fallback support. Selector catalog/report validation may support UI automation if needed, but it is not the main product deliverable.
|
||
|
||
## Capability source priority
|
||
|
||
Use this priority order when searching for real implementations:
|
||
|
||
1. Existing bridge / API / local service.
|
||
2. Local database / log / cache read-only access.
|
||
3. UI automation.
|
||
4. Network/API analysis.
|
||
5. Reverse engineering, only for explanation and validation, not as the default route.
|
||
|
||
Implications:
|
||
|
||
- Prefer an existing bridge/API/local service before reading local storage or using UIA.
|
||
- Prefer read-only database/log/cache access before UI automation when it can answer the business question.
|
||
- UIA selector work is a fallback access mechanic, not the primary roadmap.
|
||
- Invest in selector/report work only when it directly unblocks a concrete core MCP tool.
|
||
- Reverse engineering is last resort and should explain formats or validate assumptions; it should not become the default delivery path.
|
||
|
||
## Stage A: Freeze MCP core tools contract
|
||
|
||
Goal: lock the business-facing MCP tool surface before adding more helper or selector work.
|
||
|
||
Deliverables:
|
||
|
||
- `docs/mcp-core-tools-contract.md` exists and defines:
|
||
- `isphere_search_contacts`
|
||
- `isphere_search_groups`
|
||
- `isphere_receive_messages`
|
||
- `isphere_send_message`
|
||
- `isphere_receive_files`
|
||
- `isphere_send_file`
|
||
- Write-capable tools expose preview and execution metadata.
|
||
- Read tools come before write tools so the capability source is proven first.
|
||
|
||
Acceptance:
|
||
|
||
- Contract names, input parameters, output JSON, error codes, audit fields, read/write status, and implementation priority are explicit.
|
||
- Selector/report work is not the next primary step.
|
||
|
||
## Stage B: Find real capability sources
|
||
|
||
Goal: identify the best source for each read-only capability.
|
||
|
||
Tasks:
|
||
|
||
1. Inventory existing bridge/API/local service artifacts and current Go/C# boundaries.
|
||
2. Re-check whether existing bridge endpoints or local services can provide contacts, groups, messages, or files.
|
||
3. Re-check local database/log/cache artifacts only in read-only mode.
|
||
4. Use UIA only if higher-priority sources cannot satisfy the read-only tool.
|
||
5. Document source decisions per tool before implementation.
|
||
|
||
Acceptance:
|
||
|
||
- Each read-only tool has a selected primary source and a fallback source.
|
||
- The decision is evidence-backed and does not rely on stale prior notes without current verification.
|
||
|
||
## Stage C: Read-only loop
|
||
|
||
Goal: deliver useful MCP read capability before any real write capability.
|
||
|
||
Implementation order:
|
||
|
||
1. `isphere_search_contacts`
|
||
2. `isphere_search_groups`
|
||
3. `isphere_receive_messages`
|
||
4. `isphere_receive_files`
|
||
|
||
Acceptance:
|
||
|
||
- Each tool can return normalized JSON through MCP.
|
||
- Each tool records audit metadata.
|
||
- File receiving/download writes to a configured local output directory.
|
||
- Tests and verification cover connector behavior without expanding into selector/report-only work.
|
||
|
||
## Stage D: Write capability
|
||
|
||
Goal: add write behavior only after the read-only loop is proven.
|
||
|
||
Implementation order:
|
||
|
||
1. `isphere_send_message` preview first.
|
||
2. Audit and execution metadata.
|
||
3. `isphere_send_message` production write mode.
|
||
4. `isphere_send_file` preview first.
|
||
5. `isphere_send_file` production write mode.
|
||
|
||
Acceptance:
|
||
|
||
- Every write records target, content/file hash, operator, time, connector, and result.
|
||
- Idempotency prevents accidental duplicate sends.
|
||
- Preview output is available before production execution.
|
||
|
||
## Stage E: Pre-production audit and deployment acceptance
|
||
|
||
Goal: make the MCP service operable before broader use.
|
||
|
||
Checks:
|
||
|
||
- Tool registry and source registry are explicit.
|
||
- Audit records are durable and redacted where needed.
|
||
- Execution records are traceable.
|
||
- Deployment docs include exact commands, rollback, logs, and known limits.
|
||
|
||
Acceptance:
|
||
|
||
- Full test suite passes.
|
||
- Operator runbook covers normal operation and failure modes.
|
||
- A business user can understand which of the six capabilities are supported and which remain staged.
|
||
|
||
## Immediate next action
|
||
|
||
Current next step is:
|
||
|
||
```text
|
||
MCP core tools contract freeze + read-only message source discovery + N12-pre evidence package organization.
|
||
```
|
||
|
||
N16/N17 selector/report hardening is not the mainline. If UIA is needed later, use the existing N13/N14/N15 results as auxiliary evidence only.
|