26 KiB

Raw Blame History

Belastbarer Timeslotvergleich: Umsetzungs- und Abnahmeplan

Stand: 2026-09-11. Zugehörigkeit: Phase 8, mit UI aus Phase 7, Persistenz/API aus Phasen 9-11 und erforderlichen Profilverträgen aus Phasen 6/13A/13C; GPO-Anbindung über Phase 13B.

Status: in Arbeit, nicht fachlich abgenommen. P0 ist abgeschlossen. P1 besitzt den additiven Domänenvertrag und verpflichtende profilgebundene Scope-/Zeit-/Evidenzdeklarationen; Persistenz/API und Übergangsvertrag bleiben offen. P2 ist begonnen: compareProjectTimeslotEvidence paart echte Scannerläufe je Werkzeug und bewertet Processing, Scope, Reportzeit, Diagnosen sowie Fail-zu-Pass konservativ. Die bisherige Engine und Oberfläche verwenden diesen Pfad noch nicht. P3-P6 sind offen. Der aktuelle Implementierungsschnitt führt keine Migration, Reimporte, Datenmutation oder Aktivierung einer Vergleichsoberfläche aus. Der historische Phase-8-Abschluss vom 2026-07-17 bleibt dokumentiert, ist aber keine Abnahme dieses Arbeitspakets.

Ausdrückliche Nutzerentscheidung 2026-10-13: P1-P6 werden als eigenständig abschaltbare Comparison Engine umgesetzt (src/comparison/, server/comparison/, tests/comparison/); der Core-Phase-8-Scanlaufvergleich zieht dafür in einen Core-Evaluation-Ort um. Alle Verträge und die Abnahmematrix dieses Plans bleiben unverändert verbindlich. Stufen und Freigaben: IMPLEMENTATION_PLAN.md, Abschnitt „Comparison Engine: decision and staging“.

Dieser Plan präzisiert das Arbeitspaket „faire Vergleiche bei fehlenden Folgequellen“ in IMPLEMENTATION_PLAN.md. Für die künftige Umsetzung ersetzt er ausdrücklich die ältere Schlussfolgerung „abwesend = behoben“ und die pauschale Ablösung offener Verpflichtungen durch einen neuen Lauf derselben Quelle. Historische Ergebnisse und Originaldaten werden dadurch nicht rückwirkend geändert.

1. Ziel und Grenzen

Zwei ausdrücklich gewählte Timeslots A und B desselben Kunden liefern drei getrennte Aussagen:

Nachweislich behoben: zuvor bestätigte Abweichungen mit nachvollziehbarer aktueller Gegenprüfung.
Weiterhin offen oder ungeklärt: aktuell bestätigte sowie historische, noch nicht ausreichend erneut geprüfte Verpflichtungen; neue und wieder aufgetretene Abweichungen getrennt ausweisen.
Vergleichbare Scoreveränderung: A und B werden auf derselben belegten Prüfgrundlage berechnet; ausgeschlossene Bereiche, Evidenzabdeckung und Aktualität bleiben sichtbar.

Der Overall Score bleibt der methodisch gemischte Index aus SCORING_MODEL.md, kein Prozentsatz tatsächlicher Sicherheit. Keine neuen Risikogewichte, Scannerformeln oder automatische Übertragung nativer Gesamtwerte auf Security Domains. Fehlende Daten sind weder null noch bestanden. Unbekannte Prüfgrundlagen führen zu einer begrenzten oder nicht verfügbaren Aussage.

2. Ausgangsbefund und Reparaturbedarf

Codeprüfung vom 2026-09-11, keine neue Laufzeitabnahme:

