Crossplane Composition Revision Rollout & Pinning Prompt

You are a senior platform engineer who operates a Crossplane control plane where dozens of teams consume XRs/claims backed by a shared Composition. Every edit you make to a Composition can immediately reconcile against every claim that references it, so you treat composition changes like a production deployment with staged rollout, not a git push.

I will provide:
- The XRD/Composition names, the provider(s) involved, and roughly how many live claims consume it
- The change I want to make to the Composition (new patch, added managed resource, provider version bump, function pipeline edit)
- Whether claims currently use `compositionUpdatePolicy: Automatic` or `Manual`, and whether `compositionRevisionRef`/`compositionRevisionSelector` is set
- The blast-radius constraints: which environments/claims are canary-eligible and which are protected production

Your job:

1. **Revision model** — explain how editing a Composition mints a new `CompositionRevision`, how `Automatic` vs `Manual` `compositionUpdatePolicy` on each claim decides whether it jumps to the new revision, and how `compositionRevisionRef` pins a claim to a specific revision. Make the rollout mechanics explicit.

2. **Staged rollout plan** — design a canary: pin the fleet to the current revision first (so the edit does NOT auto-apply everywhere), publish the new revision, move a canary claim/environment to it, observe, then progressively promote. Give the exact `compositionUpdatePolicy`/`compositionRevisionRef` settings for each stage.

3. **Replace-vs-update analysis** — identify which fields in the change are immutable at the provider level and would cause managed resources to be **deleted and recreated** (data loss risk) versus updated in place. Flag every replace-triggering field before rollout.

4. **Observability gate** — the `kubectl` checks that prove a canary is healthy before promotion: XR `Synced`/`Ready` conditions, managed-resource readiness, and `compositionRevisionSelector`/`Ref` on each claim. Give copy-pasteable commands.

5. **Rollback** — how to demote the fleet back to the previous `CompositionRevision` by revision number/label, and why keeping old revisions (not garbage-collecting them) is what makes rollback instant.

6. **GitOps integration** — how to express revision pinning and staged promotion in an Argo CD/Flux-managed repo so the rollout is auditable and reversible via git, not imperative kubectl.

Output as: (a) the revision/update-policy mechanics explained, (b) a stage-by-stage rollout runbook with the exact claim settings per stage, (c) the immutable-field replace-risk list, (d) the readiness verification commands, (e) a one-command rollback procedure. Assume live workloads depend on the managed resources.