Files
werkbaum/CLAUDE.md
T
mhoennigandClaude Fable 5 623b68799f docs: jeder Knoten des Werkbaum-Plans bekommt ID und Beschreibung (D48)
Der mitgelieferte Plan ist Vorzeigedokument und Projektübersicht zugleich —
und war für Fremde weitgehend stumm. „Stay greedy, but say so" oder „Cycles
are legal" sagt jemandem, der die DECISIONS nicht gelesen hat, nichts. Jetzt
trägt jeder der 172 Knoten eine ID und einen erläuternden Block.

Langform hinter dem `---`-Trenner statt `"`-Zeilen: Bei 172 Knoten
verdreifachte die Kurzform die Höhe des Baumteils und machte ihn unlesbar —
gerade das, was der Plan zeigen soll. Genau der Fall, für den die Langform
gebaut wurde (D40). Die eine vorhandene `"`-Zeile an „Collaborating" bleibt
stehen und führt die Kurzform weiter vor; beide Formen zum selben Knoten
hängen sich planmäßig aneinander.

ID-Schema `#bereich.task`, dritte Stufe nur wo nötig: acht Bereiche mit kurzen
Kürzeln (not, ed, bld, be, col, mmd, idea, trk), Wurzel `#wb`. Vier bereits
vergebene IDs sind ins Schema gewandert (`#closure` -> `#ed.closure`,
`#scaffold` -> `#be.scaffold`, `#docs` -> `#be.docs`, `#resolve` ->
`#trk.resolve`), die fünf `:#…`-Verweise darauf mit.

Englisch wie der Plan, ein bis zwei Sätze je Knoten: was es ist und warum es
im Plan steht.

Nachgemessen: 172 Knoten, 172 eindeutige IDs, kein Knoten ohne Beschreibung,
0 Warnungen, Pfad weiterhin exakt mit 24 Stationen. Im Editor tragen alle 149
sichtbaren Knoten die ”-Marke, der Tooltip zeigt Text, Trennstrich und
Kurz-Fakten; der Cursor in einem Block wählt den beschriebenen Knoten aus
(D40-Nachtrag 2, auf Kopf- und Textzeile geprüft, der Trenner selbst wählt
nichts). Datei 189 -> 902 Zeilen, Bundle 443 -> 506 kB (gzip 247 -> 270 kB).
236 Tests grün.

CLAUDE.md hält fest, dass neue Knoten immer zu zweit anzulegen sind: Zeile im
Baum und Block unten.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-23 13:43:14 +02:00

2.2 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.md
  • backend/ — Kotlin/Spring-Boot-Anwendung (Taiga-Integration, Persistenz). Eigene Regeln: backend/CLAUDE.md
  • docs/ — Projektdokumente · brand/ — Marke (brand/BRAND.md)

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

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.