---
name: pool-refusal-tail-reads-as-release-confirmation
description: The releases#103 pool blurb is the LAST line of a SPT_POOL_FOREIGN refusal too, so a tail-read of pool-release turns four failed builds into four apparent successes.
metadata:
  type: feedback
---

`cargo run -p xtask -- pool-release --pool <dir>` read through `tail -2` printed:

    Two trees sharing one pool overwrite each other's artifacts; that is how a
    red belonging to neither tree gets fabricated (releases#103).

That sentence reads as a release confirmation. It is not. It is the closing
blurb of a **`SPT_POOL_FOREIGN` build refusal** — the xtask binary never built,
so the verb never fired. I ran it for four pools and got four identical
"confirmations"; all four POOL-OWNER.json files were still on disk with their
original mtimes. Measured 2026-08-21, PORTER wave-3 teardown.

**The blurb is the tail of MORE THAN ONE outcome, so the tail cannot
discriminate between them.** The verdict token is at the TOP of the output.
Read the head, or the whole thing — never `tail` a command whose success and
failure share a trailer.

Two compounding facts that make this bite:
- `pool-release`/`pool-claim` are themselves *built through the pool*, so a
  foreign claim on a tree's own `target/` makes the release tool unreachable
  from that tree — the fix for a bad claim is blocked by the bad claim.
- The claim can outlive its worktree: the root pool here was owned by
  `.worktrees/gate-204`, a tree no longer in `git worktree list`.

If you are reaping the pool anyway, skip `pool-release` entirely — deleting the
`target/` subtree takes `POOL-OWNER.json` with it and the claim dies with it.

Related: [[dont-take-a-diagnosis-as-measured]] ·
[[delivery-confirmation-is-a-claim-too]] · [[pipe-verdict-traps]] ·
[[open-the-subindex-before-running-a-gate]]