feat: expose read-only admin surface

docs/current_roadmap.md

@@ -106,6 +106,21 @@ implementation state.
       broker-owned.
    - Completed: read-only source inventory is exposed through JSON-RPC HTTP and
       `wf source list` / `wf source inspect`.
+   - Completed: read-only admin/config sibling surface covers connection
+      inventory, connection status, and broker/server events. Keep it separate
+      from `WorkflowApiSurface`; this is platform management, not workflow
+      lifecycle.
+   - Completed: read-only admin/config now has a neutral `WorkflowAdminApi` /
+      `WorkflowAdminSurface`, is exposed through JSON-RPC HTTP, and is available
+      through `wf admin connections`, `wf admin statuses`, and
+      `wf admin events`.
+   - Defer mutating source/connection config commands until the store-backed
+      source registry is designed. Config can bootstrap sources, but server-owned
+      dynamic source changes need persistence, validation, and auth rules before
+      they are safe.
+   - Longer term: make the MCP frontend an adapter over these neutral workflow,
+      source-admin, and config-admin surfaces so the old `wf_mcp` server entry
+      point can shrink or retire.
 
 5. **CLI/API alignment**
    - Completed for the basic lifecycle: selected `wf` commands can target local

docs/superpowers/specs/2026-06-03-cli-api-alignment-notes.md

@@ -83,6 +83,8 @@ surface, or plain local CLI utilities.
 1. **Store-backed source registry**
    - Read-only source/admin operations are now available through JSON-RPC HTTP
      and `wf source list` / `wf source inspect`.
+   - Read-only admin/config operations are now available through JSON-RPC HTTP
+     and `wf admin connections`, `wf admin statuses`, and `wf admin events`.
    - Next source work is persistence for server-owned dynamic source changes.
    - Keep mutation out until the store-backed source registry is designed.
 
@@ -101,8 +103,9 @@ surface, or plain local CLI utilities.
 
 ## Open Questions
 
-- Should source/admin operations live in `wf_api` as a sibling surface, or in a
-  new package that composes `wf_api` plus server management services?
+- Source/admin and admin/config read-only operations currently live in `wf_api`
+  as sibling surfaces. If mutation grows into a larger management domain, split
+  that later instead of overloading `WorkflowApiSurface`.
 - Should `wf schema` describe local CLI command payloads only, or query a remote
   server for supported method schemas?
 - Should `wf docs` read packaged local docs, remote server docs, or both?