Andreas 04.09.: "nimm den info-checkout aus silverbullet raus". Die
Quellen liegen jetzt unter <data>/quellen/<name> neben der Ablage — die
Oberfläche sieht sie nicht mehr. Der Index führt sie unter dem
virtuellen Pfad <ns>/doku/<name>/…, read löst ihn auf die Datei im
Checkout auf (mit Wurzelprüfung). Kein Zurückschreiben mehr: geändert
wird im Quell-Repo, gelesen über die gebaute MkDocs-Seite.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Andreas 04.09.: SilverBullet ist für die Doku nicht das Richtige — die
Doku soll aussehen wie sie soll, lesen statt editieren, und ohne
Auto-Commit-Problem. km baut deshalb je Quelle mit mkdocs.yml nach jedem
Pull mit Änderung eine statische Seite nach <data>/site/<name>; Caddy
liefert sie unter /doku/<name>/ aus. Ein Baufehler lässt die alte Seite
stehen und wird im Lauf gemeldet. Image bekommt mkdocs-material.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
TreeView-Plug für SilverBullet, konfiguriert in CONFIG; ohne die
committete Plug-Datei fehlt nach einem frischen Checkout die Navigation.
Doku im deploy-README.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
KM_SOURCES=name=url@branch legt je Quelle einen Checkout unter
<ns>/doku/<name> in der Ablage an. SilverBullet sieht die Seiten, der
Index nimmt sie mit (typ doku, projekt = Name), und je Takt gehen
Änderungen aus der Oberfläche als Commit ins Quell-Repo zurück, danach
pull --rebase. Die Ablage ignoriert */doku/, damit die Wahrheit nur im
Quell-Repo liegt. Vorerst komplett und ungefiltert (Andreas 04.09.:
"sobald hive.corp steht, trennen wir die Quellen"). Doku in
docs/quellen.md.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Wirt, Ports, Volume, Routen über Caddy, Einrichtung und die drei Dinge,
die beim ersten Aufsetzen Zeit gekostet haben.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
www.ent-spannung.de auf git.home hat Issues abgeschaltet; jeder
Issue-Endpunkt antwortet dort mit 404 und riss den ganzen Lauf. Jetzt
filtert die Repo-Liste nach has_issues, ein 404 auf die Kommentare gilt
als leer, und ein Fehler je Repo landet im Ergebnis statt im Abbruch.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
podman-compose auf Debian 13 reicht ${VAR:-x} wörtlich durch; km bekam
den Platzhalter als Repo-Namen. Jede Variable steht jetzt in der .env
(Vorlage deploy/env.example), und die Konfiguration verwirft Werte, die
wie ein unersetzter Platzhalter aussehen.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Ohne das CA-Bündel des Wirts scheitert jeder Aufruf an git.home an
CERTIFICATE_VERIFY_FAILED, weil requests sein eigenes Bündel benutzt.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
SilverBullet mountet dasselbe Volume und legt seine Dateien an, bevor km
dran ist — der clone scheiterte auf hive.home an einem nicht leeren
Verzeichnis. Jetzt: init im Verzeichnis, Remote holen, Branch auschecken
wenn vorhanden, sonst legt der erste Push ihn an. Die Eigendateien der
Oberfläche (.silverbullet*, _plug/) kommen in die .gitignore der Ablage.
Dazu die restlichen Umlaute im compose-Kommentar.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Ein Prozess (image/km/main.py) mit API (read, search, summary, health,
refresh) auf Standardbibliothek und einem Takt, der die Ablage zieht,
Gitea einliest, indexiert und alles Geänderte committet und pusht — auch
Änderungen aus SilverBullet. Die Ablage ist ein Git-Checkout auf dem
Volume, der Index eine SQLite-Datei daneben; ein Start ohne nötige
Umgebung hält mit einer Liste an.
deploy/compose.yml: km plus SilverBullet auf demselben Volume, für den
oci-Betrieb in hive.home unter /km (SB_URL_PREFIX). deploy/health für
42i-hc. Lokal gegen ein Bare-Remote und spine/core durchgespielt: Ingest,
Index, Commit, Push, Suche, Read mit Kanten in beide Richtungen, und eine
von Hand angelegte Seite landet im nächsten Takt im Remote.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Entscheidung Andreas 2026-09-04 (spine/core#8): kein Datenbankdienst. Der
Index ist eine abgeleitete Sicht auf die Markdown-Ablage in einer Datei im
Volume, jederzeit neu baubar. image/km/index.py zerlegt die Dateien in
Chunks (Chunking aus info/ai/scripts/index_docs.py übernommen), hält
Volltext in FTS5 und Vektoren aus bge-m3 in sqlite-vec, inkrementell über
SHA-256 je Datei. image/km/search.py sucht Volltext führend, Vektor
ergänzend, mit Filtern vor dem Ranking (0 Treffer statt gesperrt).
Ingest: Kommentare bei der Erstbefüllung repo-weit statt je Vorgang —
die erste Fassung hing bei live/live nach 371 Vorgängen; jetzt 2175 in zwei
Minuten. Gemessen: Volltext über 61.000 Chunks in 3 s, Vektoren 0,31 s je
Chunk auf der CPU-Box. Kein Bytecode mehr im Repo.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Erster Baustein von spine/core#13: image/km/ingest_gitea.py liest Issues,
Pull Requests und Kommentare je Repo oder Organisation und schreibt je
Vorgang eine Markdown-Datei mit Frontmatter (Zustand, Labels, Milestone,
Beteiligte, Zeitstempel, Verweise auf andere Vorgänge als Kanten) unter
<ablage>/<namespace>/vorgaenge/<owner>/<repo>/<nummer>.md.
Inkrementell über since je Repo, idempotent, Stand erst nach vollständigem
Durchlauf. Zugang aus OpenBao wie beim Gitea-Helfer, nie in der Ausgabe.
Schreibt nichts nach Gitea zurück. Gemessen: 1165 Vorgänge in drei Minuten.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
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.
eltonandClaude Fable 5.1