pdf-umbenenner/WORKFLOW.md

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.