Hoard/codexInfo.md

Projektübersicht – self-hosted Datei- und Markdown-App

Projektidee

Ich baue eine einfache self-hosted Web-App, die sich funktional zwischen Google Drive, Notion und Obsidian einordnet. Der Schwerpunkt liegt aber klar auf einer Google-Drive-artigen Oberfläche mit Dateien und Ordnern. Markdown-Dateien sollen direkt im Browser bearbeitet werden können, andere Dateien sollen gespeichert und – wenn möglich – als Vorschau angezeigt werden.

Ziel des Projekts

Das Projekt ist ein kleines, bewusst einfach gehaltenes Solo-Projekt neben meiner Ausbildung. Es soll mehrere Benutzer unterstützen, aber technisch und funktional schlank bleiben. Wichtig ist ein realistisches MVP, das sauber läuft und später erweitert werden kann.

Geplanter Tech-Stack

• Frontend: Vue 3
• Markdown-Editor: md-editor-v3
• Backend: ASP.NET Core mit C#
• Datenbank: PostgreSQL
• Dateispeicher: MinIO als S3-kompatibler Storage
• Authentifizierung: klassische Cookie-basierte Authentifizierung, keine JWTs
• Deployment: self-hosted Web-App auf meinem eigenen Server

Kernfunktionen für das MVP

• Login mit bestehenden Accounts
• Kein öffentliches Registrieren
• Ein initialer Admin-Account wird zuerst erstellt
• Weitere Benutzer werden später nur manuell durch den Admin angelegt
• Dateien und Ordner anlegen, hochladen und öffnen
• Durch Ordnerstrukturen navigieren
• Google-Drive-artige Hauptansicht mit Dateiliste und Vorschau
• Markdown-Dateien direkt im Browser bearbeiten
• PDFs und Bilder als Vorschau anzeigen
• Andere Dateien einfach speichern und bei Bedarf herunterladen oder öffnen

Was bewusst nicht Teil des MVP ist

• Keine Registrierung für normale Nutzer
• Kein Teilen oder Freigeben von Dateien
• Keine Suche
• Keine Versionierung oder Dateihistorie
• Keine Echtzeit-Zusammenarbeit
• Keine Desktop-App oder Mobile-App
• Keine komplizierte Rechteverwaltung
• Keine JWT-, OAuth- oder SSO-Lösung

Gewünschter Stil der Anwendung

Die Oberfläche soll sich eher an Google Drive orientieren als an Notion oder Obsidian. Wichtig sind Übersicht, einfache Navigation und ein klarer Fokus auf Dateien, Ordner, Vorschau und Bearbeitung. Die App soll schlicht, pragmatisch und gut allein umsetzbar sein.

Sprachregel für UI-Texte

• Umlaute sind ausdrücklich erwünscht (ä, ö, ü, Ä, Ö, Ü).
• Keine Umschreibungen mit ae, oe, ue in sichtbaren deutschen Texten.

Wie die App später wirken soll

Die Anwendung soll wie eine einfache Dateiverwaltung im Browser wirken. Man meldet sich an, sieht seine Ordner und Dateien, kann sich durch die Struktur klicken, PDFs und Bilder direkt ansehen und Markdown-Dateien öffnen und bearbeiten. Der Fokus liegt auf Einfachheit statt auf vielen Sonderfunktionen.

Technische Leitidee

Das Projekt soll möglichst einfach aufgebaut werden. Dateimetadaten liegen in PostgreSQL, die eigentlichen Dateien in MinIO. Das Backend verwaltet Login, Benutzer, Ordner, Dateien und Vorschau-Informationen. Das Frontend bildet hauptsächlich die Dateiverwaltung, Vorschau und Markdown-Bearbeitung ab. Die gesamte Architektur soll bewusst schlank bleiben, damit sie für ein Solo-Projekt realistisch ist.

Projektbeschreibung für eine KI

