aYOUne

Changelog

What changed — grouped by release, filterable by component and repository.

Other changes 4
Fix onboarding

Betreiber-Verdrahtung zurueckgenommen — die Annahme-Seite weist den Status ab

Der Katalog-Eintrag aus 7281a71 haette eine Mail verschickt, deren Verweis auf
eine Seite fuehrt, die ihn ABWEIST — also genau die Fehlerklasse, mit der der
CEO-Entscheid Weg (b) verworfen hat ("toter Verweis"), nur eine Ebene weiter.

Gemessen: `platform/auth/src/lib/inviteState.ts:32` fuehrt
`INVITE_OPEN_STATUS = 'invite-sent'` als "der EINZIGE Status, aus dem heraus
eine Einladung angenommen werden darf"; Zeile 70 weist jeden anderen als
`not-open` ab. Der Betreiber-Weg schreibt `user-created-by-admin`. W2 hat den
Fall gesehen und den Wert in einer eigenen Probe FESTGENAGELT
(`platform/auth/test/inviteState.test.ts:44`) — eine getroffene Entscheidung
der Nachbarstrecke, kein Versehen. Der Entscheid nahm an, W2 trage die Annahme;
er sagt selbst "die Annahme-Seite muss stehen, BEVOR diese Mail sinnvoll
verschickt wird".

Die VORARBEIT bleibt und ist geprueft: Empfaenger-Rueckfall auf `evt_data.email`
(der Betreiber-Weg kennt kein `inviteEmail`) und Handelnden-Rueckfall auf
`aYOUneInvites.sourceUser` (das Ereignis meldet keinen `sourceUserId`; ohne ihn
begaenne der Betreff mit einer Luecke — am Bestand belegt: 2 von 2 Betreiber-
Einladungen tragen `sourceUser`).

Zwei Proben lesen jetzt die BLOCKER-Zeilen im Quelltext: wird eine geaendert,
faellt die Probe und zwingt zur erneuten Messung, statt dass jemand den Eintrag
blind setzt. Umkehrproben: Vorarbeit ausgehebelt -> 2 rot, auth-Zeile geweitet
-> 1 rot. Volle Reihe 864/864.

Rest-Schnitt: queue/toPost/annahme-seite-nimmt-betreiber-einladung-nicht-an

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
New onboarding

Betreiber-Anlage verschickt die Einladungs-Mail (CEO-Entscheid Weg (a))

`user.created-by-admin` zeigt auf dieselbe Vorlage und Huelle wie die
Team-Einladung (`invite-user-to-tenant` / `forgotpass`) — beide fuehren eine
Person OHNE Passwort ueber einen Token zum Passwort-Setzen.

Der Katalog-Eintrag allein haette NICHT getragen: das Ereignis meldet dieselben
Daten unter teilweise anderen Namen (`email` statt `inviteEmail`) und laesst den
Handelnden ganz aus (kein `sourceUserId`). Ohne Rueckfall haette der Betreff
mit einer Luecke begonnen. Der Handelnde wird deshalb vom Einladungs-Datensatz
gelesen (`aYOUneInvites.sourceUser`) — nur dann, wenn das Ereignis ihn nicht
mitschickt.

Die bestehende Negativ-Kontrolle benutzte ausgerechnet `created-by-admin` als
"fremdes Ereignis" und waere durch die Verdrahtung gebrochen — sie nennt jetzt
`password-changed`.

Umkehrproben (je einzeln gefahren): Katalog-Eintrag entfernt -> 13 rot,
Handelnden-Rueckfall entfernt -> 1 rot, `data.email` entfernt -> 1 rot.
Volle Reihe 871/871.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
New onboarding

user.invite-sent wird zu einer echten Einladungs-Mail

Der Einladungs-Weg endete nach dem aYOUneInvites-Datensatz: die Vorlage
onboarding/invite-user-to-tenant liegt seit Monaten global in mails, aber eine
Suche nach ihrem Namen ueber die ganze Flotte fand NUR den Seed — kein
Verbraucher. Die eingeladene Person erfuhr nie von ihrer Einladung.

dispatchOnboardingMail haengt als fuenfter Zweig in defaultTriggers, ist also
eine Plattform-Regel, die ein Mandant nicht loeschen kann (gleiche Begruendung
wie bei den drei Geschwistern). Versand ueber den consumer-losen
sendSecurityEmail-Weg, weil eine eingeladene Person noch keinen Consumers-
Datensatz hat. Adresse auf PASSWORD_RESET_FRONTEND_URL mit Marken-Segment,
nicht auf authHost — das ist die API, nicht die Oberflaeche.

18 Proben inkl. fuenf Negativ-Kontrollen; beide Flip-Proben beissen
(Vorlagen-Name 1 rot, Marken-Segment 3 rot), Geschwister 50/50 gruen.
Fix onboarding

create-with-welcome legt username an — unique-Index ohne sparse liess jede Anlage in E11000 laufen (500)

Ursache am Bestand gemessen: ayouneusers traegt username_1 als unique OHNE
sparse/partialFilterExpression, und der EINE erlaubte Platz ohne Wert ist seit
dem 2026-07-12 belegt (1 von 200 Zeilen). Die Route legte ohne username an, also
scheiterte JEDE Anlage — zweimal 500 ohne Datensatz, gemessen 2026-08-22.

Neu: deriveUsername leitet deterministisch ab (Adresse, sonst Adresse+Mandant,
sonst zaehlend) und scheitert laut statt still. Zusaetzlich antwortet die Route
auf einen Schluessel-Konflikt jetzt mit 409 statt 500. 8 Proben inkl. zwei
Negativ-Kontrollen.