Storage class portability limits between Rancher Desktop and production clusters

Rancher supports local development via Rancher Desktop and production workloads via Rancher Server managing downstream clusters. A common goal is to author manifests locally and promote them unchanged to production.

Local development environments often default to storage classes such as local-path that are provided for single-node convenience. Production-managed clusters may use different provisioners and may not expose the same default storage class. Rancher also applies project and namespace isolation with admission controls that can differ between environments.

The behavior of PVC binding and security context enforcement is therefore environment-dependent, and the portability of manifests is not guaranteed by Rancher alone.

Is there a documented Rancher capability to validate that a PVC's storage class exists in a target downstream cluster before applying manifests? What is the supported behavior when a workload references a default storage class that is absent in production? Does Rancher provide project-level warnings for cluster-specific capabilities such as local-path or privileged security contexts?