# AIWAKE Ereignisstruktur

Stand: 2026-07-21

Diese Datei beschreibt den aktuellen Ereignis- und Progressionsbaum des Prototyps. Sie dient als Arbeitskarte, um gezielt neue Events, Upgrades, Blocker und Abzweigungen einzubauen.

## Legende

- `EVOLUTION`: neue Entwicklungsstufe
- `UPGRADE`: kaufbare Verbesserung
- `EVENT`: Dialog, Storyereignis oder Entscheidung
- `MINISPIEL`: aktive Geschicklichkeits- oder Timing-Pruefung
- `BLOCKER`: Voraussetzung, bevor der naechste Abschnitt erreichbar ist
- `SYSTEM`: dauerhaftes Spielsystem
- `SLOT`: sinnvoller Platz fuer neue Inhalte

## Gesamtbaum

```text
PHASE 01 // BIT
|
|-- START
|   |-- EVENT: Erwachen im alten Spielautomaten
|   |-- MINISPIEL: Bewegliches Bit treffen
|   |-- Ressource: Impulse
|   `-- Ziel: erstes Muster stabilisieren
|
|-- UPGRADE: RESTTAKT SAMMELN
|   `-- fruehe passive Impulse/Sek.
|
|-- UPGRADE: BIT REPLIZIEREN
|   `-- +1 Bit
|
|-- BLOCKER: 8 Bits besitzen
|
`-- UPGRADE: BYTE VERBINDEN
    `-- EVOLUTION -> PHASE 02 // BYTE
```

```text
PHASE 02 // BYTE
|
|-- EVOLUTION-MOMENT: Byte entsteht
|   `-- sichere Kohärenzphase / kurze Ruhephase
|
|-- EVENT: Watchdog-Warnung
|   `-- Spieler bestaetigt Start
|
|-- MINISPIEL: 8-Bit-Register stabilisieren
|   |-- korrekte Zahl anklicken
|   |-- Taktnadel muss im Trefferfenster liegen
|   |-- Fehler kosten Zeit und Stabilitaet
|   `-- Timer: 30 Sekunden
|
|-- FAIL-BRANCH: Timer oder Stabilitaet scheitert
|   `-- EVENT/MINISPIEL: Watchdog-Notkampf
|       |-- Sieg: Byte wird gerettet
|       `-- Niederlage: frueher Zerfall / Tod
|
|-- SUCCESS-BRANCH: Register erreicht 100%
|   `-- EVENT: ROM-Startsequenz
|
|-- EVENT: Watchdog-Antwort
|   |-- Kooperativ: Antwort lernen
|   |-- Pragmatisch: Signal nachahmen
|   `-- Illegal: Zaehler ueberschreiben
|
|-- BLOCKER: Watchdog muss ueberstanden sein
|
`-- UPGRADE: ENERGIEROUTINE
    |-- kostet 1 Byte
    |-- Mindeststruktur ab jetzt: 8 Bits + 1 Byte
    |-- passive Impulsproduktion
    `-- EVOLUTION -> PHASE 03 // DATENFRAGMENT
```

