v0.6.1.de.md
docs/i18n/release-notes/v0.6.1.de.md
Tesserae v0.6.1 — Komfortverbesserungen der CLI und ein Fix für den codex-Provider
<!-- translations:start -->
English · 한국어 · 中文 · 日本語 · Русский · Español · Français
<!-- translations:end -->
Veröffentlichungsdatum 2026-06-08 · PyPI · GitHub release · pip install --upgrade tesserae==0.6.1
Ein kleiner Nachzügler zur CLI-Neugestaltung in v0.6.0: zwei Komfortverbesserungen für die neue CLI mit flachen Verben und ein echter Fehlerbehebung für codex-Nutzer mit mehreren Konten.
1. tesserae compile zeigt jetzt den Fortschritt live an
Eine lange Kompilierung blieb früher stumm. Sie rendert nun auf einem interaktiven Terminal eine mehrphasige Fortschrittsanzeige im Stil von codegraph index:
◆ Scanning sources — 2036 found
Extracting ████████████████░░░░░░░░ 64% 1302/2036 0:12
◆ Extracted 2036 files
⠙ Finalizing — community summaries, vault, site…
◆ Compiled · 220243 nodes · 679073 edges · 41s
Sie wird von rich (bereits eine Abhängigkeit) angetrieben und rendert nur auf einem TTY — Ausführungen über Pipes, in CI, auf dem MCP-Server und als Daemon bleiben Byte für Byte identisch (die schlichte Zusammenfassungszeile Compiled project wiki: … bleibt erhalten), sodass sich für Skripte nichts ändert.
2. tesserae projects register initialisiert automatisch
Das Registrieren eines Verzeichnisses, das noch kein Tesserae-Projekt war, schlug mit No .tesserae/graph.json found fehl. Wenn der Pfad nun ein vorhandenes Verzeichnis ohne .tesserae/-Arbeitsbereich ist, erstellt register zuerst einen leeren (und gibt anschließend einen Hinweis aus, tesserae compile auszuführen). Ein fehlender oder falsch eingegebener Pfad ist weiterhin ein Fehler — er wird niemals automatisch erstellt — und ein bereits initialisiertes Projekt bleibt unangetastet.
3. Fix: llm_provider: codex wird jetzt von jedem LLM-Durchlauf berücksichtigt
Wenn du codex ausgewählt hattest (über tesserae config llm --llm-provider codex oder die config.json des Projekts), nutzten mehrere LLM-Durchläufe zur Kompilierzeit trotzdem die Claude-CLI — und erzeugten ClaudeCLIJsonClient … You've hit your Sonnet limit, obwohl du codex gewählt hattest. Die Ursache: Der Durchlauf für Community-Zusammenfassungen, die Speicher-Durchläufe von Phase 5 sowie die Befehle lab schema-drift / lab evolve / query --llm bauten ihren LLM-Client auf, ohne die Provider-Einstellung zu berücksichtigen, und griffen daher stets standardmäßig auf Claude zurück. Sie alle bestimmen das Backend nun auf dieselbe Weise wie der Rest der Engine — Umgebungsvariable > config.json des Projekts > globale ~/.tesserae/config.json > Standardwert — sodass llm_provider: codex überall berücksichtigt wird.
Upgrade von v0.6.0
Es gibt nichts zu ändern — alle drei sind direkt einsetzbar. Falls du zuvor llm_provider: codex gesetzt hattest und während der Kompilierung trotzdem Claude aufgerufen wurde, behebt dieses Release das; führe einfach erneut tesserae compile aus.