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.

kb/concepts/CI Integration.md

@@ -0,0 +1,105 @@
+---
+type: types/concept.md
+concept_type: workflow
+tags: [pre-commit, hooks, automation, quality-control]
+created: 2026-08-03
+modified: 2026-09-01
+related: [wikitool, Gitea Actions]
+sources: [Source - LLM Improvements Codex Analysis, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
+confidence: 0.80
+confidence_base: 0.80
+provenance: sourced
+summary: 'CI/CD-Hooks vor dem Publish: ci.yml (Push/PR, Stack-Pfade, seit 1.8.1 mit Coverage-Messung ohne Schwelle) und nightly.yml (Zeitplan, schliesst die paths-ignore-Luecke fuer Content-Drift; schedule-Ausloesung seit 2026-09-01 bestaetigt) setzen Quality Gates durch'
+---
+# CI Integration
+
+**Typ:** workflow
+
+## Definition
+
+CI Integration bezieht sich auf die Einrichtung von Pre-Commit-Hooks und CI/CD-Pipelines, die automatisch Quality Gates durchsetzen, bevor Änderungen im Repository veröffentlicht werden. Dies stellt sicher, dass Regressionen früh abgefangen werden und das Wiki jederzeit strukturelle Integrität bewahrt.
+
+## Kernpunkte
+
+- **Umgesetzt, nicht mehr nur geplant:** `.gitea/workflows/ci.yml` läuft seit `1.2.0` bei jedem
+  Push/PR auf Stack-Pfaden und führt `docs verify`, `instructions verify` und
+  `lint --fail-on-error` aus, bevor `dist export` die Verteilung prüft.
+- **`paths-ignore` schließt Content-Commits explizit aus** (`kb/`, `raw/`, `work/`, `reports/`) -
+  ein reiner Wiki-Publish löst also **keinen** CI-Lauf aus. Das ist gewollt (`publish` fasst bei
+  jedem Ingest `kb/` an, die volle Suite dafür zu fahren wäre Lärm), öffnet aber eine Lücke:
+  strukturelle Regression im Korpus selbst fällt zwischen zwei Content-Publishes niemandem auf.
+  Siehe [[Gitea Actions]] für den Beleg, dass der Filter tatsächlich greift.
+- **Diese Lücke schließt ein zweiter, geplanter Workflow**, nicht ein Pre-Commit-Hook:
+  `.gitea/workflows/nightly.yml` (seit 2026-08-31, Gitea-Issue #9) läuft `on: schedule` plus
+  `workflow_dispatch` und fährt `doctor`, `docs verify`/`instructions verify`,
+  `lint --fail-on-error`, `sources coverage` und `migrate status` unabhängig vom
+  Push-Ereignis[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+  Ein Workflow, der `doctor` auf einem frischen Checkout aufruft, braucht denselben Bootstrap
+  wie ein neuer Clone (git-Identität, `instructions sync`) - sonst scheitert er an der eigenen
+  Startbedingung, nicht am
+  Korpus[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+  ~~Ob der `schedule`-Trigger auf dieser Gitea-Instanz tatsächlich feuert, ist noch
+  unbeobachtet - bislang bewiesen nur, dass der Job selbst läuft~~ (Stand
+  2026-08-31)[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+  **Beobachtet seit 2026-09-01:** Run 90 feuerte als erster Lauf mit `"event":"schedule"`,
+  exakt zur konfigurierten Cron-Zeit (`17 3 * * *` UTC), alle sieben Schritte grün - der
+  Trigger funktioniert also auf diesem Gitea-1.26.1-Stand tatsächlich, Gitea-Issue #9 ist
+  geschlossen.
+- **Fehlersichtbarkeit ist eine bewusste Nutzerentscheidung, kein Automatismus:** ein
+  fehlgeschlagener `nightly`-Lauf meldet sich über Giteas eigene Run-Notification, nicht über ein
+  automatisch angelegtes
+  Issue[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
+- Ein Pre-Commit-Hook (lokale Prüfung vor `git commit`) ist bisher **nicht** eingerichtet - beide
+  bestehenden Workflows sind serverseitig.
+- **`ci.yml`s Tests-Schritt misst seit `1.8.1` Coverage und weist sie als Artefakt aus**, ohne
+  Abbruchschwelle - siehe Messen vor Schwelle für die Begründung der Reihenfolge. Konfiguration
+  in `tools/.coveragerc`, nicht `pytest.ini`, weil coverage.py Letzteres nicht liest.
+
+## Beispiele
+
+- `ci.yml`: `docs verify` + `instructions verify` + `lint --fail-on-error` bei jedem
+  Stack-Push/PR, danach `dist export` und ein Replay von `setup-instance.md` gegen die Export.
+- `nightly.yml`: dieselben Kernprüfungen auf einem Zeitplan statt auf einen Push, damit
+  Korpus-Drift zwischen zwei Content-Publishes nicht unbemerkt bleibt.
+
+## Implementierungshinweise
+
+Beide Workflows teilen sich dieselbe Runner-Form (Debian trixie-slim, `nodejs` vor dem Checkout,
+`actions/checkout@v7`) - siehe [[Gitea Actions]] für die Begründung und die dort dokumentierten
+Fallstricke (fehlendes `node` im Image, git-Konfiguration im Job-Container, `doctor`s
+Bootstrap-Anspruch an eine Instanz statt an einen bloßen Checkout).
+
+## Wann zu verwenden
+
+- In jeder produktiven oder gemeinsam genutzten Wiki-Bereitstellung
+- Um Konsistenz über mehrere Mitwirkende durchzusetzen
+- Um Fehler vor Erreichen des Hauptzweigs abzufangen
+
+## Wann NICHT zu verwenden
+
+- In früher Entwicklung, wenn sich Regeln häufig ändern
+- Für Single-Contributor-Test-Repos, bei denen manuelle Prüfungen ausreichend sind
+
+## Verwandte Concepts
+
+- [[wikitool]] (stellt Lint- und andere Befehle für CI bereit)
+(die Reihenfolge hinter dem Coverage-Reporting)
+(CI-Gates ergänzen Runtime-Gates)
+- [[Lint Workflow]] (Lint ist eine Schlüssel-CI-Prüfung)
+- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
+
+## Beziehungen
+
+- **verwendet:** [[wikitool]]
+- **implementiert über:** [[Gitea Actions]]
+
+## Siehe auch
+
+- [[Source - LLM Improvements Codex Analysis]]
+- [[wikitool]]
+- [[Gitea Actions]]
+
+## Fußnoten
+
+[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]: [[Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]]
+[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]