Transaktionsakte TP17.1-dtu-pin-ap2 geschlossen (zurueckgebaut)

Audit-Trail zum fehlgeschlagenen DTU-Pin. state=rolledback, closed 2026-08-23.
access-list ist wieder leer, Snapshot-Vergleich 0 zu 0 Zeilen, keine offenen
Transaktionen mehr auf crs326-core.

Abnahme am Geraet statt am Job-Status: DTU wieder erreichbar, und die Telemetrie
fliesst -- 385,8 W, Tagesertrag 613, Zeitstempel 14:48. Die Unterbrechung hat rund
zehn Minuten gedauert.

Hinweis fuer spaetere Leser: das reason-Feld der Akte nennt noch die Annahme, ueber
ap2 wandere der DTU-AP auf ch11. Genau die ist widerlegt worden -- das Geraet hat
eine feste Kanalwahl und kann auf ch11 nicht assoziieren. Die Akte bleibt bewusst
unveraendert (sie ist ein Protokoll, kein Dokument); die Aufloesung steht im
Runbook unter "Versuch DTU an ap2 binden -- FEHLGESCHLAGEN".

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

docs/transaktionen/TP17.1-dtu-pin-ap2.json

@@ -8,7 +8,8 @@
   "reason": "DTU/Wechselrichter (54:F2:9F:12:51:F0) per access-list an ap2 binden. Grund: ein ESP hat EIN Radio, AP und STA teilen den Kanal -- der nicht abschaltbare DTU-AP sitzt auf ch1 (ap1) und stoert dort mit -59 dBm. Ueber ap2 wandert er auf ch11. Ist der Kanalplan nach dem Einbau der zwei neuen APs entschieden, wird das neu bewertet: entweder committen oder zurueckrollen.",
   "started": "2026-08-23",
   "expires": "2026-09-06",
-  "state": "open",
+  "state": "rolledback",
   "snapshot": "docs/transaktionen/TP17.1-dtu-pin-ap2.snapshot.rsc",
-  "device_backup": ""
+  "device_backup": "",
+  "closed": "2026-08-23"
 }

docs/transaktionen/TP17.1-dtu-pin-ap2.rollback.rsc

@@ -0,0 +1,6 @@
+# Rueckbau-VORSCHLAG fuer TP17.1-dtu-pin-ap2 (crs326-core, Scope wifi-access-list)
+# Aus dem Snapshot vom 2026-08-23. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+