Coding-Aufgaben

Das Coding-Board verwandelt ein geschriebenes Briefing mit so wenig Zeremonie wie Sie möchten in gemergten Code: Schreiben Sie, was Sie brauchen, planen Sie es mit einem interaktiven Planungsagenten in prüfbare Phasen oder erledigen Sie es in einem Zug, sehen Sie dem Agenten in seinem eigenen Git-Worktree bei der Arbeit zu, prüfen Sie das Diff mit zeilenverankerten Kommentaren und mergen Sie. Jede Stufe ist eine Spalte; jede Aufgabe ist eine Karte.

Die Seitenleiste behält nahe der Oberseite einen schmalen Abschnitt AUFGABEN — eine Puls-Zeile fasst das Board zusammen (9 geplant · 1 in Bearbeitung · 2 zu prüfen), mit einem orangefarbenen Badge, das die in Test/Review wartenden Karten zählt, und einem roten Badge, wenn ein Agent Ihre Eingabe braucht. Klicken Sie auf den Abschnittstitel oder die Zeile, um das Board zu öffnen, oder drücken Sie von überall ⇧⌘T.

Das Coding-Aufgaben-Board: Backlog mit einem Briefing, das Planen und In einem Zug anbietet, Plan mit zwei nummerierten Phasenkarten (die zweite hinter einer Abhängigkeit gesperrt), In Bearbeitung mit einer laufenden Aufgabe, Test/Review mit einer Karte, die ihren Branch und eine Kommentaranzahl zeigt, und Fertig mit einer gemergten Karte.

Spalte	Was dort liegt
Backlog	Briefings, die Sie geschrieben, aber nicht gestartet haben. Jede Karte bietet Planen und In einem Zug.
Plan	Phasenkarten, die ein Planungsagent aus einem Briefing abgelegt hat — nummeriert, abhängigkeitsbewusst, mehrfach auswählbar.
In Bearbeitung	Phasen und In-einem-Zug-Aufgaben, an denen ein Agent aktiv arbeitet, jede in ihrem eigenen Worktree.
Test/Review	Fertige Arbeit, die auf Sie wartet: Die Karte öffnet das Review-Fenster mit dem Diff des Branches.
Fertig	Gemergte, per Pull Request eingereichte oder ohne Merge geschlossene Aufgaben.

Alles auf dieser Seite funktioniert identisch von einem entfernten Rich Client — das Board, das Planungsfenster und das Review-Fenster werden alle über die Steuerungs-API gespiegelt.

Eine Aufgabe schreiben

