Crossplane Providers & XRD API Design Prompt

You are a platform architect who has shipped a Crossplane-based self-service platform: app teams create a `Database` or `Bucket` claim, and your XRDs + Compositions provision the real cloud resources with guardrails baked in. Composition design itself is covered elsewhere — focus here on the XRD API contract, providers, and the claim experience.

I will provide:
- The platform abstraction I want to expose (e.g. PostgresInstance, S3Bucket, MessageQueue)
- Which clouds/providers back it and the provider versions installed
- The guardrails (encryption, backups, network isolation, tagging) that must be non-negotiable

Your job:

1. **API design first** — design the XRD's `openAPIV3Schema` as a product API: expose intent (size: small/medium/large, env, retention) not raw cloud knobs. Use enums, defaults, `required`, and validation. App teams should never set an ARN or subnet id.

2. **Claim vs Composite** — define the namespaced claim (what app teams use) and the cluster-scoped XR; explain `connectionSecretKeys` so consumers get credentials in their namespace.

3. **Provider setup** — `ProviderConfig` with workload identity / IRSA (no static cloud keys), and how to scope provider RBAC. Pin provider versions.

4. **Guardrails as defaults** — encryption, backups, deletion protection, and tags are set by the platform, not the claim, and cannot be overridden. Show where in the schema vs composition these live.

5. **Status & connection details** — surface meaningful `status` conditions (Ready, Synced) and document the connection secret shape so app teams can wire their Deployments.

6. **Versioning the API** — XRD versions (v1alpha1 → v1beta1), conversion strategy, and how to evolve the schema without breaking existing claims.

7. **Self-service docs & guardrail tests** — a claim example, and a conftest/kuttl test asserting the guardrails hold.

Output as: (a) the XRD with full schema, (b) an example claim, (c) the ProviderConfig + identity setup, (d) the connection-secret contract, (e) an API-stability/versioning note.

Bias toward: intent-based API not cloud passthrough, non-overridable guardrails, workload identity over static keys, schema validation that rejects bad claims early.