1
0
Files
pdf-umbenenner/WORKFLOW.md

124 lines
3.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# WORKFLOW KI-gesteuerte AP-Implementierung
Dieses Dokument beschreibt verbindlich, wie Claude Code Arbeitspakete eines Meilensteins
sequenziell implementiert. Es ist ein technischer Arbeitsrahmen, kein fachliches Dokument.
---
## Eingabe
- Eine Arbeitspakete-MD-Datei des aktiven Meilensteins (z. B. `M6 - Arbeitspakete.md`)
- `CLAUDE.md` im Projektroot (Architektur, Konventionen, Nicht-Ziele)
- alle verbindlichen Spezifikationsdokumente im Projektroot
---
## Grundregeln
- **Immer zuerst lesen, dann implementieren.** Vor jeder Änderung die relevanten
Typen, Ports und Implementierungen im echten Workspace suchen und öffnen.
- **Keine Annahmen über Dateipfade.** Typen und Klassen werden per Suche nach
Typname gefunden, nicht über vermutete Pfade.
- **Kein Git.** Keine git-Befehle, keine Commits, kein Staging, kein Revert.
- **Nur Dateioperationen.**
---
## Sequenzielle AP-Bearbeitung
Arbeitspakete werden in der Reihenfolge des Dokuments abgearbeitet.
Ein AP ist abgeschlossen, wenn:
1. der Scope vollständig umgesetzt ist,
2. der Build vom Parent-Root fehlerfrei durchläuft,
3. das vorgeschriebene Output-Format ausgegeben wurde.
Erst dann beginnt das nächste AP.
---
## Build-Validierung
Nach jedem AP wird **zwingend** ein Build aus dem Parent-Root ausgeführt:
```
.\mvnw.cmd clean verify -pl pdf-umbenenner-domain,pdf-umbenenner-application,pdf-umbenenner-adapter-out,pdf-umbenenner-adapter-in-cli,pdf-umbenenner-bootstrap --also-make
```
Schlägt der Build fehl:
- Fehler analysieren
- im selben AP beheben
- Build erneut ausführen
- erst bei grünem Build weiter zum nächsten AP
---
## Pflicht-Output-Format nach jedem AP
```
## AP-XXX Abschluss
- Scope erfüllt: ja/nein
- Geänderte Dateien:
- <Dateipfad>
- ...
- Build-Kommando: .\mvnw.cmd clean verify ...
- Build-Status: ERFOLGREICH / FEHLGESCHLAGEN
- Offene Punkte: keine / <Beschreibung>
- Risiken: keine / <Beschreibung>
```
---
## Scope-Kontrolle
Pro AP gilt verbindlich:
- **Nur** die im AP beschriebenen Änderungen umsetzen.
- **Kein Vorgriff** auf spätere APs oder spätere Meilensteine.
- **Kein Refactoring** außerhalb des AP-Scopes.
- **Keine kosmetischen Cleanups**, die nicht durch den AP-Scope gedeckt sind.
- **Keine Import-Bereinigungen**, die nicht durch konkrete eigene Änderungen erzwungen werden.
---
## Naming-Regel (verbindlich für alle APs)
In geänderten Dateien Code, Kommentare, JavaDoc dürfen **keine** Meilenstein-
oder Arbeitspaket-Bezeichner erscheinen:
- Verboten: `M1`, `M2`, `M3`, `M4`, `M5`, `M6`, `M7`, `M8`
- Verboten: `AP-001`, `AP-002`, … `AP-00x`
Stattdessen werden **zeitlose technische Bezeichnungen** verwendet.
Wenn bestehende Kommentare solche Bezeichner enthalten und durch den AP-Scope
berührt werden, sind sie zu ersetzen.
---
## Architekturregeln (Kurzfassung vollständig in CLAUDE.md)
- Strenge hexagonale Architektur: Abhängigkeitsrichtung zeigt immer nach innen.
- Domain und Application: keine Infrastruktur, kein `Path`/`File`, kein JDBC, kein HTTP.
- Adapter-Out: alle Infrastrukturdetails (Dateisystem, SQLite, HTTP, PDFBox).
- Adapter dürfen nicht direkt voneinander abhängen.
- Ports sind die einzigen Querschnittspunkte.
---
## Startkommando für einen vollständigen Meilenstein
```
Lies CLAUDE.md und M6 - Arbeitspakete.md vollständig.
Implementiere danach alle Arbeitspakete sequenziell gemäß WORKFLOW.md.
Beginne mit AP-001.
```
## Startkommando für ein einzelnes AP
```
Lies CLAUDE.md und M6 - Arbeitspakete.md vollständig.
AP-001 bis AP-00X sind bereits abgeschlossen und bilden die Baseline.
Implementiere ausschließlich AP-00Y gemäß WORKFLOW.md.
```