1 Development
Claude edited this page 2026-06-29 21:37:15 +00:00

Development

Setup

cd server   && docker-compose up -d   # backend + postgres
cd frontend && npm run dev            # dev-server

Konventionen

Backend

  • Neuer Router → in server/main.py einbinden.
  • Neues Model → in server/models/__init__.py exportieren.
  • Auth via require_superadmin / require_read() / require_write().
  • Agent-ausgelöste Aktionen → CommandLog.
  • Nach jeder server/-Änderung: docker-compose up -d --build.

Frontend

  • Svelte 5 Runes: $state, $derived, $derived.by(()=>{}), $effect.
  • Alle API-Calls in $lib/api.ts registrieren.
  • CSS-Variablen statt Tailwind.

Komponenten-Granularität: 1 Tab / Panel / Modal = 1 .svelte-Datei

Keine Mehrzweck-Dateien. Jeder Tab, jedes Panel und jedes Modal lebt in einer eigenen, isolierten Komponente. Grund: einfacherer Support (Fehler → genau eine Datei), kleine/isolierte Diffs beim Review & Deploy, weniger Merge-Konflikte bei mehreren Contributors.

Bestehende Muster, an denen man sich orientiert:

  • lib/components/admin-node-tabs/ — 11 Node-Detail-Panels.
  • lib/components/admin-vm-modal/tabs/ — 16 VM-Modal-Tabs.
  • lib/components/dashboard/ — die Dashboard-Modals (Provision, NodeSettings, NodeNotes, InstallInfo, DeleteConfirm, QemuScan, HostUpdateLog, KernelCleanup, Vnc).

Regeln beim Zerlegen:

  • Props rein, Callbacks raus. Eine Komponente bekommt ihre Daten als Props und meldet Aktionen über onX-Callbacks zurück. Kein Import von Page-/Parent-State.
  • CSS wandert mit (scoped in die Komponente). Generische, global in +layout.svelte definierte Klassen (.modal, .modal-header, …) bleiben global; nur komponenten-spezifische Selektoren werden mitgenommen. Tote Styles im Parent danach entfernen.
  • Verhalten 1:1 — Extraktion ist kein Redesign. Jede Extraktion ein eigener, kleiner, revertierbarer Commit (kein Big-Bang).
  • Die Parent-Seite bleibt Orchestrierung: Daten laden, State halten, Komponenten verdrahten.

Node-Agent

  • Quellen in theprox_agent/, nach Änderung bundeln: cd Node-Agent && python bundle.py.
  • Version erhöhen + notes/changelog.md dokumentieren.

VM-Guest-Agent

  • Nach src/-Änderung Binary neu bauen + committen:
    cd VM-Guest-Agent
    cargo build --release --target x86_64-unknown-linux-musl
    cp target/x86_64-unknown-linux-musl/release/theprox-vm-agent theprox-vm-agent-x86_64
    
  • Version erhöhen + notes/changelog.md.

Aufgaben-Workflow

  • Tasks kommen als Markdown in notes/mustchange.md (UI: /notizen).
  • Erledigt: - [ ]- [x].
  • Erledigte Änderungen technisch in notes/changelog.md (Dateipfade, Funktionsnamen, Bug-Ursachen — keine Task-Titel-Kopien).

Changelog-Stil

Technisch und nachvollziehbar: Problem → betroffene Datei(en) mit Pfad → Fix im Detail. Siehe bestehende Einträge in notes/changelog.md.

Git

  • origin = ssh://git@git.itdata-gera.de:222/chinux/theProx.git
  • Conventional Commits. Nach Änderung: commit und push.