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.
82 lines
3.9 KiB
Markdown
82 lines
3.9 KiB
Markdown
# 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](https://git.42i.org/spine/core/issues/8), zusammengeführt und
|
|
> fortgeschrieben — siehe [docs/konzept.md](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](https://git.42i.org/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](https://git.42i.org/spine/core/issues/8) und
|
|
[spine/core#1](https://git.42i.org/spine/core/issues/1) steht. Die beiden
|
|
bleiben als Ursprung stehen und verweisen hierher.
|