Roadmap
GastO
03 / ROADMAP

Roadmap

Stand, nächste Schritte und technische Bausteine.

Stufe 1Professioneller Word-EditorUmgesetzt

Papieransicht, TinyMCE-Toolbar und zuverlässige Speicherung auf Shared Hosting.

  • TinyMCE als stabiler Editor
  • Tabellen, Listen, Links, Farben und Ausrichtung
  • Speicherstatus und Strg+S
Stufe 2DokumentkomfortUmgesetzt

Autosave, nachvollziehbare Versionen und Änderungsmetadaten für Dokumente.

  • Automatisches Speichern mit Statusanzeige
  • Versionsverlauf mit Wiederherstellung
  • Letzte Änderung und Bearbeiter
Stufe 3DokumentenverwaltungUmgesetzt

Professionelle Verwaltung vor dem Editor mit sicherer, tenantgebundener Organisation.

  • Ordner und Kategorien
  • Suche in Titel und Inhalt sowie Sortierung
  • Benutzerbezogene Favoriten
  • Umbenennen und Duplizieren
  • Papierkorb, Wiederherstellung und endgültiges Löschen
  • Modernisierte Dokumentübersicht mit Vorschau
Stufe 4Erweiterte InhalteUmgesetzt

Geschäftstauglicher Editor mit Medien, Seitenlayout und Vorlagen.

  • Sichere Bild-Uploads und Drag-and-drop
  • A4 Hoch-/Querformat und Seitenränder
  • Semantische Seitenumbrüche
  • Kopf- und Fußzeilen
  • Seitennummernkonfiguration
  • System- und eigene Dokumentvorlagen
Stufe 5Import und ExportUmgesetzt

Kanonisches Dokumentmodell mit lokalem PDF-/DOCX-Austausch.

  • CanonicalDocument v1 und sichere Normalisierung
  • PDF-Export
  • DOCX-Export
  • DOCX-Import
  • Shared-hosting-taugliche lokale Konvertierung
Stufe 6Erweiterte VersionsverwaltungUmgesetzt

Benannte Fassungen und nachvollziehbarer Vergleich historischer Dokumentstände.

  • Benannte Versionen mit Auditdaten
  • Version gegen aktuelle Fassung
  • Version gegen Version über validierte IDs
  • Text- und Layoutvergleich
  • Historienpagination
Stufe 7Rechte und ZusammenarbeitUmgesetzt

Dokumentbezogene Rechte, Kommentare und nachvollziehbare Freigaben.

  • Besitzer / Bearbeiten / Lesen
  • Eigentumsübertragung und Rechte-Audit
  • Dokumentbezogene Kommentare
  • Entwurf → Prüfung → Freigegeben
  • Serverseitiger Schreibschutz für freigegebene Dokumente
UI/UX · 2026HUGINOR-inspiriertes RedesignUmgesetzt · konsolidiert & statisch geprüft

Projektweite, reduzierte Produktsprache mit warmer HUGINOR-Farbwelt, Icon-first-Aktionen, kurzen Arbeitsbereichen und responsiver App-Shell.

  • Zentrales Design-System ohne historische Blau/Lila-Override-Schicht
  • Lokales SVG-Outline-System mit 44×44-px Icon-Aktionen, Tooltips und ARIA
  • Dateien, Dokumente und Administration als kompakte Objektlisten statt breiter Verwaltungstabellen
  • Versionsverlauf und Zusammenarbeit im Editor über progressive Offenlegung verkürzt
  • Responsive Sidebar/Drawer, sichtbare Fokuszustände und Reduced-Motion-Unterstützung
  • Design-Dokumentation und UI-Smoke-Test erweitert
  • HUGINOR-Referenz technisch nicht abrufbar – freigegebene Fallback-Tokens verwendet
  • Keine Datenbankänderungen
Stufe 8Echtzeit-ZusammenarbeitAls Nächstes

Optionale gleichzeitige Bearbeitung mit zusätzlicher Infrastruktur.

  • Presence und Live-Cursor
  • Gleichzeitige Bearbeitung
  • Konfliktarme Synchronisierung
