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.
5.3 KiB
Konzept
Zusammengeführt aus spine/core#8 (Entwurf und vier Kommentare, 2026-09-01). Der Entwurf steht wörtlich, die Präzisierungen darunter.
Der Entwurf im Original
nehmen wir https://km.lan.
https://km.lan/api/v1/bekommt ein paar endpunkte: write, read, search, summarydas alles in namespaces („42i", „familie", …). Zugriff per RBAC,
namespace:verb, mit Token → role → grantes wird alles als md auf platte gespeichert, in den kategorien mission, knowledge, status. In den passenden verzeichnissen. in jedem verzeichnis gibt es eine
index.mdmit dem verzeichnis. Jedes write schreibt die index.md um. Sortiert ist die index.md nach datum. Neuste Änderungen oben. Bei History basierten Sachen ist der jeweils gültige Kurs und Status oben zusammengefasst und veraltete einträge sind als depricated markiert.Die summary funktion gibt ein md mit einem Kapitel pro Kategorie und fasst die Inhalte aus den index.md zusammen. jeder eintrag hat einen autor und ein datum.
km.lan selber ist ein image. Das wird in spine/images angelegt und wird ein übergreifender service. die ablage ist ein volume. Gehosted in einem lxc, darin ein podman service in /srv wie aktuell alle anderen auch. Hive macht daraus dann irgendwann ein K8s Chart Ding, aber das ist dann hive. Hier machen wir erstmal den fachlichen prototyp und schauen ob das geht.
Dann noch einen mcp endpoint. Den hängen wir in den aggregator rein, oder noch prominenter. Das muss zwingend proprietäre memory funktionen von claude oder opencode ersetzen. also müssen wir die eingebauten tools abschalten.
die write funktion muss dann ein llm aufrufen (url wird in der compose.yml definiert, key aus openbao). der aufruf hat einen minimalen prompt, der kategorisiert und gegen den aktuellen stand prüft, konflikte findet und meldet. Bei Konflikten wird abgewiesen. Dann kann der Einreicher aber bewusst übersteuern und force mitgeben. Dann wird diese Info als neuer gesicherter Stand übernommen und ersetzt den alten stand (also update der doku oder kurskorrektur). Neuer Status (Fortschrittsmeldung) fürs log geht auch ohne force.
Präzisierungen
Konzepte sind eine eigene Kategorie
Genannt waren mission, knowledge, status. Konzepte gehören dazu und
sind nicht dasselbe wie Wissen:
| Knowledge | Konzept | |
|---|---|---|
| Was | wie etwas ist | wie etwas gedacht ist |
| Beispiel | „:low ist ein Pool aus drei Quellen" |
„Aufträge haben zwei Bestätigungsachsen" |
| Widerspruch dazu | ein Irrtum, wird korrigiert | eine Abweichung, wird gemeldet |
Der Unterschied trägt eine ganze Rolle: Ein Navigator prüft Umsetzung gegen Konzept. Läge das Konzept unter „Wissen", wäre jede Abweichung nur ein widersprüchlicher Fakt statt eines Befunds.
Projekt als zweite Achse — und was ohne sie gilt
Namespaces trennen Mandanten (42i, familie). Innerhalb eines Namespace
braucht es eine zweite Achse: live, hive, spine, inka, infra. Ein
Eintrag gehört zu einem Projekt, aber ein Projekt hat Einträge in allen
Kategorien. Das ist die Trennung aus 42i/intern#860: Owner-Pfad (genau einer,
hart) gegen Tags (viele, weich).
Ein Eintrag ohne Projekt-Tag gehört der Organisation — nicht keinem (Andreas, 2026-09-01):
„sonst könnte ja die 42i keine Einträge bekommen und dann sind wir wieder bei Krücken wie in gitea, wo man orga tickets nicht an die orga hängen kann sondern ein repo braucht. Und dann bauen wir core oder intern. Beides Krücken."
Die Ebenen sind also 42i/ (Sache der Organisation, gültig) und 42i/live/
(Sache des Projekts). Praktisch:
| Aufruf | liefert |
|---|---|
summary(ns="42i") |
alles |
summary(ns="42i", projekt="live") |
nur live |
summary(ns="42i", projekt=None) |
nur die Orga-Ebene — Kurs, Mission, was über allen Projekten steht |
Der dritte Fall ist der wichtige: Genau danach fragt ein Agent, der wissen will, was hier überhaupt gilt, bevor er in ein Projekt einsteigt.
Status braucht laufende Vorgänge, nicht nur Fakten
Der dritte Beleg aus dem Ticket — zwei Agenten lösen dasselbe Problem und legen
zwei Tickets an — ist mit Fakten allein nicht zu verhindern. Er verlangt, dass
summary auch offene Arbeit kennt, nicht nur abgeschlossene. Ohne das
beantwortet der Dienst „was gilt", aber nicht „woran arbeitet gerade jemand".
Offene Punkte
- Volltext oder Vektor? Andreas: „auf dem Volume muss das checkout liegen
… außerdem wäre eine volltext db (oder vektor db) gut." Der vorhandene
Wissens-MCP nutzt Qdrant mit
bge-m3über den LLM-Knoten — Erfahrung und Kosten sind dort dokumentiert (info/docs/lan/infra/wissens-mcp.md). - Verhältnis zum bestehenden
wissens_learn. Der legt Drafts in die info-Basis, die ein Mensch promoten müsste — was niemand tut. Andreas: „das macht heute niemand. Ich wüsste nicht einmal, wo das liegt." - Welches LLM prüft die Schreibfunktion, und was passiert bei Ausfall: abweisen oder durchlassen? Ein Dienst, der ohne Modell nichts annimmt, ist bei jedem Gateway-Ausfall stumm.
- Ablösung der eingebauten Memory-Funktionen von Claude und opencode. Ohne das bleibt die proprietäre Ablage der bequemere Weg.