ReveLithEin Shell, getrennte Editoren und formatspezifische Engines
ReveLith vereint Dokumente, Tabellen, Präsentationen, PDF und Zeichnen in einer Desktop-Anwendung. Eine Electron-Shell öffnet Dateien in getrennten Editoren; jedes Format nutzt eigene Parser-, Modell-, Patch- oder Exportpfade. Gewöhnliches Öffnen, Bearbeiten und Speichern benötigt keinen KI-Anbieter.
Welche Aufgabe das System angeht
Office-Dateien sind strukturierte Container. Editoren unterscheiden sich darin, welche Strukturen sie erhalten oder neu serialisieren. Eine gemeinsame Oberfläche kann diese Unterschiede verbergen; die Architektur muss daher die jeweiligen Formatgrenzen kenntlich machen.
Wie Verantwortlichkeiten getrennt sind
Die Shell verwaltet Tabs, Dateirouting und App-Lebenszyklus. Isolierte Renderer nutzen schmale IPC-Bridges. Format-Engines verarbeiten lokale Dateien; optionale KI und Automatisierung sind separate Pfade.
Komponenten und Vertrauensgrenzen
Quellcode-abgeleitetes Systembild, keine bestätigte Live-Deployment-Topologie.
Fenster, Tabs, zuletzt verwendete Dateien, Einstellungen und Öffnen/Speichern.
Module haben getrennte Renderer und validierte Bridges zu privilegierten Prozessen.
Parser, Modelle und Speicherpfade unterscheiden sich je nach Dokument, Tabelle, Präsentation, PDF und Zeichnung.
Nur bei Aufruf einer KI-Funktion gehen Prompt und relevanter Kontext an den konfigurierten lokalen oder entfernten Anbieter.
CLI, MCP und Headless-Befehle decken begrenzte unterstützte Operationen ab; lokaler Desktop-MCP muss lokal bleiben.
Ein konkreter Pfad durch die Implementierung
Optionale Pfade und Grenzen sind in den Schritten benannt.
- SCHRITT 01
DOCX öffnen
Shell leitet die Datei an Docs und dessen DOCX-Parser.
- SCHRITT 02
Modell bilden
Der Engine-Code erstellt ein Blockmodell und ordnet unterstützten Strukturen XML-Offsets zu.
- SCHRITT 03
Bearbeiten
Änderungen aktualisieren das lokale Modell. KI ist ein optionaler Zweig im Editor.
- SCHRITT 04
Patchen und speichern
Unterstützte geänderte OOXML-Strukturen werden gezielt bearbeitet; andere Funktionen können beim Rundlauf abweichen.
- SCHRITT 05
AI Draw
Anbieter liefert strukturierte Diagrammargumente; lokaler Compiler prüft Geometrie und erstellt editierbare Elemente. Inhaltliche Korrektheit bleibt zu prüfen.
Was die Regel tatsächlich ausdrückt
Kein einheitlicher Speicheralgorithmus gilt für alle Module. Einige Engines patchen selektiv; andere serialisieren oder exportieren neu.
Quelldatei → Parser / Blockmodell → geänderte Strukturen → Patch oder Export → lokale Datei
Was sich aus dem Repository belegen lässt
Quellinventar, dokumentierte Ergebnisse und ausgeführte Prüfungen bleiben getrennt.
Das Repository beschreibt neun Desktopmodule und eine gemeinsame Shell.
Diagrammerstellung nutzt strukturierte Werkzeugargumente und lokale Geometrieprüfung; das garantiert kein fachlich richtiges Ergebnis.
Normale Dateioperationen bleiben lokal. Entfernte KI kann Prompt und relevanten Kontext übertragen.
CLI teilt Engines für unterstützte Lese-, Bearbeitungs-, Konvertierungs- und Renderingoperationen; Headless-Ausgabe deckt nicht jede Desktopfunktion ab.
Offene Annahmen und Risiken
Diese Punkte begrenzen, wie weit die Architektur- und Evidenzaussagen interpretiert werden sollten.
- 0.x-Status: Dateitreue hängt von Format, Parser und bearbeiteten Funktionen ab.
- Der Desktop-MCP-Server ist standardmäßig deaktiviert; falls aktiviert, bindet er laut Case-Study-Code an 127.0.0.1 ohne Authentifizierung.
- CLI-MCP über stdio und separat konfiguriertes HTTP haben unterschiedliche Grenzen.
- Vor Freigabe wichtiger Dokumente Ausgabe öffnen, vergleichen und sichern.
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.