Address Jhrozek review feedback on RFC-0055

- Generalize mode selection guide to cover all auth types, not just token exchange
- Reword rule of thumb to use "fronted by vMCP" vs "standalone" framing
- Replace ASCII auth flow diagrams with mermaid sequence diagrams
- Clarify dual-consumer auth behavior per mode
- Remove implementation-level token lifetime detail
- Add groupRef rationale inline comment
- Replace name collision fallback with admission-time rejection
- Replace CEL oidcConfig rule with standard kubebuilder Required marker

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: ChrisJBurns

rfcs/THV-0055-mcpremoteendpoint-unified-remote-backends.md

@@ -96,16 +96,17 @@ should be a configuration choice within it.
 | Scenario | Recommended Mode | Why |
 |---|---|---|
 | Public, unauthenticated remote (e.g., context7) | `direct` | No auth middleware needed; no pod required |
-| Remote requiring only token exchange auth | `direct` | vMCP handles token exchange; one fewer hop |
+| Remote with outgoing auth handled by vMCP (token exchange, header injection, etc.) | `direct` | vMCP applies outgoing auth directly; one fewer hop |
 | Remote requiring its own OIDC validation boundary | `proxy` | Proxy pod validates tokens independently |
 | Remote requiring Cedar authz policies per-endpoint | `proxy` | Authz policies run in the proxy pod |
 | Remote needing audit logging at the endpoint level | `proxy` | Proxy pod has its own audit middleware |
 | Standalone use without VirtualMCPServer | `proxy` | Direct mode requires vMCP to function |
 | Many remotes where pod-per-remote is too costly | `direct` | No Deployment/Service/Pod per remote |
 
-**Rule of thumb:** Use `direct` for simple, public, or token-exchange-only
-remotes. Use `proxy` when you need an independent auth/authz/audit boundary
-per remote, or when the backend needs to be accessible standalone.
+**Rule of thumb:** Use `direct` for simple, public remotes or any remote
+fronted by vMCP where vMCP handles outgoing auth. Use `proxy` when you need an
+independent auth/authz/audit boundary per remote, or when the backend needs to
+be accessible standalone.
 
 ## Proposed Solution
 
@@ -173,12 +174,21 @@ graph TB
 
 **`type: proxy` — two independent auth legs:**
 
-```
-Client --[aud=vmcp token]--> vMCP [validates token at incoming boundary]
-  --[externalAuthConfigRef credential]--> Proxy Pod
-    [proxy pod oidcConfig validates the incoming request]
-    [proxy pod applies externalAuthConfigRef as outgoing middleware]
-      --> Remote Server
+```mermaid
+sequenceDiagram
+    participant C as Client
+    participant V as vMCP
+    participant P as Proxy Pod
+    participant R as Remote Server
+
+    C->>V: Request (aud=vmcp token)
+    V->>V: Validate incoming token
+    V->>P: Forward (externalAuthConfigRef credential)
+    P->>P: oidcConfig validates incoming request
+    P->>R: Forward (externalAuthConfigRef as outgoing middleware)
+    R-->>P: Response
+    P-->>V: Response
+    V-->>C: Response
 ```
 
 `externalAuthConfigRef` on a `type: proxy` endpoint is read by two separate
@@ -191,16 +201,26 @@ consumers:
    (`AddExternalAuthConfigOptions()` in `mcpremoteproxy_runconfig.go`). The pod
    applies it as outgoing middleware when forwarding requests **to the remote server**.
 
+In direct mode, only consumer 1 applies — there is no proxy pod.
+
 `proxyConfig.oidcConfig` is a third, separate concern — it validates tokens
 arriving at the proxy pod from vMCP. It is entirely independent of
 `externalAuthConfigRef`.
 
 **`type: direct` — single auth boundary:**
 
-```
-Client --[aud=vmcp token]--> vMCP [validates token at incoming boundary]
-  [vMCP applies externalAuthConfigRef as outgoing auth]
-    --> Remote Server
+```mermaid
+sequenceDiagram
+    participant C as Client
+    participant V as vMCP
+    participant R as Remote Server
+
+    C->>V: Request (aud=vmcp token)
+    V->>V: Validate incoming token
+    V->>V: Apply externalAuthConfigRef as outgoing auth
+    V->>R: Request (with outgoing credentials)
+    R-->>V: Response
+    V-->>C: Response
 ```
 
 vMCP reads `externalAuthConfigRef` and applies it when calling the remote