Ich baue alleine neben meiner Ausbildung eine einfache self-hosted Web-App für mehrere Benutzer. Die App kombiniert eine Google-Drive-artige Dateiverwaltung mit einfacher Markdown-Bearbeitung. Benutzer sollen durch Ordner und Dateien navigieren können, Bilder und PDFs in einer Vorschau sehen und Markdown-Dateien direkt im Browser bearbeiten. Es gibt keine öffentliche Registrierung, kein Teilen, keine Suche und keine Versionierung. Benutzerkonten werden manuell angelegt, beginnend mit einem initialen Admin-Account. Der Tech-Stack besteht aus Vue 3 im Frontend, md-editor-v3 als Markdown-Editor, ASP.NET Core mit C# im Backend, PostgreSQL für Metadaten, MinIO als S3-kompatiblen Dateispeicher und Cookie-basierter Authentifizierung.

Frontend-Designquelle (Style Guide)

• Es gibt einen zentralen Design-Guide unter GUI/style.md.
• Dieser Guide definiert die visuelle Richtung für Hoard: light-first, dateiorientiert, ruhige Flächen, gezielte Verwendung von Grün als Markenfarbe.
• Enthalten sind Farbpalette, Typografie, Spacing, Border-Radien, Schatten, Komponentenregeln und Interaktionsprinzipien.

Angelegte globale CSS-Basis

• Statt app.css wurde eine zentrale globale Datei GUI/src/global.css angelegt und verwendet.
• Diese Datei wird in GUI/src/main.ts über import './global.css' eingebunden.
• Zusätzlich wurden modulare globale CSS-Dateien angelegt: GUI/src/styles/global/page-layouts.css und GUI/src/styles/global/surface-patterns.css.
• Beide Module werden ebenfalls zentral in GUI/src/main.ts eingebunden und bündeln wiederkehrende Layout-/Surface-Patterns.
• Inhaltlich stellt global.css bereit:
  • Design-Tokens als CSS-Variablen (:root) für Farben, Spacing, Radius, Schatten, Typografie und Statusfarben.
  • Globale Basisstile für html, body, Links, Überschriften, Fokuszustände und Scrollbars.
  • Vuetify-nahe globale Anpassungen für App-Shell und Standardkomponenten (Topbar, Sidebar, Cards, Buttons, Inputs, Tabellen).
  • Wiederverwendbare Utility-/Pattern-Klassen für Hoard-Seiten, z. B. hoard-panel, hoard-toolbar, hoard-list-row, hoard-empty-state, hoard-status.
  • Responsive Verhalten für kleinere Viewports per Media Query.

Anleitung: CSS-Patterns verwenden

• Neue Seiten standardmäßig mit hoard-page aufbauen; für zentrierte Vollhöhen-Ansichten zusätzlich hoard-page--centered.
• Karten-/Shell-Container als hoard-shell-grid hoard-panel verwenden; Breite/Abstände pro Seite über CSS-Variablen setzen (--hoard-shell-width, --hoard-shell-gap, --hoard-shell-padding).
• Wiederkehrende Headlines/Kicker mit hoard-kicker nutzen, Varianten bei Bedarf mit hoard-kicker--wide oder hoard-kicker--xs.
• Button-/Link-Aktionszeilen mit hoard-action-row bauen statt pro Seite eigene Flex-Definitionen zu duplizieren.
• Gradient-Flächen über hoard-panel-gradient + Variablen steuern (--hoard-gradient-angle, --hoard-gradient-start, --hoard-gradient-end, --hoard-gradient-end-stop), nicht pro Seite komplett neu definieren.
• Lokales scoped CSS nur für wirklich seitenspezifische Styles verwenden; alles Wiederverwendbare zuerst in GUI/src/styles/global/page-layouts.css oder GUI/src/styles/global/surface-patterns.css ergänzen.

Aktueller Stand

