torben/chemenu

Fork 0

Files

T

torben 18ae28f918

CI / verify (push) Failing after 32s

Details

Release / release (push) Successful in 38s

Details

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

7.7 KiB

Raw Blame History

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type

concept_type

KB Migration

Typ: Workflow

Definition

KB Migration ist der Ablauf, mit dem der Inhalt einer Wissensbasis auf die Form gebracht wird, die eine neuere Stack-Version erwartet. Die Form des Inhalts hat eine eigene Version in .wikitool-kb.json, unabhängig von der Stack-Version in VERSION (KB Stack Versioning)¹. Eine Instanz kann Maschinerie 1.4.0 tragen, während ihr Inhalt noch in 1.2.0-Form vorliegt; genau diesen Zustand durchläuft jedes Upgrade, und er ist der Grund für die Trennung.

Migrationen selbst sind manual: true-Anweisungen unter instructions/migrations/. Damit werden sie von dist export ohne zweiten Exportpfad mitgeliefert¹.

Kernpunkte

Die Kette ist ein Intervall, keine Fallunterscheidung. migrate status bildet (kb_version, VERSION] aus den vorhandenen Migrationsdokumenten und ordnet aufsteigend. Von 1.3.1 nach 2.0.0 laufen 1.4.0, dann 1.7.0, dann 2.0.0. Dass keine Migration auf 1.3.x zielt, ist kein Sonderfall, sondern schlicht nicht im Intervall¹.
migrate done verweigert jede Version, die nicht das nächste Glied ist. Ein Sprung wird dadurch unmöglich, und ein unterbrochenes mehrstufiges Upgrade ist an der Stelle fortsetzbar, an der es abbrach¹.
1.0.0 ist die Basis. Alles Ältere wird neu exportiert, nicht migriert¹. Eine bestehende Instanz ohne .wikitool-kb.json erhält ihren Startwert über migrate baseline; der Entwicklungsbaum selbst war der erste Fall und bekam 1.0.0, weil sein Inhalt seiner Maschinerie nie hinterherhing¹.
Zählen, nie Mengen vergleichen. kb_scan.extract_wikilinks() liefert ein Set. Für lint ist das richtig - die Frage lautet, ob ein Verweis auflöst. Für eine Migrationsprüfung ist es falsch, denn dort lautet die Frage, ob einer verschwunden ist. Drei der vier Defekte, die die frühere Übersetzung des Korpus fand, hatten unveränderte Link-Mengen und nur veränderte Zählungen¹.
lint kann eine Migration nicht absichern. Die Negativkontrolle: eines von zwei [[Docker]]-Vorkommen aus kb/entities/tools/Act Runner.md entfernt, die Link-Menge damit unverändert. migrate verify --from HEAD --fail-on-error meldet 'Docker' 2->1, lint --fail-on-error endet mit Exit 0 und schweigt über alle 21 Checks¹. lint liest eine einzige Revision; ein verschwundener Verweis hinterlässt ein Korpus, das in sich vollkommen stimmig ist. Darauf ruht die gesamte Strategie.
„Seite" muss überall dasselbe heißen. Der erste Lauf von migrate verify über 248 Seiten meldete 13 „entfernte Seiten", die keine sind: Die historische Seite listete jede .md unter kb/, die Arbeitsbaum-Seite benutzte iter_kb_pages, das COLLECTION.md, INDEX.md und die Meta-Dateien der kb-Wurzel überspringt. Behoben durch ein gemeinsames kb_scan.is_page_path, festgehalten durch einen Regressionstest¹.
Kanonischer Name plus Aliase ist das Migrationsmuster. sections.py dokumentiert es im eigenen Docstring: Es ist das, was ein Korpus Seite für Seite statt auf einen Schlag migrieren lässt - und das Entfernen eines Alias ist eine Breaking Change, keine Aufräumarbeit¹.
Zwei Größen, zwei Regeln. Einheiten werden nach dem Iterationsbudget geschnitten, Batches getrennt davon nach dem Mass-Update Gate. Beides zu verwechseln kostete im ersten Schnitt des Plans elf unnötige Freigaben¹.
Pro Einheit zuerst die Struktur: Frontmatter, H1, Wikilink-Ziele und Cite-IDs gegen HEAD vergleichen, bevor irgendetwas anderes geprüft wird. lint wird über jede Einheit vollständig gelesen, nicht nur über die vermeintlich betroffenen Abschnitte - der Frontmatter-Fehler der ersten Einheit tauchte als Schema-Fehler in einem Feld auf, das niemand bearbeitet hatte¹.
Zusammenfassungen schreibt die orchestrierende Sitzung, nie aus einem Subagenten übernommen: Sie schmücken aus, etwa „measuring application performance and responsiveness" zu „Latenz und Durchsatz unter Lastbedingungen"¹.

Beispiele

wikitool - stellt migrate list/status/verify/done/baseline bereit und trägt die Prüfung corpus diff.
Chemenu - erster Fall für migrate baseline; 1.0.0 wurde ohne Migrationsdokument gesetzt, mit ausdrücklicher Begründung.

Wann zu verwenden

Sobald eine semantische Änderung am Inhalt ansteht, die eine bestehende Instanz nicht durch ein bloßes Stack-Update mitbekommt - eine geänderte Abschnittsbenennung, ein umbenanntes Frontmatter-Feld, ein umgezogenes Verzeichnis. Der MAJOR-Bump ohne Migrationsdokument wird von version bump verweigert¹.

Wann NICHT zu verwenden

Nicht für Änderungen, die nur die Maschinerie betreffen. Ein neuer Befehl ohne Wirkung auf die Form des Inhalts braucht kein Migrationsdokument.
Nicht mit einem mechanischen Runner für Null-Migrationen. Eine DSL dafür wurde bewusst nicht gebaut, solange es nichts zu automatisieren gibt¹.
Nicht mit lint als Absicherung - siehe die Negativkontrolle oben.
Nicht für eine offene Instanz-Aktion. Die Maschinerie ist durchgehend auf Korpus-Form verdrahtet: kb_version beschreibt die Form des Inhalts, migrate done nimmt --pages, migrate verify vergleicht kb/. Eine Anforderung, die eine Instanz erfüllen muss, ohne dass sich eine Seite ändert - etwa das Anlegen von USER.md/SOUL.md aus der Personalization Plane - ist deshalb keine Migration, sondern ein Fall für einen doctor-Check. Ein Migrationsdokument dafür hätte zwei Kosten: migrate done würde kb_version heben und damit über den Inhalt etwas behaupten, das nicht über ihn gilt, und eine frische Instanz bekäme die Migration nie zu sehen, weil dist export ihr kb_version = VERSION mitgibt. Der Health-Check ist hier zudem das schärfere Werkzeug, weil er selbstprüfend ist: er meldet FAIL, bis die Sache erledigt ist, während migrate done eine Behauptung ist, die man ohne die Arbeit aufstellen kann.

Fußnoten

Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30 ↩︎

7.7 KiB Raw Blame History