# 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/` | 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](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` 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](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.