Snow Lee
7edef42d76
The change feed is flat reverse-chron with no notion of when you last looked, so "what happened while I was away" is date arithmetic in your head — and cheap agents write more files per day than that scales to. Server: `?since=<RFC3339>` on GET /api/p/<id>/history, one case in the existing filter switch. It sits after the kinds[] classification (which must keep walking every op, or a filtered view relabels an edit as an add) and before the sort, so next_cursor is minted from the filtered list and paging a since-feed terminates on its own oldest match. Client: /<project-id>/since — a real VIEW_ROUTES entry — renders the existing HistoryView with that filter and a header line. The anchor is a per-(account, project) localStorage marker, read once from a useState initializer and stamped after entries render: read it any later and the page empties itself while you are reading it. SinceView is the only caller of stampVisit, so no other page moves the marker. Known ceiling: the marker is per browser, not per account — laptop and phone keep separate last-visit times. The server-side marker is the larger follow-up.
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 serveserver (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).