# image — der Dienst selbst

Hier entsteht `git.42i.org/spine/km`: die API, die Ablage, der MCP-Endpunkt und
die prüfende Schreibfunktion.

**Erster Baustein vorhanden:** `km/ingest_gitea.py` holt Tickets und Kommentare
aus Gitea in die Ablage (spine/core#13, Doku in
[../docs/ingest-gitea.md](../docs/ingest-gitea.md)). Der Rest steht in
[../docs/konzept.md](../docs/konzept.md).
Die Reihenfolge, in der es sinnvoll wächst:

1. `read` und `search` über eine Ablage aus Markdown-Dateien — ohne die beiden
   ist nichts nachprüfbar.
2. `write` **ohne** LLM-Prüfung, aber mit Kategorie und Namespace. Ab hier ist
   der Dienst benutzbar und kann die ersten Einträge aufnehmen.
3. Die `index.md` je Verzeichnis, die jedes `write` fortschreibt.
4. `summary` über die `index.md`.
5. Die prüfende Schreibfunktion (LLM, Konflikte, `force`).
6. Der MCP-Endpunkt.

Die Reihenfolge ist nicht beliebig: Schritt 5 ist der einzige, der ein Modell
braucht und ausfallen kann. Er kommt zuletzt, damit der Dienst vorher schon
trägt — und damit man beim Abschalten der Prüfung sieht, was sie eigentlich
verhindert hat.

## Zwei Dinge, die beim Bauen schon feststehen

**Benannt nach der Fähigkeit, nicht nach dem Produkt** — die Regel aus
`spine/images`. `km` ist ein Versprechen auf Wissensverwaltung, keine Wette auf
eine bestimmte Ablage oder Suchmaschine.

**Die Ablage ist ein Volume, kein Datenbankgeheimnis.** Markdown auf Platte,
lesbar ohne den Dienst. Wer nur nachsehen will, was gespeichert ist, soll dafür
kein laufendes System brauchen.