werkbaum/docs/ROADMAP.md

Roadmap

Nahziel: tragfähige Codebasis

• Single-HTML-Prototyp (index.html) in Module zerlegen: parser, model, render, app. Parser und Renderer müssen headless (ohne DOM-Editor) nutzbar sein — Voraussetzung für alle Integrationen.
• Testsuite gegen docs/SPEC.md (kanonisches Beispiel als Fixture).

Mermaid-Plugin

Ziel: wbs-Blöcke in Mermaid-Umgebungen rendern.

• Offizieller Mechanismus: mermaid.registerExternalDiagrams() mit Detektor (Schlüsselwort wbs), Parser, DiagramDB, Renderer. Präzedenzfälle: ZenUML (extern), Mindmap (ursprünglich extern, ebenfalls einrückungsbasierte Syntax).
• Hauptaufwand: SVG-Renderer mit eigener Layout-Berechnung (Knotenmaße messen, Positionen, Verbinder als Pfade) inkl. Mischlayout und transponiertem Modus. Toggles werden zu Syntax-Optionen (z. B. wbs LR, Direktiven).
• Einschränkungen: wirkt nur in selbst initialisierten Mermaid-Instanzen (nicht GitHub/GitLab/Notion); Lazy-Loading externer Diagramme galt zuletzt als experimentell. Für universelle Verfügbarkeit: PR als eingebautes Diagramm (Vorbild Mindmap/Kanban).

Taiga-Integration

Ziel: Knoten mit Taiga-Objekten verlinken, Status automatisch synchronisieren.

• Architektur nach Seedtime-Vorbild: Companion-Ansatz — der Editor (frontend/) plus ein Kotlin/Spring-Backend (backend/, D13) sprechen per REST-API mit Taiga; optional dünnes contrib-Frontend-Plugin (Menüpunkt im Projekt) und Backend-Paket (Speicherung in Taigas DB statt Wiki-Seite).
• Syntax-Erweiterung #123: Referenz auf Epic/User Story/Task/Issue; App löst Titel, Link und Status per API auf. Status-Mapping Taiga-Workflow → Notation (z. B. „In progress“ → [~], „Done“ → [x]).
• Aktualisierung: API-Abfrage beim Öffnen; Push via Webhooks. Rückrichtung (Status im WBS ändern → Taiga) möglich.
• Einschränkungen: Plugins nur self-hosted (nicht taiga.io-Cloud); Taiga 6 im Wartungsmodus, Frontend AngularJS-Altbestand — daher Companion-App bevorzugen.

Tenzu (Beobachten)

Nachfolger von „Taiga Next“; seit Ende Juli 2024 von der französischen Genossenschaft Biru entwickelt (Kaleidos fokussiert Penpot). Open Source, in laufender Entwicklung, Integrationsfähigkeit erklärtes Ziel — noch zu jung als Plattform-Ziel. Companion-App so schneiden, dass ein späterer Umzug Taiga → Tenzu nur den API-Adapter betrifft.

Gemeinsam an einem Diagramm arbeiten

Ziel: mehrere Personen ändern denselben Plan. Drei Stufen, aufeinander aufbauend — die dritte lohnt nur, wenn wirklich gleichzeitig gearbeitet wird.

1. Lesen teilen — vorhanden. ?sourceUrl= (D23) zeigt eine entfernte Textdatei an; die Quelle wird anderswo gepflegt. Einbahnstraße, aber ohne jeden Server.

2. Asynchron ändern über Git — heute schon möglich, ohne eine Zeile Code. Die .werkbaum-Datei (D24) liegt im Repository, wird per Pull Request geändert und per ?sourceUrl= angezeigt. Weil der Plan Text ist (D14), sind git diff und git blame tatsächlich lesbar („wer hat Payment provider auf [!] gesetzt?"). Für einen Plan, der sich pro Woche und nicht pro Sekunde ändert, ist das oft die passendere Antwort — mit Review und Historie obendrauf. Ausbau: Das Backend (D13) legt jede Änderung als Commit ab und bekommt Historie, Wiederherstellung und Verzweigungen für Szenarien geschenkt.

Git direkt aus dem Browser ist technisch möglich (isomorphic-git spricht das HTTP-Smart-Protokoll), taugt aber nicht als Live-Sync: Es synchronisiert auf Zuruf statt fortlaufend, braucht wegen fehlender CORS-Header einen Proxy (SSH scheidet im Browser ohnehin aus), und ein Konflikt landet als <<<<<<<-Markierung mitten in der Notation — der Parser sähe kaputte Zeilen.

3. Live gemeinsam tippen — offen. Der Transport ist das kleinere Problem (WebSocket; SSE + POST oder WebRTC als Alternativen). Die eigentliche Frage ist, was passiert, wenn zwei Personen dieselbe Zeile ändern: Naives „jede Änderung sofort in beide Richtungen" führt zu Textsprüngen unter dem Cursor und verlorenen Zeichen. Erprobte Antworten sind Operational Transformation (Google Docs) und CRDTs. Für Werkbaum fällt die Wahl leicht, weil D14 das Format auf puren Text festgelegt hat: Ein Text-CRDT (Y.Text in Yjs, oder Loro) passt ohne eigene Merge-Logik darauf; Cursor und Anwesenheit fallen als Beigabe ab. Eigene Merge-Algorithmen sind hier kein Betätigungsfeld — das Problem ist gelöst.

Offene Punkte vor einer Entscheidung: Yjs wäre die erste Laufzeit-Abhängigkeit überhaupt (CLAUDE: nicht ohne Rückfrage); wie CRDT- Zustand und Git-Historie zusammenspielen (Commit-Granularität — nicht jeder Tastendruck ein Commit); und wer bei einem Backend eigentlich was darf (Rechte, siehe „Accounts" im Werkbaum-Beispielplan).

Kleinere Ideen

• Deterministische Pastellfarbe pro @name (Personen wiedererkennen).
• Sichtbare Anmerkungen am Knoten (eigene Syntax, getrennt von %%).
• Aufwands-Rollup: Größen der Kinder aggregieren und mit Parent vergleichen. (Größen sind ordinal, nicht additiv — S+S ≠ M; braucht erst eine Mapping-Konvention, z. B. Story-Point-Werte hinter den Größen.)
• Nutzen/Wert je Knoten (Gegenstück zur Kosten-Größe): eigenes Attribut für den erwarteten Nutzen; erlaubt Nutzen/Kosten-Priorisierung (WSJF-artig) statt reiner Kostenminimierung. Rollt analog zum Aufwands-Rollup hoch. (Syntax offen — SPEC-first; (…)/@/#/%% sind belegt, es braucht ein eigenes kollisionsfreies Zeichen.)
• Gestaffelter „günstigster Pfad" (Ausbaustufen): die Pfad-Rechnung (D18) status-bewusst machen — fertig/prod gelten als erledigt (Hintergrund), hervorgehoben wird nur der günstigste noch offene Rest (aktuelle Front). Ist eine Alternativen-Gruppe komplett realisiert, springt der Pfad zur nächsten, per Nutzen gewählten Ausbaustufe weiter (Regel: erst die Kette auf fertig, dann die nächste Stufe). Baut auf Nutzen + Aufwands-Rollup auf und erweitert D18 (heute rein statisch/kostenminimierend) um Nutzen- und Status-/Zeitachse.
• Attribut-Syntax für Termine/Meilensteine.