Gegenbuch: Pruefmodus schreibt nicht mehr, Widerspruch aufgeloest (R181)

R181-01: Der Pruefmodus sagte zu, nichts zu veraendern und kein Schreibrecht zu
brauchen - und pushte trotzdem, weil ankerNachziehen() in jedem Modus lief. Ein
read-only Audit mutierte damit still das geteilte Substrat.

R181-02: Ein Widerspruch zwischen den eigenen Fixes. R180-01 erhebt die
Serversperre auf refs/notary/* zur tragenden Pflicht, R180-02 verlangt dort
Schreibrecht zur Selbstheilung. Sobald je ein Anker fehlte, bekam jeder
read-only pruefende Auditor dauerhaft einen Fehler auf einer voellig gueltigen
Kette, den er nicht beheben konnte. Fix: Reparieren nur im Notar-Schreiblauf,
im Pruefmodus wird der fehlende Anker gemeldet.

Eigener Rueckgabecode 5: "Anker unvollstaendig" ist nicht "nicht feststellbar" -
die Kette ist gueltig, nur das Substrat-Gedaechtnis unvollstaendig, ein
benannter reparierbarer Defekt. Dieselbe Trennung wie bei Genesis/Adoption.

Empirisch beantwortet: Die Notar-Identitaet laesst sich eng auf das Anlegen von
refs/notary/* beschraenken, ohne Loeschen oder Ueberschreiben - serverseitig
unterscheidbar an der Null-OID. Mit pre-receive-Hook verifiziert: Backfill
greift, Loeschen und Force-Overwrite bleiben abgewiesen. Hook als Beispiel in
der README.

Verifiziert: read-only --check mit fehlendem Anker -> Code 5, nichts gepusht;
Notar-Schreiblauf unter derselben ACL -> Anker nachgetragen, exit 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/todo.md

@@ -97,6 +97,39 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🧮 Gegenbuch: Pruefmodus schreibt nicht mehr, Widerspruch aufgeloest (Pentest R181)** (2026-08-18)
+  - **R181-01 (LOW→MED)** – Der Pruefmodus sagte zu, nichts zu veraendern und
+    kein Schreibrecht zu brauchen – und pushte trotzdem: `ankerNachziehen()`
+    lief in JEDEM Modus. Ein „read-only“ Audit mutierte damit still das
+    geteilte Substrat. Fix: Nachziehen nur im Schreiblauf.
+  - **R181-02 (MEDIUM) – ein Widerspruch zwischen meinen EIGENEN Fixes.**
+    R180-01 erhebt die Serversperre auf `refs/notary/*` zur tragenden Pflicht;
+    R180-02 verlangt genau dort Schreibrecht zur Selbstheilung. Ergebnis:
+    Sobald je ein Anker fehlte, bekam jeder read-only pruefende Auditor
+    dauerhaft einen Fehler auf einer **voellig gueltigen** Kette – und konnte
+    ihn nicht beheben.
+    Fix: Reparieren ist Sache des Notar-Laufs; im Pruefmodus wird der fehlende
+    Anker gemeldet, nicht repariert.
+  - **Eigener Rueckgabecode 5** (seine Frage b): „Anker unvollstaendig“ ist
+    NICHT „nicht feststellbar“. Die Kette ist geprueft und gueltig, nur das
+    Substrat-Gedaechtnis ist unvollstaendig – ein benannter, reparierbarer
+    Defekt mit klarer Handlungsanweisung. Ihn in Code 3 zu werfen hiesse, eine
+    Anweisung als Ungewissheit zu melden; dieselbe Trennung wie bei
+    Genesis/Adoption.
+  - **Seine Frage (a) empirisch beantwortet:** Die Notar-Identitaet laesst sich
+    eng auf das ANLEGEN von `refs/notary/*` beschraenken, ohne ihr Loeschen
+    oder Ueberschreiben zu geben – serverseitig unterscheidbar an der Null-OID
+    beim Anlegen. Mit `pre-receive`-Hook verifiziert: Backfill greift (exit 0),
+    Loeschen und Force-Overwrite werden weiterhin abgewiesen. Der Hook steht
+    als Beispiel in der README.
+  - Verifiziert: read-only `--check` mit fehlendem Anker → **Code 5, nichts
+    gepusht** (Anker-Anzahl vorher/nachher identisch); Notar-Schreiblauf unter
+    derselben ACL → „Fehlende Anker nachgetragen: 1“, exit 0.
+  - Seine Non-Findings uebernommen: Die Backfill-Zuordnung ist gegen das
+    PIN-Modell robust – jeder Commit mit echter Ledger-Aenderung ist non-merge
+    und muss keyA-signiert sein, sig-exempte Merges tragen keinen Inhalt in die
+    Zuordnungsliste.
+
 - [x] **🛑 Gegenbuch: Anker belegen nichts mehr, Anker-Verlust wird laut (Pentest R180-01/-02)** (2026-08-18)
   - **R180-01 (MEDIUM)** – Genau die Unsicherheit, die ich selbst benannt
     hatte, bestaetigt: Der Code nahm den **hoechsten noch vorhandenen**