Merge main + nervous-williams; Drift-Zuschreibung korrigiert

Der Branch enthaelt jetzt origin/main (0680cca, TP25 Fund E / TP27) und
die Korrektur c8b2a15 aus claude/nervous-williams-acf000.

Inhaltliche Korrektur an meinen eigenen Dateien
- Ich hatte die wifi-security-Drift (ft-over-ds=no auf sec-main) dem
  7.24.1-Upgrade zugeschrieben. Falsch: gc-transaktion.py status fuehrt
  TP25-fund-e-ft-over-ds als OFFEN -- der Hebel wurde 08:09 bewusst
  gesetzt, der Core erst 14:36 gehoben. Sie gehoert einer laufenden
  TP25-Session, braucht keine Entscheidung und darf nicht gruen gemacht
  werden. Korrigiert im §5-Prompt und im §2/§3-Handoff.
- Merkregel in CLAUDE.md: vor jeder Drift-Bewertung gc-transaktion.py
  status lesen. Dazu die Abgrenzung Transaktion (befristeter Versuch)
  vs. Soll/Template (Dauerzustand) -- die sechs AP-Drifts aus TP16.3
  §3.4 sind Dauerzustand und gehoeren deshalb ins Template, nicht in
  eine Transaktion.
- Notiert: gc-transaktion.py findet den Token aus einem Worktree heraus
  nicht (210-nautobot.yml liegt nur im Haupt-Checkout); die
  Transaktionsliste kommt trotzdem, nur die Compliance-Spalte fehlt.

Konflikt in teilprojekte.md (ROS-7.24.1-Zeile) zusammengefuehrt statt
eine Seite zu verwerfen: TP27-Erledigung samt Zeitstempeln aus main plus
die npk-Folge fuer TP16.3 aus diesem Branch.

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

CLAUDE.md

@@ -9,11 +9,13 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
 1. **`docs/teilprojekte.md`** (Quick-Index-Block) — kanonischer Stand, Scope, Abhängigkeiten, **offene** TPs. **1 Read reicht.**
 2. **`docs/handoff-*.md`** (neueste) — wo die letzte Session aufgehört hat.
 3. Bei Live-Writes oder Inventur: **`docs/cf-tunnel-mapping.md`**, **`docs/teilprojekte-archiv.md`**.
