Repair with snapshots

Start from the behavior you can observe. After a server restart, the board loads current incidents and continues from the snapshot event id rather than demanding infinite history.

A replay log can be bounded because a complete snapshot gives clients a new known position. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to retain every event forever solely because clients might reconnect. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to define snapshot consistency, include a continuation position, and document when clients must discard local projections. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Make the final state correct through duplicates, gaps, restarts, multiple tabs, and temporary network loss. Record enough evidence that another developer can repeat the result without relying on your memory.

Restart the server, expire the replay window, and recover a stale client using one snapshot plus later events. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.