mill gives its own clones no git identity

[slowernet]

Mill::Repo.prepare writes gc.auto and maintenance.auto to the clone (repo.rb:71) and no identity. git clone copies no config, so a clone has no identity of its own. Stages commit inside worktrees of that clone, and prompts/implement.md tells the implement stage to make a commit per task.

On a server whose account has no ~/.gitconfig — the ubuntu-latest shape mill's own CI runs on, and the deployment target the design doc describes — that first commit fails, the stage is charged a strike, and the run burns its attempts on something the machine did to it. Nothing tests this and Mill::Doctor does not check it.

Decided 2026-08-20, written up in the design doc under "Setting up, and preparing a repo". You are the author and mill is the committer, named mill at the author's address, set through GIT_COMMITTER_NAME/GIT_COMMITTER_EMAIL in Mill::Rules.env_for (rules.rb:89). It is mill's own setting, not a .mill.yml key, because that file lives in the repo being worked on and its base branch would decide what name your credentials push under. Unset, the author falls back to the machine's git config, so a laptop needs nothing.

Not implemented. Needs: Repo.prepare writing the identity beside gc.auto (repo.rb:72), the two committer variables in env_for, a doctor check that fails when nothing resolves, and a test that a prepared clone commits with the right author and committer.

Every commit mill has made so far is authored as the operator, indistinguishable in git log and git blame from work typed by hand.

Context: docs/notes/2026-08-20-plan-3a-review-triage.md, blocker zero.

[slowernet]

Core implementation merged as 5e6966e (reviewed in place: verdict keep). Author = operator, committer = mill at the author's address, doctor check via git var GIT_AUTHOR_IDENT. Suite green at 582.

FIX-FORWARD, in order, before this closes:

1. (HIGH) The two "machine config" reads (rules.rb:95, doctor.rb:231) run git -C ~/.mill, and git walks UP — if $HOME is a dotfiles repo, its repo-local identity answers for the machine (measured), so the stage's committer address diverges from the copied author address, and doctor reports a third thing. Fix: GIT_CEILING_DIRECTORIES=$HOME on those reads (needs a small env parameter on Mill::Git.run, keeping it inside the one module allowed to run git), and rewrite the comment at rules.rb:89-92 — it currently describes the bug as the defence.
2. (MEDIUM, closes two findings) identify skips a key when git config --local --get exits 0 — and an empty string exits 0, so a borrowed checkout with user.name = "" passes doctor (which only asks the machine) and dies mid-stage with fatal: empty ident name, the exact strike-shaped failure this issue removes. Also nothing forces doctor to run (Rakefile-only). One fix for both: after copying, prepare verifies git var GIT_AUTHOR_IDENT INSIDE the clone and returns its existing blocking-question shape on failure — blocks one item instead of charging a strike, no doctor required.
3. (LOW) Author freezes at first prepare; committer tracks the live config — they drift if the operator edits ~/.gitconfig later. Decide: committer address from the clone too?
4. (LOW) Design doc: drop the "what a stage can read outside its worktree stops mattering" claim (untrue for the committer on every launch, and for GECOS fallback), and reflow the ragged doctor paragraph at ~1243. Test note: the prepared-clone test only load-tests GIT_COMMITTER_NAME; the address assertion passes vacuously (covered separately in test_rules).

Cleared by review: worktrees see the clone's shared config; boundary discipline clean; test isolation correct in both directions including the GECOS trap (uses user.useConfigOnly, not an empty file).