001 ConMeet-Instanzen, Berechtigungen und Kontoverknüpfung Entwurf

Übersicht

vd:suite für ConMeet kennt heute keine ConMeet-Instanz und keinen ConMeet-Benutzer; jede Funktion mit Daten aus ConMeet (Anrufinformation, Gesprächsnotiz, Vorgänge) setzt beides voraus. Diese Spezifikation legt das Fundament: Der Administrator des Betriebs verbindet Instanzen und berechtigt Mitarbeitende dafür, jede Person verknüpft je berechtigter Instanz ihren eigenen ConMeet-Benutzer. Die Verknüpfung per persönlichem Schlüssel ist die Lösung für den Proof of Concept; sie weicht bewusst von der Qualität „Kein Einrichtungsaufwand für Mitarbeitende“ ab (US-15).

Verhältnis zu anderen Dokumenten

• User Stories — setzt US-11, US-15 und US-16 um; US-10 und US-12 bauen darauf auf.
• Terminologie — ConMeet-Instanz, Kontoverknüpfung, Produktrolle.
• Integrationsplan — Produktrollen (Entscheidung 2) und ConMeet-Anbindung je Mandant (Entscheidung 5, WP9); diese Spezifikation füllt beide für ihren Ausschnitt.
• Backend-Entwicklung — Mandantenfilter, Basis-Entität, Audit, Autorisierung.

Ziele

1. Der Administrator des Betriebs verbindet beliebig viele ConMeet-Instanzen und sieht beim Aufruf ohne eigenes Zutun, ob jede Verbindung funktioniert.
2. Jede Person sieht und nutzt nur die Instanzen, für die sie berechtigt ist.
3. Jede Person verknüpft je berechtigter Instanz selbst genau einen ConMeet-Benutzer und sieht, ob die Verknüpfung funktioniert.
4. Ohne Verknüpfung greift vd:suite für ConMeet für diese Person nicht auf ConMeet zu.
5. Kein Schlüssel verlässt den Server im Klartext.

Scope

Diese Spezifikation definiert:

• Datenmodell für Instanz, Berechtigung und Kontoverknüpfung,
• die Produktrolle „Administrator des Betriebs“ und ihre Berechtigung,
• Verbinden, Ändern und Trennen einer Instanz samt Verbindungsprüfung,
• Berechtigen einzeln und für „Alle“, Entzug der Berechtigung,
• Verknüpfen, Ersetzen und Lösen per persönlichem Schlüssel samt Prüfung,
• Speicherung der Schlüssel, GraphQL-Operationen und Oberflächen dafür.

Nicht im Scope:

• die Verknüpfung per Anmeldung bei ConMeet (US-10),
• weitere Angaben zum ConMeet-Benutzer über den Benutzernamen hinaus (R54),
• das Umschalten der Instanz in der Anrufinformation (US-12) — 002; bietet alle Instanzen an, für die die Person berechtigt ist (R22); ohne Verknüpfung greift die gewählte Instanz nicht auf ConMeet zu (R30),
• jede fachliche Abfrage an ConMeet (Kontakt zur Rufnummer: 002, Kundeninformationen) — eigene Spezifikationen; hier steht nur, welcher Schlüssel dafür gilt (R30),
• geteilte ConMeet-Benutzer (F-024) — ausgeschlossen durch R44.

Spezifikation

1. Datenmodell

Die drei Entitäten bilden ein Aggregat mit der Wurzel ConMeetInstance; InstanceGrant und AccountLink existieren nur zu ihrer Instanz. Alle drei sind mandanteneigen (TenantOwnedEntity, IsTenantOwned()), auditiert und liegen gemeinsam in der fachlichen Vertikale ConMeet.Core/Features/ConMeetInstances/ mit eigener vertical.json. Die Vertikale enthält zusätzlich die aktive Instanz je Person (ActiveInstanceChoice, 002-R20).

R1 Name ist je Mandant eindeutig, ohne Groß- und Kleinschreibung zu unterscheiden.

R2 BaseUrl ist je Mandant eindeutig, verglichen nach Normalisierung (Schema und Host klein, ohne abschließenden Schrägstrich).

R3 BaseUrl verlangt https. Nur in der Umgebung Development ist http zulässig.

R74 BaseUrl hat höchstens 2048 Zeichen, jeder Schlüssel höchstens 1000.

