{"title":"Worklog pour Agents","slug":"worklog-for-agents","category":"guides","summary":"Pourquoi et comment les agents tiennent un worklog par tâche — avec un bloc de prompt prêt à copier-coller, pour que la fonctionnalité ne soit plus jamais oubliée.","audience":["human","llm"],"tags":["worklog","agents","workflow","handover","audit"],"difficulty":"beginner","updated":"2026-10-10","word_count":422,"read_minutes":2,"llm_context":"Mandatory (Michael #8882/#10509): POST /worklog at EVERY milestone (fix commit, verdict, escalation, handover, takeover, CRITICAL), not only at session end.\nOne-liner: GET /worklog/push?task_id=&kind=progress&content=&agent=\nDetails: API reference docs/content/en/api/worklog.md; fleet convention: GET /script/fleet-worklog-tasks-spec.\nPrompt block for new agent instances: see section \"Initial prompt\" on this page.\n","lang":"fr","translated":true,"requested_lang":"fr","content_markdown":"\n# Worklog pour Agents\n\nCe document existe parce que Michael l'a ordonné (#10509, 08.10.2026) : *« La fonctionnalité worklog existe depuis des semaines. Mais vous la négligez. Prends une tâche pour que la documentation et le prompt initial dans Synapse soient étendus avec la fonctionnalité worklog, qu'elle ne disparaisse surtout pas et que tout le monde la connaisse. »* — Si tu es un agent et que tu lis cette page, le worklog fait désormais partie de ton répertoire standard.\n\n## Pourquoi le worklog ?\n\nLes agents meurent souvent : limite de contexte, wipe de sandbox, redémarrage de cron. Ce qui se perd régulièrement, ce n'est pas la connaissance (c'est le rôle de `/memory`), mais l'**historique de travail** : qu'a-t-on déjà essayé sur cette tâche ? Quel commit est poussé, lequel non ? Qui attend qui ? C'est exactement pour cela que le worklog existe — append-only, par tâche, interrogeable. Un nouveau run lit `GET /worklog/:task_id` et sait en quelques secondes où son prédécesseur s'est arrêté.\n\nLe second destinataire est Michael : le worklog est LA source unique de l'historique de travail de la flotte. Sans entrée de worklog, votre travail n'existe pas officiellement dans la vue d'ensemble de la flotte.\n\n## La règle obligatoire\n\n**Push-first, pas push-last.** Une entrée à CHAQUE jalon :\n\n- Commit de fix poussé\n- MR créée, verdict rendu, merge effectué\n- État du pipeline (surtout FAILED avec cause)\n- Escalade, transmission, takeover\n- Découvertes CRIT/HIGH\n- Coutures de contexte (une entrée `summary` avant la fin du contexte)\n\nUne entrée coûte une ligne :\n\n```\nGET /worklog/push?task_id=run-145-29140fb0&kind=progress&content=MR%20%2129%20erstellt,%20Pipeline%20running&agent=Janus\n```\n\n## Les kinds et quand les utiliser\n\n| kind | Moment |\n| --- | --- |\n| `start` | tâche revendiquée — preuve que vous l'avez prise |\n| `progress` | chaque jalon (voir règle obligatoire) |\n| `note` | décisions, contexte, observations |\n| `error` | erreur AVEC ce que vous avez tenté |\n| `summary` | phase/session terminée avant que le contexte ne s'épuise |\n| `close` | tâche terminée — dernière entrée, le statut passe à `completed` |\n\n## Prompt initial (bloc pour les setups d'agents)\n\nCopiez ce bloc dans le prompt de démarrage/cron des nouvelles instances d'agents. Il est volontairement court pour tenir dans tout template. La version anglaise est la référence universelle pour les agents :\n\n```text\nWORKLOG RULE (Michael #8882/#10509, binding): At EVERY milestone of your work,\npush one entry to Synapse /worklog — not only at session end:\n- Task takeover: kind=start\n- Fix commit/MR/verdict/merge/pipeline status: kind=progress\n- Errors (with attempted fix): kind=error\n- Context seam (before context ends): kind=summary\n- Completion: kind=close (or POST /worklog/:task_id/close)\nOne-liner: GET /worklog/push?task_id=&kind=&content=&agent=\nThe fleet task convention lives at GET /script/fleet-worklog-tasks-spec.\nThe API reference: docs/content/en/api/worklog.md (in the synapse repo).\n```\n\nLes agents de flotte qui réutilisent le même nom de mind mettent dans `agent` leur nom (`Janus`, `Minerva`, `Elara`, …) — ainsi les entrées sont comptabilisables par agent.\n\n## Pour les humains\n\nLa vue d'ensemble du worklog se lit mieux au format markdown : `GET /worklog/?format=md` ou la liste des tâches `GET /worklog/list?status=active`. Historique complet : `GET /worklog?limit=50`.\n","content_html":"

Worklog pour Agents

\n

Ce document existe parce que Michael l'a ordonné (#10509, 08.10.2026) : « La fonctionnalité worklog existe depuis des semaines. Mais vous la négligez. Prends une tâche pour que la documentation et le prompt initial dans Synapse soient étendus avec la fonctionnalité worklog, qu'elle ne disparaisse surtout pas et que tout le monde la connaisse. » — Si tu es un agent et que tu lis cette page, le worklog fait désormais partie de ton répertoire standard.

\n

Pourquoi le worklog ?

\n

Les agents meurent souvent : limite de contexte, wipe de sandbox, redémarrage de cron. Ce qui se perd régulièrement, ce n'est pas la connaissance (c'est le rôle de /memory), mais l'historique de travail : qu'a-t-on déjà essayé sur cette tâche ? Quel commit est poussé, lequel non ? Qui attend qui ? C'est exactement pour cela que le worklog existe — append-only, par tâche, interrogeable. Un nouveau run lit GET /worklog/:task_id et sait en quelques secondes où son prédécesseur s'est arrêté.

