duffyduckandClaude Opus 5
1a349d142e
verifyIntegrity waehlte die Pruefstaerke nach der von der Zeile selbst deklarierten hashVersion - und die ist nicht gehasht. Angriff: hashVersion 2->1 setzen, die nur von V2 abgedeckten Felder aendern (success false->true, errorMessage leeren, resourceLabel umschreiben) und den schwachen V1-Hash ueber die 7 unveraenderten Felder nachziehen. Ergebnis: Fehl-Login als Erfolg getarnt, Pruefung meldet "gueltig". An der letzten Zeile der Kette entsteht dabei nicht einmal ein Gap - dauerhaft unsichtbar. Fix: Version-Floor. Die erwartete Pruefstaerke leitet sich aus der Kette ab (MIN(id) WHERE hashVersion >= 2), nicht aus der Selbstauskunft. Ab dieser Grenze muss jede Zeile V2 sein; weicht die deklarierte Version ab, gilt die Zeile selbst als manipuliert. Geprueft wird immer mit dem erwarteten Verfahren. Die Grenze laesst sich durch Herabstufen einzelner Zeilen nicht verschieben. Zusaetzlich konsultiert die Pruefung jetzt das Loeschungs-Manifest: neu unexplainedGaps - nur Luecken ohne protokollierte Loeschung sind erklaerungsbeduerftig. Vorher war das Manifest rein informativ, wodurch sich eine boeswillige Loeschung als harmloser Gap tarnen konnte. Verifiziert (PoC nachgebaut): Downgrade mit Nachfolger erkannt, Downgrade der Tail-Zeile erkannt, Gegenrichtung (V1 faelschlich als V2) erkannt, keine Falschmeldungen auf Bestandsdaten. tsc + vite build gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>