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
//! Testing scaffolding — in-process multi-node `MeshOsRuntime`
//! harness + bridge probes that wire a real `Mesh` into a real
//! `MeshOsRuntime`'s probe registry.
//!
//! Gated behind the `testing` Cargo feature; consumers opt in via
//! `[dev-dependencies] net-mesh-sdk = { ..., features = ["testing"] }`.
//! Never linked into a release binary.
//!
//! # What's here
//!
//! - [`ClusterHarness`] — boots N `(Mesh, MeshOsDaemonSdk)` pairs
//! on `127.0.0.1:<ephemeral>`, peers every Mesh pair via real
//! UDP handshake, and installs bridge probes so the MeshOS
//! snapshot fold reflects peer state.
//! - [`MeshLocalityProbe`] / [`MeshHealthProbe`] /
//! [`MeshInventoryProbe`] — `LocalityProbe` / `HealthProbe` /
//! `InventoryProbe` impls that read peer state off a `Mesh`.
//! The bridge that closes the substrate's two-layer split:
//! network on one side, MeshOS state fold on the other.
//!
//! # Why this exists
//!
//! See `crates/net/docs/plans/DECK_DEMO_HARNESS_PLAN.md` Phase 0 +
//! Phase 0.5. The short version: `MeshOsRuntime` is a pure
//! in-memory snapshot fold (sdk.rs:643 constructs it with an empty
//! `ProbeRegistry` and no network bind), and `Mesh` is the
//! network. They communicate through probe traits the runtime
//! polls each tick. Without bridge probes, a multi-`MeshOsRuntime`
//! cluster has fully-peered Meshes underneath but every runtime's
//! `snapshot.peers` stays empty.
pub use ;
pub use ;