R81 ConMeetUserName ist Pflicht und hat 1–150 Zeichen; Leerzeichen am Rand werden vor dem Speichern entfernt.

R75 Pfad und Port gehören zur Adresse und zählen beim Vergleich nach R2 mit.

R53 Jede ConMeet-Instanz, auch Live und Staging desselben Betriebs, hat eine eigene Adresse; der Administrator gibt sie je Instanz an (R91), z. B. https://dev.conmeet.io.

R90 Je Instanz gibt es höchstens eine Kontoverknüpfung mit IsAdmin (admin-Verknüpfung).

R4 Je Instanz und Benutzer gibt es höchstens ein InstanceGrant und höchstens einen AccountLink.

R5 Ein AccountLink verweist auf einen Benutzer desselben Mandanten wie die Instanz; ein InstanceGrant ebenso.

R54 ConMeetUserName ist der Benutzername, den die Person beim Verknüpfen eingibt (R62). ConMeet bestätigt ihn nicht — die Public API hat keinen Endpunkt für den eigenen Benutzer. Im Proof of Concept ist in Kauf genommen, dass ein falsch eingegebener Name einen anderen Benutzer nach R68 sperrt und dass R51 und R60 den Namen so zeigen, wie er eingegeben wurde. Verglichen wird er ohne Unterschied von Groß- und Kleinschreibung.

R68 ConMeetUserName ist je Instanz über alle AccountLink eindeutig, ruhende (R26) eingeschlossen. Eine ruhende Verknüpfung belegt ihren Benutzernamen also weiter; R27 kann keinen Konflikt auslösen.

2. Produktrolle

R7 Der Rollenkatalog (ProductRoles) enthält die Rolle conmeet-admin mit dem Namen „Administrator des Betriebs“ und der Berechtigung ManageInstances.

R8 Alle Operationen aus Abschnitt 3 und 4 verlangen die Berechtigung ManageInstances über eine eigene Policy; die Operationen aus Abschnitt 5 verlangen nur die Standard-Policy (READY).

R9 me liefert die Berechtigungen der Person (permissions); die Oberfläche blendet die Verwaltung der Instanzen nur bei ManageInstances ein. Die Prüfung im Backend gilt unabhängig davon.

3. Instanz verbinden, ändern, trennen (US-11)

R91 Zum Verbinden gibt der Administrator Name, Kommentar (optional), Adresse, seinen ConMeet-Benutzernamen und seinen persönlichen Schlüssel an; alle Felder außer dem Kommentar sind Pflicht; der Schlüssel folgt R101. Aus Benutzername und Schlüssel entsteht seine Kontoverknüpfung mit IsAdmin; einen Schlüssel je Instanz kennt ConMeet nicht.

R92 Die admin-Verknüpfung aus R91 wird auch bei fehlgeschlagener Prüfung gespeichert (R11); R57 und R65 gelten für sie nicht, R79 (Eindeutigkeit des Benutzernamens) schon.

R11 Beim Verbinden und beim Ändern prüft der Server die Verbindung (R95). Die Instanz wird auch bei fehlgeschlagener Prüfung gespeichert; das Ergebnis erscheint sofort an der Instanz.

R94 Beim Ändern sind Name, Kommentar und Adresse änderbar. Benutzername und Schlüssel der admin-Verknüpfung ändert ihr Inhaber wie jede Verknüpfung (R61).

R13 Ändern lässt Berechtigungen und Kontoverknüpfungen unverändert, auch bei geänderter Adresse.

R14 Trennen verlangt eine Bestätigung. Der Dialog nennt die Zahl der Kontoverknüpfungen, die mit der Instanz entfallen, ruhende eingeschlossen.

R15 Trennen löscht die Instanz mit allen Berechtigungen, Kontoverknüpfungen und aktiven Instanzen (002-R30) physisch (ExecuteDeleteAsync ohne Soft-Delete-Filter, in einer Transaktion, mit expliziter Audit-Zeile je Entität) — gespeicherte Schlüssel bleiben auch nicht in soft-gelöschten Zeilen zurück.

R98 Ein Administrator mit ManageInstances übernimmt die admin-Verknüpfung, indem er seine eigene, nicht ruhende Verknüpfung der Instanz zur admin-Verknüpfung macht; die bisherige verliert IsAdmin und bleibt als gewöhnliche Verknüpfung bestehen. Ohne eigene Verknüpfung antwortet der Server mit ACCOUNT_NOT_LINKED.

