---
name: pool-claim-writes-a-record-the-build-enforces
description: "`xtask pool-claim` never reads the incumbent — it is last-writer-wins. The refuse/takeover verdict lives in the BUILD guard, so predicting a refusal from the claim verb is predicting from the wrong code."
metadata: 
  node_type: memory
  type: project
  originSessionId: 1e15e6ca-6830-40c8-b051-25a9b1850b5c
  modified: 2026-08-19T01:10:35.506Z
---

Measured by source read (main checkout, 2026-08-19): `pool_claim`
(`crates/xtask/src/main.rs:2232-2294`) parses its flags, reads its OWN lane
identity (`symbolic-ref` branch + `rev-parse HEAD` base, :2260-2261), builds a
`PoolOwner` and calls `write_owner` **unconditionally** (:2280), then prints its
success line. There is no `read_owner`, no verdict, no base-vs-tip comparison,
no branch on the existing claim. `base` is RECORDED, never evaluated there.

The enforcement is at BUILD time: `crates/spt-store/build.rs:31-113` consumes
`spt_poolguard::Verdict` and holds all four arms — `Refuse` (the
`SPT_POOL_FOREIGN` hard stop, :100), `Takeover` (loud, "taking it over:
{reason}", :58-66), `Unproven` (proceeds, no takeover), `HatchOpen` (the
announced override). That is where "an unlanded lane refuses, a finished lane is
taken over loudly" is real.

So a claim protects nothing on its own: two lanes can each hold the pool in
sequence with only the last write surviving, and the losing lane learns nothing
until its next build. Observed three times in one session — my own third claim
silently overwrote my second while that lane had an unlanded commit, and a
peer's gate claim later overwrote mine with no notice on either side.

**Why:** AGENTS.md's refusal sentence sits directly under the "Claim a pool at
lane start with `xtask pool-claim ...`" instruction, so the refusal reads as a
property of the CLAIM verb. I warned a gater mid-run that his claim "will be
REFUSED" on that model; one read of `POOL-OWNER.json` refuted me, and the source
read showed the predicate I cited does not exist in that command at all.

**How to apply:** never predict a tool's refusal from prose — the prediction is a
claim about a FILE and a code path, so read both before telling a peer. When a
pool question comes up: `POOL-OWNER.json` answers who holds it NOW, and only a
BUILD answers what happens next. Kin:
[[lane-check-via-main-pool-prebuilt-xtask]],
[[pool-claim-holder-death-is-not-lane-state]],
[[name-the-file-and-sha-a-condition-came-from]].