TGV · Master-Konzept · Betrieb — Projekte · Stand 2026-07-15

Projekte & Constructor

Wie TGV Beratungs-/Leistungsprojekte trägt — und wie der Superadmin TGV in TGV selbst baut. Verbindliche Quellen: KONZEPT_NACHHALTIG_FIRST_PROJEKT_CONSTRUCTOR_ARBITRAGE_2026-07-15.md + TOWER_BRIEF_PROJEKT_TYP_A_CONSTRUCTOR_HANDOFF_2026-07-15.md (JC-Entscheide 15.07.). Die Prinzipien dahinter (Versionierung, Compliance, EU-Garantie): ♻️ Nachhaltig & Compliance First.

§1Projekt Typ A — was es ist (und was nicht)

Einordnung (JC C1, kein Parallelmodell): Projekt Typ A lebt in Welt A / prf_projects — es ist die noch fehlende Welt-A-Ausarbeitung unter der Entität (Plattform → Mandant → Entität → Projekt → Daten/Rechte/Regeln), zeitlich begrenzt, mit eigenem Datenleben, Regelsatz und internen/externen Mitgliedern. Drei Ebenen von Anfang an — gleiche Projektrollen, gleicher Scope, gleiche Versionierung, gleiche Archivierung; kein Bereich erfindet eine eigene Projektwahrheit:

