Tesserae v0.28.3 — das Ein-Zug-Limit des Extraktors und was es still gekostet hat

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Español · Français

<!-- translations:end -->

Released 2026-07-31 · PyPI · GitHub release · pip install --upgrade tesserae==0.28.3

Ein einziges Flag. Es steckte seit dem allerersten Pipeline-Commit im Claude-Extraktor und verhinderte auf einer Maschine mit konfigurierten MCP-Servern, dass die LLM-Extraktion überhaupt funktionierte — ohne die Kompilierung scheitern zu lassen.

--max-turns 1 war nie eine Entscheidung

Beide Claude-CLI-Aufrufstellen starteten:

claude -p --output-format text --max-turns 1

--max-turns zählt Tool-Aufrufe, nicht Antworten. Enthält das Konfigurationsverzeichnis der CLI MCP-Server oder Hooks, kann der erste Zug des Modells ein Tool-Aufruf sein — und damit ist der einzige Zug verbraucht. Die CLI beendet sich mit Code 1 und Reached max turns (1), ohne ein einziges Byte JSON auszugeben.

Tesserae fängt das ab und fällt auf die deterministische Extraktion zurück, denn ein Provider-Ausfall darf eine Kompilierung nie abbrechen. Also war die Kompilierung erfolgreich, der Graph sah plausibel aus — und das LLM hatte nichts beigetragen.

Das Flag wurde nie gewählt. Es kam mit dem ursprünglichen Pipeline-Commit, und ClaudeCLIJsonClient kopierte es drei Monate später wörtlich, weil sein Docstring sagt, er „folge dem Muster von run_claude_cli". Keine Commit-Nachricht erwähnt es.

--strict-mcp-config ist, was „ein Schuss" tatsächlich bedeutet

Die Absicht hinter dem Limit war: „antworte einmal, dreh keine Agentenschleife". Der korrekte Ausdruck dafür ist, gar keine MCP-Server zu laden — dann gibt es kein Tool, für das ein Zug draufgehen kann:

claude -p --output-format text --strict-mcp-config

Die erste Antwort des Modells ist die Antwort, und ein konfigurierter MCP-Server kann den Aufruf nicht mehr aushungern. Beide Aufrufstellen sind korrigiert, und ein Regressionstest stellt sicher, dass das Zug-Limit an keiner von beiden zurückkehrt.

Prüfen, ob es Sie einen Graphen gekostet hat

Der Fehler ist in der Kompilierungs-Zusammenfassung unsichtbar — er lebt nur im Log:

grep -c 'Reached max turns' <Ihr Kompilierungs-Log>

Jeder Wert über null bedeutet, dass diese Dateien deterministisch extrahiert wurden; ein erneutes Kompilieren mit dieser Version holt sie zurück. Im Graphen dieses Projekts selbst stieg die Knotenzahl nach Wiederherstellung echter LLM-Extraktion von 5.155 auf 13.182 — der deterministische Rückfall kostete rund 60 % des Graphen.

Dass eine Kompilierung Erfolg meldet, während sie bei den meisten Dateien die LLM-Extraktion verliert, ist ein eigener Defekt: verfolgt in #92 und hier nicht behoben. Dieses Release entfernt eine Ursache des stillen Rückfalls, nicht die Stille selbst.

Upgrade von v0.28.2

Direkter Austausch. Keine API-, Schema- oder Konfigurationsänderung. Waren Ihre früheren Kompilierungen betroffen, kompilieren Sie neu und holen Sie die fehlende Extraktion nach — zwischengespeicherte LLM-Antworten in ~/.tesserae/llm_cache werden wiederverwendet, es kosten also nur die Dateien, die damals zurückgefallen sind.