# Bulk Workspace

Der dedizierte Bulk-Modus stellt neben `POST /v1/bulk/declarations` wieder eine browserbasierte Arbeitsoberfläche bereit.

## Routen

```text
GET  /
GET  /bulk
POST /v1/bulk/declarations
```

Die Oberfläche ist für interne Publisher-, Agentur- und Enterprise-Workflows gedacht. Sie ersetzt die API nicht, sondern verwendet denselben Endpunkt.

## Visueller Workflow

Im Standardworkflow werden Inhalte zeilenweise angegeben:

```text
article-1001 | https://example.org/articles/1001
article-1002 | https://example.org/articles/1002
```

Alternativ genügt eine URL pro Zeile. IDs werden dann automatisch erzeugt.

Ein gemeinsames Artikelprofil kann u. a. festlegen:

- Text, Titelbild, weitere Bilder, Recherche, Übersetzung und Code;
- KI-Anteil und menschliche Prüfung pro Bereich;
- Nachweisgrundlage;
- relevante Artikel-50-Angaben;
- redaktionelle Verantwortung.

## Erweiterter JSON-Modus

Heterogene Daten können als regulärer Bulk-Request eingefügt werden. Dadurch können einzelne Artikel vollständig unterschiedliche Parameter erhalten.

## API-Key

Ist `BULK_REQUIRE_API_KEY=true`, fragt die Oberfläche den Schlüssel lokal ab. Er wird nur im `sessionStorage` des aktuellen Browser-Tabs gehalten und als `Authorization: Bearer ...` an den Bulk-Endpunkt gesendet.

Der Schlüssel wird nicht serverseitig in HTML eingebettet und nicht in Exportdateien übernommen.

## Ergebnisse

Die Oberfläche zeigt pro Datensatz:

- ID;
- Validierungsstatus;
- technische Artikel-50-Einordnung;
- Link zur Erklärung;
- Link zum JSON-LD-Manifest;
- Badge-Link;
- Validierungsfehler.

Das Gesamtergebnis kann als JSON oder CSV exportiert werden.

## Sicherheitsmodell

Der dedizierte Container behält die 2.0-Sicherheitsdefaults:

```text
SERVICE_MODE=bulk
REQUIRE_LICENSE=true
BULK_REQUIRE_API_KEY=true
API_ALLOWED_ORIGIN=
```

Die Oberfläche ist deshalb kein Ersatz für Netzwerksegmentierung. Für externe Veröffentlichung sollte weiterhin ein TLS-Reverse-Proxy bzw. API-Gateway mit zusätzlicher Authentifizierung eingesetzt werden.