I've been implementing a local-first persistent memory server (backed by a local document vault) and I'm working through what the 2026-07-28 stateless core means for servers whose whole purpose is durable state.

The stateless rework makes sense for the horizontally-scaled HTTP case. But for a server like mine the state isn't session-scoped transport state — it's the product. The vault persists across sessions, clients, and restarts by design.

My current read is that "stateless" refers to the protocol/transport layer (no server-side session affinity required), and that durable application state living behind a tool boundary is orthogonal to that. The server stays stateless at the protocol level even though the data it exposes is persistent. Is that the intended interpretation?

If so, two follow-ups:

1. Is there any guidance (or a planned extension) for servers to advertise that their backing store is durable vs. ephemeral, so clients/agents can reason about caching and re-fetching?
2. For local-first deployments specifically — is the expectation that these stay on stdio/local transport, or is there an intended story for them under the stateless HTTP model?

Happy to write this up as a concrete scenario for the conformance suite if it's useful — I have a working implementation I can point at.