tests: repos sweep health suite fails locally (6 tests, sweep_run returns 1)

[solomonneas]

What

tests/test_repos_sweep_health_cmd.py fails locally with 6 failures. All are repos_cmd.sweep_run(...) returning 1 instead of 0 inside isolated tmp_path fixtures.

FAILED test_repos_sweep_plan_filters_disabled_stale_and_cli
FAILED test_repos_sweep_run_writes_receipts_logs_show_closeout_and_privacy
FAILED test_repos_sweep_failed_repo_does_not_block_other_repo
FAILED test_repos_sweep_runs_configured_read_only_health_commands
FAILED test_repos_health_command_registry_labels_timeouts_receipts_and_report
FAILED test_repos_sweep_integrates_with_report_center_work_and_release
6 failed, 4218 passed, 3 skipped in 523.96s

Representative assertion:

>       assert repos_cmd.sweep_run(target=tmp_path, repo_ids=["alpha"], json_output=True) == 0
E       AssertionError: assert 1 == 0
tests/test_repos_sweep_health_cmd.py:149

sweep_plan succeeds repeatedly in the same tests; only sweep_run fails. sweep_run is the step that actually executes the configured health command (center-report-build), so the failure is in command execution, not planning.

Repro

.venv/bin/pytest tests/test_repos_sweep_health_cmd.py -q --no-cov

Reproduces on a clean checkout of main with no working-tree changes.

Ruled out

• Not tests: repos sweep health suite fails locally when git init defaults to master #330. That was init.defaultBranch defaulting to master. The fixture now pins git init -b main explicitly, and the comment documenting that guard is still in place.
• Not BRIGADE_CLAUDE_SESSION leaking into the test environment. Fails identically with and without the variable set.
• Not caused by uncommitted work. Same failures on a checkout without local changes.

Timing note

The full suite passed twice earlier the same day (two ./scripts/verify runs, exit 0, 4218 passed) and then began failing roughly seven hours later on the same machine with no intervening source change to this module. That points at environment- or state-dependence in what sweep_run shells out to, rather than a code regression, but the trigger is not yet isolated.

Impact

./scripts/verify is the documented Definition of Done gate. While this fails, every local completion check fails, and agents following AGENTS.md cannot report a green gate for unrelated work.

[solomonneas]

Additional data: this does not reproduce in CI. PR #543 ran the full matrix on a branch off current main and test (3.10) and test (3.11) both passed, along with every other job.

That narrows it to a local-environment or local-state dependence on the affected machine rather than a code defect in sweep_run. Whatever sweep_run shells out to behaves differently there than on a clean CI runner - candidate causes are PATH resolution picking up a different brigade binary, a timeout under load, or leftover state in the developer's environment.

Anyone picking this up should first confirm whether it reproduces on their machine at all before digging into the execution path.

[solomonneas]

Second clean environment confirms it: on another fleet machine, same main checkout, fresh venv (pytest 9.1.1 / ruff 0.16.0 / mypy 2.3.0), the suite passes:

$ ./.venv/bin/pytest tests/test_repos_sweep_health_cmd.py -q --no-cov
.........                                    [100%]
9 passed in 10.37s

So: CI passes, a second machine passes, and only the original machine fails. This is machine-local state, not a code defect. Retitling/downscoping may be appropriate - it does not block other contributors and should not be treated as a release blocker.

Next diagnostic on the affected machine: compare which brigade binary sweep_run resolves from PATH during the test versus the one on the developer's interactive PATH, since the fixture shells out to brigade center report build.