Files
automaton/tasks/complete/add-blast-radius-scheduler/BUG_REPORT.md
T
Lap Tran 4a2301b077
CI / build (push) Has been cancelled
Archive completed tasks, add cleanup commands, self-documenting dashboard UI
- Archive 79 completed framework-dev tasks from tasks/ -> tasks/complete/
- status.py: add --cleanup-done and --install-cleanup-schedule commands
- Add scripts/automaton-cleanup.sh for periodic task archiving
- Dashboard: rename 'Background' tab -> 'Agent', 'Cleanup' agent -> 'Completed Task Archiver', remove redundant group headers and pill badges, dim inactive agent placeholders
- .rules.md: add Self-Documenting UI Names rule
- New tests: test_cleanup_done.py, expanded test_app.py and test_task.py
2026-06-24 22:43:33 -04:00

1.8 KiB

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.