Expand description
The worktrees daemon service.
A thin adapter that hosts the cross-window WorktreesRegistry under the
daemon’s lifecycle and exposes register/heartbeat/unregister/list/tree/open
over the control socket, plus a tray submenu with a per-window “focus” action.
The open op (#1266) focuses/opens an arbitrary worktree folder in VS Code
through the same launcher path the tray uses, so a socket client (the
companion’s double-click) shares the tested guard and launcher resolution
rather than duplicating them.
All registry state and liveness logic (the Mutex<HashMap>, TTL reaping, the
entry cap/eviction) lives in crate::worktrees; this adapter only routes
ops, renders the menu/status, and drives the VS Code launcher. Like the
Snowflake service it is a cheap, in-memory adapter — no async setup, no
secret persisted.
The adapter also computes the per-worktree git enrichment (current
branch, ahead/behind counts, and the parent repository a linked worktree
belongs to) on read via git2 (#1186), keeping the companion a thin reporter
of raw folder paths (ADR-0040). The engine stores only what the companion
sends; disk I/O for the enrichment lives here, alongside the launcher, never
under the registry lock.
The tree op (#1265) inverts the data model for the companion’s tree view:
from the open windows the adapter derives the distinct repositories, then
enumerates all of each repo’s worktrees (main working tree +
Repository::worktrees), enriches each (reusing [git_status]), tags the
GitHub identity of origin, and joins the open windows back on by
canonicalized path. The open-window registry stays the liveness source;
“is a window open on it?” becomes a per-worktree attribute. All of this is
git disk I/O, so it runs on a blocking thread, never under the registry lock.
Structs§
- Worktrees
Service - Hosts the cross-window
WorktreesRegistryas aDaemonService.
Constants§
- SERVICE_
NAME - The worktrees service name (the control-socket routing key).