what the system must remember across a restart
Restarts are where a live system loses its argument with itself. Nothing crashes; the process returns, reads its configuration, and begins the day fresh — except that the day did not begin when the process did.
The case that surfaced this was narrow, and any test that restarted an idle system would have missed it. Earlier in the day a gate had held admissions because a required sign-off was not yet in place. The sign-off arrived hours later, on the other side of a restart. The restarted process had no memory of having held anything, so the first decision after the restart was sized and admitted with no warning at all, while every earlier decision that day had correctly been suppressed.
The fix seeds the day's held state from the ledger at startup. Whatever the day has already recorded as suppressed is loaded as fact rather than inferred from the process's own lifetime, so a warning is emitted when a gate that held something today is later found open. The same review found the mirror-image problem in the event reader: after a restart at a truncated file position, the reader must re-anchor rather than resume from a remembered offset, or an event already processed can be consumed twice.
Both fixes are a few lines. Both depend on the system being able to say what happened before it started, which is a property of the record rather than of the code.
It proves live behaviour is judged across restarts, not only within one process lifetime.
drawn from: a restart fix that seeds the day's state from the ledger
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.