realERP
QS-Gate

Das QS-Gate spielt nach jeder Änderung die komplette realERP-Anwendung durch – Schnittstellen, Oberfläche, Datenbank und Geschäftsprozesse –, vergleicht jedes Ergebnis mit dem zuletzt freigegebenen Stand und entscheidet nachvollziehbar über die Freigabe.

Es besteht aus zwei Teilen: dem Prüfstand, der den automatischen Prüflauf ausführt, und dem Cockpit, in dem Sie die Ergebnisse auswerten, Abweichungen freigeben und Prozesse im Prozess-Studio abspielen oder aufnehmen.

Was das QS-Gate leistet

• Spielt nach jeder Änderung die komplette App durch – API, Oberfläche, Datenbank, Prozesse.
• Vergleicht jedes Ergebnis mit dem zuletzt freigegebenen Stand (Referenz) und zeigt jede Abweichung.
• Bündelt Fehler nach Ursachen und erzeugt daraus einen Prüfauftrag für das (KI-)Entwicklungsteam.
• Entscheidet über die Freigabe nach festen Muss-Kriterien – mit Vier-Augen-Prinzip und Protokollkette.
• Macht Qualität über viele Läufe sichtbar: Verlauf, Stabilität, Leistung, Vergleich.

Grundprinzipien

Zwei Begriffe, die man auseinanderhalten muss

Aufbau dieses Handbuchs

Teil A erklärt Ablauf, Schnelllauf, Bewertung und Freigabe. Teil B beschreibt jeden Menüpunkt des Cockpits in der Reihenfolge der Navigation – mit Zweck, Bildschirmfoto, Bedienung und Tipps. Teil C enthält Arbeitsanleitungen (Prüfauftrag und Pakete, Prozess-Studio, Prüfbericht), Teil D die Prüfinhalte (Fachprüfung Rechnungswesen, Sonderfälle und Ketten, Prozesskatalog, neue Prüfdimensionen, Prozessvarianten 9v, SAP-Abgleich, Variantenläufe mit Reihenfolge und Zeitmodus), Teil E Schnittstelle, Betrieb und Rollen, Teil F FAQ, Glossar und Änderungsprotokoll.

In fünf Minuten vom Login zur Antwort auf die Frage „Darf diese Version zum Kunden?“.

Anmelden über die Landingpage

1. Landingpage öffnen. Die Adresse des Prüfstands aufrufen; ohne Anmeldung erscheint die Landingpage (/anmelden) mit Kurzüberblick über Leistung, Funktionen und Ablauf.
2. „Anmelden“ bzw. „Zum Cockpit“ wählen. Das Formular rechts wird fokussiert.
3. Name eintragen. Ihr Name steht später an jeder Freigabe, jeder Befund-Bearbeitung und im Änderungsprotokoll – bitte den echten Namen verwenden.
4. Gemeinsames Passwort des Prüfstands eingeben und „Anmelden“. Das Passwort erhalten Sie vom QS-Team; es steht nie in Unterlagen.
5. Sitzung. Die Anmeldung gilt 12 Stunden. „Abmelden“ finden Sie in der Fußzeile der Navigation.

Der Bildschirm im Überblick

Erster Blick in drei Schritten

1. Cockpit öffnen. Oben steht das Urteil des letzten Laufs, darunter die Freigabe-Entscheidung GO / NO-GO mit Qualitätspunkten. Rote Kriterien mit dem Zusatz „muss“ entscheiden – siehe Bewertung.
2. „Abweichungen prüfen“. Zeigt, was sich gegenüber der Referenz geändert hat. Zuerst nach „kritisch“ filtern.
3. „Befunde“ bzw. „Ursachen“. Zeigt, was kaputt ist – gebündelt nach gemeinsamer Ursache. Für die Entwicklung den Gesamt-Prüfauftrag (MD) herunterladen.

Tastenkürzel

Mit ? zeigt das Cockpit diese Übersicht jederzeit an.

Befehlspalette

Die Palette (Strg+K oder Lupe in der Kopfzeile) findet Seiten, Bereiche, Szenarien und Tabellen des gewählten Laufs. Ab zwei Zeichen bietet sie zusätzlich „„…“ in allen Beobachtungen suchen“ an – das öffnet den Reiter Suche. Navigation mit ↑ ↓, öffnen mit Enter.

Automatisch, reproduzierbar, nachvollziehbar: Jede neue Version startet auf demselben Datenstand mit eingefrorener Uhr – nur echte Änderungen fallen auf.

Wie ein Lauf startet

• Automatisch: Der Prüfstand fragt den Gesundheits-Endpunkt der QS-API regelmäßig ab (standardmäßig jede Minute). Meldet sie eine neue Version, startet der Lauf nach 180 Sekunden.
• Manuell: Schaltfläche Lauf starten in der Kopfzeile. Ist ein automatischer Reset eingerichtet (Deploy-Hook oder Neustart des API-Dienstes), wird das QS-Gate vorher auf den Golden-Record zurückgesetzt (einige Minuten). Ohne Reset warnt das Cockpit: Der Lauf startet dann mit den Daten des Vorlaufs und ist nicht vergleichbar (Muss-Kriterium „Start auf frischem Golden-Record“).
• Schnelllauf: Schaltfläche Schnelllauf in der Kopfzeile – prüft in Minuten nur die Bereiche, die ein Commit berührt; nicht freigaberelevant. Siehe Schnelllauf.
• Variantenlauf: mit gemischter Szenario-Reihenfolge oder verstellter Uhr/Zeitzone (POST /api/v2/start mit reihenfolge, zeit, dbZeitzone) – nur Statusvergleich, nicht freigaberelevant, nicht referenzfähig. Siehe Variantenläufe.
• Während ein Lauf läuft, sind „Lauf starten“ und „Schnelllauf“ gesperrt. Prüfläufe und Wiedergaben im Prozess-Studio warten aufeinander.

Warteschlange: neue Commits während eines Laufs

