You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The canonical human benchmark does not currently enforce its “exactly one first completed human attempt per map” invariant across concurrent processes. Map selection, attempt numbering, first-completion classification, and persistence are each derived from a fresh filesystem snapshot, but there is no lock or other single-writer boundary covering the read/decide/write sequence.
Two benchmark processes can therefore select the same still-unplayed map, both complete it, both observe no earlier completed attempt during finalize_attempt(), and both persist is_first_completed_attempt: true for the same map.
Why This Matters
The repository treats the first completed human attempt on each of the 17 reserved maps as immutable canonical evidence and uses that sample as the prerequisite for the Phase 1 human-relative gate. Duplicate canonical first attempts would make the benchmark ambiguous and could require manual adjudication after evidence has already been collected.
This is especially relevant while #12 is actively completing the remaining 16 canonical maps: accidental duplicate terminals/processes should not be able to violate the benchmark’s defining invariant.
Evidence
tools/human_benchmark.py::execute() loads all attempts, selects an unplayed map from that snapshot, creates a started attempt, and persists it without reserving the map against another process.
make_started_attempt() derives attempt_number from the caller’s previously loaded attempt list; concurrent starts can therefore derive the same logical attempt number for one map.
finalize_attempt() reloads attempts and sets is_first_completed_attempt = not earlier, but the check and subsequent persist_attempt() are not protected by any lock/transaction. Two processes can both perform the check before either completed record becomes visible.
persist_attempt() atomically replaces one attempt JSON file, but atomicity is only per file; it does not protect the cross-file invariant that at most one completed human attempt per map is canonical-first.
docs/human-benchmark.md states that the first completed attempt is the canonical statistic for each map and that completed first attempts are immutable evidence.
Make canonical human-benchmark registration single-writer for the operations that determine map eligibility, attempt numbering, and first-completed status. A second concurrent process must either select a different eligible map or fail clearly before it can create conflicting canonical evidence.
The implementation may use a repository-local/file-system lock or another simple mechanism appropriate to this local benchmark workflow, but the protected critical section must cover the invariant-defining read/decision/write operations rather than only individual file writes.
Definition of Done
Two concurrent ordinary human-benchmark processes cannot reserve the same unplayed map as independent canonical first-attempt sessions.
At most one completed human attempt per map can ever be persisted with is_first_completed_attempt: true through the maintained workflow.
Attempt numbering for a map remains unique/monotonic under concurrent starts or replays.
Lock acquisition/recovery has clear behavior for interruption or a stale process and does not silently discard an already-recorded attempt.
Regression coverage exercises a simulated concurrent or interleaved first-attempt race and proves that conflicting canonical-first records cannot be produced.
The maintained documentation states the single-writer/concurrency guarantee for canonical benchmark collection.
Constraints / Non-Goals
This issue does not change the 17-map pool, first-completed-attempt rule, benchmark UI, statistical gate, or immutable evidence semantics. It does not require a database or network service; a minimal local coordination mechanism is sufficient if it robustly protects the canonical registry invariant.
Validation
Use a temporary benchmark output root and deliberately interleave two workers against the same initially unplayed map. Verify that only one worker can claim/persist the canonical first completion and that the resulting registry and rebuilt summary contain exactly one is_first_completed_attempt: true record for that map.
Audit Priority: P2
Audit Type: FIX
Problem / Opportunity
The canonical human benchmark does not currently enforce its “exactly one first completed human attempt per map” invariant across concurrent processes. Map selection, attempt numbering, first-completion classification, and persistence are each derived from a fresh filesystem snapshot, but there is no lock or other single-writer boundary covering the read/decide/write sequence.
Two benchmark processes can therefore select the same still-unplayed map, both complete it, both observe no earlier completed attempt during
finalize_attempt(), and both persistis_first_completed_attempt: truefor the same map.Why This Matters
The repository treats the first completed human attempt on each of the 17 reserved maps as immutable canonical evidence and uses that sample as the prerequisite for the Phase 1 human-relative gate. Duplicate canonical first attempts would make the benchmark ambiguous and could require manual adjudication after evidence has already been collected.
This is especially relevant while #12 is actively completing the remaining 16 canonical maps: accidental duplicate terminals/processes should not be able to violate the benchmark’s defining invariant.
Evidence
tools/human_benchmark.py::execute()loads all attempts, selects an unplayed map from that snapshot, creates a started attempt, and persists it without reserving the map against another process.make_started_attempt()derivesattempt_numberfrom the caller’s previously loaded attempt list; concurrent starts can therefore derive the same logical attempt number for one map.finalize_attempt()reloads attempts and setsis_first_completed_attempt = not earlier, but the check and subsequentpersist_attempt()are not protected by any lock/transaction. Two processes can both perform the check before either completed record becomes visible.persist_attempt()atomically replaces one attempt JSON file, but atomicity is only per file; it does not protect the cross-file invariant that at most one completed human attempt per map is canonical-first.docs/human-benchmark.mdstates that the first completed attempt is the canonical statistic for each map and that completed first attempts are immutable evidence.Proposed Outcome
Make canonical human-benchmark registration single-writer for the operations that determine map eligibility, attempt numbering, and first-completed status. A second concurrent process must either select a different eligible map or fail clearly before it can create conflicting canonical evidence.
The implementation may use a repository-local/file-system lock or another simple mechanism appropriate to this local benchmark workflow, but the protected critical section must cover the invariant-defining read/decision/write operations rather than only individual file writes.
Definition of Done
is_first_completed_attempt: truethrough the maintained workflow.Constraints / Non-Goals
This issue does not change the 17-map pool, first-completed-attempt rule, benchmark UI, statistical gate, or immutable evidence semantics. It does not require a database or network service; a minimal local coordination mechanism is sufficient if it robustly protects the canonical registry invariant.
Validation
Use a temporary benchmark output root and deliberately interleave two workers against the same initially unplayed map. Verify that only one worker can claim/persist the canonical first completion and that the resulting registry and rebuilt summary contain exactly one
is_first_completed_attempt: truerecord for that map.