goodbye modes 1

docs/mcp_protocol_proxy_inventory.md

@@ -1,6 +1,6 @@
 # MCP Protocol Proxy Inventory
 
-This document records observed behavior of `wf-mcp` unified mode against real
+This document records observed behavior of the `wf-mcp` server against real
 upstream MCP servers. It is not a design spec. It is a fact log for deciding
 which proxy features need explicit implementation.
 
@@ -23,7 +23,7 @@ everything.default
 Proxy mode:
 
 ```text
-wf-mcp serve --mode unified
+wf-mcp serve
 ```
 
 ### Working

docs/superpowers/plans/2026-05-16-retire-legacy-mcp-modes.md

@@ -49,7 +49,7 @@ Remove the public `serve --mode broker` and `serve --mode proxy` choices.
 
 After this pass:
 
-- `wf-mcp serve` runs the unified surface
+- `wf-mcp serve` runs the server surface
 - users no longer choose among three product modes
 - docs should describe one server behavior, not a mode matrix
 
@@ -76,7 +76,7 @@ These packages still represent useful implementation boundaries:
 - `wf_mcp.server`
 
 `transparent_proxy` is already partly a legacy package name, but the code inside
-it still owns real proxy-mounting mechanics used by unified mode. Rename or
+it still owns real proxy-mounting mechanics used by the server. Rename or
 re-home that code only as a later cleanup if the package name becomes a real
 source of confusion.
 

docs/wf_mcp_architecture.md

@@ -101,11 +101,12 @@ The current practical proxy roadmap, including which FastMCP gaps are worth
 working around locally and which should stay upstream-dependent for now, lives
 in [`wf_mcp_proxy_reality_and_roadmap.md`](wf_mcp_proxy_reality_and_roadmap.md).
 
-The public MCP mode split is now being retired. The current execution plan is
+The public MCP mode split has been retired. The execution plan is
 [`superpowers/plans/2026-05-16-retire-legacy-mcp-modes.md`](superpowers/plans/2026-05-16-retire-legacy-mcp-modes.md):
-`broker` and `proxy` are legacy public launch surfaces, while unified behavior
-is the intended product surface. Internal concern packages remain useful even
-after the public mode choices disappear.
+`broker` and `proxy` were legacy public launch surfaces, while the ordinary
+server now exposes both local capabilities and proxied upstream capabilities.
+Internal concern packages remain useful even though the public mode choices are
+gone.
 
 ## Future Extraction
 

docs/wf_mcp_capability_sources.md

@@ -2,8 +2,8 @@
 
 `wf_mcp` should model capabilities before it models MCP server tool lists.
 Tools, workflow node specs, prompts, resources, and admin controls all belong to
-a source. Broker mode, transparent proxy mode, workflow planning, and future UI
-surfaces are projections of those sources.
+a source. The MCP server, workflow planning, and future UI surfaces are
+projections of those sources.
 
 This avoids the current trap where broker admin tools, transparent proxy admin
 tools, workflow node specs, and upstream MCP tools all look like unrelated
@@ -237,15 +237,15 @@ names.
 
 ## Migration Path
 
-1. Add explicit admin MCP exposure controls for broker mode.
-2. Project broker admin tools from `wf.admin` only when admin MCP exposure is
+1. Keep explicit admin MCP exposure controls on the server surface.
+2. Project admin tools from `wf.admin` only when admin MCP exposure is
    enabled.
 3. Add source-level enable/disable operations backed by `wf.admin`.
 4. Add persisted source policy so source visibility survives process restart.
 5. Add system prompts/resources for `wf.std` and `wf.mcp` manuals.
 
-The implementation should avoid having broker mode and transparent proxy mode
-define separate copies of the same admin/control capabilities.
+The implementation should avoid having separate backend layers define copies of
+the same admin/control capabilities.
 
 ## Current Inventory Surfaces
 

docs/workflow_artifacts.md

@@ -51,16 +51,15 @@ new workflow artifacts are saved. A stable `run_deployment` tool lets an LLM
 test saved workflows immediately without requiring dynamic tool registration or
 tool-list notifications to work perfectly.
 
-This control surface should not fork between broker mode and transparent proxy
-mode. The project currently has two MCP exposure styles:
+This control surface should not fork between backend service layers. The public
+server now has one exposure style, but internally it still combines:
 
-- compatibility broker tools such as list/call wrappers
-- transparent proxy projection through MCP `tools/list` and `tools/call`
+- service-backed local workflow/admin tools
+- upstream proxy projection through MCP `tools/list` and `tools/call`
 
 Workflow artifact operations should be defined once and projected through the
-chosen MCP server surface. If broker and transparent modes remain as launch
-options, they should share the same platform service instead of owning separate
-workflow registries or separate run semantics.
+server surface instead of owning separate workflow registries or separate run
+semantics.
 
 Dynamic projection of saved workflows as individual MCP tools can exist later,
 but it should be optional. The stable run tool is the reliable base layer.