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.
This commit is contained in:
+144
@@ -0,0 +1,144 @@
|
||||
---
|
||||
type: types/source.md
|
||||
source_type: notes
|
||||
author: Claude Code (claude-opus-5)
|
||||
raw_files: ['raw/notes/Conversation Transcript - Versioning, CI-CD and Content Migration Session 2026-08-30.md']
|
||||
source_language: en
|
||||
date: 2026-08-30
|
||||
tags: [versioning, ci-cd, migration, gitea, wikitool, release]
|
||||
entities: [wikitool, Chemenu, Act Runner, Gitea Actions, Gitea, Gitea MCP Server, Claude Code]
|
||||
concepts: [KB Stack Versioning, KB Migration, Mass-Update Gate, CI Integration]
|
||||
summary: Sitzung, die Stack-Versionierung mit CI und Release-Artefakten baut, sie um eine getrennte KB-Versionierung mit Migrationskette ergaenzt und die Gitea-Actions-Pipeline in Betrieb nimmt
|
||||
---
|
||||
# Source: Conversation - Versioning CI-CD and Content Migration Session 2026-08-30
|
||||
|
||||
**Autor:** Claude Code (claude-opus-5)
|
||||
**Datum:** 2026-08-30
|
||||
**Raw-Dateien:** raw/notes/Conversation Transcript - Versioning, CI-CD and Content Migration Session 2026-08-30.md
|
||||
**Typ:** Notes
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
Das Transkript ist eine vom Assistenten am Sitzungsende rekonstruierte Zusammenfassung, kein
|
||||
wörtliches Protokoll; Befehlsausgaben darin sind echt, Torbens Fragen und Entscheidungen sind
|
||||
eng wiedergegeben, die Begründungen des Assistenten verdichtet. Die Sitzung lief vom 2026-08-29
|
||||
bis 2026-08-30 und deckt drei Arbeitspakete ab, die sich als dieselbe Mechanik von verschiedenen
|
||||
Seiten erwiesen: Versionierung des Stacks mit CI und Release-Artefakten (ausgeliefert als
|
||||
`0.1.0`, dann `1.0.0`), eine darauf aufsetzende Content-Migrationsstrategie und schließlich das
|
||||
Inbetriebnehmen der Pipeline. Resultierende Commits: `2508f7a`, `7d63d61`, `c3034ab`, `db03b08`,
|
||||
`aace3e7`, `401d700`, `b94166b`.
|
||||
|
||||
Der erste Entwurf versionierte nur den Stack. Torben verwarf ihn mit der Frage, wo die aktuelle
|
||||
Version einer KB gespeichert wird und wie eine KB über mehrere Versionen hinweg aktualisiert
|
||||
wird. Das legte einen Fehler offen: Stack- und Content-Version waren zusammengeworfen, obwohl
|
||||
eine Instanz Maschinerie `1.4.0` tragen kann, während ihr Inhalt noch in `1.2.0`-Form vorliegt -
|
||||
genau der Zustand, den jedes Upgrade durchläuft. Der zweite Entwurf trennt drei Fakten in drei
|
||||
Dateien und baut die Migrationskette als geordnetes Intervall. Er wurde freigegeben und
|
||||
umgesetzt.
|
||||
|
||||
Parallel wurde die Gitea-Actions-Pipeline gegen den Runner auf `ci-runner.example.net` gebracht.
|
||||
Die Diagnose über den neu verfügbaren Gitea-MCP-Server ergab das Gegenteil der Annahme: Die
|
||||
Runner hatten die Workflows die ganze Zeit angenommen und scheiterten am Checkout, weil
|
||||
`actions/checkout` eine JavaScript-Action ist, die act_runner mit `node` im Job-Container
|
||||
ausführt - und das gepinnte `debian:trixie-slim` bringt keins mit. Der erste Lauf, der bis
|
||||
`pytest` kam, fand einen echten Fehler in zwei Tests, die auf jeder Entwicklermaschine
|
||||
monatelang grün gewesen waren.
|
||||
|
||||
## Kernaussagen
|
||||
|
||||
- **Die Version beschreibt den Stack; der Content hat seine eigene Version.** Drei Fakten, drei
|
||||
Dateien: `VERSION` (welche Maschinerie installiert ist, geschrieben von `version bump`),
|
||||
`.wikitool-release.json` (woher sie kam, erzeugt von `dist export`) und `.wikitool-kb.json`
|
||||
(in welcher Form der Inhalt vorliegt, geschrieben von `migrate done`). Getrennte Dateien, weil
|
||||
der Release-Stempel erzeugt ist und nie von Hand geändert werden darf, der KB-Zustand dagegen
|
||||
veränderlicher Instanzzustand ist.
|
||||
- **Kompatibilität ist die linkeste Nicht-Null-Komponente** - dieselbe Regel, die Cargos
|
||||
Caret-Ranges verwenden. Sie gilt einheitlich für `0.x` und `1.x`; ab `1.0.0` liest sie sich als
|
||||
gewöhnliches Semver. Keine Pre-Release-Suffixe, weil eine zweite Ordnungsregel vom Release-Feed,
|
||||
von der Migrationskette und von der Kompatibilitätsprüfung gleichermaßen befolgt werden müsste.
|
||||
- **Die Migrationskette ist ein Intervall, keine Fallunterscheidung.** `migrate status` bildet
|
||||
`(kb_version, VERSION]` aus den Migrationsdokumenten und ordnet aufsteigend; von `1.3.1` nach
|
||||
`2.0.0` laufen `1.4.0`, `1.7.0`, `2.0.0` nacheinander. 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 - damit ist ein Sprung unmöglich und ein
|
||||
unterbrochenes mehrstufiges Upgrade fortsetzbar.
|
||||
- **Zählen, nicht Mengen vergleichen.** `kb_scan.extract_wikilinks()` liefert ein Set. Das ist
|
||||
richtig für `lint` (löst der Verweis auf?) und falsch für eine Migrationsprüfung (ist einer
|
||||
verschwunden?). Drei der vier Defekte, die die frühere Übersetzung fand, hatten unveränderte
|
||||
Link-Mengen und nur veränderte Zählungen.
|
||||
- **Der Runner nahm die Workflows immer an.** `actions/checkout` ist eine JavaScript-Action, die
|
||||
act_runner mit `node` **im Job-Container** ausführt; das gepinnte `debian:trixie-slim` hat
|
||||
keins, daher `exec: "node": executable file not found in $PATH` und `exitcode '127'`. Die
|
||||
Lösung war eine Zeile in einer apt-Liste: `nodejs` **vor** dem Checkout installieren, plus
|
||||
`actions/checkout@v7`. `runs-on: linux-docker` blieb, weil die Läufe 46-51 bewiesen, dass das
|
||||
Label routet und den Container startet.
|
||||
- **Ein CI-Lauf ist Evidenz, ein lokaler Lauf ist Gewohnheit.** Lauf 52 kam als erster bis
|
||||
`pytest` und ließ zwei von 630 Tests fallen: `config.default_author()` ruft `git config
|
||||
user.name` mit `cwd=config.ROOT`, das Fixture-Root ist kein Repository, also antwortete die
|
||||
globale git-Konfiguration dessen, der die Suite ausführte. Im Container als root gibt es keine.
|
||||
Behoben in den Tests, nicht durch eine git-Identität für CI: Das hätte den Lauf grün gemacht
|
||||
und den Fehler stehen gelassen.
|
||||
- **Das Origin-Repository ist privat, und Gitea antwortet anonym identisch** mit `404` für ein
|
||||
unsichtbares und für ein nicht existierendes Repository. `curl` beweist damit nichts über den
|
||||
CI-Zustand; Läufe werden über den Gitea-MCP-Server gelesen. `WIKITOOL_UPDATE_TOKEN` ist
|
||||
dadurch Voraussetzung statt Ausnahme.
|
||||
- **`${{ gitea.token }}` genügt für Releases, Tags und Asset-Uploads.** Kein Actions-Secret mit
|
||||
`write:repository` nötig. Belegt dadurch, dass `release.yml` beim Versionssprung auf `1.0.1`
|
||||
von selbst feuerte und `llm-wiki-stack-1.0.1.tar.gz` samt `.sha256` hochlud.
|
||||
- **`paths-ignore` scheitert bewusst offen.** Die Liste steht zweimal statt einmal über einen
|
||||
YAML-Anker, weil GitHubs Parser Anker ablehnt und Gitea sie nicht dokumentiert akzeptiert; es
|
||||
gibt keine `!**/CONTRACT.md`-Negation, weil Gitea negierte Filtermuster nicht dokumentiert; und
|
||||
`kb/CONTRACT.md` ist absichtlich nicht ausgenommen, weil es unter einem Content-Verzeichnis
|
||||
liegt, aber zum Stack gehört. Alles Unvorhergesehene löst weiterhin CI aus.
|
||||
- **Die verworfene Methodik lag im git-Verlauf.** Der geschlossene Workshop `translate-kb-de`
|
||||
wurde aus `de0862f` zurückgeholt und trug eine vollständige Arbeitsweise: Einheiten nach dem
|
||||
Iterationsbudget geschnitten, Batches getrennt davon nach dem Mass-Update Gate, Frontmatter/H1/
|
||||
Wikilink-Ziele/Cite-IDs vor allem anderen gegen `HEAD` geprüft, `lint` über jede Einheit
|
||||
vollständig gelesen, und Zusammenfassungen von der orchestrierenden Sitzung geschrieben statt
|
||||
von einem Subagenten übernommen.
|
||||
|
||||
## Aufgaben
|
||||
|
||||
- [ ] Gitea-Issue #7 - `dist upgrade` bauen (in dieser Sitzung bewusst zurückgestellt)
|
||||
- [ ] Gitea-Issue #8 - Testsuite gegen stille Umgebungsabhängigkeiten härten
|
||||
- [ ] Gitea-Issue #9 - nächtlichen Drift-Check einrichten
|
||||
- [ ] Gitea-Issue #10 - Coverage
|
||||
- [ ] Gitea-Issue #11 - bestätigen, dass Gitea die `paths-ignore`-Muster wie erwartet auswertet;
|
||||
ausdrücklich als Beobachtung geführt, nicht als Bauaufgabe - der Beleg kommt beim nächsten
|
||||
reinen Content-Publish von selbst
|
||||
|
||||
## Nicht übernommen
|
||||
|
||||
- **Die turn-für-turn-Struktur des Transkripts.** Der Verlauf der Sitzung ist Chronologie, keine
|
||||
dauerhafte Aussage; die Entscheidungen wurden auf die Concept- und Entity-Seiten gehoben, die
|
||||
Reihenfolge blieb hier.
|
||||
- **Die Commit-Hashes einzelner Zwischenschritte** (`2508f7a`, `7d63d61`, `db03b08`) über die
|
||||
Zusammenfassung hinaus. Der git-Verlauf und `CHANGES.md` führen sie bereits; eine zweite Kopie
|
||||
in `kb/` wäre der driftende Doppeleintrag, den der Stack sonst überall vermeidet.
|
||||
- **Die Modul- und Dateiliste der Implementierung** (`corpus_diff.py`, `kb_state.py`,
|
||||
`migrate_cmd.py`) unterhalb dessen, was die Concept-Seiten zum Verständnis brauchen. Die
|
||||
Codestruktur ist im Repository nachlesbar und veraltet in `kb/` schneller als dort.
|
||||
- **Die Zahlen der Verifikationsläufe** (248 verglichene Seiten, 2,2 s, 630 Tests, 29 gezählte
|
||||
Dateien am Mass-Update Gate). Sie belegen einen Stichtag, nicht eine Eigenschaft; nur die
|
||||
Negativkontrolle `'Docker' 2->1` bei gleichzeitig stillem `lint` wurde übernommen, weil sie die
|
||||
Aussage trägt, auf der die Strategie ruht.
|
||||
- **Die Korrektur der Modellzuschreibung** in der Kopfzeile des Transkripts (erste Fassung nannte
|
||||
„Claude Sonnet 5", das Sitzungslog `claude-opus-5`). Sie betrifft die Quelle selbst und ist
|
||||
über `author:` bereits festgehalten.
|
||||
|
||||
## Verwandte Entities
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Chemenu]]
|
||||
- [[Act Runner]]
|
||||
- [[Gitea Actions]]
|
||||
- [[Gitea]]
|
||||
- [[Gitea MCP Server]]
|
||||
- [[Claude Code]]
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Stack Versioning]]
|
||||
- [[KB Migration]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[CI Integration]]
|
||||
Reference in New Issue
Block a user