mhoennigandClaude Fable 5
623b68799f
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>
42 lines
2.2 KiB
Markdown
42 lines
2.2 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)
|
|
|
|
## 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.
|