GitGalaxy

Strukturintelligenz auf Repository-Ebene ohne Kompilierung.

Docs · Visualizer · Language Crucible · Keyword Rosetta · Raw Output

1 Scan · 97 strukturelle Signale · 50+ Sprachen · keine Kompilierung · 17 Risikoexpositionskategorien · 6 Ausgaben

Die Kurzfassung

GitGalaxy erstellt einen sprachunabhängigen strukturellen Graphen eines gesamten Repositorys direkt aus dem Quelltext — kein Build, keine sprachspezifische Toolchain.

Es ist für Repositorys konzipiert, die polyglott, teilweise defekt, Legacy-, vendor-lastig oder anderweitig schwierig über einen Build-First-Workflow zu analysieren sind:``` text Go + C++ + Python + Java + Bash + YAML

• generated code + vendored code + legacy code
• half-migrated modules + broken dependencies

Statt eines separaten Parsers pro Sprache extrahiert GitGalaxy ein gemeinsames
Vokabular von **strukturellen Signaturen** — Funktionen, Klassen, Argumente,
Kontrollfluss, Zustandsänderungen, I/O, APIs, Abhängigkeiten — und normalisiert sie
in ein deterministisches Repository-Modell, das Architekturanalyse,
Risikoexpositions-Priorisierung, SBOM-Generierung, Refactoring- und Ownership-
Analyse, KI-orientierten Codebase-Kontext und CI/CD-Gates speist.

> **Zentrale These:** Vollständiges Sprach-Parsing ist nicht immer notwendig, um
> hochgradig nützliche strukturelle Informationen im Repository-Maßstab zu
> gewinnen.

Wie diese These getestet wird — gegen Tree-sitter und Ctags, gegen ein
eingesetztes Kontrollkorpus und als Nächstes gegen die Git-Historie — ist
unten in [Genauigkeit, gemessen](#accuracy-measured) zusammengefasst und
vollständig in [dem Validierungsprogramm](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md) dargelegt.

------------------------------------------------------------------------

## Was ein Scan liefert

Ein Befehl:``` bash
pip install gitgalaxy
galaxyscope path/to/repo

Sechs koordinierte Ansichten desselben deterministischen Scans:

Ausgabe	Zweck
LLM-Architektur-Brief	Kompakter, maschinen-/agentenorientierter Kontext (unten)
SARIF	CI-/Security-Dashboard-Integration
CycloneDX SBOM	Abhängigkeitsinventar/Compliance
SQLite	Abfragbarer Wissensgraph des Repositorys
JSON-Audit-Daten	Forensik-/Automatisierungsworkflows
3D-Visualisierungsdaten	Interaktive Repository-Topologie

Der Architektur-Brief

Der Flaggschiff-Report ist ein einzelner Markdown-Brief, der dazu gedacht ist, einem Ingenieur — oder einem KI-Agenten — ein tragfähiges mentales Modell eines Repositorys zu vermitteln, das er noch nie gesehen hat. Er ist ein in sich geschlossenes Paket: Die Risikogleichungen sind im Report selbst abgedruckt, und ein eingebetteter Interpretations-Prompt ermöglicht es jedem LLM, ihn zu erzählen, ohne zu halluzinieren, was die Zahlen bedeuten. Die Abschnitte behandeln Makrozustand und Sprachzusammensetzung, Netzwerktopologie (Modularität, Artikulationspunkte, zyklische Dichte), Abhängigkeits-Engpässe, die schwersten Funktionen und Dateien, strukturelle Signaturen pro Datei mit PageRank-Blast-Radius, gezielte und kumulative Risiko-Hitlists, Supply-Chain-Audits und Refactoring-Ziele, geordnet nach Volatilität und Zentralisierung der Autorenschaft — plus eine detaillierte Liste jeder Datei, die er verweigert hat zu scannen, und warum.

Zwei Beispiele, gescannt am 31.08.2026 mit der aktuellen Engine. Beide Repositorys sind öffentlich — klonen Sie eines davon und führen Sie galaxyscope --llm-only <path> aus, um den vollständigen Brief zu reproduzieren:

