docs: clarify server store roles

docs/current_roadmap.md

@@ -245,6 +245,13 @@ implementation state.
     Not done: auth is still compatibility-grade. There is no OAuth flow,
     production secret manager, provider-specific display model, or
     full removal of the legacy MCP auth record shape yet.
+  - Role-specific server stores: the current neutral config has one
+    `server.store` root that backs workflow records, desired source registry,
+    catalog/cache snapshots, and local/dev auth records. The next config slice
+    should add optional `server.stores.*` overrides while preserving
+    `server.store` as the fallback for every missing role. First implementation
+    should stay filesystem-only; secret managers, SQL, and object stores are
+    later backend implementations.
   - Completed: `wf run watch` starts run progress UX with polling over existing
     `inspect_run` and optional bounded `read_run_trace`. SSE/WebSocket/MCP
     progress remains deferred until polling UX proves insufficient.

docs/superpowers/specs/2026-06-03-long-lived-workflow-api-boundary.md

@@ -202,6 +202,25 @@ WorkflowApi
 The context must pass `require_workflow_stores()` before being exposed through
 the long-lived API.
 
+Current config exposes one default `server.store` root. The server then fans it
+out into workflow stores, auth records, source registry state, and catalog/cache
+state. That is acceptable for the first durable server path, but the boundary
+should not assume every persistence role always shares one backend.
+
+Future config should support optional role-specific store overrides:
+
+```text
+server.store              default for every missing role
+server.stores.workflow    artifacts, deployments, drafts, runs, traces
+server.stores.auth        auth records or secret-manager references
+server.stores.sources     desired source registry entries
+server.stores.catalog     source catalog/cache snapshots
+```
+
+The compatibility rule is: if a role store is absent, use `server.store`. First
+implementation should keep overrides filesystem-only; SQL, object storage, and
+secret-manager adapters are later backend implementations.
+
 The first server runtime may reuse existing implementation classes when they do
 not require MCP-specific behavior. If reuse would require constructing
 `WfMcpService`, that is the wrong dependency direction.

docs/superpowers/specs/2026-06-03-workflow-config-targets-and-sources.md

@@ -173,7 +173,7 @@ sources.
 
 `server.store` answers: where does the server persist workflow platform state?
 
-The current implementation can start with a filesystem store:
+The current implementation uses one default filesystem store root:
 
 ```json
 {
@@ -186,6 +186,13 @@ The current implementation can start with a filesystem store:
 }
 ```
 
+That single root fans out internally into role-specific files/directories:
+
+- workflow records: artifacts, deployments, draft workspaces, runs, and traces
+- source registry desired state
+- source catalog/cache snapshots
+- auth records for local/dev MCP-compatible credentials
+
 Recommended Pydantic shape for the first slice:
 
 ```python
@@ -211,7 +218,52 @@ the config does not bake the store concept into a single `store_root` field.
 Relative filesystem paths should resolve relative to the config file directory.
 SQL-backed stores are future work.
 
-The store should eventually own mutable workflow platform registries:
+### Store Roles
+
+`server.store` is the default store for every role. Future configs should allow
+optional role-specific overrides without breaking existing files:
+
+```json
+{
+  "server": {
+    "store": {
+      "kind": "filesystem",
+      "root": ".wf_store"
+    },
+    "stores": {
+      "workflow": {
+        "kind": "filesystem",
+        "root": ".wf_store"
+      },
+      "auth": {
+        "kind": "filesystem",
+        "root": ".wf_auth"
+      },
+      "source_registry": {
+        "kind": "filesystem",
+        "root": ".wf_sources"
+      },
+      "catalog_cache": {
+        "kind": "filesystem",
+        "root": ".wf_catalog"
+      }
+    }
+  }
+}
+```
+
+Resolution rule:
+
+```text
+effective_store(role) = server.stores[role] if present else server.store
+```
+
+The first implementation should keep all role overrides optional and filesystem
+only. This preserves the current single-root config while making the boundary
+ready for secret-manager auth stores, database-backed workflow records, and
+separate catalog/cache storage.
+
+The store layer should own mutable workflow platform registries:
 
 - artifact records
 - deployment records

docs/wf_cli.md

@@ -53,6 +53,12 @@ The old `store_root` field maps to
 `server.store: {"kind": "filesystem", "root": ...}`; old `connections[]` map to
 `server.sources[]` entries with `kind: "mcp"`.
 
+`server.store` is currently the default root for all file-backed server state:
+workflow artifacts/deployments/runs, source registry entries, catalog cache, and
+local/dev auth records. Future configs may add role-specific store overrides
+such as `server.stores.auth` or `server.stores.source_registry`; missing roles
+should continue to fall back to `server.store`.
+
 Start a JSON-RPC server backed by MCP broker config and MCP-capable sources:
 
 ```bash