mhoennig
ac6df1bb6b
Deployen, Log ansehen, Dienst schalten und fragen was laeuft waren vier verschiedene Beschwoerungen, drei davon von Hand als ssh + systemctl. Jetzt: remote backend deploy|upload|setup|install-jdk|reset-password remote backend start|stop|restart|status|enable|disable remote backend log|info|documents|backup remote frontend deploy|preview|info remote ssh Die Skripte unter scripts/ bleiben die Implementierung und einzeln aufrufbar; tools/remote bringt nur mit, wofuer es bisher nichts gab. Wo ein Schalter noetig war, kam er ins Skript statt ins Werkzeug: --unit-only in deploy-backend.sh (sonst kennte eine zweite Stelle die Unit-Platzhalter) und --dry-run in deploy-prod.sh, das die Befoerderung ausdruecklich mit abschaltet. Neu ist die Sicherung: H2 haelt die Datei offen, also anhalten, holen, wieder starten (gemessen ~8 s Auszeit) - und das Archiv lesen, bevor der Befehl es behaelt. Gegenprobe von Hand: lokal ausgepackt, Backend mit --werkbaum.data-dir dagegen gestartet, es liefert genau die Dokumente des Servers. .envrc legt tools/ auf den PATH (direnv), 217 Plan-Knoten, 0 Warnungen.
2.9 KiB
2.9 KiB
Werkbaum
Monorepo für Werkbaum: eine textuelle WBS-Notation mit Und/Oder-Zerlegung („all of" nebeneinander, „any of" untereinander) samt Editor und geplantem Integrations-Backend.
Struktur
frontend/— Editor (Vanilla HTML/CSS/JS). Eigene Regeln: frontend/CLAUDE.mdbackend/— Kotlin/Spring-Boot-Anwendung (Taiga-Integration, Persistenz). Eigene Regeln: backend/CLAUDE.mddocs/— Projektdokumente ·brand/— Marke (brand/BRAND.md)tools/remote— alles, was auf dem Server passiert, als Ziel und Aktion (remote backend deploy,remote frontend preview, …;remote --help). Die Arbeit machen weiterhin die Skripte unterscripts/—remoteist die Vordertür davor. Braucht ein Skript einen neuen Schalter, kommt der ins Skript, nicht ins Werkzeug (D77-Nachtrag).
Verbindliche Referenzen
- Sprachdefinition: @docs/SPEC.md — die Notation ist der gemeinsame Vertrag
von Frontend und Backend. Syntaxänderungen: SPEC zuerst, dann Code,
dann die Agenten-Fassung
frontend/public/llms.mdnachziehen (SPEC §13, D43). - Entscheidungen: @docs/DECISIONS.md — respektieren; Abweichungen als neuen Eintrag begründen, alte Einträge nie löschen. Besonders D13 (Backend-Stack) und D14 (Parser-Hoheit) beachten.
- Ziele: docs/ROADMAP.md · Offene Arbeit: docs/TASKS.md (Checkboxen pflegen).
- Änderungen: @docs/CHANGELOG.md — jedes Feature und jeder behobene Fehler
bekommt dort eine Zeile, englisch, ein Satz, unter der Überschrift des
Tages (
## JJJJ-MM-TT). Die Datei speist das Neuigkeiten-Popup im Editor (D58); ohne die Zeile geschieht die Änderung für den Benutzer unsichtbar.
Querschnitts-Konventionen
- Doku auf Deutsch. Die Editor-UI ist mehrsprachig (DE/EN/ES/FR direkt,
PL/RU/HI/ZH/JA hinter dem „…“-Aufklapper des Umschalters oben rechts);
Deutsch ist die Quellsprache — neue UI-Texte zuerst auf Deutsch im
I18N-Objekt (frontend/index.html) anlegen, dann in alle Sprachen übersetzen. - Keine neuen Laufzeit-Abhängigkeiten ohne Rückfrage (gilt in beiden Teilen).
- Der Notationstext ist das führende Datenformat; kein Teil erfindet ein eigenes Speicherformat für die Struktur.
- Im mitgelieferten Plan
docs/examples/werkbaum.werkbaumbekommt jeder Knoten eine ID nach dem Muster#bereich.task(dritte Stufe nur, wo es sonst kryptisch würde) und einen Beschreibungsblock hinter dem----Trenner, englisch, ein bis zwei Sätze — siehe D48. Neue Knoten also immer zu zweit anlegen: Zeile im Baum und Block unten. - Im mitgelieferten Plan
docs/examples/werkbaum.werkbaumbekommt eine fertige Funktion beim Mergen[x], nicht[^]. Auf „in Produktion" befördert erst der Deploy der stabilen Instanz (scripts/promote-shipped.sh, vondeploy-prod.shaufgerufen) — nur er macht die Aussage wahr. Siehe D30; SPEC §4 trennt beide Zustände ohnehin.