diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index b231d14..ca58a2f 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -1364,6 +1364,41 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > zurückgebaut haben. Der Sticky-Client-Defekt ist damit **platzierungsunabhängig**.
 > ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach
 > dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos.
+> 🔴🔴 **2026-08-22, Werkzeug-Fund mit Rückwirkung auf ALLE bisherigen Messungen: die
+> `cap-wifiN`-Nummern sind NICHT stabil.** Der Manager vergibt sie dynamisch in der
+> Reihenfolge, in der sich die CAPs anmelden — nach dem ap1-Rückbau auf `ether15` sind heute
+> `cap-wifi1/2` = **ap2** und `cap-wifi3/4` = **ap1**, also genau umgekehrt zu der festen
+> Tabelle, die in `tp6-marker/server.py` und `tp25-gehweg-auswertung.py` stand.
+> ⚠️ **Daraus folgt NICHT, dass die alten Auswertungen falsch sind** — der erste Verdacht in
+> diese Richtung war voreilig. Die Gegenprobe spricht dagegen: wendet man die *heutige* Karte
+> auf die Raumkarte vom 08-21 an, wird **Technik OG von ap1 mit −43 dBm versorgt** — in dem
+> Raum, in dem **ap2 steht**. Die alte Tabelle war zu ihrer Zeit also plausibel richtig und
+> ist erst durch das Umstecken falsch geworden.
+> ⇒ **Die Zuordnung gehört zum Messlauf, nicht zur Auswertungszeit.** `tp25-walk-messung.sh`
+> friert sie jetzt als `ap-map.txt` im Lauf ein; die Auswertung nimmt ausschließlich diese
+> Datei und lässt die Namen sonst roh (`cap-wifiN`) — unbeschriftet ist ehrlicher als falsch
+> beschriftet. **Läufe vor dem 2026-08-22 sind nicht rekonstruierbar**; wer ihre AP-Namen
+> zitiert, muss sie an der Physik prüfen (der AP im Raum liefert dort das stärkste Signal).
+>
+> 🆕 **Messaufbau neu gedacht (Christoph, 2026-08-22) — eine Runde statt zwei.** Das frei
+> roamende iPhone zeigt ohnehin, welchen AP ein normaler Client wählt; interessant ist der
+> **andere**. Das S22 wird deshalb per `access-list` automatisch auf den **Gegen-AP** des
+> iPhones gezwungen (`docs/tp25-pin-s22.sh`, Automatik in der Klick-Konsole auf Port 3031).
+> Pro Standort fallen so **zwei** Messpunkte an. Ein Doppelton meldet „beide angemeldet,
+> verschiedene APs" = weitergehen.
+> 🔴 **Die Falle dabei, live erlebt:** ein vom Pin **abgewiesener** Verbindungsversuch ist in
+> den Ping-Daten **nicht** von einem Funkloch zu unterscheiden, und der Manager protokolliert
+> ihn auf `info`-Ebene **gar nicht** (Beleg: zwischen `disconnected, access-list changed` und
+> dem manuellen Reconnect stehen vier Minuten ohne eine einzige Zeile). Android quittiert die
+> Abweisung mit „Verbindung fehlgeschlagen" und **wählt das Netz ab** — danach misst der Rest
+> des Rundgangs Stille. Die Konsole schlägt deshalb mit Ton, Vibration und Vollbanner Alarm,
+> sobald das gepinnte Gerät nirgends hängt, und schreibt nach 45 s vergeblicher Suche
+> `UNERREICHBAR=apX` — denn „der Gegen-AP trägt hier nicht" **ist das Messergebnis**.
+> ⏸️ **Stand bei Sitzungsende 2026-08-22: Rundgang noch nicht gegangen.** Pin gelöst,
+> Automatik aus, `crs326-core` unverändert (die `access-list` steht unter keiner
+> ComplianceRule, es gibt also nichts zu committen). Erster Messwert nebenbei: am Arbeitsplatz
+> iPhone **ap2 −68**, S22 auf ap1 gezwungen **−77…−78**; ohne Pin geht das S22 sofort auf
+> **ap2/5 GHz −71**.
 > 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
 > ✅ **Transaktion `TEST-ether3-trunk-ap1-sideboard` am 2026-08-22 zurückgerollt und geschlossen**
 > (Scope `bridge-vlan`) — `ether3` ist wieder untagged VLAN40, Compliance zurück auf 92/92.
diff --git a/docs/tp25-gehweg-auswertung.py b/docs/tp25-gehweg-auswertung.py
index 9bca311..a0b1f3f 100644
--- a/docs/tp25-gehweg-auswertung.py
+++ b/docs/tp25-gehweg-auswertung.py
@@ -15,6 +15,7 @@ import argparse
 import csv
 import os
 import re
+import sys
 import urllib.parse
 
 
@@ -23,8 +24,38 @@ def sec(t):
     return h * 3600 + m * 60 + s
 
 