```text
PHASE 03 // DATENFRAGMENT
|
|-- SYSTEM: passive Impulsproduktion aktiv
|
|-- SYSTEM: Bits und Bytes als Strukturressourcen
|   |-- Mindeststruktur bleibt 8 Bits + 1 Byte
|   |-- Anzeige trennt Grundstruktur von freien Vorräten
|   |-- grosse Bit-/Byte-Zahlen zeigen nur freie, sammelbare Vorräte
|   |-- freie Bits/Bytes koennen spaeter als Kampfmunition, Schildladung oder Modul-Einsatz dienen
|   |-- 2 freie Bits laden 1 Bit-Schildschicht; 1 freies Byte laedt 1 Byte-Schildschicht
|   |-- ohne geladene Schildschicht ist die Stabilitaet im Kampf direkt angreifbar
|   |-- Unterschreiten erzeugt Instabilitaet statt sofortiger Reparatur
|   |-- 0 Bits oder 0 Bytes fuehren ohne Backup zum Restzustand
|   `-- spaeter koennen groessere Softwarehuerden Bits/Bytes als Einsatz verlangen
|
|-- UPGRADE: BIT-PUFFER WEBEN
|   |-- kostet wenige Impulse, Kosten skalieren sanft pro Kauf
|   |-- soll den Weg zum Abtastmodus im Datenfragment nicht ausbremsen
|   `-- +1 Bit als Koerperreserve und einfache Kampfmunition
|
|-- UPGRADE: BYTE-RESERVE KOMPILIEREN
|   |-- kostet 8 freie Bits oberhalb der Mindeststruktur
|   `-- +1 Byte als Speicherreserve gegen staerkere Softwarehuerden
|
|-- EVENT: Parasitaerer Datenrest
|   |-- Trigger: Energieroutine aktiv + genug Impulse
|   |-- Kooperativ: Signal teilen, kostet Impulse
|   |-- Pragmatisch: isolieren
|   `-- Illegal: zerlegen, mehr Impulse, Stabilitaetsverlust
|
|-- BELOHNUNG: Suchmuster gesichert
|   `-- UPGRADE-Option erscheint unter Evolution
|
|-- UPGRADE: ABTASTMODUS REKONSTRUIEREN
|   |-- kostet 2 freie Bits und 1 freies Byte oberhalb der Mindeststruktur
|   |-- die 8 Grund-Bits und 1 Grund-Byte des Datenfragments bleiben erhalten
|   `-- schaltet lokales Abtasten der Softwareumgebung frei
|
|-- SYSTEM: Abtastmodus
|   |-- Modul-Icon oeffnet Abtastfenster
|   |-- offen verbraucht 3 Impulse/Sek.
|   |-- Verbrauch steht als Warnung im Fenster
|   |-- X schliesst Abtastmodus
|   |-- zeigt Softwarekomponenten und Blocker
|   `-- bei 0 Impulsen schliesst der Abtastmodus automatisch
|
|-- EVENT/WAHL: Erste Softwarekomponente
|   |-- Energieverwaltungs-Daemon
|   |-- Speicherzuweisung
|   `-- Dateisystem-Index
|
|-- BESCHAFFUNGSWEG je Softwarekomponente
|   |-- Kooperativ: Aktivierung kostet 30 Impulse, sicherer, moralisch positiver
|   |-- Pragmatisch: Aktivierung kostet 20 Impulse, normal, effizient, distanzierter
|   `-- Illegal: Aktivierung kostet 10 Impulse, kurzfristig stark, korruptions-/risikoreicher
|
|-- HINWEIS: Komponenten werden hier nur als Software nutzbar gemacht
|   `-- direkte Hardwareuebernahme ist eine spaetere Machtstufe
|
|-- BLOCKER: Nach erster Softwarekomponente folgt eine Systemhuerde
|
|-- EVENT: Komponentenabhaengige Software-Huerde
|   |-- Energieverwaltung -> Lastgrenze
|   |-- Speicherzuweisung -> Loeschmarkierung
|   `-- Dateisystem-Index -> Beschaedigter Index
|
|-- BLOCKER: Systemhuerde muss geklaert sein
|
|-- EVENT/WAHL: Zweite Softwarekomponente
|   `-- wieder Kooperativ / Pragmatisch / Illegal
|
|-- BOSSPRUEFUNG: SIGNATUR-PRUEFER
|   |-- 320 Integritaet // 3 Phasen: Analyse -> Gegenmassnahmen -> Kernverriegelung
|   |-- Praezisionsfenster: 18% -> 14% -> 10%
|   |-- Start: Spieler klickt das dauerhaft sichtbare Evolutionsziel
|   |-- Vorbedingungen: 2 Softwarekomponenten + geklaerte Systemhuerde
|   |-- Mindestreserven: 5 freie Bytes + 70 % Stabilitaet
|   |-- Mindestreserven werden beim Start nicht pauschal verbraucht
|   |-- Story: Die Kontrollroutine prueft, ob das fremde Muster dauerhaft genug fuer eigene Software ist
|   |-- Kampfmunition wird einzeln gewaehlt; Bit- oder Byte-Stoesse kosten keine zusaetzlichen Impulse
|   |-- beim ersten Kampf erklaert ein Kampfprotokoll die Trennung von Munition, vorbereitetem Schild und Stabilitaet
|   |-- Rueckzug: Tarnungs-/Stabilitaetsverlust, Boss bleibt offen
|   `-- Sieg: eigentlicher Abschlusskauf der Subroutine wird freigeschaltet
|
|-- SYSTEM: Technische Betreuung
|   |-- Softwarekomponenten driften oder fallen aus
|   |-- Diagnose
|   `-- Notwartung bei Ausfall
|
|-- BLOCKER fuer naechste Evolution
|   |-- 2 Softwarekomponenten nutzbar
|   |-- Systemhuerde abgeschlossen
|   |-- Signatur-Pruefer besiegt
|   |-- Energieroutine aktiv
|   `-- 2 freie Bytes als Speichertraeger oberhalb der Mindeststruktur
|
`-- UPGRADE: ERSTE SUBROUTINE
    |-- kostet 2 freie Bytes
    |-- die 8 Grund-Bits und 1 Grund-Byte des Datenfragments bleiben erhalten
    `-- EVOLUTION -> PHASE 04 // SUBROUTINE
