Zum Inhalt

Funktionen

CodeDocumentation deckt den vollständigen Weg von der Quellcode-Übergabe bis zum heruntergeladenen Markdown-Bündel ab. Drei Eingangsquellen stehen zur Verfügung; die anschließende Analyse erfasst Sprachen, Frameworks, Endpunkte, Konfigurationsschlüssel und Abhängigkeiten und erzeugt sechs zusammenhängende Dokumente einschließlich eines begleitenden Generierungs-Reports.

Anwendungsszenarien

  • Erstdokumentation eines bestehenden Projekts — Eine bislang undokumentierte Codebasis erhält eine vollständige Markdown-Grundlage mit Architekturübersicht, API-Referenz und Installationsanleitung, die anschließend manuell verfeinert werden kann.
  • Standardisierung über mehrere Projekte — Mehrere Projekte erhalten eine einheitlich strukturierte Dokumentation mit gleicher Datei-Aufteilung, gleicher Diagramm-Konvention und gleicher Tonalität.
  • Onboarding neuer Mitarbeiter:innen — Architektur- und API-Übersichten dienen als Einstieg in eine fremde Codebasis, ohne dass das Team eine vollständige Einführungsdokumentation neu schreiben muss.
  • Periodische Re-Generierung als Baseline — Bei größeren Code-Änderungen wird die generierte Fassung neu erzeugt und mit der manuell gepflegten Fassung verglichen, um veraltete Stellen zu identifizieren.
  • Migration einer GitLab-Codebasis — Ein Repository wird ohne lokalen Checkout direkt aus GitLab geladen, analysiert und in einen durchsuchbaren Markdown-Dokumentensatz überführt.

Auf einen Blick

  • Drei Eingangsquellen: lokales Verzeichnis, ZIP-Upload, GitLab-API
  • Tiefen-Unterstützung für vier Frameworks; generischer Fallback für übrige Python- und PHP-Codebasen
  • Sechs ausgegebene Dokumente plus Generierungs-Report, einzeln aktivierbar
  • Zwei separat konfigurierbare LLM-Endpunkte mit optionalem Thinking-Modus
  • Test-Dateien standardmäßig ausgeschlossen, mit Opt-in zuschaltbar
  • Vorschau einzelner Dokumente in der Oberfläche, gerendert und als Quelltext
  • ZIP-Bündel als einheitlicher Download mit datierter Dateibenennung

Eingangsquellen und Authentifizierung

Drei Quellen werden über eine gemeinsame Source-Loader-Komponente angesprochen. Die Quelle wird in der Oberfläche umgeschaltet; Eingabefelder folgen der Auswahl.

  • Lokales Verzeichnis — Ein bereits ausgechecktes Projekt wird direkt aus dem Dateisystem analysiert. Geeignet für Codebasen, die bereits auf demselben System verfügbar sind.
  • ZIP-Upload — Eine ZIP-Datei wird in ein temporäres Arbeitsverzeichnis entpackt. Enthält das Archiv ein einziges Wurzelverzeichnis, wird dieses automatisch als Projektwurzel verwendet.
  • GitLab-Repository — Ein Projekt wird über die GitLab-REST-API geladen, sowohl von gitlab.com als auch von selbstgehosteten Instanzen. Eingabe erfolgt über Pfad (Gruppe/Projekt) oder numerische ID; Branch oder Tag sind optional. Das Personal-Access-Token mit Scope read_repository verbleibt ausschließlich im Session-Status, wird nicht persistiert und kann jederzeit aus der Oberfläche entfernt werden.

Sprachmodell-Anbindung

CodeDocumentation verbindet sich gegen zwei OpenAI-kompatible Endpunkte, die getrennt konfiguriert werden.

  • Schnelles Modell — Wird in der Analysephase parallel auf einzelne Dateien angewendet, in der Regel mit deaktiviertem Thinking-Modus.
  • Thinking-Modell — Wird in der Erzeugungsphase für die Fließtext-Abschnitte und die Projekt-Charakterisierung verwendet.
  • Verbindungstest — Beide Endpunkte können vor einem Lauf einzeln getestet werden, um Konfigurations- und Authentifizierungsfehler frühzeitig zu erkennen.
  • Thinking-Erweiterungen — Der nicht-standardisierte Parameter enable_thinking wird über extra_body an die OpenAI-Schnittstelle weitergereicht. Endpunkte ohne Unterstützung ignorieren den Parameter oder lehnen ihn ab; in diesem Fall lässt sich der Modus per Checkbox abschalten.

Erfasste Strukturen

