Meilensteine sind die nutzersichtbare Historie und bleiben; Sync-Versionen tragen die Diffs des Live-Editings und werden nach der Aufbewahrungsfrist verdichtet (D76). Ohne die Trennung wuerde die Historie beim getakteten Schreiben zum Transaktionslog. Die Schreibpause braucht keinen Zeitgeber: Die naechste Aenderung stellt fest, dass eine Pause war, und befoerdert die Version davor nachtraeglich. Strukturelle Aenderungen sind immer Meilensteine. Das Historie-Repository greift jetzt gezielt zu (eine Version, juengster, aeltester, Meilensteine, maxVersion) statt stets alle Eintraege zu laden und in Kotlin zu filtern — bei hunderten Volltext-Versionen je Dokument war das untragbar. Restore liest den letzten Stand aus dem Tombstone: der ueberlebt das Verdichten, die Version davor womoeglich nicht. Dabei die D76-Unschaerfe aufgeloest: RESTORED heisst nur noch "ein geloeschtes Dokument ist wieder da" (der Client hebt seine Sperre auf), der Rueckfall eines lebenden Dokuments ist ROLLED_BACK. 81 Tests. Gegenprobe: Schreibpause ignoriert -> genau die danach benannte Zusicherung faellt; Rueckfall wieder als RESTORED -> Unit- und Cucumber-Test dazu; juengster Stand aus der Historie genommen -> genau einer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.9 KiB
Werkbaum · Backend
Kotlin/Spring-Boot-Anwendung. Aufgaben: Persistenz der Notationstexte,
Live-Editing (D76), Taiga-Integration (REST-API, #ref-Auflösung,
Status-Sync), später Tenzu-Adapter.
Stand: Gerüst steht — Dokumenten-CRUD mit Historie und Wiederherstellung,
API-First aus src/main/resources/openapi/api.yaml, H2 mit Liquibase.
Kommandos in README.md hier. Live-Editing (D76,
docs/live-editing-proposal.md) ist in Arbeit: Schritte 1 und 2 der
Reihenfolge dort sind gebaut (Zeilen-Diff in de.werkbaum.diff, Historie in
zwei Ebenen), ab Schritt 3 (PATCH /content) steht es aus.
Konventionen
- Kotlin, Spring Boot 4, Gradle (Kotlin DSL), JDK 21.
- Paketwurzel
de.werkbaum; Schichten:api(Controller),domain,service,repository(Interfaces),persistence(JPA), späterintegration.taiga(Client, Mapping). - API First: Interfaces und Modelle werden aus der OpenAPI-Spezifikation generiert; der Controller implementiert sie. Ändert sich die Spec, schlägt der Compile fehl — genau so ist es gewollt.
- Tests mit JUnit 5 als Runner + Kotest-Assertions (
shouldBe,shouldContain,shouldThrow) und MockK; Verhalten per Cucumber gegen die laufende Anwendung (RestTestClient, nicht TestRestTemplate — das ist in Boot 4 Auslaufmodell). Taiga-Client gegen aufgezeichnete Antworten (WireMock), nie gegen Live-Instanzen. - Konfiguration über
application.yaml+ Umgebungsvariablen; keine Zugangsdaten im Repository. - Keine neuen Laufzeit-Abhängigkeiten ohne Rückfrage (Wurzel-CLAUDE.md); Test-Abhängigkeiten sind unkritisch, sie landen in keinem Artefakt.
Spring Boot 4 — drei Fallen (D13-Nachtrag)
Vieles ist aus dem Kern in eigene Module gewandert. Was uns getroffen hat:
spring-boot-starter-testbringt keinTestRestTemplate/RestTestClientmit — dafürspring-boot-resttestclient.@SpringBootTeststellt die Test-Client-Bean nicht mehr von selbst bereit:@AutoConfigureRestTestClientgehört an die Testkonfiguration.org.liquibase:liquibase-coreallein bringt die Autokonfiguration nicht mehr mit; ohnespring-boot-starter-liquibaseläuft keine Migration, und der Fehler zeigt sich erst spät als „Schema validation: missing table".
Wichtig (D14 — Parser-Hoheit)
Das Backend parst die Notation nicht. Es speichert den Text als Ganzes und arbeitet mit expliziten Metadaten. Sollte Backend-Parsen doch nötig werden: zuerst DECISIONS ergänzen, dann gegen die gemeinsamen Fixtures aus docs/SPEC.md §10 testen — niemals eine zweite, abweichende Grammatik pflegen.
Taiga-Mapping (Vorgabe aus docs/ROADMAP.md)
#123referenziert Epic/User Story/Task/Issue; Auflösung liefert Titel, URL, Status. Status-Mapping Taiga-Workflow → Notation konfigurierbar (Default: „New"→[ ], „In progress"→[~], „Ready for test"→[/], „Done"→[x], „Archived"→[^]).