3f938e83895f44908e321716574e0798e77963f6
Eine Aenderung, die am Geraet steht, aber nicht in der SoT, ist Drift -- und Drift sieht bisher immer gleich aus, egal ob er ein Versehen ist oder ein laufender Versuch. Wer testen wollte, hatte die Wahl zwischen "Compliance kaputt" und "gar nicht testen". gc-transaktion.py macht die Absicht sichtbar, ohne die Governance aufzuweichen: der Change geht weiterhin ausschliesslich ueber Golden Config, die Compliance meldet den Drift weiterhin -- neu ist, dass `status` ihn zuordnen kann, "erwartet (offene Transaktion)" statt "unerklaert". Und dass er ein Ablaufdatum hat. Drei Regeln erzwingt das Werkzeug: --expires ist Pflicht (eine unbefristete Ausnahme ist undokumentierter Drift mit besserem Gewissen), der Scope ist eine ComplianceRule und kein Freibrief (Drift ausserhalb wird ausdruecklich als nicht abgedeckt gemeldet), und es gibt genau eine offene Transaktion je Geraet -- sonst ist beim Rollback nicht mehr entscheidbar, wohin zurueck. Der Commit wird verweigert, solange der Scope noch driftet: dann waere die SoT gar nicht nachgezogen worden. Zwei bewusste Grenzen: der Rollback pusht nicht selbst, sondern schreibt einen Vorschlag zum Pruefen (add-Zeilen aus einem /export legen neu an, statt zu aendern), und der Snapshot enthaelt nur den Scope-Abschnitt. Der Vollexport enthielt Firewall, Adressen, Benutzerliste und Skriptquellen -- nichts davon braucht der Rueckbau, und die Akten liegen im Git. Erste Akte ist der ether3-Trunk: ap1 haengt testweise am Sideboard auf core ether3, und dieser Port traegt bisher keines der sieben VLANs. Deploy steht noch aus -- er wurde in dieser Session vom Berechtigungs-Klassifikator blockiert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%