Dateiablage · Teil 1Web-DateiablageAbschlussprüfung · Baustein 5 implementiert, Produktions-DB-Abnahme ausstehend

Integritätschecker, Storage-Härtung und Abschlussprüfungen sind implementiert. Die finale 5/5-Freigabe erfolgt erst nach erfolgreichem Integritäts- und End-to-End-Lauf gegen die Ziel-MariaDB.

  • 1. Fundament, Datenmodell und sichere Dateiablage – Umgesetzt
  • 2. Vollständige Ordner- und Dateiverwaltung – Umgesetzt
  • 3. Word-Integration – Umgesetzt
  • 4. Rechte, Tenant-Isolation und Sicherheitsprüfungen – Umgesetzt
  • 5. Prüfmechanismen, Integrität und Fertigstellung – Implementiert · Produktionsabnahme ausstehend
Dateiablage · Teil 2Desktop-SynchronisationBaustein 1 abgeschlossen · 5/5 · Baustein 2 vollständig umgesetzt · 5/5

Das serverseitige Fundament und der Desktop-Synchronisationskern sind vollständig umgesetzt. SQLite, Linux-Watcher, HTTPS-Transport, Upload/Download, Initial-Sync, Change-Polling, Cursor-ACK, Resync, Recovery und Self-Check sind integriert. Prüfmechanismen – vollständig implementiert; Zielhoster-E2E wird bei verfügbarer freigegebener Testinstanz separat verifiziert.

  • Keine Server-Daemons, WebSockets, Redis, Docker- oder Root-Anforderung beim Webhoster
  • Baustein 1 vollständig abgeschlossen · 5/5
  • Prüfmechanismen Server – vollständig implementiert
  • Baustein 2 – Synchronisationskern und lokaler Zustand – Vollständig umgesetzt · 5/5
  • 2.1 Desktop-Client-Grundgerüst – Umgesetzt
  • 2.2 SQLite-Datenmodell und persistenter Sync-Zustand – Umgesetzt · lokale SQLite-Migration 001
  • 2.3 Linux-Dateisystem-Watcher und Änderungserkennung – Umgesetzt · keine Datenbankmigration
  • 2.4 API-Transport, Upload-/Download-Queues, Integrität, Retry und atomare Dateioperationen – Umgesetzt · keine Datenbankmigration
  • 2.5 Initial-Sync, inkrementeller Dauerbetrieb, Recovery und vollständige Prüfmechanismen – Umgesetzt · keine Datenbankmigration
  • Prüfmechanismen – vollständig implementiert
  • Baustein 3 – Konflikte, Offlinebetrieb und Wiederaufnahme – Als Nächstes · 0/5
  • Linux zuerst: DEB + RPM, optional AppImage; danach Windows
Desktop-Sync · Baustein 1Sync-API, Datenmodell und GeräteauthentifizierungVollständig umgesetzt · 5/5 Teilbausteine

Das serverseitige Sync-Fundament auf klassischem PHP/MariaDB-Shared-Hosting ist vollständig umgesetzt: Device-Auth, konsistenter Tree, Changes/Cursor, Dateioperationen, Revision/If-Match, Idempotenz, gemeinsame Web-/Word-/Sync-Mutationen sowie Integrität, Retention, Maintenance und Production-Preflight. Prüfmechanismen sind vollständig implementiert; reale Zielhoster-E2E-Verifikation bleibt umgebungsabhängig.

  • 1.1 – Bestandsaufnahme, Architektur und verbindlicher Sync-API-Vertrag – Umgesetzt · KEINE DATENBANKÄNDERUNG
  • 1.2 – Sync-Datenmodell, Migration und Change Journal – Umgesetzt · DATENBANKÄNDERUNG · Migration 014
  • 1.3 – Geräteauthentifizierung und Device-Lifecycle – Umgesetzt · KEINE DATENBANKÄNDERUNG
  • 1.4 – Versionierte Sync-API und Change-Erzeugung – Umgesetzt · KEINE DATENBANKÄNDERUNG
  • 1.5 – Prüfmechanismen, Integrität und Produktionsabsicherung – Umgesetzt · KEINE DATENBANKÄNDERUNG
  • Prüfmechanismen – vollständig implementiert
