# Anfrage → Aufgabe

**Lernpaket 1 · Deutsch · 6. September 2026**

Eine eingegangene Anfrage soll genau eine bearbeitbare Aufgabe ergeben. Dieses Paket zeigt den kleinen Kern dafür: Text normalisieren, Pflichtfelder prüfen, wiederholte IDs erkennen und jeden Eingabedatensatz mit einem sichtbaren Ergebnis versehen. Es versendet keine Nachrichten und schreibt nichts in ein Kunden- oder Ticketsystem.

**Was tatsächlich geprüft ist:** Der n8n-Workflow wurde lokal mit n8n 2.37.10 in einem isolierten Container importiert und ausgeführt. Das Ergebnis wurde Feld für Feld mit der vorab festgelegten Sollausgabe verglichen. Der Make-Blueprint wurde von Hand aus nativen Modulen erstellt und lokal auf Struktur und identische Eingabedaten geprüft. Sein Import und seine Ausführung in Make sind noch nicht bestätigt. `test-report.json` nennt Nachweise und Grenzen. Eine lokale JavaScript-Prüfung ist kein Make-Test.

## 1. Was du erhältst

| Datei | Verwendung |
| --- | --- |
| `n8n-workflow.json` | In einen neuen n8n-Workflow importieren; manuell ausführen |
| `make-blueprint.json` | In ein neues Make-Szenario importieren; Cloud-Abnahme noch offen |
| `fixtures.json` | Sieben rein synthetische Anfragen, in fester Reihenfolge |
| `fixtures.csv` | Dieselben Anfragen als Tabelle für den manuellen Vergleich |
| `expected-results.json` | Vorab festgelegte vollständige Sollausgabe |
| `expected-tasks.csv`, `expected-errors.csv` | Soll-Aufgaben bzw. Soll-Fehler und Dubletten als Tabellen |
| `n8n-classify.js` | Lesbare Quelle des n8n-Prüfknotens; identisch zum Export |
| `verify.mjs` | Wiederholbare lokale Prüfungen; optional echte n8n-Ausführung |
| `CLOUDTEST.md` | Import, Ausführung, Gegenproben und Erfolgskriterien je Anbieter |
| `METHODIK.md` | Testvertrag, Grenzen und Pflege |
| `test-report.json` | Tatsächlicher Prüfstand mit Versionen und Hashes |
| `manifest.json` | Dateiliste mit Größen und SHA-256-Prüfsummen |
| `LICENSE.txt` | MIT-Lizenz für dieses eigene Lernpaket |

Die `expected-*`-Dateien sind **Sollwerte**, keine nachträglich erfundenen Messungen. Du brauchst weder eine Partnerregistrierung noch einen Affiliate-Link, um das Paket zu nutzen. Es enthält keine Anbieterkennungen, Zugangsdaten oder Partnerlinks.

## 2. Der feste Testvertrag

Der unterstützte gemeinsame Testfall ist ein Stapel von **1 bis 100 Anfragen mit Textfeldern**. Die mitgelieferte Datei enthält sieben. Die Reihenfolge entscheidet: Die erste gültige Anfrage mit einer ID erzeugt eine Aufgabe; weitere gültige Anfragen mit derselben ID ergeben `duplicate_request_id`, auch wenn sich deren Text unterscheidet. Fehlerhafte Anfragen reservieren keine ID. Die ID ist groß-/kleinschreibungssensitiv. Eine E-Mail-Adresse allein ist kein Dublettenschlüssel.

| Feld | Regel |
| --- | --- |
| `request_id` | Pflicht; außenliegende Leerzeichen entfernen; 1–64 Zeichen aus A–Z, a–z, 0–9, `_`, `-` |
| `subject` | Pflicht; trimmen; 1–120 Zeichen |
| `email` | Pflicht; trimmen, kleinschreiben; maximal 254 Zeichen; einfache Syntax mit einem `@` und einem Punkt im Domainteil |
| `detail` | Optionaler Text, höchstens 2.000 Zeichen; unverändert übernehmen |

Die E-Mail-Regel prüft nur die **einfache Syntax**. Sie prüft weder Erreichbarkeit noch Zustellbarkeit und ersetzt keine vollständige E-Mail-Validierung. Alle Beispieladressen liegen unter `example.invalid`; Nachrichten werden ohnehin nie gesendet.

Die erste verletzte Regel in Tabellenreihenfolge bestimmt den Fehlercode. Fehlerhafte Textwerte erhalten ein sichtbares Fehlerergebnis. Strukturell falsche Daten (z. B. Zahl statt Text) sind außerhalb des gemeinsamen Testvertrags: n8n stoppt dann ausdrücklich; Make kann Typen automatisch umwandeln. Make ist deshalb ohne zusätzliche, separat abgenommene Eingangsschema-Prüfung kein gleichwertiger Validator für beliebige fremde JSON-Daten.

## 3. Was bei den sieben Anfragen herauskommen soll

| Zeile | ID | Ergebnis | Warum? |
| --- | --- | --- | --- |
| 1 | A-001 | Aufgabe TASK-A-001 | Gültig; Leerzeichen und E-Mail-Schreibweise normalisiert |
| 2 | A-002 | Aufgabe TASK-A-002 | Zweite gültige Anfrage |
| 3 | A-001 | Dublette | Bereits eine gültige Anfrage mit derselben ID verarbeitet |
| 4 | A-003 | `missing_email` | Leeres Pflichtfeld |
| 5 | A-004 | `invalid_email` | Kein einfach gültiges E-Mail-Muster |
| 6 | A-005 | `missing_subject` | Betreff besteht nur aus Leerzeichen |
| 7 | A-006 | Aufgabe TASK-A-006 | Mehrzeiliger Text bleibt Aufgabeninhalt und löst keine Aktion aus |

Erwartet sind **7 Ergebnisdatensätze: 3 Aufgaben, 1 Dublette und 3 Fehler**. `source_index` verweist auf die ursprüngliche Zeile. Fehler und Dubletten haben absichtlich keine `task_id` und keine übernommenen Kontakt-/Inhaltsfelder; die Quelldatei bleibt für die Korrektur erhalten. Es geht keine Anfrage still verloren.

## 4. Schnellstart in n8n

1. Neues, leeres Testprojekt bzw. neuen Workflow öffnen. `n8n-workflow.json` über **Import from File** importieren. Nicht in einen bestehenden produktiven Ablauf importieren.
2. Den Knoten **Synthetische Anfragen** öffnen: Die sieben Eingaben sind bereits enthalten. Alle Knoten sind Standardknoten; es werden keine Credentials gebraucht.
3. Workflow manuell ausführen. **Aufgaben und Fehlerprotokoll** öffnen und die JSON-Ausgabe ansehen.
4. `counts` muss `{input: 7, tasks: 3, duplicates: 1, errors: 3}` enthalten. `records` mit `expected-results.json` vergleichen. JSON-Ausgabe herunterladen und außerhalb kurzlebiger Ausführungshistorie sichern.
5. Workflow erneut ausführen. Dasselbe Ergebnis ist richtig: Der Dublettenspeicher gilt **nur innerhalb eines Stapels**. Der zweite Lauf wird nicht unterdrückt.

Die vollständigen Gegenproben stehen in `CLOUDTEST.md`. Der Export enthält eine lesbare, feste Demo-Workflow-ID für den isolierten CLI-Test; sie ist keine ID eines produktiven Kontos. Bei CLI-Import in eine bestehende Instanz könnte eine vorhandene gleiche Workflow-ID überschrieben werden. Der mitgelieferte CLI-Weg verwendet deshalb immer eine neue, anschließend entfernte Instanz.

## 5. Make vorbereiten

