@staff0rd/assist 0.243.0 → 0.244.0

package/README.md

@@ -243,6 +243,14 @@ The first backlog command in a repository that still has a local `.assist/backlo
 - `assist sessions` - Start the web dashboard (same as `sessions web`)
 - `assist sessions web [-p, --port <number>]` - Start the web dashboard with Sessions and Backlog tabs, xterm.js terminals (default port 3100)
 - `assist sessions summarise [-f, --force] [-n, --limit <count>]` - Generate one-line summaries for unsummarised Claude sessions (force re-generates all; limit caps how many to process)
+- `assist daemon run` - Run the sessions daemon in the foreground (normally auto-spawned detached by `assist sessions`)
+- `assist daemon status` - Show sessions daemon status and live sessions
+- `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
+
+Web sessions are owned by a long-lived daemon process, not the web server: the server is a thin client that relays WebSocket traffic to the daemon over a local IPC socket (unix domain socket at `~/.assist/daemon/daemon.sock`; named pipe `\\.\pipe\assist-sessions-daemon` on Windows). Restarting the web server leaves sessions running with scrollback intact. The daemon logs to `~/.assist/daemon/daemon.log` and auto-exits once no sessions remain and no client has been connected for 60 seconds (it is respawned on demand by the web server).
+
+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.
 - `assist next [id]` - Alias for `backlog next [id]`
 - `assist draft` (alias: `feat`) - Launch Claude in `/draft` mode, chain into next on `/next` signal
 - `assist bug` - Launch Claude in `/bug` mode, chain into next on `/next` signal

package/claude/commands/draft.md

@@ -51,7 +51,15 @@ Good (vertical):
 - Phase 2: Add real data handling and validation
 - Phase 3: Polish edge cases and error states
 
-The test: at the end of each phase, you should be able to answer "does this work?" by running or inspecting the result. If a phase only produces internal plumbing with no observable effect, it's horizontal — restructure it.
+**Every phase must pass `assist verify` on its own.** Verification includes knip, which fails on unused exports. This makes horizontal slicing mechanically impossible to verify: an API helper, type, or stub added in phase 1 "for phase 2 to use" has no caller yet, so knip flags it and phase 1 cannot complete. Therefore:
+
+- Every export a phase adds must have a caller wired up **in that same phase**.
+- Never plan a task like "add X helper/endpoint/type" unless the same phase also includes the task that consumes it.
+- If a feature spans backend + UI, each phase carries its slice through both — e.g. "Phase 1: endpoint + UI button that calls it", not "Phase 1: endpoint, Phase 2: button".
+
+Two tests for each phase before proposing the plan:
+1. **Observable**: can you answer "does this work?" by running or inspecting the result? If a phase only produces internal plumbing with no observable effect, it's horizontal — restructure it.
+2. **Self-contained**: would `assist verify` pass with only this phase's code committed — no unused exports, no dead stubs awaiting a later phase? If not, merge the producer and its consumer into the same phase.
 
 Keep phases small (2-4 tasks each). A typical item should have 2-3 phases.
 

package/claude/commands/refine.md

@@ -62,6 +62,14 @@ assist backlog remove-phase <id> <phase>
 assist backlog add-phase <id> "Phase name" --task "Task 1" --task "Task 2"
 ```
 
+### Phase design rules
+
+When adding or restructuring plan phases, follow the same rules as /draft:
+
+- **Vertical slices, not horizontal layers.** Each phase delivers a thin, working increment verifiable end-to-end — never "backend in phase 1, UI in phase 2".
+- **Every phase must pass `assist verify` on its own.** Verification includes knip, which fails on unused exports — so every export a phase adds must have a caller wired up in that same phase. No "phase 2 will use it" scaffolding.
+- If the user proposes a horizontal split, point out that the earlier phase won't verify (knip will flag the unused exports) and suggest a vertical restructure instead.
+
 **To add a comment** (for context, decisions, or notes that don't fit in fields):
 ```
 assist backlog comment <id> "Comment text"

package/claude/settings.json

@@ -80,7 +80,8 @@
 			"SlashCommand(/handover)",
 			"Skill(recall)",
 			"SlashCommand(/recall)",
-			"WebFetch(domain:staffordwilliams.com)"
+			"WebFetch(domain:staffordwilliams.com)",
+			"Bash(assist daemon status)"
 		],
 		"deny": [
 			"Bash(git commit:*)", "Bash(npm run:*)", "Bash(npx assist:*)"