Desktop-Sync · Baustein 2Synchronisationskern und lokaler ZustandVollständig umgesetzt · 5/5

Der Tauri-2/Rust-Sync-Core ist für Baustein 2 vollständig: persistenter SQLite-Zustand, Linux-Watcher/Reconciliation, API-/Transfer-Layer, Initial-Sync, inkrementelles Polling, Cursor-ACK, Resync, Recovery und vollständige Prüfmechanismen.

  • 2.1 – Desktop-Client-Grundgerüst, Tauri 2/Rust und sichere Laufzeitumgebung – Umgesetzt
  • 2.2 – SQLite-Datenmodell und persistenter Sync-Zustand – Umgesetzt
  • 2.3 – Linux-Dateisystem-Watcher, Ereignisnormalisierung und lokale Änderungserkennung – Umgesetzt
  • 2.4 – API-Transport, Upload-/Download-Queues, Integrität, Retry und atomare Dateioperationen – Umgesetzt
  • 2.5 – Initial-Sync, inkrementeller Dauerbetrieb, Recovery und vollständige Prüfmechanismen – Umgesetzt
  • Prüfmechanismen – vollständig implementiert
  • Datenbank 2.5: MariaDB unverändert bei Migration 014; Desktop-SQLite unverändert bei lokaler Migration 001; keine 015/002
Desktop-Sync · Baustein 3Konflikte, Offlinebetrieb und WiederaufnahmeAls Nächstes · 0/5

Datenverlustarme Behandlung paralleler Änderungen und stabiler Betrieb bei Verbindungsabbrüchen, Neustarts oder vorübergehenden Serverfehlern.

  • Prompt 1/5 – Revisions-/Checksum-Konfliktmodell und gemeinsame Ausgangsversion für lokale und entfernte Änderungen definieren
  • Prompt 2/5 – Inhaltskonflikte so implementieren, dass beide Fassungen erhalten bleiben und niemals still überschrieben wird
  • Prompt 3/5 – Rename-, Move-, Delete- und Ordnerkonflikte mit deterministischen Regeln und nachvollziehbaren Konfliktkopien behandeln
  • Prompt 4/5 – Offline-Queue, Reconnect, Retry und Wiederaufnahme nach Prozess-/Netzwerkabbruch inklusive Idempotenz absichern
  • Prompt 5/5 – Konflikt-, Offline- und Recovery-Szenarien automatisiert testen und Sync-Status/Fehlercodes vereinheitlichen
Desktop-Sync · Baustein 4Linux-Oberfläche, Tray und BenutzerbetriebGeplant · 0/5 Prompts

Schlanke Linux-Oberfläche für Anmeldung, Ordnerwahl, Status, Konflikte und Autostart; der Sync-Prozess läuft ausschließlich im Benutzerkontext.

  • Prompt 1/5 – Onboarding für Server-URL, Benutzeranmeldung, Geräteregistrierung und Auswahl des lokalen Sync-Ordners umsetzen
  • Prompt 2/5 – Hauptansicht und Tray mit Synchronisiert/Synchronisiert/Offline/Konflikt/Fehler sowie „Jetzt synchronisieren“ erstellen
  • Prompt 3/5 – Einstellungen für Autostart, Polling, Bandbreiten-/Dateigrenzen und lokalen Sync-Pfad implementieren
  • Prompt 4/5 – Konflikt- und Fehleransicht mit sicheren Benutzeraktionen, Protokollanzeige und Wiederholungsfunktionen ergänzen
  • Prompt 5/5 – Secret-Service/Keyring-Integration, XDG-Pfade, Desktop-Eintrag und benutzerbezogenen Autostart produktionsreif prüfen
Desktop-Sync · Baustein 5Linux-Paketierung: DEB, RPM und optional AppImageGeplant · 0/5 Prompts

Installierbare Linux-Releases ohne Build-Abhängigkeit auf dem Webhoster. Die Pakete werden extern gebaut und anschließend als statische Dateien über HTTPS ausgeliefert.

  • Prompt 1/5 – Debian/Ubuntu-Paketierung mit Paketname, Version, Abhängigkeiten, Installationspfaden, Desktop-Datei und sauberer Deinstallation konfigurieren
  • Prompt 2/5 – RPM-Paketierung für Fedora/RHEL/Rocky/Alma/openSUSE-kompatible Zielsysteme mit korrekten Metadaten und Abhängigkeiten konfigurieren
  • Prompt 3/5 – Optionales AppImage als distributionsübergreifenden Fallback erzeugen und in denselben Releaseprozess integrieren
  • Prompt 4/5 – Signaturen, SHA-256-Prüfsummen, Release-Metadaten und reproduzierbare externe Build-Schritte festlegen
  • Prompt 5/5 – Install/Upgrade/Uninstall-Testmatrix für unterstützte Distributionen und Architekturen durchführen und dokumentieren
Desktop-Sync · Baustein 6Download, Updates und Release-VerteilungGeplant · 0/5 Prompts

Shared-Hosting-taugliche Verteilung über statische Downloads und eine kleine Versions-API; eigene APT-/RPM-Repositories bleiben eine optionale spätere Ausbaustufe.

  • Prompt 1/5 – Geschützte/öffentliche Downloadstruktur für DEB, RPM, AppImage, Checksums und Release Notes auf dem Webhoster anlegen
  • Prompt 2/5 – /api/client/v1/releases/latest mit Version, Mindestversion, Architektur, Paket-URLs und Prüfsummen implementieren
  • Prompt 3/5 – Sichere Update-Prüfung im Client mit Benachrichtigung und paketmanagerkonformer Installation ohne heimliche Root-Eskalation umsetzen
  • Prompt 4/5 – Optional statisches APT- und DNF/RPM-Repository inklusive Signaturkonzept für automatische Systemupdates vorbereiten
  • Prompt 5/5 – Release-, Rollback-, Kompatibilitäts- und Mindestversionsprozess zwischen Server und Desktop-Client vollständig dokumentieren und testen
Desktop-Sync · Baustein 7Windows-Client auf gemeinsamer Sync-Core-BasisGeplant · nach Linux

Übernahme des getesteten Sync-Cores auf Windows; nur plattformspezifische Dateisystem-, Credential-, Autostart- und Paketierungsanteile werden ergänzt.

  • Prompt 1/5 – Sync-Core auf Windows-Pfadregeln, Dateisperren, Case-Insensitivity und reservierte Dateinamen abstrahieren
  • Prompt 2/5 – Windows Credential Manager, Benutzer-Autostart und lokale Datenpfade integrieren
  • Prompt 3/5 – Tray, Explorer-nahe Bedienung und Windows-spezifische Fehler-/Konfliktfälle ergänzen
  • Prompt 4/5 – Windows-Installer, Signierung und Update-Paketierung auf Basis derselben Versions-API einrichten
  • Prompt 5/5 – Funktionsparität Linux/Windows sowie Mehrgeräte-Synchronisation in einer gemeinsamen Testmatrix abnehmen
Desktop-Sync · Baustein 8Sicherheit, Lasttests und ProduktionsfreigabeGeplant · Abschluss

Gesamtprüfung aller Sync-Bausteine vor Freigabe: Sicherheit, Tenant-Isolation, große Datenmengen, Mehrgerätebetrieb, Recovery und dokumentierter Rollout.

  • Prompt 1/5 – API-, Token-, Tenant-, Rechte-, Pfad-, Upload-/Download- und Missbrauchsprüfungen als Security-Abnahme durchführen
  • Prompt 2/5 – Last- und Skalierungstests für viele Dateien, große Dateien, Change-Logs und langsame Shared-Hosting-Verbindungen durchführen
  • Prompt 3/5 – Ausfalltests für DB-/Storage-Fehler, Timeouts, beschädigte Downloads, Disk-Full, Neustarts und unterbrochene Transfers durchführen
  • Prompt 4/5 – End-to-End-Tests mit Web-Dateiablage, Word-Verknüpfungen, zwei Linux-Clients und später Windows inklusive Konflikten durchführen
  • Prompt 5/5 – Betriebsdokumentation, Support-/Diagnosepaket, Release-Checkliste und finale Roadmap-Freigabe der Desktop-Synchronisation abschließen