docs: update-felis.md's restart guidance overstates which commands auto-spawn #160

New issue

Closed

opened 2026-09-06 12:41:08 +09:00 by natsukium · 0 comments

natsukium commented

2026-09-06 12:41:08 +09:00

Owner

docs/how-to/update-felis.md lines 73-75 read:

The next window launch or headless command (such as felis sessions spawn) automatically starts the freshly installed daemon binary,

phrased as a general claim about headless commands, with sessions spawn as a mere example. Under the auto-spawn policy documented by #141 (and always implemented by the code), that is false for most headless commands: felis daemon status, felis sessions list/info/capture/..., felis notifications subscribe, felis version, felis doctor, and felis bridge all refuse to auto-spawn on a cold socket and instead report unreachable / exit 2 / "not running". Only sessions spawn and window launches spawn a daemon.

The parallel remote-update sentence at line 104 ("The next felis --host user@remote invocation automatically spawns...") is fine as written: it follows from the bare window-launch example in that section rather than making a general claim.

Correction: narrow lines 73-75 to name the two spawning forms explicitly (sessions spawn and a window launch) rather than "headless command" generically, so a reader does not expect e.g. daemon status to resurrect the daemon after daemon stop.

Reason deferred from #141: this file is untouched by that branch (git diff origin/main...HEAD --stat) and the falsehood predates it; it is not one of the three docs (cli.md / ipc.md / control-surfaces.md) or skills/felis named by #141's acceptance criteria, so fixing it was out of that issue's scope.

Split from #141.

`docs/how-to/update-felis.md` lines 73-75 read: > The next window launch or headless command (such as `felis sessions spawn`) automatically starts the freshly installed daemon binary, phrased as a general claim about headless commands, with `sessions spawn` as a mere example. Under the auto-spawn policy documented by #141 (and always implemented by the code), that is false for most headless commands: `felis daemon status`, `felis sessions list/info/capture/...`, `felis notifications subscribe`, `felis version`, `felis doctor`, and `felis bridge` all refuse to auto-spawn on a cold socket and instead report unreachable / exit 2 / "not running". Only `sessions spawn` and window launches spawn a daemon. The parallel remote-update sentence at line 104 ("The next `felis --host user@remote` invocation automatically spawns...") is fine as written: it follows from the bare window-launch example in that section rather than making a general claim. Correction: narrow lines 73-75 to name the two spawning forms explicitly (`sessions spawn` and a window launch) rather than "headless command" generically, so a reader does not expect e.g. `daemon status` to resurrect the daemon after `daemon stop`. Reason deferred from #141: this file is untouched by that branch (`git diff origin/main...HEAD --stat`) and the falsehood predates it; it is not one of the three docs (cli.md / ipc.md / control-surfaces.md) or `skills/felis` named by #141's acceptance criteria, so fixing it was out of that issue's scope. Split from #141.

natsukium referenced this issue

2026-09-06 12:44:44 +09:00

docs: make the auto-spawn contract per verb, not per carrier #161

natsukium added the

priority/P1

release/v0.1.0

labels

2026-09-06 20:10:36 +09:00

natsukium referenced this issue from a commit

2026-09-07 13:24:40 +09:00

docs: name the two daemon-spawning forms in update-felis

natsukium referenced this issue from a pull request that will close it,