Sechs Lücken aus Vertrag B (Handoff 01.09.), gebaut im Stil der App-Demo: Feldfehler im E-Mail-Schritt, Passwort mit Bestätigung, SMS-Code mit Restgültigkeit, die dauerhaft vergebene Nummer und die zwei Konflikte rund um ein schon vorhandenes Konto. Alles statisch, jede Ansicht ein eigener Rahmen.
Über jedem Rahmen steht seine state_uid als Beschriftung, das ist der Kontaktbogen. Der lila Ring um jeden Rahmen markiert: diese Ansicht ergänzt den bestehenden Stand (ADDED_BY_COMPLETION), sie ersetzt keine vorhandene.
Bisher erscheint der Fehler als Banner unter dem Feld, das Feld selbst kennt keinen Fehlerzustand, und Weiter prüft erst beim Antippen. Neu (B-4): der Fehler wohnt im Feld (2 px Rahmen, Meldung direkt darunter), und der gesperrte Knopf sagt, was ihm fehlt. Wegen B-2 gilt: geprüft wird nur die Form der Adresse, nie ob ein Postfach existiert. Die Meldung behauptet deshalb nichts über Zustellung.
Eine Frage nach der anderen · dauert keine Minute.
Eine Frage nach der anderen · dauert keine Minute.
Beim Korrigieren wird die Meldung still und der Knopf wacht auf, ohne erneutes Antippen. Links und rechts sind Vorher und Nachher desselben Feldes.
Das Bestätigungsfeld bleibt (B-6). Die Häkchenliste spiegelt exakt die Serverregeln (B-8): 12 bis 128 Zeichen, kein häufig genutztes Passwort, nichts aus den eigenen Daten. Sie darf weder strenger noch laxer sein als der Server. Der Mismatch meldet sich erst zu drei verdienten Momenten (B-7), und abgeschickt wird nur im gültigen Zustand (B-9).
Die Wiederholung ist noch kürzer als das Passwort: kein verdienter Moment, die Meldung bleibt still. Der Knopf ist trotzdem ehrlich gesperrt und sagt warum.
Verdiente Momente für die Meldung: die Wiederholung hat die Passwortlänge erreicht, das Feld wurde verlassen, oder es wurde abgeschickt. Hier: gleiche Länge, anderer Inhalt. Bei Ungleichheit bleibt Abschicken hart gesperrt, auch wenn alles andere passt.
Beide Felder stimmen überein, die Meldung ist wieder still. Die Anzeige entspricht den Serverregeln, nicht mehr und nicht weniger.
Zwischen zwei Code-Anfragen gibt es keine Wartezeit, nur die Gültigkeit des aktuellen Codes. Der Text sagt deshalb, was die Zahl ist: noch 4:32 gültig. Einen neuen Code gibt es jederzeit, ohne Zähler neben dem Senden-Weg.
Wir haben einen Code an +49 171 2345678 geschickt.
Das Band oben ist das Timer-Muster aus dem Buchungsablauf: der Countdown sitzt in der Sache, die er betrifft. Neuen Code senden trägt keinen Zähler, denn es gibt keine Sperrfrist.
Die Prüfung greift, bevor eine SMS überhaupt entsteht, und die Absage ist endgültig. Codeeingabe und Erneut senden sind deshalb entfernt: was nicht helfen kann, wird nicht angeboten. Drei echte Auswege bleiben, und keiner davon ist ein Knopf, dessen einzige Antwort eine Absage wäre.
Gilt für die Registrierung. Wer die Nummer später in den Einstellungen ändert und denselben Konflikt trifft, wird dabei nicht abgemeldet; dort entfällt der Anmelde-Ausweg.
Zwei Wege, derselbe Kern: die Adresse hat schon ein Konto. Kommt sie aus der normalen Registrierung, zeigt sich der Konflikt erst nach dem Passwort-Schritt (so prüft es der Server), das Formular springt auf den E-Mail-Schritt zurück und bietet den Login an. Kommt sie über Google oder Apple, ist Anmelden und verknüpfen der Hauptweg.
Rücksprung aus dem Passwort-Schritt (B-5): dieselbe Feldsprache wie in Block 1, der Ausweg steht direkt darunter. Kein Weiter-Knopf, der nur noch einmal dieselbe Antwort holen würde.
Gezeigt am Beispiel Google, für Apple wortgleich. Kein zweites Konto nebenher: die Verknüpfung ist der einzige Weg, der beide Anmeldearten zusammenführt.
Nicht Teil dieses Auftrags, im Vertrag aber als zwingend designbar gelistet und weiterhin offen: Code abgelaufen, zu viele Versuche, Rate-Limit, Laden und Serverfehler. Die Support-Adresse ist konfiguriert und wird erst im echten Build eingesetzt, hier steht bewusst nur der Weg.