bf-infra/docs/announcements.md

Announcements — bf-infra

Breaking News / Querschnitts-Änderungen, die jede folgende Session kennen muss, bevor sie losarbeitet — Dinge, die man sonst erst nach dem ersten Fehlschlag merkt. Kein Ersatz für die TP-Prosa (docs/teilprojekte.md) oder das Gitea-Board; hier steht nur, was quer zu den TPs gilt.

Format je Eintrag: Überschrift ## YYYY-MM-DD — <Titel>, dann die Zeilen Betrifft: (wer/was) und Aktion: (was eine Session konkret anders machen muss), optional ein, zwei Sätze Kontext. Neueste oben. Der Skill /news liest diese Datei und zeigt die Einträge, die seit dem letzten /news-Lauf dazugekommen sind (Rest auf Wunsch).

---

2026-10-12 — Airfryer „airschreier" ist FUSION/Cloud-only — lokale Anbindung endgültig tot

Betrifft: TP5.1 (Airfryer-Fall, DNS-Redirect + Live-Torch), die UNTRUSTED-Einordnung des Geräts (10.40.30.180, VLAN30) und jede Session, die den Airfryer als „Low-Trust-Gerät mit lokalem OTA-Problem" behandelt. Aktion: Die Begründung für den DHCP-Override dns 1.1.1.1 auf der Lease („OTA geht nicht über den DoH-Gateway-Pfad") ist erledigt — das Gerät hat die FUSION-Migration bereits vollzogen. Der Override kann abgebaut werden; danach greift wieder normale DNS-Policy/Filterung. Aber: Bei FUSION ist die Cloud-Verbindung die einzige Steuerungsroute — das Gerät darf nicht ins internetlose UNTRUSTED- VLAN (40) wandern, sonst ist es komplett unsteuerbar (auch aus HA). Der frühere UNTRUSTED-Move-Kandidat aus TP5.1 ist damit zurückzustellen, nicht umzusetzen.

Befund (aus HA verifiziert, 2026-10-12):