-4. 🔴 **WLAN/Fund E — LAUFENDER VERSUCH:** [`docs/handoff-20260831-fund-e-hebel1-gezogen.md`](docs/handoff-20260831-fund-e-hebel1-gezogen.md)
+4. 🔴 **WLAN/Fund E — HEBEL 1 GESCHEITERT + TP27 durchgezogen:**
-   — Hebel 1 (`ft-over-ds=no` auf `sec-main`) ist am **2026-08-31 08:09** gezogen, Transaktion
+   [`docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md)
-   `TP25-fund-e-ft-over-ds` ist **offen**, **Compliance steht deshalb absichtlich auf 134/135**.
+   — `ft-over-ds=no` hat **nicht** gegriffen (124 `reauthenticating` nach dem Eingriff, zwei erlebte
-   Einzige offene Aufgabe: **messen und entscheiden** (24 h). Befund davor:
+   Ausfälle um 13:16 und 14:23). Transaktion `TP25-fund-e-ft-over-ds` **bleibt offen**, **Compliance
-   [`docs/handoff-20260831-wlan-fund-e.md`](docs/handoff-20260831-wlan-fund-e.md).
+   steht weiter absichtlich auf 134/135**. Nächste Entscheidung: Hebel 2 (`ft=no`) **oder**
+   `wpa2-psk,wpa3-psk` — vorher prüfen, ob 7.24.1 das Verhalten schon verändert hat.
+   Vorstufen: [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md) · [Befund](docs/handoff-20260831-wlan-fund-e.md).
 5. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
 6. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
 
@@ -63,11 +65,11 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
 |---|---|---|
 | ~~ALLNET Core-Switch (sw1)~~ | — | ❌ **außer Betrieb (2026-08-08)** — durch `crs326-core` (L3-Router + Core-Switch, Technik UG) ersetzt; physisch abgelöst. (Telnet-Runner `switch/` = nur noch historisch.) |
 | ~~Omada Access-Switch (sw2)~~ | — | ❌ **abgebaut 2026-07-23** (TP15 Branch-Tausch) — durch `crs326-branch` in Technik OG ersetzt, physisch entfernt |
-| **crs326-branch** (CRS326, Technik OG) | **10.40.99.2** (VLAN99) · Bootstrap Rev4 2026-08-08 | RouterOS **7.24** · `admin`/`~/.secrets` (`CRS326_BRANCH_*`) · REST `http://10.40.99.2/rest` · MikroMCP `crs326-branch` ✅ **live** (2026-08-16 verifiziert) · **TP15 ✅: ersetzt sw2** (L2-Switch), volle Portbelegung (ether1 Uplink-Trunk, 2/8 NAS, 3 Drucker, 4 Dock, 5/6 Sonos, 7 macmini, 24 ap2) · sw-id RGZJ-UK0T, MAC 04:F4:1C:B4:15:58 |
+| **crs326-branch** (CRS326, Technik OG) | **10.40.99.2** (VLAN99) · Bootstrap Rev4 2026-08-08 | RouterOS **7.24.1** · `admin`/`~/.secrets` (`CRS326_BRANCH_*`) · REST `http://10.40.99.2/rest` · MikroMCP `crs326-branch` ✅ **live** (2026-08-16 verifiziert) · **TP15 ✅: ersetzt sw2** (L2-Switch), volle Portbelegung (ether1 Uplink-Trunk, 2/8 NAS, 3 Drucker, 4 Dock, 5/6 Sonos, 7 macmini, 24 ap2) · sw-id RGZJ-UK0T, MAC 04:F4:1C:B4:15:58 |
-| **crs326-core** (CRS326, Technik UG) | **10.40.99.1** (VLAN99-SVI = L3-GW; same-subnet-Fallback `10.40.10.1`) · Identity `crs326-core` | RouterOS **7.24** · `admin`/`~/.secrets` (`CRS326_CORE_*`) · MikroMCP routerId `crs326-core` ✅ **live** (2026-08-16 verifiziert) · **TP15/TP21.1 ✅ 2026-08-08: PRODUKTIVER L3-Router** (ersetzt ap1) — Routing/DHCP (7 Server + 54 Leases)/DNS (**DoH zum CF-Gateway mit `verify-doh-cert=yes`**, TP23 Stufe 1 ✅ 2026-08-18; `servers=1.1.1.1` nur noch Bootstrap) · **NTP-Server für den Standort**/NAT/WG-Hub (fm+dw live); WAN `vlan100`=Liwest `90.146.33.177` · sw-id 4W04-URHT, MAC 04:F4:1C:B4:17:76 |
+| **crs326-core** (CRS326, Technik UG) | **10.40.99.1** (VLAN99-SVI = L3-GW; same-subnet-Fallback `10.40.10.1`) · Identity `crs326-core` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`CRS326_CORE_*`) · MikroMCP routerId `crs326-core` ✅ **live** (2026-08-16 verifiziert) · **TP15/TP21.1 ✅ 2026-08-08: PRODUKTIVER L3-Router** (ersetzt ap1) — Routing/DHCP (7 Server + 54 Leases)/DNS (**DoH zum CF-Gateway mit `verify-doh-cert=yes`**, TP23 Stufe 1 ✅ 2026-08-18; `servers=1.1.1.1` nur noch Bootstrap) · **NTP-Server für den Standort**/NAT/WG-Hub (fm+dw live); WAN `vlan100`=Liwest `90.146.33.177` · sw-id 4W04-URHT, MAC 04:F4:1C:B4:17:76 |
-| hAP ax² #1 (ap1) | **10.40.99.11** (VLAN99) · Identity `ap1` | RouterOS **7.24** · `admin`/`~/.secrets` (`ROUTER_AP1_*`) · REST `http://10.40.99.11/rest` · MikroMCP `ap1` ✅ live · **TP28 ✅ 2026-08-17: reiner CAP** (Manager = `crs326-core`) · 🔴 **FUNKSTILL seit 2026-08-30**: keine Provisioning-Regel am Manager, weil ap3 daneben steht und denselben Kanal 5180 fährt. Gerät bleibt erreichbar. Beim Umzug ans Sideboard → `5260/Ce` (Band B, DFS) und Uplink auf `core ether3` — Uplink `ether1` (PoE-Port, `poe-out=off`) an crs326-core `ether15`; SSIDs/Kanäle kommen vom Manager, ch36/ch1 · MAC D0:EA:11:4D:40:E0 · Config-Referenz `routeros/.secrets/ap1-prov-base.rsc` |
+| hAP ax² #1 (ap1) | **10.40.99.11** (VLAN99) · Identity `ap1` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP1_*`) · REST `http://10.40.99.11/rest` · MikroMCP `ap1` ✅ live · **TP28 ✅ 2026-08-17: reiner CAP** (Manager = `crs326-core`) · 🔴 **FUNKSTILL seit 2026-08-30**: keine Provisioning-Regel am Manager, weil ap3 daneben steht und denselben Kanal 5180 fährt. Gerät bleibt erreichbar. Beim Umzug ans Sideboard → `5260/Ce` (Band B, DFS) und Uplink auf `core ether3` — Uplink `ether1` (PoE-Port, `poe-out=off`) an crs326-core `ether15`; SSIDs/Kanäle kommen vom Manager, ch36/ch1 · MAC D0:EA:11:4D:40:E0 · Config-Referenz `routeros/.secrets/ap1-prov-base.rsc` |
-| hAP ax² #2 (ap2) | **10.40.99.12** (VLAN99) · Identity `ap2` | RouterOS **7.24** · `admin`/`~/.secrets` (`ROUTER_AP2_*`) · REST `http://10.40.99.12/rest` · MikroMCP `ap2` · **TP28 ✅ 2026-08-17: reiner CAP** — Uplink `ether1` (PoE) an crs326-branch `ether24`; ch44/ch11 (TP25: ch149 war unter ETSI leistungsbegrenzt) · MAC D0:EA:11:4D:40:3A · Config `routeros/.secrets/ap2-prov-base.rsc` |
+| hAP ax² #2 (ap2) | **10.40.99.12** (VLAN99) · Identity `ap2` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP2_*`) · REST `http://10.40.99.12/rest` · MikroMCP `ap2` · **TP28 ✅ 2026-08-17: reiner CAP** — Uplink `ether1` (PoE) an crs326-branch `ether24`; ch44/ch11 (TP25: ch149 war unter ETSI leistungsbegrenzt) · MAC D0:EA:11:4D:40:3A · Config `routeros/.secrets/ap2-prov-base.rsc` |
-| **cAP ax (ap3)** | **10.40.99.13** (VLAN99) · Identity `ap3` | ✅ **LIVE seit 2026-08-30** (TP28-Nachtrag) · `cAPGi-5HaxD2HaxD`, RouterOS **7.24.1** + RouterBOOT 7.24.1 (Flotte sonst 7.24 — Differenz bewusst, s. TP27) · reiner CAP, Manager `crs326-core` · Uplink `ether1` → **core `ether21`** (Trunk) · Kanäle **`5180/ax/Ce/I`** (5 GHz) + **`2437/ax`** (ch6) nach TP25-Plan · 🔴 **nur 2 Ethernet-Ports** (`ether1` PoE-in, `ether2` PoE-out, **kein** Bridge-Port) → `ap.extra_ports=[]` · `device-mode=basic` (scheduler/fetch/romon **erlaubt**, anders als ap1/ap2) · Dateien `routeros/tp28-ap3-phase{1,2}-*.rsc` + `-service-accounts.rsc` + `-werksreste.rsc` |
+| **cAP ax (ap3)** | **10.40.99.13** (VLAN99) · Identity `ap3` | ✅ **LIVE seit 2026-08-30** (TP28-Nachtrag) · `cAPGi-5HaxD2HaxD`, RouterOS **7.24.1** + RouterBOOT 7.24.1 (**seit 2026-08-31 ist die ganze Flotte auf 7.24.1**, TP27-Angleichung erledigt) · reiner CAP, Manager `crs326-core` · Uplink `ether1` → **core `ether21`** (Trunk) · Kanäle **`5180/ax/Ce/I`** (5 GHz) + **`2437/ax`** (ch6) nach TP25-Plan · 🔴 **nur 2 Ethernet-Ports** (`ether1` PoE-in, `ether2` PoE-out, **kein** Bridge-Port) → `ap.extra_ports=[]` · `device-mode=basic` (scheduler/fetch/romon **erlaubt**, anders als ap1/ap2) · Dateien `routeros/tp28-ap3-phase{1,2}-*.rsc` + `-service-accounts.rsc` + `-werksreste.rsc` |
 | **🔑 Einheitliches Admin-PW (2026-08-08)** | alle 4 MikroTik (core/branch/ap1/ap2) | user `admin`, gleiches PW (`~/.secrets/credentials.env` → `ROUTER_*_PASS`/`CRS326_*_PASS`; „Überlebensversicherung", User-Vorgabe). Werks-Defaults ap1/ap2 damit obsolet. |
 | NAS (nas-bf, DS923) | 10.40.20.10 | SSH `adm.christoph@10.40.20.10` (kein PW nötig) · Docker (Portainer endpointId=14) |
 | platform-pg (LXC 105, pve) | 10.40.20.20 | SSH via pve (`pct exec 105 --`) · **TP20 ✅ 2026-07-16: PG16, DB `nautobot`, Creds `postgres/.secrets`** |
@@ -127,6 +129,21 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
   **rückwirkend nicht diagnostizierbar**. `/system logging` steht jetzt unter der 27. ComplianceRule
   `system-logging` — vorher unter keiner. **Merkregel: bevor man ein sporadisches Problem sucht,
   erst prüfen, ob es überhaupt irgendwo mitgeschrieben wird.**
+- 🧮 **Ein Log-Burst über VIELE MACs ist Infrastruktur, über EINE MAC ein Client** (Fund 2026-08-31).
+  Am 31.08. sahen 13 × `caps,info … joined`, 4 × `activity timeout` und zwei Massenbursts
+  `association rejected, no cached PMK` (74 Zeilen, **38 verschiedene MACs**) wie eine CAPWAP-
+  Instabilität aus, die das ganze Netz trifft. Es waren die **Reboots des TP27-Upgrades**. Jedes
+  Ereignis fiel auf einen Neustart. 🔴 **Vor jeder Client-Diagnose erst `grep " caps,"` und
+  `/system resource get uptime` lesen** — sonst sucht man einen Gerätefehler, der ein geplanter
+  Reboot war. Der Umkehrschluss gilt auch: 93 von 93 `reauthenticating` von **einer** MAC auf
+  **einer** SSID sind ein echter Client-/SSID-Befund.
+- 🗺️ **Die `cap-wifiN`-Karte verschiebt sich bei JEDEM CAP-Rejoin, nicht nur beim Provisionieren.**
+  Am 2026-08-31 wanderte sie zweimal an einem Tag (08:09 Re-Provisionierung, 14:36 Core-Reboot);
+  eine im Handoff festgehaltene Tabelle war nach sechs Stunden falsch. ⇒ **Interface-Namen in
+  Logzeilen sind ohne einen zeitnahen Karten-Snapshot NICHT zuschreibbar.** Vor jeder Auswertung
+  `/interface wifi radio print terse proplist=cap,radio-mac,interface` am Manager lesen — und wenn
+  zwischen Ereignis und Auswertung ein Rejoin liegt, die Zuordnung als **unbekannt** behandeln
+  statt zu raten.
 - 🔑 **CAPsMAN verteilt KEINE Login-Passwörter — nur WLAN-PSKs.** Zwei verschiedene Dinge heißen
   „Passwort": die **WPA-Passphrase** (`/interface wifi security`) liegt am Manager und wird an die
   CAPs verteilt ✅; der **Geräte-Login** (`/user`) ist eine **lokale Benutzer-DB auf jedem Gerät** ❌.
@@ -272,6 +289,18 @@ Verhaltensregeln für nachfolgende AI-Sessions — kleiner, klarer, weniger Drif
 - **Manuell gepflegte Doku mit Live-Daten verliert gegen die Realität, wenn sie lang wird.** Befund 2026-08-28: der „Nächster Schritt (2026-08-26): TP31 Schritt 5"-Satz stand zwei Tage nach seiner Formulierung noch im Ist-Stand-Block, obwohl ich in derselben Zeit drei Folge-Sessions eröffnet hatte. **Merkregel pro Edit:** drei Stellen berücksichtigen — Quick-Index (Tabelle), TP-Abschnitt, Ist-Stand-Block. Keine schlägt die andere; wer eine ändert, **muss** die anderen mitlesen. Strukturelle Antwort = TP36 (SSoT via Nautobot, Datei wird read-only Snapshot) — eigene Session, nicht nebenbei. **Lessons-Block erweitert 2026-08-28 nach Skill-Verifikation in opencode.**
 - **`sed 's/=.*/=<set>/'` maskiert NICHT, wenn das `.*` greedy ist und der Wert Slashes/Backslashes enthält** (Befund 2026-08-28, shelly-mcp-Deploy). Ich habe `sed 's/SHELLY_DEVICE_PW=.*/<set>/'` auf die Stack-YML angewendet — der **Wert selbst** wurde in den Output geschrieben, weil mein Replacement-String nicht greedy genug war und ich die Pipe nicht mit `cat -v` oder `head -15 | sed 's|=.*|=<set>|'` abgesichert hatte. Folge: **`SHELLY_DEVICE_PW` ist jetzt als verbrannt zu betrachten** — wandert in **TP30 Posten #3** mit Hochstufung. **Merkregel:** bei jeder Ausgabe von Secret-haltigen Dateien entweder `head -c <n>` (Abbruch nach Bytes), oder die Datei vor dem Read mit `tr -d '\n' | sed 's|=.*|=<set>|'` über einen Stream-Filter schicken — **niemals** einfach `cat` und auf einen Replacement-Pattern vertrauen. Vergleichbar zum PSK-Leak 2026-08-24.
 
+- **Vor jeder Drift-Bewertung `python3 nautobot/gc-transaktion.py status` lesen** (Befund 2026-08-31,
+  zweimal am selben Tag gestolpert). **Drift aus einem laufenden Versuch sieht identisch aus wie ein
+  Versehen** — die Compliance-Zahl unterscheidet nicht. Konkret: `crs326-core`/`wifi-security`
+  (`ft-over-ds=no`) wurde dem 7.24.1-Upgrade zugeschrieben und als „braucht eine Entscheidung"
+  weitergereicht; tatsächlich ist es **TP25 Fund E Hebel 1**, um 08:09 bewusst gesetzt, während der
+  Core erst um 14:36 gehoben wurde, geführt als offene Transaktion `TP25-fund-e-ft-over-ds`.
+  🔴 **Eine solche Drift grün zu machen macht den Versuch unsichtbar.** Umgekehrt gilt: was **dauerhaft**
+  gelten soll (z.B. das `veth`/`masquerade` aus TP16.3 §3.4), gehört **nicht** in eine Transaktion,
+  sondern ins **Soll** — Transaktion = befristeter Versuch, Template = Dauerzustand.
+  ⚠️ Das Skript löst den Token-Pfad gegen die Repo-Wurzel auf und findet ihn **aus einem Worktree
+  heraus nicht** (`210-nautobot.yml` liegt nur im Haupt-Checkout) — die Transaktionsliste kommt
+  trotzdem, nur die Compliance-Spalte fehlt dann.
 - **Maskierungs-Muster auf den SCHLÜSSELNAMEN ankern, nie auf ein Trennzeichen** (Befund 2026-08-31,
   zweiter Fall dieser Klasse nach `SHELLY_DEVICE_PW`). `grep -n "TOKEN" datei | sed 's/:.*TOKEN/…/'`
   maskiert **nicht**: `grep -n` stellt `<zeile>:` voran, und das `:.*TOKEN` matcht diesen Präfix statt

docs/handoff-20260831-tp16.3-paragraph2-3-durch.md

@@ -33,12 +33,18 @@ Nach vollem Refresh (Backup → Intended → Compliance, **nicht** die stale Zah
 |---|---|---|
 | ap1 / ap2 / ap3 | `ip-address` | `/ip address add address=172.17.0.1/24 interface=veth-cf` |
 | ap1 / ap2 / ap3 | `ip-firewall-nat` | `masquerade`, Kommentar `TP31: cloudflared egress` |
-| crs326-core | `wifi-security` | `ft-over-ds` — **die bekannte, unverändert** |
+| crs326-core | `wifi-security` | `ft-over-ds` — **offene Transaktion `TP25-fund-e-ft-over-ds`**, kein Versehen |
 
 **Ursache ist ein Widerspruch zwischen zwei Dokumenten**, kein Ausrutscher: Runbook §3.4 schreibt
 Direkt-Writes für `veth`/`ip address`/`nat` vor, die Governance stellt `/ip address` und
 `/ip firewall` unter GC-Pflicht. Ich bin dem Runbook gefolgt.
 
+⚠️ **Korrektur 2026-08-31 (nachgetragen):** die siebte Drift wurde hier zuerst dem 7.24.1-Upgrade
+zugeschrieben — falsch. `gc-transaktion.py status` führt **`TP25-fund-e-ft-over-ds` als OFFEN**
+(gesetzt 08:09, Core-Upgrade erst 14:36). Sie ist Absicht einer laufenden Messung und braucht **keine**
+Entscheidung. **Merkregel: vor jeder Drift-Bewertung `gc-transaktion.py status` lesen** — Drift aus
+einem laufenden Versuch sieht identisch aus wie ein Versehen.
+
 **Die sechs Drifts sind inhaltlich richtig** — die Config *soll* dort stehen, ohne sie läuft kein
 Container. Der saubere Weg ist, sie ins **Soll** zu heben (AP-Template bzw. ConfigContext
 `ap-common`), damit die Compliance sie als konform sieht.

docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md

@@ -0,0 +1,162 @@
+# Handoff 2026-08-31 nachmittags — TP27 durchgezogen, Hebel 1 gescheitert, Fund B entwarnt
+
+> Vorgänger: [`handoff-20260831-fund-e-hebel1-gezogen.md`](handoff-20260831-fund-e-hebel1-gezogen.md)
+> (Eingriff + Abnahme). **Dieses Dokument ist der Stand danach** und löst ihn als aktuellen Zeiger ab.
+> Anlass war eine Nutzermeldung, nicht ein geplanter Messtermin.
+
+## Ausgangspunkt: zwei erlebte Störungen mit Uhrzeit
+
+Christoph hat zwei Vorfälle gemeldet und dazu — entscheidend — **Standort und Bewegung**:
+
+| Zeit | Situation | Was er sah |
+|---|---|---|
+| **13:16** | Terrasse, Telefon in der Halterung, **unbewegt** | Telegram-Videocall bricht ab, „schwaches Signal", danach 5G |
+| **14:23** | Arbeitszimmer, kurz zuvor gewechselt, **unbewegt** am Schreibtisch | iPhone auf 5G, scannt dauernd, `-main` sichtbar, Verbinden schlägt fehl. **Behoben durch WLAN aus/ein.** |
+
+Beide stehen im Kollektor, beide mit derselben Signatur — **Reauth-Schwall, dann ein Loch:**
+
+```
+13:08:37–13:08:42   10 × reauthenticating      13:09:12  weg, −77
+   → 7 Minuten kein WLAN                        ← der Call-Abbruch
+14:17:47–14:18:07    4 × reauthenticating      14:18:29  weg, −72
+   → 5,5 Minuten kein WLAN                      ← „scannt, verbindet nicht"
+14:23:54  connected, −71                        ← der WLAN-Toggle
+14:23:57–14:28:47   70 × reauthenticating auf dem anderen Radio
+```
+
+**Der Toggle hat also nicht „reparariert", sondern eine Assoziation erzwungen** — das Hämmern lief
+danach auf dem zweiten Radio noch fünf Minuten weiter.
+
+## 🔴 Ergebnis: Hebel 1 (`ft-over-ds=no`) hat NICHT gegriffen
+
+Der Hebel wurde um **08:09** gezogen. Beide Vorfälle liegen **danach**.
+
+| Fenster | `reauthenticating` |
+|---|---|
+| 07:00–08:00 (**vor** dem Hebel) | **79** |
+| 14:00–15:00 (**nach** dem Hebel) | **70** |
+| gesamt nach 08:09 bis 14:36 | **124** |
+
+Vergleichbare Tagesstunden, praktisch unveränderte Rate, dazu zwei erlebte Ausfälle. Das
+Erfolgskriterium des Vorgänger-Handoffs lautete „geht auf ~0 zurück" — **nicht eingetreten.**
+
+⚠️ **Gewertet wird bewusst nur das Fenster 08:09–14:36** (6,5 h auf unveränderter Firmware).
+Ab 14:36 kommt eine zweite Variable dazu, s. u. — Christoph-Entscheid 2026-08-31: „Vormittag als
+Ergebnis werten". Das ist keine 24-h-Messung, aber für ein **Negativ**-Ergebnis mit zwei erlebten
+Ausfällen belastbar.
+
+## ✅ TP27 ist durchgezogen — die Flotte steht komplett auf 7.24.1
+
+Von Christoph selbst, über WebFig vom MacBook (`10.40.10.82`), rollierend über den Tag:
+
+| Gerät | Version | Reboot ca. |
+|---|---|---|
+| ap3 | 7.24.1 | gestern (kam schon so) |
+| ap2 | 7.24.1 | **08:56** |
+| crs326-core | 7.24.1 | **14:36** |
+| ap1 | 7.24.1 | **14:50** |
+| crs326-branch | 7.24.1 | **14:52** |
+
+Die Doku-Zeile „Flotte auf 7.24, ap3 auf 7.24.1 — Differenz bewusst" ist damit **überholt**;
+die Angleichung, die als eigener TP27-Durchgang vorgemerkt war, ist erledigt.
+
+**Zustand nach dem Upgrade, live geprüft (15:1x):**
+
+| Prüfung | Ergebnis |
+|---|---|
+| CAPs | 3 × `state=Ok`, alle 7.24.1 |
+| Provisionierung | 4 Regeln (ap2 5G/2,4G, ap3 5G/2,4G) unverändert; ap1 bewusst ohne |
+| VAPs am CAP gelesen | ap2: 9 × `running=yes` |
+| Clients | 30 |
+| Transaktion überlebt? | `sec-main`: `ft=yes ft-over-ds=no` ✓ |
+| Core-Ressourcen | 435 MiB frei, CPU 8 % |
+
+## ✅ Fund B (vermeintliche CAPWAP-Instabilität) ist ENTWARNT
+
+Beim Nachsehen fielen 13 × `joined`, 4 × `activity timeout`, 3 × `connection interrupted` auf —
+das sah nach einem Manager-CAP-Problem aus, das alle Clients trifft. **Es war das Upgrade.**
+Jedes Ereignis fällt auf einen Reboot aus der Tabelle oben. Die Massenbursts
+`association rejected, no cached PMK` (74 Zeilen, 38 verschiedene MACs, um 08:08 und 14:33)
+sind Re-Provisionierungen, kein Defekt.
+
+🔴 **Merkregel daraus:** ein Burst über **viele** MACs ist ein Infrastruktur-Ereignis, ein Burst über
+**eine** MAC ein Client-Ereignis. Vor jeder Client-Diagnose erst `grep " caps,"` und `uptime` lesen —
+sonst sucht man einen Gerätefehler, der ein geplanter Reboot war.
+
+## Neue Beobachtungen, die in der Auswertung morgen gebraucht werden
+
+**1. Die Logzeile `association rejected, no cached PMK` ist neu** — 157 × am 31.08., **null** am
+30.08. Sie benennt die PMK-Caching-Achse ausdrücklich. Der überwiegende Teil sind Reboot-Folgen
+(s. o.), aber nicht alle.
+
+**2. Die `cap-wifiN`-Karte hat sich seit 08:09 ERNEUT verschoben.** Die Tabelle im Vorgänger-Handoff
+ist bereits wieder falsch:
+
+| | Handoff-Stand 08:09 | **live 15:1x** |
+|---|---|---|
+| ap1 | `cap-wifi1` / `cap-wifi2` | `cap-wifi1` / `cap-wifi2` |
+| ap2 | `cap-wifi3` / `cap-wifi5` | **`cap-wifi5` / `cap-wifi6`** |
+| ap3 | `cap-wifi4` / `cap-wifi6` | **`cap-wifi3` / `cap-wifi4`** |
+
+⇒ Die Karte verschiebt sich bei **jedem** CAP-Rejoin, nicht nur beim Re-Provisionieren. Bei fünf
+Reboots an einem Tag heißt das: **Interface-Namen in Logzeilen sind ohne Zeitstempel-nahen
+Karten-Snapshot nicht zuschreibbar.** Wer die Vormittagszeilen mit der jetzigen Karte liest, ordnet
+falsch zu. *(Strukturelle Antwort wäre ein stündlicher Karten-Snapshot ins Log — der Core ist
+**kein** `device-mode=home`, Scheduler ist dort erlaubt. Nicht gebaut, nur vorgeschlagen.)*
+
+**3. Sticky-Verdacht, teilweise belegt.** Um 14:23 unbewegt am Schreibtisch **−72 dBm**, um 14:38 am
+selben Platz **−49 dBm**. Die Pegeldifferenz ist ein Faktum; **welcher** AP jeweils dahinterstand,
+ist wegen (2) nicht mehr rekonstruierbar. Über den Tag zeigt jedes Interface dieselbe Spannweite
+(−91…−47) — das Telefon hängt regelmäßig auf −85…−91, obwohl −47 möglich wäre.
+
+**4. `docs/wifi-p750w-coverage-and-map.md` ist als Beleg unbrauchbar.** Die Datei ist vom
+**2026-07-02** — vor CAPsMAN-Cutover, vor ap2s Umzug nach oben, vor ap3. Ihre Aussage „Terrasse
+grenzwertig −76…−89 dBm" beschreibt ein Netz, das es nicht mehr gibt. Christophs Einschätzung
+(„seit ap2 nach oben hat die Terrasse faire Coverage") ist die jüngere Information. **In dieser
+Session hat die veraltete Zeile beinahe dazu geführt, den 13:16-Vorfall als „erwartbar" abzutun.**
+
+**5. Erste ruhige Phase des Tages — unbewertet.** Zwischen dem Core-Reboot (14:37) und 15:12 steht
+**1** `reauthenticating` im Log, **keines vom iPhone**. 35 Minuten sind keine Aussage, und das
+iPhone lag zuletzt bei −49…−52 dBm. **Nicht als Erfolg verbuchen** — aber morgen früh gezielt
+prüfen, ob 7.24.1 auf dem Manager etwas verändert hat.
+
+## Entscheidungslage für die nächste Session
+
+Hebel 1 ist gescheitert. `sec-main` unterscheidet sich von den fünf ereignislosen SSIDs in **zwei**
+Attributen (bereits im Vorgänger korrigiert):
+
+```
+sec-main    authentication-types=wpa3-psk            ft=yes  ft-over-ds=no   ← 93/93 Ereignisse
+sec-infra…  authentication-types=wpa2-psk,wpa3-psk   ft=no                   ← null Ereignisse
+```
+
+| Option | Dafür | Dagegen |
+|---|---|---|
+| **Hebel 2 `ft=no`** | folgt der beschlossenen Reihenfolge, isoliert die FT-Achse sauber | bleibt WPA3-only; wenn das die Ursache ist, ändert sich nichts |
+| **`wpa2-psk,wpa3-psk`** | `no cached PMK` ist eine SAE/PMKSA-Meldung; iOS + WPA3-only + PMK-Caching ist ein bekanntes Problemfeld; bringt `main` exakt auf den Stand der ruhigen SSIDs | ändert das zweite Attribut, nicht das aus dem Plan |
+| **beides** | höchste Chance auf Ruhe | hinterher weiß niemand, welches gewirkt hat |
+
+**Vor der Entscheidung zuerst prüfen:** ob 7.24.1 auf dem Manager das Verhalten schon verändert hat
+(Punkt 5). Ein Hebel, der auf ein bereits gelöstes Problem gezogen wird, verbrennt einen Messtag.
+
+⚠️ Die Transaktion **`TP25-fund-e-ft-over-ds` bleibt offen** (Ablauf 2026-09-03), Compliance steht
+deshalb weiter absichtlich auf **134/135**. Rollback oder Commit ist eine bewusste Entscheidung,
+kein Aufräumen.
+
+## Messrezept (unverändert gültig)
+
+```bash
+ssh root@10.40.20.100 "pct exec 400 -- sh -c '
+  grep -c reauthenticating /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log;
+  grep -c \" caps,\" /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log'"
+```
+Erste Zahl = Fund A. Zweite Zahl = Reboots/Rejoins; steht sie über 0, **erst dort nachsehen**,
+bevor die erste Zahl gedeutet wird.
+
+## Unverändert offen
+
+1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — **Terrasse und Arbeitszimmer**, um die
+   Sticky-Frage aus Punkt 3 zu entscheiden. `ap-map` dabei neu einfrieren.
+2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt; fehlende `MCP_MIKROMCP_*_PASS`).
+3. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste**, `tx-power` vorher messen).
+4. Karten-Snapshot ins Log automatisieren (Vorschlag aus Punkt 2, nicht gebaut).

docs/teilprojekte.md

@@ -89,9 +89,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   Vor-Ort-Session** (§2/§3: `container.npk`, `device-mode`, Container) und danach Flip + Abbau.
 - 🆕 **Globale Verhaltensregeln konsolidiert (2026-08-29, TP35 Schicht 3):** `~/.config/opencode/AGENTS.md` ist jetzt die **SSoT** für globale Verhaltensregeln (Secrets, VLAN-Schema, 5 Lessons, SoC, Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis, Backup-Guard). `~/.claude/CLAUDE.md` hält denselben Block als Claude-Code-Spiegelung mit Verweis auf die SSoT. opencode liest AGENTS.md mit Vorrang vor `~/.claude/CLAUDE.md`.
 
-- **Fünf MikroTik, alle auf RouterOS `7.24.1`** (User-Upgrade 2026-08-31, live gegengelesen;
+- **Alle fünf MikroTik laufen auf RouterOS `7.24.1`** (🆕 **Angleichung am 2026-08-31 von Christoph
-  RouterBOOT jeweils = `upgrade-firmware` = `7.24.1`). Neu dabei **`ap3`** (cAP ax `cAPGi-5HaxD2HaxD`,
+  selbst durchgezogen, TP27 damit erledigt** — ap2 08:56, core 14:36, ap1 14:50, branch 14:52;
-  **`10.40.99.13`**, Uplink core `ether21`).
+  ap3 kam bereits so. RouterBOOT jeweils = `upgrade-firmware` = `7.24.1`, live gegengelesen).
+  Vorher: vier auf 7.24 (08-17), nur ap3 auf 7.24.1. Neu in der Flotte **`ap3`**
+  (cAP ax `cAPGi-5HaxD2HaxD`, **`10.40.99.13`**, Uplink core `ether21`).
   ✅ **Folge für TP16.3:** die versionsgebundene `container.npk` ist damit **eine** Datei für alle drei
   APs (alle `arm64`) — die Zwei-Dateien-Regel vom 08-30 war rein versionsbedingt und ist erledigt.
   *(Hier stand bis 08-29 „Alle vier MikroTik … 7.24" — durch ap3 und das Upgrade zweifach überholt.)*
@@ -112,7 +114,7 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
   🆕 **Dritter AP `ap3` (cAP ax) ✅ LIVE seit 2026-08-30** (TP28 dafür wieder geöffnet):
   `10.40.99.13`, Uplink `ether1` → **core `ether21`** (Trunk), reiner CAP, **RouterOS 7.24.1**
-  (die anderen vier auf 7.24 — Angleichung ist ein eigener TP27-Durchgang). Kanäle
+  (🆕 **seit 2026-08-31 die ganze Flotte** — die frühere Versionsdifferenz ist aufgelöst). Kanäle
   **`5180/ax/Ce/I`** + **`2437/ax`** (ch6) nach dem TP25-Plan vom 2026-08-24, am Gerät nachgemessen.
   🔴 **ap1 ist funkstill** — es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und würde
   auf 5180 kollidieren; es hat deshalb bewusst **keine Provisioning-Regel** am Manager, bleibt aber
@@ -157,16 +159,27 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
   `system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
   nicht diagnostizierbar.
-- 🔬 **TP25 Fund E — Hebel 1 läuft seit 2026-08-31 08:09 (LAUFENDER VERSUCH, nicht Endstand):**
+- 🔴 **TP25 Fund E — Hebel 1 ist GESCHEITERT (Stand 2026-08-31 nachmittags):** `sec-main` steht am
-  `sec-main` steht am Core auf **`ft=yes ft-over-ds=no`** (vorher `yes/yes`). Belegt am Manager an
+  Core auf **`ft=yes ft-over-ds=no`** (seit 08:09), aber das Symptom blieb: **124× `reauthenticating`
-  allen vier aktiven Master-VAPs (`cap-wifi3/4/5/6`). Transaktion
+  nach dem Eingriff** und **zwei von Christoph erlebte Ausfälle** — 13:16 (Videocall bricht ab,
-  **`TP25-fund-e-ft-over-ds`** ist **OFFEN** (Scope `wifi-security`, Ablauf **2026-09-03**),
+  7 min ohne WLAN) und 14:23 (5,5 min, nur durch WLAN-Toggle beendet). Stundenvergleich auf
+  gleicher Firmware: **07:00–08:00 = 79 · 14:00–15:00 = 70**. Erfolgskriterium war „~0" ⇒ nicht
+  eingetreten. Gewertet wird bewusst nur **08:09–14:36** (danach kommt das TP27-Upgrade als zweite
+  Variable dazu; Christoph-Entscheid: „Vormittag als Ergebnis werten").
+  ⇒ Transaktion **`TP25-fund-e-ft-over-ds` bleibt OFFEN** (Ablauf **2026-09-03**), **Compliance
+  weiter bewusst 134/135**; Rollback oder Commit ist eine Entscheidung, kein Aufräumen.
   Geräte-Backup `pre-tp25-funde-ftoverds.backup` liegt auf dem Core.
-  ⇒ **Compliance steht deshalb bewusst auf 134/135** — der eine Drift ist genau dieser Versuch und
+  **Nächste Entscheidung:** Hebel 2 (`ft=no`) **oder** `authentication-types=wpa2-psk,wpa3-psk` —
-  wird von `gc-transaktion.py status` als *erwartet* ausgewiesen. **135/135 kommt beim COMMIT
+  `sec-main` ist auch die einzige SSID ohne `wpa2-psk`, und `association rejected, no cached PMK`
-  zurück**, nachdem 24 h gemessen sind und das Template nachgezogen ist; das Skript verweigert den
+  (157× am 31.08., 0× am 30.08.) ist eine SAE/PMKSA-Meldung. **Vorher prüfen, ob 7.24.1 auf dem
-  Commit ohnehin, solange der Scope driftet. Baseline zum Vergleich: **93× `reauthenticating`**,
+  Manager das Verhalten schon verändert hat** — zwischen 14:37 und 15:12 stand nur **1**
-  93/93 vom iPhone `F2:62:4C:E1:AF:09`, 93/93 auf `dirtyvader-main`.
+  `reauthenticating` im Log, keines vom iPhone (35 min = noch keine Aussage).
+  Details: [`handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](handoff-20260831-tp27-upgrade-und-hebel1-befund.md).
+- ⚠️ **Messfalle, die diese Session fast erwischt hat:** die 13 CAP-`joined`/`activity timeout` vom
+  31.08. sahen nach CAPWAP-Instabilität aus — es waren die **Reboots des TP27-Upgrades**. Und die
+  **`cap-wifiN`-Karte hat sich an einem Tag zweimal verschoben** (08:09, 14:36), womit die im
+  Vorgänger-Handoff festgehaltene Tabelle nach sechs Stunden falsch war. Interface-Namen in
+  Logzeilen sind ohne zeitnahen Karten-Snapshot **nicht zuschreibbar**.
 - **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 5 Geräte in der Registry),
   **Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
   **135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30;
