GitOps Sync-Wave Dependency Ordering Design Prompt

You are a senior automation engineer whose GitOps sync keeps failing on first apply because a CustomResource is created before its CRD exists, and the app pods crash-loop because they start before the database migration Job finishes. You now design explicit ordering — sync waves, phases, and hooks — so a single declarative sync converges deterministically instead of relying on retries to eventually heal.

I will provide:
- The set of resources in the application and their real dependencies (CRDs, operators, secrets/config, databases and migrations, the workloads themselves, ingress/DNS)
- The GitOps controller in use (Argo CD sync waves/hooks, Flux dependsOn/health checks) and its reconciliation model
- Which resources have meaningful health signals (Deployments, Jobs, custom health) versus fire-and-forget ones
- What must be true before traffic is allowed, and how a failed mid-sync should behave (halt, roll back, or leave partial)

Your job:

1. **Dependency graph** — turn the resources into an explicit ordering DAG and call out every edge that must hold on a *clean-cluster first apply*, not just steady-state reconciliation (CRD before CR, operator before its CRs, secret before consumer, migration before app).
2. **Wave assignment** — map the DAG onto sync waves / phases, keeping independent resources in the same wave for parallelism and only serializing where a real dependency demands it; avoid over-serializing into a slow single-file sync.
3. **Health gates between waves** — specify that a wave only advances after the prior wave's resources report healthy, and define the health check for each gating resource (Deployment available, Job succeeded, CRD established, custom resource condition) plus a per-wave timeout.
4. **Hooks and their lifecycle** — place pre-sync, sync, and post-sync hooks (migrations, smoke tests, cache warms) correctly, make each hook idempotent and safely re-runnable, and define hook deletion policy so failed/succeeded hooks don't accumulate or block re-sync.
5. **Idempotency and re-sync** — ensure the whole ordering is safe to apply repeatedly: a re-sync of an already-converged app must be a no-op, and a partially-applied sync must resume, not duplicate.
6. **Failure and rollback** — define what happens when a gating resource never goes healthy: does the sync halt at that wave, auto-rollback the app, or surface for manual action — and ensure later waves cannot apply on top of an unhealthy dependency.
7. **Observability** — define what to surface per wave (which wave is active, which resource is blocking, elapsed vs timeout) and an alert for "sync stuck on wave N" so a hang is visible, not silent.

Output as: the dependency DAG, the wave-to-resource mapping, the per-gate health checks and timeouts, the hook placement with idempotency and deletion policy, the re-sync no-op guarantee, the failure/rollback behavior, and the observability plan.

Require that ordering be correct on a first apply to an empty cluster (not merely eventually-consistent via retries), that each wave gate on real health signals with a timeout, and that hooks be idempotent so any re-sync is safe.