70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
> **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.
|