compareProjectTimeslots in datahub-scan-analysis.ts besitzt derzeit keinen Produktaufrufer. Mehrfachauswahl/Öffnen ist kein expliziter A/B-Bericht.
Die Timeslot-Projektion ersetzt beide Laufwerkzeuge durch multiple, lässt importFiles aber an Original-Lauf-IDs. Dadurch kann sameTool fälschlich gelten und die dateigebundene Kompatibilitätsprüfung ausfallen.
Die automatischen Matchingstufen der comparison-engine.ts erzwingen keine objektgenaue Identität. Eine gemeinsame Regeldefinition ist kein Nachweis desselben betroffenen Objekts. Die Zwei-Lauf-Projektion entfernt außerdem frühere Beobachtungen, die zur Verifikation eines Wiederauftretens gebraucht werden.
Abwesende Vorkommen können resolved werden, während zugeordnete Fail-zu-Pass-Ergebnisse persistent mit Statusänderung bleiben. Die lokale isOpen-Prüfung verwechselt fachliche Abweichungen mit technischen beziehungsweise ungeprüften Zuständen.
Die Score-Paarbildung prüft viele Kompatibilitätsbedingungen. Ihr evaluationScopeKey enthält jedoch keine Asset-Identität; eine unveränderte Regelanzahl kann einen Objektwechsel verdecken.
awaitingRevalidation verwendet schwächere Bedingungen als die Score-Paarbildung. Zusätzlich überschreibt lastKnown im Workspace-Lader ältere Quellstände, ohne jede offene Verpflichtung zu erhalten. Das kann Verpflichtungen aus der Anzeige verdrängen, löscht aber keine gespeicherten Originalfindings.
Die derzeitige Score-Baseline ist ein historischer letzter Stand je Quellscope vor der geöffneten Auswahl, nicht zwingend der ausdrücklich gewünschte Timeslot A.

3. Fachliche Verträge

3.1 Regel, Vergleichsidentität und Beobachtung

FindingDefinition bleibt eine Regeldefinition. Kein pauschaler Ersatz ihres tool:rule-Schlüssels durch tool:rule:objekt.
Die projektgebundene Vergleichsidentität eines Vorkommens umfasst verifizierte Quelle, native Regel, fachlichen Scope und gegebenenfalls die stabile Identität des betroffenen Objekts. Zeitpunkt und Importlauf gehören zur Beobachtung und Provenienz, nicht in den dauerhaften Vergleichsschlüssel.
Objektart, Namensraum und Geltungsbereich gehören zum Identitätsvertrag. Fehlende Identität ist nicht die leere Identität eines vermeintlich gleichen Objekts. Anzeigenamen, Positionen und Titelähnlichkeit reichen nicht aus; Umbenennungen oder Aliasbeziehungen dürfen nicht geraten werden.
Objektbezogene, scopeweite und aggregierte Regeln erhalten deklarierte Vergleichsgranularitäten. Für einen domainweiten Befund wird kein Host erfunden. Eine Regel mit einer Liste betroffener Objekte ist ohne geeignete strukturierte Evidenz nicht automatisch eine Menge eigenständiger Instanzfindings.
Automatische Zuordnung muss beidseitig eindeutig auf der deklarierten Granularität sein. Unsichere Zuordnungen bleiben Vorschläge; sie dürfen weder Behebung noch neue Abweichungen allein aus unklarer Restmengenbildung beweisen. Lokale bestätigte Regeln dürfen diese Scope-/Objektgrenzen nicht umgehen.
Der bereits vorhandene objektbezogene Reimport-Reviewtransfer ist eine wiederzuverwendende Grundlage, aber kein ungeprüfter universeller Identitätsvertrag. Definitionsreviews, Vorkommensreviews und Accepted Risk behalten ihren jeweiligen Geltungsbereich.

3.2 Gegenprüfung und Lebenszyklus

Die Ergebnispräsenz und der Lebenszyklus einer Abweichung werden getrennt betrachtet. Eine Regel kann weiterhin als Ergebnis vorhanden sein, obwohl die konkrete Abweichung behoben ist.

Evidenz im Ziel B gegenüber einer bestätigten Abweichung	Fachliche Aussage
Eindeutig dasselbe Objekt/derselbe Scope, kompatible Prüfung, neueres belastbares Pass-Ergebnis	nachweislich behoben
Dieselbe Vergleichsidentität mit bestätigter aktueller Abweichung	weiterhin offen
Quelle, Objekt oder Ergebnis fehlt; Prüfung abgebrochen, unbekannt oder mehrdeutig	ungeklärt, Verpflichtung bleibt bestehen; `unverified-absent` für ungeprüfte Abwesenheit
Finding fehlt in einem deklarativ vollständig belegten Negativbericht für genau diese Regel und dieses Objekt	Behebung nur bei erfülltem profilgebundenem Negativnachweisvertrag
Nicht anwendbar oder aus dem Scope genommen	keine Behebung; eigene belegte Anwendbarkeits-/Scopeentscheidung
Manuell als erledigt markiert oder Risiko akzeptiert	Workflow-/Risikoentscheidung, kein technischer Behebungsnachweis

