werkbaum/docs/prs/2026-09-08-PR#5-kanban-plan.md

Hinweis: Dieses Dokument beschreibt nur die Änderung dieses PR. Es kann veraltet sein, sobald der nächste PR gemergt ist. Historische PR-Dokumentation wird nicht nachgepflegt — sie ist eine Momentaufnahme, keine aktuelle Doku.

Das Problem

Werkbaum zeigt einen Plan als Baum; wer den Stand nach Status abgehen will, muss ihn aus den Farben zusammenlesen. Eine Kanban-Ansicht beantwortet die Frage „was steht wo“ in Spalten — und ist die Form, in der Teams ihre Arbeit im Tracker ohnehin sehen. Die schwierige Frage ist nicht die Spalte, sondern die Karte: Was ist eine Karte, und wohin gehen die Unterknoten eines Baums, der tiefer ist als Epic → Story → Task?

Nicht das Ziel

• Nichts wird gebaut. Der PR hält die Entscheidungen fest (D98), reserviert die Rollen-Schlagworte in SPEC §11 und legt die Plan-Knoten an.
• Keine Änderung an llms.md: Die Syntax ist reserviert, nicht gebaut (§13, wie bei D91-Nachtrag 3).
• Kein Umbau des Diagramms: Das Board wird ein vierter Modus, die drei bestehenden bleiben, wie sie sind.

Die Szenarien

Feature: Kanban-Ansicht ist geplant

Szenario#5.01: Der Plan führt die Kanban-Ansicht mit ihren Teilpaketen

Damit die Arbeit in Teilpaketen mit Größen dasteht und der günstigste Pfad sie einordnet.

• Gegeben der mitgelieferte Plan
• Wenn er geparst wird
• Dann trägt #ed.kanban (XL) sieben Teilpakete, #not.tag.roles steht unter den Schlagworten, und der Plan hat keine Warnung

Nachgewiesen durch

• Headless geparst: 0 Warnungen, kein Größen-Konflikt (S+M+M+S+XS+M+S = 19 < 32).

Szenario#5.02: Die Rollen-Schlagworte sind reserviert, mit Ableitungsregel

Damit niemand &epic, &story oder &task anderweitig vergibt und die Ableitung vor dem Bau feststeht.

• Gegeben SPEC §11, Abschnitt Schlagworte
• Wenn man ihn liest
• Dann stehen dort die drei Rollen, die Ableitung aus Schachtelung und Größe und die Regel, dass ein Schlagwort die Ableitung übersteuert

Nachgewiesen durch

• SPEC §11 (dieser PR), D98.

Die Lösung

• Vierter Darstellungsmodus statt eigenem Umschalter oder eigener Seite — das Board erbt Cursor-Zeile, Knoten-Fenster, Sprung, Filter und Export.
• Spalten aus den Boxen, intrinsischer Status, [!] als Marke, [-] nur mit dem Verworfen-Filter.
• Rollen aus &epic/&story/&task, abgeleitet aus Schachtelung und Größe, wo Tags fehlen (Nutzer-Entscheidung nach vier Entwürfen; Kurzfassung in D98).
• Filter über Personen-Linse und Pfad-Umschalter, dazu Zähler und Größen-Spanne je Spalte.
• XL mit Drag&Drop von Anfang an: Ein Drop schreibt die Statusbox über setStatusBox().

Warum C und nicht A+D: Der Nutzer will Rollen setzen können, wo die Form des Baums rät; die Ableitung sorgt dafür, dass ein Plan ohne Tags trotzdem ein Board zeigt.

Offene Fragen

• Lane-Überschriften bei Epics über Epics, tiefere Ebenen unter einer Story, das Board auf dem Telefon, eine Status-Leiste auf der Story-Karte — alle in D98 benannt, entschieden beim Bauen.

Weitere Änderungen

• Keine.

Vorausgesetzte PRs

• Keine.

Folge-PRs

• Der Bau selbst, in der Reihenfolge der Teilpakete: Spalten und Karten zuerst, Drag&Drop zuletzt.