mhoennigandClaude Opus 5
90230c4dd3
Die fünf geplanten Notations-Erweiterungen für vollständiges Lean-Pathfinding sind in die Doku eingearbeitet — Schreibweisen samt offener Punkte in SPEC §11, Begründung und Folgen in D34, Aufgaben in Phase 4, und als Knoten im mitgelieferten Werkbaum-Plan. Drei Kollisionen mit Bestehendem sind dabei benannt statt stillschweigend mitentschieden: `#` trägt jetzt drei Bedeutungen (Ticket, Schlagwort, Knoten-ID), `x` für XOR liest sich neben `[x]` schlecht, und kurze Knotenbeschreibungen können keine eingerückte Folgezeile sein, weil Einrückung Hierarchie bedeutet. Die weitestreichende Folge betrifft D18: Mit Dependency Closure — gemeinsame Abhängigkeiten nur einmal gezählt — ist die günstigste Alternative nicht mehr lokal entscheidbar; die gierige Wahl je Gruppe ist nicht länger optimal. LEAN-PATHFINDING.md schlug für Abhängigkeiten noch `→ Feature` vor (Verweis auf den Titel, rote Linien); das ist mit `:#id` überholt und korrigiert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.1 KiB
5.1 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 (Knoten-ID vs. Schlagwort) und in SPEC §11 festschreiben;#taghängt an derselben Entscheidung.- Knoten-IDs parsen; doppelte ID → Warnung mit Zeilennummer.
- Abhängigkeiten
:#a,#bparsen; unbekannte ID → Warnung, Zyklen erlaubt. - Effektiven Status rechnen (intrinsisch + Abhängigkeiten); Darstellung entscheiden — die Knotenfarbe zeigt heute den intrinsischen Status.
- 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.
- Faltmarken
>/<parsen; interaktives Auf-/Zuklappen im Diagramm. - XOR-Gruppe (
x): Zeichen endgültig wählen, parsen, Verletzung melden. - Knotenbeschreibungen: Schreibweise für kurze und lange Form festlegen (Einrückung ist bereits Hierarchie), dann Tooltip/Pop-up.