uid-delta-brief.md:
UIDVALIDITY+UID waehlt nur KANDIDATEN aus. Body wird weiterhin geladen,
Identitaet weiterhin aus canonicalMessageBytes berechnet. body_sha256
bleibt die Wahrheit; die UID spart nur den Download alter Kandidaten.
backup-brief.md (Pos-81):
DB und mbox sind NICHT symmetrisch abhaengig - mbox ohne DB ist per
Reindex heilbar, DB ohne mbox ist wertlos. Gefaehrlich ist allein
neuere DB + aeltere mbox. Daraus die Reihenfolge-Regel: DB zuerst.
Gemessen: /mnt/DATA ist ext4 ohne LVM -> atomarer Snapshot unmoeglich.
Aber mbox ist strikt append-only (06-mbox.go:61, kein O_TRUNC/Truncate/
Rename), und MAX(file_offset+frame_len) aus mbox_index ist die exakte
Schreib-Wasserlinie - ueber alle 228 mbox-Dateien 0 Abweichungen.
Daraus: VACUUM INTO + Praefix-Kopie = konsistenter Stand OHNE Stillstand.
Falle notiert: mbox_index_state.indexed_bytes ist NICHT die Wasserlinie.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Volllauf laedt strukturell jede Quellmail, bevor er weiss, ob er sie hat -
die Identitaet ist der Body-Hash. Belegt am Lauf e.klarner: 46.415 gelesen,
10.023 geschrieben. Der Nachtlauf zieht so ~42 GB/Nacht.
Die UID ist die einzige Kennung ohne Body und bricht die Ringabhaengigkeit.
UIDVALIDITY-Pruefung ist dabei nicht Beiwerk, sondern Voraussetzung.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