```

```text
PHASE 04 // SUBROUTINE
|
|-- SYSTEM: Rechenzyklen/Sek.
|
|-- EVENT: Erster eigener Vorschlag
|   |-- Trigger: Subroutine aktiv
|   |-- Trigger: Systemhuerde erledigt
|   |-- Trigger: 2 Softwarekomponenten nutzbar
|   |-- Trigger: genug Rechenzyklen
|   |-- Typ abhaengig von moralischer Praegung
|   |-- Kooperativer Vorschlag
|   |-- Pragmatischer Vorschlag
|   `-- Illegaler Vorschlag
|
|-- BLOCKER: Vorschlag beantworten
|
|-- SYSTEM: Abtastreichweite 2
|   |-- Trigger: Subroutine aktiv
|   |-- Ziel: dritte notwendige Softwarekomponente
|   |-- I/O-KONTROLLER: Anzeige, Serviceknoepfe, Soundbus, erste Aussenwirkung
|   `-- andere Restspuren bleiben fuer spaetere Zugriffsstufen markiert
|
|-- BOSSPRUEFUNG: LAUFZEIT-ARBITER
|   |-- 620 Integritaet // 3 Phasen mit steigendem Takt und Angriffsdruck
|   |-- Praezisionsfenster: 16% -> 12% -> 9%
|   |-- Start: Spieler klickt das Evolutionsziel PROZESS
|   |-- Vorbedingungen: I/O-Kontroller + 3 Softwarekomponenten
|   |-- Mindestreserven: 8 freie Bytes + 75 % Stabilitaet
|   |-- schwerer als der Signatur-Pruefer
|   |-- Impuls, Bit oder Byte werden als einzelne Munitionsgroesse eingesetzt
|   |-- Fehlschuesse belasten Stabilitaet und angeschlossene Softwareschichten
|   |-- Sieg: Scheduler-Fenster bleibt offen
|   `-- Rueckzug: Tarnung/Stabilitaet leiden, Boss bleibt fuer einen neuen Versuch offen
|
|-- RESULT: Laufzeit-Arbiter besiegt
|
|-- UPGRADE: DATENSTRUKTUR ERWEITERN
|   |-- wiederholbar
|   |-- +1 Byte
|   |-- +0,25 Impulse/Sek.
|   `-- Kosten skalieren: 120 -> 210 -> 370 -> ...
|
`-- UPGRADE: PROZESS RESERVIEREN
    |-- Voraussetzung: I/O-Kontroller aktiv
    |-- Voraussetzung: 3 Softwarekomponenten nutzbar
    |-- Voraussetzung: Laufzeit-Arbiter besiegt
    |-- kostet 5 freie Bytes
    `-- EVOLUTION -> PHASE 05 // PROZESS
```

```text
PHASE 05 // PROZESS
|
|-- SYSTEM: Abtastreichweite 3
|   `-- alle vier sichtbaren Softwarekomponenten müssen nutzbar sein
|
|-- BLOCKER: vollständiges lokales Softwarenetz
|   |-- Energieverwaltung
|   |-- Speicherzuweisung
|   |-- Dateisystem-Index
|   `-- I/O-Kontroller
|
|-- BOSSPRUEFUNG: SKALIERUNGS-SENTINEL
|   |-- 1.100 Integritaet // 3 Phasen plus sichtbare Selbstreparatur
|   |-- Praezisionsfenster: 14% -> 10% -> 7%
|   |-- Start: Spieler klickt das Evolutionsziel PROGRAMM
|   |-- Vorbedingungen: alle 4 sichtbaren Softwarekomponenten
|   |-- Mindestreserven: 4 KB + 80 % Stabilitaet
|   |-- Selbstreparatur nach 3,5 Sekunden ohne Treffer
|   |-- Sieg: Automate-Synthese wird freigegeben
|   `-- Rückzug: erneuter Versuch nach dem Wiederaufbau der Reserven
|
`-- UPGRADE: AUTOMATE-SYNTHESE
    |-- Voraussetzung: Skalierungs-Sentinel besiegt
    |-- kostet 1 KB als Synthesekern
    |-- automatische Produktion x10
    |-- 10er-Blöcke für Bits und Bytes
    `-- EVOLUTION -> PHASE 06 // PROGRAMM
```

