docs: consolidate design documentation and standardize crate English

crates/client/README.md

@@ -1,30 +1,10 @@
 # client
 
-## Role
+Shared client for Backend Workspace/Runtime APIs and the Worker protocol. Provides authenticated communication and typed connection targets for CLI/TUI. The standalone crate owns Standalone execution, Runtime and the controller own Worker state and input admission, and higher-level crates own presentation and product commands.
 
-`client` contains reusable socket-client and runtime-command mechanics for talking to Workers from CLI/TUI code.
+## Implementation entry points
 
-## Boundaries
-
-Owns:
-
-- one-shot Worker socket client behavior
-- request/reply delivery mechanics
-- runtime command construction below the product façade
-- shared attach/status probing helpers used by higher layers
-
-Does not own:
-
-- product command names (`yoi`)
-- Worker state authority (`worker`, `session-store` worker metadata)
-- UI rendering (`tui`)
-- Engine turn semantics (`agen`)
-
-## Design notes
-
-The client boundary lets `tui` and `yoi` share Worker communication without making library crates depend on the product binary. Socket clients should drain connect-time snapshot/alert traffic before sending a method or deciding status.
-
-## See also
-
-- [`../../docs/design/worker-session-state.md`](../../docs/design/worker-session-state.md)
-- [`../../docs/design/overview.md`](../../docs/design/overview.md)
+- [`BackendApiClient`] — Authenticated HTTP/WS requests bound to an origin
+- [`backend_runtime`] / [`backend_workspace`] — Backend resource retrieval and operations
+- [`Client`] / [`transport`] — Method/Event encoding and message transport
+- [`target`] — Distinct Backend and Standalone targets and operation intents