Drei Teile, die das Frontend-Deploy nicht braucht: ein eigenes JDK 21 im Home
des Servers (dort ist nur 17 installiert, und die Toolchain zu senken hiesse,
Entwicklung und Produktion auseinanderlaufen zu lassen), ein systemd-User-Unit
statt nohup, und die Proxy-Regel in der .htaccess — gemessen ist, dass das
P-Flag auf diesem Hoster erlaubt ist und eine Verbindung 30 s durchhaelt.
Der Port steht an genau einer Stelle: deploy-prod.sh setzt ihn in die
Proxy-Regel, deploy-backend.sh in die Unit. Zwei Zahlen, die zueinander passen
muessen, sind eine zu viel.
Die JVM-Flags sind gemessen, nicht geschaetzt. Mein erster Entwurf setzte
-Xmx384m; nachgemessen kam heraus, dass die Obergrenze der kleine Hebel ist:
Ohne Freiraum-Verhaeltnisse behaelt der Kollektor den gewachsenen Heap, obwohl
nach einem GC nur ~45 MB leben. Mit ihnen 174 MB RSS statt 291 MB ohne jede
Angabe — auf einem Host mit rund 300 MB frei ist das der Unterschied zwischen
"passt" und "draengt die Datenbank weiter in den Swap".
Zwei Fallen sind eingebaut, weil beide nur am Ziel auffielen: systemd
expandiert kein $HOME (deshalb %h), und `systemctl --user` findet ohne
XDG_RUNTIME_DIR seinen Manager nicht.
Geprueft bis an die SSH-Grenze: Das Jar startet mit genau den Flags der Unit
in einer Sekunde, antwortet auf die Lebendprobe mit 404 und ist von aussen
nicht erreichbar; die erzeugte Unit besteht systemd-analyze verify; der ganze
Ablauf lief mit gestelltem ssh/rsync durch; deploy-prod.sh liefert die
Proxy-Regel mit eingesetztem Port aus. Der Deploy selbst laeuft erst, wenn
jemand ihn startet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Manifest mit Icons aus der Marke und Standalone-Fenster; ein bewusst dummer
Service Worker beantwortet nur die App-Navigation network-first und hält die
zuletzt gesehene Fassung für den Offline-Fall — die Update-Prüfung (D45)
bleibt dadurch unverändert wahr, der skipWaiting-Lebenszyklus entfällt. Die
installierte App registriert sich für .werkbaum-Dateien (file_handlers +
launchQueue -> adoptFile). Beide Deploy-Wege kopieren die App-Hülle mit;
.htaccess liefert .webmanifest mit MIME-Typ aus.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Anlass war die Frage, ob `llms.md` ein guter Name ist. Zwei Befunde:
1. Der Zweck der Konvention ist ein anderer, als D43 annahm. llmstxt.org
über die eigene Datei: „a markdown file that provides brief background
information and guidance, along with links to markdown files providing
more detailed information“ — ein Index, kein Inhalt. Der 211-Zeilen-
Leitfaden ist genau eine jener verlinkten Dateien; `llms.md` ist damit
der richtige Name, es fehlte der Wegweiser davor.
2. `llms.md` kam auf der stabilen Instanz falsch kodiert an: Apache kennt
`.md` nicht und sendet GAR KEINEN Content-Type, der Browser rät
windows-1252. Gemessen: characterSet=windows-1252, aus „notation —
guide“ wurde „notation â€" guide“, 31 Zeilen betroffen. GitHub Pages
liefert dieselbe Datei korrekt als text/markdown; charset=utf-8 aus.
- frontend/public/llms.txt: Index nach der Konvention (Titel, Blockquote,
Notation in Kurzform, ## Docs, ## Optional). Rein ASCII — er ist die
Datei, die ein fremder Agent ungefragt abruft, und soll auch dort
ankommen, wo ein Server die Kodierung verschweigt. Alle 5 Links: 200.
- scripts/prod.htaccess: AddType für .md/.txt/.werkbaum, von
deploy-prod.sh als .htaccess gespiegelt. Nicht in public/ — dort landete
es wirkungslos im Pages-Artefakt. Rückweg bei 500 steht in der Datei.
- Beide Deploy-Wege kopieren llms.txt mit.
SPEC §13 + D43-Nachtrag 2 (mit Richtigstellung der D43-Annahme);
Plan: #not.llms.index [x]. 243 Tests grün, Plan 157 Knoten, 0 Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
