Fix: Verarbeitung von PROPOSAL_READY bis SUCCESS in einem Lauf; log4j-core im GUI-Test-Classpath

Der Dokument-Processing-Coordinator finalisiert jetzt unmittelbar nach dem
Persistieren des PROPOSAL_READY-Versuchs im selben Lauf zur Zielkopie und zu
SUCCESS. Die Invariante "neuester PROPOSAL_READY-Versuch ist die fuehrende
Quelle" bleibt gewahrt: Pro Lauf entstehen zwei Historieneintraege
(PROPOSAL_READY, dann SUCCESS). Bootstrap-E2E-Tests auf Single-Run-Semantik
angepasst; die "kein neuer KI-Aufruf bei vorhandenem PROPOSAL_READY"-Invariante
ist weiterhin im Application-Unit-Test abgedeckt.

Zusaetzlich log4j-core als Test-Scope-Abhaengigkeit im GUI-Modul ergaenzt,
damit die "Log4j2 could not find a logging implementation"-Warnung im
Testlauf nicht mehr erscheint.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-04-21 17:26:21 +02:00
parent aaedc2d713
commit 8be1848ba9
11 changed files with 317 additions and 251 deletions
+11
View File
@@ -20,3 +20,14 @@ Titelregeln:
- Eindeutig und verständlich, nicht generisch
Wenn das Dokument nicht eindeutig interpretierbar ist, beschreibe dies im Reasoning.
**Ausgabeformat: Ausschließlich reines JSON-Objekt**
Antworte nur mit einem JSON-Objekt nach folgendem Schema:
- Keine Präambel, keine Erklärungen, keine Markdown-Codeblöcke
- `title` (erforderlich): Der ermittelte deutsche Titel
- `reasoning` (erforderlich): Begründung der Entscheidung
- `date` (optional): Das ermittelte Datum im Format YYYY-MM-DD; auslassen, falls kein belastbares Datum ableitbar ist
Beispiel:
{"title":"Stromabrechnung","reasoning":"Das Rechnungsdatum 2026-02-11 ist eindeutig erkennbar.","date":"2026-02-11"}