@@ -1820,8 +1833,8 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört
   `vlan99`, Flotten-PW) über das Kabel, Phase 2 (Werks-WLAN weg, CAP-Modus,
   `slaves-datapath`, `vlan-filtering=yes`) über `vlan99`.
 - ✅ **RouterOS 7.20.8 → 7.24.1 + RouterBOOT 7.24.1** (zwei Reboots, TP27-Kriterium
-  `current-firmware = upgrade-firmware`). ⚠️ Die anderen vier stehen auf **7.24**; die
+  `current-firmware = upgrade-firmware`). 🆕 **Die Angleichung der übrigen vier ist am
-  Angleichung auf 7.24.1 ist ein eigener TP27-Durchgang (Core-Reboot = Standort-Ausfall).
+  2026-08-31 erfolgt** (Christoph, WebFig) — die Flotte ist einheitlich, TP27 erledigt.
 - ✅ **ap1 funkstill** (Provisioning-Regeln entfernt + `remote-cap provision`), gegengeprüft
   **am CAP**: nur noch `wifi1`/`wifi2` mit `running=false`, keine dynamischen VAPs.
 - ✅ **ap3 funkt**: `cap-wifi5` = **`5180/ax/Ce/I`**, `cap-wifi6` = **`2437/ax`**, voller

docs/tp16.3-paragraph5-session-handoff-prompt.md

@@ -36,6 +36,9 @@ sie stehen nicht im Soll, weil Runbook §3.4 Direkt-Writes vorschreibt für Feat
 Golden-Config-Kontrolle stehen.
 
 Der saubere Weg ist, sie ins **Soll** zu heben (AP-Template bzw. ConfigContext `ap-common`).
+🔑 **Bewusst KEINE Transaktion:** `gc-transaktion.py` ist für **befristete Versuche** da (so wie
+`TP25-fund-e-ft-over-ds`). Das `veth`/`masquerade` soll **dauerhaft** gelten — Dauerzustand gehört
+ins Template, nicht in eine Transaktion mit Ablaufdatum.
 🔴 **Kein Re-Baseline** (macht die Drift-Erkennung wertlos), **kein Rückbau** (killt die Tunnel).
 ⚠️ Dabei mitentscheiden, ob `/interface veth` überhaupt erfasst sein soll — dafür existiert heute
 keine ComplianceRule, deshalb erzeugt `veth` auch keine Drift.
@@ -43,8 +46,14 @@ keine ComplianceRule, deshalb erzeugt `veth` auch keine Drift.
 Mit ungeklärter Drift in den Produktivpfad zu gehen ist die eine Sache, die diese Session
 **nicht** tun sollte. Christoph entscheidet, nicht die Session.
 
