So funktioniert CodeGraph
Parsen Sie das Estate in einen typisierten Graphen und führen Sie dann deterministische Analysen aus. Kein LLM sitzt im kritischen Pfad.
Die Pipeline läuft Fixture-Estate, dann Parse (COBOL, Copybooks, JCL, DB2 DDL), dann Aufbau eines typisierten Wissensgraphen, dann transitiver Impact-Abschluss plus Provenienz, dann die deterministischen Analysen, dann Audit und Evidenz-Export, dann das interaktive Dashboard. Beim Laden führt die App das live über Server-Sent Events aus, sodass jede Stufe mit ihrer real gemessenen Latenz in einer Konsole erzählt, Panels sich schrittweise füllen und eine persistente Stufenleiste die Input-, Processing- und Output-Spur jeder Stufe öffnen lässt. Ein einziges Steuerelement spielt den gesamten Lauf erneut ab.
Der typisierte Wissensgraph
Gebaut mit networkx und gehalten im Speicher plus SQLite, hat der Graph sieben Knotentypen (program, copybook, variable, table, jcl, dataset und ein unaufgelöster Platzhalter) und typisierte Kanten wie DEFINES, IMPORTS, REDEFINES, CONTROLS_TYPE_OF, WRITES_VAR, REFERENCES, CALLS, READS and WRITES, EXECUTES, USES_DATASET und PRECEDES. Auf der ausgelieferten Fixture hat der Graph 47 Knoten und 70 Kanten: 14 Programme, 5 Copybooks, 17 Variablen, 3 DB2-Tabellen, 3 JCL-Jobs, 4 Datasets und 1 unaufgelöster Knoten.
Vier deterministische Analysen
Das sind schlichte Graphalgorithmen, keine Modellaufrufe, sodass dieselbe Fixture bei jedem Lauf dasselbe Ergebnis liefert.
1. Impact-Abschluss mit Provenienz
Der transitive Abhängigkeitsausschnitt einer Änderung, wobei jede Kante ihre file:line-Quelle trägt, sodass Sie nicht nur sehen, was betroffen ist, sondern wo die Evidenz liegt.
2. Naiver versus Graph-Recall
Der Abschluss des Graphen, bewertet gegen die bekannte Ground-Truth-Abhängigkeitsmenge der Fixture, gegenüber einem simulierten Einzeldatei-Fenster, also dem, was ein textbasiertes Werkzeug einem Modell tatsächlich zuführt.
3. Extraktionssequenzierung
Ein Kopplungs- und Blast-Radius-Score je Programm (Kopplung gewichtet drei, COMP-3-Fallen gewichtet zwei, JCL-Kritikalität gewichtet zwei, unaufgelöste Calls gewichtet fünf), der eine sichere Strangler-Fig-Migrationsreihenfolge rangiert.
4. Erreichbarkeit toten Codes und Completeness Gate
Jeder PERFORM, CALL, COPY und jede DB2-Referenz muss aufgelöst oder als prüfungsbedürftig markiert werden, niemals stillschweigend verworfen. Unerreichbare Paragraphen werden als Illustration berichtet, nicht als Leitmetrik bewertet.
Ein Schalter macht den Unterschied greifbar. Aktivieren Sie die naive AI-Kontextsicht, und der Graph verdunkelt sich auf die einzelne Quelldatei mit wenigen Kontextzeilen. Sechs der neun Überweisungsfakten verschwinden, ein rotes Banner nennt die Konsequenz, und das Zurückschalten stellt 9/9 mit Belegen wieder her. Dieser Schalter illustriert, welchen Kontext die Abrufschicht liefern muss, er ist nicht die Quelle des Werts.
Wenn Sie fertig sind, schreibt Export JSON eine Datei migration-evidence.json, und Evidence report rendert einen druckbaren Codebase Topology and Completeness Report: die Knoten- und Kantenzusammenfassung, Closures je Modul mit file:line-Provenienz, das Recall-Ergebnis und die Methode, die rangierte Extraktionssequenz, die Liste toten Codes und einen Zeitstempel. Wir positionieren das als DORA-ICT-Asset-Inventar und als SOC-2-Change-Control-Beleg. Eine optionale Pydantic-AI-Schicht kann Fragen über den Abschluss beantworten, ist aber standardmäßig aus und schlüsselgesteuert, und die deterministische Demo zeichnet das Ergebnis ohne jeden Schlüssel auf.
