b927e56fab
* fix(daemon): let the daemon own its pidfile, so stop can stop it `bdrive stop` could fail with "no such process" and leave sync running. Liveness became the flock in #88, and Run already announces the child's own pid only after it holds that lock. But Start still wrote daemon.pid from the parent, right after fork, with the pid of a child that had not earned anything yet. Two starts inside that window — `bdrive init` followed by the login agent's `bdrive resume`, or two resumes close together — race: Running still reads false, a second child spawns, it loses hold(), and it exits without ever being the daemon. Its pid is already in the file. Everything downstream trusts that file. Stop signals the loser and gets ESRCH, so it reports failure while the winner keeps syncing — the one command whose job is "stop sending my files" silently does not. status prints the phantom pid, or "pid 0" when the loser's cleanup removed the file the winner wrote. So the parent no longer writes it: the pidfile belongs to whoever holds the lock. Start now waits for the lock to be taken instead of assuming the spawn worked, which also means a caller that gets a pid back can trust a daemon owns it — `bdrive resume` used to print "started (pid N)" for a child that had already died. The regression test needs the real binary (Start execs os.Executable), so it lives with the CLI e2e rather than in internal/daemon, whose tests synthesize locks. It is deterministic on Linux and roughly one run in five on macOS, where the window is tighter; `sandbox/run.sh daemon-linux` is the reliable reproducer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DgF8JsoeNPVShGYWdooE72 * docs(architecture): the daemon owns its pidfile, Start only waits for the lock Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DgF8JsoeNPVShGYWdooE72 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Architecture diagrams
Mermaid diagrams of the current implementation, kept next to the code so PRs can update them alongside the change.
Convention: when a PR changes the structure drawn here (new/removed types, new seams, changed relationships), update the affected diagram in the same PR and add an "Architecture changes" section to the PR description that, per changed diagram:
- names exactly which types/relationships changed and how (one sentence);
- shows a Before and an After mermaid block — each an excerpt of only the affected classes and their immediate relationships, never the full diagram (Before comes from the diagram at the merge base).
The committed diagram file stays the full current state; the before/after
excerpts exist only in the PR description so reviewers see the structural
delta at a glance. A pre-PR hook (.claude/hooks/check-arch-diagrams.sh)
reminds Claude Code sessions when server code changed but no diagram did.
Together these cover every application package in the repo — every code change lands inside exactly one detail diagram's scope (plus the overview when the package map or cross-piece wiring changes):
- overview.md — system diagram: every package and surface on one page, and how they connect
- cli-sync.md — class diagram of the CLI and sync engine (
cmd/bdrive+internal/{syncer,store,journal,config,daemon,agenthooks,autostart}) - webapp-server.md — class diagram of the
bdrive webserver (internal/webapp+ itsinternal/remoteseam) - webapp-frontend.md — module diagram of the hub's React SPA (
internal/webapp/frontend/src)
Not covered on purpose: web/docs (content site, no application code) and
cloud/ (private nested repo — its architecture lives there).