Question 1

How does it handle monorepos, git worktrees, and multiple repos?

Accepted Answer

Monorepot: yksi graafi per repositorion juuri luodaan automaattisesti; indeksoidaan vain seuratut tiedostot, ja .code-review-graphignore‑tiedostolla voidaan sulkea pois lisäpolkuja. Git‑worktree‑t: jokainen worktree havaitaan erillisenä juurena ja sille luodaan oma graafi; yhden tietokannan jakamista eri commit‑tiloissa olevien worktree‑jen välillä ei tueta. Useita repoja: kevyt rekisteri (sijaitsee polussa ~/.code-review-graph/registry.json) mahdollistaa MCP‑asiakkaiden hakemisen rekisteröidyistä projekteista, ja daemon voi tarkkailla useita repoja pitääkseen niiden graafit ajan tasalla. Käytä --repo, --data-dir tai CRGDATADIR‑ympäristömuuttujaa mukauttaaksesi sijainteja.

Question 2

Kuinka suuri koodikanta oikeuttaa sen käyttöön?

Accepted Answer

Alle muutaman sadan tiedoston kohdalla hyöty on marginaalinen, koska agentti voi usein pitää koko repo:ta kontekstissa. Muutaman sadan ja muutaman tuhannen tiedoston välinen alue on optimaalinen: benchmarkit repositorioissa, jotka sisältävät 60–~1 100 tiedostoa, osoittavat 38×–528× tokenin vähennyksen koko‑korpuksen kysymyksiin. Useita tuhansia tiedostoja sisältävät repo:t ja monorepo:t tarjoavat vahvimman perustelun, koska agenteilla ei voida lukea koko korpusta yhtä kyselyä kohti, ja inkrementaaliset graafipäivitykset pitävät indeksin ajantasaisena minimaalisella kustannuksella. Usean tiedoston kyselyiden tiheys vaikuttaa myös tuoton suuruuteen.

Question 3

Kuinka varmistan, että se toimii?

Accepted Answer

1. Varmista, että graafitiedosto on olemassa ja sisältää solmuja/kaaria; nolla‑määrä tarkoittaa, että buildia ei suoritettu. 2. Tee muutos ja tarkkaile riskiyhteenvetoa sekä Token Savings -paneelia; lisää --verify tarkistaaksesi token‑arviot cl100kbase‑tokenisoijalla. 3. Claude Codessa suorita /mcp ja vahvista, että code‑review‑graph -palvelin on yhteydessä ja sen työkalut on listattu. Kysy sitten rakenteellinen kysymys (esim. "mitkä kutsuvat parsefile?"), ja varmista, että avustaja käyttää query_graph‑komentoa greppaamisen sijaan. Jos jokin askel epäonnistuu, katso TROUBLESHOOTING.md.

Question 4

Lähettääkö se tietoja verkkoon?

Accepted Answer

Ei. Telemetriaa ei ole lainkaan. Graafi tallennetaan paikallisesti SQLite‑tiedostoon repositoriosi sisällä, ja kaikki ydintoiminnot suoritetaan kokonaan koneellasi. Ainoa verkkoaktiviteetti on valinnainen: jos asennat embeddings‑lisäosan, se lataa sentence‑transformers‑mallin HuggingFacesta, ja pilvi‑embeddauksen tarjoajat (OpenAI, Google Gemini, MiniMax) saavat vain ne funktiotunnisteet, jotka päätät nimenomaan upottaa, sen jälkeen kun hyväksyt lähdön varoituksen. Muulloin koodisi ei koskaan poistu koneelta.

Question 5

Milloin sitä ei tulisi käyttää?

Accepted Answer

README‑tiedosto listaa useita tilanteita: hyvin pienet repositoriot (muutama sata tiedostoa), joissa graafin rakentamisen overhead on suurempi kuin hyödyt; triviaalit yhden tiedoston muutokset, joissa graafivastaus lisää enemmän tokeneita kuin pelkkä diff; kertaluonteiset kysymykset repositoriosta, jota ei aio palata myöhemmin; sekä virtausdetektointi kielissä, joissa CRG:n sisäänkäyntien tunnistus on vähemmän luotettava (esim. JavaScript ja Go, joilla on tällä hetkellä alhainen recall). Näissä tapauksissa yksinkertainen agenttipohjainen haku tai greppaus riittää yleensä.

Question 6

Miten se vertautuu Seranaan, codegraphiin, claude-contextiin ja repomixiin?

