Coding-Aufgaben

Die Coding-Tafel verwandelt ein geschriebenes Briefing in gemergten Code, mit so wenig Zeremonie, wie Sie wollen: schreiben Sie, was Sie brauchen, lassen Sie es von einem interaktiven Planungs-Agenten in reviewbare Phasen planen oder machen Sie es in einem Zug, sehen Sie dem Agenten in seiner eigenen git-Worktree zu, reviewen Sie den Diff mit zeilenverankerten Kommentaren, und mergen Sie. Jede Stufe ist eine Spalte; jede Aufgabe eine Karte.

In der Seitenleiste sitzt der Abschnitt Aufgaben direkt unter Sitzungen, über Automatisierungen und Virtuelle Maschinen. Seine Kopfzeile zeigt, wie viele Aufgaben es gibt, ein oranges Abzeichen mit der Zahl der Karten, die in Test/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 zu reviewen), oder liest Tafel öffnen, wenn sie leer ist. Klicken Sie den Abschnittstitel (Die Coding-Tafel öffnen (⇧⌘T)) oder jene Zeile, um die Tafel mit dem Titel Coding-Aufgaben zu öffnen; Sie können auch ⇧⌘T drücken (Arbeitsbereiche › Aufgaben) oder in der ⌘K-Palette Coding-Aufgaben 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 Aufgaben der Seitenleiste, oder ein Klick auf eine Backlog-Karte öffnet den Editor:

• Ein Titel und eine in Markdown geschriebene Beschreibung, mit einem Umschalter Schreiben / Vorschau. Das Briefing wird zum Prompt des Agenten, schreiben Sie es 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.

Ein Briefing im Backlog bietet zwei Schaltflächen:

• In einem Zug schickt die Aufgabe direkt nach In Arbeit: der Agent macht die ganze Sache autonom und übergibt Ihnen den Diff in Test/Review.
• Planen öffnet zuerst eine Planungssitzung.

Planen

Planen startet eine sichtbare, interaktive Planungssitzung und öffnet ihr Fenster — eine native Gesprächsansicht, ohne Terminal. Die Sitzung öffnet mit Ihrem Briefing, als Karte dargestellt; der Agent erkundet das Repository nur lesend, erzählt, was er findet, und stellt Fragen, wenn das Briefing echte Entscheidungen offen lä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, reiht er den Plan auf die Tafel ein — geordnete Phasenkarten in der Spalte Plan, jede etwa eine reviewbare Pull Request Arbeit, mit Abhängigkeiten dazwischen — und hält eine Plan-Übersicht fest. Das Fenster zeigt dann Der Plan ist bereit mit der Zahl der Phasen und einer Schaltfläche Schließen, der Tab der Planungssitzung schließt sich selbst und ihre Sitzung wird archiviert, und das Briefing verlässt den Backlog (seine Phasen treten an seine Stelle; löschen Sie alle, und es kommt zurück).

Die Planung wird bewacht: startet die Maschine neu, wird der Agent beendet, oder stirbt die Sitzung, bevor Phasen eingereiht sind, endet das Drehrad der Karte mit einem konkreten Grund — klicken Sie Planen, um es erneut zu versuchen — statt endlos zu drehen.

Die Spalte Plan

Phasenkarten 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 ihres Eltern-Briefings.

Wählen Sie mehrere Phasen mit den Ankreuzfeldern, und die Auswahlleiste erscheint: N ausgewählte starten macht jede davon in einem Zug (durch Abhängigkeiten gesperrte Phasen stellen sich in die Schlange), Leeren lässt die Auswahl fallen, und Löschen 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, wenn nötig, erstellt eine frische Worktree des Repositorys, und startet den Agenten mit dem Briefing als Prompt. Der Agent erscheint wie jede andere Sitzung in der Seitenleiste, Sie können ihm also im Chat folgen. Die Karte zeigt einen lebenden Agenten-Statuspunkt, wann er begann, und Braucht Ihre Eingabe in Rot, wenn der Agent an einer Frage hängt — die Karte zu klicken (Die lebende Sitzung der Aufgabe öffnen) stellt diese Sitzung auf die Bühne. Das Aufgaben-Abzeichen der Seitenleiste zählt sie, sodass Sie keine verpassen.

