spb/ka-guardian

- orchestrator/registry.py : applique ~/ka-guardian-spool/registry.json (nœud, IP, dir,
  port, PM2 sans ngrok) à SERVICES/NODES en place, journalise les déménagements,
  lit la sonde des runners ; topology.json ne garde que service→registry_app
  (+ pm2_exclude), ses node/dir/port ne sont qu un repli
- main.py : refresh à chaque tick, refus de dépêcher vers un nœud sans runner
  (log 1×/h), rollback sur le nœud ACTUEL du service, bloc registry dans /api/state
- deploy/registry-sync.sh + launchd com.ka.registry-sync (zsh pur, LNP) :
  tire le registre via gitsrv toutes les 2 min + sonde :7791 → runners.json
- deploy.sh : nœuds/repos dérivés du registre, cible registry-sync, pousseur
  fusionné, helper lc_reload (agent gui/uid ou DAEMON système sur nœud sans
  session graphique, ex. M2U64), filtre <nœud>
- dashboard : runner prêt/occupé/absent + fraîcheur du registre par service

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- topology.json: services houseka (M4M64b:8098, www.house-ka.com) et rentka
  (M4M36:8125, www.rent-ka.com) ajoutés à ka2 (gardien immobilier & local);
  nœud m4m36 (192.168.2.69) ajouté aux nodes.
- Runner com.ka.guardian-runner déployé sur M4M36 (rent-ka y tourne):
  deploy.sh RUNNER_NODES += M4M36, CLAUDE.md à jour.
- ngrok exclus des listes pm2[] (même convention que vraiprix).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- topology.json: service vraiprix (M3U96a:8090, site seulement) ajouté a ka6;
  politique du veilleur (intervalle 120s, 2 echecs, throttle restart 10 min,
  fenetres watching/cooldown courtes pour _site)
- orchestrator/main.py: site_engine — check du site public de chaque service,
  down confirme → pm2 restart auto via runner /restart, toujours down →
  incident site_down (priorite max) + mission Claude d investigation
  (build_site_down_prompt); current_status/_site, resolution auto au retour
  en ligne, garde anti-boucle abandonnes 24h; /api/state expose sites
- runner/runner.py: endpoint POST /restart (pm2 restart + healthcheck, sans git)
- app.js: libelle site_down; CLAUDE.md: doc du veilleur

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- Damper : si plus de mass_incident_threshold (20, policy) nouveaux incidents
  seraient créés d un coup pour un service, c est une panne GLOBALE de l app
  (sync mort, /api/stats cassé), pas autant de pannes individuelles — on ne
  crée rien et on alerte au journal/dashboard. Les sources encore cassées une
  fois la vague retombée reçoivent leurs incidents normalement (2026-08-24 :
  794 incidents jobka créés après ~17 h d arrêt de job-ka-sync).
- Statut retired (nouveau côté api-ka d10b2f6) : un incident actif dont la
  source est retirée de la supervision est fermé en abandoned.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Une source diagnostiquée irréparable (site_source_mort, tentatives épuisées)
ne redonne plus d incident avant abandoned_retry_hours (168 h, policy).
Sans cette garde, un connecteur désactivé côté app mais rapporté broken à
perpétuité par la supervision api-ka relançait une mission toutes les ~10 min
(2026-08-24 : 37 missions sur origin-north.ai + 37 sur visionartproductions.com,
~42 USD). Les deux lignes mortes ont aussi été acquittées dans connector_health
côté api-ka.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Orchestrateurs (M4M36) + runners claude -p sur les nœuds d'apps + courrier zsh
(contournement Local Network Privacy macOS 26) + dashboards live style Groupe KA
+ efforts commandés (nouveau connecteur / enrichissement).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>