Files
chemenu/kb/concepts/Crystallization.md
T
torben 18ae28f918
CI / verify (push) Failing after 32s
Release / release (push) Successful in 38s
Chemenu 2.1.0 - deterministischer Wissenskompiler
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
2026-09-01 16:26:14 +02:00

5.5 KiB

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary
type concept_type tags created modified related sources confidence confidence_base provenance summary
types/concept.md workflow
crystallization
knowledge
distillation
workflow
2026-07-26 2026-08-29
LLM Wiki Pattern
Memory Lifecycle
Event-Driven Automation
Source - LLM Wiki v2
0.85 0.85 sourced Verdichten abgeschlossener Erkundungen, Debugging-Sitzungen und Recherchen zu strukturierten Wiki-Auszügen als eigenständige Wissensquellen.

Crystallization

Typ: Arbeitsablauf (Wissensdestillation aus Erkundung)

Definition

Crystallization ist der Prozess, bei dem eine abgeschlossene Arbeitskette (ein Forschungsthread, eine Debug-Sitzung, eine Analyse, eine Erkundung) genommen und automatisch destilliert wird in eine strukturierte Zusammenfassung. Das ursprüngliche Muster erwähnt, gute Antworten zurück ins Wiki zu organisieren; Crystallization geht weiter, indem es Erkundungen als erstklassige Quellen behandelt.

Kernpunkte

Das Problem

Ohne Crystallization:

  • Wertvolle Erkenntnisse aus Erkundungssitzungen gehen verloren
  • Muster, die durch Debugging oder Forschung entdeckt werden, werden nicht erfasst
  • Jede Erkundung beginnt von vorne
  • Wissen wächst nicht aus abgeschlossener Arbeit

Die Lösung

Erkundungen als Quellen behandeln - genau wie Artikel oder Arbeiten. Das Wiki sollte:

  1. Die Ergebnisse von Erkundungen aufnehmen
  2. Den Wissensgraphen aktualisieren
  3. Bestehende Aussagen stärken oder in Frage stellen

Crystallization-Prozess

Für eine abgeschlossene Arbeitskette automatisch eine strukturierte Zusammenfassung erstellen:

Zusammenfassungskomponenten:

Komponente Beschreibung Beispiel
Frage Wie lautete die ursprüngliche Frage/Problem? "Warum schlägt der Build fehl?"
Methode Welcher Ansatz wurde gewählt? "Logs verfolgt, Abhängigkeiten überprüft"
Dateien/Entitäten Welche Dateien, Systeme, Entitäten waren beteiligt? "Dockerfile, build.sh, Jenkins"
Erkenntnisse Was wurde entdeckt? "Fehlende BuildKit-Abhängigkeit"
Lektionen Welche allgemeinen Lektionen ergaben sich? "Immer BuildKit-Version überprüfen"
Ergebnis Wie war das Ergebnis? "Durch Hinzufügen der BuildKit-Abhängigkeit repariert"
Verwandt Links zu verwandten Wiki-Seiten "Docker, Python"

Ausgabe: Die Zusammenfassung wird zu einer erstklassigen Wiki-Seite, typischerweise in kb/sources/ oder als Konzept-Seite.

Was wird kristallisiert

Arbeitstyp Crystallization-Ausgabe
Forschungsthread Forschungsergebnisse-Seite
Debugging-Sitzung Debug-Analyse-Seite
Analyse Analyseergebnisse-Seite
Deep Dive Deep Dive-Zusammenfassung-Seite
Vergleich Vergleichsseite (siehe Vergleichsseite-Vorlage)

Automatisierung

Mit Event-Driven Automation integrieren:

Trigger: Bei Sitzungsende (oder expliziter Crystallization-Befehl)

Maßnahmen:

  1. Das Sitzungstranskript/Log analysieren
  2. Schlüsselinformationen extrahieren (Frage, Methode, Erkenntnisse, etc.)
  3. Involvierte Entitäten und Konzepte identifizieren
  4. Strukturierte Zusammenfassung erstellen
  5. Als neue Wiki-Seite organisieren
  6. Verwandte Entitäts-/Konzept-Seiten aktualisieren
  7. kb/index.md und kb/log.md aktualisieren
  8. Extrahierte Fakten zu angepassten Consolidation Tiers fördern

Beispiel

Sitzung: Debugging von fehlgeschlagenen CI-Builds

Crystallized Output: kb/sources/debug-ci-build-failure-2026-07-26.md

# Debug: CI Build Failure - 2026-07-26

**Question:** Why are CI builds failing in the last 24 hours?

**Method:**
- Checked CI logs for errors
- Compared failing vs. passing builds
- Reviewed recent changes
- Tested locally

**Entities Involved:**
- [[Docker]]
- [[Gitea Actions]]

**Findings:**
- Builds fail with "BuildKit not found" error
- Recent update to BuildKit version in Dockerfile
- Actions Cache Server connectivity issue

**Lessons:**
- Remote BuildKit requires port 1234 to be accessible
- Actions Cache Server needs host network mode
- Version mismatches can cause silent failures

**Outcome:** Fixed by updating BuildKit configuration and network settings

**Related:**

Vorteile

  • Knowledge Compounding: Erkenntnisse aus Erkundungen werden permanent erfasst
  • Reduzierte Redundanz: nicht die gleichen Probleme erneut debuggen
  • Mustererkennung: Lektionen entstehen über mehrere Crystallizations
  • Automatische Dokumentation: Erkundungen dokumentieren sich selbst
  • Quellenvielfalt: Erkundungen sind wertvolle Quellen neben Artikeln

Wann zu verwenden

  • Jedes Wiki, das für Forschung oder Debugging verwendet wird
  • Mehrseissions-Erkundungen
  • Situationen, in denen Erkundungseinsichten wertvoll sind
  • Domänen mit wiederkehrenden Problemen oder Mustern

Wann NICHT zu verwenden

  • Triviale, einmalige Fragen
  • Situationen, in denen der Overhead nicht gerechtfertigt ist
  • Vollständig ad-hoc Erkundung (keine Struktur zum Kristallisieren)

Verwandte Konzepte

Siehe auch