chemenu/kb/sources/transcripts/Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31.md

type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary, fidelity, authority

type	source_type	author	raw_files	source_language	date	tags	entities	concepts	summary	fidelity	authority
types/source.md	transcript	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	verbatim	reporting

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

• wikitool
• Chemenu
• Gitea Actions

Verwandte Concepts

• CI Integration