Coding-Aufgaben

Die Coding-Tafel macht aus einer geschriebenen Aufgabe gemergten Code, mit so wenig Zeremonie, wie Sie möchten: Schreiben Sie, was Sie brauchen, und dann entweder Zuerst planen — sie mit einem interaktiven Planungs-Agenten in reviewbare Phasen zerlegen — oder sie gleich Starten, sehen Sie dem Agenten bei der Arbeit in seiner eigenen git-Worktree zu, reviewen Sie den Diff mit zeilengenauen Kommentaren und übernehmen Sie ihn — der Agent, der die Änderung geschrieben hat, mergt sie (oder öffnet den Pull Request), sobald Sie sie freigeben. Jede Stufe ist eine Spalte; jede Aufgabe steht in einer davon.

In der Seitenleiste sitzt der Abschnitt Coding-Aufgaben gleich unter Sitzungen, über Automationen und Virtuellen Maschinen. Seine Kopfzeile zeigt, wie viele Aufgaben offen sind, ein orangefarbenes Abzeichen mit der Zahl der Aufgaben, die in Review warten, ein rotes Abzeichen, wenn ein Agent Ihre Eingabe braucht, und ein + für eine neue Aufgabe. Darunter fasst eine Zeile die Tafel zusammen (2 geplant · 1 in Arbeit · 1 zum Review), oder sie lautet Keine offenen Aufgaben, wenn die Tafel leer ist. Klicken Sie den Abschnittstitel (Coding-Aufgaben öffnen (⇧⌘T)) oder diese Zeile, um die Tafel mit dem Titel Coding-Aufgaben zu öffnen; Sie können auch ⇧⌘T drücken (Arbeitsbereiche › Aufgaben) oder Coding-Aufgaben in der ⌘K-Palette wählen.

Alles auf dieser Seite funktioniert von einem entfernten Rich Client genauso — die Tafel, das Planungsfenster und das Review-Fenster spiegeln alle über die Steuer-API.

Eine Aufgabe schreiben

Neue Aufgabe oben auf der Tafel, das + in der Kopfzeile Coding-Aufgaben der Seitenleiste, oder ein Klick auf eine Backlog-Aufgabe öffnet den Editor:

• Ein Titel und eine in Markdown geschriebene Beschreibung, mit einem Umschalter Schreiben / Vorschau. Die Beschreibung wird zum Prompt des Agenten, schreiben Sie sie also wie einen.
• Arbeitsbereich und Agent — die Aufgabe läuft auf der gewählten Maschine (einem Arbeitsbereich, im Einstellungseditor) mit einem der dort verfügbaren Agenten.
• Den Agenten starten in — einem Ordner innerhalb der Maschine. Ist er ein eigenes git-Repository, läuft die Aufgabe dort in einer frischen Worktree und einem frischen Branch.
• Ordner und git-Repository anlegen, falls nötig — für Arbeit auf grüner Wiese: Starten oder Planen führt zuerst mkdir + git init aus (mit einem leeren Wurzel-Commit), wenn der Ordner nicht schon sein eigenes Repository ist. Lassen Sie es aus für einen Ordner innerhalb eines bestehenden Repositorys.
• Nach Freigabe — wie die Aufgabe das Review verlässt: Workspace-Standard (die Wahl der Maschine, die ihrerseits den Einstellungen folgt — siehe Allgemein), In den Branch mergen oder Einen Pull Request öffnen.

Eine neue Aufgabe beginnt mit dem Arbeitsbereich und dem Ordner, die Sie zuletzt benutzt haben.

Eine Aufgabe im Backlog bietet zwei Schaltflächen:

• Starten schickt die Aufgabe nach In Arbeit: Ein neuer Agent erledigt das Ganze autonom in einer frischen Worktree und übergibt Ihnen den Diff in Review. (Nicht verfügbar, solange die Aufgabe geplant wird.)
• Zuerst planen öffnet zuerst eine Planungssitzung.

Starten prüft, bevor sich irgendetwas bewegt: Die Maschine wird bei Bedarf gebootet, dann muss der Ordner existieren und ein eigenes git-Repository sein (oder Ordner und git-Repository anlegen, falls nötig muss an sein). Während der Prüfung bleibt die Aufgabe mit einem Indikator Startet… in ihrer Spalte; sie wechselt erst nach In Arbeit, wenn der Agent wirklich starten kann. Eine Aufgabe, die nicht starten kann, bleibt, wo sie war, und zeigt den Grund in Rot — ein fehlender Ordner, ein Ordner, der kein Repository ist —, sodass die Tafel (und GET /tasks) nie eine Aufgabe als In Arbeit zeigt, die nicht läuft.

Jede Backlog-Aufgabe zeigt außerdem, wer sie übernimmt: Zuweisen öffnet die Auswahl (ein neuer Agent, die Schaltzentrale, eine Sitzung oder ein Raum), und die Aufgabe lautet dann Zugewiesen an Name; Zuweisung aufheben nimmt sie aus dieser Warteschlange. Neue Aufgaben: nicht zugewiesen oben auf der Tafel legt fest, wem neue Aufgaben beim Anlegen zugewiesen werden.

Planen

Zuerst planen startet eine sichtbare, interaktive Planungssitzung und öffnet ihr Fenster — eine native Gesprächsansicht, kein Terminal nötig. Die Sitzung öffnet mit Ihrer Aufgabe; der Agent erkundet das Repository schreibgeschützt, erzählt, was er findet, und stellt Fragen, wo die Aufgabe echte Entscheidungen offenlässt.

Fragen kommen als Karte mit Tabs — ein Tab je Frage, genau ein Spiegel der Auswahl, die der Agent in seiner eigenen Sitzung zeigt. Antworten werden lokal gesammelt und bleiben bearbeitbar, bis Sie Senden drücken, was den ganzen Satz auf einmal schickt; ein Fehlklick ist nie endgültig. Sie können auch frei formulierte Antworten in das Eingabefeld am Fuß des Fensters tippen, oder Terminal öffnen drücken, um die rohe Sitzung zu beobachten.

Hat der Agent, was er braucht, legt er den Plan auf der Tafel ab — geordnete Phasen in der Spalte Plan, jede etwa ein reviewbarer Pull Request an Arbeit, mit Abhängigkeiten untereinander — und hält einen Planüberblick fest. Das Fenster zeigt dann Der Plan ist fertig mit der Phasenzahl und einer Schaltfläche Schließen, der Tab der Planungssitzung schließt sich selbst und ihre Sitzung wird archiviert, und die Aufgabe verlässt den Backlog (ihre Phasen ersetzen sie; entfernen Sie alle, kommt sie zurück).

Die Planung wird überwacht: Startet die Maschine neu, wird der Agent beendet oder stirbt die Sitzung, bevor Phasen abgelegt sind, endet der Indikator der Aufgabe mit einem konkreten Grund — zum Wiederholen Zuerst planen klicken — statt sich endlos zu drehen.

Die Spalte Plan

Phasen sind in Planreihenfolge nummeriert und tragen:

• Ein Abhängigkeits-Abzeichen (ein Schloss mit Phasennummern), wenn die Phase erst frühere Phasen als Fertig braucht.
• Ein Abzeichen in der Schlange, wenn Sie sie gestartet haben, bevor ihre Abhängigkeiten fertig waren — sie startet automatisch, sobald alle Fertig sind.
• Den Namen ihrer Eltern-Aufgabe.

Wählen Sie mehrere Phasen mit den Ankreuzfeldern, und die Auswahlleiste erscheint: N ausgewählte starten startet jede davon (durch Abhängigkeiten gesperrte Phasen stellen sich in die Schlange), Leeren lässt die Auswahl fallen, und Entfernen entfernt die ganze Auswahl hinter einer Bestätigung. Eine Phase zu bearbeiten zeigt ihre Liste Hängt ab von — jede Schwesterphase mit einem Ankreuzfeld, sodass Abhängigkeiten von Hand umgearbeitet werden können.

Phasen laufen völlig autonom — nach dem Start wird keine interaktive Eingabe erwartet.

In Arbeit

Eine gestartete Aufgabe bootet die Maschine bei Bedarf, legt eine frische Worktree des Repositorys an und startet den Agenten mit der Beschreibung der Aufgabe als Prompt. Der Agent erscheint als Sitzung in der Seitenleiste wie jede andere, Sie können ihm also im Chat folgen. Die Aufgabe zeigt den Zustand ihres Agenten mit denselben Worten wie die Zeile der Sitzung in der Seitenleiste — Arbeitet, Braucht Sie in Rot, wenn der Agent an einer Frage hängt, Bereit, wenn der Agent an seinem Prompt wartet, ohne die Aufgabe übergeben zu haben, Pausiert, wenn seine Sitzung schläft — und dazu, wann sie gestartet ist. Ein Klick darauf (Live-Sitzung der Aufgabe öffnen) holt diese Sitzung auf die Bühne; eine verschwundene Sitzung bietet Sitzung neu starten, und eine Aufgabe, deren Repository oder Branch verschwunden ist, bietet Von vorn beginnen (ein frischer Lauf auf einem neuen Branch). Ein Agent, der beim Start stirbt — ein fehlender Befehl, ein falsches Flag —, wird binnen Sekunden erkannt: Die Aufgabe sagt es in Rot, mit dem Exit-Status des Agenten, und bietet Sitzung neu starten. Findet eine Nachricht für den Agenten bereits Text in seinem Eingabefeld, tippt Bromure nicht darüber: Die Nachricht wartet, bis das Feld leer ist, und wird es das nicht, sagt die Aufgabe es in Rot. Das Abzeichen Aufgaben der Seitenleiste zählt diese, damit Sie keine verpassen.

Beim Überfahren einer Aufgabe in Arbeit erscheint eine Schaltfläche ✓ Fertig (Als erledigt markieren, nach einer Bestätigung: nichts wird gemergt, der Branch bleibt). Ein Rechtsklick bietet Sitzung öffnen, Sitzung neu starten, Zum Review verschieben, Als erledigt markieren, Stoppen & zurück in den Backlog (der Agent stoppt; seine Worktree und sein Branch bleiben im Arbeitsbereich, die Aufgabe geht zurück in den Backlog), Stoppen & Branch verwerfen und Nur Aufgabe entfernen. Eine Backlog-Aufgabe oder eine Phase auf In Arbeit zu ziehen, startet sie. Eine Aufgabe, die einer Sitzung oder einem Raum übergeben wurde, bietet stattdessen Sitzung öffnen und Stoppen & zurück in den Backlog.

Meldet der Agent, dass er fertig ist, wechselt die Aufgabe nach Review. Ihre Sitzung bleibt offen: Review-Kommentare, die Sie zurückschicken, erreichen dieselbe Unterhaltung, und wenn Sie die Aufgabe freigeben, übernimmt derselbe Agent sie. Die Sitzung wird archiviert, sobald die Aufgabe übernommen, als erledigt markiert oder verworfen ist — oder nach etwa zwei Stunden in Review, in denen nichts passiert; dann setzt ein Zurücksenden oder eine Übernahme die Unterhaltung des Agenten in einem frischen Tab fort. Stürzt der Agent stattdessen ab, wird die Aufgabe rot, statt so zu tun, als arbeite sie.

Review

Eine Aufgabe in Review zeigt ihren Branch, ihre Review-Kommentare und wo sie steht: Bereit zum Übernehmen, Wird übernommen — Agent merged in Branch… (mit der letzten Zeile des Agenten) oder Braucht Sie — Grund in Rot (zwei Zeilen auf der Karte, alles beim Überfahren) mit den Schaltflächen Erneut versuchen und Sitzung öffnen. Eine Aufgabe, die keinen Code erzeugt hat, lautet Keine Codeänderungen — Bericht lesen. Fahren Sie über eine Aufgabe für ✓ Fertig; ziehen Sie sie auf Fertig, um sie als erledigt zu markieren. Klicken Sie sie, um das Review-Fenster zu öffnen — dasselbe Fenster, mit dem man die Änderungen einer Sitzung reviewt, betitelt Review — <Aufgabe>, mit den eigenen Schaltflächen der Aufgabe.

Unter der Kopfzeile des Fensters sagt eine Zusammenfassung, wo der Branch steht: Kimi Code hat an wt/fix-login in Web app gearbeitet · ~/app · 3 Commits · 4 Dateien (+120 −7) gegenüber main · main ist seitdem 2 Commits weiter · main-Checkout sauber · Remote: origin.

