rebrand to notevi: one CLI over the jj sidecar

vr and vrsite become a single binary. vrsite/ folds into a web package in
one module (0x4200.cafe/notevi); "notevi web" serves and exports exactly
what vrsite did, and "notevi read/grep/note/query" is unchanged.

The sidecar is renamed with it: notevi_log, notevi-log.jsonl, and the
description "private: notevi log". The pre-rebrand names are still
recognized, so an old repository opens and reads; it is renamed in place
on the first write, or up front with "notevi migrate DIR...".

That rename cannot be a single mv inside jj run. jj only auto-tracks a
*new* file in the run working copy below a size limit it does not take
from the command line, so writing a whole log under a name the change has
never held is silently dropped while jj reports success. ensureLogFile
creates the file empty first and lets every later byte be a modification
of a tracked file, which snapshots at any size; that also fixes the same
latent bug when importing a large legacy vr-log.jsonl.

Adds a bem-te-vi mark (favicon and nav brand) and a README.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

1 files changed, 19 insertions, 17 deletions

diff --git a/doc.txt b/doc.txt
index 87b0db4..e3fe5fc 100644
--- a/doc.txt
+++ b/doc.txt
@@ -1,28 +1,30 @@
-vr — read code and take notes; every call is logged in a private jj sidecar.
+notevi — read code and take notes; every call is logged in a private jj sidecar.
 
 read a file (line-numbered, relative to a jj revision):
-  vr read FILE                  whole file
-  vr read FILE:120-180          line range (or FILE:120 for one line)
-  vr read -r REV FILE           the file as it is in another jj change
+  notevi read FILE                  whole file
+  notevi read FILE:120-180          line range (or FILE:120 for one line)
+  notevi read -r REV FILE           the file as it is in another jj change
 
 search (regex):
-  vr grep PATTERN [PATH]        search the working copy
-  vr grep -r REV PATTERN PATH   search another change (scope with PATH)
+  notevi grep PATTERN [PATH]        search the working copy
+  notevi grep -r REV PATTERN PATH   search another change (scope with PATH)
 
 take a note while reading (ids count up from 1 per session):
-  vr note -f FILE:10-42 TEXT...             about a line range
-  vr note -t struct -f FILE:10-42 TEXT...   about a struct/enum/const/fn/...
-  vr note -r REV -f FILE TEXT...            about code in another change
-  vr note -reply 12 TEXT...                  reply to log-wide note #12
+  notevi note -f FILE:10-42 TEXT...             about a line range
+  notevi note -t struct -f FILE:10-42 TEXT...   about a struct/enum/const/fn/...
+  notevi note -r REV -f FILE TEXT...            about code in another change
+  notevi note -reply 12 TEXT...                 reply to log-wide note #12
 
-vr query -op note shows both the session-local id and the log-wide id used by
--reply and vrsite /note/N permalinks.
+notevi query -op note shows both the session-local id and the log-wide id used
+by -reply and by the /note/N permalinks in `notevi web`.
 
 REV is any jj revset; default @ (the working copy).
-The repo-local revset alias vr_log names the log change. vr creates it lazily
-as an anonymous child of root(); it never appears in the project working copy.
-Every new entry records the full target change id and exact target commit id.
-An existing repo-root vr-log.jsonl is read and imported on the first append;
-vr leaves that legacy working-tree file for you to remove after migration.
+The repo-local revset alias notevi_log names the log change. notevi creates it
+lazily as an anonymous child of root(); it never appears in the project working
+copy. Every new entry records the full target change id and exact target commit
+id. A sidecar left by the older vr tool is renamed in place the first time
+notevi writes to it, and an existing repo-root vr-log.jsonl is read and imported
+on the first append; notevi leaves that legacy working-tree file for you to
+remove after migration.
 The sidecar has no bookmark and is deliberately local-only: a fresh clone will
 not contain it, so include the jj repository in backups when notes matter.