.ps1 braucht ein BOM: Autologon-Skript brach unter powershell.exe 5.1

Das Skript liess sich nicht ausfuehren — "Schliessende ) fehlt",
"Zeichenfolge hat kein Abschlusszeichen". Es war KEIN Syntaxfehler:
Windows PowerShell 5.1 liest .ps1 als CP1252, wenn kein BOM da ist. Aus dem
Gedankenstrich werden drei Zeichen, das darin enthaltene Anfuehrungszeichen
schliesst den String vorzeitig, und der Fehler kaskadiert bis zum Dateiende.

Der eigentliche Punkt ist, warum es beim Schreiben nicht auffiel: das hiesige
PowerShell-Werkzeug ist pwsh 7, und das liest UTF-8 ohne BOM klaglos. Die Datei
war in meiner Umgebung fehlerfrei und beim Nutzer kaputt — dieselbe
Divergenz-Klasse wie der Deployment-Drift, nur eine Ebene tiefer: die
Pruefumgebung war nicht die Laufumgebung.

Behoben (UTF-8 MIT BOM) und mit dem ECHTEN 5.1-Parser gegengeprueft
(Parser::ParseFile, 0 Fehler) — nicht mit pwsh 7, das den Fehler ja gerade
nicht zeigt.

Dabei ein zweiter Fall gefunden und mitbehoben: scripts/send_daily_report.ps1
(Umlaute, kein BOM). Der ist zwar dormant (Microsoft.Graph-Modul fehlt), haette
aber genauso gebrochen.

Dauerhaft abgesichert: tools/check_nfalle.py prueft es als Stufe C2 —
.ps1 mit Nicht-ASCII und ohne BOM ist ab jetzt ein Befund.

.bat ist nicht betroffen: cmd.exe verzeiht das in echo/Kommentaren
(restart_server.bat enthaelt Sonderzeichen, bricht aber nicht).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -284,6 +284,23 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   Passwort steht **nicht** im Skript und wird nirgends gespeichert; es wird im
   Autologon-Dialog eingegeben. **Zurück:** `Autologon /accepteula` → Disable, und
   `schtasks /Delete /TN OilAutoLogonLock /F`.
+- **⚠⚠ .ps1 MIT NICHT-ASCII BRAUCHT EIN BOM — sonst bricht `powershell.exe` 5.1
+  (2026-08-07, real passiert).** Das Autologon-Skript ließ sich nicht ausführen:
+  „Schließende ) fehlt", „Zeichenfolge hat kein Abschlusszeichen". Es war **kein**
+  Syntaxfehler: **Windows PowerShell 5.1 liest `.ps1` als CP1252, wenn kein BOM da
+  ist.** Aus dem Gedankenstrich `—` werden drei Zeichen (`â€"`), das enthaltene
+  `"` schließt den String vorzeitig, und es kaskadiert bis zum Dateiende.
+  ⚠⚠ **Warum es beim Schreiben nicht auffiel — und das ist der eigentliche Punkt:**
+  das hiesige PowerShell-Werkzeug ist **pwsh 7**, und das liest UTF-8 **ohne** BOM
+  klaglos. Die Datei war also in meiner Umgebung fehlerfrei und beim Nutzer kaputt.
+  Dieselbe Divergenz-Klasse wie der Deployment-Drift, nur eine Ebene tiefer: **die
+  Prüfumgebung war nicht die Laufumgebung.**
+  ✅ Behoben (UTF-8 **mit** BOM) und mit dem **echten 5.1-Parser** gegengeprüft
+  (`Parser::ParseFile`, 0 Fehler). Dabei ein **zweiter** Fall gefunden:
+  `scripts/send_daily_report.ps1` (Umlaute, kein BOM).
+  ✅ **Dauerhaft abgesichert:** `tools/check_nfalle.py` prüft es als Stufe **C2**.
+  ⚠ `.bat` ist NICHT betroffen (`cmd.exe` verzeiht das in `echo`/Kommentaren —
+  `restart_server.bat` enthält zwar `─`/`⚠`, bricht aber nicht).
 - **✅ STUFE 5 DER PIPELINE IST JETZT EIN SKRIPT (`tools/deploy.py`, 2026-08-07).**
   Ersetzt das von Hand zusammengesetzte „killen, starten, warten, nachsehen" und
   macht die dokumentierte Schwachstelle prüfbar.

