merge: dev3 → master — resilience: respawn automatico bridge + canary processi 4 layer + process_health daemon dashboard + guardia TimeoutExpired tmux-send

Author: leopu00

.launcher/agent-watchdog.sh

@@ -27,6 +27,10 @@
 
 set -u
 
+# jht-tmux-send vive in /app/agents/_tools (come in start-agent.sh): serve per
+# l'escalation al Capitano in maybe_respawn_bridges. Best-effort se assente.
+export PATH="/app/agents/_tools:${PATH}"
+
 JHT_HOME="${JHT_HOME:-/jht_home}"
 CONFIG="$JHT_HOME/jht.config.json"
 JHT_BIN="/app/cli/bin/jht.js"
@@ -37,6 +41,23 @@ AGENTS=(assistente capitano mentor sentinella)
 # il context window accumulato. Refresh deterministico, near-stateless.
 SENTINELLA_MAX_CTX_AGE_H="${JHT_SENTINELLA_MAX_CTX_AGE_H:-24}"
 
+# ── Bridge suite supervision (2026-06-27) ──────────────────────────────
+# I bridge/daemon ausiliari sono lanciati `setsid` detached da start-agent.sh
+# → NON sono figli di pid1, quindi il respawn-on-crash di pid1 NON li copre.
+# Se uno muore (crash da eccezione, OOM-kill) resta giù finché non riparte il
+# container — è il buco che ha lasciato andris cieco sull'usage per 8h il
+# 2026-06-27. Qui li risorvegliamo a ogni tick. **Anti-flap** (lezione del V4
+# restart-loop, per cui il self-restart del bridge fu RIMOSSO): oltre un cap di
+# respawn in finestra, NON rispawna più e ESCALA al Capitano — niente crash-loop.
+# Vedi docs/internal/2026-06-27-andris-sentinel-bridge-crash.md.
+BRIDGE_STATE_DIR="$JHT_HOME/logs"
+BRIDGE_FLAP_WINDOW_SEC="${JHT_BRIDGE_FLAP_WINDOW_SEC:-600}"   # 10 min
+BRIDGE_FLAP_CAP="${JHT_BRIDGE_FLAP_CAP:-3}"                   # max respawn/finestra
+BRIDGE_ESCALATE_COOLDOWN_SEC="${JHT_BRIDGE_ESCALATE_COOLDOWN_SEC:-3600}"
+# La liveness dei processi la calcola shared/skills/process_health.py (in Python,
+# senza self-match) — stessa fonte di verità del Mantenitore. La suite detached
+# riparabile da un solo `start-agent.sh bridge` è definita lì (gruppo bridge-suite).
+
 mkdir -p "$(dirname "$LOG")"
 
 log() {
@@ -141,7 +162,101 @@ maybe_refresh_sentinella() {
   fi
 }
 
-log "watchdog start · interval=${INTERVAL_SEC}s · agents=${AGENTS[*]} · sentinella_max_ctx_age=${SENTINELLA_MAX_CTX_AGE_H}h"
+bridge_flap_ok() {
+  # 0 se sotto il cap di respawn nella finestra, 1 se il cap è superato.
+  local key="$1" f="$BRIDGE_STATE_DIR/bridge-flap-$1" now cutoff cnt
+  now=$(date -u +%s); cutoff=$((now - BRIDGE_FLAP_WINDOW_SEC))
+  [ -f "$f" ] || return 0
+  cnt=$(awk -v c="$cutoff" '$1+0>=c' "$f" 2>/dev/null | wc -l | tr -d ' ')
+  [ "${cnt:-0}" -lt "$BRIDGE_FLAP_CAP" ]
+}
+
+bridge_flap_record() {
+  # appende 'now' e pota i timestamp fuori finestra (rolling window).
+  local key="$1" f="$BRIDGE_STATE_DIR/bridge-flap-$1" now cutoff
+  now=$(date -u +%s); cutoff=$((now - BRIDGE_FLAP_WINDOW_SEC))
+  { [ -f "$f" ] && awk -v c="$cutoff" '$1+0>=c' "$f" 2>/dev/null; echo "$now"; } \
+    > "$f.tmp" 2>/dev/null && mv "$f.tmp" "$f" 2>/dev/null || true
+}
+
+bridge_escalate() {
+  # avvisa il Capitano UNA volta per finestra di cooldown (no spam), poi tace.
+  local what="$1" now ef last
+  now=$(date -u +%s)
+  ef="$BRIDGE_STATE_DIR/bridge-escalate.ts"
+  if [ -f "$ef" ]; then
+    last=$(cat "$ef" 2>/dev/null || echo 0)
+    [ $((now - last)) -lt "$BRIDGE_ESCALATE_COOLDOWN_SEC" ] && return 0
+  fi
+  echo "$now" > "$ef" 2>/dev/null || true
+  log "bridge-watchdog: FLAP CAP superato ($what) — STOP respawn, escalo al Capitano"
+  jht-tmux-send CAPITANO "[WATCHDOG] $what continua a morire (>${BRIDGE_FLAP_CAP} respawn in $((BRIDGE_FLAP_WINDOW_SEC/60))min). Ho FERMATO il respawn automatico per evitare un crash-loop. Serve diagnosi manuale: controlla /tmp/*-bridge.log. Il Mantenitore farà comunque un canary completo al prossimo sweep." >/dev/null 2>&1 || true
+}
+
+tg_bots_configured() {
+  # vero se almeno un bot Telegram ha un token (channels.telegram.bots.<role>).
+  python3 - "$CONFIG" 2>/dev/null <<'PYEOF'
+import json, sys
+try:
+    d = json.load(open(sys.argv[1]))
+except Exception:
+    sys.exit(1)
+bots = (d.get("channels", {}) or {}).get("telegram", {}).get("bots", {}) or {}
+sys.exit(0 if any((b or {}).get("bot_token") for b in bots.values()) else 1)
+PYEOF
+}
+
+maybe_respawn_bridges() {
+  # Liveness via process_health.py (legge /proc in PYTHON → NIENTE self-match,
+  # a differenza di `grep MARKER /proc/*/cmdline` che trova il proprio argv e
+  # riporterebbe SEMPRE "vivo"). Unica fonte di verità, condivisa col Mantenitore
+  # (step 0 di maintainer-sweep). In steady-state: 1 call, tutti vivi, zero azione.
+  local plan PROC_DEAD_BRIDGE_SUITE="" PROC_DEAD_DEEP="" PROC_TG_ALIVE=0 PROC_ALL_OK=1
+  # NB: process_health.py esce 1 PROPRIO quando c'è un morto (è il caso che ci
+  # interessa) → NON gatare su `|| return` sull'exit code, sarebbe un no-op
+  # esattamente quando serve agire. Catturiamo l'output sempre; skip solo se vuoto
+  # (python assente/errore reale).
+  plan=$(python3 /app/shared/skills/process_health.py summary --shell 2>/dev/null)
+  [ -z "$plan" ] && return 0
+  eval "$plan" 2>/dev/null || return 0
+  [ "${PROC_ALL_OK:-1}" = "1" ] && [ -z "$PROC_DEAD_BRIDGE_SUITE" ] && [ "${PROC_TG_ALIVE:-9}" -ge 3 ] && return 0
+
+  # (1) bridge-suite morti → un solo `start-agent.sh bridge` li rispawna tutti
+  #     (idempotente kill+respawn). Anti-flap: oltre il cap, escala invece di loopare.
+  if [ -n "$PROC_DEAD_BRIDGE_SUITE" ]; then
+    if bridge_flap_ok bridge; then
+      log "bridge-watchdog: suite incompleta (morti: $PROC_DEAD_BRIDGE_SUITE) — respawn via start-agent.sh bridge"
+      JHT_HOME="$JHT_HOME" bash /app/.launcher/start-agent.sh bridge >>"$LOG" 2>&1 \
+        || log "bridge-watchdog: respawn bridge FAIL (rc=$?)"
+      bridge_flap_record bridge
+    else
+      bridge_escalate "suite bridge (morti: $PROC_DEAD_BRIDGE_SUITE)"
+    fi
+  fi
+
+  # (2) tg-bridge: canale Telegram OPZIONALE → respawn solo se i bot sono
+  #     configurati e mancano istanze (attese >=3 process: wrapper+python ×3).
+  if tg_bots_configured && [ "${PROC_TG_ALIVE:-0}" -lt 3 ]; then
+    if bridge_flap_ok tg-bridge; then
+      log "bridge-watchdog: tg-bridge incompleto (${PROC_TG_ALIVE}/3 process) — respawn via start-agent.sh tg-bridge"
+      JHT_HOME="$JHT_HOME" bash /app/.launcher/start-agent.sh tg-bridge >>"$LOG" 2>&1 \
+        || log "bridge-watchdog: respawn tg-bridge FAIL (rc=$?)"
+      bridge_flap_record tg-bridge
+    else
+      bridge_escalate "tg-bridge (${PROC_TG_ALIVE}/3)"
+    fi
+  fi
+
+  # (3) Process "profondi" morti (doctor-watchdog/auto-report/cloud-daemon/pid1):
+  #     dovrebbe rispawnarli pid1. Se restano morti è un problema più serio →
+  #     ESCALA (NON tentare il respawn da qui: li orfaneremmo). agent-watchdog
+  #     non comparirà mai qui (è il processo che gira questo check).
+  if [ -n "$PROC_DEAD_DEEP" ]; then
+    bridge_escalate "process pid1-managed morti: $PROC_DEAD_DEEP"
+  fi
+}
+
+log "watchdog start · interval=${INTERVAL_SEC}s · agents=${AGENTS[*]} · sentinella_max_ctx_age=${SENTINELLA_MAX_CTX_AGE_H}h · bridge_supervision=on (flap_cap=${BRIDGE_FLAP_CAP}/$((BRIDGE_FLAP_WINDOW_SEC/60))min)"
 
 # Loop principale: gate sulla config (può non essere ancora pronta al
 # primo boot del container — il wizard la scrive post-pairing). Sleep
@@ -182,6 +297,10 @@ while true; do
     for role in "${AGENTS[@]}"; do
       ensure_agent "$role"
     done
+    # Bridge/daemon detached (sentinel/pacing/capitano-bridge/window-ratio/
+    # codex-auth-healer + tg-bridge): respawn se morti, con anti-flap. Sono
+    # fuori dal respawn-on-crash di pid1 (setsid), questo è il loro recovery.
+    maybe_respawn_bridges
   else
     # Soft log: config non pronta = wizard non ancora finito. Aspettiamo
     # silenziosamente, niente spam.

.launcher/pacing-bridge.py

@@ -1338,4 +1338,22 @@ def main():
 
 
 if __name__ == "__main__":
-    main()
+    # Supervisore in-process (difesa in profondità, gemello del sentinel-bridge):
+    # il loop ha già un try/except per-tick, ma un'eccezione FUORI dal tick (es.
+    # next_quarter/sleep) ucciderebbe comunque il processo, senza recovery (setsid
+    # detached). Qui qualsiasi eccezione → log + ri-entro in main(). Con --once
+    # main() ritorna subito → break. Vedi 2026-06-27-andris-sentinel-bridge-crash.md.
+    import time as _time
+    import traceback as _tb
+    while True:
+        try:
+            main()
+            break
+        except KeyboardInterrupt:
+            print("\n[pacing-bridge] interrotto.", file=sys.stderr)
+            break
+        except Exception as _e:  # noqa: BLE001 — catch-all VOLUTO
+            print(f"[pacing-bridge] FATAL nel loop: {_e} — riavvio in 5s",
+                  file=sys.stderr, flush=True)
+            _tb.print_exc()
+            _time.sleep(5)

.launcher/sentinel-bridge.py

@@ -427,7 +427,16 @@ def session_exists(s):
 
 
 def jht_tmux_send(session, text):
-    return subprocess.run(["jht-tmux-send", session, text], capture_output=True, timeout=15).returncode == 0
+    # Difesa: un tmux-send che si blocca (pane occupato) NON deve mai abbattere il
+    # bridge. Senza questa guardia, TimeoutExpired propagava fuori dal while-loop di
+    # main() (l'unico handler esterno è KeyboardInterrupt) → bridge morto in silenzio,
+    # zero auto-recovery (setsid detached, fuori dal respawn di pid1). Vedi postmortem
+    # docs/internal/2026-06-27-andris-sentinel-bridge-crash.md. Degrada a "tick saltato".
+    try:
+        return subprocess.run(["jht-tmux-send", session, text], capture_output=True, timeout=15).returncode == 0
+    except (subprocess.TimeoutExpired, OSError) as e:
+        print(f"[bridge V6] WARN jht_tmux_send({session}): {e}", file=sys.stderr)
+        return False
 
 
 def _sample_vitals_and_maybe_alert():
@@ -1680,7 +1689,25 @@ def main():
 
 
 if __name__ == "__main__":
-    try:
-        main()
-    except KeyboardInterrupt:
-        print("\n[bridge V6] interrotto.")
+    # Supervisore in-process (difesa in profondità): una QUALSIASI eccezione non
+    # gestita nel loop di main() NON deve uccidere il bridge. Era il bug del
+    # 2026-06-27: TimeoutExpired su jht_tmux_send propagava fuori dal while-loop
+    # → processo morto e ZERO recovery (setsid detached, fuori dal respawn di
+    # pid1). Qui la cattura, logga e RI-ENTRA in main(). Layer complementari:
+    # (a) la guardia in jht_tmux_send degrada il caso noto a "tick saltato";
+    # (b) l'agent-watchdog (maybe_respawn_bridges) respawna il processo se muore
+    # del tutto (OOM/kill); (c) il Mantenitore fa il canary completo 1×/dì.
+    # Vedi docs/internal/2026-06-27-andris-sentinel-bridge-crash.md.
+    import time as _time
+    import traceback as _tb
+    while True:
+        try:
+            main()
+            break  # uscita normale (main() è un loop infinito → non dovrebbe capitare)
+        except KeyboardInterrupt:
+            print("\n[bridge V6] interrotto.")
+            break
+        except Exception as _e:  # noqa: BLE001 — catch-all VOLUTO: niente morte silenziosa
+            print(f"[bridge V6] FATAL nel loop: {_e} — riavvio in 5s", file=sys.stderr)
+            _tb.print_exc()
+            _time.sleep(5)

BACKLOG.md

@@ -159,6 +159,7 @@ Versione: `package.json` `v0.1.17` (production ferma a `v0.1.12` dopo blocco Tur
   - **✅ DONE 2026-06-21 (commit `1530430c7` + `32d28df48`)** — affordance UI read-only sul cloud (d3 di `[JHT-WEB-READONLY]`), a livello PAGINA/SEZIONE (no `if` sparsi). **(a) Pagine intere desktop-only**: guard unico nel `(protected)/layout.tsx` → su `isCloudDeploy()` redirect a `/dashboard` per `settings`/`credentials`/`secrets`/`channels`/`providers`/`integrations`/`cron`/`backup`/`setup`/`cli-link` (eccezione `settings/cloud-sync` = sync-infra, resta); `UserMenu` nasconde i link Impostazioni/Backup. **(b) Sezioni-controllo in pagine miste** (la pagina resta, sparisce il controllo): `/team` start/stop + azioni per-agente; `AgentInteraction` (chat+terminale di analista/critico/scrittore/scout/scorer) → `null` su cloud + stop polling; chat composer di `/team/capitano` e `/team/assistente`; `/profile` → `ProfileEditButton`+`ProfileAssistantFab` nascosti = view-only (export resta). La sicurezza è comunque a monte (route 403 via `requireLocalWrite`+`isCloudDeploy`); questo toglie i vicoli ciechi.
   - **⬜ Rifinitura minore residua** — bottoni secondari sulle pagine miste (pulisci-chat, apri-terminale, toggle-terminale in capitano/assistente): innocui sul cloud (agiscono su dati locali assenti) ma volendo si nascondono con lo stesso pattern.
 - ⬜ **`[JHT-CLOUD-INTERACTIVE-RETIRE]` 🟡 (= fix di scala definitivo)** — freeze/ritiro del **path cloud interattivo** ridondante una volta che l'interazione è desktop+tunnel: bus `team_state` control + reconciler, lane `user_to_agent_messages` + `user-messages-poller`, `team_commands` legacy. **NB:** è qui che il costo Vercel per-utente va a ~0 (mitigato nel frattempo dal poll adattivo, `[JHT-DATA-SYNC]` (4), ma non azzerato): solo togliendo i poller di controllo resta **un solo daemon di sync** per VPS. **🟡 In larga parte FATTO 2026-06-21 (dev4, commit `ce96b44eb`)**: **scoperta** che il controllo Start/Stop è retto SOLO dal reconciler (la dashboard scrive `should_run`, nessun path diretto) → spegnerlo romperebbe il controllo. Fix corretto = **fold nel daemon**: `team-state-reconciler` → `reconcileOnce()` chiamata dal cloud daemon ogni tick (riusa `reconcile()`/`applyAction()`: `.team-halted.flag` + heartbeat preservati); poller standalone **non parte più**. `user-messages-poller` **ritirato** (chat web=solo-desktop). `team-commands-poller` + `file-bridge` **restano** (adattivi) finché i loro feeder cloud non spariscono (sentinella web in dismissione lato collega). Entrambi i ritirati ri-attivabili con `JHT_CLOUD_CONTROL_POLLERS=1`. **Effetto**: da 3 poller a 5s/≤30s per-utente → 1 daemon a 60s (+team-commands transitorio). Latenza controllo ≤60s. ⚠️ Caveat: niente più claim single-team (edge multi-VPS/utente). **Test runtime utente** (controllo via dashboard+daemon). Residuo: ritiro `team-commands` quando il feeder web è rimosso; eventuale freeze/delete delle route cloud `team_commands`/`team-state` browser-ramp (lane web/collega). **⚠️ Eccezione (rivisto 2026-06-20):** la **corsia richieste async** (`position_tickets`, `position_feedback`, flag `*_requested` + `pull-desired-state`) **NON si ritira** — non è il bus real-time, è un'event-queue che la VPS pulla con calma (vedi `[JHT-DATA-SYNC]`). **Resta** il push dati one-way + `jht cloud restore` + dashboard read-only. ⚠️ *Ribalta codice shippato 23–31 maggio: scelta freeze-vs-delete deliberata, pezzo per pezzo.*
+- ⬜ **`[JHT-REALTIME-SCALE]` 🟢 (robustezza/scaling daemon event-driven, NON urgente)** — il sync event-driven via Supabase Realtime è live+validato su andris (dietro flag `JHT_REALTIME_SYNC`, vedi `docs/internal/2026-06-26-sync-status-report.md`). Degrada con grazia (col Realtime giù → floor = paracadute ~56 q/h/utente, -94%, nessun dato perso), quindi questi sono affinamenti di scala da fare crescendo a molti clienti, non blocchi: **(1) monitor del rate di riconnessione** per-VPS (conteggio `CHANNEL_ERROR`/`SUBSCRIBED` + alert); **(2) tetto connessioni Realtime Supabase** (~500 concorrenti su Pro = muro di scala vero → bump tier/sharding); **(3) thundering herd** al riavvio del server Realtime (N socket riconnettono insieme → jitter/backoff extra); **(4) unificare l'auth** REST-diretto+websocket (oggi 2 sessioni sullo stesso refresh_token → race di rotazione possibile a scala); **(5) paracadute regolabile** (`JHT_PARACHUTE_SEC`) come leva se il Realtime è inaffidabile. Vedi `[JHT-DATA-SYNC]` / `[JHT-DAEMON-SUPABASE-DIRECT]`.
 - ⬜ **`[JHT-SETUP-LOCAL-FIRST]` 🟢** — rielevare il **Local PC** a path di prima classe ("il team è tuo, accendi/spegni quando vuoi"); allinea la copy execution-mode (oggi "not recommended for daily machines"). Si incastra col Dedicated computer mode.
 
 **Sequenza proposta:** I `[TELEGRAM-OPTIONAL]` → II `[DATA-SYNC]` → III `[WEB-READONLY]` → IV `[DASHBOARD-SPLIT]`/`[DESKTOP-COCKPIT]` → V `[VPS-TUNNEL]` → VI `[CLOUD-INTERACTIVE-RETIRE]`. I+II scorporabili subito; V porta il valore "VPS come locale". **Decisioni aperte per l'utente** elencate nel design doc § "Decisioni aperte".