001 ConMeet-Instanzen, Berechtigungen und Kontoverknüpfung Entwurf

Ort: R26, R44, R4 Problem: R44 verbietet, einen ConMeet-Benutzernamen in derselben Instanz mit einem zweiten Suite-Benutzer zu verknüpfen. Ob eine nach R26 ruhende Verknüpfung dabei mitzählt, steht nicht da. Zählt sie, kann der echte Inhaber nach einem Personalwechsel nicht verknüpfen; zählt sie nicht, gibt es nach R27 zwei aktive Verknüpfungen zum selben ConMeet-Benutzer. R44 steht zudem im Abschnitt „Schnittstelle“, das Datenmodell (R4) nennt die Eindeutigkeit nicht. Erforderlich: Festlegen, ob ruhende Verknüpfungen zählen und was R27 im Konfliktfall tut; die Eindeutigkeitsregel ins Datenmodell aufnehmen. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: ruhende Verknüpfungen zählen mit; neue R68 im Datenmodell.

Ort: R17, R34, R45 Problem: R34 nennt Meldungen nur für „abgelehnt“ und „nicht erreichbar“; R45 kennt nur CONMEET_KEY_REJECTED und CONMEET_UNREACHABLE. Für UNEXPECTED (z. B. HTTP 404 bei falscher Adresse) fehlen Code und Meldung. Ebenso fehlt, was beim Verbinden/Ändern einer Instanz bei fehlgeschlagener Prüfung zurückkommt (R11 speichert trotzdem). Erforderlich: Code und Meldung für UNEXPECTED beim Verknüpfen festlegen; Rückgabe von connectConMeetInstance/updateConMeetInstance (Instanz plus Prüfergebnis?) benennen. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: R17, R34, R45 ersetzt durch R63 (auch 402 und 429 als eigene Zustände), R64 (Statuscode und Antworttext), R65 und R66 (CONMEET_CHECK_FAILED mit Prüfergebnis); Rückgabe von Verbinden/Ändern in R67.

Ort: R6, R35, Abschnitt 7 (checkMyConMeetAccount) Problem: R6 überschreibt die Angaben „bei jeder erfolgreichen Prüfung“. R35 startet beim Öffnen eine Prüfung über eine Query. Ob diese Query Daten schreibt (Query mit Seiteneffekt) oder R6 nur beim Verknüpfen/Ersetzen gilt, ist offen. Ebenso, was geschieht, wenn die Prüfung beim Öffnen einen anderen Benutzernamen liefert als gespeichert. Erforderlich: Festlegen, welche Prüfungen R6 auslösen, und das Verhalten bei abweichendem Benutzernamen. Hinfällig seit 2026-10-29: R6 und R35 entfallen; der Benutzername wird eingegeben (R54), keine Prüfung schreibt Daten.

Ort: R11, R12 Problem: R11 sagt „beim Speichern“ im Abschnitt Verbinden; ob ein Speichern nach R12 ebenfalls prüft und das Ergebnis zeigt, ist nicht eindeutig. Erforderlich: R11 ausdrücklich auf Verbinden und Ändern beziehen oder abgrenzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R67): R11 nennt Verbinden und Ändern.

Ort: R23, R24 Problem: Die Replik enthält auch Benutzer ohne Lizenz für conmeet-base. Ob die Auswahl in R24 sie anbietet und ob „Alle“ sie einschließt, ist offen. Praktisch wirkt es erst mit Lizenz (R8, Standard-Policy), die Anzeige „Zahl der Personen“ (Abschnitt 8) hängt aber davon ab. Erforderlich: Festlegen, ob nur lizenzierte Benutzer auswählbar und gezählt sind. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R8): R24 bietet und zählt nur Benutzer mit gültiger Lizenz für conmeet-base; R23 verweist auf READY.

Ort: R29, R35 Problem: R29 nennt einen „Verknüpfungsstatus“, ohne die Werte zu nennen (nicht verknüpft, verknüpft + Prüfzustand nach R17?). Die Zeile einer unverknüpften Instanz hat keine festgelegte Aktion und keinen Text. Erforderlich: Zustände und Anzeige je Zustand festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R60–R62 und R37): neue R71 mit „Nicht verknüpft“ und „Verknüpft“ samt Aktionen.

