---
name: shared-target-two-live-trees
description: Two LIVE source trees sharing one CARGO_TARGET_DIR fabricate evidence in BOTH directions — gate and builder lanes need separate target pools
metadata: 
  node_type: memory
  type: project
  originSessionId: 15112c41-c0e3-4c41-b3d4-dd86175e25af
  modified: 2026-08-02T07:56:02.523Z
---

BAROMETER W1/H1 (2026-08-02): builder worktree and gate worktree both junctioned onto `.worktrees/gate-target` while both trees were live. The gate's `cargo check --tests` compiled against the builder's HALF-BUILT mid-seam spt-live rlib and fabricated an E0308 in `psyche_event_turn_e2e` that vanished on re-run behind the cargo file lock. Symmetric hazard: the builder's test greens during the window raced the gate's writes and were equally untrustworthy.

**Why:** cargo's file lock serializes writes but does not partition artifacts by source tree; whichever tree built a dep last wins the shared slot, so the OTHER tree type-checks against foreign code. "Blocking waiting for file lock on build directory" during a gate leg is the tell that another live tree shares the target — treat any result from that window as fabricated, both colors.

**How to apply:** one warm target pool PER LANE — builder pool and gate pool never the same dir while both trees are live (gate got `.worktrees/gate-target-h1`). On any evidence produced in a shared window: re-run clean before citing. Distinct from [[shared-target-stale-false-green]] (stale binary serving old green); this is cross-tree contamination while both are building. Evidence recorded on releases#103, which builds the enforced policy.