diff --git a/routeros/tp27-routerboot-firmware-724.rsc b/routeros/tp27-routerboot-firmware-724.rsc
new file mode 100644
index 0000000..2be7ed0
--- /dev/null
+++ b/routeros/tp27-routerboot-firmware-724.rsc
@@ -0,0 +1,37 @@
+# TP27 — RouterBOOT-Firmware auf 7.24 nachziehen (2026-08-17).
+#
+# KONTEXT: Christoph hat alle vier MikroTik selbst auf RouterOS 7.24 stable
+# gehoben. Verifiziert, nichts kaputt. Was dabei offen blieb, ist die zweite
+# Haelfte jedes MikroTik-Upgrades: die **RouterBOOT-Firmware** haengt zurueck.
+#
+#   crs326-core    7.19.5 -> 7.24
+#   crs326-branch  7.19.5 -> 7.24
+#   ap1            7.23.2 -> 7.24
+#   ap2            7.23.2 -> 7.24
+#
+# `/system routerboard upgrade` SCHREIBT die Firmware nur; wirksam wird sie
+# erst beim naechsten Reboot. Darum: erst schreiben, dann gezielt rebooten,
+# dann `current-firmware` gegenpruefen — vorher zeigt sie weiter den alten Wert.
+#
+# WARUM UEBER GC UND NICHT MikroMCP: `/system routerboard upgrade*` steht auf
+# der MikroMCP-Deny-Liste (zu Recht — es schreibt den Bootloader). Der
+# GC-Weg ist ohnehin der vorgeschriebene.
+#
+# Push je Geraet:
+#   python3 nautobot/gc-manual-plan.py --device <name> \
+#       --commands-file routeros/tp27-routerboot-firmware-724.rsc \
+#       --change-id TP27-fw-<name> --deploy
+#
+# Danach Reboot (MikroMCP `reboot`), dann:
+#   current-firmware muss 7.24 sein.
+#
+# REIHENFOLGE (bewusst): ap2 -> ap1 -> core -> branch.
+# branch zuletzt, weil der Arbeitsplatz per LAN daran haengt — er ist die
+# Lifeline zu allen anderen Geraeten und wird erst angefasst, wenn der Rest
+# nachweislich sauber oben ist.
+#
+# Backups davor: <geraet>-post724-pre-fw-20260817.backup
+
+:do { /system routerboard upgrade } on-error={ :log info "tp27: upgrade warf" }
+
+:log info ("tp27: fw-geschrieben current=" . [/system/routerboard/get current-firmware] . " upgrade=" . [/system/routerboard/get upgrade-firmware] . " (current wechselt erst nach dem Reboot)")