spine/km: das Zuhause fuer den Wissensdienst

Andreas: "lass uns ein repo in spine machen, fuer das knowledge
management thema. Darin sollen images gebaut werden und ein compose und
charts, sodass daraus dann km.lan betrieben werden kann. alles zu dem
thema kann dann da rein wandern, als doku und als tickets."

Vier Verzeichnisse: image/ fuer den Dienst, deploy/ fuer den Betrieb
heute (LXC und podman ueber oci), chart/ fuer den Betrieb spaeter (hive
und k8s), docs/ fuer Konzept und Entscheidungen.

Compose und Chart sind ausdruecklich gleichrangig und beschreiben
DENSELBEN Dienst. Beim Teamspace hat genau das getragen: Das hive-Chart
war die Vorlage, und seine drei teuer gelernten Einstellungen liefen in
der 42i ohne eine einzige eigene Entdeckung durch. Driften sie, wird der
Umzug nach k8s ein Neubau statt eines Wechsels.

docs/konzept.md fuehrt spine/core#8 zusammen: Andreas Entwurf woertlich,
dazu die Praezisierungen aus den Kommentaren -- Konzepte als eigene
Kategorie, Projekt als zweite Achse, und dass ein Eintrag ohne
Projekt-Tag der Organisation gehoert statt keinem. Mit den offenen
Punkten, die noch niemand entschieden hat.

Das README benennt zwei Dinge, die man sonst spaeter diskutiert: warum
das Repo von der spine-Konvention abweicht (Image und Chart liegen sonst
zentral -- km ist eigene Entwicklung, kein fertiges Upstream-Produkt),
und dass hive den Dienst verwenden kann, weil er nichts 42i-spezifisches
eingebaut hat.

image/README.md

@@ -0,0 +1,31 @@
+# image — der Dienst selbst
+
+Hier entsteht `git.42i.org/spine/km`: die API, die Ablage, der MCP-Endpunkt und
+die prüfende Schreibfunktion.
+
+**Noch leer.** Was hineingehört, 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.