claim(M2-nixenv): live parity proven on BOTH paths — gitea test_lfs_roundtrip green under the real timer fire (@17:57:54Z, git-lfs from cc-ci-run runtimeInputs; unit PATH has no git-lfs) AND the Drone path (build #871, RECIPE=gitea REF=357926f2 PR=1). Deploy d11f8f5 healthy post-sweep (systemctl --failed empty, timer+oneshots active, endpoints 200). No regression: sweep SKIPs/promotes correct; gitea promote-fail + discourse/mattermost reds all pre-existing (identical pre-deploy, runner/ unchanged since canon f94de22). Awaiting Adversary.

machine-docs/JOURNAL-nixenv.md

@@ -57,3 +57,32 @@ additions override cleanly. Both `#cc-ci` and `#cc-ci-hetzner` built with no col
 - sweep wrapper `gh02w1kc…` execs the SAME `zxlx9j…/bin/cc-ci-run`.
 - cc-ci host sw/bin now lists git-lfs + openssl (was missing git-lfs pre-refactor).
 - `grep -rn withPackages nix/` → 1 hit (packages.nix:17).
+
+## 2026-06-17T18:17Z — M2 claim (both live parity witnesses green)
+
+### Drone-path witness (build #871)
+Why REF=357926f2 PR=1 SRC=recipe-maintainers/gitea: this is the lfs-plain-gitea capstone ref (the
+gtea-phase Build #685 ref). PR #1 is now merged so compose.lfs.yml is also on main, but pinning the
+PR head guarantees `_lfs_enabled()` is true (compose.lfs.yml in checkout + RECIPE=gitea) so the LFS
+test RUNS rather than skips. fetch_recipe takes the SRC+REF mirror-clone path; EXTRA_ENV adds
+compose.lfs.yml to install+custom tiers so the deployed gitea has LFS on for the round-trip. Triggered
+via the Drone API with the bridge's drone token (kept on-host). Build went green in ~3 min;
+test_lfs_roundtrip PASSED. This is the SAME cc-ci-run store path the timer sweep execs, so the two
+witnesses prove parity by both construction (M1) and observation (M2).
+
+### Why the timer fire is the harder witness
+The systemd unit PATH is systemd-minimal (coreutils/findutils/gnugrep/gnused/systemd) — NO git-lfs,
+NO /run/current-system/sw/bin. So a green LFS test there can ONLY come from cc-ci-run's runtimeInputs
+prepending git-lfs-3.6.1 to PATH. Confirmed by reading /proc/<run_recipe_ci pid>/environ live: PATH
+starts with the cc-ci-run tool prefix incl git-lfs. This is exactly the DEFECT-3 condition the phase
+set out to make structurally impossible.
+
+### GREEN-BUT-PROMOTE-FAILED is not mine
+Spent effort confirming the gitea promote-fail (`abra app deploy warm-gitea -o -n` → "already
+deployed") is pre-existing: it appears identically in the two pre-deploy sweep fires (14:28Z, 15:56Z,
+OLD env) and the promote path (runner/nightly_sweep.py) is unchanged by nixenv (last touched canon
+f94de22). It's an abra deploy-idempotency limitation on the persistent warm canonical (warm-gitea up
+since 08:39Z), non-fatal, known-good unchanged. discourse/mattermost-lts reds are likewise recipe-level
+and pre-existing (mattermost: postgres restore marker assertion; docker resolved fine → not a dropped
+tool). nixenv changes only WHICH tools are on PATH; it dropped nothing (M1 superset proof), so it
+cannot have caused an app-level red.