# BUG_REPORT: add-blast-radius-scheduler

Probed worktree creation, fallback, and state consistency against edge cases.

## Bugs found

None blocking. Informational observations below.

## Observations (non-blocking)

### O1 -- Worktree state written before step 10 (idempotence gap)
`_ensure_worktree` calls `_write_state_loop` to record `worktree_path`/`worktree_branch` immediately after worktree creation. If the tick crashes between this point and step 10 (state advance), `iteration_count` is NOT incremented (correct), but `worktree_path` IS set in `.state.loop`. On the next tick, the runner reuses the existing worktree (which exists on disk). This is correct behavior -- the worktree was created, it exists, reusing it is right. The "idempotent in failure" contract from task 3 refers to `iteration_count` and `last_verdict`, not to worktree state. Accepted.

### O2 -- `git worktree add` on a repo with uncommitted changes
`git worktree add` creates a new working tree from the current HEAD. It does not require a clean working tree in the main checkout. So this is fine -- the worktree gets a clean copy of HEAD. No issue.

### O3 -- Worktree path collides with existing directory
If `<loop_path>/worktree` already exists as a non-git directory (e.g. the user manually created it), `git worktree add` will fail with "already exists". The runner falls back to project root. The user would need to remove the directory manually. Acceptable for v1.

### O4 -- No cleanup of worktree on `--approve --loop` or loop deletion
When a loop is halted and then approved (resumed), the worktree remains. When a loop dir is deleted, the worktree branch remains in the repo. Worktree GC is a v1.1 item (BACKLOG `worktree-gc`). Accepted.

## Verdict

PASS -- no blocker bugs. All observations are accepted trade-offs or v1.1 hardening items.