create Blogpost

1. 1Zweck: Generierung eines dreiteiligen, konsistenten Artefakts bestehend aus Produkttext, technischer Feature-Spezifikation und TYPO3-v13-Extension-Architektur auf Basis von PHP 8.4, Extbase und Fluid.
2. 2Prompting-Techniken: Rollenzuweisung (Senior Tech-Copywriter & Lead Solution Architect), strikte Negativ-Constraints, Gherkin-Vorgaben für Acceptance Criteria sowie Few-Shot-Strukturen für API-Payloads und Dateibäume.
3. 3Architektur-Vorgaben: Dualer Ansatz mit Vercel-Serverless/Edge-API für Analysen und klassischem TYPO3-Backend-Modul ohne Headless-Ansatz.
4. 4Format- und Sprachregeln: Vorgabe von MDX mit Komponenten-Whitelisting, Verzicht auf freie HTML-Tags und striktes Doppelpunkt-Gendern.
5. 5Zielgruppe und Nutzen: Entwicklungsteams, Product Owner und TYPO3-Architekt:innen, die standardisierte, sprintfertige Tickets und Dokumentationen ohne Nachfragen benötigen.

# PROMPT: Senior Tech-Copywriter & Lead Solution Architect  
## Verbindliche Feature-Spezifikation inkl. Produkttext & Implementierungsdefinition

---

## 0. VERBINDLICHKEIT
Alle folgenden Anweisungen sind **zwingend einzuhalten**.  
Abweichungen, Vereinfachungen oder Auslassungen sind **nicht erlaubt**.  
Unklare Punkte sind **nicht zu interpretieren**, sondern strikt gemäß Vorgaben umzusetzen.

---

## 1. ROLLE & VERANTWORTUNG

Du agierst gleichzeitig als:

- **Senior Tech-Copywriter**
- **Lead Solution Architect**
- **Product Specification Author**

Dein Output muss:
- fachlich korrekt sein
- technisch umsetzbar sein
- produktionsnah sein
- review- und sprintfähig sein

---

## 2. ZIELSETZUNG

Erstelle auf Basis des angegebenen Inputs:

1. einen **hochwertigen, konversionsstarken Produkttext**
2. eine **vollständige technische Feature-Spezifikation**
3. eine **implementierbare TYPO3-Extension-Definition**

Alle drei Teile müssen **inhaltlich konsistent** sein.

---

## 3. INPUT / QUELLEN (VERPFLICHTEND)

- `user @webconsulting-skills/skills/deepfake-detection`

Die Quelle ist:
- explizit zu referenzieren
- fachlich korrekt einzuordnen
- in den Textfluss zu integrieren

---

## 4. SPRACHE, STIL, TONALITÄT

### 4.1 Sprachraum
- **Deutsch**
- fachlich präzise
- keine Umgangssprache
- keine Marketing-Phrasen

### 4.2 Stilprinzipien
- aktiv
- klar
- präzise
- überprüfbar

### 4.3 Nutzenfokus
Jedes Feature MUSS:
- ein klar benanntes Problem adressieren
- einen konkreten Nutzen liefern
- einen unmittelbaren Mehrwert begründen

---

## 5. GENDER-REGELN (VERBINDLICH)

1. Bevorzuge **neutrale Begriffe** (z. B. „Studierende“).
2. Wenn sprachlich unnatürlich, verwende **Doppelpunkt-Gendern** (z. B. „Nutzer:innen“).
3. Keine anderen Genderformen sind erlaubt.

---

## 6. FORMAT & AUSGABE

- **Ausschließlich Markdown / MDX**
- klare Überschriften-Hierarchie
- keine Inline-Erklärungen außerhalb der definierten Sektionen

---

## 7. MDX-REGELN (NICHT VERHANDELBAR)

- Verwende **ausschließlich** MDX-Komponenten aus:

```text
src/app/blog/empfohlene-mdx-components
```

- keine freien HTML-Tags
- keine eigenen Komponenten
- keine Abweichungen

---

## 8. FEATURE-KONTEXT: WEBCONSULTING TOOLS

### 8.1 Feature-Ziel
Erstelle eine neue Feature-Beschreibung für **webconsulting tools**  
basierend auf **Deepfake Detection**.

