GitGalaxy

Intelligenza strutturale su scala di repository senza compilazione.

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

1 scansione · 97 segnali strutturali · 50+ linguaggi · nessuna compilazione · 17 categorie di esposizione al rischio · 6 output

La versione breve

GitGalaxy costruisce un grafo strutturale agnostico rispetto al linguaggio dell'intero repository direttamente dal testo sorgente — nessuna build, nessuna toolchain per linguaggio.

È progettato per repository poliglotti, parzialmente non funzionanti, legacy, pieni di codice di terze parti o comunque difficili da analizzare tramite un flusso di lavoro basato prima sulla build:``` text Go + C++ + Python + Java + Bash + YAML

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

Invece di un parser separato per ogni linguaggio, GitGalaxy estrae un
vocabolario comune di **firme strutturali** — funzioni, classi, argomenti,
flusso di controllo, mutazione dello stato, I/O, API, dipendenze — e le normalizza
in un unico modello deterministico del repository che alimenta l'analisi
architetturale, la prioritizzazione dell'esposizione al rischio, la generazione
di SBOM, il refactoring e l'analisi della proprietà, il contesto del codebase
orientato all'AI e i gate CI/CD.

> **Tesi centrale:** il parsing completo del linguaggio non è sempre necessario
> per recuperare informazioni strutturali altamente utili su scala di repository.

Come questa tesi viene testata — contro Tree-sitter e Ctags, contro un corpus
di controllo predisposto, e in seguito contro la cronologia Git — è riassunto
in [Precisione, misurata](#accuracy-measured) di seguito ed esposto in dettaglio
nel [programma di validazione](https://gitlab.com/squid-protocol1/gitgalaxy/-/blob/main/docs/validation.md).

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

## Cosa ti offre una scansione

Un solo comando:``` bash
pip install gitgalaxy
galaxyscope path/to/repo

Sei viste coordinate dello stesso scan deterministico:

Output	Scopo
Brief sull'architettura per LLM	Contesto compatto orientato a macchine/agenti (di seguito)
SARIF	Integrazione con CI/dashboard di sicurezza
CycloneDX SBOM	Inventario delle dipendenze/conformità
SQLite	Grafo di conoscenza del repository interrogabile
Dati di audit JSON	Flussi di lavoro forensi/di automazione
Dati di visualizzazione 3D	Topologia interattiva del repository

Il brief sull'architettura

Il report di punta è un singolo brief Markdown costruito per consegnare a un ingegnere — o a un agente AI — un modello mentale funzionante di un repository che non ha mai visto. È un pacchetto autonomo: le equazioni di rischio sono stampate nel report stesso, e un prompt di interpretazione incorporato consente a qualsiasi LLM di narrarlo senza allucinare il significato dei numeri. Le sezioni coprono lo stato macro e la composizione linguistica, la topologia di rete (modularità, punti di articolazione, densità ciclica), i colli di bottiglia delle dipendenze, le funzioni e i file più pesanti, le firme strutturali per file con raggio d'impatto PageRank, le hitlist di rischio mirate e cumulative, gli audit della supply chain e gli obiettivi di refactoring classificati per volatilità e centralizzazione della paternità — più un elenco dettagliato di ogni file che ha rifiutato di scansionare, e perché.

Due esempi, scansionati il 2026-08-31 con il motore attuale. Entrambi i repository sono pubblici — clona l'uno o l'altro ed esegui galaxyscope --llm-only <path> per riprodurre il brief completo:

curl — 4.250 artefatti, 696 scansionati, 112.653 LOC tra C, Perl, Python, Shell, M4 e Makefile. Il brief classifica src/tool_setup.h come il principale pilastro strutturale (80 connessioni in entrata) e colloca una funzione Perl — APPEND_imap in tests/ftpserver.pl, Impact 2135, 1.672 LOC — in cima alla hitlist delle funzioni a livello di repository, nella stessa classifica del codice C. Quel grafo cross-linguaggio è il prodotto: un unico insieme di segnali comparabili attraverso ogni linguaggio del repository. L'avvertenza onesta nello stesso brief: solo il 16,4% degli artefatti è stato scansionato — il filtro di ingestione scarta aggressivamente binari, codice generato e dati di test, e la §5 del brief elenca ogni esclusione per estensione e motivo.

cics-genapp (il sample CICS COBOL/DB2 di IBM) — 92,1% scansionato: 44 programmi COBOL, 29 job JCL. La hitlist cumulativa della superficie strutturale è guidata da base/src/lgupdb01.cbl (superficie di mutazione ~100%, carico di complessità 92%), e il paragrafo più pesante nel repository è UPDATE-POLICY-DB2-INFO — la logica di row-locking SELECT FOR UPDATE, che è esattamente dove un manutentore di quel programma vorrebbe guardare per primo. Lo stesso brief mostra anche chiaramente un limite: su un'architettura piatta senza un vero grafo di import, la lista dei "pilastri strutturali" degenera in file a zero connessioni, e il report dice di controllare i conteggi delle connessioni prima di fidarsi.

Centinaia di brief non modificati per repository selezionati in modo indipendente sono committati su gitgalaxy-raw-output; il brief di self-scan sempre aggiornato di questo stesso repo è in docs/gitgalaxy_architecture_brief.md.

Un grafo, molti consumatori

Consumatore	Domanda
Architettura	Di cosa è fatto questo repository?
Analisi strutturale	Dove sono le funzioni, le classi, le API, le dipendenze e le strutture di controllo?
Structural Surface Profile (precedentemente Risk exposure)	Dove è concentrato un dato pattern strutturale/di contenuto?
Refactoring	Quali file sono complessi, ad alto churn o portanti?
Supply chain	Quali dipendenze esistono fisicamente su disco?
Contesto AI	Quale architettura e quali relazioni dovrebbe conoscere un agente?
Migrazione legacy	Dove sono le unità strutturali da trasformare?
Analisi storica	Come cambia l'esposizione misurata man mano che il repository evolve?

Pipeline dell'architettura di GitGalaxy

Accuratezza, misurata

Due programmi di misurazione permanenti supportano le affermazioni di cui sopra. La narrazione completa — metodologia, verdetti, limiti e cosa viene dopo — è in il programma di validazione; questa è la sintesi.

Validazione strutturale: GitGalaxy vs Tree-sitter vs Ctags

GitGalaxy è confrontato con Tree-sitter e Universal Ctags sul corpus pinned Language Crucible — 24 dei 45 linguaggi ricevono tutti e tre gli strumenti, altri 13 ne ricevono due, e ogni disaccordo viene investigato rispetto al codice sorgente reale e registrato con un verdetto (200 delle 201 forme di discrepanza registrate validate). Su quel corpus, la precisione delle funzioni validate di GitGalaxy è del 100% su tutti i 31 linguaggi comparabili con tree-sitter, e non è mai lo strumento trovato in errore in un disaccordo validato su classe o argomento. Il limite: tre obiettivi strutturali, un corpus fisso — non "analizza accuratamente come un AST" in generale.

gitgalaxy — Updated!