@staff0rd/assist 0.433.5 → 0.434.1

package/README.md

@@ -296,7 +296,7 @@ Backlog item ids are written and displayed in an `a`-prefixed form (e.g. item 55
 - `assist daemon status` - Show sessions daemon status, live sessions, and any stray daemon processes or stolen socket
 - `assist daemon stop` - Stop the sessions daemon; running claude sessions resume on next start
 - `assist daemon restart` - Restart the sessions daemon, resuming previously running claude sessions
-- `assist daemon drain` - Remove all sessions from the local daemon for a clean slate (does not affect the Windows daemon)
+- `assist daemon drain [--yes]` - Remove all sessions from the local daemon for a clean slate (does not affect the Windows daemon); prompts before closing live sessions (`--yes` skips the prompt, and is required when stdin is not a TTY), and a session holding unpushed work is stopped, not removed
 
 The sessions topnav has a **Design** dropdown: submitting a prompt launches an interactive `claude` session with the vendored design system prompt appended via `--append-system-prompt` (so the 647-line prompt stays out of the visible conversation) and the prompt sent as the first message; submitting an empty prompt opens a design-configured session with no initial message.
 
@@ -310,7 +310,7 @@ From WSL, the selector can also surface and drive Windows-host repos (requires `
 
 A `run:` entry in `assist.yml` flagged `server: true` (with an optional display-only `port:`) is treated as a singleton **dev server**: at most one may be live per normalised git remote (`getCurrentOrigin`), i.e. across a clone and all its sibling clones of the same repo. Every session card for a repo that defines a `server: true` run shows a **▶ start** button (surfaced by `GET /api/server-runs?cwd=`); clicking it sends `create-run`. The daemon enforces the singleton on `create-run` (and on relaunch via retry) — if a server run is already live for that remote it rejects with a conflict instead of starting a second one that would collide on the port. The web UI turns that conflict into a "replace running server?" prompt; confirming stops the old server and starts the new one, declining leaves it untouched. The serving session's own card shows a `serving :<port>` chip and a **⏹ stop** button (stop leaves a relaunchable card rather than dismissing it), and the slot frees automatically whenever that session stops, exits, or is killed. Non-`server` runs (`build`, `test`, …) are unconstrained.
 
-Concurrent sessions in one repo can be isolated with native git worktrees instead of keeping multiple physical clones. Opt in per repo (default off): `assist config set worktree.enabled true -g --repo`. A lone session runs in the clone's own tree unchanged; a concurrent session spills into an adjacent `<clone>-N` worktree with its own tree, index, and HEAD. New worktrees are seeded so they build and run — a per-worktree dependency install (`worktree.install`: `true` auto-detects the package manager from the lockfile, or give an explicit command; `false` skips it — `node_modules` is never shared) and a copy of the configured gitignored files (`worktree.copy`, default `.env`, `settings.local.json`, `.claude/settings.local.json`). Worktrees hang beside the clone under `worktree.root` (default: the clone's parent). A worktree is reaped only when its session reaches `done`, and a session cannot reach `done` while its tree is dirty or holds local-only commits (`push:false`) — the card shows why (`waiting — unpushed commits`) and the daemon fs-watches the tree's git state, auto-reaping the moment the branch becomes durable (pushed). Worktrees orphaned across a daemon restart are reconciled on startup against a persisted registry (`~/.assist/worktrees.json`); nothing is removed while undurable. With worktree mode off, behaviour is unchanged.
+Concurrent sessions in one repo can be isolated with native git worktrees instead of keeping multiple physical clones (opt in per repo, default off): see [docs/parallel-work.md](docs/parallel-work.md).
 
 When iterating on assist itself: web server changes only need the `assist sessions` process restarted — sessions survive. Daemon/session-core changes need `assist daemon restart` to load the new code; this kills the PTYs, then claude sessions — including assist sessions that wrap claude, like `assist draft` — are auto-respawned via `claude --resume` with scrollback starting fresh, while run sessions (and assist sessions whose claude sessionId was never discovered) reappear as not-restored tiles that can be retried. A `--once` draft/bug/refine session is respawned through its assist wrapper instead of bare `claude --resume`, so its `assist signal done` watcher is re-established and the card still auto-closes.