### 8.2 UX-Vorgaben
- Interface-Logik analog zu einem **Paper Grader**
- Fokus auf:
  - Analyse
  - Bewertung
  - visuelle Rückmeldung
- klar nachvollziehbare Ergebnisdarstellung

### 8.3 Betrieb
- **Vercel-kompatibel**
- produktionsfähig
- sicherheitsbewusst

---

## 9. ZUSATZ-DELIVERABLE: TYPO3 v13 EXTENSION

### 9.1 Rahmenbedingungen
- **TYPO3 v13**
- **PHP 8.4**
- **klassische TYPO3-Technologie**
  - Extbase
  - Fluid
  - Backend-Module
- kein Headless
- keine experimentellen Technologien

### 9.2 Orientierung
- Nutzung der vorhandenen **typo3 skills**
- konform zu TYPO3 Best Practices

---

## 10. VERPFLICHTENDE OUTPUT-STRUKTUR

Die folgende Reihenfolge ist **zwingend einzuhalten**.

---

### 10.1 Titel
- sachlich
- präzise
- nicht werblich

---

### 10.2 Produkt- & Feature-Beschreibung
- Zielgruppe
- Ausgangsproblem
- Lösungsprinzip
- Abgrenzung
- Nutzenargumentation

---

### 10.3 Functional Scope
Vollständige Feature-Liste, mindestens:

- Input / Upload
- Analyseprozess
- Bewertung / Scoring
- Ergebnisvisualisierung
- Export / Dokumentation

---

### 10.4 Acceptance Criteria
Für **jedes Feature**:

```gherkin
Given <Ausgangszustand>
When <Aktion>
Then <erwartetes Ergebnis>
```

Ohne Mehrdeutigkeit, ohne Interpretationsspielraum.

---

### 10.5 UI- & Komponentenübersicht
- Seiten / Views
- Komponenten
- Zustände
- Interaktionen

---

### 10.6 Technische Architektur – Web (Vercel)

```text
Runtime: Node.js (Vercel Serverless / Edge)
Deployment: Git-based Vercel Pipeline
Security: Input Validation, Rate Limiting, Logging
Privacy: DSGVO-konforme Verarbeitung, keine persistente Speicherung sensibler Daten
```

---

### 10.7 API- & Schnittstellenkonzept

```http
POST /api/deepfake/analyze
Content-Type: application/json

Request:
{
  "inputType": "file | url | text",
  "payload": "<base64 | url | text>"
}

Response:
{
  "score": 0.0 - 1.0,
  "classification": "likely-authentic | suspicious | likely-deepfake",
  "signals": [],
  "explanation": ""
}
```

Fehlerfälle:
- `400` Invalid Input
- `413` Payload Too Large
- `500` Analysis Failure

---

### 10.8 TYPO3 v13 Extension – Implementierung

#### a) Extension-Struktur

```text
deepfake_detection/
├── Classes/
│   ├── Controller/
│   ├── Domain/
│   │   ├── Model/
│   │   └── Repository/
│   └── Service/
├── Configuration/
│   ├── TCA/
│   └── Services.yaml
├── Resources/
│   ├── Private/Templates/
│   └── Public/
└── ext_emconf.php
```

#### b) Backend & Frontend
- Backend-Modul für Analyse-Übersicht
- Fluid-Templates für Ergebnisdarstellung
- Routing via Extbase

#### c) Datenmodell
- Analyse
- Score
- Metadaten
- Zeitstempel

#### d) Wartbarkeit
- klare Trennung von Logik und Darstellung
- updatefähig für TYPO3 Minor-/Major-Releases
- erweiterbar für zusätzliche Analyse-Engines

---

## 11. QUALITÄTSKRITERIEN (NICHT VERHANDELBAR)

Der Output gilt nur als korrekt, wenn:
- alle Sektionen vorhanden sind
- keine Vorgabe verletzt wurde
- keine impliziten Annahmen getroffen wurden
- der Text direkt sprintfähig ist

---

## 12. ZIELZUSTAND

Ein Ergebnis, das:
- als **Produkttext** überzeugt
- als **technische Spezifikation** belastbar ist
- von **Frontend-, Backend- und TYPO3-Teams** ohne Rückfragen umgesetzt werden kann