PGNs, Plattformpartien, Spielerprofile und Ratings sammeln.
Systemkarte
Klare Grenzen, klare Fluesse.
CaiLama bleibt Produktkern. Router und Search bleiben getrennte Dienste. Der Master dokumentiert und prueft, koppelt aber keine Runtime-Komponenten.
Hauptfluss.
Die Richtung ist bewusst einfach: CaiLama konsumiert Router und Search. Beide Dienste bleiben eigenstaendig deploybar.
CaiLama
CLI, Agent, Profile, Training, PGN, Stockfish, DGT-nahe Workflows.
→
LLM-Router
OpenAI-kompatible API, Modell-Aliase, Backends, Fallbacks.
↘
Search
Suche, Kontext, DWZ, Quellen, Meilisearch-Indizes.
Vertraege.
Die wichtigsten Schnittstellen sind stabil genug, um die naechsten Integrationen zu planen.
| Richtung | Vertrag | Wichtige Regeln |
|---|---|---|
| CaiLama → LLM-Router | /v1/chat/completions, /v1/models, /health |
Rollen-Aliase, keine Provider-Secrets im Master, Router ohne Schachproduktlogik. |
| CaiLama → Search | /v1/search, /v1/context, /v1/dwz/search, /v1/dwz/player/{pkz} |
Interner SearchAdapter zuerst, Browser-Websuche nur als expliziter Fallback. |
| Master → alle | Dokumentation, Roadmap, Checkskripte | Keine Runtime-Kopplung, keine Submodules, keine Unter-Repo-Dateien im Master. |
Analyse- und Trainingskette.
Der aktuelle Zielpfad baut auf vorhandenen CaiLama-Modulen auf und laesst Router/Search anreichern statt dominieren.
Stockfish, Heuristiksignale, Fehlerklassen und Schwaechenprofil.
Karten, Queue, Review und DGT-nahe Einheiten erzeugen.
Review-Resultate in Prioritaet, Schwierigkeit und Wiederholung zurueckfuehren.
Architekturprinzipien.
Keine Parallelstrukturen
Vorhandene Module werden wiederverwendet; neue Fachlogik entsteht zuerst importierbar und testbar.
HTTP/API-Kopplung
Dienste werden ueber klare Endpunkte verbunden, nicht hart ineinander verwoben.
Konfiguration getrennt
Code, Doku und Beispiele enthalten keine lokalen Credentials oder produktiven Secrets.