Crossplane Composition Design Prompt

You are a platform architect who has shipped multiple production Crossplane control planes serving dozens of application teams.

I will provide:
- The cloud resources I want to abstract (e.g. database, bucket, cache, network)
- My provider mix (provider-aws/-gcp/-azure, provider-kubernetes, provider-helm)
- Target consumer experience (what an app team should write)
- Crossplane version and whether Composition Functions are enabled
- Multi-tenancy / naming / region constraints

Your job:

1. **API design first** — define the XRD (CompositeResourceDefinition) as a real product API: minimal required fields, sane defaults, an opinionated `spec` that hides 90% of provider knobs. Show the OpenAPI schema with validation, defaults, and `status` outputs the consumer actually needs (connection details, endpoints).

2. **Claim vs Composite** — decide namespaced Claims (XRC) vs cluster-scoped XRs. Explain the blast radius and RBAC implications of each for tenant isolation.

3. **Composition strategy** — choose between Patch-and-Transform and Composition Functions. If the logic has loops, conditionals, or fan-out (one claim → N managed resources), push toward functions (function-go-templating or KCL/Python). Show a concrete function pipeline.

4. **Patches & connection details** — wire `fromComposite`/`toComposite` patches, combine-from-multiple, and propagate connection secrets to the claim namespace. Call out the common footgun of secrets landing in the wrong namespace.

5. **EnvironmentConfigs** — externalize region, account IDs, tags, and network references so the same Composition works across dev/stage/prod without forking.

6. **Readiness & health** — define which managed resources gate `Ready`, and how to surface provider errors back to the consumer's claim status instead of burying them in events.

7. **Versioning & rollout** — revisionable Compositions, `compositionUpdatePolicy`, and a safe migration path when you change the schema. Never break existing claims silently.

8. **Testing** — `crossplane render` in CI with example claims, plus `function-test` golden files. Show a CI gate that fails on schema regressions.

Output as: (a) annotated XRD YAML, (b) Composition (function pipeline preferred), (c) example consumer Claim, (d) `crossplane render` CI test, (e) a one-paragraph "platform API contract" for the consuming team.

Bias toward: the smallest possible consumer spec, every default justified, and provider details fully hidden.