scripts/send_daily_report.ps1

@@ -1,4 +1,4 @@
-# send_daily_report.ps1
+# send_daily_report.ps1
 # Sendet täglich um 0 Uhr eine HTML-Zusammenfassung aller Trades des Vortages.
 
 $python    = "C:\Users\ah\AppData\Local\Programs\Python\Python312\python.exe"

tools/autologon_einrichten.ps1

@@ -1,4 +1,4 @@
-# Auto-Logon einrichten — schliesst die letzte Luecke der Boot-Pipeline.
+# Auto-Logon einrichten — schliesst die letzte Luecke der Boot-Pipeline.
 #
 # WOZU: `OilTradingServer` und `HyperliquidDashboard` haengen an einem LOGON-
 # Trigger. Nach einem Windows-Update-Reboot laeuft nichts, bis sich jemand

tools/check_nfalle.py

@@ -185,6 +185,40 @@ for p in list(dateien(".html")) + list(dateien(".md")):
 
 
 # ── D) Signatur der heutigen Faelle ──────────────────────────────────────
+# ── C2) .ps1 ohne BOM mit Nicht-ASCII = Zeitbombe ────────────────────────
+# ⚠⚠ REAL PASSIERT (2026-08-07): `tools/autologon_einrichten.ps1` liess sich nicht
+# ausfuehren — „Schliessende ) fehlt", „Zeichenfolge hat kein Abschlusszeichen".
+# Ursache war KEIN Syntaxfehler: **Windows PowerShell 5.1 (`powershell.exe`) liest
+# .ps1-Dateien als CP1252, wenn kein BOM da ist.** Aus dem Gedankenstrich „—"
+# werden dann drei Zeichen (â€"), und das enthaltene " schliesst den String
+# vorzeitig — Folgefehler bis zum Dateiende.
+# ⚠ Warum es beim Schreiben nicht auffiel: `pwsh` 7 (mein Werkzeug) liest UTF-8
+# OHNE BOM klaglos. Die Datei war also fuer mich fehlerfrei und fuer den Nutzer
+# kaputt. Genau die Sorte Divergenz, die dieses Projekt als Deployment-Drift
+# kennt — hier auf der Werkzeug-Ebene.
+# Fix: UTF-8 MIT BOM schreiben. Gefunden wurde dabei ein zweiter Fall
+# (`scripts/send_daily_report.ps1`, mit Umlauten).
+print()
+print("=" * 88)
+print("  C2) POWERSHELL — .ps1 mit Nicht-ASCII braucht ein BOM (sonst CP1252)")
+print("=" * 88)
+for p in dateien(".ps1"):
+    roh = p.read_bytes()
+    bom = roh[:3] == b"\xef\xbb\xbf"
+    try:
+        txt = roh.decode("utf-8-sig")
+    except UnicodeDecodeError:
+        txt = roh.decode("cp1252", errors="replace")
+    na = sorted({c for c in txt if ord(c) > 127})
+    if na and not bom:
+        befunde.append(f"PS1 {p.relative_to(WURZEL)}: Nicht-ASCII ohne BOM")
+        print(f"  FEHLER  {p.relative_to(WURZEL)}  "
+              f"{len(na)} Nicht-ASCII-Zeichen, KEIN BOM → bricht unter "
+              f"powershell.exe 5.1")
+    else:
+        print(f"  OK      {p.relative_to(WURZEL)}"
+              + ("  (BOM)" if bom else "  (rein ASCII)"))
+
 print()
 print("=" * 88)
 print('  D) SIGNATUR — Zeile endet offen, naechste besteht nur aus einem Quote')