Designing Distributed System Tests

Original name

Original description

Use when designing a test plan for a distributed or stateful system — anything with persistence, replication, consensus, retries, idempotency, async messaging, multi-tenancy, or partial failure. Plans are claim-driven; investigate the product's claimed guarantees first, then design hypotheses and scenarios that try to falsify those claims under fault. Handles both change-scoped plans (a specific commit / PR / feature) and project-wide plans (a holistic plan for the whole system with existing-test inventory and gap analysis). Also use when asked to write a stability plan, fault matrix, release-validation plan, durability test plan, partition test plan, upgrade test plan, crash-recovery test plan, linearizability test plan, deterministic-simulation plan, tenant isolation test plan, authz / boundary test plan, namespace isolation plan, multi-protocol access plan, fairness test plan, noisy-neighbor test plan, "test plan to enough coverage", "what should we be testing", or "make a holistic test plan". Trigger even if the user just says "what should we test for this change", "design the test plan for this project", "are my tenants actually isolated", or "how do I test fairness across tenants / shards / queues". Produces a structured Markdown plan file with hypothesis-driven scenarios drawn from a curated technique catalog (Jepsen+Elle, deterministic simulation, chaos/fault injection, fuzzing, formal methods, property+metamorphic, performance, crash-recovery+upgrade) and, for claims involving consistency / durability / idempotency / isolation / ordering / membership, a model+history+checker discipline (§7.M); for claims involving boundary semantics (tenant isolation, authz, namespace, routing, multi-protocol) or fairness, a surface-decomposition discipline (§7.M.S) that splits the scenario into per-surface arms with independent verdicts.