laptop-untracked-review: bare git commit sweeps pre-staged work into its commits — the junk-ignore commit also lands the newly tracked files and any unrelated staged edit #1751

Problem

laptop-untracked-review.sh commits with bare git commit — no pathspec — at both of its commit sites, so each commit lands everything in the index, not just the files the review itself staged. The daily unattended job therefore sweeps any pre-staged work in the personal primaries (an agent's or Drew's half-finished staged edit) into a commit whose message claims it only ignored junk paths or tracked N new files. Worse, the two commits interact: files the review stages for the second commit are already in the index when the first commit fires, so they land in the wrong commit and the second commit then has nothing to do.

Evidence (verified this run, main 7b87168c)

• nixos/home/laptop-untracked-review.sh:77 — git add -- .gitignore && git commit -q -m "untracked-review: ignore junk paths $DAY": the add is path-scoped, the commit is not.
• nixos/home/laptop-untracked-review.sh:80 — git commit -q -m "untracked-review: track $tracked_new file(s) $DAY": same unscoped commit; and by the time it runs, line 66 has already staged each newly tracked file during the scan loop, so those files are in the index for the line-77 commit whenever any junk file was also found.
• Probe (laptop, ~/git/fleet/probe-2026-10-28-laneB-untracked/; drove the real script, sha256 6c580a69… identical to main, in a fixture HOME whose hatch-personal repo had a pre-staged unrelated edit to tracked.txt, an untracked junk notes.tmp, and an untracked normal newnote.md):
  • Report printed: now tracking: newnote.md, junk ignored: notes.tmp, .gitignore updated — and no "committed 1 newly tracked file(s)" line.
  • git log --stat shows exactly ONE review commit, untracked-review: ignore junk paths 2026-10-28, containing 3 files: .gitignore, newnote.md, and tracked.txt (the pre-staged unrelated edit).
  • The line-80 commit then ran against an empty index: git printed nothing to commit, working tree clean into the job's stdout, the && say never fired, and the report silently omits that its tracking commit never happened.
  • Control shape: with no junk file present, line 77 never runs and line 80 still sweeps any pre-staged changes into the "track N file(s)" commit — the pathspec bug is at both sites independently.

Why it matters

This job runs daily and unattended against ~/.openclaw and ~/hatch-personal — the two repos where agents and Drew most often have work in flight. Primaries are supposed to sit clean on main, but "clean" is a discipline, not a guarantee (the repo-keeper exists precisely because primaries drift), and a staged-but-uncommitted edit is exactly the state a human/agent leaves mid-task. The review converts that state into a pushed-history commit with a false message, mixing unrelated work into a junk-ignore commit where nobody will look for it, and its own report then misdescribes what was committed. House rule for this fleet is surgical staging: stage explicit paths, commit only those paths.

Acceptance criteria

• Both commits are path-scoped (e.g. git commit -m ... -- .gitignore and git commit -m ... -- <the files this run added>), so a pre-staged unrelated change survives a review run still staged and uncommitted.
• The tracking commit contains exactly the files the review added this run, and the report's "committed N newly tracked file(s)" line fires only when that commit actually happened; a nothing-to-commit outcome is not silently swallowed.
• A regression test (fixture repo in the style of the probe: pre-staged edit + junk file + normal untracked file) pins all three outcomes: junk commit = .gitignore only, track commit = the new file only, pre-staged edit still staged afterwards.
• Report lines, secret-shaped and too-big handling, and the public-repo report-only mode are unchanged.

Triage note: the likely fix is pathspec commits plus collecting the tracked file list for the second commit's pathspec; whether the job should also refuse/skip a repo with pre-staged changes (the keeper's BUSY-style guard) is the triage pin — pathspec alone already stops the sweep.