diff --git a/CHANGELOG.md b/CHANGELOG.md
index cd4e6bb..67705c0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,52 @@
 # Änderungen
 
+## V1 — Release Candidate 9, 18. August 2026
+
+### Sicherungsart je Auftrag
+
+Bisher entschied die Anlage allein: Liegt ein Elternbackup vor, wird
+inkrementell gesichert. Jetzt wählbar —
+
+- **inkrementell** (Standard, bisheriges Verhalten),
+- **immer voll**, oder
+- inkrementell **mit festem Volltag**, etwa „immer freitags".
+
+Der Wochentag wird in der **Zeitzone des Zeitplans** bestimmt. Rechnete der
+Server in UTC, bekäme ein Betreiber in Berlin seine Vollsicherung am
+Donnerstagabend und wunderte sich, warum sie freitags fehlt.
+
+**Der Platzbedarf steigt bei „immer voll" nicht nennenswert** — unveränderte
+Blöcke werden dedupliziert. Was steigt, ist die Laufzeit. Das steht so in der
+Maske, weil es die häufigste Verwechslung ist.
+
+Migration 000014 mit drei CHECKs. Der dritte lehnt „immer voll" zusammen mit
+einem Wochentag ab: Dann ist ohnehin jeder Lauf voll.
+
+### Behoben
+
+- **Das Aufnahme-Token eines Agenten zeigte „undefined".** Das Feld heißt
+  `token`, nicht `enrollment_token` — Letzteres ist der Name im *Anfrage*körper
+  der Registrierung. Der dritte Formfehler dieser Art; alle konsumierten
+  Endpunkte sind jetzt gegen den laufenden Dienst abgeglichen statt aus der
+  Struktur abgeleitet.
+
+### Aufnahmedialog mit Anleitung
+
+Vollständige Anleitung für **Linux und Windows**, umschaltbar, mit fertig
+ausgefüllten Befehlen — Serveradresse und Token eingesetzt, jeder Schritt
+einzeln kopierbar. Eine Anleitung mit Platzhaltern führt zuverlässig dazu, dass
+jemand `<token>` wörtlich einsetzt.
+
+Dazu die beiden Stolperstellen: `--state` erwartet eine **Datei**, und der
+Agent braucht Schreibzugriff auf das Repository.
+
+### update.sh rüstet die Wiederherstellungsfläche nach
+
+Sie kam mit rc8 dazu; eine Anlage aus einer älteren Fassung hat sie nicht. Ohne
+sie scheitert jede Wiederherstellung an `ProtectSystem=strict`. `update.sh`
+legt sie jetzt an und trägt sie in `ReadWritePaths` ein — ein Schritt, den man
+von Hand ausführen muss, wird übersehen und fällt erst im Ernstfall auf.
+
 ## V1 — Release Candidate 8, 18. August 2026
 
 Wiederherstellung von Dateien und Ordnern mit Auswahl statt Textfeld — und die
diff --git a/docs/backup-engine.md b/docs/backup-engine.md
index 85ee1b0..aa6a437 100644
--- a/docs/backup-engine.md
+++ b/docs/backup-engine.md
@@ -89,6 +89,46 @@ Wiederherstellung: 355 MiB/s, Ergebnis bitgenau identisch zur Quelle.
 
 Ein früherer Messlauf zeigte 1021-fache Kompression. Diese Zahl war wertlos: die Testdaten waren periodisch erzeugt und damit unrealistisch gut komprimierbar. Belastbar sind nur Messungen mit inkompressiblen Daten.
 
+## Sicherungsart je Auftrag
+
+Der Standard ist **inkrementell**: Liegt ein Elternbackup vor, wird nur
+Geändertes gelesen. Zwei Abweichungen lassen sich je Auftrag einstellen.
+
+| Einstellung | Wirkung |
+| --- | --- |
+| `incremental` | Erster Lauf voll, danach inkrementell. Standard |
+| `always_full` | Jeder Lauf liest die gesamte Quelle |
+| `full_backup_weekday` | Zusätzlich an einem festen Wochentag voll |
+
+**Der Platzbedarf steigt bei „immer voll" nicht nennenswert.** Unveränderte
+Blöcke werden dedupliziert und liegen weiterhin nur einmal im Repository. Was
+steigt, ist die **Laufzeit**: Jeder Lauf liest, hasht, komprimiert und
+verschlüsselt alles neu. Gemessen (Phase 6): 190,7 MiB in 1 815 ms gegen
+4,8 MiB in 133 ms bei einer geänderten von 41 Dateien.
+
+Wer das verwechselt, hält „immer voll" für teuer im Speicher und plant seinen
+Nachtbetrieb falsch.
+
+Wann eine Abweichung sinnvoll ist:
+
+- **Immer voll**, wenn das Repository außer Haus geht oder auf einen
+  Datenträger geschrieben wird, der einzeln weggetragen wird.
+- **Wöchentlich voll** als üblicher Kompromiss: unter der Woche schnell, an
+  einem festen Tag einmal vollständig.
+
+Der Wochentag wird in der **Zeitzone des Zeitplans** bestimmt. Ohne diese
+Umrechnung liefe derselbe Auftrag auf zwei Servern an verschiedenen Tagen voll
+— und ein Betreiber in Berlin bekäme seine Vollsicherung am Donnerstagabend.
+
+Ein Widerspruch — „immer voll" **und** ein Wochentag — wird von der Datenbank
+abgelehnt, nicht stillschweigend aufgelöst.
+
+Zur Einordnung: Syncova-Manifeste sind vollständig (Phase 6). Eine
+Zusatzsicherung trägt die Blockverweise des Elternbackups mit, ein Restore liest
+genau **ein** Manifest, und das Löschen eines alten Backups kann ein neueres
+nicht beschädigen. Der Unterschied liegt also in der Laufzeit, nicht in der
+Wiederherstellbarkeit.
+
 ## Grenzen des aktuellen Stands
 
 **Das Manifest wird vollständig im Speicher gehalten.** Das ist die wichtigste offene Baustelle. Jeder Blockverweis kostet rund 200 Byte: