feat(lesereisen): implement lesereisen

docs/adr/035-optional-string-three-way-patch-semantics.md

@@ -0,0 +1,43 @@
+# ADR-035 — `Optional<String>` for three-way PATCH semantics
+
+**Status:** Accepted  
+**Date:** 2026-06-08  
+**Issue:** #751 (JourneyItem CRUD API)
+
+## Context
+
+The `PATCH /api/geschichten/{id}/items/{itemId}` endpoint must distinguish three cases for the `note` field:
+
+| JSON body         | Intended meaning      |
+|-------------------|-----------------------|
+| `{"note": "text"}`| Set note to "text"    |
+| `{"note": null}`  | Clear the note        |
+| `{}` (absent)     | Leave note unchanged  |
+
+The standard library for this on Jackson 2.x is `jackson-databind-nullable` (`JsonNullable<T>` from `org.openapitools`). However, that library targets `com.fasterxml.jackson.*` (Jackson 2.x) and is incompatible with Spring Boot 4.0 / Spring Framework 7, which uses `tools.jackson.*` (Jackson 3.x). The module fails to register and throws at startup.
+
+## Decision
+
+Use `Optional<String>` with Java's default field initializer (`= null`) to encode the three states:
+
+```java
+@Data
+public class JourneyItemUpdateDTO {
+    private Optional<String> note = null;  // Java default — absent = no-op
+}
+```
+
+| Java value         | JSON wire         | Semantics     |
+|--------------------|-------------------|---------------|
+| `null` (default)   | field absent      | no-op         |
+| `Optional.empty()` | `{"note": null}`  | clear         |
+| `Optional.of("x")` | `{"note": "x"}`   | set           |
+
+Jackson 3.x natively maps a JSON `null` to `Optional.empty()` and leaves absent fields at their Java default. No custom module is needed.
+
+## Consequences
+
+- No external dependency for PATCH semantics — simpler pom.xml.
+- The DTO field type is `Optional<String>`, not `String` — service code must null-check the field first (`if (noteField == null) return;`) and then call `.orElse(null)` to unwrap.
+- This pattern applies to any future PATCH DTO that needs three-way semantics on a nullable field.
+- `jackson-databind-nullable` is removed from `pom.xml`; `JacksonConfig.java` is kept as a placeholder for future custom modules.

docs/adr/036-geschichte-responses-are-views-not-entities.md

@@ -0,0 +1,65 @@
+# ADR-036 — Geschichte responses are views assembled in-transaction, never entities
+
+**Status:** Accepted
+**Date:** 2026-06-10
+**Issue:** #753 (JourneyEditor frontend), PR #792 review
+
+## Context
+
+The project convention (CLAUDE.md §DTOs) has been: *"Response types are the model
+entities themselves (no response DTOs)."* That convention assumed entities whose
+associations are either eager or initialized by the time Jackson serializes.
+
+The lazy-fetch migration (ADR-022, `open-in-view: false`) broke that assumption:
+Jackson serializes **after** the service transaction has closed, so any lazy
+collection on a returned entity is a dead proxy. `Geschichte.items` (added with the
+Lesereisen data model, #750) made this concrete: every `PATCH /api/geschichten/{id}`
+(save draft, publish) failed with HTTP 500
+`LazyInitializationException: Geschichte.items … (no session)`.
+
+Per-endpoint force-initialization (`g.getItems().size()` inside the transaction)
+worked for `getById()` but is a footgun: every new write method must remember the
+trick, the entity carries a warning comment nobody reads, and the raw entity also
+leaks the `author` `AppUser` graph (email, password hash, groups).
+
+## Decision
+
+In the **geschichte domain**, controllers never return entities. Every response is a
+purpose-built read model assembled **inside** the service transaction:
+
+- `GET /api/geschichten` → `GeschichteSummary` (projection; never carries items;
+  author exposes names only — never email)
+- `GET /api/geschichten/{id}` → `GeschichteView` (with `AuthorView`, `PersonView`,
+  `JourneyItemView` items)
+- `POST /api/geschichten`, `PATCH /api/geschichten/{id}` → `GeschichteView`
+- JourneyItem endpoints → `JourneyItemView`
+
+The invariant: **entities never cross the controller boundary in this domain.**
+A view is constructed while the Hibernate session is open, so serialization can
+never touch a lazy proxy, and the response shape is an explicit, security-reviewed
+contract.
+
+## Alternatives rejected
+
+- **`@Transactional` on read/write methods + force-init (`getItems().size()`)** —
+  fixes one endpoint at a time, silently regresses when the next write method is
+  added, and still serializes the raw `AppUser` author graph.
+- **`open-in-view: true`** — re-opens the session during rendering; hides N+1
+  queries and couples the HTTP layer to Hibernate session lifetime. Rejected
+  already by ADR-022.
+- **Jackson `@JsonIgnore` on lazy fields** — loses the data the client needs
+  (items ARE the journey) instead of loading it deliberately.
+
+## Consequences
+
+- CLAUDE.md §DTOs names the geschichte domain as the exception to the
+  entities-as-responses convention. Other domains (document, person, tag) still
+  return entities; they predate ADR-022's lazy collections on their hot paths and
+  migrate opportunistically when they grow lazy collections of their own.
+- `npm run generate:api` must run after any view change — the generated
+  `Geschichte` schema no longer exists; frontend consumers use
+  `GeschichteView`/`GeschichteSummary`.
+- New geschichte endpoints must add a view (or extend an existing one), not return
+  the entity. The regression guards are `GeschichteHttpTest`
+  (`update_returns_200_and_serializes_items_open_in_view_false`) and
+  `GeschichteListProjectionTest`.

docs/adr/037-journey-items-serve-both-geschichte-subtypes.md

@@ -0,0 +1,78 @@
+# ADR-037 — `journey_items` serves both STORY and JOURNEY Geschichte subtypes
+
+**Status:** Accepted
+**Date:** 2026-06-11
+**Issue:** #795 (restore document management for STORY-type Geschichten), PR #804 review
+
+## Context
+
+V72 added the `journey_items` table as the backing store for Lesereisen (JOURNEY-type
+Geschichten). At the same time, the previous `geschichten_documents` join table was
+dropped (#753) and the restoration of a STORY-level document attachment mechanism was
+deferred to a future issue.
+
+`JourneyItemService.append()` contained an application-level type guard that rejected
+`append()` calls on STORY-type Geschichten with `GESCHICHTE_TYPE_MISMATCH`. This guard
+was the only place where the STORY restriction was encoded — the database schema never
+enforced it (no CHECK constraint, no partial index on `type='JOURNEY'`).
+
+When #795 restored document attachment for STORY-type Geschichten, the type guard was
+the only obstacle. Two implementation paths were considered:
+
+1. Keep an allowlist (`if type not in (JOURNEY, STORY) throw ...`) — dead code today
+   because `GeschichteType` is a two-constant enum; the branch can never be reached and
+   would fail the JaCoCo branch-coverage gate.
+2. Delete the guard entirely — the schema never encoded the restriction; deleting dead
+   application logic rather than replacing it with more dead logic.
+
+Path 2 was chosen.
+
+## Decision
+
+`journey_items` is the document-attachment mechanism for **both** `STORY` and `JOURNEY`
+subtypes. No application-level type guard governs which subtype may hold items. The only
+behavioral difference between the two subtypes' use of items is at the UI layer:
+
+- JOURNEY: items form an ordered reading sequence rendered as a *Lesereise*.
+- STORY: items are a set of attached reference documents rendered as a sidebar panel.
+
+Both subtypes share the same capacity cap (100 items), dedup index, position semantics,
+and DEFERRABLE constraint — enforced at the database layer, not re-implemented per subtype.
+
+The `GESCHICHTE_TYPE_MISMATCH` error code was removed end-to-end (backend enum,
+frontend `ErrorCode` type + `getErrorMessage()` case, all three locale files).
+`GESCHICHTE_TYPE_IMMUTABLE` is unrelated and was left intact.
+
+## Naming asymmetry (intentional)
+
+The error codes `JOURNEY_AT_CAPACITY` and `JOURNEY_DOCUMENT_ALREADY_ADDED` carry
+journey-flavored names. Renaming them would ripple through `ErrorCode.java`, `errors.ts`,
+and three locale files for zero behavior change. `StoryDocumentPanel` remaps these two
+codes to story-worded user messages at the presentation layer — the asymmetry is a
+documented decision, not an accident.
+
+## Alternatives rejected
+
+- **Separate `story_documents` join table for STORY** — creates two nearly-identical
+  schemas for the same concept (document attachment with dedup and ordering), doubles the
+  migration surface, and splits the capacity/dedup logic. Rejected as unnecessary
+  duplication.
+- **Allowlist type guard (`if type not in (JOURNEY, STORY)`)** — unreachable dead code
+  under a two-constant enum; fails the JaCoCo branch gate. Rejected.
+- **Per-subtype application validation** — the schema never encoded the restriction; an
+  application-only rule with no schema backing is the weakest kind of invariant and was
+  removed when the product decision reversed it.
+
+## Consequences
+
+- `JourneyItemService.append()` accepts items for any `Geschichte`, regardless of subtype.
+  The 100-item cap and dedup constraint apply to all.
+- GLOSSARY.md and ARCHITECTURE.md updated to reflect that `JourneyItem` is not
+  JOURNEY-specific.
+- The `l3-backend-3g-supporting.puml` C4 diagram updated: type-guard language removed,
+  `geschQuerySvc` rel label reads "Checks Geschichte existence" (not "and type").
+- `StoryDocumentPanel.svelte` is the STORY-side consumer; `JourneyEditor.svelte` is the
+  JOURNEY-side consumer. Neither is aware of the other.
+- Known pre-existing constraint conflict: `ON DELETE SET NULL` on `journey_items.document_id`
+  combined with `chk_journey_item_not_empty` causes a DB-level 500 when a document linked
+  via a note-less item is deleted. Pre-existing; tracked in follow-up issue.

docs/adr/038-domain-event-driven-journey-item-cleanup.md

@@ -0,0 +1,118 @@
+# ADR-038 — Domain event drives note-less journey-item cleanup on document delete
+
+**Status:** Accepted
+**Date:** 2026-06-11
+**Issue:** #805 (P1 — deleting a document linked via a note-less journey_item 500s at DB constraint)
+
+## Context
+
+Two constraints in V72 encode contradictory rules for a journey item that has a
+`document_id` but no `note`:
+
+- **`fk_journey_items_document` → `ON DELETE SET NULL`** — when a document is deleted,
+  Postgres nulls out `document_id`.
+- **`chk_journey_item_not_empty`** — requires at least one of `document_id` or `note`
+  to be non-null.
+
+A note-less item (`document_id` set, `note IS NULL`) satisfies the CHECK while the
+document exists. Deleting the document causes Postgres to attempt `SET NULL`, which
+would leave both columns null — a direct CHECK violation. Postgres aborts the
+transaction with a 500 that bypasses `GlobalExceptionHandler`.
+
+The natural fix — delete note-less items inside `DocumentService.deleteDocument` before
+`deleteById` runs — cannot call `JourneyItemService` directly: `JourneyItemService`
+already injects `DocumentService`, and Spring Framework 7 (used by Spring Boot 4)
+**fully prohibits constructor-injection cycles**. The application will not start if such
+a cycle is introduced.
+
+## Decision
+
+`DocumentService.deleteDocument` publishes a **`DocumentDeletingEvent`** (plain record,
+payload: `documentId` UUID only) via `ApplicationEventPublisher` **before**
+`documentRepository.deleteById`. A dedicated `@Component`
+`JourneyItemDocumentDeleteListener` in the `geschichte.journeyitem` package consumes
+this event and calls `journeyItemRepository.deleteNoteLessByDocumentId(documentId)`
+directly — bypassing `JourneyItemService` to avoid re-introducing the cycle and to
+suppress the per-item `JOURNEY_ITEM_REMOVED` audit emission (see audit decision below).
+
+### Load-bearing listener-phase choice: plain `@EventListener`
+
+The listener is annotated with `@EventListener` (not
+`@TransactionalEventListener(AFTER_COMMIT)`, not `@Async`). **This choice is
+load-bearing:**
+
+- **`AFTER_COMMIT` would break the fix entirely.** `AFTER_COMMIT` fires *after* the
+  surrounding transaction has committed. By that point, `documentRepository.deleteById`
+  has already executed and Postgres has already tried `ON DELETE SET NULL` — the
+  constraint violation fires before the listener ever runs.
+- **`@Async` would break rollback atomicity (AC-5).** An async listener runs on a
+  separate thread in its own transaction. If `deleteDocument` subsequently rolls back
+  (e.g. due to an unrelated failure), the listener's deletes are in a committed async
+  transaction and cannot be undone.
+- **Plain `@EventListener` runs synchronously in the publisher's thread and
+  transaction.** The listener's JPQL delete and the `deleteById` are a single atomic
+  unit: if either fails, both roll back together.
+
+### Repository method
+
+```java
+@Modifying(clearAutomatically = true)
+@Query("DELETE FROM JourneyItem i WHERE i.document.id = :documentId AND (i.note IS NULL OR i.note = '')")
+int deleteNoteLessByDocumentId(@Param("documentId") UUID documentId);
+```
+
+`i.document.id` (the real association path) is used instead of `i.documentId`: the
+transient `getDocumentId()` getter on `JourneyItem` makes Spring Data unable to resolve
+a derived query path (same trap documented at `JourneyItemRepository:33-44`).
+
+`clearAutomatically = true` invalidates the L1 cache so subsequent reads in the same
+session do not return stale entities.
+
+The predicate `(note IS NULL OR note = '')` covers the `note = ''` edge case that the
+service layer can never produce (normalizeNote converts blank strings to null), but that
+may exist via raw SQL inserts or legacy data. Whitespace-only notes (`note = '   '`)
+do not match and are preserved as note-carrying placeholders.
+
+### Audit decision
+
+The listener calls the repository directly rather than routing through
+`JourneyItemService.delete`. This deliberately bypasses the `JOURNEY_ITEM_REMOVED`
+audit emission: a document used in multiple journeys would otherwise produce N audit
+rows for a single user action. The `DOCUMENT_DELETED` entry written by `deleteDocument`
+is the sole audit record for the operation.
+
+### Boundary: documents must not depend on journey
+
+The event direction is `document → journey`, never the reverse. `DocumentService`
+publishes events it knows nothing about the consumers of; `JourneyItemService`'s
+dependency on `DocumentService` is unchanged and remains the only cross-domain
+reference. This direction is the prerequisite for the cycle constraint to hold.
+
+## Alternatives rejected
+
+- **DB trigger on `journey_items`** — trigger logic is opaque to Java developers,
+  invisible to code review, and not covered by the JPA test harness.
+- **RESTRICT instead of SET NULL** — breaks the existing note-carrying placeholder
+  UX: deleting a document with a note-carrying journey item would 409 instead of
+  preserving the item as a placeholder.
+- **Relax `chk_journey_item_not_empty`** — the constraint enforces a real invariant
+  (every item must have at least document or note). Removing it would allow empty rows.
+- **`@Lazy` on the `JourneyItemService → DocumentService` injection** — Spring Boot 4 /
+  Spring Framework 7 prohibits constructor-injection cycles regardless of `@Lazy`.
+- **Make `DocumentService` call `JourneyItemService`** — introduces the prohibited
+  cycle. Rejected at design time.
+
+## Consequences
+
+- **No schema change** — no new Flyway migration, no `db-orm.puml` /
+  `db-relationships.puml` update.
+- This is the **first custom domain event** in the codebase. No prior
+  `ApplicationEventPublisher` usage existed in `main/`. New cross-domain cleanup that
+  cannot use direct service calls should follow this pattern.
+- All tests that delete documents and then assert journey-item state **must route
+  through `DocumentService.deleteDocument`**, not `documentRepository.deleteById`.
+  The existing `JourneyItemIntegrationTest` tests that covered the note-carrying
+  placeholder UX have been updated accordingly.
+- The `DOCUMENT_DELETED` `AuditKind` was added as part of this fix to give AC-7's
+  audit assertion a positive check (absence-only assertions pass vacuously if all
+  auditing regresses).