elton
2353d3725d
Andreas: "lass das chart raus, das ist hive. Aber compose rein. das ist das demo fuer das chart. damit ist auch der schnitt klar: hive hat charts und deren orchestrierung, aber bedient sich fuer allgemeine dienste bei spine statt es selber zu bauen. Selber bauen nur fuer sachen, die nur hive braucht und sonst niemand." chart/ ist raus. Damit aendert sich die Rolle des Compose: Es ist nicht die Uebergangsform bis zum Chart, sondern die lauffaehige Vorfuehrung des Dienstes. Wer ein Chart baut, sieht daran, welche Images, welche Umgebung und welche Volumes noetig sind -- und kann es gegen etwas Laufendes pruefen statt gegen eine Beschreibung. Der Schnitt steht jetzt im README, mit dem Pruefstein: Braucht es ausser hive noch jemand? Dann spine. km ist genau so ein Fall -- er entsteht hier, ausserhalb von hive, weil die 42i ihn braucht, und ist damit erwiesenermassen uebergreifend. Und die Referenz schuldet einem kuenftigen Chart, was das team-Chart uns geschuldet hat: nicht nur DASS eine Einstellung so ist, sondern WARUM. Dessen drei teuer gelernte Punkte liefen beim Nachbau in der 42i ohne eine einzige eigene Entdeckung durch.
4.3 KiB
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.