New circular dependency: OrderService ↔ ShippingService
HIGHShippingService.java:88 — orderService.markShipped(orderId)
Integrazione con GitHub
Blocca il drift architetturale prima che venga mergiato
Su ogni pull request, Archynt analizza i commit base e head, confronta i problemi di design tra i due, e pubblica il risultato direttamente su GitHub — così una nuova dipendenza circolare o un god-service compaiono come check fallito, non come una sorpresa tre sprint dopo.
#482 — Ship inventory reservation from checkout
archynt/architecture · feature/inline-reservation → main
OrderController now depends on InventoryRepository directly
MEDIUMOrderController.java:54 — inventoryRepository.reserve(...)
Come funzionano i check sulle PR
01
Attivato da GitHub
Un webhook pull_request (opened, synchronize, reopened) avvia il check automaticamente — nessun polling, nessun trigger manuale da Archynt.
02
Confronta il grafo, non il diff
Sia il commit base che l'head vengono analizzati in grafi di architettura completi; il check confronta i problemi di design che ciascuno produce, non il diff di codice grezzo.
03
Verdetto deterministico
PASS se non compaiono nuovi problemi, FAIL se la PR introduce un problema di severità HIGH, WARN negli altri casi — gli stessi detector usati nel resto di Archynt, non una chiamata a un LLM.
04
Check run nativo di GitHub
I risultati vengono pubblicati come check run (con un riepilogo in markdown dei risultati introdotti e risolti) una volta che la GitHub App è installata sul repository.
05
Funziona anche senza l'app
Senza la GitHub App, un token configurato pubblica comunque il risultato come commento sulla PR e stato del commit — solo senza l'interfaccia nativa del check run.
06
Supporto per repository privati
Il token di installazione della GitHub App viene usato anche per clonare repository privati ai fini dell'analisi, quindi non servono credenziali separate.
Pronto a vederlo sul tuo sistema?
Avvia un'analisi o entra direttamente nel workspace della tua organizzazione.