lessan/jobs

Que fait jobs ?

Utilisez runjob pour confier un travail borné à un modèle CLI installé en local et tenir un registre d'exécution à l'échelle de la machine. Vérifiez que runjob se trouve dans le PATH ; si ce n'est pas le cas, redirigez l'utilisateur vers les étapes d'installation du dépôt plutôt que d'improviser une installation globale.

Lancer une tâche peut consommer du quota ou entraîner des frais chez le fournisseur. Traitez une demande explicite d'envoi ou de délégation comme une autorisation pour ce lancement. Une demande d'explication, d'inspection, de brouillon ou de planification n'est pas une autorisation de lancement.

Choisir la forme d'exécution

• Utilisez runjob run pour une tâche unique et bornée. Elle s'exécute dans le répertoire de travail choisi et ne crée ni branche ni arbre de travail. Pour un travail pouvant modifier ou commiter, utilisez un arbre de travail Git jetable ou le mode flotte.
• Utilisez runjob fleet run pour plusieurs tâches, avec ordonnancement des dépendances, arbres de travail isolés automatiques, sessions reproductibles et limites de concurrence par moteur. Lisez references/fleet.md avant de créer des fichiers de flotte.
• Utilisez runjob log, runjob report et runjob dash pour inspecter les travaux déjà en vol. Ces commandes sont en lecture seule ; runjob repair est une mutation explicite du registre.

Ne substituez pas cette compétence à un sous-agent dans la session lorsque l'utilisateur a demandé une délégation au sein de la conversation en cours.

Tâches uniques (one-shot)

Utilisez un fichier de prompt pour des instructions substantielles afin que l'envoi soit révisable :

runjob run --engine codex --effort high \
  --cwd /absolute/path/to/worktree --file /absolute/path/to/prompt.md

Omettez --model ou --effort lorsque l'utilisateur ne les a pas choisis et que le moteur a une valeur par défaut CLI raisonnable. N'inventez pas de noms de modèles actuels. Lisez references/engines.md lorsque les drapeaux spécifiques au moteur, l'authentification ou le comportement du bac à sable sont importants.

runjob run retourne immédiatement après le lancement sauf si --wait est fourni. Conservez l'uid affiché. Inspectez-le avec :

runjob log --uid UID
runjob log --active
runjob report UID --json
runjob dash

Les logs et les prompts peuvent contenir du code source ou des instructions sensibles. Ils résident sous ${DEV_JOBS_HOME:-~/.config/dev-jobs} ; ne les publiez pas et ne les attachez pas sans un examen séparé.

Achèvement et remontée

Rapportez l'uid, le moteur/modèle effectivement demandé, le répertoire de travail et si la tâche est simplement lancée ou terminée. Ne décrivez pas un lancement de processus comme un résultat réussi. Lorsque vous attendez, vérifiez l'état terminal du registre et résumez la sortie réelle de la tâche, y compris les échecs ou les travaux résiduels.

Pour les terminaisons de tâches lisibles par machine, utilisez le protocole exact décrit dans references/report-trailer.md. Traitez ses champs comme les revendications de la tâche ; vérifiez indépendamment les commits, les tests et les chemins modifiés avant de fusionner ou publier quoi que ce soit.