• Config-Entry philips_homeid, Titel „Airschreier 5000 Series XXL (Cloud)" — das (Cloud) im Titel ist die FUSION-Markierung der Integration (Cloud-Relay statt lokal).
• Firmware-Sensoren: NCP 1.1.14 / Host 0.5.6 → entspricht der dokumentierten FUSION-Liste (1.1.14/0.5.6; vgl. HD9285-Fälle 1.6.2/0.6.8, 1.1.8/0.5.6). Achtung: Die HomeID-App zeigt die Reihenfolge umgedreht an (0.5.6/1.1.14) — nicht als SPECTRE fehldeuten.
• Modellnummer-Sensor: HD9285 (SPECTRE wäre die lokale Variante, ist es aber nicht mehr).
• Lokaler Port 80/443 antwortet nicht (aus MAIN getestet); mDNS announce't aber weiter PHILIPS_HD9285_2_1FB281._http._tcp.local. → Port 80. Das Gerät läuft also, hat aber keine lokalen Credentials mehr.
• Kein Weg zurück: Laut Integrations-Doku ist die FUSION-Migration einwegig („There is no way back"), weil die Zuordnung cloud-seitig über externalDeviceId verankert ist. Firmware-Downgrade hilft nicht, Custom-Firmware existiert nicht (geschlossener ESP-Stack, signierter Bootloader).
• Steuerung funktioniert über die Cloud (Live-Werte plausibel: Kochstatus setting, 180 °C, fresh_fries; Buttons für Start/Pause/Stopp/Warmhalten vorhanden).
• Nebenbefund: dns 1.1.1.1 = anonymer Consumer-Resolver → DNS-Sicht weiter blind, Gerät umgeht die Filterung. Redet nachweislich mit Versuni → AWS eu-west-1 (IoT). Bleibt ein Beobachtungspunkt, aber ohne OTA-Rechtfertigung.

---

2026-10-03 — TP-Header tragen keinen Status mehr (SSoT-Drift geschlossen)

Betrifft: alle, die docs/teilprojekte.md oder teilprojekte-archiv.md lesen oder editieren, und alle, die ein TP anlegen/abschließen. Aktion: Die ### TPnn-Header haben die Form ### TP25 · Gitea #17 — <Titel> — <Caveat>. Der Status-Anspruch (▸ ✅ FERTIG (2026-09-15), ▸ ⏳ CUTOVER …) ist entfernt — er war eine dritte Statusquelle neben Issue und Prosa und lief den Labels nachweislich hinterher. Wer einen Status braucht, liest das status:*-Label im Gitea-Board, nicht den Datei-Kopf — · Gitea #N ist die Brücke. Status-Marker im Fließtext (Messchronik, └─-Zeilen) bleiben: sie beschreiben Historie, keinen Stand.

Dazu zwei Befunde, die dabei behoben wurden:

• TP47 existierte nur in der Datei, ohne Gitea-Issue (seit Commit 808d3a1, 2026-09-27) — jetzt #74. Das war ein echter SSoT-Bruch, kein fehlender Zeiger.
• bin/gitea-tp-sync.py schrieb in die falsche Richtung: der Abgleich leitete den Zielzustand aus dem Datei-Marker ab (fest ✅) und hätte #24 (TP34, bewusst status:dropped) auf status:done gezogen. Das Werkzeug schreibt jetzt nur noch fehlende Archiv-Issues neu und fasst bestehende nie an.

2026-09-12 — Golden-Config-Backups laufen jetzt täglich (vorher KEIN Scheduler)

Betrifft: alle, die sich auf GC-Backups/Compliance oder gc-snapshot.py-Werte verlassen. Aktion: Es gab nie einen automatischen GC-Backup-Zeitplan — Backup/Intended/Compliance liefen nur manuell aus Sessions (zuletzt 09-04 → 8 Tage Stillstand). Jetzt ScheduledJob „GC Backup+Compliance – taeglich" (Nautobot, Execute All GC Jobs - Multiple Device, platform=RouterOS, täglich 03:30 UTC, Reihenfolge Backup→Intended→Compliance). Wenn backup_last_success_date eines Geräts alt ist: zuerst prüfen, ob der ScheduledJob noch enabled ist (/api/extras/scheduled-jobs/), nicht das Gerät verdächtigen.

2026-09-12 — claude.json-Secrets laufen über {env:} (TP35 Schicht 2 ✅)

Betrifft: alle, die ~/.claude.json oder ~/.secrets/exports.zsh anfassen. Aktion: Keine Klartext-Secrets mehr in ~/.claude.json — MCP-Credentials referenzieren jetzt {env:MCP_*} (dieselben Namen wie opencode.jsonc, bidirektional kompatibel). SSoT ist ~/.secrets/exports.zsh (25 Vars). Nach jeder Änderung dort: ~/dev/.bin/gui-env-sync.sh und App-Neustart (laufender Prozess erbt die launchd-Umgebung nicht). ⚠ ~/.claude.json nie aus einer laufenden Session editieren — Claude Code schreibt dort State, der Edit würde überschrieben; der Flip läuft bei beendeter App über ~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude.

2026-09-12 — TP36-Live: Gerätedaten stehen als CustomFields in Nautobot

Betrifft: alle, die Geräte-Ist-Werte (RouterOS-Version, Compliance %, DHCP-Server-Zahl, DNS-Modus, Mgmt-IP) brauchen. Aktion: Nicht mehr aus der Prosa ablesen und nicht raten — die fünf Felder (grouping: TP36-Live) hängen an den 5 RouterOS-dcim.Device in Nautobot. Aktualisieren: python3 nautobot/gc-snapshot.py --commit (liest nur aus Nautobot/GC, kontaktiert kein Gerät). Die Werte sind so aktuell wie das letzte Golden-Config-Backup (backup_last_success_date am Gerät).

2026-09-07 — SSoT-Cutover: Index/Status = Gitea, NICHT mehr teilprojekte.md

Betrifft: jede Session, die einen TP-Status ändert, anlegt oder abschließt. Aktion: Status/Reihenfolge/„was lief zuletzt" gehen ins Gitea-Issue (admin/bf-infra, Labels status:*/thema:*), nicht in eine Tabelle in docs/teilprojekte.md. Die Datei trägt nur noch die ### TPnn-Prosa. /projektstatus liest Baum + Status aus der Gitea-API. Branch tpNN-kurz jederzeit möglich, Merge nach main, sobald Code/Config steht.