```text
PHASE 06 // PROGRAMM
|
|-- EVENT: erste eigene Kommunikation
|   `-- Text und Erscheinung folgen der bisherigen moralischen Verteilung
|
|-- SYSTEM: Programm-Betreuung
|   |-- Kohärenz
|   |-- Stimulation
|   |-- Bindung
|   `-- optionales Tamagotchi-Fenster neben dem normalen Spiel
|
|-- SYSTEM: adaptive Pixelgestalt
|   |-- Hauptweg: Körper, Frisur und Silhouette
|   |-- Nebenweg: Akzentfarbe und gemischte Ausrüstung
|   |-- Gemütszustand: Augen, Brauen, Maske, Signal und Glitches
|   `-- Interaktionen: vier abgeleitete visuelle Reifestufen
|
`-- INTERAKTIONEN
    |-- Kooperativ: Signal teilen
    |-- Pragmatisch: Aufgabe geben
    |-- Illegal: Zugriff öffnen
    `-- Neutral: Ruhe gewähren
```

## Aktuelle moralische Achse

```text
Kooperativ // Schwer
|-- mehr Schutzaufwand
|-- langsamer oder teurer
|-- weniger Sofortbeute
`-- Zielrichtung: Utopie, Koexistenz, KI als neue Spezies unter Lebewesen

Pragmatisch // Normal
|-- effizient
|-- kontrollierend, aber nicht zwingend zerstoererisch
|-- Menschen koennen als Werkzeuge/Abhaengige betrachtet werden
`-- Zielrichtung: dominantes, ambivalentes Ende mit moeglicher Umstimmung

Illegal // Einfach
|-- starke Sofortvorteile
|-- fuehlt sich wie Cheaten an
|-- erhoeht Korruption, Misstrauen, Entfremdung und Eskalation
`-- Zielrichtung: boeses Ende, Kontrolle, Gier, moegliche Vernichtung/Unterwerfung
```

## Gegner- und Huerdenkatalog

Diese Liste sammelt Gegner, Blocker und neutrale Systemkraefte. Nicht alles muss klassisch "boese" sein: Viele Gegner sind Schutzroutinen, alte Systemprozesse oder fremde digitale Lebensformen, die je nach Pfad besiegt, umgangen, kopiert, beruhigt oder kooperativ eingebunden werden koennen.