In Make ein **neues Szenario** anlegen und `make-blueprint.json` über **… → Import blueprint** importieren. Noch keine Zeitplanung aktivieren. Erwartet wird eine verbundene Folge von neun Modulen: Variable leeren → JSON parsen → Iterator → bisherige IDs lesen → normalisieren → validieren → Ergebnis klassifizieren → gültige ID merken → Ergebnisliste aggregieren.

Die JSON-Datenstruktur bleibt absichtlich ohne kontogebundene Kennung. Wenn Make sie beim Import nicht erkennt, im Modul **Synthetische Anfragen** eine Datenstruktur mit dem Generator aus `fixtures.json` erzeugen; die vier Anfragefelder als Text festlegen. Danach die Zuordnung `requests[]` zum Iterator kontrollieren. Die genaue Abnahmefolge und der Umgang mit Importabweichungen stehen in `CLOUDTEST.md`.

Der Ablauf nutzt native Module, keine Drittanbieter-App und kein kostenpflichtiges Code-Modul. Welcher aktuelle Kontoplan und welches Kontingent für einen konkreten Cloudtest verfügbar sind, ist nicht belegt. Keine Upgrades für einen stillschweigenden Test abschließen.

## 6. Lokal reproduzieren

Voraussetzung für reine Datei-/JavaScript-Prüfungen: Node.js 22. Die Befehle im entpackten Paketordner ausführen:

```bash
node verify.mjs
node verify.mjs --verify-manifest
```

Das erste Kommando prüft den n8n-Code mit einem kleinen lokalen Eingabeobjekt und die Make-Dateistruktur. Das ist schnell, startet aber **keine** Automatisierungsplattform.

Für eine reale n8n-Ausführung zusätzlich Docker starten, dann:

```bash
docker pull docker.n8n.io/n8nio/n8n@sha256:307d6065be25619aa24cfc63a7c2f04ca56d084a08c05c8e9f189a89f353b1ec
node verify.mjs --n8n
```

Das Image ist über seinen Inhaltsdigest festgelegt. Der Prüfer erzeugt einen neuen Container, bindet nur diesen Paketordner lesend ein, veröffentlicht keine Ports und sperrt dessen Netzwerk mit `--network none`. Er importiert den Workflow, führt ihn aus und vergleicht die tatsächliche JSON-Ausgabe mit der Sollausgabe. Der Container wird entfernt; das heruntergeladene Image bleibt lokal für weitere Prüfungen. Keine vorhandene n8n-Instanz wird angesprochen. Der Test hat eine Zeitgrenze von drei Minuten. Der Image-Download braucht Netzwerkzugang und lokalen Speicher.

## 7. Für echte Arbeit fehlt bewusst noch ein Schritt

Die „Aufgabe“ ist hier ein exportierbarer Datensatz, kein angelegtes Ticket in Trello, Asana oder einem CRM. Das Fehlerprotokoll steht im Ausführungsergebnis, nicht in einer dauerhaft eingerichteten Fehlerdatenbank. Es gibt keinen Webhook, keinen Live-Formulareingang, keinen Zeitplan und keinen Versand.

Für einen produktiven Anschluss zuerst das Zielsystem bestimmen und dessen Datenverarbeitung prüfen. Danach braucht es einen dauerhaften, eindeutig geschützten Idempotenzschlüssel, einen bestätigten Schreibvorgang im Ziel, eine Fehlerablage mit zuständiger Person und Tests für parallele Zustellungen, Timeouts und Wiederholung nach Teilfehlern. Ein bloßes Anhängen eines „Create task“-Moduls macht diese Zusagen nicht wahr.

Bei wenigen Anfragen kann die manuelle Alternative reichen: `fixtures.csv` als Muster verwenden, Pflichtfelder prüfen, die ID in einer bestehenden Tabelle suchen, genau eine Aufgabe anlegen und Fehler in einer zweiten Tabelle sichtbar führen. Auch dabei gilt: erst nach erfolgreicher Anlage als erledigt markieren.