External/beardrive

Fork 0

mirror of https://github.com/runbear-io/beardrive.git synced 2026-08-25 08:08:08 +02:00

Files

T

History

d4fd7eb372 feat(webapp): say what a conflict copy is, where a reader meets it (BEA-128) (#177 )

A concurrent edit is preserved as `<name>.bdrive-conflict-<device>-<utc>`
— the guarantee the whole shared-folder promise rests on. Until now that
promise appeared in the README, the docs and syncer.go, and nowhere in
the hub: a conflict copy was an ordinary row with an alarming name, and a
user could only learn what it was by reading the README.

conflictName is a pure function of the path, so the frontend recovers the
device and the moment from the string alone — no server route, no journal
field, no request. lib/conflict.ts holds the parser (anchored suffix, a
strictly narrower match of the Go convention; anything malformed is null,
never a throw), the listing marks the row, and ConflictBanner explains the
file and links the version that kept the original name.

History and the Dashboard stay out, per the spec's stated cut.

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

2026-08-19 11:09:43 -07:00

cli-sync.md

fix(cli): bdrive log sorts by when a change arrived (BEA-112) (#174 )

2026-08-18 22:10:02 -07:00

overview.md

Catch a credential when it syncs, not only when you share it (#162 )

2026-08-18 15:08:44 -07:00

README.md

feat(cli): "bdrive serve" replaces "bdrive web" (web stays as an alias), and the README leads with the agent install (#94 )

2026-07-30 17:46:58 +09:00

webapp-frontend.md

feat(webapp): say what a conflict copy is, where a reader meets it (BEA-128) (#177 )

2026-08-19 11:09:43 -07:00

webapp-server.md

Catch a credential when it syncs, not only when you share it (#162 )

2026-08-18 15:08:44 -07:00

README.md

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 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).