Files
chemenu/kb/sources/Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31.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

4.4 KiB

type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary
type source_type author raw_files source_language date tags entities concepts summary
types/source.md notes Claude Code (claude-opus-5)
raw/notes/Conversation Transcript - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31.md
en 2026-08-31
wikitool
Chemenu
Gitea Actions
CI Integration
Sitzung, die einen nightly.yml-Workflow gegen Gitea-Issue #9 baut (schedule + workflow_dispatch, lint --fail-on-error als Kern), einen doctor-Bootstrap-Defekt findet und behebt, und die tatsaechliche Ausloesung des schedule-Triggers unverifiziert laesst

Source: Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31

Autor: Claude Code (claude-opus-5)
Datum: 2026-08-31
Raw-Dateien: raw/notes/Conversation Transcript - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31.md
Typ: Notes

Zusammenfassung

Zweiter Teil derselben Sitzung wie der Sitzungsmitschrift, hier zu Gitea-Issue #9: ci.ymls paths-ignore unterdrückt CI bei einem reinen Content-Publish (belegt in Gitea Actions), also läuft lint --fail-on-error dort nicht mehr mit. .gitea/workflows/nightly.yml schließt diese Lücke mit on: schedule (17 3 * * * UTC) plus workflow_dispatch, ohne Push-Trigger, in derselben Runner-Form wie ci.yml.

Vor dem Bau wurde die Vorbedingung geprüft, nicht angenommen: curl -s https://gitea.nehmer.net/api/v1/version ergab 1.26.1 - weit über der 1.20-Version, die Actions-Schedules einführte, was das Feature plausibel macht, aber nicht beweist, dass der Cron auf diesem Server tatsächlich feuert.

Die Sichtbarkeitsfrage für einen fehlgeschlagenen Lauf wurde dem Nutzer vorgelegt statt angenommen: die Empfehlung war ein automatisch angelegtes Issue bei Fehlschlag, Torben wählte stattdessen ausdrücklich "Nur Gitea-Notification" - kein Meldeschritt im Workflow, Begründung im Workflow-Kopf dokumentiert, damit die Auslassung nicht als vergessen gelesen wird.

Der erste workflow_dispatch-Testlauf (Run 83) schlug zu Recht fehl: doctor meldete FAIL git-identity und FAIL skills, weil ein frischer Checkout noch keine Instanz ist - keine git-Konfiguration im Container, keine publizierten Skills vor instructions sync. instructions verify wurde dadurch nie erreicht, der eigentliche Prüfzweck des Laufs blieb unbeobachtet. Behoben durch einen Bootstrap-Schritt (git-Identität setzen, tools/wikitool instructions sync) vor doctor; Run 85 danach grün auf allen sieben Schritten.

Das Issue bleibt offen: beide beobachteten Läufe waren workflow_dispatch, keiner schedule. Ob dieser Gitea-Stand den Cron-Trigger tatsächlich auslöst, lässt sich erst ab 2026-09-01 03:17 UTC beobachten.

Kernaussagen

  • Ein workflow_dispatch-Erfolg beweist, dass der Job läuft - nicht, dass der Zeitplan feuert. Beide Aussagen wurden in der Sitzung bewusst auseinandergehalten.
  • doctor prüft eine arbeitsfähige Instanz, kein bloßer Checkout ist eine - ein neuer Workflow, der doctor aufruft, braucht denselben Bootstrap wie ein frischer Clone (instructions/bootstrap.md).
  • Die Entscheidung "wie wird ein Fehlschlag sichtbar" wurde dem Nutzer vorgelegt und explizit gegen die Empfehlung des Agenten entschieden (Gitea-eigene Notification statt Auto-Issue).
  • Der erste rote Lauf lag vor dem eigentlichen Prüfzweck des Workflows, nicht in ihm - der Wert des Testlaufs war, das selbst zu zeigen.

Aufgaben

  • .gitea/workflows/nightly.yml erstellt (schedule + workflow_dispatch, Runner-Form aus ci.yml übernommen)
  • Lokal bewiesen, dass ein absichtlich gebrochener Korpus den Lauf rot macht
  • Bootstrap-Lücke (doctor git-identity/skills) gefunden und behoben
  • Run 85: alle sieben Schritte grün
  • Beobachtung, ob on: schedule auf diesem Gitea-Stand tatsächlich feuert (ab 2026-09-01 03:17 UTC) - Gitea-Issue #9 bleibt dafür offen

Nicht übernommen

  • Die beiden Lint-Fixes (Gitea #20, #22) aus demselben /stack-dev-Aufruf sind eine eigene Quelle - anderer Teil des Stacks, siehe der Sitzungsmitschrift.
  • Kein Artefakt-Upload für den Lint-Bericht (reports/ ist gitignored) - bewusst weggelassen, weil lint --fail-on-error die Befunde bereits ins Job-Log druckt; nachrüstbar, falls sich das als unzureichend erweist.

Verwandte Entities

Verwandte Concepts