Zuhause ist künftig git.javagil.de/mi/werkbaum (origin); GitHub bleibt unter
dem Remote `github` ein Klon, den scripts/push-github.sh mit `main` versorgt —
nur vorwärts, nie erzwungen.
Der Klon bleibt aus zwei gemessenen Gründen: Gitea sendet auf raw-Dateien kein
Access-Control-Allow-Origin (nachgemessen an mi/werkdock), die
?sourceUrl=-Beispiellinks der READMEs müssen also auf raw.githubusercontent.com
zeigen; und der Pages-Workflow lässt sich nicht mitnehmen.
Footer, llms.txt und llms.md zeigen jetzt auf Gitea (Repo-Seite ohne Anmeldung
lesbar, HTTP 200 geprüft); beide COMMIT_URL-Stellen (deploy-prod.sh und der
Pages-Workflow) ziehen mit. deploy-prod.sh prüft origin und github getrennt und
erinnert an das Spiegeln, statt selbst zu pushen.
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>
.md ist die zum Inhalt ehrliche Endung (es IST Markdown); Link rückt zur
Werkzeug-Ecke des Footers. Pipelines, SPEC §13, CLAUDE.md und Plan
nachgezogen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Englische Markdown-Kurzfassung der Notation (Syntax + Semantik: Gates,
Status, Ränge, Extraktionsreihenfolge, Abhängigkeits- und
Beschreibungsregeln, Schreib-Faustregeln, vollständiges Beispiel), damit
Agenten Werkbaum lesen und schreiben können. Name und Ort folgen der
llms.txt-Konvention; Quelle in frontend/public/ (Dev-Server und dist/
gratis), Pages-Workflow und deploy-prod.sh kopieren sie mit je einer
Zeile, Footer verlinkt den Dateinamen (keine i18n nötig, Tooltip DE·EN).
Die SPEC bleibt normativ — Hausregel jetzt: SPEC zuerst, dann Code, dann
llms.txt nachziehen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Node 20 ist seit ~April 2026 End-of-Life. Node 24 "Krypton" ist der aktuelle
Active LTS und passt zur node24-Laufzeit der Actions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
GitHub erzwingt node24 für node20-Actions (Deprecation vom 2025-09-19). Die fünf
Pages-Actions auf ihren jeweils ersten node24-Major gehoben:
checkout v4->v5, setup-node v4->v5, configure-pages v5->v6,
upload-pages-artifact v3->v5, deploy-pages v4->v5.
Der Build-`node-version: 20` (für npm ci/test/build) ist davon unberührt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Latest-Build-Hinweis wandert vom Workflow-sed in die App (app.js,
mountBuildBadge), damit ihn auch der Dev-Server zeigt — ein Post-Build-sed
erreicht den Dev-Server nicht. Logik umgekehrt: Hinweis ist der Normalfall,
nur die produktive Installation schaltet ihn ab.
Drei Zustaende ueber Vite-Env VITE_BUILD_BADGE (Auswertung in app.js):
- Dev-Server (import.meta.env.DEV) -> 🔧 "Vorschau/lokaler Entwicklungsstand"
- Default `npm run build` (Env ungesetzt) -> 🚧 "latest build"; der Pages-
Deploy nutzt den Default und traegt den Hinweis dadurch automatisch (die
sed-Injektion entfaellt).
- `npm run build:prod` (Vite-Modus prod, .env.prod: VITE_BUILD_BADGE=none)
-> KEIN Badge; esbuild eliminiert den Zweig als toten Code.
Verifiziert zur Laufzeit (Dev + `vite preview` auf beiden Builds): 🔧 im Dev,
🚧 im Default-Build, gar nichts im Prod-Build (Titel sauber "Werkbaum").
34 Vitest-Tests gruen, Workflow-YAML/Shell gueltig.
Doku: D16 fortgeschrieben (quellbasiert/env statt sed, Begruendung); README
(de/en) mit Prod-Build-Anleitung inkl. LICENSE-/Versions-Caveats; frontend/
CLAUDE.md; .claude/launch.json bekommt einen frontend-dist-Preview (vite
preview, Port 8138) zum Verifizieren gebauter Dateien.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Pages-Deploy ist der frischeste Entwicklungsstand und kann Fehler
enthalten; die stabile Instanz laeuft woanders. Damit nur diese
Veroeffentlichung markiert ist, injiziert der Workflow nach demselben Muster
wie Version/LICENSE — also NUR auf der Site-Kopie — hinter dem Titel (Anker
</h1>, im Bundle eindeutig) ein kleines Symbol mit zweisprachigem Tooltip
(<span class="build-badge">🚧</span>). Quelle bleibt unberuehrt: ein schlichter
`npm run build` erzeugt die Datei ohne Hinweis. Als Deploy-Metainfo bewusst
nicht im I18N-Objekt (D14). D16 fortgeschrieben.
Verifiziert gegen das echte dist-Bundle: Badge genau 1x, Version 1.0.x +
Commit-Link unveraendert, frontend/index.html traegt 0 Badges.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Erster Schritt der Modularisierung (ROADMAP „tragfähige Codebasis",
TASKS Phase 1). Der bisher einzelne index.html-Prototyp wird zur Vite-App:
- CSS -> src/style.css, gesamtes JS -> src/app.js (noch als ein Modul;
Parser/Renderer werden in den folgenden Checkboxen herausgelöst).
- index.html ist der Vite-Entry (<script type="module" src="/src/app.js">).
- npm run build (vite + vite-plugin-singlefile) inlint JS+CSS+Favicon (als
data:-URI) in EINE self-contained dist/index.html -> bleibt file://-tauglich.
- Vitest als Testrunner eingerichtet (tests/, passWithNoTests bis Schritt 2/3).
- Pages-Workflow: Node + npm ci + npm test + npm run build, deployt dist/;
Favicon-sed entfällt (inline), nur ../LICENSE + Footer-Version bleiben.
- .claude/launch.json auf Vite-Dev-Server (Port 8137) umgestellt.
Entscheidung als D19 dokumentiert (weicht D11 „kein Build-Zwang" bewusst auf,
hält aber D16 file://-Versprechen über die gebündelte Datei). README (de/en)
und frontend/CLAUDE.md um Dev-/Build-/Test-Workflow ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Im Footer sind "Werkbaum" und die Versionsnummer jetzt zwei Links:
- "Werkbaum" -> Repo-Startseite (wie bisher).
- Versionsnummer (<a class="ver">) -> exakt der deployte Commit.
CI setzt beim Build sowohl den Versionstext als auch den href der
ver-Anchor: COMMIT_URL=.../commit/$(git rev-parse HEAD); zwei gezielte
seds (href + Text). Lokal zeigt die Version "1.0" und verlinkt die
Commits-Uebersicht als Fallback.
Verifiziert: YAML gueltig; Trockenlauf ersetzt href -> commit/<sha> und
Text -> 1.0.7, "Werkbaum"-Link unveraendert. Preview lokal: Name -> Repo,
Version -> /commits/main.
Doku: README (EN+DE) Deployment + DECISIONS D16 ergaenzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Micro-Version jetzt commit-basiert statt aus github.run_number:
- Major.Minor in neuer Datei VERSION (per Bump-Commit gepflegt).
- Micro = Commits seit dem letzten VERSION-Bump
(git rev-list --count <VERSION-Commit>..HEAD) -> beginnt nach einem
Bump wieder bei 0 (SemVer-artig, z. B. 1.0.0, 1.0.1, dann 1.1.0).
- checkout mit fetch-depth: 0 (flacher Klon zaehlte sonst nur 1 Commit).
- sed ersetzt jetzt ">Werkbaum <ziffern></a>" (regex), damit auch nach
einem Major/Minor-Bump im Quelltext getroffen wird; viewport-/xml-1.0
bleiben unberuehrt.
Vorteil ggue. Run-Nummer: vollstaendig aus dem Repo reproduzierbar,
zaehlt keine fehlgeschlagenen/manuellen Laeufe, kein Rueckschreiben.
Doku: README (EN+DE) Deployment-Abschnitt und DECISIONS D16 aktualisiert.
Keine SPEC-Aenderung (Notation unberuehrt).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Beim Site-Build ersetzt der Workflow ">Werkbaum 1.0</a>" durch
">Werkbaum 1.0.${{ github.run_number }}</a>" (per sed, nur auf der
Site-Kopie). Die Micro-Version steigt so bei jedem Deployment monoton
um 1 — ohne Commit/Tag zurueck ins Repo und ohne selbstausloesenden
Deploy-Zyklus. run_number via env BUILD_VERSION injiziert. "1.0" bleibt
die manuell gepflegte Basis und die Version beim lokalen Oeffnen; die
viewport-/xml-"1.0" bleiben unberuehrt (Anker >...</a> als Ziel).
Doku: README (EN+DE) Deployment-Abschnitt und DECISIONS D16 ergaenzt.
Keine SPEC-Aenderung (Notation unberuehrt).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Offizieller Actions-Weg (upload-pages-artifact + deploy-pages) mit
permissions pages/id-token und concurrency-Gruppe "pages"; Trigger:
Push auf main + workflow_dispatch. Vitest-Step als Platzhalter
auskommentiert (Tests folgen, TASKS.md Phase 1).
Site-Aufbau: frontend/index.html an die Wurzel-URL, dazu docs/brand/
(Favicon) und LICENSE (MIT-Link im Footer). Die ../-Pfade der Quelle
zeigten von der Wurzel aus über die Site hinaus; statt den Editor zu
aendern, zieht der Workflow sie nur auf der Site-Kopie per sed gerade
(Editor-Quelle bleibt unveraendert, lokal weiter nutzbar). backend/
und uebrige docs/ werden nicht veroeffentlicht.
Doku: README-Abschnitt "Deployment" (inkl. einmaliger Settings-
Umstellung auf Source "GitHub Actions", Repo muss oeffentlich sein),
TASKS.md-Rubrik "Deployment" abgehakt, DECISIONS D16. Hinweis: der
Auftrag nannte "D15", das war aber schon fuer den kompakten Modus
vergeben -> als D16 angelegt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
