elton
96ba3fdcb4
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.
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/ |
Heute: LXC mit podman-compose, wie jeder andere Dienst im Haus (oci) |
chart/ |
Später: Helm-Chart, damit hive denselben Dienst fahren kann |
docs/ |
Konzept, Entscheidungen, Betriebswissen |
Die Aufteilung ist Absicht und folgt dem, was beim Teamspace funktioniert hat: Compose und Chart beschreiben denselben Dienst mit denselben Bildern und Einstellungen. Wer eines ändert, ändert das andere mit — sonst driften sie, und der Umzug nach k8s wird ein Neubau statt eines Wechsels.
Verhältnis zu hive
hive kann diesen Dienst verwenden. Er ist bewusst nicht 42i-spezifisch: Was
ihn kennt, sind Namespaces (42i, familie, …) und Projekt-Tags — beides
Konfiguration, keine eingebaute Annahme.
Für hive ist chart/ der Einstieg; deploy/ ist die Übergangsform der 42i,
solange dort kein k8s produktiv läuft. Die Rollen sind dieselben wie beim
Teamspace: hive baut Charts und k8s, die 42i fährt bis dahin LXC und podman —
mit demselben Image und demselben Bootstrapping, damit die Erfahrung
übertragbar bleibt.
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 und das Chart
nach spine/charts wandern; dieses Repo behielte Konzepte 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.