Halloween/halloween/instructions.md

# Modul `halloween/`

Hier liegt die erste Pi-WebUI. `run.py` im Projektstamm startet sie.

- `camera.py` liefert ein gemeinsames MJPEG-Bild für mehrere Betrachter.
  `--demo` erzeugt ausdrücklich gekennzeichnete Testbilder; echte Kamera
  läuft nur über Picamera2 auf dem Pi. Kamerafehler sichtbar melden.
- `controller.py` enthält bislang ausschließlich die simulierte
  Effekt-Zustandslogik. Stopp bleibt bis zum Rücksetzen bestehen; nach Start
  oder Rücksetzen muss erst der Bereich frei sein und dann ein neuer Trigger
  kommen. Beschädigte Einstellungen schalten auf `aus`.
- `web.py` bietet WebUI und API; `index.html` ist die Oberfläche. `run.py`
  bindet an `127.0.0.1`, Zugriff vom Laptop erfolgt per SSH-Tunnel.
- `event_store.py` verwaltet `data/events.sqlite3`. Erfolgreiche manuelle
  Testauslösungen werden als Ereignisse gespeichert; Profile besitzen
  Kennungen und können Ereignissen zugeordnet werden. Profil-Löschen entfernt
  die Zuordnung, nicht das Ereignis. Auto-Profile können Merkmalsvektoren
  aufnehmen und verfallen 30 Tage nach letzter Sichtung. Start, stündlicher
  Lauf und Lesezugriffe räumen abgelaufene Profile auf; die Kamera liefert
  derzeit noch keine Merkmalsvektoren.
- Automatische Profilzuordnung per Kamera ist ein neuer Nutzerwunsch, aber
  noch nicht implementiert. Eine künftige Erkennung muss Unsicherheit und
  mögliche Fehlzuordnungen sichtbar machen und am echten Pi geprüft werden.
- Der Header `X-Halloween-UI` ist nur eine einfache Schranke für
  Schreibaufrufe, kein echter Zugangsschutz. Vor Betrieb mit anderen
  Netzfreigaben Authentifizierung entwerfen und prüfen.
- Laufzeitdaten liegen standardmäßig unter `data/` und werden weder
  hochgeladen noch in Git aufgenommen.
- Echte GPIO-/Aktorsteuerung erst nach geklärter Mechanik, Versorgung,
  sicherem Stopp und den Hardwaretests aus `PLAN.md` ergänzen.

Bei Änderungen an Zustandsübergängen oder Endpunkten die zugehörigen Tests
unter `tests/` und die Bedienhinweise in `SOFTWARE.md` prüfen.