docs: align architecture and agent rules with unified bridge routing

AGENTS.md

@@ -148,7 +148,7 @@ A refactor task is complete only when:
 - Assistant conversation runtime must treat signed-out state as disconnected: do not send requests, do not read stale managed bridge secrets, and do not fallback to local ACP endpoints or default managed bridge endpoints.
 - Missing managed `BRIDGE_AUTH_TOKEN` means disconnected. Do not fallback from bridge ACP auth to gateway profile tokens.
 - Keep the UI unchanged for bridge state-flow fixes unless explicitly requested; adjust runtime readiness, endpoint resolution, and tests instead.
-- After svc.plus login and bridge sync, route provider execution through the public bridge endpoints: Hermes/Codex/Gemini/OpenCode use `/acp-server/{provider}/acp/rpc`, and OpenClaw uses `/gateway/openclaw/acp/rpc`.
+- After svc.plus login and bridge sync, route all provider and gateway execution through the unified managed bridge endpoint `/acp/rpc`. Do not use provider-specific paths or directly construct `/acp-server/*` or `/gateway/*` URLs.
 - For a user-initiated gateway connect action, the current form values may be used directly for the immediate handshake. Do not require a secure-store readback for the active request.
 - Keep network trust boundaries explicit. Loopback/local mode may use non-TLS intentionally; remote mode must not silently downgrade transport security.
 - File and attachment access must be user-driven. Never read or send workspace files implicitly.

docs/architecture/account-sync-settings-bridge-state-model.md

@@ -72,12 +72,6 @@ stateDiagram-v2
     state BridgeReady {
         [*] --> Connected: Catalog populated
         Connected: 允许发送对话
-        Connected --> ProviderRouting: User message
-    }
-
-    state ProviderRouting {
-        Gateway: /gateway/openclaw/acp/rpc
-        Agent: /acp-server/{id}/acp/rpc
     }
 
     BridgeReady --> SignedOut: Logout
@@ -119,7 +113,7 @@ flowchart TD
 - `BRIDGE_SERVER_URL` may be retained in `AccountSyncState.syncedDefaults.bridgeServerUrl`, but it is metadata only.
 - `BRIDGE_AUTH_TOKEN` is written to secure storage only, never to normal settings.
 - Bridge runtime requests use `Authorization: Bearer <token>` from secure storage.
-- Capabilities and routing discovery use the bridge root `/acp/rpc`; assistant execution uses provider-specific public endpoints.
+- Capabilities, routing discovery, and assistant execution all use the bridge root `/acp/rpc`.
 
 ## Persistence Rules
 

docs/architecture/bridge-runtime-routing-map.md

@@ -37,11 +37,12 @@ flowchart TD
 
 - App runtime requests use `https://xworkmate-bridge.svc.plus/acp/rpc`.
 - Provider and gateway selection are passed as request params, including `provider`, `routing`, and `requestedExecutionTarget`.
-- Bridge-owned mapping:
-  - `Hermes` -> `https://xworkmate-bridge.svc.plus/acp-server/hermes`
-  - `Codex` -> `https://xworkmate-bridge.svc.plus/acp-server/codex`
-  - `OpenCode` -> `https://xworkmate-bridge.svc.plus/acp-server/opencode`
-  - `Gemini` -> `https://xworkmate-bridge.svc.plus/acp-server/gemini`
-  - `OpenClaw` -> `https://xworkmate-bridge.svc.plus/gateway/openclaw`
+- Bridge-owned internal routing (Backend internal only):
+  - `Hermes` -> `/acp-server/hermes`
+  - `Codex` -> `/acp-server/codex`
+  - `OpenCode` -> `/acp-server/opencode`
+  - `Gemini` -> `/acp-server/gemini`
+  - `OpenClaw` -> `/gateway/openclaw`
 - The app must not route managed bridge tasks to local or LAN endpoints such as `127.0.0.1:*` or `192.168.*:*`.
-- The app must not route managed bridge tasks by directly constructing `/acp-server/*` or `/gateway/openclaw` URLs.
+- The app must not route managed bridge tasks by directly constructing `/acp-server/*` or `/gateway/*` URLs.
+- All App-side requests go through `https://xworkmate-bridge.svc.plus/acp/rpc`.