Eigene Zeichenebene wie der Pfad-Spline (Overlay-SVGs, /zoom): Kanten aus den neuen data-id/data-deps-Attributen des Renderers, dünn und blassgrau HINTER den Knoten — das Unterscheidungsmerkmal zu den orthogonalen Baumlinien ist die Krümmung, keine neue Farbe (die Palette ist vergeben, Rot bewusst nicht). Pfeilspitze zeigt auf das Gebrauchte, Endpunkte auf den Knotenkanten. Die Kanten des ausgewählten Knotens (Tastaturfokus, sonst Cursor-Zeile) liegen hervorgehoben in Tinte auf einer vorderen Ebene. Kanten zu verborgenen Zielen entfallen; erste ID-Vergabe gewinnt; Selbst-Abhängigkeiten zeichnen nichts. Basis-Kanten auch im SVG-Export (Schritt 1a) und im Druck, die Hervorhebung nicht. Browser-geprüft in allen drei Modi; Renderer-Attribute testgedeckt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
7.8 KiB
7.8 KiB
Aufgaben
Abhaken beim Erledigen; neue Aufgaben unten anfügen.
Phase 1 — Modularisierung & Tests
- Projektgerüst:
src/(parser.js, model.js, render.js, app.js),tests/,index.htmlbindet Module ein; weiterhin ohne Build nutzbar (ES-Module) oder mit minimalem Setup (Vite) — Entscheidung dokumentieren. → Vite gewählt (D19):src/als ES-Module,npm run buildbündelt zu einer self-containeddist/index.html(file://-tauglich). Gerüst steht (aktuellsrc/app.js+src/style.css); Parser/Renderer werden in den folgenden Checkboxen herausgelöst. - Parser extrahieren; Verhalten exakt wie in
docs/SPEC.md§1–§8. →src/parser.jsexportiertparse,STATUS_BY_CODE,SIZE_RANK(headless, kein DOM);app.jsimportiert sie. - Unit-Tests für den Parser (Vitest): kanonisches Beispiel aus SPEC §10
als Fixture; Randfälle: gemischte Gates, Tabs/ungleichmäßige Einrückung,
URL mit
@, mehrere Wurzeln, leere Labels,%%am Zeilenanfang/-ende. →tests/parser.test.js(18 Tests). - Renderer extrahieren (HTML-String-Erzeugung), Snapshot-Tests für
Normal- und Vertikalmodus sowie „Untergliederung fehlt“.
→
src/model.js(Baum-/Kostenlogik) +src/render.js(renderTreeHtml, headless);app.jsreicht UI-State als Parameter herein.tests/render.test.js(6 Tests, Snapshots). Anm.: der Modus (horizontal/vertikal/kompakt) ist reine CSS-Container-Klasse und ändert den Renderer-String nicht — ein Snapshot deckt alle drei Modi ab. - Warnungs-Modell vereinheitlichen (Zeilennummern, Typen).
→ strukturierte Objekte
{type, line, ...}(Renderer emittiertmixedGate);src/warnings.jsformatWarning(w, t)macht daraus den lokalisierten, HTML-escapten Text an einer Stelle. Vorbereitet für Phase 2 (unknownStatus).tests/warnings.test.js.
Phase 2 — Qualität
- Barrierefreiheit: Fokusreihenfolge, aria-Labels für Status/Größe/Tags.
→ je Knoten ein sprechender
aria-label(Label+Status+Aufwand+Zuständige+ Link, lokalisiert, neuea11y*-Keys in allen 9 Sprachen); visuelle Badgesaria-hidden; Knotentabindex="0"(Fokus = Lesereihenfolge) mit:focus-visible-Rahmen;#warnals Live-Region (role=status,aria-live=polite). Snapshots aktualisiert. - Druck-Stylesheet (Diagramm ohne Editor-Panel).
→
@media printinstyle.css: blendet Kopf/Editor/Splitter/Bedien- elemente/Warnungen/Footer aus, Diagramm füllt die Seite; Statusfarben viaprint-color-adjust:exact,break-inside:avoid, Pfad-Overlay inklusive. - Fehlertolerantes Parsen weiter ausbauen (unbekannte Statuszeichen melden).
→ Parser erfasst die Statusbox als beliebiges Einzelzeichen, validiert
gegen
STATUS_BY_CODE; unbekannte Codes →unknownStatus-Warnung (Zeile + Code), Knoten neutral, Folgezeilen unberührt.render()führt Parser- + Renderer-Warnungen zusammen. i18nunknownStatusWarnin allen 9 Sprachen.tests/parser.test.js(5 neue Tests).
Deployment
- GitHub-Pages-Workflow angelegt (
.github/workflows/pages.yml, siehe docs/DECISIONS.md D16).
Phase 3 — Integrationen (siehe ROADMAP)
- Backend-Gerüst per Spring Initializr in
backend/anlegen (Kotlin, Gradle Kotlin DSL, JDK 21; Konventionen: backend/CLAUDE.md). - SVG-Renderer (Layout-Engine) als gemeinsame Basis für Export und Mermaid-Plugin.
- Mermaid-Plugin-Spike: Detektor + Registrierung, ein Minimalbaum.
- Taiga-Spike:
#ref-Syntax parsen, Status via REST-API auflösen (read-only), Mapping konfigurierbar.
Phase 4 — Vollständiges Lean-Pathfinding (siehe ROADMAP, D34)
Reihenfolge ist nicht beliebig: ohne IDs keine Abhängigkeiten, ohne die keinen effektiven Status und keine Closure-Rechnung. Jeder Punkt beginnt in SPEC §11 — die dort benannten offenen Schreibweisen sind zu entscheiden, bevor Code entsteht.
#-Doppelrolle auflösen und in SPEC §11 festschreiben. → Durch Wegfall statt Trennregel: Tickets haben Vorrang (#123numerisch, oft zugleich die natürliche Knoten-ID; notfalls Präfix wie#t123); Schlagworte gehen auf&tag— niedrig priorisiert, gebaut erst mit dem ersten Konsumenten (D34-Nachtrag).- Knoten-IDs parsen; doppelte ID → Warnung mit Zeilennummer.
→ Umgesetzt (D36): Zeichenmenge wie
@name, nur alleinstehend angesetzt und nur das erste Token je Zeile (:#a,#bund Ticket-Erwähnungen bleiben unberührt); WarnungduplicateIdnennt beide Zeilen; sichtbar im Tooltip +aria-label; SPEC-§11-Teil nach §1 überführt;tests/ids.test.js. - Abhängigkeiten
:#a,#bparsen; unbekannte ID → Warnung, Zyklen erlaubt. → Umgesetzt (D37): ein zusammenhängendes Token ohne Leerraum, nur alleinstehend angesetzt (eingeklammerte Erwähnungen bleiben Label);depsals ID-Strings am Knoten, WarnungunknownDep, Zyklen bewusst ungeprüft; sichtbar als→ #a, #bim Tooltip +a11yDeps; SPEC-§11-Teil nach §1 überführt;tests/deps.test.js. - Effektiven Status rechnen (intrinsisch + Abhängigkeiten); Darstellung
entscheiden — die Knotenfarbe zeigt heute den intrinsischen Status.
→ Entschieden und umgesetzt (D39): Fortschritts-Rang (SPEC §4), effektiv
= Minimum über die Abhängigkeits-Hülle (Fixpunkt, Zyklen teilen ihr
Minimum); Knotenfarbe = effektiver Status, bei Diskrepanz die eigene
Statusbox als Marke unten links in den eigenen Farben (auch im Export);
Tooltip +
a11yEffective;tests/effective.test.js. - Günstigsten Pfad auf die Dependency Closure umstellen (gemeinsame Abhängigkeiten nur einmal zählen). Erweitert D18; die gierige Wahl je Alternativgruppe ist damit nicht mehr optimal — Verfahren wählen und benennen.
- Querverbindungen zeichnen (eigene SVG-Ebene, optisch sekundär);
bei ausgewähltem Knoten ein-/ausgehende hervorheben.
→ Umgesetzt (D41): gekrümmte blassgraue Kanten mit Pfeilspitze auf das
Gebrauchte, hinter den Knoten (
drawDepLinks); Hervorhebung in Tinte für Fokus-Knoten bzw. Cursor-Zeile; Basis-Kanten auch im Export/Druck. - Faltmarken
>/<parsen; interaktives Auf-/Zuklappen im Diagramm. → Schreibweise und Export-Verhalten entschieden (D34-Nachtrag): Marke hinter dem Zerlegungszeichen (- > [x] …), Export/Druck folgen der sichtbar eingeklappten Struktur mit Kennzeichnung am Knoten. Umgesetzt (D38):initialCollapsed()(<wandert die Faltung die Pfad-Ebenen hinunter,!!!holt sich mit hervor); Falt-Zeichen ▾/„▸ n" + Tastatur ←/→; Eingriffe je Label-Pfad, nur für die Sitzung; Warnungen aus eingeklappten Teilbäumen bleiben;tests/fold.test.js. - XOR-Gruppe (
=) parsen (nur mit folgendem Leerraum, Mischung →mixedGate), zwei realisierte Alternativen melden. → Zeichen entschieden:=stattx(D34-Nachtrag). Umgesetzt (D35): „realisiert“ =[~]/[/]/[x]/[^], WarnungxorConflictje weiterer realisierter Alternative; Darstellung als any-of plus „1“-Plakette an der Sammelleiste (auch im Grafikexport); Legende + i18n in 9 Sprachen;tests/xor.test.js. - Knotenbeschreibungen: Schreibweise für kurze und lange Form festlegen
(Einrückung ist bereits Hierarchie), dann Tooltip/Pop-up.
→ Schreibweise entschieden (D34-Nachtrag): Kurzform als
"-Zeile unter dem Knoten (Leerraum-Regel), Langform als eingerückte ID-Blöcke hinter einem----Trenner (SPEC §11). Umgesetzt (D40): Parser (descam Knoten, WarnungenunknownDesc/descStray), Anzeige im Tooltip +aria-labelmit ”-Marke am Knoten;tests/desc.test.js.