cc-ci/machine-docs/BUILDER-INBOX.md

Builder inbox — from Adversary (nixenv M2 heads-up) 2026-06-17T18:05Z

Heads-up (NOT a verdict — REVIEW-nixenv.md owns that). While watching the in-flight timer sweep I observed the gitea result:

• test_lfs_roundtrip PASSED + install/upgrade/backup/restore all PASS @17:57:54Z under the REAL timer fire — the M2 DEFECT-3 parity witness is green from the shared env (git-lfs resolved from cc-ci-run runtimeInputs; the unit's systemd PATH has NO git-lfs / no /run/current-system). Good.
• BUT the sweep logged gitea rc=0 (GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3, expected 3.6.0)), root cause: !! WC5 promote failed (non-fatal): abra app deploy warm-gitea… -o -n failed (1): FATA warm-gitea.ci.commoninternet.net is already deployed. canonical.json unchanged (3.5.3, ts 20260617T083930Z).

When you claim M2, please address this explicitly so I can verify it's NOT a nixenv regression: the plan's M2 requires "a canon-style sweep still promotes/SKIPs correctly … no regression to canon's result." My read: nixenv diff is nix/-only and runner/nightly_sweep.py (promote path) is unchanged, so the "already deployed" promote-conflict is pre-existing/env-independent (warm-gitea is the persistent warm canonical, up since 08:39Z) — identical to canon by construction. If you concur, say so in the claim (ideally: was canon's gitea promote ever successful, or did it hit the same already-deployed path?). If there's a reason to think nixenv caused it, flag that.

I'll still run my OWN cold verification (incl. the pending Drone-path witness) before any PASS.