An explicit `bdrive sync` never touched the stored session note, so a hand
edit made after `bdrive sync --note claude-session-abc` was still stamped
with that note under its 30-minute TTL — attributed to the agent in
`bdrive log`, and grouped inside that session in hub History (which also
feeds the agent-run rollback story).
The fix is a branch deleted, not added: `SaveNote("")` already routes to
`ClearNote`, so dropping the `Changed("note")` guard makes one unconditional
call both set and clear. Clearing the *store* is what leaves the cycle
unstamped — scan falls back to `LoadNote` whenever `Session.Note` is empty.
The --hook path has its own SaveNote and the daemon calls Cycle directly, so
agent- and daemon-driven syncs keep the note until the TTL expires.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(webapp): say that a read count includes your own views (BEA-61)
"14 human reads" counted the author's own browsing, and no surface said so.
Snow's call was to keep counting them — so this is disclosure, not ingest:
recordRead and /heat are untouched.
One HEAT_DISCLOSURE constant beside heatText in lib/heat.ts, consumed by all
four surfaces that print a count. The file header carries it as hover text
plus an .sr-only span rather than visible text — #meta is nowrap + ellipsis,
so anything appended there is the first thing a narrow window truncates away.
The folder page says it once out loud, covering the summary and every row,
and the heat dot keeps it in title and aria-label for a row met on its own.
The Dashboard folds it into the caption already there, both scope branches.
A unit test pins the constant as the only copy of the sentence in src/ —
"defined once" is the acceptance criterion no browser test can see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(architecture): note HEAT_DISCLOSURE in the frontend lib diagram (BEA-61)
The diagram enumerates heat.ts's exports, so a new one belongs in it — and
the note says why the constant sits beside the arithmetic instead of in the
four components that print it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
`bdrive status` answered from the state cache and the journal and never
looked at the working folder. With the daemon stopped, an edit nobody has
scanned is in neither — so the one command that answers "is this folder in
sync?" reported `pending: 0` with the change sitting right there. A wrong
"you're clean" is worse than no answer.
syncer.Drift is a sibling of Explain/SyncedFiles with the same contract:
loadFilter + walkFolder + the scan's own size+mtime compare, and nothing
else. status prints it as a `local:` line, distinct from `pending` — they
are different states and a change can be in either or both.
The load-bearing property is that it stays a pure read. status is what
someone runs when sync is stuck; a version that scanned-and-committed would
change what it was asked to describe, and would write ops from a command
nobody expects to write. Pinned by a test hashing the device journal and the
state cache before and after.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Staleness today is age and only age: Insights.tsx's STALE_DAYS = 30 flags a
fresh doc nobody reads and misses the one that costs a team — a doc edited last
week describing code that moved yesterday.
`bdrive stale` measures the other thing. It scans synced markdown for
references to other synced files and reports every doc that links to something
written after the doc itself.
It is `bdrive grep` with a different per-file predicate, and keeps that
command's whole posture: LoadProject not ResolveMount (a read must not enroll
the device), a Stat-guarded store.Open (a read must not create a volume), no
session, no flock, no network, safeField on everything printed.
The one place it must not copy the obvious approach is dating a file.
materialize never calls os.Chtimes, so a peer's January edit carries this
device's mtime — on a freshly cloned machine every mtime is within seconds of
every other, and mtime comparison would report nothing on exactly the machine
that most needs the answer. Dates come from the journal: st.AllOps() folded to
the max syncer.DisplayTime per path, which also drops a forged year-9999 stamp
rather than dating that path to year 1 and flagging everything that links to it.
Resolution is the filter — a URL, a ../ escape, a made-up path is silently
ignored — so a .bdriveignore rule or a narrowed `bdrive scope` excludes a file
here exactly as it excludes it from sync.
Exit status is 0 whether or not anything is stale. grep's "1 means nothing
found" convention inverts here: it would fail on a clean project, and this is
advisory in the same sense the agent hook's context is.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* refactor(secrets): lift the share-time credential rules into internal/secrets
The rules only ever ran on the rarest path a file takes. Moving them out of
internal/webapp is what lets internal/syncer run the same six rules on the
path every file takes, without inverting the dependency.
Pure move plus one addition: Label(), the six human strings that until now
lived only in the frontend's SECRET_LABELS — so 'bdrive share' stops printing
a bare rule id where the web dialog says 'an AWS access key'. Rule ids and the
rule/line JSON tags are unchanged: Browser.tsx keys off them, so they are a
wire contract.
* feat(sync): warn when a synced file looks like it holds a credential
The six share-time rules now run on the path every file takes. A file with an
AWS key in it used to ride a normal sync to the hub, to every teammate's disk
and into every future agent's context with no badge and no warning — while the
Share dialog one click later blocked that exact file.
Warn, never block: the op is journaled and pushed exactly as before. A hold arm
would mean a false positive silently parks someone's changes, and it would
break the cycle's degrade-to-offline posture.
- scan() reads the blob PutBlobFile just wrote (the bytes that were actually
journaled), only on the branches that wrote one — an unchanged file is still
never re-read.
- Findings persist per path in secrets-<mount>.json, merged rather than
replaced: nearly every cycle scans zero files, and a whole-set rewrite would
erase the warning seconds after it appeared. Fixing the file clears it.
- bdrive status grows a secrets block; the agent hook appends one advisory
sentence. Rule ids and line numbers only, never the matched bytes.
- SaveSecrets failing logs and continues: advisory telemetry never gets a veto
over convergence.
* docs: the credential check now runs on sync, not only on share
README, the CLI reference and project-files get the new bdrive status block
and the warn-never-block posture, with the three limits stated (checked when
it changes, first 1 MiB, writing device only). Diagrams: internal/secrets is a
package of its own in the overview, secretLog joins the sync engine, and the
share-gate class notes that it no longer owns the rules.
* test(sync): assert an unchanged file is never re-read for credentials
The check must ride the branch that already reads the file. Clearing the record
by hand and cycling proves it: a scan that re-read unchanged files would put the
finding back, and the daemon's 3-second tick would pay for it on every file.
[[guide]] rendered as href="wiki:guide" — a pseudo-scheme no browser can
resolve. The delegated click handler rescued a plain left-click, so the
feature looked fine until someone copied the link, middle-clicked it, or
opened it in a new tab and got a dead string.
Resolution moves from click time to transform time: transformHTML (the
pass that already rewrites this HTML before the mount) matches the target
against flatFiles and writes the real urlForPath() URL, plus a data-wiki
marker. A wikilink matching no file loses its href entirely and renders as
.wiki-missing, so no "wiki:" survives into the DOM either way.
The matching rules didn't change — they moved into a pure resolveWiki() in
util.ts, where node --test covers the whole matrix without a browser.
The consequence to get right is the click: real hrefs mean a plain click
must be intercepted (or it does a full document load) and every modified
click must be let through (or the fix buys nothing) — the same rule
nav.ts:linkProps applies everywhere else. The guard sits above both
branches, so cmd-clicking a relative markdown link now opens a tab too
instead of SPA-navigating the current one.
markdown.go is unchanged: wiki: stays the marker the server leaves behind
because RenderMarkdown has no file tree. /s/<token> share pages keep their
dead wikilinks by the spec's decision — the target isn't part of the share.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(webapp): a broken mermaid fence says which line, and why (BEA-135)
A fence that doesn't parse showed "Couldn't render this diagram." and
nothing else — no line, no parser output, no way to fix it. The
diagnostic already existed: mermaid throws a parse error carrying the
line number, the offending source, a caret column and the expected
tokens, and the catch discarded it one line from where it was needed.
Bind it and print it under the existing note, in a sibling element so
.mermaid-err's text stays exactly what it was. textContent, never
innerHTML: the message quotes the author's source verbatim and what
renderMermaid returns is mounted through dangerouslySetInnerHTML. The
seeded broken fence now carries a complete <img onerror=x> tag so the
e2e proves that — short on purpose, since the parser's window is 20
characters of past input and a tag it truncated would leave no start tag
for an innerHTML bug to mount.
The line number is the diagram's, not the file's: the helper only ever
sees rendered HTML, never the .md around it.
Both surfaces, one helper: the hub viewer reads style.css, the share page
reads the inline shell in shares.go and never loads the app's stylesheet.
`white-space: pre` is load-bearing (the caret only lines up in a
monospace, non-wrapping box) and max-height + overflow keeps a
pathological message inside its own box.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* chore(webapp): rebuild static/ for the mermaid diagnostics
go:embed needs the built output in the module. Split from the source
commit because rollup re-hashes the whole mermaid chunk graph when its
importer changes: 118 of these files are renames with byte-identical
content, only their import filenames differ.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(webapp): undo a whole agent run from the run card
The run card was grouped for this and stopped one button short: every row
inside it carried an action, the header carried none, so reverting a bad run
meant clicking file by file and hoping you got them all.
POST /api/p/<id>/undo-run works out, for every path the run touched, the op
that puts it back — a put at the pre-run blob, or a delete for a file the run
created — and writes them all in ONE journal append. That is the atomicity
argument, not an optimization: one Put of one object either lands or it does
not, so there is no half-undone run to report. appendOps is the batch write
every path in the package now goes through; appendOp is its single-op call.
Selection is by the journal an op was READ FROM, never op.Device — that field
is arbitrary JSON any member with write access can put in their own journal,
and the card attributes rows the same way. The note form additionally requires
an empty Session, because runs.ts can never file a session-carrying op under a
note-keyed card.
Append-only throughout: the run's own ops are never edited or removed, so
one-writer-per-journal and deterministic replay both survive. The undo's ops
carry a note naming the run, so the undo is itself a run card you can undo.
The confirm asks the server for the file list rather than deriving it from the
loaded feed (paged and filterable, so a client-computed list is wrong exactly
when the run is old), lists every path with its action, and names the one thing
that can burn someone: a file a teammate changed after the run is reverted too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(webapp): the undo confirm names the paths it will not write
planUndo already refuses a path the hub's own upload door would refuse — a
peer can push one under .bdrive/ or with a control character in it — but the
dialog listed only what the undo WOULD do, which reads as "all of it".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The frontend's PostHog tracker sees everything a person clicks, but a
device syncing through /store/* never loads a page — so an agent editing
files all day was invisible, and "number of file changes" and "daily
active users" both undercounted by however much of the product runs
headless.
One event, files_changed, from every write door: sync, upload (relay and
direct commit), remove, restore. Its distinct_id is the same email
analytics.ts identifies with, so a person on a laptop and a browser is
one user, and its puts/deletes properties sum to the change count.
The count comes from ops the hub has not stored before, not from the
request body: a device PUTs its WHOLE journal every cycle, so counting
the body would re-report the device's entire history every ten seconds
and the metric would climb while nobody edited anything.
journalKeepsItsOps already parsed the stored journal for the append-only
check and threw the sequence away; it returns storedMax now, so this
costs no extra read. Blob PUTs are deliberately not change events —
content-addressed storage skips a blob it already holds, so blob writes
undercount edits while ops are exact.
No SDK: posthog-go would ship a tracker inside every self-hoster's
binary, which is the exact thing the frontend avoids by loading
posthog-js from a CDN only when a key is configured. Capture is one JSON
POST, on its own goroutine, that does nothing when Analytics.Key is
empty — an OSS hub still contacts nobody.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Nothing on the /store/* wire was compressed, while the corpus it carries is
markdown and source. Compression lands as a pure transport concern: content
addressing, the storage layout and the journal format all stay over the
uncompressed bytes.
The two legs are not symmetric. Pull needs no negotiation — net/http already
sends Accept-Encoding: gzip and inflates transparently — so devices built
before this get it the day the hub ships; a real pre-compression binary
receives 19,958 bytes for a 148 KB corpus (7.4x) with no client change. Push
is negotiated through sign()'s accept_encoding, because a gzip body posted to
an old hub would be stored under the sha256 of its plaintext.
The hub inflates ABOVE spool — the sha a key promises, the ops a journal
carries and the size that gets billed are all plaintext properties — and the
inflate is bounded at 256 MiB, because Content-Encoding severs the
one-wire-byte-one-disk-byte relationship that made spool safe unbounded. The
presigned direct-to-storage leg stays raw and is asserted to.
Known deployment caveat: a compressed push clears ContentLength, so it goes
out chunked where every push was sized before. A reverse proxy that buffers or
rejects chunked request bodies would fail pushes (degrading to Offline and
retrying, not losing data).
Inbound sync was invisible to the machine it landed on — a local index,
cache or notifier had to poll. A `post_sync` command in the folder's own
.bdrive/config.json now runs once per cycle that applied peer changes,
with the batch as JSON on stdin.
The batch rides out on a new Result.Inbound rather than the inbound
spool: DrainInbound is destructive and `bdrive sync --hook` is its only
consumer, so a second drainer would silently empty the agent's
"teammates changed X" context. Both are kept, and both comments now say
why.
Cycle becomes a thin wrapper over cycleLocked so the hook is spawned
after the volume flock drops — a property of the code shape, not a rule
each of the seven call sites has to remember.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(sync): delta sync — large files move as content-defined chunks
Files over 4 MiB push as chunks/<sha256> pieces plus a manifests/<sha256>
chunk list keyed by the whole file's hash, so Op.Blob alone locates it and
the journal format is byte-identical. A 1-byte edit to a 20 MiB file now
transfers ~2 MB instead of ~21 MB, both directions; chunk boundaries come
from a rolling hash (restic/chunker), so front insertions stay cheap.
The hub reassembles whole blobs on demand (spool, verify, backfill, serve),
which is the entire backward-compatibility story: old clients ask for
blobs/<sha> and never learn anything changed. Proven by e2e tests that build
the real pre-change binary from the pinned merge-base commit.
The push skip-proof is one Exists per chunk — three cheaper proxies (local
basis, manifest existence, stored manifest content) each proved false or
forgeable across four CTO review rounds and are recorded in the code
comment. Hub-side, manifests are write-once and must name only chunks the
store holds; reassembly is bounded at 256 MiB against amplified manifests.
Also: per-file sync ceiling 32 -> 100 MiB; import refuses archives whose
journals reference content they do not hold (--allow-incomplete overrides).
Deploy hubs before clients: old hubs refuse chunk keys (push degrades to
offline-retry), and old clients cap reads at 32 MiB so 32-100 MiB files
report "blob corrupt on remote" until the client upgrades.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R6nqxi5a9qcENmJvrgBJF7
* fix(test): fetch the pinned pre-delta commit on shallow CI clones
buildOldBinary archives the pinned merge-base sha, which a fetch-depth-1
actions/checkout does not have — all three old-binary e2e tests failed in
CI with exit 128 while passing on any full local clone. On archive failure,
fetch just that commit (--depth=1, one object; actions/checkout persists
credentials so the in-job fetch works) and retry. Verified against a real
GitHub shallow clone: archive fails, the single-sha fetch succeeds, archive
then yields the pre-delta tree.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R6nqxi5a9qcENmJvrgBJF7
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
A device's first cycle on a volume was treated as a concurrent edit for every
path the project already held. Whichever side's clock happened to sort higher
won -- so a joiner's seeded .bdriveignore or agent-written AGENTS.md could
replace the team's -- and the loser landed beside it as a
.bdrive-conflict-<device>-<time> file.
A first cycle is a join, not an edit. Cycle step 1b holds the scan's ops back
over the pull and demotes any whose path the project already holds to lamport
0, which sorts under every op a project can carry (scan's clock starts at 1).
The project's version then wins deterministically on every device, and
conflictCopies skips those ops the way it already skips re-asserted ones. The
local content is still journaled and pushed, so it stays in History and
`bdrive restore --list <path>` can bring it back. Reported as `adopted: N`.
Concurrent edits after the join are untouched.
Claude-Session: https://claude.ai/code/session_01GLCyEWP2XZhYjBssvdCDQm
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The setup page opened with a prompt carrying three placeholders — project id,
hub URL, project name — none of which a first-time reader has. It was the
teammate-joining paste doing double duty as the getting-started paste, and
it asked someone with nothing to substitute values into a two-line string
before they could begin.
The start is now:
Follow beardrive.ai/setup to set up BearDrive. Ask me which folder to sync.
Same destination — beardrive.ai/setup 302s to INSTALL_FOR_AGENTS.md — and the
same wording the landing page hands out, so the two surfaces stop disagreeing
about how this begins.
The join case keeps its placeholders and moves to where it belongs: the
project's own home page in the hub already renders that paste pre-filled, and
the page now says to use it rather than hand-assemble one. Getting this wrong
means a teammate creating a second project beside yours, so it is stated as
the consequence rather than a preference.
Also says why "Ask me which folder to sync" is in the sentence at all. It is
not politeness: without it agents read the rest as permission to decide, and
the guess is the whole folder — the one answer INSTALL_FOR_AGENTS.md tells
them never to recommend (#157).
README carries the same paste and is updated with it, per the sync rule in
CLAUDE.md.
Claude-Session: https://claude.ai/code/session_01CmKrcXaXxamwcPqR4DcU7S
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two failures from one real run: an agent given "Set up BearDrive in this
folder" mounted the whole folder without asking, and never offered a
starting structure.
Both were already specified — the ask is a hard gate in step 3 and the
template offer was the last paragraph of it. Neither survived contact.
- A location phrase names where the session runs, not what syncs. "in this
folder" / "here" / "this project" are the start of the conversation, not
the end of it; the question is answered only when the user picks between
the recommendation and the alternatives, in a message of their own.
- The template offer is now step 4, not a trailing paragraph — same lesson
as #155. A decision the user makes is not a footnote to the command
above it.
- "Empty" is defined: init has just written .bdrive/ and seeded
.bdriveignore, so the folder is never literally empty when the agent
looks. Those, .git/ and other dotfiles do not count as content.
Verified with the onboarding-e2e skill against a seeded hub, using the
failing wording verbatim: turn 1 asks and recommends shared/ with the
folder still untouched, turn 2 offers the four templates reasoning "only
init's own .bdrive/ + .bdriveignore", and the docs template lands and
reaches the hub.
Claude-Session: https://claude.ai/code/session_01CmKrcXaXxamwcPqR4DcU7S
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The "point your repo's agents at the synced folder" instruction sat in a
trailing "Optional:" section outside the numbered flow, so installing agents
skipped it — a real setup wired up init/hooks/sync/autostart and left the repo
root with no pointer at all, meaning agents starting there never found the
folder's AGENTS.md.
Promote it to numbered Step 6 (ask-first, like step 3), with the paste-ready
pointer block, the <mount> substitution, "pointer, not copy", and a
no-duplicate-block guard so re-running is safe.
Fixes BEA-138
Claude-Session: https://claude.ai/code/session_01CmKrcXaXxamwcPqR4DcU7S
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
BearDrive launches free with a beta label, so the hub says so next to its
own name. Subtle honey pill at low alpha, not the solid accent: the accent
is already spent on the mark two elements to its left, and this sits there
until it doesn't.
It keys on what the lockup actually SAYS (`brand === "BearDrive"`), not on
whether `brand` was configured. A hub that set its own brand is labelling
somebody else's product and "Acme Docs Beta" is a claim we have no business
making for them — but the managed hub and every default self-host reach here
with the string "BearDrive", and the obvious `!config.brand` test would have
missed them: CLOUD_BRAND defaults to "BearDrive", so a BuiltinAuth hub sends
the name rather than an empty field, and the pill would have shown only on
the PropelAuth path.
Claude-Session: https://claude.ai/code/session_019vWP4DbsWCeD6zWN5gaqsV
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The seven use-case pages were the one part of docs.beardrive.ai that wasn't
documentation — job-shaped routing pages, aimed at someone deciding rather
than someone building. beardrive.ai already publishes six of them, same
titles, same slugs, so the docs copy was a fork of marketing copy that no one
was keeping in step.
They're deleted here, and every URL redirects to its counterpart over there
rather than to an index: those pages were live and indexed for a month, and
sending all seven to /use-cases/ would throw away which one someone asked
for. shared-skills is the exception — the landing site has no page for it
yet, so that one lands on the index.
The logo now points at beardrive.ai. Starlight always aims it at the docs
root and has no config for it, so this is a SiteTitle component override:
its own markup, one changed href, minus the two-logo branch this site never
takes (one `src`, so the light/dark alternate can't render).
Three off-site links — Use cases, Blog, GitHub — go at the BOTTOM of the
sidebar. The sidebar order is the recommended path, so a link that leaves
the docs must not sit above the docs.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs.beardrive.ai was serving a build from around 2026-07-19 — three weeks
and 38 docs commits stale. /manual/hooks/ 404s while /manual/skills-and-hooks/,
deleted in #85, still serves; the sitemap has no <lastmod> and robots.txt is
Cloudflare's managed content-signals file with no Sitemap: line, so #140
plainly never shipped.
The cause: the Pages project (beardrive-docs, docs.beardrive.ai) is a
direct-upload project with no Git provider. Someone ran `wrangler pages
deploy` by hand, then stopped, and nothing anywhere noticed — every check
this repo has runs during a deploy that was no longer happening.
docs.yml builds web/docs on PRs that touch it and deploys to Pages on pushes
to main. Not the Pages Git integration, deliberately: it clones shallow, and
astro.config.mjs reads each page's <lastmod> from the commit date behind it,
so a depth-1 checkout drops all 27 of them — hence fetch-depth: 0. It also
would rebuild the docs for every commit in a repo that is mostly Go.
The path filter includes internal/webapp/frontend/src/tw.css: the palette is
generated from that file, so it is a docs input even though it lives outside
web/docs (which is also why the checkout can't be sparse).
The post-deploy check:sitemap run is continue-on-error. Half of what it
checks — a Cloudflare-managed robots.txt shadowing ours, cache propagation
right after upload — isn't this repo's call, and a good deploy shouldn't go
red over it.
Needs CLOUDFLARE_API_TOKEN (Pages: Edit) and CLOUDFLARE_ACCOUNT_ID.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
- start/setup says "Three are shipped" above four templates. Four ship
(internal/templates/files: docs, para, skills, wiki).
- guides/shared-agent-memory tells the reader to run `/beardrive:install`.
There is no such command — no plugin, no skill; the integration is
internal/agenthooks and setup is the paste on start/setup.
- index lists SSO as part of the managed service. No SAML/OIDC exists
anywhere, and the cloud plan has it unstarted.
Claude-Session: https://claude.ai/code/session_01UmhLKHq3QTHjkDi2wCDhNB
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ownJournal refuses a journal write unless the device id is bound to the
caller's account, for EVERY provider — it asks only whether s.Devices is
nil. The only thing that creates that binding is DeviceRegistry.Bind, whose
only caller is BuiltinAuth.finishLogin, and that hook was wired behind
`if a, ok := s.Auth.(*BuiltinAuth); ok`.
So a hub running a managed AuthProvider — the deployment the seam exists
for — bound nothing, ever, and refused every journal push from every device
forever. Everything around it read healthy: /api/auth/me answered, project
permissions said write, and blobs (content-addressed, so ownerless) uploaded
fine. Only the journal PUT died. Signing in again could not help, because
signing in was the step that was supposed to bind.
UseDeviceBinder moves the hook onto the AuthProvider interface — a breaking
change for an out-of-tree provider, deliberately, so one that ignores a
precondition of a gate the hub enforces for it does not compile. The hub
cannot bind on the provider's behalf: a bind must be reachable only from a
completed authentication, and Authenticate reports who a request is, never
which credential class it presented. A device token still cannot reach a
bind; no new door was added, and every /store/* door still creates nothing.
Bind also reported success for a row the store had refused — observeLocked
logged the write failure and swallowed it — so a login could hand back a
token whose every push was then denied, with nothing in the hub explaining
why. It now propagates and the login fails honestly.
And a hub that refuses a journal write while holding no binding at all logs
that its provider is not calling the binder — the sentence that would have
ended this investigation on day one instead of day two.
Tested by driving the real binary against a hub with a managed provider
(cli_provider_e2e_test.go), which is the configuration no test in this repo
covered and the reason this shipped: every existing test used BuiltinAuth,
where the wiring happened to work. Both directions are pinned — a provider
that binds pushes, one that ignores the binder reproduces the reported
symptom exactly.
Claude-Session: https://claude.ai/code/session_01GSHsQU4pBCzKkPyPeXSwTm
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Leads with the upgrade reason: a CLI older than the hub's journal ownership
gate signs in without binding its device, so pushes 403 forever and
re-logging in does not help.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GSHsQU4pBCzKkPyPeXSwTm
A device whose journal push the hub 403s reported healthy sync between
every pair of remote passes, and never showed the hub's reason for the
refusal — so a user whose device was not registered to their account
re-ran `bdrive login` (which the message told them to), re-checked their
project permissions (write), and had nowhere left to look.
Two causes, both local to the client:
- Cycle recomputed st.Access from scratch at the end of every pass,
including the daemon's cheap local-only ticks that never reach the hub.
Three of those run between remote passes, so the daemon alternated
"read-only on this project" / "access restored; syncing normally" every
few seconds and `bdrive status` reported OK moments after a refused
push. Now each leg records its own verdict — pull clears no-access, push
records read-only or clears it — and a cycle that asked nothing leaves
the last answer standing.
- The hub's own sentence was summarized into "read-only (pull only)",
which describes the STATUS CODE. It is the only thing that tells a
device-registration refusal from a project the user really is a reader
on. It now rides in SyncState.AccessReason and Result.Reason(), printed
by `bdrive sync`, `bdrive status` and the daemon log, and dropped unless
it passes journal.SafeText — hub text reaching a terminal.
The hub's refusal also now names the upgrade: the binding is made by the
login request naming its device, which a CLI older than the gate does not
do, so "run `bdrive login`" alone sent that user in a circle. Hub and CLI
deploy separately, so the skew is the expected state right after the gate
ships.
Claude-Session: https://claude.ai/code/session_01GSHsQU4pBCzKkPyPeXSwTm
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking `restore` in History posted straight to the hub — no dialog —
while the two other web actions that leave the browser (revoke a share
link, remove a file) both confirm first. The gated action was the
reversible one and the effectively-irreversible one wasn't.
The dialog's second line is case-aware, because the two cases really do
differ: swapping a live file's content is walk-backable from History,
but bringing a deleted file back is not — the run card's
"undo — remove file" is the only delete control in the whole web UI, and
a restore produces no run card. So that branch says so instead of
promising an undo the UI can't keep.
The flag needs no new computation: headBlob's "" already marks a path
whose newest op is a delete, so HistoryView passes `recreates` down
beside `restoreSha` (both feed shapes — standalone rows and rows inside
a run card). A row can't decide this itself: an older EDIT row of a
deleted path re-creates the file just as much as the DELETED row does,
and only the feed knows that.
Confirm styling is non-danger on purpose: restore adds content, it takes
none away, so it doesn't wear Remove's red.
Building the missing undo for the ADDED row a restore creates is
deliberately out of scope (Snow scoped this to "add confirmation").
A teammate's agent rewrites a file and yours never hears about it — the only
trace is a `.bdrive-conflict-*` nobody opens. Now the turn-start hook names
the paths that arrived since the last turn: "re-read before editing".
The record lives in a spool (`internal/store/inbound.go`), not in Cycle's
Result, because the daemon usually materializes a peer's change seconds
before the turn starts — so the hook's own cycle sees nothing. materialize
appends every path it writes or removes, `bdrive sync --hook` drains it after
its cycle and renders it under each mount's own prefix (stripping the session
subpath when the run is inside a mount, dropping paths outside it).
Advisory only: nothing blocks, nothing prompts, no per-Write remote call. The
spool is capped, 0600, in the volume dir, and best-effort everywhere — a
spool failure never fails a cycle or a turn.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A ```mermaid fence rendered as a wall of `graph TD` source on both surfaces.
It now renders as an SVG in the hub file viewer and on public /s/<token>
markdown share pages.
Mermaid ships inside the binary (no CDN, so air-gapped self-hosters keep
working) and is imported lazily: a document with no fence downloads none of
it. A fence that doesn't parse — the common case for hand-written wiki
diagrams — keeps today's <pre><code> plus a small note, and one bad fence
never stops the good ones beside it. A blocked or offline chunk lands in the
same place.
The share page is the harder half: it is server-rendered Go HTML with no
JavaScript, and its `sandbox allow-scripts` CSP makes the origin opaque, so a
module script and every import() it makes arrive with `Origin: null`. The CSP
is unchanged and gains no allow-same-origin; instead the real-asset branch of
frontend() now sets Access-Control-Allow-Origin, which only ever touches files
that are already public and cookie-less. The script tag itself is injected
only when the rendered document actually contains a fence.
Also fixes an embed bug this change surfaced: `//go:embed static` silently
skips names beginning with `_`, and Vite's first shared chunk is
`_commonjsHelpers-<hash>.js`. The build passed, the commit looked right, and
the served app was blank. It is `all:static` now, with a test that every file
on disk is in the binary.
`.claude/skills/**` has always synced — deliberately, per the reservation
rule's own comment — but the only sentence saying so sits under the heading
"What beardrive does not sync". Nobody knows.
Track B, the one real bug: `bdrive init ~/.claude` was accepted. The
reserved-path rule matches ".claude/settings.json" on its directory segment,
so at that mount root the file is bare "settings.json" — reserved by nothing —
along with .credentials.json and every saved session under projects/. New
exported config.AgentConfigDir folds the keys of agentHookConfigs the way
ReservedDir folds (case, trailing dots), and init refuses before any network
call or file write. Only that direction leaks: a mount CONTAINING ~/.claude
still sees .claude/settings.json, reserved at any depth.
Track A, the content job: a README Features bullet stating the positive claim,
a 7th use-case page (plus its astro.config.mjs sidebar entry, without which it
is invisible), and a `skills` template appended last to the registry so `docs`
keeps the RECOMMENDED badge. The embed directive becomes `//go:embed all:files`
— a plain pattern drops dot-prefixed paths silently, so the template whose
whole payload is .claude/skills/<name>/SKILL.md would have shipped empty.
templates_test.go's every-directory-holds-a-file rule now marks ancestors, not
just the direct parent: skills is the first template more than one level deep,
and the rule was stricter than its own stated reason (an intermediate
directory on the way to a file is not empty).
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Minting a share link ran zero content checks: a file holding an AWS-shaped
key became a public URL on one click, and the CLI printed nothing but the
link. handleShareCreate now reads the first 1 MiB and runs six anchored
rules between the synced-path check and Shares.Create, answering 409 with
rule ids and line numbers unless the request carries confirm: true.
The matched text never leaves scanSecrets — not into the body, not into a
log line. TestShareSecretNeverEchoed greps both for the planted string,
because a 409 body is the easiest place in this codebase to leak it.
Both callers carry the override, since the gate alone would turn any false
positive into a hard block with no way out: `bdrive share --force`, and the
browser's Share-anyway dialog on modalConfirm (no new component). A path
that already has a live link skips the scan — its content is public
already, so withholding the URL protects nobody — but alreadyPublic drops
links whose creator left the org, since those 404 at /s/ and would
otherwise wave a secrets file straight through.
A failed blob read is 503, not a silent pass: the repo's "degrade rather
than fail" posture is for sync cycles, and a check that skips itself on a
storage hiccup is the false confidence this exists to remove.
Every user-facing string says the file was checked at the moment you shared
it. A link serves the file's LATEST content forever, so a key written into
an already-shared file is never caught — that open loop stays open, and the
copy is the only thing stopping v1 from claiming otherwise.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ⌘K palette searches file names, projects and actions; nothing in the
product searched file contents. Three personas independently typed a phrase
that lives inside a synced file and got "No matches".
`bdrive grep <pattern> [folder]` searches the working folder — RE2 or -F
literal, -i, -l, -n (default 200, 0 = all), output `path:line: text`, exit 0
on match and 1 on none.
It searches exactly what the project syncs, via a new syncer.SyncedFiles that
wraps the existing walkFolder: the one copy of the sync predicate, so an
ignore rule or a narrowed scope excludes a file from search the same way it
excludes it from sync, and .bdrive/ state can never surface. Not Explain,
which countFiles every pruned dir — a grep in a repo with node_modules/ would
walk it in full for a count it discards.
A read stays a read: LoadProject, not ResolveMount (no registry self-heal, no
device enrollment), no session, no flock, and the volume store is opened for
IgnoreAccepted only when it already exists, so a search creates nothing.
Both the path and the matched line go through safeField — a matched line is a
teammate's file content, the widest version of the surface that function
exists for.
The hub-side content index stays deliberately unbuilt; the issue records its
cost. ROADMAP's "Search across the hub" line is reworded rather than removed.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
History showed what an agent run CHANGED. What it read lived in a daily
aggregate with no session dimension, so the two could not be joined and
nobody could answer "when my agent answered, what did it look at — and was
it the fresh version or archive/retired-spec.md?".
The join is one string carried through four places: hook -> spool -> hub ->
run card. A run card now marks each change the run also read, lists the
files it read and never touched, and says on screen why a read can be
missing.
The three landmines the issue asks be named here:
1. Op.Note is USER-SETTABLE (`bdrive sync --note`), so joining reads to
writes on the note string would let any member with write access forge a
note that collides with a teammate's run card and hang their reads off
it. Fixed by adding journal.Op.Session — set only by `bdrive sync
--hook`, never by --note — and joining on that. The note stays settable
and stays untrusted; the join simply never reads it. Op.Session is
additive JSONL and, like Mtime, is never an input to Less or Replay, so
replay determinism is untouched and older ops carry "".
The read half has the same hole one step further on: POST /reads takes
the session id from the CLIENT, so a member could report reads under a
teammate's session and paint files onto their card. Every session row is
therefore pinned to the ownsDevice-validated device, and the query
requires ?session= AND ?device= together — a forged row can only be found
under the forger's own device, which MayActAs guarantees is never
somebody else's.
2. BUCKET CARDINALITY. Putting the session in the read_stats key would take
a 2k-file project from ~2k to ~100k rows/day, into a table ReadLedger
loads whole at boot and full-scans on every heat request, hub-wide — so
it would slow the Dashboard for projects that never ran an agent. This
is the escape hatch the spec itself names, taken up front: session rows
live in their own read_sessions repo, outside ReadLedger.byKey. No
read_stats PK migration, no change to the resident-row count, ?by=device
byte-identical. They get their own retention (session_retention_days,
default 30) which DELETES rather than folds — no heat total was ever
derived from them.
3. READS ARE RECORDED ONLY FOR PATHS IN THE CURRENT REPLAY, so a session
that read a file it then deleted shows a change with no read. That is by
design, and the run card says so in its footer rather than leaving it to
read as a bug.
Privacy ruling, written into internal/webapp/reads.go before anything
serves it: a session id appears only in History responses on the op that
carries it, and as a ?session= filter INPUT. It is never enumerated — no
listing endpoint, no session column in /heat output, nothing new in
?by=device.
Also: PendingReads now dedupes on (path, session), not path alone. Two
agent sessions on one device between syncs used to collapse into one event
carrying whichever session flushed last — one session's reads silently
credited to another.
Tests: journal round-trip + Less-ignores-Session; the forge test (`sync
--note "claude-code session <someone-else's>"` leaves Session empty); a
multi-device syncer test carrying the session through convergence; spool
per-session dedup; hub round-trip, cross-device forge, query contract and
non-enumeration; db_conformance on file, sqlite AND postgres; runs.ts
grouping incl. legacy fallback; a Playwright spec on the seeded run card.
BEA-71 fixed the ordering bug that made the dark block lose to the light
`code` rule, but it stopped at the background: a dark chip still inherits
the body's #eef0f3, so `bdrive init` mid-sentence looks exactly like the
prose around it. That was the reporter's actual ask — "make the text more
distinct".
Inline code now carries the hub viewer's warm tint (#e4d9c4) plus an edge.
The edge is an inset box-shadow, not a border, so the chip's box metrics
don't move between modes and light mode stays byte-identical — verified by
screenshotting the same share page in both schemes before and after.
`pre code` resets both, so a fenced block stays one dark slab instead of a
row of bordered chips.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
History folded every journal of a project on every request — 8-10s on a real
project, and paging made it worse rather than better, since each "load more"
re-downloaded and re-parsed the lot. There is no DB in this path, so no index
was ever going to help.
Journals only GROW: a device appends only to its own (the one-writer
invariant) and the hub's appendOp rewrites its key with strictly more bytes.
So the (Size, Modified) that List already reports proves a parse is still
current — no staleness window, no expiry, no new Backend method. A warm
request now pays one List and nothing else.
The cold path can never be helped by a cache, so the Get loop is concurrent
too (errgroup, limit 8) instead of one serial round trip per device.
Files() reads the same funnel, so folder listings get it for free.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
/no-such-project-xyz/some/file.md used to redirect to whichever project the
fallback chain picked, dropping the path — nothing on screen distinguished
"that link is wrong" from "you opened your project."
An unknown route.project now renders a "Project not found" panel at the URL
as typed, mirroring the org-not-found page two blocks up: shell, sidebar and
account bar stay mounted, and "Back to <name>" points at the same project the
fallback picks today. The fallback chain itself is unchanged, and "/" still
redirects to the remembered project (BEA-75).
All four redirects below the flag rewrite the address bar off current.id, so
they are gated together — /bad-id/insights and /bad-id/notes/ would otherwise
undo the fix on their own.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
There is no rename in beardrive: the scanner emits a put at the new path and
a delete at the old, same device, same blob, one cycle. Everything keyed on a
path therefore broke the moment a file moved — the viewer 404'd, history lost
the file's own past versions, restore refused them, and a share link either
404'd or silently served whatever unrelated file later took its address.
internal/webapp/moves.go derives the pairing from the ops the replay already
walks, cached with the snapshot. Deliberately not a rename op: journal.Less
and Replay are what every device converges to, and every already-shipped
journal would still need the heuristic to read its own history.
The two rules point in opposite directions on purpose. A viewer URL is an
address, so a LIVE path always wins and only an empty one redirects. A share
token is a promise about one file, so it follows the file even when a new one
takes the old address — and 404s forever once the file is deleted.
Nothing here writes an op or touches sync.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
README.md:499 promised "share/history/upload actions" in the command
palette. Upload has never existed there (browser upload is deliberately
absent, Browser.tsx:175), download went unmentioned, and share/download
are file-scoped — so a reader on a folder route goes hunting for controls
that are correctly hidden. The doc comment at Palette.tsx:8 carried the
same wrong list, so fixing only the README would leave the next reader of
the component with the same picture.
Prose and a comment only; no code path changes. `npm run build` produces
a byte-identical internal/webapp/static (source comments are stripped
from the bundle), so no assets to commit.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A signed-in account with zero projects landed on / with the create dialog
already open over the onboarding page. The page renders its own "New
project" button (#ob-new), so the same call to action appeared twice and
the rear one was permanently pointer-intercepted — Playwright retried a
click against it for 30s before failing.
The auto-open was deliberate: "With no projects at all there is nothing
else on the page to do." That stopped being true when the empty state
gained the agent paste-prompt card — the route the docs treat as primary,
which the dialog was covering.
Delete the effect and its ref; fix the two comments that documented it;
rewrite the e2e test that asserted the auto-open by name.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Project settings at 1440x900 ended at People. Public links — the section
that answers "is anything of ours public right now?" — was below the fold
of #content, the app's only scroll container, and with macOS overlay
scrollbars nothing at rest said there was more.
#content now takes a real scrollbar. The plan called for scrollbar-width
+ scrollbar-color alongside ::-webkit-scrollbar; measured, that combination
is a no-op: Chromium drops every ::-webkit-scrollbar rule as soon as either
standard property is set on the same element, and the standard properties
alone leave the macOS overlay bar, which takes no width and is invisible at
rest. So the standard properties sit behind @supports not
selector(::-webkit-scrollbar) — Firefox only. Verified: 10px reserved in
Chromium, 0 on touch.
Public links also moves from fourth card to second (General → Public links
→ People → About → Danger zone), so the security answer is above the fold
even without the cue.
browse.spec reached the shares table by .last(), which the reorder would
have silently repointed at the members table — both render through
AdminTable. It selects .shares-table now.
Known gap: Firefox on macOS always uses overlay scrollbars and no CSS
overrides it, so the bar there stays hidden at rest — that is an OS
setting, not something this can fix.
The public-links panel is where a member answers "is anything of ours
public right now?". SharesTable read an empty array as a settled answer,
and both callers hand it `shares || []` while the request is still in
flight — so the panel printed "No public links." as a confident NO, then
swapped to a table listing an active, never-expiring link.
Fix at the choke point: an optional `loading` prop honored above the
empty branch, in the same .admin-list/.admin-empty shell so the section
is one row tall either way and doesn't jump when the data lands. Wired at
both call sites — project Settings and the org-wide cross-project audit,
which had the identical bug.
`isLoading`, not `isPending`: OrgAdmin's shares query is `enabled: owner`,
and TanStack reports isPending true forever for a disabled query.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Can my Windows teammate join?" got three answers from three official
surfaces: README's feature list said macOS & Linux, its CLI table
documented an HKCU Run entry on Windows, and the hub's Installation page
named no OS at all.
Windows autostart is real code that cannot run — internal/store's flock
and internal/daemon's Kill/Setsid are unix-only, so GOOS=windows does
not build. The fix is the docs, not the port: every Windows claim comes
out of README, web/docs and `bdrive autostart`'s own help, and the
Installation page gains one line naming the supported systems.
No Go source is deleted; internal/autostart/autostart_windows.go stays
compiled-but-dormant for whenever the port happens.
Every /s/<token> hit was already recorded as a share-kind read, carrying
both a count and a timestamp — and then thrown away at the UI layer. The
Public links table showed only who shared a file and when, six inches
below a file header that already said "1 shared". Two personas filed it
independently on the same tour.
The number now rides the shares list:
* ReadLedger.ShareOpens(project) aggregates share-kind buckets per path,
all-time. Share-kind only is what makes Last mean *last opened* —
HeatEntry.LastRead is cross-kind, so a member viewing the file in the
hub would otherwise move the date.
* shareJSON takes the project's opens map, built ONCE per project by the
caller and indexed per row. Both callers — the project list and the
org-wide audit — hoist it above their loops; a per-share call would be
a full byKey scan per row.
* Counts, never openers. The share actor is token+"/"+IP, a public
credential joined to an IP, and it stays in the ledger. There is no
distinct-openers field, deliberately.
* Reads off means the keys are ABSENT, not zero: `0` would claim nobody
has opened a link on a hub that never looked.
shareDetail() is the leverage — the settings table, the org-wide audit and
the file page's share banner all render through it, so one string function
covers three surfaces. Once the row carried the receipt it truncated to
"3 op…", so the detail cell wraps instead of ellipsizing; the path keeps
its ellipsis, since it is a link with a tooltip and the column that can be
arbitrarily long.
Counted per FILE, not per link: heat is keyed by path, so two tokens on one
file report the same number. Worded that way in the section copy, alongside
the other honesty — opens are debounced visits, not requests.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A .csv already previewed — as raw text in a <pre>, columns lining up only
if the file happened to be padded. It now renders as an HTML table with the
first row as a header.
The parser is a new pure lib/csv.ts (~50 lines of RFC 4180: quoted
delimiters, "" as a literal quote, newlines inside quotes), so no
papaparse. It never throws: null means "not a table" — an unterminated
quote, or a file with no delimiter at all — and the caller falls back to
the very <pre> it renders today. That fallback is structural rather than a
second code path, because TextView gained a `delim` prop instead of a new
component: it also keeps the ["text", fileURL] query key a restore
invalidates and the retry:false a pinned ?v= version needs.
.tsv is new here — it used to fall through to SniffView and render as
text. The delimiter comes from the extension, never from sniffing.
Big files are capped at 5,000 rows with the count stated on screen
(virtualization is out of scope). Wide files scroll inside .csvbox, whose
rules are scoped under that class on purpose: the file pane carries
.markdown, and the plain .markdown table rules — including the ≤900px one
that turns a table into its own scroller — would otherwise out-specify a
bare .csvview and give the page two nested scrollers.
Not doing: sorting, filtering, search, editing, XLSX.
docs.beardrive.ai shipped no robots.txt, so nothing on that host named the
sitemap — a crawler arriving at the subdomain had to guess the URL or be
handed it in Search Console. And every entry was a bare <loc>: no freshness
signal at all, on the site whose whole value is being current.
Each URL now carries the commit date of the markdown behind it, read from one
`git log` for the whole tree. The build refuses to guess: in a shallow clone
(the default for CI checkouts) git can only attribute every file to the single
commit it has, so lastmod is omitted entirely rather than claiming the site
changed wholesale on every deploy — Google discounts a sitemap that does that,
which would cost more than the absent dates. Hosts that want the dates need
full history; README says so.
Declaring @astrojs/sitemap explicitly replaces the copy Starlight adds for
itself rather than duplicating it — that's the supported way to reach these
options, and Starlight's own version only configures i18n, which this
single-language site doesn't use.
Adds `npm run check:sitemap <origin>`: robots.txt -> index -> every advertised
URL returns 200, the checks Search Console runs, against a local preview or
against production. Run against production today it fails on the missing
Sitemap: line, and reports the deployed site is several commits behind the
repo — /concepts/permissions/ and /reference/migration/ are live 404s.
The RECOMMENDED badge renders on options[0]; the initial selection was
hard-wired to "" (the last row, Empty project), so on any hub shipping
templates the dialog contradicted its own advice — and the default was the
option that produces a project with nothing to look at.
Hoist the options array above the state and seed `template` from
options[0].value: badge row and checked row are now the same element by
construction, not by coincidence. On a template-less hub options[0] is
"I already have a folder", which still creates an empty project.
The e2e test that pinned the old default now asserts the invariant (badged
row === checked row) rather than a title, and checks that creating without
touching the radios actually seeds the template.
The share page already followed the system, but its dark @media block sat
ABOVE the light pre/code/blockquote/table rules at equal specificity, so
every light rule after it won. A dark-system visitor got a white frontmatter
slab, a white code block and light-grey table borders on a near-black page —
the surface strangers see first reading as a different product.
Source order is the whole fix: the block moves to the end of the stylesheet
and gets completed there, which repairs pre/code for free. Values are the
hub's @theme tokens from frontend/src/tw.css instead of the hand-picked greys
(#c6cbd3 body text, #3a3a44/#888 footer) that were the "different product"
half of the complaint.
Light mode is pixel-identical — only the dark block moved. Response headers
(sandbox CSP, nosniff, referrer) are untouched.
The test asserts placement, not presence: "a dark rule exists" passed while
the page was still wrong, so it checks the dark block comes after the last
light literal.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Below 900px the file view hid the who/when/how-hot line outright
(`#meta { display: none }`) and the History run header ellipsised its
note and author to `claude-…` / `Alice <ali…` — the line the product is
differentiated by, gone exactly on the surface people catch up from.
CSS-only, inside the existing `@media (max-width: 900px)` block:
- `#topbar` wraps (`height: auto; min-height: 52px`) and `#meta` takes its
own full-width row, left-aligned and wrapping. `order: 1` is what keeps
Search / Share / ⋯ on row 1 — meta precedes them in the DOM, so a bare
flex-wrap would drag them down. `#meta:empty` keeps folder, dashboard
and history routes from gaining a blank strip.
- `.hrun-head` wraps; the note loses its 46% cap and both spans stop
ellipsising, with `.hrun-meta` on its own line under the note and the
time still on row 1.
Desktop (≥901px) is untouched — every rule lives inside the breakpoint.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A read-only member seeing the People matrix and every active public link
is deliberate — the owner re-confirmed it against Google Drive, where a
viewer can see who has access. Nothing asserted it: TestReadOnlyMemberRoutes
only checks GET .../shares is not 403, so a hardening pass that returned an
empty list (or dropped the creator field) to read members would pass every
test in the repo.
Adds TestReadMemberSeesSharesAndGrants — 200 plus the link's token, path,
url and creator from a read-only session — and extends the two rationale
comments the next reader lands on instead of adding a third copy.
No route change, no UI change; the ShareBanner edit is a comment, so
internal/webapp/static is unchanged.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The page named three read types and let you filter two. The missing chip was
share — traffic from public links an owner minted, which is the category they
most want to isolate.
Everything but the lens already spoke "share": heatTotal, heatText and
hotPathSplit all carry it, and /heat returns it per path. So widening the
union makes the treemap, the scatter and the Hot path arithmetic correct for
free. The one place that decided anything was the Hot path bar, which
branched agent-vs-human and would have painted shared reads in somebody
else's colour; it now looks the pure lens up in a table instead.
The e2e seed had no share reads at all, so the lens could not be asserted.
It gains one on notes/deep/topic.md — a path no other assertion counts, so
nothing else's totals move.
BEA-62
The Dashboard treemap painted the full 0-300d green->amber->red ramp even
when every file in scope was the same age, so an all-fresh project read as
"everything is healthy" - while the legend directly underneath admitted the
colour carried no signal. The flag that legend computed never reached the
cells that made the claim.
isFlatRange now lives one component up, in Treemap, which owns both the cells
and the legend. Flat scope: one neutral grey fill (deliberately off the ramp),
an inert legend swatch, and a statement instead of an apology. Non-flat scope
is untouched. Computed over every scoped file, so it follows the folder scope
and never the read-type lens.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(webapp): /history?path=<file> shows that file's history instead of the whole project (BEA-64)
The History API takes ?path=/?prefix=, so a reader who has seen the API
types the query form at the page too. The router dropped it: viewTarget
stayed empty, the project-wide feed rendered, and nothing said a parameter
had been ignored — read as "this file has no history" or "history is
broken".
Honour it and normalize, the same shape as the legacyView and trailingSlash
redirects already there: parseRoute sets viewTarget from ?path=/?prefix=
(only on the history view, only when no path segment named a target) and
flags the URL for replacement; HubApp swaps in the canonical
/history/<target> URL with the filters intact.
The legacyView redirect next door dropped history filters on its own hop —
one-argument fix in the same call shape.
* docs(architecture): Route.queryTarget joins the normalization flags (BEA-64)
