Anwendungsfall CORE: Erst lesen, dann urteilen — warum die Reihenfolge zählt
Ein übernommener Quellcode, ein Prüfbericht voller Befunde — und ein Team, das mehr Zeit mit Widerlegen verbrachte als mit Beheben.
Ein Team übernahm die Software eines abgewanderten Dienstleisters: gewachsen über sieben Jahre, dünn dokumentiert, in Betrieb. Vor der ersten eigenen Freigabe liessen sie einen Prüflauf darüber laufen. Was zurückkam, war ein Bericht, den niemand lesen wollte — seitenweise Befunde, darunter echte, und dazwischen jede Menge Stellen, an denen der Prüfer schlicht nicht wusste, warum der Code tut, was er tut. Eine bewusst offene Schnittstelle sieht aus wie ein Loch, wenn man die Absicht dahinter nicht kennt. Das Team begann, den Bericht zu widerlegen, statt die Software zu verbessern.
Als größte Hürde erkannten sie nicht die Zahl der Befunde, sondern ihre Beweislast: Ein Fehlbefund kostet mehr als der echte, den er verdeckt. Er bindet denselben Fachmann, er endet mit „passt schon", und er zerstört das Vertrauen in die Liste. Nach dem dritten Fehlbefund liest niemand mehr den vierten — und der vierte war der richtige.
Genau dafür ist die Reihenfolge in Aigis festgelegt. Die innerste Schicht, CORE, hält zuerst fest, was da ist: Absicht, Aufrufer, Vererbung, Abhängigkeiten. Sie darf ausdrücklich nicht bewerten — kein Befund, kein Urteil, kein Daumen. Erst danach sehen die Schichten für Funktion und Sicherheit hin, und beide dürfen eine dokumentierte Absicht nicht als Fehler melden. Die offene Schnittstelle taucht im Bericht weiterhin auf, aber als das, was sie ist: eine bewusste Entscheidung mit Fundstelle, die jemand bestätigen oder zurücknehmen kann.
Die Liste wurde dadurch nicht kürzer, weil Befunde verschwunden wären. Sie wurde kürzer, weil das Widerlegen entfiel. Was übrig blieb, war Arbeit statt Beweisführung.
Die geschilderte Lage ist zusammengesetzt, nicht die eines bestimmten Kunden. Die beschriebene Mechanik ist die, die Aigis tatsächlich anwendet.