Accepted Answer

Nämä työkalut ratkaisevat vierekkäisiä ongelmia. code-review-graph rakentaa Tree‑sitter‑AST:n pysyväksi SQLite‑grafiksi, jossa on tarkastukseen keskittyviä reunoja (räjähdysalue, riskipisteistetty muutosanalyysi, testikaappauksen havaitseminen). Serena käyttää LSP‑pohjaista symbolien hakua ja muokkausta, keskittyen muokkaukseen pikemminkin kuin tarkastukseen. codegraph vaihtelee toteutuksesta riippuen, mutta yleensä tarjoaa AST‑/kutsugraafin indeksoinnin. claude-context tarjoaa lohko‑plus‑embed‑semanttista koodihakua vektoristossa, sopii hakuun enemmän kuin rakenteelliseen tarkastukseen. repomix pakkaa koko repositorion yhdeksi AI‑ystävälliseksi tiedostoksi ilman rakenteellisia kyselyjä. Valitse työkalu sen perusteella, tarvitaanko tarkkaa muokkausta (Serena), semanttista hakua (claude-context) vai tarkastukseen suunnattua rakenteellista analyysiä (code‑review‑graph).

Question 7

Why not just grep?

Accepted Answer

Grep toimii yksinkertaisissa yhden askeleen kysymyksissä, kuten "missä parsefile on määritelty?", mutta se kamppailee monivaiheisten rakenteellisten kysymysten kanssa, jotka vaativat transitiivista jäljittämistä, testikattavuuskartoitusta tai vaikutusalueen analyysiä. Jokainen lisäaskel vaatisi uuden grep‑kierroksen, mikä lisää token‑käyttöä ja tuottaa vääriä positiivisia tuloksia ylikuormitetuista nimistä. CRG vastaa näihin yhdellä graafikyselyllä, säilyttää indeksoidun rakenteen SQLite‑tietokannassa ja päivittyy inkrementaalisesti, välttäen toistuvat skannaukset ja tarjoten kyselyitä, joille grep‑vastinetta ei ole, kuten "mitkä suorituspolut tämä muutos koskee".

Question 8

Eikö tämä ole vain RAG?

Accepted Answer

Ei. RAG (Retrieval‑Augmented Generation) jakaa koodisi tekstikappaleiksi, upottaa ne ja hakee kappaleita kyselyn samankaltaisuuden perusteella. Se ei pysty vastaamaan rakenteellisiin kysymyksiin, kuten “kuka kutsuu X‑funktiota”, koska samankaltaisuus ei takaa kutsusuhdetta. CRG tallentaa AST:stä puretut rakenteelliset reunat – kutsut, importit, perintä, testikattavuus – jolloin kysymykseen “kuka kutsuu login()?” vastataan graafihakemalla. Upotuksia (embeddings) käytetään vain valinnaisena hybridhakutyökaluna. Vertailut osoittavat, että CRG saavuttaa 0,909 pistettä monivaiheisissa hakutehtävissä, kun puhdas samankaltaisuushaku ei pysty suorittamaan toista hakuvaihetta.

Question 9

Miten tämä eroaa LSP:stä ja kielipalvelimista?

Accepted Answer

Kielipalvelimet ja code‑review‑graph (CRG) molemmat rakentavat rakenteellisen mallin koodistasi, mutta ne optimoivat eri asioita. LSP:n takana on oikea kääntäjän frontend, mikä tuottaa tyyppitietoista, semanttisesti tarkkaa tulosta, kuten tarkan siirry‑määrittelyyn, viitteiden hakuun, reaaliaikaiset diagnostiset viestit, täydennykset ja turvalliset uudelleennimet. CRG käyttää yhtä pysyvää SQLite‑tietokantaa, jäsentää kerran Tree‑sitterillä ja tukee noin 35 kieltä sekä muistikirjoja yhdestä prosessista. Se tarjoaa monikielisiä yhteyksiä, inkrementaalisia päivityksiä ja tarkasteluun keskittyviä reittejä, kuten testit‑koodille, suorituksen kulkureitit ja riskipisteytykset, joita LSP ei mallinna.

Yleiskatsaus

Pääominaisuudet

Hinnat

Käyttötapaukset

Koodiarvio

Riskien arviointi

Plussat ja miinukset

Plussat

Miinukset

Arvostelut

Kysymykset

Kysy kysymys

Taidot vaihtoehdot