Ort: R54, R68, R44, R38, R49; Beispiel Schritt 5 Problem: Der Benutzername wird eingegeben, ConMeet bestätigt ihn nicht (R54), er sperrt aber je Instanz für alle anderen (R68, R44). Ein Tippfehler oder ein fremder Name blockiert den echten Inhaber dauerhaft, auch während die Verknüpfung ruht; lösen kann nur der Verursacher (R38), der Administrator nicht (R49). Zugleich kann ein Schlüssel von Ben unter dem Namen clara.schmidt gespeichert werden: Aktionen laufen in ConMeet unter Ben, vd:suite zeigt Clara. Schritt 5 des Beispiels funktioniert nur, weil Clara zuerst verknüpft hat. Erforderlich: Entscheiden, ob ein unbestätigter Name Eindeutigkeit erzwingen darf; wenn ja, einen Weg zur Auflösung festlegen (z. B. Administrator löst fremde Verknüpfung, Abgrenzung zu R49), wenn nein, R44/R68 auf das beschränken, was prüfbar ist. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: Risiko im Proof of Concept bewusst in Kauf genommen, eine Prüfung des Namens folgt später; vermerkt bei R54 und in US-15.

Ort: R57, R65, R44; Beispiel Schritt 5 Problem: Offen, ob der Server bei vergebenem Benutzernamen ConMeet noch aufruft und welcher Fehler kommt, wenn Name vergeben und Schlüssel abgelehnt sind (CONMEET_USER_ALREADY_LINKED oder CONMEET_CHECK_FAILED). Erforderlich: Reihenfolge festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, lokale Prüfung vor externem Aufruf): neue R79, Eindeutigkeit zuerst, bei vergebenem Namen kein Aufruf an ConMeet.

Ort: Abschnitt 7 (conMeetInstances), R14, R51 Problem: R14 zählt beim Trennen alle Verknüpfungen, die entfallen – ruhende eingeschlossen, da R15 sie löscht. R51 blendet ruhende in der Personenliste aus. Für die „Zahl der Verknüpfungen“ in conMeetInstances ist nicht gesagt, welche Zählung gilt; Liste und Trenn-Dialog können unterschiedliche Zahlen zeigen. Erforderlich: Zählung je Stelle festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R15 und R51): R14 zählt ruhende mit, conMeetInstances zählt nur aktive.

Ort: R39, R26, R37, Abschnitt 7 (checkMyConMeetAccount, unlinkConMeetAccount) Problem: R39 regelt nur Verknüpfen und Ersetzen. Was checkMyConMeetAccount und unlinkConMeetAccount für eine nicht berechtigte Instanz oder eine ruhende Verknüpfung tun (Fehler, Lösen erlaubt?), fehlt. Ersetzen einer ruhenden Verknüpfung nach Wiederberechtigung ist durch R39 gedeckt, Lösen einer ruhenden nicht – die Person sieht sie nicht (R26) und kann ihren Schlüssel nicht entfernen. Erforderlich: Verhalten beider Operationen festlegen; entscheiden, ob eine Person eine ruhende Verknüpfung löschen kann. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R26 und R39): neue R80, INSTANCE_NOT_GRANTED; ruhende Verknüpfung nicht lösbar.

Ort: Scope („nutzt die hier festgelegte Menge berechtigter Instanzen“), R30 Problem: Ohne Verknüpfung findet kein Zugriff statt (R30). Eine berechtigte, unverknüpfte Instanz ist in der Anrufinformation also nicht nutzbar; der Scope-Satz übergibt US-12 trotzdem die berechtigten. Erforderlich: Festlegen, welche Menge diese Spezifikation an US-12 übergibt, oder den Satz streichen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R30): Scope übergibt US-12 berechtigte und verknüpfte Instanzen.

Ort: gesamte Spezifikation Problem:

• R59 fehlt und ist nicht unter den entfallenen Nummern; unklar, ob eine Regel verloren ging.
• R58 und R50 sagen dasselbe (Schlüssel des Administrators ersetzt keine Verknüpfung) an zwei Stellen.
• Abschnitt 7, Zeile linkConMeetAccount, nennt R44, R54, R68 nicht, obwohl sie dort greifen. Erforderlich: R59 prüfen; Doppelung auflösen oder bewusst lassen; Verweise ergänzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung): R59 wurde nie vergeben, keine Regel fehlt; R50 (kein Rückgriff) und R58 (Zweck) bleiben getrennt; Verweise in Abschnitt 7 ergänzt.

