Files
82e23f2382 feat(webapp): copy a file's source to the clipboard (BEA-153) (#190)
You could read a doc in the hub and download it, but there was no way to
get its text onto the clipboard — the workaround was downloading a file
you didn't want, or select-all over rendered markdown, which silently
mangles what you paste.

Copy sits beside Download in the ⋯ menu and in the ⌘K palette, and puts
the file's raw source there: the whole file, frontmatter included, so it
round-trips with Download. With a version pinned (?v=) it copies THAT
version's bytes, the same rule Download already follows.

It fetches directly rather than reading the ["text", url] query cache:
TextView stores a bare string under that key and SniffView stores a
BlobText object, so a cache read would have refused .csv/.txt files
while working fine on the markdown a reviewer would test with.

copyText returns false instead of throwing, so the toast branches on it
— otherwise every http:// self-host gets a success message over an empty
clipboard.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-21 09:30:45 -07: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).