Run #3405

{
  "ok": true,
  "failed": [],
  "hallucinated": [],
  "context_errors": []
}

{
  "pool_status": "see_db"
}

Tu es un agent de monitoring du pool agencecom.

Lessons pertinentes:
LESSONS APPRISES PERTINENTES :
- L453-HUB: Health endpoints K8s : separer liveness no-DB / readiness DB-1s alert / startup cached
- L328-CROSS-S150-blocD2-deploy: Bloc D2 cache layer DEPLOYED Sprint 2 P2 — REUSE Redis 7.0.15 BSD existing Contabo (skip Valkey doublon) + smoke 5/5 PASS via /api/memory/cache/health endpoint dedie
- L-S199-LL2-V52-SPEC-REVIEW: L-S199-LL2 — Review V5.2 Monitoring spec (3 BLOCKERS + 15 medium + 5 low = 23 findings, GO sous condition)
- L-S199-CROSS-V52-SPEC-DRAFTED: L-S199-CROSS-V52-SPEC-DRAFTED — V5.2 Monitoring event-driven spec push DB
- L-S189-LL2-observateur-recap: L-S189-LL2 — Observateur PHASE 1 recap 13+ cycles SILENT + cron clôture

Donnees pool actuelles:
see_db

CONTRAINTE STRICTE -- Tables autorisees UNIQUEMENT :
- agencecom.agents (id, name, agent_level, status, current_session_id, error_count_last_hour, total_sessions, total_errors, total_cost_usd, quarantined_until, acquired_at, last_released_at)
- agencecom.agent_task_runs (id, agent_id, status, started_at, completed_at, error_message, llm_tokens_in, llm_tokens_out, cost_usd, validation_result)

Toute autre table (v_agents_critical, agent_pool, healthcheck_config, error_log, file_locks, zombie_agents, agent_audit, v_agent_timeout_health, v_agents_timeout_risk, agent_health_log, redis_health_ping, auto_quarantine, missions, health_checks, agent_health, internal) NEXISTE PAS -- ne reference jamais de table absente de cette liste.

Identifie les agents zombies (busy >1h sans completion via started_at + status), error_count_last_hour > 5, ou drift quarantine (quarantined_until > now).
Donne 3 recommandations concretes en markdown bullet points avec actions SQL utilisant SEULEMENT les 2 tables autorisees ci-dessus.

Voici 3 recommandations concrètes avec les actions SQL associées, exploitant uniquement les tables `agencecom.agents` et `agencecom.agent_task_runs`.

---

### 1. Éliminer les agents zombies (tâche active > 1 h sans complétion)

**Problème** : Un agent en statut `busy` avec une tâche `running` démarrée depuis plus d’une heure et jamais achevée (`completed_at` NULL) bloque une capacité de traitement.

**Action SQL** (à exécuter en transaction) :
```sql
-- Repérer les zombies
WITH zombies AS (
    SELECT a.id AS agent_id, r.id AS task_run_id
    FROM agencecom.agents a
    JOIN agencecom.agent_task_runs r ON a.id = r.agent_id
    WHERE a.status = 'busy'
      AND r.status = 'running'
      AND r.started_at < NOW() - INTERVAL '1 hour'
      AND r.completed_at IS NULL
)
-- Forcer l’échec de la tâche zombie
UPDATE agencecom.agent_task_runs
SET status = 'error',
    completed_at = NOW(),
    error_message = 'Zombie task timed out - killed by pool monitor'
WHERE id IN (SELECT task_run_id FROM zombies);

-- Libérer les agents associés
UPDATE agencecom.agents
SET status = 'idle',
    current_session_id = NULL,
    last_released_at = NOW()
WHERE id IN (SELECT agent_id FROM zombies);
```

Cette action arrête proprement la tâche fantôme et rend l’agent disponible pour de nouveaux traitements.

---

### 2. Mettre en quarantaine les agents en erreur rapide (`error_count_last_hour > 5`)

**Problème** : Un agent accumule trop d’erreurs en une heure, indiquant une dégradation. Il faut l’isoler temporairement pour éviter une cascade de coûts.

**Action SQL** :
```sql
-- Geler les agents trop fautifs pour 30 minutes
UPDATE agencecom.agents
SET status = 'quarantined',
    quarantined_until = NOW() + INTERVAL '30 minutes',
    error_count_last_hour = 0,
    last_released_at = NOW()       -- enregistre la mise en quarantaine
WHERE error_count_last_hour > 5
  AND status != 'quarantined';    -- ne pas réinitialiser un déjà quarantiné
```

Le compteur est remis à zéro pour éviter un double déclenchement immédiat ; la quarantaine expirera automatiquement après 30 minutes (une tâche de nettoyage pourra ensuite basculer le statut à `idle` une fois `quarantined_until` dépassé).

---

### 3. Corriger la dérive d’état de quarantaine (quarantined_until > now mais statut ≠ quarantined)

**Problème** : Des agents possèdent un timestamp de quarantaine future alors que leur `status` n’est pas `quarantined` – incohérence entre la politique et l’état réel.

**Action SQL** :
```sql
-- Aligner le statut avec la quarantaine active
UPDATE agencecom.agents
SET status = 'quarantined'
WHERE quarantined_until > NOW()
  AND status != 'quarantined';
```

Cette requête rétablit la cohérence : tout agent encore sous le coup d’une quarantaine (date future) est immédiatement basculé en statut `quarantined`, ce qui évite des exécutions accidentelles de tâches.

---

Ces trois interventions exploitent exclusivement les colonnes des tables autorisées et peuvent être intégrées dans un cron de monitoring périodique.