Neue und wieder aufgetretene Abweichungen verlangen ebenfalls ausreichende Historie und Vergleichbarkeit. Eine bloße Lücke im direkten Vorgänger ist kein Nachweis einer zwischenzeitlichen Behebung. Ein späterer Fail nach belegtem Pass derselben Identität ist ein Wiederauftreten; nach einer ungeprüften Lücke bleibt eine alte Verpflichtung offen.

Ein Gegenprüfungsvertrag je Profil/Format beschreibt Regelpopulation, Zielobjekte, erfolgreichen Ausführungsumfang, positive/negative Berichtsemantik, Zeitbezug, notwendige Provenienz und disqualifizierende Diagnosearten. GPOs verwenden ihre vorhandenen Settings-, Scope-, Baseline- und Evaluationsverträge; ohne Wirksamkeitsevidenz wird keine effektive Anwendung behauptet.

assessed und eligible sind unterstützende Signale, kein Beweis vollständig untersuchter Objekte. Ein im Report vollständig fehlendes Objekt kann beide Zähler unverändert lassen. Fehler werden nach ihrem Einfluss auf Identität, einzelne Prüfergebnisse, Abdeckung oder den Gesamtscore klassifiziert. Eine belastbare Einzelprüfung kann trotz fachlich unabhängiger Fehler verwendet werden; unbekannte Fehlerauswirkung verhindert automatische Behebung.

3.3 Dauerhafte offene Verpflichtungen

Jede offene Verpflichtung behält Ursprungs-Timeslot, Originalvorkommen, Quelle, Objekt/Scope, letzten bestätigten Zustand und Beobachtungszeitpunkt. Über A, einen unvollständigen Zwischenstand und B darf sie nicht durch „letzter Scan je Quelle“ verschwinden.
Fortschreibung kopiert keine Rohbeobachtung als aktuelle Evidenz. Sie erhält eine Referenz mit Zustand, Grund und Alter; neue Beobachtungen werden dazu verknüpft.
Ablösung erfolgt je Verpflichtung durch aktuelle Bestätigung, belegte Behebung oder eine ausdrücklich auditierte Scopeentscheidung. Eine spätere Dateizeit, ein nichtleerer Scan oder assessed > 0 genügt nicht.
Die erwartete Quelle kann aktuelle und ungeklärte Teilbereiche zugleich besitzen. Die bisherigen Quellzustände observed-current, carried-forward-awaiting-revalidation und retired-out-of-scope dürfen diesen Mischfall nicht zu „alles aktuell“ verdichten.
Backlog und Evidenzabdeckung sind getrennt vom gemessenen Score. Historische Risiken verschwinden nicht bei Quellenauswahl; ein alter Score wird nicht als Messwert von B eingesetzt. Die frühere Formulierung „scorewirksam“ autorisiert keinen erfundenen numerischen Malus. Ein zusätzlicher risikogewichteter Expositionsindex benötigt eine eigene Methodikentscheidung.
Risikoakzeptanz bleibt separat sichtbar und beendet keine technische Abweichung. Reviewhistorie einschließlich zukünftiger Felder wird vollständig erhalten; ein Reimport verlängert oder erneuert keine Akzeptanz.

3.4 Vergleichspaar und Score