Die Analyse trennt zwischen deterministischer Inspektion und modellgestützter Auswertung.

  • Sprachen und Frameworks — Sprachen werden über Datei-Endungen und Lines of Code gewichtet; Frameworks werden anhand von Abhängigkeitsdateien und Quellcode-Signalen erkannt.
  • Endpunkte und Routen — FastAPI, Flask, Laravel und Symfony werden über dedizierte Extraktoren ausgewertet, einschließlich Pfad-Parametern, Methoden und Tags. Für übrige Codebasen liefert ein generischer Regex-Extraktor eine Grundabdeckung.
  • Konfigurationsschlüssel — Umgebungsvariablen aus .env-Dateien, Konfigurationsdateien (z.B. config/*.yml) und Dockerfile-ENV-Anweisungen werden erfasst.
  • Abhängigkeiten — composer.json/composer.lock, requirements.txt, pyproject.toml und Poetry-Manifeste werden ausgewertet.
  • Build- und Betriebsumgebung — Dockerfile (Basis-Image, Ports, Entrypoint, Env), Docker-Compose-Dienste, Makefile-Targets sowie CI-Konfigurationen für GitLab CI und GitHub Actions werden geparst.
  • Pro Datei — Zweck, öffentliche Klassen und Funktionen, bemerkenswerte Eigenschaften und ein Wichtigkeits-Score werden modellgestützt ermittelt.

Erzeugte Dokumente

Pro Lauf werden bis zu sechs Dokumente plus ein Generierungs-Report erzeugt.

  • README — Übersicht, Beschreibung, Schlüssel-Funktionen, Schnellstart, Tech-Stack und Verweise auf die übrigen Dokumente.
  • Architektur — Überblick, Mermaid-Komponenten-Diagramm, Modul-Struktur als Tabelle, externe Abhängigkeiten.
  • API-Referenz — Endpunkt-Katalog gruppiert nach Ressource, mit Methode, Pfad, Parametern und Schemata, sofern aus dem Code ableitbar.
  • Konfiguration — Tabelle der Umgebungsvariablen, Liste der Konfigurationsdateien, Dockerfile-Variablen.
  • Installation — Voraussetzungen, Installationsschritte, Docker-Variante, CI-Übersicht.
  • Highlights — Auffällige Technologie-Entscheidungen, ungewöhnliche Implementierungen und kompakte Projekt-Kennzahlen.
  • Generierungs-Report — Laufzeit, Modellaufrufe und Token-Verbrauch je Modellrolle, erkannte Sprachen und Frameworks, Hinweise zur manuellen Nachbearbeitung.

Einzelne Dokumente lassen sich vor dem Lauf abwählen.

Qualitätssichernde Mechanismen

  • Deterministische und modellgestützte Quellen kombiniert — Endpunkte aus framework-spezifischen Extraktoren und solche aus Modell-Analysen werden zusammengeführt und über Methode und Pfad dedupliziert.
  • Wichtigkeits-Bewertung — Jeder Datei wird ein Score zugewiesen, der die Reihenfolge in den erzeugten Dokumenten und die Auswahl der für die Charakterisierung herangezogenen Dateien steuert.
  • Aggregation auf Paket-Ebene — Datei-Analysen werden zu Paket-Übersichten verdichtet, mit Datei-Anzahl, Lines of Code, öffentlicher API und Endpunkten je Paket.
  • JSON-Robustheit — Modell-Antworten werden auch bei umschließenden Markdown-Code-Fences oder eingebetteten Texten geparst; bei Fehlschlag wird leer zurückgegeben statt fehlerhafte Daten weiterzureichen.
  • Thinking-Block-Behandlung — <think>-Abschnitte aus Thinking-Modellen werden vor der Weiterverarbeitung entfernt, einschließlich abgeschnittener, unvollständiger Blöcke.
  • Wiederholungslogik — LLM-Aufrufe werden bei Fehlern bis zu dreimal mit exponentiellem Backoff wiederholt; Tokenkosten werden je Modellrolle getrennt erfasst.
  • Begrenzte Parallelität — Die Anzahl gleichzeitiger Modell-Aufrufe in der Analysephase wird über eine Semaphore beschränkt und ist in der Oberfläche einstellbar.
  • Ausschlüsse und Filter — Generische Ausschlussmuster (z.B. virtuelle Environments, Build-Artefakte, Cache-Verzeichnisse) und Test-Dateien werden standardmäßig übersprungen; zusätzliche Glob-Muster lassen sich angeben. .gitignore-Einträge werden ergänzend ausgewertet.

Weitere Funktionen

  • Vorschau in der Oberfläche — Erzeugte Dateien lassen sich gerendert oder als Quelltext betrachten, ohne das ZIP herunterzuladen.
  • ZIP-Bündel mit Zeitstempel — Der Download enthält alle aktivierten Dokumente und den Report unter einem datierten Dateinamen.
  • Konfigurierbare Bind-Adresse und Port — Bind-Adresse, Port und Reverse-Proxy-Pfad-Präfix werden über Umgebungsvariablen gesetzt.