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.
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) |
|
en | 2026-08-31 |
|
|
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. doctorprüft eine arbeitsfähige Instanz, kein bloßer Checkout ist eine - ein neuer Workflow, derdoctoraufruft, 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.ymlerstellt (schedule + workflow_dispatch, Runner-Form ausci.ymlübernommen)- Lokal bewiesen, dass ein absichtlich gebrochener Korpus den Lauf rot macht
- Bootstrap-Lücke (
doctorgit-identity/skills) gefunden und behoben - Run 85: alle sieben Schritte grün
- Beobachtung, ob
on: scheduleauf 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, weillint --fail-on-errordie Befunde bereits ins Job-Log druckt; nachrüstbar, falls sich das als unzureichend erweist.