Claude API

doc/ToDo_5_API.md

@@ -6,16 +6,31 @@ Die Schnittstellen sollen klar und vorhersagbar antworten. Steuerbefehle brauche
 
 ## Aufgaben
 
-- [ ] WebSocket-Antwortlogik strukturieren
+- [x] WebSocket-Antwortlogik strukturieren
   - Steuerbefehle erhalten gezielte Responses
   - `Ping`, `M114`, Statusabfragen und Fehlermeldungen getrennt behandeln
-- [ ] Broadcasts nur dort verwenden, wo sie sinnvoll sind
+  - → `server/InputWS.js` als klarer Router; `Ping`/`M114` antworten gezielt an den Anfrager
+- [x] 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
+  - → Bewegung (G-Code) broadcastet die neue Position; `Ping`/`M114` sind gezielt
+- [x] `InfoServer` um detaillierte Statusinformationen erweitern
+  - Senderverbindungen · Health-Checks · letzte Befehle / Pings
+  - → bereits in ToDo 2 angelegt; ergänzt um Top-Level `health`-Summary + `generatedAt`
+- [x] API-Endpunkte klar dokumentieren
+  - `/api/status` · `/api/position`
+  - → `doc/API.md`
+- [x] Fehlermeldungen konsistent und maschinenlesbar machen
+  - → einheitliches Fehler-Envelope `{ type, code, message, input }`
+    (`UNKNOWN_COMMAND` / `GCODE_ERROR` / `FILE_ERROR`)
+
+## Tests
+
+- `test/InputWS.api.test.js` — gezielte vs. Broadcast-Antworten, Fehler-Envelope
+- `test/InfoServer.test.js` — Health-Summary + `generatedAt`
+
+## Bewusst nicht in diesem ToDo
+
+- Feinere Zielsteuerung der Datei-Befehle (z. B. `FShow` nur an Anfrager) und
+  `FFirst`/`FLast` → gehören zur Datei-Verwaltung in **ToDo 4**.
+- Erfolgs-Payloads (`Ping`, Positions-JSON) bleiben aus Rückwärtskompatibilität im
+  Rohformat (externe Clients: Simulation/Gamepad); nur Fehler nutzen das Envelope.