Halloween/tools/instructions.md

Modul tools/

Hier liegen Pi-Transfer/Einrichtung und die reproduzierbaren Blender-Werkzeuge.

• upload_to_pi.sh zeigt ohne --apply nur eine lokale Vorschau. Jede Version kommt in einen neuen releases/-Ordner; niemals data/ oder bestehende Dateien überschreiben/löschen. SSH-Hostschlüssel weiterhin prüfen.
• activate_pi_release.sh läuft auf dem Pi: flock-Sperre, eigene venv vorbereiten, verwalteten Dienst stoppen, data/ sichern, current atomar wechseln. Bei Fehlern Code, Unit und Daten wiederherstellen und alten Dienst prüfen. Abhängigkeiten nur als Wheels installieren. Fremde Units und manuelle Server ablehnen.
• install_pi_service.sh richtet systemd-Autostart ein, beim Upload automatisch. Gemeinsames HALLOWEEN_STATE_DIR; Code/venv über current, wo vorhanden. Default Loopback; direkter Heimnetzzugriff nur mit ausdrücklich gewähltem Host. sudo nur bei --apply; keine Browser-Automation. Alle Versionen/Backups behalten.
• Render-, Ton- und Prüfscripte unter tools/ erzeugen Dateien in preview/. Bearbeitbare .blend-Szenen werden versioniert, gerenderte Medien und .blend1-Backups bleiben lokal.
• Keine Pi-Adressen, Zugangsdaten, WLAN-Schlüssel oder Gerätemodelle in Skripten fest eintragen. Zielwerte kommen aus Argumenten oder werden am tatsächlichen Gerät geprüft.

Änderungen an Upload- und Installationsbefehlen in UPLOAD.md und SOFTWARE.md nachführen; Renderabläufe in den jeweiligen README-Dateien unter preview/ dokumentieren.

Fiktive Scan-Videos nutzen nur synthetische Avatare und Demo-IDs. Kegelprojektion, Zeichnen der Bildsequenz und Videoschnitt sind getrennte Schritte; Reihenfolge im zugehörigen Vorschau-README dokumentieren.

• install_detection_model.py lädt auf ausdrücklichen Aufruf das im Manifest fixierte NanoDet-Modell unter data/models/. Größe und SHA-256 vor atomarem Ersetzen prüfen, TLS-Prüfung beibehalten. --state-dir bzw. HALLOWEEN_STATE_DIR muss zum Server passen. Keine Modellgewichte hochladen.

• Versionierte Updates verwenden genau einen sudo-Aufruf nach unprivilegierter Paketvorbereitung. activate_pi_release.sh --privileged ist der interne Teil: Unitprüfung, Sicherung, Umschaltung, systemd und Rückfall im selben sudo-Prozess. Normale Einstiegsshell hält flock über dessen Laufzeit. Nicht direkt aufrufen.

• Python-/Projektprüfungen und Unit-Renderer im privilegierten Teil mit runuser als SUDO_USER ausführen. Keine Pakete als root, kein Passwortspeicher/Keepalive und keine sudoers-/Zeitstempeländerung. install_pi_service.sh --print-unit rendert ohne sudo; standalone --apply ist vom Updateaufruf getrennt.

• Neu erzeugte Backupordner, Unit-Sicherung, current-Link und service-host dem ursprünglichen Pi-Benutzer zuordnen; bestehende Datenbesitzer beim Kopieren bewahren. Abgelehnte sudo-Anmeldung darf keine Umschaltung/Dienstpause auslösen.

• Upload baut einen SSH-ControlMaster pro angewendetem Aufruf auf; Ordneranlage, rsync und Aktivierung teilen den Socket. Privater temporärer Ordner unter /tmp (0700), ControlPersist=no und EXIT-/Signal-Aufräumen. Hostschlüsselprüfung bleibt aktiv, keine Passwörter/Schlüssel/SSH-Konfiguration neu speichern.

• Slave-Verbindungen verwenden BatchMode=yes, damit bei Verlust der gemeinsamen Verbindung keine weiteren Passwortdialoge entstehen. Ohne Schlüssel sind SSH und sudo weiterhin zwei getrennte Anmeldungen. Vorschau erzeugt keinen Socket.