Tooling Note
`state-sentinel` exists for projects where the system can keep running while becoming less trustworthy. In simulation-heavy work, that kind of regression is common: technically alive, operationally drifting.
The practical need was checking long chains of state transitions where a bug might only surface after several steps, under a specific sequence, or through subtle divergence from an expected baseline.
That is exactly where ordinary pass/fail checks can miss the real issue. A system can avoid crashing and still become less deterministic, less explainable, or less internally consistent over time.
Standard tests are essential, but many of them answer a narrower question: did this assertion pass right now? They do not always answer: did the larger runtime remain stable across state transitions?
What was missing was a focused audit layer for system health and determinism, not just correctness at a single checkpoint.
Determinism checks depend on assumptions. Open sourcing the tool makes those assumptions inspectable and easier to adapt to other systems with different state models, tolerances, and audit thresholds.
The exact project can change, but the operational need is common: surface silent drift before it becomes normal.
On Hubsays, `state-sentinel` represents the audit side of the live-systems loop. It helps prevent bad actions and proves the system stayed sane after real runtime activity.