Job Monitor

Surveille les jobs soumis aux clusters SLURM — quantization PTQ, évaluation NEL, déploiement de modèle, ou jobs SLURM bruts.

Quand utiliser

Auto-monitoring — une autre skill (PTQ, évaluation, déploiement) vient de soumettre un job. Enregistrez le job et mettez en place le monitoring immédiatement.
Initié par l'utilisateur — l'utilisateur demande l'état d'un job, possiblement dans une nouvelle conversation. Vérifiez le registre, identifiez le job, et rapportez.

Job Registry

Tous les jobs actifs sont suivis dans .claude/active_jobs.json. Ce fichier est la source unique de vérité pour ce qui est en cours de monitoring.

[
  {
    "type": "nel",
    "id": "<invocation_id or slurm_job_id>",
    "host": "<cluster_hostname>",
    "user": "<ssh_user>",
    "submitted": "YYYY-MM-DD HH:MM",
    "description": "<what this job does>",
    "last_status": "<last known status>"
  }
]

type est l'un de : nel, slurm, launcher.

À la soumission d'un job

Chaque fois qu'un job est soumis (par n'importe quelle skill ou manuellement) :

Ajoutez une entrée à .claude/active_jobs.json. Créez le fichier s'il n'existe pas.
Configurez un cron récurrent durable (s'il n'en existe pas déjà un) qui interroge tous les jobs enregistrés toutes les 15 minutes. Le prompt cron doit : lire le registre, vérifier chaque job, signaler les changements d'état à l'utilisateur, supprimer les jobs complétés, et se supprimer lui-même quand le registre est vide.

Faites toujours les deux étapes. N'essayez pas de prédire la durée du job.

À l'exécution du cron / Vérification d'état

Qu'il soit déclenché par le cron ou par l'utilisateur demandant « check status » :

Lisez le registre depuis .claude/active_jobs.json
Vérifiez chaque job en utilisant la méthode appropriée (voir ci-dessous)
Rapportez uniquement les changements d'état — comparez avec last_status dans le registre
Mettez à jour last_status dans le registre
Supprimez les jobs complétés — tout job dans un état terminal (COMPLETED, FAILED, CANCELLED, KILLED)
Si le registre est vide — supprimez le cron récurrent

Comment vérifier chaque type de job

Jobs NEL (`type: nel`)

Vérifiez : nel status <id>
À la complétion : nel info <id> pour récupérer les résultats
En cas d'échec : nel info <id> --logs puis inspectez les logs serveur/client/SLURM via SSH

Jobs Launcher (`type: launcher`)

Vérifiez : Suivez le fichier de sortie en arrière-plan du launcher pour les événements clés
Événements clés : experiment ID, SLURM job ID, container import, calibration progress, export path, final status
En cas d'échec : Cherchez Traceback, Error, ou FAILED dans la sortie

Jobs SLURM bruts (`type: slurm`)

Vérifiez : ssh <host> "squeue -j <id> -h -o '%T %M %R'" — si vide, le job a quitté la queue
À la complétion : ssh <host> "sacct -j <id> --format=State,ExitCode,Elapsed -n"
En cas d'échec : Vérifiez le fichier log de sortie du job

Identification des jobs (initié par l'utilisateur, pas d'ID donné)

Quand l'utilisateur demande des informations sur un job sans spécifier un ID, vérifiez dans cet ordre :

.claude/active_jobs.json — plus fiable, possède le contexte
nel ls runs --since 1d — runs NEL récents
ssh <host> "squeue -u <user>" — jobs SLURM actifs
ls -lt tools/launcher/experiments/cicd/ | head -10 — expériences launcher récentes

Directives de rapport

Signalez les changements d'état de façon proactive — PENDING → RUNNING, ou job se termine
Agrégez plusieurs jobs — "2 of 4 completed (MMLU-Pro: 42.3%, GSM8K: 67.1%), 1 running, 1 pending"
Résumez, ne répétez pas — interprétez les événements (« Calibration complete, exporting checkpoint ») et non les logs bruts
En cas d'échec, diagnostiquez immédiatement — vérifiez les logs et rapportez la cause racine sans attendre la demande de l'utilisateur
Minimisez le bruit — ne signalez pas « toujours en cours d'exécution » à moins que l'utilisateur demande activement