Files
beardrive/architecture
c8ab5504f7 feat(webapp): history can be narrowed by path, author and date (BEA-67) (#113)
* feat(webapp): history can be narrowed by path, author and date (BEA-67)

The project History view was a flat scroll with no controls but per-row
restore/open/download. Fine at eleven rows; unreadable after a month of
agent writes, and agents write far more than people do.

Four reader filters on GET /api/p/<id>/history — q= (case-insensitive
substring of the path), user= (exact account), since=/until= (UTC bounds,
inclusive at both ends, RFC3339 or a bare YYYY-MM-DD). They compose with
each other and with the existing path=/prefix= scoping, and they are
applied in the same walk as path/prefix — BEFORE the sort and the cursor
skip — so next_cursor keeps meaning "the next matching entry" and paging
under a filter needed no new machinery. kinds[] is still computed over
every op, so a filtered view classifies edits the same as the full feed.
A malformed since/until is a 400, not a silently unfiltered feed.

The filter bar drives those params through the URL rather than component
state: a narrowed feed is a link you can send, it survives reload, and
Back undoes it. The author list accumulates across fetches — rebuilding
it from the current feed would strand a reader who filtered by one
author with only their own name to pick from. Zero matches gets its own
empty state with a Clear.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(architecture): the frontend diagram parses again

The escaped quotes inside the NewProjectDialog note made the whole
classDiagram fail to parse — it has been rendering as an error box, not a
diagram, since that note landed. Same breakage on origin/main; noticed
while adding HistoryFilters to the same file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 14:11:01 +09:00
..

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:

  1. names exactly which types/relationships changed and how (one sentence);
  2. 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 serve server (internal/webapp + its internal/remote seam)
  • 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).