`static_assembly_matches_runtime_capture` walks the capture's parts and looks each up in ours, so an extra static placement was originally invisible to it — that is how `e303_wep_01` sat here decoded 100x too large. `64d372c` closed that with a set-of-names check; BACKLOG.md still says otherwise, and it is wrong. One direction stayed open, though: a set cannot fail on a resource placed *twice* when the capture lists it once. That is not hypothetical — a duplicated instance is what a bad node walk emits, and the two legitimate duplicates here (`e106_eng_01`, `e303_wep_01`) are why the test had to special-case counts at all. So pin the whole multiset — 9 resources, 11 placements, against the capture's 8 dedup'd parts — which subsumes both hand-written counts and fails on an extra, a missing, or a duplicated placement. Refuted before believing: perturbing the expected table (declaring `e106_bdy_01` twice) fails with the real multiset on the left, so the assertion runs against the disc rather than skipping for want of SYLPHEED_ISO. The remaining `for want in &cap.parts` loop guards the table itself: editing it cannot quietly drop a part the runtime actually draws.