docs: describe 3.0.0's local-speed writes and leave batched trashes and moves for later

README.md

@@ -38,8 +38,9 @@ scriptable CLI.
 - **Synced folders.** Back up folders such as `~/Documents` under your computer in Proton Drive,
   as a full two-way copy or online only. Gitignore-style `.pdfsignore` rules, conflict copies
   instead of overwrites, pause and bandwidth limits.
-- **Safe writes.** Changes are staged on disk and queued before they are acknowledged, so they
+- **Works at local speed.** Making, renaming and deleting files and folders returns at once, online
-  survive a lost connection, a crash or a reboot and upload when they can.
+  or offline. Changes are staged on disk and queued before they are acknowledged, so they survive
+  a lost connection, a crash or a reboot and reach Drive when they can.
 
 **Desktop app**
 
@@ -50,7 +51,8 @@ scriptable CLI.
 - **Sharing.** Invite people as viewer, editor or admin, create public links with password and
   expiry, accept invitations.
 - **Sync overview.** What is uploading, what is waiting, what failed and why, and a history of
-  what happened.
+  what happened. A change Drive refuses (storage full, access taken away) shows at once, on the
+  file too, and can be exported or discarded.
 - **Tray icon** with status, pause and quick actions, and a **search launcher** (`pdfs-prompt`)
   that searches Proton Drive and your home folder together, as its own window, through fuzzel,
   rofi or wofi, or live in `fzf`.

docs/MILESTONE-3.0.0-STATUS.md

@@ -77,6 +77,9 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          target; the drain takes 47 s on LAN and 247 s on Wi-Fi. Most of a create on Wi-Fi is
          its read-back waiting for Drive to list the new node (250 ms, then 1 s), so batching
          (step 8) helps trashes and moves, not creates.
+   - [x] Batched trashes and moves: left for after 3.0.0 (see below). The target is met
+         without them, the drain waits on the creates' read-back, and splitting one answer into
+         many results is where the B15x to B17x races lived.
 4. **Done-when checks**:
    - [ ] Simulation passes on the Wi-Fi profile: `one_client_on_a_slow_link` failed in CI on
          seeds 2 and 3. Two bugs (B127, B151) and a harness gap: a settle did not read the log, so
@@ -155,6 +158,12 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
   3.0.0).
 - **Phase 4**: one applier for remote changes.
 - **Phase 5**: mirror folders on the same planner and executor.
+- **Batched trashes and moves** (plan step 8). Not needed for the §7 target: the syscalls take
+  5.2 s on LAN and 5.0 s on Wi-Fi. The drain's time goes to the creates' read-back (250 ms,
+  then 1 s each), which batching does not shorten. A batch call answers for many ops at once,
+  and splitting that answer back per op is the step the B15x to B17x races came from. First
+  measure `rm -r` of 1,000 files on Wi-Fi. If it is slow, drop the queued trashes of a trashed
+  folder's children before batching anything: trashing the folder takes them with it.
 - **Any time**: `Size` and block geometry as types; a deadline on the remote calls outside
   the drain (the drain's have one: `link::upload_deadline`, `Core::block_on_within`).
 - Open questions in §12 of the milestone.

docs/ROADMAP.md

@@ -1,15 +1,42 @@
 # Roadmap
 
-Planned work and open verification, as of 2.5.0. Individual defects and their status live in
+Planned work and open verification, as of 3.0.0. Individual defects and their status live in
 [BUGS.md](BUGS.md), which is the authoritative ledger; this page groups what is left by theme.
 Nothing here is a promise of a date.
 
+- [Sync engine](#sync-engine)
 - [Data safety and recovery](#data-safety-and-recovery)
 - [Features](#features)
 - [Performance and correctness](#performance-and-correctness)
 - [Verification still owed](#verification-still-owed)
 - [Release assurance](#release-assurance)
 
+## Sync engine
+
+3.0.0 records changes made through the mount locally and sends them from the queue
+([MILESTONE-3.0.0.md](MILESTONE-3.0.0.md)). What comes after it:
+
+| Item | State | Notes |
+|---|---|---|
+| Remove the online path | Not started | The old way of sending a change before the syscall returns, and the `local_first` switch that brings it back, go in the release after 3.0.0 |
+| One applier for remote changes | Not started | Phase 4 of the milestone: a remote tree, and remote changes applied through the same planner as local ones |
+| Synced folders on the queue | Not started | Phase 5: synced folders sent by the same planner and executor as the mount |
+| Batch trashes and moves | Deferred | See below |
+
+**Batching trashes and moves.** `trash_nodes` and `move_nodes_streaming` take up to 150 nodes per
+call, but the queue still sends one node per call. It was left out of 3.0.0 on purpose:
+
+- The speed target of the milestone (§7) is met without it. Making 1,000 files in 100 folders
+  takes 5.2 s on a LAN and 5.0 s on Wi-Fi.
+- What the queue spends its time on is the creates. Each one waits for Drive to list the new node
+  before it counts as landed (250 ms, then 1 s), and batching does not help with that.
+- Sending many ops in one call means splitting one answer back into many results. Races in
+  exactly that step were the largest class of bugs found for 3.0.0 (B15x to B17x).
+
+Before building it, measure `rm -r` of a folder with 1,000 files on Wi-Fi. If that is slow, the
+cheaper fix is to drop the queued trashes of the files in a folder when the folder itself is
+trashed, since trashing the folder takes its contents with it.
+
 ## Data safety and recovery
 
 | Item | State | Notes |