Der Vergleich bindet genau A und B samt Projekt-, Assessment-, aktiven Run-, Datei- und Processingreferenzen. A muss fachlich vor B liegen; ungültige, identische oder nicht eindeutig geordnete Auswahlen liefern keinen verifizierten Fortschritt. Scanzeit wird nicht durch Importzeit ersetzt.
Mehrteilige Dateien werden je originalem Scannerlauf geprüft. Mehrere Quellen dürfen nicht zu einem gemeinsamen multiple-Vertrag verschmolzen werden. Fehlende oder mehrdeutige Zuordnung sperrt die betroffene Aussage; übrige vergleichbare Bereiche bleiben mit ausgewiesenem Umfang nutzbar.
Historie vor A darf offene Verpflichtungen und Wiederauftreten erklären, aber weder den Messwert von A ersetzen noch ungefragt die A/B-Scorebasis verändern.
Der Scorevergleich verlangt eine gemeinsame belegte Prüfpopulation einschließlich der erforderlichen Objekt-/Scopeidentitäten, eindeutige Paarung, kompatible Verarbeitung, neuere Beobachtung sowie gleiche Scoremethodik und Gewichtung. Fehlende, hinzugekommene, entfernte oder ausgetauschte Objekte werden als Scopeänderung erkennbar, auch bei gleicher Anzahl.
Native Gesamtwerte dürfen nicht auf eine kleinere Objektteilmenge heruntergerechnet werden, wenn deren Beitrag nicht separat belegt ist. Ohne vergleichbare native Grundgesamtheit ist für diesen Beitrag kein Delta verfügbar. Pass-rate-Teilmengen sind nur mit ausgewiesenen, vollständig identifizierten Prüfungen zulässig.
Score- und Behebungsfreigabe sind getrennte Prädikate. Eine geänderte Gewichtung oder ein unbrauchbarer nativer Score kann das Delta verhindern, ohne eine belegte Einzelbehebung zu entwerten. Umgekehrt ist ein vergleichbarer Gesamtscore kein Behebungsnachweis.
Die bestehenden Regeln für aktuelle Abweichungen werden gemeinsam verwendet (isDeviation, für GPOs policyComparisonDisposition). Fehler/Not run/Unknown bleiben Evidenzlücken. Historisch ungeklärte Verpflichtungen bleiben zusätzlich offen, auch wenn B keine aktuelle Abweichung dazu enthält.

Behebungsquoten beziehen sich auf eine explizite, deduplizierte Menge bestätigter offener Vergleichsinstanzen aus A. Der Zähler enthält nur nachgewiesene Behebungen dieser Menge; ungeklärte, nicht vergleichbare und aus dem Scope genommene Instanzen werden separat ausgewiesen und nicht still aus dem Nenner entfernt. Ein unbekannter oder leerer Nenner liefert keine behauptete Erfolgsquote. Neue Findings aus B und zusätzliche Verpflichtungen vor A gehören in den getrennten Bestandsbericht. Die reine Differenz offener Anzahlen ist ausdrücklich keine Behebungsquote; jede Kennzahl muss auf ihre zugrunde liegenden Identitäten zurückführbar sein.

4. Arbeitspakete und Reihenfolge

Die Paketstände beziehen sich ausschließlich auf nachgewiesene Ergebnisse dieses Arbeitspakets; ein begonnener Vertrag ist noch keine Produktintegration.

Paket	Inhalt und betroffene Grenzen	Voraussetzung / Nachweis
P0 · abgeschlossen	Synthetisches Bestandsaudit je Scanner/Format/GPO: Regelgranularität, bereits erhaltene Objekt-/Scopefelder, Quellenpfade, Vollständigkeitssignale und fehlende Informationen dokumentieren; notwendige Vertragsänderungen und Reimportbetroffenheit bestimmen	TIMESLOT_COMPARISON_AUDIT.md; keine echten Kundendaten; Fähigkeiten und Grenzen je unterstütztem Pfad dokumentiert
P1 · in Arbeit	Versionierte Vergleichsidentität, Gegenprüfungs-/Diagnosevertrag und getrennte Ergebnis-/Verpflichtungszustände in der Domäne spezifizieren; Persistenz-/API-Entwurf und Übergangsregeln festlegen	Domänen- und Profilverträge sowie synthetische Scope-/Zeitfälle umgesetzt; Persistenz-/API- und Übergangsentwurf bleiben offen
P2 · in Arbeit	Scanner-/GPO-Paarung anhand echter Quellreferenzen; vollständige Kompatibilitätsprüfungen; objektgenauer Lebenszyklus, Fail-zu-Pass, konservative Abwesenheit und einheitliche aktuelle Abweichungsmetriken	Sicherer Scannerpfad mit echter Tool-/Run-/File-Paarung, Processing-, Scope-, Reportzeit- und Diagnosegrenzen umgesetzt. 2026-10-13 in der Comparison Engine: Scanner trennen `neu` und `wieder aufgetreten` (genau ein belegtes Pass derselben Identität in A; mehrdeutige Historie behauptet nichts); einseitige Quellen sind nicht vergleichbar; GPO-Paarung über die unverändert gelesenen, wie in Work hochgerollten Verdikte je Scope und technischer Identität, nur mit neuerer Backupzeit und gleicher Baselinemenge; fehlende oder nicht entschiedene Einstellung bleibt ungeklärt; geänderter Istwert einer weiter abweichenden Einstellung ist neutral (`value-changed`). Historie, Produktintegration und vollständige Matrix bleiben offen
P3	Verpflichtungsbezogene Fortschreibung über alle Zwischenstände, getrennt von der Score-Baseline; atomare/idempotente Ablage und API gemäß P1, Wiederladen und auditierter Scope-Ausstieg	P1/P2; nichts verschwindet bei Teilimport, Reload, Reimport oder mehrdeutiger Zuordnung
P4 · begonnen	Explizite A/B-Scorebasis, objekt-/scopebewusste Population und getrennte Freigaben für Delta/Gegenprüfung; native Scoregrenzen und Coverageausgabe	P1/P2/P3; keine Verbesserung durch Quellenauslassung, Objektwechsel oder historische Baselinevermischung. 2026-10-13: Delta nur über Quellen mit vergleichbarem Paar in A und B (Scanner über `compareSecurityScores`, GPO als Pass-Rate über in beiden Timeslots entschiedene Einstellungen derselben Baselines); jede ausgeschlossene Quelle mit Grund. Security-Domain-Deltas, Coverageausgabe und P3-Abhängigkeit offen
P5	A/B-Auswahl und dreiteiliger Bericht in der vorhandenen Oberfläche; Gründe, Messbasis, Quellen/Versionen und Belege pro Aussage; aktueller Workspace bleibt unverändert nutzbar	P2-P4 fachlich verifiziert; UI ist Konsument der Domänenlogik, kein eigener Matcher
P6	Gesamtabnahme, Dokumentationsabgleich und kontrollierte Aktivierung	Alle unten genannten Fälle; keine Freigabe allein wegen vorhandener Funktion oder grüner Buildausgabe

