werkjournal/docs/implementation/inventory.md

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.<name> 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.