Handoff Audit

Das Projekt · Milestone M1 in Arbeit

Handoff Audit

Eine bestehende Software soll von einem anderen Team, Unternehmen oder Dienstleister übernommen werden. Der eigentliche Gegenstand ist dabei nicht schlechte Qualität, sondern Unsicherheit: Das übernehmende Team weiß nicht, wo die teuren Stellen liegen.

Handoff Audit reduziert diese Unsicherheit dort, wo es das belegbar kann — und macht sie explizit, wo es das nicht kann. Deshalb ist „unentscheidbar" hier ein erstklassiges Ergebnis und kein Fehler.

Leitfrage

Wie können wir eine fremde Codebasis so analysieren, dass aus technischen Signalen und nachvollziehbarer Evidence belastbare Informationen für Übernahme, Weiterentwicklung und Refactoring entstehen?

Ansatz
Deterministisch · lokal
technische Signale → prüfbare Evidence
Interpretierend · geprüft
belastbare Aussage → Risiko · Maßnahme · Aufwand

Die gestrichelte Linie markiert die Vertrauensgrenze zwischen lokal-deterministischer Analyse und interpretierender Bewertung.

Unterfragen und ihr jeweiliger Charakter
UnterfrageCharakter
Was können wir sicher erkennen?deterministisch
Was können wir nur schätzen?interpretierend
Was wissen wir nicht?explizit auszuweisen
Welche Evidence unterstützt eine Aussage?Nachvollziehbarkeit
Welche Bereiche einer Codebasis sind betroffen?Affected Surface
Welche Findings hängen zusammen?Beziehungen
Welche Maßnahmen folgen daraus, in welcher Reihenfolge?Ableitung, Priorisierung
Mit welcher Aufwandsspanne, mit welcher Unsicherheit?Schätzung, Confidence
Wo hilft AI — und wo sollte sie bewusst nicht entscheiden?Grenzziehung

Prinzipien

  1. Evidence first

    AI interpretiert Evidence. AI erfindet keine Evidence. Das ist keine Bitte an das Modell, sondern eine Eigenschaft des Typsystems: Das Paket, das mit einem externen Anbieter spricht, kann die Rohdatentypen strukturell nicht einmal benennen.

  2. Explainability

    Finding → Evidence → betroffene Komponenten → technische Bedeutung → Risiko → mögliche Maßnahme → Unsicherheit. Ein Finding, das man nicht prüfen kann, kann man auch nicht widerlegen.

  3. Decision support statt Score

    Ein Score beantwortet „wie gut ist es?". Eine Übernahmeentscheidung braucht „was kostet es, was riskiere ich, womit fange ich an, wie sicher ist das?".

  4. Local-first, fail closed

    Die Analyse läuft lokal und ohne Netzwerkzugriff. Was nicht eindeutig als erlaubt klassifizierbar ist, wird nicht übertragen — Default ist Ablehnen, nicht Senden.

    Vertrauensgrenze Links Quellcode und der Block der deterministischen Analyse, lokal. In der Mitte die gestrichelte Allowlist-Grenze. Von drei Linien überschreitet nur eine die Grenze und führt zum kleinen Exportmodell rechts; die beiden anderen enden an der Grenze.
    Abb. 2 · Vertrauensgrenze Nur das freigegebene Exportmodell überschreitet die Grenze. Quellcode und Rohdaten bleiben lokal. Eigene Darstellung, 2026

Analysemodell und aktueller Stand

8 Stufen · 3 implementiert · 1 Modell · 3 geplant · 1 offen

Jede Stufe trägt ihren tatsächlichen Stand. Keine Stufe ist als fertig dargestellt, die bislang nur konzeptionell vorgesehen ist.

  1. Repository

    Java-/Spring-Repositories mit konventionellen Quellverzeichnissen, dazu OpenAPI-3-Spezifikationen. Lokal, ohne Netzwerkzugriff.

    implementiert
  2. Deterministische Analyse

    AST- und Symbolanalyse über Spoon, ohne Klassenpfad-Auflösung; OpenAPI-Parsing mit $ref-Auflösung.

    implementiert
  3. Technische Evidence

    Repository-Inventar, Endpunkte mit kanonischer Response-Form, Typnamensindex — sowie benannte Warnungen dort, wo die Analyse weniger weiß, als sie müsste.

    implementiert
  4. Finding

    Bewerteter Befund mit Kategorie, Evidence und Begründung. Der Vergleich von Implementierung und dokumentiertem Kontrakt ist der nächste Umsetzungsschritt.

    geplant
  5. Affected Surface

    Das Datenmodell existiert; befüllt wird es zusammen mit den Findings.

    Modell vorhanden
  6. Interpretation

    Eine externe AI erhält dabei ausschließlich ein pseudonymisiertes, freigegebenes Exportmodell — nie Quellcode.

    geplant
  7. Risiko und Maßnahme
    geplant
  8. Unsicherheit

    Wie viel Unsicherheit verträgt eine Aufwandsspanne, bevor sie nutzlos wird? Offen.

    offene Forschungsfrage

Was das Projekt nicht ist

Dokumentierte Grenzen

Die folgenden Punkte markieren Bereiche, in denen die Analyse derzeit keine belastbare Aussage treffen kann.

  1. Kein Klassenpfad, dauerhaft

    Typen aus Abhängigkeiten sind nicht auflösbar und bleiben unbestimmt. Das ist der Preis dafür, dass die Analyse kein baubares Zielrepository voraussetzt und nichts nachlädt.

  2. Nur konventionelle Quellverzeichnisse

    Ein abweichendes Layout liefert kein Modell — gemeldet, nicht geraten.

  3. Gradle nur Best-Effort

    Gradle wird analysiert, Java- und Spring-Boot-Version bleiben dabei unbekannt.

  4. Nur OpenAPI 3

    Inline-Schemata ohne Referenz bleiben unbestimmt statt namensbasiert falsch zugeordnet.

  5. Keine Validierung an einem realen Projekt

    Es existieren keine Messwerte zu Trefferquote, Genauigkeit oder Zeitersparnis.

Umsetzungsstand

Epic Abschnitt Inhalt Status
A Grundlage und Kernmodell Domänenmodell, Exportmodell, Architektur- und Privacy-Regeln, CI implementiert
B Lokale Analyse Spoon- und OpenAPI-Adapter, Repository-Inventar, Endpunkte, Response-Formen implementiert
C Findings Kontraktvergleich, Typklassifikation, Schichtgrenzen geplant
D AI-Export und Assessment Allowlist-Export, Egress-Prüfung, Interpretation geplant
E CLI und Report Zwei-Phasen-Ablauf, lokale Artefakte, HTML-Report geplant

Stand: 19. September 2026. Die abgeschlossenen Abschnitte sind durch die Testsuite des Projekts abgedeckt — eine Aussage über den eigenen Build, nicht über die Wirksamkeit des Verfahrens.