• Ein laufender voller Lauf wird nicht wegen eines neuen Commits abgebrochen. Der neue Stand wartet; die Kopfzeile zeigt „wartet: <commit>“. Es wartet immer nur der jüngste Stand – ältere wartende Stände werden verworfen. Nach dem Lauf startet er automatisch (neue API-Version nach 180 s Stabilisierung).
• Deploy-Modus „auto“ (Vorgabe): Die API deployt bei jedem Commit selbst und setzt dabei ihre Datenbank auf den Golden-Record zurück. Wechselt sie während des Laufs auf eine neue Version (oder startet neu), wären die restlichen Ergebnisse falsch: Der Lauf endet als Überholt, sein Teilergebnis bleibt gespeichert, der neue Stand wird automatisch geprüft. Reagiert eine lange Phase nicht, wird der Lauf nach der Frist QSGATE_UEBERHOLT_FRIST_S (900 s) hart beendet.
• Deploy-Modus „fenster“ (QSGATE_DEPLOY_MODUS=fenster, Auto-Deploy der API aus, Deploy-Hook als QSGATE_RESET_HOOK, GITHUB_TOKEN): Der Prüfstand beobachtet den Zweig (QSGATE_BRANCH, Vorgabe qsgate) und deployt neue Commits erst nach dem laufenden Lauf – kein Lauf wird mehr überholt.
• Nur ein fertiger voller Lauf gilt als Prüfung eines Commits; Schnellläufe, überholte und abgebrochene Läufe zählen nicht. Der Prüfstand selbst startet dank Build-Filter nur bei Änderungen unter qsgate/pruefstand/** neu.

Die Prüfphasen

Jede Phase liefert Beobachtungen, die normalisiert und mit der Referenz verglichen werden; fehlschlagende Prüfungen sind Befunde. Zahlen: Lauf vom 29.10.2026 (Prüfungen · Befunde); die mit neu markierten Phasen kamen danach hinzu, die mit v46 markierten mit dem Stand v46 (31.10.2026).

Der MCP-Schlüssel des Prüfstands wird mit einem Aufruflimit von 1000 je Minute angelegt (Standard für Kundenschlüssel: 100); bei Überschreitung antwortet die App mit 429 und Retry-After. Alle Klickpfade laufen in einer gemeinsamen Browsersitzung. Prüfketten mit Status „warn“ zählen als Befund – die Go/No-Go- und Guard-Übersichten ermitteln ihren Status aus einer Probe je Guard (Verstoß und gültiger Fall) – ein unwirksamer Guard erscheint als „❌ Fehler“.

Ohne eigene Zeitmessung laufen zusätzlich der Pflichtfeld-Abgleich Oberfläche ↔ Backend (Ebene Oberfläche) und die Abfrage des Absturzschutzes (Ebene Fehleingaben). Die neuen Phasen beschreibt das Kapitel Neue Prüfdimensionen; jede lässt sich per Umgebungsvariable abschalten (z. B. QSGATE_LAST=off).

Golden-Konsistenz und Golden-Stand v46

• Direkt nach „Datenbank vorher“ – vor Klickpfaden, Prüfketten und Szenarien, die alle schreiben – laufen alle Konsistenzregeln auf dem frisch zurückgesetzten Golden-Record. Jede Verletzung dort ist ein Datenfehler des Golden-Records (Ergänzung bzw. Dump), kein Fehler des geprüften Commits; sie würde aber jede Regel „nach den Szenarien“ verfälschen.
• Befunde tragen den Schlüssel konsistenz:<regel>:vor-szenarien (Golden-Record) – im Unterschied zu …:nach:<datei> (von einer Szenario-Datei verursacht). Zusammenfassung im Lauf unter goldenKonsistenz; Muss-Kriterium „Golden-Record konsistent“ (siehe Bewertung). Abschalten: QSGATE_GOLDEN_KONSISTENZ=off.
• Golden-Stand: ein Fingerabdruck aus dem Ledger der Datenbank (db_migrations), den Ergänzungsdateien (sha256 aus den Backend-Quellen) und dem Manifest des Dumps, im Lauf unter goldenStand. Er macht das Kriterium „Start auf frischem Golden-Record“ versionsbewusst: ein neuer Golden-Stand ist kein „ohne Reset“.

App-Log: stille Rückfälle v46

• Viele Rückfälle der App enden nicht in einer HTTP-Antwort, sondern nur in einer Log-Zeile („Bestand nicht fortgeschrieben“, „Audit-Schreibfehler“, unbehandelte Promise-Ablehnung). Die Phase App-Log (nach dem Absturzschutz, vor „Datenbank nachher“) liest die Log-Zeilen zwischen Laufbeginn und Ende.
• Quellen: die QS-Route GET /__qs-aufnahme/log?since=<seq> des QS-Gates (Ringpuffer in qsgate/aufnahme.mjs: stderr vollständig, stdout nur Warn- und Fehlerzeilen; Größe über QSGATE_LOG_PUFFER am QS-API-Dienst, Vorgabe 20.000 Zeilen) oder lokal die Datei aus QSGATE_APP_LOG (gelesen ab der Dateigröße zu Laufbeginn). Ohne Quelle entfällt die Ebene still.
• Normalisierung: IDs, Zahlen, Datumswerte, Mailadressen und Belegnummern werden ersetzt; ausgefiltert werden 4xx-Zugriffszeilen, Fehlerblöcke mit status: 4xx (gewollte fachliche Abweisungen) und Stack-Zeilen.
• Je Meldungstyp eine Beobachtung applog:<stufe>:<hash> (Ebene applog) mit der Häufigkeit als Klasse (1 · 2–5 · 6–20 · 21–100 · über 100). Ein neuer Typ wird zur Abweichung „neu“, die Fehler-Stufe ist ein Befund. Zusammenfassung unter appLog; Abschalten: QSGATE_APPLOG=off.

Konsistenzregeln: neu in v46

¹ Schnelle Regeln laufen zusätzlich nach jeder Szenario-Datei (rund 0,2 s je Datei). Stand 31.10.2026: alle 65 Regeln auf frischem Golden-Record und nach den Szenarien bei 0. Beim ersten Lauf mit neuen Regeln ist „Keine neuen Konsistenzverletzungen“ rot, solange die neuen Regelschlüssel in der Referenz fehlen und eine Verletzung zeigen.

Konsistenz je Szenario-Datei (Verursacher)

• Sequentiell (auch in sequentiellen Abschnitten des Parallel-Plans) zählt der Prüfstand nach jeder Datei die schnellen Regeln; steigt eine Zahl, ist die Datei der Verursacher: konsistenz:<regel>:nach:<datei>.
• Parallele Abschnitte: vor und nach dem Abschnitt werden die Verletzungszeilen geholt; jede neue Zeile wird über ihren spezifischsten Belegschlüssel in den Beobachtungen der Szenarien des Abschnitts gesucht. Eindeutig → Schlüssel der Datei mit zuordnung: beleg; sonst Abschnitts-Schlüssel …:nach:<erste>…<letzte> mit zuordnung: mehrdeutig und den kandidaten. Abschalten: QSGATE_KONSISTENZ_JE_DATEI=off.

Fehleingaben: Datentyp-Fuzzing

• Grundlage je Route ist der erste erfolgreiche Anfrage-Inhalt aus den Szenarien (ersatzweise die Felder des Dialog-Inventars); genau ein Feld wird verfälscht. Arten: koerper-array, text-statt-zahl, zahl-statt-text, text-statt-boolean, array-statt-objekt, objekt-statt-array, langer-text (20.000 Zeichen), negative-menge.
• Seiteneffekt über das WAL der Datenbank (pg_walinspect): gewertet werden nur festgeschriebene Transaktionen mit Netto-Wirkung auf Fachtabellen (technische Tabellen ausgenommen, anpassbar mit QSGATE_FUZZ_TECHNISCH).
• Befund bei 5xx, bei 2xx mit Seiteneffekt (bei zahl-statt-text und langer-text nur Hinweis) und bei 4xx mit Seiteneffekt. Schlüssel robust:<route>:fuzz:<art>:<feld>. Erwartet ist eine fachliche Abweisung: eine Liste als ganzer Inhalt ergibt 400 BODY_OBJECT_EXPECTED, Mengen müssen größer 0 sein.
• Umfang: QSGATE_FUZZ_JE_ROUTE (Vorgabe 3), QSGATE_FUZZ_MAX (Vorgabe 2.000 Anfragen; Routen deterministisch gestreut), Notbremse QSGATE_FUZZ_MAX_S (900 s); QSGATE_FUZZ=off schaltet ab. Dauer etwa 7–9 Minuten.

Parallele Szenario-Phase

• Die Szenarien laufen nach einem Plan gleichzeitig: Grad QSGATE_PARALLEL (Vorgabe 3, höchstens 8; 1 = nacheinander wie bisher). Grundlage sind das Laufzeitprofil des Referenzlaufs und die Regeln in config/parallel.json (Sammelbereiche, exklusive Bereiche und Dateien, die allein laufen müssen; anderer Pfad über QSGATE_PARALLEL_CONFIG).
• Ohne Profil oder ohne unabhängigen Abschnitt läuft die Phase nacheinander (Grund steht im Protokoll). Der Plan steht im Lauf unter parallelPlan; node src/cli.js plan zeigt ihn vorab.
• Im Lauf steht unter phases.Szenarien.warten, wie lange auf das Anfrage- bzw. Anmeldelimit gewartet wurde – die eigentliche Bremse.

Normalisierung und Determinismus

• IDs aus dem Golden-Record bleiben fest; neu entstandene IDs werden zu «neu», Zeitstempel zu «ts», Unix-Zeiten zu «epoch», das echte Tagesdatum zu «heute»; Listen werden reihenfolgeunabhängig verglichen.
• Zusätzliche Regeln (flüchtige Felder, bekannte instabile Prüfungen, begründete Ausnahmen der Abdeckung) stehen in rules.json – Änderung nur per Pull Request mit Begründung.
• Laufzeitklassen gelten erst ab einem Sprung um zwei Klassen als Abweichung.
• Beispielpfade der Rechte- und Fehleingaben-Matrix (Feld pfad, z. B. /api/…/<uuid>/…) werden ohne konkrete IDs verglichen (:id): welche ID als Beispiel diente, ist kein Ergebnis – Route und Status sind es. Hintergrund: Lauf 2639db2 hatte rund 6.700 Abweichungen nur wegen wechselnder Beispiel-IDs.
• Seit v46 zusätzlich in rules.json (jeweils mit _begruendung): interne IP-Adressen → «ip-intern», Kundenreferenz des Klickpfads QSUI O2C … → «zufall», Kopfzeilen cf-ray und rndr-id flüchtig. Der erste Lauf nach einer neuen Normalisierung zeigt bei den betroffenen Beobachtungen einmalig Abweichungen – diese freigeben.
• Der Prüfstand-Client wiederholt ein GET bei „fetch failed“ (keine Antwort, z. B. Keep-alive-Rennen nach dem Reset) genau einmal nach 250 ms; schreibende Aufrufe werden nie wiederholt.
• Zwei Läufe hintereinander auf demselben Stand (jeweils mit Reset) müssen ohne Abweichung enden. Szenarien laufen im Normallauf in fester Reihenfolge (Dateiname); gemischte Reihenfolge nur im Variantenlauf.

Nach dem Lauf: Vergleich und Freigabe

1. Urteil lesen im Cockpit: grün (keine Abweichung), gelb (Abweichungen prüfen), rot (neue Fehler oder kritische Abweichungen), „ohne Referenz“. Daneben gibt es Schnelllauf (nicht freigaberelevant), Überholt und Abgebrochen – diese Läufe werden nicht bewertet und können keine Referenz werden.
2. Abweichungen einzeln oder gesammelt mit Begründung freigeben oder ablehnen – siehe Freigabe.
3. Befunde bearbeiten (Status, Verantwortliche, Ticket) und den Prüfauftrag an die Entwicklung geben.
4. Als Referenz übernehmen, sobald alle Abweichungen freigegeben sind; ab dann vergleicht jeder weitere Lauf gegen diesen Stand.
5. Prüfbericht als PDF ablegen – siehe Prüfbericht.

Kopfzeile › Schnelllauf · POST /api/v2/start {"modus":"schnell"} · node src/cli.js run --schnell

Ein schneller Zwischenstand nach einem Commit: Der Prüfstand prüft nur die Bereiche, die der Commit-Diff berührt, und meldet in Minuten, ob dort etwas rot geworden ist. Für die Freigabe bleibt der volle Lauf Pflicht.

Starten

1. Cockpit: Schaltfläche Schnelllauf in der Kopfzeile, Abfrage bestätigen. Die geänderten Dateien ermittelt der Prüfstand aus dem GitHub-Vergleich Referenz-Commit … aktueller Commit (GITHUB_TOKEN).
2. Schnittstelle: POST /api/v2/start mit {"modus":"schnell","dateien":["backend/src/…"],"basis":"<commit>","reset":false} – dateien und basis sind optional. Antwort mit freigaberelevant: false.
3. Kommandozeile: node src/cli.js run --schnell --dateien=a,b bzw. --seit=<commit/zweig> (git diff, Verzeichnis QSGATE_GIT_DIR) oder Umgebung QSGATE_SCHNELL_DATEIEN / QSGATE_MODUS=schnell. --baseline ist mit --schnell nicht erlaubt.

Was geprüft wird

• Umfang aus dem Diff: Router-Datei → Bereich (/api/<bereich>) über config/route-dateien.json, sonst Namens-Heuristik; daraus die passenden Szenarien, lesenden Endpunkte und Masken. Kernänderungen (z. B. Middleware, Datenbank-Helfer, Anmeldung, Nummernkreise) wirken überall – dann prüft der Schnelllauf eine Stichprobe je Modul und vermerkt, dass das Ergebnis eingeschränkt aussagekräftig ist. Reine Doku-/Prüfstand-Oberflächen-Änderungen werden ignoriert.
• Laufen mit: Schema, Schema-Abgleich Code, lesende Endpunkte und Oberfläche (nur Bereich), Pflichtfeld-Abgleich, Prüfketten, Szenarien (nur Bereich), Dialogfunktionen, Rechte, Fehleingaben (aus den Aufrufen dieses Laufs), Code-Abdeckung, Konsistenz.
• Laufen nicht: Katalog, MCP-Lesetools, Barrierefreiheit, Klickpfade, Sicherheit, Nebenläufigkeit, Last, Datenbank nachher/Delta, Kennzahlen.
• Ohne Reset (sofern nicht ausdrücklich reset: true) und nur Statusvergleich: verglichen wird je geprüfter Beobachtung ok ↔ Fehler gegenüber der Referenz – Inhalte (Belegnummern, Listen) hängen von nicht gelaufenen Vorgänger-Szenarien ab und sind nicht vergleichbar.

Ergebnis

• Urteil Schnelllauf (nicht freigaberelevant) mit Hinweis „n neue Fehler, m behoben gegenüber der Referenz“. Der Lauf erhält die Kennung …_schnell, steht in der Protokollkette, kann aber keine Referenz werden und kein GO geben.
• Im Cockpit zeigt der Reiter Abweichungen die Statuswechsel; die übrigen Reiter brauchen den vollständigen Lauf-Index und nennen das.
• Läuft schon ein Lauf, wartet der Schnelllauf in der Warteschlange; hinter einem wartenden vollen Lauf wird er verworfen.

Die Bewertung ist regelbasiert: Jedes Kriterium hat ein Gewicht. Muss-Kriterien entscheiden über GO oder NO-GO, alle Kriterien zusammen ergeben 0–100 Qualitätspunkte.

Die Kriterien

Schwellen (Abdeckung, langsame Aufrufe, Dialogfunktionen) sind je Projekt über rules.json › gates einstellbar; ohne Eintrag gelten die genannten Standardwerte. Quelle: evaluateGates() im Prüfstand. Zusätzliche Kriterien der neuen Prüfdimensionen stehen deklarativ in rules.json › kriterien – siehe Neue Prüfdimensionen. Schnellläufe, überholte Läufe und Variantenläufe werden nicht bewertet.

Art und Schweregrad einer Abweichung

Typische Fragen

Eine neue Referenz entsteht nur, wenn Menschen jede Abweichung einzeln mit Begründung freigeben – kritische und unangekündigte mit zwei Personen. Das System misst und dokumentiert, Menschen entscheiden.

Einzelne Abweichung freigeben

1. Abweichung öffnen. Im Reiter Abweichungen auf die Zeile klicken (oder j/k und Enter).
2. Änderung prüfen. Tabelle „Änderungen gegenüber der Referenz“: Feld · Referenz · Dieser Lauf; bei Masken zusätzlich Bildschirmfotos und Pixel-Unterschied; darunter der beobachtete Inhalt beider Läufe.
3. Begründung eintragen (Pflicht) – fachlich, z. B. „CR-2026-114: Preislogik bewusst geändert“. Sie steht dauerhaft in der Protokollkette.
4. „Freigeben“ oder „Ablehnen“. Die Entscheidung erscheint unter „Freigaben“ mit Name, Zeit und Begründung.

Sammelfreigabe

1. Liste filtern (z. B. Bereich, Ebene, Art), dann Häkchen je Zeile setzen, mit x markieren oder „alle sichtbaren“ wählen.
2. In der Leiste unten die Begründung eintragen und „Freigeben“ bzw. „Ablehnen“. Ohne Auswahl oder Begründung meldet das Cockpit „Zuerst Abweichungen auswählen.“ bzw. „Begründung angeben — sie steht im Änderungsprotokoll.“
3. Kritische und unangekündigte Abweichungen brauchen zwei Personen: nach der eigenen Freigabe stehen sie auf „teilfreigabe“ und bleiben in der Liste sichtbar (Vorgabefilter „offen“ + „teilfreigabe“). Eine erneute Freigabe durch dieselbe Person ändert nichts – die Meldung nennt, wie viele auf die zweite Person warten, und unter der Liste steht die Zahl der Teilfreigaben. Als Inhaber kann man in der Kopfzeile des Laufs mit „Eine Freigabe genügt (n)“ anordnen, dass für diesen Lauf die eigene Freigabe ausreicht (bewusste Ausnahme, mit Name und Begründung in der Prüfkette; API POST /api/v2/runs/:id/eine-freigabe). Stehen nur noch solche Teilfreigaben aus, bietet „Als Referenz übernehmen“ beides in einem Schritt an (Formular in der Seitenleiste: Begründung eintragen, „Anordnen und als Referenz übernehmen“).

Vier-Augen-Prinzip

• Kritische und unangekündigte Abweichungen brauchen zwei Personen (Spalte „Freigabe“ zeigt z. B. „1/2 Personen“, Status teilfreigabe).
• Die zweite Person entfällt bei einer nachgewiesenen reinen Testerweiterung (App-Quellen identisch mit der Referenz) oder auf Anordnung des Inhabers für genau diesen Lauf. Beides wird über die Schnittstelle gesetzt (nur-testaenderung mit Begründung und Nachweis bzw. eine-freigabe mit anordnender Person) und in der Protokollkette festgehalten.

Referenzwechsel

1. Lauf öffnen (Kopfzeile: Lauf-Auswahl) – im Lauf-Kopf erscheint Als Referenz übernehmen, wenn der Lauf fertig und nicht schon Referenz ist.
2. Sind noch Abweichungen offen, meldet das Cockpit „Noch n Abweichung(en) nicht freigegeben — zuerst im Reiter „Abweichungen“ freigeben.“
3. Begründung für die neue Referenz bestätigen (Vorschlag: „Alle Abweichungen geprüft und freigegeben.“). Der Wechsel wird in der Protokollkette festgehalten; alle folgenden Läufe vergleichen gegen diesen Lauf.

Nicht alles Rote ist ein App-Fehler. Jeder Befund wird automatisch einer Kategorie (wer ist zuständig?) und einer technischen Klasse (welche Art Fehler?) zugeordnet.

Kategorien

Zuständigkeit (automatische Einordnung)

Zusätzlich bekommt jeder Befund genau eine Zuständigkeit mit Begründung – die Antwort auf „wer muss handeln?“. Sie steht als Spalte „Zuständig“ und Filter in Befunde und im Befund-Verlauf, in Ticket-Texten und in jedem Prüfauftrag.

Regeln in src/report/zustaendig.js in fester Reihenfolge (die erste passende gewinnt) aus HTTP-Status, Fehlercode, Meldung, Ebene und Historie der bis zu 7 vorangehenden Läufe. Harte Code-/Schemafehler schlagen Instabilität. Folgefehler („übersprungen: Schritt … fehlgeschlagen“) erben die Klasse des fehlgeschlagenen Vorgängers.

Klassen

Die Klasse beschreibt die technische Art des Befunds und steuert Farben und Filter in Befunde und im Cockpit („Befunde nach Klasse“):

Serverfehler Schema Buchungskreis Fachlich abgewiesen MCP-Tool Prüfkette Konsistenz Oberfläche Sonstiges

Ebenen

Jede Beobachtung gehört zu einer Ebene, z. B. Szenarien, API (lesende Endpunkte), MCP, Oberfläche, Prüfketten, Datenbank, Kennzahlen, Konsistenz. Ebenen erscheinen als Filter-Chips und als Spalten der Modul-Matrix.

Adresse #/ · Kürzel g c

Die Startseite: Urteil des letzten Laufs, Freigabe-Entscheidung, Kennzahlen, Trends und die wichtigsten Auswertungen auf einer Seite.

Zweck

Eine klare, regelbasierte Antwort auf die Frage „Darf diese Version zum Kunden?“ – und der schnellste Einstieg in alle Details.

Was man sieht – von oben nach unten

Bedienung Schritt für Schritt

1. Urteil ablesen und mit den roten Muss-Kriterien beginnen – sie entscheiden, nicht die Punktzahl.
2. Kriterium anklicken, um direkt in die gefilterte Ansicht zu springen.
3. Kennzahl-Kachel oder Matrix-Zelle anklicken, um sich auf einen Bereich zu konzentrieren.
4. Gesamt-Prüfauftrag (MD) für die Entwicklung herunterladen – siehe Prüfauftrag.

Adresse #/laeufe

Die Historie aller Läufe mit Urteil, Abweichungen, Befunden, Umfang und Dauer – und der Einstieg in jeden früheren Lauf.

Was man sieht

Darunter: Dauer je Lauf (Minuten) und Abdeckung je Lauf (schreibend, lesend, MCP-Tools in %).

Bedienung

1. Lauf öffnen: Zeile anklicken – öffnet den Reiter Abweichungen dieses Laufs. Alternativ die Lauf-Auswahl in der Kopfzeile.
2. Zwei Läufe vergleichen: genau zwei Häkchen setzen, dann „Zwei Läufe vergleichen“ – öffnet den Vergleich.
3. Neuen Lauf starten: „Lauf starten“ in der Kopfzeile, Abfrage bestätigen (siehe Ablauf).

Lauf-Kopf (in jedem Reiter eines Laufs)

Über allen Reitern von „Ausgewählter Lauf“ steht der Lauf-Kopf: Urteil, ggf. Referenz, Start, Dauer, Version, Auslöser, „Verglichen mit“ (Link zur Referenz) und die Freigabe-Plakette (GO / NO-GO / OFFEN mit Punkten, Link zum Prüfbericht). Knöpfe:

Unter den Knöpfen erscheinen bei Bedarf zwei Zeilen:

• Hinweis zum Lauf – bei Schnelllauf, überholtem oder abgebrochenem Lauf der Grund bzw. das Ergebnis (z. B. „Schnelllauf – nicht freigaberelevant. 1 neue Fehler, 1 behoben …“).
• KI-Zweitprüfung Rechnungswesen – Status (bewertet, Budget erreicht, nicht konfiguriert, abgeschaltet), bewertete Belege „n von m“, Anzahl der KI-Hinweise auf Abweichung (Klick öffnet die Suche nach „KI-Hinweis“), Tokens ein/aus, Anfragen und geschätzte Kosten in €. Siehe Fachprüfung Rechnungswesen.

Die Reiter des Laufs: Abweichungen, Befunde, Ursachen, Module, Szenarien, Prozesse, Dialoge, Abdeckung, Code, Endpunkte, Oberfläche, Datenbank, Prüfketten, Suche. Die Reiter außer Abweichungen brauchen den vollständigen Lauf-Index: Läuft der Lauf noch, steht dort „Der Lauf ist noch nicht abgeschlossen.“; bei Schnelllauf, überholtem oder abgebrochenem Lauf erklärt ein Hinweis, warum es keine Auswertung gibt.

Adresse #/studio · Unterseiten #/studio/spielen, #/studio/aufnahme, #/studio/makro/<id>

Alle Prozesse, Varianten und Dialogfunktionen des Golden-Records als fertige Makros: abspielen (Schritt für Schritt, automatisch, bis zum Haltepunkt), je Schritt die Maske der Oberfläche mit dem Beleg öffnen, verändern und erweitern.

Zweck

Prozesse werden für Demo, Schulung oder Fehleranalyse Schritt für Schritt nachvollziehbar, und Kundenprozesse werden ohne Programmierung zu dauerhaften Prüfszenarien.

Kopfbereich

Zähler: Prozesse, fertige Makros, davon exakt wiederholbar, eigene Makros, Adresse der Oberfläche. Knöpfe: Laufende Wiedergabe bzw. Letzte Wiedergabe, Aufnahme an der Oberfläche, Neues Makro.

Die vier Reiter

Kurzbedienung

1. Prozess suchen (Reiter Prozesse oder Makros) und ▶ wählen: grüner Knopf = Schritt für Schritt, zweiter Knopf = automatisch.
2. Abspielen auf der Seite „Abspielen“ steuern – Nächster Schritt, Automatisch weiter, Haltepunkte, Tempo, Stopp.
3. Makro anpassen über den Stift, neu aufnehmen über „Aufnahme an der Oberfläche“.

Die ausführliche Anleitung mit allen Bildern steht im Kapitel Prozess-Studio: Anleitung.

Adresse #/lauf/<lauf>/abweichungen · Kürzel g a · Zahl im Menü = offene Abweichungen des letzten Laufs

Jede Änderung gegenüber der Referenz – nach Schweregrad, Ebene, Art und Bereich – mit Freigabe direkt in der Liste.

Zweck

Unbeabsichtigte Seiteneffekte einer Änderung werden gefunden, bevor ein Anwender sie bemerkt. Nichts ändert sich mehr „still“ im System.

Filter und Elemente

Spalten der Liste: Schweregrad (ggf. unangekündigt), Prüfung mit Ebene · Modul · Art, Änderung (bis zu zwei Felder alt → neu, „+ n weitere“), Freigabe (Status, bei vier Augen „x/2 Personen“).

Bedienung Schritt für Schritt

1. Nach „kritisch“ filtern – offene kritische Abweichungen blockieren die Freigabe.
2. Zeile öffnen (Klick oder j/k + Enter): Die Schublade zeigt Änderungen, Bildschirmfotos (Referenz, dieser Lauf, Pixel-Unterschied), Anfrage, HTTP-Status und den normalisierten Inhalt beider Läufe.
3. Entscheiden: in der Schublade oder als Sammelfreigabe – siehe Freigabe.
4. Weitere Aktionen der Schublade: „Verlauf über die Läufe“, „Prüfauftrag (MD)“ für genau diese Prüfung, „Bereich …“ (Bereichs-Steckbrief).

Typische Fragen

Adresse #/lauf/<lauf>/befunde · Kürzel g b · Zahl im Menü = Befunde des letzten Laufs

Alle fehlschlagenden Prüfungen des Laufs – nach Kategorie, Klasse, Ebene und Bereich, mit Bearbeitung (Status, Verantwortliche, Ticket) und Exporten.

Zweck

Unterscheidet echte App-Fehler von fachlichen Ablehnungen und Golden-Daten-Themen – ein gemeinsames Fehlerbild für Fachbereich, Berater und Entwicklung.

Filter und Elemente

Die Spalte Zuständig zeigt Klasse und Team; der Tooltip nennt die Begründung (z. B. „Keine Antwort vom QS-Gate (HTTP 0) – Dienst/Netz prüfen“) und bei instabilen Befunden den Verlauf. Die Suche findet auch Klasse und Team. Ticket-Texte und Prüfaufträge enthalten die Zuständigkeit.

Bedienung Schritt für Schritt

1. Eingrenzen: Bereich im Balkendiagramm anklicken, Kategorie/Klasse wählen oder nach Zuständig filtern – so bekommt jedes Team genau seine Liste.
2. Befund öffnen: Die Schublade zeigt Fehler, Erste Analyse mit Diagnose-Hinweisen (z. B. Suchbefehl für die Route) und die Anfrage.
3. Bearbeiten: Status (neu, in Arbeit, Ticket, bekannt, akzeptiert, erledigt), Verantwortlich, Ticket (z. B. RERP-123), Notiz → „Speichern“. Die Bearbeitung gilt für diesen Befund über alle Läufe; der Verlauf der Bearbeitung ist aufklappbar.
4. Weitergeben: „Ticket-Text kopieren“ (Markdown für das Ticketsystem) oder „Prüfauftrag (MD)“.
5. Sammelbearbeitung: mehrere Befunde markieren, Felder in der Leiste füllen, „Bearbeitung setzen“.

Adresse #/lauf/<lauf>/ursachen

Befunde mit derselben normalisierten Fehlermeldung werden zu Ursachen-Gruppen gebündelt: eine Ursache, viele Symptome. Eine Korrektur an der richtigen Stelle beseitigt oft dutzende Befunde auf einmal.

Was man sieht

• Kennzahlen: Befunde, Ursachen-Gruppen, Anteil der 10 größten Ursachen, neu im letzten Lauf.
• Pareto der Ursachen: die 25 größten Gruppen; rote Balken enthalten neue Befunde. Klick auf einen Balken springt zur Gruppe.
• Nach Ursachen-Typ: Klick filtert die Liste auf diesen Typ (erneuter Klick hebt auf).
• Je Gruppe: Anzahl, Typ · Kategorie, Meldung, Klassen, HTTP-Status, Bereiche (Links zum Steckbrief), Diagnose-Hinweise, betroffene Endpunkte und Szenarien (Links), erstes Auftreten.

Bedienung

1. Filtern: Suchfeld „Meldung, Endpunkt, Bereich …“, Klasse, Chips echte Fehler (Voreinstellung) · alle · mit neuen Befunden · unbearbeitet · Golden-Daten/Customizing.
2. Gruppe exportieren: „Prüfauftrag (MD)“ erzeugt den Auftrag nur für diese Ursache (ohne Abweichungen) – ideal, um Arbeit zu verteilen.
3. Befunde der Gruppe ansehen: Knopf „Befunde“.
4. Gemeinsam bearbeiten: „Bearbeitung für alle n Befunde setzen“ aufklappen, Felder füllen, „Übernehmen“.
5. Mehr anzeigen: Die Liste zeigt 25 Gruppen; „Weitere … Ursachen anzeigen“ lädt nach.

Adresse #/lauf/<lauf>/module · Bereichs-Steckbrief #/bereich/<Bereich>

Die Modul-Matrix über alle Bereiche und Ebenen sowie eine sortierbare Bereichstabelle – zeigt sofort, wo sich Probleme ballen.

Modul-Matrix lesen

• Zeilen = Bereiche, Spalten = Ebenen (Szenarien, API, MCP, Oberfläche, Prüfketten, Datenbank, Kennzahlen, Konsistenz).
• Farbe = Fehleranteil (0, < 2 %, < 5 %, < 12 %, < 25 %, ≥ 25 %); Zahl = Fehler, kleine rote Zahl = Abweichungen.
• Tooltip: Prüfungen, fehlerhaft, Abweichungen, davon kritisch.
• Klick auf eine Zelle öffnet Befunde (oder, wenn es nur Abweichungen gibt, Abweichungen) gefiltert auf Bereich und Ebene; Klick auf den Bereichsnamen öffnet den Bereichs-Steckbrief.

Bereiche im Überblick

Tabelle mit Prüfungen, Fehlern (Link zu Befunden), Fehleranteil, Abweichungen (Link, kritische hervorgehoben), Szenarien grün, Schritten und geprüften Endpunkten – sortierbar per Klick auf die Spaltenüberschrift.

Bereichs-Steckbrief

Alles zu einem Bereich auf einer Seite: Kennzahlen (Prüfungen, Befunde, offene Abweichungen, Szenarien grün, Endpunkte geprüft, Tabellen verändert), Ebenen des Bereichs, Befunde je Lauf, Listen der Szenarien, Befunde, Endpunkte („nur ohne Prüfung“), Abweichungen sowie Tabellen und Prüfketten. Oben: Prüfauftrag (MD) für den Bereich und eine Auswahl, um zu einem anderen Bereich zu wechseln.

Adresse #/lauf/<lauf>/szenarien · Detail …/szenarien/<id>

Rund 1.120 fachliche Szenarien – echte Abläufe vom Angebot bis zur Zahlung, über die API bis zum Endzustand.

Bedienung

1. Überblick: Kacheln Szenarien, Vollständig grün, Mit Befund-Schritten (davon abgebrochen), Schritte (davon fehlerhaft).
2. Filtern: „Szenario suchen …“, Bereich, Status: mit Befund-Schritten · vollständig grün · abgebrochen.
3. Szenario öffnen: Karte anklicken. Die Detailseite zeigt Kennzahlen (Schritte, Befund-Schritte, abweichende Schritte, Laufzeit und langsamster Schritt), eine Schrittleiste mit Tooltips und die Zeitleiste aller Schritte mit Anfrage, Prozessart (Storno, Korrektur, Retoure …), Kennzeichen „abweichend“, HTTP-Status und Laufzeit.
4. Schritt öffnen: Klick auf einen Schritt öffnet die Schublade mit Anfrage, Antwort und Vergleich zur Referenz.
5. Zurück: „← alle Szenarien“.

Adresse #/lauf/<lauf>/prozesse

Prozessvarianten je Bereich: Normal, Storno, Retoure, Korrektur, Ablehnung, Abschluss, Wiedereröffnung – und der Prozesskatalog mit fachlicher Erwartung je Variante.

Was man sieht

• Kennzahlen: Prozessvarianten im Katalog (Prüfmenge, davon von der App nicht angeboten; ohne ausgenommene, Katalog gesamt in Klammern), Geprüft und grün, Mit Befund, Lücken / nicht gelaufen und Ausgenommen (Klick filtert die Liste darauf).
• Prozessarten je Bereich: automatisch aus den Schrittnamen erkannt. Klick auf eine Zelle listet die betroffenen Szenarien.
• Sonderfälle gesamt: grün / mit Befund je Sonderfall; Bereiche ohne Storno, Korrektur oder Retoure werden genannt.
• Prozesskatalog: fachliche Erwartung je Prozess und Variante mit Zustand.

Filter im Prozesskatalog

Suchfeld „Prozess, Erwartung, Szenario …“, Bereich, Prozessart und Chips je Zustand: Befund · abgebrochen · nicht gelaufen · teilweise gelaufen · Lücke · grün · nicht angeboten · ausgenommen.

• ausgenommen – bewusst nicht Gegenstand der Prozessprüfung (z. B. technischer/interner Wert, Konzepttext, gesetzlich nur im Kassensystem). Die Begründung (mindestens 15 Zeichen, sonst gilt die Variante als Lücke) steht in der Spalte „Fachliche Erwartung“. Ausgenommene Varianten zählen nicht in Prüfmenge und Quote und sind ohne Zustandsfilter ausgeblendet (Hinweis mit Anzahl über der Liste).
• nicht angeboten – die App bietet die Variante (noch) nicht an: Produktentscheidung offen bzw. Umsetzung nach SAP-Abgleich geplant.

Wie Varianten entstehen und entschieden werden, beschreibt das Kapitel Prozesskatalog.

Adresse #/lauf/<lauf>/dialoge (Reiter „Dialoge“)

Jeder Knopf, jede Aktion einer Maske, die das Backend aufruft – Speichern, Export, Statuswechsel – und ob ein Test sie erreicht.

So wird gezählt

Jede Stelle im Frontend, an der eine Maske das Backend aufruft, ist eine Dialogfunktion. Geprüft ist sie, wenn ein Szenario-Schritt oder die Leseprüfung dieselbe Methode und Route aufruft; bei Varianten (feste Werte wie action: 'approve' oder Query-Parameter wie ?format=csv) muss der Aufruf diese Variante tragen. Tote Knöpfe – Aufrufe ohne Backend-Route – meldet die Prüfphase „Dialogfunktionen“ als Befund.

Bedienung

1. Kennzahlen lesen: Dialogfunktionen (davon dynamisch), Durch Tests geprüft, Variante fehlt, Ungeprüft (davon ohne bekannte Backend-Route).
2. Bereich wählen im Balkendiagramm „Abdeckung je Bereich“ (klicken filtert).
3. Zustände filtern: Chips nur mit Fehler · ungeprüft · Variante fehlt · geprüft · dynamisch – Voreinstellung sind die drei offenen Zustände. Suchfeld „Pfad, Datei, Komponente …“.
4. Lücke schließen: im Prozess-Studio › Dialogfunktionen „bis Schritt n“ abspielen oder einen Schritt aus der Maske in ein Makro übernehmen.

Adresse #/lauf/<lauf>/abdeckung · Code-Abdeckung im Reiter „Code“ (…/code)

Was wird geprüft – und was bewusst nicht: Endpunkte, Laufzeitklassen, langsamste Aufrufe, begründete Ausnahmen und die Backend-Code-Abdeckung.

Elemente

Reiter „Code“: Backend-Code-Abdeckung

Das QS-Gate misst während des ganzen Prüflaufs mit der V8-Abdeckung, welche Funktionen und Verzweigungen des Backends tatsächlich ausgeführt wurden – über alle Ebenen. Kennzahlen: Funktionen ausgeführt (mit Referenzwert), Verzweigungen, Dateien (ohne jede ausgeführte Funktion), Gegenüber Referenz. Filter: „Datei, Funktion …“, Bereich, „nur Dateien mit Lücken“; schwächste Bereiche stehen oben, Klick filtert.

Adresse #/lauf/<lauf>/endpunkte · Kürzel g e

Jede Schnittstelle des Katalogs mit aufrufenden Szenarien, Aufrufen, Fehlern, Median-Laufzeit und HTTP-Status.

Bedienung

1. Kennzahlen: Endpunkte im Katalog (lesend/schreibend), Durch Szenarien aufgerufen, Ohne jede Prüfung (davon begründet ausgenommen), Mit Fehlern.
2. Filtern: „Pfad oder Szenario …“, Bereich, Methode (GET, POST, PUT, PATCH, DELETE) und Prüfart: alle · ohne Prüfung · ausgenommen · nur lesend geprüft · in Szenarien · mit Fehlern. Klick in „Abdeckung je Bereich und Methode“ filtert ebenfalls.
3. Endpunkt öffnen: Die Schublade zeigt den Status (geprüft, begründet ausgenommen mit Begründung, ohne Prüfung), fehlerhafte Aufrufe, Median-Laufzeit, die Kennzahlen Szenarien · Aufrufe · HTTP-Status, das Ergebnis der lesenden Prüfung („Details öffnen“) und die aufrufenden Szenarien als Links. Ohne Szenario: schreibende Endpunkte sind Kandidaten für neue Prozesse im Golden-Record.

Adresse #/lauf/<lauf>/oberflaeche

Alle Masken aus Navigation und Routing: geöffnet, fotografiert und mit der Referenz verglichen – Text, Konsolen- und Serverfehler, Pixelvergleich.

Bedienung

1. Kennzahlen: Masken geöffnet, Mit Fehlern (Server- oder Konsolenfehler), Abweichend (Text oder Bild), Nicht inhaltlich geprüft (nur Super-Admin bzw. verschachtelte Route mit 404).
2. Filtern: „Maske oder Pfad …“ und Chips alle · Fehler · abweichend · Super-Admin · 404.
3. Maske öffnen: zeigt geänderte Texte, Bildschirmfotos von Referenz und diesem Lauf sowie den Pixel-Unterschied – und, bei Abweichung, Freigeben/Ablehnen.

Adresse #/lauf/<lauf>/datenbank

Was ein Prüflauf in der Datenbank verändert – je Bereich und Tabelle – und der Abgleich zwischen Backend-Code und Datenbankschema.

Bedienung

1. Kennzahlen: Tabellen verändert (von allen Tabellen), Zeilen hinzugefügt, geändert, entfernt.
2. Bereiche nach veränderten Zeilen zeigt, wo der Lauf schreibt.
3. Tabelle suchen („Tabelle …“, Bereich) und anklicken: Die Schublade zeigt die Änderungen gegenüber der Referenz.
4. Schema-Abgleich Code ↔ Datenbank: Tabellen und Spalten, die der Backend-Code nutzt, die im Schema fehlen (statische Analyse aller SQL-Texte). Filter „Tabelle, Spalte, Datei …“ und Chips alle · Tabelle fehlt · Spalte fehlt; Export Auftrag (MD) mit allen Fundstellen.

Adresse #/lauf/<lauf>/ketten (Reiter „Prüfketten“)

Fachliche Regeln über die gesamte Datenbank: In-App-Prüfketten, Kennzahlen (Summen-/Saldenliste, Soll = Haben, offene Posten, Steuern, Bestand) und Konsistenzregeln.

Bedienung

1. Kennzahlen: In-App-Prüfketten (Schritte), Ketten mit Fehlern, Kennzahlen, Kennzahlen mit Fehler.
2. Konsistenzregel öffnen: Klick auf die Regel zeigt die Verletzungen und das auslösende Szenario.
3. Prüfkette öffnen: Klick auf die Zeile listet jeden Kettenschritt mit ok/Fehler; Klick auf einen Schritt öffnet dessen Beobachtung.
4. Kennzahl öffnen: zeigt die Werte im Detail.

Adresse #/lauf/<lauf>/suche?q=…

Volltextsuche über alle rund 45.000 Beobachtungen eines Laufs – nach Schlüssel, Titel, Modul oder Fehlermeldung.

Bedienung

1. Suchbegriff eingeben (mindestens 2 Zeichen), z. B. „pricelist“, „column“ oder „/api/sales“. Die Ergebnisse erscheinen während der Eingabe.
2. Eingrenzen: „Alle Ebenen“ bzw. eine Ebene wählen, „nur Fehler“ ankreuzen (dann auch ohne Suchbegriff).
3. Treffer öffnen: Zeile anklicken öffnet die Beobachtung in der Schublade. Angezeigt werden bis zu 300 Treffer; die Gesamtzahl steht neben den Filtern.

Diese Ansicht ist ohne Bildschirmfoto aus dem Code beschrieben.

Adresse #/verlauf · Kürzel g v

Jeder Befund mit Status und Verlauf über die letzten Läufe: neu, weiterhin offen, behoben.

Bedienung

1. Kennzahlen: Neu im letzten Lauf (vorher nicht aufgetreten), Weiterhin offen (in beiden letzten Läufen), Behoben (im vorletzten, nicht im letzten Lauf), Betrachtete Läufe (Standard: 12).
2. Filtern: „Pfad, Meldung …“, Bereich und Chips neu · offen · behoben · früher (Voreinstellung: neu, offen, behoben).
3. Zeile öffnen: zeigt die Beobachtung – bei „behoben“ aus dem vorletzten Lauf. Die Spalte „Bearbeitung“ zeigt den Status aus Befunde, die Spalte Zuständig die automatische Einordnung (siehe Befund-Klassen).

Adresse #/stabilitaet · Kürzel g s

Prüfungen, deren Ergebnis zwischen Läufen wechselt – mit und ohne neue Version. Wechselt ein Ergebnis ohne neue Version, ist die Prüfung (oder die App) instabil.

Bedienung

1. Zeitraum wählen: letzte 6, 12, 20 oder 30 Läufe (mindestens zwei ausgewertete Läufe nötig; ältere werden im Hintergrund ausgewertet).
2. Kennzahlen: Prüfungen mit Wechseln, Instabil verdächtig, Statuswechsel grün ↔ rot, Bekannt (rules.json).
3. Filtern: „Prüfung, Schlüssel …“, Bereich, Chips instabil (Voreinstellung) · Statuswechsel · alle · bekannt, Ebenen.
4. Muster lesen: jede Zeile eine Prüfung, jedes Kästchen ein Lauf (ältester links): grün ok, rot Fehler/rot geworden, orange Inhalt geändert, grau unverändert, gestrichelt nicht vorhanden. Klick öffnet den Verlauf der Prüfung über die Läufe.

Adresse #/leistung · Kürzel g l

Antwortzeiten über die Läufe: Perzentile, Summen je Ebene, Regressionen, Verbesserungen und die langsamsten Aufrufe. Eine Version kann fachlich korrekt, aber spürbar langsamer sein.

Bedienung

1. Zeitraum wählen (letzte 6, 12, 20 oder 30 Läufe).
2. Kennzahlen: Gemessene Aufrufe, Summe Antwortzeit, Median (p50), p90 / p99, Regressionen, Verbesserungen.
3. Diagramme: Perzentile je Lauf (ms), Summe der Antwortzeit je Lauf nach Ebene (s), Bereiche nach Antwortzeit (rot = mit Regression; Klick öffnet den Bereichs-Steckbrief).
4. Listen: Regressionen, Langsamste Aufrufe, Verbesserungen – Klick auf eine Zeile öffnet den Verlauf der Prüfung mit Laufzeit je Lauf.

Adresse #/vergleich?a=<vorher>&b=<nachher>

Freier Vergleich ohne Bewertung – beliebige zwei Läufe, z. B. zwei Versionen nebeneinander, unabhängig von der Referenz.

Bedienung

1. Läufe wählen: „Vorher“ und „Nachher“ (Voreinstellung: Referenz und letzter Lauf) – oder in Läufe zwei Häkchen setzen.
2. „Vergleichen“ – rund 45.000 Beobachtungen werden verglichen. Das Ergebnis wird je Laufpaar zwischengespeichert: Der erste Vergleich dauert einige Sekunden, danach erscheint er sofort („aus dem Zwischenspeicher“).
3. Ergebnis lesen: Unterschiede je Ebene nach Art (geändert, neu, entfallen, neuer Fehler, behoben) und Eckdaten beider Läufe (Start, Version, Urteil, Schritte, Befunde).
4. Filtern und blättern: „Prüfung, Feld …“, Chips Art und Ebene – die Filter wirken auf alle Treffer, nicht nur auf die angezeigte Seite. Die Liste zeigt 200 Zeilen je Seite; „Zurück“ / „Weiter“ blättern. Klick auf eine Zeile zeigt Feld · Vorher · Nachher und den Inhalt beider Läufe.

Adresse #/kette

Jeder Lauf, jede Freigabe und jeder Referenzwechsel – verkettet über SHA-256. Nachträgliche Änderungen an Prüfergebnissen oder Freigaben würden die Kette brechen.

Was man sieht

• Status oben rechts: intakt oder verletzt; derselbe Status steht in der Fußzeile der Navigation und als Muss-Kriterium in der Freigabe-Entscheidung.
• Je Eintrag: Zeit, Ereignis (Lauf, Freigabe, Referenz), Inhalt (z. B. „Name: freigegeben #12, #13 — Begründung“) und die ersten Zeichen des Hashs. Die neuesten 300 Einträge stehen oben.
• Zusätzlich verkettet: Anordnungen „eine Freigabe genügt“ und Nachweise „reine Testerweiterung“.

Prüfumfang

Oberster Block der Einstellungen: optionale Prüfebenen des vollen Laufs. Barrierefreiheit prüfen (axe-core nach WCAG 2.1 AA und Mobilansicht 390 px der wichtigsten Masken, ca. 6–8 Minuten zusätzlich) ist standardmäßig ausgeschaltet. Häkchen setzen und „Prüfumfang speichern“ – gilt ab dem nächsten Lauf; angezeigt wird, wer wann geändert hat. Gespeichert im Prüfstand unter DATA_DIR/pruefumfang.json.

Adresse #/einstellungen

KI-Unterstützung für den Aufnahme-Assistenten im Prozess-Studio und die KI-Zweitprüfung Rechnungswesen im Prüflauf.

Zweck

Mit einem eigenen API-Schlüssel plant der Assistent Aufnahmen aus einer Beschreibung (Startmaske, Schritte, Testdaten, passende Prozessvarianten) und bereitet aufgenommene Abläufe zu lesbaren, prüfenden Makros auf (Schrittnamen, fachliche Prüfungen). Ohne Schlüssel arbeitet der Assistent regelbasiert aus dem Prozesskatalog.

Bedienung

1. Anbieter wählen: OpenAI oder Anthropic (oder „keiner“).
2. Modell eintragen – leer lassen übernimmt den angezeigten Vorschlag des Anbieters.
3. API-Schlüssel eingeben; ist bereits einer hinterlegt, bleibt er bei leerem Feld unverändert.
4. „KI-Unterstützung aktiv“ ankreuzen und Speichern.
5. Verbindung testen – zeigt Antwortzeit und Antwort oder die Fehlermeldung. Schlüssel löschen entfernt ihn nach Rückfrage.

Block „KI-Zweitprüfung Rechnungswesen“

Steuert die Phase KI-Zweitprüfung im Prüflauf. Oben steht, ob sie ausgeführt wird („wird ausgeführt“ bzw. „wird nicht ausgeführt (kein Schlüssel)“).

„Prüfungseinstellungen speichern“ übernimmt die Werte. Ein leeres Feld bedeutet: Umgebungsvariable bzw. Vorgabe. Einstellungen im Cockpit haben Vorrang vor QSGATE_KI_MAX, QSGATE_KI_MAX_TOKENS_LAUF, QSGATE_KI_MAX_TOKENS_ANFRAGE und QSGATE_KI_MAX_KOSTEN. Ist ein Budget erreicht, endet die Phase sauber mit „Budget erreicht nach n von m Belegen“.

Diese Ansicht ist ohne Bildschirmfoto aus dem Code beschrieben.

Ein Export – alle Probleme, priorisiert und reproduzierbar. Ein KI-Coding-Agent oder Entwickler kann die Fehler ohne Rückfragen nachstellen und beheben.

Welche Exporte es gibt

Jeder Befund trägt im Prüfauftrag eine Zeile bzw. Spalte Zuständig (Klasse und Team, siehe Befund-Klassen).

Prüfauftrag in Paketen

Der Gesamt-Prüfauftrag eines großen Laufs ist zu lang für einen Coding-Agenten (cefd1ba: eine Datei mit 149.956 Zeilen). Die Schaltfläche Prüfauftrag in Paketen im Lauf-Kopf teilt ihn in Arbeitspakete – im Beispiel 68 Pakete (74 Dateien inkl. Teile; 17 kritisch, 25 hoch, 26 mittel).

• Größe: höchstens ~1.500 Zeilen je Datei; größere Pakete werden in Teile geschnitten (Parameter ?max= 400–5.000).
• Kopf je Paket: Priorität mit Begründung, Zuständigkeit, Kontext (Lauf, Commit), Reproduktion (curl, try-scenario), Akzeptanzkriterium „Befund verschwindet im nächsten Lauf“ und am Ende die Schlüssel zur Nachprüfung.
• Priorität: kritisch wenn ein Muss-Kriterium betroffen ist, bei mindestens 3 Server-/Code-/Schemafehlern oder bei App-Fehlern mit 10 und mehr Prüfungen bzw. kritischen Abweichungen; hoch bei einzelnen harten Fehlern, Infrastruktur, App-Fehlern ab 3 Prüfungen bzw. hohen Abweichungen; sonst mittel (Fehlalarm-Verdacht immer mittel – zuerst die Prüfung klären).
• Übersicht 00-uebersicht.md: alle Pakete in empfohlener Reihenfolge und eine Tabelle nach Zuständigkeit. „Alle als ZIP“ enthält Übersicht und alle Pakete.

Der Korrekturzyklus

1. Lauf: alle Phasen gegen die Referenz; Befunde werden nach Ursache gebündelt und einer Zuständigkeit zugeordnet.
2. Prüfauftrag (MD): je Ursachen-Gruppe Befunde, curl-Reproduktion, Diagnose-Hinweise und eine Arbeitsweise in sieben Schritten; empfohlene Reihenfolge (z. B. zuerst fehlende Tabellen/Spalten, dann die größten Ursachen-Gruppen). Befunde der Kategorie „Golden-Daten/Customizing“ werden im Golden-Record behoben, nicht im Code.
3. Korrektur: Der KI-Entwickler korrigiert in main (nie direkt in qsgate), mit Test; das Szenario wird lokal grün gespielt.
4. Neuer Lauf: Merge main → qsgate; der Prüfstand bestätigt „behoben“ und meldet neue Befunde.

Ein Makro ist ein Geschäftsprozess als JSON – keine Programmierung: eine Folge von Schritten, die jeweils einen Aufruf der App abbilden. Zu jedem Prozess des Golden-Records gibt es ein fertiges Makro, aufgezeichnet auf dem frischen Golden-Record und per Gegenprobe auf Wiederholbarkeit geprüft.

Aufbau eines Schritts

A · Vorhandenes Makro anpassen

1. Makro öffnen: Prozess-Studio › Reiter „Makros“, suchen, Stift – oder im Reiter „Prozesse“ auf „Makro (n)“.
2. Schritt aufklappen: Name direkt ändern; Schritte mit den Pfeilen verschieben, duplizieren, löschen.
3. Reiter „Dialog“: Eingaben mit Beschriftung, Positionen als Tabelle, Such-/Filterwerte als Felder.
4. Wert ändern, z. B. Menge 100 → 120; Werte aus früheren Schritten ({{…}}) bleiben verknüpft.
5. Prüfung ergänzen: „+ Prüfung“: Pfad, Vergleich, Wert, Bezeichnung.
6. Optional prüfen: „Live ansehen“ spielt den Ablauf bis zu diesem Schritt und zeigt die echte Maske mit den Daten; „In der Maske neu erfassen“ spielt bis vor den Schritt und ersetzt ihn durch eine neue Eingabe in der echten Maske.
7. Speichern oder Speichern & abspielen.

Kopfzeile des Makro-Editors

• Als Szenario-Datei – exportiert das Makro als .mjs für das Repository.
• JSON – das ganze Makro als JSON bearbeiten und „Übernehmen“ oder kopieren.
• Kopie verwerfen (angepasstes Golden-Makro) bzw. Löschen (eigenes Makro).
• Felder ID (nur Kleinbuchstaben, Ziffern, Bindestrich, z. B. vk-teillieferung), Titel, Bereich, Beschreibung.
• In jeden Prüflauf aufnehmen – das Makro läuft in jedem Lauf wie ein Szenario mit, vor den globalen Abschlüssen, und wird mit der Referenz verglichen.
• „Fachliche Prüfungen des Originals“ zeigt bei angepassten Golden-Makros die Prüfungen des Ursprungs-Szenarios.

B · Neues Makro an der Oberfläche aufzeichnen

1. Optional planen: Im Assistenten beschreiben, was aufgenommen werden soll (z. B. „Kundenauftrag mit Teillieferung, Rest später liefern und fakturieren“), „Plan erstellen“. Der Assistent schlägt Startmaske, Benutzer, Schritte mit Testdaten und die abgedeckten Prozessvarianten vor; „Mit diesem Plan aufnehmen“ übernimmt ihn. Die Plan-Schritte erscheinen während der Aufnahme als Checkliste.
2. Starten: Benutzer (E-Mail), Tenant, Bezeichnung, Startmaske (z. B. /sales) eintragen; „Oberfläche hier eingebettet zeigen (sofort angemeldet)“ ist voreingestellt. „Neue Aufnahme starten“.
3. Arbeiten: Die echte realERP-Oberfläche erscheint im Studio, bereits angemeldet. Masken durchgehen, Daten eingeben, speichern, buchen, freigeben. Aufgezeichnet werden nur die API-Aufrufe dieses Benutzers; jeder Klick und jede Eingabe benennt den Schritt.
4. Beenden: „Aufnahme beenden“ oben rechts (oder „Verwerfen“).

1. ID und Titel vergeben (Vorschlag aus der Bezeichnung).
2. Nur nötige Lesezugriffe (voreingestellt): Lesezugriffe des Seitenaufbaus entfallen, wenn ihr Ergebnis nicht gebraucht wird. „lesende anzeigen“ blendet GET-Aufrufe in der Liste ein.
3. Auswahl je aufgenommenem Aufruf per Häkchen; schreibende Aufrufe sind vorausgewählt.
4. Assistent: Namen & Prüfungen vorschlagen (optional) – lesbare Schrittnamen und fachliche Prüfungen, regelbasiert oder mit eigenem KI-Schlüssel (Einstellungen).
5. Als Makro speichern: IDs neu entstandener Belege werden zu Platzhaltern ({{s5n}}) und verknüpft, Passwörter zu {{password}}; danach öffnet der Editor.

C · Abspielen und prüfen

1. Starten: „Speichern & abspielen“ im Editor oder ▶ in der Liste (Schritt für Schritt oder automatisch).
2. Schrittweise: „Nächster Schritt“, „Ausführen“ in der Karte oder Leertaste führt den angezeigten Schritt aus (die Karte nennt Name, Methode, Pfad und ggf. „als Benutzer“).
3. Automatisch: „Automatisch weiter“ mit Tempo-Regler (0–4.000 ms je Schritt), „Pause“, „Schrittweise“ zurück, „Stopp“.
4. Prüfen: je Schritt HTTP-Status (Abweichung zur Aufzeichnung markiert, z. B. „≠ 201“) und Prüfungen ✓/✗; „mitlaufen“ hält den aktuellen Schritt im Blick.
5. Details: Schritt anklicken – Anfrage-Inhalt, Antwort, gemerkte Werte (Variablen); „Maske öffnen“ bzw. „Beleg in der Oberfläche“ öffnet die echte Maske.
6. Nachjustieren: „Anfrage bearbeiten & senden“ testet eine Variante (wird nicht aufgezeichnet).
7. Nach dem Ende: Zusammenfassung (Schritte, Fehler, nicht erfüllte Prüfungen, Benutzer); „Als Makro speichern“ (bei abgespielten Szenarien), „Per Aufnahme erweitern“, „Erneut abspielen“.

Haltepunkte

• Beim Start: Im Reiter Dialogfunktionen spielt „bis Schritt n“ das Makro automatisch bis vor diese Funktion und hält dort an; „Live ansehen“ und „In der Maske neu erfassen“ im Editor halten ebenfalls am gewählten Schritt.
• Während der Wiedergabe: Links im Ablauf steht vor jedem noch ausstehenden Schritt ein Punkt ●. Ein Klick setzt bzw. entfernt dort einen Haltepunkt. Bis Haltepunkt spielt ohne Pause bis zum nächsten gesetzten Haltepunkt und hält dort an; danach schrittweise oder automatisch weiter.

Tipps und typische Meldungen

Adresse #/bericht/<lauf> · erreichbar über „Prüfbericht“ im Lauf-Kopf, die GO/NO-GO-Plakette oder die Befehlspalette

Das Ergebnis eines Laufs als Dokument – für Abnahme, Lenkungskreis und Ablage beim Kunden.

Inhalt

1. Freigabe-Entscheidung – kompakte Kriterienliste mit Punkten.
2. Kennzahlen des Laufs – Beobachtungen, Szenarien/Schritte, grün, Befunde, Abdeckung schreibend/lesend, MCP-Tools, Masken, Tabellen, Prüfketten.
3. Abweichungen gegenüber der Referenz – je Schweregrad Anzahl, freigegeben, abgelehnt, offen; instabile; Liste der kritischen und hohen Abweichungen.
4. Befunde nach Klasse und Bereich.
5. Prozessabdeckung je Bereich – Szenarien, grün, Schritte, Befund-Schritte, Endpunkte geprüft.
6. Freigaben – Zeit, Person, Entscheidung, Abweichung, Begründung.
7. Bestätigung – Unterschriftsfelder Qualitätssicherung und Fachbereich / Produktverantwortung.

Als PDF speichern

„Drucken / als PDF speichern“ öffnet den Druckdialog des Browsers; dort „Als PDF speichern“ wählen. „← zum Lauf“ führt zurück. Zusätzlich im Lauf-Kopf: Protokoll PDF, Markdown und Release Notes.

Stimmt die Buchhaltung fachlich – nicht nur technisch? Die Fachprüfung prüft jeden Prüfbeleg Zeile für Zeile gegen einen Buchungssatz-Katalog, stimmt den Abschluss ab und lässt optional eine KI als Zweitprüfer drüberschauen.

A · Szenarien 97f „Fachprüfung Buchungen“

• Katalog config/buchungssaetze.json: 29 Geschäftsvorfälle mit 86 erwarteten Buchungszeilen und 9 Steuerschlüsseln (je mit UStVA-Kennzahl und Norm). Zeilen können $variablen, Kontoalternativen und optionale Zeilen enthalten.
• Je Beleg wird jede Katalogzeile geprüft (Konto, Soll/Haben, Betrag, Steuerschlüssel), dazu „keine unerwartete Zeile“, Soll = Haben, Belegstatus und Kopfbeträge. Der Beleg wird als Wert „Fachprüfung Beleg <Vorfall>“ festgehalten – Grundlage der KI-Zweitprüfung.
• SKR04 nach DATEV (v46): Die SKR04-Vorlage der App führt jetzt die DATEV-Kontonummern (Beispiele: 1246 Einzelwertberichtigung, 1248 Pauschalwertberichtigung, 3840/3841 USt laufendes Jahr/Vorjahr, 6920 Einstellung PWB, 6923 Einstellung EWB, 6930 Forderungsverluste, 1460 Geldtransit, 3250 erhaltene Anzahlungen, 5200 Wareneingang). Bestehende Pläne werden nur bei ungebuchten, nicht referenzierten Konten umgeschlüsselt. Die Erwartungen des Prüfstands folgen dem: Szenario 34a bucht EWB 6923 an 1246 und PWB 6920 an 1248; 96-B Verzugszins 7100 (Scheck bleibt 1890, weil ein Katalog die Nummer referenziert); 75-treasury, 34q und 9c-code-fi-r1 erwarten die Demo-Egypt-Konten nach DATEV (u. a. 4840, 6304, 1300, 1360, 0930, 0810, 7355, 7100, 7300; 1890 und 6850 bleiben); im Katalog buchungssaetze.json bucht der Vorfall „mahngebuehr“ (Nordlicht, BuKr NL1) die Verzugszinsen auf 7100. Die Vorfälle des Demo-Kunden (SKR03) sind unverändert.
• GoBD-Siegel (v46): Jeder gebuchte Beleg wird beim Commit versiegelt – auch Zahlungen, Bankausgleiche und Modulbelege; Belege ohne Journal bilden eine eigene Kette. Die Konsistenzregeln fi-gebucht-ohne-siegel und fi-siegel-kette prüfen das (siehe Konsistenzregeln: neu in v46).

B · Szenarien 97g „Fachprüfung Abschluss“

• Saldenliste, Bilanz und GuV abgestimmt, Saldovortrag je Bestandskonto, Nebenbücher (Debitoren, Kreditoren, Anlagen) gegen das Hauptbuch, Anlagenspiegel, Bestand gegen Bestandskonten (Bewertung aller Werke eines Buchungskreises gegen das Warenbestandskonto, wie SAP MB5L).
• UStVA-Entwurf des laufenden Monats gegen die Salden der Steuerkonten.
• Periodensperre: Periode schließen, Buchungswege prüfen (müssen abgewiesen werden), wieder öffnen.
• Bekannte Befunde aus dem Prüfauftrag cefd1ba sind ausdrücklich geprüft: B99s-5 (Stichtagssaldo nach Saldovortrag), B99s-6 (Jahresabschluss bei Ergebnis ≠ 0), B99s-7 (AfA-Lauf / AfA auf Finanzanlage).

C · Konsistenzregeln fp-…

D · KI-Zweitprüfung (nicht freigaberelevant)

• Ablauf: Nach den Szenarien nimmt die Phase die festgehaltenen Fachprüf-Belege und lässt eine Stichprobe (Vorgabe 40) von der eingerichteten KI (OpenAI oder Anthropic, Einstellungen) nach HGB, UStG und SKR beurteilen.
• Reproduzierbar: Temperatur 0 und Ergebnis-Cache je Beleg-Fingerabdruck (Beleginhalt, Modell, Prompt-Version) – gleiche Belege werden nicht neu bewertet.
• Ergebnis: Beobachtungen der Ebene „KI-Hinweis“ mit Status immer „ok“ – nie ein Befund, kein Muss-Kriterium. Im Lauf-Kopf: Status, Belege, Hinweise auf Abweichung und Verbrauch (Tokens ein/aus, Anfragen, Kosten €).
• Ohne Schlüssel oder abgeschaltet wird die Phase übersprungen (eine Beobachtung „KI-Zweitprüfung nicht konfiguriert“ bzw. „abgeschaltet“). Drei Fehler in Folge oder ein erreichtes Budget beenden sie sauber.
• Datenschutz: Gesendet werden nur Testdaten des Golden-Records (Konten, Beträge, Steuerschlüssel, Belegart, Normen) – keine IDs, Belegnummern, Personen- oder Zugangsdaten.

Storno, Retoure, Abschluss und modulübergreifende Ketten verursachen im Betrieb die meisten Fehler. Eigene Szenarien prüfen sie mit Abstimmregeln bis ins Hauptbuch.

• Jede Kette läuft vom ersten Beleg bis zur Abstimmung im Hauptbuch; Folgewirkungen (Bestand, Debitor, Erlös, Steuer, WE/RE) werden als Deltas auf eigenen Stammsätzen geprüft – unabhängig von anderen Szenarien.
• Die Zeitsprung-Szenarien 99-Z-zeit-* laufen immer zuletzt; Sonderfälle und Ketten laufen davor mit der eingefrorenen Uhr (21.10.2026). Alle Datumswerte sind trotzdem ausdrücklich gesetzt.
• Mengen- und Summenregeln (sd-menge-geliefert, sd-menge-fakturiert, mm-menge-fakturiert, auftrag-kopf-summe) zählen Storno-Belege, stornierte Materialbelege und Abschlags-/Anzahlungspositionen nicht mit – wie SAP: die Rechnungsmenge einer Bestellung zählt erst mit dem gebuchten FI-Beleg (MIRO), eine Retouren-Gutschrift gehört zum Retourenauftrag. aa-afa-plan rechnet übernommene AfA (Altanlagen) mit ein.
• Erwartete Störfälle mit HTTP 5xx (z. B. IMAP-Abruf, RFC-Runtime) prüfen Szenarien mit einem eigenen Client als Störfall; umgeschaltetes Customizing wird im finally zurückgesetzt.
• Welche Kombination Kernprozess × Art abgedeckt ist, zeigt die Matrix inventory/sonderfall-matrix.md.
• Hinweis für Szenario-Autoren: /api/fi/balance-sheet liest den Stichtag aus year/month.

Der Prozesskatalog scenarios/prozesskatalog.json listet jede fachliche Prozessvariante mit Erwartung und den Szenarien, die sie prüfen. Er ist die Messlatte für das Kriterium „Alle Prozessvarianten des Katalogs geprüft“.

Status je Variante

Wie der Katalog entsteht

1. Quellkataloge als Markdown in inventory/kataloge/ (je Bereich Prozesse, Varianten, Erwartungen).
2. Entscheidungen dauerhaft in scenarios/code-zuordnung/katalog-*.json: katalog-entscheidungen.json (Status, Begründung, ausdrückliche Szenario-Zuordnung – auch für dynamisch erzeugte Szenario-IDs), katalog-sonderfall.json, katalog-sap.json.
3. Bauen: node scripts/build-process-catalog.mjs --stand <JJJJ-MM-TT> inventory/kataloge/*.md; Optionen --out <datei> (Vorgabe scenarios/prozesskatalog.json) und --ohne-entscheidungen.
4. Abnahme: mit --vergleich <datei> schreibt das Skript nichts, sondern vergleicht mit dem vorhandenen Katalog – erwartet sind 0 Abweichungen (sonst Exit 1).

Szenarien gegen Lücken

Die Dateien 98a–98m (IDs lk-… bis lk4-…, Lückenrunden 1–4; Feld runde in katalog-entscheidungen.json) schließen Katalog-Lücken bereichsweise (FI, CRM/Personal/Handel, Plattform, Marktplatz/Treasury, CCM/NGO/Filiale, FI/HR/Einkauf, Abweisungen, Plattform-Module, FSV/Ausgabe, Lohn/GaLaBau/NGO, Rest). 98k prüft die Vorbedingungen der Klasse-c-Ausnahmen (Vier-Augen nur als Plattformvorlage, Zeitablauf ohne Stichtag): wird es rot, ist die Ausnahme neu zu entscheiden. Grundsätze: Vier-Augen nur mit echtem zweitem Benutzer, Zeitablauf nur über Stichtag oder Job der App; Customizing, das ein Szenario vorübergehend umschaltet, wird in finally zurückgesetzt. Entscheidungsarten je Lücke: neues Szenario, Zuordnung korrigiert (ein vorhandenes Szenario erreicht den Zustand nachweislich), Szenario mit Befund (bleibt rot bis zur App-Korrektur), ausgenommen, nicht angeboten. Szenarien mit dynamisch erzeugter ID werden über katalog-entscheidungen.json den Varianten zugeordnet.

Die Szenarien 96s-sap-p0…p7-* (IDs sap-p…) weisen die SAP-Umsetzung je Paket nach; ihre Zuordnung steht in inventory/sap-zuordnung-*.json und wird mit katalog-sap-umsetzung.json in den Katalog übernommen. Umgesetzt und nachgewiesen sind P0, P1, P2, P5 (Branchen, Projekte, Abo, Facility, Handel/Filiale, Service, CRM: u. a. Wartungsfreigabe, Reparatur-Rückgabe, Abo-Gutschrift und Kündigungsrücknahme, Kassentag mit Bestand, Fakturierungsplan, Agentur-Zinslauf, Umlage nach Belegung, CCM-Termin sperren, Chargeback; Szenarien 96s-sap-p5-*), P4 (Personal & Lohn: Rückrechnung, SEPA-Exportlauf, Lohnkonto, Rückrechnungsgrenze, LStB-Korrektur, Reisekosten-Korrektur, SFN-Zuschläge, zweistufige Abwesenheitsgenehmigung, Spesen in Fremdwährung, Zeiterfassung nach CATS, Betriebsrat bei Stellenanforderungen) und P7. Zwei P4-Szenarien schalten Einstellungen vorübergehend um und setzen sie in finally zurück (sap-p4-spesen-fremdwaehrung/-reisekosten-korrektur das Modul DocCap, sap-p4-rueckrechnungsgrenze Rückrechnungsgrenze und Sammelsperre 2025). Mehrere P4-Szenarien melden sich als zweite Person an (Vier-Augen) – das erhöht die Zahl der Anmeldungen je Lauf.

Neue und geänderte Szenarien in v46

Vier Ebenen erweitern den Lauf über die Fachlichkeit hinaus. Alle arbeiten nur gegen die QS-Instanz, legen eigene Wegwerf-Objekte an (Kürzel ZZ-SI, QSLT …) und verändern keine Golden-Daten.

Last

• 8 virtuelle Benutzer verschiedener Rollen (FI, Vertrieb, Einkauf, Lager, CRM, Administrator) arbeiten gleichzeitig mit fester Zahl von Iterationen (Vorgabe 5) auf typischen Lese- und Schreibpfaden – z. B. Ausgangsrechnung anlegen und buchen, Angebot, Bestellung im Entwurf.
• Befund bei Serverfehler oder Verbindungsabbruch unter Last, doppelten Beleg-/Auftrags-/Bestellnummern (kritisch), nicht ausgeglichener oder nicht gebuchter Rechnung und wenn das p95 die Schwelle überschreitet (Lesen 2.000 ms, Schreiben 5.000 ms).
• Antwortzeiten (p50/p90/p95/p99) stehen nur als Information; verglichen wird „Schwelle eingehalten ja/nein“. Umfang QSGATE_LAST_VU (1–20), QSGATE_LAST_ITER; Schwellen QSGATE_LAST_P95_LESEN_MS, QSGATE_LAST_P95_SCHREIBEN_MS; aus mit QSGATE_LAST=off.

Sicherheit

• Mandantentrennung: eigene Objekte des Demo-Kunden mit dem Administrator eines fremden Mandanten lesen, ändern, löschen → 403/404, nie Daten; dazu eine Stichprobe lesender Objekt-Endpunkte (QSGATE_SICHERHEIT_STICHPROBE, Vorgabe 30).
• Buchungskreistrennung: eigener Benutzer nur für DK5 versucht, Belege und Salden eines fremden Buchungskreises zu lesen, zu ändern oder anzulegen.
• Eingabe-Angriffe: SQL-Injection in Such-/Sortierparametern, XSS-Nutzlasten (Befund, wenn die Oberfläche sie ausführt), Path Traversal an Datei-Endpunkten, übergroße Nutzlast, Mass Assignment (z. B. tenant_id, isAdmin).
• Anmeldung: manipulierte Tokens → 401, Abmeldung sperrt Zugangs- und Refresh-Token, schreibende Routen ohne Anmeldung (Stichprobe QSGATE_SICHERHEIT_OHNEAUTH, Vorgabe 150). Aus mit QSGATE_SICHERHEIT=off.

Barrierefreiheit & Mobil

• Die 30 wichtigsten Masken (QSGATE_A11Y_MASKEN) mit axe-core nach WCAG 2.0/2.1 A+AA bei 1.440 px: Verstöße „critical“/„serious“ sind Befunde, „moderate“/„minor“ nur Information.
• Dieselben Masken bei 390 px (Touch): waagrechtes Scrollen und abgeschnittene Bedienelemente sind Befunde; Touch-Ziele unter 24 × 24 px werden gezählt.
• Standardmäßig ausgeschaltet. Einschalten unter Einstellungen › Prüfumfang (gilt ab dem nächsten Lauf); läuft nur mit Oberfläche; QSGATE_A11Y=off schaltet unabhängig von der Einstellung ab. Ist die Ebene aus, entfallen auch ihre Kriterien in der Bewertung.

Datenmigration

Szenarien 97m (IDs dm-…): Stammdaten-Import mit Abgleich von Anzahl und Summen gegen die Datei, Fehlerprotokoll mit richtiger Zeilennummer und idempotenter Wiederholung; Eröffnungsbilanz mit Abstimmung der Saldenliste und Storno; Cutover-Anfangsbestände; Import über den KI-Assistenten (MCP).

Vorgesehene Freigabekriterien (rules.json › kriterien)

Ist eine Ebene nicht gelaufen oder abgeschaltet, entfällt ihr Kriterium (wie bei Rechten und Nebenläufigkeit).

Statt jede Abfolge von Hand zu schreiben, beschreibt ein Zustandsmodell je Belegkette, welche Schritte wann zulässig sind. Ein Generator erzeugt daraus reproduzierbar Pfade – Teillieferung, Storno, Storno vom Storno, Gutschrift, Retoure … – und prüft jeden Schritt bis ins Hauptbuch.

Zustandsmodelle

Modelle liegen in src/varianten/modelle/. Jede Aktion hat pruefe(z) (zulässig, abgewiesen mit erwarteten Fehlercodes und Begründung, oder null = Verhalten nicht festgelegt – solche Übergänge werden nicht erzeugt) und wende(z) (Folgezustand).

Generator und Szenarien

• Abdeckungsziel: erst jeder Übergang (Aktion × Erwartung × Begründung), dann jedes Paar aufeinanderfolgender Übergänge; offene Ziele werden auf dem kürzesten Weg angesteuert. Gleicher Seed und gleiche Parameter ergeben dieselben Pfade.
• Szenario-Dateien scenarios/9v-varianten-o2c.mjs, -p2p, -fertigung, -anlagen (laufen nach 9m und vor den Zeitsprung-Szenarien). Szenario-IDs 9v-<modell>-<hash der Aktionsfolge> bleiben stabil, solange die Aktionsfolge gleich ist; dazu je Modell 9v-<modell>-abdeckung mit den Abdeckungszahlen als Wert.
• Prüfungen je Schritt: Erwartung und HTTP-Code; nach zulässigen Schritten Mengen und Status am Beleg (Fertigung/Anlagen auch Bestand und Buchwert). Am Ende: jeder FI-Beleg gegen seinen Vorfall in config/buchungssaetze.json bzw. als Spiegel seines Originals, Soll = Haben, Kontosalden über alle Belege des Pfads, Bestand, offene Posten, Status.
• Abweichung ⇒ Pfad endet: Weicht die App von der Erwartung ab, endet der Pfad; Belegfluss und Bestand werden als Nachweis-Wert festgehalten. Ein Schritt mit dem Zusatz „(abgewiesen erwartet)“ in der Pfadbeschreibung muss von der App abgelehnt werden – wird er angenommen, ist das der Befund.
• Eigene Stammdaten je Pfad (Präfix ZZ-9V-…, eigener Kunde/Lieferant, eigene Anlagenklasse): die Pfade sind voneinander und von der Reihenfolge unabhängig. Hinweis: der AfA-Lauf ist mandantenweit und bucht auch fällige AfA fremder Anlagen (wie 31a/33/99-A).

Stufen und Umgebungsvariablen

Export und Vergleich mit SAP (manuell)

1. Lauf mit QSGATE_VARIANTEN_EXPORT=<Verzeichnis>. Spalten des CSV: REFKEY, VORGANG, BUKRS, BELNR, GJAHR, BLART, BUDAT, XBLNR, STORNO_ZU, BUZEI, HKONT, SHKZG, DMBTR, MWSKZ, MATNR, MENGE, SGTXT.
2. Vorgang in SAP Schritt für Schritt nachstellen; je Beleg den REFKEY 9V-<hash>-<Schritt> als Referenz (XBLNR) eintragen, alternativ in Zuordnung oder Kopftext.
3. Einzelposten exportieren (FBL3N oder SE16N BKPF/BSEG) als CSV – Trennzeichen ;, , oder Tab und deutsche Zahlen werden erkannt.
4. Vergleich: node src/varianten/sap-abgleich.mjs --variante <ID>.json --sap sap.csv [--konten zuordnung.json] [--schluessel XBLNR] [--toleranz 0.01] [--json ergebnis.json]. Zuordnungsdatei: {"konten":{"1400":"140000",…},"steuer":{"A19":"A1"}}.
5. Ergebnis je Beleg: gleich, abweichend, „fehlt in SAP“, „nur in SAP“; dazu Steuerkennzeichen und Kontosalden der ganzen Variante (ohne REFKEY im SAP-Export nur Salden). Exit-Code 0 = gleich, 1 = Abweichungen, 2 = Bedienfehler.

Automatisch gegen ein SAP-Testsystem: Kapitel SAP-Abgleich. Modell erweitern: neue Aktion mit pruefe/wende/api ergänzen, für nicht festgelegtes SAP-Verhalten null liefern und test/varianten.test.mjs erweitern. Stand 31.10.2026: alle vier Modelle in Stufe „woche“ grün; die mit den Varianten gefundenen App-Fehler (Überlieferung ohne Toleranz, WA-Storno nach Retoure/Faktura, Retoure zu stornierter Lieferung, Fertigung vor Freigabe, 262-Storno, Anlagen-Zugangsstorno nach Abgang) sind behoben. Noch nicht modelliert: Zahlung/OP-Ausgleich, Mahnung.

„Im Zweifel so wie SAP“ – messbar gemacht: Die optionale Phase „SAP-Abgleich“ liest das Customizing eines angebundenen SAP-ECC-Testsystems und vergleicht es mit dem realERP-Customizing des QS-Gates; mit ausdrücklicher Freigabe bucht sie zusätzlich Vergleichsfälle in SAP und stellt sie den realERP-Belegen gegenüber.

Weg der Aufrufe

Prüfstand → realERP-Backend (realerpdev, Mandant mit der hinterlegten sap_rfc-Verbindung) → Integration-Runtime (/runtime/rfc/*) → SAP. Der Prüfstand spricht nie direkt mit SAP; er meldet sich wie ein Benutzer am realERP-Mandanten an.

1 · Lesender Abgleich (Customizing)

• SAP-Tabellen: T001, T001K, T001W, T030, T156, T156X, T156W, T003, T169G, SKA1/SKB1 (nur die Konten der Kontenfindung), T007A. Felder, die es im Zielrelease nicht gibt, werden aus der Feldauswahl entfernt und der Lesevorgang wiederholt.
• realERP-Seite: /api/cfg/account-determination, movement-types, fi-doc-type-map, /api/accounts/accounts, /api/cfg/tax-codes.
• Kontenrollen statt Kontonummern: Die Zuordnung config/sap-abgleich-zuordnung.json stellt SAP-Vorgänge (BSX, WRX, PRD, GBB-xxx …) den realERP-Vorgängen mit Soll-/Haben-Seite gegenüber, dazu Belegarten, Steuerkennzeichen und Toleranzen. Kontonummern werden nur verglichen, wenn eine Kontenzuordnung vorliegt – aus der Datei oder aus dem Migrationsprojekt (SAPREF_PROJECT_ID, Wertzuordnung Domäne gl_account).

2 · Schreibende Vergleichsfälle (nur mit Opt-in)

Laufen nur, wenn am Prüfstand SAPREF_SCHREIBEN=1 gesetzt und an der sap_rfc-Verbindung im Integration Hub von realerpdev der Schalter „Schreiben erlaubt“ eingeschaltet ist (Tenant-Admin mit settings:update; Vorgabe aus, jede Änderung wird protokolliert). Gebucht wird nur über eine fest eingebaute Liste freigegebener BAPIs; ohne beides wird nichts geschrieben.

Danach werden BKPF/BSEG, MSEG, EKBE und VBFA gelesen und je Vorgang (WE, RE, WA, Faktura, Gutschrift) mit dem realERP-Belegexport der Prozessvarianten verglichen (Verzeichnis QSGATE_VARIANTEN_EXPORT bzw. SAPREF_REALERP_EXPORT; die passende Variante wird über Modell und Aktionsfolge gewählt). Geprüft: Rollen-Summen je Soll/Haben, Steuer, Preisdifferenz (PRD), Mengen in MSEG/EKBE und Bestand. Fehlt ein Beleg auf einer Seite, ist das eine eigene Abweichung (z. B. „realERP sperrt die Rechnung, SAP bucht sie“).

Ergebnisarten

Umgebungsvariablen am Prüfstand

Nur als Umgebungsvariablen des Prüfstand-Dienstes setzen – nie in Dateien, Makros oder dieses Handbuch. Werte (insbesondere Benutzer und Passwort) vergibt der Betrieb.

Einzeln aufrufen

node scripts/sap-abgleich.mjs [--json] [--ausgabe <Verzeichnis>] – gleiche Umgebungsvariablen; ohne sie „übersprungen“ mit Exit 0.

Phase im Lauf: nach der KI-Zweitprüfung. Was erst mit echtem Zugang feststeht: ob die zustandsbehaftete SOAP-RFC-Sitzung BAPI und Commit in einem Kontext ausführt (sonst meldet der Prüfstand „kein FI-Beleg … Sitzung zustandsbehaftet?“), releaseabhängige Parameter und die Berechtigungen des SAP-RFC-Benutzers. Nach dem ersten Lauf mit gesetzten Variablen das Ergebnis unter run.sapAbgleich prüfen.

Fehler, die nur in einer bestimmten Reihenfolge oder zu einer bestimmten Uhrzeit auftreten, findet ein Lauf auf festem Stand nie. Variantenläufe mischen die Szenario-Reihenfolge oder stellen die Uhr auf kritische Zeitpunkte – und vergleichen nur, ob etwas rot wird.

Was ein Variantenlauf ist

• Ausgelöst durch eine gemischte Reihenfolge oder eine Zeit-/Zeitzonen-Variante. Der Lauf trägt run.variante (Zeit, Ziel, DB-Zeitzone bzw. Reihenfolge-Modus und Seed); der Lauf-Kopf nennt die Variante im Hinweis.
• Nur Statusvergleich (ok ↔ Fehler je Beobachtung) gegen die Referenz – Belegnummern und Daten verschieben sich gewollt.
• Nicht freigaberelevant und nicht referenzfähig: „Als Referenz übernehmen“ und POST /api/v2/runs/:id/baseline sind gesperrt.
• Varianten brauchen eine frisch zurückgesetzte Instanz (sonst z. B. schon fakturierte Verträge oder ein Vier-Augen-Lauf ohne Anforderung) – vor jeder Variante zurücksetzen.

Reihenfolge „gemischt“

Die Zeitsprung-Dateien 99-Z-zeit-* bleiben immer zuletzt (Muster änderbar mit QSGATE_SZENARIO_ORDER_ZULETZT). Modus, Seed und Dateifolge stehen in run.szenarioReihenfolge.

Isolationsprüfung: „reihenfolgeabhängig“

• Optionale letzte Phase Isolationsprüfung: QSGATE_ISOLATION=<max. Anzahl> schaltet ein (Vorgabe aus). Ablauf: ein Reset (QSGATE_RESET_CMD lokal, sonst Deploy-Hook bzw. Neustart wie vor manuellen Läufen), danach laufen die roten Szenarien einzeln. Ohne Reset-Möglichkeit wird sie übersprungen; QSGATE_ISOLATION_OHNE_RESET=1 erzwingt sie auf dem Stand nach dem Lauf (nur Indiz).
• Je Szenario eine Beobachtung isolation:<id> mit dem Ergebnis:

Die Phase meldet dem Server den gewollten Neustart (resetting), damit der Lauf nicht als „überholt“ gilt. Kosten: ein Reset (2–5 min) plus die Szenarien. Lokal: node scripts/isolationspruefung.mjs --beobachtungen <observations.json.gz|Laufverzeichnis> oder --ids a,b [--je-szenario].

Zeitmodus

Das QS-Gate läuft unter libfaketime; eine Zeit-Variante stellt die Uhr vor „Datenbank vorher“ auf einen kritischen Zeitpunkt (UTC). Die Uhr läuft danach weiter – „monatsende“ überschreitet nach 30 Minuten den Monatswechsel, gewollt.

• Zeitzone der Datenbank: QSGATE_DB_ZEITZONE bzw. dbZeitzone (IANA-Name, z. B. Pacific/Kiritimati, America/Los_Angeles) setzt die Datenbank-Zeitzone für diesen Lauf; ruhende App-Verbindungen werden beendet, damit sie sofort gilt.
• Zeitzone der App bzw. Grundeinstellung der DB am QS-API-Dienst: QSGATE_APP_TZ (Vorgabe UTC) und QSGATE_DB_TZ (Vorgabe Europe/Berlin) in backend/qsgate/start.sh.
• Die Uhr ist ein Abstand zur echten Uhr; App und Datenbank zeigen dieselbe Zeit (kein Vorlauf der DB mehr um die Dauer des Golden-Resets). frozenToday kommt im Variantenlauf von der verstellten Uhr. Am Ende stellt der Prüfstand die DB-Zeitzone zurück und die Uhr auf „Golden-Zeit + Laufdauer“; protokolliert werden App-Uhr, DB-Uhr, DB-Datum und Abstand.

Starten

• Schnittstelle: POST /api/v2/start mit {"zeit":"monatsende"}, {"dbZeitzone":"Pacific/Kiritimati"} und/oder {"reihenfolge":"shuffle:42"}.
• Umgebung (gilt für jeden Lauf, solange gesetzt): QSGATE_SZENARIO_ORDER, QSGATE_ZEIT, QSGATE_DB_ZEITZONE. Für den Normalbetrieb nicht dauerhaft setzen – sonst ist kein Lauf mehr freigaberelevant.

Instabile Abweichungen einordnen

node scripts/instabil-analyse.mjs <abweichungen.csv> ordnet wechselnde Abweichungen eines Laufs Ursachen zu: Datenstand (Szenario soll auf eigene Daten filtern), Schrittfolge (bedingte Schritte verschieben die Nummern), Nummernversatz, asynchron, Reihenfolge (Listen ohne Sortierung – App-Befund), Zufallscode, interne IP-Adresse. Die beiden letzten sind in rules.json normalisiert (siehe Normalisierung); die übrigen werden im Szenario oder in der App behoben, nicht weg-normalisiert.

Alles, was das Cockpit zeigt, liefert die JSON-Schnittstelle /api/v2 – für Coding-KI, Automatisierung und eigene Auswertungen.

Anmeldung

• Im Browser genügt die Cockpit-Anmeldung (Sitzungs-Cookie).
• Für Skripte und Agenten: Kopfzeile Authorization: Bearer <Zugangspasswort des Prüfstands>. Das Passwort erhalten Sie vom QS-Team; es gehört nie in Code, Tickets oder Unterlagen.
• Ohne Anmeldung antwortet die Schnittstelle mit HTTP 401 {"error":"nicht angemeldet"}. Über die Schnittstelle gesetzte Freigaben tragen den Namen „API“.

Wichtige Endpunkte

Außerhalb von /api/v2: /gesund (Erreichbarkeit, ohne Anmeldung; mit laeuft und wartet), /api/status (laufender Lauf, Warteschlange mit wartendem Stand, geplantem Start und Deploy-Modus), /lauf/:id/protokoll.pdf|.md|.json, /lauf/:id/release-notes.md, /klassisch (klassische Ansicht).

Die drei Dienste (Branch qsgate)

Golden-Record

• Fester Datenstand vom 21.10.2026: rund 370.000 Datensätze in über 1.000 Tabellen, ~22 Monate Kerngeschäft.
• Schema immer aus dem Installer, danach Deltas und Ergänzungen (Kontenfindung, Nummernkreise, Testbenutzer …). Fehlende Golden-Daten werden per Ergänzung behoben, nicht in der App; der Golden-Record ändert sich nur per Pull Request.
• Altdaten-Korrekturen: Fehlerhafte Testdaten werden per Ergänzung richtiggestellt, nicht durch einen Neuaufbau (der Aufbau ist nicht reproduzierbar). Geänderte versiegelte Belege bekommen ihre Hash-Kette nach der Formel der App neu berechnet; die App selbst umgeht keine Siegel. Beispiele: 025 (Zeilensaldo = Soll − Haben), 036 (Wareneingänge auf Bestandskonto statt Eigenkapital), 037 (Zugangsbelege der Seed-Anlagen wie AS91), 038 (Intercompany-Verrechnungskonten in Vorgangsrichtung), 039 (Kontenfindung Einkauf „Meine Firma“), 040 (FI-Nachbuchung von 415 Materialbelegen ohne Buchhaltungsbeleg auf dem Weg „FI nachbuchen“ der App, danach Bestandsabstimmung als Altdatenübernahme „1600 an 9000“), 041 (Kontenfindung je Bewegungsart für „Meine Firma“), 042 (Preisdifferenzkonto mit Kontenfindung PRICE_DIFFERENCE), 043 (Kontenfindung Inventurdifferenz 701/702/ADJ), 044 (Erstbestand 561 für Lagerortbestände ohne Materialbeleg, alle Werke), 045 (Preisdifferenzkonto Nordlicht/Demo Egypt), 046 (Wertübernahme Altbestand DK5 zum Standardpreis, Abstimmung 1600 an 9000), 050 (Verrechnungskonto Anlagenzugang 1596), 051 (Wertübernahme Altbestand Demo Egypt und Meine Firma zum Standardpreis, Abstimmung Bestandskonto gegen Übernahmekonto), 052 (Werk DC10R in Demo Egypt: doppelt übernommener Bestand per Storno 562 aufgelöst, Lager nur noch Werk EG10). Mit v46 dazu: 054 (zwei fehlende Audit-Einträge nachgetragen, beide Supportfälle mit Begründung geschlossen), 055 (FI-Nachbuchung der letzten FI-relevanten Bewegung ohne FI-Beleg, Korrektur der Altdaten-Abstimmung aus 040), 056 (Kontenfindung „Meine Firma“ und Demo-Kunde vollständig), 059 (Siegel-Ketten in Kettenfolge neu berechnet, als letzte Ergänzung), 060 (1.636 gebuchte Altbelege ohne Siegel an die Kette angehängt, Prüfung „lückenlos 1..n“).
• Start-Zeilenzahl: 299.835 bis v45; mit den Ergänzungen bis 059 gemessen 303.381 (1.568 Tabellen). Maßgeblich ist der erste fertige Lauf mit dem neuen Golden-Stand – danach die Referenz neu setzen.
• Mandanten: Demo-Kunde (Hauptmandant, alle Modulbereiche; Buchungskreis DK5, Werk DE01), Meine Firma GmbH (Ergebnisse der In-App-Prüfketten), Nordlicht Software GmbH (Edition Start), Demo Egypt (Länderpaket Ägypten).
• Muss-Kriterium „Start auf frischem Golden-Record“: bei gleichem Golden-Stand Zeilenzahl wie in der Referenz (Toleranz 0,05 %, mind. 50 Zeilen); bei neuem Golden-Stand bestanden mit Hinweis „Referenz neu setzen“. Muss-Kriterium „Golden-Record konsistent“: alle 65 Konsistenzregeln vor den Szenarien bei 0 (siehe Bewertung).
• Neu erfasster Dump: Die IDs der Golden-Daten ändern sich einmalig – der erste Lauf zeigt dadurch viele Abweichungen; prüfen, freigeben und neue Referenz setzen (Referenzwechsel).

Eingefrorene Uhr

• Datenbank und App laufen mit fester Uhr: 21.10.2026 ab 18:00 Uhr (nach Erzeugen des Golden-Records – neue Sätze sind immer jünger).
• Jede Version rechnet mit demselben „Heute“ – Fälligkeiten, Alter, Perioden bleiben gleich, sonst wäre der Vergleich mit der Referenz wertlos.
• Ein Lauf muss vor Mitternacht der eingefrorenen Uhr fertig sein; darum vor jedem Lauf zurücksetzen. Muss-Kriterium „Uhr steht auf dem Golden-Tag“.
• Technik (libfaketime): Die Uhr wird als Abstand zur echten Uhr geführt; App und Datenbank starten gemeinsam auf 18:00 und zeigen dieselbe Zeit. Zeitzonen am QS-API-Dienst: QSGATE_APP_TZ (App, Vorgabe UTC) und QSGATE_DB_TZ (Datenbank, Vorgabe Europe/Berlin). Das Buchungsdatum der App ist der Geschäftstag in Europe/Berlin. Verstellen nur über einen Variantenlauf.

Reset und Laufstart

• Reset-Methode: Deploy-Hook des API-Dienstes oder Neustart über die Render-Schnittstelle – je nach Einrichtung; ohne beides kein automatischer Reset (Warnung beim manuellen Start).
• Neue Version wird über den Gesundheits-Endpunkt erkannt (Abfrage standardmäßig jede Minute), Start nach 180 s. Neue Commits während eines Laufs warten (nur der jüngste); Deploy-Modus „auto“ oder „fenster“ – siehe Ablauf.
• Prüfläufe und Studio-Wiedergaben warten aufeinander. Der Prüfstand drosselt sich selbst: Vorgabe 450 Anfragen/min (QSGATE_MAX_RPM) und 14 Anmeldungen je 15 Minuten (QSGATE_MAX_AUTH_15MIN); im QS-Testsystem sind beide angehoben (4.500 bzw. 450), passend zu den angehobenen Limits der QS-API.

Umgebungsvariablen (Auswahl, neu)

Konfigurationsdateien (config/)

Kommandozeile und CI

• node src/cli.js run [--parallel=N] [--schnell --dateien=…|--seit=<ref>] – Lauf bzw. Schnelllauf.
• node src/cli.js plan [--parallel=N] – Parallel-Plan der Szenario-Phase aus dem Profil der Referenz.
• node src/cli.js vergleich <laufA> <laufB> [--ebene=szenarien] – Beobachtungen zweier Läufe vergleichen.
• node scripts/sap-abgleich.mjs [--json] [--ausgabe <dir>] – SAP-Abgleich einzeln; node src/varianten/sap-abgleich.mjs --variante … --sap … – Varianten-Export gegen SAP-CSV.
• node scripts/isolationspruefung.mjs – rote Szenarien einzeln auf frischem Stand; node scripts/instabil-analyse.mjs <abweichungen.csv> – instabile Abweichungen nach Ursache.
• GitHub-Workflow .github/workflows/pruefstand.yml bei Änderungen unter qsgate/pruefstand/**: npm ci, Syntax aller Quellen und Szenarien, Szenarien laden, Konfiguration prüfen, npm test.

Datenablage (Disk /data)

Testbenutzer im Golden-Record

Die Rechte-Matrix prüft jede schreibende Route gegen jede Rolle: Recht vorhanden → keine Abweisung; Recht fehlt → 401/403; fremder Mandant → 403/404.

Weitere Fachrollen: qs-fertigung, qs-personal, qs-crm, qs-controlling, qs-admin-light. Passwörter stehen nie in Unterlagen oder Makros (dort nur {{password}}).

Abweichung

Unterschied einer Beobachtung zur Referenz: neu, geändert, entfallen, neuer Fehler, behoben.

Ausgenommen

Prozessvariante, die mit Pflichtbegründung bewusst nicht geprüft wird; zählt nicht in Prüfmenge und Quote.

Befund

Im Lauf fehlgeschlagene Prüfung (Fehler, verletzte Erwartung oder Regel).

Beobachtung

Normalisiertes Ergebnis einer einzelnen Prüfung in einem Lauf (rund 45.000 je Lauf), eindeutig über ihren Schlüssel.

Bereich

Fachlicher Modulbereich (z. B. Finanzbuchhaltung, Lager); Zeile der Modul-Matrix.

Dialogfunktion

Jede Aktion einer Maske, die ein Backend aufruft (Speichern, Buchen, Export …).

Ebene

Art der Prüfung, z. B. Szenarien, API, MCP, Oberfläche, Prüfketten, Datenbank, Kennzahlen, Konsistenz.

Golden-Record

Fester Datenstand (Dump + Ergänzungen), auf den das QS-Gate vor jedem Lauf zurückgesetzt wird.

Golden-Stand

Fingerabdruck des Golden-Records aus Ledger, Ergänzungsdateien und Dump-Manifest; ändert er sich, ist eine neue Referenz fällig.

Instabil

Prüfung, deren Ergebnis ohne Codeänderung zwischen Läufen wechselt.

KI-Hinweis

Beurteilung eines Fachprüf-Belegs durch die KI-Zweitprüfung – nie ein Befund, nicht freigaberelevant.

Konsistenzregel

Fachliche Invariante per SQL, z. B. Soll = Haben oder Bestand = Bewegungen.

Makro

Prozess als JSON im Prozess-Studio: Schritte, gemerkte Werte, Prüfungen – abspielbar, änderbar.

Muss-Kriterium

Freigabekriterium, das bei Verletzung allein NO-GO bedeutet.

Protokollkette

Per SHA-256 verkettete Chronik von Läufen, Freigaben und Referenzwechseln.

Paket

Teil des Prüfauftrags (höchstens ~1.500 Zeilen) mit Priorität, Zuständigkeit, Reproduktion und Akzeptanzkriterium.

Prozessvariante

Fachliche Ausprägung eines Prozesses im Katalog mit erwartetem Ergebnis. Generierte Variantenszenarien 9v-…: Pfade durch ein Zustandsmodell einer Belegkette.

Prüfauftrag

Markdown-Export der Probleme eines Laufs mit Ursachen-Gruppen und Reproduktion für (KI-)Entwickler.

Prüfkette

In der App eingebaute Prüfung über mehrere Schritte (z. B. FI, Go/No-Go, Ledger-Guards).

Qualitätspunkte

Gewichteter Anteil erfüllter Kriterien, 0–100.

Referenz

Zuletzt freigegebener Lauf; jeder neue Lauf wird mit ihm verglichen.

Reihenfolgeabhängig

Szenario, das im Verbund rot und einzeln auf frischem Stand grün ist (Ergebnis der Isolationsprüfung).

Schnelllauf

Lauf nur über die vom Commit berührten Bereiche, ohne Reset, mit reinem Statusvergleich – nicht freigaberelevant.

Szenario

Geschäftsprozess als Programm (scenarios/*.mjs), läuft über die API bis zum Endzustand.

Überholt

Lauf, der endete, weil die API währenddessen neu deployt wurde; Teilergebnis gespeichert, nicht bewertet.

Variantenlauf

Lauf mit gemischter Reihenfolge oder Zeit-/Zeitzonen-Variante; nur Statusvergleich, nicht freigaberelevant, nicht referenzfähig.

Unangekündigt

Abweichung in einem Modul, das im Pull Request nicht angekündigt war; eine Stufe schwerer, vier Augen.

Ursachen-Gruppe

Befunde mit derselben normalisierten Fehlermeldung – eine Ursache, viele Symptome.

Warteschlange

Höchstens ein wartender Stand (der jüngste), der nach dem laufenden Lauf geprüft wird – „wartet: <commit>“.

Zuständigkeit

Automatische Einordnung eines Befunds: App-Fehler, Testdaten/Szenario, Customizing/Golden-Record, Fehlalarm-Verdacht, Infrastruktur.

Jede Änderung, die Anwender sehen oder bedienen, ändert im selben Commit das Handbuch mit (siehe AGENTS.md). Neueste Einträge oben.