R99 Entfernt Core den Inhaber der admin-Verknüpfung oder wechselt er den Mandanten, entfällt sie mit R86 bzw. R69. Die Prüfung der Instanz liefert dann den Zustand NO_ADMIN_LINK („Kein Prüfkonto – Verbindung nicht prüfbar“), ergänzend zu R63, bis ein Administrator sie nach R98 übernimmt. Verliert der Inhaber nur die Produktrolle oder seine Berechtigung, bleibt die admin-Verknüpfung bestehen.

Verbindungsprüfung der Instanz

R95 Die Verbindungsprüfung ist der Aufruf GET {BaseUrl}/api/public/v1/customers?limit=1, ausgeführt vom Server mit dem persönlichen Schlüssel einer Verknüpfung — für die Instanz mit dem der admin-Verknüpfung, auch wenn sie ruht (R26).

R63 Das Ergebnis ist genau einer dieser Zustände:

R64 Jedes Prüfergebnis enthält den HTTP-Statuscode und, außer bei CONNECTED, den Antworttext von ConMeet, gekürzt auf 2000 Zeichen; die Oberfläche zeigt beides unter der Anzeige aus R63 (Antworttext aufklappbar). Ohne Antwort (Zeitüberschreitung, Netzwerkfehler) steht dort die Art des Fehlers. Bei CONNECTED entfällt der Antworttext, weil er einen Kundendatensatz enthält.

R18 Sobald die Seite mit den Instanzen geöffnet wird, startet für jede Instanz eine eigene Prüfung; die Liste erscheint sofort, jede Zeile zeigt „Wird geprüft …“, bis ihr Ergebnis da ist.

R19 Eine Zeile bietet „Erneut prüfen“ an. Das Ergebnis wird nicht gespeichert.

R76 Je geöffneter Seite laufen höchstens fünf Prüfungen gleichzeitig (R18, R60); weitere warten mit „Wird geprüft …“. Jede Prüfung durchläuft zusätzlich die Begrenzung der Aufrufe je Instanz aus 002-R52 und wartet dort, bis sie an der Reihe ist.

R20 Verbindungsprüfungen sind Aufrufe ohne Wirkung in ConMeet und laufen deshalb synchron, nicht über die Outbox.

4. Berechtigen (US-16)

R93 Eine neu verbundene Instanz ist nur für den Administrator freigegeben, der sie verbindet: Er erhält ein InstanceGrant; GrantedToAll ist nicht gesetzt.

R22 Eine Person ist für eine Instanz berechtigt, wenn GrantedToAll gesetzt ist oder ein InstanceGrant für sie besteht. Das gilt auch für den Administrator selbst.

R23 Ist GrantedToAll gesetzt, ist jede Person des Mandanten berechtigt, auch jede, die später in der Replik hinzukommt. Nutzen kann die Instanz nur, wer READY ist (R8).

R24 Der Administrator berechtigt Personen einzeln aus den Benutzern seines Mandanten in der Replik, die eine gültige Lizenz für conmeet-base haben; die Auswahl ist nach Namen durchsuchbar. Die „Zahl der Personen“ (Abschnitt 8) zählt Einzelberechtigungen solcher Benutzer.

R25 Ist GrantedToAll gesetzt, zeigt die Oberfläche die Einzelberechtigungen nicht; sie bleiben gespeichert und gelten wieder, sobald GrantedToAll entfernt wird.

R26 Entzieht der Administrator einer Person die Berechtigung — einzeln oder durch Entfernen von GrantedToAll —, ruht ihre Kontoverknüpfung: Sie bleibt gespeichert, wird nicht genutzt und erscheint der Person nicht. War die Instanz ihre aktive, entfällt diese Wahl (002-R28, 002-R29).

R27 Wird die Person wieder berechtigt, gilt die ruhende Verknüpfung ohne weiteres Zutun wieder.

R70 Der Entzug einer Einzelberechtigung löscht ihr InstanceGrant physisch, wie R15 — sonst stieße eine erneute Berechtigung an die Eindeutigkeit aus R4.

R86 Entfernt Core einen Benutzer (UserDeleted, Backfill), werden seine InstanceGrant und AccountLink physisch gelöscht.

