A heavy package run outside make takes no suite lock

Start with Makefile:125-126, scripts/one-suite.sh, and cmd/codeaf-suite-lock to trace how heavy packages enter the locking scheme. Compare the Makefile test path with a direct go test ./internal/session run, then define how an unattended contender waits with a timeout and records wait time. Done means heavy runs cannot proceed unlocked and contention is not reported as a work failure.

The one-suite rule binds make, not the box. scripts/one-suite.sh opens with
the reason the lock exists: nine sessions fired go test ./... at once, the
reds that came out were manufactured by the load, and so "a second run on the
same box refuses to start and says who holds it rather than joining the pile."

A second run started as go test ./internal/session does not refuse. It does
not see the lock, does not take one, and nothing tells it to. It is the same
workload the lock exists to serialise, entered by a door that has no lock on it.

Observed on the box, 2026-09-20T19:25Z

Two heavy runs alive at the same instant, one holding the lock and one not.

The holder, correct in every respect:

• pid 1555853, bin/codeaf-suite-lock --hold-heavy-suite-lock 1555852 302442410,
  cwd /home/santosh/src/trees/sdev-e098ca1fd, holding fd 3 on
  /tmp/codeaf-suite-1001.lockfile.
• Its parent chain is bash /tmp/gate.sh e098ca1fd then make check then
  codeaf-suite-lock /tmp/codeaf-suite-1001.lockfile go test -count=1 -timeout 15m.
  It went through the Makefile, so it took the lock.

Beside it, taking nothing:

• pid 1531326, go test ./internal/session, started 19:21:29Z, 4m20s elapsed at
  the time of reading, a direct child of an ordinary shell.
• It started about forty seconds BEFORE the gate took the lock, so the gate did
  not refuse either: there was nothing to refuse against.

Box load reached 14.52 with both up.

This is not #1307

#1307 is two lock mechanisms that cannot see each other, both of which are
trying to participate. This is a runner that never enters the scheme at all. It
is not failing to cooperate, it has no cooperation to fail at.

The distinction decides what a fix is worth. Every remedy in #1307, dual
checking on the read side and taking both locks in one-suite.sh, could land
tomorrow and this hole would be exactly as open as it is now. A reader of #1307
alone would reasonably conclude the flock closed it.

Put plainly: the lock does not protect the box from every heavy run, only from
the ones that went through make. A lock that binds only the compliant is a
convention with a syscall in it.

The mechanism, from the repo's own files

Makefile:125-126

HEAVY_PKGS := ./... ./internal/tui3 ./internal/tui3/ ./internal/session ./internal/session/
SUITE_LOCK := $(if $(filter $(HEAVY_PKGS),$(PKGS)),./scripts/one-suite.sh)

The lock is selected by the PKGS variable of the test target. scripts/one-suite.sh
says the same thing in prose: "The Makefile invokes this wrapper for a full
make test or test-report when PKGS contains ./..., ./internal/tui3 or
./internal/session."

So the binding is between the MAKE TARGET and the lock. It is not between the
PACKAGE and the lock, and the package is what actually loads the box.

Note that the Makefile already takes the neighbouring risk seriously one level
up. test-focus requires RUN and refuses without it, with the comment "an
omitted selector must not silently turn a focused command into a full package
run." That guards a focused run degrading into a heavy one inside make. It
cannot guard a heavy run that never enters make.

Refusing is the wrong answer for an unattended runner

cmd/codeaf-suite-lock refuses a contender and prints "Wait for it, or run one
named regression with make test-focus." For a person at a terminal that is
right: they read it and retry.

For an unattended runner it converts a scheduling fact into a false negative
about the work. A run that fails because the box was busy is indistinguishable,
in whatever report it writes, from a run that failed because the code is wrong.
That is the shape this repository keeps finding in other places: a single signal
that means two different things.

So whatever closes this should make an unattended contender WAIT, with its own
timeout, and record how long it waited in its report. Never proceed unlocked,
and never fail for contention.

What I am not claiming

I have not shown that the overlap above corrupted any result. Both runs may
finish clean. The claim is only that the box permitted two heavy suites at once
while one of them believed it held exclusivity, which is the state the lock was
written to make impossible.

Related: #1307.