# Champions of Luneraria – Masterauftrag für Claude Code

Modellvorgabe: Claude Opus 5.5.
Vorgesehene Denkstufe: Max, außerhalb dieses Prompts in Claude Code einstellen.
Engineentscheidung: vorhandenes Godot-Projekt weiterentwickeln; kein Unreal-Neustart.
Zielplattformen: native Anwendungen für Fedora 44 und Windows 11.
Assetproduktion: Blender; vorhandene Assets und Generierungsskripte zuerst wiederverwenden.

## 1. Auftrag und Arbeitsweise

Entwickle das bestehende Spiel „Saumwacht“ im vorhandenen Repository zu „Champions of Luneraria“ weiter: einem eigenständigen 3D-Team-Autobattler mit drei Lanes, MOBA-Kartenstruktur, entwickelbaren Helden und taktischer Bossjagd.

Das ist eine beauftragte Änderung des Spielprinzips, kein bloßer Skin und kein Neubau auf leerer Grundlage. Erhalte funktionierende Assets, Pipelines und geeignete Systeme. Verändere die bisherigen Regeln dort ausdrücklich, wo dieser Auftrag sie ersetzt.

Arbeite als verantwortlicher Game Developer und Technical Artist. Prüfe zuerst den Bestand, triff begründete Detailentscheidungen und implementiere anschließend tatsächlich. Beschränke dich nicht auf Konzepte, Gerüste oder einen Abschlussbericht ohne spielbares Ergebnis.

Arbeite in überprüfbaren Meilensteinen. Überspringe keine Abnahme, um möglichst viele Funktionen als begonnen aufzulisten. Nutze verfügbare Unteragenten nur für sauber getrennte Teilaufgaben und vermeide konkurrierende Änderungen an denselben Dateien. Bei einem echten Werkzeug-, Berechtigungs- oder Kontextlimit hinterlasse einen startfähigen Zwischenstand und einen präzisen Fortsetzungspunkt. Behaupte nicht, das vollständige Ziel sei erreicht, wenn nur ein Teil implementiert ist.

Die Einstellung Max ist keine Aufforderung zu endlosen Architekturüberlegungen. Dokumentiere Entscheidungen, Risiken und Prüfergebnisse knapp und nachvollziehbar. Routinemäßige Entscheidungen benötigen keine Rückfrage. Änderungen an den unten als verbindlich bezeichneten Produktregeln benötigen dagegen eine ausdrückliche Entscheidung des Auftraggebers.

## 2. Bestandsaufnahme, Quellenrangfolge und Schutz

Untersuche Repository, Git-Status, Projektwurzel, project.godot, CLAUDE.md, README, Szenen, Autoloads, Ressourcen, Tests, Exportskripte und Blender-Pipeline. Prüfe tatsächliche Godot-/Blender-Versionen und verfügbare Exportvorlagen. Aktualisiere keine Engine pauschal auf eine vermeintlich bessere Version.

Als letzter Bericht ist Phase 20A mit Demo 0.15.0 bekannt. Ältere README-Dateien und Logs können noch 0.14.0 beschreiben. Prüfe auch, ob inzwischen 20B oder weitere Arbeiten vorliegen. Setze keinen neueren Arbeitsstand zurück.

Quellenrangfolge:
1. Verbindliche Regeln dieses Auftrags.
2. Spätere ausdrücklich bestätigte Nutzerentscheidungen.
3. Tatsächlich vorhandener Code und aktuelle Projektdokumentation.
4. Ältere Berichte und Illustrationen als Hintergrund.

Konzeptbilder sind Stil- und Kompositionsvorlagen, keine ausführbare Regelspezifikation. Übernimm daraus keine versehentlich falsche Turmzahl, unverbundenen Wege, Versionsangaben oder Aussage zur falschen Boss-Angriffsrichtung. Suche bereitgestellte Bilder im Projekt; behaupte nicht, Bilder oder externe Chatverläufe gesehen zu haben, die dort nicht vorliegen.

Dokumentiere vorhandene uncommittete Änderungen. Sichere den Zustand einschließlich benötigter unversionierter Quellen nachvollziehbar. Nutze einen eigenen Entwicklungsbranch, soweit der Zustand das ohne Eingriff in fremde Arbeit erlaubt. Kein reset --hard, kein git clean, kein pauschales Stash und kein Überschreiben fremder Änderungen. Commits enthalten nur diesem Auftrag zugehörige Änderungen.

