68 Zeilen
1.5 KiB
Markdown
68 Zeilen
1.5 KiB
Markdown
# VG-Environment Codex Workflow
|
|
|
|
## Grundprinzip
|
|
|
|
VG-Environment wird schrittweise modularisiert.
|
|
Grosse unkontrollierte Refactors sind ausdruecklich unerwuenscht.
|
|
|
|
## Codex-Arbeitsweise
|
|
|
|
- Kleine, klar abgegrenzte Prompts.
|
|
- Ein Git-Commit pro sinnvoller Aenderungseinheit.
|
|
- Vor groesseren Aenderungen immer Git-Status pruefen.
|
|
- Keine destruktiven Aenderungen ohne ausdrueckliche Freigabe.
|
|
- Keine stillen IndexedDB-Schemaaenderungen.
|
|
- Keine DB-Full-Scans.
|
|
- Keine Monster-Dateien.
|
|
|
|
## Empfohlene Codex-Chat-Trennung
|
|
|
|
Separate Codex-Kontexte fuer:
|
|
|
|
- VG-Core
|
|
- VG-Observe
|
|
- VG-Block
|
|
- VG-Graph
|
|
- Architektur / Dokumentation
|
|
- Export / Evidence
|
|
- Datenbank / IndexedDB
|
|
|
|
## Ziel der Trennung
|
|
|
|
- kleinere Kontexte
|
|
- weniger Halluzinationsrisiko
|
|
- bessere fachliche Isolation
|
|
- kontrollierbare Diffs
|
|
- nachvollziehbare Git-Historie
|
|
|
|
## Pflicht vor Refactors
|
|
|
|
Vor Refactors:
|
|
|
|
1. Git-Status pruefen
|
|
2. kleinen Zielbereich definieren
|
|
3. Architekturgrenzen beachten
|
|
4. moeglichst nur einen Verantwortungsbereich aendern
|
|
|
|
## IndexedDB-Regeln
|
|
|
|
- Migrationen nur additiv
|
|
- Keine destruktiven Schemaaenderungen
|
|
- Keine Loeschung historischer Evidenzen ohne ausdrueckliche Freigabe
|
|
|
|
## Forensische Regeln
|
|
|
|
- Beobachtung und Eingriff trennen
|
|
- Rohdaten moeglichst erhalten
|
|
- Auswertungen klar von Beobachtungen trennen
|
|
- Keine Behauptung staerker formulieren als die Datenlage
|
|
|
|
## Zielarchitektur
|
|
|
|
VG-Environment entwickelt sich als modularer Plattformansatz mit klar getrennten Verantwortlichkeiten zwischen:
|
|
|
|
- VG-Core
|
|
- VG-Observe
|
|
- VG-Block
|
|
- VG-Graph
|