name: spec description: "Feature-Spezifikation für RESA erstellen" user-invocable: true argument-hint: "[Feature-Name oder Beschreibung]"

/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

# SPEC: {Feature-Titel}

**Status:** Entwurf
**Erstellt:** {Datum}
**Betrifft:** {Kurzbeschreibung welche Bereiche betroffen sind}

## Zusammenfassung

{2-3 Sätze was dieses Feature macht und warum es gebraucht wird}

## Betroffene Dateien

### Neue Dateien
- `includes/...` — {Beschreibung}
- `src/...` — {Beschreibung}

### Geänderte Dateien
- `includes/...` — {Was ändert sich}
- `src/...` — {Was ändert sich}

## API-Änderungen

### Neue Endpoints
| Methode | Route | Beschreibung | Auth |
|---|---|---|---|
| GET | `/resa/v1/...` | ... | Admin |

### Geänderte Endpoints
{Falls zutreffend}

## Datenbank-Änderungen

### Neue Tabellen
{Falls zutreffend — Schema mit Spalten, Typen, Indizes}

### Geänderte Tabellen
{Falls zutreffend}

### Neue Optionen
{wp_options Einträge falls zutreffend}

## Modul-Klassifizierung

| Eigenschaft | Wert |
|---|---|
| **Typ** | [Kern-Feature / Lead Tool Modul / Integration Add-on] |
| **Modul-Flag** | [free / pro / paid / nicht zutreffend] |
| **Modul-Slug** | [z.B. rent-calculator / nicht zutreffend] |

## Free vs. Premium

| Feature-Aspekt | Free | Pro | Add-on |
|---|---|---|---|
| ... | ... | ... | ... |

## UI/UX

### Admin-Seite
{Beschreibung der Admin-UI — Seitenstruktur, Komponenten, Interaktionen}

### Frontend-Widget
{Falls zutreffend — Beschreibung der Widget-Änderungen}

### Mockup/Wireframe
{ASCII-Wireframe oder Beschreibung des Layouts}

## Implementierungsdetails

### Modul-Struktur (falls Lead Tool Modul)

Verzeichnis: `modules/{slug}/`
- `module.php` — Bootstrap, registriert sich bei ModuleRegistry
- `{Name}Module.php` — ModuleInterface Implementierung
- `{Name}Service.php` — Berechnungslogik (CalculatorInterface)
- `src/steps/` — React Step-Komponenten
- `src/result/` — Ergebnis-Komponente
- `src/validation/schema.ts` — Zod-Schema
- `tests/` — Modul-spezifische Tests

### PHP-Klassen
{Klassenstruktur, Methoden-Signaturen, Verantwortlichkeiten}

### React-Komponenten
{Komponentenbaum, Props, State-Management}
Icons: Nur semantische Namen aus Icon Registry verwenden (`<ResaIcon name="..." />`)

### Validierung
{Zod-Schemas, PHP-Validation-Regeln}

## Akzeptanzkriterien

- [ ] {Kriterium 1}
- [ ] {Kriterium 2}
- [ ] ...

## Security-Überlegungen

{Sanitization, Escaping, Nonces, Capabilities die beachtet werden müssen}

## Testplan

### Unit Tests
- {Test 1}
- {Test 2}

### Integration Tests
- {Test 1}

## Offene Fragen

- {Frage 1}
- {Frage 2}

## Abhängigkeiten

- {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