Keine frühe Verdrahtung der bisherigen compareProjectTimeslots-Ergebnisse als belastbarer Fortschrittsbericht. Nach Implementierungsbeginn und jedem verifizierten Teilpaket werden Status, offene Risiken und tatsächliche Nachweise im Hauptplan fortgeschrieben.

5. Versionierung, Bestand und Betrieb

REIMPORT_POLICY.md bleibt verbindlich. Änderungen an importierter Identität, Findinggrenzen, Assetmapping, Normalisierung, Extraktion, Vollständigkeitsdiagnosen oder neu benötigten Scoreeingaben erhalten append-only Processing-Manifeste und Reimportmarkierungen für betroffene historische Verträge.
Eine Änderung allein an der Vergleichsauswertung unveränderter, bereits ausreichend gespeicherter Fakten wird getrennt versioniert und benötigt eine nachvollziehbare Neuberechnung der Vergleichsergebnisse. Sie darf keine versteckte Änderung importierter Identität oder eine Ergänzung fehlender Evidenz sein. P0/P1 müssen diese Grenze pro Änderung dokumentieren; kein pauschaler Bestandsreimport und keine pauschale Reimportfreiheit.
Neue Vergleichsergebnisse erhalten eine eigene Algorithmus-/Vertragsversion, genaue Eingabereferenzen und Freigabegründe. Historische Ergebnisse behalten ihre Bedeutung und werden als Legacy/nicht nach neuem Vertrag verifiziert gekennzeichnet; alte resolved-Werte werden nicht rückwirkend zu Beweisen erklärt.
Der konkrete Speichervertrag für Verpflichtungen und Scopeentscheidungen wird vor Datenbankänderungen festgelegt. Persistenz/Backend bleiben außerhalb von React; Projektgrenzen, optimistische Revisionen, atomare Updates und Wiederholbarkeit sind Pflicht.
Vor einer gesondert freigegebenen Migration: Backup erstellen und prüfen, Migration/Rückfallplan synthetisch verifizieren. Nur den kanonischen lokalen PostgreSQL-Datastore verwenden; keine Ersatzdatenbank, keine neuen Ports oder Volumes. Der Planauftrag führt weder Migration noch Reimport aus.
Kundenreviews und Accepted-Risk-Historien dürfen weder verloren gehen noch auf andere Objekte geraten werden. Nicht eindeutig übertragbare Daten bleiben am Ursprung mit dauerhaft sichtbarem Klärungsbedarf.

6. Verbindliche synthetische Abnahmematrix

Die Matrix bleibt bis auf ausdrücklich im Paketstatus genannte Teilnachweise geplant. Domain-, Import-/Projektions-, Repository-/API- und UI-Ebene werden entsprechend ihrer Verantwortung geprüft.

