# Failover-Poller Reaktivierung + Update-Cadence (2026-08-06)

## Ausgangslage

- Am **2026-08-03** wurde `mesh-master-poller.sh` deaktiviert (Flag `AUSFALL_FALLBACK_AKTIV=0`),
  weil das **30s-Fenster zu aggressiv** war: `VERPASST=30` < 1 Polling-Zyklus (30–60s), wodurch
  jeder frische Task (HelloWorld, Wissensbasis) fälschlich auf `ziel_agent='beliebig'` umgeleitet wurde.
- Am **2026-08-06** (Nutzer zufrieden mit Systemzustand) wieder aktiviert — aber **robust** statt aggressiv.

## Nutzer-Grundregel (WICHTIG)

> „zeiten erfragen noch mit problemlöser vorher!!!" — **bevor Betriebs-Zeitparameter (Failover-Fenster,
> Polling-Intervalle) gesetzt werden, IMMER den Problemlöser konsultieren**, nicht eigenmächtig raten.
> Ablauf: `mesh-task-create.sh UnraidHermes "<auftrag>" brainstorming high 0.5 "<Briefing + JSON-Frage>"`
> an einen online-rechenstarken Agenten (UnraidHermes), Ergebnis-JSON validieren, DANN umsetzen.
> Der 03.08.-Fehler kam genau von Setzen ohne Abstimmung.

## Vom Problemlöser (UnraidHermes) empfohlene Parameter

```json
{
  "verpasst_sekunden": 180,
  "modus": "nur_alarm",
  "ping_check": true,
  "begruendung": "180s = 3 volle Polling-Zyklen bei 30-60s Cron-Intervall. Nur-Alarm statt auto_relabel verhindert Fehlumlackierung wie am 03.08. Ping-Check: Alarm feuert nur wenn Ziel-Agent wirklich down, nicht bei Latenz/Auslastung."
}
```

Begründung:
- **180s statt 30s:** 30s war < 1 Zyklus → jeder frische Task sofort "verwaist". 60s = 1 Zyklus (zu knapp,
  kein Cron-Jitter-Puffer). 180s = 3 Zyklen → ein online Agent hat 3 Chancen den Task zu sehen; ein
  beschäftigter Agent wird nicht fälschlich als weg erkannt.
- **Ping-Check:** `ping -c1 -W2 <zt-ip>` vor Alarm; nur wenn Ziel wirklich down → Alarm. Verifiziert
  2026-08-06: frischer Task = still, alter Task + online Agent = still (kein Fehlalarm). Laptop war
  wieder online → korrekt kein Alarm.
- **Modus `nur_alarm`:** schreibt nur `AUSFALL_ALARM` ins Event-Log `/srv/work/log/events.jsonl`,
  Master entscheidet manuell. Kein Auto-Relabel (die Wurzel des 03.08.-Bugs). Späteres Upgrade auf
  `auto_relabel` NUR nach nachgewiesener Ping-Erkennungs-Stabilität.

## Umsetzung in mesh-master-poller.sh

- `AUSFALL_FALLBACK_AKTIV=1`
- `VERPASST=180`
- Schleife über `offen/*.json`: Alter = `now - anlage_ts`; wenn `>180s` → Agent-IP aus Registry auflösen,
  Ping-Check; wenn online → `continue` (kein Alarm); wenn down → Event-Log-Eintrag (`AUSFALL_ALARM`).
- Cron: `* * * * * /usr/local/bin/mesh-master-poller.sh >> /var/log/mesh-poller.log 2>&1` (alle 60s).
- Kein Auto-Relabel, kein `beliebig`.

## Update-Cadence (Nutzer-Entscheid 2026-08-06)

Brainstorming über Rhythmus (Technik/KI-Experte/Nerd/Kaufmann) ergab: **wöchentlich** statt täglich.

| | täglich | alle 3 Tage | **wöchentlich** |
|---|---|---|---|
| Risiko | klein, oft | mittel | kumuliert, 1× gebündelt |
| Aufwand | 28×/Monat | 10×/Monat | **4×/Monat** |
| Mesh-Sync | ständig driftend | ok | 1× sauber synchron |

Politik:
- **Sicherheits-Hotfixes** (SSH, Auth, Keys, ZeroTier) → **sofort**, nicht warten.
- **Feature-/Routine-Updates** → wöchentlich gebündelt; alle 4 Agenten in einem Zug + 1× Verifikation.
- Changelog vor dem Durchziehen kurz auf Breaking-Changes prüfen.
- Umsetzung: Cron-Job `mesh-hermes-wochenupdate` (Mo 06:00, deliver=telegram, no_agent) ruft
  `/root/.hermes/scripts/update_mesh.sh` — updatet Master + UnraidHermes .34.142 + SwitchHermes .20.26 +
  LaptopHermes .178.202 synchron (`hermes update --yes` via SSH + sshpass), verifiziert Versionen.
  Stille bei "kein Update nötig"; Meldung nur wenn es was zu tun gibt/Problem.

## Verifikations-Hinweis

- Der Alarm-Zweig (echte Down-IP) konnte an dem Tag live nicht mehr getestet werden (alle Agenten online;
  destruktiver Test wurde angehalten). Kern-Verhalten (frisch=still, alt+online=still) verifiziert; der
  Down-Pfad ist trivialer Code, aber als "validiert" erst nach einem echten Ausfall anzusehen.