resiliencelisted

# Resilience Adapted from [codewithmukesh/dotnet-claude-kit](https://github.com/codewithmukesh/dotnet-claude-kit) (MIT). **Find out who already owns retry before adding any.** The most common resilience defect is *doubled* retry: a Polly pipeline wrapped around a transport that already retries and dead-letters on its own. Message brokers (Azure Service Bus, RabbitMQ, SQS), managed queue triggers, and most cloud SDKs have built-in retry policies — wrapping those in Polly multiplies the attempt count and turns a transient blip into a thundering herd. Before writing a pipeline, check the repo's messaging/infrastructure docs and the SDK defaults, then apply the Polly v8 patterns below **only to outbound calls the application itself owns**: HTTP clients, database drivers without their own retry, and third-party libraries you call directly. Say in the PR which layer owns retry for the path you touched. ## Core Principles 1. **Polly v8 resilience pipelines, not v7 policies** — Polly v8 replaced `Policy` with `ResiliencePipeline`. Never use `PolicyBuilder`, `Policy.Handle<>()`, or `ISyncPolicy`. The new API is composable, type-safe, and integrates natively with `IHttpClientFactory`. 2. **Configure via `AddResilienceHandler`, not manual wrapping** — For HTTP calls, use `Microsoft.Extensions.Http.Resilience` which adds pipelines directly to `HttpClient` via DI. No manual `ExecuteAsync` wrapping. 3. **Compose strategies, don't nest them** — A single `ResiliencePipeline` can chain r