How should the v0.9.3 daemon work?

Three approaches — pick the one that fits how agents should consume context

A

Extend WatchDaemon + HTTP server

The existing WatchDaemon (double-fork, mtime polling, pidfile) gains an embedded http.server thread on localhost:27471. synlynk daemon becomes an alias for the extended watch. One process, two jobs: file watching + HTTP.

Pros

  • Minimal new code — builds on existing double-fork + pidfile pattern
  • Single process to manage, single pidfile
  • No new concepts for users already using synlynk watch

Cons

  • watch and daemon become entangled — harder to evolve independently
  • Threading in a daemon process adds subtle failure modes
B

New SynlynkDaemon class (recommended)

A separate SynlynkDaemon subclasses WatchDaemon and adds the HTTP server as a second thread. synlynk daemon start/stop/status is its own command. synlynk watch stays as-is (lightweight, no HTTP). launchd/systemd registration as synlynk daemon --install-service.

Pros

  • Clean separation — daemon is a superset of watch, not a replacement
  • Reuses all double-fork + pidfile + mtime polling logic from WatchDaemon
  • Follows existing patterns exactly (same structure as agent --install-cron)
  • Easy to test HTTP server independently

Cons

  • Two running processes if user has both watch and daemon active (edge case)
C

Standalone HTTP process (no file watcher)

Skip the file-watching loop entirely. The daemon is just an HTTP server that reads context.md on each request. No polling, no mtime tracking. Agents call GET localhost:27471/context and get the current file contents. Context freshness is the caller's problem.

Pros

  • Simplest possible implementation — no threads, no polling loop
  • Stateless — no risk of stale cache or missed changes

Cons

  • No auto-regeneration — agents get stale context unless human runs checkpoint
  • Loses the "always-current" guarantee that makes the daemon valuable
  • Not what the roadmap describes