Files
automaton/tasks/add-blast-radius-scheduler/BUG_REPORT.md
T

26 lines
1.8 KiB
Markdown
Raw Normal View History

# 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.