S•U•S•I - Qualitätsmanagement für immoSoR

Nicht jeder Seitenwechsel ist ein neuer Arbeitstag

Das Öffnen einer weiteren Seite innerhalb desselben Arbeitsraums erzeugt keinen neuen QM-Lauf. Auch ein Reload des Dashboards, der Wechsel zwischen Objektansichten, das Öffnen eines Drawers, die Navigation innerhalb derselben Rolle oder das Aktualisieren eines Browser-Tabs sind für sich genommen kein neuer Trigger.

Die Prüfung bleibt an den bereits festgestellten Tageszustand gebunden. Dadurch werden wiederholte Einladungen, doppelte Läufe, unnötige Wartezeiten und widersprüchliche Tagesnachweise vermieden. Die Oberfläche bleibt ruhig, und der QM-Prozess fügt sich in den Arbeitsfluss ein.

Der Tageszustand folgt dem Prinzip „Key and Lock“

Ein gültiger Tageszustand wird durch einen eindeutigen Schlüssel beschrieben. Nur wenn alle Bestandteile dieses Schlüssels übereinstimmen, darf ein vorhandener Zustand wiederverwendet oder fortgesetzt werden.

Der fachliche Tages-Key setzt sich mindestens zusammen aus:

• Tagesdatum in Europe/Berlin,
• company_id,
• role_code,
• user_id,
• App-Version,
• Funktionsregister-Version.

Diese Kombination bildet den fachlichen Key. Der gespeicherte Tageszustand bildet den zugehörigen Lock. Nur ein vollständig passender Schlüssel darf den vorhandenen Zustand öffnen oder fortsetzen. Abweichende Kontexte werden nicht still miteinander verbunden.

Das Tagesdatum in Europe/Berlin

Der Tagesbezug richtet sich nach der lokalen Zeitzone Europe/Berlin einschließlich Sommer- und Winterzeit. Dadurch bleibt eindeutig, welchem Arbeitstag ein Lauf zugeordnet ist.

Technische Speicherung kann weiterhin in UTC erfolgen. Die sichtbare Tageslogik verwendet jedoch konsistent Berliner Zeit. Ein Lauf kurz vor oder nach Mitternacht darf nicht durch unterschiedliche Zeitzonen falsch zugeordnet werden.

Der Tageswechsel kann einen neuen Prüfanlass begründen. Das Datum allein reicht jedoch nicht aus. Auch Mandant, Rolle, Nutzer und Versionsstände müssen übereinstimmen.

Mandant, Rolle und Nutzer als feste Bindung

Der Tageszustand ist immer an den aktiven Mandanten gebunden. Ein Ergebnis aus Unternehmen A darf nicht für Unternehmen B gelten. Die company_id begrenzt Funktionsregister, Datenraum, Rollenbindung, Nachweis und Tagesquittung.

Ein Mandantenwechsel erzeugt einen neuen Arbeitskontext. Der bisherige Tageszustand darf nicht weiterverwendet werden. Abweichende Mandantenwerte aus Request, Session oder manipuliertem Link werden verworfen. Fehlt eine eindeutige Mandantenbindung, arbeitet das System Fail-Closed.

Gleiches gilt für die aktive Rolle. Ein Makler-Tagescheck darf nicht automatisch für den Affiliate- oder Assistenzkontext gelten. Jede Rolle besitzt ein eigenes Funktionsregister, eigene Capabilities, eigene Datenreichweiten und eigene Kernarbeitsbereiche.

Ein Rollenwechsel führt zu einer neuen Scope-Auflösung, einer neuen Schutzprüfung und gegebenenfalls zu einem neuen QM-Angebot. Mehrfachrollen werden nicht zu einer Rechteunion zusammengeführt. Für jeden Request und jeden Tageszustand gilt genau ein aktiver Rollen- und Arbeitskontext.

Auch die user_id gehört fest zum Tages-Key. Der Tageszustand gilt ausschließlich für den angemeldeten Nutzer. Ein Ergebnis darf nicht auf andere Personen übertragen werden. Gemeinsames Gerät oder identischer Browser begründen keine gemeinsame Prüfung.

Die Bindung an die Nutzeridentität schützt die Nachweisspur. Sie dient nicht der Leistungs- oder Anwesenheitsüberwachung.

App-Version und Funktionsregister-Version

Ein Tagesergebnis gilt nur für die tatsächlich geprüfte App-Version. Ändern sich relevante Routen, Services, Schutzmechanismen, Assets oder Konfigurationen, kann ein neuer Test sinnvoll sein.

Eine rein kosmetische Änderung muss jedoch nicht automatisch einen neuen Lauf auslösen. Deshalb wird unterschieden, ob eine Version prüfrelevant oder nicht prüfrelevant ist. Der Tagesnachweis dokumentiert den tatsächlich geprüften Programmstand.

Auch die Funktionsregister-Version ist Teil des Tages-Keys. Das Register bestimmt, welche Funktionen für die aktive Rolle geprüft werden. Eine neue Pflichtfunktion, geänderte Capability, zusätzliche Schutzbedingung, neue Zuweisung oder entfernte Funktion kann ein bisher gültiges Ergebnis unvollständig machen.

Ein altes Ergebnis bestätigt nur den damals gültigen Prüfumfang. Neue Anforderungen dürfen nicht still durch einen früheren grünen Status abgedeckt werden.

Der zusammengesetzte Tages-Key

Der eindeutige Tages-Key lässt sich vereinfacht so darstellen:

Europe/Berlin-Datum + company_id + role_code + user_id + App-Version + Funktionsregister-Version = eindeutiger Tages-Key

Nur bei vollständiger Übereinstimmung ist der bestehende Tageszustand wiederverwendbar. Bereits eine relevante Abweichung kann einen neuen Prüfanlass begründen.

Der Tages-Key verhindert kontextfremde Wiederverwendung, Rollenvermischung, Mandantenüberschreitung, veraltete Versionsnachweise und unvollständige Funktionsabdeckung.

Statusprüfung vor der Einladung

Nach Bildung des Tages-Keys sucht das System nach einem passenden Lauf oder Tagesstatus. Mögliche Zustände sind: kein Lauf vorhanden, vorbereitet, gestartet, unterbrochen, abgeschlossen, ungültig oder fehlgeschlagen.

Erst danach entscheidet S•U•S•I über die Nutzeransprache. Ein abgeschlossener und weiterhin gültiger Lauf erzeugt keine neue Einladung. Ein unterbrochener Lauf führt zunächst zur Fortsetzung. Ein neuer Lauf wird nur angeboten, wenn tatsächlich ein Bedarf besteht.

Die Einladung bleibt dabei freiwillig.

Fortsetzen statt doppelt starten

Existiert ein passender unterbrochener Lauf, wird er nicht durch einen neuen Lauf ersetzt. Die Fortsetzung bleibt an Run-ID, Tages-Key, Nutzer, Mandant, Rolle und Versionsstände gebunden.

Ein Reload oder Browserabbruch darf keinen parallelen Lauf erzeugen. Wiederholte Startanfragen werden idempotent verarbeitet. Fremde, manipulierte oder veraltete Fortsetzungen werden abgewiesen.

Der Nutzer kehrt zum letzten bestätigten Prüfschritt zurück. Dadurch bleibt der Prozess bruchfrei und nachweisbar.

Relevante und irrelevante Änderungen

Auch innerhalb desselben Kalendertages kann ein neuer Prüfanlass entstehen. Relevante Änderungen sind insbesondere:

• Mandantenwechsel,
• Rollenwechsel,
• neue App-Version,
• neue Funktionsregister-Version,
• wesentliche Capability-Änderung,
• neue oder entzogene Zuweisung,
• kritischer technischer Befund.

Ein neuer Lauf muss daraus nicht in jedem Fall automatisch folgen. Das System kann einen neuen Check empfehlen, eine Teilprüfung anbieten oder bei betroffener Schutzbedingung einen vollständigen Lauf verlangen.

Irrelevante Änderungen lösen dagegen keinen neuen Tagescheck aus. Dazu gehören etwa reine Textkorrekturen, ein unverändertes Layout mit neuem Cache-Buster, Seitenwechsel innerhalb desselben Arbeitsbereichs oder das erneute Öffnen eines bereits geprüften Drawers.

Eine zu empfindliche Triggerlogik würde Nutzer belasten, unnötige Läufe erzeugen, widersprüchliche Protokolle schaffen und den Tagesablauf dominieren. Deshalb wird klar festgelegt, welche Änderungen den Tages-Key oder seine Gültigkeit tatsächlich beeinflussen.

Trigger ist nicht gleich Prüfzwang