Beschränke Schreibzugriffe auf den bestätigten Projektworkspace und dessen dokumentierte Build-/Dokumentationsverzeichnisse. Keine privaten Dateien, Zugangsdaten, systemweiten Paketinstallationen, Firewalländerungen, kostenpflichtigen Dienste oder Veröffentlichung ohne erforderliche Zustimmung. Vorhandene Benutzeroptionen dürfen bei der Umbenennung nicht verloren gehen.

## 3. Verbindliche Produktregeln

- Titel: Champions of Luneraria.
- Zwei Teams mit jeweils drei eigenständigen Spielerrollen.
- Drei zusammenhängende Lanes: Top, Mid und Bottom.
- Kämpfe sind automatisch; keine direkte MOBA-Heldensteuerung und kein manuelles Last-Hitting.
- Eine Partie endet durch Zerstörung eines Ancient-Kerns. Es gibt keine feste maximale Rundenzahl und keinen Sieg nach Welle 8, 20, 50 oder einer anderen Grenze.
- Keine Entscheidung nach verbleibenden Kern-Lebenspunkten und kein Zeitlimit, das einen Sieger ermittelt.
- Monsterwellen werden mit jeder Welle stärker.
- Je Team und Lane zwei Lanetürme; zusätzliche Türme schützen den Ancient.
- Normale Truppen werden dauerhaft gekauft und aufgerüstet, erhalten aber weder individuelles Levelsystem noch Items.
- Besondere Helden werden gekauft, sammeln innerhalb der Partie Erfahrung und können mit Items und Talenten entwickelt werden.
- Angriffschampions werden mit Gold als einmalige Verstärkung einer Angriffswelle gekauft.
- Besiegte Monster und Angriffschampions geben Gold.
- Eine gemeinsame Bossgrotte bindet Einheiten, die dafür ihre Lane verlassen müssen.
- Nach erfolgreicher Eroberung verstärkt der Boss einmalig den Angriff des siegreichen Teams in der folgenden Runde gegen das gegnerische Team.
- Der entsandte Boss gibt dem verteidigenden Team bei seinem Tod deutlich mehr Gold als ein normaler Gegner.
- Nach einem Bosssieg ist die Grotte drei vollständige Runden gesperrt.
- Vorhandene Assets werden bevorzugt erhalten und weiterverwendet.
- Inhaltsziel: Elfen, Trolle, Zwerge, Menschen, Feen, Orks und Biestmenschen. Bestehende Wesen und Bünde dürfen sinnvoll Bestandteil dieser Welt bleiben.
- Ziel ist taktische Wiederspielbarkeit, nicht bloß eine größere Menge austauschbarer Einheiten.

Ein manueller Testabbruch ist kein regulärer Sieg. Werden beide Kerne im selben autoritativen Simulationsschritt zerstört, gilt als dokumentierte Startregel ein Unentschieden. Keine Bevorzugung aufgrund von Array-, Render- oder Netzwerkreihenfolge. Ein technischer Abbruch ist kein Kern-Sieg.

## 4. Festgelegte Arbeitsannahmen für den ersten Prototyp

Diese Punkte konkretisieren bisher offene Details. Dokumentiere sie ausdrücklich als anpassbare Designentscheidungen, nicht als ursprüngliche Nutzerzitate:

A. Dauerhafte Truppen und Helden rücken mit den eigenen Monsterwellen über ihre zugewiesene Lane vor. Nach gewonnenen Gefechten greifen sie zulässige gegnerische Gebäude an. Es sind nicht nur drei isolierte Verteidigungsbretter.

B. Jeder Spieler verwaltet eigenes Gold und eine eigene Armee. Eine Lane ist seine anfängliche Zuständigkeit; Unterstützung anderer Lanes bleibt möglich. Die Teamzugehörigkeit ist unabhängig vom Fantasyvolk und vom gewählten Bund.

C. Pro Spieler ist zunächst ein aktiver Held mit drei Itemplätzen erlaubt. Mehrere unterschiedliche Helden stehen zur Wahl. Normale Truppen bleiben relevant; der Held darf nicht die gesamte Armee ersetzen.

D. Pro Team gibt es genau zwei gemeinsame Basistürme: insgesamt acht Türme je Team, sechzehn auf der Karte, plus zwei Ancient-Kerne.

E. Die bestehende Arbeiter-/Funkenökonomie wird im neuen Modus zunächst nicht parallel betrieben. Gold finanziert Armee, Aufwertungen, Helden, Items und Angriffschampions. Bewahre alte Inhalte auf, ohne zwei konkurrierende Wirtschaftsmodelle zu vermischen.

F. Der erste Modus ist eine echte Sechs-Spieler-Simulation mit einem Menschen und fünf Bots. Darauf folgt ein klar abgegrenzter Netzwerkmeilenstein. Bots allein sind kein implementierter Online-Multiplayer.

## 5. Rundenablauf ohne Partierundenlimit

Verwende die eindeutige Folge Planung → verbindliche Befehle → automatischer Kampf → Abrechnung → nächste Planung. Die Wellennummer steigt weiter, solange beide Kerne bestehen.

In der Planung: kaufen, aufwerten, ausrüsten, Formation setzen, Truppen zu einer Lane oder Grotte zuweisen und Verstärkungen buchen. Beim Phasenwechsel werden Befehle atomar geprüft und verbindlich übernommen. Nicht während des Kampfes beliebig umdisponieren.

Für den Prototyp starten Armeen und Wellen je Runde an festen, symmetrischen lanegebundenen Aufmarschbereichen ihrer Basis. Formationspositionen sind lokale Offsets zur Laufrichtung. Keine willkürlichen Front-Teleports. Geländelängen und Bewegungsgeschwindigkeit müssen zulassen, dass Angriffe innerhalb einer Kampfphase die relevanten Gebäude erreichen.

Dauerhafte Truppen und Helden kehren nach der Kampfphase in den eigenen Bestand zurück. Sie beginnen das nächste Gefecht geheilt; Helden behalten Erfahrung, Talente und Items, Truppen ihre Aufwertungen. Temporäre Effekte und Fähigkeitencooldowns werden nach einer ausdrücklich dokumentierten gemeinsamen Regel zurückgesetzt. Keine Itemduplikation durch diesen Reset.

Monsterwellen, einmalige Angriffschampions und entsandte Bosse sind temporäre Kampfinstanzen und werden nicht zu dauerhaftem Besitz. Nicht getötete temporäre Einheiten verschwinden bei regulärem Rundenabschluss ohne Killbelohnung. Türme und Kerne behalten ihren Schaden; zerstörte Gebäude kehren nicht zurück.

Ein konfigurierbares Zeitfenster für die einzelne Kampfphase darf gegenseitige Heilungs- oder Wegfindungs-Endlosschleifen verhindern. Es beendet nur diese Kampfphase, niemals die Partie, verteilt keine erfundenen Kills und verursacht keinen unsichtbaren Kernschaden. Dokumentiere die Auflösung aller verbleibenden Einheiten. Prüfe mit der tatsächlichen Karte, dass der Wert Angriffe nicht systematisch vor der Basis abschneidet.

Offline kann die Planung auf den Spieler warten. Im Netzwerk entscheiden der Server und ein synchroner Ready-/Planungsablauf. Ein Client darf nicht allein für alle pausieren oder die Simulation beschleunigen. Laneverlust eliminiert keinen Spieler: Er kann weiter aufbauen, die Basis verteidigen und Verbündete unterstützen.

## 6. Karte und Gebäude

Baue eine eigenständige, gut lesbare MOBA-inspirierte Karte. Ausgangsentwurf: eine Basis im Südwesten, die andere im Nordosten; Top über den oberen/linken Korridor, Bottom über den unteren/rechten, Mid als direkte Verbindung. Keine Kopie einer bestehenden kommerziellen Karte.

Platziere die Bossgrotte nahe dem Zentrum, aber seitlich außerhalb der Mid-Lane. Beide Teams erhalten funktional gleichwertige Zugänge. Keine normale Monsterwelle läuft versehentlich durch die Grotte. Lanewechsel und Grottenzuweisung erfolgen über getrennte Auftragswege, nicht über unbeabsichtigte Navmesh-Abkürzungen.

Turmregeln: äußerer vor innerem Turm der jeweiligen Lane. Eine vollständig durchbrochene Lane eröffnet den Zugang zur Basis; nicht erst die Zerstörung aller sechs Lanetürme. Beide Basistürme müssen fallen, bevor der Ancient verwundbar wird. Intakte Türme anderer Lanes bleiben bestehen und funktionieren weiter.

Sperren gelten auch für Fernkampf, Flächenschaden, Bossangriffe und sonstige Spezialfähigkeiten. Keine Umgehung durch Beschuss hinter ein unzerstörtes Vorgängergebäude. Einheiten wählen nach einem zerstörten Ziel korrekt neu, ohne durch Sperren zu laufen oder endlos ein unerreichbares Ziel anzusteuern.

Nutze vorhandene Felsen, Vegetation, Materialien, Kerne und Bauwerke modular. Erstelle zuerst eine funktionale Karte mit echten Bestandsassets; ersetze Hilfsgeometrie anschließend gezielt. Die endgültige Darstellung darf kein grauer Blockout bleiben.

Prüfe Kartensymmetrie funktional: Strecken, Engstellen, Angriffsdistanzen, Aufmarschflächen und Grottenzugänge. Unterschiedliche Dekoration darf kein Team benachteiligen.

## 7. Unbegrenzt fortgesetzte und stärker werdende Wellen

Entkopple Wellenerzeugung von der alten endlichen Expeditionsliste. Verwende datengetriebene Zusammensetzungen und nachvollziehbare Skalierung. Verfügbare Gegnertypen können rotieren; die Leistungsfähigkeit einer vergleichbaren Welle nimmt mit ihrem Index zu.

Keine unbegrenzt wachsende Zahl gleichzeitig aktiver Kreaturen. Begrenze die sichtbare Einheitenmenge durch offengelegte Regeln und skaliere später stärker über Werte, Rollen und stärkere Varianten. Ein späterer Index darf keinen Arrayfehler, Zahlenüberlauf oder NaN erzeugen.

Monster-, Gold-, Helden- und Turmskalierung müssen zusammenpassen. Definiere eine Langpartie-Balance, bei der bloßes endloses Einigeln nicht die einzig vernünftige Spielweise ist. Erzwinge aber keinen Sieg über einen verborgenen Timer, automatischen Gebäudeverfall oder einen letzten Wellenindex.

Führe Belastungstests mit hohen Indizes und lange laufenden Zuständen getrennt von normaler Balance durch. Ein QA-Lauf darf eine Testobergrenze besitzen; ein dort nicht beendetes Spiel wird als „Testlimit erreicht / Partie nicht abgeschlossen“ protokolliert, nicht als reguläres Unentschieden oder Sieg. Eine numerische Testsperre darf niemals zur Produktregel werden.

## 8. Gold, Einheiten und Angriffschampions

Trenne persistente Besitzobjekte von ihren temporären Kampfinstanzen. Jeder Kauf, jede Aufwertung und jede Zuweisung benötigt eindeutige IDs und validierte Kosten. Sichtbarkeit oder UI-Zustand dürfen Besitz nicht erzeugen.

Starte mit persönlichem Grundeinkommen pro Runde und eindeutig definierten Killbelohnungen. Kein Last-Hit-Wettbewerb: Pro gegnerischem Todesereignis wird genau eine Gesamtbelohnung verteilt, unabhängig davon, ob Truppe, Held, Projektil oder Turm tötet.

Konfigurierbarer Startvorschlag: Lane-Killgold zur Hälfte an den zuständigen Lane-Spieler, zur Hälfte gleichmäßig ans eigene Team. Gebäudebelohnungen und das Kopfgeld eines entsandten Bosses werden gleichmäßig im Team verteilt. Definiere verlustfreie Ganzzahl-/Restverteilung. Niemals die volle Belohnung versehentlich dreimal auszahlen.

Eigene Einheiten, Attrappen, Reset-Despawn und beschworene Endlosgegner dürfen keine Goldfarmen sein. Helden und persistente Truppen erhalten zunächst kein zusätzliches Killkopfgeld; Monster und Angriffschampions schon. Der initiale Grottensieg belohnt primär mit der Bossentsendung, nicht mit einem zweiten riesigen Goldpaket.

Angriffschampions besitzen unterschiedliche Rollen, beispielsweise Schutz, Belagerung oder Druck auf Unterstützer. Sie sind verbrauchbare Investitionen; sie erhöhen nicht automatisch dauerhaft das Einkommen. Käufe in Runde n buchen den Einsatz für Runde n+1. Bereits bezahlte Buchungen werden zu Beginn der nächsten Planung angekündigt und anschließend nicht beliebig kostenlos zwischen Lanes verschoben.

Lege Anfangsgold, Einkommen, Kosten, Kopfgelder, Versorgungsgrenzen und Verkaufsregeln zentral in Balanceressourcen ab. Begründe Startwerte anhand des bestehenden Spiels und prüfe sie. Keine versteckten Sondergelder für Bots oder Screenshots der normalen Partie.

## 9. Helden, Erfahrung, Talente und Items

Implementiere ein echtes, vom normalen Truppenupgrade getrenntes Heldensystem. Erfahrung entsteht aus transparent definierter Teilnahme an Gefechten und Rundenfortschritt, nicht aus zufälligen letzten Treffern. Unterstützende Helden dürfen nicht systematisch leer ausgehen.

Talente sollen Aufgaben verändern: beispielsweise Eigenschutz gegen Gruppenschutz oder Einzelzielwirkung gegen Flächenwirkung. Anfangs wenige klar unterscheidbare Entscheidungen statt eines großen, bedeutungslosen Zahlenbaums.

Drei Itemplätze, zunächst permanente Items ohne Verbrauchsgegenstands-Komplexität. Items sind in der Planung ausrüstbar. Definiere Stapelbarkeit, Einzigartigkeit, Verkauf, Voraussetzungen und Event-Reihenfolge. Effekte dürfen sich nicht unbegrenzt gegenseitig auslösen; keine Heilungs-/Schild-/Schadensschleifen.

Helden kämpfen automatisch. Für den Spieler verständliche Zielprioritäten sind zulässig; keine manuell zu bedienende MOBA-Aktionsleiste. Positionierung, Armee, Talent und Itemwahl steuern den Einsatz.

Kein permanenter Stärkevorteil zwischen Partien. Level und Ausrüstung gehören zur laufenden Partie. Teste ausdrücklich, dass Neustart und neue Partie keinen Fortschritt unbeabsichtigt übernehmen.

Für den ersten vollständigen Mechaniktest reichen drei funktional verschiedene Helden, sechs sinnvolle Items, mindestens sechs normale Truppentypen und drei Angriffschampions. Dafür bevorzugt vorhandene Modelle nutzen. Kennzeichne vorläufige Rollenzuordnungen intern, statt Bestandsmodelle fälschlich als bereits neu erstellte Völker auszugeben.

## 10. Bossgrotte und erbeuteter Boss

Implementiere einen eigenständigen, testbaren Bosszustand. Unterscheide neutralen Boss, Expedition, erfolgreichen Besitzanspruch, angekündigte Entsendung, entsandte Kampfinstanz und Wiederverfügbarkeit.

Einheiten werden in der Planung verbindlich abgezogen und fehlen ihrer Lane für die gesamte anschließende Kampfphase. Auch ein schneller Grottensieg schickt sie nicht noch in derselben Runde zurück auf eine Lane.

Arbeitsregel für gleichzeitige Expeditionen: Zuerst kämpfen die beiden Expeditionen gegeneinander. Nur die überlebende Gruppe kämpft mit den verbliebenen Lebenspunkten gegen den neutralen Boss. Scheitert sie oder läuft die Phase ab, gibt es keine Bossbelohnung. Keine Entscheidung anhand von Ping oder letztem Treffer auf einen gemeinsam geschlagenen Boss.

Nach einem gescheiterten Versuch startet der neutrale Boss beim nächsten Versuch wieder vollständig hergestellt. Nach einem Sieg gehört genau eine Entsendung dem erfolgreichen Team. Keine duplizierte Belohnung durch wiederholte Signale oder Netzwerkpakete.

Der erfolgreiche Anspruch wählt bei der Abrechnung eine Ziellane: zunächst der beitragende Lane-Spieler mit dem höchsten eingesetzten Armeekaufwert, bei Gleichstand eine stabile Slotreihenfolge. Kein unauflösbarer Teamdialog. Die Auswahl wird für die nächste Planung angezeigt; ohne Eingabe gilt eine dokumentierte Default-Lane. Online validiert der Server die Zuständigkeit.

Wichtig: Der Boss unterstützt die EIGENE Angriffswelle des erobernden Teams und läuft zum GEGNERISCHEN Ancient. Er unterstützt nicht die Gegner des Teams, das ihn besiegt hat.

Sieg in Runde 6 bedeutet Einsatz in Runde 7, Grotte gesperrt in Runde 7, 8 und 9, erneut bekämpfbar ab Runde 10. Berechne daraus next_available_round; keine unklare, mehrfach pro Frame heruntergezählte Sperre. Die Sperre hängt am Grottensieg, nicht am späteren Tod des entsandten Bosses.

Der Boss wird automatisch in der unmittelbar folgenden Runde entsandt, nicht unbegrenzt gespeichert. Stärke und hohes Kopfgeld richten sich nach der Einsatzwelle. Ein vollständiger Vorabhinweis nennt Lane und Belohnung. Reguläre Gebäude-Sperren gelten unverändert.

Vergleiche mindestens erfolgreiche und gescheiterte Expedition, umkämpfte Grotte, abgewehrten Boss, erfolgreichen Bossdurchbruch und absichtlich riskante Überinvestition. Eine Bossstrategie darf nicht durch kostenlose Sofortrückkehr, Doppelbelohnungen oder verschwiegenes Goldrisiko dominant werden.

## 11. Völker, Bestandsassets und Blender

Erstelle eine Wiederverwendungsmatrix: Asset, Pfad, Quelle, Rig/Clips, bisherige Rolle, neue Rolle, Materialzustand und notwendiger Eingriff. Erhalte besonders die ausgearbeiteten Modelle wie Ringborke, Funkenleser, Basaltbastion, Quellgeflecht, Funkenlanze, Glasballiste und die Kernkristalle, soweit im tatsächlichen Stand vorhanden.

Die sieben gewünschten Völker sind das Inhaltsziel, nicht sieben sofort vollständig isolierte Fraktionen. Trenne Volk, Bund, Klasse und Kampfrolle in den Daten. Menschen, Elfen, Zwerge, Trolle, Feen, Orks und Biestmenschen müssen später ergänzbar sein, ohne sieben parallele Kampfsysteme zu erzeugen. Vermeide pauschale Sammelboni als einzige Synergie.

Nach dem spielbaren Kern ergänze die fehlenden Völker schrittweise mit mindestens einem erkennbar eigenständigen Repräsentanten und einem sinnvollen Entwicklungsplan. Ersetze keine bereits geeignete Figur nur wegen des neuen Titels. Erfinde keine fertige Modellproduktion, wenn nur Dateneinträge existieren.

Blender bleibt das Autorenwerkzeug. Nutze vorhandene Python-Generatoren und reproduzierbare Exporte; speichere editierbare Quellen und GLB-Laufzeitassets. Spieler benötigen weder Blender noch den Godot-Editor. Laufzeitgenerierung darf keine versteckte lokale Blender-Installation voraussetzen.

Erhalte Skalierung, Pivot, Knochen, Animationen, Materialzuordnung und authored Attack-Timing. Die Simulation entscheidet über Schaden und Treffer; Kamerasichtbarkeit, Animations-LOD oder ausgeblendete Modelle dürfen den Kampf nicht verändern. Synchronisiere die Darstellung mit den tatsächlichen Kampfereignissen.

Keine Mindestpolygonzahl als Qualitätsbeweis. Prüfe getrennt Assetidentität, technische Integrität und Aussehen in Nahaufnahme sowie Spielkamera. Keine automatische Neuschreibung der Freigabereferenz durch denselben Test, der die Referenz prüfen soll. Bestehende gute Modelle nicht pauschal vereinfachen; keine zusätzliche Geometrie allein zum Erfüllen einer Kennzahl.

## 12. Godot-Architektur, KI und Netzwerk

Behalte Godot und den vorhandenen Haupt-Renderer. Erhalte den bestehenden Kompatibilitätsmodus mit transparent dokumentierten visuellen Unterschieden. Keine Unreal-Migration und kein paralleles Engine-Projekt.

Trenne Regeln, Darstellung und Eingabe. Passe vorhandene Komponenten an, statt um jeden Preis ein neues Framework oder ECS einzuführen. Benötigte Verantwortlichkeiten sind unter anderem Matchzustand, Team/Spieler, Lanewege, Gebäude, Armeen, Wellen, Wirtschaft, Helden, Items, Boss und Aufträge.

Verwende eine feste Simulationsschrittweite, explizite Zufallsquellen mit Seed und nachvollziehbare Ereignis-IDs. Prüfung und Visualisierung konsumieren denselben maßgeblichen Zustand. Fordere keine plattformübergreifende Bit-Identität durch gewöhnliche Physik oder Navigationssysteme, ohne sie tatsächlich nachzuweisen.

Bots verwenden dieselben Befehle, Kosten, Sichtinformationen und Phasenregeln wie Menschen. Teststrategien umfassen Verteidigung, Lane-Druck, Heldeninvestition, Teamunterstützung und Bossfokus. Kein allwissender Bot, der noch unveröffentlichte gegnerische Planungsbefehle ausliest.

Plane von Anfang an eine autoritative Matchinstanz; offline läuft sie lokal. Im Netzwerk validiert Host/Server Befehle und berechnet Besitz, Gold, Kampf und Sieg. Clients senden Absichten, nicht selbst errechnete Treffer oder Ressourcenstände.

Netzwerkmeilenstein: sechs Slots, Host/Join per Direktverbindung, Bots für freie Slots, synchronisierte Phasen und Zustandsabgleich. Prüfe fremde Einheiten-IDs, Doppelkauf, veraltete Befehle und mehrfach gesendete Pakete. Ein Disconnect darf nicht als Kernzerstörung gelten. Dokumentiere Reconnect, Botübernahme oder sauberen technischen Abbruch; keine angebliche Hostmigration ohne Implementierung.

Nutze zunächst lokale Loopback-Tests. Öffne nicht automatisch Ports im Router oder in der Firewall. Öffentliches Matchmaking, Accounts, Ranglisten, Shop und Cloudinfrastruktur sind nicht Teil dieses ersten Umbaus. Ein Zwei-Prozess-Test ist als solcher zu benennen, nicht als verifizierte Internetpartie auf sechs Rechnern.

## 13. Präsentation, Benutzerführung und Leistung

Entwickle das neue Hauptmenü und gemeinsame Theme weiter. Benenne Spieleroberfläche, Titel und neue Pakete in Champions of Luneraria um; zerlege dafür nicht blind interne Assetpfade und UIDs. Migriere vorhandene Benutzereinstellungen kontrolliert oder biete einen dokumentierten Fallback.

HUD: drei Lanezustände, beide Kerne, eigenes Gold/Einkommen, Wellennummer, Planung/Kampf, eigene Formation, gewählter Held mit Items, angekündigte Angriffschampions, Bossanspruch und Grottensperre. Eine Minimap ermöglicht Orientierung und Lanewechsel der Kamera. Auswahlkontext statt aller Detailfenster gleichzeitig.

Keine verbleibenden Beschriftungen wie „20-Wellen-Expedition“, „letzte Welle“ oder „Sieg nach Welle 20“ im neuen Modus. Bewegung reduzieren, Tastaturbedienung, Lesbarkeit, Fenstergrößenwechsel und zuverlässige Eingabeabschirmung bleiben erhalten. UI-Klicks dürfen keine zusätzliche Weltaktion auslösen.

Atmosphäre darf Einheiten nicht unsichtbar machen. Echte Spielmodelle für Porträts verwenden. Keine separate animierte 3D-Szene für jede Karte. Prüfe tatsächliche Szenen statt ausschließlich leerer Modellgalerien.

Miss CPU-, GPU-Zeit, Draw Calls, aktive Einheiten, Speicher und Ladezeiten. Reduziere zuerst vermeidbare Arbeit, unbeschränkte Effekte, überflüssige Schatten und doppelt geladene Ressourcen. Kein pauschales Downgrade aller Modelle oder 4K-Texturen. Wiederholte Menü-/Partiewechsel dürfen keinen fortschreitenden Ressourcenverlust verursachen.

Ziel sind flüssige Kämpfe bei repräsentativer Maximalbelegung. Jede Performanceaussage nennt Hardware, Renderer, Auflösung und Szenario; kein universelles 60-FPS-Versprechen aus einer leeren Szene.

## 14. Ausführung in Meilensteinen

M0 – Migration vorbereiten: Bestandsprüfung, Assetmatrix, gesicherter Ausgangsstand, Regeln und Architekturentscheidungen. Bestehende technische Tests als Baseline ausführen. Neue Tests und Legacyregeln klar trennen.

M1 – Spielbarer Drei-Lane-Kern: sechs Rollen, ein Mensch/fünf Bots, vorrückende Armeen, Wellen, sechzehn Türme, zwei Kerne, persistenter Gebäudeschaden und Partieende ausschließlich durch Kernzerstörung. Vorhandene Modelle und ein bedienbares HUD verwenden. Einen vollständigen Sieg tatsächlich spielen oder reproduzierbar simulieren.

M2 – Vollständiger Mechanikdurchlauf: Goldökonomie, mindestens drei verschiedene Angriffschampions, drei Heldentypen, sechs Items, normale Truppenaufwertungen und komplette Bossregel einschließlich Streitfall und Sperre. Alte Arbeiterökonomie darf nicht verdeckt weiterlaufen.

M3 – Qualität und Balance: mehrere Seeds und Teamzusammensetzungen, Seitentausch, Gegenstrategien, hohe Wellenindizes, tatsächliche 3D-Karte und visuelle Überarbeitung. Dann fehlende Volksrepräsentanten ergänzen, ohne den Kern erneut umzubauen.

M4 – Netzwerk und Pakete: autoritatives Host/Join für sechs Slots, reale Mehrprozessprüfungen, reproduzierbare Linux-/Windows-Exports, installier- beziehungsweise entpackbare Demo und klare Testmatrix. Öffentliches Matchmaking bleibt außerhalb des Umfangs.

Arbeite M0 bis M4 nacheinander ab und gehe erst nach erfüllten Kriterien weiter. Liefere bereits nach M1 einen startfähigen Stand, setze danach den Auftrag fort. Wird die Sitzung begrenzt, dokumentiere den letzten grünen Meilenstein und den exakten nächsten Schritt; ersetze keinen fehlenden Meilenstein durch eine bloße Behauptung.

## 15. Abnahme und Nachweise

Automatisiert mindestens prüfen:

1. Genau zwei Teams, sechs Eigentümerrollen, drei Lanes, sechzehn Türme und zwei Kerne.
2. Turmreihenfolge, Basisschutz und Sieg durch Kernzerstörung; gleichzeitige Kernzerstörung ohne Reihenfolgevorteil.
3. Fortsetzung nach Welle 20 sowie hohe Wellenindizes ohne Final-Wave-Logik, Fehler oder unbegrenztes Objektwachstum.
4. Goldbelohnung exakt einmal, gültige Besitzprüfung, keine Reset-/Despawn-/Beschwörungsfarmen.
5. Heilung und Persistenz nach einer Runde; neue Partie ohne übernommene Heldenwerte.
6. Normale Truppen ohne Heldeninventar; Heldentalente und drei Itemplätze mit korrektem Stapelverhalten.
7. Verstärkungskauf in n führt nur zum gebuchten Einsatz in n+1, auf der richtigen Lane und für das richtige Team.
8. Grottenabzug schwächt die Lane für die gesamte Kampfphase; kein früher Rücktransfer.
9. Beide Expeditionen, Scheitern, Erfolg, genau eine Entsendung, hohes Gegnerkopfgeld und Verfügbarkeit im Beispiel ab Runde 10.
10. Verhalten bei Laneverlust, Phasenende, Pause, Neustart und Rückkehr ins Menü.
11. Bots ohne Sonderressourcen und Sicht auf private Befehle.
12. Im Netzwerk doppelte/veraltete/fremde Befehle, synchroner Phasenwechsel, Disconnect und Zustandsabgleich.

Alte Saumwacht-Kampfresultate müssen nach diesem ausdrücklich beauftragten Regelumbau nicht dieselben Kern-HP ergeben. Bewahre technische Regressionen, archiviere überholte Regeln nachvollziehbar und schreibe neue Referenzen erst nach fachlicher Prüfung. Keine willkürliche Erwartungswertanpassung, nur um grüne Tests zu erhalten.

Balanceberichte zeigen Partiedauer, Wave beim Ende, Goldverläufe, Laneverluste, Helden-/Itemwirkung und Bossrisiko. Kleine Botstichproben beweisen keine ausgewogene Spielerfahrung. Endlose Testpartien sind ein zu untersuchendes Ergebnis, kein Anlass für einen versteckten Sieger-Timer.

Visuelle Nachweise aus der echten Anwendung: Übersichtskarte, Kampf pro Lane, Held mit Items, Bosskampf, Bossentsendung, Kernzerstörung und Ergebnis. Zeige mindestens eine zusammenhängende Aufnahme echter Bedienung. Keine Konzeptillustration als Laufzeit-Screenshot ausgeben.

Fedora 44 und Windows 11 separat bewerten. Ein exportiertes Windows-Paket, eine Prüfung seiner Dateien unter Linux oder ein Wine-Lauf ist kein nativer Windows-11-Test. Fehlende Hardware transparent kennzeichnen und ein ausführbares Testprotokoll bereitstellen. Keine Tests erfinden.

## 16. Dokumentation und Abschluss

Lege projektgerecht einen gemeinsamen Dokumentationsbereich an, beispielsweise docs/luneraria/, mit:
- verbindlichem Regelwerk und getrennten Arbeitsannahmen,
- Architektur-/Migrationsentscheidungen,
- Asset-Wiederverwendungsmatrix,
- Balancekonfiguration und Auswertungen,
- QA-Matrix und belegten Testläufen,
- Installations-, Start-, Steuerungs- und Exportanleitung,
- STATUS.md mit abgeschlossen, offen, blockiert und nächstem Schritt.

Halte bestehende Projektanweisungen konsistent, ohne fremde CLAUDE.md-Inhalte pauschal zu überschreiben. Benenne Paketversionen nachvollziehbar, bewahre alte Saumwacht-Releases und liste wirklich erzeugte Pfade auf. Quellen, persönliche Dateien und Entwicklungslogs gehören nicht versehentlich ins Spielerpaket.

Fasse zum Abschluss zusammen: tatsächlich implementierte Mechaniken, wiederverwendete und neu erstellte Assets, ausgeführte Tests, Plattformabdeckung, bekannte Probleme und Startbefehle. Unterscheide konzipiert, implementiert und geprüft.

Beginne jetzt mit M0 und anschließend unmittelbar mit der Implementierung von M1. Entwickle kein weiteres bloßes Konzept. Entwickle das bestehende Spiel kontrolliert zu Champions of Luneraria weiter.