Design message envelopes

Start from the behavior you can observe. An acknowledgement references the client command id, while an incident update carries a server event id used for deduplication.

WebSockets transport messages; they do not define the meaning, authorization, or compatibility of those messages. 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 switch on loosely shaped JSON and trust every field because the connection is already open. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to parse safely, validate against a documented envelope, reject unknown types, and correlate commands with acknowledgements. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Build a bidirectional operator channel with explicit messages, bounded queues, and observable connection state. Record enough evidence that another developer can repeat the result without relying on your memory.

Define command, acknowledgement, event, and error envelopes and test malformed JSON and an unknown message version. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.