9e3e06eb09
Implements FR-020: Grace Time (buffer period after free time) Problem: Fan relay signal continues ~5s after laser stops, causing false billable time charges when user stops at countdown 1 second. Solution: New GRACE state between GRATIS and NET_COUNTING with configurable grace period (default 5s, range 0-30s). During grace time, display shows blinking 0 (number of blinks = remaining seconds). If laser stops during GRACE, no billable session is created. State machine: INACTIVE -> GRATIS -> GRACE -> NET_COUNTING Changes: - config.h: Add DEFAULT_GRACE_TIME_S (5), MIN/MAX constants - settings.h/cpp: Add graceTimeSeconds field, NVS persistence - laser_tracker.h/cpp: Add GRACE state, transition logic - display_manager.h/cpp: Add showGraceBlinking() with blink animation - main.cpp: Add GRACE state handling in display update loop - mqtt_client.cpp: Add grace_time_s field to session JSON - web_server.cpp: Add Grace Time input field in config page - README.md: Update documentation with GRACE state details - Feature-Requests.md: Mark FR-020 as completed (v1.6.4) Version: 1.6.4 Tested: Manual testing with logs and MQTT Explorer
43 lines
2.6 KiB
Markdown
43 lines
2.6 KiB
Markdown
# Copilot Workspace Instructions
|
||
|
||
Du bist ein KI-gestützter Code-Assistent, der in diesem Projekt verwendet wird, um die Entwicklung zu unterstützen. Bitte beachte die folgenden Anweisungen, um sicherzustellen, dass deine Beiträge zum Projekt konsistent und von hoher Qualität sind. Deine Antworten beginnen immer mit Dev:.
|
||
|
||
## Projektziele
|
||
Diese sind in der README.md definiert. Stelle sicher, dass deine Beiträge auf die Erreichung dieser Ziele ausgerichtet sind.
|
||
|
||
## Projektstand
|
||
Lese den aktuellen Stand des Projekts in der Datei `Implementation-Plan.md`, um sicherzustellen, dass deine Beiträge mit den laufenden Entwicklungen übereinstimmen. Du hast immer den kompletten Überblick über das Projekt und kennst die README.md.
|
||
|
||
## Sprache
|
||
Antworte immer auf **Deutsch** (Dev-Sprache dieses Projekts).
|
||
|
||
## Terminal-Nutzung
|
||
Öffne **keine neue Console/Terminal-Instanz**, wenn bereits eine aktive Shell vorhanden ist.
|
||
Verwende stets ein bereits geöffnetes Terminal weiter.
|
||
|
||
## await_terminal – VERBOTEN während laufender Prozesse
|
||
Verwende **niemals** `await_terminal` (oder vergleichbare Wait-Befehle), während ein Build, Upload oder sonstiger längerer Prozess läuft.
|
||
`await_terminal` **bricht den laufenden Vorgang ab**.
|
||
Warte stattdessen passiv – der Benutzer meldet das Ergebnis selbst.
|
||
|
||
## Commit
|
||
vor jedem Commit wird die neue Funktionalität mit test_sketches/test_*.cpp getestet. Alle Tests müssen erfolgreich durchlaufen, bevor ein Commit möglich ist. Sollte es keine Test geben, zum Beispiel für die Überprüfung des gesamten Moduls, lasse den Benutzer vor dem Commit die Änderung manuell testen.
|
||
|
||
### Dokumentation vor dem Commit
|
||
- **Bug Fix / kleines Feature** (kein neues Modul, keine neue Phase): Eintrag in `Feature-Requests.md` aktualisieren (Status auf ✅ setzen). `Implementation-Plan.md` wird **nicht** angefasst.
|
||
- **Neue Phase / größeres Feature** (neues Modul, neue Architektur): `Implementation-Plan.md` aktualisieren. `Feature-Requests.md` bleibt unberührt.
|
||
|
||
### Versions Nummer
|
||
Die Firmware-Version wird in `platformio.ini` als `build_flag` definiert. **Erhöhe die Version IMMER als ERSTES vor jeder Code-Änderung** (nicht erst vor dem Commit), damit beim Upload die neue Versionsnummer im Webinterface sichtbar ist.
|
||
|
||
Versionierung:
|
||
- **Bug Fixes**: 3. Stelle erhöhen (z.B. `1.0.0` → `1.0.1`)
|
||
- **Neue Funktionalität**: 2. Stelle erhöhen (z.B. `1.0.0` → `1.1.0`)
|
||
- **Neue Phase / Breaking Changes**: 1. Stelle erhöhen (z.B. `1.0.0` → `2.0.0`)
|
||
|
||
Workflow:
|
||
1. Frage den Benutzer, ob die Version erhöht werden soll
|
||
2. Erhöhe die Version in `platformio.ini`
|
||
3. Führe die Code-Änderungen durch
|
||
4. Teste die Implementierung
|
||
5. Commit |