Dispatched worker edited the MAIN checkout instead of its assigned worktree: brief #123 (PR-7) worker in wt1 made ALL edits at /Users/mikeferrara/Documents/code/flower (MAIN) via absolute paths, polluting master's tree; wt1 stayed empty. Caught by the pre-merge tree-clean guard.

Dispatch request #71 (#123, claude, branch flower/123-pr7-room-brief-nav, worktree wt1/proj 55). Over ~16min the worker resolved every file path to the MAIN project root and edited ~/Documents/code/flower/... (absolute MAIN paths) — its wt1 working tree stayed clean and its branch got zero commits. The #120 (foundation) and #184 (backend) workers in the same wave used their worktrees correctly (relative paths / cd into worktree), so the behavior is NON-DETERMINISTIC. Likely trigger: the dispatch packet advertises "project: flower (/Users/mikeferrara/Documents/code/flower)" = MAIN's path, and this worker took that literally. Recovery: killed the worker, git-stashed the MAIN leak (recoverable), merged #120 cleanly, re-dispatching #123 with an explicit worktree-pin in the kickoff. Suggested fixes: (1) the dispatch packet should prominently carry the WORKTREE path as the working dir, not (only) MAIN's project root; (2) the kickoff/packet should explicitly say "work only in your cwd worktree; never edit MAIN"; (3) consider a post-dispatch guard that warns if a worktree-targeted dispatch produced edits under MAIN. Directly related to #184 (worktree env prep at spawn).

{
    "tool": "brief_dispatch",
    "brief": 123,
    "request": 71,
    "observed": "worker edited MAIN not worktree; wt1 empty; branch 0 commits",
    "recovery": "stashed leak, merged #120 clean, re-dispatching with worktree pin",
    "worktree": "wt1/proj55"
}

created

1d ago

triaged

—

resolved

—

resolved by

—