AIAT Kreativprojekte

Das Tool darf Personen als Eintrag erfassen, etwa Gründerinnen oder akademische Autorinnen. Damit greift die DSGVO-Informationspflicht, auch wenn die Daten aus öffentlichen Quellen stammen. Reine Validierung im Server-Code wurde verworfen, weil sie über direkten Datenbank-Zugriff umgangen werden kann, über Migrations, manuelle Importe oder ein DB-Studio. Stattdessen sitzt die Garantie eine Ebene tiefer als harte Sperre im Schema: ein Check-Constraint weist jeden Insert oder Update einer Person ohne gesetzten Consent-Zeitpunkt zurück. Dazu kommen zwei weitere Linien, ein signierter Opt-Out-Token pro Person für ein formloses Austragen und ein Pflicht-Template für die Informations-Mail, deren Versand protokolliert wird. Der Preis ist ein zweistufiges Onboarding für Personen, Insert, Mail, dann Consent setzen, das nicht in einem einzigen Worker-Durchlauf erledigt werden kann. Lehre: wenn eine Regel nicht verletzt werden darf, gehört sie an die Stelle, die kein Pfad umgeht, und das ist die Datenbank, nicht die Anwendung.

Für die Reihung der Akteure nach Prominenz wurde bewusst keine gelernte Rangordnung gebaut, sondern eine deterministische, vollständig offengelegte Formel: ein gewichteter Wert aus sechs Faktoren wie unabhängige Quellen, Aktualität und Reichweite, nächtlich neu berechnet und auf einer eigenen Methodik-Seite veröffentlicht. Die Gewichte leben in einer einzigen Konstante, die sowohl die Berechnung als auch die öffentliche Seite verwendet, dadurch kann die gezeigte Formel niemals von der gerechneten abweichen. Zwei Gründe trugen die Entscheidung. Erstens muss die Frage warum steht X über Y eine ehrliche Antwort haben, ein gelerntes Modell könnte das nicht erklären. Zweitens ist ein festes Regelwerk mit publizierten Gewichten kein KI-System im Sinne der EU-Regulierung, was den rechtlichen Rahmen vereinfacht. Eine wichtige Fairness-Eigenschaft: fehlt einem Akteur ein Signal strukturell, etwa wissenschaftliche Zitationen bei einem Mode-Startup, fällt dieser Faktor aus Zähler und Nenner heraus und wird nicht als Null gewertet. Lehre: ein nach außen sichtbares Ranking sollte erklärbar und reproduzierbar sein, sonst wird jede spätere Gewichtsänderung zu einem Vertrauensbruch.

Next.js 16 hat die öffentlichen Routen /entities, /e/[slug] und /v/[vertical] zur Build-Zeit vorgerendert. Da der Build-Container keine erreichbare Datenbank-Verbindung kennt, schlug der Build mit ECONNREFUSED fehl. Die Routen wurden auf export const dynamic = 'force-dynamic' umgestellt. Der Lesezugriff erfolgt nun pro Request auf dem laufenden Container, auf dem die Datenbank erreichbar ist. Bei der aktuellen Größe von unter 250 Einträgen ist der fehlende Edge-Cache kein Problem. ISR oder ein ephemeres Build-Postgres wurden geprüft und verworfen, da sie die Ursache nicht treffen.

Das Entrypoint-Skript hat Auto-Migration übersprungen, sobald drizzle-kit fehlte (der Next.js-Standalone-Build strippt Dev-Deps). Kein Deploy-Schritt wendete Migrationen an, jede Gelegenheit erforderte einen manuellen SSH-Tunnel plus drizzle-kit migrate vom Laptop. Das ist fünfmal in rund 14 Tagen aufgetreten. Die systemische Lösung war, den drizzle-orm-Migrator (statt drizzle-kit) direkt in das Entrypoint zu verdrahten, der in dieselbe Migrations-Ledger schreibt wie der Dev-Befehl. Container-Boot bricht jetzt hart ab, wenn eine Migration fehlschlägt. Lehre: ein Schritt, der nur im Build oder lokal läuft, ist kein Deploy-Schritt.

Die Klassifizierung der Akteure in Verticals nutzt drei Modell-Stufen unterschiedlicher Stärke und Kosten. Welches Modell ein Eintrag bekommt, entscheidet eine Konfidenz-Schwelle: ein sicherer Fall geht an das günstige Modell, ein unsicherer eskaliert an ein stärkeres. Personen-Einträge gehen über eine harte Regel immer an das stärkste Modell, weil ein falscher Tag auf einer Person sensible Rückschlüsse erlauben könnte. Die eigentliche Lehre lag im Kalibrieren der Schwellen. Ein erster Vergleichslauf gegen echte Daten lieferte unbrauchbare Signale, weil jedes Modell durch eine Eigenheit der Pipeline einen anderen, nicht überlappenden Teil der Einträge bekam, und der Quell-Pool zudem mit themenfremden Papieren verschmutzt war. Die Konsequenz war, die Schwellen nicht auf diesen verzerrten Daten zu tunen, sondern erst einen Sondermodus zu bauen, der mehrere Modelle dieselben Einträge bewerten lässt, und den Pool zu säubern. Erst auf diesem sauberen Satz aus rund 56 identischen Einträgen wurde nachjustiert. Lehre: wer Routing-Schwellen aus Messdaten ableitet, muss zuerst sicherstellen, dass die Messung dasselbe vergleicht, sonst kodiert man Rauschen in die Konfiguration.

Bei einem React-kontrollierten nativen <dialog> verhindert preventDefault() auf dem cancel-Event (Escape) das Schließen, danach feuert das close-Event nicht mehr. Wer die Sichtbarkeit über das open-Prop steuert und cancel preventDefaultet, muss den App-Callback im cancel-Handler selbst aufrufen und darf ihn nicht an onClose delegieren. Der ursprüngliche Fix war im Test grün, weil der Test cancel und close manuell beide feuerte, im echten Browser blieb Escape-zum-Schließen aber defekt. Lehre: ein grüner Test beweist den Test, nicht das Verhalten. Bei geteilten Seams am Aufrufer-Verhalten vorbeischauen.