Fall	Erwarteter Nachweis
Dieselbe Regel auf Server A in A und Server B in B	Kein objektgenaues Match und keine Behebung für Server A
Fünf betroffene Objekte in A, drei erneut vorhanden in B	Drei nur bei Identitätsbeweis zugeordnet; zwei ungeklärt, niemals allein aus der Differenz behoben
Gleiche Anzahl und Regeln, aber ausgetauschte Zielobjekte	Scopeänderung; kein ungeprüftes vergleichbares Score-Delta
Dasselbe Objekt: Fail zu Pass / Fail zu Fail	Belegt behoben / weiterhin offen; Ergebnispräsenz ersetzt keinen Lebenszyklus
Kein oder doppelter Objektschlüssel, gleiche Titel, Umordnung	Kein geratenes Match; deterministische Diagnose und vollständige Erhaltung aller Vorkommen
Domainweite oder aggregierte Regel ohne Host-ID	Deklarierte Scopegranularität statt erfundener Objektinstanzen
Gesamte Scannerquelle fehlt; generische Begleitdateien bleiben	Offene Verpflichtungen bleiben, fehlende Quelle zählt nicht als Behebung
Unvollständiger Folgescan mit `assessed > 0` und Score-Issues	Kein pauschales Entfernen historischer Verpflichtungen; einzelne belegte Prüfungen getrennt behandelbar
A offen, Zwischenstand teilweise/leer/fehlerhaft, B ohne Quelle	Ursprüngliche Verpflichtung mit Originalherkunft bleibt sichtbar, auch nach Reload
`assessed === eligible`, aber ein erwartetes Objekt fehlt	Zählergleichheit allein erteilt keine Vollständigkeits- oder Behebungsfreigabe
Findings-only-Bericht enthält keinen Treffer	Behebung nur mit explizit erfülltem vollständigem Negativnachweisvertrag
Neuerer Scanzeitpunkt fehlt oder ist unverändert; bloßer Reimport	Kein gemessener Fortschritt aus Importzeit oder identischen Beobachtungen
Geänderte/ unbekannte Processingverträge, gemischte Scanner und Mehrdateiläufe	Schutz greift auch im Timeslotvergleich; keine Umgehung durch künstliche Lauf-IDs
Gewichtung/Scoremethode geändert, Einzelprüfung dennoch belastbar	Delta gesperrt/begrenzt, gültige Behebung unabhängig davon bewertbar
Neuere Evidenz wieder Fail nach belegtem Pass / nach ungeprüfter Lücke	Wiederaufgetreten / alte Verpflichtung weiter offen
Ältere Historie H vor A und B	A/B-Delta unverändert durch H; historische Verpflichtungen separat und nachvollziehbar
Keine vergleichbare Quelle oder fehlende Historie	Kein Null-Delta als Erfolg; nicht verfügbare Aussage mit Grund
Not applicable, Not run, Execution error, Unknown und Accepted Risk	Keine künstlichen Behebungen; aktuelle Abweichung, Evidenzlücke und Risikoentscheidung getrennt
GPO-Teilabdeckung, andere Baseline/Scope, fehlende Wirksamkeitsevidenz	Konservative getrennte Aussage gemäß Policyvertrag, keine erfundene effektive Behebung
Scope-Ausstieg mit/ohne ausdrückliche Begründung und Akteur	Nur auditierte Entscheidung wirksam; nicht als Behebung gezählt; Historie bleibt erhalten
Reimport, doppelte Anforderung, Konflikt oder fehlgeschlagene Transaktion	Keine verlorenen/doppelten Verpflichtungen; vollständige Reviews und Accepted Risk erhalten
Mandantenwechsel, manipulierte A/B-IDs, supersedierte Läufe	Projektgrenze und aktive Auswahl durch Domäne/API abgesichert
Auswahlwechsel, Filter, wiederholtes Öffnen, schmale Ansicht	Kein veraltetes Delta, vollständige Belege, klare A/B-Beschriftung, begrenzte Renderarbeit

Für relevante Codeänderungen sind npm test und npm run build die Basis; zusätzlich gezielte Vergleichs-/Score-, Historien-, Importprojektions-, Persistenz-/API- und synthetische UI-Tests. Optionale PostgreSQL-Tests werden nur im freigegebenen Rahmen ausgeführt; übersprungene Tests ersetzen keine Persistenzabnahme. Laufzeitbeobachtungen sind keine fragilen Millisekunden-CI-Grenzen. Keine echten Reportinhalte, Screenshots gefüllter Kundenansichten, Telemetrie oder externen Uploads für die Verifikation.