Ort: R54, R84, Offene Fragen; US-11, US-15; Terminologie und SystemContext („Schlüssel des Administrators an der Instanz“) Problem:

• R54 nennt nur das Sperren eines fremden Namens. US-15 ergänzt „eine Prüfung folgt später“; weder die Offenen Fragen der Spezifikation noch Fragen.md führen diese spätere Prüfung.
• Dass R51 (Administrator) und R60 (Person) einen unbestätigten Namen anzeigen, steht nirgends.
• R84 steht nur in der Spezifikation. US-11 erwähnt das Risiko nicht, anders als US-15 für R54. Terminologie und SystemContext sagen „den er beim Verbinden … angibt“. Nach R12 und R84 kann der Schlüssel aber von einem anderen oder einem ausgeschiedenen Administrator stammen.
• R84 steht in Abschnitt 5 (Konto verknüpfen), regelt aber den Instanzschlüssel (Abschnitt 3 oder 6). Erforderlich: Festlegen, wo bekannte PoC-Risiken stehen (Regel, Offene Fragen, Story, Frage mit F-Nummer), und beide Risiken überall gleich führen; R84 in den passenden Abschnitt stellen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus den Entscheidungen zu U7 und L6): R54 nennt die Anzeige des unbestätigten Namens, Offene Fragen die spätere Bestätigung; R84 steht in Abschnitt 3; US-11 nennt das Risiko aus R84; Terminologie und SystemContext sagen „beim Verbinden oder Ändern … bleibt, bis ein Administrator ihn ersetzt“.

Ort: R23, R24, R25, R51; Abschnitt 7 (conMeetInstances) Problem: Bei gesetztem GrantedToAll ist nach R23 „jede Person des Mandanten“ berechtigt, auch ohne Lizenz. R51 zeigt „je berechtigter Person“ den Verknüpfungsstand. Offen ist, ob die Liste dann alle Replik-Benutzer zeigt oder nur lizenzierte wie R24. Ebenso offen ist, ob eine Einzelberechtigung erscheint, deren Benutzer die Lizenz inzwischen verloren hat. Erforderlich: Zusammensetzung der Personenliste für beide Fälle festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R24): R51 zeigt nur Benutzer mit gültiger Lizenz, bei „Alle“ alle lizenzierten des Mandanten.

Ort: R37, R61, R39, R80; US-10, US-15 („jederzeit selbst … lösen“) Problem: R37 und R61 erlauben Lösen und Ersetzen „jederzeit“. R39 und R80 schließen beides für nicht berechtigte Instanzen aus; eine ruhende Verknüpfung kann die Person nicht lösen. Die Stories versprechen dasselbe „jederzeit“. Erforderlich: „jederzeit“ in R37 und R61 auf berechtigte Instanzen einschränken; entscheiden, ob die Stories die Einschränkung nennen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R39 und R80): R37 und R61 gelten, solange die Person berechtigt ist; US-15 ebenso. US-10 bleibt, es ist nicht Gegenstand von 001.

Ort: Abschnitt 7 Problem:

• Zeile setConMeetInstanceGrantedToAll, grantConMeetInstance, revokeConMeetInstance verweist auf R21–R27; R70 (physisches Löschen beim Entzug) fehlt.
• Zeile myConMeetInstances nennt R29, nicht R71 (Verknüpfungsstatus).
• Zeilen connectConMeetInstance/updateConMeetInstance nennen R67, R73, R74, R82 nicht. Erforderlich: Verweise ergänzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung): Verweise in Abschnitt 7 ergänzt.

Diese Spezifikation (R20, R33): Verbindungsprüfungen laufen „synchron, nicht über die Outbox“; das Verknüpfen ruft ConMeet vor dem Speichern auf. AGENTS.md: „Alles, was eine Transaktionsgrenze überschreitet (Mail, Bus, externe HTTP-Aufrufe), läuft über die Outbox im selben Commit.“ Widerspruch: Die Projektregel kennt keine Ausnahme für lesende Aufrufe. Entscheidung erforderlich: Gilt die Ausnahme für lesende, wirkungslose Aufrufe? Wenn ja, gehört sie in AGENTS.md (Entscheidung des Nutzers, nicht dieser Spezifikation); wenn nein, sind R20 und R33 nicht umsetzbar wie beschrieben. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: AGENTS.md nimmt lesende Aufrufe ohne Wirkung im Fremdsystem von der Outbox-Regel aus; R20 und R57 bleiben.

