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>

tools/audit-notary/README.md

@@ -103,6 +103,19 @@ Standardzustand.
 > einen niedrigeren stehen lässt, senkt damit den Vergleichswert selbst – und
 > in-repo ist das von „gab es nie" nicht zu unterscheiden.
 >
+> **Die Notar-Identität braucht dort eine eng gefasste Ausnahme:** Sie muss
+> `refs/notary/*` **anlegen** dürfen, aber ausdrücklich **nicht löschen oder
+> überschreiben**. Sonst hebelt eine kompromittierte Notar-Identität genau den
+> Schutz aus, um den es hier geht. Server-seitig ist das unterscheidbar – ein
+> `pre-receive`-Hook sieht beim Anlegen die Null-OID als alten Wert:
+>
+> ```sh
+> # refs/notary/*: nur anlegen, niemals ändern oder löschen
+> case "$ref" in refs/notary/*)
+>   [ "$old" = "0000000000000000000000000000000000000000" ] || exit 1 ;;
+> esac
+> ```
+>
 > Deshalb begründen Anker **keine** Unversehrtheit. Sie können ein
 > Zurückspulen *widerlegen* (wenn ein hoher Anker nicht mehr im Kopf steckt),
 > aber nie belegen, dass nichts fehlt. Ein `--check` aus frischem Klon erkennt
@@ -198,6 +211,7 @@ Deshalb gilt jetzt:
 | 0 | alles in Ordnung, Checkpoint angehängt (bzw. Prüfung bestanden) |
 | 1 | Betriebsfehler (Konfiguration, Commit oder Push fehlgeschlagen) |
 | 2 | **Befund** – Widerspruch zwischen CRM und Gegenbuch, oder ungültige Signatur |
+| 5 | **Anker unvollständig** – die Kette ist gültig, aber `refs/notary/seq-N` fehlt. Reparierbar durch einen Notar-Schreiblauf |
 | 4 | **Wächter-Gedächtnis fehlt** – Erstinbetriebnahme unbestätigt, oder Speicher nach der Etablierung verloren |
 | 3 | beglaubigter Stand nicht abschließend feststellbar – Remote fehlt/unerreichbar, erste Beobachtung, Zurückspulen nicht ausschließbar, **oder** Checkpoint erstellt aber nicht verankert |
 
@@ -210,8 +224,14 @@ Code 3 heißt „ich weiß es nicht" – und das ist ausdrücklich kein Freibrie
 node notary.mjs --check
 ```
 
-Führt alle Kontrollen aus, hängt aber nichts an und braucht kein Schreibrecht.
-Geeignet für jemanden, der die Kette unabhängig nachvollziehen will.
+Führt alle Kontrollen aus, **verändert nichts** und braucht kein Schreibrecht –
+auch dann nicht, wenn dabei ein fehlender Anker auffällt. Der wird gemeldet
+(Code 5), nicht repariert; Reparieren ist Sache des Notar-Laufs.
+
+Das ist kein Detail: Die Serversperre für `refs/notary/*` lehnt Schreibzugriffe
+ja gerade ab. Würde der Prüfmodus dort nachtragen wollen, bekäme jeder
+read-only prüfende Auditor dauerhaft einen Fehler auf einer völlig gültigen
+Kette – und könnte ihn nicht beheben.
 
 ## Anhängen ist selbst ein Beglaubigungsakt