7446ce0293
The unit tests pin the enumerator's sequence in isolation; this pins that the real PlayoutBuilder actually distributes by weight, through the whole chain: MultiCollection -> MediaCollectionRepository -> CollectionWithItems.Weight -> ShuffleSourceBuilder -> WeightedShuffleCollectionEnumerator -> PlayoutItems. The fixture is deliberately lopsided: the HEAVY source (weight 3) is the SMALL collection (2 items) and the LIGHT source (weight 1) is the LARGE one (4). Over the pinned 2-day window that yields 81 : 27 = exactly 3.00 : 1 — the smaller collection taking the larger share, which is the entire point of the feature and is not reachable by any existing order: Shuffle is size-proportional (~2:4 here) and ShuffleInOrder plays every item exactly once per cycle. Longest consecutive same-source run is 3, so it interleaves smoothly rather than draining blocks. Same determinism contract as Classic_shuffle: pinned Playout.Seed + Continue mode (Reset randomizes the seed). Channel number/GUID 5 — every golden fixture shares one in-memory DB, so those must be globally unique. The net is armed, not decorative: with the golden absent the test fails (missing golden is a hard failure by design), and regenerating added only classic-weighted — the three existing goldens are byte-identical, so nothing was silently re-baselined. Core.Tests 566 passed, 0 failed. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>