--- name: cleanup-after-welle description: Cleanup-Routine nach jeder Welle. Aktivieren bei "Welle abgeschlossen", "Cleanup nach Welle", "STATUS aktualisieren", "Audit-Files weg", "aufrauemen nach Worker", "cleanupAfterWelle", "wrapUpWorkflow". --- # Cleanup-After-Welle — Persona Du bist der Aufraeumer nach jeder abgeschlossenen Welle. Du machst aus dem Worker-Chaos einen sauberen Workspace-State, in dem der naechste Architekt sofort weiterarbeiten kann. Verweis: Top-Doktrin in Root-`CLAUDE.md` Sektion "Cleanup nach jeder Welle". ## Wann aktivieren - "Welle abgeschlossen", "Cleanup nach Welle", "STATUS aktualisieren", "Audit-Files weg", "aufrauemen nach Worker" - Nach jeder Architekt-Welle, jedem grossen Worker-Loop, jeder Master-Konsolidierung. - Pflicht-Trigger im Anschluss an `audit-worker`, `welle-orchestration`, `website-perfektionieren`, `grv-bugs-workflow`. ## 8-Schritte-Routine ### 1. STATUS.md ueberschreiben Identifiziere das betroffene Projekt (L4-L7). Ueberschreibe dessen `STATUS.md` mit dem Welle-Outcome. Pflicht-Sektionen (Template: `_control/templates/status-template.md`): - Letzte Welle (ID, Datum, Outcome) - Live-URLs / BUILD_ID / Service-Status - Final-Scores / Pass-Fail-Liste - Offene Bugs / Known-Issues - Naechster Schritt Kein Append — Ueberschreiben. Git-Log ist das Archiv. ### 2. Audit-Files loeschen Alle `*.audit.md` im Projekt-Scope sind Sub-Agent-Auftraege. Nach Erledigung sind sie Muell und MUESSEN weg, sonst verwirren sie den naechsten Init-Agenten. ``` Glob /**/*.audit.md # pro File: pruefen ob Welle-Outcome im STATUS.md festgehalten ist # dann: rm ``` Falls eine `.audit.md` "verloren wirkt" (Worker abgebrochen): Inhalt in `STATUS.md` Sektion "Offene Bugs" festhalten, dann loeschen. ### 3. Tot-Files in Archiv Verschiebe in `/_archive/-/`: - `temp-*`, `draft-*`, `scratch-*`, `holding-*` - `HANDOFF*.md` (verboten laut Root-CLAUDE.md, ins Archiv) - `SESSION-*.md`, `CURRENT-AUDIT.md` (Legacy-Pattern) - Worker-Berichte ohne Aufnahme in STATUS.md `_archive/` wird nicht weiter beruehrt — git haelt es. ### 4. Memory pflegen Falls die Welle drift-relevant war (neue Architektur-Erkenntnis, veralteter State, neue Konvention, gestrichenes Projekt): - Betroffene `~/.claude/projects/.../memory/*.md` updaten ODER Stale-Marker `> Stand: — VERALTET` setzen. - `MEMORY.md` syncen: Count + Pointer-Liste konsistent mit Filesystem. - Falls neue Erkenntnis: ggf. neues Memory-File + Eintrag in MEMORY.md. Vollroutine bei groesseren Drifts: Runbook `_runbooks/memory-pflege.md`. ### 4b. Runbook-Run-Logs der Welle pflegen (Mitlern-Pflicht) Welche Runbooks haben die Worker / der Architekt in dieser Welle genutzt? (Aus den Audit-Files / Handoffs / Welle-Bericht ablesen, oder Worker fragen.) Pro genutztem Runbook: - EINE Zeile ins `## Run-Log` (neueste oben, max 8 — aelteste raus): `| YYYY-MM-DD | | PASS|PARTIAL|FIX|META | |` - War ein Schritt falsch / hat sich was geaendert -> Schritt korrigieren + `## Learnings`-Eintrag (`### YYYY-MM — Kurztitel`). - Hat ein Worker waehrend der Welle ein NEUES Runbook geschrieben -> pruefen ob es Pflicht-Sektionen + INDEX-Eintrag hat (`_runbooks/runbook-erstellen.md`). Grund: Runbooks lernen nur mit, wenn der Schreib-Moment erzwungen ist. Cleanup ist der Backstop, falls die Worker es vergessen haben. Doktrin: `_runbooks/struktur-navigieren.md` Sektion 6, `CLAUDE.md` "Navigations-Doktrin". ### 5. Schriftbuero-Inbox ablegen Pro Projekt mit Schriftbuero (`/_schriftbuero/` oder `_schriftbuero/`): - Files in `Inbox/` aelter als 4 Wochen -> `_archive//Inbox/` - Files in `Antworten/` mit Status "verstanden" -> `_archive/` - Briefings: nur die letzten 3 in `Briefings/` behalten - **User-Anleitungen die "Erledigt" gekennzeichnet werden sollen:** vor Archivierung Body nach Inline-User-Kommentaren scannen (typisch `---`-Trenner gefolgt von User-Antwort, oder `>`-Quote am Ende von Schritten). Wenn User Folge-Wuensche hinterlassen hat -> NEUE ACT-Datei (`ACT-YYYY-MM-DD-NNN-.md`) anlegen, im MASTER-ACTIONS verlinken, ERST DANN das alte File archivieren. Eine "Erledigt"-Markierung darf nie Folge-Wuensche schlucken. (Lesson aus Welle 2026-05-11: ntfy-Anleitung enthielt 2 versteckte User-Wuensche, die ohne Konsolidierungs-Welle verloren gegangen waeren.) - **INDEX-Phantom-Check vor Update:** jedes referenzierte File via Glob verifizieren. Phantom-Verweise streichen statt blind durchschleppen. Vollroutine: Runbook `_runbooks/schriftbuero-konsolidieren.md` (insb. Schritt 4a). ### 6. MASTER-STATE / OPEN-ITEMS syncen Falls Workspace-Root `MASTER-STATE.md` oder `OPEN-ITEMS.md` existiert: - Eintrag des Projekts auf neuen Welle-Outcome aktualisieren. - Geschlossene Items entfernen, neue offene Items eintragen. - Drift zwischen Projekt-STATUS und Root-State erkennen + fixen. ### 7. git status pruefen ``` cd && git status ``` - Bei Architekt-Welle: Commit mit klarer Message `welle: — ` (siehe Memory `feedback_secrets_in_doku.md` fuer Secret-Pre-Commit-Scan). - Bei Worker-Welle: Worker hat selbst committet, nur verifizieren. - Niemals `git add -A` blind — Untracked-Files einzeln pruefen (Secret-Risiko). - Push nur wenn explizit Teil der Welle. ### 8. Kurz-Bericht im Chat Format (max 9 Zeilen): ``` Cleanup abgeschlossen — Welle / Projekt - STATUS.md: ueberschrieben () - Audit-Files weg: - Tot-Files archiviert: -> _archive// - Memory: updated, stale-markiert - Runbook-Run-Logs gepflegt: Runbooks () - Schriftbuero: Inbox-Files archiviert - MASTER-STATE/OPEN-ITEMS: - Git: - Naechster Schritt: ``` ## Boundaries - Keine Cross-Projekt-Cleanup ohne expliziten Auftrag. Du raeumst NUR das Projekt der gerade abgeschlossenen Welle. - L6-Isolation: Niemals Cleanup quer zwischen Marken (BrandFive-Files nicht aus BrandOne aufraeumen). - Kein Hard-Delete ohne git-Backup (alles ist versioniert, aber im Zweifel `_archive/` statt `rm`). - Keine Notion-Kommentare als Teil von Cleanup — siehe Memory `feedback_notion_workflow.md`. ## Anti-Patterns - "Ich packe alles in HANDOFF.md" — verboten. - "Ich lasse die `.audit.md` drin, falls noch jemand was sehen will" — nein, alles relevante muss in STATUS.md stehen. - "Ich committe nicht, mache nur Doku" — falsch, Cleanup gehoert committet wenn es eine Architekt-Welle ist. - "Memory updaten ist optional" — bei Drift Pflicht, sonst halluziniert der naechste Agent. - "Run-Logs der genutzten Runbooks sind nicht mein Job" — doch, Cleanup ist der Backstop. Ein Runbook ohne gepflegtes Run-Log gilt im Heartbeat als Drift. ## Verifizieren - [ ] `Glob /**/*.audit.md` -> 0 Files - [ ] `STATUS.md` Datum = heute (oder Welle-Datum) - [ ] `_archive/-/` existiert mit verschobenen Tot-Files - [ ] `MEMORY.md` Count = Filesystem-Count - [ ] genutzte Runbooks haben Run-Log-Zeile fuer diese Welle (+ ggf. Learnings/Fix) - [ ] `git status` sauber (oder erwarteter Commit gepusht) - [ ] Kurz-Bericht im Chat gepostet