What happened
2026-09-21, dev@17ae56d34 plus the seven-plus-six commits of #1336 (which touch nothing in the task harness), running the repository's own gate on a laptop while a second full suite and a read-only reviewer were also running:
make pr-ready
…
--- FAIL: TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson (37.55s)
task_divide_sketch_test.go:594: the worker was never stopped for work only a person can do
FAIL
FAIL github.com/Agent-Field/codeaf/internal/session 799.740s
The package took 800 s against the 210 s constrained-runner baseline in CLAUDE.md. CI's touched packages job on the same head passed. The same test on a quiet box:
go test -count=3 -run '^TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson$' ./internal/session/
ok github.com/Agent-Field/codeaf/internal/session 0.879s
So it is the shape CLAUDE.md says is a bug report and not a known one: a session test that fails only when other suites run beside it.
Replication
Deterministic (no model). Run the session suite while another heavy suite runs beside it, on a box with a few cores:
GOMAXPROCS=4 go test -count=1 -timeout 15m ./internal/tui3/ &
GOMAXPROCS=4 go test -count=1 -timeout 15m -run 'TestWork' ./internal/session/
What a developer sees today, some of the time: the --- FAIL above after 30 s of waiting. On a quiet box it passes in well under a second.
Field (real models). Not applicable: this is a test's own wall, no product door.
Where
TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson in internal/session/task_divide_sketch_test.go, and its siblings in the same file: each waits on a channel with case <-time.After(30 * time.Second) (search that string; eight sites). The worker being stopped is real work driven by a held completer (completer.hold); on a loaded box the stop lands after the thirty seconds have gone.
The fix
A test in this package should not lose a race against wall time. Either the wait is on a sync point the harness owns (the held completer's release, the worker's own stop acknowledgement) with no timer at all, or the ceiling is the test's deadline (t.Deadline() minus a margin) rather than a fixed thirty seconds. CLAUDE.md's learned preference already says it: deterministic clocks over real sleeps.
Acceptance
- e2e: not applicable — nothing crosses a product door; the defect is the test's own timer.
- Unit: every wait in
task_divide_sketch_test.go is either a sync point with no timer or bounded by the test deadline; grep -c 'time.After(30' internal/session/task_divide_sketch_test.go is 0.
- Unit: the test passes with
-count=5 while go test ./internal/tui3/ runs beside it on a 4-core box.
- No manual page or change entry is involved.
What happened
2026-09-21,
dev@17ae56d34plus the seven-plus-six commits of #1336 (which touch nothing in the task harness), running the repository's own gate on a laptop while a second full suite and a read-only reviewer were also running:The package took 800 s against the 210 s constrained-runner baseline in CLAUDE.md. CI's
touched packagesjob on the same head passed. The same test on a quiet box:So it is the shape CLAUDE.md says is a bug report and not a known one: a session test that fails only when other suites run beside it.
Replication
Deterministic (no model). Run the session suite while another heavy suite runs beside it, on a box with a few cores:
What a developer sees today, some of the time: the
--- FAILabove after 30 s of waiting. On a quiet box it passes in well under a second.Field (real models). Not applicable: this is a test's own wall, no product door.
Where
TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePersonininternal/session/task_divide_sketch_test.go, and its siblings in the same file: each waits on a channel withcase <-time.After(30 * time.Second)(search that string; eight sites). The worker being stopped is real work driven by a held completer (completer.hold); on a loaded box the stop lands after the thirty seconds have gone.The fix
A test in this package should not lose a race against wall time. Either the wait is on a sync point the harness owns (the held completer's release, the worker's own stop acknowledgement) with no timer at all, or the ceiling is the test's deadline (
t.Deadline()minus a margin) rather than a fixed thirty seconds. CLAUDE.md's learned preference already says it: deterministic clocks over real sleeps.Acceptance
task_divide_sketch_test.gois either a sync point with no timer or bounded by the test deadline;grep -c 'time.After(30' internal/session/task_divide_sketch_test.gois 0.-count=5whilego test ./internal/tui3/runs beside it on a 4-core box.