The claim that git+https goes through libgit2 reading ~/.netrc is wrong
for the pinned Nix. Measured on 2.31.5 with a PATH shim: it runs the git
binary as a subprocess — ls-remote --symref, then fetch into the gitv3
cache, then symbolic-ref.

The consequence is the part that matters. Those fetches resolve
credentials through git own credential chain, so a git credential helper
is a supported route to authenticating a private HTTPS flake input. The
libgit2 story hides that, and a guest with no writable home has no other
way to do it.

Not tested, and stated as untested rather than guessed: whether git also
consults ~/.netrc through curl. The three-file layout stays recorded as
the libvirt path that is known to work.

@@ -25,3 +25,1 @@
-- `/etc/nix/netrc` (640, root:users) - nix daemon via `netrc-file` in nix.conf
-- `/root/.netrc` (600, root:root) - libgit2 when root runs nix
-- `/home/${username}/.netrc` (600, user:users) - libgit2 when the user runs `nix flake update`
+Nix 2.31.5 fetches those by running the **`git` binary as a subprocess**, not through libgit2. Measured with a PATH shim: `git ls-remote --symref <url>`, then `git -C ~/.cache/nix/gitv3/<hash> --git-dir . fetch --force -- <url> <refspec>`, then `symbolic-ref`. So a `git+https://` input authenticates through **git's own credential chain, and a git credential helper is a supported route** — the thing the libgit2 story hides. Whether git additionally consults `~/.netrc` through curl was not tested; do not assume either way.

@@ -86,6 +90,10 @@ Exposing a second system multiplies nothing by default: `nix flake check` skips
 
 Checks that build NixOS fixtures cost the same as a machine, so a framework repo's own check run climbs with fixture count, not machine count: `allod/archetypes` peaks around 5.7 GiB against a 7 GiB box with no swap, and the margin has been measured at ~840 MiB. Hold sabotage fixtures as thunks consumed one at a time rather than a list forced together — keeping a dozen live is an OOM kill, and the difference is over a gigabyte. A fixture that only needs an option value costs far less than one whose `system.build.toplevel` is forced, so force deliberately: forcing is what runs the module assertions, and skipping it is what makes a check vacuous.
 
+**One peak measurement proves nothing about a tree.** The evaluator's collector sizes its heap against the memory the box has free, so peak RSS is a property of the tree *and* the machine's state, anti-correlated with load. Measured on one unchanged check, three consecutive `nix build --no-eval-cache` runs on an idle box: 4.85, 4.38, 3.63 GiB — a 1.2 GiB spread, falling monotonically as the page cache filled. So a single run per tree cannot resolve a half-gigabyte change in either direction, and a before/after comparison built that way is noise. Interleave repeated runs and report the spread, or gate the expensive read behind a flag and compare it against itself. This is the same mechanism as the `GC_MAXIMUM_HEAP_SIZE` warning: free memory acts as an implicit bound, and under a bound the collector simply works harder.