The Manager and Build

Der Manager ist der Chat neben dem Board. Er sieht den Projektauftrag, die Loops, das Task Book und die letzten Durchgänge, sodass du ihn zum Board befragen und mit ihm planen kannst.

Die vier Modi

Ein Modus legt fest, was der Manager verändern darf. Die Unterhaltung bleibt in einem Modus, bis du ihn wechselst; der Manager wechselt ihn niemals von sich aus.

Modus	Liest deine Dateien	Kann verändern
Ask	Ja, wenn ein Ordner gebunden ist	Nur PROJECT.md
Plan	Ja, wenn ein Ordner gebunden ist	Task-Book-Karten, nach deiner Zustimmung, und PROJECT.md
Code	Ja	Dateien in einem Loop-Ordner und PROJECT.md
Build	Nein	Schlägt ein Board vor, das erst bei Klick auf Build it platziert wird, und PROJECT.md

• Ask beantwortet Fragen zum Projekt und zum Board.
• Plan wandelt eine Unterhaltung in Karten um. Er fragt vor dem Schreiben.
• Code bearbeitet Dateien direkt, beschränkt auf den Ordner eines Loops. Wenn dieser Loop gerade einen Durchgang im selben Ordner ausführt, wartet der Code-Schritt darauf.
• Build entwirft Loops. Siehe unten.

Fragen

Wenn etwas wichtig ist, fragt der Manager. Eine Frage enthält zwei bis sechs Optionen, höchstens eine davon als empfohlen markiert, sowie ein Freitextfeld. Nichts ist vorausgewählt. Eine unbeantwortete Frage gilt als „keine Präferenz“.

Lenken und Bearbeiten

Du kannst tippen, während der Manager arbeitet. Die Nachricht wird bei seinem nächsten Schritt als Lenkung gelesen, anstatt auf das Ende des Durchgangs zu warten. Das Bearbeiten einer früheren Nachricht verzweigt die Unterhaltung; die andere Version bleibt erhalten.

PROJECT.md, der Projektauftrag

Der Auftrag eines Boards ist PROJECT.md im Projektstamm. Bis sie geschrieben ist, zeigt der Tab Tasks No PROJECT.md yet. Sie gehört dir: Sie liegt im Projekt, nicht im Ordner der App, und ist für das Einchecken in die Versionsverwaltung bestimmt. Jeder Durchgang jeder Bubble liest sie zuerst.

Sie hat zwei Abschnitte, die der App bekannt sind:

• Rules: wie das Projekt gebaut werden muss. Der Manager ändert dies nur auf deine Nachfrage.
• Current state: wie der Stand des Projekts ist.

Wenn du verlangst, dass das Projekt deployable sein soll, fügt der Manager eine Deployable-Zeile unter Rules hinzu. Von da an halten Bubbles den Produktions-Build lauffähig und eine Deploy-Konfiguration bereit. Du kannst dies über das Auftrags-Panel ausschalten.

Build

Build legt ein Board in zwei Schritten für dich an:

キュリティ:

1. Er liest, was er weiß (den Auftrag, das Task Book, die Unterhaltung), schlägt eine Struktur in klaren Worten vor und fragt, ob sie stimmt.
2. Sobald du zustimmst, schlägt er die Loops vor: die Bubbles in jedem Loop, einen Prompt für jede Bubble, den Ordner, in den jeder Loop schreiben darf, und die Sub-loops, die jeder Loop an seine Subloop-Bubbles hänget.

Der Vorschlag trägt den Titel Build this board?, und was er neben dem Button Build it anzeigt, ist genau das, was Build tun wird. Build selbst schreibt keinen Code und keine Karten, sondern nur PROJECT.md. Ein Klick auf Build it:

• fragt zuerst nach dem Ordner des Boards, wenn ein vorgeschlagener Loop Code schreibt und kein Ordner gebunden ist;
• meldet, wenn ein vorgeschlagener Ordner bereits zu einem Loop gehört, Nothing was built. A folder is already taken. und bietet Edit the existing loop oder Replace & build an;
• fragt, bevor ein von dir handgeschriebener Team-Prompt ersetzt wird.

Ein Loop, der etwas baut, das ein Mensch betrachtet, erhält vor seinem Coder einen designer und nach ihm einen reviewer, der die visuelle Prüfung ausführt. Ein Loop ohne Benutzeroberfläche erhält keines von beiden.

Ein leeres Board oder ein leeres Task Book ist kein Problem: Wenn zu wenig bekannt ist, fragt Build nach.

Das Task Book

Das Task Book enthält die Karten des Boards in sechs Spalten: Draft, Approved, Implementing, Review, Done und Blocked.

• Loops verarbeiten nur freigegebene Arbeit. Draft ist dein Tor.
• Karten, die du tippst, und Karten, die eine Planer-Bubble während eines Laufs schreibt, beginnen in Draft.
• Karten, die der Manager im Plan-Modus schreibt, beginnen in Approved, da du ihnen im Chat zugestimmt hast.
• Ein Loop, der eine Karte fertigstellt, verschiebt sie nach Review: gebaut und wartend darauf, dass der Prüfer des Loops (der Architekt oder wer auch immer die Arbeit in diesem Loop überprüft) sie akzeptiert oder zurückschickt.
• Eine Karte, die auf eine Unteraufgabe wartet, benennt diese, mit Stop waiting, um sie auch ohne diese fortzulassen.