docs: trim safety constraints from mcp roadmap

docs/mcp-core-business-plan.md

@@ -36,7 +36,7 @@ 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.
-- Do not continue investing in selector report hardening unless a concrete business tool is blocked by selector quality.
+- 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
@@ -52,14 +52,13 @@ Deliverables:
   - `isphere_send_message`
   - `isphere_receive_files`
   - `isphere_send_file`
-- Write-capable tools require `approval_id` for real execution.
-- Write-capable tools support `dry_run=true` and default to dry-run until approved.
-- Read-only tools do not mutate the iSphere client state.
+- 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-only/write status, approval behavior, and implementation priority are explicit.
-- No new selector/report node is introduced as the next primary step.
+- 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
 
@@ -77,7 +76,6 @@ 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.
-- No automatic login, hook, injection, memory read, or endpoint-security bypass is introduced.
 
 ## Stage C: Read-only loop
 
@@ -94,39 +92,37 @@ Acceptance:
 
 - Each tool can return normalized JSON through MCP.
 - Each tool records audit metadata.
-- File receiving/download writes only to an approved local output directory and never mutates source client state.
-- Tests and verification do not send messages, upload files, click destructive controls, or alter production data.
+- 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: Approval-after-read-only write capability
+## Stage D: Write capability
 
 Goal: add write behavior only after the read-only loop is proven.
 
 Implementation order:
 
-1. `isphere_send_message` with `dry_run=true` preview first.
-2. Approval store and audit validation.
-3. `isphere_send_message` real send only with valid `approval_id`.
-4. `isphere_send_file` with `dry_run=true` preview first.
-5. `isphere_send_file` real send only with valid `approval_id`.
+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:
 
-- No valid `approval_id`, no real send.
-- Every real send records target, content/file hash, approver, time, connector, and result.
+- Every write records target, content/file hash, operator, time, connector, and result.
 - Idempotency prevents accidental duplicate sends.
-- Operator can review dry-run output before approval.
+- Preview output is available before production execution.
 
-## Stage E: Pre-production safety, audit, and deployment acceptance
+## Stage E: Pre-production audit and deployment acceptance
 
-Goal: make the MCP service safe and operable before broader use.
+Goal: make the MCP service operable before broader use.
 
 Checks:
 
-- Tool allowlist and source allowlist are explicit.
+- Tool registry and source registry are explicit.
 - Audit records are durable and redacted where needed.
-- Approval records are traceable.
+- Execution records are traceable.
 - Deployment docs include exact commands, rollback, logs, and known limits.
-- Security boundaries are still enforced: no automatic login, no bypass, no injection, no hook, no target-process memory read.
 
 Acceptance:
 
@@ -142,4 +138,4 @@ Current next step is:
 MCP core tools contract freeze + read-only message source discovery + N12-pre evidence package organization.
 ```
 
-Do not start N16/N17 selector/report hardening as the mainline. If UIA is needed later, use the existing N13/N14/N15 results as auxiliary evidence only.
+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.