Improve docs

[ContextVM-org]

Restructure the docs to have a clearer structure. For example, use 'Reference' for specs and SDKs, 'How-to' for operator guides, 'Design' for architectural design rationale, and 'Tutorial' for hands-on guides.

[1amKhush]

@ContextVM-org Here's the restructure plan, lmk if i should make any changes.

Implementation Plan — Docs Restructure

New Structure

The current flat layout (Getting Started → Specification → TypeScript SDK → CVMI) will be reorganized into four audience-oriented top-level sections:

Section	Purpose	Content
Reference	Specs & SDK API docs	Specification, CEPs (promoted to top-level), TypeScript SDK, Rust SDK (new — 11 pages)
How-to	Operator & task guides	CVMI CLI (moved), Payments (moved from TS SDK)
Tutorials	Hands-on step-by-step	Client-Server Communication (moved, promoted to top-level)
Design	Architectural rationale	Rust SDK Design (adapted from rs-sdk/DESIGN.md)

Rust SDK Docs (New)

11 pages ported from rs-sdk/docs/ with Starlight frontmatter:

Overview · Native Server Guide · Native Client Guide · Gateway · Proxy · Discovery · Encryption · Transport Modes · Transports (Low-Level) · Stateless Mode · RMCP Integration

Key Decisions

• Payments → How-to: Payments docs are task-oriented ("how do I add payments?"), not API reference, so they move out of the TS SDK section
• CEPs promoted: CEPs move from 3-level nesting under Specification to a top-level group under Reference for better discoverability
• git mv for all moves: Preserves git history across the restructure

[ContextVM-org]

This sounds good, but I have some thoughts that might improve the organization of the docs. It makes sense to move the “how to implement payments” material out of the SDK documentation, yet we should retain the API reference and relevant information within each SDK section. The design section should cover the protocol, diagrams, design decisions, and related content, not merely SDK design documents. In fact, we could place a design subsection within each SDK’s documentation instead of maintaining a separate general design section. Aside from that, this looks great; the structure should be flexible enough to accommodate the evolving protocol and SDK implementations.