GitGalaxy

Intelligence structurelle à l'échelle du dépôt sans compilation.

Docs · Visualiseur · Language Crucible · Keyword Rosetta · Sortie brute

1 analyse · 97 signaux structurels · 50+ langages · aucune compilation · 17 catégories d'exposition au risque · 6 sorties

La version courte

GitGalaxy construit un graphe structurel agnostique au langage d'un dépôt entier directement à partir du texte source — sans build, sans chaîne d'outils par langage.

Il est conçu pour les dépôts polyglottes, partiellement cassés, legacy, surchargés de dépendances externes, ou autrement difficiles à analyser via un workflow orienté build :``` text Go + C++ + Python + Java + Bash + YAML

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

Au lieu d'un analyseur distinct par langage, GitGalaxy extrait un vocabulaire
commun de **signatures structurelles** — fonctions, classes, arguments,
flux de contrôle, mutation d'état, E/S, API, dépendances — et les normalise
en un modèle de dépôt déterministe unique qui alimente l'analyse d'architecture,
la priorisation de l'exposition aux risques, la génération de SBOM, l'analyse de
refactoring et de propriété, le contexte de base de code orienté IA, et les portes CI/CD.

> **Thèse centrale :** l'analyse complète d'un langage n'est pas toujours nécessaire pour
> récupérer des informations structurelles très utiles à l'échelle d'un dépôt.

La manière dont cette thèse est testée — face à Tree-sitter et Ctags, face à un
corpus de contrôle implanté, et ensuite face à l'historique Git — est résumée dans
[Précision, mesurée](#accuracy-measured) ci-dessous et détaillée dans
[le programme de validation](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md).

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

## Ce qu'un scan vous apporte

Une seule commande :``` bash
pip install gitgalaxy
galaxyscope path/to/repo

Six vues coordonnées de la même analyse déterministe :

Sortie	Objectif
Brief d'architecture LLM	Contexte compact orienté machine/agent (ci-dessous)
SARIF	Intégration CI/tableau de bord de sécurité
CycloneDX SBOM	Inventaire des dépendances/conformité
SQLite	Graphe de connaissances du dépôt interrogeable
Données d'audit JSON	Flux de travail forensiques/automatisés
Données de visualisation 3D	Topologie interactive du dépôt

Le brief d'architecture

Le rapport phare est un brief Markdown unique conçu pour transmettre à un ingénieur — ou à un agent IA — un modèle mental opérationnel d'un dépôt qu'il n'a jamais vu. C'est un paquet autonome : les équations de risque sont imprimées dans le rapport lui-même, et un prompt d'interprétation intégré permet à n'importe quel LLM de le narrer sans halluciner sur la signification des chiffres. Les sections couvrent l'état macro et la composition linguistique, la topologie du réseau (modularité, points d'articulation, densité cyclique), les points d'étranglement des dépendances, les fonctions et fichiers les plus lourds, les signatures structurelles par fichier avec le rayon d'impact PageRank, les listes de cibles de risque ciblées et cumulatives, les audits de chaîne d'approvisionnement, et les cibles de refactoring classées par volatilité et centralisation de la paternité — plus une liste détaillée de chaque fichier qu'il a refusé de scanner, et pourquoi.

Deux exemples, scannés le 2026-08-31 avec le moteur actuel. Les deux dépôts sont publics — clonez l'un ou l'autre et exécutez galaxyscope --llm-only <path> pour reproduire le brief complet :

curl — 4 250 artefacts, 696 scannés, 112 653 LOC réparties entre C, Perl, Python, Shell, M4 et Makefile. Le brief classe src/tool_setup.h comme le pilier structurel principal (80 connexions entrantes) et place une fonction Perl — APPEND_imap dans tests/ftpserver.pl, Impact 2135, 1 672 LOC — au sommet de la liste des fonctions à l'échelle du dépôt, dans le même classement que le code C. Ce graphe multi-langage est le produit : un ensemble de signaux comparables à travers chaque langage du dépôt. La mise en garde honnête dans le même brief : seulement 16,4 % des artefacts ont été scannés — le filtre d'ingestion écarte agressivement les binaires, le code généré et les données de test, et la §5 du brief détaille chaque exclusion par extension et par raison.

cics-genapp (l'échantillon CICS COBOL/DB2 d'IBM) — 92,1 % scanné : 44 programmes COBOL, 29 jobs JCL. La liste cumulative de surface structurelle en tête est base/src/lgupdb01.cbl (surface de mutation ~100 %, charge de complexité 92 %), et le paragraphe le plus lourd du dépôt est UPDATE-POLICY-DB2-INFO — la logique de verrouillage de ligne SELECT FOR UPDATE, qui est exactement là où un mainteneur de ce programme voudrait regarder en premier. Le même brief montre aussi clairement une limitation : sur une architecture plate sans véritable graphe d'import, la liste des « piliers structurels » dégénère en fichiers à zéro connexion, et le rapport indique de vérifier les compteurs de connexions avant de lui faire confiance.

Des centaines de briefs non édités pour des dépôts sélectionnés indépendamment sont committés sur gitgalaxy-raw-output ; le brief d'auto-scan toujours à jour de ce dépôt lui-même se trouve à docs/gitgalaxy_architecture_brief.md.

Un graphe, de nombreux consommateurs

Consommateur	Question
Architecture	De quoi ce dépôt est-il fait ?
Analyse structurelle	Où sont les fonctions, classes, APIs, dépendances et structures de contrôle ?
Profil de surface structurelle (anciennement exposition au risque)	Où un motif structurel/de contenu donné est-il concentré ?
Refactoring	Quels fichiers sont complexes, à forte rotation ou porteurs de charge ?
Chaîne d'approvisionnement	Quelles dépendances existent physiquement sur le disque ?
Contexte IA	Quelle architecture et quelles relations un agent devrait-il connaître ?
Migration d'héritage	Où sont les unités structurelles à transformer ?
Analyse historique	Comment l'exposition mesurée évolue-t-elle à mesure que le dépôt évolue ?

Pipeline d'architecture GitGalaxy

Précision, mesurée

Deux programmes de mesure permanents étayent les affirmations ci-dessus. Le récit complet — méthodologie, verdicts, limites et ce qui vient ensuite — se trouve dans le programme de validation ; voici le résumé.

Validation structurelle : GitGalaxy vs Tree-sitter vs Ctags

GitGalaxy est comparé à Tree-sitter et Universal Ctags sur le corpus épinglé Language Crucible — 24 des 45 langages disposent des trois outils, 13 de plus en ont deux, et chaque désaccord est investigué face au code source réel et consigné avec un verdict (200 des 201 formes de divergence enregistrées validées). Sur ce corpus, la précision validée des fonctions de GitGalaxy est de 100 % sur les 31 langages comparables à tree-sitter, et il n'est jamais l'outil trouvé en tort dans un désaccord validé de classe ou d'argument. La limite : trois cibles structurelles, un corpus fixe — pas « analyse aussi précisément qu'un AST » en général.

gitgalaxy — Mis à jour !