Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die "2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring) war nie real; beide korrigiert. Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device" enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS, täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5 Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit. Announcement-Eintrag ergänzt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.3 KiB
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-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.