Rechtsklick auf eine In-Arbeit-Karte für Sitzung neu starten, Nach Test verschieben, Ohne Merge schließen, Agent stoppen & Worktree löschen und Nur Karte entfernen.

Meldet der Agent, dass er fertig ist, wandert die Aufgabe nach Test/Review: ihr Terminal-Tab schließt sich von selbst und ihre Sitzung wird archiviert, sodass fertige Arbeit sich nicht in der Sitzungsliste stapelt. Die archivierte Sitzung bleibt in der Archiviert-Falte der Seitenleiste lesbar (siehe Die Sitzungsübersicht). Stürzt der Agent stattdessen ab, wird die Karte rot, statt vorzugeben, zu arbeiten.

Test/Review

Eine Test/Review-Karte zeigt den Branch der Aufgabe und wie viele Review-Kommentare sie trägt („Bereit zum Review — klicken, um den Diff zu sehen"). Klicken Sie sie, um das Review-Fenster zu öffnen — dasselbe Fenster, mit dem man die Änderungen einer Sitzung reviewt, mit dem Titel Review — <Aufgabe> und den eigenen Schaltflächen der Aufgabe.

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ückschicken. Die Senden-Schaltfläche liest Mit 1 Kommentar zurückschicken, Mit N Kommentaren zurückschicken, oder Zurück nach In Arbeit, wenn es keine gibt. Sie liefert jeden Entwurfs-Kommentar in einer Nachricht an den Agenten — formatiert als In foo.js, Zeile 196: benutze eine andere Methode — und schiebt die Aufgabe für eine weitere Runde zurück nach In Arbeit, auf derselben Worktree und demselben Branch (⇧⌘⏎).
• Mergen. Die geteilte Schaltfläche In <Eltern> mergen mergt beim Klick in den Eltern-Branch. Ihr Menü bietet Squashen & in <Eltern> mergen, Pull Request erstellen…, Mergen in… jeden anderen Branch des Repositorys, und eine Option Worktree nach dem Merge entfernen (voreingestellt ein: Worktree und Branch werden entfernt, sobald der Merge auf dem Ziel bestätigt ist, nie vorher). Ein sauberer Merge schiebt die Aufgabe nach Fertig („Merge läuft… geht auf Fertig, sobald die Änderungen landen"); Konflikte öffnen eine Sitzung, die sie löst.
• Terminal öffnen springt zur Worktree der Aufgabe auf der Maschine.

Rechtsklick auf eine Test/Review-Karte auf der Tafel für In <Eltern> mergen…, Zurück nach In Arbeit, Ohne Merge schließen (beendet die Runde, behält aber den Eintrag in Fertig), Worktree & Branch löschen und Nur Karte entfernen.

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.

Karten entfernen

Jede Karte lässt beim Überfahren ein ✕ wachsen (und einen Kontextmenü-Eintrag Von der Tafel entfernen), hinter einer Bestätigung. Für Karten mit echter Arbeit dahinter bietet der Dialog eine Wahl: Agent stoppen & Worktree löschen (In Arbeit) oder Worktree & Branch löschen (Test/Review) reißt alles ab, während Nur Karte entfernen Sitzung und Arbeitskopie auf der Maschine unberührt lässt.

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) zur Tafel zurück: board_get_task, board_set_plan, board_create_subtasks und board_ready_for_review sind, wie Phasen eingereiht werden und wie eine fertige Aufgabe sich meldet — ohne Polling, ohne Abkratzen. Die Werkzeuge werden für jeden unterstützten Agenten automatisch verdrahtet: Claude Code lädt eine MCP-Konfiguration je Branch, Codex bekommt mcp_servers-Übersteuerungen je Aufruf, und Grok liest eine projektbezogene .grok/settings.json, die in die Arbeitskopie der Sitzung geschrieben (und aus ihrem Diff ausgeschlossen) wird.