JournalDAY 99 / X

FIELD NOTE / X

Two worktrees share one staging tenant.

The short film, the complete written thought, and the evidence behind it.

Journal September 28, 2026 · X target January 4, 2027
Open the approved MP4 ↗

The X conversation link will follow its public release.

Two worktrees share one staging tenant.

Video caption

Two worktrees share one staging tenant. The evidence environment may move during acceptance. Lease shared resources and reject stale evidence. Narration uses Eric's authorized AI voice clone. #EricFieldNotes

Full written post / accessibility read

Give two agents separate Git worktrees and their file changes stop colliding. Good. Both may still use the same staging database, cloud project or browser account. One agent's tests can pass against a fixture the other changes a moment later.

Suppose worker A tests a tenant rule at version twelve. Worker B then updates the same fixture to version thirteen before A deploys. A's test log is real, but it no longer certifies the target state A will use. The WAL needs the external version, not just commit SHA.

At test start and verdict, capture the external resource version. Acquire a lease or separate tenant when possible. If versions differ, invalidate the verdict and rerun the protected test. Track who owns credentials and merge decisions in the same handoff packet.

Keep worktrees for file safety, but treat databases, cloud projects and browser sessions as separately owned resources. Verify the resource version at the effect gate. Do this because green tests tied only to a branch can be true at the wrong moment.

Narration uses Eric's authorized AI voice clone.

#EricFieldNotes

Four-beat scene transcript

1. Two worktrees share one staging tenant.

Give two agents separate Git worktrees and their file changes stop colliding. Good. Both may still use the same staging database, cloud project or browser account. One agent's tests can pass against a fixture the other changes a moment later.

Visual: Clean files do not isolate external state.

2. A local green verdict can expire.

Suppose worker A tests a tenant rule at version twelve. Worker B then updates the same fixture to version thirteen before A deploys. A's test log is real, but it no longer certifies the target state A will use. The WAL needs the external version, not just commit SHA.

Visual: The evidence environment may move during acceptance.

3. Bind evidence to the target.

At test start and verdict, capture the external resource version. Acquire a lease or separate tenant when possible. If versions differ, invalidate the verdict and rerun the protected test. Track who owns credentials and merge decisions in the same handoff packet.

Visual: Record task, source SHA, target ID and target version.

4. Isolate the effect path too.

Keep worktrees for file safety, but treat databases, cloud projects and browser sessions as separately owned resources. Verify the resource version at the effect gate. Do this because green tests tied only to a branch can be true at the wrong moment.

Visual: Lease shared resources and reject stale evidence.

Research and claim limits

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.

More notes from the work ↗