Das Fenster zeigt den Diff des Branches, live von der Maschine gelesen (die Maschine muss also laufen), mit Aufklappern je Datei, den Zahlen hinzugefügter und entfernter Zeilen, den Commits und dem Zustand der Arbeitskopie, und dem Plan, den der Agent festgehalten hat, falls es einen gibt. Eine Auswahl oben bestimmt, wogegen der Diff verglichen wird:

Reviewen Sie sie wie eine Pull Request:

• Dateien als angesehen markieren. Jede Datei hat eine Marke Angesehen (Als angesehen markieren — sie klappt weg, bis sie sich wieder ändert). Eine angesehene Datei klappt weg und klappt von selbst wieder auf, wenn ihr Diff sich ändert.
• Kommentieren. Fahren Sie über eine Zeile und klicken Sie die Blase im Rand (Diese Zeile kommentieren), um genau diese Zeile zu kommentieren, benutzen Sie Diese Datei kommentieren in einer Dateikopfzeile, oder tippen Sie in das Eingabefeld unten für einen Kommentar zur ganzen Änderung. Im Eingabefeld fügt ⏎ den Kommentar hinzu, ⌥⏎ setzt eine neue Zeile und ⇧⌘⏎ schickt alles zurück. Entwurfs-Kommentare können entfernt werden, bevor Sie sie senden.
• Zurücksenden. Die Senden-Schaltfläche lautet Zurücksenden (N). Sie liefert jeden Entwurfs-Kommentar dem Agenten in einer Nachricht aus — formatiert als In foo.js, Zeile 196: eine andere Methode verwenden — und schickt die Aufgabe für eine weitere Runde zurück nach In Arbeit, in derselben Unterhaltung, Worktree und demselben Branch (⇧⌘⏎).
• Übernehmen. Die Hauptschaltfläche folgt der Wahl Nach Freigabe der Aufgabe: In Branch mergen oder Pull Request öffnen (nur angeboten, wenn das Repository ein Remote hat). Ihr Menü enthält die jeweils andere, Squash & Merge in Branch, In anderen Branch mergen… und Branch behalten — als erledigt markieren. Jede öffnet eine Bestätigung, die genau sagt, was passieren wird (siehe Übernehmen), mit einer Option Branch behalten.
• Als erledigt markieren — erledigt ohne Merge, nach einer Bestätigung, dass der Branch bleibt.
• Mehr — Sitzung öffnen, Protokoll anzeigen und Branch verwerfen … (löscht den Branch und seinen Checkout; die Aufgabe geht als ohne Zusammenführen geschlossen nach Fertig, ihr Protokoll bleibt erhalten).
• Terminal öffnen springt zur Sitzung der Aufgabe auf der Maschine.

Eine Aufgabe, die keinen Code erzeugt hat — kein Branch, ein Branch ohne Änderung gegenüber seinem Ziel, oder eine delegierte Lieferung ohne Worktree —, zeigt statt git den Abschlussbericht des Agenten: Ihre Hauptschaltfläche ist Als erledigt markieren, neben Protokoll anzeigen und Zurücksenden.

Eine von einer Sitzung oder einem Raum erledigte Aufgabe, die bereits einen Pull Request geöffnet hat, bietet Pull Request #N ansehen und Als gemergt markieren (sobald er auf der Forge gemergt ist).

Rechtsklicken Sie eine Aufgabe in Review für Änderungen prüfen, Sitzung öffnen, Übernahme wiederholen (wenn sie Sie braucht), Als erledigt markieren, In Branch mergen… (öffnet das Review bei seiner Merge-Bestätigung), Zurück nach „In Arbeit“, Branch verwerfen … und Nur Aufgabe entfernen. Verwerfen oder Als-erledigt-Markieren sagt, wie viele Review-Kommentare, die den Agenten nie erreicht haben, mit ihr gehen.

Rechtsklicken Sie eine Fertig-Aufgabe für Protokoll lesen, Sitzung öffnen, solange ihre Sitzung noch lebt, Pull Request öffnen, wenn sie einen hat, und Aufgabe entfernen. Das Menü jeder Karte ist auch ihr VoiceOver-Menü (VO-Umschalt-M) und ihre Aktionsliste; VoiceOver liest eine Karte als ihren Titel und Zustand.

Übernehmen

Eine Merge-Freigabe übernimmt die Änderung, ohne dass Sie irgendetwas von Hand auflösen:

