Control Plane + Governance

Governance keeps customer-controlled configuration, runtime enforcement, and Leverage-owned operations separated.

Implemented

Customer-facing connector policy and curation live in cms-customer.
Connector OAuth provider rows are hidden seed-managed relationship metadata, not a separate customer policy surface.
Connector runtime catalog and connect flows are API-served and fail closed on registry/config drift.
Connector OAuth credentials and public chat provider API keys are deployment-owned secrets, not CMS content fields.
Public provider keys can be supplied only through cms-customer setup/validate/rotate actions that write declared credential slots and store safe status metadata.
Public chat availability is governed from cms-customer Chat Behavior, approved public provider/model policy, API runtime provider wiring, and public-provider credential health; API runtime config and public create/send enforcement consume those inputs and fail closed when public chat is disabled or unavailable.
Curated default connector identity and capability fields are guarded from ordinary edits/deletes.
The old connector approval/request workflow is removed from runtime/control-plane contracts.
cms-customer and cms-leverage are separate apps with separate data, auth, secrets, service audiences, and release boundaries.

Whitelabel brand settings for CMS and web are deferred until product accepts the settings model and ownership boundary.
Future database-secret storage needs envelope encryption, key rotation, and structured decrypt-failure events before implementation.
Some dynamic same-provider multi-account proof remains verification work.
CMS operator landing and non-admin route IA are tracked separately under CMS Operator Experience.