589be3a6de
* fix(hub): open the project Dashboard to every member, rename /insights → /dashboard (BEA-12) "Dashboard" was the first sidebar item a new member clicked and it always refused: it landed on /<project>/insights showing "Insights is for hub admins and org owners." The gate was client-side only — GET /heat is gated on project membership and returns counts without actor identities, so every member's browser could already fetch every number the page draws. Drops the canInsights gate (nav item, dedicated route, project-home embed, ⋯ menu entry) and renames the view route insights → dashboard so the nav label, the URL and the page title finally agree. The shipped /insights URL still resolves and normalizes to /dashboard (LEGACY_VIEWS in router.ts) so bookmarks don't 404 and only one URL stays live. No server change: /heat gating and response shape are untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(architecture): router VIEW_ROUTES now names dashboard, with LEGACY_VIEWS Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- 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,agentskills}) - 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).