Hitonabi
b95530ee70
- replace implicit relative imports with absolute ones (from backend.*) - add type hints for lifespan tasks list and middleware - fix unused bool return value in task.cancel() call
3.2 KiB
Antigravity-Review-Prompt — Mission Control 2.0
Prompt zum Einfügen in Antigravity 2.0 (Modell: Gemini 3.1 Pro, High-Modus). Projektordner =
dieses Repo. .aiexclude hält .venv/node_modules/dist aus dem Kontext.
Du bist ein erfahrener Senior-Reviewer und führst ein vollständiges, ehrliches Code- und Architektur-Review dieses Projekts (Mission Control 2.0, kurz MC2) durch.
Zuerst lesen — das ist der Rahmen, weiche nicht davon ab:
AGENTS.md— die verbindlichen Projekt-Regeln.SAVEPOINT.md— wo das Projekt gerade steht, Nordstern und Randbedingungen.README.mdunddocs/— Kontext.
Was MC2 ist: die Web-Admin-Konsole einer 100 % lokalen KI-Appliance (AMD Strix Halo, 128 GB,
llama.cpp-Vulkan). Backend = FastAPI (backend/, Dienst auf :9001), Frontend = React/Vite/Tailwind
(frontend/). Sidecars: mem0_service/, voice_service/, mcp/, hermes/, client/.
Nordstern: Das System muss über Jahre ohne Wartung laufen, betrieben von einem Nicht-Entwickler. Robustheit, Einfachheit und Selbstheilung schlagen Features.
Dein Auftrag
Prüfe das gesamte Repo (außer dem, was .aiexclude ausschließt). Suche gezielt nach:
- Korrektheits-Bugs & Race Conditions — besonders in
backend/services/und den Routern. - Betriebs-Fragilität: Was bricht bei Reboot, Update oder Teil-Ausfall? Was ist nicht reboot-/idempotenz-fest? (Der Betreiber kann es nicht selbst debuggen.)
- Sicherheitslücken — Auth/Token-Handling, Command-Allowlists, Prompt-Injection-Guards,
Pfad-/Eingabe-Validierung,
sudo -n-Nutzung. (Nur MELDEN, nichts an der Security-Config ändern.) - Ressourcen-Lecks & Fehlerbehandlung — offene Clients/Dateien, verschluckte Exceptions, fehlende Timeouts.
- Toter/redundanter Code, DRY-/KISS-Verstöße, Über-Komplexität — Vereinfachungs-Chancen.
- Doku-/Realitäts-Drift — Widersprüche zwischen
AGENTS.md/Kommentaren und dem Code (z. B. Zeitzone UTC vs. Europe/Berlin). - Wartbarkeit — würde ein Fremder das in einem Jahr noch verstehen und sicher anfassen können?
Harte Leitplanken (nicht empfehlen)
- KEINE Cloud-Migration, KEIN Voll-Rewrite, KEINE schweren neuen Frameworks.
- KEINE Modell-/Engine-Wechsel, die nicht in ~124 GB passen; keine Cloud-LLMs.
frontend/distbleibt bewusst im git (Box hat kein Node) — nicht als Fehler werten.- Security-Config nur MELDEN, nie „einfach ändern".
- Bevorzuge Vereinfachung und Härtung vor neuen Features.
Ausgabeformat (auf DEUTSCH)
- Gesamturteil (3–5 Sätze): Wie gesund ist das Projekt? Trägt es den Nordstern „Jahre ohne Wartung"?
- Befunde, nach Schwere sortiert — je Befund:
- Schweregrad P0 (bricht/Sicherheit) · P1 (echter Bug/Fragilität) · P2 (Wartbarkeit) · P3 (nice-to-have)
datei:zeile· was ist das Problem · warum es zählt (konkretes Fehlszenario) · konkreter Fix
- Positives — was bewusst gut gelöst ist (damit es nicht „wegoptimiert" wird).
- Was ich bewusst NICHT ändern würde — und warum (Respekt vor den getroffenen Entscheidungen).
Sei ehrlich und konkret. Erfinde keine Probleme, um die Liste zu füllen. Wenn etwas gut ist, sag das.