• GUI/src/Layout.vue bildet die zentrale App-Shell mit Topbar, Sidebar, Footer, Routen-Kontext und responsivem Drawer-Verhalten.
• Darkmode (light/dark) ist global integriert (Toggle in der Topbar, Persistenz in localStorage, Theme-Tokens in CSS/Vuetify).
• Öffentliche Kernseiten sind im einheitlichen Hoard-Stil umgesetzt: Home.vue (Landingpage), Login.vue, 404NotFound.vue, Impressum.vue.
• Das Topbar-Branding nutzt das App-Icon aus GUI/src/assets/images/icon.svg.
• Globale CSS-Struktur ist aktiv: GUI/src/global.css (Tokens/Basis) sowie GUI/src/styles/global/page-layouts.css und GUI/src/styles/global/surface-patterns.css für wiederverwendbare Patterns.
• Sidebar-Sichtbarkeit unterstützt Visibility.Route mit optionalem visibilityRoute in GUI/src/plugins/routesLayout.ts.
• Mobile-Touch-Optimierung ist für alle aktuellen öffentlichen Oberflächen aktiv (Shell, Home, Login, Impressum, 404), inklusive Safe-Area-Unterstützung.
• Desktop-Ansicht bleibt unverändert, da alle neuen Anpassungen ausschließlich in mobilen Breakpoints (<= 960px, Feinschliff <= 600px) umgesetzt sind.
• Backend-API ist auf ein Minimal-Setup reduziert und stellt aktuell den Test-Endpunkt GET /api/health bereit.
• Frontend-Build (npm run build im GUI-Projekt) schreibt direkt nach API/wwwroot; das Backend liefert die SPA und statische Assets aus.

Änderungen durch Codex

• Grundlegender UI-Neuaufbau der App-Shell (GUI/src/Layout.vue) inklusive Navigation, Footer und Seitenkontext.
• Einführung eines globalen Theme-Managements (light/dark) über GUI/src/plugins/vuetify.ts, GUI/src/global.css und localStorage.
• Überarbeitung der zentralen öffentlichen Seiten (Home.vue, Login.vue, 404NotFound.vue, Impressum.vue) auf ein einheitliches Hoard-Design.
• Erweiterung von GUI/src/plugins/routesLayout.ts um routeabhängige Sidebar-Sichtbarkeit (Visibility.Route, visibilityRoute).
• Konsolidierung der UI-Texte auf deutsche Umlaute gemäß Sprachregel.
• Aufbau und fortlaufende Konsolidierung der globalen CSS-Basis (global.css) inkl. Fokus-/Auswahl-Polish.
• CSS-Debloat-Refactor: gemeinsame Oberflächen-Patterns in GUI/src/styles/global/page-layouts.css und GUI/src/styles/global/surface-patterns.css ausgelagert und zentral in GUI/src/main.ts eingebunden.
• codexInfo.md um eine kompakte Nutzunganleitung für die globalen CSS-Patterns ergänzt.
• Mobile-Usability über globale Styles erweitert: größere Touch-Ziele (v-btn, Navigationspunkte), Safe-Area-Paddings und mobile Spacing-Feinschliff in GUI/src/global.css sowie den globalen Pattern-Dateien.
• GUI/src/Layout.vue für Mobile optimiert: entzerrte App-Bar-Abstände, touchfreundlicher Bottom-Sheet-Drawer und besser bedienbarer Footer auf kleinen Viewports.
• Mobile-spezifische Detailoptimierungen in Home.vue, Login.vue, Impressum.vue und 404NotFound.vue ergänzt (Actions, Card-/Form-Spacing, CTA-Stacking), ohne Desktop-Basislayout zu verändern.
• GUI/style.md um einen verbindlichen Abschnitt „Umsetzungsstandard Responsivität“ ergänzt (Breakpoints, Touch-Zielgrößen, Safe-Area, globale Pattern-Nutzung, QA-Checkliste), damit Folgeaufgaben denselben Stil beibehalten.
• Topbar-Kontext in GUI/src/Layout.vue für schmalere Breiten beruhigt: auf Mobile wird der Seitenkontext komplett ausgeblendet, auf mittleren Breiten bleibt nur der Seitentitel (ohne Unterzeile), damit das Header-Layout sauber und nicht gequetscht wirkt.
• Backend-Template-Code bereinigt: WeatherForecastController und WeatherForecast entfernt, OpenAPI-Templatepaket aus API/API.csproj entfernt.
• Neuen Test-Controller API/Controllers/HealthController.cs angelegt (GET /api/health), der 200 OK zurückgibt.
• GUI/vite.config.ts Build-Ausgabe auf API/wwwroot umgestellt (outDir) und Bereinigung des Zielordners beim Build aktiviert (emptyOutDir: true).
• API/Program.cs erweitert, damit statische Dateien aus wwwroot inkl. SPA-Fallback (index.html) ausgeliefert werden.
• SPA-Fallback im Backend aufgeteilt: Frontend-Routen liefern index.html, unbekannte /api/*-Routen bleiben korrekt 404 statt auf die SPA zu fallen.