Files
beardrive/architecture
31db19b9c6 fix(webapp): carry the hot-and-stale warning to the file and folder views (BEA-119) (#175)
* fix(webapp): carry the hot-and-stale warning to the file and folder views (BEA-119)

The Dashboard flagged archive/retired-spec.md as read-a-lot and
unmaintained, then the file's own page served it with raw counts and a
raw date and left the reader to do the staleness arithmetic. The warning
existed on the one screen nobody opens before trusting a doc.

HOT_READS, STALE_DAYS and the danger predicate were module-private to
Insights.tsx, so no other surface could reach the verdict — even though
both inputs (heatMap, Node.time) were already in hand on both of them.
They move to lib/heat.ts, whose own header says every read-count surface
shares one arithmetic, and Insights.tsx imports them instead.

The predicate takes (reads, days) rather than a heat entry: only the
Dashboard has a reader lens, so it keeps passing its lens-filtered count
while the file and folder views pass heatTotal.

- file page: "⚠ stale · last changed 7 months ago", leading the meta line
  because #meta is nowrap + ellipsis and a trailing warning is the first
  thing a narrow window eats
- folder listing: ⚠ beside the heat dot, files only (a folder's heat is a
  subtree sum with no single mtime), with a real aria-label rather than a
  hover-only title
- no threshold change: the Dashboard flags the same set, pinned by both a
  unit test on the boundaries and an e2e test on all three surfaces

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

* docs(architecture): heat.ts now owns the hot-and-stale verdict (BEA-119)

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 22:15:22 -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).