What problems was I solving

Custom components created by authors through the Page UI have no exposed API surface for management users to list, view, create, and publish them. Management UI lacks both data-read fibers (for Studio dropdowns, validation, display) and lifecycle operations (for admin approval workflows and governance).

What user-facing changes did I ship

Management users can now consume custom component data through the management UI GraphQL endpoint. Custom component creation, versioning, validation, and publishing operations are available via the management tRPC router when the tenant feature flag is enabled. No direct product usage changes; this is a behind-the-scenes surface addition.

How I implemented it

Three-layer solution: (1) Management UI view-model with React hooks and GraphQL operations, reusing service-owned schemas to parse JSON blobs and maintain backward compatibility, (2) Management gateway GraphQL schema extension with three queries (list/detail/version) that resolve through custom-component-service with feature flag gating, and (3) Web service tRPC router for lifecycle mutations (create/validate/publish/proposal) sharing feature flag logic. All three layers are tested: UI layer has JSON parsing tests, gateway has runtime schema tests with stub service mocks, and web service has full DSL tests covering auth and feature gating.

Description for the changelog

Introduces management-side data and lifecycle fibers for custom components. Management UI can now query custom component lists and details through GraphQL. Management users can create, add versions to, validate, and publish custom components via tRPC when the custom-components tenant feature flag is enabled. All operations are gated and delegated to the custom-component-service, maintaining the canonical service API as the single source of truth.