--- kind: wireframe-package project: HiveGrid Screen Project ticket: D-P2 package: WF-P2 Signup typ: Flow status: In Subframe subframe: "https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit" canvas: "02 Wireframes/P2 Signup/WF-P2 Signup/WF-P2 Signup.canvas" --- # WF-P2 Signup Status: In Subframe Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit Canvas: [[WF-P2 Signup.canvas]] Stand: 2026-06-24 --- ## 1. Kurzfassung Dieses Paket klaert den Self-Service-Signup fuer HiveGrid. Der Signup ist fuer v1 bewusst ein minimaler Test-/Basis-Signup, kein Wizard. Er soll grundsaetzlich Account und ersten Workspace erstellen koennen, damit die App nutzbar und testbar ist. Wichtig: Dieser Signup ist fachlich noch nicht der finale volle Signup. Spaeter muss er deutlich ausgebaut werden. Firmenname ist in v1 nur ein Platzhalter fuer den Workspace-/Firmenkontext; Billing, USt-ID, Branding, Team, Onboarding und weitere Firmendaten kommen spaeter. --- ## 2. Intent Check | Frage | Antwort | |---|---| | Welches Ticket/Modul ist betroffen? | D-P2 Auth / Identitaet & Mandantentrennung | | Was soll der Nutzer am Ende schaffen? | Account und Workspace anlegen und danach in den ersten sicheren Einstieg kommen | | Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | kleiner Signup-Flow mit Hauptformular und wichtigen Blocker-/Feedback-Zustaenden | | Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP ยง1 Auth-Screens | | Was ist sicher im Scope? | E-Mail, Passwort innerhalb des Signup-Flows, Vorname, Nachname, Firmenname als Platzhalter, Captcha, AGB-/Datenschutz-Checkbox, Auto-SHK-Seed | | Was ist sicher nicht im Scope? | USt-ID, Rechnungsdaten, Logo/Branding, Mitglieder einladen, Template-Auswahl, CRM-/Pipeline-Konfiguration, mehrstufiger Onboarding-Wizard, Tenant-Auswahl nach Login, Admin-Rollenverwaltung | | Gibt es Admin/Normalrolle-Unterschiede? | Signup-Ersteller wird initialer Tenant-Admin; weitere Rollen kommen spaeter ueber Mitarbeiter/Admin-RBAC | | Welche Annahmen sind noch unsicher? | Keine fuer v1; spaeterer Ausbau ist im Backlog markiert | --- ## 3. Scope | Punkt | Inhalt | |---|---| | Ticket/Modul | D-P2 Auth | | Nutzerrolle | neuer Nutzer ohne Account | | Admin-Variante | erster Nutzer wird Tenant-Admin | | Normale Rolle | nicht relevant im Signup selbst | | Startpunkt | `/signup`, Link aus Login | | Ziel | Tenant/Workspace + erster User angelegt, sicherer Folgepfad klar | | Haupt-Archetyp | A4 Form | | Bespoke-Anteil | nein | | Out of scope | Onboarding-Checkliste, Demo-Daten, detaillierter Firmen-Wizard, Billing-/USt-Daten, Branding, Team-Setup | --- ## 4. Brainstorming ### Flow-Frage Soll Signup als einzelnes Formular gebaut werden oder als mehrstufiger Wizard? ### UX-Varianten | Option | Beschreibung | Vorteil | Nachteil | Empfehlung | |---|---|---|---|---| | A | Ein schlankes Formular mit Account, minimalem Firmen-Platzhalter und Rechtlichem | schnell, gut fuer Testzugang, wenig Reibung | spaeter fachlich unvollstaendig | genommen | | B | Mehrstufiger Wizard Account -> Firma -> Rechtliches -> Setup | ruhiger pro Schritt | widerspricht v1-Schnitt, hoeherer Aufwand | raus fuer v1, spaeterer Ausbau | | C | Einladung-only, kein Self-Service | kontrollierter Vertriebspfad | D-P2 fordert Self-Service-Signup | raus | ### Entscheidung | Entscheidung | Status | Notiz | |---|---|---| | Ein Formular, kein Wizard | genommen | entspricht D-P2 und SCREEN-MAP | | Minimaler Test-/Basis-Signup | genommen | Ziel ist erstmal grundsaetzlich Accounts/Workspaces erstellen zu koennen | | Firmenname nur als Platzhalter | genommen | spaeter kommen echte Workspace-/Firmen-/Billing-Daten dazu | | Captcha im Signup | genommen | Anti-Spam/Schutz fuer Self-Service-Signup | | Legal-Consent sichtbar im Formular | genommen | AGB und Datenschutz sind vor Submit notwendig | | Passwort im Signup verankert | genommen | Ausnahme fuer Neukunden-Signup, damit moeglichst wenig Reibung entsteht | | `WF-P2 Set Password` nicht fuer Signup | genommen | Core-Flow bleibt fuer Einladung, Reset, Change Password, Admin-Reset und spaetere Trigger | | Vorbereitungsscreen nach E-Mail-Bestaetigung | genommen | S02 zeigt, dass Workspace/Account vorbereitet wird; kann technisch uebersprungen werden, wenn alles sofort fertig ist | | E-Mail-Bestaetigung vor Abschluss | genommen | Signup kann ohne bestaetigte E-Mail nicht final abgeschlossen werden | ### Happy Path 1. Nutzer oeffnet `/signup`. 2. Nutzer gibt E-Mail, Passwort, Vorname, Nachname und Firmenname/Workspace-Platzhalter ein. 3. Nutzer loest Captcha und bestaetigt AGB/Datenschutz. 4. Nutzer sendet Signup ab. 5. Nutzer muss die E-Mail bestaetigen, bevor der Signup abgeschlossen wird. 6. Danach legt/finalisiert das System Workspace/Tenant und ersten Admin-User. 7. Nutzer sieht S02 `Workspace wird vorbereitet`, falls Provisioning/Laden sichtbar ist. 8. Wenn kein sichtbares Laden noetig ist, kann S02 technisch uebersprungen werden und direkt in die App fuehren. ### Varianten / Branches - Passwort ist zu schwach oder in Breach-Liste. - Firmen-/Tenant-Slug ist reserviert oder bereits vergeben. - Legal-Checkbox fehlt. - Tenant-Provisioning laeuft noch. ### Roadblocks - E-Mail bereits registriert - Passwort durch Policy blockiert - Legal-Consent fehlt - reservierter Tenant-Slug - Provisioning-Fehler beim Tenant/Seed ### Meldungs-/Error-State-Brainstorming | Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz | |---|---|---|---|---| | Passwort zu schwach | Inline | ja | nein | A4-Validierung, klare Policy | | Passwort in Breach-Liste | Inline/Banner im Formular | ja | nein | sicherheitskritisch, aber kein eigener Screen | | E-Mail existiert bereits | Inline + Link zu Login/Reset | ja | nein | keine Account-Enumeration ausserhalb Signup uebertreiben | | Legal-Consent fehlt | Inline | ja | nein | Nutzer kann direkt korrigieren | | Tenant-Slug reserviert/vergeben | Inline | ja | nein | Alternativvorschlag anzeigen | | Signup erfolgreich / Workspace wird vorbereitet | Screen mit Ladezustand oder App-Redirect | nein | ja | Screen bauen, aber bei sofort fertigem Workspace ueberspringbar | | Provisioning-Fehler | Banner | ja | nein | Retry/Kontakt anbieten | ### S01 Validierter Minimalumfang | Feld / Element | Status | Notiz | |---|---|---| | E-Mail | rein | Pflichtfeld | | Passwort | rein | direkt im Signup-Flow verankert, inklusive Staerke-/Breach-Feedback | | Vorname | rein | Pflichtfeld fuer Basisprofil | | Nachname | rein | Pflichtfeld fuer Basisprofil | | Firmenname | rein als Platzhalter | erzeugt Workspace-/Tenant-Kontext, spaeter deutlich ausbauen | | Captcha | rein | Anti-Spam/Schutz | | AGB-Checkbox | rein | Pflicht | | Datenschutz-Checkbox | rein | Pflicht | | USt-ID | raus v1 | spaeter in Workspace/Billing-Settings | | Rechnungsdaten | raus v1 | spaeter Billing | | Logo/Branding | raus v1 | spaeter Branding/Workspace-Settings | | Mitglieder einladen | raus v1 | spaeter Admin RBAC/Checklist | | Template-Auswahl | raus v1 | spaeter Onboarding-Ausbau | --- ## 5. Screen-Kandidaten nach Entscheidung | Kandidat | Warum eventuell noetig? | Erste Einschaetzung | |---|---|---| | Signup | Hauptformular | Bauen | | Signup erfolgreich / Workspace wird vorbereitet | klaert Folgepfad und Auto-SHK-Seed | Bauen | | E-Mail bestaetigen | Pflicht, sonst ist Signup nicht abgeschlossen | Bauen | | Passwort/Breach blockiert | Sicherheitsfeedback | Nur dokumentieren | | Tenant-Slug reserviert/vergeben | korrigierbarer Formularfehler | Nur dokumentieren | | Legal-Consent fehlt | korrigierbarer Formularfehler | Nur dokumentieren | | Provisioning-Fehler | technischer Fehler mit Retry | Nur dokumentieren | --- ## 6. Screen Validation Gate | ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung | |---|---|---|---|---|---| | S01 | Signup | ja | ja, Hauptformular | Validiert | minimaler Test-/Basis-Signup mit E-Mail, Passwort, Name, Firmenname-Platzhalter, Captcha und Legal | | S02 | Signup erfolgreich / Workspace wird vorbereitet | ja | ja, Folgepfad nach E-Mail-Bestaetigung | Validiert | eigener Lade-/Vorbereitungsscreen; bei sofort fertigem Workspace technisch ueberspringbar | | S03 | E-Mail bestaetigen | ja | ja, Auth-Sicherheitsentscheidung | Validiert | Pflicht, sonst ist Signup nicht abgeschlossen | | D01 | Passwort zu schwach/Breach | nein | nein | Nur dokumentieren | Inline-Zustand in S01 | | D02 | Slug/Firma reserviert | nein | nein | Nur dokumentieren | Inline-Zustand in S01 | | D03 | Legal-Consent fehlt | nein | nein | Nur dokumentieren | Inline-Zustand in S01 | | D04 | Provisioning-Fehler | nein | ja, technischer Blocker | Nur dokumentieren | Banner mit Retry reicht voraussichtlich | ### Copy-kritische Zustaende | Zustand | Bauen? | Warum / Copy-Entscheidung | |---|---|---| | Passwort in Breach-Liste | nein | Formulierung muss klar, aber nicht technisch sein | | Legal-Consent | nein | muss vor Submit eindeutig sein | | Workspace wird vorbereitet | ja | eigener Lade-/Feedbackscreen nach E-Mail-Bestaetigung, ueberspringbar wenn sofort fertig | ### Blockierende Error States | Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung | |---|---|---|---|---| | E-Mail existiert bereits | Inline | Einloggen | Passwort vergessen | Kein Sackgassen-Text | | Slug reserviert/vergeben | Inline | Vorschlag uebernehmen | Firmenname anpassen | Kurz, konkret | | Provisioning-Fehler | Banner | Erneut versuchen | Support kontaktieren | Keine Rohfehler | --- ## 7. Validierte Screen-Liste S01 ist als minimaler Test-/Basis-Signup validiert. S03 E-Mail bestaetigen ist Pflicht und validiert. S02 ist als Vorbereitungsscreen nach E-Mail-Bestaetigung validiert. | ID | Screen/Zustand | Typ | Umsetzung | Ort | Status | |---|---|---|---|---|---| | S01 | Signup | Auth Form | Bauen | `/signup` | Validiert | | S02 | Signup erfolgreich / Workspace wird vorbereitet | Auth Feedback | Bauen | nach E-Mail-Bestaetigung | Validiert | | S03 | E-Mail bestaetigen | Auth Feedback | Bauen | nach S01 | Validiert | --- ## 8. Subframe-Grid ```text S01 Signup -> S03 E-Mail bestaetigen -> E-Mail-Link -> S02 Signup erfolgreich / Workspace wird vorbereitet -> App-Start ``` Hinweis: Wenn der Workspace ohne sichtbares Warten fertig ist, darf S02 technisch uebersprungen werden und direkt in die App fuehren. --- ## 9. Screen-Pakete | ID | Datei | |---|---| | S01 | [[Screens/S01 Signup]] | | S02 | [[Screens/S02 Signup erfolgreich Workspace wird vorbereitet]] | | S03 | [[Screens/S03 E-Mail bestaetigen]] | --- ## 10. Backlog / Ausbau Diese Punkte muessen spaeter nochmal gross ausgebaut werden. Der v1-Signup ist nur ein schlanker Einstieg, damit Accounts/Workspaces erstellt und getestet werden koennen. | Thema | Warum spaeter | |---|---| | Voller Firmen-/Workspace-Step | Rechtsform, Adresse, USt-ID, Rechnungsdaten, Logo, Branding, ggf. weitere Organisationseinstellungen | | Billing/Trial/Plan-Auswahl | gehoert zu P20/Billing, nicht in den Minimal-Signup | | Onboarding-Wizard | v2 laut Planning; v1 nutzt Auto-SHK-Seed und spaeter Checklist/Banner | | Template-/Branchen-Auswahl | echte Templates existieren noch nicht; SHK ist Default | | Mitglieder einladen | nach Signup ueber Admin RBAC / Erste-Schritte-Checklist | | Integrationen verbinden | spaeter In-App-Setup fuer E-Mail, Kalender, Telefonie, Formulare | | CRM-/Pipeline-Konfiguration | spaeter Settings/Onboarding, nicht Signup-Blocker | --- ## 11. Handoff-Check - [x] Paket ist angelegt. - [x] Screen-Kandidaten sind gesammelt. - [x] Meldungs-/Error-State-Matrix ist ausgefuellt. - [x] Offene Fragen sind sichtbar. - [x] S01 Minimal-Signup ist validiert. - [x] Passwort ist fuer Neukunden-Signup direkt im Signup-Flow verankert. - [x] `WF-P2 Set Password` bleibt fuer Einladung, Reset, Change Password und andere Passwort-Trigger reserviert. - [x] S03 E-Mail bestaetigen ist als Pflichtschritt validiert. - [x] S02 Signup erfolgreich / Workspace wird vorbereitet ist validiert. - [x] Spaeterer Signup-/Onboarding-Ausbau ist im Backlog markiert. - [x] David hat die Kandidaten validiert. - [x] Screen-Dateien sind angelegt. - [x] Canvas ist angelegt. - [ ] Subframe-Link ist eingetragen.