Verbindliche Projektregeln – alle Modelle, auch GPT-5.3-Codex-Spark

Diese Regeln gelten für jede neue Aufgabe in diesem Repository. Sie dokumentieren die ausdrücklichen Vorgaben des Nutzers vom 10. September 2026.

1. Vor Änderungen die aktuelle Basis nachweisen

• Lies zuerst Docs/PROJECT-STATE.json, die aktuellen Abschnitte von Docs/PROGRESS.md und Docs/DELIVERY.md. Frühere Chattexte oder ein zufällig vorhandener Build sind keine maßgebliche Ausgangsbasis.
• Führe vor der ersten Änderung & ./Tools/Check-ProjectBasis.ps1 aus. Die Prüfung ist rein lesend; sie startet weder Unity noch Tests. Prüfe außerdem git worktree list und git status --short.
• Maßgebliches gemeinsames Projekt ist C:\Unity Projects\Space Hero - Galactic Reclaimers, Integrationszweig main. Neue Worktrees müssen den aktuellen main und den letzten verifizierten Release-Quellcommit enthalten. Auch ein namensgleiches Unity-Projekt kann einen älteren Stand enthalten. Prüfe den tatsächlichen Pfad und Git-Verlauf.
• Melde zu Arbeitsbeginn knapp: verwendeter Projektpfad, Branch/Commit und aktuelle Releasebasis. Bei veralteter Basis erst die aktuellen Änderungen übernehmen; bei divergierenden oder fremden uncommitteten Änderungen nichts überschreiben. Kläre nur dann mit dem Nutzer, wenn die richtige Basis nicht eindeutig feststellbar ist. Kein stiller Rückgriff auf eine ältere Version.
• Andere aktive Worktrees können noch nicht integrierte Arbeit enthalten. Prüfe deren Status vor einer Zusammenführung; „neuester Zeitstempel“ ersetzt keine Integration. Keine fremden Änderungen verwerfen oder blind kopieren.
• Nach abgeschlossener Arbeit den geprüften Stand samt Regeln und Dokumentation in das gemeinsame main übernehmen, sofern dies ohne Überschreiben fremder Arbeit möglich ist. Sonst die noch offene Integration ausdrücklich melden. Einen allein im Worktree verbleibenden Stand nicht als synchronisiert ausgeben.

2. Bestehende Spielqualität und Umfang erhalten

• Bei einem begrenzten Feature nur den beauftragten Bereich ändern. Titelbild, Schriftarten, Menüs, Medien, Story, Missionen, Upgrades und Steuerung erhalten, solange keine konkrete Änderung daran beauftragt wurde.
• Aktuelle Produktion: Assets/SpaceHero, Szene Assets/SpaceHero/Scenes/SpaceHero.unity. Die ursprünglichen Szenen unter Assets/Scenes und Skripte unter Assets/Scripts sind nicht die aktuelle Produktionsbasis. Kein BuildOriginal für einen regulären Playtest.
• Der gute Referenzbuild SpaceHero-Playtest-20260909-200638 ist v28. Der danach erschienene SpaceHero-Playtest-20260909-205846 war irrtümlich aus v25 gebaut und darf nicht als Entwicklungsbasis verwendet werden. Die aktuelle, darüber hinaus weiterentwickelte Basis steht in Docs/PROJECT-STATE.json; nicht dauerhaft auf v28 zurücksetzen.
• Nutzerprofile und bestehende Releases nicht für Tests verändern. Testdaten ausschließlich in einem frischen, isolierten --spacehero-data-Verzeichnis.

3. Umfangreiche Tests nur nach ausdrücklicher Freigabe

• Ohne weitere Freigabe erlaubt: Code lesen, Diffs prüfen, Syntax/Kompilierung und ein kurzer, unmittelbar zur Änderung passender Einzeltest/Smokecheck. Bei reinen Dokumentationsänderungen keine Unity-, Spiel- oder Audiotests.
• Vor umfangreichen Tests die ausdrückliche Freigabe des Nutzers einholen. Dazu zählen vollständige Testsuiten, Kampagnen-/Mehrmissionsdurchläufe, größere GPU-/Screenshotserien, Audio-Messserien, Performance-/Dauertests und wiederholte breite Regressionen. Mehrere kleine Läufe nicht zur Umgehung dieser Regel zu einer umfangreichen Runde zusammensetzen.
• Vorher kurz Zweck, Umfang und ungefähr benötigte Zeit nennen. Bis zur Freigabe darf unabhängige Implementierungsarbeit weitergehen; diese Tests nicht starten. Ein allgemeines „GO“, „umsetzen“ oder „Build erstellen“ ist keine pauschale Freigabe für umfangreiche Tests. Alte Freigaben aus früheren Aufgaben gelten nicht automatisch für neue Aufgaben. Eine konkrete, bereits erteilte Testfreigabe im laufenden Auftrag nicht erneut abfragen.
• Werkzeugoption -ExtendedTestsApproved nur setzen, wenn diese Freigabe tatsächlich vorliegt; die Option selbst erteilt keine Erlaubnis. Prüfungen nicht durch direkte Unity-Aufrufe oder andere Skripte umgehen.
• Nach passenden bestandenen Checks keine zusätzlichen Testserien aus eigener Initiative anhängen. Nicht ausgeführte Prüfungen ehrlich benennen. Wenn der Nutzer selbst weitertestet, den angeforderten Playtest rechtzeitig liefern.

4. Releases nachvollziehbar liefern

• Alle Releases ausschließlich unter C:\Unity Projects\Space Hero - Galactic Reclaimers\Artifacts\Releases ablegen.
• Tools/Unity.ps1 und Tools/Package-Playtest.ps1 verwenden. Vor Paketierung Quellcommit und exakte Builddateien in einem Manifest festhalten; falls native QA freigegeben ist, den Bestand schon vor dieser QA einfrieren. Vorhandene Build-/Paketprüfungen nicht abschwächen oder umgehen.
• Neue Lieferung mit Tools/Verify-Playtest.py gegen Manifest und Anleitungen abgleichen. Ein erfolgreicher Build allein beweist nicht die richtige Basis.
• Nach einer verifizierten neuen Lieferung Docs/PROJECT-STATE.json, Docs/PROGRESS.md und Docs/DELIVERY.md aktualisieren und zusammen mit dem Spielstand im gemeinsamen main halten. Alte Prüfergebnisse nicht als neue Tests ausgeben. Die Testfreigaberegel gilt auch während der Paketierung.