# Bestandsaufnahme für den Werkbaum-Knoten inventory Stand: 2026-09-08. Bestandsaufnahme abgeschlossen; die nachfolgenden Abschnitte halten auch den chronologischen Prüfverlauf fest. Native Machbarkeit und produktiver Betrieb sind damit noch nicht nachgewiesen. ## Verifizierte lokale Grundlagen - Werkjournal-Repository: `mih09-git@git.javagil.de:mi/werkjournal.git`, Branch `main`. - Bisher vorhanden: Werkbaum, sechs Gherkin-Dateien, `.envrc`. Kein Build, keine Anwendung und keine Deployment-Konfiguration. - Keine anwendbare AGENTS.md im Projekt oder den geprüften übergeordneten Verzeichnissen gefunden. - Lokales Werkator-Referenzrepository: `/home/mi/Projekte/werkator`, HEAD `8943095`. - Lokales Werkdock-Referenzrepository: `/home/mi/Projekte/werkdock`, HEAD `1160d30`. - Gelesen: Werkdock README und CI-Konfiguration, Werkator CI-Konfiguration und `docs/deployment.md`; Konfiguration und Buildrunner gezielt durchsucht. ## Konsequenzen Werkdock hat bereits eine Docker-kompatible CLI mit import/load, run, Volumes und doctor. Die Dateisicht ist isoliert; Netzwerk, UID und weitere Hostressourcen werden geteilt. Ein Docker-Engine-API-Daemon für Testcontainers ist ausdrücklich noch nicht implementiert. Tests dürfen deshalb nicht stillschweigend einen Docker-Daemon auf dem Webspace voraussetzen. Werkator verwendet `builds.` und Werkdock über `werkdock.enabled/rootfs/binary/env`. Im aktuellen ConfigLoader sind enabled, rootfs und binary gepinnt. Das Werkdock-Repository verlangt in seiner eigenen CI mindestens Werkator 1.0.1; daraus folgt keine Bestätigung der tatsächlich installierten Serverversion. Die aktuelle Werkator-Betriebsanleitung beschreibt eine verwaltete Instanz mit separater Repository-Registrierung. `tools/remote ... repo-add` klont und initialisiert, schreibt aber die Instanzregistrierung absichtlich nicht automatisch. Bestehende Instanz nicht ungeprüft verändern. Die Anleitung enthält ein erprobtes Muster für statische Wartungsseiten über `.htaccess` und ErrorDocument 502/503/504. Für Werkjournal zusätzlich die explizite Wartung vor Migration sowie bereits offene Flow-Clients berücksichtigen. ## Noch erforderlich Das konkrete SSH-Ziel und die Konfigurationsquelle für Werkjournal sowie die zu verwendende Werkator-Instanz fehlen im Werkjournal-Repository. Der Git-SSH-Nutzer mih09-git ist kein belegter Deployment-Nutzer. Nach deren Benennung sind installierte Version, Rootfs/GraalVM, Ressourcen, Zielport, systemd und Proxy read-only zu prüfen. Keine Zugangsdaten in diese Dokumentation aufnehmen. Bis diese Frage beantwortet ist, bleibt der Knoten in Arbeit. Commit und Push erfolgen nach Abschluss des Knotens gemäß Nutzerauftrag. ## Werkator-Instanz tatsächlich geprüft Vom Nutzer benannt: SSH `mih09-werkator@mih09.hostsharing.net`, öffentliche URL `https://werkator.javagil.de`. SSH-Aufrufe wegen Host-Ratelimit bündeln und zeitlich auseinanderlegen; keine enge Polling-Schleife. Lesend am 2026-09-08 festgestellt: - Debian 12 Bookworm, x86_64. - Werkator v1.2.0 unter `~/.werkator/werkator/bin/werkator`. - Werkdock `0.1.0-dev` unter `~/.werkator/bin/werkdock`; nicht im PATH der nicht interaktiven SSH-Shell. - `werkator-werkator.service` ist aktiv; Instanzkonfiguration nennt Port 18089 und maxConcurrent 1. - Vorhandene Repository-Verzeichnisse: werkator, werkdock, werkbaum, michael.hoennig.de. Kein Werkjournal-Verzeichnis im aufgelisteten Home-Verzeichnis. - Importiertes Image `werkator-buildenv-d64103d02393`; Node im Rootfs gefunden. GraalVM-Verfügbarkeit noch nicht verifiziert: die begrenzte Dateisuche ist kein Nachweis der Abwesenheit. - Hostweite Momentaufnahme: etwa 4.8 GiB RAM, 2.4 GiB verfügbar; Swap bereits genutzt. Das sind keine bestätigten Benutzer-/cgroup-/Quota-Budgets. Freier Dateisystemplatz ist ebenfalls keine Aussage über das Hostsharing-Paketquota. Keine Serverkonfiguration geändert, keine Dienste neugestartet und keine Geheimnisse ausgegeben. Die Werkator-Zuordnung ist damit geklärt. Offen bleibt das separate SSH-Ziel für die produktive Werkjournal-Anwendung; CI- und Git-Benutzer nicht automatisch als App-Benutzer verwenden. ## Produktives Zielkonto geprüft Vom Nutzer festgelegt: `mih04-werkjournal@mih04.hostsharing.net`; kanonische URL `https://werkjournal.javagil.de` ohne www. Lesend verifiziert: Home `/home/pacs/mih04/users/werkjournal`, Debian 12 Bookworm x86_64, systemd User Manager erreichbar, Linger=yes. Noch kein Werkjournal-Dienst vorhanden. Domainverzeichnis `/home/pacs/mih04/users/werkjournal/doms/werkjournal.javagil.de`; sowohl `htdocs` als auch `htdocs-ssl` vorhanden. Das Domainverzeichnis gehört dem App-Nutzer mit Gruppe httpd; die verwaltete doms-Struktur nicht rekursiv chown/chmod ändern. Deploymentlayout: native Releases und persistente Daten unter dem noch anzulegenden `~/opt/werkjournal`, Unit unter `~/.config/systemd/user/werkjournal-backend.service`, geschützte Laufzeitkonfiguration getrennt davon. Nur öffentliche Proxy-/Wartungsdateien unter `~/doms/werkjournal.javagil.de/htdocs-ssl`. H2, Backups, Binärdateien und Geheimnisse niemals unter die Document Roots legen. HTTP-Weiterleitung gehört nach htdocs. Auffälligkeit: Bereits htdocs-ssl/.htaccess enthält `Redirect permanent / https://werkjournal.javagil.de/`. Das kann auf HTTPS eine Selbstweiterleitung erzeugen und muss beim koordinierten Deployment durch die Proxy-/Wartungsregeln ersetzt werden. Noch nichts am Server verändert. Offene Zielangabe: zugewiesener Backend-Userport. Die Liste momentan belegter Ports beweist keine Zuteilung eines freien Ports; daher keinen beliebigen Port als autorisiert übernehmen. ## Abschluss und Übergabe Backend-Port vom Nutzer bestätigt: **18090**, Bindung **127.0.0.1**. Kanonische URL bleibt https://werkjournal.javagil.de ohne www. Keine Änderung am Server für diese Bestandsaufnahme erforderlich. Die vertiefte Pfadsuche im vorhandenen Buildimage findet OpenJDK 21, jedoch kein native-image innerhalb der geprüften Tiefe. Für den nativen Prototyp daher eine explizite GraalVM-Buildumgebung bereitstellen und deren Compiler/Systembibliotheken prüfen; das bestehende Image nicht als native-ready deklarieren. Werkator-Service zeigt MemoryHigh/MemoryMax=infinity und TasksMax=5855. Keine Benutzer-Diskquota gemeldet; Paket-/Gruppenlimits bleiben davon unbewiesen und sind vor großen Image-Uploads zu prüfen. Der Knoten inventory ist als Bestandsaufnahme erledigt: reale Konten, Hostplattformen, Pfade, Dienst, Port, vorhandene Werkzeuge und konkrete Lücken sind erfasst. Die praktische Image-Erstellung, native Funktionsnachweise und Ressourcenmessung gehören zu native-spike; der sichere CI-Deployment-Aufruf zu remote-ci, die tatsächliche Backup-Wiederherstellung zu restore-test. Keine dieser Folgearbeiten ist hier als erledigt markiert.