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), 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.
• 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.

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).

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.
• Zwei Läufe hintereinander auf demselben Stand (jeweils mit Reset) müssen ohne Abweichung enden. Szenarien laufen in fester Reihenfolge (Dateiname).

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 und überholte Lä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.“

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.

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.
• 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 Dateien laufen nach den Zeitsprung-Szenarien 99-A/99-Z (Uhr dann 01.01.2027); alle Datumswerte sind deshalb ausdrücklich gesetzt.
• 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.

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).

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.
• 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“: Zeilenzahl wie in der Referenz (Toleranz 0,05 %, mind. 50 Zeilen).

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“.

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.
• 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.

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.

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.

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.

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.