Edivora wird als Open-Source-Desktopanwendung mit lokaler Foto-, Video- und Audiobearbeitung entwickelt. Das Repository ist öffentlich. Externe Beiträge erfolgen über Forks und Pull Requests; direkte Änderungen auf main sind kein vorgesehener Beitragsweg. Beiträge von Menschen und Coding-Assistenten sind willkommen, solange Datenschutz, Dateischutz, Versionierung und nachgewiesene Funktionalität erhalten bleiben.
Verbindlich: AGENTS.md. Der produktive Entwicklungsstand ist nicht mit dem alten veröffentlichten Foto-Testpaket v0.1.0-alpha.1 gleichzusetzen. Vor einer Änderung README, Architektur, Medienprojekte und Roadmap lesen.
Unter Windows mit Python 3.12:
py -3.12 -m venv .venv
.venv\Scripts\python -m pip install -e .
.venv\Scripts\python tools\prepare_model.py
.venv\Scripts\python tools\prepare_voice_model.py
.venv\Scripts\python -m local_ai_photo_editorDie prepare_*.py-Schritte sind nur explizite Build-/Entwicklungsvorbereitung. Sie dürfen nicht in den Programmstart wandern. Modelle werden zur Laufzeit lokal und nur nach Prüfsummenabgleich geladen. Laufzeit benötigt weder Login noch Internetzugriff. Auf Linux/macOS kann man lokal entwickeln, eine Paket-/Hardware-Freigabe für diese Systeme wird dadurch nicht behauptet.
| Bereich | Dateien / Grenze |
|---|---|
| Start/CLI | src/local_ai_photo_editor/__main__.py; --tool photo|video|audio und unabhängige Prozesse |
| UI | src/local_ai_photo_editor/ui/, Übersetzungsdictionaries, theme.py |
| Foto-Operationen / Projekt | core/ inkl. project.py, mask.py, editing.py |
| Medien/Sequenzen/Projekte | core/media.py, media_sequence.py, media_project.py |
| KI und Isolation | ai/ und begrenzte Unterprozess-Jobs; keine Cloud-Adapter |
| Marke/Assets | branding.py, assets/*.svg, tools/brand_assets.py |
| Builds | tools/build_windows.py, .github/workflows/, THIRD_PARTY_NOTICES.md |
| Tests | tests/ (reine Coretests, GUI-Tests, Medien-/echte Modell-Smokes) |
Abhängigkeitsregel: core/ kennt weder Qt noch ONNX Runtime, UI ruft geprüfte Kernoperationen auf; ai/ kapselt Modellverifikation. Keine direkten Runtime-Downloads, Shell-Encoderaufrufe oder pickle-Deserialisierung.
$env:PYTHONPATH = "src"
.venv\Scripts\python -m unittest discover -s tests -v
.venv\Scripts\python -m compileall -q src tests tools
.venv\Scripts\python -m local_ai_photo_editor --media-smoke-test test-results/mediaBei GUI-Änderungen zusätzlich Qt im Offscreen-Modus (nur soweit die Testumgebung dies unterstützt) und echte deutsche/englische Screenshots prüfen. Für Modell- oder Windows-Änderungen die gepinnten echten Gewichte, Source- und Standalone-EXE sowie File-/Codec-Tests prüfen. Ein erfolgreiches Unit- oder Mock-Ergebnis belegt weder funktionierendes On-Device-KI-Modell noch ein auf Windows 11 funktionierendes Installationspaket.
- Problem und Abgrenzung: Für wen? Was ist die bisherige Funktion? Welche Medienformate, Projektversionen, Ressourcen- und Sicherheitsgrenzen gelten?
- Isolierte Umsetzung: Nicht-destruktive Kernoperation, begrenzter Worker/Encoder, verständliche DE/EN-Steuerung, explizite Vorschau/Übernahme/Abbruch.
- Regressionen: Erfolgs-, Fehler-, Abbruch-, Datei-Alias-, untrusted-input- und Versionsfälle. Bei Bildformaten Farb-/Alpha-/Metadatenkorrektheit prüfen; bei Sequenzen stille Clips und Streamwechsel.
- Dokumentation: README-Funktionsmatrix, Erste Schritte, Detaildokument, Roadmap, Modellhinweise und Lizenztexte konsistent anpassen; veraltete Zusagen entfernen.
- PR mit Nachweisen: Ausgeführte Befehle, exakter Stand, CI-Links, verbleibende manuelle Prüfungen, Lizenz-/Verteilungs-Gates. Kein automatisches „Release bereit“-Label auf Basis statischer Prüfung.
Gib dem Assistenten den Repository-Link und die Anweisung, AGENTS.md zuerst zu lesen. Er soll main und offene PRs vergleichen, veränderliche Aussagen am Code prüfen, keine Funktionen aus ungemergten PRs als aktuell ausgeben, nur in einem separaten Branch arbeiten und Tests/Limitierungen dokumentieren. Reproduzierbare kleine PRs sind besser als ein großflächiger Rewrite ohne Nachweise.
Sicherheit / verantwortliche Veröffentlichung: Keine Medienproben von Nutzern committen, keine geheimen Tokens oder internen Infrastrukturdaten veröffentlichen. Bei Sicherheitsschwachstellen SECURITY.md beachten und keine Ausnutzungsdetails in öffentlichen Issues posten.
Für ein neues verbreitetes Windows-Paket müssen Source- und Paket-Smoke, echter Offline-Modelltest, FFmpeg-Build-/Lizenzpflichten, Qt-/Modellumverteilung, realistische Codec-Tests und frische Windows-11-Abnahme separat belegt sein. Unsignierte Builds müssen als Teststände gekennzeichnet werden. Historische Nachweise dürfen nicht als Abnahme eines späteren Stands wiederverwendet werden.
- Vor einem neuen Issue oder PR bestehende offene und geschlossene Vorschläge prüfen.
- Repository forken, einen kleinen Feature-Branch anlegen, Tests und DE/EN-Übersetzungen ergänzen.
- PR-Vorlage ausfüllen. Neue Modelle/Bibliotheken nur mit überprüften Lizenzrechten für die konkreten Binärdateien aufnehmen.
- Keine Zugangsdaten, privaten Medien, internen Hostnamen oder persönlichen E-Mail-Adressen committen. Für Sicherheitslücken gelten die Regeln in SECURITY.md.
Private Commit-Adresse des Repository-Inhabers: 198997962+Cenn0@users.noreply.github.com. Für lokale neue Commits git config user.email '198997962+Cenn0@users.noreply.github.com' setzen. Zusätzlich auf GitHub unter Settings → Emails die E-Mail-Privatsphäre und das Blockieren von Pushes mit persönlicher Adresse aktivieren. Diese Einstellungen ändern die historische Commit-Metadaten nicht.
Before touching the 0.4 pipeline, read VIDEO_RESTORATION.md. Run the new protocol, history, real-model, cancellation, UI and geometry regressions. --suite-smoke-test <fresh-output-directory> must also pass in source and standalone form. Do not call classical presets AI, claim generic filter reversal or expand model/time/resource limits without new evidence.