v0.7.0

Adoption no longer touches your disk.

Community criticism, accepted in full: moving and renaming a directory at adopt time risked breaking whatever pointed at it — editors, running servers, shell sessions, absolute paths in configs. The original justification did not survive an audit (nothing in the pool actually requires slots to live in the pool directory), so the disruption now lands where it is harmless:

• warmtree adopt <path> registers the worktree in place. Original path, original name, nothing on disk changes. Everything pointed at the folder keeps working.
• warmtree release graduates the folder into the pool as slot-N — at the one moment nothing legitimate is inside it: the branch is done, the lease surrendered, and the tree is being reset by release's own semantics anyway. The folder-named-after-a-dead-branch problem never occurs, because the rename coincides with the branch's death.
• A blocked move degrades gracefully: the slot stays ready and usable at its old address, and the next release retries.

Two guardrails found while building it:

• git worktree move into an existing directory does not fail — it silently nests the tree inside and exits zero. The graduation step guards against that explicitly.
• A slot living outside the pool directory is never auto-deleted: trim skips it and remove refuses without --force, because that folder is in your own space.

The agent skill and README describe the new behavior; installed skill copies refresh automatically on the next warmtree skill or init.