docs: refresh project status and roadmap

README.md

@@ -216,10 +216,20 @@ SLOP v0.1 is designed to be useful now while leaving room to grow. Key limitatio
 - **Multi-user apps** — Server-side providers currently expose one shared tree to all consumers. The protocol already supports per-user state (each connection is independent), but the SDKs don't implement session-scoped tree rendering yet. Client-only SPAs are unaffected — each tab is its own provider. See [Sessions & Multi-User](./docs/sdk/sessions.md).
 - **No reconnection** — If a WebSocket drops, the consumer must re-connect and re-subscribe from scratch. No automatic reconnect or version-based catch-up.
 - **No backpressure** — `pause`/`resume` messages are mentioned in the spec but not defined. Providers should debounce rapid changes (50-100ms).
-- **No network discovery** — mDNS/DNS-SD is reserved but unspecified. Remote providers require manual configuration.
+- **No LAN discovery** — Local discovery is shipped (`~/.slop/providers/`, `/tmp/slop/providers/`, browser meta tags, and `/.well-known/slop`), but mDNS/DNS-SD for remote providers is still reserved and unspecified.
 
 Full list: [Known Limitations & Future Work](https://docs.slopai.dev/spec/limitations/)
 
+## Current status
+
+As of `v0.1`, SLOP already includes:
+
+- Core protocol docs plus scaling, content-reference, and async-action extensions
+- TypeScript SDKs, framework adapters, and the discovery layer
+- Python, Go, and Rust SDKs
+- Chrome extension and desktop app
+- Examples, benchmarks, and OpenClaw integration
+
 ## Roadmap
 
 **Protocol**
@@ -237,7 +247,6 @@ Full list: [Known Limitations & Future Work](https://docs.slopai.dev/spec/limita
 **Product**
 - Firefox extension
 - Safari extension
-- OpenClaw integration
 - Agent CLI (`npx @slop-ai/init`)
 - Extension per-site toggles
 

docs/sdk/discovery.md

@@ -40,7 +40,7 @@ Integrations that only need discovery + MCP (e.g. `slop-bridge` with the MCP SDK
 
 ## Phase 1: Core Discovery Layer
 
-The current cross-SDK parity target is the **core discovery layer**. The TypeScript implementation is the behavioral reference, but other SDKs do **not** need to copy its package topology.
+As of `v0.1`, the **core discovery layer** is shipped across TypeScript, Python, Go, and Rust. The TypeScript implementation remains the behavioral reference, but other SDKs do **not** need to copy its package topology.
 
 - TypeScript reference files: `packages/typescript/integrations/discovery/src/discovery.ts`, `bridge-client.ts`, `bridge-server.ts`, `relay-transport.ts`, and `tools.ts`
 - Python target module: `slop_ai.discovery`

packages/go/slop-ai/README.md

@@ -53,7 +53,7 @@ That mounts:
 
 ## Discovery layer
 
-The Go SDK now includes the core discovery layer in the `discovery` subpackage:
+The Go SDK includes the core discovery layer in the `discovery` subpackage:
 
 ```go
 import (

packages/python/slop-ai/README.md

@@ -49,7 +49,7 @@ app.add_middleware(SlopMiddleware, slop=slop)
 
 ## Discovery layer
 
-The Python SDK now includes the core discovery layer in `slop_ai.discovery`:
+The Python SDK includes the core discovery layer in `slop_ai.discovery`:
 
 ```python
 import asyncio

packages/rust/slop-ai/README.md

@@ -54,7 +54,7 @@ slop.register("todos", json!({
 
 ## Discovery layer
 
-The Rust SDK now includes the core discovery layer in `slop_ai::discovery` under the default `native` feature set:
+The Rust SDK includes the core discovery layer in `slop_ai::discovery` under the default `native` feature set:
 
 ```rust
 use slop_ai::discovery::{DiscoveryService, DiscoveryServiceOptions};

packages/typescript/integrations/claude/slop-native/README.md

@@ -139,7 +139,7 @@ Browser SPAs ──postMessage──Extension─────────┤
 
 All dynamic affordance tools remain registered for the lifetime of the connection. Apps with many distinct action+schema combinations can consume significant context tokens (~128 tokens per tool) even when Claude isn't actively interacting with the app.
 
-**Planned improvement: idle tool deregistration.** Track the last tool call per provider. After a configurable idle timeout (e.g. 60 seconds with no tool calls), deregister that provider's tools via `tools/list_changed` to free context. The connection and state subscription stay alive — the hook still injects the state tree each turn so Claude retains awareness of the app. When Claude needs to act again, a single `connect_app("appname")` call re-registers the tools instantly from the cached state (no reconnection needed).
+One possible follow-up is idle tool deregistration. Track the last tool call per provider. After a configurable idle timeout (e.g. 60 seconds with no tool calls), deregister that provider's tools via `tools/list_changed` to free context. The connection and state subscription stay alive — the hook still injects the state tree each turn so Claude retains awareness of the app. When Claude needs to act again, a single `connect_app("appname")` call re-registers the tools instantly from the cached state (no reconnection needed).
 
 This gives the best of both worlds: direct tool calls with zero overhead during active use, freed context when idle.
 

spec/integrations/desktop.md

@@ -336,8 +336,8 @@ The desktop app aggregates providers from all discovery sources into a single li
 
 Each discovered provider appears in the desktop's sidebar under the appropriate group (Pinned, Local Apps, or Browser Tabs — see Sidebar groups above). The desktop connects using the appropriate transport — Unix socket, direct WebSocket, or bridge relay — transparently.
 
-## Roadmap: SLOP-enabled desktop app
+## Future work: desktop app as a SLOP provider
 
-The desktop app itself can become a SLOP provider. Its own state — the workspace list, connected providers, chat history, settings — is observable via the same protocol it consumes. Another SLOP client (a CLI agent, a second desktop instance, a web dashboard) could connect to the desktop app and read or manipulate its state.
+The desktop app already ships as a multi-provider SLOP consumer workspace. A future step is for the desktop app itself to become a SLOP provider. Its own state — the workspace list, connected providers, chat history, settings — would be observable via the same protocol it consumes. Another SLOP client (a CLI agent, a second desktop instance, a web dashboard) could then connect to the desktop app and read or manipulate its state.
 
 This turns the desktop from a leaf consumer into a node in the SLOP graph — consuming providers below it and exposing its own state to consumers above it.

spec/limitations.md

@@ -26,11 +26,11 @@ The spec mentions `pause` / `resume` messages for subscriptions but doesn't defi
 
 **Path forward:** Define `pause` and `resume` message types in a future protocol version. Low priority — debouncing covers most real-world scenarios.
 
-### No network discovery
+### No LAN discovery
 
 Remote provider discovery via mDNS/DNS-SD (service type `_slop._tcp`) is reserved but not specified.
 
-**Current behavior:** Local discovery works via `~/.slop/providers/` files and web discovery via `<meta>` tags and `/.well-known/slop`. Remote providers must be configured manually (hardcoded URLs).
+**Current behavior:** Local discovery works via `~/.slop/providers/` files and web discovery via `<meta>` tags and `/.well-known/slop`. Remote providers must still be configured manually (hardcoded URLs).
 
 **Impact:** AI agents can't automatically discover SLOP providers on the local network. Only matters for multi-machine setups.
 

website/docs/src/content/docs/sdk/discovery.md

@@ -42,7 +42,7 @@ Integrations that only need discovery + MCP (e.g. `slop-bridge` with the MCP SDK
 
 ## Phase 1: Core Discovery Layer
 
-The current cross-SDK parity target is the **core discovery layer**. The TypeScript implementation is the behavioral reference, but other SDKs do **not** need to copy its package topology.
+As of `v0.1`, the **core discovery layer** is shipped across TypeScript, Python, Go, and Rust. The TypeScript implementation remains the behavioral reference, but other SDKs do **not** need to copy its package topology.
 
 - TypeScript reference files: `packages/typescript/integrations/discovery/src/discovery.ts`, `bridge-client.ts`, `bridge-server.ts`, `relay-transport.ts`, and `tools.ts`
 - Python target module: `slop_ai.discovery`

website/docs/src/content/docs/spec/integrations/desktop.md

@@ -337,8 +337,8 @@ The desktop app aggregates providers from all discovery sources into a single li
 
 Each discovered provider appears in the desktop's sidebar under the appropriate group (Pinned, Local Apps, or Browser Tabs — see Sidebar groups above). The desktop connects using the appropriate transport — Unix socket, direct WebSocket, or bridge relay — transparently.
 
-## Roadmap: SLOP-enabled desktop app
+## Future work: desktop app as a SLOP provider
 
-The desktop app itself can become a SLOP provider. Its own state — the workspace list, connected providers, chat history, settings — is observable via the same protocol it consumes. Another SLOP client (a CLI agent, a second desktop instance, a web dashboard) could connect to the desktop app and read or manipulate its state.
+The desktop app already ships as a multi-provider SLOP consumer workspace. A future step is for the desktop app itself to become a SLOP provider. Its own state — the workspace list, connected providers, chat history, settings — would be observable via the same protocol it consumes. Another SLOP client (a CLI agent, a second desktop instance, a web dashboard) could then connect to the desktop app and read or manipulate its state.
 
 This turns the desktop from a leaf consumer into a node in the SLOP graph — consuming providers below it and exposing its own state to consumers above it.

website/docs/src/content/docs/spec/limitations.md

@@ -27,11 +27,11 @@ The spec mentions `pause` / `resume` messages for subscriptions but doesn't defi
 
 **Path forward:** Define `pause` and `resume` message types in a future protocol version. Low priority — debouncing covers most real-world scenarios.
 
-### No network discovery
+### No LAN discovery
 
 Remote provider discovery via mDNS/DNS-SD (service type `_slop._tcp`) is reserved but not specified.
 
-**Current behavior:** Local discovery works via `~/.slop/providers/` files and web discovery via `<meta>` tags and `/.well-known/slop`. Remote providers must be configured manually (hardcoded URLs).
+**Current behavior:** Local discovery works via `~/.slop/providers/` files and web discovery via `<meta>` tags and `/.well-known/slop`. Remote providers must still be configured manually (hardcoded URLs).
 
 **Impact:** AI agents can't automatically discover SLOP providers on the local network. Only matters for multi-machine setups.