Auch wenn ein neuer Prüfanlass erkannt wurde, bleibt der Tagescheck freiwillig. Der Trigger bedeutet zunächst nur, dass S•U•S•I eine neue Einladung anbieten darf.

Der Nutzer kann weiterhin zwischen Jetzt starten, Später erinnern und Heute nicht mehr anzeigen wählen. Nur unabhängig festgestellte kritische Schutzprobleme dürfen die konkret betroffene Funktion sperren.

Der Trigger selbst ist keine Zugriffssperre. Er ist die kontrollierte Entscheidung, ob ein QM-Angebot fachlich sinnvoll ist.

Sicherheit bleibt Fail-Closed

Die Freiwilligkeit der Prüfung ändert nichts an den grundlegenden Schutzregeln. Eindeutiger Mandant, gültige Rollenbindung, sichere Sitzung, zulässige Capability, zulässiger Scope und Wirtschaftsmodus LOCKED bleiben zwingend.

Fehlt eine dieser Schutzbedingungen, darf das System keinen ungebundenen Tageszustand erzeugen. Der Fall wird als technischer oder kritischer Befund behandelt.

Die Einladung ist freiwillig. Die Sicherheit ist es nicht.

Sperren gegen Doppel- und Parallelläufe

Für denselben Tages-Key darf nicht gleichzeitig mehr als ein aktiver Tageslauf bestehen. Eine Lauf-Sperre verhindert doppelten Start, parallele PDF-Erzeugung, doppelte Arbeitsprotokolle und widersprüchliche Gesamtstatus.

Die Sperre wird nach Abschluss, kontrolliertem Abbruch oder definiertem Timeout aufgelöst. Verwaiste Sperren dürfen nur nach Prüfung und mit Auditspur behandelt werden.

Ein abgeschlossener Lauf bleibt über seine Run-ID eindeutig referenzierbar.

Der Trigger bleibt nachvollziehbar

Das System protokolliert, warum ein Lauf angeboten oder erneut empfohlen wurde. Mögliche Triggergründe sind:

• first_login_of_day,
• manual_start,
• role_changed,
• tenant_changed,
• app_version_changed,
• function_registry_changed,
• resume_available,
• recheck_requested.

Dadurch bleibt nachvollziehbar, warum die Einladung erschien, welcher Kontext zugrunde lag und ob ein neuer Lauf tatsächlich erforderlich war. Die Triggerinformation gehört zur Lauf- und Auditspur.

Der erste Login ist kein Anwesenheitsnachweis

Der Begriff erster Login darf nicht als Arbeitszeit- oder Anwesenheitskontrolle verstanden werden. Das System bewertet nicht, wann jemand mit der Arbeit begonnen hat, ob ein Login früh oder spät erfolgte, wie lange jemand angemeldet war oder wie häufig das System geöffnet wurde.

Der erste Login ist lediglich ein technischer Gelegenheitspunkt für die Statusprüfung. Ein fehlender Login oder ein ausgelassener QM-Lauf erzeugt keinen Personalbefund.

Verhalten bei gültigem oder verändertem Kontext

Wird ein vollständig passender und abgeschlossener Tageszustand gefunden, erscheint keine erneute Einladung. Der Status wird kompakt angezeigt, PDF und Protokoll bleiben abrufbar und der Nutzer kann normal weiterarbeiten.

Ein manueller Wiederholungstest bleibt möglich. Er erzeugt eine neue Run-ID und eine neue Revision. Der frühere Nachweis bleibt unverändert erhalten.

Wird dagegen eine relevante Kontextabweichung erkannt, wird der bisherige Tageszustand nicht gelöscht. Seine Gültigkeit bleibt auf den früheren Kontext begrenzt. Für den neuen Kontext wird ein neuer Prüfanlass erzeugt und verständlich begründet.

Ein Wechsel vom Makler- in den Affiliate-Kontext bedeutet deshalb: Der frühere Nachweis bleibt bestehen, das neue Funktionsregister wird aufgelöst und ein neuer Tagescheck kann angeboten werden. Kontextwechsel erzeugt eine neue Prüfung, nicht eine Rechteunion.

Auch bei einer prüfrelevanten Versionsänderung bleibt der alte Nachweis unverändert. Ein neuer Lauf erhält eine neue Versionsbindung, während die Historie vollständig erhalten bleibt.