-*(Die siebte Drift, `crs326-core` / `wifi-security` / `ft-over-ds`, ist die bekannte aus dem
+🔴 **Die siebte Drift ist KEINE Drift im Sinne eines Versehens:** `crs326-core` / `wifi-security`
-7.24.1-Upgrade und gehört weiterhin nicht in diese Session.)*
+(`ft-over-ds=no`) ist **TP25 Fund E, Hebel 1** — am 2026-08-31 um 08:09 bewusst gesetzt und als
+**offene Transaktion `TP25-fund-e-ft-over-ds`** geführt (Scope `wifi-security`, Ablauf 2026-09-03).
+Sie gehört einer anderen, laufenden Session; **grün machen würde deren Versuch unsichtbar machen.**
+⚠️ **Merkregel:** vor jeder Drift-Bewertung `python3 nautobot/gc-transaktion.py status` lesen.
+Drift aus einem laufenden Versuch sieht identisch aus wie ein Versehen — genau dafür gibt es das
+Werkzeug. (Diese Zeile behauptete zuerst, die Drift käme vom 7.24.1-Upgrade. Falsch: der Core wurde
+erst um 14:36 gehoben, sechseinhalb Stunden nach dem Hebel.)*
 
 ## REIHENFOLGE
 
@@ -89,8 +98,8 @@ zuletzt. Nach **jedem** Namen die Abnahme aus §5.3, erst dann der nächste.
 
 1. **Rotation zweier Nautobot-Tokens** (`NAUTOBOT_SUPERUSER_API_TOKEN`, `NAUTOBOT_GITEA_TOKEN`) —
    in der Vorsession ins Transkript geraten, als verbrannt zu behandeln. Gehört zu **TP30**.
