Files
werkbaum/CLAUDE.md
T
mhoennig ac6df1bb6b feat(tools): remote <ziel> <aktion> als Vordertuer zum Server (D77-Nachtrag)
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.
2026-08-26 19:59:24 +02:00

51 lines
2.9 KiB
Markdown

# 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.md
- `backend/` — Kotlin/Spring-Boot-Anwendung (Taiga-Integration, Persistenz).
Eigene Regeln: backend/CLAUDE.md
- `docs/` — 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 unter `scripts/``remote` ist 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.md` nachziehen
(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.werkbaum` bekommt **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.werkbaum` bekommt eine
fertige Funktion beim Mergen **`[x]`**, nicht `[^]`. Auf „in Produktion"
befördert erst der Deploy der stabilen Instanz
(`scripts/promote-shipped.sh`, von `deploy-prod.sh` aufgerufen) — nur er macht
die Aussage wahr. Siehe D30; SPEC §4 trennt beide Zustände ohnehin.