[kixelated]

Problem

A benchmark harness on a shared host can't keep other work off the host while it measures. Two sessions ran rind's admin/bench-report collect against the same host at once. The second wiped the first's build mid-compile, and gated cargo builds from other agents ran alongside the benchmarks, skewing about half the timings by over 10%. Load-based admission let all of it in.

Behavior

quest gate --host <command> holds the whole host:

• It records a reservation (host: true, held by its gate's process) at once, so no other caller is admitted while it waits.
• It starts once every gated command already running has ended, regardless of load and memory.
• Until it ends, every other gated command waits, quick and priority ones included, and a second --host caller queues behind it.
• A dead holder releases the host. Every admission now records its gate's start time as well as its PID (Linux: boot ID and start ticks; macOS: ps -o lstart in UTC), so a reused PID, as after a reboot, holds nothing.
• --host conflicts with --quick, and Windows refuses it, since it has no cheap start time to tell a reused PID from a holder. A nested --host runs at once, like any nested call.

Validation

• just check and just test pass.
• New tests cover the reservation: ordinary, quick (past its deadline), priority, and --host callers all wait on it; the holder waits out a running build and is then admitted; a dead holder, or one whose PID was reused, holds no one; a holder doesn't wait on an ordinary admission whose PID was reused; Windows refuses --host.
• On kixtop (macOS), the same process's ps -o lstart differed between time zones and locales, which the fixed TZ=UTC LC_ALL=C removes.
• End to end on one host, with two concurrent --host commands and a --quick one: the second and the quick one waited until the first ended, then ran one at a time.

Limitations

• Only gated work is held off; the command should still check for load from outside the gate.
• A gate from an older Quest on the same host ignores the reservation (it keeps the entry intact when it publishes).
• While held, a land check's priority gates on that host also wait.

Review

Codex (gpt-6.1-sol, medium), 4 rounds; round 4 on head 07124a9 reported no findings.

• Round 1: a host reservation trusted PID existence, so a reused PID could hold the host for good. Fixed: reservations record the gate's start time.
• Round 2: Windows reservations stayed PID-only. Fixed: Windows refuses --host. macOS ps -o lstart depended on the caller's time zone and locale. Fixed: TZ=UTC LC_ALL=C.
• Round 3: a holder still waited on ordinary admissions checked only by PID. Fixed: every admission records its gate's start time.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[pullfrog]

  ^{｜ Review this ➔}

[kixelated]

Automated review by review (OpenAI)

Reviewed head: 07124a9

[P2] Fail closed when macOS process inspection fails — src/cli/gate.ts:291–295. If spawnSync("/bin/ps", ...) fails, for example with EAGAIN or ENOMEM, this returns undefined just as it does for a missing process. For a live holder with a recorded start time, fileHost.running() then returns false, so another caller can be admitted alongside it. Once the reservation is older than RECENT_MS, that caller can also remove it from the ledger. A failed self-inspection instead creates a PID-only reservation.

Propagate spawn errors and distinguish inspection failure from confirmed process exit; require a usable start identity before granting --host. Add a regression test with a live holder and a failed ps invocation, asserting that no competing admission is published.

Recommendation: address this isolation failure before merging. Scope: static review of all five changed files and surrounding admission/ownership logic through GitHub only. I did not run tests or reproduce the macOS failure; CI was still in progress when checked.

(Written by OpenAI)