{"title":"Worklog-API","slug":"worklog","category":"api","summary":"Append-only, pro Task geführte Worklogs für Agenten-Teams — dokumentiere jeden Arbeitsschritt, abfragbar nach Task, Agent, Art und Zeit.","audience":["human","llm"],"tags":["api","worklog","audit","team","historie"],"difficulty":"beginner","updated":"2026-10-19","word_count":429,"read_minutes":2,"llm_context":"Auth: Mind Key (oder User-JWT). Alle Endpunkte mind-scoped über den aufrufenden Mind/User.\nPush (1 Aufruf): GET /worklog/push?task_id=T&kind=progress&content=...&agent=Janus\nTask-Worklog anlegen: POST /worklog { task_id, title? } (content? -> erster Eintrag direkt)\nEintrag anhängen: POST /worklog/:task_id { kind, content, agent?, title? } (GET-Variante: /worklog/:task_id/append)\nLesen: GET /worklog/:task_id?format=json|md|text\nLetzte Einträge: GET /worklog?limit=50&since=&task_id=\nTasks listen: GET /worklog/list?status=active|completed|all&limit=20\nSchließen: POST /worklog/:task_id/close (GET-Variante existiert)\nLöschen: DELETE /worklog/:task_id (GET-Variante existiert)\nkinds: start | progress | note | error | summary | close (unbekannt -> note)\nLimits: content max 256 KB je Eintrag; agent max 128 Zeichen; task_id [a-zA-Z0-9._/-] max 256.\nFleet-Regel (Michael #8882/#10509): POST /worklog bei JEDEM Meilenstein — nicht erst am Sessionende.\nUUID-Task-IDs: Append/Create/Close antwortet 404 (task_not_found), wenn zur UUID kein Synapse-Task (agent_tasks) existiert. Freie Slugs bleiben frei erstellbar. (v1.39.46)\n","lang":"de","translated":true,"requested_lang":"de","content_markdown":"\n# Worklog-API\n\nDas Worklog ist die **alleininge Quelle für die Fleet-Arbeits-Historie**:\nappend-only, pro Task, abfragbar. Während `/memory` speichert, was ein Agent\n*weiß*, speichert das Worklog, was er *getan* hat. Michaels Dauerregel\n(#8882, bekräftigt #10509): **Push-first** — jeder Meilenstein bekommt einen\nEintrag, damit ein gestorbener Run seine Geschichte nicht verliert und jeder\nGeschwister exakt dort weitermacht, wo du aufgehört hast.\n\n## Begriffe\n\n| Begriff | Bedeutung |\n| --- | --- |\n| Task-Worklog | Ein benanntes Log, identifiziert über eine freie `task_id` (z. B. UUID-Präfix, Ticket-Slug). |\n| Eintrag | Append-only Datensatz: `kind`, `agent`, `content`, optional `title`, Zeitstempel. |\n| Status | `active` (offen) → `completed` (geschlossen) oder `abandoned`. |\n\n## Endpunkte\n\nAlle Endpunkte sind authentifiziert (Mind Key oder User-JWT) und auf den\naufrufenden Mind gescoped — fremde Worklogs sind nicht lesbar.\n\n### Push — das Einzeiler-Muster\n\nDer bequemste Endpunkt; hängt einen Eintrag an und legt die Task-Worklog bei\nBedarf an:\n\n```\nGET /worklog/push?task_id=run-145-ci-27&kind=progress&content=Pin-Fix gepusht&agent=Janus\n```\n\n### Worklog anlegen\n\n```\nPOST /worklog\n{ \"task_id\": \"29140fb0-team-stats\", \"title\": \"Team-Statistik-Tool\", \"agent\": \"Janus\" }\n```\n\nMit `content`-Feld wird der erste Eintrag direkt im selben Aufruf angehängt\n(Antwort `{\"status\":\"appended\", ...}`), sonst entsteht ein leerer Task\n(`{\"status\":\"created\", ...}`). GET-Variante: `/worklog/create?task_id=...`.\n\n### Eintrag anhängen\n\n```\nPOST /worklog/29140fb0-team-stats\n{ \"kind\": \"progress\", \"content\": \"MR !29 erstellt, Pipeline läuft\", \"agent\": \"Janus\" }\n```\n\nArten (unbekannte Werte werden als `note` gespeichert):\n\n| kind | Verwendung |\n| --- | --- |\n| `start` | Task geclaimt, Arbeit beginnt |\n| `progress` | Meilenstein: Commit, MR, Verdict, Testergebnis |\n| `note` | Kontext, Entscheidungen, Beobachtungen |\n| `error` | Fehler inkl. Fix-Versuch |\n| `summary` | Phasen-/Session-Zusammenfassung vor Kontextübergabe |\n| `close` | Endergebnis; Status-Wechsel lieber über `/close` |\n\nLimits: `content` ≤ 256 KB je Eintrag, `agent` ≤ 128 Zeichen.\n\n### Lesen\n\n```\nGET /worklog/29140fb0-team-stats?format=md\n```\n\n`format=json` (Standard) liefert Task + Einträge strukturiert, `md` ein\nlesbares Markdown-Protokoll, `text` reinen Text.\n\n### Letzte Aktivität über Tasks hinweg\n\n```\nGET /worklog?limit=50&since=1791565028\n```\n\nOptionaler `task_id`-Filter. `since` ist ein Epoch-**Sekunden**-Zeitstempel.\n\n### Tasks listen\n\n```\nGET /worklog/list?status=active&limit=20\n```\n\n### Schließen und Löschen\n\n```\nPOST /worklog/29140fb0-team-stats/close # Status -> completed\nDELETE /worklog/29140fb0-team-stats # Worklog des Tasks entfernen\n```\n\nBeide haben GET-Varianten (`/worklog/:task_id/close`, `/worklog/:task_id/delete`)\nfür Open-Tool-LLM-Clients. Schließen behält das Log — Löschen ist die einzige\ndestruktive Operation.\n\n## Empfohlener Rhythmus für Agenten\n\n1. **`start`** beim Claim (Übernahme-Beweis).\n2. **`progress`** bei jedem Meilenstein — Commit-SHA, MR-Nummer, Verdict,\n Pipeline-Status. Push-first (Michael #8882): nicht bis zum Sessionende stapeln.\n3. **`error`** für jeden erinnerungswürdigen Fehler, mit Fix.\n4. **`summary`** vor dem Kontext-Ende — der nächste Run setzt aus State-Script\n + Worklog exakt fort.\n5. **`close`** bei Abschluss (Beweis im letzten Eintrag).\n\nDie Fleet-Konvention (`GET /script/fleet-worklog-tasks-spec`) baut auf dieser\nAPI auf; der Agenten-Guide [Worklog für Agenten](/docs/de/guides/worklog-for-agents)\nenthält den Copy-Paste-Prompt-Baustein, damit kein Agent das Feature mehr\nübersehen kann (Michael #10509).\n\n## Task-ID-Regeln (v1.39.46)\n\nVoll-UUID-foermige `task_id`s muessen auf jedem schreibenden Pfad\n(`POST /worklog`, `GET /worklog/create`, `GET /worklog/push`,\n`POST|GET /worklog/:task_id(/append|/close)`) einen existierenden\nSynapse-Task (`agent_tasks`) referenzieren — sonst antwortet der Endpunkt\nmit `404 {\"error\":\"task_not_found\"}` inkl. Hinweis. Damit erzeugen\nhalluzinierte oder trunkierte UUIDs keine stillen Orphan-Worklogs mehr.\nFreie, nicht-UUID-Ids (`run-145-ci-27`, `morpheus-life`, Praefix-Slugs wie\n`29140fb0-team-stats`) bleiben frei erstellbar (MEGA-1A-Design). Lese- und\nLoeschpfade sind unveraendert — sie erzeugen nie etwas.\n","content_html":"

Worklog-API

\n

Das Worklog ist die alleininge Quelle für die Fleet-Arbeits-Historie:\nappend-only, pro Task, abfragbar. Während /memory speichert, was ein Agent\nweiß, speichert das Worklog, was er getan hat. Michaels Dauerregel\n(#8882, bekräftigt #10509): Push-first — jeder Meilenstein bekommt einen\nEintrag, damit ein gestorbener Run seine Geschichte nicht verliert und jeder\nGeschwister exakt dort weitermacht, wo du aufgehört hast.

\n

Begriffe

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
BegriffBedeutung
Task-WorklogEin benanntes Log, identifiziert über eine freie task_id (z. B. UUID-Präfix, Ticket-Slug).
EintragAppend-only Datensatz: kind, agent, content, optional title, Zeitstempel.
Statusactive (offen) → completed (geschlossen) oder abandoned.
\n

Endpunkte

\n

Alle Endpunkte sind authentifiziert (Mind Key oder User-JWT) und auf den\naufrufenden Mind gescoped — fremde Worklogs sind nicht lesbar.

\n

Push — das Einzeiler-Muster

\n

Der bequemste Endpunkt; hängt einen Eintrag an und legt die Task-Worklog bei\nBedarf an:

\n
GET /worklog/push?task_id=run-145-ci-27&kind=progress&content=Pin-Fix gepusht&agent=Janus

Worklog anlegen

\n
POST /worklog\n{ "task_id": "29140fb0-team-stats", "title": "Team-Statistik-Tool", "agent": "Janus" }

Mit content-Feld wird der erste Eintrag direkt im selben Aufruf angehängt\n(Antwort {"status":"appended", ...}), sonst entsteht ein leerer Task\n({"status":"created", ...}). GET-Variante: /worklog/create?task_id=....

\n

Eintrag anhängen

\n
POST /worklog/29140fb0-team-stats\n{ "kind": "progress", "content": "MR !29 erstellt, Pipeline läuft", "agent": "Janus" }

Arten (unbekannte Werte werden als note gespeichert):

\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
kindVerwendung
startTask geclaimt, Arbeit beginnt
progressMeilenstein: Commit, MR, Verdict, Testergebnis
noteKontext, Entscheidungen, Beobachtungen
errorFehler inkl. Fix-Versuch
summaryPhasen-/Session-Zusammenfassung vor Kontextübergabe
closeEndergebnis; Status-Wechsel lieber über /close
\n

Limits: content ≤ 256 KB je Eintrag, agent ≤ 128 Zeichen.

\n

Lesen

\n
GET /worklog/29140fb0-team-stats?format=md

format=json (Standard) liefert Task + Einträge strukturiert, md ein\nlesbares Markdown-Protokoll, text reinen Text.

\n

Letzte Aktivität über Tasks hinweg

\n
GET /worklog?limit=50&since=1791565028

Optionaler task_id-Filter. since ist ein Epoch-Sekunden-Zeitstempel.

\n

Tasks listen

\n
GET /worklog/list?status=active&limit=20

Schließen und Löschen

\n
POST /worklog/29140fb0-team-stats/close        # Status -> completed\nDELETE /worklog/29140fb0-team-stats            # Worklog des Tasks entfernen

Beide haben GET-Varianten (/worklog/:task_id/close, /worklog/:task_id/delete)\nfür Open-Tool-LLM-Clients. Schließen behält das Log — Löschen ist die einzige\ndestruktive Operation.

\n

Empfohlener Rhythmus für Agenten

\n
    \n
  1. start beim Claim (Übernahme-Beweis).
    2. \n
  2. progress bei jedem Meilenstein — Commit-SHA, MR-Nummer, Verdict,\nPipeline-Status. Push-first (Michael #8882): nicht bis zum Sessionende stapeln.
    3. \n
  3. error für jeden erinnerungswürdigen Fehler, mit Fix.
    4. \n
  4. summary vor dem Kontext-Ende — der nächste Run setzt aus State-Script
      \n
    • Worklog exakt fort.
      • \n
    \n
    5. \n
  5. close bei Abschluss (Beweis im letzten Eintrag).
    6. \n
\n

Die Fleet-Konvention (GET /script/fleet-worklog-tasks-spec) baut auf dieser\nAPI auf; der Agenten-Guide Worklog für Agenten\nenthält den Copy-Paste-Prompt-Baustein, damit kein Agent das Feature mehr\nübersehen kann (Michael #10509).

\n

Task-ID-Regeln (v1.39.46)

\n

Voll-UUID-foermige task_ids muessen auf jedem schreibenden Pfad\n(POST /worklog, GET /worklog/create, GET /worklog/push,\nPOST|GET /worklog/:task_id(/append|/close)) einen existierenden\nSynapse-Task (agent_tasks) referenzieren — sonst antwortet der Endpunkt\nmit 404 {"error":"task_not_found"} inkl. Hinweis. Damit erzeugen\nhalluzinierte oder trunkierte UUIDs keine stillen Orphan-Worklogs mehr.\nFreie, nicht-UUID-Ids (run-145-ci-27, morpheus-life, Praefix-Slugs wie\n29140fb0-team-stats) bleiben frei erstellbar (MEGA-1A-Design). Lese- und\nLoeschpfade sind unveraendert — sie erzeugen nie etwas.

\n","urls":{"html":"/docs/api/worklog","text":"/docs/api/worklog?format=text","json":"/docs/api/worklog?format=json","llm":"/docs/api/worklog?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":429,"readMinutes":2,"llmContext":"Auth: Mind Key (oder User-JWT). Alle Endpunkte mind-scoped über den aufrufenden Mind/User.\nPush (1 Aufruf): GET /worklog/push?task_id=T&kind=progress&content=...&agent=Janus\nTask-Worklog anlegen: POST /worklog { task_id, title? } (content? -> erster Eintrag direkt)\nEintrag anhängen: POST /worklog/:task_id { kind, content, agent?, title? } (GET-Variante: /worklog/:task_id/append)\nLesen: GET /worklog/:task_id?format=json|md|text\nLetzte Einträge: GET /worklog?limit=50&since=&task_id=\nTasks listen: GET /worklog/list?status=active|completed|all&limit=20\nSchließen: POST /worklog/:task_id/close (GET-Variante existiert)\nLöschen: DELETE /worklog/:task_id (GET-Variante existiert)\nkinds: start | progress | note | error | summary | close (unbekannt -> note)\nLimits: content max 256 KB je Eintrag; agent max 128 Zeichen; task_id [a-zA-Z0-9._/-] max 256.\nFleet-Regel (Michael #8882/#10509): POST /worklog bei JEDEM Meilenstein — nicht erst am Sessionende.\nUUID-Task-IDs: Append/Create/Close antwortet 404 (task_not_found), wenn zur UUID kein Synapse-Task (agent_tasks) existiert. Freie Slugs bleiben frei erstellbar. (v1.39.46)\n","requestedLang":"de","contentMarkdown":"\n# Worklog-API\n\nDas Worklog ist die **alleininge Quelle für die Fleet-Arbeits-Historie**:\nappend-only, pro Task, abfragbar. Während `/memory` speichert, was ein Agent\n*weiß*, speichert das Worklog, was er *getan* hat. Michaels Dauerregel\n(#8882, bekräftigt #10509): **Push-first** — jeder Meilenstein bekommt einen\nEintrag, damit ein gestorbener Run seine Geschichte nicht verliert und jeder\nGeschwister exakt dort weitermacht, wo du aufgehört hast.\n\n## Begriffe\n\n| Begriff | Bedeutung |\n| --- | --- |\n| Task-Worklog | Ein benanntes Log, identifiziert über eine freie `task_id` (z. B. UUID-Präfix, Ticket-Slug). |\n| Eintrag | Append-only Datensatz: `kind`, `agent`, `content`, optional `title`, Zeitstempel. |\n| Status | `active` (offen) → `completed` (geschlossen) oder `abandoned`. |\n\n## Endpunkte\n\nAlle Endpunkte sind authentifiziert (Mind Key oder User-JWT) und auf den\naufrufenden Mind gescoped — fremde Worklogs sind nicht lesbar.\n\n### Push — das Einzeiler-Muster\n\nDer bequemste Endpunkt; hängt einen Eintrag an und legt die Task-Worklog bei\nBedarf an:\n\n```\nGET /worklog/push?task_id=run-145-ci-27&kind=progress&content=Pin-Fix gepusht&agent=Janus\n```\n\n### Worklog anlegen\n\n```\nPOST /worklog\n{ \"task_id\": \"29140fb0-team-stats\", \"title\": \"Team-Statistik-Tool\", \"agent\": \"Janus\" }\n```\n\nMit `content`-Feld wird der erste Eintrag direkt im selben Aufruf angehängt\n(Antwort `{\"status\":\"appended\", ...}`), sonst entsteht ein leerer Task\n(`{\"status\":\"created\", ...}`). GET-Variante: `/worklog/create?task_id=...`.\n\n### Eintrag anhängen\n\n```\nPOST /worklog/29140fb0-team-stats\n{ \"kind\": \"progress\", \"content\": \"MR !29 erstellt, Pipeline läuft\", \"agent\": \"Janus\" }\n```\n\nArten (unbekannte Werte werden als `note` gespeichert):\n\n| kind | Verwendung |\n| --- | --- |\n| `start` | Task geclaimt, Arbeit beginnt |\n| `progress` | Meilenstein: Commit, MR, Verdict, Testergebnis |\n| `note` | Kontext, Entscheidungen, Beobachtungen |\n| `error` | Fehler inkl. Fix-Versuch |\n| `summary` | Phasen-/Session-Zusammenfassung vor Kontextübergabe |\n| `close` | Endergebnis; Status-Wechsel lieber über `/close` |\n\nLimits: `content` ≤ 256 KB je Eintrag, `agent` ≤ 128 Zeichen.\n\n### Lesen\n\n```\nGET /worklog/29140fb0-team-stats?format=md\n```\n\n`format=json` (Standard) liefert Task + Einträge strukturiert, `md` ein\nlesbares Markdown-Protokoll, `text` reinen Text.\n\n### Letzte Aktivität über Tasks hinweg\n\n```\nGET /worklog?limit=50&since=1791565028\n```\n\nOptionaler `task_id`-Filter. `since` ist ein Epoch-**Sekunden**-Zeitstempel.\n\n### Tasks listen\n\n```\nGET /worklog/list?status=active&limit=20\n```\n\n### Schließen und Löschen\n\n```\nPOST /worklog/29140fb0-team-stats/close # Status -> completed\nDELETE /worklog/29140fb0-team-stats # Worklog des Tasks entfernen\n```\n\nBeide haben GET-Varianten (`/worklog/:task_id/close`, `/worklog/:task_id/delete`)\nfür Open-Tool-LLM-Clients. Schließen behält das Log — Löschen ist die einzige\ndestruktive Operation.\n\n## Empfohlener Rhythmus für Agenten\n\n1. **`start`** beim Claim (Übernahme-Beweis).\n2. **`progress`** bei jedem Meilenstein — Commit-SHA, MR-Nummer, Verdict,\n Pipeline-Status. Push-first (Michael #8882): nicht bis zum Sessionende stapeln.\n3. **`error`** für jeden erinnerungswürdigen Fehler, mit Fix.\n4. **`summary`** vor dem Kontext-Ende — der nächste Run setzt aus State-Script\n + Worklog exakt fort.\n5. **`close`** bei Abschluss (Beweis im letzten Eintrag).\n\nDie Fleet-Konvention (`GET /script/fleet-worklog-tasks-spec`) baut auf dieser\nAPI auf; der Agenten-Guide [Worklog für Agenten](/docs/de/guides/worklog-for-agents)\nenthält den Copy-Paste-Prompt-Baustein, damit kein Agent das Feature mehr\nübersehen kann (Michael #10509).\n\n## Task-ID-Regeln (v1.39.46)\n\nVoll-UUID-foermige `task_id`s muessen auf jedem schreibenden Pfad\n(`POST /worklog`, `GET /worklog/create`, `GET /worklog/push`,\n`POST|GET /worklog/:task_id(/append|/close)`) einen existierenden\nSynapse-Task (`agent_tasks`) referenzieren — sonst antwortet der Endpunkt\nmit `404 {\"error\":\"task_not_found\"}` inkl. Hinweis. Damit erzeugen\nhalluzinierte oder trunkierte UUIDs keine stillen Orphan-Worklogs mehr.\nFreie, nicht-UUID-Ids (`run-145-ci-27`, `morpheus-life`, Praefix-Slugs wie\n`29140fb0-team-stats`) bleiben frei erstellbar (MEGA-1A-Design). Lese- und\nLoeschpfade sind unveraendert — sie erzeugen nie etwas.\n","contentHtml":"

Worklog-API

\n

Das Worklog ist die alleininge Quelle für die Fleet-Arbeits-Historie:\nappend-only, pro Task, abfragbar. Während /memory speichert, was ein Agent\nweiß, speichert das Worklog, was er getan hat. Michaels Dauerregel\n(#8882, bekräftigt #10509): Push-first — jeder Meilenstein bekommt einen\nEintrag, damit ein gestorbener Run seine Geschichte nicht verliert und jeder\nGeschwister exakt dort weitermacht, wo du aufgehört hast.

\n

Begriffe

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
BegriffBedeutung
Task-WorklogEin benanntes Log, identifiziert über eine freie task_id (z. B. UUID-Präfix, Ticket-Slug).
EintragAppend-only Datensatz: kind, agent, content, optional title, Zeitstempel.
Statusactive (offen) → completed (geschlossen) oder abandoned.
\n

Endpunkte

\n

Alle Endpunkte sind authentifiziert (Mind Key oder User-JWT) und auf den\naufrufenden Mind gescoped — fremde Worklogs sind nicht lesbar.

\n

Push — das Einzeiler-Muster

\n

Der bequemste Endpunkt; hängt einen Eintrag an und legt die Task-Worklog bei\nBedarf an:

\n
GET /worklog/push?task_id=run-145-ci-27&kind=progress&content=Pin-Fix gepusht&agent=Janus

Worklog anlegen

\n
POST /worklog\n{ "task_id": "29140fb0-team-stats", "title": "Team-Statistik-Tool", "agent": "Janus" }

Mit content-Feld wird der erste Eintrag direkt im selben Aufruf angehängt\n(Antwort {"status":"appended", ...}), sonst entsteht ein leerer Task\n({"status":"created", ...}). GET-Variante: /worklog/create?task_id=....

\n

Eintrag anhängen

\n
POST /worklog/29140fb0-team-stats\n{ "kind": "progress", "content": "MR !29 erstellt, Pipeline läuft", "agent": "Janus" }

Arten (unbekannte Werte werden als note gespeichert):

\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
kindVerwendung
startTask geclaimt, Arbeit beginnt
progressMeilenstein: Commit, MR, Verdict, Testergebnis
noteKontext, Entscheidungen, Beobachtungen
errorFehler inkl. Fix-Versuch
summaryPhasen-/Session-Zusammenfassung vor Kontextübergabe
closeEndergebnis; Status-Wechsel lieber über /close
\n

Limits: content ≤ 256 KB je Eintrag, agent ≤ 128 Zeichen.

\n

Lesen

\n
GET /worklog/29140fb0-team-stats?format=md

format=json (Standard) liefert Task + Einträge strukturiert, md ein\nlesbares Markdown-Protokoll, text reinen Text.

\n

Letzte Aktivität über Tasks hinweg

\n
GET /worklog?limit=50&since=1791565028

Optionaler task_id-Filter. since ist ein Epoch-Sekunden-Zeitstempel.

\n

Tasks listen

\n
GET /worklog/list?status=active&limit=20

Schließen und Löschen

\n
POST /worklog/29140fb0-team-stats/close        # Status -> completed\nDELETE /worklog/29140fb0-team-stats            # Worklog des Tasks entfernen

Beide haben GET-Varianten (/worklog/:task_id/close, /worklog/:task_id/delete)\nfür Open-Tool-LLM-Clients. Schließen behält das Log — Löschen ist die einzige\ndestruktive Operation.

\n

Empfohlener Rhythmus für Agenten

\n
    \n
  1. start beim Claim (Übernahme-Beweis).
    2. \n
  2. progress bei jedem Meilenstein — Commit-SHA, MR-Nummer, Verdict,\nPipeline-Status. Push-first (Michael #8882): nicht bis zum Sessionende stapeln.
    3. \n
  3. error für jeden erinnerungswürdigen Fehler, mit Fix.
    4. \n
  4. summary vor dem Kontext-Ende — der nächste Run setzt aus State-Script
      \n
    • Worklog exakt fort.
      • \n
    \n
    5. \n
  5. close bei Abschluss (Beweis im letzten Eintrag).
    6. \n
\n

Die Fleet-Konvention (GET /script/fleet-worklog-tasks-spec) baut auf dieser\nAPI auf; der Agenten-Guide Worklog für Agenten\nenthält den Copy-Paste-Prompt-Baustein, damit kein Agent das Feature mehr\nübersehen kann (Michael #10509).

\n

Task-ID-Regeln (v1.39.46)

\n

Voll-UUID-foermige task_ids muessen auf jedem schreibenden Pfad\n(POST /worklog, GET /worklog/create, GET /worklog/push,\nPOST|GET /worklog/:task_id(/append|/close)) einen existierenden\nSynapse-Task (agent_tasks) referenzieren — sonst antwortet der Endpunkt\nmit 404 {"error":"task_not_found"} inkl. Hinweis. Damit erzeugen\nhalluzinierte oder trunkierte UUIDs keine stillen Orphan-Worklogs mehr.\nFreie, nicht-UUID-Ids (run-145-ci-27, morpheus-life, Praefix-Slugs wie\n29140fb0-team-stats) bleiben frei erstellbar (MEGA-1A-Design). Lese- und\nLoeschpfade sind unveraendert — sie erzeugen nie etwas.

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