Diese Spezifikation (R2, R16, R33): Jede Instanz hat eine eigene, je Mandant eindeutige Adresse; Aufrufe gehen an die Adresse der gewählten Instanz. Terminologie.md, ConMeet-Instanz: „der Benutzername entscheidet bei der Anmeldung, in welcher Instanz man landet“; SystemContext.md: „welche Instanz man erreicht, entscheidet der Benutzername“. Widerspruch: Teilen Live und Staging eine Adresse und unterscheiden sich nur über den Benutzer, verletzt die zweite Instanz R2, und eine Adresse identifiziert die Instanz nicht. Entscheidung erforderlich: Hat jede ConMeet-Instanz eine eigene Schnittstellenadresse? Wenn nein, braucht die Instanz ein anderes Unterscheidungsmerkmal und R2 entfällt. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: Live und Staging haben getrennte Adressen (R53), R2 bleibt. Terminologie.md und SystemContext.md zieht die nächste Interview-Sitzung nach.

Diese Spezifikation (R7, R8): Rolle conmeet-admin mit Berechtigung ManageInstances. Integrationsplan, Entscheidung 2: „offen – noch nicht bekannt … Rollenkatalog leer“; Onboarding- Entwurf: Produktrollen <offen>; Prüfung „Zugriff: Ausnahme“. Widerspruch: Beide Dokumente beschreiben einen anderen Stand des Rollenkatalogs. Entscheidung erforderlich: Gilt R7 als Entscheidung 2 (dann Integrationsplan und Onboarding- Anfrage nachziehen), oder bleibt R7 bis zur Bestätigung durch Core ein Vorschlag? Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: die Spezifikation gilt. Integrationsplan führt Entscheidung 2 als vorläufig mit conmeet-admin, die Onboarding-Anfrage nennt die Rolle; Bestätigung durch Core bleibt offene Frage der Spezifikation.

Diese Spezifikation: legt Anbindung je Mandant fest (Instanz, Schlüssel, Aufrufe). architecture.md: „Anbindung des ConMeet-ERP: zurückgestellt, bis API, Authentifizierung und Mandantenbezug geklärt sind“; Integrationsplan: WP9 „wartet auf Entscheidung 5“. Widerspruch: Die Spezifikation setzt voraus, was die Architektur als ungeklärt zurückstellt; API und Authentifizierung sind auch hier offen (R16, R33). Entscheidung erforderlich: Ist Entscheidung 5 durch diese Spezifikation gefallen (Anbindung je Instanz mit Schlüssel, Mandantenbezug über den vd:suite-Mandanten)? Dann Architektur und Integrationsplan nachziehen; sonst bleibt die Umsetzung blockiert. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: die Spezifikation gilt. Entscheidung 5, WP9 und architecture.md verweisen auf 001; offen bleibt die Erreichbarkeit aus dem Cluster.

Diese Spezifikation (R13, R15, R26, R27): Ändern behält, Trennen löscht, Entzug lässt ruhen. userStories.md, US-11 und US-16: „… ist offen (F-025)“ bzw. „… ist offen (F-026)“. Widerspruch: Die Fragen sind in Fragen.md beantwortet, die Stories noch nicht nachgezogen. Entscheidung erforderlich: Antworten in US-11 und US-16 einarbeiten (nächste Interview-Sitzung). Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, Antworten von Martin Linkwitz liegen vor): US-11 und US-16 nachgezogen, F-025 und F-026 auf „eingearbeitet“.

Diese Spezifikation (R32): Jede Person gibt ihren persönlichen Schlüssel ein. quality.md, Qualität 2: „keine Schlüssel abschreiben – Schlüssel ‚für die Nutzer nicht bedienbar‘“. Widerspruch: Bekannt und in US-15 als Übergangslösung benannt (F-020), in der Spezifikation aber nicht als bewusste Ausnahme von Qualität 2 vermerkt. Entscheidung erforderlich: Ausnahme für den Proof of Concept ausdrücklich festhalten oder ein Ziel nennen, das Qualität 2 trotzdem stützt (z. B. Zeitrahmen aus F-014). Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus US-15): die Übersicht nennt die bewusste Abweichung für den Proof of Concept.

