Record the failed first pass, integrated repairs, actual Playwright flows, source and research decisions, same-port daemon behavior and maintainer entry points. Include before/after screenshots and the final map recheck after login. Archive original test logs losslessly with SHA-256 records; retain failed runs separately instead of presenting them as successful checks. Disclose unresolved global C lint, parser callsite coordinates, heuristic architecture roles, manual diff narrowing and outstanding platform validation. Signed-off-by: Bernhard Jackiewicz <bj@techport.io>
14 KiB
PR 2068: Abschlussbericht und Übergabe
Übergabe vorbereitet am 10. September 2026 (Europe/Berlin), ausschließlich auf feat/codeatlas-web. Der englische Maintainer-Einstieg fasst Umsetzung, Übernahme und offene Arbeiten zusammen. Die folgenden Browserbefunde stammen aus der zweiten Reparaturrunde vom 9. September; die Abschlussprüfung nach der erneuten Anmeldung ist separat belegt.
Stand: 9. September 2026, nach dem kritischen Produkt-Audit und den anschließenden Reparaturen. Der damalige Eindruck, dass sich im normalen Bedienablauf zu wenig verbessert hatte, war berechtigt. Einzelne neue APIs und Widgets waren vorhanden, aber wesentliche Einstiege waren kaputt oder unzusammenhängend. Dieser Bericht beschreibt den anschließend tatsächlich implementierten und im Browser geprüften Stand.
Vergleichsaufnahmen und lokaler Einstieg
- Aktuelle Architecture-Übersicht auf 9749.
- Originalfrontend des aufgezeichneten Vergleichslaufs auf Port 9751, Revision
80f4f41f9bcb9daf60afc5f607bcbcba24a4b196. Beide Frontends verwendeten denselben Daemon/Index. Der Vergleich bildet keine historische Backend-Installation ab. Port 9751 war ausschließlich ein lokaler Prüfserver; die Screenshots bleiben unabhängig von seiner Laufzeit nachvollziehbar. - Vorher und nachher, frisch mit Playwright bei 1440×1000 aufgenommen. Vergleichsprotokoll.
Entwicklung ausschließlich auf feat/codeatlas-web, PR-Basis feat/atlas-r1; bestehende Änderungen bleiben erhalten. Kein Branchwechsel oder Zurücksetzen. Eingebettetes Frontend der geprüften Reparaturrunde: index-nfAv5dSK.js; derselbe Asset-Hash entstand beim erneuten Abschlussbuild. Der abschließende reale Indexlauf dieser Runde endete ohne Fehler: 42.649 gespeicherte Knoten, 177.320 Kanten, Generation u08b7127147560895g2. Diese Gesamtzahlen sind nicht gleich dem begrenzten Ausschnitt der Karte oder dem Dateibaum. Später erzeugte Testberichte sind keine Behauptung über diesen Indexzeitpunkt.
Was jetzt konkret funktioniert
| Entwicklerfrage | Implementierter Ablauf und überprüfbare Evidenz |
|---|---|
| Was macht das Repository, wo beginne ich? | Die Architecture-Übersicht liest die Autorenbeschreibung aus README und Beschreibungen aus tatsächlichen Dateiheadern. Bereiche zeigen belegte Abhängigkeiten und ausdrücklich abgeleitete Grenzen. Einstiegskandidaten sind nach Application, Frontend, Tests und Tools unterscheidbar. Aus einem Einstieg lassen sich begrenzte statische CALLS-Pfade öffnen. |
| Worauf beruht eine Architekturbeziehung? | Eine Beziehung führt unmittelbar zu ihren Endpunkten, Kanten-IDs, vorhandenen Auflösungsmetadaten und gültigen Quellpositionen. Der Quellen-Drawer bewahrt Karte oder Änderungsanalyse. Ungültige Indexzeilen werden als unbestätigt markiert, nicht als korrekte Aufrufstellen präsentiert. |
| Warum ist diese Auswahl relevant? | Selection context zeigt konkrete eingehende/ausgehende Beziehungen und vorhandene Einstiegspfade. Aufgezeichnete Agentenaktivität ist separat, mit ehrlichem Leerzustand. Der nächste Schritt führt zur Quelle oder in die gemeinsame Änderungsanalyse. |
| Was könnte meine Änderung betreffen? | Ein gemeinsamer Change-impact-Dialog für aktuelle Auswahl, Working Tree und Since ref. Echte geänderte Dateien lassen sich auf Symbole eingrenzen. Strukturelle Abhängigkeiten, Testkandidaten, historische Co-Changes und Datenqualität sind getrennt. Pfade, Quellstellen, Commit-IDs und kopierbare lokale Git-Prüfkommandos machen Befunde überprüfbar. |
| Sind Fehler oder Lücken tatsächlich erfasst? | System filtert projektbezogene SQLite-Logs vor dem Zeilenlimit. System und Galaxy erhalten echte Fehler live. Die ruhige Kopfzeile unterscheidet Historie von aktueller Störung. Die vorhandene Coverage-Diagnose zeigt partielle Parses, Ausschlüsse und weitere erfasste Gründe; ein bearbeitbarer Bericht entsteht erst nach ausdrücklicher lokaler Aktion. |
| Woher kommen Agenteninformationen? | Sichtbares lokales Hook-Setup, Download und prüfbares Installationskommando. Ereignisse laufen über denselben Daemon-Port in SQLite. Die Anzeige unterscheidet verbundenes History-Polling vom Zeitpunkt des letzten Werkzeugaufrufs und behauptet keine aktuelle Agentenarbeit aus alten Ereignissen. |
Zusätzlich repariert: rows_refs-Dekompression und paginierte RPC-Ergebnisse, exakte Dateipfadsuche einschließlich sofortigem Enter und verspäteter Antworten, Quellenauflösung ohne zuvor geladene Karte, EOF-nahe Quellseiten, überfüllter Impact-Inspector, fehlgeschlagener Working-tree-Einstieg und abgebrochene große Mapantworten.
Technische Grundlage
Der bestehende Daemon bedient eingebettetes Frontend, RPC, Repository-Karte, Impact, Logs und Agentenereignisse auf Port 9749. MCP-Transporte bleiben erhalten. SQLite-Activity-Schema 4 nutzt WAL, begrenzte Speicherung, Cursor und dauerhafte Sequenz-Deduplizierung auch nach Payload-Retention. Alle UI-Logs lesen dieselbe SQLite-Quelle; JSONL bleibt ein lokaler Export mit begrenztem einmaligem Altimport. Es wurde kein zweiter Produktlistener oder notwendiger Bridge-Prozess eingeführt.
Browser aktualisieren über begrenztes Polling auf demselben Port. Git-/Graphanalysen haben Arbeitsgrenzen und einen kurzen Cache; Git-Co-Changes werden nicht als persistierte zweite Graphwahrheit geführt. Repository-Karten über 1 MiB erhalten gezielt eine begrenzte Sendezeit von fünf Sekunden; gewöhnliche HTTP-Antworten behalten ihre bisherigen Grenzen. Keine neuen npm-Pakete oder Frameworks wurden eingeführt.
Tatsächlich ausgeführte Prüfung
- Erneute Abschlussprüfung: 2473 Unit-Tests in 175 Dateien, 203 Acceptance-Checks, Produktionsbuild, Style-Gate, Promise-Gate, fünf Operational-Reference-Tests und sieben lokale Hook-Tests bestanden. Ein nachträglich umbenannter Hook-Download war im Gate noch unter dem alten Dateinamen hinterlegt; die exakte Zuordnung und Bytegleichheit sind jetzt geprüft. Ein wortgetreuer Diagnose-Download ist als JSON-Zitat erhalten. Der ältere fehlgeschlagene Style-Lauf bleibt als historisches Protokoll erhalten und wird nicht als grün ausgegeben.
- Originalprotokolle sind platzsparend als
.log.gzbeigelegt; Archivmanifest mit Prüfsummen. Dekomprimieren liefert die unveränderten Originalbytes. Screenshots und JSON-Ablaufprotokolle bleiben direkt lesbar. - Nach der erneuten Anmeldung wurde der lokale Prüfdaemon wieder gestartet und der vollständige Kartenablauf nochmals bestanden: separater Browserlauf zur Übergabe, sechs Aufnahmen, keine Browserausnahmen oder externen Requests. Frühere Browserprotokolle wurden dabei nicht überschrieben.
- Native HTTP-/Journal-/Transporttests: 83 bestanden, ein bestehender Windows-only-Skip, unter ASan/UBSan. Native UI-/Map-/Impacttests: 40 bestanden. Das ist die gezielte finale native Prüfung, keine Behauptung über einen erneut vollständig ausgeführten Gesamttestlauf.
- Der globale C-Lint ist weiterhin nicht grün:
cppcheckfehlt im lokalen Setup, clang-tidy meldet umfangreiche Befunde; auch die neuen UI-C-Dateien erfüllen nicht sämtliche zusätzlichen Komplexitäts-/Stilregeln. Der frühere vollständige Lintlauf und die Abgrenzung der fokussierten Korrektheitsprüfungen bleiben gültige Einschränkungen. Ein erfolgreicher Build und die gezielten nativen Tests ersetzen keinen grünen globalen Lint-Gate. - Karte: frische Sitzung, Projektbeschreibung,
src/main.c, echter Pfad, sofort sichtbare Kanten,project_lock.c:61tatsächlich geladen und markiert, Rückkehr, Daemonbereich, Symbol und gemeinsamer Impact. Quelle neben Karte. - Suche und Explore: 144 Funktionen und acht Klassen in
application.c; tatsächlicher Monaco-Quelltext, Auswahlkontext und derselbe Impact-Dialog. Sofortiges Enter öffnet keine Ersatzdatei. Eine unveränderte echte ältere RPC-Antwort, 26ms nach Pfadwechsel freigegeben, überschreibt die aktuelle Suche nicht. Ein tatsächlicher HTTP-Abbruch wird daraus nicht behauptet. - Änderungsanalyse: 325/325 Worktreepfade und 339/339 Pfade seit
HEAD~1im aufgezeichneten Lauf. Für das reale Symbolapplication_project_lock_release_fully: 17 strukturell erreichbare Betroffene und sieben Testkandidaten, prüfbare Pfade, Testquelle, Git-Evidenz, Datenqualität und Fokuswiederherstellung. 1024×800 ohne horizontale Überläufe. - Echte Indexfehler: ausdrücklich markierte lokale EACCES-Testfälle wurden persistiert und erschienen ohne Reload in System und Galaxy. System-Filter stimmten mit SQLite überein: 57/57 Fehler, 11/11 Projektfehler und 3/3 Texttreffer zum dokumentierten Zeitpunkt. Die Dateiberechtigungen wurden wiederhergestellt.
- Lokaler Hook-Prozess: echter Python-Aufruf in temporärer Konfiguration, explizites TEST-Ereignis, Retry erzeugt keine zweite Zeile. Keine LLM-Sitzung. Nach Neustart und bei Browser-Reconnect bleibt das Ereignis erhalten; Offline/Online stellt dieselben Zeilen ohne Reload oder Duplikate wieder her. Der Browser war beim echten Daemon-Neustart noch nicht verbunden; diese zwei Nachweise werden getrennt ausgewiesen.
- Derselbe finale Browserlauf prüft Setup-Download, unveränderte persönliche Konfiguration, bewusst gestartete Diagnose und ausschließlich lokal heruntergeladenen bearbeiteten Bericht. Keine externen Requests oder Bridge-Anfragen. Die geprüften finalen Produktabläufe meldeten keine Browserausnahmen.
- Responsive Kartenprüfung: 1024×800, Quellen-Drawer vollständig im Fenster, Escape kehrt zur Karte zurück; direkter Architecture-Link überschreibt eine zuvor gespeicherte Explore-Auswahl.
Zwischenzeitliche Fehlläufe wurden nicht als bestanden umetikettiert: etwa ungültige Callsite und EOF-Fehler. Die abschließenden erfolgreichen Läufe liegen separat vor.
Recherche und verbleibende Grenzen
Der quellenbezogene Rechercheabgleich nennt tatsächliche Browserinteraktionen, Quellcodeprüfungen, Lizenzen und Integrationsentscheidungen. Archify und ein Graphify-Beispiel wurden mit Diagrammdaten bedient; GitNexus und das bestätigte CodeGraph überwiegend am Frontend-/API-Code untersucht. Übertragen wurden Einstiegshierarchie, ausgewählte Pfade, Quellenlesen bei erhaltener Ansicht und getrennte historische Evidenz. Keine Fremdviewer, zusätzlichen Datenbankstacks oder fremden Quelltexte wurden integriert.
Die Grenzen bleiben sichtbar und sind keine gelieferten Zukunftsfeatures:
- Eine nach Quellpfaden gegliederte, mit Autorenzitaten erklärte Karte ist keine automatisch validierte Domänenarchitektur. Ein Header beschreibt seine Datei und belegt nicht die gesamte Verantwortung seines Bereichs. Einstiegserkennung und Rollen bleiben Heuristiken. Ein Erstnutzer-Onboarding-Test wurde nicht durchgeführt; vollständige Erfüllung dieses qualitativen Abnahmekriteriums wird deshalb nicht behauptet.
- Statische CALLS-Pfade zeigen mögliche Erreichbarkeit, keine Laufzeitausführung oder Datenflüsse. Ein bestehender C-Präprozessor-/Indexkoordinatenfehler kann falsche Kantenzeilen liefern. Die UI kennzeichnet nachweisbar ungültige Zeilen; die zugrunde liegende Parserursache wurde nicht repariert.
- Der aktuelle Index enthält 85 partielle Parse-Pfade und 300 absichtlich ausgeschlossene Pfadrecords. Diese Zählung enthält auch Ordner und ist keine Prozent-Coverage. Nicht entdeckte Eingaben können fehlen. Diagnose macht diese Grenzen sichtbar, behebt jedoch keine Grammatik- oder Ausschlussregeln automatisch.
- Diff-Hunks werden nicht automatisch semantisch Symbolen zugeordnet; die Eingrenzung erfolgt sichtbar manuell. Historie ist begrenzt, kann dünn sein und bezieht sich auf committed Versionen. Indexrevision und Worktreegleichheit können unbekannt bleiben. Ein heuristischer Risikohinweis ist keine kalibrierte Defektwahrscheinlichkeit.
- Das produktive Agent-Setup muss der Nutzer bewusst aktivieren. Nachgewiesen sind der echte lokale Hook-Prozess, Persistenz und Anzeige; es wurde keine produktive Agenten-/LLM-Sitzung zum Test gestartet. Diagnose und Veröffentlichung bleiben getrennt, ohne automatische externe Übermittlung.
- Globale C-Lint-Bereinigung und die vollständige plattformübergreifende PR-/Release-Prüfung sind weiterhin offen. Die hier bestandenen lokalen Prüfungen werden nicht als allgemeine Merge- oder Releasefreigabe ausgegeben.
Zur manuellen Prüfung: den Daemon mit eingebettetem Frontend starten, das Repository indexieren, Architecture öffnen, main aus src/main.c wählen, den statischen Pfad und seine Quelle öffnen. Danach Search → src/daemon/application.c → ein Symbol → Change impact → Working tree. System/Agents und Inspect index coverage ergänzen denselben lokalen Datenstand. Start- und Prüfkommandos stehen im Maintainer-Einstieg; lokale URLs und temporäre Verzeichnisse aus den Originalprotokollen sind keine Voraussetzung für die Codeübernahme.