-AP = {"cap-wifi1": "ap1/5GHz", "cap-wifi2": "ap1/2,4GHz",
-      "cap-wifi3": "ap2/5GHz", "cap-wifi4": "ap2/2,4GHz"}
+# 🔴🔴 Hier stand bis 2026-08-22 eine feste Tabelle -- mit VERTAUSCHTEN APs: cap-wifi1/2
+#     sind ap2, nicht ap1 (live belegt ueber cap=, configuration= und Kanal). Die Baender
+#     stimmten, die Identitaet nicht. Der Manager vergibt die cap-wifiN-Nummern DYNAMISCH in
+#     der Reihenfolge, in der sich die CAPs anmelden -- eine Konstante dazu ist nur bis zum
+#     naechsten AP-Reboot richtig und faellt danach still falsch aus.
+#
+#     ⚠️ OFFEN: ob die Messungen vom 2026-08-21 (Raumkarte, Sideboard-Test) mit vertauschten
+#     AP-Namen ausgewertet wurden, ist NICHT geprueft. Die Rohdaten sind unberuehrt -- es geht
+#     allein um die Beschriftung. Betroffen waere u.a. Fund F ("Schlafzimmer -61 ap1 -> -83
+#     ap2") und damit die Sideboard-Entscheidung. Vor dem Zitieren alter Zahlen klaeren.
+def ap_karte(run_dir):
+    """cap-wifiN -> apX/Band, aus der Karte DIESES Messlaufs (ap-map.txt).
+
+    🔴 Ausdruecklich NICHT live nachschlagen. Die Nummern gelten nur fuer den Zeitpunkt der
+       Messung; ein spaeter erzeugtes Mapping auf alte Daten anzuwenden ergibt eine
+       selbstbewusst falsche Antwort. Fehlt die Datei (alle Laeufe vor 2026-08-22), bleiben
+       die rohen cap-wifiN stehen -- unbeschriftet ist ehrlicher als falsch beschriftet.
+    """
+    pfad = os.path.join(run_dir, "ap-map.txt")
+    if os.path.exists(pfad):
+        with open(pfad) as fh:
+            return dict(z.strip().split("=", 1) for z in fh if "=" in z)
+    print("⚠️  Kein ap-map.txt in diesem Lauf -- AP-Namen bleiben roh (cap-wifiN).\n"
+          "    Fuer Laeufe vor 2026-08-22 ist die Zuordnung NICHT rekonstruierbar: sie haengt\n"
+          "    daran, in welcher Reihenfolge sich die CAPs damals angemeldet haben.\n"
+          "    Anhaltspunkt aus der Physik: der AP im Raum sollte dort das staerkste Signal\n"
+          "    liefern (ap2 steht in Technik OG, ap1 haengt an core ether15).",
+          file=sys.stderr)
+    return {}
+
+
+AP = {}
 
 
 def ros_ms(v):
@@ -40,6 +71,9 @@ def main():
     ap.add_argument("--dir", required=True)
     a = ap.parse_args()
 
+    global AP
+    AP = ap_karte(a.dir)
+
     pings = []
     csv_path = os.path.join(a.dir, "walk-ping.csv")
     if os.path.exists(csv_path):
diff --git a/docs/tp25-walk-messung.sh b/docs/tp25-walk-messung.sh
index e344dd6..de72364 100755
--- a/docs/tp25-walk-messung.sh
+++ b/docs/tp25-walk-messung.sh
@@ -34,6 +34,16 @@ mkdir -p "$RUN_DIR"
 # Auswertung auf, wenn die Raummarken fehlten.
 printf '%s\n' "$RUN_DIR" > "$HERE/docs/tp6-marker/.current-run"
 
+# 🔴 Die AP-Zuordnung JETZT einfrieren, im Messlauf. Die cap-wifiN-Nummern vergibt der
+#    Manager dynamisch beim Anmelden der CAPs -- sie aendern sich, sobald ein AP neu
+#    bootet oder umgesteckt wird. Wer sie erst bei der Auswertung nachschlaegt, beschriftet
+#    alte Daten mit einer neuen Wahrheit. Genau das waere am 2026-08-22 beinahe passiert:
+#    die Raumkarte vom 08-21 haette Technik OG dann ap1 zugeschrieben -- dem AP, der nicht
+#    in diesem Raum steht.
+bash "$HERE/docs/tp25-pin-s22.sh" map > "$RUN_DIR/ap-map.txt" 2>/dev/null \
+  && echo "AP-Zuordnung eingefroren -> $RUN_DIR/ap-map.txt" \
+  || echo "⚠️ AP-Zuordnung konnte nicht gelesen werden -- Auswertung bleibt bei cap-wifiN"
+
 # Frueheren Lauf beiseitelegen, statt ihn zu ueberschreiben.
 if [[ -f "$RUN_DIR/sampler.csv" ]]; then
   ARCHIV="$RUN_DIR/archiv-$(date +%H%M%S)"; mkdir -p "$ARCHIV"