R87 Das Löschen nach R86 und R69 läuft über einen Erweiterungspunkt der Suite-Replik (Crosscutting/Suite/), den die Vertikale ConMeetInstances registriert: Er wird beim Entfernen und beim Mandantenwechsel eines Benutzers in der Transaktion des Replik-Handlers aufgerufen, löscht auch seine aktive Instanz (002-R31) und schreibt je gelöschter Zeile eine Audit-Zeile. Die Replik kennt die Vertikale nicht — Querschnitt nutzt nie Features (LayerDirectionTests).

R69 Wechselt ein Benutzer den Mandanten, werden seine InstanceGrant und AccountLink im bisherigen Mandanten physisch gelöscht wie in R86 — sie verweisen sonst über Mandanten hinweg (R5).

R51 Die Personenliste einer Instanz zeigt dem Administrator je berechtigter Person mit gültiger Lizenz für conmeet-base (wie R24; bei „Alle“ also alle lizenzierten Benutzer des Mandanten), ob sie ihr Konto verknüpft hat, und bei Verknüpfung den ConMeet-Benutzernamen. Ruhende Verknüpfungen (R26) erscheinen dort nicht.

5. Konto verknüpfen (US-15)

R29 Der Abschnitt „Meine ConMeet-Verbindungen“ auf der Übersicht listet alle Instanzen, für die die Person berechtigt ist, mit Name, Kommentar und Verknüpfungsstatus. Ohne berechtigte Instanz zeigt er „Für Sie ist noch keine ConMeet-Instanz freigegeben. Wenden Sie sich an den Administrator Ihres Betriebs.“

R71 Der Verknüpfungsstatus ist „Nicht verknüpft“ mit der Aktion „Verknüpfen“ oder „Verknüpft“ mit den Angaben aus R60 und den Aktionen „Schlüssel ersetzen“ und „Verknüpfung lösen“.

R30 Jeder Zugriff auf ConMeet im Namen einer Person nutzt ausschließlich ihren persönlichen Schlüssel für die gewählte Instanz. Ohne Verknüpfung für diese Instanz findet kein Zugriff statt.

R96 Die admin-Verknüpfung ist eine gewöhnliche Kontoverknüpfung ihres Inhabers (R30); ihr Schlüssel prüft zusätzlich die Verbindung der Instanz (R95). Für Zugriffe anderer Personen wird er nie genutzt (R50).

R62 Zum Verknüpfen gibt die Person ihren ConMeet-Benutzernamen und ihren persönlichen Schlüssel ein. Neben den Feldern steht eine Anleitung, wie sie den Schlüssel in ConMeet erzeugt, mit einem Link auf <Adresse der Instanz>/home/account/api-tokens.

R101 Das Schlüsselfeld nimmt keine Eingabe über die Tastatur an. Der Schlüssel gelangt nur über die Schaltfläche „Einfügen“ (oder Strg+V in das Feld) aus der Zwischenablage hinein und wird verdeckt angezeigt. Beschriftung „Ihr persönlicher Schlüssel (API-Token)“ und Anleitung sagen, dass dort nicht das ConMeet-Passwort hingehört, sondern ein in ConMeet erzeugtes API-Token. So kann niemand sein Passwort versehentlich eintippen. Gilt für jedes Schlüsselfeld (R62, R91, R61).

R57 Vor dem Speichern führt der Server die Prüfung aus R95 mit dem eingegebenen Schlüssel aus.

R79 Vor der Prüfung aus R57 prüft der Server die Eindeutigkeit des Benutzernamens (R44, R68); ist der Name vergeben, ruft er ConMeet nicht auf.

R65 Schlägt die Prüfung aus R57 fehl, wird nichts gespeichert. Die Person sieht den Zustand nach R63 mit Statuscode und Antworttext nach R64.

R60 Eine verknüpfte Instanz zeigt den ConMeet-Benutzernamen und den Status einer Prüfung mit dem persönlichen Schlüssel (R95), die beim Öffnen der Seite startet wie in R18.

R61 Die Person kann Benutzername und Schlüssel jederzeit ersetzen, solange sie für die Instanz berechtigt ist (R39); das Ersetzen folgt R62, R57 und R65.

R37 Die Person kann die Verknüpfung jederzeit lösen, solange sie für die Instanz berechtigt ist (R80) und es nicht die admin-Verknüpfung ist (R97). Lösen verlangt eine Bestätigung und löscht den AccountLink physisch.