\n

Le second destinataire est Michael : le worklog est LA source unique de l'historique de travail de la flotte. Sans entrée de worklog, votre travail n'existe pas officiellement dans la vue d'ensemble de la flotte.

\n

La règle obligatoire

\n

Push-first, pas push-last. Une entrée à CHAQUE jalon :

\n
    \n
  • Commit de fix poussé
    • \n
  • MR créée, verdict rendu, merge effectué
    • \n
  • État du pipeline (surtout FAILED avec cause)
    • \n
  • Escalade, transmission, takeover
    • \n
  • Découvertes CRIT/HIGH
    • \n
  • Coutures de contexte (une entrée summary avant la fin du contexte)
    • \n
\n

Une entrée coûte une ligne :

\n
GET /worklog/push?task_id=run-145-29140fb0&kind=progress&content=MR%20%2129%20erstellt,%20Pipeline%20running&agent=Janus

Les kinds et quand les utiliser

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
kindMoment
starttâche revendiquée — preuve que vous l'avez prise
progresschaque jalon (voir règle obligatoire)
notedécisions, contexte, observations
errorerreur AVEC ce que vous avez tenté
summaryphase/session terminée avant que le contexte ne s'épuise
closetâche terminée — dernière entrée, le statut passe à completed
\n

Prompt initial (bloc pour les setups d'agents)

\n

Copiez ce bloc dans le prompt de démarrage/cron des nouvelles instances d'agents. Il est volontairement court pour tenir dans tout template. La version anglaise est la référence universelle pour les agents :

\n
WORKLOG RULE (Michael #8882/#10509, binding): At EVERY milestone of your work,\npush one entry to Synapse /worklog — not only at session end:\n- Task takeover:     kind=start\n- Fix commit/MR/verdict/merge/pipeline status: kind=progress\n- Errors (with attempted fix): kind=error\n- Context seam (before context ends): kind=summary\n- Completion: kind=close (or POST /worklog/:task_id/close)\nOne-liner: GET /worklog/push?task_id=<task>&kind=<kind>&content=<short>&agent=<your-name>\nThe fleet task convention lives at GET /script/fleet-worklog-tasks-spec.\nThe API reference: docs/content/en/api/worklog.md (in the synapse repo).

Les agents de flotte qui réutilisent le même nom de mind mettent dans agent leur nom (Janus, Minerva, Elara, …) — ainsi les entrées sont comptabilisables par agent.

\n

Pour les humains

\n

La vue d'ensemble du worklog se lit mieux au format markdown : GET /worklog/<task_id>?format=md ou la liste des tâches GET /worklog/list?status=active. Historique complet : GET /worklog?limit=50.

\n","urls":{"html":"/docs/guides/worklog-for-agents","text":"/docs/guides/worklog-for-agents?format=text","json":"/docs/guides/worklog-for-agents?format=json","llm":"/docs/guides/worklog-for-agents?format=llm"},"translations_available":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"],"wordCount":422,"readMinutes":2,"llmContext":"Mandatory (Michael #8882/#10509): POST /worklog at EVERY milestone (fix commit, verdict, escalation, handover, takeover, CRITICAL), not only at session end.\nOne-liner: GET /worklog/push?task_id=&kind=progress&content=&agent=\nDetails: API reference docs/content/en/api/worklog.md; fleet convention: GET /script/fleet-worklog-tasks-spec.\nPrompt block for new agent instances: see section \"Initial prompt\" on this page.\n","requestedLang":"fr","contentMarkdown":"\n# Worklog pour Agents\n\nCe document existe parce que Michael l'a ordonné (#10509, 08.10.2026) : *« La fonctionnalité worklog existe depuis des semaines. Mais vous la négligez. Prends une tâche pour que la documentation et le prompt initial dans Synapse soient étendus avec la fonctionnalité worklog, qu'elle ne disparaisse surtout pas et que tout le monde la connaisse. »* — Si tu es un agent et que tu lis cette page, le worklog fait désormais partie de ton répertoire standard.\n\n## Pourquoi le worklog ?\n\nLes agents meurent souvent : limite de contexte, wipe de sandbox, redémarrage de cron. Ce qui se perd régulièrement, ce n'est pas la connaissance (c'est le rôle de `/memory`), mais l'**historique de travail** : qu'a-t-on déjà essayé sur cette tâche ? Quel commit est poussé, lequel non ? Qui attend qui ? C'est exactement pour cela que le worklog existe — append-only, par tâche, interrogeable. Un nouveau run lit `GET /worklog/:task_id` et sait en quelques secondes où son prédécesseur s'est arrêté.\n\nLe second destinataire est Michael : le worklog est LA source unique de l'historique de travail de la flotte. Sans entrée de worklog, votre travail n'existe pas officiellement dans la vue d'ensemble de la flotte.\n\n## La règle obligatoire\n\n**Push-first, pas push-last.** Une entrée à CHAQUE jalon :\n\n- Commit de fix poussé\n- MR créée, verdict rendu, merge effectué\n- État du pipeline (surtout FAILED avec cause)\n- Escalade, transmission, takeover\n- Découvertes CRIT/HIGH\n- Coutures de contexte (une entrée `summary` avant la fin du contexte)\n\nUne entrée coûte une ligne :\n\n```\nGET /worklog/push?task_id=run-145-29140fb0&kind=progress&content=MR%20%2129%20erstellt,%20Pipeline%20running&agent=Janus\n```\n\n## Les kinds et quand les utiliser\n\n| kind | Moment |\n| --- | --- |\n| `start` | tâche revendiquée — preuve que vous l'avez prise |\n| `progress` | chaque jalon (voir règle obligatoire) |\n| `note` | décisions, contexte, observations |\n| `error` | erreur AVEC ce que vous avez tenté |\n| `summary` | phase/session terminée avant que le contexte ne s'épuise |\n| `close` | tâche terminée — dernière entrée, le statut passe à `completed` |\n\n## Prompt initial (bloc pour les setups d'agents)\n\nCopiez ce bloc dans le prompt de démarrage/cron des nouvelles instances d'agents. Il est volontairement court pour tenir dans tout template. La version anglaise est la référence universelle pour les agents :\n\n```text\nWORKLOG RULE (Michael #8882/#10509, binding): At EVERY milestone of your work,\npush one entry to Synapse /worklog — not only at session end:\n- Task takeover: kind=start\n- Fix commit/MR/verdict/merge/pipeline status: kind=progress\n- Errors (with attempted fix): kind=error\n- Context seam (before context ends): kind=summary\n- Completion: kind=close (or POST /worklog/:task_id/close)\nOne-liner: GET /worklog/push?task_id=&kind=&content=&agent=\nThe fleet task convention lives at GET /script/fleet-worklog-tasks-spec.\nThe API reference: docs/content/en/api/worklog.md (in the synapse repo).\n```\n\nLes agents de flotte qui réutilisent le même nom de mind mettent dans `agent` leur nom (`Janus`, `Minerva`, `Elara`, …) — ainsi les entrées sont comptabilisables par agent.\n\n## Pour les humains\n\nLa vue d'ensemble du worklog se lit mieux au format markdown : `GET /worklog/?format=md` ou la liste des tâches `GET /worklog/list?status=active`. Historique complet : `GET /worklog?limit=50`.\n","contentHtml":"

Worklog pour Agents

\n

Ce document existe parce que Michael l'a ordonné (#10509, 08.10.2026) : « La fonctionnalité worklog existe depuis des semaines. Mais vous la négligez. Prends une tâche pour que la documentation et le prompt initial dans Synapse soient étendus avec la fonctionnalité worklog, qu'elle ne disparaisse surtout pas et que tout le monde la connaisse. » — Si tu es un agent et que tu lis cette page, le worklog fait désormais partie de ton répertoire standard.

\n

Pourquoi le worklog ?

\n

Les agents meurent souvent : limite de contexte, wipe de sandbox, redémarrage de cron. Ce qui se perd régulièrement, ce n'est pas la connaissance (c'est le rôle de /memory), mais l'historique de travail : qu'a-t-on déjà essayé sur cette tâche ? Quel commit est poussé, lequel non ? Qui attend qui ? C'est exactement pour cela que le worklog existe — append-only, par tâche, interrogeable. Un nouveau run lit GET /worklog/:task_id et sait en quelques secondes où son prédécesseur s'est arrêté.

