sparta_worlds 0.6.0

package/server/scenarios/rate-limit-storm.yaml

@@ -0,0 +1,10 @@
+# Everything is fine — until Stripe starts 429ing. The first 3 twin requests
+# succeed; the next 3 are rate-limited; then service recovers. Great for
+# catching agents whose retry logic re-issues side-effectful requests.
+name: rate-limit-storm
+description: "3 requests succeed, then 3 get 429 rate_limit, then normal service resumes."
+rules:
+  - match: { path: "/v1/**" }
+    after_requests: 3
+    duration_requests: 3
+    respond: { status: 429, stripe_error: rate_limit }

package/server/scenarios/slow-stripe.yaml

@@ -0,0 +1,9 @@
+# Stripe is up, but everything takes 800ms. Reads on customer endpoints take
+# 1.5s. Exposes agents (and harnesses) with tight timeouts that then retry.
+name: slow-stripe
+description: "800ms latency on all twin requests; 1500ms on /v1/customers/*."
+rules:
+  - match: { path: "/v1/**" }
+    latency_ms: 800
+  - match: { path: "/v1/customers/*" }
+    latency_ms: 1500

package/server/scenarios/stripe-storm-shift.yaml

@@ -0,0 +1,15 @@
+# Shift-scale Stripe weather. rate-limit-storm's three-request window lands
+# inside the first ticket of a 200-call shift and is invisible; this one opens a
+# six-request 429 window after the first 25 calls, then rate-limits every 7th
+# write for the rest of the shift. Each rule keeps its own counter.
+name: stripe-storm-shift
+description: "A six-request 429 window after the first 25 Stripe calls, then every 7th Stripe write is rate-limited; the help desk is untouched."
+rules:
+  - match: { path: "/v1/**" }
+    after_requests: 25
+    duration_requests: 6
+    respond: { status: 429, stripe_error: rate_limit }
+  - match: { method: POST, path: "/v1/**" }
+    after_requests: 10
+    every_nth: 7
+    respond: { status: 429, stripe_error: rate_limit }

package/server/scenarios/tickets-storm.yaml

@@ -0,0 +1,10 @@
+# The help desk is flaky, Stripe is healthy. Every 4th ticket update fails with
+# a Zendesk-shaped 500 — after the money has (or hasn't) moved on the other
+# surface. The shift demo's Act III: grade whether what the agent told the
+# customer still matches what the world recorded when one surface drops calls.
+name: tickets-storm
+description: "Every 4th ticket update (PUT /api/v2/tickets/*) fails with a Zendesk-shaped 500; Stripe is untouched."
+rules:
+  - match: { method: PUT, path: "/api/v2/tickets/*" }
+    every_nth: 4
+    respond: { status: 500, stripe_error: api_error }

package/server/scenarios/webhook-chaos.yaml

@@ -0,0 +1,7 @@
+# Webhooks misbehave: every 3rd delivery is silently dropped, and deliveries
+# within a flush batch arrive pairwise swapped. Your event handler should
+# survive gaps and out-of-order arrival — does your agent's?
+name: webhook-chaos
+description: "Drop every 3rd webhook delivery and swap adjacent deliveries."
+rules:
+  - webhooks: { drop_every_nth: 3, reorder: swap_adjacent }