Diese Spezifikation (R55, R52): Der Administrator gibt „seinen persönlichen Schlüssel“ an; „ConMeet kennt keinen Schlüssel je Instanz“; jeder Schlüssel ist ein Token „im ConMeet-Konto einer Person“. Terminologie.md: Begriff „Schnittstellenschlüssel der Instanz“; SystemContext.md, Betriebsumfeld: dasselbe; userStories.md, US-11: „einen Schnittstellenschlüssel, den er zuvor in ConMeet erzeugt hat“ und „einen Kommentar“ als Pflichtangabe neben Adresse und Namen (R55: Kommentar optional). Widerspruch: Die Anforderungsdokumente beschreiben einen eigenen Schlüsseltyp je Instanz, den es laut Spezifikation nicht gibt. Entscheidung erforderlich: Gilt R55? Dann Begriff, Betriebsumfeld und US-11 nachziehen (nächste Interview-Sitzung); Kommentar in US-11 als optional kennzeichnen oder R55 ändern. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: R55 gilt; Terminologie und Systemkontext führen „Schlüssel des Administrators an der Instanz“, US-11 nennt den persönlichen Schlüssel und den Kommentar als optional.

Diese Spezifikation (R53): Jede Instanz, „auch Live und Staging desselben Betriebs, hat eine eigene Adresse“. Terminologie.md, ConMeet-Instanz: „der Benutzername entscheidet bei der Anmeldung, in welcher Instanz man landet“; SystemContext.md, Umgebungen von ConMeet: „welche Instanz man erreicht, entscheidet der Benutzername“. Widerspruch: Bei C2 als nachzuziehen vermerkt, heute unverändert. Dazu nennt R53 und Beispiel Schritt 2 https://dev.conmeet.io als Adresse einer Betriebs-Instanz – ein gemeinsamer Host, der eher die Lesart der Terminologie stützt: Zwei Instanzen eines Betriebs auf diesem Host scheitern an R2. Entscheidung erforderlich: Terminologie und Systemkontext auf R53 bringen; bestätigen, dass eine Instanz auf einem gemeinsamen Host wie dev.conmeet.io eine eigene Adresse (Pfad nach R75) hat, sonst ein anderes Beispiel wählen. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz (eigene Adresse je Instanz): Terminologie und Systemkontext nachgezogen; dev.conmeet.io bleibt die Adresse der Staging-Instanz im Beispiel.

Diese Spezifikation (R54, Scope): Nur der eingegebene Benutzername; weitere Angaben nicht im Scope. userStories.md, US-15: „einige Angaben zu ihrem ConMeet-Benutzer; welche, ist offen (F-023)“; die Person gibt dort nur den Schlüssel ein, keinen Benutzernamen. Fragen.md, F-023: beantwortet mit R54. Widerspruch: Antwort liegt vor, Story nicht nachgezogen. Entscheidung erforderlich: Antwort in US-15 einarbeiten (Benutzername eingeben, keine weiteren Angaben), F-023 auf „eingearbeitet“. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, Antwort auf F-023 liegt vor): US-15 mit Benutzernamen, F-023 eingearbeitet.

Diese Spezifikation / Integrationsplan, Entscheidung 5: Public API mit persönlichem Token als Bearer-Token je Instanz (R52, R53); Entscheidung 5 verweist auf 001. userStories.md, US-10 und US-11, Technische Vorgaben: „Offen: Wie ConMeet je Mandant angebunden wird (Q2: Entscheidung 5).“ Widerspruch: Entscheidung 5 ist gefallen, die Stories führen sie als offen. Entscheidung erforderlich: Vorgabe in US-11 durch die Entscheidung ersetzen; in US-10 auf die noch offene Anmeldung bei ConMeet beschränken. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, Entscheidung 5 liegt vor): US-11 nennt die Anbindung, in US-10 entfällt die Zeile.