curl — 4.250 Artefakte, 696 gescannt, 112.653 LOC über C, Perl, Python, Shell, M4 und Makefile. Der Brief führt src/tool_setup.h als oberste strukturelle Säule (80 eingehende Verbindungen) und setzt eine Perl-Funktion — APPEND_imap in tests/ftpserver.pl, Impact 2135, 1.672 LOC — an die Spitze der repositoryweiten Funktions-Hitlist, im selben Ranking wie der C-Code. Dieser sprachübergreifende Graph ist das Produkt: ein vergleichbarer Signalsatz über jede Sprache im Repository hinweg. Der ehrliche Vorbehalt im selben Brief: Nur 16,4 % der Artefakte wurden gescannt — der Ingestion-Filter verwirft Binärdateien, generierten Code und Testdaten aggressiv, und §5 des Briefs listet jede Ausnahme nach Erweiterung und Grund auf.

cics-genapp (IBMs CICS-COBOL/DB2-Beispiel) — 92,1 % gescannt: 44 COBOL- Programme, 29 JCL-Jobs. Die kumulative Hitlist der strukturellen Oberfläche führt mit base/src/lgupdb01.cbl (Mutationsoberfläche ~100 %, Komplexitätslast 92 %), und der schwerste Paragraph im Repository ist UPDATE-POLICY-DB2-INFO — die SELECT FOR UPDATE-Row-Locking-Logik, genau dort, wo ein Maintainer dieses Programms zuerst nachsehen würde. Derselbe Brief zeigt auch klar eine Einschränkung: Bei einer flachen Architektur ohne echten Import-Graphen degeneriert die Liste der „strukturellen Säulen" zu Dateien ohne Verbindungen, und der Report empfiehlt, die Verbindungszahlen zu prüfen, bevor man ihm vertraut.

Hunderte uneditierte Briefs für unabhängig ausgewählte Repositorys sind eingecheckt unter gitgalaxy-raw-output; der stets aktuelle Self-Scan-Brief dieses Repositorys selbst befindet sich unter docs/gitgalaxy_architecture_brief.md.

Ein Graph, viele Konsumenten

Konsument	Frage
Architektur	Woraus besteht dieses Repository?
Strukturanalyse	Wo sind die Funktionen, Klassen, APIs, Abhängigkeiten und Kontrollstrukturen?
Structural Surface Profile (früher Risikoexposition)	Wo konzentriert sich ein gegebenes strukturelles/inhaltliches Muster?
Refactoring	Welche Dateien sind komplex, stark verändert oder tragend?
Supply Chain	Welche Abhängigkeiten existieren physisch auf der Festplatte?
KI-Kontext	Welche Architektur und Beziehungen sollte ein Agent kennen?
Legacy-Migration	Wo sind die strukturellen Einheiten, die transformiert werden müssen?
Historische Analyse	Wie verändert sich die gemessene Exposition, während sich das Repository weiterentwickelt?

---

Genauigkeit, gemessen

Zwei dauerhafte Messprogramme stützen die obigen Aussagen. Die vollständige Darstellung — Methodik, Urteile, Grenzen und was als Nächstes kommt — findet sich in dem Validierungsprogramm; dies ist die Zusammenfassung.

Strukturelle Validierung: GitGalaxy vs. Tree-sitter vs. Ctags

GitGalaxy wird gegen Tree-sitter und Universal Ctags auf dem gepinnten Language Crucible-Korpus benchmarkt — 24 von 45 Sprachen erhalten alle drei Tools, 13 weitere erhalten zwei, und jede Abweichung wird gegen echten Quellcode untersucht und mit einem Urteil festgehalten (200 von 201 protokollierten Diskrepanzformen validiert). Auf diesem Korpus beträgt GitGalaxys validierte Funktionspräzision 100 % über alle 31 mit tree-sitter vergleichbaren Sprachen, und es ist nie das Tool, das bei einer validierten Klassen- oder Argument-Diskrepanz als falsch befunden wird. Die Grenze: drei strukturelle Ziele, ein fester Korpus — nicht „parst generell so genau wie ein AST".