Cheating and validation

Client-side validation is useful for UX, not a security boundary. A modified client can bypass getValidActions, alter a local snapshot, fabricate a resource, or send a direct CRDT update. In a peer game there is no automatic trusted referee.

For competitive play, validate and commit outcomes in an authoritative Engine, keep private state out of broad projections, and make dispatch failures and partial mutation behavior explicit. The authoritative server's outbound projection is a disclosure boundary; it is not proof that inbound peer state is honest.

For merge-friendly games, encode invariants in the action handler, use immutable tokens/tombstones, preserve conflicting writes where appropriate, and audit derived views. Test malformed, duplicate, stale, and concurrent actions.