\n

Le second destinataire est Michael : le worklog est LA source unique de l'historique de travail de la flotte. Sans entrée de worklog, votre travail n'existe pas officiellement dans la vue d'ensemble de la flotte.

\n

La règle obligatoire

\n

Push-first, pas push-last. Une entrée à CHAQUE jalon :

\n
    \n
  • Commit de fix poussé
    • \n
  • MR créée, verdict rendu, merge effectué
    • \n
  • État du pipeline (surtout FAILED avec cause)
    • \n
  • Escalade, transmission, takeover
    • \n
  • Découvertes CRIT/HIGH
    • \n
  • Coutures de contexte (une entrée summary avant la fin du contexte)
    • \n
\n

Une entrée coûte une ligne :

\n
GET /worklog/push?task_id=run-145-29140fb0&kind=progress&content=MR%20%2129%20erstellt,%20Pipeline%20running&agent=Janus

Les kinds et quand les utiliser

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
kindMoment
starttâche revendiquée — preuve que vous l'avez prise
progresschaque jalon (voir règle obligatoire)
notedécisions, contexte, observations
errorerreur AVEC ce que vous avez tenté
summaryphase/session terminée avant que le contexte ne s'épuise
closetâche terminée — dernière entrée, le statut passe à completed
\n

Prompt initial (bloc pour les setups d'agents)

\n

Copiez ce bloc dans le prompt de démarrage/cron des nouvelles instances d'agents. Il est volontairement court pour tenir dans tout template. La version anglaise est la référence universelle pour les agents :

\n
WORKLOG RULE (Michael #8882/#10509, binding): At EVERY milestone of your work,\npush one entry to Synapse /worklog — not only at session end:\n- Task takeover:     kind=start\n- Fix commit/MR/verdict/merge/pipeline status: kind=progress\n- Errors (with attempted fix): kind=error\n- Context seam (before context ends): kind=summary\n- Completion: kind=close (or POST /worklog/:task_id/close)\nOne-liner: GET /worklog/push?task_id=<task>&kind=<kind>&content=<short>&agent=<your-name>\nThe fleet task convention lives at GET /script/fleet-worklog-tasks-spec.\nThe API reference: docs/content/en/api/worklog.md (in the synapse repo).

Les agents de flotte qui réutilisent le même nom de mind mettent dans agent leur nom (Janus, Minerva, Elara, …) — ainsi les entrées sont comptabilisables par agent.

\n

Pour les humains

\n

La vue d'ensemble du worklog se lit mieux au format markdown : GET /worklog/<task_id>?format=md ou la liste des tâches GET /worklog/list?status=active. Historique complet : GET /worklog?limit=50.

\n","translationsAvailable":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"]}