docs: clarify auth and mcp ui limits

docs/current_roadmap.md

@@ -238,6 +238,9 @@ implementation state.
     available through MCP-backed server admin, JSON-RPC, and CLI. Summaries show
     ids, schemes, metadata, and payload keys only; secret payload values remain
     hidden.
+    Not done: auth is still compatibility-grade. There is no auth mutation UI/CLI,
+    OAuth flow, production secret manager, provider-specific display model, or
+    full removal of the legacy MCP auth record shape yet.
   - 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.
@@ -251,6 +254,11 @@ implementation state.
     as workflow capabilities. The current `wf_mcp` package still contains both
     roles plus compatibility entrypoints; new server/transport work should avoid
     depending on that combined facade.
+    MCP UI/App metadata is source metadata only for now. Do not advertise widget
+    or MCP Apps support through workflow transports until a dedicated MCP
+    frontend transport owns iframe hosting, `ui://` resources, app-only tool
+    calls, and bridge semantics. Raw proxy/debug paths may expose upstream MCP
+    behavior explicitly, but that is not the durable workflow surface.
 - Cleanup candidate: consolidate store/source registry id validation patterns
       (`SOURCE_REGISTRY_ID_PATTERN`, `STORE_ID_PATTERN`) only after another package
       needs the same rule. Today they intentionally stay close to their stores.

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

@@ -80,6 +80,29 @@ legacy/source-specific input to normalize, not a permanent peer config family.
 can construct the same application boundary with required stores and an explicit
 runtime/source implementation.
 
+## MCP UI/App Support Policy
+
+MCP UI metadata is not workflow-server capability by itself. Upstream MCP tools
+may expose `_meta.ui` / `ui://...` resources, but rendering those resources is a
+host/frontend responsibility, not a workflow runtime responsibility.
+
+Until a dedicated MCP frontend transport owns the full host behavior, do not
+advertise MCP Apps/UI support to clients. Supporting it requires more than
+passing metadata through:
+
+- serving `ui://` resources and any dependent assets from a stable origin
+- sandboxed iframe hosting
+- a JSON-RPC `postMessage` / app bridge
+- app-only tool visibility and calls
+- CSP/domain policy
+- widget state and teardown semantics
+
+`wf_sources_mcp` / current upstream MCP source code may preserve UI metadata as
+observed source metadata, but it must not imply that `wf_server` can render or
+host widgets. `wf_transport_mcp` may later implement a real host bridge. Raw
+MCP proxy/debug modes can expose upstream behavior explicitly, but that path is
+not the durable workflow surface.
+
 ## Why Not Wrap WfMcpService
 
 `WfMcpService` is still a compatibility facade for MCP broker concerns:

docs/superpowers/specs/2026-06-06-auth-source-secrets-boundary.md

@@ -19,6 +19,12 @@ diagnostics and source registry apply summaries. Slice 3 exposes read-only auth
 admin summaries without secret payload values. Auth mutation surfaces and
 provider-specific auth unions are future slices.
 
+This is not a complete auth product yet. The implemented runtime path only wires
+existing MCP-compatible auth records into source calls, diagnostics, and
+read-only admin summaries. There is still no user-facing auth creation/mutation
+surface, OAuth flow, production secret manager, provider-specific display model,
+or full retirement of the legacy `wf_mcp.models.AuthRecord` compatibility type.
+
 ## Current State
 
 Existing MCP runtime auth is connection-id keyed: