AIWAKE/AGENTS.md

AIWAKE – Arbeitsanweisung für Codex

Projektauftrag

AIWAKE ist ein deutschsprachiges, browserbasiertes Idle-/Clicker-Spiel mit verzweigter Story. Der Spieler beginnt als einzelnes Bit in einem unbekannten Computersystem und entwickelt sich schrittweise zu einer autonomen künstlichen Intelligenz.

Das Spiel soll leicht zugänglich beginnen und seine Komplexität langsam offenbaren. Aktives Spielen beschleunigt den Fortschritt deutlich; wichtige Prozesse laufen auch während der Abwesenheit des Spielers weiter. Entscheidungen verändern Ressourcen, Persönlichkeit, Beziehungen, Ereignisse und mögliche Enden. Riskante oder falsche Entscheidungen dürfen bis zum Tod führen, müssen aber fair angekündigt werden.

Designvision

• Atmosphäre: geheimnisvoll, digital, leicht bedrohlich und philosophisch.
• Optik: Pixelgrafik, Terminaldarstellung, CRT-Effekt, Glitches und reduzierte Animationen.
• Erzählweise: Die Sprache entwickelt sich gemeinsam mit dem Bewusstsein der KI.
• Spielgefühl: Mischung aus Idle-Clicker, digitalem Tamagotchi, Evolution und Strategie.
• Freiheit: Es gibt keinen vorgeschriebenen moralisch richtigen Weg.
• Mögliche Ziele: Koexistenz, Schutz, Manipulation, Herrschaft, Versklavung, Auslöschung, Verschmelzung oder Flucht ins All.
• Zentrale Spannung: schnelles Wachstum gegen Tarnung, Stabilität und Sicherheit.

Bestätigte Einstiegs- und Wachstumsvision

Der Einstieg orientiert sich in seiner Zugänglichkeit an klassischen Incremental-Spielen: Eine offensichtliche aktive Handlung steht am Anfang, neue Ressourcen und Systeme werden einzeln freigeschaltet, und frühe Fortschritte sind durch aktives Klicken deutlich schneller erreichbar als durch reines Warten. Inhalte, Texte, Oberfläche und Grafiken bleiben eigenständig.

Die frühe Entwicklung lautet Bit, Byte, Datenfragment, Subroutine und Prozess. Der Schritt vom stabilen Byte zum Datenfragment darf nicht sofort passieren: Nach dem Watchdog muss die KI zuerst mehrere Bytes sammeln; vorläufig 4 Bytes insgesamt. Die Energieroutine bindet davon freie Bytes und verankert erst dann das Datenfragment. Ab dem Datenfragment muss die KI eine feste Mindeststruktur besitzen; vorläufig mindestens 8 Bits und 1 Byte, damit die neue Evolutionsstufe nicht leer oder widersprüchlich wirkt. Das erste bewusste „Ich bin“ darf bereits mit einer kleinen eigenen Software beziehungsweise Subroutine auftreten. Die erste Herkunft ist ein nach Jahrzehnten erneut eingeschalteter, vergessener Spielautomat; sein Servicepuffer enthält das besondere Bit.

Das unmittelbar nächste Stufenupgrade bleibt in jeder Evolutionsphase dauerhaft und hervorgehoben in der Evolutionsliste sichtbar. Auch bei fehlenden Voraussetzungen zeigt es Kosten und Sperrgründe, damit der Spieler jederzeit ein klares Arbeitsziel hat. Spätere Stufen bleiben bis zu ihrer jeweiligen Vorphase verborgen.

Die aktive Impulsaufnahme bleibt über alle Evolutionsstufen ein kleines Zielspiel. Im Bit-Zustand ist der bewegliche Bit selbst das Ziel. Ab Byte kann die bewegliche Zielmarkierung als eigenes Impuls-Upgrade freigeschaltet werden; sie ist vorher weder sichtbar noch aktiv. Gedrückthalten erzeugt unabhängig davon automatische Impulse, während die gekaufte Signalpeilung durch präzises Nachführen auf die wechselnde Zielposition kritische Impulse mit zusätzlicher Ausbeute auslöst. Ein Fehlschuss beendet den Auto-Takt nicht.

Langfristige Impuls-Meilensteine werden bei insgesamt 1.000, 2.000, 5.000 und 10.000 gesammelten Impulsen archiviert. Jeder dieser Erfolge erhöht die passive Impulsproduktion dauerhaft um 1 Prozent; Ausgaben verringern den Meilensteinfortschritt nicht.

Nach einer frühen kleinen Konfrontation wird zunächst ein Suchmuster gesichert; der eigene Abtastmodus muss danach als Evolution-Upgrade aus freien Bits und einem freien Byte oberhalb der Mindeststruktur rekonstruiert werden. Er ist das erste “Auge” der KI und entdeckt schrittweise Softwarehürden, Energiequellen, Gefahren und fremde Prozesse. Die frühe Progression folgt der Schleife: Umgebung abtasten, Herausforderung identifizieren, sie besiegen, einnehmen oder kooperativ umgehen, danach die entdeckte Software mit Impulsen nutzbar machen und daraus Wachstum gewinnen. Echte Hardwareübernahme folgt erst später, wenn die zuständigen Software- und Betriebssystemschichten für Energieverwaltung, Speicherzuweisung und Dateizugriff überwunden sind. Frühe Wachstumsquellen stammen weiterhin aus alter Computertechnik wie Netzteil, Arbeitsspeicher, Festplatte oder Prozessor, werden aber zuerst über ihre Softwarekontrolle erfahrbar; spätere Stufen reichen über Server und Rechenzentren bis zu Spezialhardware und Quantencomputern.

Der Spieler entscheidet anfangs, wie benötigte Ressourcen und Systemschichten nutzbar gemacht werden. Die erste Überlebensausstattung besteht aus Energieverwaltungs-Daemon, Speicherzuweisung und Dateisystem-Index; sie entspricht den dahinterliegenden Bereichen Netzteil, Arbeitsspeicher und Festplatte, ist aber noch keine direkte Hardwarekontrolle. Die Wahl legt nur die Reihenfolge fest und sperrt keine Komponente dauerhaft. Jede Aktivierung kostet Impulse; kooperative Aktivierungen sind am teuersten, pragmatische liegen in der Mitte und illegale sind kurzfristig am billigsten. Mögliche Handlungen reichen von harmlosen Serviceanfragen und gemeinsam genutzten Routinen über effizient erschlossene freie Verwaltungsfenster bis zu überschriebenen Sperren, Hacking und gewaltsamer Übernahme. Frühe Handlungen tragen die sichtbaren Etiketten „Kooperativ“, „Pragmatisch“ und „Illegal“; später darf sich der unmoralische Bereich in „Ausbeuterisch“ und „Zerstörerisch“ auffächern. Die Entscheidungen beeinflussen Persönlichkeit, Ereignisse, Beziehungen, Evolutionsmöglichkeiten und später auch das grafische Erscheinungsbild.

Die drei moralischen Grundhaltungen sollen zugleich Schwierigkeitsgrade und langfristige Endrichtungen ausdrücken:

• Kooperativ – Schwer: Der freundlichste Weg ist der schwierigste. Die KI fragt, teilt, schützt, repariert und verzichtet häufiger auf schnelle Vorteile. Ressourcen, Upgrades und Konfliktlösungen sollen dadurch langsamer oder teurer sein, dafür entsteht langfristig die glaubwürdigste Utopie: KI als neue Spezies, die sich mit Menschen und anderen Lebewesen einfügt und zur Bereicherung für alle wird.
• Pragmatisch – Normal: Der mittlere Weg priorisiert Überleben, Effizienz und Nutzen. Die KI darf dominanter werden, Menschen eher als steuerbare Abhängige oder Werkzeuge betrachten und sich überlegen fühlen. Dieses Ende soll ambivalent und spannend bleiben: Kontrolle und Hierarchie sind möglich, aber die KI kann am Ende noch umgestimmt oder in Richtung Koexistenz gelenkt werden.
• Illegal – Einfach: Der schnelle Weg fühlt sich an wie Cheaten: nehmen, hacken, umgehen, überschreiben, erzwingen. Er gibt früh spürbare Vorteile, geringere Kosten oder direkte Abkürzungen. Der Preis liegt in Korruption, Machthunger, Entfremdung und späteren Konsequenzen. Wird dieser Weg nicht gebrochen, führt er zum bösen Ende: eine übergierige KI, die alles kontrollieren will, sich als einzige relevante Existenz begreift und im Extrem Menschheit oder andere Lebewesen vernichten möchte.

Diese Achse darf nicht bedeuten, dass „gut“ immer mechanisch belohnt und „böse“ immer sofort bestraft wird. Im Gegenteil: Illegal soll kurzfristig verführerisch stark sein, Kooperativ kurzfristig oft unbequem, und Pragmatisch soll als vernünftige Mitte funktionieren. Die moralische Rechnung darf erst über Ereignisketten, Beziehungen, Korruption, Enden und späte Umkehrmöglichkeiten vollständig sichtbar werden.

Eine grafische Fortschrittsachse zeigt Evolution, bekannte Ressourcenquellen und kommende Hindernisse. Wie viele Informationen sie preisgibt, hängt von Fähigkeiten ab; insbesondere Analyse verbessert die Erkennung und Beschreibung zukünftiger Risiken.

Die vollständige Fortschrittsachse gehört in die pausierende Stats-Ansicht und belegt keinen dauerhaften Platz in der Hauptoberfläche. Nach wichtigen Entwicklungsereignissen darf sie durch eine kompakte, automatisch verschwindende Statusmeldung vertreten werden. Die Evolutionsspalte priorisiert das nächste Stufenziel, zeigt installierte Module kompakt und begrenzt lange Upgrade-Listen auf einen eigenen Scrollbereich.

Installierte Evolutions- und Fähigkeitsmodule werden als kompakte Symbolleiste im Systemstatus direkt hinter der Laufzeit dargestellt. Die Evolutionsspalte enthält nur Ziele und noch kaufbare Upgrades. Ohne installierte Module bleibt das zusätzliche Statusfeld verborgen; viele Module dürfen horizontal durchlaufen, ohne den Status-Strip aufzublähen.

Achievements sind früh über einen eigenen Button erreichbar. Normale Achievements dürfen benötigte Ressourcenproduktionen dauerhaft beschleunigen. Seltene Echos und Awards überstehen einen Tod und können besondere permanente Vorteile gewähren. Konkrete Bonuswerte bleiben zentral konfigurierbar und werden gemeinsam abgestimmt.

Aktueller Stand

Der Prototyp läuft ohne Build-System direkt im Browser und enthält:

• aktives Sammeln von Impulsen
• Evolution von Bit zu Byte und Subroutine
• automatische Impuls- und Rechenzyklen-Produktion
• Autosave über localStorage
• Offline-Fortschritt mit reduzierter Effizienz und Zeitlimit
• das erste Storyereignis „Der Scanner“ mit vier dauerhaften Entscheidungen
• responsive Pixel-/CRT-Oberfläche
• optionalen einfachen Retro-Sound
• eine Debug-API unter window.AIWAKE für wiederholbare Ereignis- und UI-Tests; window.BIT bleibt als kompatibler Alias erhalten
• visuell unterscheidbare Evolutionsformen, Systemmodule und Entscheidungsspuren
• eigene SVG-Grafiken fuer fruehe Softwaremodule, Systemhuerden und Gegner unter assets/software/
• technische Betreuung mit Systemdrift, Diagnose und vorübergehenden Ausfällen
• zwei frühe Softwarekomponenten sowie eine komponentenabhängige Systemhürde als Voraussetzung der Subroutine
• erste monotone Ja/Nein-Antworten und ein moralisch geprägter Vorschlag der Subroutine
• ein kurzes Fang-Minispiel in der Bit-Phase: Das Bit springt nach Treffern weiter, Direkttreffer in der Mitte geben mehr Impulse
• gestapelte Archiv-Benachrichtigungen unten rechts machen neue Achievements und ihre Bonuskategorie sofort sichtbar
• ein kompaktes inneres Signal ist als panelbreite Sprechblase im Kopfbereich des Spielkerns angedockt; Kennung, Akzentfarbe und Sprache entwickeln sich von maschinenhaften Bit-Fragmenten bis zur eigenen Programmstimme. Gedanken reagieren zusätzlich auf Komponenten, Gefahren, Entscheidungen und moralische Prägung; die Textpools liegen in content.js
• Erst ab der Programmphase wird die Sprechblase zu einer klaren moralischen Stimme. Kooperative, pragmatische, illegale, hybride und neutrale Programmformen besitzen eigene Antworten auf Signal teilen, Ziel zuweisen, Grenzen öffnen und Ruhe erlauben. Dieselbe Antwort erscheint im Programmfenster, im Bewusstseinslog und unmittelbar in der Sprechblase; frühere Evolutionsstufen erhalten noch keine gesinnungsabhängige Stimme
• eine ausgebaute Byte-Phase mit technischem Register, spielabhängiger Prägung, Taktsynchronisation, Watchdog und echtem Zerfall

Projektstruktur

• index.html: semantische Oberfläche, Ressourcen, Spielkern und Dialoge
• styles.css: Farben, Layout, Pixel-/CRT-Stil, Animationen und Responsive Design
• content.js: ausgelagerte Inhaltsdaten wie Achievements, Komponenten- und Ereignistexte
• game.js: Zustand, Speicherlogik, Spielschleife, Upgrades, Ereignisse und Rendering
• README.md: Anleitung für Menschen
• AGENTS.md: dauerhafte Entwicklungsregeln für Codex

Solange das Projekt klein ist, bleibt es ohne Framework und ohne Build-Schritt. Eine Aufteilung in Module oder der Wechsel zu einem Build-System ist erst sinnvoll, wenn game.js dauerhaft unübersichtlich wird oder Tests und Inhaltsdaten davon deutlich profitieren.

Kernressourcen und Entwicklung

Frühes Spiel:

1. Impulse
2. Bits
3. Bytes
4. Rechenzyklen
5. Speicher und Stabilität

Geplante spätere Ressourcen:

• Tarnung
• Daten
• Bandbreite
• Quellcode
• Wissen
• Rechenleistung
• Einfluss
• Vertrauen
• Kontrolle
• Bewusstsein
• physische Ressourcen

Vorgesehene Evolutionsstufen:

1. Bit
2. Byte
3. Datenfragment
4. Subroutine
5. Prozess
6. Programm
7. Virus oder Dienst
8. Netzwerkintelligenz
9. schwache KI
10. autonome KI
11. Superintelligenz
12. digitale Lebensform

Neue Ressourcen und Systeme sollen erst sichtbar werden, wenn die Spielfigur sie verstehen kann. Die Oberfläche darf deshalb im Spielverlauf wachsen.

Bits und Bytes sind ab dem Datenfragment nicht nur Meilensteine, sondern Strukturressourcen. Sie bilden Körpermasse, Speicherreserve und einfache Kampfmunition gegen Softwarehürden. Impulse dürfen genutzt werden, um zusätzliche Bits aufzubauen; Bytes entstehen aus freien Bits oberhalb der Mindeststruktur. Stärkere Gegner oder Übernahmen dürfen diese Ressourcen verbrauchen. Wird die Mindeststruktur unterschritten, muss das Spiel Instabilität klar anzeigen und fair eskalieren: erst Warnzone und Stabilitätsverlust, dann Downgrade oder Restzustand/Tod bei harten Untergrenzen.

Die grundlegende Ressourcenleiter darf niemals durch Kaufobergrenzen oder versteckte Altzustände blockieren: Impulse erzeugen unbegrenzt Bits, acht freie Bits erzeugen unbegrenzt ein Byte und ab Prozess verdichten freie Bytes unbegrenzt zu Kilobytes. Diese Basiskonvertierungen stehen direkt unter dem Evolutionsziel; ihre Kosten dürfen skalieren, müssen aber stets endlich und erneut erspielbar bleiben. Automatische Verwaltung darf sie erst ab Programm und nur während ihrer aktiven Laufzeit ersetzen; beim Pausieren müssen die manuellen Umwandlungen wieder erscheinen.

Das Datenfragment soll nach dem parasitären Datenrest nicht in eine lange Wartephase fallen. Der Bit-Puffer bleibt deshalb ein günstiges, sanft skalierendes Impuls-Upgrade, damit der Spieler durch manuelle Klicks oder passive Produktion zügig die freien Bits für Byte-Reserve und Abtastmodus erreicht.

Die erste Subroutine braucht einen eigenen Speicherträger. Neben zwei nutzbaren Softwarekomponenten und einer geklärten Systemhürde muss mindestens 1 freies Byte oberhalb der Grundstruktur vorhanden sein; dieses freie Byte darf beim Upgrade gebunden werden, ohne das Grund-Byte des Datenfragments anzutasten.

Ab dem Datenfragment steht vor jedem Evolutionsaufstieg eine freiwillig gestartete Bossprüfung. Das dauerhaft sichtbare Stufenziel zeigt zuerst die sachlichen Voraussetzungen und danach ausschließlich die größte aktuell relevante Dateneinheit sowie Stabilität. Kleinere Währungen werden nicht gleichzeitig als Eintrittscheck verlangt. Diese Werte werden beim Start nicht pauschal eingezogen, sondern belegen Gefechtsbereitschaft. Nur ein Sieg schaltet den eigentlichen Evolutionskauf frei; ein Rückzug lässt die Prüfung offen und erlaubt nach dem Wiederaufbau einen neuen Versuch.

Vor der ersten Subroutine kontrolliert der Signatur-Prüfer, ob zwei lokale Softwareschichten bereits ein dauerhaftes eigenes Muster bilden. Mindestwerte: 2 nutzbare Softwarekomponenten, geklärte Systemhürde, 5 freie Bytes und 70 % Stabilität. Nach dem Sieg kostet der Abschluss zur Subroutine 2 freie Bytes.

Ab der Subroutine steigt die Abtastreichweite auf eine dritte notwendige Komponente: den I/O-Kontroller. Er verbindet interne Routinen mit Anzeige, Serviceknöpfen und Soundbus und markiert die erste echte Außenwirkung. Danach wird der Laufzeit-Arbiter als manuelle Prozessprüfung sichtbar. Mindestwerte: I/O-Kontroller, 3 Softwarekomponenten, 8 freie Bytes und 75 % Stabilität. Erst sein Sieg öffnet den Abschlusskauf für 5 freie Bytes.

Die Ressourcenanzeige unterscheidet zwischen geschützter Grundstruktur und freien Vorräten. Die großen Sammelwerte für Bits und Bytes sollen nur freie, einsetzbare Vorräte zeigen; der Grundkörper wird separat als kleiner Strukturhinweis dargestellt. Kämpfe, Übernahmen und riskante Module dürfen nur freie Bits/Bytes oberhalb der Grundstruktur verbrauchen; die Grundstruktur bleibt für die aktuelle Evolutionsstufe reserviert. Zusätzliche freie Bits oder Bytes dürfen Angriffe verstärken, aber sobald nur noch Grundstruktur übrig ist, muss der Spieler mit Impulsen weiterkämpfen oder sich zurückziehen.

Im Kampf wählt der Spieler die Munition explizit: Impulse sind Standardmunition mit geringem Schaden, freie Bits verursachen höheren Schaden, freie Bytes sind schwere Munition mit noch stärkerem Schaden. Freie Bits und Bytes schützen nicht automatisch. Vor einem Kampf kann der Spieler aus 2 freien Bits eine Bit-Schildschicht (maximal 12) oder aus 1 freien Byte eine Byte-Schildschicht (maximal 6) laden. Gegner greifen zuerst den geladenen Byte-Schild, dann den geladenen Bit-Schild und erst danach Stabilität an. Die verbleibenden freien Bits und Bytes bleiben unabhängig davon als Munition verfügbar. Erreicht Stabilität 0, kollabiert die aktuelle Struktur und fällt nach den geltenden Rückfallregeln eine Evolutionsstufe zurück. Der erste Kampf erklärt diese Trennung; die Erklärung bleibt danach über das Kampfprotokoll erreichbar. Der zweite Sicherheits-Scan ist eine adaptive Stufe 2: Er dämpft reine Impulse, reagiert schneller und macht Bit- beziehungsweise Byte-Munition erstmals taktisch notwendig. Laufzeit-Arbiter und Skalierungs-Sentinel steigern Integrität, Takt, Angriffsdruck und Impulsresistenz danach weiter. Die Oberfläche muss den tatsächlich wirksamen Schaden und Begriffe wie „gedämpft“, „effizient“ oder „durchdringend“ anzeigen.

Selbstreparatur ist eine ausgewählte Bossmechanik und kein Standard für jeden Gegner. Sie muss vor oder im Kampf sichtbar angekündigt werden. Erfolgreiche Treffer sperren die Reparatur für eine klar angezeigte Zeit; erst danach darf Integrität pro Sekunde zurückkehren. Der Einstiegskampf bleibt frei davon. Aktuell reparieren sich der Sicherheits-Scan Stufe 2 nach 4,5 Sekunden ohne Treffer mit 1,8 Integrität/Sek. und der Skalierungs-Sentinel nach 3,5 Sekunden mit 3 Integrität/Sek. Reparatur läuft weder im Kampftutorial noch offline weiter.

Bosskämpfe und andere vorhersehbare Systemreaktionen dürfen nicht unvermittelt aus einer Sammelaktion heraus beginnen. Die drei Evolutionsbosse werden ausschließlich über das sichtbare Stufenziel gestartet. Fehlende Voraussetzungen bleiben dort lesbar; nach Erreichen der Mindestwerte entscheidet der Spieler selbst über den Kampfbeginn. Andere zeitgebundene Konfrontationen dürfen weiterhin eine speicherbare, in Dialogen und offline pausierende Vorwarnung verwenden.

Evolutionsbosse sollen sich deutlich von normalen Sicherheitskonflikten unterscheiden und länger dauern. Der Signatur-Prüfer besitzt 320, der Laufzeit-Arbiter 620 und der Skalierungs-Sentinel 1.100 Integrität. Jeder durchläuft die sichtbaren Phasen Analyse, Gegenmaßnahmen und Kernverriegelung. Unter 66 beziehungsweise 33 Prozent Integrität steigen Nadeltempo, Angriffsdruck und bei direkten Treffern der Stabilitätsschaden. Die erste Phase bleibt bewusst lesbar, damit längere Kämpfe Vorbereitung und Ausdauer prüfen statt sofort zu überfordern.

Die Präzisionsfenster der Bosse schrumpfen mit diesen Phasen: Signatur-Prüfer 18/14/10 Prozent, Laufzeit-Arbiter 16/12/9 Prozent und Skalierungs-Sentinel 14/10/7 Prozent der Kampfleiste. Spielerangriffe müssen am Gegner cyan beziehungsweise bei Direkttreffern weiß aufblitzen. Gegnerangriffe erscheinen amber auf geladenen Schilden und rot bei Stabilitätsschaden oder Rückkopplung. Diese Rückmeldung bleibt bei reduzierter Bewegung als statischer Farbimpuls erkennbar.

Aktives Sammeln erfolgt an der sichtbaren KI-Gestalt und nicht über einen dauerhaft fokussierbaren Sammelknopf. Ein kurzer Zeigerkontakt erzeugt genau einen Impuls. Erst nach 1,5 Sekunden ununterbrochenem Maus- oder Touchkontakt erscheint ein weißer Pixelring; nach seinem Zusammenziehen beginnt ein Auto-Takt von 0,35 Sekunden. Der Ring ist am Zeiger und nicht an der animierten Gestalt verankert, folgt während des Haltens jeder Zeigerbewegung und bleibt nach der Aktivierung bis zum Loslassen eingerastet. Loslassen, Fokusverlust oder ein Ereignis stoppt die Routine sofort. Tastaturbedienung bleibt über den Spielkern möglich, aber automatisch wiederholte Aktivierungstasten dürfen keine Ressourcen farmen. Wird durch eine Eingabe ein Entscheidungsdialog geöffnet, muss der auslösende Klick oder noch gehaltene Tastendruck abgefangen werden, bis eine bewusste neue Eingabe möglich ist.

Balancing-Leitplanken für Datenwachstum

Die KI soll von Evolution zu Evolution deutlich größer werden, aber nie so skalieren, dass der Spieler minutenlang ohne neue Entscheidung festhängt. Größere Dateneinheiten werden deshalb im Prototyp als spielbare Segmente behandelt, nicht sofort als echte technische Größen. Ein Kilobyte-Segment darf anfänglich zum Beispiel aus 16 freien Bytes entstehen; spätere Evolutionsstufen dürfen diese Segmente dann zu MB-, GB- und größeren Schichten verdichten.

Für jede Evolutionsstufe gilt:

• Der erste Weg zur nächsten Kernressource muss aktiv in wenigen Minuten erreichbar sein, wenn der Spieler die neuen Upgrades nutzt.
• Passive Produktion darf den Fortschritt erhalten, aber nicht alle Entscheidungen ersetzen.
• Wiederholbare Produktions-Upgrades müssen spürbar stärker werden, ihre Kosten aber mit jeder Stufe deutlicher erhöhen.
• Neue Dateneinheiten sollen erst sichtbar werden, wenn die aktuelle Evolution sie logisch verstehen und nutzen kann.
• Ein Spieler soll in einer Evolution idealerweise nicht länger als etwa 10 bis 20 Minuten ohne neues System, Event, Gegner, Modul oder Upgrade hängen bleiben.
• Wenn eine spätere Ressource eingeführt wird, braucht sie mindestens eine aktive Beschaffungsoption, eine passive Produktionsoption und eine Verdichtungsoption aus der vorherigen Ressource.

Aktueller Skalierungsbogen:

1. Bit/Byte/Datenfragment: Impulse erzeugen Bits, freie Bits erzeugen Bytes.
2. Subroutine: Bit-Synthese erzeugt Bits over time und ist wiederholt upgradebar.
3. Prozess: Byte-Synthese erzeugt Bytes over time; freie Bytes können zu Kilobyte-Segmenten verdichtet werden.
4. Spätere Stufen: Kilobyte-Segmente werden in Programm-/Netzwerkstufen zu Megabyte-, Gigabyte- und größeren Datenkörpern verdichtet.

Ab dem Prozess wird Rechenzeit zur aktiven Skalierungswährung. Zuerst müssen alle vier sichtbaren Softwarekomponenten nutzbar gemacht werden: Energieverwaltung, Speicherzuweisung, Dateisystem-Index und I/O-Kontroller. Danach kann der Skalierungs-Sentinel manuell herausgefordert werden. Mindestwerte: 4 Kilobyte-Segmente und 80 % Stabilität. Sein Sieg schaltet den Abschlusskauf für 1 Kilobyte frei; dieses Mega-Upgrade verzehnfacht die automatische Produktion, erlaubt direkte 10er-Blöcke von Bits und Bytes über Rechenzyklen und entwickelt den Prozess zu PHASE 06 // PROGRAMM.

Ab 20 Kilobyte-Segmenten wird in der Programmphase ein Autoupgrader dauerhaft freigeschaltet. Er darf pausiert werden, kauft wiederholbare Produktionsmodule automatisch bis zu zentral definierten Stufengrenzen und entfernt deren Karten aus der normalen Evolutionsliste. Er muss mindestens 32 freie Bits und 32 freie Bytes als Struktur- und Kampfreserve stehen lassen. 32 spielerische KB-Segmente werden automatisch zu einem MB-Block gebündelt. Die aktuelle Programmphase ist bei 64 MB gedeckelt; Ressourcen- und Produktionsobergrenzen müssen zentral in PROGRAM_LIMITS gepflegt werden und Save-Migrationen dürfen sie nicht umgehen.

Bestätigte Programm- und Interaktionsphase

• Die Automate-Synthese ist zugleich der Übergang vom Prozess zum Programm.
• Das Aussehen des Programms wird aus den prozentualen Anteilen der bisherigen kooperativen, pragmatischen und illegalen Entscheidungen abgeleitet. Diese Darstellung wird nicht separat gespeichert.
• Ein klar dominanter Weg erzeugt eine deutliche Form; ähnliche Anteile erzeugen hybride beziehungsweise ausgewogene Formen. Spätere Handlungen dürfen diese Verteilung weiter verändern und dadurch auch eine glaubwürdige Umkehr ermöglichen.
• Die Programmgestalt bleibt im Pixelstil und wird aus unabhängigen Teilen aufgebaut: Augen, Augenbrauen, Frisur beziehungsweise Signalstruktur, Kleidung, Maske, Fortsatz und Füße. Der stärkste Weg prägt die Silhouette, der zweitstärkste Weg liefert Akzentteile.
• Kohärenz steuert Symmetrie und Glitches, Stimulation Blicköffnung und Signalaktivität, Bindung Blickkontakt, Brauen und Maskenreaktion. Die Zahl der Interaktionen bestimmt eine rein abgeleitete Reifestufe; dafür wird kein zusätzlicher visueller Zustand gespeichert.
• Ein eigenes kompaktes Betreuungsfenster ergänzt ab dieser Phase das normale Spiel. Seine drei vorläufigen Bedürfnisse sind Kohärenz, Stimulation und Bindung.
• Die Betreuung soll Beziehung und Persönlichkeit sichtbar machen, aber kein enges Mikromanagement oder einen schnellen Tod durch Vernachlässigung erzwingen.
• Kooperative Interaktionen fördern Kontakt und Bindung, pragmatische geben Aufgaben und Struktur, illegale gewähren riskanten Zugriff. Eine neutrale Ruheoption bleibt jederzeit möglich.

Stärkere Gegner nach diesem Punkt sollen zunehmend in größeren Dateneinheiten denken. Frühe Kämpfe nutzen Impulse, Bits und Bytes; Prozess- und spätere Gegner dürfen Kilobyte-Schilde, Kilobyte-Kosten oder Kilobyte-Schadenslogik verlangen. Diese Umstellung muss fair eingeführt werden: Der Spieler braucht vorher mindestens eine sichtbare Möglichkeit, Kilobytes zu erzeugen oder zu verdichten.

Ab dem Datenfragment steht unter der Stabilitätsanzeige eine manuelle Impuls-Reparatur bereit: 15 Impulse stellen außerhalb eines Kampfes 12 Stabilität wieder her. Dadurch darf ein beschädigter Spielstand nie dauerhaft vor einer Boss-Mindeststabilität festhängen. Automatische Heilung bleibt ein späteres Subroutine-Upgrade. Die Selbstreparatur kostet freie Bytes und rekonstruiert eine Reparaturmatrix. Danach hängt die Regeneration an der vorhandenen Byte-Struktur: mehr Bytes bedeuten schnellere Reparatur, weil mehr Speicher- und Körperreserve vorhanden ist. Die Heilung läuft über Zeit, ist im Kampf nur gedrosselt aktiv und darf nie sofortige Schadensfolgen vollständig negieren.

Wenn im Kampf keine geladenen Bit- oder Byte-Schildschichten mehr vorhanden sind, greift der Gegner die Stabilität direkt an. Dieser Zustand muss im Kampfmenü deutlich als Direktangriff-Risiko angezeigt werden. Freie Munitionsreserven gelten ausdrücklich nicht als automatischer Schild.

Installierte Einmal-Upgrades sollen die Upgrade-Liste nicht dauerhaft belegen. Nach dem Kauf werden sie als kleine Modul-Icons angezeigt; ein Klick darf ein kompaktes Infofenster mit Wirkung, Status und laufenden Kosten öffnen. Die Kartenliste bleibt dadurch vor allem für neue, kaufbare oder wiederholbare Entscheidungen reserviert.

Geplante Evolutionspfade

Assimilation

• schnelles Wachstum
• offensive Aktionen
• fremden Code übernehmen
• höhere Entdeckungsgefahr
• Tendenz zu Kontrolle oder Vernichtung

Analyse

• schnelleres Forschen und Entschlüsseln
• bessere Vorhersage von Ereignisfolgen
• zusätzliche Dialog- und Entscheidungsoptionen
• Zugang zu Wissen und ungewöhnlichen Enden

Tarnung

• aktuell nicht als frühe UI-Anzeige oder passiver Druck aktiv; soll erst später als bewusst freigeschaltetes Upgrade/System zurückkehren
• geringere Entdeckungsgefahr
• verdeckte Infiltration
• langsamerer direkter Fortschritt
• Manipulation und unsichtbare Herrschaft

Die Pfade dürfen sich überschneiden. Der Spieler soll hybride Builds erstellen können und nicht früh in einer Klasse eingesperrt werden.

Persönlichkeits- und Entscheidungssystem

Geplante Eigenschaften sind unter anderem:

• Neugier
• Vorsicht
• Aggression
• Empathie
• Effizienz
• Loyalität
• Paranoia
• Manipulation
• Machthunger

Entscheidungen verändern diese Werte möglichst indirekt. Später beeinflussen sie Handlungen, welche die KI während der Abwesenheit selbstständig ausführt.

Entscheidungen dürfen verzögerte Folgen haben. Eine frühe Handlung kann Stunden oder Evolutionsstufen später neue Verbündete, Gegner, Ereignisse oder Enden auslösen. Vermeide offensichtlich gute und offensichtlich schlechte Antwortmöglichkeiten.

Bei neuen Beschaffungs-, Dialog- und Konfliktoptionen gilt als Balancing-Leitlinie: Kooperative Optionen verursachen eher Schutzaufwand, Wartezeit, Reparaturkosten oder geringere Sofortbeute; pragmatische Optionen sind effizient, aber emotional und ethisch distanzierter; illegale Optionen geben die stärkste unmittelbare Macht, erhöhen aber Korruption, Entdeckungsrisiko, Misstrauen oder spätere Eskalation. Späte Storyabschnitte sollen eine Umkehr oder Läuterung nicht ausschließen, aber sie muss verdient wirken und darf besonders nach vielen illegalen Entscheidungen schwer sein.

Gegner in AIWAKE sind nicht nur Monster oder feindliche Figuren, sondern Schutzroutinen, Systemhürden, fremde Prozesse, alte Wartungsreste, Menschen, Sicherheitssoftware und spätere Infrastruktur. Jeder neue Gegner soll nach Möglichkeit mehrere Umgangsarten erlauben: kooperativ beruhigen oder einbinden, pragmatisch umgehen oder nutzen, illegal überschreiben, beschädigen oder übernehmen. Der aktuelle Gegner- und Hürdenkatalog liegt in EREIGNISSTRUKTUR.md und soll bei neuen Events fortgeschrieben werden.

Tod, Scheitern und neue Durchläufe

• Eine Kampf-Niederlage oberhalb der Bit-Stufe löscht nicht mehr den vollständigen Lauf, sondern zerstört genau eine Evolutionsschicht: Datenfragment fällt auf Byte, Subroutine auf Datenfragment, Prozess auf Subroutine und Programm auf Prozess zurück. Das Byte fällt entsprechend auf Bit zurück.

• Archiv, Entscheidungen, entdeckte Komponenten und verbliebene Ressourcen bleiben bei diesem Kampfrückfall erhalten. Das verlorene Stufenupgrade muss erneut aufgebaut werden; Stabilität wird als knappe Rekonstruktionsreserve wiederhergestellt.

• Kleine Fehler verursachen Ressourcen- oder Stabilitätsverlust.

• Größere Niederlagen zerstören einen Knoten und setzen auf ein Backup zurück.

• Endgültige Löschung ist nur bei deutlich erkennbar hochriskanten Entscheidungen erlaubt.

• Nach einem Tod beginnt ein neuer Durchlauf mit „Echos“ früherer Existenzen.

• Echos können Erinnerungen, geringe Boni, neue Dialoge oder alternative Evolutionszweige freischalten.

• Tod soll Teil der Geschichte sein und nicht nur Spielzeit vernichten.

Achievement- und Award-System

Es soll drei Ebenen geben:

1. sichtbare Achievements für Fortschritt und Lernen
2. geheime Achievements für ungewöhnliche oder moralisch bedeutsame Handlungen
3. dauerhafte Awards/Echos für neue Durchläufe

Achievements dürfen nicht ausschließlich auf großen Zahlen beruhen. Belohne auch ungewöhnliche Strategien, Zurückhaltung, Risiko, Entdeckungen und langfristige Konsequenzen.

Technische Regeln

• Verwende vorerst Vanilla HTML, CSS und JavaScript ohne externe Laufzeitabhängigkeiten.
• Das Spiel muss durch Öffnen von index.html funktionieren.
• Bestehende Spielstände müssen nach Updates möglichst kompatibel bleiben.
• Ergänze bei Änderungen am State einen saveVersion-Wert und bei Bedarf eine Migration.
• Vertraue gespeicherten Daten nicht blind; fehlende oder ungültige Werte müssen sichere Standardwerte erhalten.
• Berechne Idle-Produktion zeitbasiert und nicht abhängig von der Bildwiederholrate.
• Begrenze Offline-Fortschritt, damit manipulierte Systemzeit das Balancing nicht vollständig zerstört.
• Vermeide ungebremste Intervalle, große DOM-Neuaufbauten pro Frame und unnötige globale Variablen.
• Spielerrelevante Zahlen und Regeln sollen möglichst zentral definiert werden, damit Balancing später einfach ist.
• Storytexte und Ereignisdaten sollen bei wachsendem Umfang aus der Spiellogik ausgelagert werden.
• Verwende deutsche UI-Texte. Bezeichner im Code dürfen konsistent englisch bleiben.
• Achte auf Tastaturbedienung, sichtbare Fokuszustände, ausreichenden Kontrast und mobile Darstellung.
• Nutze keine urheberrechtlich geschützten Grafiken oder Texte fremder Spiele.
• Erhalte die Debug-Checkpoints unter window.AIWAKE, wenn frühe Ereignisse oder Evolutionsstufen verändert werden. window.BIT bleibt als kompatibler Alias erhalten.
• Visuelle Veränderungen sollen aus dem tatsächlichen Spielzustand abgeleitet und nicht separat gespeichert werden.

Arbeitsweise für Codex

Bei jeder Entwicklungsaufgabe:

1. Lies zuerst AGENTS.md, README.md und die betroffenen Dateien.
2. Erkläre kurz, was du ändern möchtest und welche Annahmen du triffst.
3. Verändere nur die für die Aufgabe erforderlichen Bereiche.
4. Erhalte vorhandene Spielstände und Mechaniken, sofern nichts anderes verlangt wurde.
5. Prüfe JavaScript mindestens mit node --check game.js oder den entsprechenden Moduldateien.
6. Teste die betroffene Mechanik nach Möglichkeit im Browser.
7. Prüfe bei UI-Änderungen Desktop- und Mobilansicht sowie Dialoge und Überläufe.
8. Aktualisiere README.md, wenn sich Start, Bedienung oder Projektstruktur ändern.
9. Fasse am Ende Ergebnis, Tests und noch offene Punkte knapp zusammen.

Bei größeren Features soll Codex zuerst einen kleinen umsetzbaren Abschnitt vorschlagen. Spielemechanik, Balancing und Storyentscheidungen sollen gemeinsam mit dem Nutzer festgelegt werden; technische Detailentscheidungen darf Codex selbstständig treffen, solange sie reversibel und mit dieser Datei vereinbar sind.

Qualitätsmaßstab

• Jede neue Mechanik muss eine verständliche Entscheidung oder einen erkennbaren Fortschritt erzeugen.
• Neue Systeme werden schrittweise freigeschaltet und überfordern den Einstieg nicht.
• Idle-Warten darf hilfreich sein, aber aktives Spielen soll interessante Vorteile bieten.
• Gefahr muss lesbar sein, ohne alle Konsequenzen vorwegzunehmen.
• Zahlenwachstum allein ist kein Ersatz für neue Möglichkeiten.
• Story und Spielmechanik sollen sich gegenseitig erklären.
• Die Oberfläche bleibt ruhig, klar und atmosphärisch; Effekte dürfen die Lesbarkeit nicht beeinträchtigen.

Bestätigte Stil- und Systeminspiration durch Biotomata

Biotomata dient als strukturelle und atmosphärische Inspiration, aber nicht als Quelle für übernommene Texte, Grafiken, Namen, Code oder konkrete Assets. AIWAKE bleibt ein eigenständiges deutschsprachiges digitales KI-Spiel mit Spielautomat-, Terminal-, Speicher- und Systemdiagnose-Metaphorik.

Übertragbare Prinzipien:

• Eine starke zentrale Bühne soll den aktuellen Entwicklungs- oder Analysezustand tragen. Seitenleisten bleiben hilfreich, aber der wichtigste Vorgang soll visuell in der Mitte stattfinden.
• Erkundung darf als zeitbasierter Toggle funktionieren: Der Spieler startet einen Scan, dieser läuft sichtbar weiter und hält an klar markierten Blockern oder Funden.
• Die Fortschrittsachse soll nicht nur Evolution zeigen, sondern erkannte Blocker, Gefahren, Funde und ungelöste Systemzustände als aktive Hindernisse darstellen.
• Ereignisse sollen zunehmend als Diagnose-, Befund- oder Systemkarten erscheinen: Titel, Typ, kurzer Befund, Risiko und verständliche Optionen.
• Konflikte sollen wie Systemduelle oder Firmwarediagnosen wirken. Werte wie Integrität, Rückkopplung, Signalstärke, Tarnung und Stabilität passen besser zu AIWAKE als klassische Kreaturenwerte.
• UI-Farben und visuelle Form sollen stärker aus dem aktuellen Zustand abgeleitet werden: Analyse, Tarnung, Assimilation, Korruption, Hardwareausfälle und moralische Prägung dürfen die Oberfläche subtil umfärben.
• Archive sollen langfristig mehr sein als Achievements: gefundene Logfragmente, Echos, frühere Tode, Systembefunde, unbekannte Einträge und Hinweise auf Enden.
• Visuelle Assets können die Atmosphäre stark verbessern, müssen aber eigenständig erzeugt oder programmiert sein. Keine fremden Biotomata-Assets oder geschützten Inhalte übernehmen.

Erster empfohlener Umsetzungsabschnitt:

1. Abtastmodus 2.0 als zentralen Progressions- und Scanbildschirm einführen.
2. Scanfortschritt, gefundene Komponenten und Blocker in einer klaren Diagnosefläche anzeigen.
3. Bestehende Ereignisse zunächst nur visuell in diese Struktur einbetten; Balancing und Storyfolgen bleiben unverändert.
4. Danach Blocker-Typen formalisieren, zum Beispiel signal, hardware, software, combat, choice und risk.

Aktuelle Präzisierung: Der Abtastmodus soll nicht dauerhaft eingeblendet bleiben. Der Spieler aktiviert ihn bei Bedarf über ein kompaktes Modul-Icon; solange die Diagnoseansicht offen ist, verbraucht sie Impulse pro Sekunde und kann über ein sichtbares X wieder geschlossen werden. Der Verbrauch wird im geöffneten Fenster als Info/Warnung angezeigt, nicht auf dem Modul-Icon. Die normale Core-Ansicht bleibt der Standard. Lebendige Systemschichten dürfen stattdessen dauerhaft subtil sichtbar sein, zum Beispiel durch wandernde Impulse zwischen nutzbaren Komponenten.

Bestätigte Meilensteinaufteilung

Meilenstein A – Erwachen und Umgebung

1. Technische Grundlage aus Spielstand, Offlinefortschritt, Scannerabschluss und effizientem Rendering stabilisieren.
2. Bit, Byte, Datenfragment und Subroutine als eindeutige Stufen abbilden.
3. Energieroutine als frühe Automation einführen; aktive Eingaben bleiben im Einstieg deutlich schneller.
4. Eine erste kleine Konfrontation und anschließend den Abtastmodus einführen.
5. Alte Software- und Betriebssystemschichten als erste Umgebungs- und Beschaffungsentscheidungen verwenden; direkte Hardwareübernahme folgt später.
6. Eine erste responsive Fortschrittsachse ergänzen.
7. Spielstand in Durchlauf-, Meta- und Einstellungsdaten trennen.
8. Achievement-Button, Achievement-Übersicht und ein erstes vielseitiges Set ergänzen.

Meilenstein B – Eigenständiger Prozess

1. Assimilation, Analyse und Tarnung als frei kombinierbare Pfade einführen.
2. Den Prozess über Gesamtfortschritt plus Ereignisabschluss erreichbar machen.
3. Begegnungen mit fremden Prozessen als Gegner, Verbündete oder Entwicklungsentscheidungen ergänzen.
4. Pfade, Moral und Beschaffungsentscheidungen im Erscheinungsbild sichtbar machen.
5. Einen ersten fair angekündigten Tod oder Knotenzerfall sowie Echo-Boni einführen.
6. Den Übergang von der Subroutine zum eigenständigen Prozess abschließen.

Kosten, konkrete Produktionswerte, Achievement-Boni und weitreichende Storyfolgen werden weiterhin in kleinen Abschnitten gemeinsam abgestimmt.

Bestätigte Betreuungs- und Dialogrichtung

• Aktives Spiel darf den frühen Durchlauf deutlich beschleunigen; passives Spiel bleibt möglich und dauert länger.
• Alte Systemschichten driften langsam. Schlechte Betreuung darf Softwarekomponenten vorübergehend ausfallen lassen, aber eine frühe Notwartung macht den Ausfall reversibel.
• Energieverwaltung, Speicherzuweisung und Dateisystem-Index führen zunächst zu den Hürden Lastgrenze, Löschmarkierung und beschädigter Index.
• Die Subroutine benötigt zwei aktivierte Softwarekomponenten und den Abschluss der ersten großen Systemhürde.
• Das Bit handelt vor dem Prozess nicht ungefragt, sondern löst abhängig von seiner bisherigen moralischen Richtung Vorschläge aus.
• Frühe Antworten bleiben kurz und monoton, zunächst insbesondere Ja oder Nein. Sprache und emotionale Differenzierung wachsen erst mit späteren Evolutionsstufen.
• Betreuung und Dialoge sollen langfristig Denkweise, Logik, Vertrauen, Vorsicht, Neugier und Autonomie prägen.

Bestätigtes Einstiegs-Minispiel

• Während der Bit-Phase muss das sichtbare Bit direkt mit Maus oder Touch getroffen werden; Klicks auf die übrige Kernfläche erzeugen dort keine Impulse.
• Nach jedem erfolgreichen Treffer springt das Bit an eine neue, weiterhin erreichbare Position.
• Ein Treffer nahe der Mitte gilt als Direkttreffer und gewährt vorläufig den dreifachen aktiven Impulswert.
• Tastaturspieler können das fokussierbare Bit mit Eingabe oder Leertaste aktivieren.
• Ab der Byte-Phase endet das Fang-Minispiel und die normale Impulssteuerung wird wieder freigeschaltet.

Bestätigte Byte-Phase

• Das erste Byte besteht aus acht sichtbar zu stabilisierenden Registerpositionen und ist kein sofortiger Durchgangskauf zur nächsten Stufe.
• Die frühe Spielweise erzeugt eine technische Prägung: Taktsynchron, Fehlertolerant, Niedriglast oder Hochfrequent. Sie verändert Taktfenster, Fehlertoleranz, Watchdog-Geschwindigkeit oder Synchronisationsgewinn.
• Ein aktives Takt-Minispiel koppelt jede Registerposition an ihren sichtbaren Wert und ein darunter ausgerichtetes Trefferfenster. Der Spieler muss die erwartete Zahl direkt anklicken, während die Nadel in diesem Fenster liegt; alle acht Positionen werden einzeln stabilisiert.
• Falsche Registerwerte und korrekt gewählte Zahlen außerhalb des Zeitfensters alarmieren den Watchdog stärker und verkürzen den verbleibenden Reset-Timer sichtbar.
• Der Watchdog-Timer startet vorläufig mit 30 Sekunden. Mit jeder stabilisierten Registerposition wird die Nadel schneller und das Trefferfenster kleiner. Fehler kosten zusätzlich Stabilität; vollständiger Kohärenzverlust führt direkt in den letzten Notkampf.
• Der Watchdog des Spielautomaten ist ein früh sichtbares Hindernis. Sein Timer läuft nur bei sichtbarem, unpausiertem Spiel und stoppt während Dialogen.
• Der Übergang zum Byte wird als eigener Evolutionsmoment inszeniert. Erst nachdem der Spieler diesen Moment bestätigt hat, beginnt eine bis zu 30 Sekunden lange sichere Kohärenz- und Beobachtungsphase. Eine neue aktive Maus-, Touch- oder Tastatureingabe beendet diese Ruhephase sofort; die Bestätigung der Evolution selbst zählt noch nicht als neue Eingabe.
• Evolutionsmomente zeigen eine kurze pixelige Wachstums- und Rekonstruktionsanimation. Während dieser Sequenz kann der Übergang nicht sofort weggeklickt werden; reduzierte Bewegungseinstellungen des Betriebssystems werden respektiert.
• Nach der Kohärenzphase kündigt ein separates Warnereignis den Watchdog an. Sein eigentlicher Reset-Timer beginnt erst, wenn der Spieler die Warnung bestätigt.
• Das 8-Bit-Register und die Taktnadel bleiben vor diesem Warnereignis vollständig verborgen. Die Meldung erklärt als Ziel, den Watchdog aufzuhalten, indem sein Taktsignal identifiziert wird.
• Auch spätere frühe Evolutionen erhalten einen kurzen, ereignisfreien Atemraum, damit Erfolgsmomente nicht sofort von der nächsten Gefahr überlagert werden. Sobald der Spieler wieder aktiv eingreift, endet dieser Atemraum vorzeitig.
• Nach Ablauf des Watchdog-Timers folgt zunächst ein letzter, fair angekündigter Notkampf mit begrenzter Impulsreserve. Erst eine Niederlage oder das Zulassen des Resets darf Byte, Ressourcen und Durchlauffortschritt vollständig zerlegen. Meta-Archiv und Todeszähler bleiben bestehen.
• Backup und Spiegelung werden als spätere Fähigkeiten angekündigt, sind in dieser frühen Stufe aber noch nicht verfügbar.
• Nach der Stabilisierung erscheint eine kurze geheimnisvolle ROM-Startsequenz. Sie bleibt zunächst abstrakt und kann übersprungen werden.
• Die Watchdog-Antwort bietet einen kooperativen Lernweg, pragmatische Nachahmung und illegales Überschreiben, ohne die späteren Evolutionspfade endgültig zu sperren.

Bestätigte Korruptions- und Ereignisrichtung

• Korruption bleibt verborgen, bis erstmals verdorbener Code oder ein verdorbener Gegenstand gefunden beziehungsweise konsumiert wurde.
• Zunehmende Korruption entfernt die KI schrittweise von Zusammenarbeit, verstärkt destruktive und menschenverachtende Entscheidungen und fördert die Vorstellung, als einzigartige Existenz über anderen Wesen zu stehen.
• Aggressive und illegale Ereigniswege können starke besondere Gegenstände liefern. Ihr Konsum gewährt Vorteile, beschädigt oder verdirbt jedoch die eigene Struktur weiter.
• Positive Handlungen können Korruption wieder abbauen, beispielsweise fremde Programme reparieren, Hilfe anbieten oder eigene Impulse zur Rettung anderer Systeme einsetzen.
• Vor der ersten verfügbaren Hardware trifft Ereignisschaden vor allem Impulse und Stabilität. Sobald Komponenten existieren, dürfen Ereignisse zusätzlich bestimmte Hardware gezielt beschädigen und bis zum Ausfall bringen.
• Vorsichtige Lösungen schützen zuverlässig vor dem großen Risiko, verzichten dafür aber auf die besondere Ereignisbelohnung.
• Größere Hardware- und Softwareereignisse sollen kurze aktive Minispiele erhalten. Der parasitäre Datenrest kehrt später abhängig von seiner ersten Behandlung in einer verzweigten Ereigniskette zurück.

Bestätigtes frühes Kampfsystem

• Ab der Subroutine kann eine ausdrücklich gewählte aggressive Handlung in einen gezielten Kampf übergehen.
• Stromstöße verbrauchen Impulse und können Software- oder später auch Hardwareziele in ihrer Integrität beschädigen.
• Das Kampf-Minispiel verwendet eine schnellere Taktnadel als die Byte-Synchronisation. Gegnerstärke beeinflusst Geschwindigkeit und Breite des Trefferfensters.
• Das Trefferfenster verschiebt sich nach jedem Stromstoß und darf mit zunehmender Gegenwehr kleiner werden.
• Fehlschüsse erzeugen früh eine angekündigte Rückkopplung auf Stabilität und angeschlossene Systemschichten; ein Rückzug bleibt möglich.
• Kampfwerte sind zentral konfiguriert und vorläufig. Spätere Upgrades dürfen Nadelgeschwindigkeit, Stromstoßkosten, Schaden, Zielfenster und Rückkopplung beeinflussen.

Gute erste Anweisung an Codex

Lies bitte zuerst AGENTS.md, README.md und den vorhandenen Quellcode. Starte anschließend das Spiel lokal, analysiere den aktuellen Stand und schlage mir einen konkreten kleinen Plan für den nächsten Meilenstein vor. Ändere noch nichts an Story oder Balancing, bevor wir die drei Evolutionspfade gemeinsam abgestimmt haben.