-2. **`crs326-core` / `wifi-security` / `ft-over-ds`** — bekannte Drift, braucht eigenen Entscheid
+2. **`crs326-core` / `wifi-security` / `ft-over-ds`** — offene Transaktion `TP25-fund-e-ft-over-ds`
-   plus CAP-Re-Provisionierung.
+   einer laufenden TP25-Session. **Nicht anfassen, nicht grün machen**, Ablauf 2026-09-03.
 3. **`mcp/mikromcp/config/routers.yaml`** meldet `rosVersion: "7.24"` für alle fünf, live ist
    `7.24.1` — kosmetisch, gehört auf `main`.
 4. **§6 Abbau** (sechs Container, drei Alttunnel) — frühestens 7 Tage nach dem Flip.

mcp/mikromcp/config/routers.yaml

@@ -10,7 +10,8 @@
 # 2026-08-30 (TP28-Nachtrag): ap3 (cAP ax, .99.13) aufgenommen, Uplink core ether21.
 #   Diese Datei ist seit 2026-08-30 die EINZIGE gelesene Registry: MIKROMCP_CONFIG_PATH
 #   zeigte bis dahin auf ~/dev/bf-network-r6 (Archiv-Repo) -- Aenderungen hier waren
-#   wirkungslos. rosVersion war auf allen Eintraegen stale (7.23/7.19.5), live ist 7.24.
+#   wirkungslos. rosVersion war auf allen Eintraegen stale (7.23/7.19.5).
+# 2026-08-31 (TP27): Flotte einheitlich auf 7.24.1 gehoben -- alle fuenf Eintraege nachgezogen.
 #   ap1/ap2 (.99.11/.99.12) = Zielwerte — ap1 ist derzeit Werksreset/getrennt und kommt
 #   erst mit der WLAN-Neuprovisionierung (eigene Session) zurück.
 
