[{"data":1,"prerenderedAt":869},["ShallowReactive",2],{"search-de":3,"content-de-guide\u002Fcode-tasks":4,"surround-de-\u002Fguide\u002Fcode-tasks":860},[],{"id":5,"title":6,"body":7,"description":852,"extension":853,"meta":854,"navigation":855,"path":856,"seo":857,"stem":858,"__hash__":859},"content_de\u002F1.guide\u002F34.code-tasks.md","Code-Aufgaben",{"type":8,"value":9,"toc":835},"minimark",[10,23,37,42,56,97,124,128,135,146,159,185,189,192,293,303,306,399,427,431,444,500,503,558,561,706,719,731,734,737,759,762,783,786,789,792,824],[11,12,13,14,18,19,22],"p",{},"Code-Aufgaben sind eine Warteschlange für den KI-Coding-Agenten. Eine Aufgabe trägt eine umgangssprachliche Beschreibung eines Features oder Bugfixes; der ",[15,16,17],"strong",{},"code-worker","-Sidecar ist dafür ausgelegt, sie aufzunehmen, Ihr Repository zu klonen, die Änderung mit einem Coding-Agenten zu schreiben, die Test-Suite auszuführen und einen Pull Request zu eröffnen, den Sie prüfen können. Das Dashboard unter ",[15,20,21],{},"Postfach -> Code-Aufgaben"," zeigt jede Aufgabe und ihre aktuelle Stufe. Das ist eine Admin-Oberfläche — nur Owner und Admins können Aufgaben anlegen oder abbrechen.",[11,24,25,26,30,31,36],{},"Die Backend-Warteschlange und das Dashboard funktionieren bereits heute, und der code-worker-Sidecar authentifiziert sich mit dem Admin-Key des Deployments, beansprucht Aufgaben aus der Warteschlange und meldet den Fortschritt zurück. Beide mitgelieferten Compose-Stacks — der Dev-Stack und das VPS-Template — reichen ",[27,28,29],"code",{},"CONVEX_ADMIN_KEY"," an den code-worker-Service durch, sodass eine Standardinstallation den Worker startet, sobald Sie das Profil aktivieren (siehe ",[32,33,35],"a",{"href":34},"#setup-the-code-worker-service-and-its-environment","Setup",").",[38,39,41],"h2",{"id":40},"was-code-aufgaben-sind","Was Code-Aufgaben sind",[11,43,44,45,48,49,52,53,55],{},"Das Feature besteht aus zwei Hälften: der ",[15,46,47],{},"Warteschlange",", die im Owlat-Backend liegt (die Tabelle ",[27,50,51],{},"codeWorkTasks","), und dem ",[15,54,17],{},", einem separaten Docker-Container, der die eigentliche Programmierarbeit erledigt. Das Dashboard liest Aufgaben lediglich und bricht sie ab; die eigentliche Arbeit passiert außerhalb des Prozesses im Sidecar.",[11,57,58,59,62,63,66,67,70,71,74,75,78,79,82,83,85,86,88,89,91,92,96],{},"Code-Aufgaben sind durch das Feature-Flag ",[15,60,61],{},"Code-Aufgaben aus dem Postfach extrahieren"," (",[27,64,65],{},"inbox.codeTasks",") abgesichert, das ",[15,68,69],{},"standardmäßig deaktiviert"," ist. Weil das Flag sowohl ",[27,72,73],{},"inbox"," als auch ",[27,76,77],{},"ai.agent"," voraussetzt (",[27,80,81],{},"requires","), aktiviert das Einschalten auch diese beiden; und wenn Sie ",[27,84,77],{}," wieder ausschalten, kaskadiert das die Code-Aufgaben ebenfalls aus. Ist das Flag aktiv, erscheint im Postfach-Abschnitt der Seitenleiste ein Eintrag ",[15,87,6],{},"; ist es aus, verschwindet der Eintrag aus der Seitenleiste, und die Seite selbst ist über die Feature-Voraussetzung ",[27,90,65],{}," abgesichert. Wie Sie es umlegen, lesen Sie unter ",[32,93,95],{"href":94},"\u002Fguide\u002Ffeature-flags","Feature-Flags",".",[98,99,102],"callout",{"title":100,"type":101},"Automatische Erstellung aus eingehender Mail","info",[11,103,104,105,107,108,111,112,115,116,119,120,96],{},"Ist ",[27,106,65],{}," aktiviert, werden eingehende Nachrichten, die als ",[15,109,110],{},"Feature-Request"," klassifiziert wurden, über ",[27,113,114],{},"createFromInbound"," automatisch in Code-Aufgaben in der Warteschlange verwandelt (idempotent je eingehender Nachricht, sodass dieselbe Nachricht nie zwei Aufgaben anlegt). Die manuelle Erstellung über die Mutation ",[27,117,118],{},"codeWorkTasks.create"," gibt es zusätzlich weiterhin. Siehe ",[32,121,123],{"href":122},"#current-limitations","Aktuelle Einschränkungen",[38,125,127],{"id":126},"eine-aufgabe-anlegen-und-abbrechen","Eine Aufgabe anlegen und abbrechen",[11,129,130,131,134],{},"Eine Aufgabe braucht genau eines: eine ",[15,132,133],{},"Beschreibung"," dessen, was getan werden soll. Schreiben Sie sie so, wie Sie ein Ticket schreiben würden — „Der Kontakttabelle eine Schaltfläche für den CSV-Export hinzufügen“, „Den Off-by-one-Fehler im Datumsbereich des Digests beheben“. Je klarer die Beschreibung, desto besser das Ergebnis des Coding-Agenten, denn dieser Text wird wortgetreu an den Agenten übergeben und wird zur Zusammenfassung des Pull Requests.",[11,136,137,138,141,142,145],{},"Das Anlegen einer Aufgabe erfordert die Berechtigung ",[27,139,140],{},"organization:manage"," (Owner und Admins). Die neue Aufgabe startet in der Stufe ",[15,143,144],{},"in Warteschlange"," und wartet darauf, dass der code-worker sie aufnimmt.",[98,147,149],{"title":148,"type":101},"Eine Aufgabe im Dashboard anlegen",[11,150,151,152,155,156,158],{},"Das Code-Aufgaben-Dashboard hat eine Schaltfläche ",[15,153,154],{},"Neue Code-Aufgabe"," — in der Kopfzeile und im Leerzustand —, die ein Beschreibungs-Modal öffnet und die Aufgabe über die Mutation ",[27,157,118],{}," einreicht (dieselbe Mutation, die Sie auch aus dem Convex-Dashboard, einem Skript oder Ihrem eigenen Tooling aufrufen können). Die Beschreibung muss mindestens 10 Zeichen lang sein. Der unten beschriebene Lebenszyklus gilt unabhängig davon, wie die Aufgabe eingereicht wurde.",[11,160,161,162,165,166,168,169,172,173,176,177,180,181,184],{},"Zum Abbrechen öffnen Sie das Code-Aufgaben-Dashboard und nutzen die Schaltfläche ",[15,163,164],{},"Abbrechen"," auf einer Aufgabenkarte. Die Abbrechen-Schaltfläche des Dashboards erscheint nur bei Aufgaben ",[15,167,144],{}," oder ",[15,170,171],{},"läuft",", doch die zugrunde liegende Mutation ",[27,174,175],{},"codeWorkTasks.cancel"," lehnt nur ",[15,178,179],{},"gemergte"," Aufgaben ab — Aufgaben in Test und Prüfung lassen sich über das Backend weiterhin abbrechen. Ein Abbruch markiert die Aufgabe als ",[15,182,183],{},"fehlgeschlagen"," mit der Meldung „Cancelled by user“ — es gibt keine eigene Stufe „abgebrochen“.",[38,186,188],{"id":187},"aufgaben-lebenszyklus-und-die-pr-test-kostenanzeige","Aufgaben-Lebenszyklus und die PR-\u002FTest-\u002FKostenanzeige",[11,190,191],{},"Eine Aufgabe durchläuft einen festen Satz von Stufen. Der code-worker treibt sie im Laufe seiner Arbeit voran, und das Dashboard spiegelt jeden Übergang in Echtzeit wider.",[193,194,195,211],"table",{},[196,197,198],"thead",{},[199,200,201,205,208],"tr",{},[202,203,204],"th",{},"Stufe",[202,206,207],{},"Badge",[202,209,210],{},"Was sie bedeutet",[212,213,214,228,241,254,267,280],"tbody",{},[199,215,216,222,225],{},[217,218,219],"td",{},[27,220,221],{},"queued",[217,223,224],{},"In Warteschlange",[217,226,227],{},"Eingereicht und wartet darauf, dass der code-worker sie beansprucht.",[199,229,230,235,238],{},[217,231,232],{},[27,233,234],{},"running",[217,236,237],{},"Läuft (pulsierend)",[217,239,240],{},"Der Worker hat die Aufgabe beansprucht, einen Branch eingerichtet und lässt den Coding-Agenten laufen.",[199,242,243,248,251],{},[217,244,245],{},[27,246,247],{},"testing",[217,249,250],{},"Test",[217,252,253],{},"Die Änderung ist committet; der Worker führt die Test-Suite aus.",[199,255,256,261,264],{},[217,257,258],{},[27,259,260],{},"review",[217,262,263],{},"Prüfung",[217,265,266],{},"Ein Pull Request wurde eröffnet. Die Änderung ist bereit dafür, von einem Menschen geprüft und gemerged zu werden.",[199,268,269,274,277],{},[217,270,271],{},[27,272,273],{},"merged",[217,275,276],{},"Gemerged",[217,278,279],{},"Der Pull Request wurde gemerged.",[199,281,282,287,290],{},[217,283,284],{},[27,285,286],{},"failed",[217,288,289],{},"Fehlgeschlagen",[217,291,292],{},"Der Aufgabe sind die Versuche ausgegangen, sie wurde abgebrochen oder sie hat keine Änderungen erzeugt. Der Fehler wird auf der Karte angezeigt.",[11,294,295,296,298,299,96],{},"Ein fehlgeschlagener Lauf beendet die Aufgabe nicht beim ersten Stolpern: Solange noch Versuche übrig sind, geht sie hinter einer wachsenden Verzögerung zurück in die ",[15,297,47],{},", und der Worker nimmt sie erneut auf. Siehe ",[32,300,302],{"href":301},"#automatic-retries","Automatische Wiederholungen",[11,304,305],{},"Jede Aufgabenkarte zeigt das Arbeitsergebnis an, sobald es verfügbar ist:",[193,307,308,318],{},[196,309,310],{},[199,311,312,315],{},[202,313,314],{},"Feld",[202,316,317],{},"Wann es erscheint",[212,319,320,333,343,353,363,389],{},[199,321,322,327],{},[217,323,324],{},[15,325,326],{},"Branch",[217,328,329,330,36],{},"Sobald der Worker den Feature-Branch angelegt hat (benannt ",[27,331,332],{},"code-worker\u002F\u003Ctask-id>",[199,334,335,340],{},[217,336,337],{},[15,338,339],{},"Pull Request",[217,341,342],{},"Ein klickbarer Link zum PR, sobald der Worker einen eröffnet hat.",[199,344,345,350],{},[217,346,347],{},[15,348,349],{},"Testergebnisse",[217,351,352],{},"Ein Auszug der Ausgabe des Test-Runners, aufgezeichnet während der Test-Stufe.",[199,354,355,360],{},[217,356,357],{},[15,358,359],{},"Fehler",[217,361,362],{},"Nur bei fehlgeschlagenen Aufgaben — der Grund, warum die Aufgabe gestoppt hat.",[199,364,365,370],{},[217,366,367],{},[15,368,369],{},"Kosten",[217,371,372,373,376,377,380,381,384,385,388],{},"Die LLM-Ausgaben für den Lauf, auf vier Nachkommastellen angezeigt (z. B. ",[27,374,375],{},"$0.0123","). Das Feld existiert im Schema und in der Oberfläche, doch der code-worker meldet ",[27,378,379],{},"llmCost"," derzeit nicht (es wird nie an ",[27,382,383],{},"completeWithPR","\u002F",[27,386,387],{},"markFailed"," gesendet), sodass die Kosten bei vom Worker ausgeführten Aufgaben in der Praxis leer bleiben.",[199,390,391,396],{},[217,392,393],{},[15,394,395],{},"Erstellt",[217,397,398],{},"Ein relativer Zeitstempel („gerade eben“, „vor 12 Min.“, „vor 3 Tagen“).",[98,400,402],{"title":401,"type":101},"Die Stufe „gemerged“ erreichen",[11,403,404,405,407,408,411,412,415,416,419,420,423,424,426],{},"Der Worker eröffnet den Pull Request und setzt die Aufgabe auf ",[15,406,263],{},". Damit sie automatisch auf ",[15,409,410],{},"gemerged"," weiterrückt, konfigurieren Sie einen GitHub-Webhook, der auf ",[27,413,414],{},"POST \u002Fwebhooks\u002Fgithub"," zeigt, mit dem Secret ",[27,417,418],{},"GITHUB_WEBHOOK_SECRET",". Wird der PR gemerged, benachrichtigt GitHub Owlat, und die Aufgabe wechselt über ",[27,421,422],{},"markMergedByPrUrl"," auf ",[15,425,410],{},". Die Stufe „gemerged“ ist im Produktivbetrieb erreichbar — die Prüfung ist kein Endzustand.",[38,428,430],{"id":429},"setup-der-code-worker-service-und-seine-umgebung","Setup: der code-worker-Service und seine Umgebung",[11,432,433,434,437,438,440,441,443],{},"Der code-worker wird als Docker-Sidecar ausgeliefert. Im mitgelieferten Compose-Stack läuft er unter dem Profil ",[27,435,436],{},"inbox-codetasks",", das durch das Feature-Flag ",[27,439,65],{}," aktiviert wird. Er verbindet sich über den Convex-Client mit Ihrem Owlat-Deployment, fragt die nächste Aufgabe im Status ",[27,442,221],{}," ab (standardmäßig alle 10 Sekunden) und bearbeitet jeweils eine Aufgabe zur Zeit.",[98,445,447],{"title":446,"type":101},"Der Worker braucht den Admin-Key des Deployments",[11,448,449,450,452,453,456,457,460,461,464,465,464,468,464,471,464,474,464,476,464,478,481,482,484,485,488,489,492,493,495,496,499],{},"Der Worker authentifiziert sich mit dem Admin-Key des Deployments (",[27,451,29],{},"), genau wie die Sidecars ",[27,454,455],{},"imap"," und ",[27,458,459],{},"mail-sync","; das erlaubt ihm, die internen Queries und Mutationen aufzurufen, mit denen er die Aufgabe steuert (",[27,462,463],{},"getNextQueued",", ",[27,466,467],{},"claim",[27,469,470],{},"updateBranch",[27,472,473],{},"markTesting",[27,475,383],{},[27,477,387],{},[27,479,480],{},"reclaimStale","). Sowohl der Dev-Compose-Stack als auch das VPS-Template reichen die Variable an den Service ",[27,483,17],{}," durch; die Setup-CLI erzeugt den Key beim ersten Start und schreibt ihn in ",[27,486,487],{},".env",", wo Compose ihn interpoliert. Beendet sich der Worker beim Start mit ",[27,490,491],{},"CONVEX_ADMIN_KEY environment variable is required",", fehlt der Key in ",[27,494,487],{}," — erzeugen Sie ihn mit ",[27,497,498],{},"docker compose exec convex .\u002Fgenerate_admin_key.sh"," und starten Sie den Service neu.",[11,501,502],{},"Für jede beanspruchte Aufgabe tut der Worker Folgendes:",[504,505,506,511,517,521,527,531,534,538,548,552],"steps",{},[507,508,510],"h3",{"id":509},"die-aufgabe-beanspruchen","Die Aufgabe beanspruchen",[11,512,513,514,516],{},"Er beansprucht atomar die älteste Aufgabe aus der Warteschlange und setzt sie auf ",[15,515,171],{},", damit kein anderer Abrufvorgang sie aufnimmt.",[507,518,520],{"id":519},"einen-workspace-und-branch-einrichten","Einen Workspace und Branch einrichten",[11,522,523,524,526],{},"Er klont Ihr Repository (flach, auf dem Basis-Branch) in einen aufgabenspezifischen Workspace und checkt einen neuen Branch ",[27,525,332],{}," aus.",[507,528,530],{"id":529},"den-coding-agenten-laufen-lassen","Den Coding-Agenten laufen lassen",[11,532,533],{},"Er führt den Coding-Agenten (standardmäßig OpenCode) mit Ihrer Aufgabenbeschreibung als Prompt aus, mit einem Timeout von 10 Minuten. Schlägt der Agent fehl oder erzeugt er keine Dateiänderungen, wird der Lauf als Fehlschlag gemeldet — was die Aufgabe für einen weiteren Versuch zurück in die Warteschlange stellt oder sie endgültig scheitern lässt, sobald die Versuche aufgebraucht sind.",[507,535,537],{"id":536},"committen-und-testen","Committen und testen",[11,539,540,541,543,544,547],{},"Er committet die Änderungen, setzt die Aufgabe auf ",[15,542,250],{}," und führt die Test-Suite (",[27,545,546],{},"vitest",") mit einem Timeout von 5 Minuten aus, wobei er den Ausgabe-Auszug festhält.",[507,549,551],{"id":550},"pushen-und-einen-pr-eröffnen","Pushen und einen PR eröffnen",[11,553,554,555,557],{},"Er pusht den Branch und eröffnet — sofern GitHub-Zugangsdaten konfiguriert sind — einen Pull Request, dessen Beschreibung Ihre Aufgabenbeschreibung und die Testzusammenfassung enthält. Die Aufgabe wechselt auf ",[15,556,263],{},", mit PR-URL, Testergebnissen und Kosten im Gepäck.",[11,559,560],{},"Der Container liest seine Konfiguration aus Umgebungsvariablen:",[193,562,563,573],{},[196,564,565],{},[199,566,567,570],{},[202,568,569],{},"Variable",[202,571,572],{},"Zweck",[212,574,575,585,594,604,617,627,641,654,670,683,693],{},[199,576,577,582],{},[217,578,579],{},[27,580,581],{},"CONVEX_URL",[217,583,584],{},"Das Owlat-Backend, das der Worker abfragt und an das er meldet. Erforderlich.",[199,586,587,591],{},[217,588,589],{},[27,590,29],{},[217,592,593],{},"Admin-Key des Deployments, mit dem sich der Worker authentifiziert, um die internen Queries und Mutationen der Warteschlange aufzurufen. Erforderlich — der Worker wirft beim Start einen Fehler, wenn er nicht gesetzt ist.",[199,595,596,601],{},[217,597,598],{},[27,599,600],{},"GIT_REPO_URL",[217,602,603],{},"Die Klon-URL des Repositorys, in dem der Agent arbeitet.",[199,605,606,611],{},[217,607,608],{},[27,609,610],{},"GIT_BASE_BRANCH",[217,612,613,614,36],{},"Branch, der geklont wird und gegen den der PR gerichtet wird (Standard: ",[27,615,616],{},"main",[199,618,619,624],{},[217,620,621],{},[27,622,623],{},"GITHUB_TOKEN",[217,625,626],{},"GitHub-Token, mit dem der Pull Request eröffnet wird.",[199,628,629,638],{},[217,630,631,634,635],{},[27,632,633],{},"GITHUB_OWNER"," \u002F ",[27,636,637],{},"GITHUB_REPO",[217,639,640],{},"Das Repository, gegen das der PR eröffnet wird. Sind beide nicht gesetzt, pusht der Worker den Branch, überspringt aber das Anlegen des PR.",[199,642,643,651],{},[217,644,645,634,648],{},[27,646,647],{},"LLM_BASE_URL",[27,649,650],{},"LLM_API_KEY",[217,652,653],{},"LLM-Konfiguration für den Coding-Agenten. Das sind die einzigen beiden LLM-Variablen, die der Kindprozess des Workers tatsächlich liest.",[199,655,656,664],{},[217,657,658,634,661],{},[27,659,660],{},"LLM_PROVIDER",[27,662,663],{},"LLM_MODEL",[217,665,666,667,96],{},"Werden der Bequemlichkeit halber über die Compose-Umgebung durchgereicht, aber vom Worker selbst ",[15,668,669],{},"nicht gelesen",[199,671,672,677],{},[217,673,674],{},[27,675,676],{},"OPENCODE_BIN",[217,678,679,680,36],{},"Pfad zum OpenCode-Binary (Standard: ",[27,681,682],{},"opencode",[199,684,685,690],{},[217,686,687],{},[27,688,689],{},"POLL_INTERVAL_MS",[217,691,692],{},"Wie oft nach Aufgaben in der Warteschlange gefragt wird (Standard: 10000).",[199,694,695,700],{},[217,696,697],{},[27,698,699],{},"WORKSPACE_ROOT",[217,701,702,703,36],{},"Wo die aufgabenspezifischen Klone im Container liegen (Standard: ",[27,704,705],{},"\u002Fworkspace",[98,707,710],{"title":708,"type":709},"Der Worker hat Schreibzugriff auf Ihr Repository","danger",[11,711,712,713,715,716,718],{},"Der code-worker klont, committet, pusht und eröffnet Pull Requests mit den Zugangsdaten, die Sie ihm geben, und lässt einen autonomen Coding-Agenten auf Ihre Codebasis los. Beschränken Sie ",[27,714,623],{}," auf ein einzelnes Repository, richten Sie ",[27,717,610],{}," auf einen Branch, den Sie mit verpflichtenden Reviews schützen, und behandeln Sie jeden erzeugten Pull Request als nicht vertrauenswürdig, bis Sie ihn gelesen haben.",[11,720,721,722,724,725,456,729,96],{},"Wo diese Variablen im Deployment liegen und wie Sie das Profil ",[27,723,436],{}," aktivieren, lesen Sie unter ",[32,726,728],{"href":727},"\u002Fdeveloper\u002Fself-hosting-config","Self-Hosting-Konfiguration",[32,730,95],{"href":94},[38,732,302],{"id":733},"automatische-wiederholungen",[11,735,736],{},"Die meisten Arten, auf die eine Code-Aufgabe scheitert, sind vorübergehend — der LLM-Endpunkt schluckt, der Klon läuft in einen Timeout, der Container wird mitten im Lauf neu gestartet —, deshalb wird ein fehlgeschlagener Lauf wiederholt, statt die Aufgabe zu beenden.",[11,738,739,740,743,744,747,748,751,752,755,756,758],{},"Jede Beanspruchung zählt als ein Versuch. Eine Aufgabe erhält insgesamt ",[15,741,742],{},"3 Versuche","; schlägt ein Lauf fehl und sind noch Versuche übrig, stellt das Backend die Aufgabe zurück ",[15,745,746],{},"in die Warteschlange"," und versieht sie mit dem frühesten Zeitpunkt, zu dem sie erneut beansprucht werden darf. Die Verzögerung wächst mit jedem Fehlschlag — ",[15,749,750],{},"1 Minute"," nach dem ersten, ",[15,753,754],{},"5 Minuten"," nach dem zweiten —, damit ein komplett ausgefallener LLM-Endpunkt nicht von einer Aufgabe bombardiert wird, die momentan gar nicht erfolgreich sein kann. Der Worker sieht eine Aufgabe erst, wenn dieses Fenster verstrichen ist, und bearbeitet in der Zwischenzeit jede andere bereite Aufgabe. Schlägt der letzte Versuch fehl, gilt die Aufgabe endgültig als ",[15,757,183],{},", mit dem letzten Fehler auf der Karte.",[11,760,761],{},"Zwei Regeln begrenzen das:",[763,764,765,772],"ul",{},[766,767,768,771],"li",{},[15,769,770],{},"Abbrechen gewinnt immer."," Eine Aufgabe, die Sie abbrechen, ist sofort endgültig. War der Worker mitten im Lauf, kann der Fehlschlag, den er anschließend meldet, die Aufgabe nicht zurück in die Warteschlange bringen.",[766,773,774,777,778,168,780,782],{},[15,775,776],{},"Ein abgestürzter Worker lässt keine Aufgabe hängen."," Beim Start holt der Worker jede Aufgabe zurück, die sein Vorgänger in ",[15,779,171],{},[15,781,250],{}," hinterlassen hat; jede davon wird hinter demselben Backoff wieder eingereiht (oder als fehlgeschlagen markiert, wenn ihre Versuche aufgebraucht sind), statt für immer in der Schwebe zu hängen.",[11,784,785],{},"Die Wiederholungsobergrenze und die Verzögerungen liegen im Backend, sodass ein veraltetes Worker-Image sie nicht ausweiten kann.",[38,787,123],{"id":788},"aktuelle-einschränkungen",[11,790,791],{},"Code-Aufgaben sind ein frühes Feature. Behalten Sie Folgendes im Hinterkopf:",[763,793,794,803,809,815],{},[766,795,796,799,800,802],{},[15,797,798],{},"Kosten werden nicht gemeldet."," Der code-worker sendet nie ",[27,801,379],{},", sodass das Feld Kosten bei vom Worker ausgeführten Aufgaben leer bleibt, obwohl Schema und Oberfläche es unterstützen.",[766,804,805,808],{},[15,806,807],{},"Eine Aufgabe zur Zeit, der Reihe nach."," Der Worker bearbeitet pro Abruf die älteste bereite Aufgabe aus der Warteschlange; es gibt keine Parallelität und keine Priorisierung.",[766,810,811,814],{},[15,812,813],{},"Wiederholungen sind nicht konfigurierbar."," Die Versuchsobergrenze und der Backoff-Plan sind im Backend fest verdrahtet; es gibt keine Einstellung pro Aufgabe oder pro Instanz und keine Möglichkeit, eine Aufgabe mit aufgebrauchten Versuchen von Hand erneut zu starten — außer, eine neue einzureichen.",[766,816,817,820,821,823],{},[15,818,819],{},"Eine wiederholte Aufgabe sieht aus wie eine wartende."," Während eine Aufgabe ihren Backoff abwartet, zeigt sie das Badge ",[15,822,224],{},"; das Dashboard zeigt bislang weder die Anzahl der Versuche noch, wann der nächste Versuch ansteht.",[11,825,826,827,456,831,96],{},"Ein umfassenderes Bild davon, wie Owlats Agent eingehende Konversationen und Entwürfe behandelt, finden Sie unter ",[32,828,830],{"href":829},"\u002Fguide\u002Fai-agent","KI-Agent & Autonomie",[32,832,834],{"href":833},"\u002Fguide\u002Fteam-inbox","Team-Postfach",{"title":836,"searchDepth":837,"depth":837,"links":838},"",2,[839,840,841,842,850,851],{"id":40,"depth":837,"text":41},{"id":126,"depth":837,"text":127},{"id":187,"depth":837,"text":188},{"id":429,"depth":837,"text":430,"children":843},[844,846,847,848,849],{"id":509,"depth":845,"text":510},3,{"id":519,"depth":845,"text":520},{"id":529,"depth":845,"text":530},{"id":536,"depth":845,"text":537},{"id":550,"depth":845,"text":551},{"id":733,"depth":837,"text":302},{"id":788,"depth":837,"text":123},"Aufgaben für den Coding-Agenten einreihen, ihren Weg von der Warteschlange bis zur Prüfung verfolgen und den code-worker-Sidecar betreiben, der die Pull Requests eröffnet.","md",{},true,"\u002Fguide\u002Fcode-tasks",{"title":6,"description":852},"1.guide\u002F34.code-tasks","viH2sMU-PZWsUHEv9IDYYnhy_P1Ckz9lYvxWoNxmjuU",[861,865],{"title":862,"path":863,"stem":864,"children":-1},"Team-Chat","\u002Fguide\u002Fchat","1.guide\u002F33.chat",{"title":866,"path":867,"stem":868,"children":-1},"Zielgruppendaten: Identitäten, Beziehungen & Timeline","\u002Fguide\u002Faudience-data","1.guide\u002F35.audience-data",1786915105541]