VG-Environment/docs/architecture/codex-workflow.md

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