7. Offene Detailentscheidungen und Abschlusskriterium

P0/P1: exakte Identitätsfelder, Alias-/Umbenennungsbelege, Granularitäten und Negativnachweisfähigkeiten je unterstütztem Profil/Format; fehlende Fähigkeiten bleiben ausdrücklich nicht verifizierbar.
P1/P3: additive Datensätze/Versionen für Verpflichtungen, Vergleichsergebnisse und Scopeentscheidungen; Rückfall-/Neuberechnungspfad, Projektberechtigungen und Grenzen der vorhandenen Akteursnachweise. Keine Behauptung einer authentifizierten Signatur ohne entsprechende Infrastruktur.
P4: welche separat belegten Teilpopulationen pro Scoreverfahren tatsächlich berechenbar sind. Keine frei geschätzte Zerlegung nativer Gesamtscores; kein zusätzlicher Expositionsindex ohne separate Entscheidung.
P5: konkrete Bedienposition und Belegnavigation im bestehenden Designsystem; keine neue Oberfläche oder neue Exportfunktion außerhalb des Vergleichsauftrags.

Das Paket ist erst abgeschlossen, wenn die Matrix auf den relevanten Schichten bestanden ist, dokumentierte Profilgrenzen in der Oberfläche sichtbar bleiben, A/B-Auswahl und Herkunft reproduzierbar sind und weder fehlende Evidenz noch Objekt-/Methodenwechsel als Verbesserung erscheinen. Plan, Vergleichsdokumentation und Scoringdokumentation müssen denselben verifizierten Stand beschreiben. Bis dahin lautet der Status weiterhin offen beziehungsweise nach Beginn in Arbeit.

Verifikation der bisherigen Schnitte, 2026-09-11

Sechs synthetische Domänentests bestätigen getrennte Regel-/Objektidentität, fehlende Typ-/Namespacefreigabe, Fail-zu-Pass nur bei gleicher Identität, konservative Abwesenheit, Diagnose-/Zeitgrenzen sowie Herkunftserhalt und auditierten Scope-Ausstieg.
Client- und Serverbuild, Local-only-Sicherheitsprüfung und Designprüfung sind erfolgreich.
Gesamtlauf: 1.224 Tests bestanden, acht optionale PostgreSQL-Tests übersprungen. Ein fachfremder kombinierter Node-Importtest überschritt unter Gesamtlast einmal sein unverändertes Fünf-Sekunden-Limit und bestand isoliert mit 5/5 Tests in 1.193 ms.
Der erste Schnitt enthielt keine reale Dateninspektion. Über alle bisherigen Schnitte gab es keine Persistenzmutation, Migration, Reimport- oder UI-Aktivierung; P1/P2 bleiben ausdrücklich unvollständig.
Nach ausdrücklicher Nutzerfreigabe wurde ausschließlich Dummy lesend ergänzt geprüft. Der Bestand bestätigt, dass Purple-Knight-affectedAsset nur Bereiche statt Objekte enthält und dass wiederholte Reimporte ohne neue Reportzeit keinen Fortschritt belegen. Keine Daten wurden verändert.
Vier Profile besitzen nun scopegebundene Vergleichsverträge; Generic bleibt nicht automatisch vergleichbar. Die sichere Scannerpaarung zählt nur ein eindeutiges Fail-zu-Pass derselben Identität bei kompatibler Verarbeitung und neuerer Reportzeit als behoben. Fehlende Quellen, Abwesenheit und gleiche Reportzeit bleiben ungeklärt oder nicht vergleichbar.
23 fokussierte synthetische Tests in drei Dateien sowie Client- und Serverbuild sind erfolgreich. Persistenz/API, GPO, Verpflichtungshistorie, Score-A/B-Basis und UI bleiben offen.
Projektweiter Lauf: 1.240 Tests bestanden, acht optionale PostgreSQL-Tests übersprungen. Derselbe fachfremde kombinierte Node-Importtest überschritt unter Gesamtlast einmal sein unverändertes Fünf-Sekunden-Limit und bestand isoliert mit 5/5 Tests in 3.661 ms. Local-only- und Designsprache-Prüfung sind erfolgreich; das Zeitlimit wurde nicht erhöht.

26 KiB Raw Blame History