SynEvidÄnderungsfolgen als begrenzten Graph untersuchen
SynEvid analysiert Repositories lokal, bildet unterstützte Symbole und Beziehungen in einem typisierten Graph ab und berechnet begrenzte Auswirkungsbereiche. CLI, MCP, Web Inspector und CI sind getrennte Integrationsflächen. Im Rust-Analyse-Kern gibt es keinen LLM-Aufruf.
Welche Aufgabe das System angeht
Nach Änderungen an Symbolen oder Verträgen möchte ein Entwickler mögliche Aufrufer, Regeln und betroffene Tests erkennen. Statische Beziehungen sind hilfreich, dürfen aber fehlende Syntaxabdeckung oder dynamisches Verhalten nicht als sichere Aussage ausgeben.
Wie Verantwortlichkeiten getrennt sind
Ein Scanner liest Repository und optionalen Git-Kontext. Sprachadapter erzeugen Symbole, Verträge und Kanten mit Herkunft. Diff, Impact-Traversal und Invarianten nutzen dieses Modell. BLAKE3-Digests bilden prüfbare Artefakte, sind aber weder Signatur noch Korrektheitsbeweis.
Komponenten und Vertrauensgrenzen
Quellcode-abgeleitetes Systembild, keine bestätigte Live-Deployment-Topologie.
Pfade, Ignore-Regeln, Dateilimits und Snapshotdaten begrenzen die gelesene Arbeitskopie.
Im geprüften Snapshot gibt es TypeScript/JavaScript- und Python-Adapter; unbekannte Syntax begrenzt die Abdeckung.
Symbole und statisch extrahierte Beziehungen tragen Kantenart und Provenienz.
Diff, begrenzte BFS-Auswirkungssuche, Invarianten, Verträge und Testauswahl nutzen das Graphmodell.
Terminal, JSON, SARIF, lokale SQLite, MCP-Prozess, Inspector und externer CI-Runner bilden getrennte Grenzen.
Ein konkreter Pfad durch die Implementierung
Optionale Pfade und Grenzen sind in den Schritten benannt.
- SCHRITT 01
Snapshot
Repository lokal scannen; optional früheren Snapshot oder Git-Stand als Basis wählen.
- SCHRITT 02
Änderungen
Datei-, Symbol-, Kanten- und Vertragsdifferenzen berechnen.
- SCHRITT 03
Reichweite
Von geänderten Symbolen über gewählte Kanten und bis zur Tiefen- und Knotengrenze suchen.
- SCHRITT 04
Regeln prüfen
Konfigurierte Schicht-, Zyklus-, Abhängigkeits- oder API-Invarianten prüfen; unvollständige Abdeckung darf kein Pass werden.
- SCHRITT 05
Bericht
Befunde, Pfade, Abdeckung und kanonischen Digest als Terminal-, JSON- oder SARIF-Ausgabe prüfen.
Was die Regel tatsächlich ausdrückt
Die Implementierung nutzt Breitensuche, stabile Sortierung und markiert abgeschnittene Suchen. BLAKE3 wird auf kanonisierte JSON-Felder angewandt; es authentifiziert keinen Urheber.
I(s,K,D,d,B) = erreichbare v über K in Richtung D ab s; dist(v) ≤ d und |I| ≤ B
Was sich aus dem Repository belegen lässt
Quellinventar, dokumentierte Ergebnisse und ausgeführte Prüfungen bleiben getrennt.
Review-Commit 05e11481575f59acda2f107badbad87ecb745dbd; Cargo nennt Version 0.1.0, der Changelog markiert sie als unveröffentlicht.
Workspace mit 21 Rust-Engine-Crates und separater Integrationstest-Crate. MCP ruft über stdio ein lokales autopsy-CLI auf; Inspector liest exportierte Dateien.
README nennt 831 bestandene Tests. Diese Prüfung führte die Suite nicht aus und ordnet die Zahl keinem aktuellen CI-Lauf zu.
README und Reproduktionsbericht widersprechen sich. Der Bericht nennt 100 % Recall, aber 6,11 % Precision und 10,87 % F1; bis zur Reproduktion sind diese Zahlen vorläufig.
Offene Annahmen und Risiken
Diese Punkte begrenzen, wie weit die Architektur- und Evidenzaussagen interpretiert werden sollten.
- Dynamische Dispatches werden nicht als verifizierte Abhängigkeiten inferiert.
- Der statische Inspector liest exportierte Artefakte; er ist kein gehosteter Live-Dienst.
- MCP nutzt stdio und einen lokalen Prozess; GitHub Actions läuft extern auf einem CI-Runner.
- Benchmark-README, JSON und Markdown müssen aus einem reproduzierbaren Lauf abgeglichen werden.
Implementierung und Belege nachlesen
Versionierte Links führen zum geprüften Quellstand, sofern der Audit einen solchen festhält. Nicht versionierte Links können sich ändern.