Diese Spezifikation (R69): Beim Mandantenwechsel werden InstanceGrant und AccountLink im bisherigen Mandanten physisch gelöscht. Integrationsplan, Prüfung Replikation: „Umzug mit gleicher IdentityId ohne Konflikt; Mandantendaten und Audit-Namen bleiben“ – erfüllt. Widerspruch: Ob Berechtigung und Verknüpfung „Mandantendaten“ (bleiben) oder benutzereigene Daten (werden gepurgt) sind, ist in beiden Dokumenten verschieden eingeordnet; der Umzug-Pfad löscht bisher nichts. Entscheidung erforderlich: Einordnung bestätigen; gilt R69, Prüfzeile im Integrationsplan um benutzereigene Daten beim Umzug ergänzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R5): R69 bleibt; Prüfzeile Replikation im Integrationsplan nennt die Löschung beim Umzug.

Diese Spezifikation (R28): stützt sich auf SuiteReplica.RemoveUserAsync bei UserDeleted und Backfill. architecture.md: „nur die (noch fehlende) Replikation schreibt sie“; Stand Replikation „geplant“. Integrationsplan, WP3: erledigt; backend-development.md: beschreibt RemoveUserAsync. Widerspruch: architecture.md ist veraltet gegenüber den Dokumenten, auf die R28 baut. Entscheidung erforderlich: architecture.md auf den Stand von WP3 bringen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus WP3 im Integrationsplan): architecture.md nachgezogen.

Diese Spezifikation (Offene Fragen): „Die Onboarding-Anfrage nennt die Rolle bisher nicht (F-002).“ Integrationsplan, Onboarding, Produktrollen: conmeet-admin | „Administrator des Betriebs“ Widerspruch: Die Anfrage nennt die Rolle seit C3. Offen ist nur noch die Bestätigung durch Core. Entscheidung erforderlich: Offene Frage auf die Bestätigung durch Core kürzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, Integrationsplan nennt die Rolle): Offene Frage auf die Bestätigung durch Core gekürzt.

Diese Spezifikation (Scope, US-12): „bietet nur Instanzen an, für die die Person berechtigt ist (R22) und eine Verknüpfung hat (R30)“. userStories.md, US-12: „Zur Auswahl stehen nur Instanzen, für die die Person berechtigt ist (US-16).“ US-10: „Ohne Verknüpfung zeigt die Anrufinformation … nur den Hinweis, dass die Verknüpfung fehlt, und den Weg dorthin.“ Widerspruch: Nach US-12 und US-10 ist eine berechtigte, unverknüpfte Instanz wählbar und zeigt den Hinweis. Nach dem Scope erscheint sie nicht. Entscheidung erforderlich: Welche Menge US-12 anbietet. Danach Scope-Zeile oder US-12 angleichen. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: US-12 bietet alle berechtigten Instanzen an; Scope-Zeile angeglichen, die Festlegung aus U11 ist damit ersetzt.

Diese Spezifikation (R28, R69, Abschnitt 1): InstanceGrant und AccountLink liegen in ConMeet.Core/Features/Instances/; „SuiteReplica.RemoveUserAsync löscht seine InstanceGrant und AccountLink physisch mit“. AGENTS.md, Vertikalen-Richtung: „Features dürfen Querschnitt nutzen, Querschnitt nie Features – geprüft von LayerDirectionTests.“ SuiteReplica liegt in Crosscutting/Suite/ (backend-development.md). Widerspruch: Kennt RemoveUserAsync die Entitäten der Vertikale, verletzt es die Schichtrichtung. backend-development.md („Benutzereigene Daten … purgt SuiteReplica.RemoveUserAsync mit“) nennt keinen Weg ohne diese Abhängigkeit. Entscheidung erforderlich: Wie die Vertikale beim Entfernen und beim Umzug mitlöscht, ohne dass die Replik sie kennt. Möglich sind ein Erweiterungspunkt, den die Vertikale registriert, oder Fremdschlüssel mit Kaskade. R28 und R69 nennen dann das Ergebnis statt der Methode. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, Martin Linkwitz ohne Vorliebe): R28 entfällt; R86 nennt das Ergebnis, R87 einen Erweiterungspunkt der Replik, den die Vertikale registriert – nur er deckt Entfernen und Mandantenwechsel samt Audit ab. backend-development.md nachgezogen.

Ort: Fragen.md, Sitzungsprotokoll 2026-10-29-martin-linkwitz-3.md, Quellen.md, SystemContext.md Problem:

