The [API reference](/docs/api) tells you what each endpoint takes and returns.
These pages are the other half: what a whole feature looks like when it is
built on top of them.

| Guide | What it works through |
|---|---|
| **[Domain modelling with the SDK](/docs/guides/architecture)** | One feature end to end — Zod schema, use-case, oRPC procedure, TanStack Query hook, component |
| **[Caching with the KV store](/docs/guides/caching)** | Cache-aside, rate limits, feature flags and idempotency, with the TTL semantics that make them safe |
| **[Analytics](/docs/guides/analytics)** | What to emit, what Connect already counts for you, and reading it back |

## The pattern every guide follows

Read [Domain modelling](/docs/guides/architecture) first. Every other guide,
and every worked example in the API reference, is written against the layering
it establishes:

```
schema (Zod)  →  use-case  →  procedure (oRPC)  →  hook (TanStack Query)  →  component
                    ↓
              Connect SDK
```

One direction, all the way down. A use-case may call Connect; a component
never does. Three rules hold it together, and they are worth stating once here
because every example assumes them:

**Connect calls happen on the server.** `@cosmoops/connect-sdk/server` holds
your API key and is fenced off from browser bundles by an export condition —
importing it from a client component fails the build rather than shipping the
key.

**The workspace comes from the session, never from an input.** A `workspaceId`
a caller can supply is a cross-tenant write one forgotten check away. Reading
it from the session is also what makes a workspace switch work without
touching your handlers.

**Entitlement is checked in the use-case, not the component.** A gate in the UI
is the explanation; the check in the use-case is the enforcement. Ship both —
the first without the second is a hidden button in front of an open endpoint.