@@ -25,7 +26,7 @@ routers:
       source: "env"
       envPrefix: "ROUTER_AP1"
     tags: ["bf", "wifi", "access-point"]
-    rosVersion: "7.24"
+    rosVersion: "7.24.1"
 
   ap2:
     host: "10.40.99.12"
@@ -37,7 +38,7 @@ routers:
       source: "env"
       envPrefix: "ROUTER_AP2"
     tags: ["bf", "wifi", "access-point"]
-    rosVersion: "7.24"
+    rosVersion: "7.24.1"
 
   crs326-core:
     host: "10.40.99.1"
@@ -49,7 +50,7 @@ routers:
       source: "env"
       envPrefix: "CRS326_CORE"
     tags: ["bf", "switch", "core", "l3-router"]
-    rosVersion: "7.24"
+    rosVersion: "7.24.1"
 
   crs326-branch:
     host: "10.40.99.2"
@@ -61,7 +62,7 @@ routers:
       source: "env"
       envPrefix: "CRS326_BRANCH"
     tags: ["bf", "switch", "branch"]
-    rosVersion: "7.24"
+    rosVersion: "7.24.1"
 
   ap3:
     host: "10.40.99.13"
@@ -73,4 +74,4 @@ routers:
       source: "env"
       envPrefix: "ROUTER_AP3"
     tags: ["bf", "wifi", "access-point"]
-    rosVersion: "7.24"
+    rosVersion: "7.24.1"