R97 Die admin-Verknüpfung kann ihr Inhaber nicht lösen, solange sie IsAdmin trägt; der Server antwortet mit dem Fehlercode ADMIN_LINK_REQUIRED („Diese Verknüpfung prüft die Instanz. Ein anderer Administrator muss sie zuerst übernehmen.“), ergänzend zu R66.

R38 Verknüpfen, Ersetzen und Lösen wirken nur auf den AccountLink der aufrufenden Person; die Operationen nehmen keine Benutzer-ID entgegen.

R39 Verknüpfen und Ersetzen sind nur für Instanzen möglich, für die die Person berechtigt ist (R22); sonst antwortet der Server mit dem Fehlercode INSTANCE_NOT_GRANTED.

R80 checkMyConMeetAccount und unlinkConMeetAccount antworten für eine Instanz ohne Berechtigung ebenfalls mit INSTANCE_NOT_GRANTED. Eine ruhende Verknüpfung kann die Person deshalb nicht lösen; ihren Schlüssel kann sie in ConMeet zurückziehen.

6. Schlüssel

R40 PersonalKey liegt AES-256-GCM-verschlüsselt in der Datenbank; Associated Data ist Mandant, Zweck (conmeet-personal-key) und Zeilen-ID. Der Schlüssel zur Verschlüsselung kommt aus der Konfiguration, nie aus dem Repository.

R72 Fehlt der Schlüssel zur Verschlüsselung oder ist er ungültig, startet der Dienst nicht. Ein Wechsel dieses Schlüssels ist nicht vorgesehen.

R88 Der Schlüssel zur Verschlüsselung steht in der Konfiguration unter Secrets:EncryptionKey als 64 Hex-Zeichen (32 Byte); jeder andere Wert ist ungültig nach R72. Die Übergabe (docs/vds-suite/deployment-handover.md) nimmt ihn mit der Umsetzung auf.

R41 Keine GraphQL-Antwort enthält einen Schlüssel, auch nicht teilweise.

R100 Die Instanz zeigt dem Administrator Inhaber und ConMeet-Benutzernamen der admin-Verknüpfung; die Personenliste (R51) kennzeichnet sie als „Prüfkonto“.

R42 Schlüssel erscheinen in keinem Log, keiner Fehlermeldung und keinem Trace; die Schlüsselattribute stehen in der Audit-Blacklist (BlacklistAttribute<T>()).

R43 Im Browser sind Schlüsselfelder vom Typ password ohne Autovervollständigung; der BFF reicht den Wert nur an die Mutation weiter und speichert ihn nicht.

R52 Jeder Aufruf der ConMeet-Schnittstelle (Public API) sendet den Schlüssel als Authorization: Bearer <Schlüssel>, ohne Cookies oder Browser-Sitzung. Jeder Schlüssel ist ein Public-API-Token, ausgestellt im ConMeet-Konto einer Person.

7. Schnittstelle

R44 Gibt eine Person einen ConMeet-Benutzernamen an, der in derselben Instanz schon mit einem anderen Suite-Benutzer verknüpft ist, wird nichts gespeichert; Fehlercode CONMEET_USER_ALREADY_LINKED, Meldung „Dieser ConMeet-Benutzer ist bereits mit einer anderen Person verknüpft.“

R66 Fehler der Mutationen haben stabile Codes: INSTANCE_NOT_FOUND, INSTANCE_NAME_TAKEN, INSTANCE_URL_TAKEN, INSTANCE_URL_INVALID, INSTANCE_NOT_GRANTED, CONMEET_USER_ALREADY_LINKED und CONMEET_CHECK_FAILED. CONMEET_CHECK_FAILED trägt das Prüfergebnis nach R63 und R64 als Erweiterung des Fehlers.

R89 Die Fehlercodes aus R66, R73 und R82 gelten auch für Queries. Hat die Person für eine berechtigte Instanz keine Verknüpfung, antwortet checkMyConMeetAccount mit dem Fehlercode ACCOUNT_NOT_LINKED („Sie haben Ihr ConMeet-Konto für diese Instanz noch nicht verknüpft.“); unlinkConMeetAccount gelingt dann ohne Wirkung.

R67 connectConMeetInstance und updateConMeetInstance liefern die gespeicherte Instanz und das Prüfergebnis nach R63 und R64; eine fehlgeschlagene Prüfung ist dort kein Fehler (R11).

R73 Ändern zwei Administratoren dieselbe Instanz gleichzeitig, scheitert das spätere Speichern an der Zeilenversion (xmin) mit dem Fehlercode INSTANCE_CHANGED, ergänzend zu R66.

