diff --git a/README.md b/README.md
new file mode 100644
index 0000000..6f29757
--- /dev/null
+++ b/README.md
@@ -0,0 +1,138 @@
+# AppRobotDriver
+
+Dieses Projekt empfängt G-Code und Robotersteuerbefehle, berechnet Inverse Kinematik für einen mehrgliedrigen Roboterarm und leitet die resultierenden Achsenbefehle an mehrere GRBL/FluidNC-Telnet-Sender weiter.
+
+## Architektur
+
+- `startRobot.js` startet zwei HTTPS-Server:
+  - Eingabe-Server + WebSocket für G-Code und Steuerbefehle
+  - Info-Server für Status, Position und einfache Weboberfläche
+- `server/InputWS.js` empfängt Nachrichten von WebSocket-Clients, prüft sie auf G-Code oder Datei-Kommandos und gibt Positionsdaten zurück.
+- `robot/GCode.js` verarbeitet G-Code, übersetzt ihn in Roboter-Koordinaten und triggert `robot.sendCommand()`.
+- `robot/Robot.js` führt die Inverse Kinematik aus und berechnet Motorwinkel sowie optionale Motor-Geschwindigkeiten.
+- `robot/TelnetSenderGRBL.js` formatiert die Motor-Positionen in GRBL-kompatible Befehle und sendet sie per Telnet an einen Zielcontroller.
+
+## Eingaben
+
+Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/InputWS.js` verarbeitet.
+
+### Unterstützte Nachrichten
+
+- `Ping`
+  - Antwort: Wird zurück an alle verbundenen Clients gesendet.
+- `M114`
+  - Antwort: Positionsdaten des Roboters im JSON-Format.
+- G-Code-Befehle:
+  - `G90`, `G91`, `G1`, `G28`, `G92`
+  - Messungen in `X`, `Y`, `Z`, `A`, `B`, `C`, `E`, `F`
+  - `M1` für direkte Motor-Koordinaten
+- Datei-Kommandos:
+  - `FPoint`, `FPlus`, `FMinus`, `FFirst`, `FLast`, `FShow`, `FList`, `FLoad <file>`, `FSave <file>`, `FClear`
+  - `M20`, `M23`, `M28`, `M29`
+
+### G-Code-Verarbeitung
+
+- `GCode.receiveGCode(robot, message)`
+  - Gruppiert Zeilen, unterstützt Inline-Jogging (`$J=`)
+  - Schaltet zwischen absoluter und relativer Koordinatenverarbeitung
+  - Aktualisiert Position und Winkel im `robot`-Objekt
+  - Führt inverse Kinematik aus mit `robot.calculateAngles3D()`
+  - Sendet das Ergebnis an `robot.sendCommand()`
+
+## Ausgaben
+
+- WebSocket-Broadcasts an alle verbundenen Clients
+  - Nachdem ein G-Code-Befehl verarbeitet wurde, sendet das System `GCode.getM114(robot)` zurück.
+  - Für Datei-Kommandos gibt `GCode.receiveFC()` ebenfalls die aktuelle Position zurück.
+- Telnet-Ausgabe an GRBL/FluidNC-Geräte
+  - `TelnetSenderGRBL.execCommand()` erzeugt `G1`/`G90`-Befehle mit Achsenzuordnung und Feedrate.
+- Info-Server API
+  - `/api/status` — zeigt Client-Status, Sender-Status und letzte Befehle/Pings an
+  - `/api/position` — gibt die aktuelle Roboterposition und Motorwinkel als JSON zurück
+
+## Konfiguration
+
+### Starten
+
+- `npm start`
+- Alternativ: `node startRobot.js`
+
+### Umgebungsvariablen
+
+- `PORT`
+  - Standard: `2095`
+  - Port für den WebSocket/HTTPS-Eingabeserver
+- `GRBL_BASE_IP`
+  - Standard: `fluidNcBase.local`
+  - Zielhost für den ersten Telnet-Sender
+- `GRBL_ELLBOW_IP`
+  - Standard: `fluidNcEllbow.local`
+  - Zielhost für den Ellbogen-Sender
+- `GRBL_HAND_IP`
+  - Standard: `fluidNcHand.local`
+  - Zielhost für den Hand-Sender
+- `ROBOT_DEFAULT_FEEDRATE`
+  - Standard: `1000` (mm/min)
+  - Default-Feedrate für `G1`-Befehle, wenn keine `F`-Angabe vorhanden ist
+- `ROBOT_USE_SPEED_CALC`
+  - Werte: `true`, `1` oder sonst leer
+  - Wenn gesetzt, werden `robot.calculateSpeeds()` und interne Motor-Geschwindigkeiten verwendet
+
+### HTTPS-Konfiguration
+
+- `https/localhost.key`
+- `https/localhost.pem`
+- Passphrase aktuell hart codiert als `abcd`
+
+### Telnet-Sender-Konfiguration
+
+In `startRobot.js` werden drei `TelnetSenderGRBL` Instanzen erzeugt:
+
+- `telnetSender1` → Basisachse(n): `x`, `y`, `z`
+- `telnetSender2` → Ellbogenachse: `a`
+- `telnetSender3` → Handachsen: `c`, `e`, `b`
+
+Die Achszuordnung kann in `robot/TelnetSenderGRBL.js` durch Anpassung der Konstruktorparameter geändert werden.
+
+## Serverschnittstellen
+
+### WebSocket Input Server
+
+- Läuft auf `https://localhost:<PORT>`
+- Erwartet WebSocket-Verbindungen und verarbeitet Nachrichten als G-Code oder Steuerbefehle
+
+### Info Server
+
+- Läuft auf `https://localhost:2098`
+- Statische Dateien:
+  - `/`
+  - `/app.js`
+  - `/style.css`
+  - `/allApps.css`
+- API-Endpunkte:
+  - `/api/status`
+  - `/api/position`
+
+## Wichtige Dateien
+
+- `startRobot.js`
+- `server/InputWS.js`
+- `server/InfoServer.js`
+- `robot/Robot.js`
+- `robot/GCode.js`
+- `robot/TelnetSenderGRBL.js`
+- `GCodeFiles/` — enthalten Beispiel- und Log-G-Code-Dateien
+
+## ToDo / Open Tasks
+
+- Architektur- und Refactoring-Aufgaben sind zusätzlich in `doc/ToDo_*.md` dokumentiert.
+
+- [ ] Dokumentation der vollständigen G-Code-Syntax erweitern
+- [ ] Feedrate-Berechnung im Sender genauer definieren
+- [ ] `ROBOT_USE_SPEED_CALC` und `motorSpeeds` im Einsatz prüfen
+- [ ] Fehlerbehandlung bei Telnet-Verbindungen verbessern
+- [ ] Einheitliche Behandlung von absoluten und relativen `M1`-Motorbefehlen
+- [ ] `G92`-Verhalten überprüfen: Position setzen ohne Roboterbewegung
+- [ ] Zusätzliche Testfälle für `InputWS`, `GCode` und `TelnetSenderGRBL` schreiben
+- [ ] HTTPS-Konfiguration und Zertifikatsverwaltung verbessern
+- [ ] Mehrsprachige Kommentare/README-Übersetzung bei Bedarf
diff --git a/doc/ToDo_1_Parsing.md b/doc/ToDo_1_Parsing.md
new file mode 100644
index 0000000..2e525b4
--- /dev/null
+++ b/doc/ToDo_1_Parsing.md
@@ -0,0 +1,13 @@
+# ToDo 1 — Parsing
+
+## Ziel der Verbesserung
+
+Klare Trennung zwischen G-Code-Parsing und Robotersteuerlogik. Der Parser soll nur lesen und strukturieren, nicht direkt den Roboterzustand verändern.
+
+## Aufgaben
+
+- [ ] `GCodeParser` einführen, das G-Code und Nachrichten in strukturierte Befehlsobjekte übersetzt
+- [ ] Parsing-Regeln definieren für `G90`, `G91`, `G1`, `G28`, `G92`, `M1` und `$J=` sowie Parameter `X`, `Y`, `Z`, `A`, `B`, `C`, `E`, `F`
+- [ ] Raw-String-Verarbeitung aus `GCode.receiveGCode()` entfernen
+- [ ] Parser-Resultate als Objekte an den Controller übergeben, nicht als rohe Textbefehle
+- [ ] Parser-Fehlerfälle klar behandeln: ungültige Syntax, fehlende Werte, unbrauchbare Befehle
\ No newline at end of file
diff --git a/doc/ToDo_2_Anbindung.md b/doc/ToDo_2_Anbindung.md
new file mode 100644
index 0000000..d92215b
--- /dev/null
+++ b/doc/ToDo_2_Anbindung.md
@@ -0,0 +1,44 @@
+# ToDo 2 — Anbindung
+
+## Ziel der Verbesserung
+
+Die Anbindung soll zuverlässig werden: WebSocket-Eingaben, Steuerlogik und Sender müssen klar verbunden und sauber orchestriert sein.
+
+Dieses ToDo konzentriert sich auf die technische Integration der Komponenten, nicht auf G-Code-Parsing oder Konfiguration.
+## Paket 1: Start/Orchestrierung
+
+- [ ] `startRobot.js` als Orchestrator behandeln
+  - Erzeugung und Verbindung der Module
+  - keine Geschäftslogik im Start-Skript
+- [ ] Bindung der WebSocket-Eingabe an die Steuerlogik
+  - `InputWS.js` empfängt Nachrichten
+  - Delegation an den Parser / Controller
+- [ ] Sauberes Fehler- und Status-Reporting beim Start
+  - fehlende Zertifikate
+  - fehlende Senderverbindungen
+
+## Paket 2: Sender-Schicht (Option C)
+
+- [ ] Sender-Interface definieren
+  - `connect()`
+  - `send(command)`
+  - `getStatus()`
+  - `disconnect()`
+- [ ] `TelnetSenderGRBL` als konkrete Implementierung
+  - async `connect()`-Methode
+  - eindeutiger Verbindungsstatus, nicht nur `this.tSocket`
+  - reconnect/backoff-Strategie
+  - saubere Fehlerlogs
+- [ ] Sender-Schicht testbar und austauschbar machen
+  - später können andere Sender als `TelnetSenderGRBL` angehängt werden
+
+## Paket 3: Status- und Info-Anbindung
+
+- [ ] `InfoServer.js` meldet nicht nur Weboberfläche, sondern auch Senderstatus
+- [ ] `/api/status` erweitert um Senderverbindungen und Health-Informationen
+- [ ] `/api/position` liefert aktuelle Roboterposition unabhängig von laufenden Verbindungen
+
+## Hinweis
+
+- Parsing, Konfiguration, Datei-Management und Tests werden getrennt in eigenen `doc/ToDo_*.md`-Dateien behandelt.
+- Event-basierte Architektur ist aktuell nicht vorgesehen; die Umsetzung folgt Option A mit einer klaren Sender-Interface-Schicht.
\ No newline at end of file
diff --git a/doc/ToDo_3_Config.md b/doc/ToDo_3_Config.md
new file mode 100644
index 0000000..4ceb0ad
--- /dev/null
+++ b/doc/ToDo_3_Config.md
@@ -0,0 +1,18 @@
+# ToDo 3 — Konfiguration
+
+## Ziel der Verbesserung
+
+Zentralisierte Konfiguration statt verstreuter Hardcodierung. Konfiguration soll transparent, testbar und leicht anpassbar sein.
+
+## Aufgaben
+
+- [ ] `config.js` oder ein zentrales Config-Modul anlegen
+- [ ] Alle Umgebungsvariablen an einer Stelle lesen und validieren
+  - `PORT`
+  - `GRBL_BASE_IP`, `GRBL_ELLBOW_IP`, `GRBL_HAND_IP`
+  - `ROBOT_DEFAULT_FEEDRATE`
+  - `ROBOT_USE_SPEED_CALC`
+  - HTTPS-Zertifikatpfade und Passphrase
+- [ ] `startRobot.js`, `TelnetSenderGRBL`, `InfoServer.js` und weitere Module mit dem Config-Modul arbeiten lassen
+- [ ] Optional: `config/default.json` oder `.env` als Konfigurationsbasis bereitstellen
+- [ ] Fehlende oder ungültige Konfiguration frühzeitig mit klarer Fehlermeldung melden
\ No newline at end of file
diff --git a/doc/ToDo_4_GCode.md b/doc/ToDo_4_GCode.md
new file mode 100644
index 0000000..ac1b51a
--- /dev/null
+++ b/doc/ToDo_4_GCode.md
@@ -0,0 +1,15 @@
+# ToDo 4 — G-Code und Datei-Handling
+
+## Ziel der Verbesserung
+
+G-Code-Logik sauber von Datei-Management trennen. Die Bewegungssteuerung soll nicht durch Dateibefehle oder File-IO verwässert werden.
+
+## Aufgaben
+
+- [ ] `GCodeFileManager` einführen für Datei-bezogene Befehle und Logik
+  - `FPoint`, `FPlus`, `FMinus`, `FFirst`, `FLast`
+  - `FShow`, `FList`, `FLoad`, `FSave`, `FClear`
+- [ ] `GCode.js` auf reines G-Code-Parsing reduzieren
+- [ ] Datei-Befehle in `InputWS.js` separate behandeln und an den FileManager weiterleiten
+- [ ] Logfile-Operationen von der Steuerkreislauf-Logik entkoppeln
+- [ ] `G92`/`M92`-Verhalten im Kontext des Datei-Managements klar dokumentieren
\ No newline at end of file
diff --git a/doc/ToDo_5_API.md b/doc/ToDo_5_API.md
new file mode 100644
index 0000000..27d1a43
--- /dev/null
+++ b/doc/ToDo_5_API.md
@@ -0,0 +1,21 @@
+# ToDo 5 — API und Antwortlogik
+
+## Ziel der Verbesserung
+
+Die Schnittstellen sollen klar und vorhersagbar antworten. Steuerbefehle brauchen eigene Antwortpfade, und Status-/Positionsergebnisse müssen eindeutig getrennt werden.
+
+## Aufgaben
+
+- [ ] WebSocket-Antwortlogik strukturieren
+  - Steuerbefehle erhalten gezielte Responses
+  - `Ping`, `M114`, Statusabfragen und Fehlermeldungen getrennt behandeln
+- [ ] Broadcasts nur dort verwenden, wo sie sinnvoll sind
+  - Broadcasts für Status-Updates, nicht für direkte Steuerantworten
+- [ ] `InfoServer` um detaillierte Statusinformationen erweitern
+  - Senderverbindungen
+  - Health-Checks
+  - letzte Befehle / Pings
+- [ ] API-Endpunkte klar dokumentieren
+  - `/api/status`
+  - `/api/position`
+- [ ] Fehlermeldungen konsistent und maschinenlesbar machen
\ No newline at end of file
diff --git a/doc/ToDo_6_RobotController.md b/doc/ToDo_6_RobotController.md
new file mode 100644
index 0000000..de452b9
--- /dev/null
+++ b/doc/ToDo_6_RobotController.md
@@ -0,0 +1,17 @@
+# ToDo 6 — RobotController
+
+## Ziel der Verbesserung
+
+Der `RobotController` fasst die Steuerlogik zusammen und hält den Roboterzustand vom G-Code-Parsing getrennt. So wird die Architektur modularer und leichter wartbar.
+
+## Aufgaben
+
+- [ ] `RobotController` einführen
+  - verarbeitet strukturierte G-Code-/Befehlsobjekte
+  - steuert `moveRelative`, `calculateAngles3D()`, `calculateSpeeds()` und `sendCommand()`
+- [ ] `Robot.js` als reines Modell-/Kinematik-Modul nutzen
+  - Zustand, Längen, Winkel, Kinematik-Berechnungen
+- [ ] den Übergang von Befehlsobjekt zu Motorpositionen sauber definieren
+- [ ] Logik für Bewegungsbefehle zentralisieren: `G1`, `G28`, `G90`, `G91`, `G92`, `M1`
+- [ ] rohe Textstrings aus der Controller-Schicht entfernen
+- [ ] Zustandsänderungen konsistent an die Sender weiterreichen
diff --git a/doc/ToDo_7_Tests.md b/doc/ToDo_7_Tests.md
new file mode 100644
index 0000000..ffe7986
--- /dev/null
+++ b/doc/ToDo_7_Tests.md
@@ -0,0 +1,27 @@
+# ToDo 7 — Tests und Stabilität
+
+## Ziel der Verbesserung
+
+Testabdeckung und Fehlerbehandlung sollen die Stabilität der Architektur erhöhen. Kernfunktionen müssen verlässlich arbeiten und unerwartete Zustände sauber behandeln.
+
+## Aufgaben
+
+- [ ] Unit-Tests für `GCodeParser`
+- [ ] Unit-Tests für `RobotController`
+- [ ] Unit-Tests für `TelnetSenderGRBL`
+  - Verbindungsstatus
+  - Fehlerfälle
+  - korrektes Sendeformat
+- [ ] Tests für `InputWS.js`
+  - gültige G-Code-Nachrichten
+  - Ping-Verarbeitung
+  - Statusabfragen
+- [ ] Tests für `InfoServer`
+  - `/api/status`
+  - `/api/position`
+- [ ] Fehlerfälle explizit prüfen
+  - ungültiger G-Code
+  - verlorene Telnet-Verbindung
+  - fehlende Zertifikate
+  - unvollständige Konfiguration
+- [ ] Testausführung via `npm test` sicherstellen