`sweep_orphans` force-removes containers and had never run against a
daemon — only its pure decision logic was covered. The two Docker-touching
seams are exactly the ones worth exercising for real: what it can see, and
whether a checkout holds work no remote has.
Three fixtures, three outcomes, one sweep:
- unpushed commits, no remote ref → SURVIVES
- every commit on a remote ref → reaped
- inside the grace window → survives anyway
Negative-controlled: making `unpushed_commits` return `None` for a dirty
checkout fails with "the probe said a checkout with an unpushed commit
holds nothing — this is the exact answer that destroys work".
Two real hazards the test surfaced, neither of them in the sweep:
1. **The tests raced each other.** The sweep is global — it reaps every
orphaned mission container on the daemon, including fixtures another
test in this file just started. A `FIXTURES` mutex serialises them.
Found the honest way: the reap test deleted the listing test's fixture
and the listing test reported a container it could not see.
2. **The test destroyed real local state.** The sweep asks the DATABASE
whether a container is known, and `test_pool()` knows nothing — so on
a developer machine it classified the live stack's mission containers
as orphans and reaped two of them on the first run. `adopt_existing`
now gives every pre-existing mission container a row before sweeping,
which makes the test safe AND covers the one case the other
assertions missed: a container the platform still knows about is never
touched.
Negative-controlled both ways with a bystander container: without
adoption REAPED, with adoption SURVIVED.
Skips cleanly with no Docker, so a runner without one reports "not run"
rather than failing — the placeholder-as-result shape
`scripts/verify-mission-delivery.sh` was written to avoid.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
