Befund: v1 hatte keine KI-Deklarationsfelder — Submit lief seit der
KI-Kennzeichnungspflicht (09.07.) immer auf 422 und haette alle
Legacy-API-Kunden blockiert (Suite uebersah es: Factory deklariert).
- v1-Submit verlangt ai_text_declaration; der Call gilt dokumentiert
als verbindliche Bestaetigung (Art. 50 KI-VO) und schliesst die
Archiv-Kenntnisnahme (AGB par. 13) ein
- Bild-Upload verlangt ai_declaration (original/ai_generated/ai_edited)
- Legacy-/service-Aliasse defaulten auf none/original — das
API-Kunden-Mailing (R6.4) weist auf die Erklaerungswirkung hin
- OpenAPI v1.yml + lang-Hinweis aktualisiert; Tests erweitert
(Submit/Image/LegacyCompatibility)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bestehende Kunden-Integrationen der Altportale laufen nach dem Relaunch
weiter, ohne dass Kunden etwas umstellen muessen:
1. legacy:import-api-keys uebernimmt die api_keys aus den Legacy-DBs
(sf_guard_user_profile) als Sanctum-Tokens mit identischem Secret
(Sanctum loest Tokens ohne id|-Praefix per sha256-Hash auf) — nur
fuer berechtigte Nutzer (aktiver Zahlungsstatus/Bestandsschutz,
ApiAccessEligibilityService); idempotent, mit Dry-Run. Probe gegen
die lokalen Snapshots: 406 Keys wuerden uebernommen.
2. Die Auth-Middleware uebersetzt die alten Uebergabeformen (X-ApiKey-
Header, api_key-Parameter) fuer gueltige Keys in Bearer; unbekannte
Keys erhalten weiterhin 410 mit Migrationshinweis.
3. Die dokumentierten /service/...-Pfade der Alt-API sind als Aliasse
auf die v1-Controller gelegt (pressreleases inkl. Bilder, companies
lesend); nicht uebernommene Alt-Endpoints (Pressemappen/Kontakte
anlegen) antworten 410 mit Hinweis auf Kundenkonto und neue Doku.
API-Seite + OpenAPI entsprechend aktualisiert; Go-Live-Checkliste um den
Import-Schritt (nach dem Grandfathering) ergaenzt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
