Update chaos strategy documentation with notes

docs/chaos/index.md

@@ -47,13 +47,14 @@ builder
     .AddChaosBehavior(behaviorInjectionRate, cancellationToken => RestartRedisAsync(cancellationToken)); // Inject a chaos behavior to executions
 ```
 <!-- endSnippet -->
+> [!NOTE]
+> It is usual to place the chaos strategy as the last strategy in the resilience pipeline.
+> By placing the chaos strategies as last, they subvert the usual outbound call at the last minute, substituting their fault or adding extra latency, etc.
+> The existing resilience strategies - further out in the `ResiliencePipeline` - still apply, so you can test how the Polly resilience strategies you have configured handle the chaos/faults injected by Simmy.
 
-- It is usual to place the chaos strategy as the last strategy in the resilience pipeline.
-- By placing the chaos strategies as last, they subvert the usual outbound call at the last minute, substituting their fault or adding extra latency, etc.
-- The existing resilience strategies - further out in the `ResiliencePipeline` - still apply, so you can test how the Polly resilience strategies you have configured handle the chaos/faults injected by Simmy.
-
-- The `AddChaos*` will take effect sequentially if you combine them together.
-- In the above example, we use **fault first then latency strategy**, it can save fault waiting time. If you put `AddChaosLatency` before `AddChaosFault`, you will get different behavior.
+> [!NOTE]
+> The `AddChaosFault` `AddChaosLatency` `AddChaosOutcome` `AddChaosBehavior` will take effect sequentially if you combine them together.
+> In the above example, we use **fault first then latency strategy**, it can save fault waiting time. If you put `AddChaosLatency` before `AddChaosFault`, you will get different behavior.
 
 ```mermaid
 sequenceDiagram