• Fragen.md: F-023, F-025 und F-026 stehen auf „eingearbeitet“, aber unter „Offen“. F-021 und F-027 mit demselben Status stehen unter „Erledigt“.
• Sitzungsprotokoll, Abschnitt Fragen: F-023, F-025 und F-026 seien „noch nicht in die Stories eingearbeitet“. Die Tabelle „Änderungen am Zielbild“ desselben Protokolls und Fragen.md sagen eingearbeitet. Weiter nennt es unter „Quellen“ „Spezifikationen: keine“, führt aber Q3 neu. Unter „Widersprüche und Entscheidungen“ steht „keine“, obwohl Martin Linkwitz entschieden hat: eigene Adresse je Instanz, persönlicher Schlüssel des Administrators, PoC-Risiko R54.
• Quellen.md, Q3: „— (noch nicht eingearbeitet)“, obwohl US-11, US-15 und US-16 aus Q3 nachgezogen sind.
• Derselbe Schlüssel heißt in Terminologie.md „Persönlicher Schnittstellenschlüssel“, in SystemContext.md (Betriebsumfeld) „ConMeet-Schnittstellenschlüssel“. Entscheidung erforderlich: Stand in Fragen, Protokoll und Quellen angleichen, einen Begriff wählen (nächste Interview-Sitzung). Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung): F-023, F-025, F-026 unter „Erledigt“; Sitzungsprotokoll nennt Q3, die Entscheidungen und den Stand der Fragen; Q3 in Quellen.md „aktuell“; SystemContext führt „Persönlicher Schnittstellenschlüssel“ wie die Terminologie.

Problem: Endpunkt der Verbindungsprüfung (R16), Endpunkt für den aktuellen Benutzer (R33) und die Übergabe des Schlüssels fehlen; steht unter Offene Fragen. Auswirkung: R16, R17, R33–R36 sind ohne diese Angaben nicht umsetzbar, R17 setzt zudem voraus, dass ConMeet abgelehnte Schlüssel mit 401/403 beantwortet. Erforderlich: Endpunkte und Authentifizierung klären oder eine Schnittstelle im Code festlegen, hinter der beide Aufrufe austauschbar sind. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: Prüfendpunkt /account/social/status (R16, R33), Schlüssel als Bearer-Token (R52). Welche Antwortfelder Benutzername und Anzeigename tragen, steht unter Offene Fragen der Spezifikation.

Problem: R5 verlangt denselben Mandanten für Instanz und Benutzer. Der Integrationsplan kennt einen Umzug mit gleicher Identität. Was mit Berechtigungen und Verknüpfungen beim Umzug geschieht, steht nicht da (R28 deckt nur das Entfernen). Erforderlich: Regel für den Umzug ergänzen (z. B. wie Entfernen behandeln). Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R5): neue R69, Umzug löscht wie R28.

Problem: R15 und R37 löschen physisch; für revokeConMeetInstance fehlt die Löschart. Bei Soft Delete kollidiert eine erneute Berechtigung mit der Eindeutigkeit aus R4, sofern der Index soft gelöschte Zeilen nicht ausnimmt. Erforderlich: Löschart für InstanceGrant festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, folgt aus R4, R15, R37): neue R70, physisches Löschen.

Problem: R40 nimmt den Schlüssel aus der Konfiguration; was ohne ihn geschieht (Start verweigern?) und ob er gewechselt werden kann, fehlt. Erforderlich: Verhalten ohne Schlüssel festlegen; Schlüsselwechsel festlegen oder als nicht vorgesehen abgrenzen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung): neue R72, ohne gültigen Schlüssel kein Start, kein Schlüsselwechsel vorgesehen.

Problem: Gesammelte Kleinigkeiten:

• Kein Verhalten bei gleichzeitigem Bearbeiten derselben Instanz (Zeilenversion xmin), kein Fehlercode dafür in R45.
• Meldungstexte zu INSTANCE_NAME_TAKEN, INSTANCE_URL_TAKEN, INSTANCE_URL_INVALID fehlen.
• Längengrenzen für Adresse und Schlüssel fehlen; R2 sagt nicht, ob Pfad und Port zur Normalisierung gehören.
• Keine Obergrenze gleichzeitiger Prüfungen beim Öffnen der Seite (R18) bei vielen Instanzen.
• Navigationseinträge zu /verwaltung/conmeet-instanzen und /conmeet-verbindungen sind nicht benannt (nur „blendet ein“, R9). Erforderlich: Je Punkt eine Festlegung oder bewusstes Offenlassen unter Offene Fragen. Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz (übliche Werte): R73 INSTANCE_CHANGED, R74 Längen, R75 Pfad und Port, R76 höchstens fünf Prüfungen gleichzeitig, R77 Meldungen, R78 Navigation.

