fix(fix-swarm): scope git add to owned files instead of sweeping worktree debris - #80
Open
jeffhamons wants to merge 2 commits into
Open
Conversation
…bris Lane checks that run pytest were recording FAIL in ringer runs but passing on manual reruns of the same verify command. Traced to fix-swarm.py's unconditional `git add -A`: it stages ANY file present in the task worktree, not just the agent's actual diff, so the owned-files gate then flags incidental debris as an unauthorized change and fails the whole check even though verify (pytest) passed. Confirmed two debris sources via reproduction against the real 2026-07-19 sprint-wave-3/4 task worktrees: - w3-4598-wallclock: fresh pytest-of-<user>/ basetemp junk. The worker engine (opencode) runs pytest under a sandbox that returns EPERM on writes to ~/.jeff-os/_test_isolation/ and the system temp dirs; Python's tempfile falls through to cwd (the task worktree) as a last resort, leaving pytest-of-.../pytest-N/ debris behind. - w4-2369-refresh: a stale, unrelated .jeff-os/state/argus/checkpoint.json dated May 14 -- 2+ months old, sitting untracked in the worktree from setup, first swept in by this run's git add -A. Fix: unless owned-files is the wildcard "*", stage with `git add -u` (tracked-file modifications only, so an out-of-lane edit to an existing file still trips outside_owned_files) plus `git add -- <owned paths that exist>` for new files under the declared lane. Untracked debris outside the lane is never staged, so it's never flagged. Verified against both task worktrees: checks now PASS with the debris still present, and a synthetic out-of-lane edit to a tracked file still correctly fails outside_owned_files. Ringer's own check-subprocess env (_run_check, ringer.py:6766) was investigated and ruled out -- not the cause.
tests/test_contributors.py audits every author in the branch history against `## Contributors`, so any first-time contributor's PR is red until the line lands. Adding it here rather than leaving a red required check for you to interpret. Identical text on both my open PRs (NateBJones-Projects#79, NateBJones-Projects#80) so the second resolves trivially once the first merges — drop the commit if you would rather add credit at merge time.
jeffhamons
added a commit
to jeffhamons/ringer
that referenced
this pull request
Jul 27, 2026
tests/test_contributors.py audits every author in the branch history against `## Contributors`, so any first-time contributor's PR is red until the line lands. Adding it here rather than leaving a red required check for you to interpret. Identical text on both my open PRs (NateBJones-Projects#79, NateBJones-Projects#80) so the second resolves trivially once the first merges — drop the commit if you would rather add credit at merge time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The fix-swarm check stages a worker's result with
git add -A. That sweeps in whatever untracked debris the worker and check subprocesses happened to leave in the worktree — in my case a sandboxedpytestrun falling back to cwd for itsbasetemp— so the task's commit contains files the task never claimed and nobody reviewed.The fix
owned_files == ["*"]keepsgit add -A. A task that declares it owns everything means it.git add -uto catch modifications and deletions of already-tracked files, plus the declared owned paths explicitly.git add -- <path>hard-fails with "did not match any files" for a declared-but-untouched owned path — which would turn an honest partial result into a check error.Proof
Full suite on macOS (Python 3.14), rebased on current
main(2c2b599): 218 of 218 pass.Overlap
#56 (Preserve fix-swarm patches across retries) touches the same file. These are independent changes — patch preservation across retries versus what gets staged — but they will conflict textually. I am happy to rebase onto whichever lands first; no need to hold either on my account.
Motivation
This one is from a live regression rather than a hypothetical: the fix rode on my local
mainfrom 2026-07-19, a sync reset the branch, and every fix-swarm run for the following eight days silently went back toadd -Abefore I caught it.Update: the README credit line is now a second commit on this branch, so the suite is fully green. The same line is on #79 and #80 — identical text, so whichever merges second resolves trivially. Drop the commit if you would rather handle credit yourself.