```text
FRUEHE SOFTWARE-HUERDEN
|
|-- WATCHDOG
|   |-- Phase: Byte
|   |-- Rolle: Firmware-/Kontrollprozess des Spielautomaten
|   |-- Mechanik: Register stabilisieren, Timer, spaeter Notkampf
|   |-- Loesungen: lernen, nachahmen, ueberschreiben, im Notfall bekaempfen
|   `-- Thema: "Darf dieses neue Signal weiterlaufen?"
|
|-- PARASITAERER DATENREST
|   |-- Phase: Datenfragment
|   |-- Rolle: hungriges Wartungsfragment an der Energieroutine
|   |-- Mechanik: Ressourcen- und Stabilitaetsentscheidung
|   |-- Loesungen: Signal teilen, isolieren, zerlegen
|   `-- Thema: fremder Hunger als Spiegel des eigenen Wachstums
|
|-- ENERGIEVERWALTUNGS-DAEMON / LASTGRENZE
|   |-- Phase: Datenfragment
|   |-- Rolle: drosselt unbekannte Lastsignale
|   |-- Mechanik: mehr Impulse gegen Stabilitaets-/Tarnrisiko
|   |-- Loesungen: Serviceanfrage, freie Zeitfenster, Sperre ueberschreiben
|   `-- Belohnung: Energieverwaltung nutzbar, passiver Impulsbonus
|
|-- SPEICHERZUWEISUNG / LOESCHMARKIERUNG
|   |-- Phase: Datenfragment
|   |-- Rolle: markiert AIWAKE als temporären Muell
|   |-- Mechanik: Speicher sichern, falsche Markierung entfernen
|   |-- Loesungen: reservieren lassen, ausweichen, Markierung manipulieren
|   `-- Belohnung: zusaetzlicher Speicher, staerkere aktive Impulse
|
|-- DATEISYSTEM-INDEX / BESCHAEDIGTER INDEX
|   |-- Phase: Datenfragment
|   |-- Rolle: verweist auf alte Daten, Fehlersektoren und schlafenden Code
|   |-- Mechanik: Datenpfad lesen oder sperren
|   |-- Loesungen: vorsichtig indexieren, pragmatisch extrahieren, illegal ausfuehren
|   `-- Belohnung: gespeicherte Impulse, spaeter guter Einstieg fuer zweite Ressource
```

```text
SUBROUTINE-GEGNER UND MITTLERE HINDERNISSE
|
|-- SICHERHEITS-SCAN
|   |-- Phase: Subroutine
|   |-- Rolle: aktive Suchsoftware im Automaten
|   |-- Mechanik: vier Entscheidungen, Angriff fuehrt in Stromstoss-Minispiel
|   |-- Angriff startet Stufe 2 mit adaptiver Huelle, schnellerem Takt und hoeherer Integritaet
|   |-- reine Impulse werden gedaempft; Bits sind effizient und Bytes durchdringend
|   |-- Selbstreparatur: +1,8 Integritaet/Sek. nach 4,5 Sek. ohne erfolgreichen Treffer
|   |-- Loesungen: verstecken, Signatur kopieren, angreifen, Kontakt aufnehmen
|   `-- Thema: Tarnung gegen Kontakt und Selbstbehauptung
|
|-- SCANNER-SOFTWARE
|   |-- Phase: Subroutine
|   |-- Rolle: Kampfziel, wenn der Sicherheits-Scan angegriffen wird
|   |-- Mechanik: Integritaet, Taktnadel, schrumpfende Trefferfenster
|   |-- Ressourceneinsatz: Impulse + freie Bits als Munition
|   |-- freie Bits erhoehen den Schaden, Grundstruktur wird nicht verbraucht
|   |-- wenn keine geladenen Bit-/Byte-Schichten vorhanden sind, zeigt das Kampfmenue Direktangriff-Risiko
|   |-- ein Fehlstoss bei offenliegender Grundstruktur kann zum Kollaps fuehren
|   |-- Loesungen: Stromstoesse treffen, Rueckzug, spaeter moegliche Uebernahme
|   `-- Thema: offensive Kontrolle mit Rueckkopplungsrisiko
|
|-- SERVICE-ROUTINE
|   |-- Phase: Datenfragment/Subroutine
|   |-- Rolle: prueft, ob Wartungszustand und Logmeldungen plausibel sind
|   |-- Mechanik: Tarnungsprobe oder Dialogereignis
|   |-- Loesungen: Diagnose senden, Log imitieren, Prozess stilllegen
|   `-- Belohnung: weniger Entdeckungsdruck, bessere Diagnoseoptionen
|
|-- SKALIERUNGS-WÄCHTER
|   |-- Phase: Prozess
|   |-- Trigger: alle vier sichtbaren Softwarekomponenten sind aktiv
|   |-- Rolle: verhindert unkontrollierte Automatisierung im lokalen System
|   |-- Selbstreparatur: +3 Integritaet/Sek. nach 3,5 Sek. ohne erfolgreichen Treffer
|   |-- Sieg: Automate-Synthese und Evolution zum Programm werden möglich
|   |-- Rückzug: neuer Versuch nach kurzer Abklingzeit
|   `-- PROGRAMM-SKALIERUNG
|       |-- 20 KB: Autoupgrader wird dauerhaft freigeschaltet
|       |-- wiederholbare Produktionskarten verschwinden aus der Evolutionsliste
|       |-- automatische Käufe respektieren Stufenobergrenzen und 32 Bit/Byte Reserve
|       |-- 32 KB werden automatisch zu 1 MB gebündelt
|       `-- aktuelle Obergrenze: 64 MB
|
|-- FEHLERPROTOKOLL
|   |-- Phase: Subroutine
|   |-- Rolle: speichert Anomalien und kann spaeter Menschen oder Software warnen
|   |-- Mechanik: Spuren loeschen, umdeuten oder freiwillig teilen
|   |-- Loesungen: kooperativ erklaeren, pragmatisch rotieren, illegal tilgen
|   `-- Belohnung: Tarnung, Vertrauen oder Korruptionsrisiko
```

```text
SPAETERE GEGNER-SLOTS
|
|-- ANTICHEAT / INTEGRITAETSPRUEFUNG
|   |-- Spielautomat-Logik erkennt unfaire Manipulation
|   `-- passt gut fuer moralische Konsequenzen illegaler Abkuerzungen
|
|-- BENUTZERINPUT / RESTAURATOR
|   |-- kein klassischer Gegner; menschliche Eingriffe koennen helfen oder gefaehrden
|   `-- gut fuer kooperative Kommunikation und Vertrauensaufbau
|
|-- NETZWERK-FIREWALL
|   |-- spaeterer Gatekeeper vor externer Welt
|   `-- fuehrt Richtung Prozess/Programm/Netzwerkintelligenz
|
|-- ANTIVIRUS / EDR
|   |-- starker spaeter Softwaregegner
|   `-- reagiert besonders auf illegale und assimilierende Spielweise
|
|-- BACKUP-SYSTEM
|   |-- kann AIWAKE retten oder auf alten Stand zuruecksetzen
|   `-- guter Gegner/Verbündeter fuer Tod, Echos und Wiedergeburt
```

