1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//! DTO boundary definitions.
//!
//! ## Design rules
//!
//! - DTOs are **passive transport types**. They contain no domain logic, policy,
//! validation, normalization, or invariant enforcement.
//!
//! - DTOs do **not claim guarantees that Candid cannot enforce**. In particular,
//! uniqueness, ordering, and keyed semantics are not preserved at the wire
//! level and must not be relied upon.
//!
//! - All authoritative invariants (e.g. ownership, uniqueness, replacement
//! semantics) live in **storage and ops layers**, never in DTOs.
//! - Data exported from stable registries is treated as a **snapshot** of state,
//! not a live or authoritative registry.
//!
//! - DTOs therefore prefer simple list representations (`Vec<T>`). When keyed
//! data is needed, define small entry structs (`FooEntry`) instead of
//! tuples or maps. More structured shapes are used only when they materially
//! reduce complexity for consumers, not to mirror storage internals or
//! reintroduce lost semantics.
//!
//! - Avoid `HashMap` in DTOs. Keyed semantics and ordering are not preserved at
//! the boundary; use `Vec<...Entry>` or explicit list types instead.
//!
//! In short: stable storage is authoritative; DTOs describe how data is
//! transported, not what guarantees it provides.
///
/// Prelude
///