deterministic-simulation-testing

Tests distributed systems by replaying seeded fault injections through simulated network, disk, and clock boundaries.

Updated May 21, 2026
One-click install
npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill deterministic-simulation-testing-cagesthrottleus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: deterministic-simulation-testing
Source: https://github.com/CagesThrottleUs/private-ai-harness/tree/main/skills/deterministic-simulation-testing
Command: npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill deterministic-simulation-testing-cagesthrottleus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Concurrent and distributed components fail through rare multi-fault interactions — a network partition plus a slow disk plus a node crash at the same moment — that flaky integration tests cannot reproduce and chaos engineering can observe but not replay. This Skill wires a single seeded random source through every nondeterministic boundary so any failing run replays exactly from its recorded seed. ## Core Features & Use Cases - Seeded Deterministic Boundaries: Replaces network I/O, disk I/O, clock, and scheduling with simulated implementations driven by one seeded PRNG, while real production code runs unchanged in-process. - Fault Injection and Invariant Checking: Drops, reorders, and delays messages, corrupts disk operations, crashes nodes, and skews clocks, asserting a steady-state invariant after every simulated step. - Seed-Based Regression Discipline: Commits each failing seed as a permanent named regression test, modeled on TigerBeetle's VOPR and FoundationDB's simulation framework. - Use Case: When building a consensus or replication protocol, run thousands of seeded simulations to surface a conflicting-commit bug, then replay seed 12345 forever as a regression test proving the fix. ## Quick Start Ask the AI to apply deterministic simulation testing to your distributed component by wiring seeded simulated network, disk, and clock boundaries and asserting your invariant every step.

Frequently Asked Questions about deterministic-simulation-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make distributed system tests reproducible?

Route every nondeterministic boundary — network, disk, clock, and scheduling — through a simulated implementation driven by one seeded PRNG. Record the seed and git commit on failure so re-running with the same seed replays the exact fault interleaving.

What is deterministic simulation testing vs chaos engineering?

Chaos engineering injects faults into a live staging deployment and observes once, black-box. Deterministic simulation testing runs real production code in-process behind seeded simulated boundaries, so any failure replays exactly on demand from its seed.

When should I use deterministic simulation testing?

Use it for components coordinating state across network or disk boundaries with concurrency — consensus, replication, distributed transactions. Skip it for single-process business logic, CRUD services, or components already covered by single-dependency failure-path integration tests.

How do I turn a failing simulation seed into a regression test?

Commit the failing seed and commit hash as a named permanent test, such as test_regression_seed_12345. Never delete a fixed failing seed — it proves that specific fault combination stays handled, like a shrunk property-testing counterexample.

Does simulation testing require changing production code?

Production logic stays unchanged; only the network, disk, and clock interfaces it talks to gain a simulated implementation alongside the real one. The same RealNodeImplementation code runs in production and in simulation, unaware it is being simulated.