km — Knowledge Management

Der gemeinsame Wissensdienst: eine Ablage für das, was Agenten und Menschen über die 42i wissen — statt je Werkzeug eine eigene, die niemand sonst sieht.

Betrieben wird er als km.lan. Dieses Repo trägt alles dazu: das Image, die Betriebsform für heute (compose), die für später (Chart), die Konzepte und die Tickets.

Stand: Entwurf. Es läuft noch nichts. Was hier steht, ist der Bauplan aus spine/core#8, zusammengeführt und fortgeschrieben — siehe docs/konzept.md.

Warum das gebraucht wird

Nicht vermutet, sondern gemessen. Am 2026-09-01 suchte der XO-Gesprächsfaden nach fehlenden Übersetzungsschlüsseln, während die Messung dazu seit Stunden vorlag — dieselbe Persona, zwei Körper, kein gemeinsames Gedächtnis. Am selben Abend kamen drei weitere Fälle dazu, alle bei einem Agenten, der die Regel „erst suchen, dann bauen" selbst geschrieben hatte:

Fall	Was gefehlt hat
Eine Vorgabe (oci) übersehen, obwohl die Seite offen war	„Für diese Art Aufgabe gibt es hier eine Vorgabe" — vor dem Bauen
Im falschen Verzeichnis gebaut, das richtig aussah	„Diese Datei ist nicht die Quelle" — beim Anfassen
Dasselbe Problem zweimal gelöst, zwei Tickets dafür	„Daran arbeitet gerade jemand" — beim Anlegen

Alle drei sind nicht durch bessere Dokumentation lösbar: Die Information existierte jedes Mal, korrekt und auffindbar. Was fehlte, war die Zustellung im richtigen Moment. Das ist der Unterschied zwischen einem Index und einem Bibliothekar — der Index beantwortet Fragen, der Bibliothekar sagt, welche Frage man hätte stellen sollen.

Was wohin gehört

Verzeichnis	Inhalt
image/	Das Container-Image: API, Ablage, MCP-Endpunkt, prüfende Schreibfunktion
deploy/	Die lauffähige Referenz: LXC mit podman-compose über oci
docs/	Konzept, Entscheidungen, Betriebswissen

Ein Chart liegt hier nicht. Charts und ihre Orchestrierung sind hive — siehe den Schnitt unten. Das Compose ist deshalb kein Notbehelf für die Zeit bis dahin, sondern die Vorführung des Dienstes: Wer ein Chart dafür baut, sieht hier, welche Images, welche Umgebung und welche Volumes er braucht, und kann es gegen etwas Laufendes prüfen statt gegen eine Beschreibung.

Der Schnitt zwischen spine und hive

Festgelegt von Andreas am 2026-09-02:

„hive hat charts und deren orchestrierung, aber bedient sich für allgemeine dienste bei spine statt es selber zu bauen. Selber bauen nur für sachen, die nur hive braucht und sonst niemand. die gehören dann in die hive orga in gitea."

	spine	hive
baut	den Dienst: Image, Ablage, API	das Chart und die Orchestrierung
liefert	eine lauffähige Referenz (deploy/)	den Betrieb auf k8s
eigenes	allgemeine Dienste, die mehrere brauchen	nur, was ausschließlich hive braucht

Der Prüfstein ist einfach: Braucht es außer hive noch jemand? Dann gehört es nach spine. km ist genau so ein Fall — er entsteht hier, außerhalb von hive, weil die 42i ihn braucht, und ist damit erwiesenermaßen übergreifend.

Was ihn kennt, sind Namespaces (42i, familie, …) und Projekt-Tags — beides Konfiguration, keine eingebaute Annahme. Es steckt nichts 42i-spezifisches darin.

Anschluss auf hive-Seite: hive/core — insbesondere die Bibliothekars-Rolle (dort Bob), aus der dieser Dienst hervorgegangen ist.

Verhältnis zur spine-Konvention

In spine liegen Images sonst zentral in spine/images und Charts in spine/charts, benannt nach der Fähigkeit. Hier liegt beides beisammen, weil km kein fertiges Upstream-Produkt ist, sondern eigene Entwicklung — API, Ablageform und die prüfende Schreibfunktion entstehen hier, und sie gehören zu den Konzepten und Tickets, die sie begründen.

Ist der Dienst reif und stabil, kann das Image nach spine/images wandern; dieses Repo behielte Konzepte, Betrieb und Vorgänge. Das ist eine Entscheidung für später, keine Vorfestlegung.

Tickets

Alles zum Thema gehört hierher — auch das, was heute noch in spine/core#8 und spine/core#1 steht. Die beiden bleiben als Ursprung stehen und verweisen hierher.