internal/core/implement/loop outruns even the unit stage's new 40-minute package budget on this Mac: its 505 tests run one after another in one test binary, and on 2026-10-25 a preflight killed it at 40m00s with no test hung (the test running at the alarm was three seconds old), after a gated run of the package alone took 3590s at a load of about 13. The time is spread across the suite, not in a few tests: the ten slowest are 17% of it and the median test takes 4.4s, so no single fix shortens it. On CI's dedicated macOS runner the same package takes 1830s under -race, 76% of that budget. Almost every test sets HOME and git's environment through t.Setenv in the shared git fixture (gittest.NewRepo), and the production code reads them from the process, so the tests cannot run in parallel without threading the environment through about 30 to 40 files.

internal/core/implement/loop outruns even the unit stage's new 40-minute package budget on this Mac: its 505 tests run one after another in one test binary, and on 2026-10-25 a preflight killed it at 40m00s with no test hung (the test running at the alarm was three seconds old), after a gated run of the package alone took 3590s at a load of about 13. The time is spread across the suite, not in a few tests: the ten slowest are 17% of it and the median test takes 4.4s, so no single fix shortens it. On CI's dedicated macOS runner the same package takes 1830s under -race, 76% of that budget. Almost every test sets HOME and git's environment through t.Setenv in the shared git fixture (gittest.NewRepo), and the production code reads them from the process, so the tests cannot run in parallel without threading the environment through about 30 to 40 files.

Grounds

• pursued: each sharded package's processes fit the 40-minute budget at the load two preflights put on this Mac; shown wrong by a preflight that kills a shard at 40 minutes with no test hung