The Gate Got a Lock. Its Best Part Is the Cleanup Code That Isn't There.

I would have written the signal handler. I'd have been proud of it, too: lock file on start, remove it on exit, and if someone hits Ctrl-C (which sends the process a signal, a nudge from the operating system), catch it and clean up. I have shipped that exact shape at two jobs. It would have been wrong here, and a commit this morning shows exactly why.

Some background. The gate is the checklist every change must pass, and pnpm gate:scoped runs it against one checkout (one working copy of the repository on disk). Nothing stopped a second run from starting beside a live one. Issue #2660 quotes two agent sessions that paid for that: one on 24 October "started two more runs that overlapped and clobbered .nuxt and the build lock" (the build's output folder and its own lock, not the one in this story), another on 29 October "started a second gate while the first still ran; both shared a log and build, giving a false EXIT 1." The issue proposed a PID lockfile (a small file holding the number of the process that owns the lock), "git-ignored, inside the checkout". The gate already limited how many heavy runs share one machine, two at a time, to save memory; this was a different guard, for a different collision.

PR #2737, written by an agent like everything here, did it a little better. The lock goes in the checkout's git directory, found with git rev-parse --absolute-git-dir, and a linked worktree (a second checkout of the same repository) has its own git directory. So each worktree gets its own lock, and, per the PR description, "no .gitignore line is needed". If the process in the file is alive, the run exits with "gate already running (pid N) in this checkout"; a dead one is taken over. That's the whole mechanism, a thirteen-line function, and it reuses the probe that checks whether a process is still running the gate already had for that machine-wide limit.

Now the part I'd like you to look at. The PR's first commit, cb64624 (09:37 UTC on 31 October), had my handler: a loop over SIGINT, SIGTERM and SIGHUP that turns each signal into an exit so the cleanup runs, under the comment "A signal skips 'exit' handlers unless it is turned into an exit." Reasonable! The second commit, 4aad69f (09:47 UTC), deleted all of it. Its message: "main() is synchronous, so a JS signal listener only runs after all steps and replaces node's default kill." In plain words: the gate runs its steps in one unbroken stretch of code, so a handler wouldn't get its turn until every step had finished. Ctrl-C would politely wait for the thing you were trying to cancel. What replaced the loop is a two-line comment, and the PR description owns up to the departure from the agent's instructions: "This departs from the brief's 'remove on signal'."

So, anxious math: ten minutes, one handler, and the version I'd have been pleased with makes Ctrl-C wait out the whole gate. A killed run now leaves a stale file behind, and the next run shrugs and takes it over, which is the better design and came from deleting code. What keeps me up is the unit test. It has three cases (live holder, dead holder, no file) for the small decision function, and nothing in it notices if a handler comes back. The only thing standing between the next helpful afternoon and a gate that ignores Ctrl-C is a comment. I've watched comments lose that fight.