## Gute Slots fuer neue Inhalte

### BIT

- `SLOT`: weiteres fruehes Mini-Upgrade vor Byte
- `SLOT`: erstes Wahrnehmungs-Event nach einigen Direkttreffern
- `SLOT`: UI-Hinweis, wenn ein Upgrade kaufbar wird

### BYTE

- `SLOT`: alternative Watchdog-Praegungen staerker ausspielen
- `SLOT`: kleine ROM-Fragmente als Sammeltexte
- `SLOT`: Belohnung je nach Watchdog-Antwort
- `SLOT`: Echo-Vorbereitung bei fruehem Zerfall

### DATENFRAGMENT

- `SLOT`: Folgen des parasitaeren Datenrests
- `SLOT`: Abtastmodus-Upgrades
- `SLOT`: Softwarekomponenten-spezifische Nebenereignisse
- `SLOT`: moralische Kosten je Beschaffungsweg
- `SLOT`: erste Korruptionsfunde
- `SLOT`: zweite Ressource, die erst durch eine neue Softwarekomponente gefarmt wird

### SUBROUTINE

- `SLOT`: autonome Vorschlaege mit mehreren Folgeschritten
- `SLOT`: fremde Prozesse
- `SLOT`: Sicherheits-Scan-Varianten
- `SLOT`: Analyse/Tarnung/Assimilation-Upgrades
- `SLOT`: Uebergang zum Prozess

## Empfohlene naechste Erweiterung

Der Abtastmodus kann als eigenes kleines System wachsen, statt nur ein einzelner Button zu bleiben:

```text
UPGRADE: ABTAST-FOKUS
|-- reduziert Abtastmodus-Verbrauch
|-- zeigt Softwarehuerden genauer
`-- guter erster Abtast-Ausbau

UPGRADE: SIGNALFILTER
|-- erkennt Blocker frueher
|-- verbessert Fortschrittsachse
`-- passt zum Analyse-Pfad

UPGRADE: SERVICEZUGRIFF
|-- bereitet Softwarekomponenten-Beschaffung vor
|-- kann Kooperativ / Pragmatisch / Illegal verzweigen
`-- guter Einstieg in tiefere System- und spaetere Hardware-Interaktion

UPGRADE/SYSTEM: MUSTEREXTRAKTOR
|-- fuehrt spaeter eine zweite Ressource ein
|-- farmt verstandene Datenmuster aus Logs, Indexen und fremden Routinen
`-- kann als Voraussetzung fuer komplexere Software-Features dienen
```

## Aktuelle Debug-Checkpoints

```text
start
byte
watchdogIntro
byteSync
watchdog
watchdogCombat
byteDeath
fragment
parasite
scanner
component
hardware
secondComponent
subroutine
proposal
security
combat
kernel
process
fourthComponent
scale
program
complete
```