Privat-Validierung (JC 28.07. via Tower#28): WH39-Verkauf = JCs erstes privates Typ-A-Projekt — die Projekt-Achse ist damit auch unter dem Privat-Mandanten validiert (Kaskade Plattform → Mandant → Entität privat → Projekt WH39), nicht nur für Firmen-Entitäten. Gleiche Projektrollen, gleicher Scope, gleiche Versionierung; ein privates Projekt ist kein Sonderfall, sondern dieselbe Wahrheit mit anderer Entität.

UI-Anschluss: Projektkarte im Hauptmenü (JC C5 — die Shell hat Projekt-WIP vorgesehen) · Projektmodule = Sichtbarkeit + Defaults, KEIN Capability-Lock (JC C4: KAI soll alles können, das UI soll nicht überfordern) · Adaptive Kontext-Rail statt dauerhafter dritter Spalte (Dokumente → Dokumentenbaum, Projekte → Projektnavigator) — an DESIGN#03 übergeben, hier nur Verweis.

§1bProjekt Typ B — was es ist (und worin es sich von Typ A unterscheidet)

Das Adapter-Prinzip (NUXIN-N, nicht zwei Produkte): EIN Kontrakt (SSOT) + geteilte UI/UX, dünne Adapter je Ziel — Typ B = flaches PHP (Anna = Referenz-Adapter), TGV = Supabase/RLS + vorhandene Skills. YAGNI: Kontrakt + Typ-B-Adapter zuerst, TGV-Adapter erst bei echtem Bedarf.

⚠️ Ehrlicher Ist-Stand (gemessen, nicht behauptet — TYPB#01 10.08.): die Typ-B-Struktur steht (Mig 204: world_subtype · stack · multi_tenant · prf_project_id), ist aber dormant — nur Mig 204 schreibt die Felder, kein Leser liest sie. Die Mandanten-Wand erreicht Welt B heute nicht (public.projects trägt live keine mandant_id; der Ausbau M2/M4 ist STAGED, M5 hat keine Migration). Und das eine externe Gesicht (Anna) liegt ganz ausserhalb TGV in PHP-Flat-Files. Kurz: Typ B ist als Achse entschieden, aber als Datenhaltung noch nicht durchgängig. Vollständiger Befund + Entscheidungsvorlage: Multi-Mandant §7 — Öffentliches Gesicht & Typ-B-Datenhaltung (hier verwiesen, nicht gedoppelt — §7.1 Ist-Stand).

§1aDie Projektnummer — Identität, mandanten-definiert

Das Format (gemessen, nicht erfunden): NN-YY-XXX + optionaler beschreibender Suffix — NN = Entität (nicht Typ!), YY = Jahr 2-stellig, XXX = laufende Nummer 3-stellig je Entität und Jahr. Beispiele aus dem Bestand: 03-26-007 (School of Transformation 2026) · 00-26-001-life-memory-gabriel.

Wo die Regel konfiguriert wird: prf_project_number_rules (Mig 245, STAGED) — eine Zeile je (mandant_id, entity_slug) mit entity_code (die NN), format_key, vergabe_modus und quelle. RLS mandant-scoped, Schreiben nur Mandant-Admin (Nummern sind Governance). Muster 1:1 aus der Beleg-Nr (Mig 216/217): 216 legt die Zahlen, 217 die eine Format-Funktion — hier tgv_projekt_nr · tgv_projekt_nr_gueltig · tgv_projekt_nr_vorschlag.

Anschluss: Der Skill projekt-anlegen (Tower#33 ②, noch nicht gebaut — im Skill-Register existiert heute nur rag-ingest-project, der befüllt statt anzulegen) liest diese Regel, holt über tgv_projekt_nr_vorschlag() eine Nummer, legt den Steckbrief an und dockt an die bestehende Struktur an — er erfindet keine eigene Nummernlogik. KAI nimmt den Auftrag entgegen (Tower#33 ③) erst, wenn der Skill steht.

Core-Graph im Projekt-/Entitätskontext (JC 25.09.2026, #3120; geschrieben, Bau offen). Ein eigener Screen soll dieselbe Graphansicht wie die KAI-Antwortkarte zeigen, eingegrenzt auf den erlaubten Betrachtungsraum. Persönliche Ansichten speichern Filter, Darstellungstiefe, Fokus und Layout — keine Kopie der Fachdaten und keine Prozessdefinition. Beim Wiederöffnen werden Daten und Rechte neu geprüft; entfernte Knoten oder entfallene Rechte dürfen nicht aus dem gespeicherten Zustand wieder erscheinen. Die erste Ausbaustufe braucht keine neue Freigabe- oder Team-Sharing-Funktion. Produktvertrag: Human First §8a.

§2Kaskade & Projekt-Versionierung — das Rückgrat

Projektlogik lebt in einer Vererbungs-Kaskade und wird NIE überschrieben, sondern versioniert (JC C2):

Global Default  →  Mandant Default  →  Entität Default  →  Projekt Override
z.B.: „Rechnungsentwurf nie ohne Freigabe"  →  —  →  „C3: 14 Tage, DE-Rechnung" / „C4: FR/TVA/Factur-X"  →  „EU-Förderprojekt: gesonderte Stunden-/Sachkosten-Berichte"

Projekt v1  →  Nachtrag 1  →  Projekt v2  →  Vertragsänderung  →  Projekt v3

§3Die Agenten — sparsam: Rollen statt neue Gehirne

Codex bestätigt unser Agent-vs-Skill-Modell wörtlich: viele „Agenten" sind KAI-Rollen mit Scope, Prompt und Toolset, nicht neue Gehirne. Zwei Rollen sind per JC entschieden, weitere sind Codex-VORSCHLÄGE (nicht kanonisch — ehrlich getrennt):

Der Constructor lässt den Superadmin TGV in TGV konzipieren: freie Beschreibung → Konstruktions-Steckbrief → Einordnung (Konfig? Prompt? Regel? Skill-Mapping? UI? DB? Code-Auftrag?) → Entwurf + Tests + Risiken + offene Entscheidungen → ApprovalCards. Nur Konfigurierbares wird direkt aktiviert — die harte Grenze:

Grafisch bauen ist eine eigene Baustelle (JC 25.09.2026, #3120). Der Core-Graph startet als Lese- und Erklärwerkzeug. Knoten verschieben oder eine Ansicht speichern ändert niemals Agenten, Skills oder Prozesse. Ein späterer grafischer Constructor darf sich in der Bedienung an n8n orientieren; die Ausführungsplattform ist damit nicht festgelegt. Feste Schrittfolgen und adaptive Agenten mit erlaubten Fähigkeiten müssen unterscheidbar bleiben. Echte Änderungen brauchen den bestehenden Constructor-Weg mit Berechtigung, versioniertem Entwurf, Auswirkungsprüfung, Tests, Freigabe und Rückweg. Kein Prozesseditor, kein Ausführen und kein Aktivieren im Sonntagsumfang des Core-Graphen. Gemeinsame Begriffe/IDs sind wiederverwendbar, die Schreibfähigkeit wird nicht vorweg eingebaut. Umfang und Lesefähigkeit.

§4Wizard-DB — deklarativ, zwei Führungsmodi

JC-Entscheid 14.1: Ein Wizard ist kein hartcodierter Einzeldialog, sondern eine deklarative Intentionserfüllungs-Struktur in einer Wizard-DB, die der Constructor pflegen kann: Intention → Scope → Kernfragen → offene/geschlossene Fragen → Arbitrage-Logik → Pflichtwissen → erlaubte Skills → Output-Steckbrief → Approval-Regeln. Beide Modi füllen DENSELBEN Steckbrief — der Unterschied ist nur die Dialogführung:

Reuse-Anker (R-V4-19): WIZARD#01 (Persona-Wizard, E1+E2 gebaut) + KONZEPT_WIZARD_ENGINE.md sind die Vorarbeit — die Wizard-DB ist deren Generalisierung, kein Neuanfang. Der „User führt"-Modus ist dasselbe Muster wie Human First §3 (Erzählung → Steckbrief → Bestätigung) und JCs Unterwegs-Erfassung.

§5Rechnung = Semantic Invoice Core — PDF ist nur Output

JC D1: KEIN PDF-first. Die Rechnung ist ein semantisches Datenobjekt, aus dem ALLE Ausgaben entstehen: PDF · EN 16931 / XRechnung / ZUGFeRD / Factur-X · UBL/CII · Plattform-Export · Archivpaket · Buchhalterpaket. Rechnungen sind Vorschläge, bis der User explizit freigibt (JC D3) — KAI erfindet keine Leistung, keinen Betrag, keine Steuerlogik; fehlt Vertrag/Stunden/Regel/Pflichtangabe, wird es als offene Frage markiert.

Je Rechnung speichert TGV: Land/Regime · Empfängerart B2B/B2G/B2C · Formatpflicht · Pflichtfelder · Validator-Version · Übermittlungsweg · Archivanforderung · User-Freigabe · Ausgabeartefakte. JC D4: E-Rechnung wird ein eigenes Modul (Codex-Vorschlag „COMPLIANCE#EINVOICE" — Lane-Name Tower-Hoheit). Anschluss Bestand: FES-AP3 (USt/MwSt, §13b) + Finanzen-Kanon liefern die Steuer-Vorarbeit — kein Parallelbau.

§6Empty-Mandant & PM-Layer — wachsen statt erschlagen

Empty-Mandant-Prinzip (JC 15.2): Ein neuer Mandant startet MINIMAL (Login · Rollenbasis · Sprache · Datenschutz-Grundkonfig · KAI-Onboarding · fast leeres Menü). Danach wächst die Oberfläche bedarfsorientiert: User beschreibt Ziel → KAI erkennt Intention → schlägt Module + nächste Schritte vor → User bestätigt → TGV blendet passende Menüpunkte ein. Sichtbarkeit ist KEIN Capability-Lock — Fähigkeiten bleiben innerhalb RLS erreichbar. Das ist UX-First + Human-First + KI-First zugleich: „Ich will Rechnungen stellen." → „Dafür brauchen wir Entität, Kunden, Vertragslogik — sollen wir mit der Kundendatenbank anfangen?"

PM-Layer (JC 15.1, Pflicht): Aufgaben, Termine, Protokolle, Kanban, Meetings, Meilensteine, Risiken, Statusberichte, Change Requests — als modularer Daten-/Agent-/Surface-Layer aus vorhandenen TGV-Bausteinen, ausdrücklich KEINE zweite Asana/Jira/Monday-Kopie:

§7Archivierung — eigenes TGV-Thema

JC 14.4: Hinter Projektverwaltung und CFO-Cockpit steht ein Archiv-Lifecycle für Mandant, Entität und Projekt — Archivierung ist nicht Ablage, sondern Compliance, CFO-Nachweis und Offboarding-Fähigkeit:

aktiv → pausiert → abgeschlossen → archiviert → aufbewahrungspflichtig
      → exportiert / gelöscht / wiedereröffnet

Umfasst: Schlussrechnung · Vertragsstand + Nachträge · Rechnungen + E-Rechnungsartefakte · Belege/Bankabgleich · Berichte · Projekt-RAG · Rollen-/Zugriffsende · Aufbewahrungsfristen · Exportpaket (Mandant/Kunde/Buchhalter) · Lösch-/Sperrkonzept. Anschlüsse: Lösch-3-Stufen + Erasure-FK-Vorbedingung (Sicherheit §7) · Periodenabschluss-Lock (FES-AP2) · Retention-Entscheidungen (Dokumente §6).

§8Bestands-Import — ChatGPT-Controllings werden Projekt-Artefakte

Der Tower-Brief liefert einen fertigen Extraktions-Prompt (18 Kapitel: Kurzprofil → Provenance → Steckbrief → Vertrag/Leistung → Stunden → Kosten → Rechnungs-/Controlling-Logik → PM → Compliance → Modulbedarf → Wizard-Fragen → Regeln → Datenmodell → offene Entscheide → MVP → YAML-Export), mit dem JC bestehende ChatGPT-/Excel-Projektcontrollings in strukturierte Projekt-Typ-A-Spezifikationen übersetzt — nichts wird verworfen, nichts erfunden („OFFEN / zu klären" statt Annahme). Plus Multi-Konversations-Modus: mehrere Chats zum selben Projekt werden dedupliziert, Widersprüche markiert, Provenance je Feld dokumentiert.

§9Anti-Drift, Reihenfolge & offene Calls

Anti-Drift (aus beiden SSOTs, die harten Nein): kein Projekt-Parallelmodell neben Welt A · kein AGENT-PROJEKT als zweites Gehirn · keine Rechnung PDF-only · keine EU-Behauptung ohne Checks · kein Prompt-/Regel-Overwrite ohne Version · kein Schreiben ohne Approval · kein Capability-Lock durch Sichtbarkeit · kein Wizard als Einzelflow · keine PM-App-Kopie · keine Menülawine für neue Mandanten · kein Build vor Tower-/JC-Gate für DB/RLS/Security/Finanzen.

Empfohlene Reihenfolge (Arbitrage §11): ① Bibel-Entscheid Nachhaltig-First ✅ → ② Runtime-Versionierungs-Konzept → ③ Projekt-Typ-A-Konzeptpaket → ④ Semantic Invoice Core → ⑤ Constructor-Konzept → ⑥ EU-Trust-Layer → ⑦ CFO-Cockpit → ⑧ Regulatory Watch / Deprecation.