ebc5be407ec79ccda772faf60d4490d70b4188c6
65
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 mhoennig
|
6b35cf4277 |
docs: Recherche Hostsharing — eigenes Etherpad ist machbar, aber ohne Websockets
Frage: Lässt sich Etherpad in einem Managed Webspace auf einem eigenen Managed Server betreiben? Recherchiert, mit einem Befund, der die Sache anders kippt als erwartet. Machbar, ja: - Hostsharing erlaubt ausdrücklich eigene Serverdienste (Daemons) im Managed Webspace gegen ein RAM-Kontingent, und Installationen im Userland — Programmiersprachen, Webserver, Datenbanken. - Node.js wird ausdrücklich unterstützt. Der Haken sitzt beim Transport: Der dokumentierte Node-Weg läuft über Apache mit mod_passenger, und Passenger unterstützt Websockets auf Apache NICHT (nur Nginx und Passenger Standalone, sagt Phusion selbst). Socket.io fällt dann auf Long Polling zurück. Root gibt es auf einem Managed Server nicht; ob die Apache-Vhost-Konfiguration ein Upgrade zu einem eigenen Port durchreicht, ist die offene Frage — deshalb steht der Knoten auf [!]. Entscheidend ist aber, dass unsere Anforderung davon gar nicht abhängt: Die 2 Sekunden brauchen keine Websockets, sondern die Hoheit über die Konfiguration — Export-Rate-Limit oder ein postMessage-Plugin. Beides ist auf einer eigenen Instanz reine Einstellungssache, unabhängig vom Transport. Ein Etherpad, das intern nur pollt, liefert uns trotzdem alles, was wir wollten. Geprüft: 121 Knoten, keine Warnungen. |
||
|
mhoennig
|
f830b4450a | docs: rephrase node description for collaboration in example plan | ||
|
mhoennig
|
f3dead402c |
docs: eigene Etherpad-Instanz als Alternative in den Plan
Nutzer-Idee: ein eigenes Etherpad unter javagil.de betreiben, statt den Admin der Genossenschafts-Instanz um Konfigurationsänderungen zu bitten. Die Alternative beherrscht mehrere der übrigen, deshalb steht sie zuoberst in der Gruppe: Auf einer eigenen Instanz sind Rate Limit, `cookie.sameSite`, Plugins und socket.io-CORS allesamt selbst gesetzt. Schon das Anheben des Export-Limits — eine Zeile Konfiguration — würde die 2-Sekunden-Anforderung erfüllen; ein Plugin wäre der elegantere Weg. `javagil.de` steht wie `hostsharing.net` nicht auf der Public Suffix List, `pad.javagil.de` und `werkbaum.javagil.de` wären also same-site, womit der Cookie-Ärger im eingebetteten Rahmen ohnehin entfällt. Die Kosten stehen als Kinder darunter statt im Kommentar, weil sie echte Arbeit sind: Node ≥ 18.18.2 und eine richtige Datenbank (Etherpads Flatfile-Speicher ist ausdrücklich nicht für Produktion), ein Proxy, der das Websocket-Upgrade durchreicht, TLS. Das Patchen eines öffentlich erreichbaren Dienstes bekommt `[!]`: Der Aufwand ist unklar UND unbefristet, und das ist bei dieser Alternative der eigentliche Preis — nicht die Installation. Geprüft: 118 Knoten, keine Warnungen. |
||
|
mhoennig
|
f3d3cc3afb |
docs: Recherche zur automatischen Aktualisierung — Alternativen in den Plan
Wunsch: Ansicht aktualisiert sich selbst, höchstens ~2 s Verzögerung, möglichst über Etherpads Websockets. Recherchiert und gemessen, nicht geschätzt. Kernbeobachtung, die alles erklärt: Der einzige Endpunkt, den wir fremdstämmig lesen dürfen, ist genau der gedrosselte. `/export/txt` sendet `Access-Control-Allow-Origin: *` und ist auf 10 Abrufe je 90 s und IP begrenzt (Etherpad-Voreinstellung, in settings.json.template bestätigt); die Pad-Seite `/p/<pad>` enthält den vollen Text in `clientVars`, sendet aber KEINEN CORS-Header — der naheliegende Umweg ist also versperrt. Der vorgeschlagene Websocket-Weg ebenfalls, und das ist gemessen: Ein `wss://…/socket.io/?EIO=4&transport=websocket` scheitert mit Code 1006 ohne `open`, während ein fremder Echo-Server aus derselben Seite sauber öffnet — die Umgebung kann WebSockets, dieser Server nimmt uns nur nicht. Das eingebettete Pad verbindet sich dagegen problemlos; der Unterschied ist der Origin. Damit scheitert der Weg nicht an unserer Bereitschaft, eine Abhängigkeit aufzunehmen, sondern an der Gegenseite — die Easysync-Frage stellt sich gar nicht mehr. Fund der Suche: Etherpad-Plugins reden per postMessage mit der einbettenden Seite. `ep_iframeinsert` schickt periodisch den ganzen Pad-Text ans Elternfenster (und nimmt insert-Befehle an, könnte also sogar Schreiben erlauben). Das ist der einzige Weg, der live ist, kein Polling braucht, das Rate Limit nicht berührt und uns nur einen message-Zuhörer kostet — keine neue Laufzeit-Abhängigkeit. Preis: Installation auf der Instanz. Damit hängt alles an einer Frage: Kommt man an die Konfiguration der Pad-Instanz? Alle wirksamen Wege sind Server-Änderungen. Ohne Zugriff bleibt Polling im Budget — höchstens einmal je 9 s, geteilt über alle Betrachter hinter derselben IP. Im Plan steht das als any-of-Gruppe unter „Update by itself"; die beiden gemessenen Sackgassen als [-] mit dem Messergebnis im Kommentar, damit niemand sie erneut aufmacht. Der günstigste Pfad wählt dort von selbst die Rate-Limit-Anhebung. Geprüft: 107 Knoten, keine Warnungen. |
||
|
mhoennig
|
fdde15cef3 |
docs: Werkbaum-Plan — 9 Knoten in Produktion
Beim Deploy der stabilen Instanz gehen diese Knoten live; SPEC §4 unterscheidet [x] fertig von [^] in Produktion (D30): - Optional nodes — neither required nor an alternative - Show what is new since your last visit - Watch a shared Etherpad — it merges, we render - Load the pad's plain-text export - Reload on demand (XS) %% a timer only trips Etherpad's rate limit - Embed the pad, keep the text mirror beside it - Three views: pad and text, pad only, text only - Splitter between pad and mirror - A shared pointer: !!! focuses a node for everyone |
||
|
mhoennig
|
816a77d9e7 |
notation: !!! als Fokusmarke — ein geteilter Zeigefinger im Text
Beim gemeinsamen Arbeiten an einem Pad (D31) fehlte das Naheliegendste: „schau mal hier". Etherpad zeigt die Cursor der anderen im Pad, aber Werkbaum kommt nicht an sie heran — ein fremdstämmiger Rahmen gibt keinen DOM-Zugriff, der Klartext-Export überträgt nur Text. Eine Marke IM Text ist damit nicht der Notbehelf, sondern der einzige Weg. Und sie hat etwas, das ein Cursor nicht hat: alle sehen dieselbe Stelle. Erkannt wird `!!!` nur ALLEINSTEHEND (`(^|\s)!!!(?=\s|$)`), sonst verlöre jedes „Achtung!!!" seine Ausrufezeichen und niemand fände den Grund. Bewusst ohne Lookbehind — Safari kennt es erst ab 16.4, und die Notation soll nicht an einer Browserversion hängen. Position in der Extraktion (SPEC §1): nach den Tags; der Kommentar fällt vorher weg, eine Marke hinter `%%` wirkt also nicht. Darstellung ist DIESELBE wie die der Cursor-Zeile (D25), nicht eine vierte: neben Fokusrahmen, Strahlenkranz (D28) und Cursor-Ring wäre ein weiterer Ring ein Zeichen zu viel — es gibt nur einen Begriff „hier schauen". Preis: Im Bild ist nicht zu unterscheiden, ob die eigene Cursor-Zeile oder eine fremde Marke leuchtet; für Screenreader benennt `a11yFocusMark` es ausdrücklich. Ins Bild geholt wird nur bei ÄNDERUNG der Marke, Schlüssel ist der Label-Text statt der Zeilennummer (Umsortieren im Pad soll nicht neu scrollen). Ohne diese Bedingung zöge jeder Neubau den Blick zurück und man käme nicht weg. Beides geprüft: gleiche Marke -> Scrollstand bleibt 0, Marke gewandert -> springt auf 242 und markiert den neuen Knoten. Beim Hinsehen gefunden: Die Pfad-Inversion verschluckte den Zeigefinger. Der erste markierte Knoten im Test war eine nicht gewählte any-of-Alternative („Headless CMS") — `opacity:.32; saturate(.4)`, der Ring praktisch unsichtbar. Der Zeiger zeigte auf nichts. Dieselbe Ausnahme wie für D28 behebt es, und hier ist sie zwingender: „Sollten wir diese verworfene Alternative noch einmal ansehen?" ist einer der wahrscheinlichsten Gründe, überhaupt zu zeigen. Anders als beim optionalen Knoten (D29), wo das Zurücktreten die Aussage IST. Nicht im Druck und nicht im Grafikexport (wie die Cursor-Zeile): Die Marke sagt „schau jetzt hierhin", nicht „so ist der Plan". Nicht ins kanonische Beispiel (SPEC §10) aufgenommen — das ist zugleich Test-Fixture, ein dauerhafter Zeigefinger darin wäre eine Aussage, die niemand gemacht hat. Verworfen war `%%!` (Kommentar-Variante, bliebe harmlos liegen und könnte die Begründung tragen) — der Nutzer wählte `!!!`, weil es im Moment des Zeigens schnell zu tippen ist, und genau dann will man nicht über Syntax nachdenken. Der Preis steht in D32: die Marke bleibt sichtbar stehen, bis jemand sie löscht; Werkbaum kann sie nicht entfernen (kein Schreibzugriff auf das Pad). SPEC §1/§9 zuerst, dann D32, dann Code. 15 neue Tests (86 -> 101), Legende und i18n in allen 9 Sprachen. |
||
|
mhoennig
|
0a08706877 |
frontend: Pad einbetten — drei Ansichten mit Splitter, Spiegel bleibt
Das Einbetten ist möglich, ohne D25 zu opfern. Nachgemessen zuerst, ob der
Server es überhaupt zulässt: pad.hostsharing.net sendet kein
`X-Frame-Options` und keine CSP mit `frame-ancestors`, und im Versuch baute das
Pad in einem fremdstämmigen Rahmen seine inneren Editorframes auf
(`contentWindow.length === 2` = ace_outer/ace_inner), samt Werkzeugleiste,
heiler Einrückung und lebender Socket-Verbindung.
Einbetten heißt aber nicht Ersetzen: Ein cross-origin-iframe gibt keinen
DOM-Zugriff, ein ersetztes Textfeld kostete also beide Richtungen von D25
(Alt+Klick -> Zeile, Cursor-Zeile -> Knoten). Deshalb drei Ansichten, reihum
über einen Wähler in der Editor-Titelzeile:
- Pad und Text, geteilt durch einen eigenen Splitter (Mechanik und Idiom vom
Legenden-Splitter aus D26: von der Spiegelseite gezogen, Doppelklick setzt
zurück, `--pcol`/`--prow` getrennt gehalten und persistiert). Der Spiegel darf
schmal werden und trägt weiter die Sprünge — die arbeiten auf unserem
eigenen `<textarea>`.
- nur Pad — Spiegel ausgeblendet; `revealEditor()` schaltet bei einem Sprung
auf „beide", sonst zeigte der Sprung ins Nichts.
- nur Text — wie bisher, kein Rahmen.
Ein Wähler statt dreier Knöpfe, weil die Titelzeile schon Dokument, Pad, Neu
laden, Kopieren, Legende und Fensterknöpfe trägt (mobil dreifach eng, D17) —
derselbe Reihum-Griff wie beim Modus-Wähler dort. Der Zustand steckt im Symbol
(geteilt / links gefüllt / rechts gefüllt), der Tooltip nennt ihn im Klartext.
Der Rahmen bekommt nur sichtbar ein `src`, sonst `about:blank`. Das ist kein
Geiz um Bytes: Ein geladenes Pad verbindet sich per Socket und macht dich in
dessen Anwesenden-Liste sichtbar. „Nur Text" ist damit die Ansicht, die nichts
von dir verrät.
Zwei Dinge, die beim Prüfen auffielen und behoben sind:
- Eine überzählige `}` ließ das Modul gar nicht laden. Die Messung sah trotzdem
plausibel aus, weil die abgefragten Werte die statischen HTML-Vorgaben waren —
seither prüft jede Messung zuerst, ob überhaupt Knoten gerendert sind, und
`node --check` läuft vor dem Blick in den Browser.
- In „nur Pad" war der Spiegel weiterhin sichtbar (sogar breiter als das Pad):
die Regel `.src-area.pv-pad>textarea{display:none}` fehlte.
Bleibender Preis: `Set-Cookie: token=…; SameSite=Lax`. Das Cookie ist Etherpads
Autoren-Identität und wird im fremdstämmigen Rahmen nicht mitgesendet — man ist
bei jedem Laden ein neuer Autor. Nur serverseitig zu beheben
(`cookie.sameSite: "None"`), nicht in Werkbaum. Steht in D31.
Auf kleinem Bildschirm nachgemessen statt geschätzt: bei 375x812 bleiben Pad
317 px und Spiegel 180 px, per Splitter verschiebbar — brauchbar, also keine
Sonderregel für Mobil.
SPEC §9 und D31 nachgezogen; 5 neue i18n-Schlüssel in allen 9 Sprachen.
|
||
|
mhoennig
|
793561c873 |
frontend: Pad auf Knopfdruck holen statt zu takten — Etherpad drosselt
Der Hintergrund-Takt aus dem letzten Commit funktionierte in der Praxis nicht:
im Netzwerk-Mitschnitt stapelten sich Anfragen und wurden abgebrochen
("cancelled"). Die Ursache ist nicht Langsamkeit, sondern ein Rate Limit —
Etherpads `importExportRateLimiting` ist serienmäßig an und lässt 10 Abrufe je
90 s und IP zu; der Takt wollte 36. Jenseits davon antwortet die Gegenseite
nicht mit 429, sondern hält die Verbindung ohne Antwort offen. Nachgemessen:
12:48:12 Abbruch nach 25 s (0 Bytes)
Abbruch nach 25 s (0 Bytes)
12:50:23 HTTP 200 nach 0,436 s <- nach ~40 s Pause
Zwei Minuten totgestellt, dann sofort in 0,4 s da. Gegen eine Drosselung kann
ein Takt nicht gewinnen, er erzeugt sie. Also ein Knopf. Damit entfallen
Stabilitätstakt, Sichtbarkeits-Wächter, Anti-Stapel-Riegel und Wiederanlauf.
Der Knopf greift zudem gut mit "Was ist neu?" (D28) zusammen: drücken, und was
seither in Produktion ging, leuchtet auf.
Verhindern UND melden, beides:
- Mindestabstand 10 s zwischen zwei Abrufen. Das ergibt höchstens 9 je 90 s und
bleibt damit beweisbar unter Etherpads Budget — die Drosselung wird gar nicht
erst ausgelöst. Nach einem Abbruch sind wir schon drüber: dann das ganze
Fenster (90 s) abwarten statt weiter dagegen zu rennen.
- Der Knopf bleibt in der Sperre **klickbar** (nur `aria-disabled`, nicht
`disabled`): Ein Klick meldet den Grund und nennt die Grenze samt Restzeit.
Die Meldung landet in `#warn`, das eine Live-Region ist, wird also angesagt.
Ein `disabled` erklärt nichts.
- Eigener Warnungstyp `sourceTimeout` für den Abbruch: `sourceLoad` zeigt auf
CORS und schickte hier auf die falsche Fährte.
- `setPadBusy()` dreht das Symbol während des Abrufs — das können bis zu 20 s
sein, und ohne Zeichen wirkt der Knopf kaputt.
Zwei Fehler des Vorgänger-Commits fielen dabei auf:
- `padSource` und der Takt standen HINTER dem `await` des ersten Abrufs. Ein
einziger Fehlschlag — bei dieser Gegenseite der Normalfall — ließ das Dokument
tot liegen, ohne Knopf und ohne Wiederversuch, bis zum Neuladen der Seite.
Genau das war die vom Nutzer gemeldete Fehlermeldung.
- Kein Erfolg räumte die Warnung des ersten Versuchs weg; sie hätte gestanden,
während der Text längst da war.
Dazu: `deleteDoc()` beendet die Pad-Quelle, sonst legte ein späterer Abruf das
gelöschte Dokument wieder an und aktivierte es auch gleich.
Nebenbefunde, beide nachgemessen und in D31 festgehalten:
- Das *Tippen* im Etherpad-Editor war der letzte offene Punkt. Der Nutzer hat
` - [ ] Layout` eingerückt eingetippt; der Export gibt es zeichengenau
zurück (vier echte Leerzeichen, kein Tab, kein Listen-Markup).
- Einbetten verweigert der Server nicht: kein `X-Frame-Options`, keine CSP mit
`frame-ancestors`, und im Versuch baute das Pad in einem fremdstämmigen Rahmen
seine Editorframes auf. Preis ist `SameSite=Lax` am Autoren-Cookie (jedes
Laden ein neuer Autor; nur serverseitig zu beheben) und der Verlust beider
Richtungen von D25, falls das Textpanel ersetzt wird.
86 Tests (85 -> 86); Schreibschutz zeigt den Text jetzt in Tinte statt grau —
hier wird gelesen, der Plantext ist der Hauptinhalt.
|
||
|
mhoennig
|
3310cab7be |
frontend: ?etherpad= — Echtzeit-Zusammenarbeit über ein geliehenes Pad
Werkbaum hat kein Backend, und das eigentlich Schwere an gemeinsamem Bearbeiten ist das Zusammenführen gleichzeitiger Änderungen — im Plan als `[!] Merging simultaneous edits` markiert. Etherpad hat das gelöst. Also geliehen statt nachgebaut: das Pad ist die Schreibfläche, Werkbaum die Ansicht. Nachgemessen an pad.hostsharing.net, bevor irgendwas gebaut wurde: - der Klartext-Export sendet `Access-Control-Allow-Origin: *`, - das kanonische Beispiel (SPEC §10) kommt byte-identisch zurück, - der HTML-Export zeigt kein Listen-Markup — Etherpad deutet `-` nicht zur Aufzählung um und behält die führenden Leerzeichen. Das war das Risiko, das die Idee hätte erledigen können. Nicht geprüft ist das Tippen im Etherpad-Editor selbst (Tab-Einrückung, mögliches Auto-Bullet); dafür braucht es einen echten Browser. Eigener Parameter statt `?sourceUrl=`: Die URL, die ein Mensch in der Hand hat, ist die Pad-URL — `/export/txt` hängt Werkbaum selbst an. Vor allem aber lizenziert der eigene Parameter das andere Verhalten, sodass D23 unangetastet bleibt: `sourceUrl` heißt weiter „statische Datei, einmal pro Laden geholt", bestehende Links bekommen kein Polling. Name und id sind die vollständige Pad-URL (Pad-Namen sind nur pro Instanz eindeutig). Textfeld schreibgeschützt, Knopf öffnet das Pad: ohne das verschwände getippter Text beim nächsten Abruf. Schrift bleibt Tinte statt grau — hier wird gelesen, der Plantext ist der Hauptinhalt. Drei Riegel im Takt, jeder aus einem echten Fehler: - `padBusy` — im Netzwerk-Mitschnitt stapelten sich die Abrufe, weil die Gegenseite langsamer war als der Takt; eine spät eintreffende alte Antwort hätte neueren Text überschrieben, - Abbruch nach 10 s — sonst bliebe der Riegel bei hängender Gegenseite für immer zu, - `visibilityState` + `visibilitychange` — nicht im Hintergrund abrufen, aber bei Rückkehr sofort. Der Stabilitätstakt übernimmt erst beim zweiten gleichen Abruf, sonst sieht man die anderen mitten im Tippen. Die Normalisierung der Pad-Adresse liegt headless in `remote.js`, damit sie testbar ist (23 neue Tests, 60 -> 83). Im Vorschau-Browser meldet `visibilityState` „hidden" und HMR lädt bei jeder Quelländerung neu — ein Reload sieht wie eine geglückte Übernahme aus; nachgewiesen wurde die Übernahme deshalb mit einem Marker auf `window`, der einen Reload nicht überlebt. SPEC §9 zuerst, dann D31, dann Code. Der Plan bekommt den Knoten nach D30 mit `[x]`, nicht `[^]`. |
||
|
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> |