/spec — Feature-Spezifikation erstellen

Erstelle eine strukturierte Feature-Spezifikation für das RESA Plugin.

Vorgehen

1. Kontext sammeln:

   • Lies relevante Planungsdocs aus docs/planning/ (insbesondere RESA-Technischer-Stack.md, RESA-Plugin-Architektur.md)
   • Prüfe ob bereits verwandte Specs in docs/specs/ existieren
   • Prüfe CLAUDE.md für Architektur-Vorgaben

2. Spec-Datei erstellen:

   • Pfad: docs/specs/SPEC-{feature-name-kebab-case}.md
   • Verwende das Template unten

3. Bei Unklarheiten nachfragen:

   • Wenn das Feature unklar ist, frage beim User nach
   • Lieber einmal mehr nachfragen als falsche Annahmen treffen

Spec-Template

markdown
1# SPEC: {Feature-Titel}
2
3**Status:** Entwurf
4**Erstellt:** {Datum}
5**Betrifft:** {Kurzbeschreibung welche Bereiche betroffen sind}
6
7## Zusammenfassung
8
9{2-3 Sätze was dieses Feature macht und warum es gebraucht wird}
10
11## Betroffene Dateien
12
13### Neue Dateien
14- `includes/...` — {Beschreibung}
15- `src/...` — {Beschreibung}
16
17### Geänderte Dateien
18- `includes/...` — {Was ändert sich}
19- `src/...` — {Was ändert sich}
20
21## API-Änderungen
22
23### Neue Endpoints
24| Methode | Route | Beschreibung | Auth |
25|---|---|---|---|
26| GET | `/resa/v1/...` | ... | Admin |
27
28### Geänderte Endpoints
29{Falls zutreffend}
30
31## Datenbank-Änderungen
32
33### Neue Tabellen
34{Falls zutreffend — Schema mit Spalten, Typen, Indizes}
35
36### Geänderte Tabellen
37{Falls zutreffend}
38
39### Neue Optionen
40{wp_options Einträge falls zutreffend}
41
42## Modul-Klassifizierung
43
44| Eigenschaft | Wert |
45|---|---|
46| **Typ** | [Kern-Feature / Lead Tool Modul / Integration Add-on] |
47| **Modul-Flag** | [free / pro / paid / nicht zutreffend] |
48| **Modul-Slug** | [z.B. rent-calculator / nicht zutreffend] |
49
50## Free vs. Premium
51
52| Feature-Aspekt | Free | Pro | Add-on |
53|---|---|---|---|
54| ... | ... | ... | ... |
55
56## UI/UX
57
58### Admin-Seite
59{Beschreibung der Admin-UI — Seitenstruktur, Komponenten, Interaktionen}
60
61### Frontend-Widget
62{Falls zutreffend — Beschreibung der Widget-Änderungen}
63
64### Mockup/Wireframe
65{ASCII-Wireframe oder Beschreibung des Layouts}
66
67## Implementierungsdetails
68
69### Modul-Struktur (falls Lead Tool Modul)
70
71Verzeichnis: `modules/{slug}/`
72- `module.php` — Bootstrap, registriert sich bei ModuleRegistry
73- `{Name}Module.php` — ModuleInterface Implementierung
74- `{Name}Service.php` — Berechnungslogik (CalculatorInterface)
75- `src/steps/` — React Step-Komponenten
76- `src/result/` — Ergebnis-Komponente
77- `src/validation/schema.ts` — Zod-Schema
78- `tests/` — Modul-spezifische Tests
79
80### PHP-Klassen
81{Klassenstruktur, Methoden-Signaturen, Verantwortlichkeiten}
82
83### React-Komponenten
84{Komponentenbaum, Props, State-Management}
85Icons: Nur semantische Namen aus Icon Registry verwenden (`<ResaIcon name="..." />`)
86
87### Validierung
88{Zod-Schemas, PHP-Validation-Regeln}
89
90## Akzeptanzkriterien
91
92- [ ] {Kriterium 1}
93- [ ] {Kriterium 2}
94- [ ] ...
95
96## Security-Überlegungen
97
98{Sanitization, Escaping, Nonces, Capabilities die beachtet werden müssen}
99
100## Testplan
101
102### Unit Tests
103- {Test 1}
104- {Test 2}
105
106### Integration Tests
107- {Test 1}
108
109## Offene Fragen
110
111- {Frage 1}
112- {Frage 2}
113
114## Abhängigkeiten
115
116- {Andere Features/Specs die vorher implementiert sein müssen}

Hinweise

• Sprache: Deutsch (Dokumentation und Code-Kommentare)
• Berücksichtige IMMER Free vs. Premium Limits
• Berücksichtige IMMER CSS-Isolation (resa- Prefix) für Frontend-Widget
• Berücksichtige IMMER i18n (alle User-facing Strings mit gettext)
• Berücksichtige IMMER Security (Sanitization, Escaping, Nonces, Capabilities)
• Vermeide Over-Engineering — nur das Nötigste spezifizieren