@@ -213,9 +233,6 @@ client's token.
 - The STS must be configured to accept subject tokens from vMCP's IdP.
 - Configure `audience` in the `MCPExternalAuthConfig` to match the remote
   server's expected audience claim.
-- Client token lifetime should exceed the expected duration of the exchange
-  request. Exchanged tokens are managed by the `golang.org/x/oauth2` token
-  source and refreshed automatically on expiry per connection.
 
 **Unsupported `externalAuthConfigRef` types for `type: direct`:**
 
@@ -255,10 +272,12 @@ The four rules for `MCPRemoteEndpoint`, placed on their correct owning types:
 //nolint:lll
 type MCPRemoteEndpointSpec struct { ... }
 
-// MCPRemoteEndpointProxyConfig struct-level rule:
-//
-// +kubebuilder:validation:XValidation:rule="has(self.oidcConfig)",message="spec.proxyConfig.oidcConfig is required"
-type MCPRemoteEndpointProxyConfig struct { ... }
+// MCPRemoteEndpointProxyConfig — oidcConfig uses standard required marker:
+type MCPRemoteEndpointProxyConfig struct {
+    // +kubebuilder:validation:Required
+    OIDCConfig OIDCConfigRef `json:"oidcConfig"`
+    // ...
+}
 ```
 
 **Important:** The `oldSelf == null` guard is required so the immutability rule
@@ -292,7 +311,8 @@ spec:
   # +kubebuilder:validation:Enum=streamable-http;sse
   transport: streamable-http
 
-  # REQUIRED: Group membership.
+  # REQUIRED: Group membership. MCPRemoteEndpoint only functions as part of
+  # an MCPGroup (aggregated by VirtualMCPServer), so groupRef is always required.
   groupRef: engineering-team
 
   # OPTIONAL: Auth for outgoing requests to the remote server.
@@ -589,11 +609,18 @@ Extend `ListWorkloadsInGroup()` and `GetWorkloadAsVMCPBackend()` in
 - `type: proxy` — uses `status.url` (proxy Service URL), same as MCPRemoteProxy
 - `type: direct` — uses `spec.remoteURL` directly
 
-**Name collision handling:** `fetchBackendResource()` in
-`pkg/vmcp/k8s/backend_reconciler.go` tries resources in order: MCPServer →
-MCPRemoteProxy → MCPRemoteEndpoint. Same-name resources across types in the
-same namespace always resolve to the first match. Log a warning when a
-collision is detected.
+**Name collision prevention:** The MCPRemoteEndpoint controller MUST reject
+creation if an MCPServer or MCPRemoteProxy with the same name already exists in
+the namespace, setting `ConfigurationValid=False` with reason
+`NameCollision`. Likewise, the MCPServer and MCPRemoteProxy controllers MUST
+be updated to reject collisions with MCPRemoteEndpoint. This prevents
+surprising fallback behaviour where deleting one resource type silently
+activates a different resource with the same name.
+
+`fetchBackendResource()` in `pkg/vmcp/k8s/backend_reconciler.go` retains its
+existing resolution order (MCPServer → MCPRemoteProxy → MCPRemoteEndpoint) as
+a defensive fallback, but the admission-time rejection above makes same-name
+collisions a user error rather than an implicit resolution policy.
 
 ##### vMCP: HTTP Client for Direct Mode