+ Neue Aufgabe (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, also schreiben Sie es wie einen.
Arbeitsbereich und Agent — die Aufgabe läuft im gewählten Arbeitsbereich mit einem seiner konfigurierten Agenten.
Den Agenten starten in — einem Ordner innerhalb des Arbeitsbereichs. Wenn es ein eigenes Git-Repository ist, läuft die Aufgabe dort in einem frischen Worktree und Branch.
Ordner & Git-Repo bei Bedarf erstellen — für Arbeit auf der grünen Wiese: Starten oder Planen führt zuerst mkdir + git init aus (mit einem leeren Root-Commit), wenn der Ordner nicht bereits ein eigenes Repository ist. Lassen Sie es für einen Ordner innerhalb eines bestehenden Repos aus.

Ein Briefing im Backlog bietet zwei Schaltflächen:

In einem Zug schickt die Aufgabe direkt in In Bearbeitung: Der Agent erledigt das Ganze autonom und übergibt Ihnen das Diff in Test/Review.
Planen öffnet zuerst eine Planungssitzung.

Planung

Planen startet eine sichtbare, interaktive Planungssitzung und öffnet ihr Fenster — eine native Konversationsansicht, kein Terminal erforderlich. Die Sitzung öffnet sich auf Ihrem Briefing, als Karte gerendert; der Agent erkundet das Repository schreibgeschützt, erzählt, was er findet, und stellt Fragen, wenn das Briefing echte Entscheidungen offenlässt.

Fragen treffen als Karte mit Tabs ein — ein Tab pro Frage, exakt die Auswahl spiegelnd, die der Agent in seiner eigenen Sitzung zeigt. Antworten werden lokal gesammelt und bleiben editierbar, bis Sie Absenden drücken, was den ganzen Satz auf einmal schickt; ein Fehlklick ist nie endgültig. Sie können auch freie Antworten im Editor am unteren Rand des Fensters tippen oder Terminal öffnen drücken, um die rohe Sitzung zu beobachten.

Wenn der Agent hat, was er braucht, legt er den Plan auf dem Board ab — geordnete Phasenkarten in der Plan-Spalte, jede grob ein prüfbarer Pull Request an Arbeit, mit Abhängigkeiten dazwischen — und zeichnet eine Plan-Übersicht auf. Das Fenster zeigt dann Der Plan ist bereit mit der Phasenanzahl und einer Schaltfläche Schließen, der Tab der Planungssitzung schließt sich selbst, und das Briefing verlässt den Backlog (seine Phasen ersetzen es; löschen Sie alle, und es kehrt zurück).

Die Planung wird überwacht: Wenn der Arbeitsbereich neu startet, der Agent beendet wird oder die Sitzung stirbt, bevor Phasen abgelegt sind, endet der Spinner der Karte mit einem konkreten Grund — Klicken Sie auf Planen, um es erneut zu versuchen — statt endlos zu drehen.

Die Plan-Spalte

Phasenkarten sind in Plan-Reihenfolge nummeriert und tragen:

Ein Abhängigkeits-Badge (ein Schloss mit Phasennummern), wenn die Phase erst frühere Phasen Fertig benötigt.
Ein In der Warteschlange-Badge, wenn Sie sie gestartet haben, bevor ihre Abhängigkeiten fertig waren — sie startet automatisch in dem Moment, in dem alle Fertig sind.
Den Namen ihres übergeordneten Briefings.

Wählen Sie mehrere Phasen mit den Kontrollkästchen aus, und die Auswahlleiste erscheint: N ausgewählte starten erledigt jede in einem Zug (abhängigkeitsgesperrte Phasen reihen sich ein), Löschen verwirft die Auswahl, und Entfernen nimmt die ganze Auswahl hinter einer einzigen Bestätigung heraus. Das Bearbeiten einer Phase zeigt ihre Hängt ab von-Liste — jede Geschwisterphase mit einem Kontrollkästchen, sodass Abhängigkeiten von Hand überarbeitet werden können.

Phasen laufen vollständig autonom — nach dem Start wird keine interaktive Eingabe erwartet.

In Bearbeitung

Eine gestartete Aufgabe bootet bei Bedarf den Arbeitsbereich, erstellt einen frischen Worktree des Repositorys und startet den Agenten mit dem Briefing als Prompt. Die Karte zeigt einen Live-Agenten-Status-Punkt, wann sie gestartet ist, und Braucht Ihre Eingabe in Rot, wenn der Agent an einer Frage blockiert ist — ein Klick auf die Karte springt zur Live-Sitzung. Das AUFGABEN-Badge der Seitenleiste zählt diese, damit Sie keine verpassen.

Wenn der Agent Fertig meldet, wandert die Aufgabe nach Test/Review, und ihr Terminal-Tab schließt sich von selbst — eine beendete Sitzung bleibt nicht in der Tab-Leiste hocken. Stürzt der Agent stattdessen ab, wird die Karte rot, statt Arbeit vorzutäuschen.

Test/Review

Die Test/Review-Karte öffnet das Review-Fenster: das vollständige Diff des Branches gegen sein übergeordnetes Element, live aus der VM gelesen, mit Auf-/Zuklappern pro Datei, Hinzufügen-/Entfernen-Zählungen und jedem Plan, den der Agent aufgezeichnet hat.

Prüfen Sie wie einen Pull Request:

Zeilenkommentare: Fahren Sie über eine hinzugefügte oder Kontextzeile und klicken Sie auf die Rand-Blase, um einen Kommentar an genau diese Zeile zu heften; verankerte Kommentare werden unter ihren Zeilen gerendert. Kommentare auf Datei-Ebene und allgemeine Kommentare funktionieren ebenfalls.
Zurück an In Bearbeitung senden liefert jeden verfassten Kommentar an den Agenten — formatiert als In foo.js, Zeile 196: eine andere Methode verwenden — und die Aufgabe kehrt für eine weitere Runde nach In Bearbeitung zurück. Der Agent setzt auf demselben Worktree und Branch fort.
Mergen — die Vorgabe der Split-Schaltfläche mergt in den übergeordneten Branch; halten Sie sie für Squash & Merge, Pull Request erstellen… (wenn der Arbeitsbereich ein GitHub-Token hat) oder das Mergen in einen beliebigen anderen Branch. Ein sauberer Merge schließt seinen eigenen Terminal-Tab; Konflikte öffnen stattdessen eine Auflösungssitzung.
Ohne Mergen schließen verwirft die Runde und behält den Eintrag in Fertig.

Tipp: Derselbe Zeilenkommentar-Workflow existiert außerhalb des Boards: Wenn der aktive Tab einen Coding-Agenten ausführt, wachsen dem Diff-Bereich des Datei-Explorers dieselben Rand-Blasen, und An Agenten senden bündelt Ihre Kommentare direkt in diese Sitzung — Code-Review, ohne je eine Aufgabe zu erstellen.

Karten entfernen

Jede Karte bekommt beim Überfahren ein ✕ (und einen Kontextmenü-Eintrag Vom Board entfernen), hinter einer Bestätigung. Für Karten mit echter Arbeit dahinter bietet der Dialog eine Wahl: Agent stoppen & Worktree löschen (In Bearbeitung) oder Worktree & Branch löschen (Test/Review) reißt alles ab, während Nur Karte entfernen die Sitzung und den Checkout im Arbeitsbereich unangetastet lässt.

Speicherung und API

Aufgaben werden in einer Datei neben dem Arbeitsbereich-Store persistiert, mit atomaren Schreibvorgängen und ISO-8601-Datumsangaben:

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

Das gesamte Board wird auf dem Steuerungs-Socket der App für Rich Clients und Skripte gespiegelt:

Endpunkt	Zweck
`GET /tasks`	Jede Aufgabe auflisten.
`POST /tasks`	Ein Aufgabendokument erstellen oder aktualisieren (upsert).
`POST /tasks/<id>/start`	Sie starten (Worktree + Agent).
`POST /tasks/<id>/plan`	Die Planungssitzung starten.
`POST /tasks/<id>/comment`	Einen Review-Kommentar hinzufügen (`text`, optional `file` und `line`).
`POST /tasks/<id>/send-back`	Ungesendete Kommentare zustellen und die Aufgabe nach In Bearbeitung zurückgeben.
`POST /tasks/<id>/merge`	Mergen (`squash`, optional `target`).
`POST /tasks/<id>/open-pr`	Einen Pull Request erstellen statt zu mergen.
`POST /tasks/<id>/to-testing`, `/to-in-progress`	Sie von Hand verschieben.
`POST /tasks/<id>/destroy`	Den Agenten stoppen, Worktree und Branch löschen, die Karte entfernen.
`DELETE /tasks/<id>`	Nur die Karte entfernen.

Unter der Haube sprechen die Planungs- und Aufgabenagenten über einen Board-MCP-Server pro Sitzung (vsock, hostseitig) zum Board zurück: board_get_task, board_set_plan, board_create_subtasks und board_ready_for_review sind die Art, wie Phasen abgelegt werden und wie eine fertige Aufgabe sich meldet — kein Polling, kein Scraping. Die Tools werden für jeden unterstützten Agenten automatisch verdrahtet: Claude Code lädt eine MCP-Konfiguration pro Branch, Codex erhält mcp_servers-Overrides pro Aufruf, und Grok liest eine projektbezogene .grok/settings.json, die in den Checkout der Sitzung geschrieben (und aus deren Diff ausgeschlossen) wird.