# 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.
```