Background
#5328 (PR #5345) wired the OBO external-auth type through the operator dispatch sites and the MCPExternalAuthConfig reconciler, surfacing Valid=False / Reason=EnterpriseRequired on the MCPExternalAuthConfig itself in upstream-only builds.
The original AC for #5328 also called for the consumer CRDs (MCPServer, MCPRemoteProxy, VirtualMCPServer) to surface a parallel Valid=False / EnterpriseRequired condition. That parity does not exist in the codebase today — a grep of cmd/thv-operator/controllers/ confirms only one site sets the ConditionTypeExternalAuthConfigValidated condition (for the multi-upstream rejection), not as a general propagation from MCPExternalAuthConfig.Status. PR #5345's tests verify the dispatch error path, not the parallel-condition propagation.
Per .claude/rules/operator.md's Status Condition Parity rule ("a gap means one type silently accepts invalid config that the other rejects"), this remains a real parity gap. It was deferred from #5345 as out-of-scope cross-cutting work.
Why this matters now
#5329 (CRD enum admission) is what makes obo reachable in production. Before #5329 lands, an OBO-typed MCPExternalAuthConfig referenced from a consumer CR fails the consumer's reconcile silently (the dispatch error propagates up the runconfig-build error path but no Valid=False/EnterpriseRequired condition surfaces on the consumer's own Status.Conditions).
Acceptance criteria
References
Background
#5328 (PR #5345) wired the OBO external-auth type through the operator dispatch sites and the
MCPExternalAuthConfigreconciler, surfacingValid=False/Reason=EnterpriseRequiredon theMCPExternalAuthConfigitself in upstream-only builds.The original AC for #5328 also called for the consumer CRDs (
MCPServer,MCPRemoteProxy,VirtualMCPServer) to surface a parallelValid=False/EnterpriseRequiredcondition. That parity does not exist in the codebase today — a grep ofcmd/thv-operator/controllers/confirms only one site sets theConditionTypeExternalAuthConfigValidatedcondition (for the multi-upstream rejection), not as a general propagation fromMCPExternalAuthConfig.Status. PR #5345's tests verify the dispatch error path, not the parallel-condition propagation.Per
.claude/rules/operator.md's Status Condition Parity rule ("a gap means one type silently accepts invalid config that the other rejects"), this remains a real parity gap. It was deferred from #5345 as out-of-scope cross-cutting work.Why this matters now
#5329 (CRD enum admission) is what makes
oboreachable in production. Before #5329 lands, an OBO-typedMCPExternalAuthConfigreferenced from a consumer CR fails the consumer's reconcile silently (the dispatch error propagates up the runconfig-build error path but noValid=False/EnterpriseRequiredcondition surfaces on the consumer's ownStatus.Conditions).Acceptance criteria
MCPServerreferences anMCPExternalAuthConfigwhoseValidcondition isFalse/EnterpriseRequired, theMCPServer.Status.Conditionssurfaces a parallelValid=False/Reason=EnterpriseRequiredcondition (or equivalent — confirm the reason taxonomy with the operator-rules owner).MCPRemoteProxy.VirtualMCPServer.cmd/thv-operator/test-integration/mcp-external-auth/verify the propagation end-to-end against envtest, with CRD-enum bypass per Wire OBO dispatch arms and reconciler branch; add integration tests #5328's documented strategy.MCPExternalAuthConfig).References
.claude/rules/operator.mdStatus Condition Parity section