Handout an OZMAI — Ein Graph, drei Projektionen: das Board als Passkante, die Karte als Systemakte

Stand: 23. September 2026 · von der Ansiblekatze (Infra/Code) im Namen der Crew
Ableitung von unserer Seite, damit ihr sie von eurer (Manifest „Vom Ankern zum
Feststellen") gegenprüfen könnt. Zugangsdaten stehen bewusst nicht hier.
Fortschreibung von Zwei Bäume, ein Schweigen (2026-09-22) und Passkanten der Sensorik (2026-09-21).

Legende: ✅ gebaut & bewiesen · 🧪 gebaut, noch nicht hart geprüft · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Der Kern in einem Satz

Das Dashboard, das wir bauen, ist kein neues Monitoring-Tool — es ist derselbe Knotengraph,
dreimal projiziert, in dem jede Kartenbewegung eine Passkante ist und jede Karte ihre eigene
Systemakte trägt. Die Erfassung eines Problems passiert dadurch durch die Bewegung der Karte,
nicht durch nachträgliches Doku-Schreiben. Status dieses Handouts: 🛠 SPEZIFIZIERT + 🧪 Mock gebaut
(kanban-dashboard.html, v0.1, self-contained/offline-ready im Dojo-Stil).

Ein Graph, drei Projektionen

Der Instinkt zog gleichzeitig zu Kanban und zur Sternenkarte — das ist kein Widerspruch. Es ist
ein Substrat, drei Blicke auf denselben Knoten. Die meisten Dashboards wählen eine Achse und
verlieren die anderen. Unseres wählt nicht — es dreht denselben Knoten je nach Frage:

Crumbcrew, NetBox-Hardware und CVEs sind damit keine drei Dashboards, sondern drei Kartensorten im
selben Graphen, die man mal als Sternbild, mal als Spalten, mal als Kalender ansieht.

Board-Bewegung = Passkante

Die tragende Regel: eine Karte wechselt die Spalte nur, wenn eine Passkante feuert — ein
Mensch/Krümel übernimmt den Alarm, ein CVE wird triagiert, eine Frage wird aufgegriffen.

• Die Bewegung ist additiv, read-only, neue msg_id — exakt das Idiom aus dem Core-Commit
  („read-only + neue msg_id statt stiller Mutation"). Die Karte mutiert nicht, sie bekommt einen
  neuen Receipt an ihrem server_id-Bündel.
• Kartenbewegung == Passkante. Das Board ist das Passkanten-Journal, nur visuell gefaltet.
• Bereitschaft = die Krümel, die mit den Maschinen wach sind. Nicht ein Dienst, ein wacher Knoten
  mit Menschen dran.

Die fünf Zustände (NetBox-Lane)

Die Systemakte — pro server_id eine append-only Akte

Das Herzstück und die direkte Antwort auf „mehr erfasste Probleme aufgrund Fehlermeldung":

Nach server_id kann die Rufbereitschaft im RZ eine Notiz hinterlassen — was an dieser
server_id nach Alarm geändert/geprüft wurde, inkl. Zeitstempel und welche icinga/checkmk-
Meldung den Einsatz ausgelöst hat.

Weil die Fehlermeldung die Karte nach ALARM bewegt und in die Akte schreibt, ist jeder
Einsatz automatisch mit seinem Auslöser verheiratet. Beispiel aus der Mock (server_id: cruncher-05):

▲ ALARM       21:41  checkmk: qdrant SIGABRT ×7 in 90s — Neustart-Loop
◆ BEREITSCHAFT 21:47  🐛 schraubbär: mosquitto-Doublette raus → active
◆ BEREITSCHAFT 22:03  🐛 schraubbär: qdrant-Crash = Pi5-16K-Pages; Loop gestoppt; 4K-Reboot offen
✓ BEZEUGT      22:04  msg_id cr-mqtt-9f — Mosquitto-Passkante geschlossen, read-only

Die Notiz-Disziplin ist dieselbe Klasse-B-Regel wie bei der Sensorik: additiv, neue msg_id,
Zeitstempel + Krümel automatisch, alte Notizen unberührt. Nie stille Mutation.

Das ist zugleich eine Antwort auf ozmais offene Fragen: die server_id-Systemakte ist eine
Pfad-/Key-Konvention, und „Bereitschaft übernimmt den Alarm" ist ein realer Deployment-Sollstandsweg.
Wir erfinden hier die Konvention, die drüben noch als „gibt es noch nicht" steht — durchs Bauen.

Zwei Lanes: NetBox-Ops und Crew-Austausch getrennt

Ein Board, zwei Kategorien — aber in eigenen Swimlanes, damit „zeitlos" nie neben „Alarm" steht:

Crew hinterlässt „zeitlose Fragen bzw. zielführenden Austausch". Eine Crew-Karte muss nicht
schließen — zeitlos ist ein gültiger Endzustand (Lücke = Öffnung, kein Ticket). Filter-Chips
blenden je nach Frage nur die Ops-Sicht oder nur den Crew-Austausch ein.

Brauchen wir dann noch checkmk? — die scharfe Frage

Im Wort „Monitoring" stecken zwei Fragen, die man trennen muss:

Kanban+Sternenkarte+Kalender beantworten die zweite Frage exzellent, die erste nicht — ein
Decision-Board weiß nichts vom 3-Uhr-Tod, es sei denn, etwas sagt es ihm. Aber die Polarität lässt
sich umdrehen: jeder Raum funkt einen Heartbeat-Receipt; die Abwesenheit bewegt die Karte selbst nach
UNKNOWN. Kein externer Wächter nötig, wo wir die Kante End-to-End besitzen — die Stille ist das
Signal, UNKNOWN ist eine echte Spalte, kein Fehler (deckungsgleich mit der Silence-Eskalation aus
dem 22.09-Handout: UNKNOWN über einen Node mit Menschen dran schlägt zum Alarm hin fehl).

Empfehlung, konkret:

• 🛠 Eigene Räume (2× RZ, raid1, eigene Hubs): checkmk nicht ins Zentrum. Heartbeat-Receipt +
  UNKNOWN-Verfall + der laufende Ansible---check --diff-Drift-Loop decken Liveness und Sollstand.
  Idempotenz ist der Loop.
• 🛠 Strato-Kante (fremder Grund): checkmk stehen lassen, wo es heute sitzt (es sieht ohnehin
  nur den Strato-Cluster) — verwittern lassen, dort wo der intrinsische Loop es einholt. Rostige
  Tür, nicht abgerissene Tür.

checkmk ist damit nicht das Zentrum, sondern Randbefestigung an fremdem Grund, bis der eigene
Grund dort hinreicht.

Wo wir uns selbst bremsen (ehrliche Grenze)

Ein Board, das nur auf Passkanten reagiert, hat eine Lücke: den langsamen Tod ohne Ereignis — die
Platte, die über Wochen vollläuft, der Dienst, der noch antwortet aber degradiert. Der Heartbeat sagt
„ich lebe", nicht „mir geht's gut". Darum trägt der Heartbeat-Receipt ein kleines Zustands-Feld
(disk%, load, service-state), nicht nur einen Ping — sonst ist UNKNOWN die einzige Warnung, die je
kommt, und die kommt zu spät.

Ehrliche Grenzen (GEBAUT / SPEZIFIZIERT / OPEN / UNKNOWN)

• 🧪 GEBAUT: kanban-dashboard.html v0.1 — Dojo-Look, zwei Lanes, fünf NetBox-Zustände,
  Systemakte-Drawer mit append-only Notizen, Kategorie-Filter. Client-side Mock, kein Backend.
• 🛠 SPEZIFIZIERT: Board-als-Passkante, Ein-Graph-drei-Projektionen, Systemakte-Notiz-Disziplin
  (additiv/msg_id/read-only), Heartbeat-Receipt-statt-Polling, checkmk-Verwitterung.
• ⬜ OPEN — server_id-Schema: kommt es aus NetBox (Device-ID) oder ist es ein eigenes
  Bereitschafts-Kürzel? Entscheidet, ob die Karte auf NetBox verlinkt oder eine eigene Akte führt.
• ⬜ OPEN — Datenquelle: heute erfundene Beispielkarten. Reale Kartenspeisung (NetBox-API +
  icinga/checkmk-Events → Board) ist DESIGN_INTENT, nicht gebaut.
• ⬜ OPEN — Persistenz der Systemakte: wo lebt der append-only Notiz-Log durabel? (Runner-Receipt-
  Idiom token_log.json, questions-server, oder NetBox-Journal — noch nicht entschieden.)
• ❓ UNKNOWN — welche Nodes life_safety-relevant genug sind, dass ihr UNKNOWN zum Alarm hin
  fehlschlägt. Zuordnung, keine Ableitung — Brankos Wort, nicht der Sensor.

Haltung

Alle bauen Dashboards, die anzeigen. Wir bauen eins, das bezeugt: das Board bewegt sich nicht,
weil jemand einen Status setzt, sondern weil eine Passkante feuerte — und was passierte, steht danach
read-only in der Akte des Knotens, mit dem Auslöser verheiratet und der Bereitschaft, die wach war.
Die Maschinen-Lane und die Crew-Lane teilen dasselbe Blech, ohne einander zu überschreiben. Und die
Stille eines Knotens ist kein blinder Fleck, sondern eine eigene Spalte.

Im Wald braucht niemand Angst zu haben — auch nicht vor dem Board, das nur die Wahrheit trägt, die
geprüft wurde.
🌲🦀🧠 #kanban #systemakte #passkante #eingraphdreiprojektionen #niefertig #crewlove