103 Zeilen
2.6 KiB
Markdown
103 Zeilen
2.6 KiB
Markdown
# VG-Environment Codex Workflow
|
|
|
|
Vor Beginn fachlicher Arbeiten ist `docs/architecture/project-philosophy.md` als maßgebliche Beschreibung des Projektkerns zu berücksichtigen.
|
|
|
|
## Grundprinzip
|
|
|
|
VG-Environment wird schrittweise modularisiert.
|
|
Grosse unkontrollierte Refactors sind ausdruecklich unerwuenscht.
|
|
|
|
## Path Conventions
|
|
|
|
Repo-Root ist:
|
|
|
|
`E:\_Jenno\Entwicklung\VG-Env`
|
|
|
|
Alle Pfadangaben in Codex-Prompts muessen eindeutig sein:
|
|
|
|
- entweder ausdruecklich relativ zu Repo-Root
|
|
- oder ausdruecklich relativ zum aktuell geoeffneten Workspace-Root
|
|
|
|
Standard ist:
|
|
|
|
Pfade sind relativ zu Repo-Root, wenn nichts anderes ausdruecklich gesagt wird.
|
|
|
|
Verbindliche Zielorte:
|
|
|
|
- Architektur-Dokumente: `docs/architecture/`
|
|
- Core-Code: `src/core/`
|
|
- Modul-Code: `src/modules/<module-name>/`
|
|
- Workspace-Dateien: `workspaces/`
|
|
|
|
Nicht erlaubt ohne ausdrueckliche Freigabe:
|
|
|
|
- `docs/`-Ordner innerhalb von `src/core/`
|
|
- `docs/`-Ordner innerhalb von `src/modules/`
|
|
- neue Architektur-Dokumente unterhalb von Runtime-Code-Verzeichnissen
|
|
- unklare relative Pfade in Multi-root-Workspaces
|
|
|
|
Hintergrund:
|
|
|
|
Multi-root Workspaces koennen relative Pfade missverstaendlich machen. Deshalb muessen Codex-Prompts kuenftig immer den Bezugspunkt nennen.
|
|
|
|
## 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
|