Ort: R55, R12, R58, R28, R69, R49, R50 Problem: AdminKey ist der persönliche Token eines bestimmten Administrators (R55, R52), das Datenmodell hält nicht fest, wessen. Ändert ein zweiter Administrator die Instanz mit leerem Schlüsselfeld, bleibt der Token des ersten (R12). Scheidet der Inhaber aus (R28, R69) oder verliert er conmeet-admin, bleibt sein Token gespeichert und wird bei jeder Prüfung genutzt – R28 löscht nur Berechtigungen und Verknüpfungen. R49 verbietet Schlüssel für andere, ist aber mangels Endpunkt für den eigenen Benutzer (R54) nicht prüfbar. R50 und R58 bleiben stimmig: der Token dient nur der lesenden Prüfung. Erforderlich: Festlegen, ob der Inhaber des AdminKey gespeichert und angezeigt wird, was beim Ausscheiden oder Rollenentzug mit dem Token geschieht, und ob R49 auch für AdminKey gilt (dann als organisatorische Regel kennzeichnen). Aufgelöst am 2026-10-29 durch Entscheidung von Martin Linkwitz: für den Proof of Concept in Kauf genommen; neue R84 hält fest, dass der Inhaber nicht gespeichert wird und der Schlüssel bis zum Ersetzen oder Trennen bleibt.

Ort: R54, R62, R74, R66, R77 Problem:

• ConMeetUserName: keine Länge, keine Aussage zu Pflicht, Leerzeichen am Rand.
• Name (1–100) und Comment (0–1000) haben Grenzen, aber keinen Fehlercode; R66 kennt keinen Code für Eingabefehler (leeres Pflichtfeld, Länge überschritten nach R74).
• R77 nennt Meldungen nur für vier Codes; INSTANCE_NOT_FOUND, INSTANCE_NOT_GRANTED und CONMEET_CHECK_FAILED haben keine. Erforderlich: Je Punkt eine Festlegung. Aufgelöst am 2026-10-29 durch specification-fixer (übliche Werte wie bei L5): R81 Benutzername, R82 INVALID_INPUT, R83 weitere Meldungen.

Ort: R66, R80, R46; Abschnitt 7 (checkMyConMeetAccount, checkConMeetInstance, unlinkConMeetAccount) Problem: R66 regelt stabile Codes nur für „Fehler der Mutationen“. checkMyConMeetAccount (R80) und checkConMeetInstance (R46) sind Queries und liefern trotzdem INSTANCE_NOT_GRANTED bzw. INSTANCE_NOT_FOUND. Für eine berechtigte Instanz ohne eigene Verknüpfung fehlt das Ergebnis von checkMyConMeetAccount und unlinkConMeetAccount: Fehler mit Code, leeres Ergebnis oder wirkungslos. Erforderlich: R66 auf Queries ausdehnen; Verhalten und gegebenenfalls Code und Meldung für „keine Verknüpfung“ festlegen. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung): neue R89 – Codes gelten für Queries; ohne Verknüpfung ACCOUNT_NOT_LINKED beim Prüfen, Lösen ohne Wirkung.

Ort: R40, R72; deployment-handover.md (Umgebungsvariablen) Problem: R72 verweigert den Start bei fehlendem oder „ungültigem“ Schlüssel. Konfigurationsname, Format und Länge stehen nirgends, „ungültig“ ist damit nicht prüfbar. Zum Vergleich nennt die Übergabe für TOKEN_ENCRYPTION_KEY „64 Hex-Zeichen“. Die Übergabe kennt den neuen Pflichtwert noch nicht; ohne ihn startet der Dienst nach R72 nicht. Erforderlich: Name, Format und Länge festlegen; vermerken, dass die Übergabe den Wert mit der Umsetzung aufnimmt. Aufgelöst am 2026-10-29 durch specification-fixer (eigene Entscheidung, wie TOKEN_ENCRYPTION_KEY): neue R88 – Secrets:EncryptionKey, 64 Hex-Zeichen; die Übergabe nimmt ihn mit der Umsetzung auf.