cfbbfab54bfdd1dc37b4c690ac893822104167a7
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 mhoennigandClaude Opus 4.8
|
6836352e84 |
deploy: „fertig" wird erst beim Deploy „in Produktion" (D30)
Der mitgelieferte Werkbaum-Plan behauptete [^] für Funktionen, die nur auf der
automatisch deployten Pages-Instanz lagen, nicht auf werkbaum.javagil.de
(manueller Deploy, D16). Ausgerechnet das Dokument, das den Stand beschreiben
soll, war ungenau — und „Was ist neu?" (D28) meldete Dinge als live, die es
dort nicht waren.
Die Unterscheidung gibt es längst: SPEC §4 trennt [x] fertig von [^] in
Produktion. Der Plan hat sie für sich selbst nie benutzt. Konvention ab jetzt:
beim Mergen [x], der Deploy befördert — nur er weiß, wann die Aussage wahr wird.
- scripts/promote-shipped.sh schreibt Statusboxen am Zeilenanfang von [x] auf
[^] und hält das als eigenen Commit fest (-n zeigt nur, -y ohne Rückfrage).
Bricht ab, wenn die Plandatei uncommittete Änderungen hat; committet nur
diesen einen Pfad; pusht nicht.
- deploy-prod.sh ruft es als Schritt 0 auf (--no-promote schaltet es ab) und
warnt, wenn HEAD noch nicht auf origin liegt — der Footer-Versionslink zeigt
sonst auf einen Commit, den GitHub nicht kennt.
Warum ein Commit und kein Rewrite beim Bauen: Ein Rewrite macht GENAU EINE
Installation ehrlich; Pages untertriebe dauerhaft und die Neu-Anzeige wäre dort
für immer stumm. Der Commit wird von beiden Pipelines gesehen (Pages beim Push,
prod beim rsync), das Artefakt bleibt inhaltsgleich mit dem Repo — die
vorhandenen sed-Regeln (D16) fassen nur Pfade und Version an, Infrastruktur,
kein Rewrite dessen, was das Dokument aussagt. Außerdem Präzedenzfall D16:
VERSION per bewusstem Bump-Commit, „vollständig aus dem Repo reproduzierbar".
Einmalige Nachholung, exakt statt geschätzt: Der Footer der stabilen Instanz
verlinkt den deployten Commit (
|
||
|
mhoennigandClaude Opus 4.8
|
56c18cb8cb |
frontend: Treppe für aufeinanderfolgende optionale Endknoten
Im horizontalen Fächer kostet jedes optionale Geschwister eine eigene Spalte — Breite für gerade das, was am entbehrlichsten ist. Zwei oder mehr aufeinanderfolgende optionale ENDknoten werden deshalb als Kaskade gestapelt: erste Stufe am Stiel von oben wie ein gewöhnliches Kind, jede weitere eine Stufe tiefer und weiter rechts, an einem gestrichelten Winkel, der an der linken Kante der vorigen Stufe herabfällt und waagerecht in ihren Kreis einbiegt. Verworfen: die naheliegendere SENKRECHTE Spalte unter einem Anschlusspunkt. Schmaler und in einem Bruchteil der Zeit gebaut — sähe aber fast genau aus wie eine any-of-Gruppe (gestapelte Spalte an gestrichelter Leiste), unterschieden nur durch Tinte statt Grau. Genau diese Verwechslung zu vermeiden ist der Zweck von Kreis und Farbgebung. Ebenfalls verworfen: eine echte Diagonale — Rahmenkanten sind achsenparallel, sie bräuchte die SVG-Ebene und wäre eine zweite Zeichenebene neben allen anderen Linien, nachzuführen bei jedem Rendern, Moduswechsel und Zoom. Rechte Winkel geben denselben Kaskaden-Eindruck im vorhandenen Mechanismus. - Nur Endknoten: Der Platzgewinn entsteht gerade daraus, dass kein Teilbaum mitgestapelt wird — ein optionaler Knoten MIT Kindern spart nichts und behält seine Spalte. Technisch dasselbe: die Stufengeometrie setzt Zellenhöhe == Knotenhöhe voraus. Geprüft wird genau das (ein Element-Kind, und das ist der Knoten) — schließt auch den Geister-Knoten aus. - Gruppiert wird in app.js, nicht im Renderer. Die DOM-Ebene gibt es semantisch nicht und müsste in den drei übrigen Anordnungen (vertikal, kompakt, all-of unter any-of) wieder neutralisiert werden, jede mit hand-getunter Geometrie. `display:contents` löst das nicht: richtet die Boxen, aber die >-Selektoren jener Regeln greifen weiter auf dem DOM. applyOptStairs() baut die Gruppe nur im Fächer und löst sie beim Moduswechsel auf — dieselbe Kategorie wie alignStems() und drawCheapPath(); SPEC §9 bleibt für den RENDERER wörtlich wahr, Lese- und Fokusreihenfolge unberührt. - Der Export folgt der Kaskade. Erste Fassung reihte alle Stufen flach als Kinder ein und ließ den Export selbst routen — die Linie zur dritten Stufe lief dann HINTER der zweiten hindurch und las sich wie eine Eltern-Kind- Beziehung. Keine Schönheitsfrage, sondern eine falsche Aussage über die Struktur. Jetzt hängt nur die erste Stufe an der Sammelleiste. Nicht durch Tests gedeckt: applyOptStairs() arbeitet auf dem DOM, und für app.js gibt es keine Testumgebung (die Suite prüft die headless-Module). Verifiziert im Browser: Kaskade in horizontal (drei Stufen, Winkel treffen die Kreise), Moduswechsel horizontal↔kompakt↔vertikal mehrfach hin und zurück — Gruppe entsteht und löst sich rückstandsfrei auf, Knotenzahl (9) und Dokumentordnung in allen drei Modi unverändert, keine übrig gebliebenen --i-Variablen. SVG-Export gerendert geprüft: drei Kreise, Winkelkette statt kreuzender Linien. Vitest 60/60 (Renderer unverändert). Im mitgelieferten Werkbaum-Plan stehen die beiden Editor-Zugaben jetzt nebeneinander und zeigen die Treppe. Reihenfolgeänderung ist für „Was ist neu?" folgenlos — die Knoten-Identität ist der Label-Pfad (D28), test-abgedeckt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
mhoennigandClaude Opus 4.8
|
aa3e087ee6 |
notation: + für optionale Knoten — Zugaben statt Pflicht oder Alternative
Die Notation kannte nur „erforderlich" (-) und „wählbar" (|). Ein einzelnes zusätzliches Feature — weder nötig noch Alternative zu etwas anderem — musste als normales -Kind notiert werden und log damit. Feature-Modelle (FODA) unterscheiden seit den 90ern mandatory/optional/alternative; `+` ergänzt die fehlende zweite Beziehung. Mnemonik: `-` Teilpaket, `+` Zugabe, `|` Alternative. Anlass ist nicht die Optik, sondern der günstigste Pfad (D18): markCheapest() lief bei all-of über ALLE Kinder, jede Zugabe steckte also im errechneten Minimum — systematisch zu groß, und zwar umso mehr, je ehrlicher ein Plan auch die Kür notiert. Sichtbar wird es beim Alternativenvergleich: eine Alternative mit teurer Zugabe verlor gegen eine schlichtere, obwohl die Zugabe gar nicht dazugehört. - Parser setzt `optional:true` und lässt `type:'and'` stehen — `+` gehört zum Knoten, nicht zur Gruppe. Dadurch bleiben gateOf() und die mixedGate-Warnung unverändert richtig: sie meldet weiter genau dann, wenn | mit -/+ gemischt wird. `-` neben `+` ist erlaubt und still — „diese drei sind nötig, das hier wäre schön" ist der Normalfall, nicht der Fehlerfall. - Aus dem Pfad fallen optionale Knoten über pathChildren() heraus, die eine Stelle, die cheapestCost() und markCheapest() gemeinsam nutzen — deshalb wirkt es samt Teilbaum. - Darstellung: hohler Kreis mittig auf der Knotenkante, wo der Abzweig auftrifft (FODA-Konvention). Bewusst KEIN dritter Linienstil: im kompakten Modus codiert allein der Stil das Gate (D15), gepunktet müsste sich dort gegen gestrichelt-grau behaupten. Der Kreis ist orthogonal dazu. CSS-Grundfall ist gestapelt (links/50 %), Ausnahme der horizontale Fächer (oben/50 %), Rück-Ausnahme der gestapelte all-of-Teilbaum unter any-of (D18) — andersherum wären es vier Ausnahmen statt zwei. - SVG-Export zeichnet den Kreis NACH den Knoten (optMarks, Schritt 3a): er liegt halb außerhalb der Box und würde sonst vom Knoten-Rechteck überdeckt. - Legende, Knoten-Tooltip und aria-label in allen neun Sprachen; hint_root formuliert die neue Mischregel. Bekannte Schwäche, bewusst in Kauf genommen: Bei aktivem Pfad-Umschalter wird der optionale Knoten ausgeblasst (opacity:.32) — und mit ihm sein Kreis, der die Erklärung dafür wäre. `opacity` am Elternteil schlägt auf Pseudoelemente durch, das lässt sich nicht zurücknehmen. Das Zurücktreten ist hier die Hauptaussage (wie bei nicht gewählten Alternativen), Tooltip/aria/Legende liefern die Begründung nach. Verhaltensänderung: `+` am Zeilenanfang ist jetzt ein Zeichen und nicht mehr Teil des Labels (`+ 5 % Puffer` ergibt „5 % Puffer"). Test-abgedeckt. SPEC §1/§3/§9/§10 zuerst, dann Code (CLAUDE). Das kanonische Beispiel in §10 enthält jetzt eine `+`-Zeile und ist mit der Test-Fixture wieder deckungsgleich. Der mitgelieferte Werkbaum-Plan markiert Drucklayout, „Was ist neu?" und die Personenfarben als Zugaben — „Was ist neu?" war der Auslöser der Frage. Verifiziert: 12 neue Tests (Parser setzt optional/type; Status/Größe/Tags/URL am +-Knoten; führendes + wird verbraucht; Pfad lässt Zugabe samt Teilbaum aus; Kosten des Elternknotens ohne Zugabe; Alternativenvergleich ohne Zugaben; optionale Knoten bleiben sichtbar; opt-Klasse; keine Warnung bei -/+; Warnung bei |/+; aria-label). Vitest 58/58, Snapshot zeigt `node opt` OHNE `cheap`. Im Browser in allen drei Modi angesehen: Kreis sitzt in horizontal oben mittig, in vertikal und kompakt links auf halber Höhe, jeweils genau auf dem Ende des Abzweigs; SVG-Export enthält beide Kreise an denselben Punkten (gerendert geprüft, nicht nur im Quelltext). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
mhoennigandClaude Opus 4.8
|
b7637d6393 |
docs: Werkbaum-Plan — Dokumentenverwaltung und zwei neue Funktionen auf [^]
Der Plan hinkte dem Stand hinterher: „Several documents in one editor" stand
noch auf [x], obwohl es samt Kindern längst deployt ist, und zwei seither
ausgelieferte Funktionen fehlten ganz.
- Several documents in one editor + Switcher + ?sourceUrl= von [x] auf [^].
- Neu aufgenommen, beide live: „Jump between diagram and text" (D25) und
„Show what is new since your last visit" (D28).
Damit hat „Was ist neu?" zugleich wieder etwas zu zeigen — Unit tests war
bestätigt und damit verbraucht.
Verifiziert gegen das gebaute dist-Artefakt mit nachgestelltem Leser-Zustand
(Basis und Dokumenttext = Vorstand
|
||
|
mhoennigandClaude Opus 4.8
|
68abdc6625 |
docs+frontend: Gemeinsam arbeiten in Roadmap und Werkbaum-Plan
- docs/ROADMAP.md: neuer Abschnitt „Gemeinsam an einem Diagramm arbeiten" in drei Stufen — Lesen teilen (?sourceUrl=, vorhanden), asynchron über Git (heute schon möglich, weil der Plan Text ist: git diff/blame sind lesbar; Ausbau = Backend committet jede Änderung), live tippen (Transport ist der kleinere Teil, das Zusammenführen gleichzeitiger Änderungen der eigentliche; Text-CRDT passt wegen D14 ohne eigene Merge-Logik). Notiert auch, warum Git direkt aus dem Browser kein Live-Sync ist (Sync auf Zuruf, CORS-Proxy nötig, Konfliktmarker mitten in der Notation) und was vor einer Entscheidung offen ist (erste Laufzeit-Abhängigkeit, Commit-Granularität, Rechte). - docs/examples/example-werkbaum.werkbaum: passender Zweig „Working together on one plan" (94 Knoten, parst ohne Warnung). Dabei aufgefallen: Das mitgelieferte Dokument wurde nur EINMAL angelegt — die Ergänzung hätte niemanden erreicht, der die Seite schon geöffnet hatte. `werkbaum-seeded` hält deshalb statt '1' den Fingerabdruck (FNV-1a) der ausgelieferten Fassung; bei neuer Fassung wird der Text nachgezogen, aber nur wenn der Nutzer ihn nicht bearbeitet hat. Gelöscht bleibt gelöscht. `resetToDefaults()` setzt den Merker mit. Verifiziert im Browser, vier Fälle: alte unveränderte Fassung wird nachgezogen (98 Zeilen, neuer Zweig da); selbst geänderter Text bleibt unangetastet; gelöschtes Dokument kehrt nicht zurück; frischer Zustand zeigt die neue Fassung (89 sichtbare Knoten, keine Warnung). Vitest 37/37. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
mhoennigandClaude Opus 4.8
|
cdf843e2e3 |
docs: Eigene Endung .werkbaum + fünf Beispieldateien unter docs/examples/
Mit nur einem Beispiel ließ sich das Umschalten zwischen Dokumenten (D22) nicht zeigen — jeder ?sourceUrl=-Link legt genau ein Dokument an (D23), erst mehrere nacheinander geöffnete füllen den Wähler. - Neue Endung `.werkbaum` (D24, SPEC §12): macht Notationstexte zuordenbar (spätere Editor-Zuordnung, Syntax-Highlighting, Öffnen/Speichern). Konvention, kein Vertrag — `?sourceUrl=` wertet weder Endung noch Content-Type aus, `.txt` bleibt gültig. `.gitattributes` führt `*.werkbaum` als Text (LF). - docs/example-plan.txt -> docs/examples/example-plan-0.werkbaum (Inhalt bis auf die Kopfzeile unverändert); README-Links nachgezogen. - Neu, je einen anderen Aspekt zeigend: example-plan-1 (Küche: kein Software-Plan, alternativenlastig — günstigster Pfad), example-plan-2 (Konferenz: breiter Fächer, viele Beteiligte), example-plan-3 (drei Wurzeln = drei Bäume nebeneinander, dazu ein Knoten ohne Größe für das implizite-M-Badge), example-werkbaum (Werkbaum selbst: Bestand + mögliche Weiterentwicklung, destilliert aus ROADMAP/TASKS/DECISIONS). - README.md / README.de.md: Tabelle mit den fünf Live-Links samt Hinweis, dass sie nacheinander geöffnet den Dokument-Wähler füllen. Verifiziert: alle fünf parsen headless ohne Warnungen und ohne gemischte Gates (19/26/43/28/79 Knoten, 3 Wurzeln in Beispiel 3); Vitest 34/34 grün. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |