@@ -1203,7 +1203,7 @@ Repos plus eins. Geprüfte Klassen ohne Fund stehen in [`BUGHUNT-CHECKED.md`](BU
 - **Nachtrag (Branch-Review 2026-10-20):** Die beiden Tests oben prüften nur, dass nichts wirft, und die fertige Anfrage; welche Fragmente als `PartialToolCall` gemeldet werden und mit welcher Id, war ungeprüft (Fund J14-2). `#toolCallDeltaWithoutArguments_doesNotFailTheStream` pinnt jetzt genau ein gemeldetes Teilstück (Index 0, Id `call_1`, Name `get_weather`, Argumente `{}`), einen `CompleteToolCall` und langchain4js Vertrag über den neuen Helfer `assertPartialsMakeUpTheCompleteCall` (die Argumentstücke ergeben aneinandergehängt die Argumente des fertigen Aufrufs, jedes trägt dessen Id und Namen). `#toolCallDeltaBeforeItsName_doesNotFailTheStream` prüft nur, dass mindestens ein Teilstück gemeldet wird (`is(not(empty()))`, damit die Schleife nicht leer durchläuft; bei der Prüfung ergänzt, rot gegen eine Mutante, die nach einem zurückgehaltenen Fragment nichts mehr meldet: `Expected: is not an empty collection`) und dass jedes gemeldete Teilstück die endgültige Id und den Namen trägt: der Vertrag ist dort heute rot (`Expected: is "{\"city\":1}" but: was "ty\":1}"`, das Präfix vor dem Namen wird nie gemeldet, Fund J14-1) und kommt mit dessen Fix; das heutige einzelne Teilstück wird bewusst nicht festgeschrieben. Gegenprobe rot: die Id aus dem aktuellen Fragment statt aus dem gesammelten Aufruf (`Expected: is "call_1" but: was ""`), das Kopf-Fragment mit einem Platzhalter-Argument `" "` gemeldet (`Expected: is <1> but: was <2>`); unverändert 12/12 grün.
 - **Status:** gefixt
 - **Commit:** java-llama.cpp `f7f3f0f`
-- **Nachtrag (Branch-Review 2026-10-20, Fund J14-4):** Die Klassen-Javadoc von `StreamingChunkAssembler` sagte noch, jedes `tool_calls`-Fragment gehe als `onPartialToolCall` hinaus, und dass id und Name am ersten Fragment kämen. Seit dem Fix (`4d599fa`) wird ein Fragment nur weitergereicht, wenn es Argumenttext trägt und sein Aufruf schon einen Namen hat; andere (ein Kopf nur mit id/Name, Argumente vor dem Namen) speisen nur den zusammengesetzten Aufruf. Javadoc und der Satz im `llama-langchain4j/README.md` sagen das jetzt, „id und Name“ kommen „usually“ am ersten Fragment. Nur Doku.
+- **Nachtrag (Branch-Review 2026-10-20, Fund J14-4):** Die Klassen-Javadoc von `StreamingChunkAssembler` sagte noch, jedes `tool_calls`-Fragment gehe als `onPartialToolCall` hinaus, und dass id und Name am ersten Fragment kämen. Seit dem Fix (`f7f3f0f`) wird ein Fragment nur weitergereicht, wenn es Argumenttext trägt und sein Aufruf schon einen Namen hat; andere (ein Kopf nur mit id/Name, Argumente vor dem Namen) speisen nur den zusammengesetzten Aufruf. Javadoc und der Satz im `llama-langchain4j/README.md` sagen das jetzt, „id und Name“ kommen „usually“ am ersten Fragment. Nur Doku.
 
 <a id="f133"></a>
 ### F133 – java-llama.cpp: `setPoolingType(UNSPECIFIED)` lässt ein vorher gesetztes `--pooling` stehen
@@ -1465,14 +1465,14 @@ Repos plus eins. Geprüfte Klassen ohne Fund stehen in [`BUGHUNT-CHECKED.md`](BU
 - **Datei:** `llama/src/main/cpp/jni_utf8.hpp` (neu), `jllama.cpp` (`throw_api_status`, Modell-Laden), `jni_helpers.hpp` (`report_cxx_exception_impl`), `native_server.cpp`, `rpc_bridge.cpp`, `train_engine.cpp`
 - **Schwere:** niedrig bis mittel (still verfälschte Meldung auf HotSpot, Prozessabbruch unter Android-CheckJNI)
 - **Historie:** Offener Verdacht vom 2026-10-18 (Musterdurchsicht nach F71, TODO (6)). Gemessen auf HotSpot 21 mit einer eigenen JNI-Sonde: `GetStringUTFChars` liefert für U+1F600 `ED A0 BD ED B8 80` (CESU-8), `NewStringUTF` macht aus `F0 9F 98 80` ein falsches Zeichen und verschluckt Folgebytes.
-- **Beschreibung:** `ThrowNew` und `NewStringUTF` lesen Modified UTF-8. Die Meldungen aus llama.cpp zitieren Pfade und Anfragetext in Standard-UTF-8. Die Trainer-Meldung für `missing-😀.gguf` kam als `missing-`, U+00F0 U+009F U+0098 U+0080 und `.g` an (der Rest des Pfads fehlte). Die Eingabeseite des Trainers (`GetStringUTFChars`) ist dagegen nicht erreichbar: `TrainingParameters.escapeNonAscii` (`ca6ccdf`) schreibt jedes Nicht-ASCII-Zeichen als `\u`-Escape (Jacksons `ESCAPE_NON_ASCII` ist standardmäßig aus), die Konfiguration ist also dort ASCII, wo sich die Kodierungen unterscheiden (gemessen: `"Hallo \\ud83d\\ude00 Welt"`). Die Fehlermeldungen von Anfragen an das Modell zitieren in den gemessenen Fällen keinen Anfragetext (Probe mit einem Zufallsmodell).
+- **Beschreibung:** `ThrowNew` und `NewStringUTF` lesen Modified UTF-8. Die Meldungen aus llama.cpp zitieren Pfade und Anfragetext in Standard-UTF-8. Die Trainer-Meldung für `missing-😀.gguf` kam als `missing-`, U+00F0 U+009F U+0098 U+0080 und `.g` an (der Rest des Pfads fehlte). Die Eingabeseite des Trainers (`GetStringUTFChars`) ist dagegen nicht erreichbar: `TrainingParameters.escapeNonAscii` (`4867189`) schreibt jedes Nicht-ASCII-Zeichen als `\u`-Escape (Jacksons `ESCAPE_NON_ASCII` ist standardmäßig aus), die Konfiguration ist also dort ASCII, wo sich die Kodierungen unterscheiden (gemessen: `"Hallo \\ud83d\\ude00 Welt"`). Die Fehlermeldungen von Anfragen an das Modell zitieren in den gemessenen Fällen keinen Anfragetext (Probe mit einem Zufallsmodell).
 - **Fix:** Neuer Header `jni_utf8.hpp` (nur `jni.h`, keine gecachten IDs, deshalb auch in `train_engine.cpp` nutzbar): `throw_utf8_impl` und `new_string_utf8_impl`. ASCII bleibt bei `ThrowNew`/`NewStringUTF`, alles andere geht als Bytes durch `String(byte[], "UTF-8")`, und Javas Dekoder ersetzt ungültige Folgen durch U+FFFD. Umgestellt sind alle Stellen mit fremdem Text: `throw_api_status`, das Modell-Laden, `report_cxx_exception_impl` (die JNI-Ausnahmegrenze), `NativeServer`, `RpcServer` und der Rückgabetext von `LlamaTrainer`. Stellen mit literalem ASCII-Text bleiben, wie sie sind. Die Eingabeseite des Trainers bekommt einen Kommentar, warum sie sicher ist.
 - **Tests:** C++ `JniUtf8.*` (6 in `test_jni_helpers.cpp`: ASCII bleibt bei `ThrowNew`, 4-Byte-Zeichen und ungültiges Byte erreichen den Konstruktor als Originalbytes, dasselbe für `new_string_utf8_impl` und für `jni_guard_impl`); Java `LlamaTrainerTest#aFourByteCharacterInAPathComesBackIntactInTheErrorMessage` (modellfrei, braucht nur `libjllama`; überspringt, wo die Dateinamen-Kodierung den Pfad nicht darstellen kann) und `#aFourByteCharacterInTheTrainingTextReachesTheTrainer` (hält die Maskierung durch `escapeNonAscii` fest, von der die Eingabeseite abhängt).
 - **Rot-Grün-Nachweis:** C++: mit durchreichenden Platzhaltern 4 von 6 rot, mit dem Fix 6 von 6 grün, die ganze Suite 640/640. Java gegen die alte Bibliothek rot (`but: was "…/missing-ð.g"`), gegen die neu gebaute grün; `LlamaLoggerTest`, `NativeLibraryLoadSmokeTest`, `RpcServerTest` grün.
 - **Nachtrag (Branch-Review 2026-10-20):** Der Satz „Die Fehlermeldungen von Anfragen an das Modell zitieren in den gemessenen Fällen keinen Anfragetext“ gilt für b11639 nicht: upstream zitiert ihn z. B. in `server-common.cpp` (`response_format type must be one of … but got: <type>`), `common/chat.cpp` (`Missing 'role' in message: <message>`) und im Schema-Konverter (`cannot resolve $ref <ref>`), alle drei über `throw_api_status`. Diesen Weg hatte kein Java-Test; ein Rückbau auf `ThrowNew` blieb grün (Fund J11-1). Neu, modellfrei: `NativeLibraryLoadSmokeTest#anErrorMessageKeepsAFourByteCharacterOfTheRequest` (`LlamaModel.jsonSchemaToGrammar("{\"$ref\":\"#/$defs/😀\"}")`, die `LlamaException` muss `#/$defs/😀` enthalten). Gegenprobe mit `env->ThrowNew` in `throw_api_status`: rot (`got: JSON schema conversion failed: JSON schema error at #: cannot resolve $ref #/$defs/ð\x9f\x98\x80, $defs not fo`, der Rest der Meldung fehlt); mit `throw_utf8_impl` 7/7 in der Klasse grün.
 - **Status:** gefixt
 - **Commit:** java-llama.cpp `50b45f8`
-- **Nachtrag (Branch-Review 2026-10-20, Funde J9-5/J11-2):** Beschreibung und Tests schrieben die Maskierung der Eingabeseite Jackson zu; sie kommt von `TrainingParameters.escapeNonAscii` (`ca6ccdf`), die gemessene Ausgabe mit kleingeschriebenem Hex (`\ud83d`) ist deren `%04x`. Jackson maskiert nur U+0000 (als Steuerzeichen) selbst. Beide Zeilen oben sind korrigiert, ebenso der Kommentar in `train_engine.cpp` und die Javadoc von `LlamaTrainerTest#aFourByteCharacterInTheTrainingTextReachesTheTrainer`, die jetzt `TrainingParametersTest#nonAsciiTextIsEscapedSoTheJsonCrossesJniIntact` als Unit-Wächter nennt. Nur Doku/Kommentar.
+- **Nachtrag (Branch-Review 2026-10-20, Funde J9-5/J11-2):** Beschreibung und Tests schrieben die Maskierung der Eingabeseite Jackson zu; sie kommt von `TrainingParameters.escapeNonAscii` (`4867189`), die gemessene Ausgabe mit kleingeschriebenem Hex (`\ud83d`) ist deren `%04x`. Jackson maskiert nur U+0000 (als Steuerzeichen) selbst. Beide Zeilen oben sind korrigiert, ebenso der Kommentar in `train_engine.cpp` und die Javadoc von `LlamaTrainerTest#aFourByteCharacterInTheTrainingTextReachesTheTrainer`, die jetzt `TrainingParametersTest#nonAsciiTextIsEscapedSoTheJsonCrossesJniIntact` als Unit-Wächter nennt. Nur Doku/Kommentar.
 
 <a id="f182"></a>
 ### F182 – java-llama.cpp: Gestreamte Anfragen antworten mit 200, bevor das Backend läuft