Handle order and duplicates

Before choosing a tool or writing more code, make the requirement concrete. Applying incident.updated:84 twice should produce the same board, while an older version must not overwrite a newer one.

Networks retry, reconnect, buffer, and sometimes deliver duplicates; application state must not depend on every event arriving exactly once. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to increment local state blindly for every received message. The happy path may still work, which makes the mistake easy to miss. track stable ids or versions, ignore duplicates, reject stale updates, and make commands idempotent where retries are possible. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Make the final state correct through duplicates, gaps, restarts, multiple tabs, and temporary network loss. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Replay the same event twice and then replay an older event; assert that the visible board does not regress. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.