• Schneller Weg. Ist der Branch seinem Ziel strikt voraus, hat sein Checkout nichts Uncommittetes und ist der Checkout des Ziels sauber, mergt Bromure ihn selbst — ein Fast-Forward dort, wo das Ziel ausgecheckt ist, oder eine direkte Aktualisierung des Branches, wenn er nirgends ausgecheckt ist. Es mergt nie in einen Checkout, der auf einem anderen Branch steht.
• Der Agent übernimmt. Andernfalls erledigt es der Agent, der die Änderung geschrieben hat, in seiner eigenen Sitzung — in seine laufende Unterhaltung getippt oder in die fortgesetzte Unterhaltung: Er committet, was noch übrig ist, rebaset auf das neueste Ziel (Konflikte löst er so, dass die Absicht beider Seiten erhalten bleibt), führt die schnellen Prüfungen des Projekts aus und behebt, was seine Änderung kaputt gemacht hat, spult das Ziel per Fast-Forward vor und meldet sich zurück. Uncommittete Änderungen im Checkout des Ziels rührt er nie an. Eine Übernahme per Pull Request pusht stattdessen den Branch und führt gh pr create mit einer Zusammenfassung und einem Testplan aus.
• Geprüft. Die Aufgabe geht erst nach Fertig, wenn Bromure die Änderung in der Historie des Ziels sieht. Eine Übernahme, die der Agent meldet, die Bromure aber nicht prüfen kann (eine Maschine, die es nicht erreicht), wird als vom Agenten gemeldet, nicht geprüft festgehalten.
• Braucht Sie. Meldet der Agent, dass er blockiert ist, hört er auf, ohne zu übernehmen, oder ist er nach 20 Minuten nicht fertig, wird die Aufgabe mit dem Grund rot; das Review-Fenster bietet Sitzung öffnen, Erneut versuchen und Übernahme abbrechen.

Danach werden der Branch und sein Checkout entfernt (sofern Sie sie nicht behalten haben), und die Sitzung wird archiviert. Aufgaben, die einer Sitzung oder einem Raum übergeben wurden, werden genauso übernommen: Der Zugewiesene erhält die Übernahme-Anfrage auf derselben Delegation und meldet sich mit deliver.

Tipp: Sie brauchen keine Aufgabe, um die Arbeit eines Agenten zu reviewen. Jede Sitzung mit einem Ordner hat Änderungen reviewen in ihrem Menü und in ⌘K, und die Zeile N Dateien geändert im Chat öffnet dasselbe Fenster für jenen Zug. Siehe Branches und Review.

Aufgaben entfernen

Jede Aufgabe bekommt beim Überfahren ein ✕ (Aufgabe entfernen), hinter einer Bestätigung. Für eine Aufgabe in Arbeit bietet der Dialog Stoppen & Branch verwerfen, was alles abbaut, oder Nur Aufgabe entfernen, was die Sitzung und den Checkout auf der Maschine unangetastet lässt; für eine Aufgabe in Review bietet er Branch verwerfen oder Nur Aufgabe entfernen. Das Menü einer Backlog-Aufgabe hat Aufgabe entfernen.

Speicherung und API

Aufgaben bleiben in einer Datei neben dem Maschinen-Speicher erhalten, mit atomaren Schreibvorgängen und ISO-8601-Datumsangaben:

~/Library/Application Support/BromureAC/tasks.json

Die ganze Tafel wird auf dem Steuer-Socket der App gespiegelt, für Rich Clients und Skripte:

Unter der Haube sprechen die Planungs- und Aufgaben-Agenten über einen Tafel-MCP-Server je Sitzung (vsock, auf der Host-Seite) mit der Tafel: board_get_task, board_set_plan, board_create_subtasks, board_ready_for_review und board_report_landing sind die Art, wie Phasen abgelegt werden, wie eine fertige Aufgabe sich meldet und wie eine Übernahme merged, pr_opened oder blocked meldet — kein Abfragen, kein Auslesen. Die Werkzeuge werden für jeden unterstützten Agenten automatisch verdrahtet: Claude Code lädt eine MCP-Konfiguration je Branch, Codex bekommt mcp_servers-Überschreibungen je Aufruf, und Grok liest eine projektbezogene .grok/settings.json, die in den Checkout der Sitzung geschrieben (und aus seinem Diff ausgeschlossen) wird.