# 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.