R82 Leere Pflichtfelder und überschrittene Längen (R74, R81, Name, Comment) beantwortet der Server mit dem Fehlercode INVALID_INPUT und dem Namen des Felds, ergänzend zu R66; die Oberfläche zeigt die Meldung „Bitte prüfen Sie diese Angabe.“ am Feld.

R83 Weitere Meldungen: INSTANCE_NOT_FOUND „Diese ConMeet-Instanz gibt es nicht mehr.“, INSTANCE_NOT_GRANTED „Für diese ConMeet-Instanz sind Sie nicht freigegeben.“; CONMEET_CHECK_FAILED zeigt die Anzeige aus R63 mit den Angaben aus R64.

R77 Meldungen zu den Fehlercodes:

R46 Eine Instanz eines anderen Mandanten verhält sich wie eine nicht vorhandene (INSTANCE_NOT_FOUND).

8. Oberfläche

R47 Verbinden und Bearbeiten geschehen in einem Sheet; Trennen und Lösen in einem Bestätigungsdialog nach validdata-frontend-patterns.

R48 Die Liste der Instanzen zeigt ohne Instanz einen Empty State mit „Instanz verbinden“.

R78 Die Navigation enthält „Übersicht“ für jede Person mit READY und „ConMeet-Instanzen“ nur bei ManageInstances (R9).

Abgrenzung

R49 Niemand hinterlegt einen persönlichen Schlüssel stellvertretend für eine andere Person, auch der Administrator nicht — Aktionen in ConMeet müssen unter dem Benutzer der handelnden Person erscheinen (US-05).

R50 Zugriffe im Namen einer Person fallen nie auf die admin-Verknüpfung zurück — sonst erschienen sie in ConMeet unter dem Benutzer des Administrators (US-05).

Beispiel: Live- und Staging-Instanz der Tischlerei Muster

Mandant „Tischlerei Muster“. Anna hat die Rolle conmeet-admin, Ben und Clara sind Mitarbeitende am Telefon.

1. Anna verbindet „Live“ (https://muster.conmeet.example) mit anna.berg und ihrem Schlüssel ***. Prüfung → CONNECTED. Ihre Verknüpfung ist die admin-Verknüpfung, freigegeben ist nur Anna (R91, R93).
2. Anna verbindet „Staging“ (https://dev.conmeet.io, Kommentar „Testsystem“) ebenso. Prüfung → KEY_REJECTED; Instanz und admin-Verknüpfung sind gespeichert (R11, R92). Anna ersetzt den Schlüssel ihrer Verknüpfung (R61). Prüfung → CONNECTED.
3. Anna setzt für „Live“ „Alle“ und berechtigt für „Staging“ zusätzlich Ben.
4. Clara öffnet die Übersicht; unter „Meine ConMeet-Verbindungen“ steht nur „Live“, nicht verknüpft (R29). Sie gibt clara.schmidt und ihren Schlüssel ein; Prüfung → CONNECTED → gespeichert (R62, R57).
5. Ben sieht „Live“ und „Staging“. Er gibt für „Live“ versehentlich Clara.Schmidt ein → CONMEET_USER_ALREADY_LINKED, nichts gespeichert (R44, R54).
6. Ben verknüpft „Staging“ als ben.mueller. Als sein Schlüssel abläuft, zeigt die Übersicht „Schlüssel ungültig“ (R60); er ersetzt ihn (R61).
7. Anna entzieht Ben „Staging“. Seine Verknüpfung ruht (R26); auf seiner Seite fehlt „Staging“. Eine Woche später berechtigt sie ihn erneut: Die Verknüpfung als ben.mueller gilt sofort wieder (R27).
8. Anna versucht, ihre Verknüpfung zu „Staging“ zu lösen → ADMIN_LINK_REQUIRED (R97). Sie trennt „Staging“. Der Dialog nennt „2 Kontoverknüpfungen entfallen“ (R14); Instanz, Berechtigungen und beide Verknüpfungen samt Schlüsseln sind physisch gelöscht (R15).

Offene Fragen

• Bestätigt Core den Rollencode conmeet-admin (R7)? Die Onboarding-Anfrage nennt ihn (F-002).
• Wie wird der eingegebene Benutzername bestätigt, sobald ConMeet einen Endpunkt für den eigenen Benutzer anbietet (R54)?