Assessor_2.0/docs/IMPLEMENTATION_PLAN.md

# ASSESSOR â€“ Umsetzungsplan

Status: lebendes Projektdokument
Erstellt: 2026-07-17
Zuletzt aktualisiert: 2026-08-04
Aktuelle Entwicklungsstufe: lokale React-/Tauri-Anwendung
Zielzustand: interne Mehrbenutzer-Webanwendung mit Backend und PostgreSQL

## 1. Zweck

Dieses Dokument ist die verbindliche technische Orientierung fÃ¼r die schrittweise Weiterentwicklung von ASSESSOR. Es hÃ¤lt Zielbild, Reihenfolge, Abnahmekriterien, Entscheidungen, Risiken und Fortschritt fest.

Der Plan ist kein unverÃ¤nderlicher Vertrag. Neue Erkenntnisse dÃ¼rfen ihn verÃ¤ndern, mÃ¼ssen aber nachvollziehbar dokumentiert werden. Eine Phase gilt erst als abgeschlossen, wenn ihre Abnahmekriterien verifiziert sind.

## 2. Produktziel

ASSESSOR soll Dateien unterschiedlicher Security- und Assessment-Werkzeuge importieren, lokal beziehungsweise innerhalb der Unternehmensinfrastruktur verarbeiten, normalisieren, dauerhaft speichern, einheitlich darstellen und Ã¼ber mehrere Assessment-LÃ¤ufe vergleichen kÃ¶nnen.

Vorrangige Quellformate:

- CSV und strukturierte Textdateien
- JSON
- XML
- HTML
- XLS und XLSX

Vorrangige Pilotquellen:

- Purple Knight
- PingCastle
- CIS-CAT
- Maester
- unbekannte tabellarische Quellen Ã¼ber ein generisches Profil

## 3. Leitprinzipien

1. Kein Informationsverlust: Originalwerte, Quelldatei und Quellposition bleiben nachvollziehbar.
2. Kanonischer Kern, flexible Erweiterungen: gemeinsame Finding-Felder werden normalisiert; werkzeugspezifische Daten bleiben erhalten.
3. Konfidenz statt Scheinsicherheit: automatische Erkennung und Zuordnung erhalten nachvollziehbare Konfidenzwerte.
4. Generischer Fallback: unbekannte Quellen mÃ¼ssen importierbar bleiben, auch wenn nicht alles automatisch zugeordnet werden kann.
5. Profile statt SonderfÃ¤lle: bekannte Werkzeuge erweitern dieselbe Pipeline Ã¼ber deklarative Profile.
6. Deterministische Kernverarbeitung: die Importengine benÃ¶tigt kein externes KI-Modell.
7. Sichere Eingabegrenze: alle importierten Dateien gelten als nicht vertrauenswÃ¼rdig.
8. ServerfÃ¤higkeit ohne vorschnellen Bruch: die lokale Anwendung bleibt nutzbar, wÃ¤hrend PlattformabhÃ¤ngigkeiten gekapselt werden.
9. Backend als Vertrauensgrenze: im Zielzustand greift der Browser nie direkt auf die Datenbank zu.
10. Verifizierbarer Fortschritt: StatusÃ¤nderungen erfolgen nur nach Tests und dokumentierter Abnahme.

## 4. Zielarchitektur

```text
Browser der Mitarbeitenden
        â†“ HTTPS
ASSESSOR-Backend im Unternehmensnetz
  â”œâ”€ Authentifizierung und Autorisierung
  â”œâ”€ Dateiannahme und Importsteuerung
  â”œâ”€ Parsing und Strukturanalyse
  â”œâ”€ Toolerkennung und semantisches Mapping
  â”œâ”€ Normalisierung und Vergleich
  â”œâ”€ Review- und Workflowlogik
  â””â”€ Export und Audit
        â†“
PostgreSQL
        â†“
optionaler geschÃ¼tzter Originaldateispeicher
```

Die heutige Tauri-Anwendung bleibt zunÃ¤chst eine lokale Laufzeitumgebung. Das React-Frontend und die Fachlogik sollen so getrennt werden, dass dieselbe OberflÃ¤che spÃ¤ter Ã¼ber ein Backend im normalen Browser betrieben werden kann.

## 5. Statusdefinitionen

- `offen`: noch nicht begonnen
- `in Arbeit`: begonnen, Abnahmekriterien noch nicht vollstÃ¤ndig erfÃ¼llt
- `blockiert`: ohne Entscheidung oder externe Voraussetzung nicht sinnvoll fortsetzbar
- `abgeschlossen`: Abnahmekriterien verifiziert

## 6. PhasenÃ¼bersicht

| Phase | Inhalt | Status |
|---|---|---|
| 0 | Plan und Arbeitsregeln etablieren | abgeschlossen |
| 1 | Bestehenden Funktionsumfang und Testkorpus absichern | abgeschlossen |
| 2 | Kanonisches Finding- und Assessment-Modell definieren | abgeschlossen |
| 3 | Universelles Import-Zwischenmodell stabilisieren | abgeschlossen |
| 4 | Importengine vollstÃ¤ndig von UI und Plattform trennen | abgeschlossen |
| 5 | Erkennungs- und Mapping-Engine mit Konfidenzen | abgeschlossen |
| 6 | Deklarative Toolprofile und generischer Fallback | abgeschlossen |
| 7 | Automatische Filter- und Darstellungslogik | abgeschlossen |
| 8 | Vergleichsengine fÃ¼r Assessment-LÃ¤ufe | abgeschlossen |
| 9 | Fachliche Persistenzschnittstelle | abgeschlossen |
| 10 | Lokales Backend Ã¼ber `localhost` | abgeschlossen |
| 11 | PostgreSQL und Datenbankmigrationen | abgeschlossen |
| 12 | Mehrdatei-Importworkflow und Importdiagnostik | abgeschlossen |
| 13 | Sicherheits- und BelastbarkeitshÃ¤rtung | abgeschlossen |
| 13A | Ingestion 2.0: Formatadapter, Source Extractors und Mappingprofile konsolidieren | abgeschlossen |
| 13B | Deterministische GPO-Backup- und Microsoft-Baseline-Analyse | in Arbeit |
| 13C | Scanner Context und Environment Inventory | in Arbeit |
| 14 | Mehrbenutzer- und Firmenbetrieb | offen |

## 7. Phasen im Detail

### Phase 0 â€“ Plan und Arbeitsregeln etablieren

Status: abgeschlossen

Ergebnis:

- Dieser Umsetzungsplan ist versionierbar im Projekt vorhanden.
- `AGENTS.md` verweist auf den Plan und definiert den Abgleich bei grÃ¶ÃŸeren Arbeiten.

Abnahmekriterien:

- Plan und Projektanweisung sind im Repository vorhanden.
- Zielzustand und Ãœbergangsstrategie sind dokumentiert.

### Phase 1 â€“ Bestehenden Funktionsumfang absichern

Status: abgeschlossen

Ziele:

- Den aktuellen lokalen Funktionsumfang als belastbare Ausgangsbasis festhalten.
- Regressionen wÃ¤hrend der Architekturarbeiten frÃ¼h erkennen.

Arbeitspakete:

- Bestehende Tests und aktuelle Funktionen inventarisieren.
- ReprÃ¤sentative, rechtlich unbedenkliche oder synthetische Testdateien bereitstellen.
- Testkorpus fÃ¼r Purple Knight, PingCastle, CIS-CAT, Maester und generische Tabellen aufbauen.
- FehlerfÃ¤lle abdecken: leere Dateien, fehlerhafte Kodierung, ungewÃ¶hnliche Kopfzeilen, mehrere Tabellen, groÃŸe Dateien und beschÃ¤digte Inhalte.
- Aktuelle Import-, Filter-, Review-, Vergleichs- und Exportfunktionen dokumentieren.
- Baseline fÃ¼r `npm test` und `npm run build` festhalten.

Verifizierter Abschlussstand vom 2026-07-17:

- Positive und negative beziehungsweise sicherheitsrelevante Importtests fÃ¼r CSV, JSON, XML, HTML und Excel sind automatisiert.
- 21 Testdateien mit 51 Tests, Local-only-SicherheitsprÃ¼fung und Produktionsbuild laufen erfolgreich.
- Die englische semantische Titelrolle `title` wird in generischen DatensÃ¤tzen erkannt.
- Die detaillierte Abdeckung und die Abschlussnachweise stehen in `docs/TEST_BASELINE.md`.
- Ein automatisierter Gesamtworkflow deckt Mehrdateiimport, ProjektzusammenfÃ¼hrung, Suche, Review, Dashboard und Snapshot ab.
- 5.000 CSV-Findings sowie ein beschÃ¤digter XLSX-Container sind als Importbaseline geprÃ¼ft.
- Browser-End-to-End-Tests sind fÃ¼r die Zeit nach Phase 4 und zwingend vor Phase 10 festgelegt.
- Der synthetische Quellenkorpus umfasst Purple Knight, PingCastle, CIS-CAT, Maester und eine generische Tabellenquelle. Herkunft, Grenzen und offizielle Strukturquellen sind in `fixtures/README.md` dokumentiert.

Abnahmekriterien:

- Alle unterstÃ¼tzten Formate besitzen mindestens einen positiven und einen negativen Testfall.
- Die wichtigsten aktuellen BenutzerablÃ¤ufe sind automatisiert oder als reproduzierbare manuelle PrÃ¼ffÃ¤lle dokumentiert.
- Test und Build laufen reproduzierbar erfolgreich.

### Phase 2 â€“ Kanonisches Finding- und Assessment-Modell

Status: abgeschlossen

Ziele:

- Findings verschiedener Werkzeuge in einem gemeinsamen Modell darstellen.
- Mehrere ScanstÃ¤nde und Vergleiche von Anfang an berÃ¼cksichtigen.

Vorgesehene Kernobjekte:

- Projekt
- Assessment
- Assessment-Lauf beziehungsweise Scan-Lauf
- Importdatei
- Quelltabelle beziehungsweise Sheet
- Finding-Definition
- Finding-Vorkommen in einem Scan
- Evidenz
- Review
- Toolprofil und Mappingversion
- Importdiagnose

Vorgesehene Finding-Felder:

- interne ID
- Quelltool und Toolversion
- Quelldatei, Sheet und Quellposition
- ursprÃ¼ngliche und kanonische Regel-ID
- Titel, Beschreibung und Kategorie
- ursprÃ¼nglicher und normalisierter Schweregrad
- ursprÃ¼nglicher und normalisierter Status
- Score
- betroffenes Asset oder Objekt
- Evidenz und Empfehlung
- Framework- und Control-Referenzen
- Scan- und Importzeitpunkt
- vollstÃ¤ndige Originalfelder
- Mapping-Konfidenz
- Profil- und Parser-Version

Verifizierter Abschlussstand vom 2026-07-17:

- Das verbindliche Schema steht in src/domain/canonical-model.ts und ist in docs/CANONICAL_MODEL.md erlÃ¤utert.
- Projekt, Assessment, Scan-Lauf, Importdatei, Quelltabelle, Finding-Definition, Finding-Vorkommen, Evidenz, Review und Importdiagnose sind getrennte Fachobjekte.
- Originalfelder, normalisierte Werte, Mappingkonfidenz, Quellposition sowie Parser-, Profil- und Mappingversion bleiben getrennt nachvollziehbar.
- Eine Finding-Definition wird im Test Ã¼ber mehrere PingCastle-Scan-LÃ¤ufe wiederverwendet; Reviews verÃ¤ndern keine importierten Vorkommen.
- Purple Knight, PingCastle, CIS-CAT und Maester werden gemeinsam ohne verlorene Zusatzfelder im Modelltest abgebildet.
- Der plattformneutrale Validator prÃ¼ft IDs, Referenzen, Quellbeziehungen, Originalfelder, Konfidenzen und Zahlenbereiche.
- 22 Testdateien mit 55 Tests, Local-only-SicherheitsprÃ¼fung und Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Alle Pilotquellen kÃ¶nnen ohne Informationsverlust abgebildet werden.
- Originalwert und normalisierter Wert sind getrennt.
- Ein Finding kann in mehreren Scan-LÃ¤ufen auftreten, ohne duplizierte Definitionen zu erzwingen.
- Reviewdaten sind von importierten Quelldaten getrennt.

### Phase 3 â€“ Universelles Import-Zwischenmodell

Status: abgeschlossen

Ziele:

- Alle Formatparser liefern dieselbe strukturelle Ausgabe.
- Fachliche Erkennung wird von der reinen Dateidekodierung getrennt.

Vorgesehene Inhalte:

- Datei- und Formatmetadaten
- Tabellen und Sheets
- Zeilen, Spalten und Zellen
- Rohwerte und dekodierte Werte
- erkannte Datentypen
- Kopfzeilenkandidaten
- Quellpositionen
- Parserwarnungen und verworfene Inhalte

Verifizierter Abschlussstand vom 2026-07-17:

- CSV, HTML, Excel, JSON und XML liefern ein versioniertes `ImportDocument` mit derselben Tabellen-, Zeilen-, Spalten- und Zellstruktur.
- Rohwerte, dekodierte Werte, erkannte Datentypen, Kopfzeilenkandidaten und formatspezifische Quellpositionen bleiben getrennt erhalten.
- Ein gemeinsamer Adapter erzeugt die bisherige `ImportedDataset`-Sicht, sodass OberflÃ¤che, Profile und Analysen ohne Parser-Sonderlogik weiterlaufen.
- CSV-Teilimporte, entfernte aktive HTML-Inhalte, leere Excel-Sheets sowie XML- und allgemeine Parserfehler werden maschinenlesbar diagnostiziert.
- Die Struktur und Abgrenzung sind in `docs/IMPORT_INTERMEDIATE_MODEL.md` dokumentiert.
- 24 Testdateien mit 60 Tests, Local-only-SicherheitsprÃ¼fung und Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Dieselbe nachgelagerte Analyse verarbeitet CSV-, HTML- und Excel-Tabellen.
- Formatparser enthalten keine React- oder Toolprofil-Logik.
- Fehler und Teilimporte werden strukturiert zurÃ¼ckgegeben.

### Phase 4 â€“ Plattformneutrale Importengine

Status: abgeschlossen

Ziele:

- Import, Analyse und Normalisierung unabhÃ¤ngig von React und Tauri ausfÃ¼hrbar machen.
- BrowserabhÃ¤ngigkeiten Ã¼ber Adapter kapseln.

Zu kapselnde Bereiche:

- Dateiobjekte und BinÃ¤rdaten
- HTML- und XML-Dokumentparser
- Persistenz
- Zeit, IDs und Hashing
- Download und Export

Verifizierter Abschlussstand vom 2026-07-17:

- `ImportSource` beschreibt Dateien nur noch als Metadaten und `Uint8Array`; Browser-`File` wird ausschlieÃŸlich am Browserrand adaptiert.
- `importSource` ist der plattformneutrale Engine-Einstieg und verarbeitet reine Bytequellen ohne React, Tauri oder Browser-Dateiobjekte.
- Textdekodierung sowie HTML-/XML-Strukturextraktion sind injizierbare Laufzeitadapter; `DOMParser` liegt ausschlieÃŸlich unter `src/platform/browser`.
- CSV-, JSON-, Excel-, HTML- und XML-Parser greifen nicht direkt auf Browser- oder UI-APIs zu.
- Persistenz, Textdownloads und Systemzeit sind Ã¼ber `StorageAdapter`, `DownloadAdapter` und `Clock` gekapselt.
- Eine automatisierte ArchitekturprÃ¼fung verhindert Browser-, React- und Tauri-AbhÃ¤ngigkeiten in Kernmodulen.
- Die Schichten und der spÃ¤tere Backend-Einstieg sind in `docs/PLATFORM_NEUTRAL_ENGINE.md` dokumentiert.
- 26 Testdateien mit 63 Tests, Local-only- und ArchitekturprÃ¼fung sowie Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Die Engine kann ohne React-Komponenten getestet werden.
- Fachmodule greifen nicht direkt auf `window`, DOM oder `localStorage` zu.
- Die aktuelle lokale OberflÃ¤che funktioniert weiterhin.

### Phase 5 â€“ Erkennungs- und Mapping-Engine

Status: abgeschlossen

Ziele:

- Quelle, relevante Tabellen und semantische Spaltenrollen automatisch erkennen.
- Entscheidungen nachvollziehbar und korrigierbar machen.

Erkennungssignale:

- Dateiname und Erweiterung
- Tool- und Versionsmarker
- Tabellen- und Sheetnamen
- Kopfzeilen und Feldsynonyme
- typische IDs, Status- und Severity-Werte
- Werteverteilungen und Datentypen
- Kombinationen mehrerer Signale

Konfidenzklassen:

- hoch: automatische Ãœbernahme
- mittel: Ãœbernahme mit sichtbarem Hinweis
- niedrig: BenutzerbestÃ¤tigung erforderlich
- unbekannt: unverÃ¤ndert als Zusatzfeld erhalten

Verifizierter Abschlussstand vom 2026-07-17:

- `ImportRecognitionResult` beschreibt Quellwerkzeug, Tabellenrelevanz und Feldrollen mit Score, Konfidenz, Evidenz und Entscheidungsquelle.
- Die Quellerkennung kombiniert Dateiname, Inhalt, Tabellenname, Kopfzeilen und typische Werte statt einzelne Marker isoliert zu verwenden.
- Purple Knight, PingCastle, CIS-CAT und Maester werden im synthetischen Quellenkorpus mit hoher Konfidenz erkannt.
- Regel-ID, Titel, Beschreibung, Kategorie, Severity, Status, Score, Asset, Evidenz, Empfehlung und Frameworkreferenz werden aus Kopfzeilen und Wertesignalen abgeleitet.
- Niedrige VorschlÃ¤ge bleiben bis zur BestÃ¤tigung als `additional` erhalten; unbekannte Felder und nicht ausgewÃ¤hlte Tabellen werden nicht verworfen.
- `applyRecognitionOverrides` bestÃ¤tigt oder korrigiert Quelle, Tabellenauswahl und Feldrollen ohne Ã„nderungen an Rohwerten oder importierten Zeilen.
- Das Ergebnis wird vom plattformneutralen Importablauf im `ImportedDataset` gespeichert; erkannte Werkzeuge kÃ¶nnen unabhÃ¤ngig vom bisherigen UI-Profil angezeigt werden.
- Modell, Schwellenwerte und Korrekturverhalten sind in `docs/RECOGNITION_ENGINE.md` dokumentiert.
- 28 Testdateien mit 68 Tests, Local-only- und ArchitekturprÃ¼fung sowie Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Jede automatische Zuordnung enthÃ¤lt BegrÃ¼ndung und Konfidenz.
- Unsichere Zuordnungen kÃ¶nnen bestÃ¤tigt oder korrigiert werden.
- Keine Zeile wird allein wegen unbekannter Semantik verworfen.

### Phase 6 â€“ Deklarative Toolprofile

Status: abgeschlossen

Ziele:

- Purple Knight vom Sonderfall zum ersten Profil der allgemeinen Engine machen.
- Weitere Werkzeuge ohne Ã„nderungen an der Kernpipeline ergÃ¤nzen.

Reihenfolge:

1. generisches Tabellenprofil
2. Purple Knight
3. PingCastle
4. CIS-CAT
5. Maester

Ein Profil beschreibt:

- Erkennungsmerkmale
- relevante Tabellen
- Feldsynonyme und semantische Rollen
- Status- und Severity-Mappings
- stabile Regelkennungen
- Darstellungshinweise
- VergleichsschlÃ¼ssel

Verifizierter Abschlussstand vom 2026-07-17:

- `ToolProfileDefinition` beschreibt Profil-ID, Version, Erkennungssignale, Tabellenregeln, Feldrollen, Normalisierung, PrÃ¤sentation und VergleichsschlÃ¼ssel.
- `createImportProfile` erzeugt aus jeder Definition dieselbe Laufzeitschnittstelle fÃ¼r Erkennung, Sheetpriorisierung, Standardansicht und Statusfilter.
- Generic, Purple Knight, PingCastle, CIS-CAT Pro und Maester besitzen versionierte Definitionen und werden Ã¼ber gemeinsame Kataloge registriert.
- Purple-Knight-Erkennung, Sheetpriorisierung, Standardfelder und Statusfilter laufen Ã¼ber dieselbe Profil-Fabrik wie die neuen Werkzeuge.
- Die Erkennungsengine bezieht Quellenmarker, Feldsynonyme und TabellenprioritÃ¤ten aus dem Definitionskatalog statt aus fest codierten Werkzeugzweigen.
- Die React-Anwendung nutzt den Laufzeitkatalog; Formatparser und Komponenten benÃ¶tigen fÃ¼r neue Profile keine Ã„nderungen.
- Die verwendete Profilversion wird im `ImportedDataset` gespeichert.
- Der generische Fallback bleibt bei unbekannten Tabellen aktiv und bewahrt alle Zeilen und Felder.
- Profilschema, Versionierung und Erweiterungsablauf sind in `docs/TOOL_PROFILES.md` dokumentiert.
- 29 Testdateien mit 74 Tests, Local-only- und ArchitekturprÃ¼fung sowie Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Neue Profile benÃ¶tigen keine Ã„nderungen an React-Komponenten oder Formatparsern.
- Generischer Import bleibt bei nicht erkannten Quellen funktionsfÃ¤hig.
- Profilversionen werden im Importergebnis festgehalten.

### Phase 7 â€“ Automatische Filter und Darstellung

Status: abgeschlossen

Ziele:

- Filter aus normalisierten Rollen und tatsÃ¤chlichen Datenwerten erzeugen.
- WerkzeugÃ¼bergreifende und quellenspezifische Filter kombinieren.

Universelle Filter:

- Projekt, Assessment und Scan-Lauf
- Quelltool
- Schweregrad und Status
- Kategorie und betroffenes Asset
- Review-Status, PrioritÃ¤t und Owner
- neu, vorhanden, behoben oder wieder aufgetreten

Dynamische Filter:

- Facetten fÃ¼r Felder mit wenigen wiederkehrenden Werten
- Bereichsfilter fÃ¼r Zahlen und Daten
- Volltextsuche fÃ¼r Freitext
- zusÃ¤tzliche werkzeugspezifische Attribute

Verifizierter Abschlussstand vom 2026-07-17:

- Eine plattformneutrale Facettenengine erzeugt Kategorie-, Zahlen- und Datumsfilter aus Spaltentypen, Wertverteilungen und erkannten kanonischen Rollen.
- Felder mit langen Freitexten, hoher KardinalitÃ¤t, leeren oder nahezu eindeutigen Werten erzeugen keine ungeeigneten Auswahllisten und bleiben Ã¼ber die Volltextsuche verfÃ¼gbar.
- Herkunft, Review-Status, PrioritÃ¤t und Owner werden als allgemeine Facetten ergÃ¤nzt, sobald mehrere sinnvolle Werte vorliegen.
- Purple-Knight-, CIS-CAT- und Maester-Statusgruppen werden Ã¼ber dasselbe profilunabhÃ¤ngige Facettenmodell gerendert; die React-OberflÃ¤che enthÃ¤lt keine Purple-Knight-Filterverzweigung mehr.
- Mehrere Facetten, Zahlen- beziehungsweise Datumsbereiche, Volltext, Actionlist und Sortierung lassen sich gemeinsam anwenden.
- Die Statuszeile zeigt Quellerkennungskonfidenz, ausstehende MappingbestÃ¤tigungen und Importwarnungen mit DetailbegrÃ¼ndungen.
- Die Vergleichsengine und der Repository-Vertrag liefern die benÃ¶tigten Lebenszyklus- und Mehrlaufdaten; die Facetten werden befÃ¼llt, sobald der Backend- und Mehrdateiworkflow aus den Phasen 10 und 12 diese Daten an die OberflÃ¤che anbindet.
- Funktionsweise und Grenzen sind in docs/DYNAMIC_FILTERS.md dokumentiert.
- 31 Testdateien mit 79 Tests, Local-only-PrÃ¼fung und Produktionsbuild laufen erfolgreich.

Verifizierte DarstellungsnachschÃ¤rfung vom 2026-08-02:

- Das bisher als `Filter text` bezeichnete Volltextfeld heisst sichtbar `Search` und steht in der unteren Work-Kopfzeile unabhaengig von der Bookmark-Breite horizontal zentriert. Unterhalb von 1200 px faellt es auf die bestehende fliessende Anordnung zurueck; Filtersemantik und angedockte Results bleiben unveraendert.
- Result-Fenster besitzen die getrennten UI-ZustÃ¤nde minimiert, im Cluster maximiert und frei herausgezogen maximiert.
- Result-Fenster zeigen Ergebniszähler und Finding-Titel in der Kopfzeile sowie zusätzlich als Überschrift im Ergebnisinhalt. Das frühere Würfelsymbol ist durch das farbige, funktionale Zustandsdreieck ersetzt: minimiert zeigt es nach rechts, maximiert nach unten; Klick und Kopfzeilen-Doppelklick verwenden denselben Umschaltpfad. Redundante Blatt- und Quellüberschriften bleiben entfernt.
- CIS-CAT-Result-Fenster zeigen die fachliche Tabellenhierarchie: `Assessment` steht über den Evidence-Tabellen. Bei Control Mappings bildet jede Framework-Version die einmalige Hauptüberschrift ihrer Tabellengruppe; jeder Control-Listenpunkt wird zur Überschrift seiner folgenden Tabelle. Der Assessment-Hinweis `No matching system items were found.` verwendet die blaue Evidence-Hervorhebung. Alle Ergebnisabschnitte sind global rahmenlos und ohne eigenen Innenabstand; nur die Zelllinien der Tabellen bleiben bestehen.
- Purple-Knight-Findings zeigen in Reader, Datensatzkarte und Kachel wieder `Passed` oder `Failed` statt einer im kanonischen `Result`-Feld wiederholten SI-Kurzkennung. Die Auswahl folgt einer geordneten Profilpräferenz; rein visuelle Profilregeln beschriften `Pass` als `Passed` und `IOE Found` als `Failed`, ohne den Quellwert zu verändern. Rohberichte, die den Status ausschließlich als `Result` liefern, bleiben kompatibel.
- Minimierte Results parken bei jedem Minimieren rechts oben in der Arbeitsfläche (80 px vom rechten Viewportrand und 46 px unterhalb der Arbeitsflächen-Oberkante), bleiben als Cluster aber über die Kopfzeile verschiebbar und können nicht in Filter- oder Statusband gezogen werden. Der geöffnete Results-Button im Reader trägt denselben individuellen Fensterton wie die Result-Kachel.
- Ein aus dem Cluster gezogenes maximiertes Result bleibt bei weiteren Ã–ffnungs-, Wiederherstellungs-, Auswahl- und Ansichtswechseln unangetastet; erst Minimieren koppelt es wieder ein.
- Hinter dem aktiven Cluster-Fenster bleiben nur 14 px breite, vertikal gestapelte Farbreiter sichtbar. Cluster, freie Fenster und ihre gespeicherten GrÃ¶ÃŸen werden an rechter und unterer Viewport-Kante begrenzt; der Inhalt scrollt innerhalb des Fensters.
- Ein maximiertes, weiterhin angedocktes Clusterfenster besitzt mindestens die Höhe des gesamten dahinterliegenden Stapels minimierter Kopfzeilen. Kurzer Ergebnisinhalt legt dadurch keine unteren minimierten Results frei; die Mindesthöhe ist an den noch sichtbaren Viewportbereich begrenzt. Frei herausgezogene Fenster bleiben inhalts- beziehungsweise nutzergrößenabhängig.
- Die ausdrueckliche Nutzerkorrektur vom 2026-08-21 trennt den Kopfzeilen-Doppelklick vom Zustandsdreieck: Ein minimiertes Result wird per Doppelklick normal wiederhergestellt; ein bereits geoeffnetes Result wird per Doppelklick auf die groesstmoegliche Arbeitsflaeche unterhalb des statischen Headers maximiert. Ein einfacher Klick auf die freie maximierte Titelleiste stellt seine unveraenderte Normalgeometrie und Clusterposition wieder her. Kopfzeilenaktionen loesen den Wechsel nicht aus und maximierte Fenster besitzen keine Resize-Kanten.
- Die Darstellungsnachschärfung und die nachfolgende Build-/Startkonfigurationshärtung sind mit 105 bestandenen Testdateien und 501 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie getrennten Client-/Server-Produktionsbuilds verifiziert.

Verifizierte Graph-Darstellungsnachschaerfung vom 2026-08-22:

- Die Graphansicht verwendet ein ruhiges dreispaltiges Arbeitslayout: links die gemeinsamen fachlichen Filter, mittig den kompakter geclusterten Netzwerkgraphen und rechts einen dauerhaft vorhandenen Detailinspektor. Flache Flaechen, reduzierte Kanten und kleinere Knoten-/Kartenabstaende vermeiden die bisherige Ueberladung.
- Work und Graph lesen und veraendern dieselben Filterzustaende im AppProvider. Suche, Quellblatt, Status, alle dynamisch verfuegbaren Facetten und `My Workspace only` werden links im Graph mit den bestehenden gemeinsamen Controls angeboten. Ein Wechsel der Ansicht bewahrt deshalb exakt dieselbe fachliche Ergebnismenge in beide Richtungen; nur `Labels`, Auswahl, Zoom und Position bleiben lokale Darstellungszustaende.
- Die Graphprojektion wird unmittelbar aus `useFilteredRecords()` aufgebaut und besitzt keine zweite lokale Suche, Kategorie-, Severity- oder Mappingfilterung mehr. Damit bleiben werkzeug- und datenabhaengige Filterangebote unveraendert und es werden keine neuen Filter erfunden.
- Zwei fokussierte synthetische Graph-Tests und der Gesamtlauf mit 647 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind erfolgreich. Local-only-Pruefung und separater Client-Bundlebuild sind gruen. Der vollstaendige Baseline-Build ist derzeit durch einen vorbestehenden, nicht zu dieser Aenderung gehoerenden TypeScript-Fehler in `server/assessor-http-server.ts` Zeile 196 blockiert; der bekannte Designcheck-Befund bleibt unveraendert auf `src/styles/datahub-redesign.css` Zeilen 39 und 42 begrenzt. Es wurden keine Realinhalte inspiziert.

Reduzierte Graph-Filter vom 2026-08-22 (Phase-7-Praesentationskorrektur; ersetzt die zuvor dokumentierte vollstaendige Sichtbarkeit aller gemeinsamen Filter im Graph-Panel):

- `Result message`, `SI version`, `Source: Scan` und `My Workspace only` werden im linken Graph-Panel nicht mehr angeboten. Suche, Quellblatt und die uebrigen fachlichen Facetten bleiben sichtbar. Bereits in Work gesetzte gemeinsame Filter bleiben auch dann fuer die Graphprojektion wirksam; die Korrektur veraendert weder Filterzustand noch Ergebnismengenlogik.
- Der Graph-Test, der vollstaendige Client-/Server-Produktionsbuild, 650 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei unveraenderten Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz-, Schema- oder Datenanderung; Phase 7 bleibt abgeschlossen.

Sidebar-unabhaengiges Graph-Panel vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Das Einklappen der Hauptnavigation blendet nur noch deren direktes `aside` aus. Die verschachtelten Graph-Bereiche fuer Filter und Detailinspektor bleiben sichtbar; dieselbe Selektorgrenze gilt in der schmalen Ansicht. Damit veraendert der Navigationszustand weder Graph-Controls noch Graph-Layout.
- Der fokussierte Graph-Test, 650 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei unveraenderten Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Workspace und Ansichts-Snapshots im Graph vom 2026-08-22 (Phase-7-Praesentationskorrektur; ersetzt die Entfernung von `My Workspace only` aus dem Graph-Panel):

- Unter den fachlichen Graph-Filtern steht wieder eine Checkbox `My Workspace`. Sie verwendet exakt den gemeinsamen `actionOnly`-/Reviewzustand aus Work und ist ohne markierte Findings wie die bestehende Work-Aktion deaktiviert; es gibt keine zweite Graph-Filterlogik.
- Derselbe `ViewBookmarks`-Baustein wie in Work steht unmittelbar darunter zur Verfuegung. Anlegen, Benennen, Anwenden und Entfernen verwenden den bestehenden client- und timeslotgebundenen Speicherbereich; der Graph fuehrt keine eigene Snapshot-Persistenz ein.
- Sieben fokussierte Graph-/Bookmarktests, 656 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt Checkbox, Snapshot-Aktion und den ohne Speicherung wieder geschlossenen Benennungsdialog. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Path Snapshots vom 2026-08-22 (Phase-7-Erweiterung; praezisiert die Graph-Snapshot-Semantik):

- Die Graph-Aktion heisst `Path Snapshot` und ist nur mit mindestens einem gepinnten Knoten aktiv. Gespeichert werden alle gleichzeitig gepinnten Knoten sowie die eindeutige Menge ihrer direkt verbundenen Nachbarn; mehrere aktive Knoten heben alle ihre inzidenten Kanten gemeinsam rot hervor.
- Normale Ansichts-Snapshots und Path Snapshots liegen im selben bestehenden client- und timeslotgebundenen Speicher und teilen sich dessen unveraenderte Obergrenze von sieben Eintraegen. Path Snapshots sind in der gemeinsamen Work-Liste rot umrandet.
- Das Oeffnen eines Path Snapshots aus Work wendet zuerst den gespeicherten gemeinsamen View-Zustand an, wechselt in den Graphen und stellt alle noch vorhandenen aktiven Knoten wieder her. Fehlende Knoten werden konservativ ausgelassen; gespeicherte Nachbarschafts-IDs werden validiert und nicht als neue fachliche Beziehung interpretiert.
- Elf fokussierte Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Der Gesamtlauf umfasst 658 bestandene Tests, 8 uebersprungene optionale PostgreSQL-Tests und eine erfolgreiche Local-only-Pruefung; der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt deaktivierten Button ohne Auswahl, Aktivierung nach Pin, acht rote Direktpfade, Speicherung, rote Work-Umrandung und Wiederherstellung; der temporaere QA-Snapshot wurde anschliessend geloescht. Keine API-, Schema-, Backend- oder Datenmutation; Phase 7 bleibt abgeschlossen.

CIS-CAT-Soll-/Verstossmarkierung vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- `Criterion` ist die vom CIS-CAT-Benchmark gelieferte konkrete Bestehens- beziehungsweise Sollbedingung der Regel, nicht bloss ein frei formulierter Verbesserungsvorschlag. Entsprechende Zeilen werden profilgesteuert gruen markiert.
- Vom CIS-CAT-Quellbericht als tatsaechlich ausgewertet gekennzeichnete Istwertzeilen zeigen die gegen dieses Criterion gepruefte Abweichung und wechseln von der bisherigen blauen Evidenzfarbe auf Rot. Der besondere Informationshinweis `No matching system items were found.` bleibt entsprechend der frueheren Vorgabe blau.
- Die Klassifikation liegt deklarativ im CIS-CAT-Profil und wird durch eine werkzeugneutrale Results-Zeilenrolle dargestellt; React enthaelt keine CIS-CAT-Parsinglogik. Originalwerte, Importmarker und Auswertungslogik bleiben unveraendert.
- 47 fokussierte Results-/Profiltests, 660 Standardtests, Local-only und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt je eine Criterion- und Verstosszeile sowie getrennte Dark-/Light-Farben. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen.

Pathfinder-Bereichsname vom 2026-08-22 (Phase-7-Beschriftungskorrektur):

- Der sichtbare Navigationsname `Graph` und die Bereichsueberschrift `MITRE Attack Paths` heissen einheitlich `Pathfinder`. Der interne stabile Bereichsschluessel `graph`, Komponenten-, CSS- und Persistenzbezeichner bleiben unveraendert.
- Zwei fokussierte Beschriftungstests, 661 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt Navigation, Ueberschrift und weiterhin sichtbaren Graphen. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Gemeinsamer Source-Scan-Filter im Pathfinder vom 2026-08-22 (Phase-7-Filterkorrektur; ersetzt die Entfernung von `Source: Scan` aus dem Graph-Panel):

- Der bisherige separate Quellblatt-Selector samt `Source`-Beschriftung ist aus dem Pathfinder entfernt. Stattdessen rendert das Panel wieder die bestehende dynamische Work-Facette `Source: Scan` mit Scanner, Scanzeitpunkt und Trefferzahl.
- Work und Pathfinder verwenden damit denselben Facettenzustand und dieselbe Filterengine; es gibt keine lokale Source-Implementierung. Die fachlich notwendigen Scanner- und Timeslotgrenzen bleiben erhalten, waehrend technische Detailblaetter nicht mehr als primaere Quellenwahl angeboten werden.
- Zwoelf fokussierte Graph-/Facettentests, 661 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt genau eine Source-Scan-Facette mit fuenf Optionen, keinen separaten Quellselector und eine technische Knotenreduktion von 626 auf 466; anschliessend wurde auf `All` zurueckgesetzt. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Getrennte Karten- und Textschalter im Pathfinder vom 2026-08-22 (Phase-7-Darstellungskorrektur):

- `Labels On/Off` steuert ausschliesslich die Kacheln gepinnter Knoten; `Text On/Off` steuert unabhaengig davon die Beschriftungen neben den Punkten. Kacheln starten eingeschaltet, Punkttexte entsprechend der Nutzervorgabe ausgeschaltet.
- Knotenauswahl, Kantenmarkierung, Filter, Zoom und Path Snapshots bleiben unveraendert. Die Dummy-Browserpruefung bestaetigt den Default `Labels On`/`Text Off`, eine Kachel nach Knotenklick, deren Entfernung durch `Labels Off` sowie 626 Punkttexte nach `Text On`; abschliessend wurden beide Schalter auf den Default zurueckgestellt.
- Drei fokussierte Graph-Tests, 661 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Dynamische Filterspur im Pathfinder-Kopf vom 2026-08-22 (Phase-7-Darstellungskorrektur):

- Rechts neben `Pathfinder` erscheint bei mindestens einem aktiven nutzergesteuerten Filter ein gelbes Rechtsdreieck und anschliessend die Bezeichnung des Filters samt Auswahl. Weitere Filter werden in Panelreihenfolge durch ein gelbes Plus getrennt. Ohne aktiven Filter wird die Spur vollstaendig ausgeblendet.
- Die Spur leitet Suche, sichtbare dynamische Facetten, Mehrfachwerte, Wertebereiche und `My Workspace` aus dem bestehenden gemeinsamen AppProvider-Zustand ab. Der fuer den Graphen feste Deviation-Scope und im Pathfinder ausgeblendete technische Facetten werden nicht als Nutzerfilter ausgegeben.
- Sieben fokussierte Pathfinder-/Kopfzeilentests, 663 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt die leere Ausgangsspur, `Severity: Critical + Category: Account Security`, gelbe Marker mit `rgb(217, 150, 42)` und die direkte Platzierung rechts vom Titel; die Testfilter wurden zurueckgesetzt. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Einheitliche Strukturknotenfarbe im Pathfinder vom 2026-08-22 (Phase-7-Farbkorrektur):

- Alle bereits ringmarkierten Strukturrollen `Category`, `D3FEND`, `Target`, `Technique` und `Tactic` verwenden fuer Punkt, Ring und die optionale Rollenkachel den gemeinsamen Farbtoken `#9333EA`. Finding-Punkte bleiben davon getrennt und verwenden weiterhin ausschliesslich ihre Severity-Farbe.
- Drei fokussierte Graph-Tests, 663 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browsermessung bestaetigt `rgb(147, 51, 234)` fuer 160 Kategorien, sechs D3FEND-Knoten, ein Target und sechs Taktiken sowie eine unveraenderte rote Critical-Severity am Finding; der konkrete Dummy-Stand enthielt keine Technik-Knoten. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Proportionale Kachelskalierung und vollstaendige Kachelhoehe im Pathfinder vom 2026-08-22 (Phase-7-Darstellungskorrektur; ersetzt die zoomstabile Kachelentscheidung desselben Tages):

- Finding- und Rollenkacheln verbleiben ohne inverse Zoomtransformation im Graph-Koordinatensystem und skalieren wieder proportional mit der Kamera. Bei der minimalen Zoomstufe `0.08` schrumpft die Finding-Kachel damit auf rund 19 mal 14 px und darf bewusst unlesbar werden; Punkttexte bleiben weiterhin getrennt zoomstabil.
- Die logische Finding-Kachelhoehe steigt von 144 auf 176 px, damit Outcome, Kategorie, Severity, Weight und Score innerhalb der wiederverwendeten Matrixkachel vollstaendig Platz finden. Breite, Inhalt, Klickbedingung und Aktionen bleiben unveraendert.
- Drei fokussierte Graph-Tests, 663 Standardtests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browsermessung bestaetigt bei Fit 85,72 mal 62,86 px ohne vertikalen Overflow und bei maximalem Herauszoomen 19,20 mal 14,08 px; Auswahl und Zoom wurden anschliessend zurueckgesetzt. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Path-Snapshot-Findingscope und Pathfinder-Zustandserhalt vom 2026-08-22 (Phase-7-Zustandskorrektur):

- Die Auswahl eines Path Snapshots im Workbereich bleibt in Work und begrenzt die gemeinsame Finding-Pipeline temporaer auf die im Snapshot enthaltenen `finding:`-Knoten. Dieser Scope ist von Workspace-Markierungen und Reviews getrennt; Reset, ein regulaerer gespeicherter View sowie ein Daten- oder Timeslotwechsel entfernen ihn wieder.
- Die Pathfinder-Ansicht bleibt beim Wechsel nach Work unsichtbar montiert. Kamera, angeheftete Positionen, aktive Punkte, Kacheln sowie Label- und Textschalter bleiben dadurch erhalten. Eine Rueckkehr fuehrt nur dann erneut ein Fit aus, wenn sich die Graphsignatur durch Daten oder Filter tatsaechlich geaendert hat.
- 19 fokussierte Tests, 665 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Die Dummy-Browserpruefung bestaetigt `Shown 1` im Workbereich fuer einen temporaeren Path Snapshot sowie eine exakt unveraenderte Kameratransformation, einen aktiven Punkt und eine sichtbare Kachel nach `Open in Work` und Rueckkehr. Der QA-Snapshot wurde geloescht und Work auf `Shown 453` zurueckgesetzt. Keine API-, Schema-, Persistenz- oder Fachdatenmutation; Phase 7 bleibt abgeschlossen.

Wortstabile Rollenkacheln im Pathfinder vom 2026-08-22 (Phase-7-Darstellungskorrektur):

- Die logische Breite ausgewaehlter Kategorie-, Taktik-, Technik-, D3FEND- und Zielkacheln steigt von 116 auf 148 px. Innerhalb einzelner Begriffe wird kein beliebiger Umbruch mehr erzwungen; mehrteilige lange Bezeichnungen koennen weiterhin an regulaeren Wortgrenzen auf bis zu zwei beziehungsweise drei Zeilen umbrechen.
- Drei fokussierte Graph-Tests, 665 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Einheitliche kompakte Pathfinder-Kacheln vom 2026-08-23 (Phase-7-Darstellungskorrektur; ersetzt die Pathfinder-Finding-Grundflaeche vom 2026-08-22):

- Finding- und Rollenkacheln verwenden im Pathfinder dieselbe logische Grundflaeche von 148 mal 72 px. Die wiederverwendete Matrixkachel wird nur innerhalb des Pathfinder-Kontexts durch kleinere Innenabstaende, 18-px-Icon- und Aktionsspalten sowie eine einzeilig begrenzte Badgeleiste verdichtet; die regulaere Matrixdarstellung bleibt unveraendert.
- Titel beider Pathfinder-Kacheltypen verwenden exakt 16 px und entsprechen damit der Schriftgroesse der Textbeschriftung neben den Graphpunkten. Proportionale Zoomskalierung, Klickbedingung und Finding-Aktionen bleiben erhalten.
- Drei fokussierte Graph-Tests, 665 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Clientname in allen Bereichs-Headern vom 2026-08-23 (Phase-7-Darstellungskorrektur):

- Sobald ein aktiver Clientkontext besteht, zeigen Work, Pathfinder, Dashboard, Result DB, DB Structure und Data Hub den Clientnamen als reinen rechtsbuendigen 16-px-Text mit 16 px Abstand zum rechten Rand. Der Name besitzt weder Rahmen noch Hintergrund und wird bei Platzmangel einzeilig mit Ellipsis gekuerzt.
- Der Data-Hub-Detailkopf erhaelt den Namen direkt aus dem dort geoeffneten Clientformular, auch wenn dieser Client noch nicht als Work-Kontext geladen wurde. Beim Verlassen des Details faellt der Kopf wieder auf den aktiven Work-Client zurueck; ohne Clientkontext bleibt die Stelle leer.
- Drei fokussierte Header-Tests, 666 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Sichtbar zoomstabile Pathfinder-Kacheltypografie vom 2026-08-23 (Phase-7-Darstellungskorrektur; praezisiert die 16-px-Regel desselben Tages):

- Die 16-px-Vorgabe bezieht sich auf die tatsaechlich am Bildschirm sichtbare Titelgroesse der Punktbeschriftung, nicht nur auf den logischen CSS-Wert innerhalb der zoomenden SVG-Kamera. Der komplette Kachel-UI-Inhalt wird daher invers zur aktuellen Kamera skaliert.
- Titel, Hexagon, Bookmark-/Result-Aktionen, Badges, Abstaende und Konturen bleiben beim Hineinzoomen visuell kompakt. Die 148-mal-72-px-Kachelflaeche selbst bleibt weiterhin proportional an den Graphzoom gebunden; ihre innere Layoutflaeche wird passend zur Kamera erweitert, sodass die kompensierte UI die Kachel korrekt ausnutzt.
- Drei fokussierte Graph-Tests, 666 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Verbindlicher 20-px-Panel-Inset vom 2026-08-23 (Phase-7-Designsystemkorrektur):

- Work ist die verbindliche Referenz fuer den Abstand zwischen dem Aussenrand eines abgerundeten Hauptpanels und seinem Inhalt: 20 px auf allen vier Seiten. `--panel-content-inset: 20px` ist der kanonische Token; `--panel-inset` bleibt als Kompatibilitaetsalias bestehen.
- Jede Ansicht wendet den Inset genau einmal auf ihrem Root-Inhaltscontainer an. Work-Kacheln, Treffer-/Leseransicht, Tabelle und Rohdaten, Datahub, Dashboard, DB Structure, Result DB, Client-Detail und Pathfinder verwenden denselben Wert. Split-Panes liegen innerhalb dieses Insets und erzeugen keinen zweiten Aussenabstand.
- Responsive Breakpoints reduzieren den Aussenabstand nicht mehr. Die Regel ist zusaetzlich in `AGENTS.md` als verbindliche Vorgabe fuer alle kuenftigen Hauptpanels dokumentiert; lokale Ersatzwerte sind ohne ausdrueckliche Nutzerkorrektur unzulaessig.
- Acht fokussierte Panel-/Graph-/Datahub-Tests, 669 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Der vollstaendige Client-/Server-Produktionsbuild ist erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der zwei vorbestehenden Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen.

Verifizierte Datahub-Darstellungsnachschaerfung vom 2026-08-22:

- Die regulaeren Bereichsbezeichnungen im gemeinsamen Anwendungskopf bewahren ihre normale Schreibweise und verwenden ansichtsuebergreifend exakt die Typografie des grossen Mandantentitels: 54 px, Semibold, Zeilenhoehe 1,15 und Laufweite -0,04 em. Die zentrale Regel umfasst Datahub, DB Structure, Dashboard, MITRE Attack Paths und Result DB; der funktionale Work-Kopf bleibt unveraendert.
- Alle Mandantenkacheln einschliesslich der Plus-Kachel verwenden denselben Hover-/Tastaturfokuseffekt wie die Kacheln der Matrixansicht: staerkere Kontur, Hoverflaeche, angehobener Schatten und 2 px Hub mit derselben 120-ms-Transition. Bei angeforderter reduzierter Bewegung entfaellt der Hub; Auswahlumrandung und Klicksemantik bleiben erhalten.
- Die sechs kanonisch gespeisten Statusdiagramme stehen vor der Mandantenauswahl. Darunter erscheinen ausschliesslich persistierte Mandanten als Karten im verbindlichen Donut-Kacheldesign, jedoch ohne Diagramm, sowie genau eine gleichartige dezente Plus-Kachel zum Anlegen eines Mandanten; kuenstliche `Empty`-Slots entfallen.
- Ein Klick waehlt genau einen Mandanten. Nur seine Karte ist umrandet und zeigt rechts oben `Show`; die Aktion oeffnet die bestehende Mandantenansicht. Die Diagramme lesen den neuesten scannergebundenen Timeslot dieses Mandanten, waehrend Mandanten ohne Scanbestand ausgewaehlt werden koennen und Nullwerte zeigen.
- Vier fokussierte Datahub-Suites mit 11 synthetischen Tests sowie der Gesamtlauf mit 620 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind erfolgreich. Local-only-, Designpruefung und Client-/Server-Produktionsbuild sind gruen. Die inhaltsarme Browserpruefung bestaetigt genau eine Auswahl, einen `Show`-Button, keine Platzhalter, eine Plus-Kachel, Diagrammwechsel und die Navigation zur Mandantenansicht. App und Backend wurden nach einem abgestuerzten Vite-Dateiwatcher kontrolliert neu gestartet.

Verifizierter Bearbeitungsschutz fuer Mandantenstammdaten vom 2026-08-22:

- Bestehende Mandanten oeffnen mit schreibgeschuetzten Feldern fuer Name, Consultant und Remarks. Ein als `Edit client data` beschrifteter, rahmenloser Stift steht unmittelbar hinter `Master Data · Client Data` und aktiviert den Bearbeitungsmodus; erst dann erscheint die Speicheraktion. Auch ein programmgesteuertes Formular-Submit wird vor der Aktivierung abgewiesen.
- Neu angelegte Mandanten bleiben unmittelbar editierbar. Nach erfolgreichem Speichern, beim Loeschen des aktuell geoeffneten Mandanten und beim Zurueckkehren zur Uebersicht wird der Bearbeitungsmodus zurueckgesetzt.
- `Import Data` und `GPO Backup Folder` stehen in jeder bestehenden Mandantenansicht zur Verfuegung, auch wenn noch kein Assessment beziehungsweise Timeslot existiert. Die bestehende optionale Assessment-Zuordnung bleibt erhalten: Ein normaler Dateiimport erzeugt ohne Ziel-ID den ersten Timeslot, ein GPO-Backup wird ohne Ziel-ID zunaechst dem Mandanten zugeordnet.
- Der grosse Mandantentitel besitzt eine erhoehte Zeilenhoehe und zusaetzlichen unteren Innenabstand, damit Glyphen und Unterlaengen trotz der weiterhin einzeiligen Ellipsendarstellung nicht am unteren Rand abgeschnitten werden.
- Die Trennlinie zwischen Mandantenkopf und Aktionszeile sowie die untere Abschlusslinie der Aktionszeile entfallen; der gesamte Kopf-/Aktionsbereich bleibt ohne horizontale Linien.
- Der Ruecksprung aus der Mandantenansicht besteht aus einem vergroesserten 28-px-Dreieck und der sichtbaren Beschriftung `Back`. Symbol und Text liegen innerhalb derselben Schaltflaeche und sind gemeinsam per Maus und Tastatur bedienbar.
- Die Datahub-Scrollflaeche reserviert ihren vertikalen Scrollbar-Gutter dauerhaft. Das Auf- und Zuklappen laengerer Bereiche wie `Imported Security Baselines` aendert dadurch nicht mehr die nutzbare Inhaltsbreite und verschiebt die zentrierte Anzeige nicht horizontal.
- `Imported Security Baselines` startet standardmaessig eingeklappt; Zaehler und Upload-Aktion bleiben in der geschlossenen Kopfzeile sichtbar.
- Zwei fokussierte Datahub-Suites mit vier synthetischen Tests sowie der Gesamtlauf mit 620 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind erfolgreich. Local-only-, Designpruefung und Client-/Server-Produktionsbuild sind gruen. Die inhaltsarme Browserpruefung bestaetigt drei schreibgeschuetzte Felder und keine Speicheraktion vor dem Stiftklick sowie drei editierbare Felder und genau eine Speicheraktion danach; die Pruefung kehrte ohne Speichern zur Uebersicht zurueck.

Verifizierter Timeslot-Auswahlworkflow vom 2026-08-22 (Phase 7/8/12-Nachschaerfung):

- Beim Oeffnen einer Mandantendetailansicht ist der chronologisch neueste vorhandene Timeslot vorausgewaehlt und zugleich aktiver Zielstand. Eine anschliessende bewusste Abwahl bleibt moeglich.
- Ausgewaehlte Timeslots tragen ihre zielgebundenen Aktionen direkt in der Datumszeile: `Delete`, `Import Scan` und `Import GPO Backup Folder (Zip)`. Beide Importe uebergeben die Assessment-ID genau dieses Slots. Der bestehende Mandanten-Delete bleibt unveraendert in der Mandantenaktionsleiste.
- Timeslot-Delete ist ein eigener bestaetigungspflichtiger Assessment-DELETE-Pfad durch UI, Same-Origin-API sowie Local- und PostgreSQL-Repository. Er entfernt den bestaetigten Assessment-Stand mit zugeordneten Scan-, GPO-, Finding-, Evidenz- und Mappingdaten, bewahrt aber Mandant und andere Timeslots. Keine SQL-Migration erforderlich.
- Der Timeslot-Bereich der Mandantenansicht besitzt oberhalb der geschlossenen Datumszeilen die eindeutige sichtbare Ueberschrift `Timeslots` in der groessten regulaeren UI-Titelgroesse. Die Auswahlzusammenfassung darunter ist rahmenlos und verwendet die regulaere UI-Textgroesse; Auswahl-, Tabellen- und Plus-Workflow bleiben unveraendert.
- Die bisherige `Scan History · Linked Scan Reports` der Mandantenansicht ist eine standardmaessig geschlossene Timeslot-Tabelle. Jede Zeile repraesentiert den fachlichen Assessment-Stichtag und fasst Quellen, Scanberichte, Dateien, Formate, Groesse und Importzeit zusammen; bestehende ScanRun-Loeschaktionen bleiben je Bericht erhalten.
- Ein rahmenloses Plus in der Timeslot-Kopfzeile oeffnet einen kleinen Datumsdialog. Der bestaetigte Wert erzeugt ueber die vorhandene Assessment-API einen leeren `Assessment`-Timeslot mit `effectiveAt`, waehlt ihn als Importziel aus und veraendert weder Scanner- noch GPO-Importlogik.
- Checkboxen erlauben eine oder mehrere Timeslot-Auswahlen. `Open` bleibt ohne verwertbaren Stand gesperrt. Bei genau einem Stand werden dessen Scannerlaeufe geoeffnet; ab zwei Staenden wird ausschliesslich die Schnittmenge sicher erkannter Scannerwerkzeuge ueber alle gewaehlten Timeslots projiziert. `generic`, `unknown` und `multiple` werden nicht automatisch gleichgesetzt. GPO wird als getrennte Assessment-Quelle in der Schnittmenge gefuehrt und bei fehlender Abdeckung ausgeschlossen, niemals als kuenstlicher ScanRun vermischt.
- Die Auswahlzeile weist Anzahl gemeinsamer und ausgeschlossener Quellen aus. Ein synthetischer Kreuzfall bestaetigt, dass gemeinsames PingCastle erhalten bleibt, waehrend nur einseitiges CIS-CAT und GPO ausgeschlossen werden. Drei fokussierte Suites mit 12 Tests, die Gesamtsuite mit 621 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt geschlossenen Default, Plus-/Datumsdialog, abbruchfreie Rueckkehr, Checkboxen und die zustandsabhaengige Open-Freigabe ohne Datenmutation.

Umgesetzte Mandantendetail-Master-Detail-Ansicht vom 2026-08-22 (Phase 7/8/12-Nachschaerfung):

- Die ausdruecklich ausgewaehlte Work-/Reports-Referenz ersetzt den zentrierten gestapelten 1180-px-Aufbau des Mandantendetails. Die Ansicht nutzt die gesamte Datahub-Arbeitsflaeche als 44/56-Master-Detail-Raster: links Mandantenkopf und eine unabhaengig scrollende Timeslotliste, rechts die read-first Mandanteninformation.
- Jeder persistierte Timeslot bleibt eine auswählbare Assessment-Einheit und kann im linken Navigator aufgeklappt werden. Darunter erscheinen ausschliesslich seine persistierten ScanRuns mit Werkzeugname und vorhandener Importmetadaten-Zusammenfassung; Beispielnamen und kuenstliche Timeslots werden nicht erzeugt. Timeslot-Delete, zielgebundener Scan-/GPO-Import und ScanRun-Delete verwenden unveraendert ihre bestaetigten bestehenden Pfade.
- ScanRuns eines ausgewaehlten Timeslots sind einzeln an- und abwaehlbar. Der lokale Ausschlusszustand veraendert keine Persistenz und wirkt nur auf `Open`; neue Importe bleiben standardmaessig eingeschlossen. Bei mehreren Timeslots wird die bestehende sichere Werkzeug-Schnittmenge weiterhin erst nach dieser Auswahl gebildet.
- Name, Consultant und Remarks bleiben bis zum Stiftklick schreibgeschuetzt; Save erscheint nur im Bearbeitungsmodus. `Open` steht im Informationskopf, waehrend der bestaetigungspflichtige Mandanten-Delete getrennt am unteren Rand der Informationsseite liegt. Auf kleinen Viewports stapeln sich Navigator und Information ohne neue Fachfunktion.
- Drei fokussierte Strukturregressionen und die Gesamtsuite mit 631 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-Pruefung und Client-/Server-Produktionsbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt 44/56-Spalten, buendige Gesamtbreite, unabhaengiges Scrollen, vorhandene Edit-/Timeslot-/Open-Controls und eine wirksame Scan-Abwahl ohne Laufzeitfehler. Der globale Designcheck bleibt ausschliesslich wegen der bereits dokumentierten, unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot; die neue Mandantendetail-CSS fuehrt keine zusaetzliche Verletzung ein.

Nachgeschaerfte Mandantendetail-Geometrie vom 2026-08-22 (Phase 7-Praesentationskorrektur):

- Die Nutzerkorrektur ersetzt das unmittelbar zuvor umgesetzte proportionale 44/56-Raster. Der Timeslot-/ScanRun-Navigator verwendet nun exakt die verbindliche Work-/Reports-Listenbreite `clamp(420px, 27vw, 520px)`; die rechte Arbeitsflaeche darf ungenutzt bleiben.
- Die Mandanteninformation ist eine links ausgerichtete, transparente Reader-Dokumentflaeche mit maximal 794 px Breite und ohne Aussenrahmen, Kartenhintergrund oder Labelkaesten. Kopf, read-first Werte und Mandanten-Delete folgen dem Work-Finding-Muster aus Abschnittsueberschrift, Fliesstext und feinem horizontalem Trenner; erst der ausdrueckliche Editzustand zeigt notwendige Eingaberahmen.
- Die Timeslotliste uebernimmt zusaetzlich die flache Work-Listenlogik: App-Hintergrund, rahmenlose Eintraege, eingerueckte Haarlinientrenner und bestehender Auswahlmarker statt umrandeter Karten. Drei fokussierte Strukturregressionen und die Gesamtsuite mit 631 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-Pruefung und Client-/Server-Produktionsbuild sind erfolgreich. Die inhaltsarme Browserpruefung misst bei 2560 px Viewport 520 px Navigator und 794 px transparente, rahmenlose Dokumentflaeche; die Timeslotliste bleibt unabhaengig scrollbar. Der globale Designcheck bleibt ausschliesslich wegen der bereits dokumentierten, unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Fachfunktionsaenderung; Phase 7/8/12-Status bleibt abgeschlossen.

Finale visuelle Mandantendetail-Korrektur vom 2026-08-22 (Phase 7-Praesentationskorrektur):

- Eine noch wirksame zweispaltige Altregel des Stammdatenformulars ist im Mandantendetail explizit auf eine Spalte zurueckgesetzt. Im Lesemodus werden Name, Consultant und Remarks nicht mehr als schreibgeschuetzte Inputs, sondern als echte vertikale Dokumentabschnitte mit neutraler Ueberschrift, 16-px-Werttext und Haarlinientrenner gerendert; Inputs erscheinen erst nach dem Stiftklick.
- Das Violett ist aus den Auswahlrollen dieser Ansicht entfernt: Timeslot- und ScanRun-Checkboxen verwenden Bernstein, die ausgewaehlte Timeslotzeile eine neutrale Hoverflaeche und der linke Auswahlmarker den bernsteinfarbenen Aktivton. `Import Scan` und `Import GPO Backup Folder (Zip)` sind gleichrangige gelbe Primaeraktionen; Delete bleibt neutral.
- Drei fokussierte Strukturregressionen und 631 Standardtests sind gruen, 8 optionale PostgreSQL-Tests uebersprungen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt drei vertikale 794-px-Dokumentabschnitte, neutrale Label, bernsteinfarbene Checkboxen, neutrale Auswahlflaeche und zwei identisch gelbe Importbuttons. Der globale Designcheck bleibt ausschliesslich an den unveraenderten dokumentierten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Fachfunktionsaenderung.

Umgesetzte ScanRun-Readiness-Tabelle vom 2026-08-22 (Phase 7/12-Nachschaerfung):

- Die aufgeklappte Timeslot-Tabelle uebernimmt das Baseline-Muster als kompaktes Fuenfspaltenraster `Auswahl | Scan | Imported | Status | Actions`. Die Groesse entfaellt zugunsten des fachlich wichtigeren Status. Jede Zeile besitzt einen ausgeschriebenen `Delete`-Button; Papierkorb-Icons sind aus ScanRun- und Mandanten-Delete entfernt und durch eine Strukturregression ausgeschlossen.
- Der Status beruht nicht auf dem blossen Uploadnachweis. `Recognized` verlangt einen persistierten ScanRun, kanonische Finding-Occurrences dieses Runs und ein spezifisch erkanntes Werkzeugprofil. `Generic` bezeichnet darstellbare kanonische Work-Daten ohne spezifisches Profil. `Not viewable` bedeutet, dass der Upload zwar gespeichert ist, aber keine Work-darstellbaren Records erzeugt hat; `Unavailable` bezeichnet ausschliesslich einen fehlgeschlagenen Readiness-Abruf.
- Nur `Recognized` und `Generic` sind fuer `Open` auswaehlbar. Checking, Not viewable und Unavailable deaktivieren die Zeilencheckbox und werden bereits vor Einzel- oder Mehrfach-Timeslot-Projektion aus der Runmenge entfernt. Damit fuehrt ein gespeicherter, aber leer projizierter Excel-Import nicht mehr still in eine leere Work-Ansicht.
- Zwei fokussierte Suites mit 5 Tests und die Gesamtsuite mit 633 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt fuenf Spalten ohne horizontalen Ueberlauf, vier technisch als `recognized` bewertete Runs, vier Text-Delete-Buttons, keine Delete-SVGs und keinen Papierkorbpfad. Der globale Designcheck bleibt ausschliesslich an den unveraenderten dokumentierten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz- oder Schemaaenderung.

Kontextabhaengiger Data-Hub-Kopf vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Die grosse Bereichsueberschrift lautet in der Data-Hub-Hauptansicht `Data Hub`. Sobald Neuanlage oder bestehende Mandantendetails geoeffnet sind, meldet die Detailkomponente ihren vorhandenen Formzustand an die Shell und die Ueberschrift wechselt auf `Client`. `Back` sowie das Verlassen des Bereichs setzen den Shellzustand wieder auf `Data Hub`.
- Ein fokussierter Regressionstest, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt `Data Hub -> Client -> Data Hub` parallel zu `Uebersicht -> Detail -> Uebersicht`. Der globale Designcheck bleibt ausschliesslich an den zwei unveraenderten dokumentierten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Entdoppelter Mandantenname vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Der Mandantenname erscheint im Lesemodus ausschliesslich links oberhalb der Timeslots und nicht erneut als Abschnitt der rechten Client-Information. Beim Stiftklick beziehungsweise bei einer Neuanlage wird exakt dieser linke Titel zum erforderlichen Namenseingabefeld; das Feld bleibt ueber `form="tenant-editor-form"` Teil des unveraenderten Save-Workflows. Rechts verbleiben Consultant und Remarks.
- Zwei fokussierte Suites mit 4 Tests, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Die inhaltsarme Browserpruefung bestaetigt zwei rechte Abschnitte, kein rechtes Namenslabel, einen linken Lesetitel und nach Edit genau ein erforderliches linkes Namensfeld plus Save. Der bekannte Designcheck-Befund bleibt unveraendert auf `datahub-redesign.css` Zeilen 39 und 42 begrenzt. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Vertikale Stammdatenhierarchie vom 2026-08-22 (Phase-7-Praesentationskorrektur; ersetzt die unmittelbar vorherige Entdoppelungsentscheidung):

- Die neueste Nutzerkorrektur stellt `Name` in der rechten Client-Information wieder her. `Name`, `Consultant` und `Remarks` bilden dort jeweils eine vertikale Dokumentzeile: kompakte 14-px-Bezeichnung, direkt darunter der linksbuendige 16-px-Wert. Der linke Identitaetskopf bleibt eine reine Anzeige und wird im Editmodus nicht mehr zum Formularfeld.
- Zwei fokussierte Suites mit 4 Tests sind erfolgreich. Die inhaltsarme Browsergeometrie bestaetigt drei Abschnitte, identische linke Kanten, Werte unterhalb der Labels, 14/16-px-Hierarchie sowie `justify-self: start` und `text-align: left`. Die Gesamtsuite umfasst 634 bestandene Tests und 8 uebersprungene optionale PostgreSQL-Tests; Local-only ist erfolgreich. Der globale Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Client-/Server-Produktionsbuild ist erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Client-Delete als Textbutton vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Die rechte Mandantenaktion ist ein normaler umrandeter `Delete client`-Button mit destruktivem Hoverzustand. Sie enthaelt weder Papierkorb-SVG noch Bild, Iconklasse oder Pseudoelement und folgt damit derselben verbindlichen Textbuttonregel wie Scan- und Baseline-Loeschaktionen.
- Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Eingeklappte Timeslot-Standardansicht vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Beim Oeffnen eines bestehenden Mandanten bleiben alle Timeslot-Details standardmaessig geschlossen. Die bisherige Vorauswahl des neuesten Timeslots bleibt bewusst erhalten und ist weiterhin am Checkboxzustand sichtbar; nur die ScanRun-Tabelle wird nicht automatisch eingeblendet. Manuelles Auf- und Einklappen sowie Auswahl-, Import-, Open- und Delete-Workflows bleiben unveraendert.
- Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Nachgeschaerftes ScanRun-Spaltenraster vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Der Scannername behaelt seine 16-px-Inhaltstypografie. Die rein beschreibende Datei-/Format-Metazeile darunter verwendet nun die kompaktere Labelgroesse. Zugleich wird die Scan-Spalte auf eine feste sinnvolle Mindestbreite begrenzt und die Imported-Spalte von 104 auf 136 px erweitert; damit beginnt der Importzeitpunkt weiter links und besitzt mehr Raum fuer Datum und Uhrzeit, ohne Status oder Delete zu veraendern.
- Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Vollbreites Remarks-Langtextfeld vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Im Bearbeitungsmodus nutzt das Remarks-Textarea die gesamte Breite der maximal 794 px breiten Client-Dokumentflaeche. Die deklarierte Zeilenzahl steigt von 5 auf 10 und die Mindesthoehe von vier auf acht zentrale 32-px-Rastereinheiten; vertikales manuelles Vergroessern bleibt moeglich. Name und Consultant behalten ihre kompakten einzeiligen Eingaben.
- Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests und 8 uebersprungene optionale PostgreSQL-Tests sowie Local-only und Client-/Serverbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Daten-, API-, Persistenz- oder Schemaaenderung.

Excel-artige Result-Spaltenbreiten vom 2026-08-22 (Phase-7-Praesentationsfunktion):

- Ausschliesslich im maximierten Result tragen alle gemeinsamen `rich-text-table`-Tabellen greifbare Spaltentrenner zwischen den Kopfzellen. Pointer-Ziehen veraendert die jeweils links liegende Spaltenbreite; Doppelklick misst den laengsten ungebrochenen Inhalt der Spalte und passt sie innerhalb sicherer 72-/720-px-Grenzen an. Nach einer manuellen Anpassung darf die Tabelle breiter als das Fenster werden und bleibt ueber ihren vorhandenen horizontalen Scrollcontainer erreichbar.
- Derselbe wiederverwendbare React-Baustein versorgt verknuepfte Ergebnisblaetter und Markdown-Ergebnistabellen. Normal grosse Result-Fenster erhalten weder Griffe noch veraenderte Tabellenbreiten. Die Trenner sind als vertikale Separatoren fokussierbar; Pfeiltasten verschieben in 16-px-Schritten, Enter fuehrt Auto-Fit aus. Die Breiten sind reiner lokaler UI-Zustand und veraendern keine importierten oder persistierten Werte.
- Drei fokussierte Suites mit 28 Tests und die Gesamtsuite mit 637 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz- oder Schemaaenderung.

Spaltenbreiten in allen frei stehenden Results vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Die neuere Nutzervorgabe erweitert die Spaltengriffe vom ausschliesslich maximierten Zustand auf jede frei stehende Result-Variante. Herausgezogene, normal grosse, manuell skalierte und maximierte Fenster erlauben Pointer-Ziehen, Doppelklick-Auto-Fit und die vorhandene Tastaturbedienung.
- Nur ein weiterhin im Findings-Cluster eingereihtes Result sowie dessen minimierte Slots bleiben ohne Spaltengriffe. Die Freigabe folgt damit nicht der Fenstergroesse, sondern der bestehenden Clusterzugehoerigkeit; das Herausziehen oder Fensterskalieren loest bereits ueber den vorhandenen `detached`-Zustand aus dem Cluster.
- Drei fokussierte Suites mit 32 Tests und die Gesamtsuite mit 640 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.

Kompakte Ausgangsbreite maximierter Result-Tabellen vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Ein maximiertes Result vergroessert nur die Arbeitsflaeche, nicht mehr automatisch jede enthaltene Tabelle. Vor einer manuellen Spaltenanpassung folgt die Tabelle ihrer ungebrochenen intrinsischen Inhaltsbreite und bleibt links ausgerichtet; sie wird nicht auf die volle Fensterbreite gestreckt.
- Tabellen, deren notwendige Breite den sichtbaren Bereich ueberschreitet, bleiben ueber den vorhandenen horizontalen Scrollcontainer erreichbar. Nach einer manuellen Breitenanpassung gilt weiterhin die explizite Nutzerbreite statt der kompakten Ausgangsregel.
- Zwei fokussierte Suites mit 27 Tests und die Gesamtsuite mit 642 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.

Nicht abschneidbarer Work-Kopf vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Die erste Work-Kopfzeile schuetzt Buttons und gruppierte Controls vor Flex-Schrumpfung: `My Workspace` besitzt eine einzeilige Mindestbreite, View-Tabs sowie Actionlist-Exportgruppe behalten ihre Inhaltsbreite und sichtbaren Aussenkanten. Wenn der Viewport ausnahmsweise schmaler als die vollstaendige Werkzeugleiste ist, bleibt die Zeile horizontal erreichbar, statt Controls innerhalb des statischen Kopfes unsichtbar abzuschneiden.
- Die Profil- und Datenprojektion fuer dynamische Filter ist unveraendert; Maester zeigt weiterhin nur seine tatsaechlich angebotenen Facetten, umfangreichere Werkzeuge entsprechend mehr. Zwei fokussierte Layouttests sichern sowohl die Nicht-Schrumpfregeln als auch den unveraenderten `SearchFilterBar`-Pfad.
- Die Gesamtsuite umfasst 639 bestandene Tests und 8 uebersprungene optionale PostgreSQL-Tests; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Filter-, Import-, API-, Persistenz- oder Schemaaenderung.

Neu geordnete Client-Aktionen vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- `Open` steht nun im oberen rechten Bereich des linken Timeslot-Navigatorkopfs neben `Back` und damit unmittelbar bei der Auswahl, auf die die Aktion wirkt. Im Lesemodus stehen im rechten Client-Information-Kopf `Delete client` und rechts daneben der gelbe `Edit`-Button. Sobald die Bearbeitung aktiv ist, verschwinden beide und nur `Save` nimmt die bisherige Edit-Position ein; Edit, Save und Delete besitzen dieselbe Mindestbreite.
- Der bisherige Bleistift neben `Client Information` und der separate Delete-Bereich am Dokumentende sind entfernt. Die bestaetigungspflichtige Loeschlogik, Open-Auswahlgrenzen und Stammdaten-Speicherlogik bleiben unveraendert.
- Vier fokussierte UI-Tests sowie die Gesamtsuite mit 639 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only und Client-/Server-Produktionsbuild sind erfolgreich. Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.

Direkte Work-Timeslot-Auswahl vom 2026-08-22 (Phase-7-Praesentationsfunktion):

- Rechts neben der bestehenden Blatt-/Client-Auswahl im Work-Kopf steht nun ein eigener Timeslot-Selector. Er bietet ausschliesslich die im aktiven Mandanten persistierten Assessment-Stichtage sowie `All timeslots` an; ein ausgewaehlter Stichtag laedt ueber den bestehenden `openProject`-Pfad genau die zugeordneten ScanRuns, die Gesamtauswahl weiterhin die vollstaendige Mandantenhistorie.
- Die Optionen werden ueber die vorhandene Same-Origin-API aus Assessment-Historie und Importdateiliste abgeleitet. Import-, Mapping-, Filter-, Persistenz- und Schemalogik bleiben unveraendert; nach Datahub-Aenderungen wird die Liste ueber das bestehende Aenderungsereignis aktualisiert.
- Drei fokussierte UI-Tests, die Local-only-Sicherheitspruefung und der Client-/Server-Produktionsbuild sind erfolgreich. Der Gesamtlauf erreichte 639 bestandene Tests und 8 uebersprungene optionale PostgreSQL-Tests; ein unabhaengiger Result-Fenster-Rendervertrag schlug in diesem Lauf einmal fehl und bestand direkt anschliessend isoliert gemeinsam mit seinen Abhaengigkeiten (16 von 16). Der globale Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Phase 7 bleibt abgeschlossen.

Direktes Client-Open aus der DataHub-Uebersicht vom 2026-08-22 (Phase-7-Navigationskorrektur):

- Jede reale Client-Karte besitzt unten rechts eine gelbe `Open`-Aktion. Sie oeffnet ohne vorherige Kartenauswahl den neuesten scannergebundenen Timeslot samt seiner vollstaendigen ScanRun-Menge ueber den bestehenden Work-Pfad. Die obere `Manage`-Aktion bleibt getrennt und oeffnet weiterhin die Stammdaten-/Timeslotverwaltung.
- Bei einem Client ohne scannergebundenen Timeslot bleibt `Open` sichtbar, aber mit erklaerendem Titel deaktiviert. Vier fokussierte DataHub-Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; keine API-, Persistenz-, Schema- oder Datenänderung. Phase 7 bleibt abgeschlossen.

Vier-Quadrate-Fortschrittsindikator vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Fortschritts-Pop-ups des Importworkflows verwenden keinen rotierenden Kreis mehr. Vier kleine Quadrate liegen oben, rechts, unten und links auf einer gedachten Kreisbahn; genau eine rote Markierung wird schrittweise im Uhrzeigersinn weitergeschaltet.
- Der vorhandene Statuscontainer und seine Texte bleiben unveraendert. Bei systemweit reduzierter Bewegung stoppt die Animation und zeigt einen statischen roten Zustand. Fuenf fokussierte Tests und der Client-/Server-Produktionsbuild sind erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung.

Rahmenloser Duplicate-Hinweis vom 2026-08-22 (Phase-7-Praesentationskorrektur):

- Die Dateivorschau im Import-Bestaetigungsdialog verwendet keine umrandeten Karten oder Statuspills mehr. Checkbox, Dateiinformationen, Mappingbestaetigung und Footeraktionen bleiben funktional unveraendert; flache Eintraege werden hoechstens durch eine Haarlinie voneinander getrennt.
- Exakte und moegliche Dubletten erscheinen unter der englischen Ueberschrift `Duplicate found` als mindestens 16 px grosser, automatisch umbrechender Fliesstext. Dateiname, Hash und Hinweise koennen die Dialogbreite nicht mehr vergroessern; die Vorschau scrollt nur vertikal.
- Sechs fokussierte Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Keine Import-, API-, Persistenz-, Schema- oder Datenänderung; Phase 7 bleibt abgeschlossen.

Timeslot-getrennter Work-Zustand vom 2026-08-22 (Phase-7-Zustandskorrektur):

- Der Client bleibt der uebergeordnete Datenrahmen; der in Work gewaehlte Timeslot ist die lokale Arbeitsgrenze. Snapshot-Lesezeichen sowie My-Workspace-Markierungen/Reviews werden unter einem stabilen Schluessel aus Client-ID und vollstaendiger sortierter ScanRun-Menge gespeichert. Zwei Timeslots desselben Clients teilen diese lokalen Arbeitszustaende damit nicht mehr.
- Beim Timeslot-Wechsel werden Suche, Facetten und Workspaceansicht wie bisher zurueckgesetzt, der Statusfilter nun jedoch aus dem Profil des neu geladenen Toolsets statt aus dem vorherigen Stand uebernommen. Ein gemischtes Aggregat vereinigt die Statusfilter der tatsaechlich enthaltenen Werkzeugprofile; ein Blattwechsel setzt weiterhin die exakten Defaults des einzelnen Blattwerkzeugs neu. Dynamische Feldfacetten werden ausschliesslich aus den im gewaehlten Stand vorhandenen Daten abgeleitet.
- 24 fokussierte Tests fuer Scope, Timeslot-Auswahl, Snapshots, Workspace, dynamische Facetten und gemischte Toolprofile sind erfolgreich. Der Produktionsbuild ist derzeit unabhaengig hiervon durch bereits vorhandene fehlende Graph-Filtervariablen in `ObsidianGraphView.tsx` blockiert. Keine Import-, API-, Backend-, Persistenzschema- oder Datenbankaenderung; die Trennung betrifft ausschliesslich lokalen UI-Zustand und Profilkomposition.

Timeslot-getrennte Result-DB vom 2026-08-22 (Phase-7-Zustands- und Querykorrektur):

- Der aktive Timeslot wird ueber seine vollstaendige ScanRun-Menge aus Work bis in Result-DB, Facettenabfrage, Same-Origin-API und Repository weitergereicht. Resultliste, Trefferzahl und Filterwerte entstehen damit ausschliesslich aus Findings dieses Stands. `All timeslots` bleibt als ausdruecklicher Aggregatmodus ohne ScanRun-Filter erhalten.
- Der Unified-Result-Queryvertrag wurde additiv um wiederholbare `scanRunIds` erweitert. Lokale Projektion und PostgreSQL wenden die Menge gemeinsam mit dem Clientfilter an; dadurch steht derselbe eindeutige Kontext spaeter auch einer LLM-Anreicherung zur Verfuegung, ohne Client und Stichtag zu vermischen.
- 22 fokussierte Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Die Gesamtsuite umfasst 647 bestandene Tests sowie 8 uebersprungene optionale PostgreSQL-Tests; Local-only ist gruen, der globale Designcheck bleibt ausschliesslich an den zwei unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Migration und keine Realdatenpruefung; Phase 7 bleibt abgeschlossen.

Verbindlicher aktiver Timeslot vom 2026-08-22 (neuere Phase-7-Zustandshaertung):

- Die ausdrueckliche Nutzerkorrektur loest den zuvor angebotenen Client-Aggregatmodus fuer die normalen Arbeitsansichten ab. Bei einem geoeffneten Client ist die konkrete ScanRun-Menge eines Timeslots der einzige fachliche Scope fuer Work, Graph, Dashboard und Result DB. Der Work-Selector bietet deshalb keinen `All timeslots`-Eintrag mehr und waehlt ohne vorhandenen Scope automatisch den neuesten scannergebundenen Timeslot.
- Result DB und Graph verhalten sich bei einem Client ohne aktive ScanRun-Menge konservativ: Sie zeigen keine projektweite Ergebnismenge beziehungsweise keinen aggregierten Graphen, sondern fordern eine Timeslot-Auswahl an. Datenaktualisierungen am bereits aktiven Client bewahren dessen ScanRun-Scope statt ihn implizit auf das gesamte Projekt zurueckzusetzen.
- Der bestehende API-/Repository-Vertrag mit wiederholbaren `scanRunIds` bleibt unveraendert die technische Querygrenze. Dashboard, Work und Graph lesen den bereits timeslot-begrenzt geladenen Workspace; Result DB wendet dieselbe Menge serverseitig auf Zeilen und Facetten an.
- Sechs fokussierte Suites mit 21 Tests sowie der Gesamtlauf mit 650 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind erfolgreich. Local-only und Client-/Server-Produktionsbuild sind gruen. Der bekannte Designcheck-Befund bleibt ausschliesslich auf `datahub-redesign.css` Zeilen 39 und 42 begrenzt. Keine Migration, Schemaaenderung oder Realdatenpruefung; Phase 7 bleibt abgeschlossen.

Nur erreichbare Filterwerte vom 2026-08-22 (Phase-7-Filterkorrektur):

- Work- und Result-DB-Facetten geben nur Werte mit mindestens einem Treffer unter Client, aktivem Timeslot, Blatt, Suche und den jeweils anderen aktiven Filtern aus. Die betrachtete Facette nimmt ihren eigenen Filter bei der Neuberechnung aus, damit zwischen weiterhin erreichbaren Alternativen gewechselt werden kann.
- Wird eine Work-Auswahl durch einen anderen Filter unmoeglich, wird der unsichtbar gewordene Restfilter automatisch entfernt; dasselbe gilt fuer einen nicht mehr erreichbaren Statusfilter. Numerische und Datumsbereiche behalten ihre vorhandene Eingabelogik, weil sie keine diskreten Nullwertoptionen ausgeben.
- 22 fokussierte Tests, der vollstaendige Client-/Server-Produktionsbuild, 650 Standardtests und Local-only sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen. Das geschrumpfte Radiusbudget ist festgeschrieben. Der Designcheck bleibt ausschliesslich an den zwei bekannten unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Datenänderung; Phase 7 bleibt abgeschlossen.

Abnahmekriterien:

- Purple-Knight-Filter benÃ¶tigen keine fest verdrahtete UI-Sonderlogik.
- Ungeeignete Freitextfelder erzeugen keine unbrauchbaren Filterlisten.
- Importwarnungen und Mapping-Konfidenzen sind sichtbar.

### Phase 8 â€“ Vergleichsengine

Status: abgeschlossen

Ziele:

- Findings Ã¼ber Scan-LÃ¤ufe zuverlÃ¤ssig zuordnen.
- Unsichere Ãœbereinstimmungen von sicheren Treffern unterscheiden.

Matching-Reihenfolge:

1. Tool- und Regel-ID
2. Control- oder Framework-ID
3. Regel-ID und betroffenes Objekt
4. normalisierte Merkmalskombination
5. unsicherer Ã„hnlichkeitsvorschlag

Ergebnisse:

- neu
- weiterhin vorhanden
- behoben
- wieder aufgetreten
- Schweregrad geÃ¤ndert
- Status oder Evidenz geÃ¤ndert
- mÃ¶glicherweise identisch
- nicht vergleichbar

Verifizierter Abschlussstand vom 2026-07-17:

- ScanRunComparison ist ein separates versioniertes Ergebnis und verÃ¤ndert weder Finding-Vorkommen noch Original- oder Reviewdaten.
- Bereits bestÃ¤tigte lokale Regeln und gemeinsame kanonische Definitionen werden vor neu berechneten SchlÃ¼sseln berÃ¼cksichtigt; danach folgen eindeutige Tool-/Regel-, Framework-/Control-, Regel-/Asset- und Merkmalskombinationen.
- Eine Matchingstufe ordnet nur beidseitig eindeutige Kandidaten automatisch zu; doppelte IDs oder Controls werden nicht willkÃ¼rlich aufgelÃ¶st.
- Neu, weiterhin vorhanden, behoben, wieder aufgetreten, mÃ¶glicherweise identisch und nicht vergleichbar werden einschlieÃŸlich zusammengefasster ZÃ¤hlwerte ausgegeben.
- Ã„nderungen an Severity, Status, Score, betroffenem Objekt und Evidenz werden getrennt und reihenfolgeunabhÃ¤ngig erkannt.
- Wiederauftreten wird Ã¼ber Ã¤ltere LÃ¤ufe desselben Assessments erkannt, wenn das Finding im direkten Basislauf fehlt.
- TextÃ¤hnlichkeit erzeugt ausschlieÃŸlich einen Vorschlag mit BenutzerbestÃ¤tigungspflicht und niemals automatisch eine gemeinsame IdentitÃ¤t.
- BestÃ¤tigte VorschlÃ¤ge kÃ¶nnen als serialisierbare LocalComparisonRule erzeugt und in spÃ¤teren Vergleichen wiederverwendet werden.
- Die Ergebnisreihenfolge ist stabil und unabhÃ¤ngig von der Arrayreihenfolge des Eingabemodells.
- Unterschiedliche Assessments und nicht ausreichend vergleichbare Werkzeugdaten werden sichtbar diagnostiziert.
- Algorithmus, Sicherheitsgrenzen und PersistenzÃ¼bergang sind in docs/COMPARISON_ENGINE.md dokumentiert.
- 32 Testdateien mit 85 Tests, Local-only-PrÃ¼fung und Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- Vergleichsergebnisse sind reproduzierbar.
- Unsichere Matches werden nicht automatisch als identisch gespeichert.
- BenutzerbestÃ¤tigungen kÃ¶nnen als lokale Mappingregel wiederverwendet werden.

### Phase 9 â€“ Fachliche Persistenzschnittstelle

Status: abgeschlossen

Ziele:

- Fachlogik von konkreter Datenbank und Transporttechnologie trennen.

BenÃ¶tigte Operationen:

- Projekte und Assessments verwalten
- Importe starten, abschlieÃŸen und zurÃ¼ckrollen
- Findings und Vorkommen speichern und abfragen
- Reviews aktualisieren
- Profile und bestÃ¤tigte Mappings verwalten
- Vergleiche laden und speichern
- Daten exportieren und kontrolliert lÃ¶schen

Verifizierter Abschlussstand vom 2026-07-17:

- AssessorRepository definiert eine asynchrone, transport- und datenbankunabhÃ¤ngige Grenze fÃ¼r Projekte, Assessments, Findings, Reviews, Profile, Mappingregeln, Vergleiche, Export und LÃ¶schung.
- LocalAssessorRepository dient als lokale In-Memory-Referenzimplementierung und ausfÃ¼hrbarer Vertrag fÃ¼r spÃ¤tere Backend- und PostgreSQL-Adapter.
- Eine Importsitzung umfasst genau einen Scan-Lauf mit Dateien, Tabellen, Definitionen, Vorkommen, Evidenz und Diagnosen; gestagete Daten bleiben bis zum Commit unsichtbar.
- Commit validiert alle Sitzungsreferenzen und das vollstÃ¤ndige kanonische Assessment-Modell, bevor der Zustand atomar ersetzt wird; Rollback und Validierungsfehler hinterlassen keine Teilimporte.
- Repository-Revisionen verhindern, dass ein veralteter paralleler Import zwischenzeitliche Ã„nderungen Ã¼berschreibt.
- Reviewupdates verwenden optimistische Revisionen; veraltete Schreibversuche werden als Konflikt abgewiesen.
- Profilregistrierungen, bestÃ¤tigte lokale Mappingregeln und Vergleichsergebnisse werden Ã¼ber dieselbe fachliche Grenze verwaltet.
- Projektexporte enthalten alle projektbezogenen Fachobjekte; kaskadierende LÃ¶schung verlangt die exakte Projekt-ID und eine ausdrÃ¼ckliche BestÃ¤tigung.
- Eine automatisierte ArchitekturprÃ¼fung verhindert SQL oder Datenbankclientimporte in React-, Komponenten- und Featuremodulen.
- Die bestehende lokale UI- und Snapshotablage bleibt wÃ¤hrend des Ãœbergangs unverÃ¤ndert; die Referenzimplementierung ist bewusst noch keine dauerhafte Produktdatenbank.
- VertrÃ¤ge, Transaktionsgrenzen, Konfliktregeln und BackendÃ¼bergang sind in docs/PERSISTENCE_BOUNDARY.md dokumentiert.
- 33 Testdateien mit 91 Tests, Local-only- und ArchitekturprÃ¼fung sowie Produktionsbuild laufen erfolgreich.

Abnahmekriterien:

- React fÃ¼hrt kein SQL aus.
- Fachlogik hÃ¤ngt weder von SQLite noch von PostgreSQL ab.
- Transaktionsgrenzen eines Imports sind definiert.

### Phase 10 â€“ Lokales Backend

Status: abgeschlossen

Ziele:

- Die Zielarchitektur zunÃ¤chst vollstÃ¤ndig auf dem Entwicklungsrechner betreiben.
- React schrittweise von lokalen Aufrufen auf eine Backend-Schnittstelle umstellen.

Lokaler Aufbau:

```text
Browser
  â†“ http://localhost
ASSESSOR-Backend
  â†“
lokale Datenbank
```

Backend-Verantwortung:

- Dateiannahme und Validierung
- Importsteuerung
- Parsing und Normalisierung
- Persistenz und Vergleiche
- Reviews und Exporte
- strukturierte Fehler und Audit-Ereignisse

Verifizierter Abschlussstand vom 2026-07-17:

- Ein Node.js-Backend auf Basis der eingebauten HTTP-Laufzeit liefert die gebaute React-App und `/api/v1` vom selben Ursprung aus; standardmÃ¤ÃŸig wird ausschlieÃŸlich an `127.0.0.1:4173` gebunden.
- Die versionierte API bildet Projekte, Assessments, Findings, Reviews, Profile, Mappingregeln, Vergleiche, Export, kontrollierte LÃ¶schung und atomare Importsitzungen auf `AssessorRepository` ab.
- CSV, JSON, HTML, XML, XLSX und XLS kÃ¶nnen Ã¼ber einen validierten Same-Origin-Endpunkt mit der vorhandenen plattformneutralen Importengine serverseitig verarbeitet werden.
- Der Node-Markupadapter fÃ¼hrt importierte Skripte nicht aus, entfernt aktive HTML-Inhalte und weist fehlerhaftes XML kontrolliert ab.
- React prÃ¼ft den Backendstatus und verwendet bei Verbindung den gekapselten API-Client; Browser-/Tauri-Parsing bleibt wÃ¤hrend der Migration als Fallback erhalten.
- Strukturierte Fehler enthalten Code, Meldung und Request-ID. Schreibzugriffe benÃ¶tigen eine besondere Request-Kopfzeile und werden bei fremdem Browser-Ursprung abgewiesen.
- Sicherheitsheader, GrÃ¶ÃŸen- und FormatprÃ¼fung, ein inhaltsfreies Audit-Ereignisprotokoll sowie Same-Origin-Architekturregressionen sind automatisiert getestet.
- Phase 10 verwendet zunÃ¤chst die flÃ¼chtige Referenzimplementierung; Phase 11 ergÃ¤nzt PostgreSQL und Migrationen Ã¼ber dieselbe Grenze, ohne React oder Fachlogik an die Datenbank zu koppeln.
- Architektur, Startbefehle, Datenfluss und Ãœbergangsgrenzen sind in `docs/LOCAL_BACKEND.md` dokumentiert.
- 36 Testdateien mit 101 Tests, Same-Origin-/Local-only-SicherheitsprÃ¼fung, Produktionsbuild und gestarteter Browser-/Health-PrÃ¼fung laufen erfolgreich.

- Nachhärtung vom 2026-08-02: Client, Server und Tests besitzen eigenständige `vite.client.config.ts`, `vite.server.config.ts` und `vitest.config.ts` mit getrennten Cache- und Outputpfaden. Alle npm-Skripte wählen ihre Konfiguration explizit; `vite.config.ts` ist nur ein clientseitiger Kompatibilitätsalias für Werkzeuge ohne `--config`. Ein Architekturtest schützt Skriptrouting, Zuständigkeitsgrenzen, `noEmit` und die vollständige Einbeziehung von TS- und TSX-Tests. `npm test` und `npm run build` liefen parallel erfolgreich; 105 Testdateien mit 498 Standardtests bestanden, 7 optionale PostgreSQL-Tests wurden erwartungsgemäß übersprungen. Local-only- und Designprüfung sowie die TypeScript-Prüfung aller vier Konfigurationsdateien waren erfolgreich.
- Nachhärtung vom 2026-08-02: `npm run dev` ist der verbindliche lokale Entwicklungsstart für Backend und Client. Der plattformneutrale Node-Starter prüft `/api/v1/health`, baut und startet ein fehlendes Backend ausschließlich auf `127.0.0.1:4173` und startet den Client erst nach erfolgreicher Health-Prüfung auf `127.0.0.1:5173`; `npm run dev:client` bleibt als ausdrücklich client-only benannter Spezialweg erhalten. Der Architekturvertrag deckt Startreihenfolge, Adressen und dedizierte Konfigurationen ab. `npm test` und `npm run build` liefen parallel erfolgreich; 105 Testdateien mit 499 Standardtests bestanden, 7 optionale PostgreSQL-Tests wurden erwartungsgemäß übersprungen.

Abnahmekriterien:

- Die Anwendung funktioniert im normalen Browser Ã¼ber `localhost`.
- Kernfunktionen hÃ¤ngen nicht mehr von Tauri-Kommandos ab.
- Tauri kann optional als lokale HÃ¼lle weiterbestehen.

### Phase 11 â€“ PostgreSQL

Status: abgeschlossen

Ziele:

- Dauerhafte, mehrbenutzerfÃ¤hige Speicherung einfÃ¼hren.

Anforderungen:

- versionierte Datenbankmigrationen
- FremdschlÃ¼ssel und IntegritÃ¤tsregeln
- Transaktionen pro Import
- geeignete Indizes
- Volltextsuche
- Backup- und Restore-Verfahren
- nachvollziehbare LÃ¶schung

Verifizierter Abschlussstand vom 2026-07-17:

- `PostgresAssessorRepository` implementiert den vollstÃ¤ndigen fachlichen Repository-Vertrag fÃ¼r Projekte, Assessments, atomare Importe, Findingabfragen, Reviews, Profile, Mappingregeln, Vergleiche, Export und kontrollierte LÃ¶schung.
- Das relationale Schema erzwingt PrimÃ¤rschlÃ¼ssel, FremdschlÃ¼ssel, Checks, kaskadierende LÃ¶schregeln, eindeutige Scan-Reihenfolgen und optimistische Reviewrevisionen; vollstÃ¤ndige versionierte Fachobjekte bleiben zusÃ¤tzlich als JSONB erhalten.
- Migrationen sind nummerierte SQL-Dateien, werden per PostgreSQL-Advisory-Lock serialisiert, einzeln transaktional ausgefÃ¼hrt und mit SHA-256-PrÃ¼fsumme in `assessor_schema_migrations` protokolliert.
- Ein Import wird im Prozess gestagt und beim Commit auf genau einer Poolverbindung in genau einer Datenbanktransaktion gespeichert; die gesperrte Repository-Revision verhindert konkurrierendes Ãœberschreiben.
- B-Tree-Indizes decken Beziehungen und Filter ab; gespeicherte `tsvector`-Dokumente und GIN-Indizes ermÃ¶glichen Volltextsuche, ein zusÃ¤tzlicher GIN-JSONB-Index unterstÃ¼tzt strukturierte Zusatzfelder.
- Das Backend wÃ¤hlt PostgreSQL Ã¼ber `ASSESSOR_DATABASE_URL`, fÃ¼hrt Migrationen beim Start aus und meldet die aktive Persistenz im Health-Endpunkt. Ohne URL bleibt der explizite In-Memory-Entwicklungsmodus; Verbindungsfehler fÃ¼hren nicht zu einem stillen Fallback.
- Docker Compose stellt PostgreSQL 16 lokal ausschlieÃŸlich auf Loopback mit persistentem Volume und nicht versionierter Passwortdatei bereit.
- `pg_dump` im Custom-Format und `pg_restore` wurden praktisch gegen eine getrennte Wiederherstellungsdatenbank geprÃ¼ft; Migrationstabelle und persistierte Profilregistrierungen wurden nach dem Restore verifiziert.
- Setup, Migrationen, Suche, Backup, Restore und LÃ¶schung sind in `docs/POSTGRESQL.md` dokumentiert.
- 40 Testdateien mit 108 Tests einschlieÃŸlich realem PostgreSQL-16-Integrationstest, Same-Origin-/Local-only-SicherheitsprÃ¼fung, Produktionsbuild und gestartetem PostgreSQL-Backend laufen erfolgreich.

Abnahmekriterien:

- Fehlgeschlagene Importe hinterlassen keine TeilbestÃ¤nde.
- Mehrere Scan-LÃ¤ufe bleiben sauber getrennt.
- Backup und Wiederherstellung sind praktisch getestet.

### Phase 12 â€“ Mehrdatei-Importworkflow

Status: abgeschlossen

Ziele:

- Mehrere heterogene Dateien gemeinsam in ein Assessment laden.

Ablauf:

1. Dateien auswÃ¤hlen
2. technische VorprÃ¼fung
3. Quellen und Tabellen erkennen
4. Erkennungsergebnis anzeigen
5. unsichere Zuordnungen bestÃ¤tigen
6. Import transaktional ausfÃ¼hren
7. Importbericht anzeigen
8. Findings und Vergleiche Ã¶ffnen

Verifizierter Abschlussstand von Phase 12 am 2026-07-17:

- Der direkte Mehrdateiimport wurde durch einen Vorschau-, Freigabe- und Berichtsworkflow ersetzt; das aktuell geÃ¶ffnete Projekt Ã¤ndert sich erst nach erfolgreichem Abschluss.
- CSV, JSON, XML, HTML, XLSX und XLS sowie unterschiedliche erkannte Werkzeuge kÃ¶nnen gemeinsam vorbereitet und als heterogenes Assessment gespeichert werden.
- Jede Datei wird unabhÃ¤ngig technisch geprÃ¼ft und geparst. Fehler bleiben als kontrollierte, nicht ausgewÃ¤hlte Vorschauzeilen sichtbar und verhindern nicht die Verarbeitung anderer Dateien.
- Vorschau und Importbericht zeigen Format, Werkzeug, Konfidenz, Tabellen, DatensÃ¤tze, Warnungen, nicht zugeordnete Felder, offene MappingbestÃ¤tigungen, Fehler, Dubletten und SHA-256.
- Unsichere automatische Quellen-, Tabellen- und Feldzuordnungen mÃ¼ssen vor dem Import der betroffenen Datei ausdrÃ¼cklich bestÃ¤tigt werden.
- SHA-256 wird aus den tatsÃ¤chlichen Bytes berechnet. PostgreSQL-Migration 002 speichert Hash, Dateimetadaten, ersten und letzten Import sowie WiederholungszÃ¤hler; der Browserfallback besitzt eine klar gekennzeichnete lokale Historie.
- Der Server gleicht Abschlussauswahlen Ã¼ber eindeutige Vorschau-IDs und unverÃ¤nderte Metadaten gegen seine eigene geparste Vorschau ab; manipulierte oder abgelaufene AbschlÃ¼sse werden abgewiesen.
- BestÃ¤tigte Dateien werden in das kanonische Projekt-, Assessment-, Scan-Lauf-, Datei-, Tabellen-, Finding-, Evidenz- und Diagnosemodell Ã¼berfÃ¼hrt.
- `commitCanonicalImport` speichert kanonisches Modell und Fingerprints in einem Repository-Vorgang; PostgreSQL verwendet dafÃ¼r genau eine Transaktion und eine optimistisch gesperrte Repository-Revision.
- Ein dauerhafter Importbericht wird lokal fÃ¼r die letzte Sitzung abgelegt; Details und Betriebsgrenzen stehen in `docs/IMPORT_WORKFLOW.md`.
- 44 Testdateien mit insgesamt 119 Tests, Local-only-SicherheitsprÃ¼fung, Produktionsbuild und echter PostgreSQL-16-Integration sind erfolgreich verifiziert.
Nachtraeglicher verifizierter UI-Integrationsstand vom 2026-08-04 (Status von Phase 8 und 12 bleibt abgeschlossen):

- Der Datahub projiziert Mandanten horizontal und ihre persistierten Scan-Durchgaenge chronologisch als anklickbare Datumsstaende. Datumsaktion und Vergleichsauswahl sind getrennt: ein Klick oeffnet ausschliesslich den gewaehlten Scanstand in Work, zwei Checkboxen starten den Vergleich; maximal zwei Staende desselben Mandanten sind gleichzeitig auswaehlbar.
- Vier Regler werden als SVG-Donut-Zustandsanzeigen fuer offene Abweichungen, behobene Abweichungen, kritische Abweichungen und gepruefte Zielbefunde gerendert. Die Werte stammen aus dem bestehenden kanonischen Vergleichs- und Reviewmodell, nicht aus React-seitiger Scannerlogik.
- Persistierte Assessments desselben Mandanten werden fuer den Vergleich ausschliesslich read-only in ein virtuelles Vergleichsmodell ueberfuehrt. Originalmodelle, ScanRuns und Persistenz werden nicht veraendert; unterschiedliche Mandanten werden abgewiesen und unsichere Aehnlichkeiten bleiben `possibly-identical` mit Bestaetigungsbedarf.
- MITRE- und Microsoft-Baselinebereiche verwenden die rackartige Referenzgestaltung; bestehende Upload-, Katalog- und Wartungsfunktionen bleiben erhalten. Responsive Regeln stellen Donuts und Rack-Inhalte am kompakten Breakpoint einspaltig dar.
- Verifikation nur mit synthetischen beziehungsweise inhaltsfreien Signalen: `npm test` mit 591 bestandenen und 8 uebersprungenen Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Isolierter Browser-Preview: vier Donuts, vier Rackmodule, kein horizontaler Seiten-Overflow in Desktop- und kompakter Ansicht. Keine Migration oder Persistenzaenderung; reale Mandanteninhalte wurden nicht inspiziert.

Korrigierter und verifizierter Timeslot-Stand vom 2026-08-05 (praezisiert den UI-Integrationsstand vom 2026-08-04; Status von Phase 8 und 12 bleibt abgeschlossen):

- Ein fachlicher Datumsstand ist ein vollstaendiger Assessment-Timeslot eines Mandanten. Scannerimporte wie CIS-CAT, PingCastle, PurpleKnight und Maester sind getrennte `ScanRun`-Quellen innerhalb dieses Timeslots; ein GPO-Backup ist eine weitere, direkt an denselben Assessment-Timeslot gebundene Quelle und wird nicht als kuenstlicher Scannerlauf modelliert.
- Neue Timeslots besitzen einen expliziten fachlichen Stichtag `Assessment.effectiveAt`. Importvorschau, Abschluss und GPO-Submission bewahren `targetAssessmentId`; wiederholte Quellenimporte ergaenzen das bestehende Assessment mit fortlaufenden ScanRun-Sequenzen statt ein neues Assessment anzulegen.
- Die Datahub-Historie rendert genau eine Zeile je Timeslot und oeffnet beziehungsweise vergleicht alle darin enthaltenen ScanRuns gemeinsam. Mehrteilige Dateien desselben Scannerlaufs zaehlen als eine Quelle. Bestehende Legacy-Imports ohne `effectiveAt` werden fuer die Darstellung nach ihrem Quellkalendertag zusammengefuehrt; dadurch bilden die vier Scannerlaeufe vom 22.07.2026 zusammen mit dem vorhandenen GPO-Backup genau einen historischen Stand.
- Ein neuer Bewertungsstand wird im Mandanteneditor mit Datum angelegt und danach als aktiver Timeslot ausgewaehlt. Scanner- und GPO-Uploads sind erst mit einem aktiven Timeslot verfuegbar und werden serverseitig erneut auf denselben Mandanten geprueft.
- Verifikation ausschliesslich mit synthetischen Daten: `npm test` mit 595 bestandenen und 8 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration; der fachliche Stichtag und die GPO-Zuordnung werden im vorhandenen versionierten JSONB-Datensatz bewahrt. Reale Mandanteninhalte wurden nicht inspiziert.
Nachtraegliche verifizierte Referenzlayout-Korrektur vom 2026-08-05:

- Die allgemeine Datahub-Begrenzung auf 1180 px wird nicht mehr durch eine spezifischere 100-Prozent-Regel ueberschrieben. MITRE- und Baseline-Racks bleiben dadurch mittig begrenzt.
- Mandantenhistorie und Zustandsregler verwenden `max-content` mit `max-width: 100%` und stehen mittig. Ein einzelner Mandant belegt 190 px plus 62 px fuer die Hinzufuegen-Aktion statt eine leere Vollbreitenmatrix zu erzeugen; die vier Donut-Zustaende und der Vergleich bilden einen kompakten 904-px-Rackblock.
- Bei mehreren Mandanten bleibt die Historie horizontal scrollbar; unter 1100 px beziehungsweise 760 px greifen die bestehenden zwei- und einspaltigen Responsive-Regeln.
- Verifikation: `npm test` mit 596 bestandenen und 8 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Eine statische Layoutregression verhindert die erneute Vollbreiten-Ueberschreibung. Keine Daten-, API- oder Persistenzaenderung.
Abschliessende Referenzkorrektur auf ausdruecklichen Bildvergleich vom 2026-08-05 (ersetzt die unmittelbar vorherige kompakte Layoutinterpretation):

- Bild 2 definiert einen vollbreiten Rackaufbau. Alle Datahub-Rackmodule nutzen wieder die verfuegbare Arbeitsbreite; die Mandantenmatrix enthaelt stets acht gleichmaessige sichtbare Slots. Nicht belegte Slots sind ausschliesslich praesentative `Empty`-Spalten und erzeugen keine Projekte oder Persistenzobjekte.
- Rechts folgt eine schmale 66-px-Hinzufuegen-Spalte. Der erste beziehungsweise aktive Mandant und sein aktueller Timeslot sind violett markiert. Jeder Timeslot bleibt fachlich genau eine Zeile mit allen Quellen; die Dreiecksflaeche waehlt fuer den Zwei-Staende-Vergleich, der Datumsklick oeffnet den gesamten Stand.
- Der separate Vergleichskasten wurde aus dem Zustandsrack entfernt. Vier kompakte 270-Grad-Regler stehen links in zwei Paaren mit breitem Zwischenraum und Trennlinie; ihre Werte stammen unveraendert aus dem kanonischen Timeslotvergleich. Bei zwei ausgewaehlten Timeslots startet der Vergleich weiterhin automatisch.
- MITRE- und Baseline-Racks verwenden dieselbe volle Arbeitsbreite. Ab 1100 px beziehungsweise 760 px bleiben die vorhandenen responsiven Umbrueche aktiv; bei einer breiteren Mandantenmatrix scrollt nur deren innerer Bereich horizontal.
- Verifikation: `npm test` mit 596 bestandenen und 8 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Die gezielte Layoutregression sichert Vollbreite, acht Slots, Empty-Platzhalter, aktive Erstspalte, Plusbreite, Reglerpaarabstand und 270-Grad-Bogen. Keine Daten-, API- oder Persistenzaenderung.
Abnahmekriterien:

Verifizierte Mandantendetail-Korrektur vom 2026-08-05 (Status von Phase 12 bleibt abgeschlossen; Phase 13B bleibt in Arbeit):

- Die Detailansicht nach Klick auf einen Mandanten folgt der ausdruecklichen Bildreferenz innerhalb des unveraenderten bisherigen Datahub-Inhaltsrahmens: maximal 1180 px, horizontal zentriert und mit bestehendem Viewer-Inset.
- Sichtbare Fachaktionen sind ausschliesslich Open, Delete, Import Data, GPO Backup Folder und Save. Timeslot-Anlage/-Auswahl, GPO-Statuslisten und das Policy-Analysepanel werden in dieser Detailansicht nicht gerendert.
- Stammdaten enthalten ausschliesslich Name, Consultant und Remarks. Die Scan History zeigt je persistiertem ScanRun File Date, Scan Report, Files, Format, Total Size, Imported und Delete; Originaldateien und Quelldaten bleiben unveraendert.
- Zwei Rackmodule mit insgesamt acht Reglern reproduzieren die Referenz rein praesentativ und sind aria-hidden; sie erzeugen keine Fachwerte und keine Persistenzmutation.
- Verifikation mit inhaltsfreien Signalen: 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Browserpruefung bestaetigt 1180 px Inhaltsbreite, gleiche linke Position und Breite von Kopf, Stammdaten und Historie, zwei Rackmodule, acht Regler, keine Timeslot-/Policy-Steuerung und keinen horizontalen Seiten-Overflow. Reale Mandanteninhalte wurden nicht gelesen oder abgebildet.
Verifizierte zentrierte Datahub-Referenzkorrektur vom 2026-08-05 (Phase 12 UI-Nachhaertung; Phase 13B bleibt in Arbeit):

- Die neue ausdrueckliche Datahub-Bildreferenz ersetzt fuer die Uebersicht die zuvor dokumentierte Vollbreiteninterpretation. Alle vier Rackmodule verwenden denselben maximal 1180 px breiten, horizontal zentrierten Inhaltsrahmen wie die Mandantendetailansicht.
- Die Historie zeigt weiterhin acht sichtbare Mandantenslots plus 66-px-Hinzufuegen-Spalte. `Empty`-Slots und die vier mit Transpose/Detune bezeichneten Regler sind reine Praesentation; Auswahl ueber Dreieck, Oeffnen ueber Datum sowie MITRE-JSON- und Baseline-ZIP-Upload bleiben die einzigen fachlich verdrahteten Funktionen dieser Uebersicht.
- MITRE-Rack, Baseline-Rack und Baselinezeilen folgen der Referenzstruktur und ihren Beschriftungen. Der innere Historienbereich bleibt bei schmaleren Viewports horizontal scrollbar, die Seite selbst laeuft nicht horizontal ueber.
- Verifikation: 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen; Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browsermessung bestaetigt vier deckungsgleiche Racks mit 1179,98 px Breite, acht Mandantenspalten, eine Hinzufuegen-Spalte, vier Regler, neun MITRE-Felder, eine Baseline-Sektion, keine alten Donuts, kein Zusatzmenue und keinen Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung.

Verifizierte Timeslot-Statusanzeige vom 2026-08-05 (Phase 12 UI-Nachhaertung; Phase 13B bleibt in Arbeit):

- Die sechs Referenzdiagramme zeigen Results All, Deviation, Passed, Not Applicable, Not Run und Error fuer den zuletzt angewählten Timeslot des jeweiligen Mandanten. Ein Timeslot mit mehreren Scannerlaeufen wird ueber alle zugehoerigen kanonischen Finding-Vorkommen gemeinsam aggregiert.
- Results All bildet stets 100 Prozent; alle weiteren animierten 270-Grad-Fortschrittsboegen zeigen ihren Anteil an dieser Gesamtzahl. Deviation verwendet das zentrale Abweichungspraedikat, die weiteren Kategorien folgen den kanonischen Outcomes beziehungsweise dem fehlgeschlagenen technischen Ausfuehrungszustand. Originalstatus und Provenienz bleiben unveraendert.
- Blau, Warnorange, Erfolgsgruen, Violett, neutral Grau und Fehlerrot unterscheiden die sechs Boegen ueber bestehende Designtokens. Bei reduzierter Bewegung bleibt der finale Zustand ohne Animation sichtbar. Die mittlere Trennlinie entfaellt; unter 1100 beziehungsweise 760 px brechen die Diagramme auf drei beziehungsweise zwei Spalten um.
- Der neueste Timeslot des aktiven beziehungsweise ersten Mandanten wird beim Laden standardmaessig ausgewaehlt, auch wenn nur ein Stand existiert. Ein zweiter angewählter Stand bleibt fuer den Vergleich moeglich; die Anzeige folgt dem zuletzt angewählten Stand.
- Verifikation: 599 Standardtests bestanden, 8 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen; Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt genau eine Standardauswahl, sechs numerische Werte und Prozentanzeigen, sechs animierte Boegen mit eindeutigen Tokenfarben, Results All bei 100 Prozent, die sechs geforderten Beschriftungen, keine Trennlinie, deckungsgleiche Ausrichtung und keinen Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung.


Verifizierter bindender Donut-Komponentenstandard vom 2026-08-05 (Phase 12 UI-Nachhaertung; Phase 13B bleibt in Arbeit):

- Die ausdrueckliche Referenz ChatGPT Image Aug 5, 2026, 01_12_23 PM.png ist fuer die jetzige und jede kuenftige Donut-Anzeige bindend. Die Datahub-Zeile verwendet sechs gleich breite dunkle Einzelkarten in einem gemeinsamen Rackrahmen, jeweils mit farbigem Kopfstrich, linksbuendigem Titel, grossem 270-Grad-Ring, zentralem Absolutwert und farbigem Prozentwert.
- DonutMetricCard und .donut-metric-rack kapseln Struktur, 700-ms-Animation, sichtbaren Startpunkt bei 0 Prozent, vollstaendigen 270-Grad-Bogen bei 100 Prozent, Rundkappen, Typografie, Abstaende und responsive Raster. Freie lokale SVG-, Gauge- oder Donutvarianten sind im Komponentenvertrag ausgeschlossen.
- Dark- und Lightmode nutzen dieselbe Geometrie und Informationshierarchie. Der Lightmode besitzt eigene helle --donut-*-Flaechen-, Linien-, Text-, Schatten- und kontrastangepasste Statusfarbwerte; Bedeutung und Reihenfolge der sechs Farben bleiben unveraendert.
- Nach dem Gesamtbildabgleich wurde der Standard proportional kompakter skaliert: 196 px Kartenmindesthoehe, maximal 128 px Ring, 8 px Kartenabstand und 12 px Rackinnenabstand sowie entsprechend reduzierte Titel-, Wert- und Prozenttypografie. Der 1180-px-Rahmen, die Sechserausrichtung und alle Funktionswerte bleiben unveraendert.
- Der ausdruecklich vorgegebene Kartenradius und die zwei tokenisierten Tiefenschatten sind eng auf DonutMetricCard und Rack begrenzte Ausnahmen der bisherigen flachen Designsprache. Designvertrag, Skill-Assets und automatisierte Designpruefung dokumentieren und sichern diese Grenze.
- Verifikation: 601 Standardtests bestanden, 8 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen; Local-only- und Designpruefung mit 239 Tokens und 0 rohen Farben sowie Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt sechs gleich breite Karten im 1180-px-Rahmen, Referenzproportionen, grosse Ringe, Kopfstriche, Rundungen, Animationen, eindeutige Farben, Results All bei 100 Prozent, gueltige Theme-Rollen und keinen Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung.
- Der Importbericht zeigt erfolgreiche Dateien, Warnungen, Fehler, Dubletten, nicht zugeordnete Felder und Konfidenzen.
- Einzelne fehlerhafte Dateien kÃ¶nnen kontrolliert behandelt werden.
- Wiederholte Imports sind Ã¼ber Hash und Importmetadaten erkennbar.

### Phase 13 â€“ Sicherheit und Belastbarkeit

Status: abgeschlossen (2026-07-17)

Ziele:

- Nicht vertrauenswÃ¼rdige Dateien und groÃŸe Datenmengen kontrolliert verarbeiten.

MindestmaÃŸnahmen:

- Limits fÃ¼r Datei-, Tabellen-, Zeilen-, Spalten- und ZellgrÃ¶ÃŸen
- Zeit- und Speicherlimits fÃ¼r Parser
- Schutz vor ZIP-Bombs
- keine AusfÃ¼hrung importierter HTML-Inhalte
- sichere XML-Verarbeitung ohne externe EntitÃ¤ten
- keine AusfÃ¼hrung von VBA oder Excel-Formeln
- parametrisierte Datenbankabfragen
- sichere temporÃ¤re Dateien
- Audit-Log
- Sicherheits- und Lasttests

Abnahmekriterien:

- Manipulierte Dateien fÃ¼hren zu kontrollierten Fehlern.
- Ressourcenlimits sind dokumentiert und getestet.
- Das Sicherheitsmodell beschreibt den tatsÃ¤chlichen Datenfluss korrekt.

Verifizierter Abschlussstand von Phase 13 am 2026-07-17:

- Eine zentrale Ressourcenrichtlinie begrenzt Datei, dekodierten Text, Tabellen, Zeilen, Spalten, Zellen, Markup, JSON-Verschachtelung und ZIP-Inhalte vor und nach dem formatspezifischen Parsing.
- Serverseitige Parser laufen in kurzlebigen Workern mit Zeit-, Speicher-, ParallelitÃ¤ts- und Warteschlangengrenzen; Ãœberlastung und AbbrÃ¼che werden als strukturierte Importfehler gemeldet.
- ZIP-Bombs, verschlÃ¼sselte beziehungsweise ausbrechende Archive, ZIP64, eingebettete VBA-Projekte, XML-EntitÃ¤ten und aktive HTML-Inhalte werden kontrolliert abgewiesen oder entfernt.
- Excel-Formeln und VBA werden nicht ausgefÃ¼hrt; spreadsheet-orientierte CSV-Ausgaben neutralisieren Formel-Injection bei unverÃ¤nderten internen Originalwerten.
- Die Datensatznavigation verwendet stabile, memoierte Filterergebnisse und Finding-Karten; verknÃ¼pfte Result-Tabellen werden erst beim Ã–ffnen des Detailbereichs gerendert.
- Der serverseitige Vorschaucache besitzt Zeit-, Anzahl- und Bytegrenzen. Audit-Ereignisse enthalten Dauer und Fehlercode, aber keine Importinhalte.
- Die Importpipeline erzeugt keine temporÃ¤ren Quelldateien; PostgreSQL-Zugriffe bleiben parametrisiert und bestÃ¤tigte Batchimporte atomar.
- Die tatsÃ¤chlichen Grenzen und Betriebsunterschiede sind in `docs/IMPORT_SECURITY_LIMITS.md` und `SECURITY.md` dokumentiert.
- 49 Testdateien mit 139 Tests wurden geprÃ¼ft: 135 Standardtests erfolgreich, 4 PostgreSQL-Tests im Standardlauf erwartungsgemÃ¤ÃŸ Ã¼bersprungen und anschlieÃŸend separat gegen PostgreSQL 16 erfolgreich. Local-only-SicherheitsprÃ¼fung, Client-/Server-Produktionsbuild und gestarteter Worker-API-Smoke-Test waren erfolgreich.

### Phase 13A â€“ Ingestion 2.0 und Profilarchitektur

Status: abgeschlossen

Ziele:

- Die in den Phasen 3 bis 6 begonnene Trennung von technischem Dateiformat, Quellwerkzeug, Reportvariante, fachlicher Beobachtung und kanonischem Finding verbindlich vervollstÃ¤ndigen.
- Einen neuen Dateityp Ã¼ber einen sicheren Formatadapter, ein neues Werkzeug primÃ¤r Ã¼ber ein versioniertes Mappingprofil und eine wesentlich andere Reportstruktur Ã¼ber einen kleinen Source Extractor integrieren.
- Bestehende Scannerimporte und die lokale Anwendung wÃ¤hrend der schrittweisen Umstellung funktionsfÃ¤hig halten.

Verbindliche Pipeline:

```text
Upload
  -> Format-/Container-Erkennung
  -> sicherer Formatadapter
  -> DecodedSourceDocument
  -> Source Extractor oder generischer Fallback
  -> FindingCandidate
  -> Mappingprofil
  -> kanonisches Finding-Modell
```

Architekturgrenzen:

- Formatadapter dekodieren ausschlieÃŸlich technische Inhalte. Sie kennen keine Quellwerkzeuge und erzeugen weder Severity noch Findings.
- `DecodedSourceDocument` unterstÃ¼tzt tabellarische, hierarchische, objektartige und containerbasierte Sichten. Nicht tabellarische Inhalte werden nicht verlustreich in kÃ¼nstliche Tabellen gezwungen.
- Source Extractors sind kleine, explizit registrierte Komponenten fÃ¼r formatspezifische Reportstrukturen. HTML-Selektoren sowie JSON-/XML-Pfade gehÃ¶ren zum Extractor, nicht zum Mappingprofil.
- Mappingprofile ordnen benannte Source-Felder kanonischen Rollen zu und verwenden nur freigegebene Transformationen. Profile sind schema-validiert, versioniert und enthalten keinen dynamischen Code.
- Eine Benutzerangabe zum Werkzeug ist nur ein Erkennungshinweis. Strukturelle Validierung bleibt erforderlich.
- BatchzugehÃ¶rigkeit und Dateiprofil bleiben getrennt. Eine generische Begleitdatei erhÃ¤lt nicht ohne eigene StrukturprÃ¼fung das Mappingprofil des Batch-Werkzeugs.
- Nur stabile native Regelkennungen oder bestÃ¤tigte lokale Regeln erzeugen dauerhafte Finding-IdentitÃ¤ten. TitelÃ¤hnlichkeit bleibt ein Reviewhinweis.
- `ImportedDataset` bleibt vorerst eine UI-KompatibilitÃ¤tsansicht; neue Fachlogik darf nicht davon abhÃ¤ngen.

Umsetzungsschritte:

1. Parallele Erkennungswege zu einer Recognition Engine mit Kandidaten, Evidenz, Konfidenz und BestÃ¤tigungsbedarf zusammenfÃ¼hren.
2. Gemeinsame VertrÃ¤ge fÃ¼r `SourceLocator`, Diagnosen, VerarbeitungsstÃ¤nde und versionierte Provenienz definieren.
3. Formatdetektion um Dateisignatur-, MIME- und Container-Evidenz ergÃ¤nzen; Dateiendung und Client-MIME nicht allein vertrauen.
4. `ImportDocument` kompatibel um ein typisiertes `DecodedSourceDocument` ergÃ¤nzen.
5. Source-Extractor-Registry einfÃ¼hren und Extractors nur ergÃ¤nzen, wenn der generische Strukturadapter nachweislich Inhalte verliert.
6. Extraktionsvarianten und gemeinsame Mappingprofile trennen.
7. Dauerhafte Finding-IdentitÃ¤t ohne unsicheren Titel-Fallback absichern.
8. Allgemeine Importartefakte, versionierte Processing Runs und persistente Jobs in DomÃ¤nenmodell, Repository und PostgreSQL ergÃ¤nzen.
9. Scannerimporte schrittweise migrieren und vollstÃ¤ndig regressionsprÃ¼fen.

Verifizierter Zwischenstand vom 2026-07-20:

- Umsetzungsschritt 1 ist im ersten vertikalen Schnitt umgesetzt: Die Importengine wÃ¤hlt das Laufzeitprofil Ã¼ber das Ergebnis der gemeinsamen Recognition Engine; ein nur Ã¼ber den Dateinamen erkanntes oder mehrdeutiges Werkzeug bleibt bis zur expliziten BestÃ¤tigung im generischen Fallback.
- Offene Quellen-, Tabellen- und Feldzuordnungen verhindern Fast-Path und Abschlussimport. Die OberflÃ¤che verlangt eine ausdrÃ¼ckliche BestÃ¤tigung; der Client Ã¼bertrÃ¤gt ausschlieÃŸlich bestÃ¤tigte Overrides.
- Das Backend verwendet weiterhin die gecachte unverÃ¤nderte Vorschau, validiert Overrides gegen registrierte Profile und tatsÃ¤chlich erkannte Tabellen, Spalten und kanonische Rollen und wendet sie erst danach auf das zu persistierende Dataset an. Fehlende oder ungÃ¼ltige BestÃ¤tigungen werden kontrolliert abgewiesen.
- Die Werkzeugzuordnung des Scan-Laufs und das Profil jeder Importdatei sind getrennt: Ein eindeutig erkanntes Batch-Werkzeug bezeichnet weiterhin den Scan-Lauf, generische Begleitdateien behalten jedoch ihr eigenes generisches Dateiprofil, ihre Erkennungsevidenz und ihre MappingidentitÃ¤t.
- Synthetische Regressionen decken Dateiname-only-Erkennung, explizite ProfilbestÃ¤tigung, serverseitige Ablehnung fehlender und manipulierter Overrides sowie die Batch-/Dateiprofiltrennung ab.
- Verifikation des ersten Schnitts: `npm test` erfolgreich mit 147 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da dieser Schnitt keine Persistenz- oder SchemaÃ¤nderung enthÃ¤lt.

- Umsetzungsschritte 2 und 4 sind im zweiten vertikalen Schnitt umgesetzt: `SourceLocator`, versionierte Importprovenienz, Transformationen, Processor-Referenzen und deterministische Processing-States bilden gemeinsame VertrÃ¤ge. `DecodedSourceDocument` ist der erweiterte Dokumentvertrag; `ImportDocument` bleibt als KompatibilitÃ¤tsname fÃ¼r UI und Recognition erhalten.
- CSV, Excel und HTML liefern tabellarische Sichten. JSON bewahrt zusÃ¤tzlich die native Objekt-/Arraystruktur, XML eine pfad- und attributerhaltende Hierarchiesicht und HTML neben Tabellen einen bereinigten Textblick. Verlustbehaftete tabellarische KompatibilitÃ¤tsprojektionen und HTML-Sanitizing werden in der Provenienz ausdrÃ¼cklich markiert.
- Source-Locators reichen vom Dateinamen Ã¼ber Tabellen-, Zeilen- und Spaltenpositionen bis zu Excel-Zellreferenzen, JSON-/XML-Pfaden, HTML-Selektoren und vorbereiteten Containerpfaden. Die verwendete Textkodierung wird nach der plattformneutralen Dekodierung am Dokument festgehalten.
- Architekturregressionen verwenden ausschlieÃŸlich synthetische Inhalte und prÃ¼fen native JSON-/XML-Strukturen, HTML-Text neben Tabellen, Locator-Provenienz, Adapterversionen, Processing-States und die unverÃ¤nderte tabellarische KompatibilitÃ¤t.
- Verifikation des zweiten Schnitts: `npm test` erfolgreich mit 148 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da auch dieser Schnitt weder Persistenz noch Schema Ã¤ndert.
- Umsetzungsschritt 3 ist im dritten vertikalen Schnitt umgesetzt: Eine zentrale Formaterkennung bewertet Excel-/OLE-/ZIP-Signaturen, Inhaltsstruktur, Dateiendung und deklarierten Medientyp als getrennte Evidenz. Signatur und Struktur bestimmen die Parserwahl; Endung und MIME bleiben schwache Hinweise.
- ZIP-Ressourcen- und PfadprÃ¼fung wird jetzt anhand der tatsÃ¤chlichen PK-Signatur statt der Dateiendung ausgefÃ¼hrt. Excel-Workbooks werden Ã¼ber Containerstruktur erkannt; generische ZIPs, unbekannte BinÃ¤rdaten und Dateien mit vorgetÃ¤uschter Excel-Endung werden vor dem Parser kontrolliert abgewiesen.
- Parser- und Ressourcenlimits richten sich nach dem tatsÃ¤chlich erkannten Format. Dadurch greifen insbesondere XML-EntitÃ¤ts-, JSON-Tiefen- und Markup-Grenzen auch bei irrefÃ¼hrender Endung oder falschem Client-MIME.
- Formatkandidaten, Evidenz, Konflikte und Validierungsart werden im `DecodedSourceDocument` gespeichert. Abweichende Hinweise erzeugen strukturierte Diagnosen, ohne eine strukturell stÃ¤rkere Parserentscheidung zu Ã¼berschreiben.
- Synthetische Regressionen prÃ¼fen umbenanntes JSON und Excel, Endungs-/MIME-Konflikte, beschÃ¤digte und generische ZIPs, unbekannte BinÃ¤rdaten, falsche Excel-Dateien sowie XML- und JSON-Sicherheitslimits bei irrefÃ¼hrenden Dateinamen.
- Verifikation des dritten Schnitts: `npm test` erfolgreich mit 152 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da keine Persistenz- oder SchemaÃ¤nderung vorgenommen wurde.
- Umsetzungsschritt 5 ist im vierten vertikalen Schnitt umgesetzt: Eine explizite, deterministisch priorisierte Source-Extractor-Registry erzeugt neutrale `FindingCandidate`-Objekte mit Originalwerten und vollstÃ¤ndigen Source-Locators. Extractors weisen noch keine kanonischen Rollen, Severity oder Finding-IdentitÃ¤ten zu.
- Der native Objekt-Extractor verarbeitet JSON-Objekt-/Arrayansichten und bewahrt verschachtelte `JsonValue`-Originalwerte. Der generische Tabellen-Extractor ist der registrierte Fallback fÃ¼r CSV, Excel, HTML und vorerst XML; er Ã¼bernimmt ausschlieÃŸlich Quellspalten, Header und Positionen.
- Extractor-ID, Version, Match-Evidenz, Diagnosen und Processing-State werden parallel zum bestehenden UI-/Mappingpfad am Importergebnis gefÃ¼hrt. Die bestehende kanonische Persistenz verwendet weiterhin den regressionsgeprÃ¼ften Altpfad, bis Mappingprofile in Umsetzungsschritt 6 kontrolliert auf `FindingCandidate` migriert werden.
- Die Registry bleibt statisch und codebasiert registriert; importierte Dateien kÃ¶nnen weder Extractorcode noch RegistryeintrÃ¤ge liefern. Ein Spezialextractor gewinnt nur mit positiver struktureller Evidenz, sonst wird der generische Fallback verwendet.
- Synthetische Regressionen prÃ¼fen deterministische Extractorwahl, tabellarischen Fallback ohne kanonische Rollen, native JSON-Kandidaten mit verschachtelten Originalwerten, Locator-Treue und den zusÃ¤tzlichen Extraction-Processing-State in Browser- und Serverpipeline.
- Verifikation des vierten Schnitts: `npm test` erfolgreich mit 154 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da keine Persistenz- oder SchemaÃ¤nderung vorgenommen wurde.
- Umsetzungsschritt 6 ist im fÃ¼nften vertikalen Schnitt umgesetzt: Versionierte Mappingprofile werden auf neutrale `FindingCandidate`-Felder angewendet und erzeugen einen eigenen `CandidateMappingResult` mit getrennten Extractor- und Mappingprofil-Referenzen.
- Recognition und Candidate-Mapping verwenden dieselbe Feldrollen-Evidenzkomponente. Automatische, Fallback- und bestÃ¤tigte Entscheidungen bleiben mit Konfidenz, Evidenz und BestÃ¤tigungsbedarf nachvollziehbar; eine explizite Profil- oder FeldbestÃ¤tigung berechnet das Kandidatenmapping konsistent neu.
- Mapping ergÃ¤nzt Rollen additiv. Originalwerte, dekodierte Werte und vollstÃ¤ndige Source-Locators bleiben unverÃ¤ndert erhalten; unterschiedliche Extraktionsvarianten kÃ¶nnen deshalb dasselbe Mappingprofil verwenden, ohne Reportselektoren oder Parserlogik in das Profil zu verlagern.
- Der neue Mapping-Processing-State lÃ¤uft in Browser- und Serverpipeline parallel mit. Die kanonische Finding-Persistenz verwendet bis zur regressionsgesicherten Scanner-Migration in Umsetzungsschritt 9 weiterhin den bestehenden Pfad und wird durch diesen Schnitt nicht doppelt oder still umgestellt.
- Synthetische Regressionen prÃ¼fen gemeinsame Recognition-/Mappingevidenz, versionierte Profilprovenienz, UnabhÃ¤ngigkeit von Extractorvarianten, verschachtelte JSON-Originalwerte, Locator-Treue und die Neuberechnung nach expliziter CIS-CAT-ProfilbestÃ¤tigung.
- Verifikation des fÃ¼nften Schnitts: `npm test` erfolgreich mit 159 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da weder Persistenz noch Schema geÃ¤ndert wurden.
- Umsetzungsschritt 7 ist im sechsten vertikalen Schnitt umgesetzt: Finding-Definitionen tragen eine explizite versionierte IdentitÃ¤tsstrategie mit Dauerhaftigkeit und Evidenz. Gemappte native Regel-IDs erzeugen werkzeuggebundene dauerhafte SchlÃ¼ssel; Findings ohne eine solche ID erhalten ausschlieÃŸlich importlokale `unresolved`-SchlÃ¼ssel.
- Titel, Titel-Asset-Kombinationen, Kategorien und andere abgeleitete Merkmale erzeugen weder im kanonischen Import noch im Vergleich automatische dauerhafte IdentitÃ¤ten. Die deklarativen Profil-`comparisonKeys` enthalten nur noch Kombinationen mit `rule-id`.
- Der Vergleich verwendet automatisch nur nachweislich dauerhafte Definitionen, eindeutige Werkzeug-/Regel-IDs oder eindeutige Framework-/Control-IDs. TitelÃ¤hnlichkeit bleibt ein `possibly-identical`-Reviewvorschlag und kann erst durch eine explizit bestÃ¤tigte lokale Regel verbunden werden.
- Lokale Regeln dÃ¼rfen auch gleiche bestÃ¤tigte Endpunkte ausdrÃ¼cken, werden jedoch weiterhin nur bei genau einem eindeutigen Paar angewendet. Mehrdeutige Kandidaten erzeugen keine automatische oder lokal bestÃ¤tigte Zuordnung.
- Neue Modellvalidierungen erkennen widersprÃ¼chliche IdentitÃ¤tsmetadaten, native Definitionen ohne Quellregel-ID, unresolved Definitionen mit vorgetÃ¤uschter Regel-ID und doppelte kanonische SchlÃ¼ssel. Legacy-Modelle ohne neue Metadaten bleiben lesbar; ihre Definition gilt nur mit vorhandener Regel- oder Framework-ID als automatisch dauerhaft.
- Kanonische Importe erzeugen pro Datei eine aggregierte Warnungsdiagnose fÃ¼r unresolved Findings. Originaltitel und Quellfelder bleiben vollstÃ¤ndig erhalten, werden aber nicht mehr als PersistenzidentitÃ¤t missbraucht.
- Synthetische Regressionen prÃ¼fen stabile IdentitÃ¤t trotz TitelÃ¤nderung, getrennte importlokale IdentitÃ¤ten bei identischen Titeln, ReviewvorschlÃ¤ge statt automatischer Titel-/Asset-Zuordnung, explizite lokale BestÃ¤tigung, Mehrdeutigkeitsblockade und IdentitÃ¤tsvalidierung.
- Verifikation des sechsten Schnitts: `npm test` erfolgreich mit 163 bestandenen Standardtests und 4 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die optionale PostgreSQL-Integration wurde nicht ausgefÃ¼hrt, da weder Persistenzschema noch Repository geÃ¤ndert wurden.

- Umsetzungsschritt 8 ist im siebten vertikalen Schnitt umgesetzt: Versionierte allgemeine Importartefakte bewahren Projektbezug, Parent-Hierarchie, Art, sicheren relativen Pfad, SHA-256, GrÃ¶ÃŸe, SensitivitÃ¤t, Parse-Status und eine ausschlieÃŸlich backendkontrollierte Speicherreferenz.
- Processing Runs werden als unverÃ¤nderliche Historie mit Processor-Versionen, Diagnosen, Zeitpunkten und expliziter Supersession gespeichert. FrÃ¼here Verarbeitungsergebnisse werden beim Reprocessing nicht Ã¼berschrieben.
- Persistente Ingestion Jobs besitzen projektweit eindeutige IdempotenzschlÃ¼ssel, deterministische Claim-Reihenfolge, atomare PostgreSQL-Claims mit `FOR UPDATE SKIP LOCKED`, begrenzte Leases und Versuche sowie Retry- und Dead-Letter-ZustÃ¤nde. Abgelaufene Leases werden kontrolliert Ã¼bernommen; ausgeschÃ¶pfte Jobs werden nicht erneut ausgefÃ¼hrt.
- Lokales und PostgreSQL-Repository prÃ¼fen Projektgrenzen und Referenzen konsistent, exportieren und lÃ¶schen die neuen EntitÃ¤ten projektbezogen. Idempotente Wiederholungen und leere Worker-Polls verÃ¤ndern die Repository-Revision nicht.
- Migration `003_ingestion_artifacts_jobs.sql` ergÃ¤nzt relationale FremdschlÃ¼ssel, Zustands- und Lease-Constraints, HashprÃ¼fung sowie Claim-, Artefakt- und Processing-Indizes, ohne bestehende Migrationen zu verÃ¤ndern.
- Synthetische Regressionen prÃ¼fen Artefakthierarchie, Pfadschutz, unverÃ¤nderliche Processing Runs, Idempotenz, Retry, Worker-Besitz, Lease-Recovery, Dead Letter, Schema-Constraints und vollstÃ¤ndigen Projektexport.
- Verifikation des siebten Schnitts: `npm test` erfolgreich mit 168 bestandenen Standardtests und 5 im Standardlauf erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only-SicherheitsprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die PostgreSQL-Integration lief zusÃ¤tzlich mit 5 von 5 Tests gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich; die Instanz wurde danach entfernt.

- Umsetzungsschritt 9 ist im achten vertikalen Schnitt umgesetzt: Die kanonische Persistenz verwendet bei neu verarbeiteten Dateien das bestÃ¤tigte versionierte `CandidateMappingResult` als einzige semantische Quelle. Die frÃ¼here direkte Ableitung aus UI-Tabellen bleibt ausschlieÃŸlich als KompatibilitÃ¤tsfallback fÃ¼r Legacy-DatensÃ¤tze ohne Mapping bestehen.
- Eine plattformneutrale Candidate-Projektion Ã¼berfÃ¼hrt Originalwerte, Feldrollen, Mappingentscheidungen, Konfidenzen, Processor-Versionen und vollstÃ¤ndige Source-Locators in Definitionen, Vorkommen und Evidenz. Native JSON-Objektpfade bleiben erhalten und werden nicht durch die verlustbehaftete Tabellenprojektion ersetzt.
- Kanonische Importe lehnen offene Quellen-, Tabellen-, Recognition-Feld- und native Candidate-Feldentscheidungen auch auÃŸerhalb des HTTP-Handlers ab. Native Candidate-BestÃ¤tigungen verwenden validierte stabile Decision-IDs; unbekannte IDs und eine Umgehung tabellarischer Feldentscheidungen werden serverseitig abgewiesen.
- Vorschau und Persistenz zÃ¤hlen dieselben ausgewÃ¤hlten Candidates. Kandidaten aus ausdrÃ¼cklich nicht ausgewÃ¤hlten Tabellen werden nicht als Findings gespeichert und mit einer strukturierten Diagnose nachvollziehbar ausgewiesen.
- Purple Knight, PingCastle, CIS-CAT, Maester und der generische Fallback werden mit synthetischen Fixtures Ã¼ber den Candidate-/Mappingpfad bis in ein validiertes kanonisches Modell geprÃ¼ft. Semantisch gleichwertige CSV- und native JSON-Inhalte erzeugen dieselbe Finding-IdentitÃ¤t, Severity und Statusbedeutung.
- ArchitekturprÃ¼fungen verhindern Quelltoolwissen in technischen Formatadaptern und direkte Parser-/Candidate-Mappinglogik in React-Komponenten. Bestehende APIs, IdentitÃ¤tslogik, Exporte, Filter, lokale Verarbeitung und PostgreSQL-Persistenz bleiben regressionsgeprÃ¼ft.
- Abschlussverifikation: `npm test` erfolgreich mit 176 bestandenen Standardtests und 5 im Standardlauf erwartungsgemÃ¤ÃŸ Ã¼bersprungenen PostgreSQL-Integrationstests; Local-only- und ArchitekturprÃ¼fung erfolgreich. `npm run build` fÃ¼r Client und Server erfolgreich. Die PostgreSQL-Integration lief zusÃ¤tzlich mit 5 von 5 Tests gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich; die Instanz wurde danach entfernt.

NachtrÃ¤gliche verifizierte Regression vom 2026-07-21: Importtabellen-IdentitÃ¤ten enthalten neben Quelldatei und Tabellenname nun den stabilen Tabellenindex; die Dataset-KompatibilitÃ¤tsprojektion Ã¼bernimmt dieselbe ID unverÃ¤ndert. Dadurch bleiben mehrfach identisch benannte HTML-Tabellen â€“ wie in umfangreichen PingCastle-Berichten â€“ getrennt adressierbar und erzeugen keine doppelten `SourceTableRecord`-IDs. Eine synthetische Regression prÃ¼ft zwÃ¶lf gleich benannte Tabellen bis zum validierten kanonischen Modell. `npm test` mit 248 Standardtests und Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind erfolgreich; keine Persistenz- oder SchemaÃ¤nderung.

NachtrÃ¤gliche verifizierte Zielkontext-Regression vom 2026-07-21: Der Importworkflow bewahrt `targetProjectId` nun Ã¼ber Vorbereitung, bestÃ¤tigungspflichtige Vorschau, Freigabe und Fehlerzustand. Damit kann ein bereits ausgewÃ¤hlter Mandant beim Abschluss nicht mehr verloren gehen und ein Scannerimport legt nicht unbeabsichtigt einen neuen Mandanten an. Synthetische Zustands-, API- und Datahub-Gruppierungsregressionen sind grÃ¼n. `npm test` mit 249 Standardtests und Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind erfolgreich; keine SchemaÃ¤nderung.

NachtrÃ¤gliche verifizierte PingCastle-Strukturregression vom 2026-07-22: Ein dedizierter plattformneutraler Source Extractor verarbeitet die nativen Finding-Strukturen aus bereinigten PingCastle-HTML-Berichten und aus `HealthcheckData/RiskRules`-XML. Wiederholte HTML-Darstellungen derselben Regel werden innerhalb einer Datei anhand der Rule ID zusammengefÃ¼hrt; dieselbe Rule ID erzeugt formatÃ¼bergreifend dieselbe kanonische Finding-IdentitÃ¤t, wÃ¤hrend jedes importierte Dateiformat sein eigenes Vorkommen mit Quell-Locator und Provenienz behÃ¤lt. RegelÃ¤hnlicher aktiver HTML-Inhalt wird vor der Extraktion entfernt. Synthetische HTML-/XML-ParitÃ¤ts-, Deduplikations-, Sicherheits- und Persistenzregressionen sind grÃ¼n. `npm test` mit 281 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests und erfolgreicher Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind erfolgreich; keine Persistenz- oder SchemaÃ¤nderung.

NachtrÃ¤gliche verifizierte native Work-Projektionsregression vom 2026-07-22: Finding-Vorkommen aus nativen Source Extractors ohne kÃ¼nstliche `SourceTable`-ID erhalten nun je Importdatei eine auswÃ¤hlbare Work-Unteransicht anhand von Werkzeug, Scandatum und technischem Dateiformat. Die Projekt-Gesamtansicht, kanonische Rule-ID-IdentitÃ¤t und dateibezogene Provenienz bleiben unverÃ¤ndert. Die ausdrÃ¼cklich freigegebenen Dummy-PingCastle-Dateien wurden ausschlieÃŸlich rein lesend gegen den aktuellen Importer geprÃ¼ft: HTML und XML enthalten jeweils 37 gematchte Regeln und erzeugen jeweils 37 Candidates ohne offene oder ausgeschlossene Mappingentscheidungen; reale Inhalte wurden nicht in Tests Ã¼bernommen. Eine synthetische Regression sichert die native Unteransicht. `npm test` mit 282 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests und erfolgreicher Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind erfolgreich; keine Persistenz- oder SchemaÃ¤nderung.

NachtrÃ¤gliche verifizierte Scanverlaufs-NachhÃ¤rtung vom 2026-07-22: VerknÃ¼pfte Scanberichte kÃ¶nnen Ã¼ber eine projekt- und scanlaufgebundene, exakt bestÃ¤tigte Repository-/API-Mutation einzeln gelÃ¶scht werden. PostgreSQL-Kaskaden und der lokale Adapter entfernen abhÃ¤ngige Dateien, Tabellen, Vorkommen, Nachweise, Diagnosen, Occurrence-Reviews, scanlaufabhÃ¤ngige Artefakte und ungÃ¼ltig gewordene Vergleiche; gemeinsam verwendete Finding-Definitionen, andere ScanlÃ¤ufe und der Mandant bleiben erhalten. Nicht mehr referenzierte Importfingerprints werden nur fÃ¼r die gelÃ¶schten Hashes bereinigt. Die Scan-Historie markiert bekannte Werkzeuge bei hÃ¶chstens 60 Sekunden auseinanderliegenden Dateizeitpunkten als â€žMÃ¶gliches Duplikatâ€œ; derselbe projektgebundene Hinweis erscheint in der Uploadvorschau, bleibt aber im Gegensatz zur exakten SHA-256-Dublette auswÃ¤hlbar. Im freigegebenen Dummy-Mandanten wurden Markierung, LÃ¶schschaltflÃ¤che und BestÃ¤tigungsdialog rein oberflÃ¤chlich geprÃ¼ft und der Dialog ohne LÃ¶schung geschlossen. `npm test` mit 286 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests und erfolgreicher Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind grÃ¼n. Der PostgreSQL-LÃ¶schpfad wurde zusÃ¤tzlich Ã¼ber die laufende API ausschlieÃŸlich mit zwei synthetischen Test-Scan-IDs ausgefÃ¼hrt und vollstÃ¤ndig auf null Importdateien bereinigt; keine Dummy-Daten wurden verÃ¤ndert.

NachtrÃ¤gliche verifizierte Result-Link-Regression vom 2026-08-02: Der gemeinsame Result-Linker lÃ¶st das Werkzeug eines Findings aus der Blattmetadaten- beziehungsweise Projektprovenienz auf und schlieÃŸt DetailblÃ¤tter mit einer ausdrÃ¼cklich abweichenden toolId aus. Die unscharfe Zuordnung verwendet nur noch erkennbare Datei- oder stabile Regel-ID-Verweise; beliebiger ErgebnisflieÃŸtext, wie ihn Maester im Feld Result liefert, kann keine Quelltabelle mehr Ã¼ber Wort- oder NamensÃ¤hnlichkeit Ã¼bernehmen. Explizite CIS-CAT-source-table-Verweise sowie bestehende Purple-Knight-Datei- und SI-ID-Verweise bleiben erhalten. Drei neue synthetische Regressionen prÃ¼fen Maester gegen CIS-CAT, Maester-FlieÃŸtext gegen ein textÃ¤hnliches Blatt und einen legitimen Maester-ID-Link im gemischten Projekt. npm test bestand mit 485 Standardtests; 7 optionale PostgreSQL-Integrationstests wurden Ã¼bersprungen. Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild waren erfolgreich. Keine Persistenz-, Schema-, Importdaten- oder RealdatenÃ¤nderung.

Phase 13A ist damit vollstÃ¤ndig verifiziert und abgeschlossen.

Persistenzprinzipien:

- Bestehende Projekt-, Assessment-, Scan-Lauf-, Importdatei-, Finding-, Evidenz- und Reviewtabellen bleiben die gemeinsame Grundlage.
- Ein allgemeines Importartefakt hÃ¤lt Parent-Beziehung, Art, relativen Pfad, Hash, GrÃ¶ÃŸe, SensitivitÃ¤t, Parse-Status und backendkontrollierte Speicherreferenz.
- Ein Processing Run speichert Parser-, Extractor-, Profil- und Mappingversion, ohne frÃ¼here LÃ¤ufe zu Ã¼berschreiben.
- Persistente Jobs verwenden IdempotenzschlÃ¼ssel, begrenzte Wiederholungen und Lease-/Recovery-ZustÃ¤nde.
- SchemaÃ¤nderungen erfolgen ausschlieÃŸlich Ã¼ber neue unverÃ¤nderliche Migrationen.

Abnahmekriterien:

- Architekturtests verhindern Toolwissen in Formatadaptern und Parserlogik in React.
- Semantisch gleiche synthetische Inhalte aus mehreren Formaten ergeben dieselbe fachliche Bedeutung.
- Benutzerangabe oder Batchassoziation erzwingen kein unvalidiertes Werkzeugmapping.
- Unbekannte Inhalte bleiben mit Provenienz und Diagnosen erhalten.
- TitelÃ¤hnlichkeit erzeugt keine automatische Finding-ZusammenfÃ¼hrung.
- Alle bestehenden Scannerimporte, APIs, Exporte und Filter bleiben regressionsgeprÃ¼ft.
- `npm test`, `npm run build` und bei PersistenzÃ¤nderungen die PostgreSQL-Integration sind erfolgreich.

### Phase 13C - Scanner Context und Environment Inventory

Status: in Arbeit

Ziele:

- Scannerinformationen ausserhalb einzelner Findings verlustfrei und mit Quellprovenienz erfassen.
- Vorhandene Werte, explizite Abwesenheit, leere Bereiche, Zugriffsfehler, Lizenzgrenzen und Parserluecken fachlich unterscheidbar machen.
- Die Informationen in lokaler und PostgreSQL-Persistenz, Export, API, Result-DB-naher Snapshotabfrage und Dashboard bereitstellen.

Umgesetzter Stand vom 2026-08-23:

- PingCastle HTML persistiert einen vollstaendigen strukturierten Abschnittsbestand mit Hierarchie, Prosa und allen Tabellen; eine zusaetzliche Report-Overview erfasst Tabellen ausserhalb benannter Abschnitte. XML bewahrt die nicht zu `RiskRules` gehoerende `HealthcheckData`-Hierarchie als Abschnitt und typisierte Pfadbeobachtungen.
- Typisierte Beobachtungen enthalten Scanner-/Berichtsmetadaten, Risiko-Scores, stabile zentrale AD-Schluessel fuer Domaene, Forest, Function Level, Schema, DC-Anzahl und Recycle Bin sowie generische, quellentreue Werte fuer jede weitere Tabellenzelle. LAPS, Backup, WEF, krbtgt und ausdruecklich fehlende Entra-Konfiguration werden als eigene Fakten abgebildet.
- `ScannerReportSection` und `EnvironmentObservation` erweitern das kanonische Modell additiv. Migration 018, Local-/PostgreSQL-Repositories, Projekt-Export und eine read-only Environment-Snapshot-API speichern und liefern denselben Vertrag.
- Die Unified Result DB projiziert jede typisierte EnvironmentObservation als eigenen Result-Typ `environment-observation` neben Scanner-Findings und Policy-Evaluationen. Original- und Normalwert, Property, Subject, Erfassungszustand, Abschnitt, Locator sowie Import-, Profil- und Mappingprovenienz bleiben direkt ueber Listen-, Facetten- und Einzelresultat-API abrufbar. Environment-spezifische Facetten filtern Zustand, Property und Subject; Finding-Achsen wie Severity, IOE, Abweichung und Review werden fuer diese Zeilen nicht fachlich umgedeutet.
- PingCastle-Profil 1.4.0 klassifiziert bekannte Tabellen mit den normalisierten sichtbaren PingCastle-Bezeichnungen `domain-information`, `computer-information`, `user-information`, `admin-groups`, `control-paths-analysis`, `infrastructure`, `anomalies`, `password-policies`, `gpo`, `trusts-details` und `pki`. Jeder sichtbare Environment-Unterpunkt wird im flachen Subject-Feld als Punktpfad an seinen Hauptbereich gebunden, beispielsweise `domain-information.entra-id-configuration`, `computer-information.operating-systems`, `infrastructure.wsus-settings`, `anomalies.windows-event-forwarding-wef` oder `gpo.firewall-configuration`. Tabellen mit null Zeilen tragen den Unterpunkt ueber ihre Row-Count-/Presence-Beobachtung; Unterpunkte ohne Tabelle erhalten eine quellentreue Heading-Presence-Beobachtung. Backup, LAPS, WEF und krbtgt bleiben entsprechend dem Bericht unter Anomalies. Finding-Regeldetailabschnitte werden nicht als Environment-Unterpunkte umgedeutet, und unbekannte Tabellen bleiben verlustfrei `pingcastle-table-row`. Bestehende 1.3.0-Importe benoetigen fuer die neuen Subject-Typen einen Reimport.
- PingCastle-Profil 1.3.0 ist die erste eindeutig versionierte Verarbeitungsrevision mit verbindlicher Environment-Context-Erfassung. Historische 1.2.0-Importe bleiben unveraendert gespeichert, gelten aber auch bei gleichem Finding-Kompatibilitaetsschluessel als `reimport-recommended`; nur ein neuer 1.3.0-Import darf als `current` erscheinen.
- Das Dashboard zeigt den aktiven Timeslot als Directory Overview mit zentralen Fakten, Betriebssystemen, hervorgehobenen Infrastruktur-/PKI-/Trust-/LAPS-Bereichen und einer Coverage-Zusammenfassung der Erfassungszustaende.
- Der Environment-Result-Vertikalschnitt ist mit 36 fokussierten synthetischen Domain-, Local-Repository-, PostgreSQL-Vertrags-, API-, HTTP- und UI-Tests verifiziert. Der Gesamtlauf besteht mit 703 Tests und ueberspringt 8 optionale PostgreSQL-Integrationstests; Local-only und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Nur der bereits dokumentierte globale Designcheck fuer zwei Schattenregeln in `datahub-redesign.css` Zeilen 39/42 bleibt rot. Die reale PostgreSQL-Laufzeitintegration fuer Migration 018 bleibt offen; Phase 13C bleibt deshalb in Arbeit.

Abnahmekriterien:

- Jeder vom Scanner benannte Nicht-Finding-Abschnitt bleibt mit Tabellen, Prosa, Zustand und Locator erhalten.
- Zentrale Umgebungswerte besitzen stabile semantische Schluessel; unbekannte Felder bleiben generisch und verlustfrei erhalten.
- Snapshot, Export und Dashboard verwenden dieselbe projekt- und scanlaufgebundene Grundmenge.
- `npm test`, `npm run build` und die PostgreSQL-Integration sind ohne fachfremde Vorfehler erfolgreich.

### Phase 13B â€“ GPO-Backup- und Microsoft-Baseline-Analyse

Status: in Arbeit

Aktueller verifizierter Zusatzstatus vom 2026-08-22: Der globale Microsoft-Security-Baselinekatalog besitzt nun einen bestaetigungspflichtigen Delete-Pfad durch UI, Same-Origin-API, Service sowie Local- und PostgreSQL-Repository. Nur nicht von Policy-Evaluationen referenzierte Pakete duerfen geloescht werden; Klassifikationen und gespeicherte Analysen werden zusammen mit dem Katalogeintrag entfernt, das private Originalobjekt anschliessend best-effort bereinigt. Keine SQL-Migration; Phase 13B bleibt in Arbeit.

Ziele:

- GPMC-/`Backup-GPO`-Backups und Microsoft-Security-Baselinepakete deterministisch, sicher und nachvollziehbar analysieren.
- Richtlinieneinstellungen technisch identifizieren, innerhalb eines konsistenten Kundensnapshots aggregieren, Konflikte erkennen und gegen alle vollstÃ¤ndig geprÃ¼ften technisch passenden Baselinekontexte bewerten.
- Nur bestÃ¤tigte konfigurierte Abweichungen als normale Findings erzeugen; tatsÃ¤chliche Wirksamkeit ohne Scope- oder RSoP-Evidenz niemals behaupten.

Gemeinsame und getrennte Grenzen:

- GPO-Importe verwenden Upload, Containererkennung, Artefakte, Provenienz, Ressourcenlimits, Jobs, Repository, Audit und Persistenz aus Phase 13A.
- GPO-Parser erzeugen `PolicyObservation` statt `FindingCandidate` und durchlaufen nicht das generische Scanner-Mapping.
- Beide Wege treffen erst bei einer fachlich bestÃ¤tigten Finding-Erzeugung im kanonischen Finding-Modell zusammen.

Verbindliche Policy-Pipeline:

```text
ZIP/Verzeichnis
  -> sichere Artefaktinventarisierung
  -> GPO-Backupinstanzen und Analysesnapshot
  -> Artefaktparser
  -> rohe Policy-Instruktionen
  -> CSE-/artefaktspezifische semantische Reduktion
  -> PolicyObservation
  -> technische Policy-IdentitÃ¤t
  -> Aggregation im Kundensnapshot
  -> Baseline-Anwendbarkeit
  -> typisierter Vergleich und Dependency-Regeln
  -> Consensus und Risikoregel
  -> PolicyEvaluationResult
  -> Finding oder PrÃ¼fhinweis
```

Fachliche Regeln:

- GPO-Namen, Pfade, Beschreibungen und Dateinamen bestimmen keinen Zielkontext. Anwendbarkeit wird je Policy aus technischer IdentitÃ¤t, Computer-/User-Scope, Produktfamilie, Produktversion und Rolle bestimmt.
- Der Benutzer wÃ¤hlt nur grundsÃ¤tzlich vorhandene Plattform- und Produktkontexte in einem versionierten `EnvironmentProfile`.
- GPO-GUID, Backup-GUID, Sicherungszeitpunkt, DomÃ¤ne, Abschnittsstatus, VollstÃ¤ndigkeit und Snapshot bleiben getrennt. Historische Backupinstanzen oder gemischte DomÃ¤nen und Zeitpunkte erzeugen keine scheinbar gleichzeitigen Konflikte.
- Einzel- und SetvollstÃ¤ndigkeit werden getrennt modelliert; ein ausgewÃ¤hlter oder unbekannter Backupsatz erlaubt keine negative Gesamtaussage.
- Artefakt-/CSE-spezifische Reducer berÃ¼cksichtigen Instruktionsreihenfolge, LÃ¶schoperationen, Create/Update/Replace/Delete, Abschnittsstatus und dokumentierte Anwendungssemantik vor der GPO-Ã¼bergreifenden Aggregation.
- `PolicyIdentity` beschreibt das technische Konfigurationsziel. Delivery Mechanism, Client-Side Extension, Operation, Reihenfolge und Item-Level-Targeting bleiben an der Beobachtung erhalten.
- Registry Policy und Registry Preference kÃ¶nnen dasselbe Ziel referenzieren, werden wegen unterschiedlicher Durchsetzungs-, Targeting- und Persistenzsemantik aber nicht gleich behandelt.
- Das Fehlen in einer GPO ist kein `not_configured` der Umgebung. `not_observed_in_backup_set` bleibt ein qualifizierter Reviewhinweis.
- BaselinezustÃ¤nde unterscheiden ausdrÃ¼ckliche Empfehlung, ausdrÃ¼cklich nicht anwendbar, keine Empfehlung, KataloglÃ¼cke, unaufgelÃ¶ste IdentitÃ¤t, ParserlÃ¼cke und nicht unterstÃ¼tzte Einstellung.
- `stronger_than_baseline` und `weaker_than_baseline` sind nur mit freigegebenen typisierten Comparatoren zulÃ¤ssig, etwa Gleichheit, Min/Max, Enum-Ordnung, Bitmaske, Menge, Auditflags, Rechte-/ACL- oder zusammengesetzte Regeln.
- Policy-AbhÃ¤ngigkeiten, Overrides, gegenseitige AusschlÃ¼sse und Voraussetzungen werden versioniert modelliert. Advanced-/Legacy-Audit, Domain-Passwortrichtlinien, Fine-Grained Password Policies und andere CSE-SonderfÃ¤lle erhalten keine universelle Skalarbewertung.
- Ein bestÃ¤tigter Consensus setzt exakte IdentitÃ¤t, vollstÃ¤ndiges Parsing, bekannten Comparator, vollstÃ¤ndig geprÃ¼fte plausible Kontexte, eindeutige Baselineempfehlungen und eine freigegebene Risikoregel voraus.
- Die belastbare Klassifikation heiÃŸt `confirmed_configured_deviation`. Eine Abbildung auf `confirmed_finding` muss ausdrÃ¼cklich `Scope unbekannt` und `Wirksamkeit nicht verifiziert` ausweisen.
- Konflikte, kontextabhÃ¤ngige FÃ¤lle, unaufgelÃ¶ste Policies und BaselinelÃ¼cken erzeugen feste PrÃ¼fhinweise, aber keine erfundene Severity.

UnterstÃ¼tzter erster Artefaktscope:

- GPO- und Backupmetadaten
- Computer- und User-`Registry.pol`
- Security Templates
- Advanced Audit Policy
- XML-basierte Group Policy Preferences einschlieÃŸlich Aktionen und Item-Level-Targeting
- Skriptinventar ohne AusfÃ¼hrung
- unbekannte Artefakte mit transparentem Status

Sicherheitsanforderungen:

- ZIP-Slip, absolute und Windows-Spezialpfade, Unicode-/Case-Kollisionen, Symlinks, manipulierte Header, ZIP-Bombs, verschachtelte Archive und tatsÃ¤chliche kumulierte Entpackgrenzen kontrollieren.
- XML ohne DTD, externe EntitÃ¤ten, externe Schemas, XInclude oder Netzwerkzugriff und mit Strukturgrenzen verarbeiten.
- Importierte Skripte und BinÃ¤rdateien niemals ausfÃ¼hren.
- GPO- und Baselineoriginale unverÃ¤ndert auÃŸerhalb des Webroots mit zufÃ¤lliger Speicher-ID, SHA-256-IntegritÃ¤tsprÃ¼fung und Backendzugriff aufbewahren, damit Reprocessing reproduzierbar bleibt.
- GPP-`cpassword` und andere mÃ¶gliche Geheimnisse niemals entschlÃ¼sseln; Vorhandensein erkennen und Werte in UI, Logs, Diagnosen und Exporten maskieren.
- Node-Worker sind eine Ressourcen-, keine Sicherheits-Sandbox. Ein optionales `LGPO.exe` benÃ¶tigt einen separaten niedrig privilegierten Prozess ohne Shell und Netzwerk, mit festem Pfad und Hash, begrenzter Umgebung, Timeout und Ausgabelimits.
- Die Anwendung muss ohne `LGPO.exe` starten und nicht unterstÃ¼tzte Dateien transparent kennzeichnen.

Persistenz und Versionierung:

- Allgemeine Importartefakte aus Phase 13A werden fÃ¼r GPO-Rohartefakte wiederverwendet.
- Relationale Fachobjekte modellieren GPO-Backups, Policy-IdentitÃ¤ten und -Beobachtungen, Baselinekataloge und -einstellungen, Environment Profiles, Evaluation Runs, Ergebnisse und Mehrquellen-Evidenz.
- Beobachtungen und Katalogversionen bleiben unverÃ¤nderlich. Alle Parser-, Identity-, ADMX-, Baseline-, Comparator-, Dependency-, Risiko- und Evaluationsversionen werden am Run gespeichert.
- Reprocessing erzeugt neue Processing- und Evaluation-Runs mit Supersession-Beziehung und Ã¼berschreibt keine Historie.
- Engineversionen gehÃ¶ren in Run und IdempotenzschlÃ¼ssel, nicht in die stabile Finding-Definition.
- Ein Ergebnis kann viele Kundenbeobachtungen, Artefakte und Baselinewerte referenzieren; es wird keine willkÃ¼rliche Hauptdatei gewÃ¤hlt.
- Nur bestÃ¤tigte konfigurierte Abweichungen werden in die generischen Finding-Tabellen geschrieben. Andere Policyergebnisse werden Ã¼ber eine gemeinsame Read-API mit normalen Findings filterbar.

Umsetzungsschritte:

1. Bestandsaufnahme und `docs/architecture/gpo-current-state.md` erstellen.
2. GPO-Bedrohungsmodell, Rohartefaktspeicher und Aufbewahrungsgrenze festlegen.
3. Sichere Container-Ingestion sowie Backup-, Snapshot- und VollstÃ¤ndigkeitserkennung implementieren.
4. Metadaten-, Security-Template-, Advanced-Audit- und Preferences-Parser mit Reducern implementieren.
5. `Registry.pol`-Bibliotheken und Lizenzen prÃ¼fen; Read-only-Parser oder optionalen `LGPO.exe`-Adapter integrieren.
6. Policy-IdentitÃ¤ten und separaten versionierten ADMX-/ADML-Metadatenkatalog implementieren.
7. Microsoft-Baselinekataloge mit bestÃ¤tigten Produkt-, Versions-, Rollen- und Scope-Metadaten importieren und freigeben.
8. Snapshotaggregation, Konflikterkennung, Anwendbarkeit und vollstÃ¤ndigkeitsgesicherten Consensus implementieren.
9. Typisierte Comparatoren, Dependency-/Override-Regeln und Policy-Risikokatalog implementieren.
10. Finding Factory, PrÃ¼fhinweise, Mehrquellen-Evidenz und gemeinsame Filterprojektion ergÃ¤nzen.
11. API, persistente Jobs, Reprocessing, Audit, UI-Vorschau, Details und Exporte ergÃ¤nzen.
12. Parser-, Sicherheits-, Evaluations-, PostgreSQL-, End-to-End- und Scannerregression verifizieren.

Verifizierter Zwischenstand vom 2026-07-21:

- Die Bestandsaufnahme aus Schritt 1 und das Bedrohungsmodell sowie die fachliche Speicher-/Aufbewahrungsgrenze aus Schritt 2 sind in `docs/architecture/gpo-current-state.md` und `docs/architecture/gpo-threat-model.md` dokumentiert. Der dateibasierte Backend-Speicher ist im Serverruntime konfigurierbar, verwendet standardmÃ¤ÃŸig einen nicht verÃ¶ffentlichten lokalen Datenpfad und verweigert eine Lage innerhalb des Webroots. Benutzer-/Rollenautorisierung, VerschlÃ¼sselung und konkrete LÃ¶schfristen bleiben vor dem Firmenbetrieb offen.
- Als vorbereitender Vertragsblock fÃ¼r Schritt 3 sind strikte NFC- und Case-sichere relative Artefaktpfade, versionierte BackupidentitÃ¤ten, technische DomÃ¤nen- und Erhebungsevidenz, explizite Backupsatz-Semantik, Artefaktinventar, Abschnittsstatus sowie getrennte Einzel- und SetvollstÃ¤ndigkeit implementiert.
- Der deterministische Snapshot-Builder trennt Projekte, DomÃ¤nen, explizite BackupsÃ¤tze und historische StÃ¤nde. Doppelte GPO-/Backup-GUIDs, widersprÃ¼chliche Setdeklarationen, DomÃ¤nenmischung und zu groÃŸe Erhebungszeitspannen werden blockiert; unbekannte oder unvollstÃ¤ndige Evidenz bleibt unbestimmt.
- Nur ein konsistenter, manifestgestÃ¼tzter vollstÃ¤ndiger DomÃ¤nenexport mit vollstÃ¤ndigen unterstÃ¼tzten Backupinstanzen darf Aussagen Ã¼ber die Abwesenheit innerhalb dieses Backupsatzes erlauben. AusgewÃ¤hlte Teilmengen, Skriptinventare, unbekannte Artefakte oder fehlende Abschnitte erlauben dies nicht. Scope, VerknÃ¼pfung und tatsÃ¤chliche Wirksamkeit werden daraus ausdrÃ¼cklich nicht abgeleitet.
- Die sichere ZIP-Inventarisierung und der selektive verifizierte Zugriff sind als dedizierter, ressourcenbegrenzter Backend-Worker implementiert. Zentralverzeichnis und lokale Header, sichere Pfade und Kollisionen, Typen, Datenbereiche, deklarierte und tatsÃ¤chliche GrÃ¶ÃŸen/KompressionsverhÃ¤ltnisse, CRC und SHA-256 werden geprÃ¼ft; Links, Spezialdateien und verschachtelte Archive werden blockiert. Ein begrenzter XML-Metadatenparser lehnt DTD, EntitÃ¤ten, externe Referenzen, XInclude, Schemas und nicht erlaubte Kodierungen ab und trennt GPO-GUID, Backup-GUID, DomÃ¤ne und Sicherungszeit. Technische IdentitÃ¤t stammt ausschlieÃŸlich aus Inhalt; Ordner- und Anzeigenamen sind keine IdentitÃ¤t. Konflikte oder gemischt gÃ¼ltige/ungÃ¼ltige Felder blockieren fail-closed, `cpassword` wird nur als vorhanden erkannt und sein Wert nie ausgegeben.
- Der Rohartefaktspeicher verwendet serverseitige zufÃ¤llige UUID-SchlÃ¼ssel, private Staging-/Objektbereiche, exklusive Dateien, Flush vor VerÃ¶ffentlichung, nachgeschaltete GrÃ¶ÃŸen-/SHA-256-PrÃ¼fung, Ã¼berschreibungsfreie VerÃ¶ffentlichung und integritÃ¤tsgeprÃ¼fte Lesezugriffe. Der GPO-Ingest erzeugt konservative Backupinstanzen nur bei Metadaten- und SYSVOL-Evidenz unter derselben Backupwurzel; Erhebungsevidenz stammt vom Backend, der Backupsatz bleibt ohne Manifest unbekannt und ParserlÃ¼cken verhindern VollstÃ¤ndigkeitsbehauptungen.
- Die projektgebundene Submission-Grenze prÃ¼ft vor jeder Aufbewahrung Projekt, Dateimetadaten, GrÃ¶ÃŸe, Base64-Konsistenz und den Container im begrenzten GPO-Worker. Erkannte Originale werden mit `secret`-SensitivitÃ¤t gespeichert, als unverÃ¤nderliches Importartefakt referenziert und Ã¼ber einen projektweit idempotenten `analyze-gpo-backup`-Job aus Migration 004 eingeplant. Der Lease-basierte Runner claimt ausschlieÃŸlich diesen Jobtyp, liest das projektgebundene Original erneut mit GrÃ¶ÃŸen- und SHA-256-PrÃ¼fung und persistiert Processing Run und Backupinstanzen Ã¼ber Migration 005 atomar vor dem Jobabschluss. Deterministische Run-/Datensatz-IDs machen den Crash-Retry nach bereits erfolgter Persistenz revisionsneutral; abweichende Wiederholungen Ã¼berschreiben keine Historie.
- Der Datahub bietet fÃ¼r bestehende Mandanten in Chrome eine native Auswahl des vollstÃ¤ndig entpackten GPO-Backupordners. Relative Browserpfade werden vor dem Lesen kanonisiert und containerweit auf Unicode-/Case-Kollisionen geprÃ¼ft; Anzahl, Einzel- und GesamtgrÃ¶ÃŸe folgen der gemeinsamen Ressourcenrichtlinie. Die Dateien werden sequenziell und bytegleich in einen deterministischen unkomprimierten ZIP-STORE-Transportumschlag Ã¼berfÃ¼hrt und an dieselbe projektgebundene Submission-Grenze gesendet. Der gehÃ¤rtete Backend-Worker validiert den Umschlag unabhÃ¤ngig erneut; die Annahme bedeutet nur `queued`, nicht erfolgreiche Analyse oder VollstÃ¤ndigkeit.
- Die Mandantenansicht lÃ¤dt GPO-Artefakt-, Job- und Processing-Status projektgebunden aus dem Backend und aktualisiert `queued`, `running`, `succeeded`, `partial`, `dead-letter` und wiederherstellungsbedÃ¼rftige ZustÃ¤nde wÃ¤hrend der sichtbaren Ansicht. Neue GPO-Artefakte und Analysejobs werden in einer Repository-Transaktion angelegt; bei Fehlschlag wird das neu geschriebene Objekt sofort entfernt. Eine stÃ¼ndliche Reconciliation repariert referenzierte GPO-Artefakte ohne Job und entfernt ausschlieÃŸlich regulÃ¤re, nicht referenzierte Speicherobjekte beziehungsweise Stagingreste nach standardmÃ¤ÃŸig 24 Stunden Schonfrist und mit begrenzter LÃ¶schanzahl. Dead-Letter-Jobs kÃ¶nnen projektgebunden ohne erneuten Upload kontrolliert auf `queued` zurÃ¼ckgesetzt werden. Das bestÃ¤tigte LÃ¶schen eines fehlgeschlagenen Imports entfernt Artefakt, Job- und Verarbeitungshistorie atomar und schreibt vor dem DateilÃ¶schen einen persistenten LÃ¶schauftrag; ein Prozessabbruch wird durch dieselbe Reconciliation wiederaufgenommen. UngÃ¼ltige oder Ã¤ltere persistierte Speicherreferenzen werden gezÃ¤hlt und sperren fail-safe jede regulÃ¤re Orphan-ObjektlÃ¶schung, ohne LÃ¶sch-Outbox oder Jobreparatur abzubrechen. GroÃŸe zulÃ¤ssige GPO-UmschlÃ¤ge werden Ã¼ber eine Ã¼bertragene Worker-Kopie statt Structured Clone Ã¼bergeben; der GPO-Worker bleibt mit konfigurierbaren Standardgrenzen von 1.024 MB Old Generation und 128 MB Young Generation begrenzt. Jedes JSDOM-Fenster der GPO-Metadaten- und Preference-Parser wird in `finally` geschlossen. Der Worker gibt nur den persistenzrelevanten Analysevertrag aus Backupinstanzen und Diagnosen zurÃ¼ck; Parser-Zwischenmodelle werden nicht Ã¼ber die Threadgrenze geklont.
- Der Security-Template-Pfad aus Schritt 4 verarbeitet `GptTmpl.inf` im begrenzten GPO-Worker. INF-Zeichen-, Zeilen- und Feldgrenzen werden erzwungen; `System Access`, `Kerberos Policy`, `Privilege Rights` und `Registry Values` bleiben als getrennte Instruktionstypen erhalten. Ein separater versionierter Reducer erzeugt zeilenbelegte Policy-Beobachtungen, behandelt unterschiedliche Dubletten als Konflikt und setzt die effektive Anwendung stets auf `unknown`. Unbekannte Abschnitte bleiben `partial`, syntaktisch ungÃ¼ltige unterstÃ¼tzte Werte blockieren das Artefakt ohne Instruktions-Salvage.
- Der Advanced-Audit-Pfad aus Schritt 4 verwendet den allgemeinen CSV-Code ausschlieÃŸlich als begrenzten lexikalischen Decoder mit physischen Startzeilen. Die fachliche Auswertung stÃ¼tzt sich nur auf technische `Subcategory GUID` und numerische `Setting Value` von 0 bis 3; lokalisierte Anzeigenamen werden ignoriert. AusschlieÃŸlich das Systemziel wird als Computer-Policy reduziert, benutzerspezifische Ziele bleiben transparent `partial`. Abweichende Dubletten derselben GUID werden Konflikte, ungÃ¼ltige unterstÃ¼tzte Zeilen blockieren das gesamte Artefakt ohne Salvage, und die effektive Anwendung bleibt `unknown`.
- Der Group-Policy-Preferences-Pfad aus Schritt 4 verarbeitet begrenztes UTF-8/BOM-UTF-16-XML ohne DTD, EntitÃ¤ten, externe Referenzen, Schemas oder fremde Processing Instructions. Getrennte CSE-Reducer unterstÃ¼tzen Registry Preferences, Local Users and Groups, Services sowie Drive Maps anhand ihrer dokumentierten technischen CLSID-/Elementstruktur. Item-UID, Dokumentreihenfolge, deaktivierter Zustand, `removePolicy`, `applyOnce` und vorhandenes Item-Level-Targeting bleiben an jeder Instruktionsbeobachtung erhalten; Targetingwerte werden nicht voreilig ausgewertet, sondern durch Filtertypen und einen Ausdruckshash als `unknown` gebunden. Registry, Local Users and Groups und Drive Maps bewahren ihre C/D/R/U-Semantik; Services verwendet davon getrennt `configure`. Drive Maps wird ausschlieÃŸlich im User-Scope reduziert und erhÃ¤lt die aktionsabhÃ¤ngige Bedeutung von `useLetter`: exakter Buchstabe, Delete-Bereich, erster freier Buchstabe oder erstes vorhandenes Mapping im Bereich. `thisDrive` und `allDrives` bleiben wegen ihrer PrÃ¤zedenz getrennt. Services wird ausschlieÃŸlich im Computer-Scope reduziert und erhÃ¤lt `serviceAction`, `startupType`, Fehleraktionen und rohe dokumentierte Zeitfelder. Local-Group-Ziele bewahren SID-PrioritÃ¤t, Delete-all-users/-groups vor der geordneten Memberliste sowie Add/Remove je Mitglied. Bei kennworttragenden CSEs wird `cpassword` ausschlieÃŸlich als `passwordAttributePresent` abgebildet; der Wert verlÃ¤sst die Parsergrenze nicht. Unbekannte Preference-CSEs und noch nicht unterstÃ¼tzte Eigenschaften bleiben `partial`, fehlerhafte unterstÃ¼tzte Strukturen blockieren ohne Salvage. Alle Beobachtungen werden innerhalb der unverÃ¤nderlichen Backupinstanz atomar mit dem Processing Run gespeichert. Weitere Preference-CSEs bleiben offen; Schritt 5 ist fuer den gegenwaertigen GPMC-Bestand umgesetzt, Schritte 3, 4 und 11 sowie Phase 13B bleiben in Arbeit.
- Der `Registry.pol`-Pfad aus Schritt 5 ist als kleiner read-only In-Process-Parser ohne externe Laufzeitabhaengigkeit umgesetzt. Er prueft PReg-Signatur und Version, begrenzt Datei, Datensaetze und Datenfelder, dekodiert die Typen 1, 2, 3, 4, 5, 7 und 11 sowie die von Microsofts Referenzimplementierung verwendete leere REG_NONE-Schluesselanlage (Typ 0), bewahrt Datensatzreihenfolge und Byteoffset-Provenienz und reduziert Set-, Delete-, SecureKey- und Soft-Instruktionen getrennt. Unbekannte Typen und ungueltige unterstuetzte Strukturen blockieren ohne Salvage; unbekannte reservierte Operationen bleiben transparent partial. Die Beobachtungen werden ueber den bestehenden Worker und die unveraenderliche Backupinstanz persistiert. Schritt 5 ist damit fuer den gegenwaertigen GPMC-Bestand umgesetzt; ADMX-Identitaet, Baseline-Einstellungsparser und Evaluation bleiben offen.
- Der Schritt-6/7-Analysevertrag fuehrt eine stabile, versionsunabhaengige technische Registry-Zielidentitaet aus Scope, Hive, kanonischem Schluessel und Wert beziehungsweise Schluesselziel ein. ADMX ordnet diese Identitaet nur zusaetzlich ueber Zielnamespace, Policy-Name und Element-ID zu; ADML-Strings bleiben lokalisierte Metadaten. Der begrenzte ADMX-/ADML-Parser lehnt externe Konstrukte, fremde Namespaces, doppelte Zielnamespaces und doppelte technische Policy-IDs ab. Ein selektiver Baseline-ZIP-Adapter behandelt XLSX/PDF/Skripte opak, prueft Containerstruktur, Pfade, Typen und deklarierte Gesamtgrenzen und entpackt mit lokaler Header-, CRC-, Groessen-, Ratio- und SHA-256-Pruefung ausschliesslich Backup.xml, Registry.pol, ADMX und ADML. Registry.pol wird durch exakt denselben Parser und Reducer wie beim GPMC-Pfad verarbeitet. Die persistente Worker-/Repository-Anbindung sowie Evaluation bleiben offen.
- Verifikation: 267 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild einschlieÃŸlich eigenem `gpo-inventory-worker.mjs` erfolgreich; 7 optionale PostgreSQL-Integrationstests im Standardlauf Ã¼bersprungen und separat 7 von 7 gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich. ZusÃ¤tzlich wurden dauerhaft neu ladbarer Mandantenstatus, Dead-Letter-Retry ohne Reupload, bestÃ¤tigtes projektgebundenes LÃ¶schen, atomare LÃ¶sch-Outbox, Wiederaufnahme nach Prozessabbruch, fail-safe Behandlung einer nicht unterstÃ¼tzten Legacy-Speicherreferenz, speicherschonende Worker-Ãœbergabe, garantierte JSDOM-Freigabe, kompakter Worker-RÃ¼ckgabevertrag sowie ein synthetischer 1.740-Dateien-/80.186.702-Byte-Lastlauf mit 300 Backupinstanzen unter der unverÃ¤nderten 1-GB-Grenze, Zustandsableitung aus Job und Processing Run, atomare Artefakt-/Jobanlage, PostgreSQL-Transaktionsrollback, sofortiges Dateispeicherrollback, Reparatur fehlender Jobs sowie alters- und mengenbegrenzte Orphan-Reconciliation synthetisch verifiziert. AusschlieÃŸlich synthetische ZIP-, Ordner-, Template-, Audit-, Preference-, Status-, Reconciliation-, LÃ¶sch- und Projektdaten wurden verwendet; Testcontainer und -daten wurden anschlieÃŸend entfernt.
- NachhÃ¤rtung vom 2026-07-22: Die quadratische Quellzeilenberechnung aller unterstÃ¼tzten Preference-CSEs ist durch einen gemeinsamen linearen Scanner ersetzt. Ein danach mit 45.000 Registry-Preference-Beobachtungen reproduzierter zweiter Speicherpeak wurde im Persistenzpfad durch backupwurzelweise Verarbeitung und sofortige Freigabe der Parser-Zwischenmodelle, eine kompakte Worker-RÃ¼ckgabe ohne vollstÃ¤ndiges Containerduplikat sowie ereignisbasiertes Registry-XML-Parsing mit dem lokal gebÃ¼ndelten, fest versionierten `saxes` 6.0.0 beseitigt. Der synthetische Produktionsworker verarbeitet 91.316.402 Bytes, 2.040 EintrÃ¤ge, 300 Backupinstanzen und 45.000 Beobachtungen bei 512 MB Old Generation erfolgreich; zuvor brach derselbe Lauf mit `gpo-inventory-memory-limit` ab. 270 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests mangels PersistenzÃ¤nderung erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Keine realen GPO- oder Mandanteninhalte wurden gelesen.
- Erster Unified-Result-Vertikalschnitt vom 2026-07-22: Der neue plattformneutrale Read-Vertrag projiziert jedes Scanner-Finding-Vorkommen einzeln mit Projekt-, Assessment-, Lauf-, Tool-, Profil-, Regel- und Locatorprovenienz. Severity, Outcome, technische AusfÃ¼hrung, Reviewstatus, Reviewentscheidung, Lebenszyklus und Wirksamkeit bleiben getrennte Dimensionen; unbelegte Lifecycle-/Effective-Aussagen bleiben `unknown`. Vorhandene Quellkategorien werden strukturiert und namespaced ausgegeben. `AssessorRepository`, Local- und PostgreSQL-Adapter, API und Client stellen Result-, Facetten-, Kategorien- und Detailqueries bereit. `PolicyObservation` wird ausdrÃ¼cklich nicht projiziert; Policyresultate folgen erst nach stabiler `PolicyIdentity`, Baseline und Evaluation. Keine SchemaÃ¤nderung. 274 Standardtests, Local-only-SicherheitsprÃ¼fung, Client-/Serverbuild und 7 von 7 PostgreSQL-Integrationstests erfolgreich; ausschlieÃŸlich synthetische Testdaten.
- Zweiter Unified-Result-Vertikalschnitt vom 2026-07-22: Migration 007 ergÃ¤nzt additiv getrennte, geprÃ¼fte und indexierte PostgreSQL-Spalten fÃ¼r fachliches Outcome und technische AusfÃ¼hrung sowie einen namespaced, profilversionierten Kategorienkatalog mit mehrwertiger Occurrence-Zuordnung und Backfill. Neue Scannerimporte bewahren die Dimensionen zusÃ¤tzlich als `MappedValue`; Legacy-Status bleibt lesekompatibel. â€žFailed to runâ€œ wird als `execution_error` mit technischer AusfÃ¼hrung `failed` persistiert und nicht als fachliches `fail`. Beide PostgreSQL-Importpfade schreiben Dimensionen und Kategorien atomar. 277 Standardtests, Local-only-SicherheitsprÃ¼fung, Client-/Serverbuild und 7 von 7 PostgreSQL-Integrationstests gegen frisches PostgreSQL 16 erfolgreich; ausschlieÃŸlich synthetische Daten, Testcontainer entfernt. Phase 13B bleibt in Arbeit.
- Verifizierte GPO-Ordner-Worker-NachhÃ¤rtung vom 2026-07-22: Die projektgebundene Submission lÃ¤sst den begrenzten Worker weiterhin den vollstÃ¤ndigen ZIP-STORE-Transportumschlag einschlieÃŸlich Pfaden, Headern, GrÃ¶ÃŸen, KompressionsverhÃ¤ltnissen, CRC und Hash prÃ¼fen, Ã¼bernimmt in der Vorstufe jedoch nur noch das kompakte Erkennungsergebnis statt eines vollstÃ¤ndigen Inventars. Das vollstÃ¤ndige Inventar bleibt ausschlieÃŸlich innerhalb der eigentlichen Job-/Parsergrenze. Workerfehler werden in sichere technische Kategorien Ã¼berfÃ¼hrt; rohe Fehlermeldungen und mÃ¶gliche Quelldaten verlassen die Grenze nicht. Der synthetische Produktionsworker verarbeitet damit auch in der Erkennungsvorstufe 91.316.402 Bytes und 2.040 EintrÃ¤ge sowie anschlieÃŸend 300 Backupinstanzen und 45.000 Beobachtungen bei 512 MB erfolgreich. `npm test` mit 281 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests und erfolgreicher Local-only-SicherheitsprÃ¼fung sowie Client-/Serverbuild sind grÃ¼n; keine Persistenz- oder SchemaÃ¤nderung. Schritte 3 und 11 sowie Phase 13B bleiben in Arbeit.
- Reale GPMC-Kompatibilitaetsnachhaertung vom 2026-08-04: Synchron geworfene Parserablehnungen werden innerhalb der Worker-Promisegrenze in strukturierte Diagnosen ueberfuehrt und nicht mehr als generischer Workerabsturz maskiert. Ein technisch gueltiger lokaler Microsoft-`BackupTime` ohne UTC-Offset bewahrt GPO-/Backup-ID und Domaene, bleibt aber mit `gpo-metadata-backup-time-zone-missing` bewusst `partial`; freie oder widerspruechliche Zeitformate bleiben fail-closed. Der ausdruecklich freigegebene Mandant Dummy und dessen GPO-Ordner wurden vollstaendig geprueft: Eine fachfremde XLSX im Auswahlroot wurde als verschachteltes Archiv sicher abgewiesen und nicht importiert; die 13 eigentlichen GPO-Dateien ergaben drei aufgeloeste Backupidentitaeten, drei vollstaendige Inventare und 47 Policy-Beobachtungen und wurden mit persistentem Status `partial` in PostgreSQL gespeichert. Der private Artefaktspeicher wurde wegen fehlender Hardlink-Unterstuetzung des synchronisierten Workspace-Dateisystems lokal auf einen expliziten NTFS-Pfad ausserhalb des Webroots konfiguriert. 519 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests im Standardlauf uebersprungen. Phase 13B bleibt in Arbeit.
- Datahub- und Baselinekatalog-Zwischenstand vom 2026-08-04: Persistente GPO-Artefakte werden nun zusammen mit Scannerlaeufen in der Mandantenkarte und in Linked Scan Reports projiziert, ohne sie als Scanner-Findings umzudeklarieren. Der freigegebene Dummy zeigt fuenf Berichte einschliesslich einer GPO-Zeile mit drei Backupinstanzen. Migration 011 fuehrt einen globalen Microsoft-Security-Baselinekatalog ein; mehrere offizielle ZIP-Pakete koennen ueber das Backend in den privaten, SHA-256-geprueften Artefaktspeicher geladen und dedupliziert werden. Produktfamilie, Produktversion, Rolle und Scope werden als getrennte Metadaten gefuehrt; nur genau ein vollstaendig passendes Paket darf automatisch ausgewaehlt werden, Mehrdeutigkeit und fehlende Metadaten bleiben fail-closed. Reconciliation schuetzt referenzierte Baselineoriginale vor Orphan-Loeschung. 523 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich; Migration 011 real angewendet, API und Datahub im Browser verifiziert. Die Paket- und Metadatenauswahl ist implementiert; Baseline-Einstellungsparser, Registry.pol/ADMX-Identitaet, Comparatoren und eigentliche PolicyEvaluation bleiben offen. Phase 13B bleibt in Arbeit.
- Baselineklassifikations-Nachhaertung vom 2026-08-04: Migration 012 fuehrt unveraenderliche, detektorversionierte Klassifikationsrevisionen ein, ohne die importierten Originaldatensaetze umzuschreiben. Ein ZIP-Paket kann mehrere Produktkontexte tragen; kombinierte Windows-10-/Windows-Server-Pakete bleiben dadurch fuer beide Kontexte exakt auswaehlbar. Detektor `microsoft-baseline-filename-v2` korrigiert ausserdem Microsoft 365 Apps 2512 sowie Server-Jahresversionen. Alle 11 freigegebenen Original-ZIPs stimmen per SHA-256 bytegenau mit dem PostgreSQL-Katalog ueberein; Migration 012, 11 Pakete und 11 Klassifikationen sind real bestaetigt. Vier repraesentative Auswahlfaelle und die Datahub-Darstellung wurden gegen die laufende App verifiziert. 524 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests uebersprungen. Baseline-Einstellungsparser und PolicyEvaluation bleiben offen; Phase 13B bleibt in Arbeit.
- GPO-Berichtsprojektion auf Nutzerkorrektur vom 2026-08-04 bereinigt: Ein importiertes, inventarisiertes oder teilweise geparstes GPO-Backup ist kein Ergebnis gegen Microsoft Security Baselines und wird daher weder in Linked Scan Reports noch im Scanberichtzaehler der Mandantenkarte gefuehrt. Upload-, Job-, Inventar- und Parserstatus bleiben getrennt unter GPO Processing sichtbar. Erst ein spaeterer persistierter Baseline-Evaluation-Run darf als GPO-Pruefbericht projiziert werden. Der freigegebene Dummy zeigt wieder vier echte Scanberichte; drei erkannte GPO-Backupinstanzen bleiben ausschliesslich im Verarbeitungsstatus sichtbar. 526 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests uebersprungen. Keine Daten- oder Schemamigration; Phase 13B bleibt in Arbeit.
- Mandanten-GPO-Backup-Snapshot auf Nutzerkorrektur vom 2026-08-04 praezisiert: Ein ausgewaehlter Hauptordner ist genau ein Backup-Snapshot des Mandanten; seine Unterordner sind die darin enthaltenen einzelnen GPOs und keine separaten Mandanten-Backups. Alle erkannten GPO-Datensaetze erhalten dieselbe aus dem Quellartefakt abgeleitete Backup-Set-ID, Scope selected-gpos und Evidenz user-selection und werden zu einem Analysesnapshot gruppiert. Bereits persistierte Datensaetze ohne Set-ID werden lesekompatibel ueber das gemeinsame Quellartefakt gruppiert, ohne unveraenderliche Historie umzuschreiben. Die Status-API fuehrt gpoCount ein; der alte technische Zaehler bleibt voruebergehend als kompatibler Alias. Die UI zeigt fuer Dummy 1 Mandanten-GPO-Backup mit 3 erkannten GPOs. Der Snapshot bleibt selected-subset und erlaubt keine Abwesenheits-, Link-, Scope- oder Wirksamkeitsbehauptung. 526 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests uebersprungen. Keine SQL-Migration; Phase 13B bleibt in Arbeit.
- Produktive Schritt-6/7/11-Anbindung vom 2026-08-04: Migration 013 persistiert stabile technische Policy-Identitaeten, versionierte Identity-Analysis-Runs und -Aufloesungen, Microsoft-Baseline-Analysen, ADMX-Katalogversionen und Baseline-Einstellungen. Der begrenzte Produktionsworker fuehrt sowohl die Registry-Policy-Identitaetsaufloesung der GPO-Beobachtungen als auch die ADMX-/ADML- und Registry.pol-Analyse der Baselinepakete aus. Local- und PostgreSQL-Repositories speichern Analyse-Run, Aufloesungen, Katalog und Einstellungen atomar; Retry nach bereits erfolgtem Commit bleibt revisionsneutral. Enginewechsel erzeugen deterministische supersedierende Processing- und Identity-Runs, explizites Reprocessing prueft den erwarteten Vorgaenger optimistisch, und Start-Reconciliation verarbeitet fehlende aktuelle Analysen nach. Projektgebundene APIs stellen Policy-Analysen und GPO-Reprocessing bereit; Referenzdaten-APIs stellen Baseline-Analysen und deren Reprocessing bereit. Ausschliesslich synthetische Fixtures wurden verwendet. `npm test` ist mit 543 bestandenen Tests und 8 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests gruen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Der neue synthetische PostgreSQL-Paritaetstest ist vorbereitet, konnte aber nicht gegen eine frische PostgreSQL-16-Instanz ausgefuehrt werden, weil kein lokales Image vorhanden und der externe Image-Download nicht freigegeben war. Snapshotaggregation, Evaluation und Result-Projektion bleiben offen; Phase 13B bleibt in Arbeit.
- Produktiver Schritt-8/11-Vertikalschnitt vom 2026-08-04: Migration 014 persistiert unveraenderliche, revisionsverkettete EnvironmentProfile-Kontexte sowie versionierte Snapshot-Aggregationslaeufe, ihre explizit ausgewaehlten Identity-Analysis-Quellen und technischen Zustandszeilen. Die Aggregation verlangt genau einen konsistenten Analysesnapshot, prueft Domaene und Scope gegen das Profil, reduziert Registry-Policy-Instruktionen in ihrer Quellreihenfolge einschliesslich Delete-Semantik und unterscheidet configured, deleted, conflicted und indeterminate. Identische GPO-uebergreifende Werte bleiben beobachtet konfiguriert; abweichende Werte werden ohne erfundene GPO-Praezedenz zum Konflikt. Unvollstaendigkeit, unaufgeloeste Identitaeten, nicht ausgewertetes Targeting und set-value-if-absent ohne bekannten Vorzustand bleiben feste Reviewhinweise. Jeder Lauf setzt effectiveState auf unknown und permitsFindingGeneration auf false; diese Stufe erzeugt daher weder Findings noch Wirksamkeitsaussagen. Local- und PostgreSQL-Repositories, projektgebundene Create-/List-/Aggregate-APIs und deterministische Idempotenz sind integriert. npm test ist mit 551 bestandenen Tests und 8 im Standardlauf erwartungsgemaess uebersprungenen PostgreSQL-Tests gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild sind erfolgreich. Die komplette PostgreSQL-Suite ist mit 8 von 8 Tests gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich, womit die zuvor offene Paritaetspruefung fuer Migration 013 und 014 geschlossen ist. Ausschliesslich synthetische Daten; Testcontainer und Testdaten entfernt. Typisierte Evaluation, Consensus/Risiko, Ergebnis-/Evidenzpersistenz und Unified-Result-Projektion bleiben offen; Phase 13B bleibt in Arbeit.
- Produktiver Schritt-9/11-Vertikalschnitt vom 2026-08-04: Migration 015 persistiert versionierte Evaluation Runs, die expliziten Baseline-Analysequellen, PolicyEvaluationResults und typisierte Mehrquellen-Evidenz. Die getrennte Bewertungsengine implementiert Equality-, Minimum-, Maximum-, Enum-, Bitmask-, Mengen- und Auditflag-Comparatoren; produktiv freigegeben ist zunaechst ausschliesslich die explizite Equality-Zuordnung, bis weitere Comparatoren durch versionierte Katalogregeln gebunden sind. Ein Vergleich verlangt einen vollstaendigen Aggregationslauf, pro Profilkontext genau eine vollstaendige Baselineanalyse, einen vollstaendigen ADMX-Katalog, eindeutige technische Identitaet und Baselinekonsens. Match oder nachweislich staerker wird als configured-match gespeichert, nachweislich schwaecher oder abweichend als bestaetigte konfigurierte Abweichung; jede Luecke, Mehrdeutigkeit, Unvergleichbarkeit oder jeder Konflikt bleibt review-required und niemals finding-berechtigt. effectiveState bleibt immer unknown und projectedFindingCount wird relational auf null erzwungen; dieser Schritt erzeugt noch keine Findings und projiziert nichts in das Unified Result Model. Local-/PostgreSQL-Repositories sowie Create-/List-APIs sind integriert und deterministisch idempotent. `npm test` ist mit 564 bestandenen Tests und 8 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild sind erfolgreich. Die vollstaendige PostgreSQL-Suite ist mit 8 von 8 Tests gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich; Migrationen 001 bis 015, Evaluationpersistenz, Idempotenz und kaskadierendes Projektloeschen wurden synthetisch verifiziert, Testcontainer und Testdaten entfernt. Die vorhandenen Microsoft-Baselinepakete bleiben wegen fehlender Windows-Inbox-ADMX-Kataloge partial und koennen daher produktiv weiterhin nur Review-Ergebnisse erzeugen. Dependency-/Override-/Risikoregeln, explizite Nichtanwendbarkeit, Finding-Erzeugung, Unified-Result-Projektion und UI bleiben offen; Phase 13B bleibt in Arbeit.
- Regelkatalog-Nachhaertung fuer Schritt 9/11 vom 2026-08-04: Die Evaluationsengine verwendet keinen impliziten Equality-Fallback mehr. Ein unveraenderlicher freigegebener Policy-Evaluation-Regelkatalog wird als vollstaendiger Snapshot und als Bestandteil des deterministischen Run-Schluessels gespeichert; jede Regel bindet exakt technische Policy-Identitaet, Delivery Mechanism, Produktfamilie, Produktversion, Rolle und Scope. Ausdrueckliche Empfehlung, ausdrueckliche Nichtanwendbarkeit, keine Empfehlung und Katalogluecke bleiben getrennte Baselinezustaende. Empfehlung verlangt einen expliziten typisierten Comparator und eine freigegebene Risikoregel. Versionierte Prerequisite-, Mutual-Exclusion- und Override-Regeln duerfen Nichtanwendbarkeit nur bei vollstaendigem abwesenheitsfaehigem Snapshot ableiten; unbekannte Abwesenheit, aktive gegenseitige Ausschluesse und Definitionskonflikte bleiben Review. Migration 016 speichert Katalogprovenienz, Baselinezustand sowie Regel-, Dependency- und Risiko-IDs relational und erweitert die Klassifikation um not-applicable, ohne die Finding Factory zu oeffnen. Eine read-only Referenzdaten-API macht den aktiven Katalog transparent. Der produktive freigegebene Katalog 1.0.0 ist bewusst leer, bis setting-spezifische Regeln fachlich kuratiert sind; deshalb erzeugt der aktuelle reale Bestand weiterhin ausschliesslich Review. Synthetische Tests decken Minimum, Katalogluecke, Nichtanwendbarkeit, keine Empfehlung, Prerequisite, Mutual Exclusion und Override ab. `npm test`: 573 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Die vollstaendige PostgreSQL-Suite lief mit 8 von 8 Tests gegen eine frische kurzlebige PostgreSQL-16-Instanz; Migrationen 001 bis 016 und die relationale Risiko-/Nichtanwendbarkeitsgrenze sind verifiziert, Testcontainer und synthetische Testdaten entfernt. Finding Factory, Unified-Result-Projektion, UI und reale Regelkuratierung bleiben offen; Phase 13B bleibt in Arbeit.

- Produktiver Schritt-10/11-Vertikalschnitt vom 2026-08-04: Eine versionierte Finding Factory verarbeitet ausschliesslich bereits `eligible` klassifizierte `confirmed_configured_deviation`-Ergebnisse und prueft vor jeder Projektion erneut explizite Baselineempfehlung, eindeutige Risikoregel, Comparatorrelation, vollstaendigen Snapshot-/Aggregationszustand sowie exakt passende Observation-, Backup-, Baseline-, Setting- und Kontext-Evidenz. Jede verletzte Invariante erzeugt eine persistente Ablehnung und niemals ein Finding. Migration 017 persistiert idempotente Factory Runs und Policy-Finding-Occurrences gegen die gemeinsame kanonische Finding-Definition; Scanner-Occurrences bleiben unveraendert an Scan Run und Importdatei gebunden. Local- und PostgreSQL-Repositories, projektgebundene Create-/List-API und Client sind integriert. Nur bestaetigte Policy-Abweichungen erscheinen als `policy-evaluation` im bestehenden Unified-Result-Read-Modell; Scope bleibt `unknown`, Wirksamkeit `not-verified` beziehungsweise `unknown_effective_state`, `is_ioe` bleibt false. Der produktive leere Regelkatalog erzeugt weiterhin null Findings. `npm test`: 577 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die vollstaendige PostgreSQL-Suite lief mit 8 von 8 Tests gegen eine isolierte kurzlebige PostgreSQL-16-Instanz; Migrationen 001 bis 017, Factory-Idempotenz und der gemeinsame Read-Pfad wurden synthetisch verifiziert, Testcontainer und Testdaten entfernt. UI fuer Reviewhinweise/partielle Analysen und reale Regel-/Inbox-ADMX-Kuratierung bleiben offen; Phase 13B bleibt in Arbeit.
- Produktiver Schritt-11-UI-Vertikalschnitt vom 2026-08-04: Ein projektgebundenes, typisiertes Policy-Analyse-Readmodell fuehrt Identity-Analysis-, Snapshot-Aggregations-, Evaluation- und Finding-Factory-Laeufe fuer die Darstellung zusammen, ohne die unveraenderlichen Fachobjekte umzuschreiben. Ein neuer read-only API-/Clientpfad liefert Laufhistorie, Environment-Profile-Revisionen, Evaluationsergebnisse und eine severity-freie Review-Queue. Der Datahub trennt konfigurierte Abweichungen, tatsaechlich erzeugte Policy-Findings und Review-Datensaetze sichtbar; Konflikte, unaufgeloeste Identitaeten, Katalog-/Parserluecken, unbekanntes Targeting, partielle Laeufe und Factory-Ablehnungen behalten feste technische Kategorien und Evidenzzaehler. Die Ansicht weist aus, dass ihre Zaehler persistierte Laufhistorie beschreiben und dass effektive Anwendung ohne RSoP/GP Results nicht verifiziert ist. Synthetische Domain-, HTTP-, Client- und Renderregressionen sichern insbesondere, dass Review oder unvollstaendige Evidenz kein Finding erzeugen. `npm test`: 582 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; reale Daten wurden nicht inspiziert. Profilwahl/-orchestrierung in der UI, fachliche Regelkuratierung, vollstaendige Windows-Inbox-ADMX-Kataloge, weitere Preference-CSEs und Exportdetails bleiben offen; Phase 13B bleibt in Arbeit.
- Produktiver Schritt-11-Orchestrierungsvertikalschnitt vom 2026-08-04: Das projektgebundene Policy-Analyse-Readmodell liefert neben Laufhistorie und Review nun eine typisierte Aktionsbereitschaft fuer GPO-Reprocessing, Snapshotaggregation, Baselineevaluation und Finding Factory. Neue Aktionen werden ausschliesslich aus aktiven Environment-Profile-Revisionen, nicht supersedierten Identity-Analysis-Runs, dem tatsaechlich letzten Processing Run sowie pro Profilkontext exakt ausgewaehlten Baselinepaketen und deren aktiver Analyse abgeleitet. Fehlende oder mehrdeutige Kataloge blockieren; partielle Identity-, Aggregations-, Baseline- oder Evaluationsevidenz wird ausdruecklich `review-only`; bereits deterministisch vorhandene Laeufe werden `completed`. Der Datahub kann Environment Profiles mit Betriebssystem-, optionalem Produkt-, Rollen-, Scope- und Domaenenkontext neu oder als Revision anlegen und ruft fuer alle weiteren Schritte nur die bestehenden projektgebundenen, idempotenten Backendmutationen auf. Supersedierte Profile und Analysen werden fuer neue Aktionen nicht angeboten, stale GPO-Reprocessing bleibt durch den erwarteten letzten Processing Run optimistisch gesperrt. Synthetische Readmodell-, Supersession-, Baselineauswahl-, HTTP- und Renderregressionen sichern Ready-, Review-only-, Completed- und Blocked-Zustaende. `npm test`: 588 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; reale Daten wurden nicht inspiziert. Fachliche Regelkuratierung, vollstaendige Windows-Inbox-ADMX-Kataloge, weitere Preference-CSEs, aktuelle snapshotbezogene Ergebnisdeduplizierung und Exportdetails bleiben offen; Phase 13B bleibt in Arbeit.
- Phase-13A-Darstellungsregression vom 2026-07-22 behoben: Ein serverseitig abgeschlossener Scannerimport lÃ¤dt fÃ¼r Work unmittelbar wieder das persistierte kanonische Mandantenmodell statt der rohen Parserprojektion. PingCastle-XML zeigt dadurch RiskRules-Findings und keine allgemeinen HealthcheckData-Knoten; das Profil verwendet Title als KartenÃ¼berschrift. 287 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich. Die laufende Dummy-Ansicht wurde rein lesend auf 37 XML-Findings, vorhandene XML-Unteransicht, ausgewÃ¤hlten Titel und fehlenden DomainSid-Knoten geprÃ¼ft. Keine Persistenz- oder SchemaÃ¤nderung.
- Phase-13A-PingCastle-Results-Nachhaertung vom 2026-08-21: Der HTML-Extractor 1.7.0 verfolgt strikt lokale Fragmentverweise aus `Details` rekursiv ueber Subsections, Tabellenzellen, Bootstrap-Modals und Collapse-Bereiche bis zu ihren Tabellenendpunkten. Elterninhalte maskieren separat verlinkte Zielcontainer, sodass jede Tabelle genau einmal und mit hierarchischer Bezeichnung im bestehenden `Verwandte Daten`-/Results-Vertrag erscheint. Zyklen, fehlende oder mehrdeutige Ziele sowie Tiefen-, Ziel- und Tabellenlimits werden sicher begrenzt und diagnostiziert; externe oder aktive Ziele werden nicht verfolgt. Results-IDs sind pro Importdatei isoliert. Das technische Feld `Verwandte Daten` und seine importdateigebundene Sektions-ID bleiben intern vollstaendig erhalten und speisen weiterhin den exakten Results-Linker, werden im Finding-Reader jedoch weder als Abschnitt noch unter `Additional Information` angezeigt. Auf ausdrueckliche Nutzerentscheidung ersetzt dies zugleich die statische HTML/XML-Begleiteranreicherung vom 2026-07-22: HTML und XML bleiben getrennte Importe, nur HTML erzeugt PingCastle-Results, XML meldet die fehlende Results-Faehigkeit als Importwarnung. Synthetische Rekursions-, Sicherheits-, Projektions- und Formattrennungsregressionen sind gruen. Der ausdruecklich freigegebene Dummy-Bericht wurde einmalig inhaltsarm verifiziert: `P-Delegated` erzeugt sieben Results-Bloecke mit 4, 14, 5, 3, 1, 1 und 5 Datenzeilen; der temporaere Realdatei-Test wurde entfernt. `npm test`: 616 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Aktualisierte App und Backend laufen lokal und liefern HTTP 200. Keine API-, SQL- oder Persistenzaenderung; Phase 13A bleibt abgeschlossen.
- Phase-13A-/Phase-7-PingCastle-Detailpfad vom 2026-08-21 nachgeschaerft: Extractor 1.8.0 ordnet rekursiv erreichte Modal- und Collapse-Endpunkte nach ihrer tatsaechlichen Zielposition im HTML; die finding-spezifische Results-Verknuepfung erhaelt diese Reihenfolge auch dann, wenn die globale Blattliste anders sortiert ist. Profil 1.2.0 zeigt hierarchische Pfadtitel an und entfernt nur das technische `PingCastle ·`-Praefix. Bereits strukturiert erhaltene Abschnittsprosa wird direkt vor ihrer Tabelle projiziert; reine Modal-Titel-/`Close`-Artefakte werden nicht als doppelter Text angezeigt. 49 fokussierte synthetische Tests, die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; bestehende Importe benoetigen fuer die neue Zielreihenfolge und Preambles einen Reimport. Phase 13A und Phase 7 bleiben abgeschlossen.
- Phase-7-PingCastle-Readerkorrektur vom 2026-08-21: Sobald strukturierte PingCastle-Results vorhanden sind, wird das urspruengliche Feld `Details` weder als Reader-Fliesstext noch unter Additional Information angezeigt. Die fachlichen Texte und Tabellen bleiben im geordneten Results-Pfad erhalten. Bei alten oder unvollstaendigen PingCastle-Importen ohne strukturierte Results bleibt `Details` als lesbarer Fallback sichtbar. 38 fokussierte synthetische Tests, die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich; keine Import-, API-, SQL- oder Persistenzaenderung. Phase 7 bleibt abgeschlossen.
- Verifizierte PingCastle-Score- und Regelkatalog-NachhÃ¤rtung vom 2026-07-22: Der native Extractor Ã¼bernimmt aus XML die individuellen Regelpunkte, die vier autoritativen Kategorie-Scores, den Domain Risk Level sowie strukturierte Details/ExtraDetails. Die Work-KompatibilitÃ¤tsprojektion ergÃ¤nzt ausschlieÃŸlich statische Herstellertexte aus einer im selben Projekt vorhandenen HTML-Begleitdatei mit identischem Dateistamm und Rule ID; dynamische Scanwerte werden nie formatÃ¼bergreifend kopiert und die HTML-Quelle wird sichtbar ausgewiesen. Regelpunkte, Kategorie-Score und Domain Risk Level erscheinen getrennt mit der Herstellersemantik â€žKategorie maximal 100, Gesamtscore als Maximum der vier Kategorienâ€œ. Synthetische XML-/HTML-, Projektions- und UI-Regressionen sowie der ausdrÃ¼cklich freigegebene Dummy-Paarabgleich mit 37 korrespondierenden Regeln sind erfolgreich. npm test mit 289 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild sind grÃ¼n. Der veraltete reviewfreie Dummy-XML-Lauf wurde kontrolliert durch die neu verarbeitete freigegebene Datei ersetzt und der HTML-Begleitlauf ergÃ¤nzt; BrowserprÃ¼fung bestÃ¤tigt je 37 getrennte XML-/HTML-Findings, Score-Badges, Regeltexte und ExtraDetails. Keine SchemaÃ¤nderung.
- Verifizierte PurpleKnight-Result-PersistenznachhÃ¤rtung vom 2026-07-22: Quelltabellen ohne Finding-Vorkommen bewahren ihre Zeilen nun als optionale Originalfelder im kanonischen SourceTable-Vertrag; Tabellen mit bereits persistierten Finding-Vorkommen werden nicht doppelt gespeichert. Work rekonstruiert diese unterstÃ¼tzenden Tabellen nach Finding- und nativen Ansichten, sodass Result-Referenzen wie SI000055 wieder auf die vollstÃ¤ndige Ergebnistabelle zeigen. Synthetische Import-, Projektions-, Reihenfolge- und Linkerregressionen sind grÃ¼n.  `npm test mit 291 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild sind erfolgreich. Der ausdrÃ¼cklich freigegebene reviewfreie Dummy-PurpleKnight-Lauf wurde mit derselben lokalen XLSX ersetzt; BrowserprÃ¼fung bestÃ¤tigt 20 Results-Buttons sowie fÃ¼r den genannten Fund eine Tabelle mit einer Zeile und vier Spalten. Die abschlieÃŸende BestandsprÃ¼fung erkannte den bereits zuvor fehlenden separaten PingCastle-XML-Lauf; die lokal vorhandene freigegebene XML-Datei wurde mit 37 Findings ergÃ¤nzt und der Browser bestÃ¤tigt wieder 193 Findings aus PurpleKnight, PingCastle HTML und PingCastle XML. Additive kanonische JSON-Vertragserweiterung, keine SQL-Migration.

- Phase-13A-CIS-CAT-Results-NachhÃ¤rtung vom 2026-07-30: Der neue `cis-cat-html-source-extractor` folgt den internen `#detail-*`-Verweisen der Assessment-Result-Tabelle und bewahrt pro Ergebniszeile genau ein Candidate-Finding. `Benchmark Item` und die vorangestellte Regelnummer werden im Profil 1.1.0 als Titel beziehungsweise Rule ID abgebildet. Description, Rationale, Remediation einschlieÃŸlich Impact, Assessment Evidence, Rule Result XML, References sowie CIS Controls V7/V8 bleiben als strukturierte Originalwerte mit sicherem Klartextwert erhalten; stabile, auf dieselbe Quelldatei begrenzte `sourceTableIndex`-Verweise Ã¶ffnen alle zugehÃ¶rigen Quelltabellen im Results-Fenster. Der bounded-lexical HTML-Pfad richtet verschachtelte Tabellen an seinen tatsÃ¤chlichen nicht Ã¼berlappenden Parserindizes aus und verlinkt XML-interne Doppeltabellen nicht erneut. Die kanonische Work-Projektion zeigt strukturierte Originalfelder Ã¼ber ihren `rawValue`, ohne die Provenienz zu Ã¼berschreiben. Synthetische Extractor-, Persistenz-, Projektions-, Linker- und Readerregressionen sowie `npm test` mit 437 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests, erfolgreicher Local-only- und DesignprÃ¼fung und der Client-/Server-Produktionsbuild sind grÃ¼n. Der ausdrÃ¼cklich freigegebene Dummy-Bericht wurde real mit 411 Findings und 1.815 Quelltabellen vorgeprÃ¼ft; die Beispielregel 2.2.2 besitzt alle zehn genannten Textabschnitte und exakt sechs Evidence- plus zwei Control-Tabellenverweise. Zwei vorherige CIS-CAT-TestlÃ¤ufe wurden kontrolliert durch diesen einen geprÃ¼ften Lauf ersetzt; API und Datahub bestÃ¤tigen wieder vier Scanberichte insgesamt. Die verbundene Browsersteuerung blockierte danach die weitere Work-Seite durch ihre URL-Policy, daher ist das Results-Popup nicht zusÃ¤tzlich visuell abgenommen; sein Daten- und Darstellungsvertrag ist durch die genannten Regressionen und den realen Parser-/Persistenznachweis abgedeckt. Keine SQL-Migration.
- Phase-13A-CIS-CAT-Results-Darstellungskorrektur vom 2026-07-30: Auf Nutzerkorrektur zeigt das Results-Fenster ausschlieÃŸlich die Ã¼ber `sourceTableReferences` verlinkten Assessment-Evidence- und CIS-Control-Tabellen; Description, Rationale, Remediation/Impact, References und sonstiger Finding-FlieÃŸtext bleiben im Finding. `Rule Result XML` ist dort ein standardmÃ¤ÃŸig geschlossenes, bewusst zu Ã¶ffnendes Detail und wird nicht als Result-Text behandelt. Bereits persistierte `CIS-CAT Details`-Sammelfelder werden lesekompatibel zerlegt, ohne Reimport oder Datenmigration; neue Importe speichern XML als eigenes strukturiertes Originalfeld. In gemischten Projekten bestimmt zusÃ¤tzlich die `toolId` des aktiven Blatts das Darstellungsprofil, sodass `Benchmark Item` statt `Weight`/`1.0` als Titel verwendet wird. Verifiziert mit 440 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests, erfolgreicher Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild. Die ausdrÃ¼cklich freigegebene Dummy-Ansicht bestÃ¤tigt fÃ¼r Regel 2.2.2 den vollstÃ¤ndigen Benchmark-Titel, geschlossenes XML und acht verlinkte Results-BlÃ¶cke ohne Finding-Volltext oder XML. Keine SQL-Migration und kein Reimport erforderlich.
- Phase-13B-Result-DB-Abweichungs- und Titelkorrektur vom 2026-07-30: Das werkzeugunabhÃ¤ngige AbweichungsprÃ¤dikat 1.1.0 bewertet nun neben festgestellten IOEs und `warning` auch `Outcome: fail` als fachliche Abweichung. Dadurch bleiben fehlgeschlagene CIS-CAT-Compliance-Checks vertragsgemÃ¤ÃŸ `IOE: Nein`, erscheinen aber als `Abweichung: Ja`. Der PostgreSQL-Vorfilter verwendet exakt dieselben Outcome-Werte (`fail`, `warning`) wie die plattformneutrale Projektion, sodass Zeilenanzeige, FacettenzÃ¤hlung und Ja/Nein-Filter nicht mehr auseinanderlaufen. Eine kanonische Importregression sichert zusÃ¤tzlich, dass der CIS-CAT-Titel aus `Benchmark Item` in die `FindingDefinition` Ã¼bernommen wird und weder `Quelle: Datei` noch der Dateiname sein darf. Verifiziert mit 443 bestandenen Standardtests, 7 erwartungsgemÃ¤ÃŸ Ã¼bersprungenen optionalen PostgreSQL-Tests, erfolgreicher Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild. Im ausdrÃ¼cklich freigegebenen Dummy zeigt Regel 2.2.2 den vollstÃ¤ndigen Benchmark-Titel, `fail`, `Abweichung: Ja`; kein geladener CIS-CAT-Titel lautet `Quelle: Datei`. Der Filter `Abweichung: Ja (323)` liefert 323 Treffer und die 50 geladenen Zeilen sind vollstÃ¤ndig `fail`/`Ja`. Keine SQL-Migration und kein Reimport erforderlich.

- Phase-13A-CIS-CAT-Results-Vollstaendigkeit vom 2026-07-31: Auf Nutzeranforderung erscheint jetzt jeder verlinkte oder im Bericht nur aufgeklappte CIS-CAT-Inhalt im Results-Fenster. Der Extractor 1.2.0 leitet die Abschnittszuordnung nicht mehr aus einer festen Liste bekannter Ueberschriften ab, sondern aus den Marken des Berichts selbst: Aufklappverweise (â€žShow Assessment Evidenceâ€œ, â€žShow Rule Result XMLâ€œ) und fette Ueberschriften mit Doppelpunkt. Damit tragen auch kuenftige Rahmenwerke ihre woertliche Ueberschrift; zuvor fiel jede unbekannte Fassung â€” etwa â€žCIS Controls V8â€œ â€” auf die vorherige Marke â€žRule Result XMLâ€œ zurueck, deren Tabellen bewusst aussortiert werden, sodass die zugehoerige Steuerungstabelle vollstaendig aus dem Fenster verschwand. Die XML-Doppeltabellen werden nun ueber ihren Behaelter (`div.xml` mit `_xml_result`) statt ueber eine Zeichenkette im Text davor ausgeschlossen. Der bisher berechnete, aber nie ausgegebene Aufzaehlungstext der Zuordnungen erscheint als neues Feld `Control Mappings` ohne die Bedienbeschriftung â€žMoreâ€œ; Detailtabellen ohne Caption uebernehmen ihre einzelne Kopfzelle als Namen (â€žCIS Control Informationâ€œ statt â€žTabelle 7â€œ). `ToolProfileDefinition.presentation.resultSectionHeaders` erklaert werkzeugunabhaengig, welche Felder als eigene benannte Abschnitte in das Fenster gehoeren; CIS-CAT 1.3.0 nennt ausschliesslich `Control Mappings`, und der Reader blendet genau dieses Feld aus. Das Rule Result XML gehoert auf Nutzerkorrektur vom selben Tag ausdruecklich nicht dazu: es fuellte das Fenster vor den eigentlichen Belegtabellen und bleibt daher â€” wie in der Darstellungskorrektur vom 2026-07-30 festgelegt â€” ein standardmaessig geschlossenes Detail im Finding, fuer neue Importe aus dem eigenen Feld und fuer aeltere Importe aus dem Sammelfeld `CIS-CAT Details`. `LinkedResults`/`FloatingResultsWindow` zeigen statt eines einzelnen fest benannten Ergebnistextes beliebig viele benannte Abschnitte; Datensatz- und Graphansicht verwenden dieselbe Zusammenstellung. Verifiziert mit 460 bestandenen Standardtests, 7 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, erfolgreicher Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild. Regressionen sichern beide Richtungen: das XML erscheint im Fenster an keiner Stelle und bleibt im Reader ein geschlossenes Detail. Neue synthetische Fixture `assessment.future-controls.synthetic.html` mit einer neuen CIS-Fassung und einem fremden Rahmenwerk sichert die Regression bis in die gerenderte Fensterausgabe. Keine visuelle Abnahme an realen Daten und kein Reimport erforderlich fuer die Reader-Vertraeglichkeit; die neuen Felder entstehen erst beim naechsten Import des Berichts. Keine SQL-Migration.

- Phase-13A-CIS-CAT-Results-Verknuepfungskorrektur vom 2026-07-31: Am freigegebenen Dummy zeigte sich, dass das Results-Fenster einer einzelnen Regel 3.294 Zeilen aus rund 50 identischen Belegtabellen fuehrte. Ursache war nicht die Extraktion, sondern der Ergebnis-Linker: er verglich die Quelldatei des Datensatzes mit `record.sourceFile`, das in der Projektansicht (â€ž<Projekt> Â· Alle Datensaetze") den Projektnamen traegt statt der Datei. Der exakte `source-table:`-Verweis fand dadurch genau in der ueblichen Leseansicht kein Blatt und fiel auf die Namensaehnlichkeit zurueck, die jede gleichnamige Tabelle des gesamten Berichts hereinzog â€” CIS-CAT gibt dieselbe Belegtabelle je Regel erneut aus. Der Linker liest die Herkunft jetzt aus dem Provenienzfeld â€žQuelle: Datei" und behandelt einen vorhandenen Quelltabellenverweis als abschliessend: loest er nichts auf, bleibt das Ergebnis leer statt einen Ersatz zu erfinden. Zusaetzlich zwei Beschriftungsfehler, die erst der reale Bericht zeigte. Erstens baut er einen Aufklappblock nicht als Verweis, sondern als `<span class="action">Show</span><span class="caption">Assessment Evidence</span>`: Bedienwort und Bezeichnung stehen in getrennten Elementen, und die Bezeichnung traegt keinen Doppelpunkt. Es entstand deshalb gar keine Marke, und die Belegtabellen erbten die vorhergehende Ueberschrift â€žImpact". Die Markensuche wertet `caption`-Beschriftungen jetzt ohne Doppelpunkt als Abschnitt und liest einen Aufklappverweis ueber sein Ende hinaus, falls ein Bericht die aeltere Ankerform nutzt. Zweitens setzt der Bericht die Steuerung selbst fett mit Doppelpunkt in den Listenpunkt, wodurch die eingebettete Tabelle â€žControl 6: â€¦" statt â€žCIS Controls V7.0" hiess; Ueberschriften innerhalb einer Zuordnungsliste gelten deshalb nicht mehr als Abschnitt. Der References-Block wird ueber seinen Behaelter von den Zuordnungen getrennt, weil der Bericht fuer beide dieselbe Listenklasse verwendet. Die synthetische Fixture bildet alle drei realen Strukturen ab. Verifiziert mit 463 bestandenen Standardtests, 7 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild. Am ausdruecklich freigegebenen Dummy wurde der Bericht mit dem korrigierten Extractor neu eingelesen (411 Occurrences) und der ueberholte Lauf danach entfernt, sodass der Mandant wieder genau vier Scanberichte fuehrt: Regel 17.7.5 zeigt jetzt 130 statt 3.294 Zeilen in sieben Bloecken â€” Control Mappings, viermal â€žAssessment Evidence Â· â€¦", â€žCIS Controls V7.0 Â· CIS Control Information" und â€žCIS Critical Security Controls V8.0 Â· CIS Control Information" â€” ohne XML und ohne References im Fenster, waehrend der Reader Description, Remediation, Rationale, References und das geschlossene Detail â€žRule Result XML" fuehrt. Keine SQL-Migration.

- Schluessel/Wert-Tabellen ohne Kopfzeile vom 2026-07-31: Die CIS-Control-Tabellen erschienen im Results-Fenster als einzelne Spalte â€žLabel:" mit der Zeile â€žDescription:" - ohne einen einzigen Wert. Ursache war die generische Kopfzeilensuche: eine `<table class="enum">` ist eine reine Schluessel/Wert-Tabelle (`Control:`, `Subcontrol:`, `Label:`, `Description:`) mit einer spaltenuebergreifenden Titelzeile und hat gar keine Kopfzeile. `detectHeaderRow` waehlte die Zeile mit den zwei laengsten Beschriftungen, machte deren Wert zur Spaltenueberschrift und verwarf alles darueber; von vier Angaben blieb eine. `analyzeRows` erkennt eine solche Tabelle jetzt an zwei Spalten mit durchgaengigen Bezeichnern auf Doppelpunkt, vergibt die Spaltennamen `Feld`/`Wert` und behaelt jede Zeile; eine vorangestellte Zeile ohne Wert bleibt Titel. Das ist die einzige Stelle, an der Spaltennamen vergeben statt gelesen werden, und sie ist als solche benannt. Da Quelltabellen aus `sheet.analysis.records` persistiert werden, wirkt die Korrektur erst mit einem erneuten Import. Verifiziert mit 464 bestandenen Standardtests, 7 erwartungsgemaess uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild; am freigegebenen Dummy zeigt Regel 17.7.5 nach dem Neuimport beide Steuerungstabellen vollstaendig â€” `CIS Controls V7.0` mit Control, Subcontrol, Label und Description, `CIS Critical Security Controls V8.0` zusaetzlich mit Implementation Group und Security Function, jeweils mit Wert. Bekannter Rest ohne Informationsverlust: im bounded-lexical Pfad (Dateien ueber 4 MB) konsumiert der Parser eine verschachtelte Tabelle zusammen mit ihrer aeusseren; die aeussere Complex-Check-Tabelle traegt dadurch eine dreispaltige erste Zeile, faellt aus der Schluessel/Wert-Erkennung und zeigt ihr `Criterion:` nicht â€” dieselbe Angabe steht vollstaendig im unmittelbar folgenden Block der inneren Tabelle. Keine SQL-Migration.

Abnahmekriterien:

- Benutzer sehen und bearbeiten nur autorisierte Projekte.
- Betrieb, Wiederherstellung und Update sind dokumentiert und getestet.
- Es findet keine Ãœbertragung an externe Dienste statt, sofern dies nicht spÃ¤ter ausdrÃ¼cklich beschlossen wird.

## 8. Aktuell empfohlene Umsetzungsetappe

Die naechste Umsetzung fuehrt Phase 13B auf dem konsolidierten Import-, Policy-Analyse- und Orchestrierungsunterbau fort:

1. Phase 13A ist abgeschlossen: Erkennung, technische Dokumenttypen, Source Extractors, Mappingprofile, Finding-IdentitÃ¤t sowie allgemeine Artefakt-, Processing- und Jobgrenzen sind konsolidiert und die Scannerpersistenz verwendet den Candidate-Pfad.
2. Phase 13B ist in Arbeit: Der sichere Ingestion-Unterbau, technische Policy-Identitaeten, versionierte ADMX-/Baselineanalysen, deterministisches Reprocessing, Environment Profiles, konservative Snapshotaggregation, typisierte Evaluation, fail-closed Finding Factory, Unified-Result-Read-Projektion sowie projektgebundene Review- und Orchestrierungsoberflaechen sind umgesetzt. Als naechste vertikale Etappe folgen fachlich kuratierte Policy-Regeln und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Kataloge; danach aktuelle snapshotbezogene Ergebnisdeduplizierung, weitere Preference-CSEs und Exportdetails. Ohne RSoP/GP Results bleibt die effektive Anwendung weiterhin ausdruecklich nicht verifiziert.
3. Erst nach verifizierter Phase 13B den kontrollierten Firmenbetrieb aus Phase 14 mit SSO, Rollen, HTTPS, Monitoring, Backup/Restore und Aufbewahrung fortsetzen.

Die technische Reihenfolge ist bis einschliesslich Phase 13A umgesetzt. Phase 13B baut auf dem verifizierten sicheren Ingestion-Unterbau auf und reicht inzwischen produktiv von der begrenzten Parser-/Workerverarbeitung ueber unveraenderliche Analyse-, Profil-, Aggregations- und Evaluationslaeufe bis zur streng evidenzgebundenen Finding Factory und ihrer gemeinsamen Unified-Result-Leseprojektion. Das Backend leitet projektgebundene Aktionsbereitschaft aus aktiven Revisionen und exakt passenden Referenzdaten ab; der Datahub fuehrt Environment-Profile-Anlage, Reprocessing, Aggregation, Evaluation und Finding Factory ueber die autoritativen idempotenten Services aus. Der produktive Regelkatalog bleibt bis fachlicher Kuratierung leer, und die vorhandenen Microsoft-Baselines bleiben ohne vollstaendige Windows-Inbox-ADMX-/ADML-Kataloge partial; dadurch erzeugt dieser reale Bestand weiterhin nur Review und keine Findings.

Aktualisierung vom 2026-08-04: Die persistente Worker-/Repository-Anbindung fuer technische Policy-Identitaeten, ADMX-Kataloge und Baseline-Einstellungsanalysen ist umgesetzt. Deterministisches GPO- und Baseline-Reprocessing mit Retry, Idempotenz und Supersession sowie die zugehoerigen Read-/Reprocess-APIs sind vorhanden. Als naechste vertikale Etappe folgen Snapshotaggregation, Konflikterkennung, `EnvironmentProfile` und die vollstaendigkeitsgesicherte Bewertungsengine; Inbox-ADMX-Kataloge und weitere Preference-CSEs bleiben getrennte Katalog-/Parserarbeit.
Aktualisierung nach dem Schritt-8-Vertikalschnitt vom 2026-08-04: Versionierte Environment Profiles und die konservative persistente Snapshotaggregation sind umgesetzt. Die naechste vertikale Etappe ist die getrennte Bewertungsengine mit typisierten Comparatoren, Dependency-/Override-Regeln, vollstaendigkeitsgesichertem Consensus, Evaluation Runs und Mehrquellen-Evidenz. Erst bestaetigte konfigurierte Abweichungen duerfen danach in das Unified Result Model projiziert werden; Inbox-ADMX-Kataloge, weitere Preference-CSEs und RSoP-Evidenz bleiben eigenstaendige Erweiterungen.
Aktualisierung nach dem Schritt-9-Vertikalschnitt vom 2026-08-04: Versionierte Evaluation Runs, Ergebnis- und Mehrquellen-Evidenzpersistenz sowie die konservative Bewertungsengine sind umgesetzt. Die Comparatorbibliothek ist typisiert; produktiv ist vorerst nur Equality explizit kataloggebunden. Als naechste vertikale Etappe folgen freigegebene Comparatorzuordnungen und Dependency-/Override-/Risikoregeln, ausdrueckliche Nichtanwendbarkeit sowie die streng getrennte Finding-Erzeugung und Unified-Result-Projektion. Windows-Inbox-ADMX-Kataloge, weitere Preference-CSEs, UI fuer Review-/Konflikt-/Katalogluecken und RSoP-Evidenz bleiben eigenstaendige Arbeitspakete.
Aktualisierung nach dem Schritt-10/11-Finding-Vertikalschnitt vom 2026-08-04: Finding Factory, persistente Policy-Finding-Occurrences, projektgebundene API und Unified-Result-Read-Projektion sind fuer ausschliesslich vollstaendig belegte `eligible` konfigurierte Abweichungen umgesetzt. Unvollstaendige Evidenz bleibt als Factory-Ablehnung ausserhalb des Resultmodells; Scope und Wirksamkeit bleiben ausdruecklich unbekannt beziehungsweise nicht verifiziert. Der aktive produktive Katalog bleibt bis zur fachlichen Freigabe setting-spezifischer Regeln leer und erzeugt daher weiterhin keine Findings. Als naechster Vertikalschnitt folgt die UI fuer Konflikte, Katalog-/Parserluecken, partielle Analysen und unaufgeloeste Identitaeten; danach folgen fachliche Regelkuratierung und vollstaendige Windows-Inbox-ADMX-Kataloge. Weitere Preference-CSEs bleiben ein getrenntes Arbeitspaket.
Aktualisierung nach dem Schritt-11-UI-Vertikalschnitt vom 2026-08-04: Konflikte, partielle Analysen, Katalog-/Parserluecken, unaufgeloeste Identitaeten, unbekanntes Targeting und Finding-Factory-Ablehnungen sind nun projektgebunden ueber ein typisiertes Readmodell, eine read-only API und den Datahub sichtbar. Findings und Review bleiben getrennt; Laufhistorie wird nicht als deduplizierter aktueller Kundenzustand bezeichnet, und die fehlende RSoP-/GP-Results-Evidenz bleibt sichtbar. Der unmittelbar folgende Orchestrierungsvertikalschnitt erweitert diese read-only Ansicht um bedienbare Environment-Profile-, Reprocessing-, Aggregations-, Evaluations- und Finding-Factory-Aktionen; fachlich kuratierte Regel- und Windows-Inbox-ADMX-Kataloge, weitere Preference-CSEs und Exportdetails bleiben getrennte Arbeitspakete.
Aktualisierung nach dem Schritt-11-Orchestrierungsvertikalschnitt vom 2026-08-04: Environment Profiles und ihre Revisionen koennen nun im Datahub angelegt werden; GPO-Reprocessing, Aggregation, Evaluation und Finding Factory sind ueber serverseitig abgeleitete Ready-/Review-only-/Completed-/Blocked-Aktionen bedienbar. Katalogauswahl, aktive Revisionen und technische Quellen werden im Backend-Readmodell bestimmt, waehrend jede Mutation ihre bestehenden Fachinvarianten erneut prueft. Als naechste Vertikalschnitte folgen die fachlich kuratierten Policy-Regeln und vollstaendigen Windows-Inbox-ADMX-Kataloge sowie danach aktuelle snapshotbezogene Ergebnisdeduplizierung, weitere Preference-CSEs und Exportdetails.

## 9. Bereits getroffene Architekturentscheidungen

| Datum | Entscheidung | BegrÃ¼ndung |
|---|---|---|
| 2026-08-24 | Die PostgreSQL-Zieladresse der Serverlaufzeit wird bei Einzelvariablen-Konfiguration aus `ASSESSOR_POSTGRES_HOST` gelesen; ohne Wert bleibt `127.0.0.1` der lokale Standard. Eine explizite `ASSESSOR_DATABASE_URL` behaelt Vorrang. | Container teilen keinen Loopback-Namensraum. Der Compose-Dienstname `postgres` muss deshalb bis in die Backend-Verbindungszeichenfolge gelangen, ohne den bestehenden lokalen Entwicklungsbetrieb zu brechen. |
| 2026-08-24 | Segmente und Kacheln folgen anwendungsweit einer gemeinsamen visuellen Grammatik: flacher abgerundeter Segmentcontainer mit einheitlichem Inset und Gap; darin gleichartige abgerundete Kacheln mit feiner Kontur, dezentem gemeinsamem Schatten und fester Inhaltsbreite. Statusfarbe bleibt Akzent oder Auswahlkontur. Unvollstaendige Zeilen werden nicht gestreckt. Jede Kachel begrenzt ihren Inhalt; Titel, Werte, Labels, Zusatztexte, Medien und Aktionen duerfen weder abgeschnitten, geklemmt, ellipsiert oder verborgen werden noch die Kachelgrenze ueberschreiten oder Nachbarkacheln ueberdecken. Notwendige Umbrueche erfolgen ausschliesslich an Wortgrenzen, Zahlen werden nicht getrennt. | Ein gemeinsamer Vertrag verhindert springende Geometrie und ansichtsspezifische Sonderkarten. Die harte Inhaltsgrenze schuetzt Nachbarkacheln, waehrend vollstaendige Inhalte die fachliche Lesbarkeit erhalten. Wenn Inhalt nicht vollstaendig passt, wird er intern neu angeordnet oder die Kachel verbreitert beziehungsweise responsiv neu angeordnet. |
| 2026-08-24 | Die neueste Nutzerkorrektur ersetzt fuer Finding-Titel die unmittelbar folgende fruehere 18-px-Reader-Entscheidung: Trefferlistentitel bleiben auf der 16-px-Inhaltsstufe, werden aber mit Medium 500 statt Semibold gesetzt; der Titel des geoeffneten Findings verwendet eine eigene 20-px-Detailtitelrolle mit Semibold. Die Finding-Abschnittsueberschrift bleibt 18 px, regulaere Matrixkacheln bleiben 16 px. | Die Trefferliste soll ruhig und scanbar bleiben, waehrend das geoeffnete Finding als primaerer Detailkontext klar hervortreten muss. Die getrennten semantischen Rollen loesen den Kontrast ohne die 16-px-Untergrenze fuer inhaltstragenden Text zu unterschreiten. |
| 2026-08-24 | Finding-Titel verwenden innerhalb von Work eine kompakte semantische Hierarchie: Reader-Titel und Finding-Abschnitt nutzen H3 mit 18 px; Titel in Trefferlisten und regulaeren Matrixkacheln nutzen H4 mit 16 px. Die globale H1-/H2-Hierarchie und die eigenstaendige Pathfinder-Micro-Card bleiben unveraendert. | Lange Scannerbezeichnungen benoetigen in Listen und Kacheln sonst zu viele Zeilen und verdraengen Status sowie Metadaten. Die vorhandenen Typografietokens erhalten die Lesbarkeitsuntergrenze von 16 px fuer inhaltstragenden Text und vermeiden lokale Sondergroessen. |
| 2026-08-24 | Alle Donutdiagramme verwenden einen gemeinsamen visuellen Vertrag: vollstaendige neutrale 360-Grad-Ringspur, farbiger Wertbogen im Uhrzeigersinn ab 12 Uhr, flache Bogenenden, gemeinsame Strichstaerke und eine mittige Primaerkennzahl mit kleiner Einheit auf derselben Grundlinie. Mehrteilige Verteilungen behalten ihre fachlichen Farbsegmente innerhalb derselben Geometrie. | Eine gemeinsame Form verhindert wechselnde Gauge-, Ring- und Prozentdarstellungen zwischen Datahub, Dashboard und Sidebar. Die neutrale Restspur macht den verbleibenden Anteil sichtbar; die zentrale Kennzahl bleibt unabhaengig von Kartenbreite und Legende unmittelbar lesbar. |
| 2026-08-24 | ASSESSOR verwendet anwendungsweit die lokal gebuendelte variable Schriftfamilie Inter. Die verbindliche Hierarchie ist H1 56 px/600, H2 32 px/600, H3 18 px/600, H4 und Fliesstext 16 px mit 600 beziehungsweise 400, UI-Labels und Buttons 14 px, Metadaten und Tabellenkoepfe 13 px sowie kompakte Finding-Badges 12 px. Uppercase bleibt Tabellenkoepfen und kurzen technischen Kennzeichnungen vorbehalten; regulaere Ueberschriften und Feldbezeichnungen verwenden Title Case. | Eine lokal gebuendelte Einzelschrift verhindert plattformabhaengige Fallbacks und visuelles Springen. Semantische Rollen statt lokaler Einzelwerte schaffen nachvollziehbare Abstufungen, waehrend 16 px fuer inhaltstragenden Text die bestehende Lesbarkeitsgrenze bewahrt und dichte Finding-Zustandszeilen visuell hinter den Titel treten. |
| 2026-08-24 | HTML-Berichte oberhalb von 1 MiB werden in Browser- und Backendlaufzeit direkt mit dem begrenzten lexikalischen Extraktor verarbeitet; kleinere Dokumente duerfen weiterhin den DOM-Adapter verwenden. Die isolierte Worker-Zeitgrenze von 30 Sekunden und alle bestehenden Ressourcenlimits bleiben unveraendert. | Scanner-HTML kann schon deutlich unter der bisherigen 4-MiB-Schwelle in eine DOM-Struktur expandieren, die das Worker-Zeitbudget ueberschreitet. Der vorhandene lineare Extraktor bewahrt Tabellen-, Locator-, Sicherheits- und Source-Extractor-Vertraege, ohne einen vollstaendigen DOM-Baum aufzubauen oder die Schutzgrenze aufzuweichen. |
| 2026-08-23 | Im Pathfinder gerenderte Knoteninformationen sind das eigenstaendige Designelement `Pathfinder Micro Card` und keine allgemeine Matrix-/Finding-TileCard. Der Vertrag besitzt die Varianten `finding` und `relation`; Category bleibt eine groessere Relation-Auspragung. Bestaetigte Geometrie, Typografie und Radien sind eigene Tokens beziehungsweise Konstanten, und die gesamte Komposition skaliert unveraendert mit Faktor 0,4 im Graphkoordinatensystem. | Graphkarten beschriften Knoten und muessen Beziehungen sichtbar lassen. Eine Uebernahme allgemeiner Kartenmasse oder nachtraegliche kamerainverse Typografie wuerde die bestaetigte Darstellung verdecken beziehungsweise ihre inneren Proportionen veraendern. Ein eigener Vertrag erlaubt gezielte Regressionen, ohne regulaere TileCards ausserhalb des Pathfinders zu beeinflussen. |
| 2026-08-23 | Scanner-Kontext wird zweistufig gespeichert: quellengetreue Reportabschnitte mit Prosa und Tabellen sowie typisierte EnvironmentObservations mit stabilen Schluesseln und explizitem Erfassungszustand. Findings bleiben ein getrennter Vertrag. | Nur die Rohstruktur verhindert Informationsverlust bei neuen PingCastle-Versionen; nur typisierte Fakten erlauben zugleich belastbare Dashboard-, Result-DB-, LLM- und Toolabfragen. Ein Zustandsfeld trennt echte Abwesenheit von leerer Ausgabe, fehlender Berechtigung, Lizenzgrenze und Parserluecke. |
| 2026-08-23 | Typisierte Scanner-EnvironmentObservations werden als eigener Unified-Result-Quelltyp `environment-observation` projiziert und niemals als Finding umgedeutet. Die Projektion ist ein abgeleitetes Readmodell ueber die bestehende Environment-Persistenz; sie bewahrt Original-/Normalwert und vollstaendige Provenienz, bietet eigene Environment-Facetten und nimmt diese Zeilen aus Finding-spezifischen Facetten heraus. | Result DB, Exporte, LLMs und weitere Tools benoetigen einen gemeinsamen timeslotgebundenen Zugriff, ohne aus DFL, OS, PKI, Trusts oder Coverage kuenstliche Schweregrade, IOEs, Abweichungen oder Reviews abzuleiten. Ein Readmodell vermeidet Datenkopien und eine weitere Migration, waehrend der getrennte SourceKind den Vertrag eindeutig haelt. |
| 2026-08-23 | PingCastle Environment Context erhaelt einen eigenen Profilversionsschnitt 1.3.0 bei unveraendertem kanonischem Finding-Kompatibilitaetsschluessel `pingcastle-canonical-v1.1`. Profil 1.2.0 bleibt append-only historisch erhalten und wird als reimportbeduerftig bewertet; 1.3.0 ist der einzige aktuelle Stand. | Die Context-Erfassung war zuvor unter derselben sichtbaren Profilnummer wie contextlose Importe ausgerollt. Versionsgleichheit konnte deshalb einen technisch alten Backendimport faelschlich als `Current` markieren. Der Profilversionsschnitt macht die Datenfaehigkeit deterministisch, ohne Findings umzudeuten oder Altdaten umzuschreiben. |
| 2026-08-24 | PingCastle-Profil 1.4.0 und Extractor 2.1.0 verwenden fuer bekannte Environment-Subjects die normalisierten sichtbaren PingCastle-Bezeichnungen und bilden jeden sichtbaren Environment-Unterpunkt als Punktpfad unter seinem Hauptbereich ab. Der Extractor bindet Tabellen ueber den unmittelbar vorangehenden H2-Berichtstitel, ordnet leere Tabellen ueber Row Count/Presence ein und erzeugt fuer Heading-only-Unterpunkte ausschliesslich eine quellentreue Presence-Beobachtung. Prosa-Fakten fuer Entra ID Configuration, Backup, LAPS, WEF und krbtgt erhalten explizite Pfade; Finding-Regeldetailbereiche bleiben ausgeschlossen. Profil 1.3.0 bleibt append-only historisch und wird reimportbeduerftig; der Finding-Kompatibilitaetsschluessel bleibt `pingcastle-canonical-v1.1`. | Die vorherige ASSESSOR-Taxonomie `active-directory-*` und reine Section-Key-Klassifikation entsprachen weder der sichtbaren Berichtshierarchie noch Unterpunkten ohne gefuellte Tabelle. Punktpfade erhalten diese Hierarchie im flachen Subject-Feld, waehrend Originalwerte, Tabellen-/Heading-Provenienz und der generische Fallback erhalten bleiben und keine Finding-Semantik in Environment Context gelangt. |
| 2026-08-23 | Geoeffnete Pathfinder-Kacheln werden in einer eigenen, nach Kanten und Knoten gerenderten SVG-Kartenebene dargestellt. Die Platzierung waehlt anhand des sichtbaren Raums links oder rechts des Bezugspunkts, haelt einen festen Abstand, bleibt innerhalb der Graphflaeche und verschiebt mehrere Karten kollisionsfrei vertikal. Finding-Kacheln reservieren feste Bereiche fuer maximal fuenf Titelzeilen, zwei vollstaendige Badgezeilen und die rechte Aktionsspalte; mehr als vier Badges werden fachlich priorisiert und mit `+N` zusammengefasst. | SVG-Malreihenfolge und DOM-Nachbarschaft hatten spaeter gezeichnete Punkte vor Karten gelegt. Eine eigene letzte Ebene beseitigt diesen Fehler deterministisch. Feste Inhaltsbereiche verhindern teilweise abgeschnittene Badges; ein sichtbarer Ueberlaufzaehler erhaelt die Information, ohne die bestaetigte Kachelgroesse oder das gemeinsame Zoomverhalten zu veraendern. |
| 2026-08-23 | Die bildlich bestaetigte Pathfinder-Kachel verwendet eine feste, vollstaendige Vorlage statt der zuvor verdichteten 148-mal-72-px-Findingstruktur: Findings werden intern auf 240 mal 176 px, Rollen auf 148 mal 72 px gesetzt und beide einmalig mit dem konstanten Graphfaktor 0,4 eingebettet. Danach skaliert die komplette Komposition ausschliesslich gemeinsam mit der SVG-Kamera. CIS-Hierarchie-Badges gehoeren wieder zur Finding-Kachel. | Das Negativbeispiel zeigte, dass die kleine logische Findingflaeche bei starker Graphvergroesserung Titel und Metadaten uebergross und abgeschnitten darstellte. Eine feste ausreichend grosse Vorlage bewahrt Titel, Status, Gewicht, CIS-Kategorien und Aktionen; der konstante Einbettungsfaktor veraendert sich beim Zoomen nicht und laesst die Kachel wie ein Bild skalieren. Diese Bildreferenz ersetzt die unmittelbar vorherige Entscheidung, CIS-Badges in der Pathfinder-Kachel auszulassen. |
| 2026-08-23 | Der Backend-Verbindungszustand steht in jedem Bereichsheader unmittelbar vor dem Clientnamen und wird ohne Text oder Pillenrahmen als Paar aus einem roten und einem gruenen 9-mal-9-px-Quadrat dargestellt. Gruen ist bei bestaetigter Verbindung voll sichtbar; Rot ist bei fehlender oder noch ungepruefter Verbindung voll sichtbar, der jeweils andere Zustand bleibt gedimmt. | Die kompakte binaere Anzeige bewahrt den technischen Zustand, ohne den ohnehin knappen rechten Headerbereich mit `Server connected` zu belegen. Ein dauerhaftes Rot-/Gruen-Paar macht beide Bedeutungen wiedererkennbar; ARIA-Label und Tooltip erhalten die textliche Aussage fuer assistive Technik. |
| 2026-08-23 | Die neueste Nutzerkorrektur ersetzt die inverse Kamerakompensation der Pathfinder-Kachelinhalte: Jede 148-mal-72-px-Kachel ist eine eingefrorene Komposition. Flaeche, Text, Hexagon, Badges, Aktionen, Abstaende und Konturen skalieren gemeinsam und ausschliesslich mit der SVG-Graphkamera. CIS-Hierarchie-Badges bleiben in Work und am Finding erhalten, werden in der Pathfinder-Kachel jedoch nicht dupliziert, weil dieselbe Hierarchie dort bereits als verbundene Kategorie-Knoten sichtbar ist. | Die Kachel soll sich beim Zoomen wie ein einziges Bild verhalten; getrennte Gegentransformationen veraendern ihre innere Proportion. Das Weglassen der redundanten CIS-Badges verhindert innerhalb der festen Grundflaeche abgeschnittene Elemente, ohne die Kategorien aus Filter, Finding oder Graphbeziehungen zu entfernen. |
| 2026-08-23 | Work definiert fuer alle bestehenden und kuenftigen abgerundeten Hauptpanels einen Aussenrand-zu-Inhalt-Abstand von 20 px auf jeder Seite. Der kanonische Token ist `--panel-content-inset`; jede Ansicht wendet ihn genau einmal am Root an, auch responsiv. | Ein gemeinsamer Root-Inset verhindert springende Inhaltskanten zwischen Bereichen und vermeidet doppelte Abstaende in Split-Panes. Die Projektregel macht den Standard fuer neue Panels verbindlich statt nur implizit im aktuellen CSS. |
| 2026-08-23 | Die Pathfinder-Titelgroesse von 16 px bezeichnet die sichtbare Bildschirmgroesse. Der gesamte UI-Inhalt einer Kachel wird invers zur Kamera skaliert, waehrend die Kachelflaeche selbst proportional zoomt. | Ein blosser logischer `font-size: 16px` wird durch die SVG-Kamera vergroessert und erscheint bei starkem Zoom deutlich groesser als der zoomstabile Text neben dem Punkt. Gemeinsame Inhaltskompensation haelt auch Symbole, Badges und Aktionen im geforderten Verhaeltnis. |
| 2026-08-23 | Jeder Bereichs-Header zeigt bei vorhandenem Clientkontext den Clientnamen als ungerahmten rechtsbuendigen 16-px-Text. Im Data-Hub-Detail hat der dort geoeffnete Client Vorrang vor dem aktiven Work-Client. | Der Clientkontext muss unabhaengig vom Bereich sofort sichtbar sein. Die Detailprioritaet verhindert einen falschen Namen, wenn Stammdaten eines anderen Clients verwaltet werden, ohne dessen Timeslot zu oeffnen. |
| 2026-08-23 | Die neueste Nutzerkorrektur ersetzt die Pathfinder-Finding-Grundflaeche von 240 mal 176 px: Finding- und Rollenkacheln verwenden gemeinsam 148 mal 72 px und 16-px-Titeltext entsprechend der Punktbeschriftung. Die Matrixkachel wird ausschliesslich im Pathfinder kompakt angeordnet. | Gleichartige ausgewaehlte Graphpunkte sollen visuell dieselbe Kachelgroesse erhalten. Die kontextspezifische Verdichtung verhindert, dass diese Entscheidung die inhaltsreichere regulaere Matrixansicht verkleinert. |
| 2026-08-22 | Pathfinder-Rollenkacheln verwenden 148 px logische Breite und trennen Titel nicht innerhalb einzelner Woerter; regulaere Umbrueche an Wortgrenzen und die bestehende Zeilenbegrenzung bleiben erhalten. | Die bisherige 116-px-Kachel bot nach Icon, Abstand und Innenrand selbst fuer kurze Kategorien wie `Anomalies` zu wenig Platz und `overflow-wrap: anywhere` erzeugte einen fachlich unnoetigen Wortbruch. |
| 2026-08-22 | Path Snapshots wenden im Workbereich einen eigenen temporaeren Finding-ID-Scope an. Der Pathfinder bleibt bei Bereichswechseln montiert und passt die Kamera bei der Rueckkehr nur nach einer geaenderten Graphsignatur neu ein. | Ein Path Snapshot beschreibt eine konkrete Finding-Nachbarschaft und darf weder Workspace- noch Reviewzustand vortaeuschen. Das Erhalten derselben Graphinstanz bewahrt Kamera und Interaktion exakt; die Signaturpruefung erlaubt zugleich ein korrektes Refit nach echten Filter- oder Datenwechseln. |
| 2026-08-22 | Die neueste Nutzerkorrektur ersetzt die zwischenzeitliche inverse Zoomtransformation der Pathfinder-Kacheln: Finding- und Rollenkacheln skalieren proportional mit der Graphkamera und duerfen bei weitem Herauszoomen unter lesbare Badgegroesse schrumpfen. Die Finding-Grundeinheit ist 240 mal 176 px; Punkttexte bleiben zoomstabil. | Eine bildschirmstabil grosse Kachel dominiert im herausgezoomten Netz und verdeckt Beziehungen. Proportionale Skalierung bewahrt die raeumliche Bedeutung; die groessere logische Hoehe verhindert zugleich abgeschnittene Metadaten, ohne die Darstellung bei weitem Zoom wieder aufzublaehen. |
| 2026-08-22 | Alle ringmarkierten Nicht-Finding-Knoten im Pathfinder verwenden rollenunabhaengig den gemeinsamen Token `--graph-relation: #9333EA`; Finding-Knoten verbleiben auf der zentralen Severity-Skala. | Der Ring kennzeichnet bereits die gemeinsame semantische Rolle als Struktur- beziehungsweise Beziehungsknoten. Eine einheitliche violette Farbe macht diese Gruppe sofort erkennbar, ohne Kategorien, Frameworkbeziehungen oder Ziele mit einer Severity zu verwechseln. |
| 2026-08-22 | Der Pathfinder-Kopf visualisiert ausschliesslich aktive nutzergesteuerte Filter als dynamische Spur aus gelbem Rechtsdreieck, Filterbezeichnungen und gelben Plus-Trennern. Die Reihenfolge folgt Suche, sichtbaren Facetten und `My Workspace`; inaktive beziehungsweise graphintern feste Filter erscheinen nicht. | Der grosse Bereichskopf soll den aktuellen Analysekontext auf einen Blick zeigen, ohne den Filterzustand zu duplizieren oder den festen Deviation-Scope als veraenderbare Auswahl misszuverstehen. Die Ableitung aus denselben Facetten-IDs und Quellwerten verhindert Abweichungen vom Panel. |
| 2026-08-22 | Karten und Punkttexte besitzen im Pathfinder getrennte lokale Darstellungsschalter. `Labels` bezeichnet die Kacheln gepinnter Knoten und startet eingeschaltet; `Text` bezeichnet die Beschriftungen neben allen Punkten und startet ausgeschaltet. | Kacheln liefern Details fuer bewusst aktivierte Punkte, waehrend die vielen dauerhaften Punkttexte das Netzwerk verdichten. Unabhaengige Schalter erlauben jede Kombination, ohne Auswahl-, Pfad- oder Filterzustand umzudeuten. |
| 2026-08-22 | Der Pathfinder verwendet als sichtbare Quellenwahl ausschliesslich die gemeinsame dynamische Facette `Source: Scan`; der separate Blattselector wird dort nicht gerendert. | Nutzer waehlen fachliche Scannerlaeufe und nicht technische Import-/Detailblaetter. Die bestehende Work-Facette bewahrt Scannername, Zeitstempel, Zaehler und gemeinsamen Filterzustand ohne doppelte Graphlogik. |
| 2026-08-22 | Der Graphbereich traegt in Navigation und Anwendungskopf den Produktnamen `Pathfinder`; der technische AppArea-Schluessel bleibt `graph`. | Ein reiner sichtbarer Produktname darf bestehende Navigation, CSS-Selektoren, Snapshot-Wiederherstellung oder internen Zustand nicht durch eine unnoetige technische Umbenennung migrieren. |
| 2026-08-22 | CIS-CAT-Results unterscheiden drei semantische Zeilenrollen: `Criterion` als gruene Sollbedingung, vom Bericht als ausgewertet markierte Istwerte als roten Verstoss und den ausdruecklichen Hinweis auf fehlende Systemelemente weiterhin als blaue Information. Die Muster und der Ton der ausgewerteten Zeile sind Teil der deklarativen CIS-CAT-Praesentation; die gemeinsame Results-Komponente rendert nur die abstrakte Rolle. | Criterion und beobachteter Istwert tragen entgegengesetzte Bedeutung und duerfen nicht dieselbe Evidenzfarbe verwenden. Profilsteuerung bewahrt die Parser-/Praesentationsgrenze und verhindert, dass generische oder andere Werkzeugtabellen allein wegen eines Wortes oder Importmarkers fachlich umgedeutet werden. |
| 2026-08-22 | Ein Graph-Snapshot ist ein `Path Snapshot`: Er speichert die Menge gepinnter Graphknoten und deren direkte Ein-Schritt-Nachbarschaft zusaetzlich zum gemeinsamen View-Zustand. Normale und Path Snapshots teilen pro Client/Timeslot genau sieben Speicherplaetze; Path Snapshots werden in Work rot umrandet und oeffnen beim Anwenden wieder den Graphen. | Der fachliche Wert des Graph-Snapshots liegt im ausgewaehlten Beziehungspfad, nicht nur in Suche und Facetten. Ein gemeinsamer Speicher bewahrt die bestehende Scope-Grenze und macht die knappe Snapshotleiste vorhersehbar; Typkennzeichnung verhindert, dass Work-Ansichten und Graphpfade visuell verwechselt werden. |
| 2026-08-22 | Das Graph-Panel verwendet fuer `My Workspace` und Ansichts-Snapshots dieselben AppProvider- und `ViewBookmarks`-Vertraege wie Work. Die Checkbox ist ohne markierte Findings deaktiviert; gespeicherte Ansichten bleiben am bestehenden Client-plus-Timeslot-Scope gebunden. | Workspace-Markierungen und Ansichtsaufnahmen sind fachlicher Arbeitszustand und keine Graph-Eigenschaft. Eine zweite Graph-spezifische Ablage oder Filterimplementierung koennte von Work abweichen und Snapshots zwischen Erhebungsstaenden vermischen. |
| 2026-08-22 | CIS-CAT-Regelnummern werden praesentativ und profilgebunden als Hierarchie interpretiert: Die vollstaendige Nummer bleibt Finding-ID, alle echten numerischen Eltern werden als `CIS n`, `CIS n.m` und gegebenenfalls weitere Zwischenstufen abgeleitet. Die Ableitung speist Graph, dynamische Facette, Finding-Reader und Matrix-/Graphkachel, ohne Quellfelder oder kanonische Persistenz zu veraendern. | CIS-CAT liefert in den vorhandenen Assessment-Results keine eigene Category-Spalte, die Nummern tragen aber die Benchmarkstruktur. Eine gemeinsame reine Ableitung verhindert isolierte Findings und haelt Filter und Darstellung konsistent; numerische Labels vermeiden erfundene Abschnittsnamen, die je Benchmark und Version variieren koennen. |
| 2026-08-22 | Finding-Vorschauen im Phase-7-Netzwerk verwenden direkt den gemeinsamen Matrix-`TileCard` mit Originaltitel, Severity-Hexagon, Outcome, Badges, Bookmark und Results-Aktion. Die Finding-Kachel verbleibt im Graph-Koordinatensystem und skaliert proportional mit der Kamera; nur die reduzierten Rollen-Vorschauen und reinen Textlabels bleiben zoomstabil. | Matrix und Graph sollen dasselbe Finding nicht mit zwei unterschiedlich nachgebauten Kacheln darstellen. Die Wiederverwendung verhindert Darstellungsdrift und erhaelt alle bestehenden Kachelaktionen; proportionale Skalierung entspricht der raeumlichen Graphmetapher und der ausdruecklichen Nutzervorgabe. |
| 2026-08-22 | Finding-Punkte im Phase-7-Netzwerk verwenden direkt die bestehende Severity-Farbskala; `unknown` erhaelt eine eigene neutrale blaue Graphfarbe statt Grau. Beim Hover oder Pin eines Knotens werden nur seine unmittelbar inzidenten Kanten rot und staerker hervorgehoben, wobei Hover den zuletzt gepinnten Knoten temporaer uebersteuert. | Punktfarbe und direkte rote Pfade vermitteln zwei getrennte Informationen: Risiko des Findings und aktuelle Nachbarschaft im Netz. Eine eigene Unknown-Farbe vermeidet die vom Nutzer ausgeschlossene graue Severity-Darstellung, ohne `unknown` einer fachlich falschen bekannten Severity zuzuordnen. |
| 2026-08-22 | Die Phase-7-Graphprojektion bildet vorhandene fachliche Beziehungen statt eines primaeren Sternzentrums ab: Jedes Finding wird mit allen Kategorien, allen expliziten ATT&CK-Taktiken beziehungsweise Techniken sowie allen D3FEND-Zuordnungen verbunden. Kategorie-, D3FEND-, Technik- und Taktikknoten sind reine praesentative Ableitungen aus den unveraenderten Quellfeldern; Severity bleibt eine Darstellungseigenschaft und kein Beziehungsersatz. | Die bisherige Reduktion auf `primaryTactic` liess gueltige Sekundaerbeziehungen und damit unter anderem `Lateral Movement` optisch leer erscheinen; das Ignorieren der Kategorie- und D3FEND-Felder erzeugte isolierte Sternhaufen. Eine vollstaendige, deterministische Projektion zeigt die tatsaechliche Mehrfachzuordnung, ohne Import-, Normalisierungs- oder Persistenzdaten umzuschreiben. |
| 2026-08-22 | Die neuere Nutzeranforderung ersetzt fuer normale Client-Arbeitsansichten den zuvor ausdruecklich erhaltenen Modus `All timeslots`: Ein konkreter Timeslot mit seiner vollstaendigen ScanRun-Menge ist der gemeinsame Single Point of Truth fuer Work, Graph, Dashboard und Result DB. Fehlender Scope darf in Result DB und Graph nicht projektweit aufgehen; der Work-Selector waehlt stattdessen den neuesten konkreten Timeslot. | `undefined` darf nicht gleichzeitig „noch kein Timeslot gesetzt“ und „bewusst den gesamten Client aggregieren“ bedeuten. Fail-closed-Darstellung verhindert vermischte Erhebungsstaende und haelt alle Ansichten auf derselben fachlichen Grundmenge. |
| 2026-08-22 | Maximierte Result-Tabellen verwenden vor jeder manuellen Anpassung ihre ungebrochene intrinsische Inhaltsbreite statt einer Mindestbreite von 100 Prozent. Eine manuell gesetzte Spaltenbreite hat danach Vorrang. | Die Maximierung stellt Arbeitsraum bereit, ist aber kein Grund fuer kuenstlich breite, visuell leere Tabellen. Inhaltsbreite ohne Zeilenumbruch erzeugt eine kompakte lesbare Ausgangsdarstellung; echte Ueberbreite bleibt sicher horizontal scrollbar. |
| 2026-08-22 | Die neuere Vorgabe ersetzt die Beschraenkung der Tabellen-Spaltengriffe auf maximierte Result-Fenster: Griffe sind in jedem nicht minimierten, frei stehenden Result aktiv. Ausschliesslich das im Findings-Cluster eingereihte aktive Result und die minimierten Cluster-Slots bleiben unveraenderbar. | Die fachliche Arbeitsfreiheit haengt vom freien Fensterstatus und nicht von der Maximierung ab. Im Cluster teilen aktives Result und minimierte Slots dagegen eine kontrollierte Geometrie; dort waeren individuelle Tabellenbreiten hinderlich und koennten die Stapeldarstellung destabilisieren. |
| 2026-08-22 | Im Client-Detail gehoert `Open` in den linken Timeslot-Navigatorkopf. Der rechte Dokumentkopf enthaelt im Lesemodus den neutralen/destruktiven Textbutton `Delete client` und die gelbe Primaeraktion `Edit`; im Bearbeitungsmodus werden beide durch einen gleich breiten `Save`-Button ersetzt. Bleistiftaktion und separater Delete-Footer entfallen. | Die Aktionsposition folgt ihrem fachlichen Ziel: `Open` wirkt auf die linke Timeslot-/Scan-Auswahl, Edit und Delete auf das rechte Client-Dokument. Das Ausblenden der destruktiven Aktion waehrend der Eingabe verhindert einen Fehlklick neben Save; identische Mindestbreiten vermeiden einen Positions- und Groessensprung beim Zustandswechsel. |
| 2026-08-22 | Fortschritt im Import-Pop-up wird durch vier quadratische Positionen mit einer umlaufenden roten Aktivmarkierung dargestellt; der bisherige kreisfoermige Spinner entfaellt. Bei `prefers-reduced-motion` bleibt der Zustand statisch. | Die diskrete Viererfolge entspricht der gewuenschten Produktsprache, bleibt als rein praesentativer Status vom Importprozess getrennt und vermeidet eine erzwungene Bewegung fuer Nutzer mit reduzierter Animationseinstellung. |
| 2026-08-22 | Importvorschauen sind flache, rahmenlose Dokumentabschnitte. Dubletten werden als englischer Hinweis mit der Ueberschrift `Duplicate found` und umbrechendem Fliesstext dargestellt; Auswahl und Aktionen bleiben unveraendert. | Die Vorschau soll Informationen und bewusste Bestaetigung priorisieren, nicht jede Datei als eigene Karte inszenieren. Ein kontrollierter Textumbruch verhindert horizontales Scrollen bei langen Dateinamen, Hashes oder Quellenhinweisen. |
| 2026-08-22 | Jede Client-Karte bietet neben dem getrennten `Manage` eine direkte gelbe `Open`-Aktion fuer den neuesten scannergebundenen Timeslot. Client-Karten ohne Scan-Daten zeigen die Aktion deaktiviert. | Stammdatenpflege und operative Arbeit sind verschiedene Ziele. Der direkte Einstieg spart Auswahl- und Detailnavigation, waehrend die explizite ScanRun-Menge die bestehende Timeslot-Kontextgrenze bewahrt. |
| 2026-08-22 | Client und Work-Timeslot bilden getrennte Zustandsgrenzen: Der Client bestimmt die Datenzugehoerigkeit, die sortierte ScanRun-Menge des Timeslots bestimmt Snapshot-Lesezeichen und lokale My-Workspace-/Review-Markierungen. Filterdefaults werden bei Timeslot- und Blattwechsel aus dem jeweils neu aktiven Werkzeugprofil geladen; ein gemischtes Aggregat vereinigt die Statusfilter aller enthaltenen bekannten Profile, Einzelblaetter verwenden ihr exaktes Profil. | Gleiche Clients koennen fachlich unterschiedliche Stichtage und Toolsets enthalten. Projektweit geteilte lokale Arbeitseinstellungen wuerden Markierungen und gespeicherte Ansichten zwischen diesen Staenden vermischen; beibehaltene oder rein generische Profilfilter koennten im neuen Toolset fehlen beziehungsweise eine falsche Treffermenge darstellen. |
| 2026-08-22 | Der aktuell in Work geladene Timeslot ist auch die Querygrenze der Result-DB. Seine eindeutige ScanRun-Menge wird neben der Client-ID an Zeilen-, Facetten-, Local- und PostgreSQL-Abfragen weitergereicht; nur `All timeslots` laesst diesen Filter bewusst weg. | Result-DB, Work, Snapshots und eine spaetere LLM-Anreicherung muessen denselben fachlichen Stichtag meinen. Ein reiner Clientfilter wuerde Findings verschiedener Erhebungsstaende vermischen und damit Auswertung sowie Anreicherung verfälschen. |
| 2026-08-22 | Diskrete Work- und Result-DB-Facetten zeigen ausschliesslich Werte mit einer Trefferzahl groesser null unter dem aktuellen Timeslot-, Such- und Fremdfilterkontext. Der eigene Facettenfilter wird fuer Alternativzaehlungen ausgenommen; unmoeglich gewordene Work-Auswahlen werden automatisch bereinigt. | Nulloptionen bieten keine ausfuehrbare Einschraenkung und vergroessern die Filterlisten ohne Nutzen. Das Ausnehmen der eigenen Facette erhaelt den Wechsel zwischen noch erreichbaren Alternativen; die Bereinigung verhindert unsichtbare Restfilter. |
| 2026-08-22 | Die erste Work-Kopfzeile darf Controls nicht mehr zur Unlesbarkeit zusammenschieben: Workspace-Button, View-Tabs, Exportgruppe und direkte Aktionsbuttons sind nicht schrumpfbar; bei echter Unterbreite ist nur diese Werkzeugzeile horizontal erreichbar. Die dynamische Filtermenge bleibt ausschliesslich profil- und datengetrieben. | Ein abgeschnittener Button ist keine sinnvolle responsive Reduktion. Inhaltsbreite plus begrenzter horizontaler Rueckfall erhaelt jede Funktion, ohne fuer Werkzeuge mit wenigen Facetten kuenstliche Filter oder fuer umfangreiche Profile eine zweite Fachlogik einzufuehren. |
| 2026-08-22 | Spaltenbreiten koennen in maximierten Result-Tabellen lokal per Pointer oder Tastatur veraendert werden; Doppelklick beziehungsweise Enter fuehrt ein auf 72 bis 720 px begrenztes Auto-Fit anhand des laengsten ungebrochenen Zellinhalts aus. Nicht maximierte Tabellen bleiben unveraendert, Breiten werden nicht persistiert. | Die maximierte Ansicht besitzt den notwendigen Arbeitsraum fuer tabellarische Detailanalyse. Ein gemeinsamer React-Baustein haelt verknuepfte Blaetter und Markdown-Tabellen konsistent; Begrenzung und bestehendes horizontales Scrollen verhindern, dass einzelne Extremwerte die gesamte Arbeitsflaeche unbedienbar machen. |
| 2026-08-22 | Timeslots sind beim Oeffnen der Client-Ansicht standardmaessig eingeklappt. Der neueste Timeslot bleibt weiterhin vorausgewaehlt, bis der Nutzer diese Auswahl aendert. | Auswahl und Detailoffenheit sind getrennte Zustaende: Die Vorauswahl erhaelt den bestehenden Open-Workflow, waehrend die geschlossene Standardansicht den Navigator ruhig und kompakt haelt. |
| 2026-08-22 | Die neueste Nutzerkorrektur ersetzt die unmittelbar vorherige Entdoppelung des Mandantennamens: Die rechte Client-Information enthaelt wieder `Name`, `Consultant` und `Remarks`, jeweils als kleine Bezeichnung direkt oberhalb des groesseren linksbuendigen Werts. Der linke Mandantenname bleibt dabei statische Identitaetsanzeige. | Die rechte Seite soll als vollstaendiges, ruhiges Stammdatendokument lesbar sein. Die unmittelbare vertikale Zuordnung beseitigt die zuvor zu grossen Abstaende und die umgekehrte Groessenhierarchie; die ausdrueckliche neuere Nutzeranweisung hat Vorrang vor der vorherigen Entdoppelungsentscheidung. |
| 2026-08-22 | Der Mandantenname wird in der Client-Ansicht nur im linken Identitaetskopf dargestellt. Bei Neuanlage oder aktivem Editmodus wird dieser Titel selbst zum erforderlichen, dem bestehenden Formular zugeordneten Eingabefeld; die rechte Readerflaeche enthaelt nur Consultant und Remarks. | Die doppelte Anzeige desselben Identitaetswerts erzeugt keine neue Information und stoert die klare Master-Detail-Hierarchie. Die Verlagerung des bestehenden Editors an die sichtbare Identitaet erhaelt die Bearbeitungsfunktion ohne eine zweite Namensdarstellung. |
| 2026-08-22 | Die Shell-Ueberschrift des Data-Hub-Bereichs ist kontextabhaengig: `Data Hub` fuer die Hauptansicht, `Client` fuer Neuanlage und Mandantendetail. Die Detailkomponente meldet nur ihren vorhandenen Formzustand; beim Unmount wird der Kontext zurueckgesetzt. | Der globale Bereichsname darf in einer objektbezogenen Detailansicht nicht dieselbe Hierarchieebene wie die Uebersicht behaupten. Ein schmaler praesentativer Callback haelt Shelltitel und lokales UI synchron, ohne Mandantendaten oder Navigation in die Shell zu verschieben. |
| 2026-08-22 | ScanRun-Readiness im Mandantendetail wird an der bestehenden Work-Projektionsgrenze bestimmt: spezifisches Werkzeug plus kanonische Occurrences = `Recognized`, generisches Werkzeug plus kanonische Occurrences = `Generic`, fehlende Occurrences oder fehlender Run = `Not viewable`. Nicht darstellbare beziehungsweise nicht pruefbare Runs werden nicht an `Open` weitergereicht. Delete-Aktionen verwenden ausgeschriebene Textbuttons statt Papierkorb-Icons. | Ein gespeicherter Datei- oder ScanRun-Nachweis belegt nur Importhistorie, nicht Darstellbarkeit. Die kanonischen Occurrences sind die vorhandene plattformneutrale Mindestgrenze der Work-Projektion und verhindern einen erfundenen Erfolgsstatus. Textbuttons sind eindeutig, zugaenglich und folgen der ausdruecklichen dauerhaften Nutzerregel fuer destruktive Aktionen. |
| 2026-08-22 | Im Mandantendetail werden Stammdaten im Lesemodus als echte einspaltige Readerabschnitte statt als Read-only-Formularfelder dargestellt. Auswahlcheckboxen und Auswahlmarker dieser Ansicht verwenden den bernsteinfarbenen Aktivton; die Auswahlflaeche bleibt neutral. Beide Importaktionen sind gelbe Primaeraktionen, Delete bleibt neutral. | Das Finding-Referenzmuster verlangt Abschnittsueberschrift und Fliesstext untereinander. Read-only-Inputs erzeugen falsche Formaffordanz und wurden durch eine Altregel zweispaltig verschoben. Bernstein trennt aktive Auswahl und Hauptaktionen klar von neutralem Inhalt, ohne die ausdruecklich abgelehnte violette Markierung fortzufuehren. |
| 2026-08-22 | Die Nutzerkorrektur ersetzt fuer das Mandantendetail das proportionale 44/56-Raster durch die bestehende Work-/Reports-Listenbreite `clamp(420px, 27vw, 520px)`. Rechts steht eine transparente, links ausgerichtete Reader-Dokumentflaeche mit maximal 794 px Breite; sie verwendet Abschnittsueberschrift, Fliesstext und Haarlinientrenner ohne Aussenrahmen oder Karten. Verbleibender Raum wird bewusst nicht gefuellt. | Identische Navigationsbreiten und flache Listeneintraege halten Datahub, Work und Reports visuell zusammen. Eine begrenzte rahmenlose Readerbreite verbessert den Lesefluss und verhindert, dass kurze Mandantenwerte ueber eine breite Arbeitsflaeche auseinanderfallen; Eingaberahmen erscheinen nur im ausdruecklichen Editzustand. |
| 2026-08-22 | Die ausgewaehlte Work-/Reports-Referenz ersetzt fuer das Mandantendetail die bisherige zentrierte Stapeldarstellung: links steht ein unabhaengig scrollender, aufklappbarer Timeslot-/ScanRun-Navigator, rechts die read-first Mandanteninformation. Einzelne ScanRuns duerfen lokal fuer `Open` ausgeschlossen werden; Persistenz, Importziele, bestaetigungspflichtige Loeschpfade und die sichere Mehrfach-Timeslot-Schnittmenge bleiben unveraendert. | Das Master-Detail-Muster haelt Navigation und fachlichen Inhalt sichtbar, ohne Stammdaten, Timeslots und Scans untereinander zu stapeln. Ein Ausschlussmodell erhaelt die bestehende Standardsemantik „alle ScanRuns des Timeslots“, schliesst neue Importe automatisch ein und benoetigt weder Schema- noch API-Aenderungen. |
| 2026-08-22 | Graphbeschriftungen verwenden quadratische, zoomstabile Mini-Ausgaben der bestehenden Work-Kachelstruktur. Sie erscheinen im Normalzustand nur bei Hover oder Auswahl; die ausdrueckliche Labelumschaltung kann weiterhin alle Karten einblenden. | Breite Dauerkarten ueberdecken Knoten und Kanten und zerstoeren den Netzwerkueberblick. Die quadratische Miniatur erhaelt Hexagon, Titel, Outcome und Badges als vertraute Semantik, waehrend die bedingte Sichtbarkeit den Graphen als primaere Informationsstruktur bewahrt. |
| 2026-08-22 | Die neuere Nutzeranforderung ersetzt die separate fachliche Graphfilterung aus der nachfolgenden frueheren Entscheidung: Work und Graph verwenden denselben AppProvider-Filterzustand und dieselbe `useFilteredRecords()`-Projektion. Der Graph rendert die vorhandenen gemeinsamen Controls fuer Suche, Quellblatt, Status, dynamische Facetten und Workspace-Einschraenkung in seiner linken Spalte; nur Labels, Auswahl und Kamera bleiben lokal. | Es gilt fachlich genau eine gefilterte Datengrundlage fuer beide Ansichten. Dadurch werden Aenderungen bidirektional uebernommen, werkzeugabhaengige Filter bleiben vollstaendig und es kann keine abweichende lokale Graph-Grundmenge entstehen. |
| 2026-08-22 | Die Graphansicht ist eine reine Phase-7-Praesentationsprojektion als interaktives Finding-Technik-Taktik-Netzwerk; Import-, Mapping-, Review- und Result-Vertraege bleiben die bestehenden Quellen. Suche, Kategorie, Severity und Mapping besitzen im kompakten Graphkopf einen gemeinsamen Reset, waehrend die unabhaengige Labelumschaltung erhalten bleibt. | Die bisherige Spalten-/Kartenansicht kann vollstaendig ersetzt werden, ohne Scannerlogik in React zu verschieben oder kanonische Daten und Provenienz zu veraendern. Der gepunktete Flaechenhintergrund gehoert ausschliesslich zur Graphansicht und besitzt getrennte Dark-/Lightwerte; alle anderen Bereiche behalten ihre ungepunktete Standardflaeche. Ein gemeinsamer Reset verhindert unklare Restfilter, ohne Darstellungsoptionen unerwartet zu aendern. |
| 2026-08-22 | Timeslot-Aktionen sind an den jeweils ausgewaehlten Assessment-Stand gebunden. `Import Scan` und `Import GPO Backup Folder (Zip)` uebergeben dessen Assessment-ID; `Delete` verwendet einen eigenen bestaetigungspflichtigen Assessment-DELETE-Vertrag. Der bestehende Mandanten-Delete bleibt getrennt und unveraendert. | Die Position in der Slotzeile muss auch der fachlichen Zielgrenze entsprechen. Eine Wiederverwendung des Mandanten-Delete waere irrefuehrend und koennte den gesamten Mandanten statt nur des ausgewaehlten Stands vernichten. |
| 2026-08-22 | Die neue ausdrueckliche Timeslot-Vorgabe ersetzt fuer die Mandantendetailansicht die Entscheidung vom 2026-08-05, dort keine Timeslot-Anlage oder -Auswahl zu rendern. `Assessment` bleibt der Timeslot; die geschlossene Tabelle, Datumsanlage und Mehrfachauswahl sind wieder sichtbar. Ab zwei ausgewaehlten Staenden darf `Open` nur ScanRuns aus Werkzeugquellen weiterreichen, die in jedem Stand sicher identifiziert vorhanden sind. GPO bleibt eine eigene Assessment-Quelle und wird nicht in einen ScanRun umgedeutet. | Der Nutzer benoetigt den fachlichen Stichtag als sichtbare Vergleichseinheit und muss auch einen leeren ersten Stand anlegen koennen. Eine explizite Quellen-Schnittmenge verhindert Scheinveraenderungen durch fehlende Scanner- oder GPO-Abdeckung und erhaelt zugleich die bestehende Assessment-/ScanRun-/GPO-Architektur. |
| 2026-08-22 | Microsoft-Security-Baselinepakete koennen nur nach ausdruecklicher UI- und API-Bestaetigung geloescht werden. Der Repository-Pfad blockiert Pakete, die bereits als Quelle einer Policy-Evaluation dienen; bei freigegebenen Paketen entfernt er Katalogeintrag, Klassifikationen und Analysen gemeinsam. | Baselineoriginale sind globale Referenzdaten und duerfen weder durch einen blossen Tabellenklick noch unter Verlust bestehender Evaluationsevidenz verschwinden. Die Schutzpruefung gehoert deshalb in die Persistenzgrenze und nicht nur in die Darstellung. |
| 2026-08-22 | Die Mandantenaktionen `Import Data` und `GPO Backup Folder` haengen nur von einem bestehenden Mandanten ab, nicht von einem bereits vorhandenen Assessment oder Timeslot. Eine vorhandene Ziel-ID wird weiterhin mitgegeben; ohne Ziel-ID verwenden die bestehenden Importdienste ihren vorgesehenen mandantenbezogenen Erstimportpfad. | Gerade ein leerer oder neu angelegter Mandant benoetigt die Importaktionen, um seinen ersten Scan beziehungsweise sein erstes GPO-Backup aufnehmen zu koennen. Die fruehere UI-Bedingung machte den dafuer bereits vorhandenen Backendpfad unzugaenglich. |
| 2026-08-22 | Bestehende Mandantenstammdaten sind beim Oeffnen schreibgeschuetzt. Nur der ausdrueckliche gelbe `Edit`-Textbutton im Client-Information-Kopf aktiviert die Bearbeitung und die dort erscheinende Speicheraktion; Neuanlagen starten dagegen sofort editierbar. Nach erfolgreichem Speichern oder Verlassen der Ansicht wird der Modus wieder gesperrt. | Der explizite Bearbeitungsmodus verhindert versehentliches Ueberschreiben oder Loeschen bestehender Feldinhalte, ohne den Neuanlagefluss mit einem unnoetigen Zwischenschritt zu belasten. Ein ausgeschriebener Button ist eindeutiger als der bisherige Stift; die Submit-Sperre sichert dieselbe Regel unabhaengig von der sichtbaren Schaltflaeche. |
| 2026-08-22 | Die neue ausdrueckliche Datahub-Vorgabe ersetzt die achtspaltige Mandanten-/Timeslottabelle und deren `Empty`-Slots aus den Entscheidungen vom 2026-08-05. Statusdiagramme stehen oben; darunter folgen nur reale Mandantenkarten und eine Plus-Karte. Es existiert genau eine Mandantenauswahl, deren neuester scannergebundener Timeslot die Diagramme speist; `Show` erscheint nur auf der ausgewaehlten Karte und oeffnet die bestehende Mandantenansicht. | Die Uebersicht soll Mandanten statt technischer Timeslotzellen in den Vordergrund stellen. Eine einzige Auswahl macht Diagrammquelle, sichtbare Umrandung und Navigation eindeutig; die bestehende Assessment-/ScanRun-Persistenz sowie die Mandantendetailseite bleiben unveraendert. |
| 2026-08-21 | Die neueste Nutzerkorrektur ersetzt fuer PingCastle die Reader-Darstellungsentscheidung desselben Tages: Sind strukturierte Results vorhanden, verschwindet `Details` vollstaendig aus Fliesstext und Additional Information. Ohne strukturierte Results bleibt `Details` als Fallback sichtbar. | Nach der vollstaendigen Results-Pfadprojektion waere derselbe fachliche Inhalt im Reader und im Popup doppelt vorhanden. Der bedingte Fallback verhindert zugleich Informationsverlust bei historischen oder unvollstaendigen Importen. |
| 2026-08-21 | PingCastle-Results folgen der im HTML definierten Reihenfolge der tatsaechlichen Detailziel-Container. Jeder Tabellenblock zeigt seinen vollstaendigen hierarchischen Pfadtitel; fachlicher Abschnittstext steht unmittelbar vor der zugehoerigen Tabelle. Die finding-spezifische Referenzliste ist fuer die Anzeigeordnung autoritativ, nicht die globale Dataset-Blattreihenfolge. | Linkausloeser koennen im sichtbaren Text vor ihren spaeter definierten Modal-/Collapse-Zielen stehen, und gemeinsam genutzte Results-Blaetter koennen global in der Reihenfolge eines anderen Findings vorliegen. Zielposition plus finding-spezifische Referenzen bilden dagegen den vollstaendigen Detailspfad deterministisch ab; Titel und Preamble erhalten den zum Verstaendnis notwendigen Kontext ohne Tabelleninhalt zu duplizieren. |
| 2026-08-21 | Der Doppelklick auf die freie Kopfzeile eines geoeffneten Result-Fensters maximiert das Fenster innerhalb der sichtbaren Arbeitsflaeche; ein einfacher Klick auf die maximierte Titelleiste stellt die vorherige Geometrie und Clusterposition wieder her. Nur im minimierten Zustand bleibt der Doppelklick ein Wiederherstellen. | Damit sind Einklappen, Flaechenmaximierung und Rueckkehr zur Standardposition eindeutig getrennt. Die dynamisch gemessene Unterkante des statischen Headers verhindert Ueberdeckung, waehrend Position, Nutzergroesse und Clusterzugehoerigkeit des normalen Fensters unveraendert erhalten bleiben. |
| 2026-08-21 | PingCastle-HTML ist die alleinige Quelle fuer Results und deren interne Subsection-, Modal- und Collapse-Beziehungen. HTML und XML werden als getrennte Importe dargestellt und nicht mehr ueber Dateistamm plus Rule ID gegenseitig angereichert; diese Nutzerentscheidung ersetzt die entsprechende Begleiteranreicherung vom 2026-07-22. Ein PingCastle-XML-Import bleibt als eigenstaendige RiskRules-Quelle erhalten, erzeugt aber keine Results und weist beim Import ausdruecklich darauf hin. | Der vorliegende XML-Regelknoten enthaelt verlaessliche Regelmetadaten, aber keine explizite, finding-spezifische Beziehung zu den im HTML gerenderten Evidence- und Popup-Tabellen. Nur der lokale HTML-Linkgraph liefert eine nachvollziehbare Beweiskette; eine semantische XML-Zuordnung waere heuristisch und koennte fremde Details an ein Finding haengen. |
| 2026-08-21 | Die ausdrueckliche Nutzerkorrektur ersetzt fuer PingCastle die Darstellungsentscheidung vom 2026-07-25: `Details` bleibt auch bei vorhandenen strukturierten Belegtabellen normaler Lesetext im Finding, steht direkt nach `Technical explanation` und erscheint nicht unter `Additional Information`. Strukturierte Belegtabellen bleiben getrennt im Results-Fenster; der importierte Detailwert wird weder veraendert noch verworfen. | Der Zusatzinformationstableau ist fuer Metadaten, nicht fuer fachlichen Fliesstext. Die normale Reader-Darstellung bietet Lesetypografie und erhaelt zugleich die Trennung zwischen originalem Detailtext und strukturierten Belegdaten. |
| 2026-08-17 | Der Standard-Vitest-Lauf behaelt Dateiparallelitaet und den isolierenden `forks`-Pool bei, begrenzt ihn im lokalen Windows-Betrieb jedoch auf hoechstens vier Worker. `minWorkers` bleibt 1. Die konkrete Workerzahl ist eine gemessene plattformspezifische Betriebsgrenze und kein Architekturvertrag des Config-Separation-Tests. | Kontrollierte Gesamtlaeufe ergaben: 1 Worker 395,31 s, 2 Worker 203,48 s und 4 Worker 122,45 s; alle drei Grenzen waren stabil. Der CPU-basierte Default-Pool blieb dagegen auf dem synchronisierten `G:`-Laufwerk weitgehend `queued` und brach mit einem Node-Dateilesefehler ab. Ein zweiter 4-Worker-Lauf ueber `npm test` terminierte in 121,03 s einschliesslich der nachgeschalteten Local-only- und Designpruefungen. |
| 2026-08-17 | **Zurueckgezogen:** Der Standard-Vitest-Lauf verarbeitet Testdateien mit genau einem Fork und ohne Dateiparallelitaet. | Diese erste Stabilisierung war ein belastbarer Diagnosebeweis, wurde aber vor dauerhafter Festschreibung durch kontrollierte 2- und 4-Worker-Benchmarks ersetzt. `fileParallelism: false` haette `maxWorkers` ohnehin auf 1 ueberschrieben und die Suite ohne belegten Grund dauerhaft serialisiert. |
| 2026-08-17 | In Arbeits- und Analyseansichten ist `Deviation` der profiluebergreifende initiale Result-Status. Projekt-, Blatt- und Ansichtswechsel bewahren die bewusste Nutzerauswahl; nur eine ausdrueckliche Statusauswahl oder Filterruecksetzung darf sie aendern. Severity-Diagramme verwenden dieselbe nachgezaehlte Facette wie der Filter und setzen beim Klick ausschliesslich die jeweilige Severity. Die Datahub-Statuskarten bleiben davon getrennte, ungefilterte Timeslot-Statistiken mit `Results All` als Referenz. | Eine einzige Facetten- und Statussemantik verhindert abweichende Diagrammzahlen und unbemerkte Filterresets. Die ausdrueckliche Datahub-Grenze erhaelt dessen statistischen Overview-Charakter. |
| 2026-08-17 | Severity-Diagramme sind eine Mehrfachauswahl innerhalb genau einer Kategorie-Facette. Jeder Klick schaltet eine Stufe unabhaengig ein oder aus; mehrere Stufen sind fachlich ODER-verknuepft und werden stets in der kanonischen Reihenfolge Critical, High, Medium, Low, Info gespeichert. Bei Mehrfachauswahl zeigt das Filterfeld die kompakte Kombination `Crit-High-Med-Low-Inf` beziehungsweise deren ausgewaehlte Teilfolge. | Toggle-Semantik vermeidet zusaetzliche Modifier-Tasten und bleibt zwischen Diagrammen, Facettenfilter und Resultliste eindeutig. Die feste Reihenfolge verhindert von der Klickreihenfolge abhaengige Filteranzeigen. |
| 2026-08-05 | Die Referenz ChatGPT Image Aug 5, 2026, 01_12_23 PM.png definiert verbindlich alle Donut-Anzeigen. DonutMetricCard und .donut-metric-rack sind die einzigen zulaessigen Implementierungen; Dark- und Lightmode teilen Geometrie und Semantik, besitzen aber eigene --donut-*-Themewerte. Die verbindliche kompakte Proportion verwendet 196 px Kartenmindesthoehe und maximal 128 px Ringdurchmesser. Kartenradius und tokenisierte Tiefenschatten sind ausschliesslich fuer diesen Vertrag zugelassen. | Ein wiederverwendbarer Komponentenvertrag verhindert abweichende lokale SVG-Varianten. Die enge, automatisiert gepruefte Ausnahme setzt die ausdrueckliche Nutzerreferenz um, ohne Schatten, Radien oder rohe Farben fuer andere Panels freizugeben. |
| 2026-08-05 | Die Datahub-Statusanzeige verwendet sechs kanonisch gespeiste 270-Grad-Diagramme. Results All ist die 100-Prozent-Referenz; Deviation, Passed, Not Applicable, Not Run und Error werden unabhaengig relativ zur Gesamtzahl dargestellt und mit bestehenden semantischen Designtokens gefaerbt. | Die Berechnung bleibt ausserhalb der React-Praesentation und zerstoert weder Originalstatus noch Provenienz. Unabhaengige Anteile vermeiden die falsche Annahme, dass fachlich ueberlappende oder nicht vollstaendig partitionierende Kategorien gemeinsam exakt 100 Prozent ergeben muessen. |
| 2026-08-05 | Die vier Datahub-Statusregler lesen den zuletzt angewählten Timeslot. Beim Laden wird der neueste vorhandene Stand des aktiven beziehungsweise ersten Mandanten ausgewaehlt; mehrere ScanRuns desselben Timeslots werden gemeinsam gezaehlt. `Deviation` verwendet das zentrale Abweichungspraedikat, technische Fehler bleiben als `Error` getrennt. | Die Anzeige benoetigt eine eindeutige fachliche Quelle, auch bei nur einem vorhandenen Stand. Die bestehende kanonische Outcome-/Execution-Semantik verhindert werkzeugspezifische UI-Logik und Doppelinterpretationen; ein zweiter Stand kann weiterhin fuer den Vergleich hinzugewaehlt werden. |
| 2026-08-05 | Die neueste ausdrueckliche Datahub-Referenz supersediert die Vollbreitenentscheidung desselben Tages: Uebersicht und Mandantendetail teilen einen maximal 1180 px breiten zentrierten Rahmen. Acht visuelle Mandantenslots, die schmale Plusspalte, vier dekorative Transpose-/Detune-Regler, MITRE und Baselines bilden ausschliesslich die gezeigte Rackoptik. | Der Nutzer hat Breite, Position und Optik erneut eindeutig festgelegt. Platzhalter und Regler bleiben ohne Fachzustand; vorhandene Navigation sowie MITRE-/Baseline-Uploads bleiben an ihren bestehenden sicheren Grenzen verdrahtet. |
| 2026-08-05 | Die ausdrueckliche Mandantendetail-Referenz ist fuer den View nach Klick auf einen Mandanten autoritativ. Der bestehende 1180-px-Inhaltsrahmen und seine Position bleiben erhalten; sichtbar sind nur Open, Delete, Import Data, GPO Backup Folder, Save, die drei Stammdatenfelder und die ScanRun-Historie. Die abgebildeten Rackregler sind reine Praesentation ohne Fachzustand. | Die Referenz verlangt eine enge, unverwechselbare Funktionsmenge. Verdeckte oder zusaetzliche Timeslot-, GPO-Status- und Policy-Bedienung wuerde diese Vorgabe verletzen; aria-hidden verhindert zugleich, dass dekorative Regler als nicht funktionierende Controls angekuendigt werden. Domain-, API- und Persistenzmodelle bleiben unveraendert. |
| 2026-08-05 | Die ausdrueckliche Bild-2-Referenz ersetzt die zuvor dokumentierte kompakte Zentrierung: Datahub-Rackmodule fuellen die Arbeitsbreite, die Historie zeigt acht gleichmaessige visuelle Mandantenslots plus schmale Hinzufuegen-Spalte, und das Zustandsrack zeigt vier kleine 270-Grad-Regler links ohne separaten Vergleichskasten. `Empty`-Slots bleiben reine Praesentation. | Die Zielgrafik ist fuer diesen View die autoritative Layoutvorgabe. Sichtbare Platzhalter reproduzieren das Raster ohne fachliche Scheindaten; die Trennung von Dreiecksauswahl und Datumsoeffnung erhaelt den Zwei-Timeslot-Workflow. Die kompakte Zentrierung aus dem vorherigen Schritt war eine Fehlinterpretation und wird nicht weitergefuehrt. |
| 2026-08-05 | Referenz-Rackmodule bleiben auf maximal 1180 px begrenzt; Mandantenhistorie und Donut-Zustandsblock schrumpfen zusaetzlich auf ihre tatsaechliche Inhaltsbreite und werden mittig ausgerichtet. Mandantenspalten besitzen eine feste kompakte Breite, bei Ueberlauf bleibt horizontales Scrollen erhalten. | Ein einzelner Mandant oder vier Zustandsregler duerfen nicht durch flexible 1fr-Spalten auf die gesamte Arbeitsflaeche gezogen werden. Inhaltsbreite verhindert massiven Leerraum, waehrend die Obergrenze und vorhandene Breakpoints mehrere Mandanten und kleine Viewports weiterhin sicher behandeln. |
| 2026-08-05 | `Assessment` ist der fachliche Mandanten-Timeslot eines Stichtags; `ScanRun` ist eine Scannerquelle innerhalb dieses Stands. GPO-Backups werden direkt an dieselbe Assessment-ID gebunden, ohne einen kuenstlichen ScanRun zu erzeugen. Oeffnen und Vergleichen projiziert jeweils alle ScanRuns eines Timeslots gemeinsam. | Ein Bewertungsdurchgang besteht aus allen zum Stichtag erhobenen Quellen. Eine Historienzeile je Scannerimport wuerde denselben fachlichen Stand vervielfachen und Fortschrittsvergleiche verfaelschen; die bestehende Assessment-/ScanRun-Hierarchie bildet die gewuenschte Einheit bereits ab und benoetigt keine neue Hauptentitaet. |
| 2026-08-04 | Die Datahub-Historie darf mehrere persistierte Assessments desselben Mandanten fuer einen expliziten Zwei-Staende-Vergleich in ein read-only virtuelles Assessment projizieren. Auswahl und Navigation bleiben getrennte Bedienhandlungen; ein Datums-Klick laedt nur den gewaehlten ScanRun, waehrend maximal zwei Checkboxen desselben Mandanten den Vergleich bestimmen. | Die Vergleichsengine erwartet ein gemeinsames Assessment, die bestehende Persistenz trennt Durchgaenge jedoch teilweise auf Assessments. Eine rein lesende, mandantengebundene Projektion nutzt die bestehende Engine ohne Schema- oder Datenmutation. Getrennte Controls verhindern, dass Auswahl versehentlich den Arbeitskontext wechselt. |
| 2026-08-04 | Bedienbare Policy-Aktionen werden als typisierte, projektgebundene Bereitschaft im Backend-Readmodell abgeleitet. Nur aktive Profil- und Analyse-Revisionen werden angeboten; Baselineauswahl verlangt je Profilkontext genau einen Katalogtreffer. Partielle Quellen duerfen nur sichtbar als `review-only` weiterlaufen, fehlende oder mehrdeutige Quellen bleiben `blocked`; React sendet ausschliesslich die expliziten IDs an die weiterhin autoritativen, idempotenten Fachservices. | Eine UI-seitige Quellkombination koennte veraltete Revisionen, unpassende Baselines oder partielle Evidenz als freigegeben behandeln. Das Readmodell verbessert Bedienbarkeit, ersetzt aber keine Mutationvalidierung; dadurch bleiben Stale-Races und manipulierte Requests fail-closed oder hoechstens review-only. |
| 2026-08-04 | Die projektgebundene Policy-Analyseansicht verwendet ein eigenes typisiertes Backend-Readmodell. React kombiniert weder Persistenzobjekte noch leitet es Severity, Wirksamkeit oder Finding-Status aus Diagnosecodes ab. Das Readmodell bewahrt einzelne historische Laeufe und kennzeichnet aggregierte Zaehler ausdruecklich als Laufhistorie. | Konflikt-, Luecken- und Factory-Diagnosen stammen aus mehreren unveraenderlichen Stufen. Eine UI-seitige Rekonstruktion wuerde Fachlogik und Vertrauensgrenzen duplizieren; eine unmarkierte Summierung historischer Reprocessings koennte dagegen einen aktuellen Kundenzustand vortaeuschen. |
| 2026-08-04 | Policy-Findings werden nicht durch kuenstliche Scannerlaeufe oder Importdateien in `assessor_finding_occurrences` gepresst. Eine eigene unveraenderliche Policy-Occurrence referenziert die gemeinsame kanonische Finding-Definition und das Evaluationsergebnis; das Unified Result Model bleibt die einzige gemeinsame lesende Projektion. | Scanner- und Policy-Provenienz haben verschiedene Pflichtbeziehungen. Eine Scheindatei wuerde Herkunft erfinden, eine zweite kanonische Definitionstabelle wuerde Identitaeten duplizieren. Die getrennte Occurrence erhaelt beide Wahrheiten und erlaubt gemeinsame Filter, Bericht und Export ohne zweite Result-Haupttabelle. |
| 2026-08-04 | Die stabile technische Policy-Identitaet bleibt von ADMX-/ADML-Katalogmetadaten getrennt. Jeder produktive Analyseversuch speichert Parser-, Reducer-, Identity-Resolver- und Katalogversionen an einem unveraenderlichen Run; ein Enginewechsel erzeugt einen deterministischen supersedierenden Run statt bestehende Ergebnisse umzuschreiben. | Registryziele muessen ueber Katalog- und Sprachrevisionen stabil bleiben. Versionierte Runs, optimistische Vorgaengerpruefung und deterministische Idempotenzschluessel machen Restart, Retry, Audit und reproduzierbares Reprocessing nachvollziehbar. |
| 2026-08-04 | Eine stabile Registry-Policy-Identitaet wird aus Scope, Hive, kanonischem Registry-Schluessel und Wert- oder Schluesselziel gebildet. ADMX-Zielnamespace, Policy-Name und Element-ID sind eine optionale katalogversionierte Metadatenzuordnung; ADML-Anzeigetexte beeinflussen die Identitaet nie. | Registryziele bleiben ueber ADMX- und Sprachrevisionen vergleichbar. Fehlende Inbox-ADMX-Dateien fuehren zu `not-found`, mehrere technische Treffer zu `ambiguous`; beides darf weder einen Match noch einen Vergleich erfinden. |
| 2026-08-04 | `Registry.pol` wird durch einen kleinen versionierten read-only In-Process-Parser verarbeitet; ein externer `LGPO.exe`-Adapter ist fuer den unterstuetzten Scope nicht erforderlich. REG_NONE wird ausschliesslich als leere Schluesselanlage akzeptiert, alle anderen nicht freigegebenen Typen bleiben fail-closed. | Die offizielle MS-GPREG-Struktur und Microsofts archivierte PowerShell-Referenz reichen fuer den benoetigten deterministischen Lesepfad aus. Dadurch entstehen weder Shell-/Prozessausfuehrung noch eine zusaetzliche Bibliotheks- oder Lizenzabhaengigkeit; der reale GPMC-Fall bleibt dennoch explizit regressionsgeprueft. |
| 2026-08-04 | Microsoft-Security-Baselinepakete bilden einen globalen, unveraenderlichen Referenzdatenkatalog ausserhalb von Mandantenimporten. Automatische Auswahl verlangt genau eine Uebereinstimmung aus Produktfamilie, Produktversion, Rolle und Scope; kein oder mehrere Treffer liefern `no-match` beziehungsweise `ambiguous`. | Baselinepakete gelten mandantenuebergreifend. Dateinamen koennen Metadaten vorschlagen, duerfen aber weder Policy-Identitaet noch eine mehrdeutige fachliche Auswahl erfinden. |
| 2026-08-04 | Eine Baselinepaket-Klassifikation ist eine unveraenderliche, detektorversionierte Revision. Ein Paket darf mehrere Produktkontexte enthalten; die Originalmetadaten des importierten Pakets werden bei verbesserter Erkennung nicht ueberschrieben. | Offizielle Microsoft-Pakete koennen Windows-Client und Windows-Server gemeinsam enthalten. Revisionen erhalten Provenienz und Reproduzierbarkeit, waehrend jede vollstaendig passende Kontextauswahl dasselbe Originalpaket referenziert. |
| 2026-08-04 | GPO-Upload, Jobabschluss, Inventarisierung und PolicyObservation-Persistenz sind Verarbeitungszustaende und keine Scan- oder Baselinepruefberichte. Ein Eintrag in Linked Scan Reports setzt einen persistierten Baseline-Evaluation-Run mit fachlichen Ergebnissen voraus. | Die reine Existenz oder technische Analyse eines Backups belegt weder einen Vergleich noch ein Ergebnis. Die UI darf deshalb keinen fachlichen Bericht vortaeuschen, bevor die verbindliche Policy-Pipeline bis PolicyEvaluationResult durchlaufen wurde. |
| 2026-08-04 | Ein ausgewaehlter GPO-Hauptordner bildet genau einen Mandanten-Backup-Snapshot. Seine erkannten GPO-Wurzeln sind Mitglieder desselben Sets und werden ueber eine gemeinsame Set-ID aggregiert; die oeffentliche Statussemantik nennt ihre Anzahl gpoCount. | Unterordner sind technische Backups einzelner GPOs, nicht mehrere Mandanten-Backups. Die Benutzerauswahl belegt nur selected-gpos, niemals Vollstaendigkeit, Verknuepfung oder Wirksamkeit; historische Datensaetze bleiben unveraendert und werden ueber ihr gemeinsames Quellartefakt lesekompatibel gruppiert. |
| 2026-08-04 | Ein syntaktisch gueltiger GPMC-`BackupTime` ohne Zeitzonenoffset wird nicht als UTC interpretiert und blockiert nicht die separat belegten GPO-/Backup-IDs oder die Domaene. Der Zeitpunkt bleibt unbekannt und die Metadaten bleiben mit einem festen Diagnosecode `partial`; freie, gemischte oder widerspruechliche Zeitformate bleiben `invalid`. | Microsoft-GPMC-Backups liefern lokale Sicherungszeiten ohne Offset. Eine erfundene Zeitzone waere falsche Provenienz, das Verwerfen unabhaengiger technischer Identitaet dagegen unnoetiger Informationsverlust. |
| 2026-08-02 | Clientbuild, Serverbuild und Tests besitzen getrennte Vite/Vitest-Konfigurationen, Cacheverzeichnisse und explizite npm-Skriptrouten. Der konventionelle Name `vite.config.ts` bleibt ausschließlich als dünner Alias auf die Clientkonfiguration bestehen. | Build- oder Testwerkzeuge von Codex, Claude Code, Gemini, IDEs und CI dürfen keine fremden Plugins, Outputs oder Testregeln aus einer gemeinsamen Konfiguration übernehmen. Der Alias hält generische Vite-Discovery kompatibel, ohne Server und Tests erneut an diese Datei zu koppeln. |

| 2026-08-02 | `npm run dev` bezeichnet den vollständigen lokalen Entwicklungsstack und nicht mehr nur den Vite-Client. Ein vorhandenes gesundes Backend wird wiederverwendet; andernfalls wird der Server über seine dedizierte Konfiguration gebaut und lokal gestartet. Erst nach erfolgreichem Health-Check startet der Client fest auf `127.0.0.1:5173`. `npm run dev:client` ist der ausdrücklich benannte Client-only-Weg. | Ein erfolgreicher Frontend-Listener bei fehlendem Backend ist kein betriebsbereiter ASSESSOR-Zustand. Die Orchestrierung macht die notwendige Reihenfolge maschinenprüfbar und verhindert, dass Menschen oder Coding-Agenten beim Standardstart den API-Prozess vergessen. |
| 2026-08-02 | Die Parkposition minimierter Results ist an die sichtbare Arbeitsfläche gebunden: 80 px vom rechten Viewportrand und 46 px unterhalb ihrer Oberkante. Dies ersetzt für neue Minimierungen die bisherige feste Höhe von 76 px ab Viewport-Oberkante. | Filter- und Statusband gehören nicht zur Fensterarbeitsfläche. Eine gemessene, inhaltsfreie Ankerkante hält die Parkposition auch bei veränderter Kopfgeometrie im Arbeitsbereich und bleibt an kurzen Viewports sicher begrenzt. |
| 2026-08-02 | Alle funktionalen Richtungsanzeigen verwenden dieselbe gefüllte Dreiecksgeometrie als SVG beziehungsweise bei nativen Selects als identisches CSS-Hintergrundsymbol; Schriftzeichenpfeile und das frühere Result-Würfelsymbol sind für Navigation und Zustandswechsel nicht mehr zulässig. Result-Titelleisten färben das Dreieck mit dem individuellen Result-Ton und zeigen minimiert nach rechts, maximiert nach unten. | SVG-Geometrie ist unabhängig von Schriftart und Zeichenkodierung und verhindert sichtbare Mojibake-Zeichen. Richtung entsteht ausschließlich durch Rotation; Semantik, ARIA-Namen und native Select-Funktion bleiben erhalten. Spezifische Zustandsfarben dürfen deshalb nur die Hintergrundfarbe, nicht die CSS-Hintergrundgrafik eines Selects überschreiben. |
| 2026-08-02 | Sichtbarkeit, Normalisierung und Hierarchie fachlicher Result-Belegtabellentitel sind optionale Präsentationshinweise des Werkzeugprofils. CIS-CAT setzt `showResultSheetTitles`, `resultSheetTitleRules` und `resultSectionListSheetTitles`. Markdown-Frameworküberschriften gruppieren ihre Tabellen einmalig; die Listenpunkte werden in Quellreihenfolge zu individuellen Tabellenüberschriften. Der ursprüngliche Abschnitt wird nur konsumiert, wenn jeder Listenpunkt vollständig zugeordnet wurde. | Das erhält die fachliche Beziehung zwischen Framework, Control und Tabelle ohne CIS-spezifische Analyse in React. Bei unvollständigen oder künftigen Berichten bleiben nicht zuordenbare Angaben sichtbar, statt durch eine partielle Umformung verloren zu gehen. |
| 2026-08-02 | Fachlich hervorgehobene Zeilen verknüpfter Result-Tabellen werden über optionale `resultSheetHighlightedRowPatterns` des Werkzeugprofils bestimmt. CIS-CAT markiert damit exakt den Assessment-Hinweis `No matching system items were found.`; die Darstellung verwendet den bereits vorhandenen ausgewerteten Zeilenstatus. | Die fachliche Entscheidung bleibt im Profil, die generische React-Tabelle kennt weder CIS-CAT noch feste Hinweistexte. Vorhandene Design-Tokens liefern identische blaue Markierung ohne neue Sonderfarbe; andere Werkzeuge bleiben unbeeinflusst. |
| 2026-08-02 | Ergebnisabschnitte im Results-Fenster besitzen keinen eigenen Rahmen, Hintergrund oder Innenabstand; Tabellen behalten ihre Zelllinien und Überschriften ihre Hierarchie. | Ein zusätzlicher Kasten um Überschrift und bereits umrandete Tabelle doppelt die visuelle Abgrenzung und verbraucht insbesondere bei vielen kurzen CIS-CAT-Belegen unnötig Höhe und Breite. Der gemeinsame Result-Block-Vertrag macht die kompakte Darstellung für alle Werkzeuge konsistent. |
| 2026-08-02 | Die sichtbare Statusspalte wird über eine geordnete `presentation.statusHeaders`-Präferenz des Werkzeugprofils aufgelöst und von Reader, Datensatzkarte und Kachel gemeinsam verwendet. Optionale `statusDisplayRules` ändern ausschließlich die sichtbare Beschriftung. Purple Knight priorisiert `Status` vor `Result`, beschriftet `Pass` als `Passed` und `IOE Found` als `Failed`; fehlt `Status`, bleibt `Result` als kompatibler Rückfall erhalten. | In der kanonischen Purple-Knight-Projektion kann `Result` die SI-Kurzkennung wiederholen, während `Status` das eigentliche Ergebnis enthält. Eine bloße erste Regex-Übereinstimmung macht die Anzeige von der Feldreihenfolge abhängig; eine Änderung des gespeicherten Rohwerts würde dagegen Herkunft und Quelltreue verletzen. |
| 2026-08-02 | Result-DetailblÃ¤tter dÃ¼rfen nur an Findings desselben explizit bekannten Werkzeugs gebunden werden; die unscharfe VerknÃ¼pfung akzeptiert ausschlieÃŸlich Datei- oder stabile Regel-ID-Verweise. | Gemischte Projektansichten enthalten BlÃ¤tter mehrerer Scanner. Freier Ergebnistext ist keine belastbare IdentitÃ¤t und darf weder Ã¼ber gemeinsame WÃ¶rter noch Ã¼ber einen zufÃ¤llig Ã¤hnlichen Namen Evidenz eines anderen Werkzeugs in ein Finding ziehen. Unbekannte beziehungsweise generische Metadaten bleiben kompatibel, ausdrÃ¼cklich widersprÃ¼chliche toolIds werden fail-closed ausgeschlossen. |
| 2026-08-02 | Die freie KopfzeilenflÃ¤che eines Result-Fensters ist zusÃ¤tzlich zum sichtbaren Button ein Doppelklick-Umschalter fÃ¼r Minimieren und Wiederherstellen; eingebettete Kopfzeilenaktionen sind davon ausgenommen. | Doppelklick ist ein schneller sekundÃ¤rer Bedienweg, darf aber Bookmark, Navigation, SchlieÃŸen oder den expliziten Umschaltbutton nicht mehrfach auslÃ¶sen. Der sichtbare Button bleibt der eindeutige und tastaturbedienbare PrimÃ¤rweg. |
| 2026-08-02 | Minimierte Cluster-Results bleiben im DOM und sichtbar, auch wenn ein Cluster- oder freies Result maximiert ist; sie werden als schmale farbige Reiter hinter dem aktiven Fenster dargestellt. | Das Ausblenden minimierter Fenster koppelt ihre wahrgenommene Position an das maximierte Fenster und nimmt den klaren Wiederherstellungsweg. Sichtbare Reiter bewahren den Clusterzustand und erlauben, ein maximiertes Result per Kopfzeilenziehen oder Größenänderung eindeutig zu lösen. |
| 2026-08-02 | Die Mindesthöhe eines maximierten, angedockten Resultfensters entspricht der gemeinsamen 34-px-Stapelhöhe aller dahinterliegenden minimierten Results und wird am noch verfügbaren Viewport begrenzt. Stapelposition, Clusterhöhe und Abdeckung verwenden dieselbe exportierte Zeilenhöhe. | Ein inhaltsabhängig kurzes aktives Fenster kann sonst die unteren minimierten Kopfzeilen freilegen und den Eindruck mehrerer gleichrangig aktiver Fenster erzeugen. Eine gemeinsame Geometriekonstante verhindert Drift zwischen Positionierung, Viewport-Klemmung und Abdeckung; entkoppelte Fenster dürfen weiterhin frei dimensioniert bleiben. |
| 2026-08-02 | Result-Fenster verwenden einen eindeutigen Unicode-Gedankenstrich als Trennzeichen; sie zeigen den Finding-Titel zusätzlich als Überschrift im Fensterkörper, unterdrücken dort aber Quellblattüberschriften. | Falsch dekodierte Trennzeichen erzeugen sichtbare Restzeichen im Titel. Die zusätzliche Finding-Überschrift ist eine bewusste Orientierung im Ergebnisinhalt; Quellnamen und ein nicht lesbarer Minimieren-Glyph konkurrieren dagegen mit dem eigentlichen Ergebnisinhalt. Der Doppelklick bleibt als vorhandener, konsistenter Umschaltweg erhalten. |
| 2026-08-02 | Jeder Minimierungsvorgang setzt den Result-Cluster auf eine viewport-sichere Parkposition rechts oben zurück; eine anschließende Verschiebung bleibt möglich. Der Results-Button im Reader übernimmt im geöffneten Zustand die Farbe seines Fensters. | Minimierte Fenster sollen vorhersehbar auffindbar sein, ohne ihren frei beweglichen Charakter zu verlieren. Die Farbe muss denselben offenen Datensatz in Kachel, Fenster und Reader eindeutig zuordnen. |
| 2026-08-02 | Maximierte Result-Fenster verlassen den Cluster als explizit entkoppelter UI-Zustand; nur Minimieren koppelt sie wieder ein. Innerhalb des Clusters bleibt ein maximiertes Fenster aktiv, herausgezogene Fenster kÃ¶nnen parallel maximiert bleiben. | Die ClusterzugehÃ¶rigkeit darf nicht aus Position oder GrÃ¶ÃŸe abgeleitet werden: Weitere Ã–ffnungs-, Wiederherstellungs-, Auswahl- und Ansichtswechsel mÃ¼ssen frei platzierte Arbeitsfenster erhalten. Eine kleine, plattformneutrale Zustandslogik hÃ¤lt diese ÃœbergÃ¤nge deterministisch und testbar. |
| 2026-07-29 | Die Kopfsektion ist eine appweit gemeinsame Shell-Komponente (`.app-header-panel`): Work bÃ¼ndelt Werkzeugleiste, Filter und Status darin; Datahub, DB-Struktur, Result DB und Graph verwenden dieselbe HÃ¼lle, der Graph weiterhin Ã¼ber sein Portal. Kopf- und Inhaltscontainer teilen Hintergrundrolle und Rundung. | Die zuvor auf Topbar und Workspace-Platzhalter verteilte Sektion konnte je Bereich auseinanderlaufen und besaÃŸ keine eigene FlÃ¤che. Eine einzige `div`-HÃ¼lle hÃ¤lt Geometrie, Hintergrund und Radius konsistent, ohne Fachzustand oder Bereichskomponenten in die Shell zu verlagern. |
| 2026-07-27 | â€žAbweichung" ist ein eigenes, versioniertes Praedikat (`src/domain/deviation-predicate.ts`, Version 1.0.0) und nicht gleichbedeutend mit `is_ioe`: `is_ioe OR outcome_normalized = 'warning'`. | `is_ioe` bleibt vertragsstreng an eine festgestellte Exposition gebunden (RESULT_CONTRACT), waehrend Ergebnisse ohne diese Feststellung fachlich relevant sein koennen. Maester meldet dafuer `Investigate`, das als Outcome `warning` normalisiert wird und sonst aus jeder Abweichungsansicht fiele. Das Praedikat liest ausschliesslich normalisierte Achsen und gilt damit unveraendert fuer kuenftige Werkzeuge. |
| 2026-07-27 | Werkzeuggelieferte Textfelder werden ausgewertet dargestellt, nicht als Quelltext. Zustaendig ist ausschliesslich `RichTextValue` ueber `src/shared/markdown.ts`; kein Aufrufer formatiert selbst. | Mehrere Quellen schreiben Markdown in ihre Zellen. Ohne zentrale Auswertung entscheidet jede Ansicht neu, und `####`, `**` sowie Pipe-Tabellen landen woertlich in der Oberflaeche. Ein einziger Zustaendiger heisst: eine neue Quelle mit derselben Auszeichnung wird ohne weitere Aenderung richtig dargestellt. |
| 2026-07-27 | Der Anzeigewert einer Zelle behaelt seine Zeilenstruktur (`cellText`), waehrend `clean` fuer Schluessel, Kopfzeilen und Vergleiche zustaendig bleibt. | Die Faltung jeder Leerraumfolge zu einem Leerzeichen war fuer Vergleiche richtig und fuer Inhalte falsch: eine mehrzeilige Tabelle liess sich danach nicht mehr von einem Satz unterscheiden. |
| 2026-07-27 | Die Werkzeugherkunft eines Datensatzes wird in den Arbeitsansichten je Datensatz aufgeloest, nicht aus der Profil-ID des Datasets uebernommen. | Die Projektaggregation mischt alle Werkzeuge eines Mandanten und traegt deshalb `generic`. Ohne Aufloesung greifen die generischen Rueckfallregeln statt des deklarierten Werkzeugmappings, und Work weicht sichtbar von der Result DB ab. |
| 2026-07-27 | Ein Outcome `warning` erhaelt keine eigene Severity-Stufe; die Severity des Funds bleibt unveraendert. | Severity und Outcome sind getrennte Dimensionen. Die betroffenen Maester-Funde tragen bereits eine belastbare Severity (`high`, `medium`); eine Stufe `warning` haette diese Priorisierung geloescht. Kenntlich gemacht wird `warning` stattdessen auf der Outcome-Achse mit Textfarbe und Glyph sowie ueber die Spalte und den Filter â€žAbweichung". |
| 2026-07-27 | **ZurÃ¼ckgezogen:** die Entscheidungen und ProtokolleintrÃ¤ge der zweiten Agentensitzung vom 2026-07-26 18:42 bis 2026-07-27 01:44 (neue Shell mit Topbar-Titel, Context Strip und Status Bar; kanonische Severity-Stufe `warning` samt Maester-Profil 1.1.0/1.2.0; getrennte Farbrollen fÃ¼r PrimÃ¤r- und Nebenfilter; Palette `#A68AF9`, `#85BFF2`, `#FFA825`; Work-Referenz aus Screenshots). Ihre Umsetzung wurde auf Nutzerwunsch vollstÃ¤ndig zurÃ¼ckgenommen. Verbindlich bleiben die Designsprache in `.claude/skills/assessor-ui/` in ihrer ursprÃ¼nglichen Fassung sowie die Schritte 1 und 2 ihrer Umsetzungsreihenfolge. | Die EintrÃ¤ge bleiben als Historie stehen, weil dieser Plan getroffene Entscheidungen nicht stillschweigend umschreibt. Sie dÃ¼rfen aber nicht als geltender Stand gelesen werden: die zugehÃ¶rigen Dateien tragen ihre Regeln nicht mehr, und ein spÃ¤terer Leser wÃ¼rde sonst gegen einen Stand implementieren, den es nicht gibt. |
| 2026-07-27 | Die beiden vom Nutzer gelieferten Work-Screenshots ersetzen den zuvor technisch konsolidierten Zwischenstand als verbindliche visuelle Strukturreferenz fuer Schritt 5: 144-px-Sidebar mit Darstellungsumschaltern unten, 34-px-Work-Topbar mit Zaehlern und direkten Werkzeugen, zweizeiliges Filterband, Masterliste `clamp(300px, 21vw, 420px)`, Reader mit 48-px-Inset und vier Bearbeitungsfeldern in einer Zeile sowie 132-px-Kacheln ab 210 px mit F/R oben rechts und allen Metadaten ohne `+n`. | Die Nutzerkorrektur betrifft Aufbau und Dichte, nicht die zuletzt abgenommenen semantischen Farben. Das neue gespiegelte Asset `assets/work-reference.css` plus Laufzeitkopie und `work-visual-contract.test.ts` machen die Struktur fuer kuenftige Erweiterungen verbindlich. Filterorange/-violett, Auswahlblau, Severitys, Warning und das Sechseck mit weissem Haken bleiben unveraendert. Bis zur visuellen Nutzerabnahme bleibt Schritt 5 in Arbeit. |
| 2026-07-27 | Der von der Nutzerabnahme verworfene kontrastarme Zwischenstand ist keine finale Work-Referenz. Datenreiche Arbeitsansichten verwenden zentral `--surface-work-rail`, `--surface-work-item` und `--surface-work-item-hover`; Reader-Navigation, Titel und Bearbeitung bilden wieder eine kompakte Folge, und Tile-Badges bleiben einzeilig mit `+n`. Filter-, Auswahl- und Severity-Rollen bleiben unveraendert. | Die technisch konsolidierte Komponentenschicht hatte Grundflaeche und Arbeitsobjekte in Light zu wenig getrennt und im Reader zu grosse Leerraeume bewahrt. Die neuen Rollen leiten sich in beiden Themes ausschliesslich aus Grundflaeche und Struktur ab und sind in Skill, Laufzeit und Regressionstest gemeinsam verankert, sodass kuenftige datenreiche Erweiterungen dieselbe Hierarchie erhalten. |
| 2026-07-27 | Die Nutzerpraezisierung ersetzt fuer Work die bisher breitere Filterfarbregel: Ausschliesslich Primaerfilter innerhalb des orange gerahmten Bereichs und der Filter-Reset verwenden die Filterrollen. Ungesetzte Primaerfilter bleiben `#FFA825`/`#262626`, gesetzte Primaerfilter wechseln auf `#A68AF9`/weiss. Nebenfilter ausserhalb des Rahmens bleiben in Grund- und Auswahlzustand neutral und tragen weder `.band__control` noch `.is-filtered`. Maester-Profil 1.2.0 ordnet das fachliche Outcome `warning` zugleich der kanonischen Severity `warning` und der Ergebnisgruppe `Abweichung` zu. | Die Nutzerbilder trennen die schnelle fachliche Filterzone eindeutig von Quellen- und Datensatzauswahl. Die gemeinsame Maester-Regel verhindert, dass Warnungen in der Standardarbeitsmenge fehlen oder weiter als Medium erscheinen. Originalwerte und Provenienz bleiben erhalten; die Work-Projektion kann bereits persistierte Maester-Outcomes ohne Datenmutation korrekt darstellen, waehrend neue Importe die Zuordnung versioniert persistieren. |
| 2026-07-26 | Die aktuelle Nutzerabnahme ersetzt die frueheren Filterzustands- und Severity-Entscheidungen: Ungesetzte Command-Band-Filter bleiben `#FFA825` mit `#262626`; ein tatsaechlich gesetzter Filter wechselt auf `#A68AF9` mit weisser Tinte. Die kanonische Severity-Reihenfolge lautet `critical`, `high`, `medium`, `warning`, `low`, `info`, `unknown`; `warning` bewahrt seit Maester-Profil 1.1.0 ausschliesslich den nativen Maester-Wert `Warning` und verwendet in beiden Themes `#BFE5C7` mit der abgenommenen weissen Tinte. | Die Browsermarkierung unterscheidet den Grundzustand eines Filterfelds vom gesetzten Auswahlzustand. Eine gemeinsame werkzeuggebundene Severity-Normalisierung verhindert, dass Maester-Warning weiter als Medium kollabiert oder andere Werkzeuge pauschal umgedeutet werden. Skill, Laufzeit-Tokens, Filter-/Severity-Komponenten und Drift-Tests bilden dieselben Regeln ab; Originalwert und Provenienz bleiben erhalten. |
| 2026-07-26 | Die Nutzerkorrektur Ã¤ndert ausschlieÃŸlich die Tinte der orangefarbenen Filtersektion: Filterrahmen, Filterfelder und Filter-Reset verwenden in Dark und Light weiterhin `#FFA825`, darauf jedoch das Design-Schwarz `#262626` statt WeiÃŸ. PrimÃ¤raktionen und aktive Ansichten bleiben `#A68AF9` mit WeiÃŸ; Navigation, Auswahl, Information und Fokus bleiben `#85BFF2`. | Die eigene `--filter-on`-Rolle hÃ¤lt die Korrektur auf das Command Band begrenzt und macht sie fÃ¼r kÃ¼nftige Erweiterungen verbindlich. `#262626` auf `#FFA825` erreicht etwa 7,85:1; die bisherige Kontrastausnahme fÃ¼r Filterorange entfÃ¤llt. |
| 2026-07-26 | Die NutzerprÃ¤zisierung trennt die Filtersektion wieder von der allgemeinen Interaktionsfarbe: AusschlieÃŸlich Filterrahmen, Filterfelder und Filter-Reset verwenden in Dark und Light `#FFA825` mit immer weiÃŸer Tinte. PrimÃ¤raktionen und aktive Ansichten bleiben `#A68AF9` mit WeiÃŸ; aktive Navigation, Auswahl, Information und Fokus bleiben `#85BFF2`. Gesetzte Filter unterscheiden sich zusÃ¤tzlich Ã¼ber Wert beziehungsweise Trefferzahl und stÃ¤rkeres Schriftgewicht. | Das Referenzbild markiert die orange Filtersektion als eigene, stabile Arbeitszone. Eine eigene `--filter-surface`-/`--filter-on`-Rolle verhindert, dass Results-, Bookmark-, Datahub- oder andere AktivzustÃ¤nde orange werden. WeiÃŸ auf `#FFA825` erreicht etwa 1,93:1 und ist auf ausdrÃ¼cklichen Nutzerwunsch eine abgenommene Kontrastausnahme; feste Zone, Beschriftung, Wert und Gewicht codieren die Funktion redundant. |
| 2026-07-26 | Die NutzerprÃ¤zisierung ersetzt die beiden unmittelbar vorherigen Farbentscheidungen fÃ¼r aktuelle und kÃ¼nftige OberflÃ¤chen: Das Auswahlblau `#85BFF2` bleibt fÃ¼r aktive Navigation, Auswahl, Information und Fokus vollstÃ¤ndig erhalten. Die separate Filterrolle `#677DBF` entfÃ¤llt. PrimÃ¤raktionen, aktive Ansichten und sÃ¤mtliche Command-Band-Filter verwenden in Dark und Light `#A68AF9` mit immer weiÃŸer Tinte; gesetzte Filter bleiben zusÃ¤tzlich Ã¼ber Wert beziehungsweise Trefferzahl und stÃ¤rkeres Schriftgewicht erkennbar. | Die drei Browsermarkierungen trennen ausdrÃ¼cklich das beizubehaltende Auswahlblau von der zu ersetzenden Filter-/Aktionsfarbe. Die gemeinsame Akzentrolle verhindert eine weitere lokale Filterfarbe und der Drift-Test sichert zugleich das unverÃ¤nderte Blau sowie das Fehlen der alten Filtertokens. WeiÃŸ auf `#A68AF9` erreicht etwa 2,75:1 und ist daher eine ausdrÃ¼cklich abgenommene Ausnahme, die durch Form, Position und Beschriftung redundant abgesichert wird. |
| 2026-07-26 | Die frÃ¼here Zuordnung des Ockers `#A16207` wird ausschlieÃŸlich fÃ¼r gesetzte Filter prÃ¤zisiert: PrimÃ¤raktionen, aktive Ansichten und ungefilterte Command-Band-Controls bleiben Ocker mit weiÃŸer Tinte. Ein gesetzter Filter verwendet in Dark und Light die eigene Rolle `#677DBF` mit `#0D0D10` als Tinte; Auswahl und Information bleiben `#85BFF2`, Medium bleibt Dark `#D9962A` und Light `#F29F05`. | Die zusÃ¤tzliche Filterrolle trennt eine wirkende Filterbedingung sichtbar von einer Aktion, einer Objektselektion und einer Severity. Dunkle Tinte erreicht auf `#677DBF` 4,86:1; WeiÃŸ wÃ¼rde mit 3,99:1 die verbindliche Kontrastgrenze verfehlen. Filterwert beziehungsweise Trefferzahl bleibt als zweites, nicht farbabhÃ¤ngiges Signal sichtbar. |
| 2026-07-26 | Aktive Filter, Ansichtsumschalter, Command-Band-Steuerungen und PrimÃ¤raktionen verwenden in Dark und Light einheitlich `#A16207` mit weiÃŸer Tinte. Medium Ã¼bernimmt themeabhÃ¤ngig die bisherigen Aktionswerte: Dark `#D9962A`, Light `#F29F05`; Beschriftung und Haken bleiben auf ausdrÃ¼cklichen Nutzerwunsch weiÃŸ. Auswahl und Information bleiben davon getrennt und unverÃ¤ndert blau `#85BFF2`. | Der Nutzer meinte mit dem Tausch die im Work-Screenshot sichtbare orange aktive Steuerung, nicht die blaue Auswahlrolle. Die semantische Trennung verhindert, dass FilteraktivitÃ¤t, Objektselektion und Severity dieselbe Farbe verwenden. Die bewusst akzeptierte Medium-Kontrastausnahme wird durch das ausgeschriebene Label, die feste Sechseckform und Position redundant abgesichert. |
| 2026-07-26 | Die GrundflÃ¤che ist die Ã¤uÃŸere Helligkeitsgrenze aller neutralen OberflÃ¤chen: Dark `#262626` ist am dunkelsten, Light `#F3F3F3` am hellsten. `#6E6C72` beziehungsweise `#B0B1B0` ist die Strukturgrenze fÃ¼r starke Linien und die Ableitung neutraler Zwischenstufen, nicht die groÃŸflÃ¤chige Shell-FÃ¼llung. Shell, Panels, Eingaben, Hover, Aktiv und Overlays werden in beiden Themes mit denselben Anteilen zwischen `--surface-app` und `--structure` abgeleitet. | Die vorherige Zuordnung invertierte die Nutzerpalette: Dark-Panels lagen mit `#1A1A1E`/`#16161A` unter der dunkelsten GrundflÃ¤che, Light-Panels mit `#FFFFFF` Ã¼ber der hellsten; zugleich dominierte die Strukturfarbe die gesamte Shell. Eine gespiegelte semantische Staffelung erhÃ¤lt die beabsichtigten Extreme, macht beide Themes gleichwertig und lÃ¤sst spÃ¤tere Palettenkorrekturen automatisch in alle neutralen FlÃ¤chen einflieÃŸen. |
| 2026-07-26 | FÃ¼r sichtbare OberflÃ¤chen ist der Projektskill `.claude/skills/assessor-ui/` die verbindliche Designquelle. Farbrollen, Severity-Palette und Komponenten werden zuerst dort gepflegt und anschlieÃŸend in die Laufzeitkopien unter `src/styles/` gespiegelt; der DesignprÃ¼fer vergleicht die Tokendeklarationen automatisch. Severity verwendet projektweit die fÃ¼nf festgelegten Farben und immer weiÃŸe Beschriftung beziehungsweise einen weiÃŸen Haken im aufrechten Sechseck. Die gemeinsame AnwendungshÃ¼lle besteht aus einer Topbar mit Seitentitel und globalen Theme-/Dichteaktionen, einer Navigation, einem dauerhaften Context Strip und einer dauerhaften Status Bar. | Die Regel macht spÃ¤tere Korrekturen und Erweiterungen zu Ã„nderungen am Gesamtsystem statt zu lokalen SonderfÃ¤llen. Die Severity-Tinte bleibt weiÃŸ; Critical, High, Low, Info und Unknown erreichen mindestens 4,92:1. Medium ist nach dem ausdrÃ¼cklich gewÃ¼nschten Rollentausch die einzige abgenommene Kontrastausnahme und wird zusÃ¤tzlich durch Textlabel sowie feste Form/Position redundant codiert. Die gemeinsame Shell verhindert pro Ansicht auseinanderlaufende Kopf-, Kontext- und Statusbereiche. |
| 2026-07-26 | Die verbindliche Designsprache liegt als Projektskill unter `.claude/skills/assessor-ui/`; seine beiden CSS-Dateien sind die Implementierungsbasis und werden als `src/styles/ui-tokens.css` und `src/styles/ui-components.css` in das Projekt gespiegelt (Ã„nderungen zuerst am Skill, dann an der Kopie). Die EinfÃ¼hrung erfolgt additiv statt als Ersetzung: Das Tokenset ist geladen, die Komponentenschicht noch nicht. Der Altbestand fÃ¼hrt seine zehn abweichenden MaÃŸ- und Akzentwerte unter `--legacy-*` weiter; die sechs in beiden Systemen vorhandenen Klassennamen (`btn`, `icon-btn`, `input`, `select`, `tile-grid`, `is-bookmarked`) werden je Ansicht aufgelÃ¶st, beginnend mit `Work`. | Ein direktes Ãœberschreiben von `tokens.css` und `components.css` hÃ¤tte 33 aktiv referenzierte Tokens undefiniert gelassen und keine der 48 Altklassen bedient â€” der DesignprÃ¼fer schlÃ¤gt darauf zu Recht an. Umgekehrt genÃ¼gt es nicht, die Komponentenschicht nur spÃ¤ter zu laden: Cascade Layers verlieren lediglich bei gemeinsamen Eigenschaften, wÃ¤hrend zusÃ¤tzliche Eigenschaften (`height`, `gap`, `justify-content`) sofort wirken und bestehende Ansichten still verÃ¤ndern â€” im Browser als 30px feste HÃ¶he statt 24px MindesthÃ¶he an bestehenden SchaltflÃ¤chen gemessen. Die additive Stufe hÃ¤lt deshalb genau die Zusage, die der Skill braucht (seine Tokens existieren im Build), ohne den bestehenden Zustand anzutasten. |
| 2026-07-23 | Der extern gelieferte Datenvertrag RESULT_CONTRACT/CANONICAL_MODEL 1.0.0 wird additiv auf das bestehende Modell abgebildet (Pfad A): `result_type`, `is_ioe` und eine Asset-/Kantenschicht ergÃ¤nzen `assessor_finding_occurrences` beziehungsweise neue additive Tabellen; es entsteht keine zweite, schreibbare `canonical_result`-Haupttabelle. `docs/CANONICAL_MODEL.md` bleibt der verbindliche implementierte Stand, der externe Vertragstext liegt unverÃ¤ndert unter `docs/RESULT_CONTRACT.md` und `docs/CANONICAL_MODEL_1.0.0.md`. | Eine zweite Resulttabelle oder ein zweites Importmodell wÃ¼rde die Entscheidung vom 2026-07-22 (Unified Result Model als ausschlieÃŸlich lesende Projektion) unterlaufen und eine zweite Datenwahrheit erzeugen. Die drei fachlich neuen Zusagen des Vertrags lassen sich additiv realisieren, ohne die feiner geschnittenen Bestandsachsen (Outcome/AusfÃ¼hrung, Review) zu verlieren. |
| 2026-07-23 | `result_state` aus RESULT_CONTRACT 1.0.0 wird nicht als eigene Spalte gefÃ¼hrt, sondern per versionierter Regel (`RESULT_CONTRACT_MAPPING_VERSION`, `src/domain/result-contract-mapping.ts`) aus den bestehenden Achsen `outcome_normalized` und `technical_execution_state` projiziert. | Die Trennung von fachlichem Outcome und technischer AusfÃ¼hrung wurde am 2026-07-22 bewusst eingefÃ¼hrt, damit ein technischer Parser-/Toolfehler nicht als fachlich fehlgeschlagener Check erscheint. Eine kollabierte `result_state`-Spalte mit dem Wert `error` wÃ¼rde diese Unterscheidung wieder aufheben. |
| 2026-07-22 | Nicht als Findings ausgewÃ¤hlte Quelltabellen dÃ¼rfen ihre Originalzeilen optional im SourceTableRecord bewahren; Tabellen mit Finding-Vorkommen speichern diese Zeilen nicht zusÃ¤tzlich. In Work erscheinen unterstÃ¼tzende Tabellen nach den fachlichen Finding-Ansichten und werden ausschlieÃŸlich Ã¼ber explizite Result-Referenzen verknÃ¼pft. | Scanner-Workbooks wie PurpleKnight halten Ergebnisdetails in separaten Sheets. Tabellenmetadaten allein reichen nicht zur spÃ¤teren Rekonstruktion; die begrenzte, additive Zeilenpersistenz verhindert Datenverlust und vermeidet zugleich Doppelhaltung der Finding-Haupttabelle. |
| 2026-07-22 | PingCastle-Regelpunkte und Report-Scores bleiben getrennte dynamische Werte der jeweiligen Quelldatei. Statische Beschreibung, technische ErklÃ¤rung, LÃ¶sung und Dokumentation dÃ¼rfen fÃ¼r die Work-Darstellung nur aus einer im selben Projekt gespeicherten HTML-Begleitdatei mit identischem Dateistamm und identischer Rule ID ergÃ¤nzt werden; die Katalogquelle wird angezeigt und die kanonischen Originalfelder werden nicht Ã¼berschrieben. | Die PingCastle-XML serialisiert gematchte Regeln und berechnete Scores, aber nicht den vollstÃ¤ndigen statischen Regelkatalog des HTML-Renderers. Eine explizite formatÃ¼bergreifende PrÃ¤sentationsanreicherung liefert den erwarteten Inhalt, ohne Scanwerte zu erfinden, Provenienz zu verlieren oder eine externe LaufzeitabhÃ¤ngigkeit einzufÃ¼hren. |
| 2026-07-22 | Nach einem erfolgreichen verbundenen Import wird Work aus dem erneut geladenen persistierten kanonischen Mandantenmodell aufgebaut; die rohe Parserprojektion bleibt ausschlieÃŸlich der lokale Offline-Fallback. PingCastle priorisiert das fachliche Feld Title als KartenÃ¼berschrift. | Persistenz und Darstellung dÃ¼rfen nicht zwei semantische Wahrheiten zeigen. Insbesondere darf ein erkannter PingCastle-XML-Report nach dem Commit nicht als generischer Elementbaum erscheinen oder Kategorien statt Finding-Titeln hervorheben. |
| 2026-07-22 | Native Finding-Vorkommen ohne `SourceTable` werden in der Work-KompatibilitÃ¤tsprojektion je Importdatei als eigene Unteransicht mit Werkzeug, Scandatum und technischem Dateiformat dargestellt. | Native Objekt- und Regelprovenienz darf nicht durch eine kÃ¼nstliche Tabelle verfÃ¤lscht werden; gleichzeitig mÃ¼ssen vollstÃ¤ndig persistierte Findings in Work gezielt nach Quelldatei beziehungsweise Format auswÃ¤hlbar bleiben. |
| 2026-07-22 | Ein verknÃ¼pfter Scannerbericht wird als gesamter Scan Run innerhalb seines bestÃ¤tigten Projekts gelÃ¶scht. Die Mutation invalidiert Vergleiche desselben Assessments, rÃ¤umt nur verwaiste Definitionen und Fingerprints auf und entfernt ein Assessment nur dann, wenn kein Scan Run verbleibt. MÃ¶gliche Duplikate werden ausschlieÃŸlich als nicht blockierende Heuristik fÃ¼r dasselbe bekannte Werkzeug und Dateizeitpunkte innerhalb von 60 Sekunden behandelt; exakte Hash-Dubletten bleiben davon getrennt. | Die Scan-Historie muss fachlich konsistent und mandantensicher lÃ¶schbar sein, ohne gemeinsame Finding-IdentitÃ¤ten oder andere LÃ¤ufe zu verlieren. Exportformate desselben Scans liegen typischerweise zeitlich eng beieinander, Dateizeitpunkte sind aber keine belastbare IdentitÃ¤t und dÃ¼rfen einen Import deshalb nur warnen, nicht sperren. |
| 2026-07-22 | Native PingCastle-Findings werden durch einen werkzeugspezifischen Source Extractor aus bereinigtem HTML beziehungsweise der dekodierten `HealthcheckData/RiskRules`-XML-Hierarchie gewonnen. Dieselbe Rule ID bildet formatÃ¼bergreifend dieselbe Finding-Definition; die Vorkommen und ihre Locators bleiben je Quelldatei getrennt. | PingCastle stellt Findings nicht verlÃ¤sslich als generische Datentabelle bereit und rendert dieselbe Regel im HTML mehrfach. Stabile technische Rule IDs vermeiden falsche TitelidentitÃ¤ten, wÃ¤hrend getrennte Vorkommen die absichtlich mehrfach hochgeladenen Exportformate und ihre Provenienz erhalten. |
| 2026-07-22 | Die GPO-Submission-Vorstufe lÃ¤sst den isolierten Worker weiterhin den gesamten Transportcontainer verifizieren, gibt aber nur die kompakte Containererkennung zurÃ¼ck; das vollstÃ¤ndige Inventar bleibt in der Analysejob-/Parsergrenze. Workerfehler werden ausschlieÃŸlich als sichere Codes und Namen diagnostiziert. | Ein vollstÃ¤ndiges Inventar in Vorstufe, Hauptprozess und Analyseworker erzeugt bei groÃŸen entpackten Ordnern unnÃ¶tige Speicherspitzen. Die kompakte RÃ¼ckgabe erhÃ¤lt die SicherheitsprÃ¼fung, ohne Quelldetails oder rohe Fehlermeldungen zu vervielfachen. |
| 2026-07-22 | Scanner-Outcome und technischer AusfÃ¼hrungszustand werden getrennt persistiert; die historische Finding-Statusdimension bleibt nur als kompatible Quelle fÃ¼r Altdaten bestehen. Resultkategorien besitzen Namespace sowie Profil-ID/-Version und werden Ã¼ber eine mehrwertige Relation zu Occurrences gebunden. | Ein technischer Parser-/Toolfehler ist kein fachlich fehlgeschlagener Check. Namespace und Profilversion verhindern unbeabsichtigte Vermischung gleich benannter, aber semantisch verschiedener Toolkategorien. |
| 2026-07-22 | Das Unified Result Model ist eine ausschlieÃŸlich lesende Repository-Projektion. Der erste Vertikalschnitt projiziert Scanner-Vorkommen; GPO-Beobachtungen werden erst nach persistierter, versionierter Policy-Evaluation als eigene Source-Kind-Zeilen ergÃ¤nzt. | Eine schreibbare Resulttabelle oder die direkte Umdeutung von PolicyObservation wÃ¼rde eine zweite Datenwahrheit beziehungsweise unbelegte Sicherheitsfindings erzeugen. Die gemeinsame Repositorygrenze hÃ¤lt Local, PostgreSQL, API und Browser synchron. |
| 2026-07-22 | Der GPO-Persistenzworker verarbeitet Policyartefakte backupwurzelweise, reduziert jedes Dokument unmittelbar und hÃ¤lt keine vollstÃ¤ndigen Parser-Zwischenmodelle oder Containerduplikate in seiner RÃ¼ckgabe. Registry Preferences werden nach denselben SicherheitsvorprÃ¼fungen mit dem lokal gebÃ¼ndelten `saxes` 6.0.0 ereignisbasiert statt als JSDOM-Baum geparst; Quellzeilen aller Preference-CSEs entstehen mit einem gemeinsamen linearen Scanner. | Der zuvor reproduzierte Workerheap-Peak bestand aus quadratischer Provenienzberechnung, gleichzeitig gehaltenen DOM-/Instruktionsmodellen und unnÃ¶tiger Ergebnisklonung. FrÃ¼he Reduktion und SAX begrenzen den Speicher, ohne das Workerlimit anzuheben, semantische Provenienz zu verlieren oder aktive/externe XML-Funktionen zuzulassen. |
| 2026-07-21 | Dead-Letter-GPO-Analysen werden ohne erneuten Upload projektgebunden zurÃ¼ck in die Queue gestellt. Das bewusste LÃ¶schen ist nur fÃ¼r vollstÃ¤ndig fehlgeschlagene GPO-Artefakte nach exakter BestÃ¤tigung zulÃ¤ssig; relationale Historie und eine unabhÃ¤ngige LÃ¶sch-Outbox werden in einer Transaktion geschrieben, bevor die backendkontrollierte Dateikopie entfernt wird. GroÃŸe Worker-Eingaben verwenden eine Ã¼bertragene Kopie bei weiterhin harten Heapgrenzen. | Retry bewahrt das unverÃ¤nderte Original und vermeidet unnÃ¶tige Uploads. Die Outbox schlieÃŸt das Absturzfenster zwischen Datenbankcommit und DateilÃ¶schung, ohne die Quelldatei des Benutzers anzutasten; Transfer statt Structured Clone reduziert temporÃ¤ren Speicherbedarf, ohne die Ressourcengrenze aufzugeben. |
| 2026-07-21 | GPO-Artefakt und initialer Analysejob werden atomar im Repository angelegt. Dateispeicher und Datenbank werden durch sofortiges Compensating Delete sowie eine periodische, 24 Stunden altersgesicherte und mengenbegrenzte Reconciliation abgeglichen. Der Mandantenstatus wird aus persistierten Artefakt-, Job- und Processing-Daten abgeleitet, nicht aus flÃ¼chtigem React-Zustand. | Dateisystem und PostgreSQL unterstÃ¼tzen keine gemeinsame Transaktion. Die Kombination schlieÃŸt das normale Inkonsistenzfenster, schÃ¼tzt parallele Uploads durch Schonfrist und macht Queue-, Retry-, Dead-Letter- und ErgebniszustÃ¤nde nach Navigation oder Neustart nachvollziehbar. |
| 2026-07-21 | Entpackte GPO-Backupordner werden im Chrome-Browser Ã¼ber relative `webkitdirectory`-Pfade eingelesen und als deterministischer unkomprimierter Transportumschlag an dieselbe projektgebundene ZIP-Ingestion Ã¼bergeben. | Benutzer mÃ¼ssen kein Zwischenarchiv erzeugen; relative Struktur und Dateibytes bleiben erhalten. Eine einzige gehÃ¤rtete Backend-Vertrauensgrenze inventarisiert sowohl direkte als auch browserseitig umschlossene Backups erneut. |
| 2026-07-21 | Der ausgewÃ¤hlte Zielmandant ist dauerhafter Kontext des gesamten Importworkflows und muss bei jedem PhasenÃ¼bergang einschlieÃŸlich manueller Mappingfreigabe erhalten bleiben. | Vorschau und BestÃ¤tigung sind keine neue Importsitzung. Ein Verlust von `targetProjectId` wÃ¼rde einen fachlich falschen neuen Mandanten erzeugen und den Scan aus der erwarteten Mandantenhistorie entfernen. |
| 2026-07-21 | Technische Importtabellen-IdentitÃ¤ten bestehen aus Quelldatei, Tabellenname und stabilem Tabellenindex; KompatibilitÃ¤tsprojektionen Ã¼bernehmen diese IdentitÃ¤t unverÃ¤ndert. | Anzeigenamen und Captions sind in HTML-Berichten nicht eindeutig. Der Index ist Bestandteil des Source Locators und verhindert, dass unterschiedliche Tabellen bei Recognition, Candidate-Mapping oder kanonischer Persistenz auf dieselbe ID kollabieren. |
| 2026-07-21 | Drive Maps wird als eigener usergebundener Preference-CSE reduziert. Laufwerksbuchstabe, `useLetter` und C/D/R/U bestimmen gemeinsam den technischen Selektor; `thisDrive` und `allDrives` bleiben getrennt. UNC-Pfad, Persistenz, Label und optionaler Benutzername werden erhalten, ein Kennwort nur als `passwordAttributePresent`. | Microsoft definiert fÃ¼r `useLetter=0` abhÃ¤ngig von der Aktion Delete-Bereich, ersten freien Buchstaben oder erstes vorhandenes Mapping im Bereich. Eine Reduktion auf Buchstabe oder Endmapping wÃ¼rde diese Verarbeitung und die SichtbarkeitsprÃ¤zedenz verlieren; ohne Zielsystem und RSoP bleibt die Wirkung unbekannt. |
| 2026-07-21 | Services wird als eigener computergebundener Preference-CSE reduziert. Die Preference-Instruktion heiÃŸt `configure`; Laufzeitaktion, Starttyp, Fehleraktionen und dokumentierte Zeitfelder bleiben getrennte Werte. Ein vorhandenes Dienstkontokennwort wird ausschlieÃŸlich als `passwordAttributePresent` modelliert. | Services besitzt keine Registry-C/D/R/U-Aktion. `RESTART_IF_REQUIRED` hÃ¤ngt vom Starttyp und Clientzustand ab; ohne Zielsystem und RSoP darf daraus kein Endzustand abgeleitet werden. Zeitfelder werden nicht ohne Spezifikationseinheit umgerechnet und `cpassword` wird nicht weitergegeben. |
| 2026-07-21 | Local Users and Groups wird als eigener Preference-CSE reduziert. Lokale Benutzer und Gruppen bleiben verschiedene Werttypen; bei Gruppen haben SIDs Vorrang vor Namen, Delete-all-Operationen bleiben vor der geordneten Add/Remove-Mitgliedsliste erhalten. Bei Benutzern wird ein Passwort ausschlieÃŸlich als boolescher `passwordAttributePresent`-Indikator modelliert. | Benutzer-, Gruppen- und Mitgliedschaftsoperationen besitzen unterschiedliche Ziel- und Reihenfolgesemantik. Eine Mengenaggregation oder Speicherung von `cpassword` wÃ¼rde die tatsÃ¤chliche Clientverarbeitung verfÃ¤lschen beziehungsweise ein bekanntes Geheimnis unnÃ¶tig weiterverbreiten. |
| 2026-07-21 | Group Policy Preferences erhalten keinen universellen Key/Value-Reducer. Der erste unterstÃ¼tzte CSE-Typ ist Registry Preferences; jede Item-UID bleibt mit Verarbeitungsreihenfolge, Aktion, Deaktivierung, Remove-on-unapply, Apply-once und nicht ausgewertetem Item-Level-Targeting als Instruktion erhalten. Registry Policy und Registry Preference bleiben verschiedene Delivery-Mechanismen. | Microsoft definiert sequenzielle CSE-Verarbeitung und aktionsabhÃ¤ngige Create/Delete/Replace/Update-Semantik. Targeting und Persistenzverhalten kÃ¶nnen die tatsÃ¤chliche Wirkung Ã¤ndern; ein kollabierter Endwert oder eine Gleichsetzung mit `Registry.pol` wÃ¼rde diese AbhÃ¤ngigkeiten verlieren. |
| 2026-07-21 | Advanced Audit Policy verwendet ausschlieÃŸlich die technische Subcategory-GUID und den numerischen Auditflagwert 0 bis 3 als IdentitÃ¤t und Wert. Anzeigenamen werden nicht semantisch verwendet, System- und benutzerspezifische Ziele nicht zusammengefÃ¼hrt und Advanced Audit bleibt von Legacy Audit getrennt. | Anzeigenamen und Ein-/Ausschlusstexte sind lokalisierbar. Eine ZusammenfÃ¼hrung verschiedener Ziel- oder Auditmechanismen wÃ¼rde unterschiedliche Anwendungsebenen verschleiern; ohne RSoP darf eine Backupkonfiguration zudem nicht als effektiv behauptet werden. |
| 2026-07-21 | Security Templates werden abschnittsspezifisch in rohe Instruktionen und anschlieÃŸend durch einen eigenen versionierten Reducer in Policy-Beobachtungen Ã¼berfÃ¼hrt. Unterschiedliche Dubletten werden als Konflikt behalten; unbekannte Abschnitte bleiben unvollstÃ¤ndig und effektive Anwendung bleibt `unknown`. | Security-Template-Abschnitte besitzen unterschiedliche Semantik. Eine universelle Key/Value- oder Last-write-wins-Logik wÃ¼rde insbesondere Principal-Mengen, Registry-Typen und widersprÃ¼chliche Instruktionen verfÃ¤lschen und ohne RSoP unzulÃ¤ssig Wirksamkeit behaupten. |
| 2026-07-21 | Ein GPO-Analysejob liest ausschlieÃŸlich das projektgebundene backendkontrollierte Original mit erneuter GrÃ¶ÃŸen-/SHA-256-PrÃ¼fung. Processing Run und Backupinstanzen werden atomar und unverÃ¤nderlich vor dem Jobabschluss gespeichert; deterministische IDs erkennen einen Crash-Retry exakt, abweichende Wiederholungen werden abgelehnt. | Ein Prozessabbruch zwischen Analyse und Queue-Abschluss darf weder Ergebnisse verlieren noch Historie duplizieren oder Ã¼berschreiben. Die Datenbanktransaktion bildet die fachliche Commit-Grenze, der Lease-Job bleibt kontrolliert wiederholbar. |
| 2026-07-21 | GPO-Uploads werden ausschlieÃŸlich Ã¼ber eine projektgebundene Backend-Submission angenommen: ProjektprÃ¼fung und begrenzte Worker-VorprÃ¼fung erfolgen vor Speicherung; Originale erhalten `secret`-SensitivitÃ¤t, der Webroot darf den Speicher nicht enthalten und die API gibt keine Speicherreferenz aus. Ein versionierter projektweit idempotenter Job trennt Annahme von Analyse. | UnvertrauenswÃ¼rdige oder projektlose Bytes dÃ¼rfen nicht aufbewahrt werden; Rohartefaktzugriff und Parserlast bleiben Backendaufgaben. Die Queuegrenze erlaubt reproduzierbare spÃ¤tere AusfÃ¼hrung, ohne bereits ErgebnisvollstÃ¤ndigkeit zu behaupten. |
| 2026-07-20 | GPO-GUID und Backup-GUID werden ausschlieÃŸlich aus unterstÃ¼tzten XML-Inhalten getrennt abgeleitet; Anzeigenamen und Ordnernamen sind niemals technische IdentitÃ¤t. Erkannte ungÃ¼ltige oder widersprÃ¼chliche IdentitÃ¤ts-, DomÃ¤nen- oder Zeitwerte blockieren die Ableitung vollstÃ¤ndig. | Microsoft modelliert `GpoBackup.Id` als Backupinstanz getrennt von `GpoBackup.GpoId`; Namen sind nicht eindeutig. Fail-closed verhindert die scheinbar plausible Auswahl einzelner Werte aus widersprÃ¼chlichen Metadaten. |
| 2026-07-20 | Rohartefakte werden Ã¼ber zufÃ¤llige BackendschlÃ¼ssel nach privatem Staging, Flush und tatsÃ¤chlicher Hash-/GrÃ¶ÃŸenprÃ¼fung Ã¼berschreibungsfrei verÃ¶ffentlicht und beim Lesen erneut geprÃ¼ft. Die Speicherimplementierung wird erst mit expliziter Root-, Projekt- und Autorisierungsbindung Ã¶ffentlich angebunden. | Reprocessing benÃ¶tigt unverÃ¤nderte Bytes, wÃ¤hrend Dateinamen, Clientpfade und Webroot keine Speicher- oder ZugriffsautoritÃ¤t sein dÃ¼rfen. |
| 2026-07-20 | GPO-ZIPs werden in einem eigenen ressourcenbegrenzten Backend-Worker zweistufig verarbeitet: vollstÃ¤ndige Struktur-, Pfad-, Kollisions-, Typ- und BereichsprÃ¼fung vor Dekompression, danach begrenzte In-Memory-PrÃ¼fung von Ist-GrÃ¶ÃŸe, KompressionsverhÃ¤ltnis, CRC und SHA-256. ArchiveintrÃ¤ge werden nicht auf das Dateisystem ausgeschrieben. | Zentralverzeichnisangaben allein sind nicht vertrauenswÃ¼rdig; die Trennung hÃ¤lt GPO-Containerlogik aus Browser und Scannerparsern heraus und begrenzt manipulierte oder komprimierte Eingaben anhand tatsÃ¤chlich gelesener Daten. |
| 2026-07-20 | GPO-Snapshots werden ausschlieÃŸlich Ã¼ber Projekt, technisch belegte DomÃ¤ne und expliziten Backupsatz gruppiert; Namen, Pfade und behauptete Zielbenutzer sind keine Gruppierungs- oder Scope-Evidenz. Historische oder nicht eindeutig zuordenbare Instanzen bleiben getrennt. | Nur technisch belegte Gleichzeitigkeit verhindert erfundene Konflikte und eine Vermischung verschiedener DomÃ¤nen oder ErhebungsstÃ¤nde. |
| 2026-07-20 | Aussagen Ã¼ber die Abwesenheit einer Einstellung innerhalb eines Backupsatzes sind nur fÃ¼r einen konsistenten, manifestgestÃ¼tzten vollstÃ¤ndigen DomÃ¤nenexport mit exakter erwarteter und beobachteter GPO-Anzahl sowie vollstÃ¤ndig unterstÃ¼tzten Einzelinstanzen zulÃ¤ssig. | SetvollstÃ¤ndigkeit und InstanzvollstÃ¤ndigkeit sind unabhÃ¤ngig; Teilmengen, ParserlÃ¼cken und unbekannte Artefakte dÃ¼rfen keine negativen Gesamtaussagen erzeugen. |
| 2026-07-20 | Relative Artefaktpfade werden vor jeder GPO-Verarbeitung NFC-normalisiert und gegen Traversal, absolute/UNC-/Laufwerkspfade, ADS, Windows-GerÃ¤tenamen, Steuer-/Bidi-Zeichen sowie Unicode-/Case-Kollisionen validiert. Skripte werden hÃ¶chstens inventarisiert und niemals als unterstÃ¼tzter aktiver Inhalt behandelt. | Archivmetadaten und Dateinamen sind nicht vertrauenswÃ¼rdig; plattformabhÃ¤ngige Aliasbildung darf weder Dateien Ã¼berschreiben noch Sicherheitsentscheidungen umgehen. |
| 2026-07-20 | FÃ¼r neu verarbeitete Scannerdateien ist das bestÃ¤tigte `CandidateMappingResult` die einzige semantische Quelle der kanonischen Persistenz; die direkte UI-Tabellenprojektion bleibt nur als Legacy-Fallback ohne vorhandenes Mapping. Native Candidate-FeldbestÃ¤tigungen verwenden separat validierte Decision-IDs. | Vorschau, Benutzerfreigabe, Reprocessing und Persistenz mÃ¼ssen dieselben versionierten Entscheidungen und Originalwerte verwenden; native Objektprovenienz darf nicht durch eine KompatibilitÃ¤tstabelle ersetzt oder durch eine zweite Mappinglogik verfÃ¤lscht werden. |
| 2026-07-20 | Allgemeine Importartefakte und Processing Runs sind unverÃ¤nderliche, projektgebundene Historienobjekte; persistente Ingestion Jobs werden projektweit idempotent, mit begrenzten Versuchen, Leases, Recovery und Dead Letter verarbeitet. | Reprocessing muss reproduzierbar bleiben, parallele Worker dÃ¼rfen AuftrÃ¤ge nicht doppelt bearbeiten, und wiederholte Requests oder Leerlauf-Polls dÃ¼rfen keine fachliche Ã„nderung vortÃ¤uschen. |
| 2026-07-20 | Vor Phase 14 werden Phase 13A fÃ¼r Ingestion 2.0 und Phase 13B fÃ¼r die deterministische GPO-/Baselineanalyse eingefÃ¼gt; historische Phasen bleiben unverÃ¤ndert. | Die Querschnittsfunktion baut auf den abgeschlossenen Phasen 3 bis 13 auf, ist kein Firmenbetriebsthema und benÃ¶tigt eine kontrollierte Erweiterung gemeinsamer Import- und Persistenzgrenzen. |
| 2026-07-20 | Technisches Format, Quellwerkzeug, Reportvariante, fachliche Beobachtung und kanonisches Finding sind getrennte Ebenen mit eigenen Adapter-, Extractor- und MappingvertrÃ¤gen. | Ein Format soll einmal sicher dekodiert werden, ohne Toolwissen in Parsern oder doppelte Businesslogik fÃ¼r jede Tool-Format-Kombination. |
| 2026-07-20 | Die Batch-WerkzeugÃ¼bertragung vom 2026-07-18 wird prÃ¤zisiert: Sie darf nur die Scan-Lauf-Zuordnung und Anzeige einer generischen Begleitdatei bestimmen; Dateiprofil, Extraktion und Mapping benÃ¶tigen weiterhin eigene strukturelle Validierung. | Ein fachlich zusammengehÃ¶riger Mehrdatei-Export soll gemeinsam angezeigt werden, ohne eine unbekannte Begleitdatei fÃ¤lschlich mit werkzeugspezifischer Parsing- oder Finding-Logik zu verarbeiten. |
| 2026-07-20 | Source Extractors sind ausschlieÃŸlich statisch registrierte, versionierte Komponenten und erzeugen neutrale FindingCandidate-Quellobjekte; kanonische Rollen und IdentitÃ¤ten bleiben Aufgabe nachgelagerter Mappingprofile. | Reportstruktur und fachliche Semantik mÃ¼ssen getrennt bleiben; importierte Inhalte dÃ¼rfen keinen Code registrieren, und ein Spezialextractor darf den generischen Fallback nur mit positiver struktureller Evidenz verdrÃ¤ngen. |
| 2026-07-20 | Extraktionsvarianten und Mappingprofile werden unabhÃ¤ngig versioniert; Recognition und Candidate-Mapping verwenden eine gemeinsame Feldrollen-Evidenz, und bestÃ¤tigte Overrides werden bei der Neuberechnung Ã¼bernommen. | Reportstruktur darf die fachliche Semantik nicht fest verdrahten; Vorschau, BestÃ¤tigung und spÃ¤teres Reprocessing mÃ¼ssen dieselbe reproduzierbare Mappingentscheidung verwenden. |
| 2026-07-20 | Dauerhafte Finding-IdentitÃ¤ten entstehen nur aus stabilen werkzeuggebundenen Regel-IDs, eindeutigen technischen Framework-/Control-IDs oder explizit bestÃ¤tigten lokalen Regeln; Titel und Merkmalskombinationen bleiben Reviewhinweise. | Gleichlautende oder Ã¤hnlich benannte Findings dÃ¼rfen weder global zusammengefÃ¼hrt noch als persistent, neu, gelÃ¶st oder wiederaufgetreten klassifiziert werden, solange keine belastbare technische oder bestÃ¤tigte lokale IdentitÃ¤t vorliegt. |
| 2026-07-20 | Parser werden zentral nach validierter Datei-/Containersignatur und Inhaltsstruktur gewÃ¤hlt; Dateiendung und Client-MIME sind nur schwache Evidenz. Generische ZIPs werden bis zur expliziten Containeradapterphase nicht als Excel oder Text verarbeitet. | Manipulierte oder falsch benannte Dateien dÃ¼rfen weder formatbezogene Sicherheitslimits umgehen noch einen ungeeigneten Parser erzwingen; ContainerunterstÃ¼tzung muss explizit und ressourcenbegrenzt eingefÃ¼hrt werden. |
| 2026-07-20 | DecodedSourceDocument erweitert den bestehenden Importvertrag additiv um typisierte Sichten, Locator-Provenienz und Processing-States; ImportDocument bleibt vorerst ein KompatibilitÃ¤tsname und tabellarische Projektionen werden als solche gekennzeichnet. | Native Objekt-, Hierarchie- und Textstrukturen dÃ¼rfen nicht durch eine kÃ¼nstliche Tabelle ersetzt werden, wÃ¤hrend UI und bestehende Recognition bis zur kontrollierten Migration weiter funktionieren mÃ¼ssen. |
| 2026-07-20 | BestÃ¤tigungsbedÃ¼rftige Erkennungsentscheidungen werden nicht automatisch beim Importabschluss bestÃ¤tigt; der Client Ã¼bertrÃ¤gt explizite Overrides und das Backend validiert und appliziert sie auf seine unverÃ¤nderte Vorschau. | Clientanzeige und persistiertes kanonisches Modell mÃ¼ssen dieselbe nachvollziehbare Entscheidung verwenden; manipulierte oder veraltete Zuordnungen dÃ¼rfen die serverseitige Vertrauensgrenze nicht umgehen. |
| 2026-07-20 | GPO-Backups verwenden den gemeinsamen Ingestion-Unterbau, erzeugen aber `PolicyObservation` statt `FindingCandidate` und werden erst nach semantischer Reduktion, Aggregation und Evaluation mit dem Finding-Modell verbunden. | GPO-Artefakte enthalten Konfigurationsinstruktionen mit CSE-spezifischer Reihenfolge, Targeting-, Override- und Persistenzsemantik und sind keine Scannerfindings. |
| 2026-07-20 | Eine GPO wird nicht als Ganzes einem Zielsystem zugeordnet; jede Policy wird gegen alle vollstÃ¤ndig geprÃ¼ften technisch plausiblen Kontexte eines Environment Profiles bewertet. | GPO-Namen und manuelle Zielzuordnungen sind unzuverlÃ¤ssig; belastbare Aussagen entstehen aus technischer IdentitÃ¤t und Baseline-Consensus. |
| 2026-07-20 | Ein normales GPO-Finding bestÃ¤tigt eine konfigurierte Abweichung im untersuchten Snapshot, nicht die effektive Anwendung in der Umgebung. | Links, Reihenfolge, Vererbung, Enforced, Block Inheritance, Security-/WMI-Filter, Loopback und RSoP fehlen in einem Backupsatz ganz oder teilweise. |
| 2026-07-20 | GPO- und Baselineoriginale werden fÃ¼r reproduzierbares Reprocessing unverÃ¤ndert Ã¼ber eine backendkontrollierte Artefaktspeichergrenze aufbewahrt; mÃ¶gliche Geheimnisse werden nicht entschlÃ¼sselt und maskiert. | Neue Parser- und Regelversionen mÃ¼ssen dieselben Eingaben verwenden kÃ¶nnen, ohne sensible Inhalte Ã¼ber Webroot, UI, Logs oder Exporte offenzulegen. |
| 2026-08-04 | EnvironmentProfile wird als unveraenderliche Revisionskette gespeichert; eine Snapshotaggregation referenziert eine konkrete Profilrevision und eine explizite, eindeutige Menge versionierter Identity-Analysis-Runs. Die Aggregation persistiert nur beobachtete technische Zustaende und Reviewhinweise, setzt Wirksamkeit auf unknown und darf keine Findings erzeugen. | Profilwahl, Quellanalysen und Engineversion muessen fuer Reprocessing reproduzierbar bleiben. Ohne GPO-Link-/Praezedenz-, Targeting- und RSoP-Evidenz waere jede Effektivitaets- oder Findingaussage in dieser Stufe unbelegt. |
| 2026-08-04 | Comparator-, Risiko- und Dependency-Semantik wird ausschliesslich aus einem unveraenderlichen freigegebenen, setting- und kontextspezifischen Policy-Evaluation-Regelkatalog bezogen. Der vollstaendige Katalogsnapshot gehoert zum Evaluation Run und dessen Idempotenzschluessel. Fehlt genau eine passende Regel, bleibt das Ergebnis Katalogluecke und Review; es gibt keinen generischen Equality-Fallback. Prerequisite und Override koennen nur bei vollstaendigem abwesenheitsfaehigem Snapshot Nichtanwendbarkeit belegen, Mutual Exclusion erzeugt ohne dokumentierte Praezedenz Review. | Typisierte Comparatorfunktionen allein belegen keine fachliche Vergleichsordnung. Ein leerer freigegebener Produktionskatalog ist sicherer als heuristische Regeln und erlaubt schrittweise fachliche Freigaben, ohne alte Runs umzuschreiben oder unvollstaendige Evidenz in Findings umzuwandeln. |
| 2026-08-04 | PolicyEvaluation wird als eigene versionierte, idempotente Stufe nach der Snapshotaggregation gespeichert. Ein Run bindet genau einen Aggregationslauf, dessen Environment-Profile-Revision und pro Kontext genau eine Baselineanalyse; nur vollstaendige, eindeutige und konsistente Evidenz darf eine bestaetigte konfigurierte Abweichung als finding-berechtigt klassifizieren. Die Stufe erzeugt dennoch keine Findings, setzt Wirksamkeit immer auf unknown und haelt projectedFindingCount relational bei null. | Bewertung, Finding-Erzeugung und Wirksamkeit bleiben getrennte Vertrauensgrenzen. Damit koennen partielle Kataloge, Konflikte, nicht aufgeloeste Identitaeten oder unfreigegebene Vergleichssemantik weder durch Retry noch durch API- oder Repositoryfehler zu einem Finding werden. |
| 2026-07-20 | Historische GPO-Backupinstanzen, DomÃ¤nen und Erhebungszeitpunkte werden vor der Aggregation in Analysesnapshots getrennt. | Mehrere Sicherungen derselben GPO oder gemischte Erhebungen sind keine gleichzeitig wirksame Konfiguration. |
| 2026-07-20 | Baselinevergleiche verwenden nur freigegebene typisierte Comparatoren sowie versionierte Dependency-, Override- und Risikoregeln. | Nicht jede Abweichung besitzt eine Ordnung schwÃ¤cher/stÃ¤rker, und komplexe Einstellungen benÃ¶tigen ihre dokumentierte Anwendungssemantik. |
| 2026-07-18 | Die Entscheidung â€žOpen lÃ¤dt das neueste Assessmentâ€œ wird ersetzt: Open lÃ¤dt alle gespeicherten Assessments und Scan-LÃ¤ufe des Mandanten und fÃ¼hrt sie in Work mit einem Gesamtblatt sowie getrennten Quellansichten zusammen. | Ein Mandant ist die Klammer Ã¼ber seine vollstÃ¤ndige Importhistorie; eine BeschrÃ¤nkung auf den neuesten Lauf blendet Ã¤ltere Excel- oder andere Scanberichte fÃ¤lschlich aus. |
| 2026-07-18 | Open lÃ¤dt Ã¼ber die Backend-API das neueste Assessment-Modell des gewÃ¤hlten Mandanten und rekonstruiert daraus die Work-Datenansicht. | Ein aktiver Mandantenkontext ohne geladene persistierte Findings erfÃ¼llt die Bedeutung von Open nicht und lÃ¤sst Work fÃ¤lschlich leer. |
| 2026-07-18 | Ein gemeinsam hochgeladener Dateisatz wird im Datahub als ein Scan-Lauf dargestellt; ist darin genau ein nicht-generisches Werkzeug erkannt, wird es auf generische Begleitdateien dieses Laufs Ã¼bertragen. | Mehrdatei-Exporte eines Scanners sind ein fachlicher Bericht und dÃ¼rfen weder als einzelne Berichte noch Ã¼berwiegend als â€žTabellendatenâ€œ erscheinen. |
| 2026-07-18 | Eine erfolgreiche Mandanten-Speichermeldung benÃ¶tigt nach dem bestÃ¤tigten Projekt-Upsert einen zweiten Lesezugriff und den Feldabgleich mit dem gespeicherten Datenbankstand. | Die OberflÃ¤che darf Erfolg erst melden, wenn der persistierte Stand tatsÃ¤chlich wieder aus dem Repository gelesen wurde. |
| 2026-07-17 | Work benÃ¶tigt einen explizit im Datahub geÃ¶ffneten Mandanten; Stammdaten und Dateiimport bleiben in einer nicht-modalen Datahub-Bearbeitungsansicht. | Arbeitskontext und Datenpflege sind eindeutig getrennt, und Dateien erhalten immer eine sichtbare Mandantenzuordnung. |
| 2026-07-17 | Zielzustand ist eine interne Browseranwendung mit Backend. | Mehrere Mitarbeitende sollen ASSESSOR ohne lokale Installation verwenden kÃ¶nnen. |
| 2026-07-17 | PostgreSQL ist die Zieldatenbank. | Der Firmenbetrieb benÃ¶tigt zentrale, transaktionale und mehrbenutzerfÃ¤hige Speicherung. |
| 2026-07-17 | SQLite ist hÃ¶chstens eine ÃœbergangslÃ¶sung, nicht das Ziel. | Eine frÃ¼he SQLite-Kopplung wÃ¼rde spÃ¤tere Migration und Mehrbenutzerbetrieb erschweren. |
| 2026-07-17 | Die Parsing- und Normalisierungsengine bleibt deterministisch. | Kernimporte mÃ¼ssen nachvollziehbar, testbar und ohne externe KI funktionieren. |
| 2026-07-17 | Tauri bleibt vorerst erhalten, darf aber keine neue fachliche AbhÃ¤ngigkeit erzeugen. | Die aktuelle lokale Anwendung soll nutzbar bleiben und zugleich serverfÃ¤hig werden. |
| 2026-07-17 | Originalwerte und normalisierte Werte werden getrennt gespeichert. | Vergleiche benÃ¶tigen Normalisierung, Audits benÃ¶tigen unverÃ¤nderte Quelldaten. |
| 2026-07-17 | Bekannte Scanner werden Ã¼ber Profile integriert. | Die Kernpipeline soll nicht aus werkzeugspezifischen SonderfÃ¤llen bestehen. |
| 2026-07-17 | Finding-Definition und Finding-Vorkommen sind getrennte Fachobjekte. | Dieselbe Regel soll Ã¼ber mehrere Scan-LÃ¤ufe vergleichbar bleiben, ohne Definitionen zu duplizieren. |
| 2026-07-17 | Reviews werden getrennt von importierten Vorkommen gespeichert. | Benutzerarbeit darf Original- und Mappingdaten nicht verÃ¤ndern. |
| 2026-07-17 | Das kanonische Modell ist noch kein Datenbankschema. | Persistenzdetails werden erst nach Import-Zwischenmodell und Plattformtrennung festgelegt. |
| 2026-07-17 | Alle Formatparser liefern ein gemeinsames, versioniertes Import-Zwischenmodell. | Dateidekodierung, semantische Erkennung und bestehende UI-KompatibilitÃ¤t bleiben dadurch getrennte Schichten. |
| 2026-07-17 | Die Importengine erhÃ¤lt Bytequellen und injizierbare Laufzeitadapter. | Derselbe Engine-Einstieg kann heute im Browser und spÃ¤ter mit serverseitigen Datei-, Text- und Markupadaptern verwendet werden. |
| 2026-07-17 | Automatische Erkennung verwendet vier Konfidenzklassen und bewahrt unsichere Felder als Zusatzdaten. | Niedrige oder unbekannte Zuordnungen dÃ¼rfen keine Quelldaten verÃ¤ndern oder verwerfen und bleiben explizit korrigierbar. |
| 2026-07-17 | Werkzeugwissen wird in versionierten ToolProfileDefinition-Objekten gepflegt. | Erkennung, Mapping, Normalisierung, PrÃ¤sentation und VergleichsschlÃ¼ssel kÃ¶nnen erweitert werden, ohne Parser oder React-Komponenten zu Ã¤ndern. |
| 2026-07-17 | Facetten werden aus Rollen, Datentypen und realen Wertverteilungen abgeleitet. | Die OberflÃ¤che bleibt werkzeugunabhÃ¤ngig und erzeugt nur Filter, die im aktuellen Datenbestand sinnvoll nutzbar sind. |
| 2026-07-17 | Nur eindeutige SchlÃ¼ssel oder bestÃ¤tigte lokale Regeln erzeugen automatische Finding-IdentitÃ¤ten. | Ã„hnlichkeit ist ein Reviewvorschlag; mehrdeutige Kandidaten dÃ¼rfen Vergleiche und spÃ¤tere Persistenz nicht verfÃ¤lschen. |
| 2026-07-17 | AssessorRepository ist die fachliche Persistenzgrenze; ein Import entspricht einer atomaren Scan-Lauf-Transaktion. | Backend, PostgreSQL und lokale Referenzimplementierungen kÃ¶nnen ausgetauscht werden, ohne Import-, Vergleichs- oder React-Logik an Speichertechnologien zu koppeln. |
| 2026-07-17 | Das lokale Backend verwendet Node.js-Bordmittel und eine versionierte Same-Origin-API unter /api/v1. | Die Entwicklungsarchitektur bleibt abhÃ¤ngigkeitsarm, browserfÃ¤hig und kann spÃ¤ter hinter internem HTTPS betrieben werden. |
| 2026-07-17 | Serverseitige HTML-/XML-Verarbeitung verwendet jsdom als nicht skriptausfÃ¼hrenden Markupadapter. | Browser- und Serverbetrieb nutzen dieselbe plattformneutrale Importengine, ohne importierte aktive Inhalte auszufÃ¼hren. |
| 2026-07-17 | PostgreSQL speichert relationale IdentitÃ¤ten und Beziehungen sowie das vollstÃ¤ndige Fachobjekt zusÃ¤tzlich als JSONB. | IntegritÃ¤tsregeln bleiben datenbankseitig erzwingbar, wÃ¤hrend neue Scannerfelder ohne verlustreiche oder vorschnelle SchemaÃ¤nderung aufgenommen werden kÃ¶nnen. |
| 2026-07-17 | Datenbankmigrationen sind unverÃ¤nderliche, nummerierte SQL-Dateien mit SHA-256-PrÃ¼fsumme und Advisory-Lock. | Mehrere Backendstarts kÃ¶nnen sicher koordiniert werden; verÃ¤nderte bereits angewandte Migrationen werden erkannt und abgewiesen. |
| 2026-07-17 | Eine konfigurierte, aber nicht erreichbare PostgreSQL-Datenbank darf nicht still auf In-Memory zurÃ¼ckfallen. | Ein Konfigurationsfehler darf keine scheinbar erfolgreichen, aber flÃ¼chtigen Importe erzeugen. |
| 2026-07-17 | BestÃ¤tigte Batchimporte werden serverseitig aus der unverÃ¤nderten Vorschau in ein kanonisches Modell Ã¼berfÃ¼hrt und gemeinsam mit Fingerprints atomar gespeichert. | Vorschau, Benutzerfreigabe und dauerhafte Daten mÃ¼ssen nachweisbar zusammengehÃ¶ren; ein Fehler darf weder Teil-Findings noch isolierte DubletteneintrÃ¤ge hinterlassen. |
| 2026-07-17 | Nicht vertrauenswÃ¼rdige Importe werden durch eine zentrale Inhaltsrichtlinie und isolierte, begrenzte Serverworker verarbeitet. | Formate teilen dieselben Ã¼berprÃ¼fbaren Grenzen; zeit- oder speicherintensive Parser dÃ¼rfen den Backendprozess nicht unkontrolliert blockieren. |
| 2026-07-17 | Reine Finding-Auswahl lÃ¶st keine Vollfilterung aus; geschlossene verknÃ¼pfte Result-Bereiche rendern keine Tabellen. | Navigation bleibt auch bei umfangreichen Ergebnis-Sheets reaktionsfÃ¤hig, ohne Daten oder Funktionen zu entfernen. |
| 2026-07-17 | Lokale Review-Persistenz erfolgt nach dem sichtbaren UI-Update in einer begrenzten Idle-Phase. | Bookmark- und Review-Aktionen reagieren sofort; die lokale Speicherung bleibt automatisch und wird bei weiteren Ã„nderungen neu eingeplant. |

| 2026-08-23 | Profil-, Mapping-, Normalisierungs- und Darstellungsstand werden getrennt persistiert und über einen append-only kanonischen Kompatibilitätsschlüssel bewertet. Unbekannte oder semantisch inkompatible Stände desselben Werkzeugs blockieren Timeslot-Mischung und Lifecycle-Vergleich; historische Daten werden nicht umgeschrieben. | Eine gleiche sichtbare Profilnummer belegt keine gleiche fachliche Semantik. Explizite Verträge verhindern stille Umdeutung, falsche Neu-/Gelöst-Aussagen und nicht reproduzierbare Teilreimporte. |
| 2026-08-23 | Die Processing-Readiness einer Datahub-Mandantenkachel bezieht sich auf den neuesten scannergebundenen und ueber `Open` erreichbaren Timeslot: `Current` und `Compatible older` sind gruen, `Reimport recommended`, `Incompatible` und `Unknown` rot; ohne Scannerstand erscheint kein Punkt. | Die Uebersicht soll den unmittelbar nutzbaren Bewertungsstand anzeigen. Ein historischer Altstand darf einen aktuell korrekt verarbeiteten Mandanten nicht dauerhaft rot markieren; GPO-only-Gruppen besitzen keinen Scanner-Processingvertrag. |
| 2026-08-23 | Processing-Readiness unterscheidet in Datahub-Kachel und Mandantendetail drei semantische Stufen: `Current`/`Compatible older` gruen, `Reimport recommended` gelb und nur `Incompatible`/`Unknown` rot. Bei Update oder Fehler bleibt `Manage` auch ohne Kartenauswahl sichtbar; beim Oeffnen werden alle betroffenen Timeslots automatisch aufgeklappt. | Ein weiterhin nutzbarer Scan mit neuerem ASSESSOR-Profilstand ist ein Wartungshinweis und kein Fehler. Die unmittelbare Aktion und das automatische Offenlegen der Erklaerung vermeiden Sucharbeit, waehrend Rot fuer unsichere Verarbeitungsvertraege reserviert bleibt. |
| 2026-08-23 | Der Processing-Readiness-Punkt ist fuer beide Zustaende ein 14-px-Eckindikator mit 4 px Abstand zur oberen und linken Kartenkante. | Die gemeinsame Geometrie setzt Rot und Gruen gleichwertig in die 8-px-Rundung der Mandantenkachel, bleibt mit minimalem Abstand innerhalb der Kontur und veraendert weder Statuslogik noch Bedienung. |
| 2026-08-23 | Scanner-Reimport ersetzt einen aktiven ScanRun revisionssicher durch einen neuen Lauf im selben Assessment: Der neue Lauf referenziert den Vorgaenger, der Vorgaenger den Nachfolger. Alte Quelldaten, Findings und Vergleiche bleiben intern erhalten, waehrend aktive Datahub-, Work-, Result- und Environment-Projektionen supersedierte Laeufe ausblenden. | Ein Reimport darf weder einen manuellen Loeschschritt noch eine riskante Delete-then-Import-Luecke erzeugen. Die Supersession bleibt auditierbar und der alte Lauf bleibt bei jedem Fehler aktiv; normale Scanneroriginale werden weiterhin nicht aufbewahrt und muessen deshalb erneut ausgewaehlt werden. |
| 2026-08-23 | Ein exakter Dateitreffer wird im explizit zielgebundenen Reimport nicht als `Duplicate`, sondern als positiver Status `Expected replacement source` dargestellt und bleibt vorausgewaehlt. `Duplicate` bleibt ausschliesslich die Warnung des normalen Importwegs; die Reimportaktion heisst `Reimport and replace`. Das vorgelagerte Panel benennt ausdruecklich das neue interne ASSESSOR-Verarbeitungsprofil samt Versionspfeil und stellt klar, dass der Scannerbericht selbst unveraendert ist. | Dieselben Bytes sind beim normalen Import ein moeglicher Bedienfehler, beim Reimport aber der erwartete und sicherste Ersatznachweis. Kontextabhaengige Sprache verhindert, dass Nutzer eine korrekte Datei aus Angst vor einer Dublette abwaehlen oder die Profilaktualisierung faelschlich dem Scannerhersteller zuschreiben, ohne die technische Hashpruefung oder den sicheren Ersatzvertrag abzuschwaechen. |
| 2026-08-23 | Ein Reimport-Backend muss das exakte Ersatz-Ziel bereits in der Vorschau zurueckspiegeln und nach dem Commit erneut bestaetigen. Ein bereits durch einen alten Server als normaler Import angelegter neuer Lauf kann explizit als Ersatz eines aelteren aktiven Laufs desselben Werkzeugs im selben Timeslot uebernommen werden. | Ein laufender veralteter Backendprozess darf neue Frontendfelder nicht still ignorieren und dadurch Dubletten erzeugen. Die kontrollierte Reparatur verknuepft vorhandene Laeufe atomar, loescht keine Daten und bleibt durch Werkzeug-, Timeslot-, Aktivitaets- und Zeitfolgepruefung begrenzt. |
| 2026-08-23 | Der lokale Standardstarter besitzt den Backendprozess selbst und fuehrt fuer jede erfolgreich gebaute Serverrevision einen kontrollierten Prozesswechsel aus. Health meldet SHA-256-Release- und Entwicklungsinstanzkennung; ein zuvor verwalteter verwaister Prozess darf nur bei Uebereinstimmung mit der lokalen Laufzeitdatei uebernommen werden. | Frontend-HMR und ein dauerhaft alter Backendprozess duerfen im Entwicklungsbetrieb nicht erneut auseinanderlaufen. Ein fehlerhafter Rebuild laesst den letzten gesunden Server aktiv; ein fremder Prozess auf Port 4173 wird niemals pauschal beendet oder still als kompatibel akzeptiert. |
| 2026-08-24 | Die im Kopfbereich dauerhaft sichtbare ASSESSOR-Version bezeichnet den globalen ASSESSOR-Verarbeitungsvertrag und wird unter dem Markennamen ausschliesslich als Zahlenfolge dargestellt. | Die fachlich relevante Processing-Version darf nicht mit der technischen npm-Paketversion verwechselt werden; die Oberflaeche verwendet dieselbe zentrale Processing-Konstante wie der Verarbeitungsvertrag. |
| 2026-08-24 | Die Processing-Readiness einer Datahub-Mandantenkachel umfasst alle aktiven scannergebundenen Timeslots des Mandanten. Ein Reimportbedarf in irgendeinem Timeslot setzt die Kachel gelb und macht `Manage` dauerhaft sichtbar; Fehlervertraege setzen sie rot. `Open` bleibt unabhaengig davon auf den neuesten scannergebundenen Timeslot gerichtet. | Lifecycle-Vergleiche zwischen Timeslots sind nur verlaesslich, wenn alle beteiligten Staende den aktuellen ASSESSOR-Verarbeitungsvertrag verwenden. Ein aktueller neuester Timeslot darf einen aelteren, noch aktiven und spaeter vergleichbaren Altstand nicht als gruen ueberdecken. |
| 2026-08-24 | Ein zielgebundener Scanner-Reimport verlangt die exakte Gleichheit des vollstaendigen SHA-256-Multisets aller Importdateien des zu ersetzenden ScanRuns mit der erneut ausgewaehlten und final bestaetigten Dateimenge. Dateiname, Datum, Werkzeug oder Aehnlichkeit genuegen nicht; fehlende Originalhashes werden fail closed behandelt. | Nur Byte-Identitaet schliesst aus, dass ein anderer Bericht, ein anderer Erfassungszeitpunkt oder ein unvollstaendiger Mehrdatei-Report denselben Timeslot ersetzt. Die Pruefung in Vorschau, Abschluss und Repository schuetzt Vergleichbarkeit, Provenienz und den aktiven Bestand auch gegen veraltete oder manipulierte Clients. |

### Verbindlicher Verarbeitungsversionsvertrag (Nachhärtung Phasen 5, 6, 8, 9, 12 und 13A)

Status: umgesetzt und mit synthetischen Vertrags-, Import-, Vergleichs- und Read-Model-Tests verifiziert (2026-08-23).

Diese Regeln sind für jede künftige Profil-, Mapping-, Normalisierungs- oder Darstellungsänderung verbindlich:

1. Profil-, Mapping-, Normalisierungs- und Darstellungsstand werden getrennt versioniert und gemeinsam mit einem stabilen kanonischen Kompatibilitätsschlüssel persistiert. Ein Profil-Release darf die anderen Stände nicht implizit mit erhöhen.
2. Jeder freigegebene historische und aktuelle Profilstand erhält vor seiner Verwendung einen append-only Manifest-Eintrag mit Änderungsklasse (`presentation-only`, `compatible`, `semantic-breaking`), betroffenen Dimensionen und Reimportbedarf. Historische Provenienz wird niemals still umgeschrieben oder neu interpretiert.
3. Unbekannte Verträge und unterschiedliche kanonische Kompatibilitätsschlüssel desselben Werkzeugs werden fail closed behandelt. Sie dürfen weder in einem Timeslot vermischt noch für Lifecycle-Aussagen wie neu, persistent oder gelöst verwendet werden.
4. Der Batchabschluss sowie Local- und PostgreSQL-Repository prüfen den vollständigen Assessment-/Timeslot-Scope vor dem Commit. Bei Inkompatibilität ist ein neuer Timeslot oder ein vollständiger Reimport aller betroffenen Quellen erforderlich; Teilreimporte in einen fachlich gemischten Stand sind unzulässig.
5. Vergleiche prüfen den Vertrag beider persistierter Läufe vor dem Matching. Bei unbekanntem oder inkompatiblem Stand werden alle betroffenen Vorkommen ausschließlich als `not-comparable` mit sicherer Diagnose ausgegeben.
6. Die Result DB zeigt einen verständlichen Processing-Status (`Current`, `Compatible older`, `Reimport recommended`, `Incompatible`, `Unknown`). Die getrennten technischen Versionsstände bleiben in der aufgeklappten Provenienz sichtbar, werden aber nicht als zwei gleich wirkende Hauptfilter angeboten.
7. Reprocessing verwendet nur eine erneut per SHA-256 geprüfte Originalquelle. Ist ein normales Scanneroriginal nicht aufbewahrt, darf kein stiller Reimport aus normalisierten Daten erfolgen; die UI weist auf den erforderlichen erneuten Upload hin.
8. Jede Änderung am Processingvertrag benötigt mindestens: Manifestvertragstest, Profil-/Mapping-Trennungstest, kanonischen Persistenztest, Timeslot-Kompatibilitätstest, Fail-closed-Vergleichstest, Readiness-/Facettentest, `npm test` sowie vollständigen Client-/Serverbuild. Bei semantischen Änderungen kommen synthetische Vorher-/Nachher-Fixtures für alle betroffenen Dimensionen hinzu.

Abnahme 2026-08-23: 677 Standardtests bestanden, 8 optionale PostgreSQL-Integrationstests übersprungen; Local-only-Sicherheitsprüfung und vollständiger Client-/Server-Produktionsbuild erfolgreich. Der globale Designcheck bleibt ausschließlich wegen der bereits dokumentierten Schattenregeln in `src/styles/datahub-redesign.css` Zeilen 39 und 42 rot; die Processingänderung berührt diese Datei nicht. Eine reale PostgreSQL-Integration sowie ein Reimport realer Scanneroriginale wurden in diesem Schritt nicht ausgeführt.

## 10. Offene Entscheidungen

- Aufbewahrung oder bewusster Verzicht auf vollstÃ¤ndige Originaldateien normaler Scannerimporte; fÃ¼r GPO- und Baseline-Reprocessing ist die unverÃ¤nderte Aufbewahrung beschlossen
- VerschlÃ¼sselung der Datenbank beziehungsweise Anforderungen an DatentrÃ¤gerverschlÃ¼sselung
- VerschlÃ¼sselung, Speicherort, Zugriffsschutz und LÃ¶schfristen des GPO-/Baseline-Artefaktspeichers
- Freigabeverfahren fuer einen optionalen externen LGPO.exe-Adapter, falls spaetere nicht unterstuetzte Registry.pol-Varianten ihn erfordern
- Bezugs-, Lizenz- und Freigabeverfahren fÃ¼r versionierte Microsoft-Baselines und ADMX-/ADML-Metadatenkataloge
- optionaler Import von `Get-GPOReport`-, Group-Policy-Results-, `gpresult`- oder anderer RSoP-Evidenz in einer spÃ¤teren Ausbaustufe
- genaue SSO-Integration im Unternehmensnetz
- Rollen- und Mandantenmodell
- Aufbewahrungs- und LÃ¶schfristen
- betriebliche Anpassung der festgelegten Importgrenzen an die Firmeninfrastruktur
- Umgang mit manuell bestÃ¤tigten Mappings zwischen Projekten
- Deployment-, Monitoring- und Backup-Plattform

Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht oder eine frÃ¼here Phase sie zwingend benÃ¶tigt.

## 11. Risiken

| Risiko | GegenmaÃŸnahme |
|---|---|
| Die Compose-Konfiguration benennt den PostgreSQL-Dienst korrekt, waehrend das Backend den Host ignoriert und innerhalb des App-Containers gegen `127.0.0.1` verbindet; Build und Datenbank-Health bleiben dabei gruen, aber die App wird unhealthy. | `ASSESSOR_POSTGRES_HOST` in den Repository-Umgebungsvertrag und die Verbindungszeichenfolge aufnehmen, Loopback nur als lokalen Fallback verwenden und Docker-Hostname sowie lokalen Standard durch einen reinen Unit-Test absichern. |
| Lokale Kartenraster koennen Kacheln wieder auf Restbreite strecken; lange Titel, Werte, Labels, Zusatztexte, Medien oder Aktionen koennen abgeschnitten, ellipsiert oder verborgen werden, aus einer Kachel herausragen, Nachbarkacheln ueberdecken oder durch aggressive Umbruchregeln mitten im Wort getrennt werden. | Gemeinsame Segment-/Kacheltokens, feste Startausrichtung und eine zuletzt geladene Kachel-Vertragsschicht verwenden. Woerter nur an Wortgrenzen umbrechen und Zahlen zusammenhalten. Bei Platzmangel Inhalt intern neu anordnen oder die Kachel verbreitern beziehungsweise responsiv neu anordnen; Clipping, Clamp, Ellipse und Truncation sind keine zulaessigen Rueckfaelle. Statische Regressionen sichern Vertrag, relevante Ansichten und Kaskadenreihenfolge. |
| Trefferlistentitel und geoeffneter Finding-Titel koennen trotz unterschiedlicher Informationshierarchie optisch gleich laut oder in der falschen Reihenfolge erscheinen. | Trefferliste auf 16 px/500 und geoeffneten Detailtitel auf 20 px/600 ueber eigene zentrale Tokens binden; Finding-Abschnitt und Matrixkacheln getrennt regressionspruefen. |
| Finding-Badges und Outcome-Texte koennen bei derselben Groesse wie regulaere Labels eine lange Titelzeile optisch ueberladen und MITRE-Zuordnungen unnoetig umbrechen. | Fuer Finding-Zustandszeilen ausschliesslich den zentralen 12-px-Badgetoken verwenden; Farbe, Glyph, Rahmen und feste Dimensionsreihenfolge bleiben als zusaetzliche Bedeutungstraeger erhalten. |
| Lange Finding-Titel koennen bei Verwendung der globalen H2- oder allgemeinen Heading-Rolle Reader, Trefferlisten und Matrixkacheln visuell dominieren und Statusinformationen aus dem sichtbaren Bereich druecken. | Finding-spezifische Titelrollen regressionspruefen: Reader 18 px, Listen- und Matrixkacheln 16 px; Fliesstext bleibt mindestens 16 px. Globale Seitentitel und Pathfinder-Micro-Cards nicht ueber lokale Work-Regeln mitveraendern. |
| Unabhaengige Donutimplementierungen koennen erneut in offene 270-Grad-Gauges, abweichende Ringspuren, runde Bogenenden oder unterschiedlich platzierte Prozentwerte auseinanderlaufen; mehrteilige Verteilungen koennten den gemeinsamen Standard umgehen. | Vollkreis, Startposition, flache Enden, neutrale Spur, Strichstaerke und zentrale Wertebehandlung ueber gemeinsame Donuttokens und Regressionen fuer Datahub-Karten, Sidebar, Dashboardstatus und mehrteilige Risiko-Verteilung absichern. Neue Donuts muessen denselben Vertrag verwenden. |
| Lokale Systemschriften, konkurrierende Font-Stacks oder frei gesetzte Schriftgroessen koennen zwischen Betriebssystemen und Ansichten unterschiedliche Laufweiten, Zeilenumbrueche und Hierarchien erzeugen. | Inter als lokale WOFF2-Abhaengigkeit ohne CDN laden, den Font-Stack und alle semantischen Schriftrollen zentral tokenisieren und Import, Hierarchie, Mindestgroesse, erlaubte Grossschreibung sowie das Fehlen abweichender Display-Schriften regressionspruefen. |
| Mittelgrosse, strukturell komplexe Scanner-HTML-Berichte koennen vor der groessenbasierten DOM-Umschaltung die isolierte 30-Sekunden-Parsergrenze erreichen; ein pauschal hoeheres Timeout wuerde problematische Eingaben nur laenger binden. | Berichte oberhalb von 1 MiB frueh in den bestehenden begrenzten lexikalischen Extraktor routen, Workerzeit-, Speicher-, Tabellen- und Zeilengrenzen beibehalten und den 1,6-MiB-PingCastle-Pfad mit synthetischer Tabelle sowie `html-bounded-extraction`-Diagnose regressionspruefen. |
| Eine Anzeige der technischen Paketversion koennte faelschlich als aktueller fachlicher Verarbeitungsstand verstanden werden; eine lokal im React-Code hartcodierte Zahl koennte ausserdem vom Processingvertrag abweichen. | Die zentrale Konstante `CURRENT_ASSESSOR_PROCESSING_VERSION` aus dem Processingvertrag im Markenblock rendern, weder `v` noch `Version` voranstellen und Quelle, Wert, Position sowie kompakte Metadaten-Typografie regressionspruefen. |
| Ein Scanner-Reimport koennte den alten Lauf vor erfolgreicher Validierung loeschen, den falschen Timeslot beziehungsweise ein anderes Werkzeug ersetzen oder alte und neue Ergebnisse gleichzeitig in Work und Result DB anzeigen. | Vorschau und Abschluss kryptografisch an dasselbe Projekt-, Assessment- und ScanRun-Ziel binden, das erkannte Werkzeug gegen den aktiven Vorgaenger pruefen und Supersession samt neuem kanonischem Lauf in einer Repositorymutation committen. Den alten Lauf nicht loeschen; aktive Read-Modelle filtern `supersededByScanRunId`, waehrend der Projektexport beide Laeufe und ihre Beziehung erhaelt. |
| Ein Bericht desselben Werkzeugs mit gleichem Dateinamen oder Datum koennte faelschlich als Reimport akzeptiert werden; bei Mehrdatei-Reports koennte eine Teilmenge oder eine zusaetzliche Datei den falschen Bestand ersetzen. Ein Client koennte ausserdem eine reine Vorschaupruefung umgehen. | Anzahl und vollstaendiges SHA-256-Multiset der Originaldateien in Preview und Complete vergleichen und dieselbe Invariante in Local- und PostgreSQL-Repository sowie beim Uebernehmen bereits importierter Ersatzlaeufe erzwingen. Fehlende Originalhashes, Offline-Fallback und jede Abweichung fail closed ablehnen; der bestehende Scan bleibt aktiv. |
| Ein erwarteter Hash-Treffer kann im Reimport als gelbe Dublette erscheinen, automatisch abgewaehlt sein oder im Abschlussbericht erneut als Fehlerzaehler auftauchen. Eine generische Zeile `current profile` kann ausserdem den Eindruck erwecken, PingCastle selbst habe den Bericht oder sein Format geaendert. Nutzer koennten dadurch die richtige Ersatzdatei abwaehlen oder den sicheren Vorgang abbrechen. | Darstellung und Vorauswahl am expliziten `replacesScanRunId`-Kontext ausrichten: erwartete Ersatzquelle positiv benennen und auswaehlen, den Bestandsschutz bis zum erfolgreichen Abschluss erklaeren und den Abschlussbutton eindeutig `Reimport and replace` nennen. Im Panel `ASSESSOR processing profile`, Alt-/Neuversion und den unveraenderten Scannerbericht explizit nennen. Die normale Import-Dublettenwarnung unveraendert getrennt halten und beide Wege regressionspruefen. |
| Ein veralteter, bereits laufender Backendprozess kann einen neuen optionalen Reimportparameter ignorieren und den Upload als normalen zusaetzlichen Scan speichern. | Das Ersatz-Ziel muss vor jeder dauerhaften Mutation in der Servervorschau exakt zurueckgespiegelt werden; fehlt die Bestaetigung, bricht der Client vor dem Batchabschluss ab. Fuer bereits entstandene Doppelstaende darf nur eine explizite, atomare Uebernahme eines neueren aktiven Scans desselben Werkzeugs und Timeslots angeboten werden. |
| Frontend-HMR kann neue API-Aufrufe laden, waehrend ein alter lokaler Backendprozess weiterhin gesund auf Port 4173 antwortet; ein blosser Health-Status erkennt diesen Vertragsversatz nicht. | Lokale Serverbundles nach erfolgreichem Watch-Build ueber ihren SHA-256-Releasewert aktivieren, Backend und Starter ueber eine zufaellige Entwicklungsinstanz binden und vor Clientfreigabe beide Werte im Health-Endpunkt pruefen. Nur eindeutig verwaltete verwaiste Prozesse zurueckfordern; unbekannte Portbelegung fail closed melden. |
| Eine nur auf den neuesten Timeslot bezogene Processing-Ampel koennte einen aelteren aktiven Altstand verdecken und dadurch spaetere Lifecycle-Vergleiche auf unterschiedlich verarbeiteten Daten zulaessig erscheinen lassen. Farbe allein waere ausserdem fuer assistive Technik nicht eindeutig; ein empfohlenes Profilupdate in Fehlerrot wuerde einen weiterhin nutzbaren Scan faelschlich als defekt darstellen. | Alle aktiven scannergebundenen Timeslots der Mandantenkachel zusammenfassen; `Reimport recommended` gelb, nur `Incompatible`/`Unknown` fail closed rot und ausschliesslich vollstaendig aktuelle beziehungsweise kompatible Staende gruen anzeigen. Update-/Fehlerkarten erhalten eine dauerhafte Manage-Aktion, alle betroffenen Timeslots oeffnen sich im Detail automatisch, und ARIA-Label sowie Tooltip benennen den mandantenweiten Zustand. Supersedierte Laeufe bleiben ausserhalb der aktiven Gruppen. |
| Globale TileCard-, Typografie- oder Radiusregeln koennen Pathfinder-Knoteninformationen vergroessern und dadurch Knoten, Kanten oder Nachbarkarten verdecken; lokale Rohwerte und `!important` wuerden die Darstellung zwar kurzfristig halten, aber Build- und Designvertraege brechen. | `PathfinderMicroCard` als eigenen wrapperfreien Vertrag mit festen Finding-, Relation- und Category-Massen, gemeinsamem Skalierungsfaktor und Pathfinder-spezifischen Typografie-, Farb- und Radius-Tokens fuehren. Regressionen pruefen beide Varianten, exakte Werte, gemeinsame Skalierung, fehlende Rohfarben/`!important` und unveraenderte regulaere TileCard-Tests. |
| Ein neuer PingCastle-Abschnitt oder eine geaenderte Tabellenueberschrift kann bei ausschliesslich festen Feldmappings unbemerkt verloren gehen; umgekehrt kann eine leere Tabelle faelschlich als nicht geprueft interpretiert werden. | Jeden Abschnitt, jede direkte Tabelle und jede Zelle zunaechst quellengetreu persistieren, stabile Schluessel nur als zusaetzliche Projektion erzeugen und `observed`, `explicitly-absent`, `empty`, `access-denied`, `license-restricted`, `unsupported`, `parse-failed` und `unknown` getrennt speichern. Synthetische Layout- und Zustandsregressionen sowie versionsgebundene Extractorprovenienz beibehalten. |
| Environment-Daten koennten in der gemeinsamen Result DB als scheinbare Findings erscheinen oder durch Severity-, IOE-, Abweichungs- und Reviewfacetten fachlich falsch bewertet werden; eine zweite Ergebniskopie koennte zudem von der Environment-Persistenz abweichen. | Einen eigenen `environment-observation`-SourceKind mit separaten Property-, Subject- und Zustandsfacetten verwenden, Finding-spezifische Dimensionen in der UI als nicht anwendbar darstellen und die Zeilen ausschliesslich als abgeleitete Projektion aus den persistierten EnvironmentObservations erzeugen. Originalwert, Normalwert, Locator, Profil- und Mappingstand muessen in Listen- und Einzel-API regressionsgeprueft bleiben. |
| Eine neue Erfassungsfaehigkeit kann unter einer bereits verwendeten Profilversion ausgerollt werden; contextlose Altimporte und vollstaendige Neuimporte waeren dann im Processingvertrag ununterscheidbar und koennten beide gruen erscheinen. | Jede persistenzrelevante neue Erfassungsdimension erfordert vor dem Rollout einen neuen append-only Profilstand. Der aktuelle Manifeststand muss Altversionen gezielt auf `reimport-recommended` setzen; synthetische Tests pruefen Altstand, aktuellen Stand, Datahub-Erklaerung und die im kanonischen Import gespeicherte Profilversion gemeinsam. |
| Feste halbe Badgebreiten und eine starre 40-px-Badgeleiste koennen laengere Pathfinder-Labels wie `Maester/Intune` abschneiden, obwohl unterhalb noch freie Kachelflaeche vorhanden ist. | Pathfinder-Badges auf den kompakten 11-px-Standardtoken `--fs-micro`, inhaltsabhaengige Breite und flexiblen Zeilenumbruch in den verbleibenden vertikalen Raum umstellen; Kachelgroesse und 16-px-Findingtitel bleiben unveraendert. Browsergeometrie prueft fuer die konkreten Dummy-Maester/Intune-Findings Textbreite und Kachelgrenzen. |
| Karten koennen in einer gemeinsamen Knotenebene von spaeteren Punkten uebermalt werden; viewportabhaengiges Klemmen und Neuverteilen kann sie beim Sidebar-Wechsel vom zugehoerigen Punkt wegschieben. Unbegrenzt viele beziehungsweise breite Badges koennen trotz passender Aussenflaeche den Kachelinhalt ueberfuellen. | Karten als letzte SVG-Ebene rendern und ihre Seite, X-/Y-Position sowie Kollisionsausweichung ausschliesslich deterministisch im Graphkoordinatensystem aus Knotenlage und Pin-Reihenfolge ableiten. Keine Kamera-, Viewport- oder Panelbreite darf die Platzierung beeinflussen; ausserhalb des Ausschnitts liegende Karten bleiben durch Pan/Zoom erreichbar. Pro Finding hoechstens vier sichtbare Badges rendern, weitere Werte mit einem getesteten `+N` kennzeichnen und die sichtbaren Badges mit Inhaltsbreite in den verbleibenden Raum umbrechen. |
| Eine zu kleine logische Findingflaeche kann beim Hineinzoomen zwar insgesamt wachsen, intern aber Titel, Badges und Aktionen in ein unpassendes Seitenverhaeltnis zwingen; zoomabhaengige Layoutkorrekturen wuerden wiederum die Bildmetapher brechen. | Eine feste 240-mal-176-px-Findingvorlage mit fuenf Titelzeilen, flexiblem Badge-Restbereich und allen Aktionen verwenden, sie nur einmal konstant mit 0,4 in Graphkoordinaten abbilden und danach keinerlei kameraabhaengige Innenformatierung anwenden. Browsergeometrie muss null ausserhalb liegende Kindelemente und identische Zoomfaktoren fuer Kachel, Titel, Badges und Aktion bestaetigen. |
| Eine rein farbliche und stark reduzierte Verbindungsanzeige kann fuer Farbfehlsichtige oder assistive Technik uneindeutig sein; eine abweichende Platzierung in Work und den uebrigen Bereichen koennte den Clientkontext wieder trennen. | Beide farblich fest codierten Quadrate mit unterschiedlicher Aktivopazitaet zeigen, am Container zustandsbezogenes ARIA-Label und Tooltip fuehren und denselben JSX-Baustein in Work sowie allen anderen Bereichsheadern unmittelbar vor dem Clientnamen einsetzen. |
| Interne Kamera-Gegentransformationen koennen Text, Symbole und Badges anders als die Kachelflaeche skalieren; redundante CIS-Hierarchie-Badges koennen die feste 148-mal-72-px-Flaeche seitlich verlassen. | Keine inverse Transformation innerhalb der Kachel verwenden und die komplette Komposition im SVG-Koordinatensystem belassen. CIS-Kategorien in Work, Reader, Filter und Graphknoten erhalten, aber aus der redundanten Pathfinder-Kachel auslassen; per Browsergeometrie alle gerenderten Kindelemente innerhalb der Kachel sowie identische Zoomverhaeltnisse von Flaeche, Titel und Symbol pruefen. |
| Lokale oder responsive Paddingwerte koennen die Inhaltskante einzelner Hauptbereiche erneut von Work abweichen lassen; pauschales Padding auf Root und Split-Pane kann den Abstand doppeln. | Den 20-px-Wert ausschliesslich ueber `--panel-content-inset`/`--panel-inset` beziehen, genau einen Root-Container je Ansicht verantwortlich machen und Work, Datahub, Client-Detail sowie Pathfinder per statischem Vertrag absichern. |
| Eine nur nominell gleiche CSS-Schriftgroesse kann innerhalb der SVG-Kamera am Bildschirm stark vergroessert erscheinen; isoliert verkleinerte Schrift wuerde Symbole, Labels und Abstaende unverhaeltnismaessig lassen. | Einen gemeinsamen inversen Kamerafaktor an Finding- und Rollenkacheln geben, deren gesamte UI samt Layoutflaeche transformieren und die proportionale aeussere Kachelflaeche unveraendert lassen. |
| Ein global aus dem Workzustand gelesener Clientname kann im Data-Hub-Detail einen anderen gerade verwalteten Client falsch auszeichnen; lange Namen koennen ausserdem die Headerwerkzeuge verdraengen. | Den Detailnamen separat und mit Vorrang fuehren, den Callback stabil halten und den reinen Text flexibel begrenzen, rechts ausrichten und mit Ellipsis kuerzen. |
| Eine auf Rollenkachelgroesse reduzierte Finding-Kachel kann Inhalt und Aktionen ueberlaufen lassen oder unbeabsichtigt auch die regulaere Matrix verkleinern. | Die Verdichtung strikt unter `.obsidian-node-matrix-card` kapseln, feste 148-mal-72-px-Graphmasse verwenden, Titel und Badgeleiste begrenzen und per Produktionsbuild sowie Pathfinder-Vertragstest absichern. |
| Zu schmale Rollenkacheln koennen kurze Kategorien mitten im Wort umbrechen; eine pauschale Einzeilenregel wuerde hingegen lange fachliche Bezeichnungen abschneiden. | Rollenkachel moderat verbreitern, beliebige Worttrennung deaktivieren und die vorhandene zwei- beziehungsweise dreizeilige Begrenzung fuer regulaere Wortgrenzen beibehalten. |
| Ein Bereichswechsel kann durch Unmount oder pauschales Auto-Fit den verlassenen Pathfinder-Zustand verlieren; ein Path Snapshot koennte faelschlich dauerhafte Workspace- oder Reviewmarkierungen setzen. | Den Pathfinder verborgen montiert halten, Auto-Fit an Aktivitaet und Graphsignatur koppeln und Path-Snapshot-Findings ueber einen separaten, bei Kontextwechseln geloeschten ID-Scope in die bestehende Filterpipeline einspeisen. |
| Eine inverse Zoomkompensation kann ausgewaehlte Kacheln beim Herauszoomen unverhaeltnismaessig gross halten; eine zu kleine feste `foreignObject`-Hoehe kann gleichzeitig die letzte Badgezeile intern abschneiden. | Kacheln direkt im kameraskalierten Knotengruppenraum rendern, nur Punkttexte invers skalieren und die Finding-Grundhoehe anhand des vollstaendigen TileCard-Inhalts auf 176 px anheben. Synthetische Vertrage verhindern die inverse Kacheltransformation; Dummy-Messungen pruefen Fit-Overflow und minimale Rendergroesse. |
| Das pauschale Umfaerben aller Graphpunkte koennte Severity-Signale der Findings zerstoeren oder nur Ring und Punkt, nicht aber die bei Auswahl sichtbare Rollenkachel, auseinanderlaufen lassen. | Den neuen Farbtoken ausschliesslich an die fuenf ringmarkierten Nicht-Finding-Klassen und ihre Rollenkachel-Hexagone binden; Finding-Severityselektoren unveraendert lassen. Beide Themes, alle Rollenklassen und eine konkrete Severityfarbe werden per Vertrag beziehungsweise Dummy-Messung abgesichert. |
| Eine separat gepflegte Kopfzeilenliste koennte andere Werte, eine andere Reihenfolge oder ausgeblendete technische Facetten zeigen als das Pathfinder-Panel; viele lange Auswahlwerte koennten zudem Titel oder Verbindungsstatus verdraengen. | Die Spur rein aus `deriveDynamicFacets` und dem bestehenden AppProvider-Zustand ableiten, dieselbe Hidden-Liste wie das Panel verwenden, graphinternen Status auslassen und den flexiblen Spurbereich mit Ellipsis begrenzen. Leerer, einfacher, mehrfacher, Mehrfachwert- und Wertebereichszustand werden synthetisch getestet; Ausrichtung und Farben werden im Dummy gemessen. |
| Ein gemeinsamer oder missverstaendlich benannter Graphschalter koennte Punkttexte und aktivierte Kacheln zugleich ausblenden und dadurch Detailauswahl mit Netzlesbarkeit koppeln. | Zwei explizite lokale Zustaende mit sichtbarem On-/Off-Text verwenden, `Labels` nur an Karten und `Text` nur an Punktbeschriftungen binden sowie Default und alle vier Umschaltwirkungen synthetisch und im Dummy regressionspruefen. |
| Gleichzeitige Anzeige von Quellblatt und `Source: Scan` koennte widerspruechliche Grundmengen erzeugen oder Nutzern technische CIS-CAT-Detailtabellen als eigenstaendige Scannerquelle darstellen. | Im Pathfinder den Blattselector vollstaendig entfernen, `Source: Scan` aus der Hidden-Liste nehmen und die Facette unveraendert ueber `SearchFilterBar`/AppProvider anwenden; Sichtbarkeit und Filterwirkung im gemischten Dummy-Aggregat regressionspruefen. |
| Eine vollstaendige technische Umbenennung von `graph` in `pathfinder` koennte Bereichszustand, Selektoren und gespeicherte UI-Verweise ohne fachlichen Nutzen brechen. | Ausschliesslich die zwei sichtbaren Labels aendern und den stabilen internen Schluessel sowie alle technischen Komponentenbezeichnungen unveraendert lassen; beide sichtbaren Stellen regressionspruefen. |
| Das Wort `Criterion` oder ein generischer Highlight-Marker kann in anderen Werkzeugen eine andere Bedeutung besitzen; eine globale Farbregel wuerde Soll, Verstoss und reine Information vermischen. | Criterion-Muster und roten Ton ausschliesslich im CIS-CAT-Profil deklarieren, in der gemeinsamen Results-Komponente nur abstrakte Rollen rendern und den separaten blauen Informationshinweis regressionspruefen. Farbe zusaetzlich durch Fettschrift absichern. |
| Ein gespeicherter Graphpfad kann nach Filter-, Mapping- oder Datenstandswechsel Knoten-IDs enthalten, die im aktuellen Graph nicht mehr existieren; blindes Wiederherstellen koennte falsche oder leere Beziehungen vortaeuschen. | Path Snapshots an denselben Client-/Timeslot-Scope wie normale Snapshots binden, aktive und Nachbar-IDs beim Lesen streng validieren, den gespeicherten View-Zustand zuerst anwenden und anschliessend ausschliesslich noch vorhandene aktive Knoten restaurieren. Beziehungen immer neu aus dem aktuellen Graph ableiten. |
| Ein in Work gespeicherter View-Bookmark enthaelt auch View- und Statuswerte, die im deviation-festen Graphen keine eigene Bedeutung besitzen; eine Graph-Sonderkopie koennte diese Werte anders anwenden oder den Speicher-Scope verlieren. | Den bestehenden `ViewBookmarks`-Baustein unveraendert wiederverwenden. Gemeinsame Suche, Quelle, Facetten und `actionOnly` werden angewendet; die Graphprojektion behaelt ihren expliziten Deviation-Override und den vorhandenen client-/timeslotgebundenen `workScopeId`. |
| Gleiche numerische CIS-Pfade koennen in unterschiedlichen Benchmarkprodukten oder Versionen andere Abschnittsbedeutungen besitzen; erfundene Klartextnamen oder eine persistierte globale Kategorie wuerden dadurch eine falsche fachliche Gleichheit behaupten. | Die Hierarchie ausschliesslich fuer als CIS-CAT erkannte Findings aus der unveraenderten Rule ID beziehungsweise dem Benchmark Item ableiten, nur numerische `CIS`-Labels anzeigen, die vollstaendige Regelnummer nicht als Kategorie wiederholen und keine Import-, Normalisierungs- oder Persistenzwerte schreiben. Source-/Timeslotfilter bleiben die Grenze fuer konkrete Benchmarkstaende; synthetische Mischprofiltests sichern, dass Nicht-CIS-Findings keine CIS-Kategorien erhalten. |
| Eine in SVG nachgebaute Finding-Kachel koennte von der Matrixdarstellung abweichen; eine inverse Zoomtransformation wuerde zudem die ausdruecklich gewuenschte proportionale Groessenaenderung verhindern. Interaktive Kachelbuttons koennten mit Knotendrag und Pin-Toggle doppelt ausloesen. | Den bestehenden React-`TileCard` innerhalb eines `foreignObject` wiederverwenden, fuer Findings keine inverse Kameraskalierung anwenden und Pointer-Down an der Kachel vom Knotendrag trennen. Der Kachel-Open-Handler steuert den Pin, Bookmark und Results verwenden dieselben vorhandenen App-Aktionen. Synthetische Vertrage sowie eine Dummy-Messung von Titel, zwei Aktionen und exakt 1,2-facher Breiten-/Hoehenskalierung sichern das Verhalten. |
| Eine rote Nachbarschaftsmarkierung koennte indirekte Pfade faelschlich als direkt darstellen oder bei gleichzeitigem Hover und Pin zwei Teilnetze hervorheben; graue beziehungsweise frei erfundene Punktfarben koennten die Severity-Semantik verfaelschen. | Den aktiven Pfadknoten deterministisch als Hover vor Pin bestimmen und die rote Klasse ausschliesslich auf Kanten anwenden, deren Quelle oder Ziel exakt dessen ID ist. Bekannte Severitys verwenden die zentralen Produkttokens; nur `unknown` erhaelt einen eigenen klar getrennten Graph-Token. Synthetische CSS-/Rendervertraege und eine Dummy-Pruefung der Drei-Kanten-Nachbarschaft sichern das Verhalten. |
| Vollstaendige Kategorie-, ATT&CK- und D3FEND-Mehrfachbeziehungen koennen bei langen Findingtiteln zu dichten Kantenbuendeln, abgeschnittenen Knoten oder unlesbaren Beschriftungen fuehren; eine kleinere Schrift wuerde die verbindliche 16-px-Inhaltsgrenze verletzen. | Beziehungen deterministisch auf einen grossen Rollenring und nach Beziehungssignatur verteilte Findings projizieren, Labels bei 44 Zeichen nur praesentativ kuerzen, links beziehungsweise rechts vom Knoten ankern und ihre 16-px-Rechtecke kollisionsbewusst vertikal versetzen. Fit reserviert zusaetzlichen Rand; synthetische Projektionstests und die freigegebene Dummy-Browserpruefung sichern Knotenabdeckung, Linkanzahl, Sidebar-Zustand und Labelkollisionen. |
| Ein fehlender aktiver ScanRun-Scope koennte als projektweiter Aggregatwunsch interpretiert werden und dadurch Result DB oder Graph unbemerkt mit Findings aller Timeslots fuellen. Ein Import oder Delete am aktiven Client koennte denselben Scope versehentlich verlieren. | Client-Arbeitsansichten ohne ScanRun-Menge fail closed rendern, den Work-Selector automatisch auf einen konkreten Timeslot setzen und bei projektgebundenen Datenaktualisierungen die aktive ScanRun-Menge weiterreichen. Struktur-, API-, Domain- und Repositorytests sichern die Grenze durchgaengig. |
| Filterlisten koennten projektweite oder ungefilterte Werte mit 0 Treffern anzeigen; beim Ausblenden koennte umgekehrt ein gesetzter, inzwischen unmoeglicher Wert als unsichtbarer Restfilter bestehen bleiben. | Jede Facette gegen Suche, Timeslot, Blatt, Status und alle anderen Facetten neu zaehlen, den eigenen Filter fuer Alternativen ausnehmen und nur positive Werte ausgeben. Nicht mehr vorhandene Work-Auswahlen und Statusfilter automatisch entfernen; gemeinsame Domainlogik sichert dieselbe Nullwertregel fuer die Result-DB. |
| Ein Client-Open aus der Uebersicht koennte nur den Client setzen und dadurch alle Timeslots mischen, oder bei einem leeren neuesten Assessment einen nicht nutzbaren Stand oeffnen. | Den chronologisch ersten tatsaechlich scannergebundenen Timeslot aus den bestehenden Gruppen waehlen und dessen vollstaendige ScanRun-Menge an `onProjectSelected` weiterreichen. Ohne solchen Stand die sichtbare Aktion deaktivieren; Manage bleibt als separater Pflegeweg erhalten. |
| Lange Dateinamen, Hashes oder Dublettenquellen koennten den Importdialog verbreitern, horizontal scrollbar machen oder ausserhalb einer Dateikarte abschneiden; eine zu starke visuelle Reduktion koennte zugleich Auswahl und Warnung unklar machen. | Alle variablen Texte innerhalb einer `minmax(0, 1fr)`-Spalte umbrechen, horizontalen Listenoverflow unterbinden und nur vertikales Scrollen zulassen. Checkbox, lesbare Statusfarbe, `Duplicate found`-Ueberschrift und Footeraktionen als nicht rahmengebundene Orientierung erhalten. |
| Result-DB oder eine spaetere LLM-Anreicherung koennte trotz sichtbarer Timeslot-Auswahl projektweit abfragen und Findings verschiedener Staende vermischen. Policy-Evaluationsergebnisse besitzen derzeit zudem keine ScanRun-Zuordnung und duerfen nicht still einem Scanner-Timeslot zugerechnet werden. | Den aktiven Scope explizit als Client-ID plus eindeutige ScanRun-Menge durch UI, API und Repository fuehren und Resultzeilen wie Facetten identisch filtern. Ergebnisse ohne passende ScanRun-ID bei aktivem Timeslot konservativ ausschliessen; eine spaetere Policy-/LLM-Anbindung muss zuerst denselben Assessment-/Timeslot-Kontext fachlich modellieren. |
| Snapshot- oder Workspace-Zustand eines Timeslots koennte in einem anderen Stand desselben Clients erscheinen; ein werkzeugspezifischer Statusfilter koennte beim Wechsel als unsichtbarer oder fachlich ungueltiger Restfilter aktiv bleiben. Ein gemischter Stand koennte umgekehrt nur generische Filter zeigen und werkzeugspezifische Werte verlieren. | Einen deterministischen Work-Scope aus Client und sortierter eindeutiger ScanRun-Menge verwenden, Reviews vor Scopewechsel sichern und den neuen Scope getrennt laden. Bei jedem Timeslot- und Blattwechsel Status-, Such- und Facettenzustand neu initialisieren; im Aggregat deklarierte Statusfilter der enthaltenen Profile dedupliziert vereinigen, waehrend Einzelblaetter ihr exaktes Profil behalten. Fokussierte Tests sichern Scopeunterschiede, Profildefault-Wechsel und Maester-/Purple-Knight-Mischung. |
| Mehrere gleichzeitig rote Quadrate oder eine rein dekorative Animation ohne zugänglichen Status koennten den Fortschritt unklar machen; dauernde Bewegung kann zudem die reduzierte Systemeinstellung missachten. | Vier feste Positionen mit phasenversetzten diskreten Animationszustaenden verwenden, den vorhandenen `role="status"`-Text erhalten und die Animation unter `prefers-reduced-motion` abschalten. Ein Strukturvertrag sichert Quadratanzahl, Rotzustand, fehlenden Kreis-Spinner und Reduced-Motion-Fallback. |
| Eine Work-Timeslot-Auswahl koennte einen Stichtag nur optisch markieren, waehrend weiterhin alle ScanRuns geladen bleiben, oder nach Mandantenwechsel veraltete Run-IDs anzeigen. | Optionen ausschliesslich aus der projektgebundenen Assessment-Historie ableiten, die Run-Menge mengenidentisch gegen den aktiven Scope vergleichen und jede Auswahl ueber den bestehenden projektpruefenden `openProject(projectId, scanRunIds)`-Pfad laden. Bei Projektwechsel, Backendausfall und Datahub-Aenderung die Optionsliste neu ableiten. |
| Eine kompakte maximierte Tabelle koennte lange Zellwerte umbrechen oder bei Ueberbreite unsichtbar abschneiden; eine spaetere Inhaltsregel koennte zudem manuell gesetzte Breiten ueberschreiben. | Die kompakte Regel nur vor `has-custom-column-widths` anwenden, Kopf- und Datenzellen dort auf `nowrap` setzen und den bestehenden horizontalen Scrollcontainer erhalten. Strukturtests sichern Inhaltsbreite, Umbruchfreiheit, Nutzerbreiten-Vorrang und Overflowpfad gemeinsam. |
| Eine nur an `maximized` oder nur an `detached` gebundene Freigabe koennte normale frei stehende Graph-Results aussperren oder umgekehrt das eingereihte aktive Cluster-Result veraenderbar machen. | Die Freigabe aus der tatsaechlichen Stapelgeometrie `minimized || isStackedCluster` ableiten: Nur diese beiden Zustaende sperren die Tabellenresizer. Komponentenregressionen pruefen Cluster, Detached, frei stehendes Standardfenster, Maximierung und minimierten Slot getrennt. |
| Beim Verschieben von `Open`, `Edit` und `Delete client` koennten Aktionen doppelt, in der falschen Spalte oder gleichzeitig als Edit und Save erscheinen; ein neben Save verbleibendes Delete erhoeht zudem das Fehlklickrisiko. | Die Aktionen an ihren fachlichen Container binden, Edit/Delete und Save als gegenseitig ausschliessende Zustaende rendern, alle drei Client-Aktionen gleich breit halten und Bleistift sowie alten Delete-Footer strukturell entfernen. Ein fokussierter Vertrag prueft Sichtbarkeit, Position, Breite und ausgeschlossene Altselektoren. |
| Das Entfernen des rechten Namensfelds koennte die Namensbearbeitung oder HTML-Formvalidierung unbemerkt verlieren, weil das sichtbare Feld ausserhalb des rechten Formularcontainers liegt. | Das linke Namensfeld im Edit-/Create-Modus explizit ueber `form="tenant-editor-form"` und `required` an denselben Submit binden; Save bleibt von `form.name.trim()` abhaengig. Fokustest und Browserpruefung sichern Lesetitel, Editfeld und Save gemeinsam. |
| Der Shelltitel koennte nach `Back` oder beim Wechsel in einen anderen Bereich irrtuemlich auf `Client` stehen bleiben. | Den Titel ausschliesslich aus dem gemeldeten Detail-Formzustand ableiten, beim Unmount explizit `false` melden und den kompletten Hin-/Rueckwechsel per fokussiertem Test und inhaltsfreier Browserpruefung absichern. |
| Ein Status koennte faelschlich bereits den erfolgreichen Upload oder eine Dateiformaterkennung als in Work darstellbar bezeichnen; umgekehrt koennte ein Statusabruf temporär fehlschlagen und wie ein fachlicher Importfehler aussehen. | Readiness ausschliesslich aus persistiertem ScanRun plus kanonischen Occurrences ableiten, spezifische und generische Werkzeugerkennung getrennt benennen und Abruffehler als `Unavailable` statt `Not viewable` darstellen. Nur tatsaechlich darstellbare Zustaende fuer `Open` freigeben und die Grenzfaelle synthetisch testen. |
| Aeltere allgemeine Formularregeln koennen die spaetere Readerdarstellung unbemerkt wieder zweispaltig machen oder Label ueber `justify-self` und Akzentfarbe verschieben. | Im Detailkontext Raster, Labelausrichtung und Farbe mit hoeherer kontextbezogener Spezifitaet explizit festlegen; der Lesemodus rendert Textwerte statt Inputs. Strukturtest und inhaltsfreie Browsergeometrie pruefen drei untereinanderliegende Abschnitte und neutrale berechnete Farben. |
| Auto-Fit auf sehr lange ungebrochene Zellwerte kann Result-Tabellen unkontrolliert verbreitern; direkte DOM-Manipulation koennte zudem React-Zustand und Tabellen aus unterschiedlichen Ergebnisquellen auseinanderlaufen lassen. | Breiten in einem gemeinsamen deklarativen React-Baustein fuehren, den ungebrochenen Inhalt nur kurzzeitig und ohne Logging messen, auf 72 bis 720 px begrenzen und den vorhandenen horizontalen Scrollcontainer erhalten. Synthetische Interaktionstests pruefen Doppelklick, Pointer-Ziehen, Tastatur und die Beschraenkung auf maximierte Results. |
| Unterschiedlich viele dynamische Filter koennen die davon fachlich unabhaengige erste Work-Kopfzeile indirekt in einen ungetesteten Schrumpfzustand bringen; verstecktes `overflow` schneidet dann Buttontext oder die letzte Tabkante ab. | Direkte Aktionsgruppen mit `flex: 0 0 auto` und einzeiligen Beschriftungen schuetzen, fuer echte Unterbreite einen horizontal erreichbaren Rueckfall an der Werkzeugzeile anbieten und mit einem CSS-/Strukturvertrag zugleich sichern, dass `SearchFilterBar` und seine profilabhaengige Facettenableitung unveraendert bleiben. |
| Eine generische Regel fuer direkte `label > span`-Kinder kann Stammdatenwerte wieder an den rechten Rand schieben, verkleinern oder typografisch wie Metadaten behandeln. | Den Wertselektor im Mandantendetail kontextbezogen spezifischer setzen und `justify-self: start`, linke Textausrichtung sowie mindestens 16 px festschreiben. Die inhaltsfreie Browserpruefung vergleicht fuer alle drei Zeilen linke Kante, vertikale Reihenfolge und berechnete 14/16-px-Hierarchie. |
| Eine feste Desktop-Navigatorbreite oder ein unbegrenzt breites Informationspanel koennte auf kleinen Viewports Inhalt verdraengen beziehungsweise auf grossen Viewports Werte optisch auseinanderreissen. | Dieselbe responsive `clamp`-Breite wie Work/Reports verwenden, unter 1050 px auf die vorhandene Stapelansicht wechseln und das Informationssheet auf 794 px begrenzen. Inhaltsfreie Browsermessungen pruefen Navigator-, Sheet- und Leeraumbreite sowie die unabhaengige Scrollgrenze. |
| Eine lokale ScanRun-Abwahl koennte beim Wechsel des Timeslots unbemerkt weiterwirken, neue Importe ausschliessen oder bei Mehrfachauswahl die bestehende Vergleichsschnittmenge umgehen. | Ausschliesslich ausgeschlossene Run-IDs lokal speichern, den Zustand beim Mandanten-/Timeslot-Neueinstieg und nach Loeschungen bereinigen und neue Runs dadurch standardmaessig einschliessen. Fuer `Open` zuerst je Timeslot die lokale Auswahl projizieren und erst danach unveraendert die sichere gemeinsame Werkzeugmenge berechnen; ohne verwertbaren Run bleibt `Open` gesperrt. |
| Work und Graph koennten bei getrennten lokalen Filterzustaenden unterschiedliche Findingmengen zeigen oder werkzeugspezifische Facetten unvollstaendig abbilden. | Beide Ansichten ausschliesslich aus dem gemeinsamen AppProvider-Zustand und `useFilteredRecords()` speisen; im Graph dieselben Search-/Sheet-/Facet-Controls wiederverwenden und lokale Graphfilter durch Strukturtests ausschliessen. Nur rein praesentative Graphzustaende lokal halten. |
| Ein dichter Netzwerkgraph kann bei vielen Findings durch zu viele Labels, Kanten oder unkontrollierte Layoutberechnungen unlesbar beziehungsweise traege werden; die gepunktete Graphflaeche kann im Lightmode zu dominant wirken. | Deterministisches lineares Clustering statt quadratischer Laufzeit verwenden, Clusterabstaende und Karten kompakt begrenzen, Labels standardmaessig auf Auswahl/Hover reduzieren, Fit/Zoom bereitstellen und Graphdaten rein aus der bestehenden gefilterten Projektion ableiten. Punktfarbe und Knotenrollen ausschliesslich ueber semantische Dark-/Light-Tokens steuern und das Muster strikt auf die Graphansicht begrenzen. |
| Ein in der Timeslot-Zeile platzierter Delete-Button koennte versehentlich den gesamten Mandanten oder nur sichtbare Scanzeilen loeschen und GPO-/Evidenzreste hinterlassen. | Mandanten- und Timeslot-Loeschung strikt trennen. Timeslot-Delete verlangt Projekt- und Assessment-ID plus Cascade-Bestaetigung an der Repository-Grenze und entfernt den Assessment-Teilbaum; der Dialog nennt den betroffenen Stichtag und bestaetigt ausdruecklich, dass Mandant und andere Timeslots erhalten bleiben. |
| Mehrere Timeslots besitzen unterschiedliche Scanner- oder GPO-Abdeckung; ein ungefiltertes Oeffnen wuerde fehlende Quellen als fachliche Veraenderung interpretieren und Aepfel mit Birnen vergleichen. | Vor der Mehrfachprojektion pro Timeslot die sicher erkannte Quellenmenge bilden und nur deren Schnittmenge weiterreichen. Generische, unbekannte oder gemischte Werkzeugidentitaeten nicht automatisch gleichsetzen; GPO separat als Assessment-Quelle behandeln und fehlende beziehungsweise ausgeschlossene Quellen sichtbar nennen. |
| Ein Delete-Button koennte eine bereits fuer Policy-Evaluationen verwendete Microsoft-Baseline oder nur deren sichtbare Tabellenzeile entfernen und dadurch Evidenz beziehungsweise Artefakte inkonsistent hinterlassen. | Expliziten Bestaetigungsdialog und bestaetigungspflichtigen DELETE-Vertrag verwenden; Referenzen in Local- und PostgreSQL-Persistenz vor der Mutation blockieren, abhaengige Klassifikationen und Analysen atomar mit dem Katalogeintrag entfernen und das danach unreferenzierte private Speicherobjekt best-effort bereinigen. |
| Importaktionen werden bei einem leeren Mandanten ausgeblendet, weil noch keine Assessment-ID existiert; der Nutzer kann dadurch den ersten Timeslot oder das erste GPO-Backup nicht anlegen. | Die Aktionen an die vorhandene Mandanten-ID binden und die Assessment-ID nur optional weiterreichen. Beide Zustaende synthetisch absichern und die Aktionsverfuegbarkeit in allen vorhandenen Mandantenansichten inhaltsarm pruefen. |
| Frei editierbare bestehende Mandantenstammdaten koennen durch einen unbeabsichtigten Tastendruck geleert oder ueberschrieben werden. | Vorhandene Felder standardmaessig als Lesewerte rendern, Bearbeitung und Speicheraktion nur ueber den eindeutig beschrifteten `Edit`-Textbutton freigeben, programmatische Submits ohne aktiven Bearbeitungsmodus ablehnen und den Modus nach Speichern oder Verlassen zuruecksetzen; Neuanlagen bleiben bewusst sofort editierbar. |
| Ein importierter PingCastle-HTML-Bericht kann zyklische, fehlende, doppelte oder extrem tiefe Fragmentziele enthalten; ungefiltertes Folgen koennte falsche Tabellen zuordnen oder Ressourcen erschoepfen. Ein XML-Import koennte umgekehrt den Eindruck vollstaendiger Results erwecken, obwohl seine RiskRules keine expliziten HTML-Evidence-Beziehungen tragen. | Nur strikt lokale Fragment-IDs aus erlaubten Attributen vor der Sanitisierung als inerte Marker bewahren, niemals HTML/JavaScript ausfuehren oder externe Ziele laden, Zielcontainer strukturell und dateilokal aufloesen, Kindcontainer im Elterninhalt maskieren, Zyklen per `visited` verhindern und Tiefe, Ziel- sowie Tabellenzahl begrenzen. Fehlende, mehrdeutige und limitierte Aufloesungen diagnostizieren. XML separat halten, keine HTML-Anreicherung vornehmen und die fehlende Results-Faehigkeit beim Import sichtbar melden. |
| PingCastle-Details koennen strukturierte Belegtabellen in abgeflachter Textform wiederholen und dadurch sehr lang werden; eine erneute pauschale Ausblendung wuerde sie dagegen wieder als schwer lesbare Zusatzinformation behandeln. | Den unveraenderten Detailwert in der normalen Reader-Lesetypografie direkt nach der technischen Erklaerung anzeigen, strukturierte Tabellen weiterhin nur im Results-Fenster rendern und die eindeutige Zuordnung mit synthetischen Auswahl-, Render- und Browserregressionen sichern. |
| Automatische Navigation koennte den bewusst gesetzten Result-Status zuruecksetzen oder Arbeitsdiagramme und Filter koennten verschiedene Grundmengen zaehlen; eine Uebertragung auf den Datahub wuerde dessen Gesamtstatistik verfaelschen. | Result-Status bei Projekt-, Blatt- und Viewwechseln bewahren, Severitys aus derselben dynamischen Facettennachzaehlung ableiten und die Datahub-Metriken weiterhin ausschliesslich aus den vollstaendigen Timeslot-Zahlen speisen. Synthetische Filter-, Komponenten-, Profil- und Datahub-Grenztests sichern die Trennung. |
| Mehrere aktive Severity-Diagramme koennten sich gegenseitig ersetzen, als UND statt ODER ausgewertet werden oder in wechselnder Klickreihenfolge unlesbar im Filterfeld erscheinen. | Die bestehende Kategorie-Facette mit einer kanonisch sortierten Werteliste verwenden, Klicks als Toggle behandeln, bei leerer Liste den Filter entfernen und die Mehrfachauswahl mit festen Kurzbezeichnungen darstellen. Synthetische Toggle-, Render- und Facettenregressionen sichern das Verhalten. |
| Kuenftige Ansichten koennten neue Donuts lokal zeichnen oder Dark- und Lightmode unterschiedlich strukturieren und dadurch die bindende Referenz schleichend aufweichen. | Ausschliesslich DonutMetricCard und .donut-metric-rack verwenden; Struktur, Tokens, beide Themes, Breakpoints und Ausnahmegrenzen im Komponentenvertrag sowie in statischen und gerenderten Regressionstests sichern. |
| Die fuenf Teilkategorien der Statusdiagramme koennen fachlich ueberlappen oder weitere kanonische Zustaende nicht abbilden; ihre Prozentwerte koennten daher faelschlich als geschlossene Verteilung gelesen werden. | Results All bleibt die explizite 100-Prozent-Referenz. Jeder weitere Bogen wird einzeln gegen All berechnet und beschriftet; Tests sichern Kategoriezuordnung, Prozentberechnung und die fehlende Summenannahme. |
| Bei zwei ausgewaehlten Vergleichsstaenden koennte unklar sein, welcher Stand die vier Statuszahlen speist; bei einem einzigen Stand duerfen die Werte nicht leer bleiben. | Die Regler folgen deterministisch dem zuletzt angewählten Timeslot. Beim Laden wird der neueste vorhandene Stand vorselektiert; Tests sichern Ein- und Mehr-Run-Aggregation sowie die getrennten kanonischen Kategorien. |
| Das starre achtspaltige Referenzraster ist breiter als kleine Viewports; rein visuelle Regler koennten als Bedienfunktionen verstanden werden. | Nur `.datahub-history-scroll` darf horizontal scrollen, waehrend alle aeusseren Racks auf `min(1180px, 100%)` begrenzt bleiben. Regler bleiben `aria-hidden`, ohne Ereignisse oder Fachwerte; statische und inhaltsfreie Browserregressionen sichern Breite, Zaehler und fehlenden Seiten-Overflow. |
| Ohne sichtbare Timeslot-Auswahl koennte ein Import bei mehreren Bewertungsstaenden dem falschen Zielstand zugeordnet werden; rein dekorative Regler koennten als Fachfunktionen missverstanden werden. | Den bestehenden neuesten projektgebundenen Assessment-Timeslot als Importziel verwenden und die serverseitige Projekt-/Assessment-Pruefung beibehalten. Regler ohne Ereignisse, Formularwerte oder ARIA-Control-Rollen rendern. Eine spaetere Aenderung des Importziels darf nur mit einer ausdruecklich freigegebenen Funktion erfolgen, weil die aktuelle Mandantendetail-Referenz keine Timeslot-Auswahl vorsieht. |
| Visuelle `Empty`-Mandantenslots koennten irrtuemlich als persistierte Mandanten behandelt werden; eine starre Achtspaltenmatrix koennte auf kleinen Viewports Inhalte abschneiden oder Vergleichsauswahl und Oeffnen vermischen. | Platzhalter ausschliesslich lokal rendern und ohne IDs, Ereignisse oder API-Aufrufe halten. Die Matrix in einem horizontal scrollbar begrenzten Container fuehren, aktive echte Projekte separat markieren und die Dreiecksflaeche nur zur Auswahl sowie den Datumsklick nur zum Oeffnen verdrahten. Responsive Reglerumbrueche und statische Layoutvertraege beibehalten. |
| Eine auf Inhaltsbreite zentrierte Mandantenmatrix kann bei vielen Mandanten oder schmalen Viewports aus der Arbeitsflaeche laufen; flexible Donutspalten koennten erneut unkontrolliert Leerraum aufnehmen. | Historie und Statusblock mit `max-width: 100%` begrenzen, die Historie innerhalb des Rackmoduls horizontal scrollbar halten, Mandanten- und Donutspalten explizit dimensionieren und die bestehenden Breakpoints fuer zwei beziehungsweise eine Donutspalte beibehalten. Ein statischer Layoutvertrag verbietet die fruehere Vollbreiten-Ueberschreibung. |
| Legacy-Scannerimporte besitzen noch keinen expliziten Timeslot-Stichtag; eine rein technische Gruppierung koennte einen fachlichen Stand vervielfachen oder zwei tatsaechlich getrennte gleichdatierte Durchgaenge verbinden. Ein nicht zugeordneter historischer GPO-Snapshot koennte bei mehreren Staenden falsch erscheinen. | Nur Legacy-Daten ohne Assessment.effectiveAt nach dem Quellkalendertag kompatibel zusammenfuehren. Neue Staende immer explizit anlegen und jede Scanner-/GPO-Submission mit projektgepruefter 	argetAssessmentId binden. Einen ungebundenen Legacy-GPO-Snapshot nur bei genau einem vorhandenen Timeslot zuordnen; bei mehreren Staenden keine Zuordnung raten. Synthetische Regressionen pruefen den 22.07-Sammelstand, spaetere Uploadzeitpunkte und getrennte explizite Stichtage. |
| Scanstaende aus getrennten Assessments werden trotz fehlender gemeinsamer Vergleichsidentitaet automatisch verbunden oder ein Mandantenwechsel vermischt die Auswahl. | Nur Modelle mit exakt derselben Projekt-ID read-only zusammenfuehren, Quellen unveraendert lassen, die ausgewaehlten Runs chronologisch ordnen und beim Mandantenwechsel die Auswahl ersetzen. Sichere kanonische Identitaeten bleiben automatisch; textaehnliche Restkandidaten bleiben als `possibly-identical` bestaetigungspflichtig. Synthetische Regressionen pruefen Mandantentrennung, Nichtmutation, behoben/neu/persistent und die gezielte Work-Projektion eines einzelnen ScanRuns. |
| Zwischen dem Laden einer angebotenen Policy-Aktion und ihrer Ausfuehrung aendert sich Profil-, Processing- oder Baselinezustand. | GPO-Reprocessing uebergibt den erwarteten letzten Processing Run und scheitert bei Stale State; Aggregation, Evaluation und Finding Factory bleiben deterministisch idempotent und pruefen Projekt-, Profil-, Analyse- und Evidenzreferenzen serverseitig erneut. Versionierte explizite Altquellen koennen hoechstens einen nachvollziehbaren Review-Lauf erzeugen, niemals durch die Bereitschaftsanzeige allein ein Finding. |
| Historische oder neu verarbeitete Policy-Laeufe werden in einer Gesamtzahl als aktueller, deduplizierter Kundenzustand missverstanden und dadurch doppelt gezaehlt. | Das Readmodell bewahrt jeden Lauf separat, die UI bezeichnet Summen als persistierte Laufhistorie und zeigt den Environment-Profile-Kontext je Evaluation. Eine spaetere aktuelle Kundensicht darf erst mit expliziter Profilwahl, aktiver Revisions-/Supersession-Auswahl und snapshotbezogener Deduplizierung entstehen. |
| Eine konservative Snapshotaggregation wird als effektive Kundensicht oder bereits als Baselinebewertung missverstanden; unbekannte GPO-Reihenfolge, Targeting oder Vorzustaende koennten dadurch scheinbar eindeutige Werte erzeugen. | Aggregationslaeufe getrennt von Evaluation Runs halten, effectiveState = unknown und permitsFindingGeneration = false vertraglich sowie relational erzwingen, widerspruechliche GPO-Werte als Konflikt und nicht aufloesbare Semantik als indeterminate mit festen Reviewhinweisen persistieren. |
| Ein technisch vorhandener Comparator wird als automatisch freigegeben missverstanden oder ein nachtraeglich veraenderter Regelkatalog macht historische Runs nicht reproduzierbar. | Ohne exakt passende freigegebene setting- und kontextspezifische Regel immer Katalogluecke/Review liefern; den vollstaendigen Katalogsnapshot am Run und in dessen Idempotenzschluessel speichern, Katalog-ID/-Version sowie Regel-/Dependency-/Risiko-IDs relational ablegen und den aktiven Katalog read-only ueber die Referenzdaten-API ausweisen. Der produktive Katalog bleibt bis fachlicher Kuratierung leer. |
| Ein manipuliertes oder historisch unvollstaendiges Evaluationsergebnis traegt irrtuemlich `eligible` und wird trotz fehlender Mehrquellen-Evidenz als Finding projiziert. | Die Finding Factory validiert die Evaluation nicht nur formal, sondern gleicht fuer jeden Kandidaten alle erwarteten Observation-, Backup-, Baseline-Setting-, Baseline-Analysis- und Kontextquellen exakt gegen persistierte Evidenz ab. Abweichungen werden als versionierte Ablehnung gespeichert; relationale Checks halten Scope unbekannt, Wirksamkeit nicht verifiziert und Klassifikation auf bestaetigte konfigurierte Abweichung begrenzt. |
| Ein generischer Comparator oder eine implizite Ordnung wird ohne setting-spezifische Katalogfreigabe verwendet und klassifiziert eine fachlich unvergleichbare Abweichung als bestaetigt. | Comparatoren als geschlossene versionierte Bibliothek fuehren, ihre produktive Bindung nur durch explizite Katalogregeln zulassen und bis dahin Equality verwenden; fehlende, mehrdeutige oder unvergleichbare Zuordnungen immer review-required und finding-ineligible speichern. Finding-Erzeugung und Unified-Result-Projektion bleiben eine nachgelagerte eigene Stufe. |
| PostgreSQL-Paritaet der neuen Policy- und Baseline-Analysetabellen bleibt ungeprueft, wenn keine isolierte frische Instanz verfuegbar ist. | Einen ausschliesslich synthetischen Fresh-Database-Integrationstest fuer Migration 013, atomare GPO-Identitaetspersistenz und Baselinekataloge vorhalten; ihn vor Milestone-Abnahme gegen eine kurzlebige PostgreSQL-16-Instanz ausfuehren und niemals ersatzweise reale Mandantendaten inspizieren. |
| Microsoft-Baselinepakete enthalten erwartungsgemaess XLSX-Dateien und damit opake eingebettete ZIP-Signaturen; pauschales rekursives Oeffnen erzeugt Angriffsflaeche, pauschales Ablehnen blockiert offizielle Pakete. | Nicht ausgewaehlte Dokumente, Skripte und Binaerdateien niemals entpacken oder interpretieren. Nur Backup.xml, Registry.pol, ADMX und ADML selektieren; fuer den Gesamtcontainer Pfade, Typen und deklarierte Ressourcenlimits und fuer jeden ausgewaehlten Inhalt zusaetzlich lokale Header, tatsaechliche Groesse, Kompressionsverhaeltnis, CRC und SHA-256 pruefen. |
| Eine reale `Registry.pol`-Datei verwendet zusaetzliche oder missgebildete Registrytypen und wird versehentlich als normale Policy interpretiert. | Nur die dokumentierten MS-GPREG-Typen sowie REG_NONE als exakt leere Schluesselanlage zulassen; Typ-, Groessen-, Struktur- und Abschlusspruefungen fail-closed anwenden, Byteoffset-Provenienz bewahren und reale Kompatibilitaet ausschliesslich ueber technische Zaehl- und Integritaetssignale pruefen. |
| Ein Baselinepaket wird allein wegen eines aehnlichen Dateinamens fuer die GPO-Pruefung verwendet oder ein gespeichertes Original wird von der Artefakt-Reconciliation als verwaist geloescht. | Produkt, Version, Rolle und Scope separat speichern; nur genau einen vollstaendigen Treffer automatisch auswaehlen, sonst fail-closed. Baseline-Storage-Keys in dieselbe referenzgesicherte Reconciliation aufnehmen und Hash/Dateigroesse beim privaten Speichern pruefen. |
| Ein kombiniertes Microsoft-Baselinepaket wird auf den ersten erkannten Produktnamen oder die erste Zahl reduziert und dadurch fuer den zweiten Produktkontext falsch oder gar nicht ausgewaehlt. | Mehrere typisierte Produktkontexte pro Paket speichern, Detektorversion und Klassifikationsrevision persistieren, Originalmetadaten unveraendert lassen und kombinierte Client-/Server-Pakete sowie Microsoft-365-Versionen regressionspruefen. |
| Ein inventarisiertes oder teilweise analysiertes GPO-Backup erscheint bereits als Ergebnisbericht und suggeriert dadurch einen noch nicht ausgefuehrten Baselinevergleich. | Ingestion-, Job-, Inventar- und Parserstatus ausschliesslich in GPO Processing anzeigen; Berichtzaehler und Linked Scan Reports nur aus echten Scan-Runs beziehungsweise persistierten Baseline-Evaluation-Runs bilden. |
| Unterordner eines gemeinsam hochgeladenen GPO-Hauptordners werden als mehrere unabhaengige Mandanten-Backups oder Snapshots behandelt. | Den Upload als ein Backup-Set mit gemeinsamer quellartefaktbasierter Set-ID modellieren, Unterordner als einzelne enthaltene GPOs zaehlen und aggregieren; ohne Manifest nur selected-gpos annehmen und keine Vollstaendigkeits- oder Wirksamkeitsaussage erlauben. |
| Der atomare GPO-Artefaktspeicher liegt auf einem synchronisierten oder virtuellen Dateisystem ohne Hardlink-Unterstuetzung; die Vorpruefung gelingt, aber die unveraenderliche Veroeffentlichung scheitert. | `ASSESSOR_ARTIFACT_ROOT` auf einen privaten lokalen Datentraeger ausserhalb des Webroots legen, Roottrennung beim Start erzwingen und Put/Hash/Read praktisch verifizieren. Fuer den lokalen Windows-Betrieb ist ein NTFS-Pfad unter LocalAppData konfiguriert; Firmenbetrieb und Backupkonzept bleiben Teil von Phase 14. |
| Freier Result-Text oder eine zufÃ¤llig Ã¤hnliche ID verknÃ¼pft in einem gemischten Projekt ein Detailblatt eines anderen Scanners, etwa CIS-CAT-Evidenz mit einem Maester-Finding. | Werkzeugherkunft je Datensatz aus Source: Scan beziehungsweise dem aktiven Blatt auflÃ¶sen, explizit abweichende Blatt-toolIds bei direkten und unscharfen Links ausschlieÃŸen und Fuzzy-Matching auf erkennbare Datei- oder stabile Regel-ID-Verweise begrenzen; Maester/CIS-CAT-KreuzfÃ¤lle synthetisch regressionsprÃ¼fen. |
| Ein Doppelklick auf eine Kopfzeilenaktion lÃ¶st zusÃ¤tzlich Minimieren beziehungsweise Wiederherstellen aus oder ersetzt den zugÃ¤nglichen Einzelklick-Button. | Doppelklick nur auf der freien KopfzeilenflÃ¤che behandeln, Ziele innerhalb von SchaltflÃ¤chen ausschlieÃŸen und beide Umschaltrichtungen sowie die Button-Ausnahme in einem synthetischen DOM-Test prÃ¼fen; den sichtbaren Button unverÃ¤ndert beibehalten. |
| Result-Fenster werden durch weitere Clusteraktionen erneut minimiert, minimierte Reiter verschwinden hinter einem maximierten Fenster oder Fenster ragen nach Verschieben, Skalieren beziehungsweise Viewport-Änderung aus der Anzeige. | Entkopplung als eigenen Zustand führen und ausschließlich beim Minimieren löschen; Clusterfokus nur auf nicht entkoppelte Fenster anwenden. Minimierte Fenster stets gemountet als schmale Farbreiter rendern sowie Reiterstapel, Position, Breite und Höhe gegen die aktuelle Viewport-Geometrie begrenzen; Übergänge und gerenderte Grenzen synthetisch regressionsprüfen. |
| Falsch kodierte UI-Trennzeichen oder wiederholte Quellüberschriften verdecken den Finding-Titel beziehungsweise den Ergebnisinhalt. | Fenstertitel über einen eindeutigen Unicode-Trenner zerlegen, den Finding-Titel zusätzlich im Ergebnisinhalt anzeigen, Blattüberschriften für Result-Fenster gezielt unterdrücken und die gerenderte Ausgabe synthetisch regressionsprüfen. |
| Minimierte Fenster öffnen an einer zufälligen früheren Position oder der Reader-Button zeigt nicht den zugehörigen Result-Fensterton. | Parkposition bei jeder Minimierung explizit zurücksetzen, Viewport-Grenzen beibehalten, Clusterverschiebung unverändert weiterreichen und die Fensterfarbe als CSS-Variable an den geöffneten Reader-Button binden; beides synthetisch regressionsprüfen. |
| Kopfwerkzeuge, Filter oder Graphsteuerungen wachsen Ã¼ber die gemeinsame KopfhÃ¶he hinaus oder einzelne Bereiche umgehen die HÃ¼lle erneut. | Bereichsspezifischen Zustand in den Komponenten belassen, aber sÃ¤mtliche Kopfbedienung ausschlieÃŸlich in `.app-header-panel` beziehungsweise das bestehende Graph-Portal rendern; Containeranzahl, Ãœberlagerungsfreiheit und berechnete Geometrie inhaltsfrei im Browser prÃ¼fen. |
| Ein technisch konsolidierter UI-Zwischenstand wird erneut als visuell final behandelt oder der exakt abgenommene Work-Aufbau driftet bei spaeteren Erweiterungen. | Die Nutzer-Screenshots sind die Strukturreferenz; `work-reference.css` wird zwischen Skill und Laufzeit exakt gespiegelt und der Vertragstest sichert Topbar, zweizeiliges Filterband, Masterbreite, Reader-Inset, vier Bearbeitungsfelder, Tile-Masse, F/R-Kopfposition und vollstaendige Metadaten. Schritt 5 bleibt bis zur visuellen Nutzerabnahme in Arbeit. |
| Bereits persistierte Maester-Vorkommen vor Profil 1.2.0 koennen ausserhalb der Work-Kompatibilitaetsprojektion weiterhin die alte Severity `medium` tragen, obwohl ihr Outcome `warning` ist; oder Nebenfilter erhalten bei spaeteren Umbauten erneut Band-/Aktivklassen. | Work projiziert Maester-Outcome `warning` deterministisch als Severity `warning`, ohne Originalfelder zu veraendern; fuer eine dauerhaft aktualisierte kanonische Severity in allen Projektionen ist ein bewusster Reimport erforderlich. Der Komponenten-Regressionscheck erzwingt `.band__control`/`.is-filtered` nur innerhalb der Primaergruppe, und der UI-Skill schreibt neutrale Nebenfilter verbindlich vor. |
| Bereits importierte Maester-Laeufe behalten vor Profil 1.1.0 den normalisierten Wert `medium`, obwohl der Originalwert `Warning` lautet. | Profil- und Mappingversion je Vorkommen bewahren; neue Importe normalisieren werkzeuggebunden auf `warning`. Bestehende Laeufe nur durch einen bewussten Reimport aktualisieren, nicht durch eine stille Datenmigration. |
| Grundzustand und gesetzter Zustand der Filter werden erneut vermischt oder das Auswahlblau faerbt fachliche Filter. | `--filter-surface`/`--filter-on` ausschliesslich fuer Filterrahmen, ungesetzte Filterfelder und Reset verwenden; `.is-filtered` wechselt zentral und in der Work-Leiste auf `--accent`/`--accent-on`. Navigation und Objektauswahl bleiben blau. Wert, Trefferzahl und Schriftgewicht bleiben als nicht farbabhaengige Signale sichtbar; der Designpruefer erzwingt beide Zustandsregeln. |
| Eine spÃ¤tere lokale Panel- oder Shellfarbe unterschreitet im Darkmode die GrundflÃ¤che beziehungsweise Ã¼berschreitet sie im Lightmode und kehrt damit die Palette erneut um. | NeutralflÃ¤chen ausschlieÃŸlich aus `--surface-app` und `--structure` ableiten. Der DesignprÃ¼fer vergleicht nun sÃ¤mtliche Tokendeklarationen beider Theme-BlÃ¶cke in Reihenfolge und erzwingt die sieben neutralen Ableitungen sowie die drei Grundrollen; Dark und Light zusÃ¤tzlich Ã¼ber inhaltsfreie berechnete Browserwerte prÃ¼fen. |
| Skill-Quelle und Laufzeitkopien der Design-Tokens laufen auseinander, oder neue Ansichten umgehen die gemeinsame Shell und zentrale Komponenten. | `AGENTS.md` verpflichtet jede sichtbare Aenderung auf den UI-Skill; der Designpruefer vergleicht Skill- und Laufzeit-Tokens, und Erweiterungen verwenden die gemeinsame Shell sowie global importierte `ui-components.css`. Medium und Maester-Warning sind ausdruecklich abgenommene Ausnahmen mit weisser Severity-Tinte; Textlabel, feste Reihenfolge, aufrechtes Sechseck und identische Hakenposition sichern die Bedeutung redundant ab. |
| PingCastle-XML enthÃ¤lt keine statischen Herstellertexte; ein beliebiger oder versionsabweichender Regelkatalog kÃ¶nnte falsche ErklÃ¤rung beziehungsweise LÃ¶sung an ein Finding hÃ¤ngen. | Nur projektlokale HTML-Begleitberichte mit identischem Dateistamm und stabiler Rule ID verwenden, die Quelle sichtbar ausweisen, dynamische Punkte/Details nie Ã¼bernehmen und ohne exakten Begleiter unverÃ¤ndert bei den XML-Originalfeldern bleiben. |
| Nach erfolgreichem Serverimport verbleibt die rohe Parserprojektion im UI und weicht von den persistierten Findings ab; strukturierte XML-Metadaten erscheinen dadurch als Findings. | Die Abschlussantwort des Servers als ProjektidentitÃ¤t verwenden, alle Assessmentmodelle erneut Ã¼ber die kanonische Projektionsgrenze laden und diesen Pfad mit einer synthetischen PingCastle-XML-Regression sowie einer inhaltsarmen BrowserprÃ¼fung absichern. |
| Dateizeitpunkte fehlen, wurden beim Kopieren verÃ¤ndert oder liegen bei zwei unabhÃ¤ngigen LÃ¤ufen desselben Werkzeugs zufÃ¤llig eng zusammen; dadurch kann die mÃ¶gliche Dublettenmarkierung fehlen oder zu viel warnen. | Nur bekannte identische Werkzeug-IDs vergleichen, die Heuristik auf 60 Sekunden begrenzen, Gruppen desselben Scan Runs nicht gegeneinander prÃ¼fen, den Hinweis ausdrÃ¼cklich als â€žMÃ¶gliches Duplikatâ€œ darstellen und die Auswahl weiterhin erlauben; exakte Gleichheit separat Ã¼ber SHA-256 behandeln. |
| Bereits importierte Scannerdateien wurden vor der nativen PingCastle-Extraktion ohne Findings persistiert und ihre Originalbytes stehen fÃ¼r automatisches Reprocessing nicht mehr zur VerfÃ¼gung. | Betroffene PingCastle-HTML-/XML-Exporte im selben Mandanten erneut importieren; neue Importe vereinigen ihre Definition Ã¼ber die Rule ID, bewahren aber je Datei ein eigenes Vorkommen und ihre Provenienz. KÃ¼nftige Reprocessing-FÃ¤higkeit nur Ã¼ber die allgemeine Artefaktaufbewahrung ergÃ¤nzen. |
| Die Unified-Result-PostgreSQL-Projektion lÃ¤dt Scannerzeilen vor Review-, Lifecycle- und Kategorienfiltern weiterhin in den Anwendungsspeicher; die neuen relationalen Outcome-/Execution-Spalten und Kategoriezuordnungen werden noch nicht vollstÃ¤ndig vom Querypfad genutzt. | Projekt-, Assessment-, Scan- und Toolfilter bereits in SQL anwenden, API-Limits beibehalten und im nÃ¤chsten Queryschnitt die Migration-007-Spalten sowie Kategoriejoins fÃ¼r Filter, Facetten und Pagination nutzen; bis dahin projektgebundene Abfragen bevorzugen. |
| GroÃŸe Group-Policy-Preference-Dateien erschÃ¶pfen trotz zulÃ¤ssiger Datei- und Itemgrenzen den Workerheap durch quadratische Provenienz, vollstÃ¤ndige DOM-BÃ¤ume, gleichzeitig gehaltene Zwischenmodelle oder geklonte Containerdaten. | Lineare Quellzeilenberechnung, backupwurzelweise Sofortreduktion, keine Parser-Zwischenmodelle beziehungsweise Containerduplikate im Workerresultat und ereignisbasiertes Registry-Parsing verwenden; denselben Produktionsworker mit 45.000 Beobachtungen bei 512 MB synthetisch regressionsprÃ¼fen und die isolierte Speichergrenze beibehalten. |
| Ein groÃŸer zulÃ¤ssiger GPO-Transport Ã¼berschreitet beim Workerstart durch Byte-Duplizierung den Heap; ein manueller Retry erfordert erneut sensible Quelldaten; ein Absturz nach relationaler LÃ¶schung lÃ¤sst eine nicht mehr referenzierte Dateikopie zurÃ¼ck. | Worker-Kopie per Transferliste statt Structured Clone Ã¼bergeben, weiterhin konfigurierbare harte Heap-/Zeit-/Eingabegrenzen anwenden, Dead-Letter-Jobs projektgebunden ohne Reupload zurÃ¼cksetzen und LÃ¶schabsicht vor dem Objektzugriff atomar in einer unabhÃ¤ngigen Outbox persistieren, die beim Start und periodisch wiederaufgenommen wird. |
| Ein Abbruch zwischen Dateispeicher, Artefaktanlage und Jobanlage hinterlÃ¤sst verwaiste Objekte oder ein GPO-Artefakt ohne Analyseauftrag; flÃ¼chtiger UI-Zustand verschleiert Queue-, Retry- oder Dead-Letter-ZustÃ¤nde. | Artefakt und Job in einer Repository-Transaktion committen, neue Objekte bei Commitfehler sofort kompensierend lÃ¶schen, fehlende Jobs periodisch idempotent reparieren, nur alte regulÃ¤re nicht referenzierte Objekte bei vorhandenem vertrauenswÃ¼rdigem Referenzbestand begrenzt entfernen und den Mandantenstatus projektgebunden aus persistierten Daten pollen. |
| Manipulierte relative Browserpfade, Unicode-/Case-Kollisionen oder groÃŸe Ordnerauswahlen umgehen beim GPO-Ordnerimport die Containergrenzen beziehungsweise erschÃ¶pfen Clientspeicher. | Pfade vor dem Dateilesen kanonisieren, Kollisionen fail-closed ablehnen, gemeinsame Eintrags-/Datei-/Gesamtgrenzen anwenden, Dateien sequenziell lesen, ohne Kompression deterministisch umschlieÃŸen und den vollstÃ¤ndigen Umschlag im Backend unabhÃ¤ngig revalidieren. |
| Ein bestÃ¤tigungspflichtiger Import verliert beim VorschauÃ¼bergang den Zielmandanten und erzeugt beim Abschluss einen neuen Mandanten. | Importworkflow-ZustÃ¤nde Ã¼ber eine kontexterhaltende Transition wechseln, `targetProjectId` bis zum Commit bewahren und den Ãœbergang mit einer synthetischen Regression prÃ¼fen. |
| Mehrere Tabellen eines Scannerberichts besitzen denselben Caption- oder Anzeigenamen und kollidieren dadurch bei Recognition oder kanonischer Persistenz. | TabellenidentitÃ¤t zusÃ¤tzlich an den stabilen Quellindex binden, dieselbe ID durch Zwischenmodell und Dataset-Projektion tragen und wiederholte Namen mit synthetischen Mehrtabellenregressionen prÃ¼fen. |
| Drive Maps werden auf einen einzelnen Buchstaben oder ein Endmapping reduziert, Computer-Scope wird akzeptiert, `thisDrive`/`allDrives` werden kollabiert oder `cpassword` gelangt in Beobachtung beziehungsweise Export. | User-Scope erzwingen; Aktion, `useLetter`, Startbuchstabe und Auswahlmodus gemeinsam erhalten; Sichtbarkeitsfelder getrennt bewahren; UNC und optionale NETBIOS-Anmeldung validieren; unbekannte Felder `partial`, fehlerhafte unterstÃ¼tzte Felder fail-closed und KennwÃ¶rter nur als Vorhandenheitsindikator behandeln. |
| Services werden wie Registry-Preferences als C/D/R/U behandelt, User-Scope wird akzeptiert, Zeitfelder werden erfunden umgerechnet oder `cPassword` gelangt in Beobachtung beziehungsweise Export. | Eigenen Services-CSE mit `configure`, separaten typisierten Dienst-/Start-/Fehleraktionen, unverÃ¤nderten nichtnegativen Zeitwerten und Computer-Scope verwenden; unbekannte Felder `partial`, ungÃ¼ltige unterstÃ¼tzte Felder fail-closed und KennwÃ¶rter nur als Vorhandenheitsindikator behandeln. |
| Local-Group-Mitgliedschaften werden als ungeordnete Menge behandelt, Namen Ã¼berschreiben vorhandene SIDs oder `cpassword` gelangt in Beobachtung, Diagnose oder Export. | SID als technischen Selektor priorisieren, Delete-all und geordnete Add/Remove-Instruktionen getrennt erhalten, lokale Benutzer und Gruppen nicht verschmelzen und fÃ¼r PasswÃ¶rter ausschlieÃŸlich einen booleschen Vorhandenheitsindikator ausgeben. |
| Group Policy Preferences werden CSE-Ã¼bergreifend vereinheitlicht, Aktionen Ã¼berschrieben oder vorhandenes Item-Level-Targeting als wirksam beziehungsweise unwirksam geraten. | Preference-Typen einzeln anhand ihrer technischen CLSID-/Schema-Semantik reduzieren; UID, Reihenfolge, Aktion und Common Options erhalten, Targeting bis zu passender Umgebungsevidenz als `unknown` binden, unbekannte CSEs `partial` lassen und `cpassword` niemals entschlÃ¼sseln oder ausgeben. |
| Lokalisierte Advanced-Audit-Anzeigenamen oder eine Vermischung mit Legacy Audit beziehungsweise benutzerspezifischen Overrides erzeugen falsche IdentitÃ¤ten und Wirkungsannahmen. | Nur technische Subcategory-GUID und numerische Flags auswerten, Delivery-Mechanismen und Zieltypen getrennt halten, benutzerspezifische Ziele bis zu einem eigenen Modell `partial` lassen und effektive Anwendung ohne RSoP als `unknown` bewahren. |
| Security-Template-Abschnitte oder doppelte INF-SchlÃ¼ssel werden durch eine universelle Skalar- oder Last-write-wins-Logik verfÃ¤lscht. | UnterstÃ¼tzte Abschnitte getrennt typisieren, rohe Werte und Quellzeilen erhalten, abweichende Dubletten als Konflikt modellieren, unbekannte Abschnitte als `partial` bewahren und ohne spÃ¤tere Scope-/RSoP-Evidenz keine effektive Anwendung behaupten. |
| Der GPO-Worker bricht nach Ergebnispersistenz, aber vor Jobabschluss ab und erzeugt beim Retry Duplikate oder Ã¼berschreibt Historie. | Processing Run und Backupinstanzen in einer Transaktion speichern, IDs aus Job und Prozessorversion deterministisch ableiten, exakte Wiederholung revisionsneutral akzeptieren, abweichende Wiederholung ablehnen und den Job erst nach erfolgreichem Commit abschlieÃŸen. |
| Manipulierte ZIP-Header, Symlinks, Pfadkollisionen oder hohe tatsÃ¤chliche Dekompression umgehen deklarative VorprÃ¼fungen. | Gesamte ZIP-Struktur vor Inflation validieren, lokale und zentrale Header abgleichen, Links/Spezialdateien/Nesting blockieren und tatsÃ¤chliche GrÃ¶ÃŸen, Einzel-/Gesamtquoten, CRC und Hash im begrenzten Worker prÃ¼fen; bei jedem Konflikt atomar abbrechen. |
| Teil-, Alt- oder gemischte GPO-Backups erzeugen scheinbar vollstÃ¤ndige Snapshots oder negative Aussagen. | Technische DomÃ¤nen- und Setevidenz, getrennte Einzel-/SetvollstÃ¤ndigkeit, manifestgestÃ¼tzte Soll-/Ist-ZÃ¤hlung, Zeitspannengrenzen sowie fail-closed Status fÃ¼r Duplikate, Konflikte, unbekannte Abschnitte und nicht unterstÃ¼tzte Artefakte. |
| UI-Tabellenprojektion und Candidate-Mapping erzeugen unterschiedliche Findinganzahlen oder semantische Werte. | Candidate-Mapping als einzige Persistenzquelle fÃ¼r neue Importe, identische VorschauzÃ¤hlung, Diagnose nicht ausgewÃ¤hlter Tabellen, validierte BestÃ¤tigungs-IDs, Legacy-Fallback nur ohne Mapping sowie format- und scannerÃ¼bergreifende ParitÃ¤tsregressionen. |
| Persistente Ingestion Jobs werden doppelt ausgefÃ¼hrt, bleiben nach Worker-Abbruch hÃ¤ngen oder erzeugen durch Wiederholungen falsche Ã„nderungsstÃ¤nde. | Projektweit eindeutige IdempotenzschlÃ¼ssel, atomare `SKIP LOCKED`-Claims, zeitlich begrenzte Leases, begrenzte Versuche, kontrollierte Lease-Recovery, Dead Letter und revisionsneutrale Wiederholungen beziehungsweise Leerlauf-Polls. |
| Unbekannte Berichtslayouts werden falsch erkannt. | Konfidenzen, generischer Fallback, Importvorschau und bestÃ¤tigbare Mappings. |
| PingCastle benennt oder strukturiert bekannte Environment-Abschnitte, H2-Unterpunkte oder Tabellen kuenftig anders und eine Subject-Klassifikation greift nicht mehr oder zu breit. | Section-Key, unmittelbar vorangehenden sichtbaren H2-Titel, Tabellenrolle und Header kombinieren; Row Count/Presence fuer leere Tabellen und quellentreue Heading-Presence fuer tabellenlose Unterpunkte bewahren. Finding-Regeldetailabschnitte ausschliessen, unbekannte Strukturen als `pingcastle-table-row` erhalten und die vollstaendige sichtbare Environment-Hierarchie sowie negative Fallback-/Rule-Detail-Faelle synthetisch regressionspruefen. |
| Quelltools Ã¤ndern ihre Exportformate. | Versionierte Profile, Fixture-Tests und Erkennung Ã¼ber mehrere Signale. |
| Ã„hnliche oder gleich betitelte Findings werden falsch zusammengefÃ¼hrt. | Importlokale unresolved IdentitÃ¤ten, automatische Zuordnung nur Ã¼ber stabile technische IDs, EindeutigkeitsprÃ¼fung pro Stufe und TitelÃ¤hnlichkeit ausschlieÃŸlich als bestÃ¤tigungspflichtiger Reviewvorschlag. |
| GroÃŸe oder manipulierte Dateien blockieren die Anwendung. | Ressourcenlimits, sichere Parserkonfiguration, Belastungstests, gecachte Result-VerknÃ¼pfungen, memoierte Datensatznavigation, lazy gerenderte Result-Tabellen und verzÃ¶gerte lokale Review-Persistenz. |
| FrÃ¼he Datenbankentscheidungen verfestigen ein falsches Modell. | Kanonisches DomÃ¤nenmodell und Persistenzschnittstelle vor PostgreSQL. |
| Tauri-spezifische Logik erschwert den Browserbetrieb. | Plattformadapter und keine neue Fachlogik in Tauri-Kommandos. |
| Plan und tatsÃ¤chlicher Code driften auseinander. | Planabgleich Ã¼ber `AGENTS.md` und Aktualisierung nach verifizierten Meilensteinen. |
| Toolwissen oder Reportselektoren wandern erneut in generische Formatadapter. | Architekturtests, getrennte Adapter-/Extractor-/MappingvertrÃ¤ge und explizite Registries ohne dynamischen Code. |
| Batchassoziation oder Benutzerauswahl fÃ¼hrt zu einem falschen Dateiprofil. | BatchzugehÃ¶rigkeit separat speichern und Mapping nur nach struktureller Profilvalidierung anwenden. |
| Ein Source Extractor wÃ¤hlt falsche Kandidatengrenzen oder vervielfacht wÃ¤hrend der Migration bereits vorhandene UI-Daten. | Extractorwahl evidenzbasiert und deterministisch halten, Originalwerte und Locator bewahren, Kandidaten bis zur Scanner-Migration in Schritt 9 nicht als kanonische Persistenzquelle verwenden und bestehende Ressourcenlimits beibehalten. |
| Recognition und Candidate-Mapping driften bei Profilwechseln oder BestÃ¤tigungen auseinander. | Gemeinsame Evidenzkomponente verwenden, Profile und Extractors getrennt versionieren, nur explizit bestÃ¤tigte Feldentscheidungen Ã¼bernehmen und das Mapping nach ProfilbestÃ¤tigung deterministisch neu berechnen. |
| Heuristische Inhaltsmerkmale liefern bei Fragmenten oder polyglotten Dateien widersprÃ¼chliche Formatkandidaten. | Kandidaten und Evidenz deterministisch speichern, Signaturen und starke Struktur priorisieren, schwache FÃ¤lle durch den sicheren Parser validieren, Konflikte diagnostizieren und unbekannte BinÃ¤r-/Containerformate ablehnen. |
| Native Sicht und tabellarische KompatibilitÃ¤tsprojektion vergrÃ¶ÃŸern wÃ¤hrend der Migration Arbeitsspeicher und Vorschauantworten. | Projektionen explizit als verlustbehaftete KompatibilitÃ¤t markieren, bestehende Ressourcenlimits beibehalten, keine zusÃ¤tzliche Persistenz einfÃ¼hren und nach EinfÃ¼hrung der Extractor-Registry schrittweise auf referenzierte native Sichten umstellen. |
| Quelltabellen-Metadaten werden ohne ihre nicht als Findings erkannten Zeilen persistiert; Results-Verweise zeigen nach dem Neuladen ins Leere. | Nicht ausgewÃ¤hlte Tabellenzeilen begrenzt und mit Originalfeldern im kanonischen SourceTable speichern, Finding-Tabellen von Doppelhaltung ausnehmen sowie Import-, Projektions- und Linkerregressionen verwenden. |
| Gemeinsam genutzte PingCastle-Results-Blaetter erscheinen nach globaler Dataset-Reihenfolge statt nach dem Detailspfad des aktuell geoeffneten Findings; Linktexte oder Modal-Bedienelemente koennen zudem als irrefuehrende Tabellenpreambles erscheinen. | Results-Blaetter strikt nach den finding-spezifischen Section-IDs aufloesen, rekursive Zielabschnitte nach ihrer HTML-Definition ordnen, fachliche Prosa getrennt am Blatt bewahren und reine Titel-/`Close`-Artefakte vor der Darstellung entfernen. Synthetische Tests verdrehen absichtlich globale Blatt- und Triggerreihenfolge. |
| PingCastle-Details erscheinen nach der strukturierten Results-Projektion doppelt im Popup und im Reader; ein pauschales Ausblenden koennte dagegen bei historischen Importen ohne Results Informationen verbergen. | `Details` nur dann aus Reader-Zusammenfassung und Additional Information entfernen, wenn fuer das konkrete Finding mindestens ein strukturiertes Result-Blatt aufgeloest wurde. Einen synthetischen Ohne-Results-Fallbacktest beibehalten. |
| Client und Backend persistieren unterschiedliche Profil- oder Mappingentscheidungen. | UnverÃ¤nderte serverseitige Vorschau als Basis, explizite Recognition Overrides, Laufzeitvalidierung gegen registrierte Profile und reale Tabellen/Felder sowie Ablehnung offener BestÃ¤tigungen. |
| Historische oder unvollstÃ¤ndige GPO-Backups werden als aktuelle Gesamtumgebung interpretiert. | Backupinstanz, Snapshot, DomÃ¤ne, Erhebungszeitpunkt sowie Einzel- und SetvollstÃ¤ndigkeit explizit modellieren. |
| Unterschiedliche GPO-Client-Side-Extensions werden mit universeller Wertlogik verglichen. | CSE-spezifische Reducer, Delivery-Semantik, typisierte Comparatoren und Dependency-/Override-Regeln. |
| Baseline-Consensus entsteht trotz fehlender oder nicht unterstÃ¼tzter Kontexte. | Nichtanwendbarkeit, fehlende Empfehlung, Katalog-/ParserlÃ¼cke und unaufgelÃ¶ste IdentitÃ¤t getrennt speichern; Findings nur nach vollstÃ¤ndigem Consensus-Gate. |
| GPO-Ergebnisse behaupten ohne Scope- oder RSoP-Daten tatsÃ¤chliche Wirksamkeit. | `confirmed_configured_deviation`, getrennte Scope Confidence und Effective State sowie feste Qualifikation und PrÃ¼fhinweise. |
| Dateisystemobjekt und relationale Artefakt-/Jobreferenz driften bei Prozess- oder Datenbankfehler auseinander. | VerÃ¶ffentlichung und Repositoryanlage eng sequenzieren, idempotente Artefakt-/Job-IDs verwenden und vor Firmenbetrieb eine referenzgeprÃ¼fte Orphan-Reconciliation mit Aufbewahrungsfrist implementieren. |
| Der Rohartefaktspeicher wird versehentlich im Webroot oder ohne ProjektprÃ¼fung angebunden. | Betriebsroot explizit auÃŸerhalb statischer Assets konfigurieren und validieren; Lesen und Reprocessing nur Ã¼ber projektgebundene autorisierte Backenddienste, niemals per statischer URL. |
| GPO-Artefakte enthalten entschlÃ¼sselbare KennwÃ¶rter oder sensible Werte. | Secret-Erkennung ohne EntschlÃ¼sselung, Maskierung, geschÃ¼tzter Artefaktspeicher und minimale Zugriffsrechte. |
| Parserworker werden fÃ¤lschlich als Sicherheits-Sandbox betrachtet. | Worker nur als Ressourcengrenze behandeln; externe Werkzeuge separat, niedrig privilegiert, ohne Shell/Netzwerk und mit Pfad-, Hash-, Zeit- und Ausgabelimits ausfÃ¼hren. |
| Reprocessing Ã¼berschreibt Ã¤ltere Beobachtungen, Regeln oder Findings. | UnverÃ¤nderliche Rohartefakte und Katalogversionen, neue Processing-/Evaluation-Runs, Supersession und deterministische IdempotenzschlÃ¼ssel. |

| Funktionale Pfeile driften zwischen Navigation, Aufklappern, Result-Zuständen und nativen Auswahlfeldern auseinander oder werden durch Zeichenkodierung beziehungsweise spezifischere `background`-Kurzschreibweisen beschädigt. | Eine zentrale SVG-Dreiecksgeometrie für React-Controls, dieselbe Geometrie als CSS-Selectindikator, ausschließlich `background-color` für Select-Zustandsfarben, richtungsabhängige Rotation und synthetische Render-/CSS-Regressionsverträge verwenden. |

| Eine getrennte Control-Mappings-Liste lässt bei mehreren Controls nicht erkennen, welche Belegtabelle zu welchem Listenpunkt gehört. Eine rein positionsbasierte Teilzuordnung könnte bei fehlenden Tabellen außerdem falsche Titel erzeugen oder Angaben verschlucken. | Profilkonfigurierte Markdown-Gruppen mit den normalisierten Framework-Blatttiteln abgleichen, Listenpunkte innerhalb jeder Gruppe in Quellreihenfolge zuordnen und den Textabschnitt nur dann ausblenden, wenn alle seine Listenpunkte Tabellen erhalten haben. Synthetische Verträge prüfen mehrere Controls derselben Version, zukünftige Frameworks und den unvollständigen Rückfall. |
| Ein globaler Inhaltsvergleich für Hinweiszeilen könnte denselben Satz bei anderen Werkzeugen unbeabsichtigt als ausgewertete Evidence markieren. | Markierung ausschließlich über das aufgelöste Finding-Werkzeugprofil anwenden und mit einem Negativvertrag für andere Profile absichern; importierte Werte und der persistierte `highlighted`-Status bleiben unverändert. |
| Außenrahmen und Innenabstand jedes Result-Blocks können bei vielen Belegtabellen einen erheblichen Teil der nutzbaren Fensterfläche verbrauchen; ein vollständiges Entfernen aller Linien würde dagegen die Tabellenlesbarkeit schwächen. | Nur den äußeren `.result-block` auf `padding: 0`, `border: 0` und transparenten Hintergrund setzen; die eigenständigen Tabellenzelllinien unverändert erhalten und dies mit einem CSS-Vertrag schützen. |
| Ein kurzes maximiertes Result im Cluster verdeckt nur einen Teil des minimierten Stapels; bei vielen offenen Results können darunterliegende Titelleisten wieder sichtbar werden. Eine unbeschränkte Mindesthöhe könnte umgekehrt aus dem Viewport laufen. | Für angedockte maximierte Fenster die Zahl der dahinterliegenden Results mit der zentralen 34-px-Stapelhöhe multiplizieren und am sichtbaren Cluster-Viewport begrenzen. Reine Layout- und Renderregressionen prüfen normalen Stapel, kurzen Inhalt und den Viewport-Grenzfall. |
| Mandantenumrandung, `Show`-Aktion und Diagramme koennten auf unterschiedliche Mandanten oder Timeslots zeigen; leere Platzhalter koennten zudem wie reale Mandanten wirken. | Einen einzigen `DatahubTimeslotSelection.projectId` als Auswahlquelle verwenden, bei Mandantenklick genau den neuesten scannergebundenen Timeslot setzen, `aria-pressed` und `Show` aus derselben Projekt-ID ableiten und keine Placeholder-Projekte rendern. Synthetische Rendervertraege und eine inhaltsarme Browserpruefung sichern Auswahlanzahl, Aktion, Plus-Kachel und Diagrammwechsel. |
| Ein auf Viewportgroesse maximiertes Result koennte den statischen Header ueberdecken, nach Viewportaenderungen aus dem sichtbaren Bereich laufen oder beim Zurueckschalten die Nutzergroesse verlieren. | Die Header-Unterkante zur Laufzeit als obere Arbeitsflaechengrenze messen, rundum einen festen Innenabstand erhalten, maximierte Geometrie nur praesentativ ueber die normale Position und Groesse legen und den Zustand bei Minimierung zuruecksetzen. Synthetische Doppelklickregressionen sichern Maximierung, Wiederherstellung und Aktionsausschluss. |
| Ein generischer Statusfinder kann bei Purple Knight das kanonische `Result` mit einer SI-Kurzkennung für den fachlichen Ausgang halten oder den Rohstatus `IOE Found` anzeigen, obwohl die Kopfzeile die eindeutige `Passed`/`Failed`-Semantik verlangt. | Statusheader im Werkzeugprofil geordnet priorisieren, sichtbare Beschriftungen über quellenwertschonende Profilregeln ableiten und sowohl `Status`-vor-`Result`, `IOE Found` zu `Failed`, `Pass` zu `Passed` als auch den `Result`-only-Rückfall synthetisch in Reader, Datensatzkarte und Kachel prüfen. |

| Gemeinsame oder implizit entdeckte Vite-Konfigurationen koppeln Client, Server und Tests erneut und führen bei parallelen Agenten-/IDE-Läufen zu Syntax-, Cache- oder Outputkonflikten. | Dedizierte Konfigurationen und Cachepfade verwenden, npm-Skripte immer mit --config routen, den Defaultnamen auf einen unveränderlich schmalen Clientalias begrenzen und die Trennung als Architekturvertrag testen. |
| Ein unbeschraenkter Vitest-Fork-Pool liest auf einem synchronisierten Windows-Projektlaufwerk viele Module gleichzeitig, laesst den Grossteil der Suites scheinbar dauerhaft `queued` oder bricht mit einem Node-Dateilesefehler ab. | Dateiparallelitaet und Isolation beibehalten, den lokalen `forks`-Pool anhand kontrollierter Gesamtlaeufe auf vier Worker begrenzen und vor jeder kuenftigen Erhoehung erneut benchmarken. Der Config-Separation-Test prueft nur die Trennung, nicht eine konkrete Workerzahl. Lifecycle-Fehler weiterhin mit fokussierten Tests und dem `hanging-process`-Reporter untersuchen; keine Exit-Erzwingung einfuehren. |


| Der Entwicklungsclient wird ohne erreichbares lokales Backend gestartet und zeigt trotz erreichbarer Oberfläche dauerhaft „Backend is unreachable“. | Den Standardbefehl als Health-gesteuerten Stack-Starter ausführen: Backend auf `127.0.0.1:4173` prüfen beziehungsweise lokal bauen/starten, erst danach den Client auf `127.0.0.1:5173` öffnen und den Client-only-Befehl eindeutig separat benennen. |

| Im Graph ausgeblendete gemeinsame Facetten koennen weiterhin in Work gesetzt sein und dadurch die Graphmenge begrenzen, ohne im Graph-Panel selbst editierbar zu sein. | Die gemeinsame Filtersemantik bewusst beibehalten, die sichtbare Suche, Quellblattauswahl und Reset-Aktion im Graph erhalten und den Darstellungsvertrag synthetisch absichern; weitergehende Entkopplung nur als ausdrueckliche Fachentscheidung vornehmen. |

| Globale Zustandsselektoren fuer die Hauptnavigation erfassen versehentlich verschachtelte semantische `aside`-Bereiche in Fachansichten und blenden dadurch Controls aus. | Sichtbarkeitsregeln auf das direkte `aside` unter `main` begrenzen und den Graph-Vertrag gegen erneut zu breite Nachfahrenselektoren absichern. |

| 2026-08-04 | Phase-13B-Schritt-9/11 um den freigegebenen Policy-Evaluation-Regelkatalog nachgehaertet. Der implizite Equality-Fallback ist entfernt; nur eine exakte Policy-/Delivery-/Produkt-/Versions-/Rollen-/Scope-Regel darf Comparator und Risikoregel aktivieren. Ausdrueckliche Empfehlung, ausdrueckliche Nichtanwendbarkeit, keine Empfehlung und Katalogluecke werden getrennt gespeichert. Prerequisite-, Mutual-Exclusion- und Override-Regeln sind versioniert und konservativ an Snapshotvollstaendigkeit gebunden. Migration 016 persistiert Katalog-, Baselinezustands-, Regel-, Dependency- und Risikoprovenienz relational; die read-only Referenzdaten-API zeigt den aktiven Katalog. Der produktive Katalog 1.0.0 ist bis fachlicher Regelkuratierung bewusst leer und damit review-only. Synthetische Tests pruefen Minimum, Katalogluecke, Nichtanwendbarkeit, keine Empfehlung, Prerequisite, Mutual Exclusion und Override. `npm test`: 573 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die komplette PostgreSQL-Suite lief gegen eine frische PostgreSQL-16-Instanz mit 8 von 8 Tests erfolgreich; Migrationen 001 bis 016 und die relationalen Sicherheitsgrenzen wurden verifiziert, Container und synthetische Testdaten entfernt. Finding Factory, Unified-Result-Projektion, UI und reale Regelkuratierung bleiben offen; Phase 13B bleibt in Arbeit. |
| Ein neuer Profilstand könnte ohne Manifestregistrierung importiert werden, kompatible Darstellungsänderungen könnten fälschlich semantische Vergleiche sperren oder semantische Änderungen könnten alte und neue Findings als gleich behandeln. Fehlende Scanneroriginale könnten außerdem einen behaupteten Reimport unmöglich machen. | Neue Verträge fail closed registrieren, Änderungsklasse und betroffene Dimensionen explizit testen, Timeslot- und Vergleichsgrenzen auf den kanonischen Kompatibilitätsschlüssel stützen und Reprocessing ausschließlich aus hashgeprüften Originalbytes erlauben. Bei `not-retained` ist ein erneuter Upload erforderlich. |

## 12. Ã„nderungsprotokoll

| Datum | Ã„nderung |
| 2026-08-24 | Phase-14-Containerverbindung korrigiert: Die Repository-Laufzeit uebernimmt `ASSESSOR_POSTGRES_HOST` in die PostgreSQL-Verbindungszeichenfolge, sodass der App-Container den Compose-Dienst `postgres` statt seines eigenen Loopbacks anspricht. `ASSESSOR_DATABASE_URL` behaelt Vorrang und `127.0.0.1` bleibt der lokale Standard. Docker-Hostname und lokaler Fallback sind synthetisch regressionsgeprueft; Gesamtlauf 735 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Schema- oder Datenmigration; Phase 14 bleibt offen. |
| 2026-08-24 | Phase-7-Segment-/Kachelgrammatik nach Nutzerreferenz anwendungsweit umgesetzt und als Projektvorgabe verankert: gemeinsame Segment- und Kacheltokens fuer Flaeche, Kontur, Radius, Inset, Gap, Schatten, Auswahl und Breiten; flache Gruppencontainer; gleichartige Inhalts-, Aktions- und Hinzufuegekacheln; Statusfarben nur als Akzent; unvollstaendige Zeilen bleiben unstretched. Datahub, Dashboard, Sidebar, Work-TileGrid, DB Structure, Policy Analysis und statische Pathfinder-Karten verwenden den Vertrag. Die verbindliche Nutzerregel verbietet abgeschnittene, geklemmte, ellipsierte oder verborgene Titel, Werte, Labels, Zusatztexte und Aktionen. Dashboardstatuskarten wurden auf 290 beziehungsweise 210 px abgestimmt; Anzahl und Prozentwert stehen getrennt, sodass `Compliance` und Werte wie `453` vollstaendig bleiben. Das Donut-Raster nutzt auf Desktop sechs Spalten und die Matrix verteilt ihre feste Spaltenzahl ueber die volle Segmentbreite. Bei Platzmangel wird Inhalt neu angeordnet oder die Kachel verbreitert beziehungsweise responsiv umgebrochen. Sechzehn fokussierte Layout-/Donuttests und der Gesamtlauf mit 736 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung mit 0 Rohfarben sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Titelhierarchie nach visueller Nutzerkorrektur nachgeschaerft: Trefferlistentitel bleiben 16 px, verwenden aber Medium 500 statt Semibold; der geoeffnete Finding-Titel verwendet eine neue zentrale 20-px-Detailtitelrolle mit Semibold. Finding-Abschnitt 18 px, Matrixkacheln 16 px und die 16-px-Untergrenze fuer Inhalt bleiben unveraendert. Titel brechen nur an Wortgrenzen. Drei fokussierte Typografieregressionen sowie der Gesamtlauf mit 736 bestandenen und 8 uebersprungenen Tests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Labels nach Nutzerkorrektur verdichtet: Outcome (`Failed`/`Passed`), Weight, Severity, Category, Score, CIS- und MITRE-Zuordnungen verwenden in Reader und regulaeren Matrixkacheln nun einen zentralen 12-px-Badgetoken statt der bisherigen 13-px-Labelstufe. Farb-, Glyph-, Rahmen-, Reihenfolge- und Statussemantik bleiben unveraendert; inhaltstragender Text wird nicht verkleinert. Fuenf fokussierte Typografieregressionen, 736 Standardtests, Local-only-Pruefung, Designpruefer und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Typografie nach Nutzerkorrektur verdichtet: Der Reader-Titel und die Finding-Abschnittsueberschrift verwenden jetzt die bestehende H3-Rolle mit 18 px statt H2 mit 32 px; Titel in Trefferlisten und regulaeren Matrixkacheln verwenden die H4-Rolle mit 16 px statt der bisherigen 18-px-Heading-Rolle. Lange Scannerbezeichnungen beanspruchen damit weniger Zeilen, waehrend inhaltstragender Text die verbindliche 16-px-Untergrenze behaelt. Die Aenderung betrifft ausschliesslich bestehende Work-Selektoren; globale Seitentitel, Pathfinder-Micro-Cards, Daten-, Import- und Persistenzlogik bleiben unveraendert. Zwei neue Typografieregressionen, 735 Standardtests, Local-only-Pruefung, Designpruefer und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Donut-Innenraum nach visueller Nutzerpruefung korrigiert: Zahl, Prozentzeichen und vorhandener Unterwert bleiben unveraendert im Ring, duerfen seine Kontur aber nicht beruehren. Die Zahl ist unabhaengig von der Einheit geometrisch zentriert; dreistellige Prozentwerte erhalten eine automatische Kompaktstufe. Fuer die kleineren Sidebar-Ringe sind Wert, Einheit und Einheitenabstand ueber eigene gemeinsame Tokens reduziert. 13 fokussierte Donut-, Sidebar- und Datahub-Regressionen, Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Filter-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Donutstandard nach Nutzerreferenz vereinheitlicht und verbindlich dokumentiert: Datahub-Statuskarten und Sidebar-Severity-Karten verwenden statt offener 270-Grad-Gauges nun vollstaendige neutrale Ringspuren mit farbigem Uhrzeigersinnbogen ab 12 Uhr, flachen Enden und mittigem Prozentwert samt kleiner Einheit; der absolute Wert bleibt als dezente Sekundaerinformation erhalten. Dashboard-Statusringe verwenden dieselbe Spur und Strichstaerke. Die mehrteilige Risk-Severity-Verteilung behaelt ihre fachlichen Segmente, uebernimmt aber Geometrie, Spur, Strichstaerke, Startposition und zentrierte Prozentdarstellung. 730 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, Filter-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Typografiesystem vereinheitlicht und als verbindliche Projektvorgabe verankert: Inter Variable wird ausschliesslich lokal gebuendelt und ersetzt abweichende System- und Display-Schriften. Zentrale semantische Rollen definieren H1 bis H4, Fliesstext, UI-Labels, Metadaten, Tabellenkoepfe und Buttons; Uppercase ist auf Tabellenkoepfe und kurze technische Kennzeichnungen begrenzt. Datahub, Bereichsheader, Mandantendetail, Tabellen, Controls, Raw Data und Kennzahlen verwenden die gemeinsame Hierarchie. 730 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Designkonflikte bereinigt: Mandantenkarten und die gemeinsam verwendeten Data-/Pathfinder-Tiles tragen weder regulaere noch Hover-Schatten und verwenden keinen Hover-Lift; Interaktion bleibt ueber Haarlinie und Hintergrund sichtbar. Redundante Pathfinder-Null-Ueberschreibungen wurden entfernt, Radius-/Control-Verweise auf vorhandene Tokens vereinheitlicht, die dynamische Dashboard-Segmentbreite erhielt einen CSS-Fallback und berechnete Result-Spaltenbreiten bleiben als erlaubte Geometrie gekapselt. Die Schattenobergrenze fuer `legacy-views.css` wurde von sechs auf drei abgesenkt. 728 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, vollstaendiger Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-13A-HTML-Import gegen den reproduzierten 30-Sekunden-Abbruch mittelgrosser Scannerberichte nachgehaertet: Die gemeinsame Browser-/Node-Umschaltung verwendet den bereits begrenzten lexikalischen HTML-Extraktor nun ab mehr als 1 MiB statt erst oberhalb von 4 MiB. Worker-Timeout und Ressourcenlimits bleiben unveraendert. Ein synthetischer 1,6-MiB-PingCastle-Bericht bestaetigt Format, Profil, Tabelleninhalt und `html-bounded-extraction`; 30 fokussierte Parser-/Worker-/PingCastle-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen, keine API-, Persistenz-, Schema- oder Profilversionsaenderung; Phase 13A bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Dashboard-IOE-Kennzahl als Filtereinstieg umgesetzt: `IOEs found` ist bei vorhandenem Trefferbestand anklickbar, setzt bestehende Dashboardfilter zurueck, uebergibt exakt die als explizite `IOE Found`/`IOEs found` gezaehlten Datensatz-IDs an die vorhandene Work-Teilmenge und oeffnet Work. Bei null Treffern bleibt das Steuerelement deaktiviert, damit kein ungefilterter Bestand erscheint. Zehn fokussierte Dashboard- und Filtertests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Ringspur nach Nutzerreferenz sichtbar gemacht: Der bislang mit dem Panel verschmelzende ungefuellte Anteil der oberen Statusringe verwendet nun den vorhandenen neutralgrauen Donut-Rahmentoken; Farbbogen, Geometrie, Werte und Interaktionen bleiben unveraendert. Sieben fokussierte Dashboardtests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Statusleiste nach Nutzerreferenz korrigiert: Die sechs gleichartigen Donutkarten sind durch eine fuenfteilige Leiste ersetzt. Compliance Score erhaelt den grossen Ring mit Formelhinweis; Deviation, Passed und Not Run verwenden kompakte Ringe mit realer Anzahl und Prozentwert. Not Applicable und Error stehen gemeinsam in einer Zusammenfassung neben `IOEs found`. Der IOE-Wert zaehlt ausschliesslich explizite `IOE Found`-/`IOEs found`-Quellenfelder und wird nicht aus Deviations abgeleitet; Statuskarten bleiben direkte Filtereinstiege in Work. 14 fokussierte Dashboard-, Donut- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Risk-Profile-Selektor um `Full Risk Profile` erweitert: Dieser Modus umfasst alle aktiven Findings, zeigt links statt Kategorien die real vorhandenen Werkzeuge mit ueber mehrere Zeitstaende aggregierten Findingzahlen und berechnet Severity-Ring, Marked-Zahl und Deviation-Nenner ueber den Gesamtbestand. Ein Werkzeugklick oeffnet Work mit genau diesem Quellenfilter; Werkzeugprofile behalten links ihre eigenen Kategorien. PingCastle bleibt beim ersten Oeffnen der Standard, sofern vorhanden. 18 fokussierte Dashboard-, Facetten- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-PingCastle-Risk-Profile um explizite Nullkategorien korrigiert: Die vier feste Scanner-Skala Anomalies, Stale Objects, Privileged Accounts und Trusts wird aus den strukturierten `risk.*`-Environment-Beobachtungen aufgebaut und filtert Nullwerte nicht mehr weg; `Trusts 0` bleibt damit sichtbar. Aeltere Importe ohne Risk-Observations fallen auf die werkzeugbezogenen Facettenzaehler zurueck, behalten aber alle vier Zeilen. Environment Snapshot wird fuer Directory Overview und Risk Profile gemeinsam einmal geladen. 15 fokussierte Dashboard- und Facettentests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Risk-Profile werkzeugbezogen korrigiert: Die bisherige statische Panelueberschrift ist ein klickbarer Tool-Selektor fuer PingCastle, PurpleKnight, CIS-CAT, Maester und alle weiteren real vorhandenen Scanquellen. Mehrere Zeitstaende desselben Werkzeugs werden zu genau einer Auswahl gruppiert; PingCastle ist der Standard, wenn vorhanden. Kategorien, Severity-Ring, Legendenzahlen, Marked-Zahl und Deviation-Nenner werden ausschliesslich aus den Datensaetzen des gewaehlten Werkzeugs neu gezaehlt. Kategorie- und Severity-Klicks uebergeben Werkzeug plus Auswahl gemeinsam an Work. 17 fokussierte Dashboard-, Facetten- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Unterzeile nach Nutzerreferenz korrigiert: Directory Overview zeigt vier getrennte Coverage-Kennzahlen oberhalb eines festen vierspaltigen Faktenrasters; die bisherigen Coverage-Chips und die wiederholte Summenzeile entfallen. Das rechte Panel ist nun ein Risk Profile mit `Marked for report` im Kopf, den vier staerksten realen Kategorien links sowie einem segmentierten Severity-Ring und Legende rechts. Kategorien und Severity bleiben direkte Filtereinstiege in Work; bei fehlenden Facetten erscheinen ehrliche Leerzustaende. Sieben fokussierte Dashboard-/Inset-Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Scanquellen nach Nutzerkorrektur gekuerzt: Die Legende der Scan Source Distribution entfernt ausschliesslich einen abschliessenden gueltigen ISO-Tag beziehungsweise ISO-Zeitstempel aus `Werkzeug · Zeitstempel`; Werkzeugname, interner Facettenwert, Provenienz und Filter-Sprung nach Work bleiben unveraendert. Drei fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard nach Nutzerreferenz als kompaktes Analyseboard neu geordnet: Der bestehende Donut-Standard zeigt Compliance Score sowie reale Statuszahlen fuer Deviation, Passed, Not Applicable, Not Run und Error; Statuskarten bleiben direkte Filtereinstiege in Work. Severity und Scanquellen erscheinen als zweispaltige segmentierte Verteilungen mit anklickbarer Legende, Directory Overview und Reportmarkierung bilden die untere Informationszeile. Der verbindliche 20-px-Panelinset und 16-px-Inhaltstext bleiben erhalten; keine erfundenen Kennzahlen, keine Import-, API-, Persistenz- oder Schemaaenderung. Neun fokussierte Layout-/Donut-/Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Gesamtlauf: 721 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; ein fachfremder CRLF-sensitiver Quelltexttest in `results-browser-timeslot-scope.test.ts` bleibt rot. Der bekannte Designcheck bleibt an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-13C-PingCastle-Environment-Subjects nachgehaertet: Profil 1.4.0, Mapping 1.2.0 und Extractor 2.1.0 verwenden normalisierte PingCastle-Berichtsnamen und Punktpfade fuer jeden sichtbaren Environment-Unterpunkt. Dazu gehoeren unter anderem `domain-information.entra-id-configuration`, die User-/Computer-Analysen, Admin-Groups-/Control-Paths-Unterpunkte, Trusts, PKI, alle Infrastructure-, Anomalies-, Password-Policies- und GPO-Unterpunkte. Leere Tabellen werden ueber Row Count/Presence, tabellenlose H2-Bereiche ueber eine quellentreue Presence-Beobachtung sichtbar; Backup, LAPS, WEF und krbtgt sind entsprechend dem Bericht unter Anomalies korrigiert. Finding-Regeldetailbereiche bleiben ausgeschlossen und unbekannte Tabellen behalten `pingcastle-table-row`. Ein ausschliesslich temporaerer, danach entfernter Read-only-Test gegen den ausdruecklich freigegebenen Dummy-Bericht bestaetigte 48 hierarchische Unterpunkt-Typen; persistierte Inhalte wurden nicht veraendert. 47 fokussierte synthetische Tests, Local-only-Sicherheitspruefung und Client-/Server-Produktionsbuild erfolgreich. Gesamtlauf: 718 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; ein fachfremder CRLF-sensitiver Quelltexttest in `results-browser-timeslot-scope.test.ts` bleibt rot. Der Designcheck bleibt an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine API-, SQL- oder Migrationsaenderung; bestehende PingCastle-1.3.0-Importe benoetigen einen Reimport. Phase 13C bleibt in Arbeit. |
| 2026-08-24 | Phase-7/12/13A-Reimportidentitaet fail closed nachgehaertet: Ein zielgebundener Scanner-Reimport akzeptiert nur noch das exakte SHA-256-Multiset aller Dateien des zu ersetzenden ScanRuns. Preview prueft die hochgeladenen Bytes vor Parsing und Persistenz; Complete prueft die final ausgewaehlten Vorschauobjekte erneut; Local- und PostgreSQL-Repository erzwingen die Invariante bei kanonischem Ersatz und bei der Uebernahme eines bereits importierten Ersatzlaufs. Fehlende Originalhashes, abweichende Bytes, fehlende oder zusaetzliche Dateien sowie der nicht verifizierbare Offline-Fallback werden mit eindeutiger Fehlermeldung abgelehnt; der alte Scan bleibt aktiv. Datahub bietet einen vorhandenen Ersatzlauf nur bei Hashgleichheit an, und der Reimportdialog akzeptiert keine bloss wahrscheinliche Dublette mehr. 31 fokussierte synthetische Tests und der vollstaendige Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 718 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die Reimportaenderung erzeugt keinen neuen Designbefund. Keine Migration, keine Realdaten gelesen oder mutiert; Phasen 7, 12 und 13A bleiben abgeschlossen. |
| 2026-08-24 | Phase-7/12-Datahub-Readiness auf mandantenweite Vergleichsbereitschaft korrigiert: Die Kachel fasst nicht mehr nur den neuesten `Open`-Timeslot zusammen, sondern alle aktiven scannergebundenen Timeslots. Sobald irgendein aktiver Altstand einen Reimport auf den aktuellen ASSESSOR-Verarbeitungsvertrag benoetigt, erscheint der Mandant gelb und `Manage` dauerhaft; inkompatible oder unbekannte Vertraege bleiben rot. `Manage` klappt saemtliche betroffenen Timeslots automatisch auf, auch wenn sie weder aktuell noch ausgewaehlt sind; `Open` oeffnet weiterhin den neuesten Timeslot. Damit kann ein aktueller neuer Stand einen fuer spaetere Lifecycle-Vergleiche relevanten Altstand nicht mehr gruen ueberdecken. Zwoelf fokussierte Datahub-Tests sowie Client-Bundle und Server-Produktionsbuild erfolgreich; Gesamtlauf 715 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der vollstaendige Client-Typecheck ist durch zwei parallele Pathfinder-Typfehler in `ObsidianGraphView.tsx` blockiert; der bekannte Designcheck bleibt nur an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 und 12 bleiben abgeschlossen. |
| 2026-08-24 | Phase-7-Kopfbereich um den dauerhaft sichtbaren ASSESSOR-Verarbeitungsstand erweitert: Unter dem Markennamen erscheint ausschliesslich die zentrale Processing-Version, aktuell `1.3.0`, ohne `Version`, `v` oder weiteren Begleittext. Die Anzeige verwendet `CURRENT_ASSESSOR_PROCESSING_VERSION` aus dem Processingvertrag und ist bewusst von der technischen npm-Paketversion getrennt. Kompakte Metadaten-Typografie und tabellarische Ziffern veraendern Logo, Navigation und Kopfgeometrie nicht. Fuenf fokussierte Header-/Versionsregressionen sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 712 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die Versionsanzeige erzeugt keinen neuen Befund. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Reimport-Hinweispanel fachlich praezisiert: Ueberschrift und Einleitung benennen jetzt ein neues internes `ASSESSOR processing profile` statt eines unspezifischen Processing-Updates. Die laufbezogene Erklaerung zeigt den Versionswechsel als `1.2.0 → 1.3.0`, erklaert die zusaetzliche Environment-Context-Erfassung und sagt ausdruecklich, dass der PingCastle-Bericht selbst unveraendert ist. Status-Tooltips verwenden dieselbe ASSESSOR-Verantwortungsgrenze. Acht fokussierte Datahub-, Readiness- und Reimport-Texttests sowie vollstaendiger Client-/Serverbuild erfolgreich; keine Parser-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-23 | Phase-7/12/13A-Reimportdialog semantisch entwirrt: Ein identischer Bericht erscheint im zielgebundenen Ersatzworkflow nicht mehr als gelbes `Duplicate`, sondern gruen als `Expected replacement source` mit ausdruecklichem Hinweis, dass die Uebereinstimmung erwartet ist. Exakte und wahrscheinliche Ersatzquellen erhalten getrennte positive Erklaerungen; die Datei bleibt vorausgewaehlt, der Hauptbutton lautet `Reimport and replace`, und der Erfolgsbericht spricht von abgeschlossenem Replacement statt von gefundenen Dubletten. Der normale Import behaelt seine bisherige Dublettenwarnung und Abwahl. 20 fokussierte Dialog-, Auswahl-, Readiness- und HTTP-Tests, 705 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie vollstaendiger Client-/Serverbuild erfolgreich. Nur der bekannte globale Designcheck fuer `datahub-redesign.css` Zeilen 39/42 bleibt rot. Keine Parser-, API-, Schema-, Persistenz- oder Realdatenaenderung. |
| 2026-08-23 | Phase-13C-Versionsvertrag nach realer inhaltsfreier Laufzeitdiagnose korrigiert: Fuenf aktive PingCastle-Laeufe besassen trotz aktueller Anzeige null ReportSections und null EnvironmentObservations; der aktuelle Parser erzeugte aus der bereitgestellten Quelldatei dagegen 17 Abschnitte und 1.501 Beobachtungen. Ursache war kein Parser- oder Result-DB-Fehler, sondern ein unter Profil 1.2.0 nicht unterscheidbarer Import durch einen aelteren Backendstand. PingCastle 1.3.0 ist nun der erste eindeutig aktuelle Environment-Context-Vertrag; 1.2.0 bleibt historisch, wird automatisch `reimport-recommended` und verwendet weiterhin denselben Finding-Kompatibilitaetsschluessel. 33 fokussierte Tests und der vollstaendige Client-/Serverbuild erfolgreich; Gesamtlauf 704 bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only gruen. Nur der bekannte Designcheck in `datahub-redesign.css` Zeilen 39/42 bleibt rot. Der Entwicklungsstarter wechselte automatisch auf den neuen Backendrelease; die Live-Facette weist alle vorhandenen PingCastle-Resultate jetzt als reimportbeduerftig aus. Keine realen Inhalte gelesen oder ausgegeben und keine Scandaten mutiert; der Nutzer muss den betroffenen Bericht einmal mit Profil 1.3.0 reimportieren. Phase 13C bleibt in Arbeit. |
| 2026-08-23 | Phase-13C-Environment-Daten in die Unified Result DB integriert: `EnvironmentObservation` wird als eigener Result-Typ `environment-observation` neben Findings und Policy-Ergebnissen projiziert. Local- und PostgreSQL-Readmodelle, Same-Origin-Listen-/Facetten-/Detail-API, Clientquery und Result-DB-Oberflaeche liefern Property, Subject, Erfassungszustand, Original-/Normalwert, Abschnitt, Locator sowie Import-, Profil- und Mappingprovenienz. Eigene Environment-Facetten sind filterbar; Severity, IOE, Abweichung und Review werden nicht als Environment-Fachaussage dargestellt. Keine neue Migration, da die Projektion auf Migration 018 aufsetzt. 36 fokussierte synthetische Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; Gesamtlauf 703 bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only gruen. Nur der bekannte Designcheck fuer `datahub-redesign.css` Zeilen 39/42 bleibt rot. Keine realen Scan-Inhalte gelesen oder Daten migriert; bestehende Altimporte benoetigen weiterhin einen erfolgreichen Reimport, bevor Environment-Resultate vorhanden sind. Phase 13C bleibt bis zur realen PostgreSQL-Laufzeitintegration in Arbeit. |
| 2026-08-23 | Phase-10-Server-Readiness im lokalen Entwicklungsbetrieb nachgehaertet: `npm run dev` fuehrt einmalig den Server-Typecheck aus, betreibt danach einen Vite-Watch-Build und startet den Client erst nach einem Health-Nachweis fuer exakt die SHA-256-Release- und zufaellige Entwicklungsinstanzkennung des gebauten Backends. Erfolgreiche Server-Rebuilds wechseln den eigenen Backendprozess geordnet; fehlgeschlagene Builds lassen den letzten gesunden Prozess aktiv. Eine kleine Laufzeitdatei unter `node_modules` erlaubt nach einem Starterabbruch ausschliesslich die Rueckforderung des exakt ausgewiesenen Entwicklungsprozesses, waehrend fremde oder inkompatible Portbelegung fail closed bleibt. Praktischer Watch-Test: PID 5068 wurde nach Buildsignal automatisch durch PID 18240 ersetzt, anschließend Frontend und Backend HTTP 200. 25 fokussierte und 698 Standardtests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an `datahub-redesign.css` Zeilen 39/42 rot. Keine Scan-, Schema-, Migrations- oder Persistenzdaten geaendert; Phase 10 bleibt abgeschlossen. |
| 2026-08-23 | Reimport-Nachhaertung nach reproduziertem Versionskonflikt zwischen aktuellem Frontend und seit 19:09 Uhr laufendem, vor dem aktuellen Serverbundle gestarteten Backend: Die Preview-API spiegelt das exakte `replacesScanRunId` vor jeder Persistenz zurueck, der Client bricht bei fehlender oder abweichender Bestaetigung vor dem Commit ab und kontrolliert auch die Abschlussantwort. Fuer den bereits als normaler zweiter Scan gespeicherten Sonderfall bietet der Datahub einen expliziten Weg, den neueren bereiten Scan desselben Werkzeugs im selben Timeslot ohne erneuten Upload und ohne Loeschung als auditierbaren Ersatz zu uebernehmen; Local- und PostgreSQL-Repository verknuepfen beide aktiven Laeufe atomar und pruefen Mandant, Timeslot, Werkzeug, Aktivstatus und Zeitfolge. 22 fokussierte sowie 693 Standardtests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only-Sicherheitspruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an `datahub-redesign.css` Zeilen 39/42 rot. Keine realen Scan-Inhalte gelesen oder veraendert; die Reparatur bleibt eine explizite Nutzeraktion. Phase 7/12/13A-Status unveraendert. |
| 2026-08-23 | Phase-7/12/13A-Reimportworkflow umgesetzt: Jeder Scanbericht kombiniert seine bisherige Viewability mit dem versionierten Processingvertrag; ein erforderlicher Reimport erscheint nicht mehr gruen als `Recognized`, sondern rot als `Reimport required`. Unter jedem betroffenen Timeslot steht ein kompaktes Erklaerpanel mit Profilstand und eigener `Reimport <Tool>`-Aktion. Da normale Scanneroriginale bewusst nicht gespeichert werden, fordert die Aktion den Original-Dateisatz erneut an, bindet Vorschau und Abschluss an Mandant, Timeslot und aktiven ScanRun und lehnt Werkzeug- oder Zielabweichungen ab. Der neue ScanRun supersediert den alten innerhalb derselben Repositorymutation; der Vorgaenger samt Findings und Vergleichen bleibt auditierbar, wird aber aus aktiven Datahub-, Work-, Result- und Environment-Projektionen ausgeblendet. 38 fokussierte API-, Repository-, HTTP- und UI-Tests sowie der Gesamtlauf mit 692 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-Sicherheitspruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der Designcheck bleibt ausschliesslich an den zwei bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine Realdaten gelesen, geloescht oder reimportiert; keine Migration erforderlich, reale PostgreSQL-Laufzeitpruefung blieb offen. Phase 7 und 12 bleiben abgeschlossen, Phase 13A bleibt abgeschlossen. |
| 2026-08-23 | Phase-7/12-Datahub-Hinweisfuehrung nachgeschaerft: `Reimport recommended` ist nun in Kachelpunkt, Scanstatus und Erklaerpanel gelb; Rot bleibt ausschliesslich `Incompatible` und `Unknown` vorbehalten. Bei Update oder Fehler ist `Manage` auch ohne Auswahl dauerhaft sichtbar und statusbezogen dezent umrandet. `Manage` klappt alle betroffenen Timeslots automatisch auf, damit Erklaerung und Reimportaktion unmittelbar sichtbar sind; mehrere Hinweise koennen gleichzeitig offen sein. Statuslogik, Reimportvertrag und Bestandsschutz bleiben unveraendert. Zwölf fokussierte Datahub-Tests und Server-Produktionsbuild erfolgreich, Local-only gruen; Gesamtlauf 705 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und ausschliesslich durch eine parallele Pathfinder-Regression in `obsidian-graph.test.ts` blockiert. Der Client-Typecheck ist ebenfalls durch parallele unvollstaendige `ObsidianGraphView.tsx`-Aenderungen blockiert. Der bekannte Designcheck bleibt nur an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die neue Hinweisgestaltung erzeugt keinen weiteren Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 und 12 bleiben abgeschlossen. |
| 2026-08-23 | Phase-7-Datahub-Processingindikator als deutliches Eckelement nachgeschaerft: Rot und Gruen verwenden nun denselben 14-px-Kreis mit 4 px Abstand zur oberen und linken Kartenkante und sitzen damit sichtbar in der 8-px-Kartenrundung. Statuslogik, ARIA-Label, Tooltip, Kachelgeometrie und Bedienung bleiben unveraendert. Die statische Layoutregression sichert Groesse und tokenisierten Eckabstand. Fokustest und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 705 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; der Indikator erzeugt keinen neuen Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Datahub-Mandantenkacheln um einen kleinen Processing-Readiness-Punkt links oben erweitert. Die Anzeige verwendet den bestehenden versionierten Processingvertrag und ausschliesslich den neuesten scannergebundenen, ueber `Open` erreichbaren Timeslot: `Current`/`Compatible older` erscheinen gruen, `Reimport recommended`/`Incompatible`/`Unknown` rot; Mandanten ohne Scannerstand zeigen keinen Punkt. Historische Altstaende halten einen aktuellen Mandanten nicht rot. ARIA-Label und Tooltip ergaenzen die Farbaussage. Sieben fokussierte synthetische Tests, 689 bestandene Standardtests, Local-only-Pruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der Designcheck bleibt ausschliesslich an den zwei bereits bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; der neue Punkt erzeugt keinen weiteren Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kacheln als eigenstaendiges Designelement `Pathfinder Micro Card` formalisiert, ohne die bestaetigte Darstellung zu veraendern: wrapperfreie Finding-/Relation-Varianten, Category als groessere Relation-Auspragung, unveraenderte Masse 240x176, 148x72 und 196x116 sowie gemeinsamer Graphfaktor 0,4. Titel 16 px, Finding-Badges 11 px, Relation-Badges 12 px, Aktionen 10 px und bestehende 8-/6-px-Aktionsradien sind nun eigene Tokens. Der optionale Extract-View-Ref ist typkorrekt, rohe Schwarz-/Weisswerte und `!important` wurden wertgleich durch Tokens und lokale Selektorspezifitaet ersetzt. 11 fokussierte Pathfinder-/Connector-/TileCard-Tests, 685 bestandene Standardtests, Local-only-Pruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der Designcheck ist fuer `obsidian-graph.css` gruen und bleibt ausschliesslich an den zwei bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine Import-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase 13C begonnen und PingCastle-Environment-Context vertikal umgesetzt: vollstaendige quellengetreue HTML-Abschnitte und Tabellen, XML-Hierarchie, typisierte AD-/PKI-/OS-/Trust-/LAPS-/Backup-/WEF-/krbtgt-/Scannerbeobachtungen, explizite Erfassungszustaende, kanonische Persistenz, Migration 018, Local-/PostgreSQL-Repositories, Projekt-Export, scanlaufgebundene Environment-Snapshot-API/Client und Dashboard-Overview. 43 fokussierte synthetische Tests sowie Server-TypeScript erfolgreich. Gesamtlauf: 684 Tests bestanden und 8 optionale PostgreSQL-Tests uebersprungen; anschliessend blockiert nur der vorbestehende Designcheck durch rohe Farbwerte in `obsidian-graph.css`. Der Produktionsbuild bleibt durch zwei vorbestehende TypeScript-Fehler in `ObsidianGraphView.tsx` blockiert; reale PostgreSQL-Integration fuer Migration 018 bleibt offen. Keine Realdaten gelesen oder migriert; bestehende Importe benoetigen einen Reimport, um den neuen Kontext zu erhalten. |
| 2026-08-23 | Phase-7-Pathfinder-Kachelpositionen von Kamera und Viewport entkoppelt. Die bisherige freie Bildschirmseitenwahl, Randklemmung und viewportgebundene Kollisionsverschiebung ist entfernt; Kachelseite, Abstand und vertikale Ausweichposition werden nun ausschliesslich im Graphkoordinatensystem aus Knotenlage, Graphmitte und stabiler Pin-Reihenfolge bestimmt. Beim Ein-/Ausklappen der Hauptsidebar verschieben sich daher Punkt und Kachel nur noch gemeinsam als Graph, ohne dass die Kachel zum Panelrand rutscht. Dummy-Browserpruefung mit zwei Maester/Intune-Findings: Graphflaeche beim Sidebar-Wechsel von 1670,89 auf 1888,88 px verbreitert und um 217,98 px verschoben, beide Kacheltransformationen blieben bytegleich und beide relativen Punktabstaende bis auf unter 0,001 px Rundungsdifferenz identisch. Drei fokussierte Tests sowie 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot; der Produktionsbuild ist weiterhin durch parallele, fachfremde TypeScript-Fehler in `tests/persistence/assessor-repository.test.ts` blockiert. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Badges korrigiert: Die starre halbe Spaltenbreite und der feste 40-px-Badgebereich entfallen. Status-, Kategorie- und Severity-Labels verwenden innerhalb der unveraenderten 240-mal-176-px-Findingkachel nun den kompakten 11-px-Standardtoken `--fs-micro`, ihre tatsaechliche Inhaltsbreite und bei Bedarf weitere Zeilen in den vorhandenen freien Raum nach unten; der 16-px-Findingtitel bleibt unveraendert. Dummy-Browserpruefung an beiden `Maester/Intune`-Findings bestaetigt vollstaendige Labels `Failed`, `Maester/Intune` und `Medium`, jeweils `scrollWidth <= clientWidth`, innerhalb der Kachel und mit unveraenderter Kachelgroesse. Neun fokussierte Tests sowie 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot; der Produktionsbuild ist aktuell durch parallele, fachfremde TypeScript-Fehler in `tests/persistence/assessor-repository.test.ts` blockiert. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Verbindliche Processing-Version-Nachhärtung für Phasen 5/6/8/9/12/13A umgesetzt: getrennte Profil-, Mapping-, Normalisierungs- und Darstellungsstände, append-only Kompatibilitätsmanifest, kanonischer Kompatibilitätsschlüssel, Import-/Repository-Barrieren, fail-closed Vergleich und sichtbarer Readiness-Status. PingCastle 1.2.0 persistiert nun korrekt Profil 1.2.0 bei weiterhin fachlichem Mapping/Normalisierung 1.1.0; technische Einzelstände bleiben in der Result-DB-Provenienz, die doppelten Hauptfilter entfallen zugunsten von Processing Status. Historische Daten wurden nicht umgeschrieben. 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests übersprungen, Local-only und vollständiger Client-/Serverbuild erfolgreich. Der bekannte Designcheck bleibt ausschließlich an den vorbestehenden Schattenregeln in `datahub-redesign.css` 39/42 rot; keine reale PostgreSQL- oder Reimportmutation ausgeführt. |
| 2026-08-23 | Pathfinder-Kacheln in eine eigene oberste SVG-Ebene verschoben und ihre Mehrfachplatzierung abgesichert. Karten waehlen automatisch die raeumlich groessere Punktseite, halten etwa 15 px Bildschirmabstand, werden innerhalb der Graphflaeche geklemmt und bei Kollisionen abwechselnd vertikal versetzt. Der Kachelinhalt besitzt feste Titel-, Zwei-Zeilen-Badge- und Aktionsbereiche; bei mehr als vier Badges bleiben Status sowie fachlich wichtige Werte sichtbar und der Rest erscheint als `+N`. Dummy-Browserpruefung mit sieben gleichzeitig gepinnten CIS-Findings: Ebenenfolge Kanten, Knoten, Karten; null Kartenueberschneidungen, null Randverletzungen, alle Karten links oder rechts ihres Punkts, vier sichtbare vollstaendige Badges in zwei Zeilen und kein abgeschnittenes Kindelement. Neun fokussierte Tests, der Gesamtlauf mit 673 bestandenen und 8 uebersprungenen Tests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Der bekannte Designcheck bleibt nur an `datahub-redesign.css` 39/42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Pathfinder-Kachel anhand der expliziten Positiv-/Negativbildreferenz neu festgelegt: Finding-Kachel als vollstaendige 240-mal-176-px-Vorlage mit fuenf Titelzeilen, Status, Gewicht, CIS-Hierarchie-Badges, Bookmark und Results; Rollenkachel bleibt eine eigene 148-mal-72-px-Vorlage. Beide werden mit einem unveraenderlichen Faktor 0,4 in Graphkoordinaten eingebettet und zoomen danach als geschlossene Komposition. Die zwischenzeitliche 148-mal-72-px-Findingverdichtung und das Auslassen der CIS-Badges sind damit ersetzt. Dummy-Browserpruefung am Finding `18.10.18.3`: auf der Referenzzoomstufe rund 211 mal 154 px, fuenf Badges, zwei Aktionen und null ausserhalb liegende Kindelemente; ein Zoomschritt skaliert Flaeche, Titel, Badgebereich und Aktion jeweils exakt mit Faktor 1,2. Acht fokussierte Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 671 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Textuelle Verbindungsanzeige im gesamten Bereichsheader durch zwei kompakte quadratische Zustandsfelder ersetzt und direkt vor den Clientnamen gesetzt. Gruen markiert die bestaetigte Serververbindung, Rot fehlende beziehungsweise noch ungepruefte Verbindung; der inaktive Gegenstatus ist gedimmt. Pillenrahmen und sichtbare Texte wie `Server connected` entfallen, ARIA-Label und Tooltip bleiben semantisch. Dummy-Browsermessung bestaetigt genau eine Anzeige, zwei randlose 9-mal-9-px-Quadrate, voll sichtbares Gruen bei bestehender Verbindung, gedimmtes Rot sowie die direkte Geschwisterreihenfolge vor `Dummy`. Fuenf fokussierte Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 671 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kachelzoom abschliessend auf eine eingefrorene 148-mal-72-px-Komposition umgestellt: Die zuvor eingefuehrte inverse Inhaltskompensation ist entfernt; Kachelflaeche, 16-px-Titel, Hexagon, Status, Gewicht, Aktionen, Abstaende und Konturen zoomen nun gemeinsam wie ein Bild. Redundante CIS-Hierarchie-Badges bleiben in Work und am Finding sichtbar, entfallen aber in der Pathfinder-Kachel zugunsten der bereits verbunden dargestellten CIS-Kategorie-Knoten. Dummy-Browserpruefung fuer `CIS 18.9.29`: keine gerenderten Kindelemente ausserhalb der Kachel, logische Masse konstant 144 mal 68 px innen und nach einem Zoomschritt identische Bildschirm-Skalierung von Kachel, Titel und Symbol mit Faktor 0,8333 bei `transform: none`. 669 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Work-Abstand als verbindlichen Designstandard fuer alle abgerundeten Hauptpanels festgeschrieben: neuer kanonischer Token `--panel-content-inset: 20px` mit bestehendem Alias `--panel-inset`, genau einmal je Root-Inhaltscontainer. Work-Varianten, Datahub, Dashboard, DB Structure, Result DB, Client-Detail und Pathfinder angeglichen; abweichende responsive Reduktionen entfernt. `AGENTS.md` schreibt denselben Wert und die Einmal-Regel auch fuer kuenftige Panels vor. Acht fokussierte Tests, 669 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Pathfinder-Kacheltypografie auf die tatsaechlich sichtbare Groesse der 16-px-Punktbeschriftung korrigiert. Finding- und Rollenkacheln erhalten den inversen Kamerafaktor; Titel, Hexagone, Aktionssymbole, Badges, Abstaende und Konturen bleiben dadurch beim Hineinzoomen kompakt, waehrend die 148-mal-72-px-Kachelflaeche weiterhin proportional mit dem Graphen zoomt. Drei fokussierte Tests, 666 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Aktiven Clientnamen in alle Bereichs-Header aufgenommen: rechtsbuendiger reiner 16-px-Text mit Randabstand, ohne Rahmen oder Hintergrund und bei Platzmangel mit Ellipsis. Work integriert ihn neben der Werkzeugleiste; die anderen Bereiche fuehren ihn als letztes Kopfelement. Der Data-Hub-Detailkopf verwendet auch ohne geladenen Workkontext den konkret verwalteten Clientnamen und faellt nach Verlassen auf den aktiven Client zurueck. Drei fokussierte Tests, 666 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kacheln vereinheitlicht: Finding-Kacheln von 240 mal 176 px auf die 148 mal 72 px der Rollenkachel reduziert und ihre Matrixstruktur Pathfinder-spezifisch verdichtet. Titel in Finding- und Rollenkacheln verwenden nun exakt die 16 px der Textbeschriftung neben den Punkten; die regulaere Matrixansicht bleibt unveraendert. Drei fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Rollenkacheln im Pathfinder von 116 auf 148 px verbreitert und erzwungene Umbrueche innerhalb einzelner Woerter entfernt. Kurze Kategorien wie `Anomalies` bleiben zusammen; lange mehrteilige Titel duerfen weiter an Wortgrenzen innerhalb der bestehenden Zeilenbegrenzung umbrechen. Drei fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Path-Snapshot-Auswahl in Work auf einen separaten temporaeren Finding-ID-Scope umgestellt: Die Auswahl bleibt in Work und zeigt nur die im Pfad enthaltenen Findings, ohne Workspace oder Reviews zu mutieren. Der Pathfinder bleibt ausserhalb seines Bereichs verborgen montiert und bewahrt Kamera, Pins, Auswahl, Kacheln und Anzeigeoptionen; ein Refit erfolgt nur nach einer geaenderten Graphsignatur. Dummy-Browserpruefung bestaetigt `Shown 1` sowie eine exakt unveraenderte Kameratransformation, einen aktiven Punkt und eine sichtbare Kachel nach `Open in Work` und Rueckkehr; QA-Snapshot entfernt und Work auf `Shown 453` zurueckgesetzt. 19 fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Fachdatenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Kacheln nach erneuter Nutzerkorrektur proportional an den Graphzoom gebunden und nicht mehr invers bildschirmstabil gehalten. Finding- und Rollenkacheln schrumpfen bei minimalem Zoom mit dem Netz; die Finding-Grundhoehe steigt von 144 auf 176 px, damit die wiederverwendete Matrixkachel keine untere Badgezeile abschneidet. Dummy-Browsermessung: Fit rund 85,72 mal 62,86 px, `scrollHeight = clientHeight` und damit kein interner Beschnitt; bei Zoomminimum rund 19,20 mal 14,08 px. Auswahl und Zoom danach zurueckgesetzt. Drei fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Strukturknoten im Pathfinder einheitlich violett dargestellt: Kategorie-, D3FEND-, Target-, Technik- und Taktikpunkte samt Ring und optionaler Rollenkachel verwenden in Dark und Light exakt `#9333EA`; Finding-Punkte behalten ihre Severity-Farbe. Dummy-Browsermessung bestaetigt `rgb(147, 51, 234)` an 160 Kategorien, sechs D3FEND-Knoten, einem Target und sechs Taktiken sowie weiterhin Critical-Rot am Finding; im aktuellen Stand gab es keine Technik-Knoten. Drei fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Kopf um eine dynamische aktive Filterspur ergaenzt: Bei mindestens einem Nutzerfilter steht rechts neben dem Titel ein gelbes Rechtsdreieck, danach Filtername und Auswahl; mehrere Filter trennt ein gelbes Plus. Suche, sichtbare Facetten, Mehrfachwerte, Wertebereiche und My Workspace stammen direkt aus dem gemeinsamen Filterzustand. Fester Deviation-Scope und ausgeblendete technische Facetten bleiben aus der Spur heraus; ohne Auswahl ist sie unsichtbar. Dummy-Browserpruefung bestaetigt `Severity: Critical + Category: Account Security`, gelbe Marker `rgb(217, 150, 42)`, rund 18 px Titelabstand und den leeren Zustand nach Reset. Sieben fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Darstellung in zwei unabhaengige Schalter getrennt: `Labels On/Off` blendet ausschliesslich die Kacheln gepinnter Knoten ein beziehungsweise aus; der neue benachbarte Schalter `Text On/Off` steuert die Punktbeschriftungen und startet standardmaessig auf `Off`. Labels starten auf `On`. Dummy-Browserpruefung bestaetigt beide Defaults, null initiale Punkttexte, eine Kachel nach Auswahl, null Kacheln nach `Labels Off` und 626 Texte nach `Text On`; danach wurden die Defaults wiederhergestellt. Drei fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Quellenwahl auf den gemeinsamen Work-Filter umgestellt: Der technische Quellblatt-Selector und seine `Source`-Beschriftung entfallen; `Source: Scan` ist als vorhandene dynamische Facette mit Scanner, Scanzeitpunkt und Trefferzahlen sichtbar. Gemeinsamer AppProvider-Zustand, Filterengine und Reset bleiben unveraendert. Dummy-Browserpruefung: genau eine Source-Scan-Facette, fuenf Optionen, keine separate Blatt-Combobox; eine Auswahl reduziert den Graphen von 626 auf 466 Knoten und wurde danach auf `All` zurueckgesetzt. Zwoelf fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphbereich sichtbar in `Pathfinder` umbenannt: Sidebar-Navigation und grosse Bereichsueberschrift verwenden denselben Namen; der interne `graph`-Schluessel und damit Navigation, Styles, Path Snapshots und Zustand bleiben unveraendert. Dummy-Browserpruefung bestaetigt genau einen Pathfinder-Navigationseintrag, keine alte Graph-Beschriftung, die Pathfinder-Ueberschrift und den weiterhin gerenderten Netzwerkgraphen. Zwei fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-CIS-CAT-Results semantisch eingefaerbt: `Criterion`-Zeilen zeigen die konkrete Bestehens-/Sollbedingung gruen; die vom CIS-CAT-Bericht als ausgewertet markierten Istwerte erscheinen als Verstoss rot statt blau. Der bestehende Informationshinweis fuer nicht gefundene Systemelemente bleibt blau. Die CIS-spezifische Erkennung liegt deklarativ im Toolprofil, die gemeinsame Results-Komponente rendert nur `criterion`, `violation` oder `highlight`; Quellwerte und Importmarker bleiben erhalten. Dummy-Browsermessung: Dark Criterion `rgb(23,107,70)`, Verstoss `rgb(152,27,55)`; Light Criterion `rgb(203,239,217)`, Verstoss `rgb(255,212,219)`. 47 fokussierte Tests, 660 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Path-Snapshots umgesetzt: Die Graph-Aktion heisst `Path Snapshot`, bleibt ohne gepinnten Knoten deaktiviert und speichert alle gepinnten Punkte plus ihre direkten Nachbarn. Mehrfachauswahl markiert die inzidenten Kanten aller aktiven Punkte rot. Normale und Path Snapshots teilen im vorhandenen Client-/Timeslot-Scope maximal sieben Plaetze; Path-Eintraege sind in Work rot umrandet. Ein Klick aus Work wendet den gespeicherten View an, wechselt in den Graphen und restauriert die noch vorhandenen aktiven Knoten. Browserpruefung im Dummy bestaetigt Buttonzustand, einen gespeicherten Pfad mit acht roten Direktkanten, rote Work-Kennzeichnung und vollstaendige Wiederherstellung; der temporaere QA-Eintrag wurde entfernt. Elf fokussierte Tests, 658 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Backend- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graph-Panel um die wieder angeforderte Work-Bedienung ergaenzt: Unter den fachlichen Filtern steht `My Workspace` als Checkbox mit demselben `actionOnly`-/Reviewzustand wie Work; ohne markierte Findings ist sie deaktiviert. Direkt darunter rendert der Graph den bestehenden `ViewBookmarks`-Baustein fuer client- und timeslotgebundene Ansichts-Snapshots, ohne zweite Speicher- oder Anwendungslogik. Browserpruefung im Dummy bestaetigt beide Controls sowie Oeffnen und Abbrechen des Snapshot-Dialogs ohne Testartefakt. Sieben fokussierte Tests, 656 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-CIS-CAT-Hierarchie durchgaengig ergaenzt: Eine gemeinsame profilgebundene Ableitung liest zuerst `Rule ID`, ersatzweise `Benchmark Item` beziehungsweise Titel, und erzeugt aus einer Regel wie `17.2.4` ausschliesslich ihre Eltern `CIS 17` und `CIS 17.2`. Diese Kategorien bilden ringmarkierte Graphbeziehungen, stehen als dynamischer `CIS Category`-Filter zur Verfuegung und erscheinen als Badges im Finding-Kopf sowie auf Matrix-/Graphkacheln. Originalnummer, Originaltitel, Quellwerte und Persistenz bleiben unveraendert. Dummy-CIS-CAT-Browserpruefung: 143 Hierarchieknoten; sichtbarer Filter mit positiven Zaehlern; `CIS 17.2` reduziert den Deviation-Graphen auf vier Findings; Finding `2.2.2` zeigt `CIS 2` und `CIS 2.2`. 36 fokussierte Tests, 656 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphprojektion fachlich auf Abweichungen begrenzt: Der Graph verwendet unabhaengig vom geteilten Work-Status ausschliesslich `deviation`; der dadurch gegenstandslose Result-Status-Selector ist im Graph ausgeblendet. Der bisherige Kategorienfallback vom fehlenden Category-Feld auf `sourceSheet` ist entfernt, sodass Mandant, Quellblatt und `Dummy · All Records` nur Filterkontext bleiben und weder Sammelknoten noch Massenkanten erzeugen. Kategorien, ATT&CK und D3FEND stammen weiterhin aus den Finding-Feldern; explizite Target-/Asset-/Host-/Domain-Felder werden neu als eigene ringmarkierte Target-Beziehungsknoten projiziert. Dummy-Browserpruefung im Aggregat `Dummy · All Records · 885`: null All-Records-Knoten, 453 Deviation-Findings, ein expliziter Target-Knoten und kein Status-Control im Graph. 16 fokussierte Tests, 653 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Zoomverhalten der Graphkacheln auf ausdruecklichen Nutzerwunsch erneut korrigiert und die unmittelbar vorherige proportionale Skalierungsentscheidung fuer Kacheln ersetzt: Finding-Kacheln verwenden nun wie Punktlabels eine inverse Kameraskalierung. Damit bleiben die kompakte Matrixkachel mit 240 mal 144 px und ihr 16-px-Titel bei jeder Graph-Zoomstufe visuell konstant, waehrend Knoten, Kanten und Kartenposition weiterhin mit der Kamera reagieren. Dummy-Browsermessung bestaetigt eingepasst 239,98 mal 144,00 px und auf maximaler Zoomstufe 239,98 mal 144,00 px bei jeweils 16 px Titeltext. Sieben fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln nach Nutzerkorrektur verdichtet und auf Klick begrenzt: Finding- und Rollenkarten erscheinen nicht mehr beim Hover, sondern ausschliesslich bei einem gepinnten Knoten. Die weiterhin direkt wiederverwendete Matrix-`TileCard` besitzt im Graphen eine kompakte 240-mal-144-Grundeinheit mit engeren Abstaenden und Aktionen; der inhaltstragende Titel bleibt 16 px gross und die gesamte Kachel skaliert weiterhin proportional mit dem Kamerazoom. Dummy-Browserpruefung bestaetigt null Kacheln vor und nach Hover, genau eine Kachel nach Klick, eine eingepasste Darstellung von rund 100 mal 60 px sowie Breiten- und Hoehenfaktor 1,2 bei einem Zoomschritt. Sieben fokussierte Tests, 652 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Rollenknoten visuell von Findings getrennt: Category, D3FEND, Technique und Tactic erhalten einen farbgleichen transparenten Aussenring; Findings bleiben ringlos und tragen weiterhin ausschliesslich ihre Severity-Farbe. Hover und Pin verstaerken beziehungsweise markieren Ring und Kern gemeinsam. Dummy-Browserpruefung bestaetigt 17 Ringe auf 17 strukturellen Knoten und null Ringe auf 20 Findings. Drei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Finding-Vorschau auf die Originalkachel des Matrixbereichs umgestellt: Der Graph rendert fuer Findings direkt `TileCard` statt der verkleinerten Nachbildung. Vollstaendiger Titel, Severity-Hexagon, Outcome, Badges, Bookmark und Results-Aktion bleiben erhalten; die Kachel skaliert im Graph-Koordinatensystem proportional mit Zoom, waehrend Rollen-Vorschauen weiterhin zoomstabil bleiben. Dummy-Browsermessung bestaetigt Originaltitel, zwei Kachelaktionen sowie beim Zoomfaktor 1,2 Breiten- und Hoehenverhaeltnis jeweils 1,2. Sieben fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphlegende auf Nutzerwunsch vollstaendig entfernt: Der unten links eingeblendete Block fuer Finding, Category, D3FEND, Technique und Tactic sowie seine gesamten CSS-Regeln entfallen. Knotenfarben, Severity-Semantik, direkte rote Pfade und Interaktionen bleiben unveraendert. Drei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Graphfarben und direkte Pfade nachgeschaerft: Finding-Punkte tragen Critical-, High-, Medium-, Low- oder Info-Farbe aus der bestehenden Produktskala; `unknown` verwendet einen eigenen neutralblauen Token und kein Grau. Der fruehere zusaetzliche Hochrisiko-Marker entfaellt. Hover oder Pin faerbt ausschliesslich alle direkt inzidenten Kanten des aktiven Knotens rot und hebt sie mit 2 px hervor. Dummy-Browserpruefung: 20 Severity-gefaerbte Findings (6/7/3/2/2) und bei `Lateral Movement` exakt drei rote direkte Pfade. Sieben fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz-, Schema- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphprojektion und Darstellung nach der Nutzerreferenz korrigiert: Kategorien und D3FEND werden als eigene Beziehungsknoten gezeigt; Findings ohne Technik-ID verbinden sich mit jeder vorhandenen ATT&CK-Taktik statt nur mit `primaryTactic`. Der Dummy-PurpleKnight-Stand zeigt damit 20 Findings als 37 Knoten und 61 Links (20 Kategorie, 30 ATT&CK, 11 D3FEND); `Lateral Movement` besitzt drei direkte Findingbeziehungen. Gelbe Findingpunkte wurden durch eine ruhige Grau-/Blau-/Blaugruen-Palette mit rotem Hochrisikomarker ersetzt, das Layout deutlich aufgezogen und alle Labels standardmaessig als zoomstabile, praesentativ gekuerzte 16-px-Texte kollisionsfrei platziert. Browserpruefung bestaetigt 37 von 37 sichtbare Knoten, null Labelueberschneidungen sowie weiterhin sichtbare Filter bei minimierter Sidebar. Sieben fokussierte Tests und der vollstaendige Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 652 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz-, Schema- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graph-Panel vom Navigationszustand entkoppelt: Die Collapse- und Mobile-Sichtbarkeitsregeln zielen nur noch auf das direkte Hauptnavigations-`aside`, nicht auf verschachtelte Filter- oder Inspektorbereiche. Graph-Filter und Details bleiben deshalb bei minimierter Sidebar sichtbar. Fokussierter Graph-Test, 650 Standardtests, Local-only und Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Designcheck unveraendert nur wegen `datahub-redesign.css` 39/42 rot; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Graph-Panel reduziert: `Result message`, `SI version`, `Source: Scan` und `My Workspace only` aus der linken Graph-Filteranzeige entfernt. Die uebrigen gemeinsamen Controls und die auf `useFilteredRecords()` beruhende Filtersemantik bleiben unveraendert; in Work gesetzte Filter wirken weiterhin. Graph-Test, 650 Standardtests, Local-only sowie Client-/Server-Produktionsbuild erfolgreich, 8 optionale PostgreSQL-Tests uebersprungen. Designcheck unveraendert nur wegen `datahub-redesign.css` 39/42 rot; keine Import-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Timeslot-Scope fail closed gehaertet: `All timeslots` aus dem Work-Selector entfernt und ohne gesetzten Scope automatisch den neuesten konkreten Timeslot geladen. Result DB fragt ohne aktive ScanRun-Menge nicht mehr den gesamten Client ab; der Graph baut in diesem Zustand ebenfalls keine Aggregatprojektion. Datenaktualisierungen des aktiven Clients bewahren den Scope. Sechs fokussierte Suites mit 21 Tests, 650 Standardtests, Local-only und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Facetten appweit auf erreichbare Werte begrenzt: Work- und Result-DB-Filter zeigen unter aktivem Client, Timeslot, Blatt, Suche und Fremdfiltern nur Optionen mit mehr als null Treffern. Die eigene Facette bleibt bei der Alternativzaehlung ausgenommen; unmoeglich gewordene Work- und Statusauswahlen werden automatisch bereinigt. 22 fokussierte und 650 Standardtests, Local-only sowie Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Radiusbudget nach vorheriger Kartenreduktion von 5 auf 4 gesenkt; Designcheck bleibt nur an zwei bekannten Schattenregeln rot. Keine API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-DataHub-Clientkarten um eine direkte gelbe `Open`-Aktion unten rechts erweitert. Sie oeffnet den neuesten scannergebundenen Timeslot samt exakter ScanRun-Menge unmittelbar in Work; `Manage` bleibt oben rechts fuer Clientdaten und Timeslotverwaltung. Ohne Scan-Daten ist Open sichtbar deaktiviert. Vier fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-Importvorschau kosmetisch reduziert: Umrandete Dateikarten, Kartenhintergrund und Statuspills entfernt; Eintraege sind nun flache, optional durch Haarlinien getrennte Abschnitte. Exakte und moegliche Dubletten erscheinen als englischer `Duplicate found`-Hinweis mit mindestens 16 px grossem Fliesstext. Lange Dateinamen, Hashes und Quellen umbrechen, horizontaler Listen-Scroll entfaellt. Checkbox, Mappingbestaetigung sowie Cancel/Import selection bleiben unveraendert. Sechs fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-Result-DB an den aktiven Timeslot gebunden: App und ResultsBrowser geben die aktuell geladenen ScanRun-IDs an Treffer- und Facettenabfragen weiter; der additive Unified-Result-Queryparameter `scanRunIds` wird als wiederholter URL-Wert geparst und in Local- sowie PostgreSQL-Persistenz angewendet. `All timeslots` bleibt der ausdrueckliche projektweite Aggregatmodus. 22 fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; Gesamtsuite 647 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only gruen. Der globale Designcheck bleibt nur an zwei unveraenderten Schattenregeln rot. Keine Migration oder Realdatenpruefung. |
| 2026-08-22 | Phase-7-Work-Zustand pro Timeslot getrennt: Snapshot-Lesezeichen und My-Workspace-/Review-Markierungen verwenden nun einen stabilen Client-plus-ScanRun-Scope. Timeslot- und Blattwechsel laden die Statusfilterdefaults des tatsaechlich aktiven Toolprofils und leeren alte Facetten. Gemischte Aggregate vereinigen die Statusfilter aller enthaltenen bekannten Profile, Einzelblaetter bleiben exakt Maester, PingCastle, Purple Knight oder CIS-CAT zugeordnet. 24 fokussierte Tests erfolgreich. Produktionsbuild unabhaengig durch bereits vorhandene fehlende Graph-Filtervariablen in `ObsidianGraphView.tsx` blockiert; keine API-, Backend-, Persistenzschema- oder Datenbankaenderung. |
| 2026-08-22 | Phase-7-Importfortschritt visuell korrigiert: Der rotierende Kreis im Fortschritts-Pop-up wurde durch vier kleine Quadrate auf einer gedachten Kreisbahn ersetzt; jeweils ein rotes Quadrat wird im Uhrzeigersinn weitergeschaltet. Der Status bleibt textlich zugaenglich, Reduced Motion zeigt einen statischen Zustand. Fuenf fokussierte Tests und Client-/Serverbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Aktionszustand sicherer gemacht: Sobald Stammdaten editiert werden, verschwindet `Delete client` gemeinsam mit Edit vollstaendig und nur der gelbe Save-Button bleibt an derselben Position. Edit, Save und Delete verwenden identische 96-px-Mindestbreiten, sodass der Wechsel keinen Groessensprung erzeugt. Drei fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine Delete-, Save-, API-, Persistenz- oder Schemafachlogik veraendert. |
| 2026-08-22 | Phase-7-Work-Kopf um eine direkte Timeslot-Auswahl rechts neben der bestehenden Client-/Blattauswahl erweitert. `All timeslots` laedt weiterhin den gesamten Mandanten; ein Stichtag uebergibt nur dessen persistierte ScanRun-IDs an den vorhandenen `openProject`-Pfad. Optionen stammen aus Assessment-Historie und Importdateiliste der Same-Origin-API und aktualisieren sich nach Datahub-Aenderungen. Drei fokussierte UI-Tests, Local-only und Client-/Serverbuild erfolgreich. Gesamtlauf: 639 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, ein unabhaengiger Result-Fenster-Test einmal rot und anschliessend isoliert mit 16 von 16 gruen. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, Mapping-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Maximaltabellen kompakter ausgerichtet: Vor einer manuellen Anpassung verwenden maximierte Result-Tabellen ihre ungebrochene intrinsische Inhaltsbreite statt die volle Fensterbreite. Echte Ueberbreite bleibt horizontal scrollbar; nach Nutzeranpassung gilt unveraendert die explizite Spaltenbreite. Zwei fokussierte Suites mit 27 Tests und Gesamtlauf mit 642 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Result-Spaltenbreiten auf alle frei stehenden Fenster erweitert: Herausgezogene, normal grosse, manuell skalierte und maximierte Results besitzen die bestehenden Spaltengriffe, Auto-Fit und Tastaturbedienung. Nur das weiterhin im Findings-Cluster eingereihte aktive Result und minimierte Slots bleiben unveraenderbar. Drei fokussierte Suites mit 32 Tests und Gesamtlauf mit 640 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Aktionen nach Nutzerreferenz neu geordnet: `Open` steht oben rechts im linken Timeslot-Navigatorkopf. Rechts folgen `Delete client` und der gelbe `Edit`-Textbutton; waehrend der Bearbeitung ersetzt `Save` den Edit-Button. Bleistift und separater Delete-Footer sind entfernt, bestaetigungspflichtiges Delete sowie Open-/Save-Fachlogik bleiben unveraendert. Vier fokussierte UI-Tests und Gesamtlauf mit 639 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Fachlogik-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Work-Kopf gegen abgeschnittene Controls nachgeschaerft: `My Workspace` bleibt mit 112 px Mindestbreite einzeilig; View-Tabs, Actionlist-Exportgruppe und direkte Toolbar-Aktionen schrumpfen nicht mehr und behalten ihre sichtbaren Kanten. Bei echter Unterbreite ist die Werkzeugzeile horizontal erreichbar statt verdeckt. Die toolabhaengige Filterableitung bleibt unveraendert. Zwei fokussierte Layouttests und Gesamtlauf mit 639 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Filter-, Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Result-Tabellen um Excel-artige Spaltenbreiten ergaenzt: Im maximierten Fenster erscheinen fokussierbare Separatoren zwischen Kopfzellen. Ziehen veraendert die linke Spalte, Doppelklick/Enter passt sie an den laengsten ungebrochenen Inhalt an; Pfeiltasten aendern um 16 px. Breiten bleiben lokaler UI-Zustand, sind auf 72 bis 720 px begrenzt und nutzen bei Ueberbreite den bestehenden Horizontal-Scroll. Direkte Ergebnisblaetter und Markdown-Tabellen verwenden denselben React-Baustein; normale Fenster bleiben unveraendert. Drei fokussierte Suites mit 28 Tests und Gesamtlauf mit 637 bestandenen Tests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Graphansicht nach Nutzerreferenz als ruhiges Dreispaltenlayout umgesetzt: gemeinsame fachliche Filter links, kompakter Netzwerkgraph mittig und permanenter Detailinspektor rechts. Work und Graph teilen Suche, Quellblatt, Status, dynamische Facetten und Workspace-Einschraenkung bidirektional ueber den bestehenden AppProvider; lokale Graphfilter entfallen. Zwei fokussierte synthetische Graph-Tests und 647 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen; Local-only und separater Client-Bundlebuild erfolgreich. Baseline-Build derzeit nur durch den vorbestehenden fremden TypeScript-Fehler in `server/assessor-http-server.ts` Zeile 196 blockiert; bekannter Designcheck-Befund unveraendert `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Remarks-Editor auf Langtextnutzung ausgerichtet: Das Textarea belegt nun 100 Prozent der Client-Dokumentbreite, verwendet 10 statt 5 Zeilen und eine von vier auf acht 32-px-Rastereinheiten verdoppelte Mindesthoehe; vertikale Nutzeranpassung bleibt aktiv. Name und Consultant bleiben einzeilig. Fokussierter Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-ScanRun-Tabelle fuer die schmale Clientnavigation nachgeschaerft: Scannername bleibt 16 px, Datei-/Format-Metazeile wird kompakter. Die Scan-Spalte erhaelt eine kontrollierte Mindestbreite, Imported waechst von 104 auf 136 px und beginnt dadurch weiter links, damit Datum und Uhrzeit nicht vorzeitig abgeschnitten werden. Status und Delete bleiben unveraendert. Fokussierter Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Timeslotstandard korrigiert: Beim Oeffnen einer Client-Ansicht sind alle Timeslots eingeklappt. Der neueste Timeslot bleibt wie zuvor vorausgewaehlt; nur dessen Detailtabelle wird nicht automatisch geoeffnet. Manuelles Aufklappen und alle bestehenden Aktionen bleiben unveraendert. Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild sind erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Delete vereinheitlicht: Die rechte Aktion ist nun ausdruecklich ein umrandeter destruktiver Textbutton `Delete client` mit fester Buttonbreite; Papierkorb, SVG, Bild- und Iconpfad entfallen vollstaendig. Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild sind erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Neueste Phase-7-Nutzerkorrektur umgesetzt und die unmittelbar vorherige Namensentdoppelung ausdruecklich abgeloest: Rechts stehen wieder Name, Consultant und Remarks als drei vertikale Dokumentabschnitte. Jede 14-px-Bezeichnung steht direkt ueber ihrem linksbuendigen 16-px-Wert; die linke Identitaet bleibt statisch. Zwei fokussierte Suites mit 4 Tests erfolgreich. Inhaltsarme Browsergeometrie bestaetigt fuer alle drei Paare gleiche linke Kante, Wert unter Label, 14/16 px und linke Ausrichtung. Gesamtlauf: 634 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only erfolgreich. Der bekannte Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` 39/42 rot. Client-/Serverbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Reader entdoppelt: Name erscheint nur links oberhalb der Timeslots; rechts verbleiben Consultant und Remarks. In Create/Edit wird der linke Titel zum erforderlichen, dem bestehenden `tenant-editor-form` zugeordneten Namensfeld, sodass Save unveraendert bleibt. Zwei fokussierte Suites mit 4 Tests, 634 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt zwei rechte Abschnitte, null rechte Namenslabel sowie linken Titel/Editinput und Save. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Shelltitel an den Data-Hub-Kontext gebunden: Hauptansicht zeigt `Data Hub`, Client-Neuanlage und -Detail zeigen `Client`; Back und Bereichswechsel setzen auf `Data Hub` zurueck. Fokustest, 634 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt Data Hub -> Client -> Data Hub ohne Inhaltszugriff. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7/12-Timeslot-Scans an der Baseline-Tabelle ausgerichtet: fuenf kompakte Spalten fuer Auswahl, Scan, Imported, Status und Actions; Size entfaellt. Readiness verwendet die bestehende Work-Grenze aus persistiertem Run und kanonischen Occurrences: Recognized, Generic, Not viewable sowie technisch getrennt Unavailable/Checking. Nicht darstellbare Runs sind nicht auswaehlbar und werden vor Open aus der Einzel-/Mehrfachprojektion entfernt. ScanRun- und Mandanten-Delete verwenden ausgeschriebene Buttons; kein Delete-Papierkorb verbleibt. Zwei fokussierte Suites mit 5 Tests und 633 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung: fuenf Spalten, kein Overflow, vier recognized, vier Text-Deletes, null Delete-SVG/Papierkorbpfade. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Mandantendetail nach den drei Nutzerreferenzen final korrigiert: Die verbliebene zweispaltige Formular-Altregel ist im Detail auf ein einspaltiges Readerlayout begrenzt. Name, Consultant und Remarks sind im Lesemodus echte vertikale Dokumentabschnitte mit neutralen Ueberschriften und 16-px-Werttext; erst Edit zeigt Inputs. Timeslot-/ScanRun-Checkboxen und Auswahlmarker sind bernsteinfarben, die Auswahlflaeche neutral statt violett. GPO- und Scanimport sind identisch gelbe Primaerbuttons, Delete bleibt neutral. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt drei vertikale Abschnitte, neutrale Label, bernsteinfarbene Auswahl und zwei gelbe Importaktionen. Bekannter Designcheck-Befund unveraendert nur in `datahub-redesign.css` Zeilen 39/42. Keine API-, Persistenz-, Schema-, Fachfunktions- oder Realdatenaenderung. |
| 2026-08-22 | Mandantendetail nach Nutzerkorrektur verdichtet: Das 44/56-Raster ist durch die exakte Work-/Reports-Listenbreite `clamp(420px, 27vw, 520px)` ersetzt. Die read-first Mandanteninformation ist eine maximal 794 px breite transparente Reader-Dokumentflaeche ohne Aussenrahmen, Karten oder Labelkaesten; Werte stehen als Fliesstext unter Abschnittsueberschriften mit feinen Trennern, Eingaberahmen erscheinen nur im Editzustand. Die Timeslotliste verwendet entsprechend flache rahmenlose Work-Eintraege. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browsermessung bestaetigt 520 px Navigator, 794 px rahmenlose Dokumentflaeche und unabhaengiges Scrollen. Der globale Designcheck bleibt ausschliesslich an den zwei dokumentierten unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema-, Fachfunktions- oder Realdatenaenderung; Phase 7/8/12-Status bleibt abgeschlossen. |
| 2026-08-22 | Mandantendetail nach der ausgewaehlten Work-/Reports-Referenz als vollflaechige 44/56-Master-Detail-Ansicht umgesetzt: links Mandantenkopf und unabhaengig scrollender Timeslot-/ScanRun-Navigator, rechts read-first Client Information mit explizitem Edit/Save, Open und getrenntem Mandanten-Delete. Persistierte Timeslots lassen sich aufklappen; ihre realen ScanRuns bleiben mit vorhandenen Metadaten, Auswahl und bestaetigungspflichtigem Delete sichtbar. Einzelne Runs koennen lokal fuer Open ausgeschlossen werden; neue Importe bleiben eingeschlossen und die sichere Mehrfach-Timeslot-Schnittmenge bleibt erhalten. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt Raster, Scrollgrenze, Controls, Scan-Abwahl und Laufzeitstabilitaet. Der globale Designcheck bleibt ausschliesslich an den bereits dokumentierten unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7/8/12-Status bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphsteuerung um einen gemeinsamen `Reset` direkt neben `Filters` erweitert. Die Aktion wird nur bei aktivem Suchtext, Kategorie-, Severity- oder Mappingfilter freigeschaltet und setzt diese vier Zustaende atomar auf ihre Defaults zurueck; `Labels` bleibt als unabhaengige Darstellungsoption unveraendert. Zwei fokussierte Graph-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung erfolgreich: initial gesperrt, nach Suche aktiv, danach Suche leer und wieder gesperrt. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphauswahl auf unabhaengige Mehrfach-Pins erweitert: Jede angeklickte Punktkachel bleibt sichtbar, weitere Knoten koennen gleichzeitig angepinnt werden und ein erneuter Klick entfernt nur die betreffende Kachel. Der Inspektor folgt dem zuletzt aktivierten Pin und wechselt beim Entfernen auf den zuletzt verbleibenden; Tastatur und Schliessen verwenden dieselbe Toggle-Semantik. Zwei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln nach Nutzerreferenz auf kleine quadratische Work-Miniaturen korrigiert: Findings verwenden die bestehende `data-tile`-Struktur mit Severity-Hexagon, zweizeiligem Inhaltstitel, normalisiertem Outcome und der vorhandenen Badge-Reihenfolge; Technik und Taktik verwenden quadratische reduzierte Rollenvarianten. Karten erscheinen standardmaessig nur bei Hover oder Auswahl, die Labelumschaltung kann alle anzeigen. Die gesamte Karte nimmt Pointerereignisse an und bleibt per Klick umschaltbar. Zwei fokussierte Graph-Tests sowie der vollstaendige Client-/Server-Produktionsbuild erfolgreich; 630 Standardtests bestanden und 8 optionale PostgreSQL-Tests wurden uebersprungen. Local-only ist gruen, der globale Designcheck bleibt ausschliesslich an den zwei bereits vorhandenen Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln um persistentes Klick-Toggle erweitert: Ein Klick pinnt die Mini-Kachel und den Detailinspektor, ein zweiter Klick auf denselben Knoten hebt die Auswahl wieder auf; Tastaturaktivierung besitzt dieselbe Semantik und `aria-pressed` macht den Zustand zugaenglich. Eine Bewegung ab 3 px gilt als Knotendrag und schaltet die Auswahl nicht versehentlich um. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphlabels nach Nutzerkorrektur als zoomstabile Mini-Kacheln umgesetzt: Findings zeigen neben ihrem Knoten eine verkleinerte Work-Kachel mit Severity-Marker, Severity-Label und zweizeiligem 16-px-Titel; Technik- und Taktikknoten verwenden reduzierte Varianten mit eigener Rollenfarbe. Die Kacheln erscheinen fuer Taktiken dauerhaft sowie fuer Findings und Techniken bei Auswahl, Hover oder aktivierter Labelansicht, skalieren nicht mit dem Graphzoom und kuerzen nur ihre Vorschau; der vollstaendige Titel bleibt im Inspektor erhalten. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphbeschriftung korrigiert: SVG-Knotentexte werden nicht mehr mit der Zoomkamera vergroessert oder verkleinert, sondern bleiben unabhaengig von Fit, Pan und Zoom konstant in der verbindlichen 16-px-Inhaltsschrift. Sehr lange Knotentitel werden nach 56 Zeichen mit Auslassungspunkt gekuerzt; der vollstaendige Titel bleibt im Detailinspektor erhalten. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Korrektur der unmittelbar folgenden Phase-7-Hintergrundausweitung auf ausdruecklichen Nutzerwunsch: Der tokenbasierte Punkthintergrund ist nun ausschliesslich an `.app-area-graph` gebunden. Datahub, Dashboard, DB Structure, Results und Work verwenden wieder ihre ungepunkteten Standardflaechen; die Dark-/Light-Anpassung fuer den Graph bleibt erhalten. Fokussierter Graph-/Hintergrundtest und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphansicht nach Nutzerreferenz vollstaendig durch einen Obsidian-aehnlichen interaktiven Netzwerkgraphen ersetzt: Findings, MITRE-Techniken und Taktiken bilden deterministisch verbundene Knoten; Zoomen am Mauszeiger, Flaechenverschiebung, Knotendragging, Auswahl/Hover, Suche, Kategorie-/Severity-/Mappingfilter, Labelumschaltung, Fit-Steuerung, Detailinspektor sowie vorhandene Work-, Results- und Workspace-Aktionen sind integriert. Die bisherige Graphkomponente und ihr Stylesheet werden nicht mehr geladen. Der gepunktete Graphhintergrund ist als tokenbasierte Standardflaeche auf Datahub, Dashboard, Graph, DB Structure und Results ausgedehnt, Work bleibt unveraendert; Lightmode besitzt eine eigene helle Punktfarbe. Fuenf fokussierte synthetische Graph-/MITRE-Tests, Client-/Server-Produktionsbuild, 630 Standardtests und Local-only-Pruefung erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Inhaltsarme Browserpruefung bestaetigt den gepunkteten Nicht-Work-Hintergrund einschliesslich Lightmode; die Graphansicht war dort mangels geladenem Datensatz bewusst nicht aktivierbar. Der globale Designcheck bleibt ausschliesslich an zwei bereits vorhandenen Schattenregeln in datahub-redesign.css rot. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-13A-PingCastle-Reader bereinigt: Das technische Feld `Verwandte Daten` einschliesslich der importdateigebundenen Sektions-ID wird in der sichtbaren Finding-Zusammenfassung und unter `Additional Information` ausgeblendet. Das Feld bleibt unveraendert im Datensatz und speist weiterhin den exakten PingCastle-Results-Linker; kein Reimport erforderlich. Zwei fokussierte Suites mit 26 bestandenen Tests bestaetigen Ausblendung und fortbestehende Verknuepfung, der Client-Produktionsbuild ist erfolgreich. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 13A bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantendetail auf Nutzerkorrektur vollstaendig linienfrei gestellt: Nach der oberen wurde nun auch die untere Trennlinie des Aktionsbereichs entfernt. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (beide Linien 0 px) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantendetail optisch bereinigt: Die obere Trennlinie zwischen Identitaetskopf und Aktionszeile wurde entfernt; die untere Linie des Aktionsbereichs bleibt unveraendert bestehen. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (oben 0 px, unten weiterhin vorhanden) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenkacheln an den Matrix-Hover angeglichen: reale Mandanten- und Plus-Kacheln wechseln bei Hover beziehungsweise Tastaturfokus auf staerkere Kontur und Hoverflaeche, erhalten den erhoehten Schatten und heben sich mit identischer 120-ms-Transition um 2 px an. `prefers-reduced-motion` unterdrueckt die Bewegung; Auswahlzustand und Aktionen bleiben unveraendert. Zwei fokussierte Datahub-Tests, Client-Produktionsbuild und inhaltsarme Browser-Stilpruefung erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Kopfzeilentypografie erneut auf die praezisierte Nutzerreferenz angeglichen: Die regulaeren Bereichsnamen verwenden nun exakt dieselben berechneten Werte wie der grosse Mandantentitel (`Dummy`-Referenz): 54 px, Gewicht 600, 62,1 px Zeilenhoehe und -2,16 px Laufweite bei aktueller Tokenbasis. Designpruefung, Client-Produktionsbuild und inhaltsarme Browser-Gleichheitspruefung erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Work-Kopf nach Nutzerreferenz angepasst: Das Freitextfeld und seine Loeschaktion verwenden nun `Search` beziehungsweise `Clear search` statt `Filter text`. Die gemeinsame Such-/Result-Dock-Gruppe wird in der unteren Kopfzeile bei regulaerer Breite exakt mittig positioniert und faellt unter 1200 px kollisionsfrei in den normalen Fluss zurueck; Bookmarks, Filterlogik und Result-Docking bleiben erhalten. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung erfolgreich: genau ein `Search`, kein altes Placeholder, Feldmitte innerhalb 4 px der Kopfzeilenmitte. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Kopfzeilentypografie auf Nutzerkorrektur praezisiert: Die zuvor eingefuehrte Grossbuchstaben-Transformation und Laufweite sind wieder entfernt. Bereichsnamen bewahren ihre normale Schreibweise wie `Datahub` und werden stattdessen zentral auf 27 px mit kompakter Zeilenhoehe vergroessert; die Regel gilt weiterhin fuer alle regulaeren Kopfpanels. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung (27 px, `text-transform: none`) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Anwendungskopf vereinheitlicht: Alle regulaeren, dort eingeblendeten Bereichsbezeichnungen werden ueber die gemeinsame `.area-topbar`-Regel in Grossbuchstaben mit dezenter Laufweite dargestellt; damit gilt die Vorgabe automatisch fuer Datahub und die weiteren Kopfpanels. Der funktionale Work-Kopf und die Sidebar-Navigation bleiben unveraendert. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung (`text-transform: uppercase`, wirksame Laufweite) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Timeslot-Typografie nach Nutzerreferenz nachgeschaerft: Die Ueberschrift verwendet nun 18 px (`--fs-xl`); die Auswahlzusammenfassung darunter ist ohne Rahmen und Innenabstand in der regulaeren 14-px-UI-Schrift (`--fs-md`) dargestellt. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (18-px-Ueberschrift, 14-px-Auswahltext, 0-px-Rahmen) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Timeslot-Bereich der Mandantenansicht mit der sichtbaren Ueberschrift `Timeslots` direkt oberhalb der Datumszeilen ergaenzt. Auswahl, geschlossener Tabellenzustand, Datumsanlage und Importlogik bleiben unveraendert. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (je eine Timeslot-Region und -Ueberschrift) erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Baselinekatalog startet auf ausdruecklichen Nutzerwunsch standardmaessig eingeklappt. Zaehler, Upload-Aktion und manuelles Aufklappen bleiben unveraendert verfuegbar. Fokussierter Datahub-Test, Client-Produktionsbuild und inhaltsarme Browserpruefung (ein Katalog, kein `open`, eine sichtbare Upload-Aktion) erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7/8/12-Timeslot-Workflow in der Mandantendetailansicht umgesetzt: `Scan History · Linked Scan Reports` ist nun eine standardmaessig geschlossene Timeslot-Tabelle mit einer Checkbox je fachlichem Assessment-Stichtag. Ein Plus oeffnet einen kleinen Datumsdialog und legt ueber die bestehende Assessment-API einen leeren, anschliessend ausgewaehlten `effectiveAt`-Timeslot an. `Open` benoetigt eine Auswahl; bei einem Stand oeffnet es dessen Scannerlaeufe, ab zwei Staenden nur die Schnittmenge sicher erkannter, in allen Staenden vorhandener Scannerwerkzeuge. GPO-Abdeckung wird separat beruecksichtigt und niemals als ScanRun modelliert; ausgeschlossene Quellen werden sichtbar genannt. Einzelne Scanberichte bleiben innerhalb der Timeslot-Zeile loeschbar. Drei fokussierte Suites mit 12 Tests und `npm test` mit 621 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt geschlossenen Default, Plus-/Datumsdialog, Abbruch ohne Anlage, Checkboxen und Open-Freigabe ohne Datenmutation. Keine neue Entitaet, Migration oder API; Phase 7, 8 und 12 bleiben abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-13B-Baselinekatalog um kontrolliertes Loeschen erweitert: Jede Zeile der an Scan History angeglichenen Tabelle besitzt nun eine Actions-Spalte mit Delete-Button und Warnungsdialog. Der neue Same-Origin-DELETE-Pfad verlangt explizite Bestaetigung, ist in API-Client und Service verdrahtet und entfernt nicht referenzierte Katalogeintraege einschliesslich Klassifikationen und Analysen in Local- und PostgreSQL-Persistenz; vorhandene Policy-Evaluationsquellen blockieren mit Konflikt. Das private Originalobjekt wird nach erfolgreichem Repository-Commit best-effort entfernt. Synthetische UI-, Client-, Service- und Persistenzregressionen ergaenzt; `npm test`: 620 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration und keine Realdatenpruefung; Phase 13B bleibt in Arbeit. |
| 2026-08-22 | Phase-7-Datahub-Geometrie beim Baseline-Expander stabilisiert: Die vertikale Scrollbar-Gutterbreite der Datahub-Ansicht wird nun dauerhaft reserviert. Beim Auf- und Zuklappen von `Imported Security Baselines` kann der Scrollbalken damit erscheinen beziehungsweise verschwinden, ohne die zentrierte Inhaltsflaeche seitlich zu verschieben. Fokussierter Datahub-Layouttest und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Zuruecknavigation der Mandantenansicht verdeutlicht: Das Richtungsdreieck wurde auf 28 px vergroessert und um den sichtbaren Text `Back` ergaenzt. Beide Elemente liegen in derselben semantischen Schaltflaeche mit gemeinsamem Klickbereich, Fokus und zugaenglichem Namen `Back to client overview`. Vier fokussierte Tests und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenkopf nach Nutzerreferenz nachgeschaerft: Die grosse einzeilige Titelbox wurde nach unten erweitert; Zeilenhoehe 1,15 und tokenbasierter unterer Innenabstand verhindern abgeschnittene Schrift beziehungsweise Unterlaengen, waehrend Ellipse, Kopfaufteilung und Aktionen unveraendert bleiben. Fokussierter Datahub-Test und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenaktionen fuer jeden bestehenden Mandanten freigegeben: `Import Data` und `GPO Backup Folder` werden nicht mehr von einer bereits vorhandenen Assessment-/Timeslot-ID ausgeblendet. Eine vorhandene Ziel-ID wird unveraendert weitergereicht; leere Mandanten nutzen den bereits bestehenden optionalen Erstimportpfad. Der fokussierte Datahub-Test prueft die entfernte Sperre. Eine inhaltsarme Browserpruefung bestaetigt beide Aktionen jeweils genau einmal in allen zwei vorhandenen Mandantenansichten, ohne Upload oder Datenmutation. `npm test`: 620 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, Importlogik-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7-Mandantenstammdaten gegen versehentliche Aenderungen abgesichert: Bestehende Mandanten zeigen Name, Consultant und Remarks zunaechst schreibgeschuetzt. Ein zugaenglich beschrifteter, rahmenloser Stift unmittelbar hinter `Master Data · Client Data` aktiviert als einzige UI-Aktion die Bearbeitung und blendet erst dann `Save` ein; der Submit-Handler weist Speicherversuche ohne aktiven Bearbeitungsmodus ebenfalls ab. Neuanlagen sind sofort editierbar, nach erfolgreichem Speichern oder Verlassen wird wieder gesperrt. Zwei fokussierte Suites mit vier Tests und der Gesamtlauf mit 620 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Die anschliessende Platzierungsnachschaerfung ist mit zwei fokussierten Tests und Client-Build verifiziert. Inhaltsarme Browserpruefung bestaetigt Read-only-/Edit-Zustand, Stiftschalter, bedingte Speicheraktion und Rueckkehr ohne Speichern. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7-Datahub-Uebersicht nach Nutzerreferenz neu geordnet: Die sechs bestehenden Statusdiagramme stehen oben. Darunter werden ausschliesslich persistierte Mandanten als diagrammlose Karten im verbindlichen Donut-Kacheldesign sowie genau eine dezente Plus-Karte angezeigt; die frueheren acht Spalten, `Empty`-Slots und Timeslotzeilen sind entfernt. Ein Kartenklick waehlt exklusiv einen Mandanten, umrandet nur ihn, zeigt nur dort `Show` und speist die Diagramme aus dessen neuestem scannergebundenen Timeslot; Mandanten ohne Scanbestand liefern Nullwerte. `Show` oeffnet die unveraenderte Mandantenansicht. Vier fokussierte Suites mit 11 Tests und der Gesamtlauf mit 620 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt eine Auswahl, einen `Show`-Button, null Platzhalter, eine Plus-Kachel, den erwarteten Diagrammwechsel und die Mandantennavigation. App und Backend laufen nach kontrolliertem Neustart wieder lokal. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7/9/10/12-Timeslot-Aktionen korrigiert: Nur angehakte Datumszeilen zeigen `Delete`, `Import Scan` und `Import GPO Backup Folder (Zip)`; beide Importe sind an die Assessment-ID genau dieses Slots gebunden. Der bestehende Mandanten-Delete bleibt oben unveraendert. Ein neuer projektgebundener, bestaetigungspflichtiger Assessment-DELETE-Pfad entfernt ausschliesslich den Timeslot-Teilbaum samt Scan-, GPO-, Finding-, Evidenz- und Mappingdaten in Local- und PostgreSQL-Persistenz; Mandant und andere Timeslots bleiben erhalten. Keine SQL-Migration. Fuenf fokussierte Suites mit 32 Tests, `npm test` mit 626 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-, Designpruefung sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Realdatenpruefung. |
| 2026-08-22 | Phase-7/12-Timeslot-Vorauswahl ergaenzt: Beim Oeffnen eines bestehenden Mandanten wird der erste Eintrag der chronologisch absteigend sortierten Timeslotgruppe automatisch markiert und als aktiver Stand gesetzt. Eine bewusste Abwahl bleibt moeglich. Zwei fokussierte Suites mit sechs Tests und Client-Produktionsbuild erfolgreich; keine API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-21 | PingCastle-`Details` auf Nutzerwunsch wieder aus dem Reader entfernt: Bei mindestens einem strukturierten Results-Blatt wird das Feld weder im Fliesstext noch unter Additional Information gerendert; der vollstaendige Inhalt bleibt im geordneten Results-Popup. Ohne strukturierte Results bleibt `Details` als verlustfreier Fallback lesbar. 38 fokussierte synthetische Tests, die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich. Keine Import-, API-, SQL-, Schema-, Persistenz- oder Realdatenaenderung; bereits gespeicherte Findings profitieren ohne Reimport. Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | PingCastle-Results auf den vollstaendigen Detailspfad ausgerichtet: Extractor 1.8.0 sortiert rekursive Zielcontainer nach ihrer Definition im HTML; der Linker rekonstruiert pro Finding exakt dessen Section-ID-Reihenfolge statt der globalen Blattreihenfolge. Profil 1.2.0 aktiviert hierarchische Results-Ueberschriften (`Details`, `Admin Groups`, `Admin Groups → …`) und blendet das technische Praefix aus. Fachliche Abschnittsprosa steht als Preamble direkt vor der zugehoerigen Tabelle; reine Modal-Titel und `Close` werden nicht doppelt ausgegeben. Damit ist zugleich der im unmittelbar folgenden Protokolleintrag dokumentierte unabhaengige `Close`-Preamble-Testfehler behoben. 49 fokussierte Tests sowie die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung und der Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL-, Schema- oder Realdatenaenderung; fuer bereits gespeicherte PingCastle-HTML-Laeufe ist ein Reimport erforderlich. Phase 13A und Phase 7 bleiben abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-7-Result-Fenster nach Nutzerreferenz erweitert: Doppelklick auf die freie Kopfzeile eines geoeffneten Results maximiert es nun auf die groesstmoegliche sichtbare Flaeche unterhalb des statischen Headers; ein einfacher Klick auf die maximierte Titelleiste stellt die vorherige Position, Groesse und Clusterzugehoerigkeit wieder her. Ein minimiertes Result wird per Doppelklick weiterhin normal aufgeklappt, Kopfzeilenbuttons bleiben ausgenommen und Resize-Kanten sind im maximierten Zustand deaktiviert. Der synthetische Interaktionstest deckt Maximierung, Ein-Klick-Rueckkehr und die Unterdrueckung einer sofortigen Wiedermaximierung durch das zugehoerige Doppelklickereignis ab und besteht mit 13 von 13 Tests; der Client-/Server-Produktionsbuild ist erfolgreich. Im abschliessenden Gesamtlauf bestanden 617 Tests, 8 optionale PostgreSQL-Tests wurden uebersprungen; ein parallel hinzugekommener, fachlich unabhaengiger PingCastle-Projektionstest blieb wegen eines unerwarteten `Close`-Preambles rot, waehrend der Result-Fenster-Test gruen blieb. Die separate Browserpruefsitzung war leer, daher wurden bewusst keine Scan- oder Testdaten im laufenden Backend angelegt. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen und Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-13A-PingCastle-Results vollstaendig und sicher auf HTML-Linkgraphen umgestellt: Extractor 1.7.0 verfolgt interne `href`, `data-bs-target` und `aria-controls` rekursiv ueber Subsections, Tabellenzellen, Modals und Collapse-Container, maskiert Kindziele im Elternblock und projiziert jeden erreichten Tabellenendpunkt separat in den bestehenden Results-Vertrag. Mehrfachtabellen, Zyklen, fehlende/mehrdeutige Ziele und Ressourcenlimits sind synthetisch abgesichert; aktive und externe Ziele bleiben ausgeschlossen. Results-Sections sind pro Importdatei namespaced. Nach ausdruecklicher Nutzerkorrektur werden PingCastle-HTML und -XML nicht mehr gegenseitig angereichert: nur HTML besitzt Results, XML bleibt eigenstaendig und erzeugt die Importwarnung `pingcastle-xml-results-unavailable`. Der freigegebene Dummy-Bericht bestaetigt inhaltsarm fuer `P-Delegated` sieben Bloecke mit insgesamt 33 Zeilen; der temporaere Realdatei-Test wurde entfernt. `npm test`: 616 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Aktualisierte App und Backend laufen lokal und liefern HTTP 200. Keine API-, SQL- oder Persistenzaenderung; neue HTML-Results erfordern eine erneute Verarbeitung des Berichts. Phase 13A bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-7-PingCastle-Darstellung nach ausdruecklicher Nutzerkorrektur angepasst: `Details` wird auch bei verknuepften strukturierten Ergebnissen als normaler Reader-Abschnitt direkt nach `Technical explanation` und vor `Advised solution` gerendert und verschwindet aus `Additional Information`. Originalfeld, strukturierte Results und Provenienz bleiben unveraendert. Synthetischer Finding-Reader-Test und kurzlebige synthetische Browserpruefung bestaetigen Reihenfolge, Absatzdarstellung und fehlende Zusatzinformationstabellenzeile; das temporaere Browserartefakt wurde entfernt. `npm test`: 615 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen und Phase 13B bleibt in Arbeit. |
| 2026-08-17 | Korrektur der unmittelbar folgenden Ein-Worker-Zwischenloesung: Die drei konkreten Parallelitaetsassertions wurden aus dem Config-Separation-Test entfernt. Kontrollierte Gesamtlaeufe mit aktivem File-Parallelismus und unveraendertem `forks`-Pool waren mit 2 Workern in 203,48 s und mit 4 Workern in 122,45 s erfolgreich; ein zweiter 4-Worker-Lauf ueber den oeffentlichen `npm test`-Pfad bestand in 121,03 s mit 614 bestandenen und 8 uebersprungenen Tests sowie erfolgreicher Local-only- und Designpruefung. `vitest.config.ts` begrenzt deshalb nur `maxWorkers` auf 4 und laesst Dateiparallelitaet aktiv. Die CPU-basierte Defaultzahl bleibt fuer das synchronisierte Laufwerk als instabil belegt; `threads` wurde bewusst noch nicht getestet, um nur eine Variable zu aendern. Keine Phasenstatus-, Fach-, Import-, API-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-17 | **Zwischendiagnose, durch den unmittelbar vorherigen Benchmarkeintrag ersetzt:** Phasenuebergreifende Verifikationshaertung fuer Phase 1/13: Der vermeintliche Server-Build-Haenger wurde widerlegt (`tsc` 6,6 s, isolierter Server-Vite-Build 1,2 s; kompletter Client-/Serverbuild 15,3 s). Der Vitest-Lauf hing nicht nach fertigen Tests an einem offenen Handle: der Standard-Fork-Pool liess auf dem synchronisierten `G:`-Laufwerk 130 von 136 Dateien `queued` und brach nach rund 9,5 Minuten mit `UNKNOWN: unknown error, read` ab. Worker-, Workflow- und Server-Cleanup-Tests terminierten fokussiert. Ein Worker ohne Dateiparallelitaet lieferte zunaechst den Stabilitaetsnachweis; diese Grenze wurde anschliessend nicht dauerhaft festgeschrieben. `npm run build` ist fuer Client und Server erfolgreich. Keine Fach-, Import-, API-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-17 | Phase-7-Severity-Bedienung um echte Mehrfachauswahl erweitert: Critical, High, Medium, Low und Info lassen sich ueber die Donuts unabhaengig kombinieren und mit erneutem Klick wieder entfernen; der letzte entfernte Wert hebt den Severity-Filter vollstaendig auf. Die Resultliste verwendet die vorhandene ODER-Semantik der Kategorie-Facette. Das Filterfeld zeigt Mehrfachauswahlen in fester Reihenfolge als `Crit-High-Med-Low-Inf` oder entsprechende Teilfolge. 17 fokussierte synthetische Tests sowie Client-/Server-Produktionsbuild erfolgreich; App und Backend liefern HTTP 200. Datahub, Import, API und Persistenz bleiben unveraendert. |
| 2026-08-17 | Phase-7-Darstellung und Filterinteraktion nach Nutzerreferenz korrigiert: fuenf groessere untereinander stehende Severity-Donuts fuer Critical, High, Medium, Low und Info; der bisher aus leeren oder nicht zuordenbaren Quellwerten normalisierte sichtbare `Unknown`-Sammelwert entfaellt. Donuts sind zugreifbare Filterbuttons und markieren die aktive Severity. Arbeitsdiagramme folgen dem persistenten Result-Status, initial `Deviation`; Projekt-, Blatt- und Ansichtswechsel aendern eine bewusste Nutzerauswahl nicht. Datahub bleibt unveraendert eine ungefilterte statistische Timeslot-Uebersicht mit `Results All` und allen Statuskarten. 601 Tests im Gesamtlauf bestanden, zwei durch parallele Windows-Worker-/Dateisystemfehler unterbrochene Suiten anschliessend isoliert mit 7 von 7 Tests bestanden; Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz- oder Realdatenaenderung. |
| 2026-08-05 | Bindenden Donut-Standard proportional an das Datahub-Gesamtbild angepasst: Kartenmindesthoehe von 226 auf 196 px, Ring von 158 auf 128 px, Ringstrich auf 11 px, Rackinnenabstand auf 12 px und Kartenabstand auf 8 px reduziert; Titel, Absolutwert und Prozentwert entsprechend kleiner skaliert. Dark-/Lightmode, Sechserausrichtung, Animation und 1180-px-Rahmen bleiben unveraendert. 601 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browsermessung bestaetigt kompakte Rack-, Karten- und Ringproportionen sowie fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Bindenden Donut-Standard nach ausdruecklicher Referenz eingefuehrt: wiederverwendbare DonutMetricCard, gemeinsamer Sechskarten-Rack, grosser animierter 270-Grad-Ring, sichtbarer Nullpunkt, Zentralwert, Prozentwert, farbiger Kopfstrich, Referenztypografie sowie eigene Dark- und Lightmode-Tokens. Datahub auf den Standard umgestellt; Komponentenvertrag, Skill-Assets und eng begrenzte Designpruefungsausnahme fuer Referenzradius und tokenisierte Tiefenschatten ergaenzt. 601 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung mit 0 rohen Farben und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt Referenzproportionen, sechs Karten/Farben/Animationen, Theme-Rollen und fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Timeslotstatus auf sechs animierte 270-Grad-Diagramme erweitert: Results All als feste 100-Prozent-Referenz sowie Deviation, Passed, Not Applicable, Not Run und Error mit Zahl, Anteil und semantischen Tokenfarben. Mehrere ScanRuns des ausgewaehlten Timeslots werden kanonisch aggregiert; reduzierte Bewegung zeigt den finalen Bogen ohne Animation. Responsive Umbrueche auf drei beziehungsweise zwei Spalten ergaenzt. 599 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt sechs Werte, sechs Prozentanzeigen, sechs Animationen, sechs eindeutige Farben, Results All bei 100 Prozent, korrekte Auswahl, Ausrichtung und fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Mandantendetail nach ausdruecklicher Bildreferenz neu aufgebaut, ohne Breite oder Position des bisherigen 1180-px-Datahub-Rahmens zu veraendern: grosser Name mit Datum, zwei rein praesentative Rackmodule, Open, Aktionsleiste mit Delete/Import Data/GPO Backup Folder/Save, Master Data mit Name/Consultant/Remarks sowie aufklappbare Scan History je ScanRun mit alleiniger Delete-Aktion. Timeslot-Verwaltung, GPO-Statusliste und Policy-Analysepanel aus diesem View entfernt. 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt 1180 px, deckungsgleiche Ausrichtung, zwei Rackmodule, acht Regler, keine Zusatzpanels und keinen horizontalen Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub nach direktem Ist-/Soll-Bildvergleich auf Bild 2 korrigiert und die vorherige kompakte Zentrierung verworfen: volle Rackbreite, acht sichtbare Mandantenslots mit rein praesentativen `Empty`-Spalten, 66-px-Plusspalte, violetter aktiver Mandant/Timeslot, Timeslotanzahl im Spaltenfuss sowie vier kleine 270-Grad-Zustandsregler in zwei getrennten Paaren. Der grosse Vergleichskasten entfällt; Auswahl ueber Dreieck und Oeffnen ueber Datum bleiben getrennt, der Vergleich startet bei zwei Staenden automatisch. `npm test` 596 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Referenzlayout mittig und inhaltsbasiert begrenzt: die fehlerhafte spezifische Vollbreitenregel entfernt, Rackmodule auf maximal 1180 px zentriert, Historie und Zustandsblock auf `max-content` mit sicherer 100-Prozent-Obergrenze gestellt, Mandantenspalten auf 190 px, Hinzufuegen auf 62 px und die vier Donutspalten auf 148 px begrenzt. Mehrmandanten-Scrollen und bestehende Responsive-Breakpoints bleiben erhalten. Neue statische Layoutregression; `npm test` 596 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Historie auf das korrigierte fachliche Timeslot-Modell umgestellt: ein Mandanten-Bewertungsstand umfasst alle Scannerquellen und den GPO-Snapshot desselben Stichtags. Bestehende vier Scannerlaeufe vom 22.07 werden als eine Zeile projiziert; neue explizite Timeslots koennen im Mandanteneditor angelegt und aktiv ausgewaehlt werden. Importvorschau/-abschluss und GPO-Upload bewahren die Assessment-ID, mehrere Scannerlaeufe werden im selben Assessment fortgeschrieben, Work und Vergleich laden alle Quellen des gewaehlten Stands. Assessment-History-API, Local-/PostgreSQL-Repository und read-only Mehrquellenvergleich ergaenzt. Synthetische Domain-, HTTP-, Client-, Gruppierungs-, Vergleichs- und Darstellungsregressionen: `npm test` 595 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration; reale Mandanteninhalte wurden nicht inspiziert. |
| 2026-08-04 | Datahub-Redesign gemaess Referenz umgesetzt: horizontale Mandanten-/Datums-Matrix, getrenntes Oeffnen und Zwei-Staende-Auswahl, read-only Vergleich ueber persistierte Assessments desselben Mandanten sowie vier SVG-Donut-Zustandsanzeigen fuer offen, behoben, kritisch und geprueft. MITRE- und Baselinekatalog sind rackartig neu dargestellt; bestehende Upload- und Wartungsfunktionen bleiben erhalten. Ein Datumsstand laedt in Work nur den gewaehlten ScanRun. Synthetische Vergleichs-, Projektions- und UI-Grenztests ergaenzt. `npm test`: 591 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt vier Donuts, vier Rackmodule, responsive Einspaltigkeit und keinen horizontalen Seiten-Overflow. Keine Migration oder Persistenzaenderung; reale Mandanteninhalte wurden nicht inspiziert. |
| 2026-08-04 | Phase-13B-Schritt-11 um die projektgebundene Policy-Orchestrierung erweitert: typisierte Backend-Aktionsbereitschaft fuer Reprocessing, Aggregation, Evaluation und Finding Factory; Datahub-Formular fuer neue oder supersedierende Environment Profiles mit Betriebssystem-, optionalem Produkt-, Rollen-, Scope- und Domaenenkontext; explizite Ready-, Review-only-, Completed- und Blocked-Zustaende samt Diagnosecodes. Nur aktive Profil-/Identity-Revisionen, der letzte Processing Run und pro Kontext exakt ausgewaehlte aktive Baselineanalysen werden angeboten. Alle Mutationen verwenden die vorhandenen autoritativen idempotenten Services; Review-only bleibt finding-ineligible, bis jede nachgelagerte Invariante erfuellt ist. Synthetische Bereitschafts-, Supersession-, Baselineauswahl-, HTTP- und Renderregressionen ergaenzt. `npm test`: 588 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; Phase 13B bleibt fuer reale Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs, aktuelle Ergebnisdeduplizierung und Exportdetails in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-11 um eine projektgebundene Policy-Analyseansicht erweitert: typisiertes Backend-Readmodell, read-only API/Client und Datahub-Darstellung fuer Laufhistorie, Evaluationen, bestaetigte Findings sowie severity-freie Konflikt-, Identitaets-, Katalog-, Parser-, Targeting-, Partial- und Factory-Review-Datensaetze. Die UI weist die fehlende RSoP-/GP-Results-Evidenz aus und trennt konfigurierte Abweichungen von tatsaechlich erzeugten Findings. Synthetische Domain-, HTTP-, Client- und Renderregressionen sichern, dass Review und unvollstaendige Evidenz keine Findings werden. `npm test`: 582 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; Phase 13B bleibt fuer Profilorchestrierung, reale Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs und Exportdetails in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-10/11 umgesetzt: versionierte fail-closed Finding Factory, Migration 017, gemeinsame Finding-Definitionen mit getrennten Policy-Occurrences, Local-/PostgreSQL-Persistenz, projektgebundene API/Client und `policy-evaluation`-Projektion in das bestehende Unified Result Model. Nur vollstaendig belegte `eligible` konfigurierte Abweichungen werden projiziert; Review, Nichtanwendbarkeit, Konflikte, Parser-/Katalogluecken und manipuliert unvollstaendige Evidenz bleiben ohne Finding. Scope bleibt unbekannt und Wirksamkeit nicht verifiziert. `npm test`: 577 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. PostgreSQL: 8 von 8 gegen isoliertes PostgreSQL 16, Migrationen 001 bis 017 und Factory-Idempotenz verifiziert; Container und synthetische Daten entfernt. UI und reale Regel-/Inbox-ADMX-Kuratierung bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-9/11-Vertikalschnitt umgesetzt: versionierte typisierte Comparatorbibliothek, konservative Evaluation Engine sowie Migration 015 fuer Evaluation Runs, Baselinequellen, PolicyEvaluationResults und Mehrquellen-Evidenz integriert. Ein Run bindet Aggregation, Profilrevision und eindeutige Baselineanalysen; nur vollstaendige Evidenz und eindeutiger Consensus koennen eine bestaetigte konfigurierte Abweichung als finding-berechtigt klassifizieren. Unvollstaendigkeit, Konflikt, Katalogluecke, Mehrdeutigkeit und Unvergleichbarkeit bleiben Review; Wirksamkeit bleibt unbekannt und projectedFindingCount ist relational null. Local-/PostgreSQL-Repositories, API und Client bieten Auswertung und Liste mit deterministischer Idempotenz. `npm test`: 564 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die komplette PostgreSQL-Suite lief gegen eine frische PostgreSQL-16-Instanz mit 8 von 8 Tests erfolgreich; Migrationen 001 bis 015, Evaluationpersistenz, Idempotenz und Projektloeschung wurden synthetisch verifiziert, Testcontainer und Testdaten entfernt. Reale Baselinepakete bleiben wegen fehlender Windows-Inbox-ADMX-Kataloge partial und damit review-only. Dependency-/Override-/Risikoregeln, explizite Nichtanwendbarkeit, Finding-Erzeugung, Unified-Result-Projektion und UI bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-8/11-Vertikalschnitt umgesetzt: Migration 014, unveraenderliche revisionsverkettete Environment Profiles, persistente versionierte Snapshot-Aggregationslaeufe mit expliziten Identity-Analysis-Quellen und konservative Registry-Policy-Zustandsreduktion integriert. Reihenfolge, Delete, Scope, Domaene, Snapshotkonsistenz und GPO-uebergreifende Konflikte werden beruecksichtigt; unvollstaendige, unaufgeloeste, getargetete oder vorzustandsabhaengige Faelle bleiben Reviewhinweise. API und Client bieten Profilanlage/-liste sowie Aggregation/-liste. Die Stufe setzt Wirksamkeit immer auf unbekannt und erlaubt niemals Findings. npm test: 551 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die vollstaendige PostgreSQL-Suite lief gegen eine frische PostgreSQL-16-Instanz mit 8 von 8 Tests erfolgreich; der kurzlebige Container samt synthetischer Testdaten wurde entfernt. Phase 13B bleibt bis typisierter Evaluation, Consensus/Risiko, Ergebnis-/Evidenzpersistenz und Unified-Result-Projektion in Arbeit. |
| 2026-08-04 | Phase-13B-Schritte 6/7/11 produktiv angebunden: Migration 013, Local-/PostgreSQL-Repositoryvertraege, begrenzte GPO-Identity- und Microsoft-Baseline-Workerpfade, atomare Analysepersistenz, deterministische Idempotenz/Supersession, Restart-Reconciliation sowie projekt- und referenzdatengebundene Read-/Reprocess-APIs implementiert. Synthetische Tests decken technische Aufloesung, `not-found`, Baselinekataloge, Crash-Retry, Reprocessing und stale-predecessor-Konflikte ab. `npm test`: 543 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ein synthetischer Fresh-PostgreSQL-Test ist ergaenzt, seine reale Ausfuehrung bleibt mangels lokalem Image und nicht freigegebenem externen Download offen. Phase 13B bleibt in Arbeit; Snapshotaggregation, Environment Profile, Evaluation und Result-Projektion sind nicht als abgeschlossen markiert. |
| 2026-08-04 | Phase-13B-Schritt-6/7-Analysevertrag umgesetzt: stabile technische Registry-Zielidentitaet aus Scope/Hive/Schluessel/Ziel, getrennte optionale ADMX-Referenz aus Zielnamespace/Policy/Element sowie lokalisierungsneutrale ADML-Ressourcen. Ein begrenzter read-only ADMX-/ADML-Parser und ein selektiver Microsoft-Baseline-ZIP-Adapter verarbeiten ausschliesslich Backup.xml, Registry.pol, ADMX und ADML; XLSX/PDF/Skripte bleiben opak. Baseline-Registryeinstellungen laufen durch denselben PReg-Parser und Reducer wie GPMC-Backups, einschliesslich Byteoffset-Provenienz und fail-closed Typpruefung. 537 Standardtests, Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen. Die 11 freigegebenen unveraenderten Dummy-Baselineoriginale wurden read-only ohne Persistenzmutation geprueft: 11/11 Pakete erfolgreich, 79 GPO-Backups, 89 Registry.pol-Dateien, 3.580 stabile technische Einstellungen, davon 185 eindeutig an mitgelieferte ADMX-Definitionen gebunden. Alle Analysen bleiben bewusst partial, weil Microsoft nur ergaenzende und keine vollstaendigen Windows-Inbox-ADMX-Kataloge mitliefert. Worker-/Repository-Persistenz, Kunden-Reprocessing und Evaluation bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-`Registry.pol`-Vertikalschnitt umgesetzt: begrenzter read-only PReg-Parser, geordnete typisierte Registry-Instruktionen, Delete-/SecureKey-/Soft-Semantik, Byteoffset-Provenienz und bestehende unveraenderliche Beobachtungspersistenz. Der reale GPMC-Kompatibilitaetsfall REG_NONE wird nur als leere Schluesselanlage akzeptiert; andere nicht freigegebene Typen bleiben blockiert. 532 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Der unveraenderte freigegebene Mandantenbestand wurde ohne Persistenzmutation ueber den Produktionsworker geprueft: ein Quellartefakt mit korrekter Integritaet, drei Backups, eine von einer `Registry.pol`-Datei unterstuetzt, vier technische Registry-Beobachtungen und keine Integritaets-, Worker- oder Blockierungsfehler. ADMX-/Baseline-Identitaet und PolicyEvaluation bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase 13B um sichtbare GPO-Scan-Historie und Microsoft-Security-Baselinekatalog erweitert. Dummy zeigt nun fuenf Scanberichte und eine eigene GPO-Zeile mit drei Backupinstanzen. Migration 011, globale Repository-/API-Persistenz, privater SHA-256-Artefaktspeicher, ZIP-Mehrfachupload, Deduplizierung, Metadatenerkennung sowie fail-closed Auswahl (`selected`, `no-match`, `ambiguous`) implementiert. Baselineoriginale sind in der Orphan-Reconciliation referenziert. Real verifiziert: Migration angewendet, Baseline-API HTTP 200, leerer Katalog `no-match`, Datahub zeigt Katalog und GPO-Zeile. 523 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests uebersprungen. Einstellung-gegen-Einstellung-Evaluation bleibt offen. |
| 2026-08-04 | Baseline-Metadatenerkennung nach realem Abgleich der 11 freigegebenen Originalpakete korrigiert. Migration 012 speichert 11 unveraenderliche Klassifikationsrevisionen fuer 11 Originalpakete; kombinierte Windows-10-/Windows-Server-ZIPs besitzen mehrere Produktkontexte, Microsoft 365 Apps wird als Version 2512 erkannt. Alle hochgeladenen Dateien stimmen per SHA-256 bytegenau mit den Originaldownloads ueberein. Auswahltests fuer Windows Server 2016, Windows 10 1809, Windows Server 20H2 und Microsoft 365 Apps 2512 liefern jeweils genau ein erwartetes Paket; Datahub zeigt alle 11 Kontexte korrekt. 524 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Einstellung-gegen-Einstellung-Evaluation bleibt offen. |
| 2026-08-04 | GPO-Inventarstatus aus Mandanten-Berichtzaehler und Linked Scan Reports entfernt. Der freigegebene Dummy fuehrt wieder vier echte Scanberichte; die drei GPO-Backupinstanzen bleiben getrennt unter GPO Processing mit ihrem Teilstatus sichtbar. Ein GPO-Bericht darf erst aus einem persistierten Baseline-Evaluation-Run entstehen. Zwei neue Regressionen sichern diese Darstellungsgrenze. 526 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Keine Daten- oder Schemamigration. |
| 2026-08-04 | GPO-Uploadsemantik korrigiert: Ein hochgeladener Hauptordner ist ein Mandanten-GPO-Backup-Snapshot, die drei Dummy-Unterordner sind drei enthaltene GPOs. Ingestion vergibt eine gemeinsame selected-gpos-Set-ID; Snapshotbildung gruppiert auch bestehende unveraenderliche Datensaetze ueber das gemeinsame Quellartefakt. Status-API und UI zeigen 1 Mandanten-GPO-Backup mit 3 GPOs; der bisherige technische Zaehler bleibt nur als kompatibler Alias. Keine Vollstaendigkeits-, Link-, Scope- oder Wirksamkeitsbehauptung. 526 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Keine SQL-Migration. |
| 2026-08-04 | Phase-13B-GPMC-Kompatibilitaet nach realer, ausdruecklich freigegebener Dummy-Pruefung nachgehaertet: synchrone Parserablehnungen verlassen den Worker nicht mehr als generischer Absturz; GPMC-Zeiten ohne Offset bleiben als Zeitzonenluecke `partial`, ohne separat belegte Identitaet und Domaene zu verwerfen. Die fachfremde XLSX im Auswahlroot bleibt als verschachteltes Archiv sicher abgewiesen. Die 13 GPO-Backupdateien wurden ueber den Produktionsworker und die reale API in Dummy persistiert: drei Backupinstanzen, drei aufgeloeste Identitaeten und Domaenen, drei vollstaendige Inventare, 47 Policy-Beobachtungen, Status `partial`, ein Versuch, kein Fehlercode. Der lokale private Artefaktspeicher ist auf NTFS ausserhalb des Webroots konfiguriert. 519 Standardtests, Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen. Phase 13B bleibt in Arbeit. |
| 2026-08-02 | Phase-7-Result-Cluster nach Nutzerreferenz angepasst: Jeder Minimierungsvorgang parkt den Cluster viewport-sicher bei 80 px rechts und 76 px oben; der minimierte Cluster bleibt danach verschiebbar. Der Reader-Results-Button übernimmt bei offenem Fenster dessen individuelle Result-Farbe, identisch zur vorhandenen Kachelmarkierung. Zwei synthetische Regressionen für Parkkoordinaten und Buttonfarbe ergänzt; 21 fokussierte Tests sowie die Client-Typescript-Prüfung bestanden. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Result-Fenster nach Nutzerkorrektur bereinigt: Den falschen Zeichenrest aus der Titeltrennung durch einen eindeutigen Unicode-Gedankenstrich ersetzt, die Quellblattüberschrift und den fehlerhaft kodierten sichtbaren Minimieren-Button entfernt. Der Finding-Titel bleibt auf ausdrücklichen Nutzerwunsch zusätzlich als Überschrift im Rumpf erhalten. Doppelklick auf die freie Kopfzeile minimiert beziehungsweise stellt wieder her. Drei synthetische Regressionen decken Titeltrennung, fehlenden Button, unterdrückte Blattüberschrift und die zusätzliche Finding-Überschrift ab; 19 fokussierte Tests sowie die Client-Typescript-Prüfung bestanden. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Result-Cluster korrigiert: Minimierte Result-Fenster werden nicht mehr ausgeblendet, sobald ein Result maximiert ist, sondern verbleiben als 14-px-Reiter im Cluster und erhalten eine sichtbare Farbkante. Das Herausziehen des maximierten Fensters ist damit unabhängig vom minimierten Stapel erkennbar und bedienbar. Eine zusätzliche synthetische Renderregression prüft den minimierten Farbreiter. Die vollständige lokale Unit-Suite läuft über die funktionsfähige JavaScript-Testkonfiguration mit 102 bestandenen Testdateien und 487 bestandenen Tests; 7 optionale PostgreSQL-Tests werden übersprungen. Client-Typescript-, Local-only- und Designprüfung sind erfolgreich. Vollständiger npm-test- und Build-Lauf bleibt durch einen vorhandenen Syntaxfehler in vite.config.ts (Zeile 17) blockiert; keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
|---|---|
| 2026-08-05 | Vier Datahub-Regler fachlich an den zuletzt angewählten Mandanten-Timeslot gebunden und in `Results All`, `Deviation`, `Passed`, `Error` umbenannt. Alle Scannerlaeufe des Timeslots werden gemeinsam aus kanonischen Finding-Vorkommen gezaehlt; das bestehende Abweichungspraedikat trennt fachliche Abweichungen von technischen Errors. Neuester vorhandener Timeslot wird auch bei nur einem Stand standardmaessig ausgewaehlt; mittlere Trennlinie und Einheiten entfernt. 599 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt Auswahlbindung, vier numerische Werte, korrekte Labels, 1180-px-Ausrichtung und keinen Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Uebersicht nach neuester ausdruecklicher Bildreferenz innerhalb des unveraenderten zentrierten 1180-px-Rahmens neu aufgebaut: acht Mandantenslots plus schmale Plusspalte, vier rein praesentative Transpose-/Detune-Regler, MITRE-Rack mit 3x3-Matrixmarke sowie Microsoft-Baseline-Rack mit `BASELINES`-Liste und Referenzbeschriftungen. Alte Donuts und das Mandanten-Zusatzmenue entfernt; vorhandene Auswahl-/Oeffnen-, MITRE-JSON- und Baseline-ZIP-Funktionen bleiben erhalten. 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browsermessung bestaetigt vier deckungsgleiche Racks mit 1179,98 px, acht Slots, vier Regler, neun MITRE-Felder und keinen Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-02 | Phase-7-Result-Cluster bei kurzem Inhalt korrigiert: Ein maximiertes, weiterhin angedocktes Result erhält nun mindestens die gemeinsame Stapelhöhe aller dahinterliegenden minimierten Kopfzeilen. Dadurch bleiben außer den vorgesehenen 14-px-Farbreitern keine unteren Result-Titelleisten sichtbar. Die Mindesthöhe ist am verfügbaren Viewport begrenzt; frei herausgezogene Fenster bleiben unverändert. Die 34-px-Stapelhöhe wird für Position, Clustergrenze und Abdeckung zentral geteilt. Zwei synthetische Geometrie-/Renderregressionen ergänzen den kurzen Acht-Fenster-Fall und den Viewport-Grenzfall. 105 Testdateien mit 517 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Purple-Knight-Statusanzeige korrigiert: Reader, Datensatzkarte und Kachel verwenden nun dieselbe profilgesteuerte Statusauswahl. Das Purple-Knight-Profil priorisiert `Status` vor `Result`, sodass eine dort wiederholte SI-Kurzkennung nicht länger als Status erscheint. Rein visuelle Regeln beschriften `Pass` mit `Passed` und `IOE Found` mit `Failed`, ohne Originalwerte oder Provenienz anzutasten; Rohberichte mit ausschließlich `Result` bleiben kompatibel. Synthetische Regressionen sichern beide Datenformen, beide Beschriftungen und alle drei Darstellungen. 105 Testdateien mit 515 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-CIS-CAT-Result-Hierarchie und Assessment-Markierung nach Nutzerpräzisierung vervollständigt: Framework-Versionen erscheinen einmal als Hauptüberschrift ihrer Tabellengruppe; jeder Control-Listenpunkt wird direkt zur Überschrift seiner Tabelle. Zusätzlich markiert das CIS-CAT-Profil `No matching system items were found.` über `resultSheetHighlightedRowPatterns` mit derselben `rich-text-table-row--evaluated`-Darstellung und denselben blauen Evidence-Tokens wie bereits ausgewertete Tabellenzeilen. Die generische Tabellenkomponente erhält nur die profilgesteuerte Markierungsentscheidung; bei anderen Werkzeugen bleibt derselbe Text unverändert. Mehrere Controls derselben Version, zukünftige Frameworks, unvollständige Tabellenzuordnung sowie die echte Hinweiszeile sind synthetisch regressionsgeprüft. 105 Testdateien mit 506 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Results global verdichtet: Die äußeren Kästen um Ergebnisüberschrift und Tabelle wurden aus dem gemeinsamen `.result-block` entfernt (`padding: 0`, `border: 0`, transparenter Hintergrund). Tabellenzelllinien, fachliche Haupt- und Tabellenüberschriften sowie die blaue Evidence-Markierung bleiben unverändert. Ein neuer synthetischer CSS-Vertrag verhindert die Rückkehr der platzraubenden Containerform. 105 Testdateien mit 507 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phasen-10/13-Entwicklungsstart nachgehärtet: `npm run dev` startet über `scripts/dev-local.mjs` den vollständigen lokalen Stack. Der Starter verwendet ausschließlich inhaltsfreie Health-Signale, übernimmt ein bereits gesundes Backend oder baut und startet ein fehlendes Backend über `vite.server.config.ts` auf `127.0.0.1:4173`; der Client über `vite.client.config.ts` folgt erst nach erfolgreicher Health-Prüfung fest auf `127.0.0.1:5173`. `npm run dev:client` bleibt als eindeutig benannter Client-only-Weg. Lokale Backend-Dokumentation repariert und ergänzt; eine dritte synthetische Konfigurationsvertragsregression schützt Reihenfolge, Adressen und Konfigurationsgrenzen. `npm test` mit 105 bestandenen Testdateien und 499 Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie `npm run build` für Client und Server erfolgreich; Test und Build liefen parallel ohne Kollision. Keine Import-, Persistenz-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Dreiecksdarstellung nach Nutzerkorrektur vervollständigt: Spezifischere Filter-, Hover-, Dashboard- und Graph-Styles verwenden für Select-Zustände nur noch `background-color` und löschen dadurch die zentrale SVG-Dreiecksmarkierung nicht mehr. In Result-Titelleisten ersetzt das individuelle farbige Zustandsdreieck den Würfel vollständig; minimiert zeigt es nach rechts, maximiert nach unten, und der Klick verwendet denselben Minimieren-/Wiederherstellen-Pfad wie der Kopfzeilen-Doppelklick. Ein zusätzlicher synthetischer CSS-Vertrag sowie erweiterte Result-Render-/Interaktionsregressionen schützen Sichtbarkeit, Farbe, Richtung und Funktion. 105 Testdateien mit 500 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich; Test und Build liefen parallel ohne Kollision. Keine Import-, Persistenz-, Server-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phasen-10/13-Buildnachhärtung umgesetzt: Die zuvor gemischte und syntaktisch beschädigte `vite.config.ts` ist durch getrennte Client-, Server- und Testkonfigurationen ersetzt. Client (`dist`, `.vite-client`), Server (`dist-server`, `.vite-server`) und Vitest (`.vite-tests`) besitzen isolierte Zuständigkeiten; Dev-, Build-, Watch-, Standard- und PostgreSQL-Testskripte wählen ihre Datei explizit. Ein schmaler `vite.config.ts`-Clientalias erhält Kompatibilität für Claude Code, Gemini, IDE-Plugins und andere generische Vite-Aufrufe. Die Test-Include-Regel erfasst ausdrücklich `.test.ts` und `.test.tsx`. Zwei synthetische Konfigurationsvertragsregressionen ergänzt. `npm test` mit 105 bestandenen Testdateien und 498 Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie `npm run build` für Client und Server erfolgreich; Test und Build liefen zusätzlich parallel ohne Kollision, alle vier Konfigurationsdateien sind typgeprüft. Veraltete generierte `vite.config.js`-/`vite.config.d.ts`-Artefakte und die Node-Buildinfo wurden entfernt; `tsconfig.node.json` verhindert neue Emits. Ein generischer `vite build` ohne `--config` lief erfolgreich über den Kompatibilitätsalias; seine temporäre Ausgabe wurde entfernt. Keine Import-, Persistenz-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Darstellung nach Nutzerreferenz korrigiert: Minimierte Results parken nicht mehr im Filter-/Statusband, sondern bei jedem Minimieren 80 px vom rechten Viewportrand und 46 px unterhalb der gemessenen Arbeitsflächen-Oberkante; kurze Viewports bleiben geklemmt. Funktionale Richtungsanzeigen in Reader-, Such- und Sidebarnavigation, Datahub-Zurückweg, DB-/Result-Aufklappern, Finding-Details und nativen Selects verwenden jetzt dieselbe gefüllte, schriftunabhängige Dreiecksgeometrie; die fehlerhaft dekodierten Reader-Zeichen entfallen. Zwei neue synthetische Regressionen plus angepasste Reader-Verträge; 104 Testdateien mit 496 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only-, Design- und Client-Typprüfung sowie Client- und Server-Produktionsbuild erfolgreich. Der normale npm-test-Einstieg bleibt unabhängig von dieser Änderung durch den vorhandenen Syntaxfehler in vite.config.ts Zeile 17 blockiert; der identische vollständige Vitest-Lauf wurde über die intakte Server-Konfiguration ausgeführt. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-13A-Result-Linker werkzeugsicher nachgehÃ¤rtet: Maester-Findings kÃ¶nnen keine CIS-CAT-DetailblÃ¤tter mehr Ã¼bernehmen. Der Linker ermittelt die Finding-Herkunft aus Blattmetadaten oder Source: Scan, verwirft ausdrÃ¼cklich abweichende toolIds bei direkten und unscharfen Verweisen und bewertet freien Ergebnistext nicht mehr als Dateiverweis; nur Datei- und stabile Regel-ID-Verweise bleiben fÃ¼r die unscharfe Zuordnung zugelassen. Echte CIS-CAT-source-table- sowie Purple-Knight-Datei-/SI-ID-Links bleiben regressionsgeprÃ¼ft. Drei neue ausschlieÃŸlich synthetische KreuzverknÃ¼pfungstests ergÃ¤nzt. 485 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Persistenz-, Schema-, Importdaten- oder RealdatenÃ¤nderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Result-Fenster um Kopfzeilen-Doppelklick ergÃ¤nzt: Doppelklick auf ein minimiertes Result stellt es wieder her, Doppelklick auf ein maximiertes Result minimiert es Ã¼ber denselben bestehenden ZustandsÃ¼bergang. Bookmark-, Minimieren-, Matrix-/Report- und SchlieÃŸen-Buttons sind vom Kopfzeilen-Doppelklick ausgeschlossen und behalten ihre Funktionen. Ein echter synthetischer DOM-Test prÃ¼ft beide Richtungen und die Button-Ausnahme. 482 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, Server-, Datenbank- oder RealdatenÃ¤nderung. |
| 2026-08-02 | Phase-7-Result-Cluster nach Nutzerkorrektur nachgeschÃ¤rft: Beliebig viele aus dem Cluster gezogene Results kÃ¶nnen gleichzeitig maximiert bleiben; Ã–ffnen, Wiederherstellen, Datensatzauswahl und Matrix-/Report-Wechsel verÃ¤ndern entkoppelte Fenster nicht. Erst Minimieren fÃ¼hrt ein Fenster in den Cluster zurÃ¼ck. Das Zielbild verwendet hinter dem aktiven Fenster nur noch 14 px breite vertikale Farbreiter statt horizontal sichtbarer Results-Beschriftungen. Cluster und freie Fenster werden bei Ã–ffnen, Verschieben, Skalieren und Viewport-Ã„nderung vollstÃ¤ndig innerhalb der Anzeige gehalten; Ã¼bergroÃŸer Inhalt scrollt im Fenster. Sechs synthetische Zustands- und Renderregressionen ergÃ¤nzt. 481 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only- und DesignprÃ¼fung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, Server-, Datenbank- oder RealdatenÃ¤nderung. |
| 2026-07-31 | SchlÃ¼ssel/Wert-Tabellen ohne Kopfzeile: Die CIS-Control-Tabellen zeigten im Results-Fenster eine einzige Spalte â€žLabel:" mit der Zeile â€žDescription:" und keinen einzigen Wert. Eine `table.enum` ist eine reine SchlÃ¼ssel/Wert-Tabelle mit spaltenÃ¼bergreifender Titelzeile; `detectHeaderRow` machte den Wert der lÃ¤ngsten Zeile zur SpaltenÃ¼berschrift und verwarf alles darÃ¼ber. `analyzeRows` erkennt sie jetzt an zwei Spalten mit durchgÃ¤ngigen Bezeichnern auf Doppelpunkt, vergibt `Feld`/`Wert` und behÃ¤lt jede Zeile; die Titelzeile bleibt Titel. Wirkt erst mit erneutem Import, weil Quelltabellen aus der Analyse persistiert werden. 464 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only-, DesignprÃ¼fung und Client-/Serverbuild grÃ¼n. Am freigegebenen Dummy nach Neuimport bestÃ¤tigt: Regel 17.7.5 zeigt beide Steuerungstabellen vollstÃ¤ndig mit Werten (V7.0 vier Angaben, V8.0 sechs). Bekannter Rest ohne Informationsverlust: im bounded-lexical Pfad fÃ¤llt die Ã¤uÃŸere Complex-Check-Tabelle wegen ihrer dreispaltigen ersten Zeile aus der Erkennung; ihr `Criterion:` steht vollstÃ¤ndig im folgenden Block. Keine SQL-Migration. |
| 2026-07-31 | Phase-13A-CIS-CAT-Results-VerknÃ¼pfungskorrektur: Am freigegebenen Dummy fÃ¼hrte eine einzelne Regel 3.294 Zeilen aus rund 50 identischen Belegtabellen. Ursache war der Ergebnis-Linker: in der Projektansicht trÃ¤gt `record.sourceFile` den Projektnamen, nicht die Quelldatei, der exakte `source-table:`-Verweis fand deshalb kein Blatt und die NamensÃ¤hnlichkeit zog jede gleichnamige Tabelle des Berichts herein. Der Linker nutzt jetzt das Provenienzfeld â€žQuelle: Datei" und behandelt einen Quelltabellenverweis als abschlieÃŸend â€” ohne Treffer bleibt das Ergebnis leer statt Ersatz zu erfinden. Dazu zwei nur real sichtbare Beschriftungsfehler behoben: AufklappblÃ¶cke, die Bedienwort und Bezeichnung auf `span.action`/`span.caption` verteilen (dadurch entstand keine Marke und die Belegtabellen erbten â€žImpact"), und fette Steuerungen mit Doppelpunkt innerhalb der Zuordnungsliste, die als AbschnittsÃ¼berschrift galten. References ist Ã¼ber seinen BehÃ¤lter von den Zuordnungen getrennt; die Fixture bildet alle drei realen Strukturen ab. 463 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only-, DesignprÃ¼fung und Client-/Serverbuild grÃ¼n. Am freigegebenen Dummy neu eingelesen (411 Occurrences, Ã¼berholter Lauf entfernt, wieder vier Scanberichte): Regel 17.7.5 zeigt 130 statt 3.294 Zeilen in sieben korrekt benannten BlÃ¶cken, ohne XML und References im Fenster, mit geschlossenem XML-Detail im Reader. Keine SQL-Migration. |
| 2026-07-31 | Phase-13A-CIS-CAT-Results-VollstÃ¤ndigkeit: Alle verlinkten und im Bericht nur aufgeklappten Inhalte erscheinen im Results-Fenster. Die Abschnittszuordnung liest ihre Ãœberschriften wÃ¶rtlich aus dem Bericht (Aufklappverweise und fette Ãœberschriften mit Doppelpunkt) statt aus einer festen Liste; eine neue Fassung wie â€žCIS Controls V8â€œ oder ein fremdes Rahmenwerk wird dadurch richtig benannt statt als â€žRule Result XMLâ€œ aussortiert und samt Tabelle verloren zu gehen. XML-Doppeltabellen werden Ã¼ber ihren BehÃ¤lter ausgeschlossen. Neues Feld `Control Mappings` mit dem bisher nie ausgegebenen Zuordnungstext ohne die Bedienbeschriftung â€žMoreâ€œ; Detailtabellen ohne Caption Ã¼bernehmen ihre Kopfzelle als Namen. Neues profilgetriebenes `resultSectionHeaders` bringt `Control Mappings` als benannten Abschnitt in das Fenster und blendet das Feld im Reader aus. Das Rule Result XML bleibt auf Nutzerkorrektur vom selben Tag ein geschlossenes Detail im Finding und erscheint im Fenster an keiner Stelle; Legacy-Sammelfelder bleiben ohne Reimport lesbar. Das Fenster trÃ¤gt jetzt beliebig viele benannte Abschnitte statt eines einzelnen Textes, in Datensatz- und Graphansicht gleich. 460 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only-, DesignprÃ¼fung und Client-/Serverbuild grÃ¼n. Neue synthetische Fixture mit neuer CIS-Fassung und fremdem Rahmenwerk sichert die Regression bis in die gerenderte Fensterausgabe. Keine visuelle Abnahme an realen Daten; neue Felder entstehen erst beim nÃ¤chsten Import. Keine SQL-Migration. |
| 2026-07-30 | Phase-13B-Result-DB-Abweichungs- und Titelkorrektur: Das versionierte PrÃ¤dikat 1.1.0 zÃ¤hlt `fail` unabhÃ¤ngig von IOE als Abweichung; CIS-CAT-Compliance-Checks bleiben IOE Nein und werden Abweichung Ja. PostgreSQL-Vorfilter, Projektion, Facetten und Filter verwenden identisch `fail`/`warning`. Importregression sichert Benchmark Item als FindingDefinition-Titel und schlieÃŸt Quelle: Datei/Dateiname aus. 443 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only-, DesignprÃ¼fung und Client-/Serverbuild grÃ¼n. Im freigegebenen Dummy bestÃ¤tigt: Regel 2.2.2 mit vollstÃ¤ndigem Titel, fail/Ja, kein Quelle-Datei-Titel sowie funktionsfÃ¤higer Ja-(323)-Filter mit 323 Treffern. Keine SQL-Migration und kein Reimport. |
| 2026-07-30 | Phase-13A-CIS-CAT-Results-Darstellungskorrektur: Results zeigt nur noch verlinkte Assessment-Evidence- und CIS-Control-Tabellen; Finding-FlieÃŸtext bleibt im Finding. Rule Result XML ist dort standardmÃ¤ÃŸig geschlossen und fehlt im Results-Fenster. Legacy-Sammelfelder bleiben ohne Reimport lesbar; neue Importe speichern XML separat. Blattspezifische Profilwahl korrigiert in gemischten Projekten den Titel auf Benchmark Item. 440 Standardtests bestanden, 7 optionale PostgreSQL-Tests Ã¼bersprungen; Local-only-, DesignprÃ¼fung und Client-/Serverbuild grÃ¼n. Im freigegebenen Dummy an Regel 2.2.2 mit vollstÃ¤ndigem Titel, geschlossenem XML und acht verlinkten Results-BlÃ¶cken ohne Volltext/XML visuell bestÃ¤tigt. Keine SQL-Migration. |
| 2026-07-30 | Phase-13A-CIS-CAT-Results-NachhÃ¤rtung: Interne `#detail-*`-Verweise werden durch einen eigenen Source Extractor verlustfrei in 411 Candidate-Findings aufgelÃ¶st; `Benchmark Item`/Rule ID ersetzen den falschen W-/1.0-Titel. Description, Rationale, Remediation/Impact, Assessment Evidence, Rule Result XML, References und CIS Controls V7/V8 erscheinen Ã¼ber sicheren Klartext und exakt dateigebundene SourceTable-Referenzen im Results-Vertrag; verschachtelte bounded-lexical Tabellenindizes sind korrigiert und XML-Doppeltabellen ausgeschlossen. Strukturierte Originalwerte und Provenienz bleiben erhalten. 437 Standardtests, Local-only- und DesignprÃ¼fung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests Ã¼bersprungen. Realer freigegebener Dummy-Preflight: 411 Findings, 1.815 Quelltabellen und fÃ¼r Regel 2.2.2 sechs Evidence- plus zwei Control-Tabellen. Zwei alte CIS-CAT-TestlÃ¤ufe wurden durch einen geprÃ¼ften Lauf ersetzt; Dummy enthÃ¤lt wieder vier Scanberichte. Visuelle Work-Popup-Abnahme durch Browser-URL-Policy blockiert, Daten-, Projektions- und Readervertrag automatisiert und real technisch verifiziert. Keine SQL-Migration. |
| 2026-07-29 | Appweite Kopfsektion als gemeinsamer `div`-Container umgesetzt (Phase 7, reine PrÃ¤sentation): Work-Werkzeugleiste, Filter und Status wurden aus zwei Shell-Ebenen in `.app-header-panel` zusammengefÃ¼hrt; Datahub, DB-Struktur, Result DB und Graph verwenden dieselbe HÃ¼lle, der Graph behÃ¤lt sein zustandsfÃ¼hrendes Portal. Kopf- und Inhaltscontainer nutzen gemeinsam `--surface-app` und 10 px Rundung; die linke und rechte Kante sind an der InhaltsflÃ¤che ausgerichtet. Alte leere Workspace-Header entfallen. Nach einer Nutzerkorrektur wurde die tatsÃ¤chlich fehlende `.reader-toolbar`-Flexregel ergÃ¤nzt und `.toolbar` von flÃ¤chenfÃ¼llendem Wachstum auf ihre ursprÃ¼ngliche Inhaltsbreite zurÃ¼ckgestellt. Damit stehen ZÃ¤hler und Werkzeugleiste wieder gemeinsam und ohne groÃŸe ZwischenlÃ¼cke auf der ersten Zeile; Filterband und Statusinformationen behalten die zweite beziehungsweise dritte Zeile. Der statische Preview-Build wurde anschlieÃŸend neu erzeugt; der Designvertrag erzwingt nun sowohl die Flexzeile als auch `flex: 0 0 auto` fÃ¼r die Werkzeugleiste. Keine Import-, Persistenz-, Server- oder DatenÃ¤nderung. Verifiziert mit 420 Standardtests (7 optionale PostgreSQL-Tests Ã¼bersprungen), Local-only-PrÃ¼fung, DesignprÃ¼fung, Client-/Server-Produktionsbuild und inhaltsfreier Browsermessung (genau ein Kopfcontainer, korrekter Hintergrund/Radius, keine Ãœberlagerung, keine Konsolenfehler). |
| 2026-07-28 | Der Nutzer erklÃ¤rt den aktuellen `Work`-Stand (Dark und Light) zum verbindlichen Wunschdesign des gesamten Assessors; Funktionen bleiben unangetastet. Erste Angleichung genau der Abweichungen, die sich gegen diese Referenz **messen** lassen â€” ermittelt Ã¼ber berechnete Stile aller fÃ¼nf Bereiche, weil in dieser Umgebung keine Screenshots mÃ¶glich sind (Browser-Pane wird nicht dargestellt). (1) Der Systemstatus-Block der Sidebar (`.sidebar-context`/`.sidebar-server-card`, `App.tsx`) entfÃ¤llt: er erschien nur auf drei von fÃ¼nf Bereichen und wiederholte dabei die Verbindungsanzeige, die die Topbar auf genau diesen Bereichen ohnehin trÃ¤gt (`.area-topbar` mit `.connection-pill`); in `Work` steht der Zustand in der Statuszeile. Die Sidebar trÃ¤gt damit wie in der Referenz ausschlieÃŸlich Navigation, ohne Informationsverlust. (2) Datahub fÃ¼hrte den Seitennamen dreifach: Topbar, Hero-Ãœberschrift (21,5 px) und SektionsÃ¼berschrift der Liste. Eyebrow und Hero-Ãœberschrift entfallen in beiden Hero-Abschnitten; Einordnungszeile und Aktionen bleiben. Damit trÃ¤gt keine Ansicht mehr einen Inhaltstitel Ã¼ber 18 px, `Work` hat keinen. (3) Die Graph-Filter waren als einzige Ansicht 40 px hoch mit `--ui-body-size`; sie verwenden jetzt `--control-height` und `--ui-control-size` wie die Filter im Command Band von `Work`. Verifiziert mit `npm test` (420/420 bestanden), `npm run build`, DesignprÃ¼fer (0 rohe Farbwerte, verbotene Muster von 40 auf 39 gesunken) sowie einer Messung aller fÃ¼nf Bereiche in Dark und Light: kein Sidebar-Statusblock mehr, keine Inhaltstitel Ã¼ber 18 px, Graph-Filter 30 px/13 px identisch zu `Work`, Seitentitel und Verbindungszustand weiterhin in der Topbar, keine Konsolenfehler. Offen bleiben die strukturellen Punkte der Korrekturliste (`review-checklist.md` Â§6.4 Datahub als Tabellenarchetyp, Â§6.5 Inspector und Virtualisierung in Ergebnisse, Â§6.6 Graph-Karten): sie Ã¤ndern Aufbau und Bedienung und brauchen eine ausdrÃ¼ckliche Freigabe, weil der Auftrag Funktionen ausdrÃ¼cklich unangetastet lÃ¤sst. |
| 2026-07-28 | Die Maester-Ergebnisdarstellung wird auf Nutzerentscheidung zur verbindlichen Ergebnisform des gesamten Assessors, unabhÃ¤ngig vom Scanbericht; dabei kam ein Abschneidefehler zutage. (1) Jedes Ergebnis â€” werkzeuggelieferter Text wie verknÃ¼pftes Blatt â€” steht jetzt im selben Ergebnisblock (`.result-block`: neutraler Kasten `--panel`/`--line`, Titel in `--ui-reading-heading-size`), und jede Ergebnistabelle trÃ¤gt dieselbe Darstellung (`.rich-text-table` in `.rich-text-table-wrap`: Zellrahmen rundum, Versalienkopf auf `--surface-inset`, oben ausgerichtet). VerknÃ¼pfte BlÃ¤tter verwendeten zuvor die allgemeine Tabellenform mit klebendem Kopf und Unterstreichungen und sahen dadurch je nach Werkzeug anders aus. (2) **Abschneidefehler behoben:** `.results-window` definierte seine Rumpfzeile als `minmax(0,auto)`. Die Zeile wuchs damit auf die volle InhaltshÃ¶he (bei 78 Ergebniszeilen 2607 px in einem 635 px hohen Fenster), das Fenster schnitt sie Ã¼ber `overflow: hidden` ab, und der Rumpf bekam nie eine RollflÃ¤che â€” lange Ergebnistabellen brachen ohne jeden Hinweis ab. Mit `minmax(0,1fr)` bleibt das Fenster bei kurzem Inhalt inhaltshoch und begrenzt den Rumpf an der Fenstergrenze, sodass er rollt. (3) `min-width: 0` auf `.linked-results` und `.result-block`: ohne diese Angabe wuchs das Rasterelement auf die Inhaltsbreite seiner breitesten Tabelle, der TabellenbehÃ¤lter wurde nie schmaler als sein Inhalt und rollte deshalb nicht selbst â€” stattdessen rollte das gesamte Fenster seitlich. (4) Ãœberlaufende ErgebnisbehÃ¤lter deklarieren eigene Scrollbalken (`--line-strong` auf `--surface-inset`, 11 px) und schalten damit die Ã¼berlagerten, erst beim Scrollen sichtbaren Balken ab: sobald der Inhalt Ã¼berlÃ¤uft, ist die RollflÃ¤che dauerhaft sichtbar, weil eine nur teilweise sichtbare Tabelle sonst wie eine abgeschnittene aussieht. Der Vertrag ist als Abschnitt 17 â€žErgebnisblock (Results)" in `.claude/skills/assessor-ui/references/components.md` verankert und in Abschnitt 12 (Floating Window) verlinkt; er ersetzt dort die frÃ¼here Zusage â€žInhalt ist immer eine `.table`". Verifiziert mit `npm test` (420/420 bestanden, zwei neue Regressionen in `linked-results.test.ts`, die Blockform und Tabellenklasse fÃ¼r Blatt und Werkzeugtext gleichermaÃŸen erzwingen), `npm run build`, DesignprÃ¼fer (0 rohe Farbwerte, unverÃ¤nderte Verbotsbudgets) sowie live in Dark und Light: 78-Zeilen-Tabelle rollt mit 10 px breitem Balken statt abzubrechen, 8-Spalten-Tabelle rollt waagerecht im eigenen BehÃ¤lter ohne das Fenster mitzuziehen, kurzer Ergebnistext hÃ¤lt das Fenster weiterhin klein. |
| 2026-07-28 | Markdown-Darstellung der Maester-Ergebnistexte durchgÃ¤ngig korrigiert; die Nutzerbeispiele deckten fÃ¼nf getrennte Ursachen auf. (1) `LinkedResults` gab den Ergebnistext als reinen Text aus statt Ã¼ber `RichTextValue` â€” die eigentliche Ursache aller gezeigten FÃ¤lle: Rauten, Sternchen, Pipe-Ketten und Verweisklammern standen wÃ¶rtlich im Ergebnisfenster. (2) `parseInlineTable` verwarf eine vollstÃ¤ndig erkennbare Tabelle, sobald hinter der letzten Datenzeile noch ein Hinweissatz stand (Zellenzahl kein Vielfaches der Spaltenzahl); der Nachtext wird jetzt an der fehlenden Abschluss-Pipe erkannt, abgetrennt und als eigener Absatz ausgegeben, die strenge VielfachenprÃ¼fung bleibt fÃ¼r geschlossene Tabellen erhalten. (3) Die Vortextgrenze (`before`) wurde Ã¼ber eine LÃ¤ngenrechnung der Kopftexte bestimmt und lieÃŸ dadurch die erste Kopfzelle in der Ãœberschrift stehen ("Impacted resources  Status"); sie wird jetzt zellenweise von rechts gesucht. (4) Eine Ãœberschrift lÃ¤uft bis zum Zeilenende und verschluckte in einer kollabierten Zeile die gesamte nachfolgende Tabelle; `parseMarkdownBlocks` trennt Ãœberschrift, Tabelle und Nachtext nun auf. (5) `cellText` faltet jeden Leerraum innerhalb einer Zeile zu einem Leerzeichen â€” die Markdown-EinrÃ¼ckung vor AufzÃ¤hlungszeichen ist in der Anzeige also grundsÃ¤tzlich verloren, weshalb die am 2026-07-28 eingefÃ¼hrte einrÃ¼ckungsbasierte Erkennung dort nie greifen konnte. Sie ist durch `breakInlineUnorderedLists` ersetzt: Unterscheidungsmerkmal ist wie bei den nummerierten Listen die Wiederholung (ab zwei Markierungen je Zeile), Markierungen innerhalb einer Verweisauszeichnung und Tabellenzeilen zÃ¤hlen nicht mit. ZusÃ¤tzlich ist das Verweismuster als `LINK_PATTERN` an einer Stelle vereinheitlicht (Erkennung, Auswertung, Schutzbereiche) und erfasst nun verschachtelte Titelklammern (`[[RaviK] - Require app protection policy](Adresse)`) sowie leere Adressen (`[name@example.invalid]()`). Verifiziert mit `npm test` (418/418 bestanden, neun neue Regressionen in `markdown.test.ts` und `linked-results.test.ts`), `npm run build`, einem Durchlauf Ã¼ber alle 249 markdownhaltigen Maester-`Result`-Werte (0 verbliebene Rohauszeichnungen) sowie live an den vier vom Nutzer gemeldeten Funden. Bekannte RestfÃ¤lle: zwei `Description`-Werte mit fehlerhafter Quellsyntax (Backslash-Escape `**\*.onmicrosoft.com**`, Adresse mit Leerzeichen) â€” Backslash-Escapes sind eine bewusst nicht unterstÃ¼tzte Markdown-Erweiterung. |
| 2026-07-28 | Nutzerkorrektur zum Maester-Ergebnistext vom selben Tag: Der Text erscheint jetzt ausschlieÃŸlich im Results-Fenster Ã¼ber die Results-SchaltflÃ¤che (wie Maesters eigene HTML-Ansicht "Test result"), nicht mehr im Finding-Fliesstext. `FindingReader.tsx` wurde auf sein ursprÃ¼ngliches Verhalten zurÃ¼ckgesetzt ("Result" bleibt fÃ¼r jedes Werkzeug einheitlich ausgeblendet). Neue Funktion `resultMessageFor` (`features/linked-results/result-message.ts`) lÃ¶st den werkzeuggebundenen Ergebnistext Ã¼ber das Toolprofil auf; `LinkedResults`/`FloatingResultsWindow` zeigen ihn als neutralen Kasten (`--panel`/`--line`, keine Warnfarbe), sobald keine verknÃ¼pfte Ergebnisdatei vorliegt. `DatasetViewer.tsx` aktiviert die Results-SchaltflÃ¤che (Kachel- und Datensatzansicht) jetzt auch ohne verknÃ¼pfte Ergebnisdatei, sofern ein solcher Text vorliegt, und filtert ihn aus den Referenzhinweisen heraus, damit der bisherige irrefÃ¼hrende Inline-Kasten "Results (Referenz gefunden)" fÃ¼r diesen Fall nicht mehr erscheint. Grund: Dieselbe Aussage soll nicht doppelt (Fliesstext und Popup) stehen, und das Ergebnisfenster ist bereits der etablierte Ort fÃ¼r Ergebnisevidenz jeder Art. Verifiziert mit `npm test` (411/411 bestanden), `npm run build` sowie live am Datensatz CIS.M365.1.1.3 im Dummy-Mandanten (Text erscheint nur noch im Popup, Finding-Text und der alte Referenz-Hinweis sind frei davon). |
| 2026-07-28 | Eingebettete AufzÃ¤hlungen in Fliesstextfeldern (Remediation-Anleitungen von CIS-CAT/Maester) verschwanden ununterscheidbar im Absatz, weil die Werkzeuge echte Zeilenumbrueche beim Export zu einzelnen Leerzeichen kollabieren. `src/shared/markdown.ts` erkennt jetzt zwei zusaetzliche, konservative Signale: (1) eine lueckenlos ab 1 aufsteigende Zahlenfolge mit `.`-Terminator (`breakInlineOrderedLists`) - eine einzelne Ziffer bleibt bewusst Fliesstext, da `1.` ebenso gut eine Kennung wie "1.1.3 (L1)" sein kann; (2) ein Aufzaehlungszeichen nach drei oder mehr Leerzeichen (`INDENTED_BULLET`) - die urspruengliche Markdown-Einrueckung vor einem `-`/`*`/`+` bleibt beim Kollabieren erhalten und ist von gewoehnlichem Fliesstext (max. zwei Leerzeichen als Absatzabstand im Datenbestand) zuverlaessig unterscheidbar. Keine Verschachtelung: mehrere direkt aufeinanderfolgende nummerierte Abschnitte verschmelzen zu einer flachen Liste, bleiben aber als Listenpunkte lesbar statt als ein Absatz. Verifiziert mit `npm test` (407/407 bestanden, vier neue Regressionen in `markdown.test.ts`), `npm run build` und live am Datensatz CIS.M365.1.1.3 im Dummy-Mandanten (Remediation-Anleitung erscheint als 14 Listenpunkte statt Fliesstext). |
| 2026-07-28 | Maester-Excel-Ergebnistext im Reader korrigiert: (1) `ToolProfileDefinition.presentation` um optionales `resultMessageHeaders` erweitert (`tool-profile-definition.ts`), damit ein Toolprofil erklÃ¤ren kann, dass sein Feld "Result" der beschreibende Ergebnistext ist statt eines kurzen Status-Badges (Purple-Knight-Konvention bleibt unverÃ¤ndert Standard); Maester-Profil setzt `resultMessageHeaders: [/^result$/i]` (`maester-definition.ts`). (2) `FindingReader.tsx` loest das Toolprofil ueber die bereits vorhandene werkzeuggebundene Datensatzherkunft (`toolIdForRecord`) auf und zeigt das Feld dann als priorisierten Fliesstext statt es wie einen reinen Status-Header auszublenden; ein als Statusfeld verwendetes Vorkommen desselben Feldes wird weiterhin nicht doppelt angezeigt. (3) `isFileReference` in `result-linker.ts` verlangt jetzt zwingend eine erkannte Dateiendung oder einen Pfadtrenner, damit ein gewÃ¶hnlicher Ergebnissatz (z. B. Maesters Klartextmeldung) nicht mehr fÃ¤lschlich als Dateiverweis in der "Results (Referenz gefunden)"-Box erscheint. Grund: Maester und Purple Knight benennen ihre Excel-Spalte identisch ("Result"), meinen aber unterschiedliche Dinge â€” ohne diese Unterscheidung verschwand Maesters einziger Beleg fÃ¼r ein Finding vollstÃ¤ndig aus der Anzeige. Verifiziert mit `npm test` (403/403 bestanden, neue Regressionen in `finding-reader.test.ts` und `result-linker.test.ts`) und `npm run build` (Client und Server grÃ¼n). |
| 2026-07-28 | Maester-Excel-Ergebnistext im Reader korrigiert: (1) `ToolProfileDefinition.presentation` um optionales `resultMessageHeaders` erweitert (`tool-profile-definition.ts`), damit ein Toolprofil erklÃ¤ren kann, dass sein Feld "Result" der beschreibende Ergebnistext ist statt eines kurzen Status-Badges (Purple-Knight-Konvention bleibt unverÃ¤ndert Standard); Maester-Profil setzt `resultMessageHeaders: [/^result$/i]` (`maester-definition.ts`). (2) `FindingReader.tsx` loest das Toolprofil ueber die bereits vorhandene werkzeuggebundene Datensatzherkunft (`toolIdForRecord`) auf und zeigt das Feld dann als priorisierten Fliesstext statt es wie einen reinen Status-Header auszublenden; ein als Statusfeld verwendetes Vorkommen desselben Feldes wird weiterhin nicht doppelt angezeigt. (3) `isFileReference` in `result-linker.ts` verlangt jetzt zwingend eine erkannte Dateiendung oder einen Pfadtrenner, damit ein gewÃ¶hnlicher Ergebnissatz (z. B. Maesters Klartextmeldung) nicht mehr fÃ¤lschlich als Dateiverweis in der "Results (Referenz gefunden)"-Box erscheint. Grund: Maester und Purple Knight benennen ihre Excel-Spalte identisch ("Result"), meinen aber unterschiedliche Dinge â€” ohne diese Unterscheidung verschwand Maesters einziger Beleg fÃ¼r ein Finding vollstÃ¤ndig aus der Anzeige. Verifiziert mit `npm test` (403/403 bestanden, neue Regressionen in `finding-reader.test.ts` und `result-linker.test.ts`) und `npm run build` (Client und Server grÃ¼n). |
| 2026-07-27 | MITRE ATT&CK Matrix Aktualisierbarkeit & Panel-Redesign: (1) Dynamischer Lade- und Validierungs-Mechanismus in `mitre-graph.ts` (`validateMitreMatrixData`, `loadStoredMitreMatrix`, `saveStoredMitreMatrix`, `clearStoredMitreMatrix`) inklusive Dateiupload- und Reset-Steuerung im DataHub (`DataHub.tsx` & `datahub.css`) zum lokalen Einspielen neuer STIX/JSON-Matrizen (z. B. v19.x) ohne externe APIs; (2) Neugestaltung des MITRE Attack Paths Panels (`MitreGraphView.tsx` & `mitre-graph.css`) mit Path Risk Index Banner, Schnell-Preset â€žKritischste Kette", Nativ vs. Abgeleitet Mappings, klarer Unterscheidung in der Spalte â€žNicht zugeordnet" fÃ¼r werkzeugfremde Befunde (Maester, CIS-CAT) und strukturiertem 3-Spalten Detail-Inspector; (3) SÃ¤mtliche Ã¼brigen Anwendungsbereiche (Shell, Topbar, Sidebar, Work) blieben optisch zu 100 % unverÃ¤ndert. Verifiziert mit `npm test` (399/399 bestanden), `design-language-check.mjs` und `npm run build` (Client & Server grÃ¼n). |
| 2026-07-27 | UI-Korrekturen und Provenienz-Facettenbereinigung auf Nutzerwunsch: (1) Sechseck-Hakenposition in `.record-card`, `.data-tile-hex` und `.reader-title-hex` im unteren linken Bereich des Hexagons platziert (`left: 2px` bzw. `translate(-6.5px, 0.5px)` in `legacy-views.css` und `components.css`), exakt entsprechend der visuellen SOLL-Vorlage; (2) Badge im Results-Fenster (`.results-window-badge`) sowie geÃ¶ffnete Results-SchaltflÃ¤chen (`.results-btn.is-open`, `.tile-results-btn.is-open`) auf immer weiÃŸe Schrift (`color: var(--text-on-accent)`) umgestellt; (3) Redundante Herkunftsfilter `Quelle: Datei`, `Quelle: Blatt` und das virtuelle `Quelldatei`-Facet in `dynamic-facets.ts` automatisch unterdrÃ¼ckt, sobald `Quelle: Scan` vorhanden ist â€” Datenmodell, DatensÃ¤tze, Exporte und der Finding Reader behalten alle Provenienzdaten zu 100 % bei. Verifiziert mit `npm test` (399/399 bestanden) und `npm run build` (Client und Server grÃ¼n). |
| 2026-07-27 | Werkzeugtexte werden lesbar dargestellt statt als Markdown-Quelltext. Neu: `src/shared/markdown.ts` (Ueberschriften, Aufzaehlungen, Tabellen, Fett/Kursiv/Code/Verweise, rekursiv fuer verschachtelte Auszeichnung), angewendet in `RichTextValue` fuer unausgezeichnete wie fuer HTML-Werte. Maester liefert seine Tabellen einzeilig, deshalb erkennt der Parser auch die Pipe-Kette ohne Zeilenumbrueche und trennt Ueberschriften, die mitten in der Zeile stehen; nummerierte Aufzaehlungen bleiben bewusst unangetastet, weil `1.` ebenso eine Kennung wie "1.1.1 (L1)" sein kann. Ergebnistabellen aus Textfeldern (`ResultDetail`) werden als Blatt projiziert und sind ueber die Results-Schaltflaeche erreichbar; der Hinweis "keine Ergebnisdatei gefunden" nennt nur noch echte Dateiverweise. Zusaetzlich behebt `cellText` den Verlust der Zeilenstruktur in `buildRecord`. Verifiziert an der laufenden Anwendung: ueber 80 Maester-Datensaetze null rohe Markdown-Textknoten bei 138 Ueberschriften, 93 Aufzaehlungen, 264 Verweisen und 433 Fettstellen; PingCastle (37) und Purple Knight (40) unveraendert ohne Reste; Ergebnisfenster eines Warning-Funds zeigt die Tabelle mit 4 Spalten und 2 Zeilen; Kacheln mit Ergebnistabelle von 59 auf 72 gestiegen. |
| 2026-07-27 | Abweichungsachse in Work nachgezogen: der Ergebnisstatus erscheint in Kachel, Fundkarte und Reader nicht mehr als neutrale Plakette, sondern als Outcome mit Textfarbe und Glyph (`.outcome-mark`, eine gemeinsame Definition fuer Work und Result DB). Dabei fiel auf, dass die Projektaggregation eines Mandanten die Profil-ID `generic` traegt: PingCastles `Matched` wurde dadurch ueber die generische Rueckfallregel als `warning` statt als `fail` gelesen, Work zeigte 40 Warnungen gegenueber 3 in der Result DB. Die Werkzeugherkunft wird jetzt je Datensatz aus der Provenienzspalte â€žQuelle: Scan" aufgeloest (`toolIdForRecord`), Einzelblaetter tragen zusaetzlich `DatasetSheet.toolId`. Verifiziert: Work meldet mit Standardfilter 130 Treffer (127 `fail`, 3 `warning`) und ohne Filter 474 (169 `pass`, 127 `fail`, 169 `not_run`, 4 `not_applicable`, 3 `warning`, 2 `execution_error`) - identisch zur Result DB und zur Datenbank. |
| 2026-07-27 | Abweichungsachse eingefuehrt und Maester-`Investigate` damit sichtbar gemacht. Neu: versioniertes Praedikat `isDeviation`, abgeleitetes Projektionsfeld, Queryparameter und Facette `deviation` (In-Memory und PostgreSQL-Vorfilterung), Spalte und Segmentfilter â€žAbweichung" in der Result DB, Outcome-Zelle nach Designvertrag mit Textfarbe und Glyph statt Klartext. Maester-Standardfilter von `failed` auf `deviation` umgestellt; die Filter `failed`, `passed` und `skipped` bleiben unveraendert erhalten, ebenso Severity, `is_ioe` und `exposure_state` jedes Funds. Verifiziert gegen die laufende Datenbank: `deviation=true` (130) = `isIoe=true` (127) + `outcome=warning` (3), `deviation` true/false ergibt zusammen die Gesamtmenge (474), `pass` (169) and `fail` (127) unveraendert, Schnittmenge `deviation` mit `pass` leer. `npm test` (367 Tests) und `npm run build` gruen. |
| 2026-07-27 | Seitenkopf vereinheitlicht: Eyebrow-Label ueber dem Topbar-Titel (`area-topbar-kicker`) sowie die Hero-Bloecke in Result DB und DB-Struktur entfernt, Seitentitel verbleibt in der Topbar. Nav- und Topbar-Bezeichnung â€žErgebnisse" zu â€žResult DB" geaendert. Die â€žAktualisieren"-Aktion beider Seiten sitzt jetzt in der Metazeile (`.page-actions-row`). |
| 2026-07-27 | **Die zweite Agentensitzung (2026-07-26 18:42 bis 2026-07-27 01:44) wurde vollstÃ¤ndig zurÃ¼ckgenommen.** Auftrag war die Wiederherstellung der Optik. Grundlage war das Sitzungsprotokoll dieser Sitzung (`~/.codex/sessions/2026/07/26/rollout-*.jsonl`, 669 Werkzeugaufrufe, 51 Dateien mit nachgewiesenen Schreibzugriffen): Je Datei wurde der letzte vollstÃ¤ndige Lesestand **vor** dem ersten Schreibzugriff extrahiert; wo kein solcher Lesestand vorlag, wurde die im Protokoll dokumentierte Ersetzung am Ist-Stand invertiert â€” jeweils mit PrÃ¼fung auf exakte Textgleichheit und Abbruch bei Abweichung, damit keine Datei auf Verdacht geÃ¤ndert wird. 58 Dateien wiederhergestellt, 11 NeuschÃ¶pfungen entfernt (`SeverityHex`, `OutcomeIndicator`, `severity-normalization.ts` samt Test, `work-reference.css` in Projekt und Skill, `color-and-severity.md`, drei weitere neue Testdateien, dazu die schon zuvor geleerte HÃ¼lle `themes.css`). ZurÃ¼ckgenommen wurden insbesondere: die neue Shell in [App.tsx](../src/app/App.tsx) samt Umbenennung von sechs Klassennamen auf `legacy-*` in 20 Dateien; die kanonische Severity-Stufe `warning` Ã¼ber DomÃ¤nenmodell, Maester-Profil, Facetten, Graph und Work-Projektion; die Aufspaltung der Filterleiste in PrimÃ¤r- und Nebenfilter; sowie die geÃ¤nderte Severity- und Akzentpalette. **Drei Fehler entstanden in der Wiederherstellung selbst und wurden gefunden und behoben:** (1) Beim Wiedereinsetzen von `normalizeSeverity` wurden die Wortgrenzen `\b` als Backspace-Zeichen (0x08) geschrieben, wodurch die Funktion jede Severity auf `unknown` abbildete â€” sichtbar geworden durch `tests/importers/canonical-candidate-migration.test.ts`. (2) Die Protokollausgabe war latin1-dekodiert; 25 Umlaute und Trennzeichen in sieben Dateien waren dadurch doppelt kodiert und wurden gezielt zurÃ¼ckgerechnet. (3) `dynamic-facets.ts` musste aus zwei Teilausgaben zusammengesetzt werden und verlor dabei die Severity-Synonymnormalisierung; die PrÃ¼fung ergab, dass diese Normalisierung selbst eine ErgÃ¤nzung der zweiten Sitzung war (22:07) und samt ihrem Test entfÃ¤llt â€” der Testbestand liegt damit wieder bei 359 statt 360. Verifikation gegen die Baseline desselben Tages: 359 Standardtests und 7 Ã¼bersprungene, Local-only-PrÃ¼fung, DesignprÃ¼fer mit 0 rohen Farbwerten, 38 verbotenen Mustern und 179 Tokens, Client- und Serverbuild erfolgreich. Im Browser inhaltsfrei gemessen: die alte Shell ist vorhanden (`area-topbar`, `sidebar-context`, `sidebar-theme-panel`), von der neuen keine Spur (`context-strip`, `status-bar`, `band`, `segmented`, `severity-hex`); Tokens `--bg #121215`, `--panel #1A1A1E`, `--state-active #D9962A`, `--legacy-accent #7C5CF5`, `--critical #E8214F`, `--medium-badge #A16207`, `--control-height 30px`. **Bewusst nicht zurÃ¼ckgenommen:** Die Designsprache-Arbeit vom Nachmittag (Schritte 1 und 2) bleibt nach Nutzerentscheidung bestehen. Die als Referenz gelieferten Screenshots zeigen den Stand **vor** dieser Arbeit; die gemessenen Abweichungen sind AuswahlflÃ¤che `rgb(42,36,64)` statt Blau `#4a6f96`, ArbeitsflÃ¤che `rgb(18,18,21)` statt `#2b2b2b`, Kachelradius 3px statt 8px und fehlende Kachelschatten. Der Nutzer hat diese Abweichung ausdrÃ¼cklich akzeptiert. Die zwÃ¶lf ProtokolleintrÃ¤ge und drei Architekturentscheidungen der zweiten Sitzung bleiben als Historie erhalten und sind in Abschnitt 9 als zurÃ¼ckgezeichnet gekennzeichnet. Keine Schema-, Persistenz- oder MandantendatenÃ¤nderung. |
| 2026-07-30 | Titel-Zuordnung, Kachel-Raster, CIS-CAT-ZeilenumbrÃ¼che, Rule Result XML Formatierung, Ergebnis-Zuordnung und Detailblock-Verlinkung korrigiert: (1) Befund-Titel zeigten fÃ¤lschlicherweise Dateinamen oder Regel-IDs. Behoben in `record-builder.ts`, `generic-definition.ts` und `generic-field-rules.ts`. (2) Kachelansicht stellte sich beim ersten Ã–ffnen einzeilig dar. Behoben in `DatasetViewer.tsx`. (3) In CIS-CAT-Textfeldern standen vereinzelte Satzzeichen (`.`, `:`) auf eigenen Zeilen. Behoben durch `cleanLineBreaks` in `markdown.ts` und `cis-cat-source-extractor.ts`. (4) Bei Regeln mit Apostrophen/Sonderzeichen im Titel (z. B. Rule 2.2.2 `Ensure 'Access this computer...'`) schlug der reine Titel-String-Match fehl, weshalb `Description`, `Rationale`, `Remediation` und die Evidenz-Tabellen fehlten. Behoben in `cis-cat-source-extractor.ts` durch direkte Extraktion der `href="#detail-..."`-ID aus der Tabellenzelle, sodass alle Assessment-Evidenztabellen, Beschreibungen und Controls zu 100 % ausgelesen und zugeordnet werden. `npm test` (454 Tests passed), `npm run build` und Local-only-Check erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-30 | Titel-Zuordnung fÃ¼r CIS-CAT, PurpleKnight und generische Berichte korrigiert: Befund-Titel in Karten, Kacheln und Lesespaltentitel zeigten fÃ¤lschlicherweise den Dateinamen (z. B. `WIN-...html`) oder die Regel-ID (z. B. `SI000055`) anstelle des tatsÃ¤chlichen Namens (`Permission changes on AdminSDHolder object`). Ursache 1: `titleTokens` in `record-builder.ts` prÃ¼fte `label.includes('name')`, wodurch `ShortName` vor `Name` gematcht wurde. Ursache 2: `titleTokens` enthielt weder `benchmark item`, `benchmark` noch `recommendation` und wich auf `Quelle: Datei` als erste gefÃ¼llte Spalte aus. Ursache 3: ID-Kopfzeilen (`ShortName`, `Rule ID`, `Control ID`, `ID` etc.) wurden bei der Token-Abfrage nicht gefiltert. Behoben in `record-builder.ts` (`isIdHeader` filtert ID-Spalten bei der Titel-Suche aus, `titleTokens` um `benchmark item`, `benchmark`, `recommendation` erweitert, Provenienzspalten vom Fallback ausgeschlossen) sowie in `generic-definition.ts` und `generic-field-rules.ts`. Regressions-Tests in `analysis.test.ts` ergÃ¤nzt. `npm test` (451 Tests passed), `npm run build` und Local-only-Check erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-27 | Visuelle Korrektur innerhalb Schritt 5 der UI-Konsolidierung umgesetzt, ohne eine Hauptphase als abgeschlossen zu markieren: Work verwendet wieder eine deutliche Ableton-orientierte Flaechenhierarchie statt nahezu gleich heller generischer Karten. Skill und Laufzeit definieren fuer Dark und Light dieselben abgeleiteten Rollen fuer Master-Rail, Arbeitsobjekte und Hover; Listen, Tiles und kuenftige datenreiche Ansichten verwenden sie gemeinsam. Reader-Inset und vertikale Leerstelle wurden auf das 4-px-Raster reduziert, die maximale Lesebreite zentralisiert und Kopfaktionen bleiben auf breiten Flaechen in derselben kompakten Zone. Tile-Badges sind auf vier sichtbare Werte mit `+n` begrenzt. Bestaetigte Regeln fuer Primaer-/Nebenfilter, Auswahlblau, Aktionsviolett, Severitys, Warning und Sechseck blieben unveraendert. Inhaltsfreie Browserpruefung bestaetigte die ausgelieferten Light-Rollen sowie identische Dark-/Light-Vertraege. `npm test`: 372 bestanden, 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen; Local-only- und Designpruefung gruen, 194 Tokens, 0 Rohfarben und 18 verbleibende Alt-Muster. Client-/Serverbuild erfolgreich; bekannte Chunkgroessenwarnung bei 896,53 kB bleibt. Keine Schema-, Persistenz- oder Datenaenderung. |
| 2026-07-26 | Nutzerkorrektur der Farbrollen als querschnittliche UI-Konsolidierung zwischen Schritt 3 und 4 umgesetzt, ohne Phasenabnahme: Das Auswahlblau `#85BFF2` bleibt fÃ¼r aktive Navigation, Auswahl, Information und Fokus unverÃ¤ndert. Die separate Filterfarbe `#677DBF` und ihre vier `--filter-active*`-Tokens wurden entfernt; PrimÃ¤raktionen, aktive Ansichten und alle Work-/Command-Band-Filter verwenden jetzt in beiden Themes `#A68AF9` mit weiÃŸer Tinte. Gesetzte Filter bleiben Ã¼ber Wert beziehungsweise Trefferzahl sowie stÃ¤rkere Gewicht erkennbar. Skill- und Laufzeittokens, zentrale Band-Komponente, Work-Ãœbergangsregel, Farb-/Zustandsreferenz, Review-Checkliste und Drift-Test sind synchronisiert. Inhaltsfreie BrowserprÃ¼fung bestÃ¤tigte in Light und Dark `#A68AF9`/`#FFFFFF` fÃ¼r die Aktions-/Filterrolle, `#85BFF2` fÃ¼r aktive Navigation und das Fehlen der entfernten Filterrolle; das Ausgangstheme Light wurde wiederhergestellt, zwei Verbindungsindikatoren blieben aktiv. 359 Standardtests, Local-only- und DesignprÃ¼fung erfolgreich; 7 optionale PostgreSQL-Integrationen erwartungsgemÃ¤ÃŸ Ã¼bersprungen, 181 Tokens, 0 Rohfarben und 30 verbleibende Alt-Muster. Client- und Serverbuild erfolgreich; bekannte GrÃ¶ÃŸenwarnung des 890,33-kB-Clientchunks unverÃ¤ndert. Keine Schema-, Persistenz- oder DatenÃ¤nderung. |
| 2026-07-26 | Schritt 1 und 2 der Designsprache abgeschlossen: **kein roher Farbwert mehr auÃŸerhalb der Tokendateien** (85 â†’ 0). Umgestellt wurden `mitre-graph.css` (34), `components.css` (30), `layout.css` (20) und `import-workflow.css` (1). Ersatzlos entfernt statt umgestellt: der Dateistatus-Block der Topbar (`.topbar-project-kpis`, `.topbar-kpi`, vier `.kpi-*`), dessen Markup schon am 2026-07-25 entfallen war; die doppelten Neomorph-Schatten und der 12px-Radius der Kachel samt Hover-Versatz; die weiche Aura des Verbindungspunktes; der Ring-Schatten der Graph-Auswahl; und zehn Light-Sonderregeln in `mitre-graph.css` sowie drei in `components.css`. Verbliebene Light-Regeln sind vier Logotausche Ã¼ber Deckkraft â€” ein zweifarbiges Logo ist keine semantische Rolle. Zustandsdarstellungen an die Sprache angeglichen: die Trefferlistenauswahl trÃ¤gt getÃ¶nte FlÃ¤che plus Akzentrahmen statt VollfÃ¼llung, damit die Severity-Kante daneben sichtbar bleibt; die Workspace-SchaltflÃ¤che unterscheidet leer (gedÃ¤mpft), gefÃ¼llt (Erledigt-Ton als Umriss) und aktiv (AkzentflÃ¤che), statt drei GrÃ¼ntÃ¶ne zu mischen. **Abweichung von der Designsprache, mit Messung begrÃ¼ndet:** deren Severity-Palette mit `--sev-on` (weiÃŸ) erreicht auf 11px-Versaltext nur 2.65:1 (medium) bis 4.41:1 (critical) und verfehlt damit die 4.5:1, die Abschnitt 4 derselben Checkliste fordert. Die dunkleren Alt-TÃ¶ne halten 5.02:1 bis 6.29:1 und bleiben als `--*-badge` in `tokens.css` stehen, bis die Rolle in `ui-tokens.css` nachgezogen ist; fÃ¼r dunkle Tinte auf gefÃ¼llter SignalflÃ¤che (Hexagon, Badge â€žmedium") gibt es das Token `--severity-ink`. Der PrÃ¼fer fÃ¼hrt die Verbotsliste jetzt vollstÃ¤ndig: rohe Farbwerte 0, verbotene Muster 102 â†’ 38 (`!important` 5, Radien Ã¼ber 4px 7, Schatten auÃŸerhalb der Overlay-Rollen 22, Light-Fixes 4, Seitenselektoren 0). Im Browser in beiden Skins gemessen: Textkontrast auf der ArbeitsflÃ¤che 15.3:1 dunkel und 15.84:1 hell, Sidebar `rgb(13,13,16)` beziehungsweise `rgb(228,228,234)`, Statuspunkt `rgb(46,158,107)` beziehungsweise `rgb(30,122,80)` und ohne Schatten, keine unaufgelÃ¶sten Tokens. 359 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder KomponentenÃ¤nderung. |
| 2026-07-26 | Designsprache Schritt 1 und 2: Altwerte auf die neuen Rollen abgebildet, Themedatei entfallen, PrÃ¼fer um die Verbotsliste erweitert. (1) [tokens.css](../src/styles/tokens.css) enthÃ¤lt keinen eigenen Farb- oder MaÃŸwert mehr, sondern leitet jeden Altnamen an eine semantische Rolle aus `ui-tokens.css` weiter; vier Ausnahmen sind einzeln begrÃ¼ndet (`--radius-pill` fÃ¼r den auf Nutzerwunsch runden Ansichtsmodus, `--reader-inset`, `--ui-glyph-size` fÃ¼r SymbolschaltflÃ¤chen, die gemischte FehlerflÃ¤che `--danger-surface`). (2) [themes.css](../src/styles/themes.css) ist damit gegenstandslos und aus `main.tsx` entfernt: der helle Skin entstand dort als eigener Tokenblock plus zwanzig Klassenregeln, die den Skinwechsel fÃ¼r `layout.css`, `components.css` und `legacy-views.css` nachreichten â€” beides ersetzt die Rollendefinition beider Skins in `ui-tokens.css`. (3) Der PrÃ¼fer setzt jetzt zusÃ¤tzlich die Verbotsliste aus Abschnitt 1 der Review-Checkliste durch: `!important`, Radien Ã¼ber 4px, Schatten auÃŸerhalb der Overlay-Rollen, seitenspezifische Ãœberschreibungen und Light-Mode-Fixes per Selektor, jeweils als ausschlieÃŸlich schrumpfende Obergrenze je Datei. Seitenselektoren prÃ¼fen bewusst nur `.page-*`; die von der Checkliste zusÃ¤tzlich genannten `.view-*` und `.screen-*` sind im Bestand Komponentennamen (`.view-tabs`, `.view-table`) und keine Seitenskopierung. Jede der fÃ¼nf Regeln wurde einzeln durch einen absichtlich eingefÃ¼gten VerstoÃŸ als wirksam nachgewiesen, ebenso die Absenkmechanik. **Sichtbare Folgen, bewusst in Kauf genommen:** die ArbeitsflÃ¤che des dunklen Skins wird von `#2b2b2b` auf `#121215` dunkler und die des hellen von mittelgrau `#bfbfbf` auf `#F1F1F4` mit weiÃŸen Panels heller â€” beides kehrt die frÃ¼here Ableton-Festlegung â€žChrome ist mittelgrau, nie weiÃŸ, nie fast schwarz" um; Steuerelemente wachsen von 24px auf 30px, Zeilen von 26px auf 32px, Radien von 2/3px auf 3/4px, AbstÃ¤nde rastern auf 4/8/12/16/20/24px; Kachelschatten entfallen ersatzlos. Im Browser in beiden Skins gemessen: dunkel `--bg #121215`, `--panel #1A1A1E`, `--text #E8E8EC`; hell `--bg #F1F1F4`, `--panel #FFFFFF`, `--text #17171C`; `--control-height` 30px, `--legacy-radius-sm` 3px, `--shadow-raised: none`; 116 referenzierte Tokens, keine unaufgelÃ¶sten auÃŸer den beiden komponentenlokalen `--severity` und `--kpi-accent`. Verbotene Muster im Restbestand von 102 auf 62 gesunken, Stildateien von 110 Zeilen `themes.css` befreit. 359 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder KomponentenÃ¤nderung. **Offen:** die leere HÃ¼lle `src/styles/themes.css` ist noch nicht gelÃ¶scht. |
| 2026-07-26 | Designsprache als Projektskill installiert und ihr Tokenset additiv in den Build gezogen: `.claude/skills/assessor-ui/` (SKILL.md, `assets/tokens.css`, `assets/components.css`, vier Referenzdateien) ist ab jetzt die verbindliche Quelle fÃ¼r alles Sichtbare. Die Ãœbernahme erfolgte **nicht** als Ersetzung der bestehenden Stildateien, wie in der Installationsanleitung des Pakets vorgesehen: Ein Abgleich vor dem Kopieren ergab zwei disjunkte Vokabulare â€” 33 der 70 im Projekt referenzierten Tokens wÃ¤ren undefiniert geblieben (`--bg`, `--panel`, `--critical`, `--ui-body-size` â€¦) und keine der 48 Altklassen wÃ¤re weiter bedient worden. Umgesetzt ist deshalb: (1) `src/styles/ui-tokens.css` als Projektkopie des Skill-Tokensets, geladen als erste Tokenquelle; (2) `src/styles/layers.css` mit der zwingenden Reihenfolge `@layer tokens, base, shell, components, utilities;` als erstes Stylesheet; (3) AuflÃ¶sung der zehn Namenskollisionen durch Umbenennung im Altbestand auf `--legacy-accent`, `--legacy-accent-active`, `--legacy-radius-sm`, `--legacy-radius-md` und `--legacy-space-1` bis `--legacy-space-6` â€” Werte unverÃ¤ndert, 197 Referenzen in acht Stildateien; (4) `src/styles/ui-components.css` liegt im Projekt, ist aber **bewusst noch nicht in `main.tsx` importiert**. Grund fÃ¼r (4) war eine im Browser gemessene stille Regression: `.btn`, `.icon-btn`, `.input`, `.select`, `.tile-grid` und `.is-bookmarked` existieren in beiden Systemen, und da der Altbestand auÃŸerhalb der Layer liegt, gewinnt er nur bei gemeinsamen Eigenschaften â€” die zusÃ¤tzlichen Eigenschaften der neuen Regel wirkten trotzdem und setzten bestehende SchaltflÃ¤chen auf `height: 30px`, `gap: 8px`, `justify-content: center` statt der bisherigen MindesthÃ¶he von 24px. Nach RÃ¼cknahme des Imports messen bestehende SchaltflÃ¤chen wieder 27,5px HÃ¶he bei 24px MindesthÃ¶he, Radius 2px, kein `gap`. Der DesignprÃ¼fer wurde an die neue Sprache angepasst: `ui-tokens.css` gilt als Tokenquelle, die SchriftgrÃ¶ÃŸenuntergrenze sinkt nach Nutzerentscheidung von 12px auf 11px (kleinste Stufe `--fs-micro`, ausschlieÃŸlich Versal-Badges, SpaltenkÃ¶pfe und ZÃ¤hler), und die PrÃ¼fung erfasst zusÃ¤tzlich die `--fs-*`-Tokendefinitionen, die sie bisher nicht sah. Baseline der Verbotsliste aus `references/review-checklist.md` gegen den Ist-Stand: 115 rohe Farbwerte auÃŸerhalb der Tokendateien, 5 `!important`, 13 Radien Ã¼ber 4px, 29 `box-shadow` auÃŸerhalb der Overlay-Rollen, 3 seitenspezifische Ãœberschreibungen, 1 SchriftgrÃ¶ÃŸe auÃŸerhalb der Skala, 56 `[data-theme="light"]`-Ãœberschreibungen auÃŸerhalb der Tokendateien. 359 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer (13 Stildateien, 179 Tokens) und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder KomponentenÃ¤nderung; ausschlieÃŸlich Stildateien, `main.tsx`, der DesignprÃ¼fer und der neue Skill. |
| 2026-07-26 | Ergebnistabellen ausschlieÃŸlich schwebend, mittig geÃ¶ffnet und Ã¼ber die SchaltflÃ¤che umschaltbar: (1) Der Reader rendert die verknÃ¼pften Tabellen nicht mehr inline â€” sie standen dort ein zweites Mal in der Lesespalte. Der Aufklapper bleibt nur fÃ¼r den Fall erhalten, dass eine Referenz vorliegt, die zugehÃ¶rige Ergebnisdatei aber nicht geladen ist; dann ist die Results-SchaltflÃ¤che abgeschaltet und der Hinweis die einzige ErklÃ¤rung. (2) Das Fenster Ã¶ffnet mittig: eine erste SchÃ¤tzung aus den HÃ¶chstmaÃŸen des Stils, unmittelbar nach dem EinhÃ¤ngen einmalig anhand der tatsÃ¤chlichen GrÃ¶ÃŸe nachzentriert; mehrere gleichzeitig geÃ¶ffnete Fenster versetzen sich weiterhin Ã¼ber `offset`. (3) Ein zweiter Klick auf die Results-SchaltflÃ¤che schlieÃŸt das Fenster wieder â€” in Datensatzansicht und MITRE-Graph gleichermaÃŸen; nach vorn geholt wird ein Fenster Ã¼ber einen Klick auf das Fenster selbst. Im Browser gemessen: Fenstermitte [924, 595] gegenÃ¼ber Bildschirmmitte [925, 595], keine Inline-Tabelle im Reader, zweiter Klick schlieÃŸt das Fenster und nimmt die EinfÃ¤rbung der SchaltflÃ¤che zurÃ¼ck. Die Zusage in `tests/features/finding-reader.test.ts` wurde auf das neue Verhalten gezogen und um den Hinweisfall ergÃ¤nzt. 359 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | Ergebnisfenster und Reader-Ãœberschrift aufgerÃ¤umt: Die Kopfleiste des Ergebnisfensters trÃ¤gt nur noch die Kennzeichnung (â€žResults (n)"); der Fundname steht jetzt als Ãœberschrift im Fensterrumpf und ersetzt dort die zuvor wiederholte Dateibezeichnung der Ergebnisquelle â€” eine Angabe, die im Reader ohnehin unter den Zusatzinformationen steht. Da die Kopfzeile den Namen nicht mehr enthÃ¤lt, trÃ¤gt der Dialog seinen Namen Ã¼ber `aria-label` statt Ã¼ber einen Verweis auf die Kopfzeile. Die Ãœberschrift im Rumpf nutzt dieselbe Typografie wie die Finding-Ãœberschrift des Readers. Der Fundname im Reader steht ebenfalls auf dieser Stufe (18px statt `clamp(18px, 1.6vw, 23px)`) und nutzt die volle Breite der Lesespalte: die SchaltflÃ¤chen Bookmark und Results rÃ¼cken in eine eigene Zeile darunter, statt den Titel zu beschneiden. Im Browser gemessen: Kopfleiste enthÃ¤lt nur â€žResults (2)", Dateibezeichnung nicht mehr vorhanden, Ãœberschrift im Rumpf und Reader-Titel je 18px, Titelbreite 792 von 834 Pixeln der Lesespalte. 358 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | **Verweisziele aus Berichten bleiben erhalten â€” Sicherheitsmodell geÃ¤ndert (Nutzerfreigabe).** Die Belegstellen der Werkzeuge gingen an zwei Stellen verloren: Der Excel-Importer las Ã¼ber `sheet_to_json` nur Zellwerte, wÃ¤hrend Excel das Ziel als eigene Zelleigenschaft fÃ¼hrt; und die HTML-Extraktion entfernte `href` pauschal als aktives Attribut. ZusÃ¤tzlich lieferte `textFromNode` Tabellenzellen als reinen Text, sodass selbst ein erhaltenes `href` den Feldwert nie erreicht hÃ¤tte. Neue Regel statt pauschaler Entfernung: `href` bleibt ausschlieÃŸlich an einem Anker und ausschlieÃŸlich als `http:`/`https:`-Adresse erhalten, jedes andere Schema sowie `xlink:href` und alle Ã¼brigen aktiven Attribute werden unverÃ¤ndert entfernt; Ã¼bernommene Werte werden normalisiert neu geschrieben, und Zellen mit Verweisen maskieren ihren Textinhalt, damit ein Bericht kein eigenes Markup einschleusen kann. Die Darstellung prÃ¼ft Ã¼ber `safeHref` ein zweites Mal und rendert nur mit `target="_blank"` und `rel="noopener noreferrer"`. Excel Ã¼bernimmt das zellgebundene Ziel derselben PrÃ¼fung; das Format kennt hÃ¶chstens ein Ziel je Zelle, mehrere Belegstellen in einer Zelle bleiben daher unverlinkter Text. CSV benÃ¶tigt keine Ã„nderung, da nackte Adressen bereits in der Darstellung erkannt werden. [SECURITY.md](../SECURITY.md) um den Abschnitt â€žVerweisziele aus Berichten" ergÃ¤nzt. Drei Regressionen ergÃ¤nzt beziehungsweise geschÃ¤rft: HTML (Web-Adresse bleibt, `javascript:`, `data:` und `file:` verschwinden, eingeschleustes Markup wird maskiert), Excel (Zellverweis wird Ã¼bernommen, Skriptschema nicht), Node-Importlaufzeit (Ereignisattribute fallen weiterhin heraus, sichere Verweise Ã¼berleben). Die frÃ¼here ZÃ¤hlzusage `removedContentCount >= 3` wurde durch inhaltliche PrÃ¼fungen ersetzt, da ein erhaltenes `href` die Zahl zu Recht senkt. **Bereits importierte Berichte tragen die Ziele nicht; sie erscheinen erst nach einem Reimport.** 358 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine SchemaÃ¤nderung. |
| 2026-07-26 | FacettenzÃ¤hler auf echte Facettenlogik umgestellt und Arbeitsgruppe durchgehend eingefÃ¤rbt: (1) Die ZÃ¤hler arbeiteten kaskadierend von links nach rechts, wodurch eine Auswahl bei â€žCategory" die davor stehende Facette â€žSeverity" unverÃ¤ndert lieÃŸ, obwohl sich deren Treffermenge geÃ¤ndert hatte. Jede Facette zÃ¤hlt jetzt gegen **alle Ã¼brigen** gesetzten Filter (`recountFacetsAgainstActiveFilters`); der eigene Filter bleibt ausgenommen, sonst zeigte eine gesetzte Facette fÃ¼r alle nicht gewÃ¤hlten Werte null. Beide Richtungen im Browser geprÃ¼ft: Category â€žAnomalies" korrigiert Severity auf Summe 20 (High 0, medium 4, low 7, info 9) bei 20 Treffern; Severity â€žCritical" korrigiert Category auf Summe 6, wobei die jeweils gesetzte Facette ihre vollstÃ¤ndigen Zahlen behÃ¤lt. (2) Die violette GruppenflÃ¤che ist entfallen â€” sie verwÃ¤sserte den Aktivton; das Token `--accent-surface` wurde ersatzlos entfernt. (3) Alle Arbeitsfilter sind durchgehend im Aktivton gefÃ¼llt, nicht mehr nur die gesetzten; die aufgeklappte Optionsliste bleibt in der gewohnten Darstellung. Ob ein Filter wirkt, bleibt an der Beschriftung ablesbar (Wert samt Trefferzahl gegenÃ¼ber â€ž: Alle"), gesetzte Filter zusÃ¤tzlich durch stÃ¤rkeres Schriftgewicht. (4) Purple Knight legt seine Belegstellen als Abschnitt â€žReferences" in dieselbe Zelle wie den vorangehenden FlieÃŸtext; der Reader trennt den Block jetzt in ein eigenes Feld ab. Die Aufteilung geschieht bewusst in der Darstellung und nicht beim Import, damit der kanonische Feldwert die Quellzelle bleibt (AGENTS.md: Originalwerte und Provenienz erhalten) und bereits importierte Berichte ohne erneuten Import profitieren. Die Verweisziele bleiben verloren, da Purple Knight sie als Hyperlinks der Excel-Zelle hinterlegt und der Importer nur den Zelltext liest. Im Browser verifiziert: â€žReferences" erscheint als eigenes Feld, â€žLikelihood of compromise" enthÃ¤lt den Block nicht mehr. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | Kennzeichnung offener Ergebnisfenster und gesetzter Filter vereinheitlicht: (1) Die Results-SchaltflÃ¤che im Reader trug bisher keinen Zustand â€” nur die Kacheln zeigten Ã¼ber `resultColor` an, dass ein Ergebnisfenster zu diesem Fund offen ist. `DatasetViewer` reicht den Zustand jetzt als `resultsOpen` an `FindingReader` durch, die SchaltflÃ¤che nutzt dieselbe `.results-btn.is-open`-Kennzeichnung wie die Kacheln. (2) Gesetzte Filter tragen den Aktivton als **VollflÃ¤che** statt als Rahmen: die Arbeitsgruppe ist selbst umrandet, wodurch ein weiterer Rahmen darin zu leise blieb; die gefÃ¼llte FlÃ¤che ist davon eindeutig unterscheidbar. (3) Der Rahmen der Arbeitsgruppe wechselt vom Markenton auf den Aktivton und ist 2px stark. (4) â€žResult message" gehÃ¶rt jetzt zu den Arbeitsfiltern. Im Browser gemessen: Gruppe enthÃ¤lt Ergebnisstatus, Severity, Category, MITRE ATT&CK, MITRE D3FEND, Target und Result message; Gruppenrahmen 2px `rgb(255,168,37)`; gesetzter Filter FlÃ¤che `rgb(255,168,37)` mit Schrift `rgb(31,31,31)`; Results-SchaltflÃ¤che wechselt beim Ã–ffnen des Fensters auf denselben Ton. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | ZurÃ¼cksetzen behÃ¤lt den gelesenen Fund: `resetFilters` setzte die Auswahl bedingungslos auf den ersten Datensatz des Blattes, wodurch man beim Aufheben eines Filters die Stelle verlor, an der man gerade gearbeitet hat. Der ausgewÃ¤hlte Fund bleibt jetzt erhalten, solange er im Standardfilter vorkommt; andernfalls fÃ¤llt die Auswahl auf den obersten sichtbaren Fund. Die Ersatzwahl nutzt bewusst `filterAndSortRecords` mit denselben Vorgaben wie die Trefferliste â€” eine erste Fassung filterte nur den Status und landete dadurch auf dem ersten Fund der unsortierten Blattreihenfolge statt auf dem obersten angezeigten. Im Browser beide FÃ¤lle geprÃ¼ft: ein im Standardfilter enthaltener Fund bleibt Ã¼ber einen gesetzten und wieder zurÃ¼ckgesetzten Kategoriefilter hinweg ausgewÃ¤hlt; ein bestandener Fund (Status â€žBestanden") wird nach dem ZurÃ¼cksetzen durch den obersten sichtbaren ersetzt. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | Trefferliste, Lesespalte und Filtermarkierung nachgeschÃ¤rft: (1) Gesetzte Filter tragen statt einer Haarlinie einen 2px-Rahmen mit Versatz und zusÃ¤tzlichem Innenring â€” auf der eingefÃ¤rbten GruppenflÃ¤che des hellen Skins war die Haarlinie kaum zu sehen. (2) Die Karten der Trefferliste sind hÃ¶her (62 â†’ 78px), stehen mit 8px Abstand statt 3px, tragen 8px-Ecken und denselben Schattenwurf wie die Kacheln; sie liegen damit auf `--panel-raised` und heben sich beim Ãœberfahren um 1px. Die Position des Hakens im Severity-Hexagon folgt jetzt der Polsterung, statt auf einen festen Pixelwert der alten Dichte zu zeigen. (3) Die Lesespalte war in ihrer Spalte zentriert, wodurch auf breiten Bildschirmen eine groÃŸe leere FlÃ¤che zwischen Trefferliste und Text stand. Sie steht jetzt linksbÃ¼ndig mit festem Abstand Ã¼ber das neue Token `--reader-inset` (80px), das auf schmalen Fenstern Ã¼ber Medienabfragen auf 22px beziehungsweise 12px zurÃ¼ckgeht. Im Browser gemessen: KartenhÃ¶he 78px, Ecken 8px, Abstand 8px, Schatten gesetzt, Abstand Trefferliste zu Text exakt 80px, Filterrahmen 2px in `rgb(255,168,37)`. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | â€žTarget" in die hervorgehobene Filtergruppe aufgenommen und deren Zusammensetzung an die Bedeutung gebunden: Die Gruppe wurde bisher Ã¼ber eine feste Anzahl (die ersten fÃ¼nf Facetten) bestimmt. Bei einem Bericht ohne eine dieser Facetten wÃ¤re dadurch eine beliebige andere nachgerÃ¼ckt. Stattdessen entscheidet jetzt dieselbe Liste, die auch die Reihenfolge festlegt: Ergebnisstatus plus die als Arbeitsfilter benannten Spalten (`isPrimaryFacet` in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts)). Reihenfolge damit Ergebnisstatus â†’ Severity â†’ Category â†’ MITRE ATT&CK â†’ MITRE D3FEND â†’ Target. Im Browser verifiziert: die sechs genannten Facetten liegen in der Gruppe, Quelle-, Result-message- und SI-version-Filter auÃŸerhalb. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-26 | Lesespalte auf die fachliche Aussage reduziert und nackte Adressen anklickbar gemacht: Herkunftsfelder (`Quelle: Datei`, `Quelle: Blatt`, `Quelle: Scan`), Kennungen (`Rule ID`, `ShortName`, `SI version`, `Target`, `Runtime`), `Points Scale` und die ANSSI-Referenzen erscheinen nicht mehr im Finding-Abschnitt, sondern unter den Zusatzinformationen â€” sie sind Ã¼ber die Filterleiste erreichbar beziehungsweise reine Nachschlagewerte und drÃ¼ckten die eigentliche Aussage nach unten. ZusÃ¤tzlich erkennt [RichTextValue](../src/components/RichTextValue/RichTextValue.tsx) jetzt nackte http- und https-Adressen im FlieÃŸtext und rendert sie als Verweise: mehrere Werkzeuge liefern ihre Belegstellen als reine Textliste â€” PingCastle etwa das Feld â€žDocumentation" mit aneinandergereihten Microsoft-Learn-Adressen â€”, die mangels HTML-Auszeichnung bisher toter Text blieben. AbschlieÃŸende Satzzeichen und Klammern gehÃ¶ren nicht zur Adresse; innerhalb bereits ausgezeichneter Anker wird nicht erneut verlinkt, sodass keine verschachtelten Anker entstehen. Die erzeugten Verweise tragen dieselbe Absicherung wie bestehende Anker (`target="_blank"`, `rel="noopener noreferrer"`, ausschlieÃŸlich http/https), da Berichtsinhalte als nicht vertrauenswÃ¼rdig gelten. Im Browser verifiziert: PingCastle-Fund zeigt im Finding-Abschnitt nur noch Description, Advised solution, Documentation, Technical explanation und Verwandte Daten; Purple-Knight-Fund nur Result message, Number of results, Description, Remediation und Likelihood of compromise; die vier Dokumentationsadressen sind Verweise mit korrektem `target` und `rel`. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Filterleiste als Arbeitswerkzeug geschÃ¤rft: (1) **Kaskadierende ZÃ¤hler** â€” jede Facette zeigt jetzt die Trefferzahlen, die sich aus den davor stehenden Filtern ergeben, statt gegen den unverÃ¤nderten Gesamtbestand zu zÃ¤hlen (`cascadeFacetCounts` in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts)). Der eigene Filter greift bewusst erst nach dem ZÃ¤hlen, sonst zeigte jede gesetzte Facette fÃ¼r alle nicht gewÃ¤hlten Werte null; die Werteliste bleibt vollstÃ¤ndig, damit eine Auswahl nicht verschwindet, sobald sie gerade keine Treffer hat. (2) **Feste Arbeitsreihenfolge** Ergebnisstatus â†’ Severity â†’ Category â†’ MITRE ATT&CK â†’ MITRE D3FEND, danach Herkunfts- und Reviewfacetten. Die Reihenfolge hÃ¤ngt zusÃ¤tzlich an der SpaltenÃ¼berschrift, weil die Rollenerkennung bei Purple Knight â€žSeverity" und â€žCategory" nur als `additional` einstuft â€” die Rollenpriorisierung griff dort nicht und die wichtigsten Filter standen am Ende. (3) Die fÃ¼nf vorderen Facetten liegen in einer **mit dem Markenton hinterlegten Gruppe** (`--accent-surface`). (4) **Gesetzte Filter bleiben umrandet** (`is-filtered`, Aktivton). (5) â€žStandardfilter" heiÃŸt jetzt **â€žZurÃ¼cksetzen"** und ist dauerhaft im Aktivton eingefÃ¤rbt bei unverÃ¤nderter Funktion; die Regel braucht erhÃ¶hte SpezifitÃ¤t, da die Ãœbergangsregel fÃ¼r `.btn` im hellen Skin sonst gewinnt. (6) Die rohe Statusspalte erscheint nicht mehr zusÃ¤tzlich als Filter, da die Facette â€žErgebnisstatus" dieselbe Aufgabe erfÃ¼llt â€” bisher wurde sie nur bei sicher erkannter Rolle ausgeblendet. Im Browser verifiziert: Reihenfolge und GruppenzugehÃ¶rigkeit korrekt, ZurÃ¼cksetzen `rgb(240,160,32)`, Severity- und Category-ZÃ¤hler summieren sich auf 57 statt 156, nach Wahl von â€žCritical Â· 6" fallen die Category-ZÃ¤hler auf Summe 6 und die Trefferanzeige auf 6. Die Zusage in `tests/features/dynamic-facets.test.ts` wurde auf das neue Verhalten gezogen. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Lesestufe eingefÃ¼hrt und PingCastle-DetailflieÃŸtext aus dem Finding-Abschnitt genommen: Die Ableton-Dichte war fÃ¼r die Lesespalte zu weit getrieben â€” der FlieÃŸtext des Finding-Abschnitts war von zuvor 17px auf 14px gefallen. Neue Tokens `--ui-reading-size` (1rem/16px) und `--ui-reading-heading-size` (1.125rem/18px) trennen die LeseflÃ¤che von der dichten Werkzeugtypografie: `.reader-summary` und das Ergebnisfenster stehen auf der Lesestufe, wÃ¤hrend Plaketten und TabellenkÃ¶pfe bei 12px, Bedienelemente bei 13px und Listen bei 14px bleiben. Am laufenden Reader gemessen: h3 18px, h4 16px, FlieÃŸtext und `rich-text-value` 16px. ZusÃ¤tzlich wird das PingCastle-Feld â€žDetails" nicht mehr im Finding-Abschnitt gerendert, sobald strukturierte Ergebnisse vorliegen: PingCastle liefert dieselben Beweisdaten doppelt â€” einmal als Abschnitte, die das Ergebnisfenster als Tabelle rendert, und einmal als FlieÃŸtext, in dem die Tabellen ohne Spaltengrenzen aneinandergereiht sind und der die halbe Lesespalte fÃ¼llte. Das Feld wandert unter â€žZusatzinformationen" und bleibt dort vollstÃ¤ndig erhalten; ohne strukturierte Ergebnisse bleibt es unverÃ¤ndert im Finding-Abschnitt, damit keine Evidenz verlorengeht. Im Browser verifiziert: â€žDetails" nicht mehr unter den Finding-Beschriftungen, aber im aufgeklappten Zusatzblock vorhanden. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Ergebnisfenster in das Farbschema des Fundes eingefÃ¼gt und LeseflÃ¤che vergrÃ¶ÃŸert: Das Popup trug eine violette Umrandung und eine eigene, fast schwarze FlÃ¤che (`#0b0c10`) und stand damit sichtbar auÃŸerhalb der Designsprache. Es nutzt jetzt dieselbe FlÃ¤che wie der Reader dahinter (`--bg`) und grenzt sich Ã¼ber eine krÃ¤ftigere Haarlinie (`--line-strong`) ab; der Fenstertitel trÃ¤gt die Typografie der Finding-Ãœberschrift `.reader-summary h3` (16px, `--ui-strong-weight`), der Rumpf `--ui-body-size` statt 16px. Das Token `--result-color` wechselt wie angekÃ¼ndigt vom Markenton auf `--state-active` (Bernstein), da ein geÃ¶ffnetes Ergebnisfenster eine Werkzeugfunktion ist; die drei zuvor darauf hart gesetzten weiÃŸen Schriftfarben tragen jetzt die dunkle Tinte des Aktivtons. Dabei fiel eine Folgeursache auf: `themes.css` setzte den Reader im hellen Skin Ã¼ber eine Ãœbergangsregel auf `--panel-raised`, wodurch er sich von jeder anderen FlÃ¤che unterschied â€” die Regel stammte aus der Zeit vor der Tokenisierung von `legacy-views.css` und `base.css` und ist samt der Ãœberschreibungen fÃ¼r Rohdatenansicht, Reviewfelder und TabellenkÃ¶pfe ersatzlos entfallen. ZusÃ¤tzlich liegen die Feldbeschriftungen im Finding-Abschnitt (`.reader-summary h4`) jetzt auf der FlieÃŸtextstufe (14px) statt auf der kleineren Label-Stufe der Bedienleisten. Rohe Farbwerte von 89 auf 85 gesunken, Obergrenze fÃ¼r `components.css` auf 30 nachgezogen. Im Browser in beiden Skins gemessen: Reader und Popup tragen identische FlÃ¤chen (dunkel `rgb(43,43,43)`, hell `rgb(191,191,191)`), kleinste SchriftgrÃ¶ÃŸe im Finding-Abschnitt 14px. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Typografie auf `rem` mit 12px-Untergrenze umgestellt: Die SchriftgrÃ¶ÃŸen-Tokens in [tokens.css](../src/styles/tokens.css) stehen jetzt in `rem` statt `px` und folgen damit der im Browser eingestellten StandardschriftgrÃ¶ÃŸe, die `px` ignoriert â€” ein Barrierefreiheitsgewinn. Bewusst **kein** Responsive-Mechanismus: `rem` reagiert nicht auf die Fensterbreite, damit Tabellen und Plaketten bei jeder FenstergrÃ¶ÃŸe gleich umbrechen; RahmenstÃ¤rken und Radien bleiben in `px`. Neue Skala: Label, Small und Value 0.75rem (12px), Control 0.8125rem (13px), Body 0.875rem (14px), dazu neu Heading 1rem (16px) und Glyph 1.3125rem (21px) fÃ¼r SymbolschaltflÃ¤chen. 81 fest verdrahtete `font-size`-Werte in sechs Stildateien wurden auf die Skala abgebildet; Ã¼brig bleiben nur `clamp()`-Ãœberschriften mit Untergrenzen von 17px aufwÃ¤rts. Damit verschwinden die bisherigen 8px- und 9px-Stellen (Topbar-Kennzahlen, Bereichs-Kicker, Status- und Severity-Plaketten, Kartenstatus) sowie sÃ¤mtliche 10px- und 11px-Werte. Der DesignprÃ¼fer erhÃ¤lt eine dritte Regel: jede absolute SchriftgrÃ¶ÃŸe in einer `font-size`-Deklaration und in jedem Typografie-Token muss mindestens 12px beziehungsweise 0.75rem betragen, `clamp()` eingeschlossen; die Regel wurde durch einen absichtlich eingefÃ¼gten 9px-VerstoÃŸ als wirksam nachgewiesen. Im Browser gemessen: kleinste tatsÃ¤chlich gerenderte SchriftgrÃ¶ÃŸe 12px, Verteilung 12/13/14/16/21/23px. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Standardansicht zeigt nur noch Abweichungen: Ursache der bisher mit angezeigten bestandenen PrÃ¼fungen war nicht der jeweilige Werkzeugstandard, sondern das **generische Profil** â€” der betroffene Bericht wurde keinem Werkzeug zugeordnet und lief unter `generic`, das gar keine Statusfilter besaÃŸ (`statusFilters: []`, `defaultStatusFilter: 'all'`). Es erhÃ¤lt jetzt ein werkzeugunabhÃ¤ngiges Statusvokabular (Abweichung, Bestanden, Nicht anwendbar, Nicht ausgefÃ¼hrt, Fehler) mit `deviation` als Standard; die Muster treffen die in `ImportProfile.matchesStatus` bereits vereinheitlichte Schreibweise, decken das Vokabular aller unterstÃ¼tzten Werkzeuge ab und halten â€žfailed to run" bewusst vom fachlichen Scheitern getrennt. ErgÃ¤nzend stehen CIS-CAT und Maester auf `failed` statt `all`; Purple Knight stand bereits auf `ioes-found`. Die Profilversion des generischen Profils bleibt bewusst auf 1.0.0, weil sich nur eine Ansichtsvorgabe Ã¤ndert und die Version je Vorkommen als Provenienz gespeichert wird. ZusÃ¤tzlich erscheinen erzÃ¤hlende Spalten nicht mehr als Auswahlfilter: Wird ihre Rolle nur als `additional` erkannt, griff die bisherige RollenprÃ¼fung nicht â€” â€žRemediation" landete dadurch als Filter in der Leiste, obwohl Abhilfetexte je Finding einzigartig sind. Eine zusÃ¤tzliche PrÃ¼fung der SpaltenÃ¼berschrift in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts) schlieÃŸt sie jetzt unabhÃ¤ngig von der Rollenerkennung aus. Die Filterleiste bleibt unverÃ¤ndert als Auswahlfelder Ã¼ber der Ansicht. Im Browser verifiziert: Statusfilter steht auf â€žAbweichung", Optionen Abweichung Â· 57, Bestanden Â· 95, Nicht anwendbar Â· 4; angezeigt werden 57 Karten, keine davon mit Pass-Kennzeichnung. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Reader-Aufbau geschÃ¤rft und Designsprache Stufe 2 fÃ¼r die Reader-Ansichten abgeschlossen: (1) Die Ãœberschrift des Finding-Abschnitts trÃ¤gt jetzt den Inhalt von â€žCheck title" (die Pruefbeschreibung der Regel) statt des generischen Wortes â€žFinding"; das Feld wird dafÃ¼r in [FindingReader.tsx](../src/features/finding-reader/FindingReader.tsx) erst nach der Sichtbarkeitsberechnung aus der Zusammenfassung gelÃ¶st, damit es nicht zusÃ¤tzlich unter den Zusatzinformationen erscheint, und der eigene â€žCheck title"-Block entfÃ¤llt. Die Versalien der Ãœberschrift wurden aufgehoben, da sie nun einen Satz trÃ¤gt. (2) Der erlÃ¤uternde PingCastle-Score-Absatz wurde samt Markup und Stilregel entfernt. (3) `.bookmark-label` war hellviolett und im hellen Skin kaum lesbar, jetzt `--text`. (4) **Grauwerte des hellen Skins nach den Vorlagen korrigiert:** Wertfelder sind in Ableton Light *heller* als ihre FlÃ¤che, nicht dunkler â€” `--surface-inset` wurde von `#bdbdbd` auf `#d5d5d5` gedreht und die gesamte Skala auf Abletons Bereich gesetzt (ArbeitsflÃ¤che `#bfbfbf`, Bedienelemente `#d8d8d8`, Auswahl `#b8d8f5`, Text `#101010`). Im dunklen Skin bleibt das VerhÃ¤ltnis wie gehabt umgekehrt. (5) [legacy-views.css](../src/styles/legacy-views.css) vollstÃ¤ndig auf Tokens umgestellt: Neomorph-Schatten, 12px-Radien, Hover-Versatz und der komplette Sonderblock fÃ¼r den hellen Skin entfallen; Auswahl nutzt `--state-selected`, gemerkte EintrÃ¤ge und geÃ¶ffnete Ergebnisse `--state-active`, Severity-Hexagone und -Plaketten die Severity-Tokens. Damit war der weiÃŸe Arbeitsbereich beseitigt, der zuvor aus `html[data-theme="light"] .viewer { background: #fff }` stammte und die themes.css-Regel Ã¼berschrieb, weil diese Datei zuletzt geladen wird. Rohe Farbwerte von 211 auf 96 gesunken, `legacy-views.css` von 114 auf **0**; Obergrenzen des PrÃ¼fers nachgezogen, der Eintrag fÃ¼r die Datei entfÃ¤llt. Im Browser in beiden Skins verifiziert: Ãœberschrift ohne Versalien in `rgb(0,0,0)`, â€žCheck title"-Block und Score-Absatz nicht mehr im DOM, Bookmark-Label `rgb(16,16,16)`. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Seitenleisten-Navigation auf den Aktivton umgestellt: Der aktive Bereich trÃ¤gt jetzt `--state-active` (Bernstein) in Schrift und Symbol; der zuvor links gesetzte rote Markierungsbalken (`.sidebar-primary-actions button.active::before`, dunkel `#b3123f`, hell violett) entfÃ¤llt ersatzlos, da die Farbe die Markierung Ã¼bernimmt. Die gesamte Navigation lÃ¤uft Ã¼ber Tokens, wodurch sechs Sonderregeln des hellen Skins entfallen. Der Ansichtsmodus ist in der Seitenleiste horizontal zentriert und bleibt auf ausdrÃ¼cklichen Wunsch rundlich (40Ã—40, Radius 50 %) â€” als dokumentierte Ausnahme von der sonst eckigen Formensprache. Rohe Farbwerte von 217 auf 211 gesunken (`layout.css` von 26 auf 20), Obergrenze des PrÃ¼fers nachgezogen. Im Browser in beiden Skins verifiziert: aktive Navigation `rgb(255,168,37)` dunkel und `rgb(240,160,32)` hell, Markierungsbalken nicht mehr gerendert, Schalter mittig. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Sidebar nach Nutzerabnahme bereinigt und Farbrolle der Nebenfunktionen festgelegt: Der Dateistatus-Block (DatensÃ¤tze, Felder, BlÃ¤tter, Format) wurde samt Markup in [App.tsx](../src/app/App.tsx) und seinen Stilregeln (`.sidebar-kpis`) ersatzlos entfernt; der Systemstatus-Block bleibt unverÃ¤ndert. Beim Ansichtsmodus entfÃ¤llt die Ãœberschrift â€žAnsicht"; die drei SchaltflÃ¤chen sind eckig mit Haarlinie statt kreisrund mit Neomorph-Schatten, das Symbol steht auf 21px. **Neue verbindliche Rolle:** Werkzeug- und Nebenfunktionen tragen den Aktivton `--state-active` (Bernstein), der Markenakzent `--accent` (Violett) bleibt der primÃ¤ren Aktion vorbehalten; die Regel ist im Kopf von [tokens.css](../src/styles/tokens.css) dokumentiert, zusammen mit dem Grundsatz, dass Akzentfarben ZustÃ¤nde markieren und niemals Text. Da Abschnittstitel und Ansichtsmodus jetzt vollstÃ¤ndig Ã¼ber Tokens laufen, entfallen vier Sonderregeln des hellen Skins ersatzlos. Rohe Farbwerte von 224 auf 217 gesunken (`layout.css` von 33 auf 26), Obergrenze des PrÃ¼fers nachgezogen. Im Browser in beiden Skins verifiziert: Dateistatus und â€žAnsicht"-Ãœberschrift nicht mehr im DOM, drei SchaltflÃ¤chen, aktive FlÃ¤che `rgb(240,160,32)` hell und `rgb(255,168,37)` dunkel. 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema- oder PersistenzÃ¤nderung. |
| 2026-07-25 | Lesbarkeitskorrektur nach Nutzerabnahme der neuen Designsprache: **Ãœberschriften und Beschriftungen tragen keine Akzentfarbe mehr.** Betroffen waren die AbschnittsÃ¼berschriften der verknÃ¼pften Ergebnisse (`.linked-results section > strong`, zuvor fest `#c9bedf`) â€” im hellen Skin heller Violettton auf grauer FlÃ¤che und damit praktisch unlesbar â€”, die Aufklapper â€žVerknÃ¼pfte Results" und â€žZusatzinformationen" (`.all-fields summary`), die Reader-Navigation, die MerkschaltflÃ¤che, die FlieÃŸtextverweise, `.workbar-action b`, `.area-kicker` sowie `.finding-techniques`. Alle nutzen jetzt `--heading` beziehungsweise `--text`/`--muted`: im hellen Skin dunkelgrau (`#0f0f0f`), im dunklen nahezu weiÃŸ (`#ececec`), gemessen rund 15:1 und 9:1 Kontrast gegen die jeweilige PanelflÃ¤che. Ebenfalls korrigiert: die Reviewbeschriftungen (`.dashboard-grid label`, `.review-grid > label`) standen fest auf WeiÃŸ und ergaben im hellen Skin weiÃŸe Schrift auf grauer FlÃ¤che; und die aufgeklappte Zeile des Ergebnis-Browsers nutzte die Auswahlfarbe `--state-selected` als FlÃ¤che, worauf der DetailflieÃŸtext schlecht lesbar war â€” Aufklappen ist kein Auswahlzustand und erhÃ¤lt jetzt die neutrale FlÃ¤che `--panel-raised`. Rohe Farbwerte von 229 auf 224 gesunken, Obergrenzen des PrÃ¼fers entsprechend nachgezogen (`legacy-views.css` 114, `components.css` 35, `mitre-graph.css` 34). 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder KomponentenÃ¤nderung. |
| 2026-07-25 | Designsprache auf Ableton Live umgestellt, Stufe 1 und Musterbildschirm: `tokens.css` ist jetzt die einzige Quelle fÃ¼r Farbe, Dichte und Typografie und trÃ¤gt eine vollstÃ¤ndige Skala (FlÃ¤chen inklusive eingesenkter Wertfelder, Haarlinien, Text, ZustÃ¤nde, Semantik, Severity, AbstÃ¤nde, Radien, RahmenstÃ¤rke, SteuerelementhÃ¶he, Typografie). Neu ist die aus Ableton Ã¼bernommene **Rollentrennung der Akzente**: `--state-selected` (blau) fÃ¼r Auswahl, `--state-active` (bernstein) fÃ¼r aktiv/scharf, `--accent` (violett) bleibt der Markenton fÃ¼r die primÃ¤re Aktion. Chrome ist in beiden Skins durchgehend grau â€” hell mittelgrau statt weiÃŸ, dunkel mittelgrau statt fast schwarz â€”, Schatten entfallen (`--shadow: none`), Radien auf 2px, Grundschrift von 14px auf 12px. `themes.css` Ã¼berschreibt nur noch Tokenwerte; seine Klassenregeln sind als Ãœbergangsbestand markiert und enthalten keine rohen Farbwerte mehr. Die Typografie-Tokens lagen bisher am Ende der Ladereihenfolge in `legacy-views.css` und hÃ¤tten die Sprache Ã¼berschrieben â€” sie sind nach `tokens.css` gewandert. VollstÃ¤ndig umgestellt: `tokens.css`, `themes.css`, `base.css` (alle Steuerelemente), `datahub.css` (Datahub, DB-Struktur, Ergebnis-Browser). Damit sinken die rohen Farbwerte von 443 auf 229, alle im noch nicht umgestellten Restbestand. Neu ist der PrÃ¼fer [tests/design-language-check.mjs](../tests/design-language-check.mjs) (`npm test`, `npm run test:design`) nach dem Vorbild von `local-only-check.mjs`: er verbietet rohe Farbwerte auÃŸerhalb von Token-Deklarationen, erzwingt, dass jedes referenzierte Token definiert ist, verbietet Inline-Styles in React und fÃ¼hrt eine ausschlieÃŸlich schrumpfende Obergrenze je Altbestandsdatei. Er hat sofort zwei stille Defekte derselben Klasse gefunden: `--panel-hover` ([layout.css:74](../src/styles/layout.css:74)) und `--result-color` ([components.css:43](../src/styles/components.css:43), [legacy-views.css:277](../src/styles/legacy-views.css:277)) wurden referenziert, ohne definiert zu sein â€” die betroffenen Hover- und â€žErgebnisse geÃ¶ffnet"-ZustÃ¤nde rendeten ersatzlos; beide Tokens sind jetzt definiert. Offen fÃ¼r Stufe 2: `legacy-views.css` (115), `components.css` (38), `mitre-graph.css` (35), `layout.css` (33), `dynamic-filters.css` (7), `import-workflow.css` (1). 355 Standardtests, Local-only-PrÃ¼fung, DesignprÃ¼fer und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Keine Schema-, Persistenz- oder KomponentenÃ¤nderung; ausschlieÃŸlich Stildateien, `package.json` und der neue PrÃ¼fer. |
| 2026-07-25 | Seit 2026-07-23 gemeldeten Dauerausfall in `tests/server/gpo-artifact-reconciler.test.ts` behoben: Der Test injizierte eine fest datierte Uhr (`2026-07-23T08:00:00.000Z`) bei 60 Sekunden Karenz, schrieb die unreferenzierte Waisendatei aber real Ã¼ber den Artefaktspeicher, sodass sie die echte Systemzeit als mtime trug. Sobald die reale Uhr dieses Datum Ã¼berschritt, lag die mtime dauerhaft hinter dem Alterungs-Cutoff (`information.mtimeMs > objectCutoff`, [server/artifacts/backend-artifact-store.ts](../server/artifacts/backend-artifact-store.ts)), die Waise wurde fail-safe zurÃ¼ckbehalten und die Zusage `removedUnreferencedObjects: 1` schlug unabÃ¤nderlich fehl. Reine Testkopplung, kein Produktionsfehler: Die Reconciliation selbst verhielt sich unverÃ¤ndert korrekt, weshalb ausschlieÃŸlich der Test geÃ¤ndert wurde. Der Reconciliationszeitpunkt wird jetzt relativ zur realen Uhr abgeleitet (`Date.now() + 24 h`), womit real geschriebene Objekte immer vor dem Cutoff altern und kein kalendarisches Ablaufdatum mehr entsteht. Die fachliche Zusage bleibt unverÃ¤ndert: referenziertes Artefakt wird repariert, integritÃ¤tsgeprÃ¼ft gelesen und behalten, nur die gealterte Waise wird entfernt, genau ein Objekt bleibt liegen. Die beiden Retentionstests derselben Datei prÃ¼fen dadurch zusÃ¤tzlich schÃ¤rfer, weil sie das ZurÃ¼ckbehalten nun allein Ã¼ber die Sperren â€žkein vertrauenswÃ¼rdiger Referenzbestandâ€œ beziehungsweise â€žungÃ¼ltige Legacy-Speicherreferenzâ€œ belegen und nicht mehr beilÃ¤ufig Ã¼ber eine noch junge mtime. 355 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; keine offenen TestausfÃ¤lle mehr. Keine Produktions-, Schema- oder MandantendatenÃ¤nderung. |
| 2026-07-25 | PingCastle-Befunde werden wieder als IOE gefÃ¼hrt (Profil 1.0.0 â†’ 1.1.0): PingCastle berichtet ausschlieÃŸlich ausgelÃ¶ste RiskRules und setzt dafÃ¼r den Status â€žMatched". Das PingCastle-Profil deklarierte fÃ¼r diesen Wert kein Mapping, sodass die generische RÃ¼ckfallregel `matched|detected` griff und den Treffer bewusst als bloÃŸen Hinweis las (`open`/`warning`). Ãœber die Vertragskette bedeutete das: `deriveExposureState` kennt `warning` nicht und liefert `unknown`, `deriveIsIoe` verlangt aber `detected` â€” dadurch war **kein einziger** PingCastle-Befund `is_ioe`, obwohl `result_type` korrekt `exposure_finding` war. Das PingCastle-Profil deklariert den exakten Wert â€žMatched" jetzt selbst als `failed`; damit greift der bereits vorhandene Vorrang des Profil-Mappings vor der generischen Regel ([src/importers/status-normalization.ts](../src/importers/status-normalization.ts)) und die Kette lÃ¶st sich zu `fail` â†’ `detected` â†’ `is_ioe = true` auf. Unspezifische Treffertexte (z. B. â€ždetected") bleiben unverÃ¤ndert ein Hinweis, andere Werkzeuge sind nicht betroffen, da nur das PingCastle-Profil eine eigene Statusliste erhÃ¤lt. Die Profilversion wurde angehoben, weil die Profilversion je Vorkommen persistiert wird; **bereits importierte LÃ¤ufe behalten ihren alten Status und benÃ¶tigen fÃ¼r die IOE-Sicht einen Reimport**. Synthetische Regressionen ergÃ¤nzt (`tests/importers/status-normalization.test.ts`: â€žMatched" â†’ fail sowie die vollstÃ¤ndige Kette bis `is_ioe`); die Versionszusage in `tests/profiles/declarative-profiles.test.ts` prÃ¼ft nun gegen den Profilkatalog statt gegen eine feste Zahl. 354 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; derselbe unabhÃ¤ngige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverÃ¤ndert fort. Keine SchemaÃ¤nderung. |
| 2026-07-23 | PingCastle-Details-VervollstÃ¤ndigung nach Nutzerabnahme (Extractor 1.6.0): Vier verifizierte Korrekturen. (1) Eine Regel kann die direkt eingebettete Beweistabelle UND einen Ankerverweis zugleich tragen (z. B. A-DC-Spooler); bisher verdrÃ¤ngte die eingebettete Tabelle die AnkerauflÃ¶sung â€” jetzt werden beide Quellen erfasst, das "Verwandte Daten"-Feld trÃ¤gt eine Liste von Sektionen und der Results-Popup zeigt mehrere BlÃ¤tter; dadurch werden auch acht zuvor verdeckte Ankerziele (u. a. useraccountanalysis, gpofirewall, auditsettings, admincountequalsone) erstmals aufgelÃ¶st. (2) Der Fundtitel folgt jetzt dem PingCastle-Card-Header (identisch zur XML-Rationale, z. B. "The spooler service is remotely accessible from 1 DC") statt der generischen h3-PrÃ¼fbeschreibung; die PrÃ¼fbeschreibung bleibt als neues Feld "Check title" erhalten, HTML- und XML-Import erzeugen damit denselben Fundnamen. (3) Die beim Import abgeleitete kanonische Severity wird deterministisch als Anzeigefeld "Severity" gespiegelt (nur wenn kein natives Severity-/Criticality-/Priority-Feld existiert), womit Karten, Kacheln und Reader-Hexagone erstmals gefÃ¤rbt werden â€” zuvor lag der Wert nur am Occurrence-Objekt, das die Work-Felderansicht nicht liest. (4) Zielabschnitte, deren Tabelle keine Datenzeilen hat (der Report listet dort nur nicht aufgetretene Ausnahmen), fallen auf ihre FlieÃŸtextdarstellung zurÃ¼ck, sodass der Results-Popup nie leer erscheint. Synthetische Regressionen ergÃ¤nzt (Extractor: kombinierte Quellen, Card-Header-Titel; Projektion: Prose-Fallback, Severity-Spiegelung). 331 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; derselbe unabhÃ¤ngige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverÃ¤ndert fort. Keine SchemaÃ¤nderung; das Payload-Format des "Verwandte Daten"-Felds wurde auf eine Sektionsliste umgestellt, bestehende LÃ¤ufe benÃ¶tigen fÃ¼r den Popup einen Reimport. |
| 2026-07-23 | PingCastle-"Details:"-AnkerauflÃ¶sung: Verweist "Details:" nicht auf eine direkt eingebettete Tabelle (bereits gehÃ¤rtet), sondern per internem Dokumentanker (`<a href="#id">Label</a>`) auf einen eigenstÃ¤ndigen Datenabschnitt an anderer Stelle im selben Bericht (z. B. "LAPS", "Admin Groups", "Domain controllers"), wird der Abschnitt jetzt bis zu seinem strukturellen Ende (`<!-- SubSection Name -->` â€¦ `<!-- SubSection Name end -->` â€¦ nÃ¤chste SubSection) aufgelÃ¶st und als FlieÃŸtext plus enthaltene Tabellen an das Details-Feld angehÃ¤ngt; zuvor blieb nur der einleitende Verweissatz sichtbar. Zwei sicherheitsrelevante Vorstufen waren dafÃ¼r nÃ¶tig: `sanitizeHtmlText` entfernt regulÃ¤r sowohl `href`-Attribute als auch HTML-Kommentare (beides richtig gegen aktiven Inhalt); ein eng begrenzter Vorlauf Ã¼berfÃ¼hrt ausschlieÃŸlich `href="#<sicheres Zeichenset>"` sowie PingCastles eigene `SubSection`-Kommentare vor der Sanitisierung in inerte Marker, jeder andere `href`- oder Kommentarwert bleibt unverÃ¤ndert der regulÃ¤ren Entfernung unterworfen. Gegen den ausdrÃ¼cklich freigegebenen Dummy-Report gegengeprÃ¼ft: 37 Regeln, keine AusreiÃŸergrÃ¶ÃŸe (max. 5.250 Zeichen bei einer tabellenreichen Zielsektion), Grenzen halten exakt an der nÃ¤chsten SubSection. Synthetische Regression ergÃ¤nzt (`tests/importers/pingcastle-source-extractor.test.ts`). 328 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; derselbe unabhÃ¤ngige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverÃ¤ndert fort. Keine SchemaÃ¤nderung. |
| 2026-07-23 | PingCastle-Details-Ergebnis-Popup: Der HTML-Extraktor liefert die aufgelÃ¶ste Zielsektion einer "Details:"-Ankerverlinkung nun zusÃ¤tzlich strukturiert (Header/Zeilen) Ã¼ber ein eigenes Feld `Verwandte Daten`, statt nur als FlieÃŸtext. `canonical-model-to-dataset.ts` baut daraus je eindeutigem Zielabschnitt genau ein Tabellenblatt mit deterministischer ID (mehrere Regeln, die auf denselben Abschnitt verweisen, teilen sich ein Blatt statt zu duplizieren) und blendet den rohen Strukturwert aus der normalen Feldanzeige aus, sodass nur die kurze Abschnitts-ID sichtbar bleibt. Ein neues, PingCastle-eigenes VerknÃ¼pfungsmodul (`pingcastle-section-links.ts`) verlinkt per exakter ID-Gleichheit statt der bei Purple Knight verwendeten Text-Heuristik und speist den bestehenden Results-Button/Popup-Mechanismus zusÃ¤tzlich zur bisherigen Purple-Knight-Verlinkung. Synthetische Regression ergÃ¤nzt (`tests/features/canonical-model-to-dataset.test.ts`: ein Abschnitt, zwei referenzierende Findings, ein gemeinsames Blatt, exakte Verlinkung). 329 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; derselbe unabhÃ¤ngige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverÃ¤ndert fort. Keine SchemaÃ¤nderung. |
| 2026-07-23 | PingCastle-Severity-Ableitung aus Points: PingCastle-Regeln besitzen kein natives Severity-Feld, nur Points je Regel. Eine neue, versionierte, werkzeuggebundene Regel (`pingcastle-severity-from-points@1.0.0`, [src/profiles/pingcastle/pingcastle-severity.ts](../src/profiles/pingcastle/pingcastle-severity.ts)) Ã¼bernimmt PingCastles eigene Score-Legende (0 = informativ, 1â€“10 = low, 11â€“30 = medium, > 30 = high) von der Kategorieebene auf die einzelne Regel; `critical` bleibt fÃ¼r PingCastle bewusst unerreichbar, bis eine gesondert versionierte Zusatzschwelle definiert wird. Eine neue werkzeuggebundene Registry ([src/importers/severity-from-score-registry.ts](../src/importers/severity-from-score-registry.ts)) greift ausschlieÃŸlich, wenn kein natives Severity-Feld erkannt wurde; andere Werkzeuge sind unverÃ¤ndert. Der Nativwert (Points) und eine erklÃ¤rende Provenienz bleiben nachvollziehbar. Ziel ist die tooluebergreifende Filterbarkeit Ã¼ber `severity_normalized` in der Unified-Result-Projektion. Synthetische Regression ergÃ¤nzt (`tests/profiles/pingcastle-severity.test.ts`, erweitertes `tests/importers/pingcastle-source-extractor.test.ts`). 328 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen; derselbe unabhÃ¤ngige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverÃ¤ndert fort. Keine SchemaÃ¤nderung. |
| 2026-07-23 | PingCastle-HTML-Detailtabellen-NachhÃ¤rtung: Rendert PingCastle nach "Details:" unmittelbar eine eingebettete Tabelle (kein externer Verweis, sondern nur ein interner Dokumentanker), wurde diese bislang stillschweigend verworfen und nur der einleitende Satz Ã¼bernommen. Der HTML-Extraktor erfasst nun eine direkt folgende Tabelle als Teil des Details-Feldwerts (Extractor-Version 1.1.0 â†’ 1.2.0). ZusÃ¤tzlich wurde der aus Purple Knight stammende, generische Ergebnisverweis-Mechanismus (`resultReferenceFields`) von der Feldbezeichnung â€žDetails" entkoppelt, die bei Purple Knight nie verwendet wird, aber bei PingCastle zu einem irrefÃ¼hrenden â€žKeine passende Ergebnisdatei gefunden"-Hinweis fÃ¼hrte, obwohl die Daten inline vorlagen. Ursache wurde am ausdrÃ¼cklich freigegebenen Dummy-Mandanten (PingCastle-Report `ad_hc_sevenkingdoms.local`) verifiziert: von 34 Regeln mit â€žDetails:" enthalten 18 eine eingebettete Tabelle; die zugehÃ¶rige XML-Exportvariante trÃ¤gt fÃ¼r 36 von 37 Regeln Ã¼berhaupt keinen Detail-Knoten und bleibt daher strukturell auf die HTML-Begleitdatei angewiesen. Synthetische Regression ergÃ¤nzt (`tests/importers/pingcastle-source-extractor.test.ts`, `tests/profiles/result-linker.test.ts`). 323 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Ein einzelner, von dieser Ã„nderung unabhÃ¤ngiger Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` (zeitbasierte Testkopplung zwischen injizierter Uhr und echter Dateisystem-mtime) wurde separat gemeldet, nicht behoben. Keine SchemaÃ¤nderung, keine Mandantendaten verÃ¤ndert. |
| 2026-07-22 | Phase-13A-PurpleKnight-Results wiederhergestellt: Der kanonische SourceTable-Vertrag bewahrt Zeilen nicht ausgewÃ¤hlter Workbook-Tabellen als Originalfelder, wÃ¤hrend Finding-Tabellen keine redundante Kopie erhalten. Die Work-Projektion rekonstruiert unterstÃ¼tzende Tabellen nach den fachlichen Ansichten; bestehende Result-Referenzen Ã¶ffnen wieder das Results-Fenster. Synthetische Persistenz-, Projektions-, Linker- und PingCastle-Reihenfolgeregressionen ergÃ¤nzt. 291 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Der freigegebene reviewfreie Dummy-PurpleKnight-Lauf wurde mit derselben lokalen XLSX ersetzt und im Codex-Browser auf 20 Results-Buttons sowie die erwartete Ein-Zeilen-/Vier-Spalten-Tabelle geprÃ¼ft. Die abschlieÃŸende BestandsprÃ¼fung stellte den bereits zuvor fehlenden separaten PingCastle-XML-Lauf aus der lokalen freigegebenen Datei mit 37 Findings wieder her; Dummy enthÃ¤lt im Browser erneut 193 Findings aus PurpleKnight, PingCastle HTML und PingCastle XML. Additive kanonische JSON-Vertragserweiterung, keine SQL-Migration. |
| 2026-07-22 | Phase-13A-PingCastle-Auswertung vervollstÃ¤ndigt: XML-Extractor auf individuelle Regelpunkte, vier Kategorie-Scores, Domain Risk Level sowie strukturierte Details/ExtraDetails erweitert; HTML-Kategorien normalisiert. Exakte projektlokale HTML/XML-Begleiter werden in Work Ã¼ber Dateistamm plus Rule ID statisch angereichert, ohne Originalfelder oder dynamische Scanwerte zu Ã¼berschreiben; die Regeltext-Quelle bleibt sichtbar. Score-Badges und Herstellerformel werden im Reader erklÃ¤rt. Synthetische Regressionen ergÃ¤nzt; 289 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich, 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Der ausdrÃ¼cklich freigegebene Dummy-Abgleich reproduziert 37 Rule IDs und die Herstellerformel exakt; der reviewfreie alte XML-Lauf wurde ersetzt, der HTML-Lauf ergÃ¤nzt und im Codex-Browser auf zwei getrennte 37er-Ansichten, Regeltexte, Score-Badges und ExtraDetails geprÃ¼ft. Keine SchemaÃ¤nderung. |
| 2026-07-22 | Phase-13A-Work-Darstellung nach Import korrigiert: Auto-Commit und bestÃ¤tigter Batch-Commit laden nun anhand der serverseitigen Projekt-ID das persistierte kanonische Mandantenmodell; auch openProject verwendet denselben Loader. PingCastle-XML erscheint als fachliche RiskRules-Ansicht statt als generischer HealthcheckData-Elementbaum, und Title ist die StandardÃ¼berschrift. Synthetische End-to-End-Projektionsregression ergÃ¤nzt. 287 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; die laufende PostgreSQL-Anwendung ist gesund und Dummy wurde rein lesend auf 37 XML-Findings, vorhandene XML-Unteransicht, ausgewÃ¤hlten Titel und nicht sichtbaren DomainSid-Knoten geprÃ¼ft. Keine Persistenz- oder SchemaÃ¤nderung. |
| 2026-07-22 | Scan-Historie nachgehÃ¤rtet: projektgebundene LÃ¶schung eines einzelnen Scan Runs mit exakter BestÃ¤tigung in Repository, PostgreSQL, lokaler Persistenz, API, Client und Datahub ergÃ¤nzt; AbhÃ¤ngigkeiten, verwaiste Definitionen/Fingerprints und ungÃ¼ltige Vergleiche werden kontrolliert bereinigt. Bekannte ScannerlÃ¤ufe mit hÃ¶chstens 60 Sekunden auseinanderliegenden Dateizeitpunkten werden in der Historie und bei zielmandantengebundener Uploadvorschau als auswÃ¤hlbares â€žMÃ¶gliches Duplikatâ€œ markiert; exakte SHA-256-Dubletten bleiben blockierend getrennt. Synthetische Domain-, UI-Helfer-, Repository-, API- und HTTP-Regressionen ergÃ¤nzt. 286 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich. PostgreSQL-LÃ¶schpfad zusÃ¤tzlich Ã¼ber zwei synthetische Scan-IDs in der laufenden API geprÃ¼ft und vollstÃ¤ndig aufgerÃ¤umt; Dummy im Codex-Browser nur hinsichtlich Markierung, SchaltflÃ¤che und Dialog geprÃ¼ft, keine LÃ¶schung ausgefÃ¼hrt. |
| 2026-07-22 | Native Work-Projektion fÃ¼r PingCastle und andere dateibasierte Source Extractors ergÃ¤nzt: Persistierte Finding-Vorkommen ohne kÃ¼nstliche `SourceTable` erhalten je Importdatei eine auswÃ¤hlbare Unteransicht mit Werkzeug, Scandatum und Format. Die freigegebenen Dummy-PingCastle-Dateien wurden rein lesend verifiziert und erzeugen im aktuellen Importer jeweils 37 von 37 Candidates ohne offene oder ausgeschlossene Mappings; reale Inhalte wurden nicht in Tests Ã¼bernommen. Synthetische Projektionsregression ergÃ¤nzt. 282 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Keine Persistenz- oder SchemaÃ¤nderung. |
| 2026-07-22 | Native PingCastle-Erkennung nachgehÃ¤rtet: dedizierten sicheren Source Extractor fÃ¼r HTML-RegelblÃ¶cke und `HealthcheckData/RiskRules`-XML ergÃ¤nzt, wiederholte HTML-Renderings je Rule ID dedupliziert, Rule-ID-IdentitÃ¤t formatÃ¼bergreifend vereinheitlicht und dateibezogene Vorkommen samt Locators erhalten. Synthetische HTML-/XML-ParitÃ¤ts-, Sicherheits- und Persistenzregressionen ergÃ¤nzt. 281 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Keine Persistenz- oder SchemaÃ¤nderung. |
| 2026-07-22 | GPO-Ordner-Submission nachgehÃ¤rtet: vollstÃ¤ndige sichere ContainerprÃ¼fung bleibt im begrenzten Worker, die Vorstufe Ã¼bernimmt nur noch eine kompakte Erkennung; vollstÃ¤ndiges Inventar und Parsermodelle bleiben an der Jobgrenze. Workerfehler werden ohne rohe Meldungen in sichere Kategorien Ã¼berfÃ¼hrt. Der synthetische Produktionslauf mit 91.316.402 Bytes, 2.040 EintrÃ¤gen, 300 Backupinstanzen und 45.000 Beobachtungen ist bei 512 MB einschlieÃŸlich Vorstufe erfolgreich. 281 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild grÃ¼n; Phase 13B bleibt in Arbeit. |
| 2026-07-22 | Zweiten scannerseitigen Unified-Result-Vertikalschnitt umgesetzt: `FindingOccurrence` besitzt getrennte optionale `MappedValue`-Dimensionen fÃ¼r fachliches Outcome und technische AusfÃ¼hrung; der Candidate-Importer persistiert beide und klassifiziert â€žFailed to runâ€œ als `execution_error`/`failed` statt als fachliches `fail`. Additive Migration 007 ergÃ¤nzt geprÃ¼fte, indexierte Spalten sowie namespaced, profilversionierte Resultkategorien und eine mehrwertige Occurrence-Relation mit Backfill. Beide PostgreSQL-Importpfade schreiben Dimensionen und Kategorien atomar; Legacy-Daten bleiben Ã¼ber den alten Status lesbar. 277 Standardtests, Local-only-PrÃ¼fung und Client-/Serverbuild erfolgreich; 7 von 7 PostgreSQL-Integrationstests nacheinander gegen frisches PostgreSQL 16 erfolgreich. AusschlieÃŸlich synthetische Daten; temporÃ¤rer Testcontainer entfernt. Phase 13B bleibt in Arbeit. |
| 2026-07-22 | Schritt 0 der Datenmodellkonsolidierung in `docs/UNIFIED_RESULT_MODEL.md` dokumentiert und ersten scannerseitigen Unified-Result-Vertikalschnitt umgesetzt: plattformneutraler Read-Typ mit getrennten Severity-, Outcome-, Execution-, Review-, Lifecycle- und Effective-Dimensionen; strukturierte namespaced Kategorien; Result-, Facetten-, Kategorien- und Detailmethoden im `AssessorRepository`; gleiche Local-/PostgreSQL-Semantik; versionierte Read-API und Client. Equal-Title- und Status-/Kategorien-/Reviewregressionen sowie HTTP-/Clienttests ergÃ¤nzt. GPO-PolicyObservation bleibt auÃŸerhalb der Projektion, bis PolicyIdentity, Baseline und Evaluation umgesetzt sind. Keine Migration. 274 Standardtests, Local-only-PrÃ¼fung und Client-/Serverbuild erfolgreich; PostgreSQL-Integration 7 von 7 erfolgreich. AusschlieÃŸlich synthetische Daten. Phase 13B bleibt in Arbeit. |
| 2026-07-22 | GPO-Worker-Speicherfehler vollstÃ¤ndig nachgehÃ¤rtet: ZunÃ¤chst wurde die quadratische Quellzeilenberechnung von Registry Preferences, Local Users and Groups, Services und Drive Maps durch einen linearen Scanner ersetzt. Nachdem der konkrete Fehler weiterhin auftrat, reproduzierte ein verschÃ¤rfter synthetischer Produktionsworker-Test den zweiten Peak bei 512 MB. Der Persistenzpfad verarbeitet Policydateien nun backupwurzelweise und gibt Parser-Zwischenmodelle sofort frei; die Worker-RÃ¼ckgabe enthÃ¤lt weder vollstÃ¤ndigen Container noch Dokumentmodelle. Registry Preferences werden mit dem fest versionierten lokalen SAX-Parser `saxes` 6.0.0 ereignisbasiert verarbeitet, wÃ¤hrend DTD, EntitÃ¤ten, Includes, Schemas und fremde Processing Instructions weiterhin vor dem Parser blockiert werden. Derselbe zuvor fehlschlagende Lauf mit 91.316.402 Bytes, 2.040 EintrÃ¤gen, 300 Backupinstanzen und 45.000 Beobachtungen ist bei 512 MB erfolgreich. 270 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Keine realen GPO- oder Mandanteninhalte gelesen; Phase 13B bleibt in Arbeit. |
| 2026-07-21 | Phase-13B-Fehlerverwaltung und Lastgrenze gehÃ¤rtet: Dead-Letter-GPO-Analysen kÃ¶nnen in der Mandantenansicht ohne erneuten Upload kontrolliert neu eingeplant werden. Ein explizit bestÃ¤tigtes LÃ¶schen entfernt ausschlieÃŸlich die ASSESSOR-Kopie samt relationaler Historie; Migration 006 persistiert zuvor einen unabhÃ¤ngigen LÃ¶schauftrag, den Start-/Stunden-Reconciliation nach einem Prozessabbruch wiederaufnimmt. GroÃŸe Worker-Eingaben werden als eigene Bytekopie per Transferliste Ã¼bergeben; der weiterhin begrenzte Standardheap wurde auf 1.024/128 MB angehoben. ZusÃ¤tzlich werden JSDOM-Fenster nach jedem Metadaten-/Preference-Dokument garantiert geschlossen und nur persistenzrelevante Ergebnisse Ã¼ber die Workergrenze Ã¼bertragen. Ein synthetischer Lastlauf mit 1.740 Dateien, 80.186.702 Bytes und 300 Backupinstanzen war unter derselben 1-GB-Grenze erfolgreich. 267 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 7 von 7 PostgreSQL-Integrationstests gegen frisches PostgreSQL 16 erfolgreich. Eine nicht unterstÃ¼tzte synthetische Legacy-Speicherreferenz blockiert regulÃ¤re Orphan-LÃ¶schungen fail-safe, ohne die Reconciliation abzubrechen. Nur synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Persistente GPO-Statusanzeige und Orphan-Reconciliation ergÃ¤nzt: Die Mandantenansicht lÃ¤dt und aktualisiert Queue-, Lauf-, Erfolgs-, Teil-, Dead-Letter- und RecoveryzustÃ¤nde aus der Datenbank einschlieÃŸlich Versuchen, Zeitpunkten, Fehlercode und erkannter Backupinstanzzahl. GPO-Artefakt und Analysejob werden atomar angelegt; fehlgeschlagene Dateischreib-/DB-Kombinationen werden sofort kompensiert. Eine beim Backendstart und stÃ¼ndlich laufende Reconciliation repariert fehlende Jobs und entfernt ausschlieÃŸlich mindestens 24 Stunden alte, unreferenzierte regulÃ¤re Objekte beziehungsweise Stagingreste, begrenzt auf 100 je Lauf; bei leerem vertrauenswÃ¼rdigem Referenzbestand ist jede ObjektlÃ¶schung gesperrt. 259 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; PostgreSQL separat 6 von 6 gegen frisches PostgreSQL 16 einschlieÃŸlich Transaktionsrollback. Nur synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Phase-13B-GPO-Ordnerimport ergÃ¤nzt: Im Datahub kann fÃ¼r einen bestehenden Mandanten unter Chrome das vollstÃ¤ndig entpackte Backupverzeichnis ausgewÃ¤hlt werden. Relative Pfade werden streng normalisiert und kollisionsgeprÃ¼ft; bis zu 20.000 EintrÃ¤ge und 100 MB werden sequenziell sowie bytegleich in einen deterministischen unkomprimierten Transportumschlag geschrieben und Ã¼ber die bestehende projektgebundene GPO-Ingestion erneut im gehÃ¤rteten Worker geprÃ¼ft. UI-Status meldet Annahme beziehungsweise Deduplizierung als Queuezustand. 253 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 von 5 PostgreSQL-Integrationstests gegen frisches PostgreSQL 16 erfolgreich. AusschlieÃŸlich synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Phase-13A-Zielkontextfehler behoben: Beim Wechsel eines bestÃ¤tigungspflichtigen Imports in die Vorschau wird der bestehende Workflowkontext einschlieÃŸlich `targetProjectId` nun erhalten. PingCastle- und andere Scannerimporte werden nach manueller Freigabe weiterhin dem ausgewÃ¤hlten Mandanten zugeordnet, statt unbeabsichtigt einen neuen Mandanten anzulegen. Synthetische Zustandsregression ergÃ¤nzt; 249 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich. Keine SchemaÃ¤nderung und keine realen Mandanteninhalte fÃ¼r Tests verwendet. |
| 2026-07-21 | Phase-13A-Regressionsfix fÃ¼r umfangreiche HTML-Scannerberichte: Quelltabellen-IDs um den stabilen Tabellenindex ergÃ¤nzt und unverÃ¤ndert in die Dataset-Projektion Ã¼bernommen. Wiederholte Caption-/Tabellennamen bleiben dadurch getrennte Source Tables; die kanonische Validierung meldet keine kÃ¼nstlichen `duplicate-id`-Fehler mehr. Synthetische Regression mit zwÃ¶lf identisch benannten HTML-Tabellen ergÃ¤nzt. 248 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; keine DatenbankÃ¤nderung und keine realen Mandanteninhalte verwendet. |
| 2026-07-21 | Group-Policy-Preferences um Drive Maps erweitert: technische Drives-/Drive-CLSIDs, kanonische Item-UIDs, C/D/R/U, Common Options und Targeting werden validiert. User-Scope wird erzwungen; UNC-Ziel, Persistenz, Label, optionales NETBIOS-Konto, Buchstabe, `useLetter` und getrennte Sichtbarkeit bleiben erhalten. Die aktionsabhÃ¤ngigen Auswahlmodi `exact`, `delete-range`, `first-available` und `first-mapped-in-range` verhindern eine falsche Endwertaggregation. `cpassword` wird nie Ã¼bernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 247 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Group-Policy-Preferences um den CSE Services erweitert: technische NTServices-/NTService-CLSIDs, kanonische Item-UIDs, Common Options und Targeting werden validiert. Services verwendet die CSE-spezifische Instruktion `configure`; `serviceAction`, `startupType`, Dienstkonto, Desktopinteraktion, Fehleraktionen und dokumentierte Zeit-/Recovery-Felder bleiben getrennt und unverÃ¤ndert. Nur Computer-Scope wird reduziert; User-Scope und unbekannte Eigenschaften bleiben `partial`, fehlerhafte unterstÃ¼tzte Werte blockieren fail-closed. `cPassword` wird nie Ã¼bernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 242 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Group-Policy-Preferences um den CSE Local Users and Groups erweitert: technische Groups-/User-/Group-CLSIDs, Item-UIDs, Aktionen, Common Options und Targeting werden validiert; Benutzer-, Gruppen- und Mitgliedschaftswerte bleiben getrennt. SID-PrioritÃ¤t, Delete-all-users/-groups vor der geordneten Memberliste und Add/Remove je Mitglied werden erhalten. `cpassword` wird niemals Ã¼bernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 237 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Ersten Group-Policy-Preferences-Vertikalschnitt umgesetzt: begrenzter XML-Parser mit Ablehnung aktiver/externer Konstrukte, strikter CLSID-/UID-/AttributprÃ¼fung und Geheimnisindikator; eigener Registry-Preference-Reducer bewahrt Create/Delete/Replace/Update, Reihenfolge, Disabled, Remove-on-unapply, Apply-once und nicht ausgewertetes Item-Level-Targeting. Unbekannte CSEs und Registry-SubProperties bleiben `partial`, fehlerhafte unterstÃ¼tzte Strukturen blockieren ohne Salvage und `effectiveState` bleibt `unknown`. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 234 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Advanced-Audit-Vertikalschnitt umgesetzt: Der allgemeine CSV-Pfad stellt nur begrenzte lexikalische Dekodierung und physische Quellzeilen bereit; ein eigener versionierter Parser/Reducer wertet technische Subcategory-GUIDs und numerische Auditflags 0 bis 3 aus, ignoriert lokalisierte Anzeigenamen, unterstÃ¼tzt vorerst nur Systemziele und hÃ¤lt benutzerspezifische Ziele `partial`. Abweichende Dubletten werden Konflikte, fehlerhafte unterstÃ¼tzte Zeilen blockieren ohne Salvage und `effectiveState` bleibt `unknown`. Beobachtungen durchlaufen Worker, Backupinstanz, atomaren Job-Commit, lokalen Export und PostgreSQL-JSONB-Roundtrip. 228 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Ersten artefaktspezifischen Phase-13B-Parser umgesetzt: begrenztes UTF-8/BOM-UTF-16-INF-Parsing fÃ¼r Security Templates, getrennte Instruktionen fÃ¼r System Access, Kerberos, Privilege Rights und Registry Values sowie versionierter Reducer zu validierten Policy-Beobachtungen. Quellzeilen, Parser-/Reducer-Version, technischer Artefaktbezug und rohe typisierte Werte bleiben erhalten; abweichende Dubletten werden Konflikte, unbekannte Abschnitte `partial`, ungÃ¼ltige unterstÃ¼tzte Werte blockiert und `effectiveState` bleibt `unknown`. Beobachtungen durchlaufen Worker, Backupinstanz, atomaren Job-Commit, lokalen Export und PostgreSQL-JSONB-Roundtrip. 222 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Container entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Lease-basierte GPO-JobausfÃ¼hrung und unverÃ¤nderliche Ergebnispersistenz umgesetzt: Der begrenzte Runner claimt nur `analyze-gpo-backup`, liest das projektgebundene Original Ã¼ber den integritÃ¤tsprÃ¼fenden Artefaktspeicher und persistiert versionierten Processing Run plus Backupinstanzen atomar vor dem Jobabschluss. Deterministische IDs ermÃ¶glichen revisionsneutrale Wiederaufnahme nach einem Crash zwischen Commit und Queue-Abschluss; abweichende Historie wird abgelehnt. Migration 005 ergÃ¤nzt die relationale Tabelle mit zusammengesetzter Projekt-/Artefakt-/Run-Referenz. 215 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. AusschlieÃŸlich synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. Weitere Policy-Artefaktparser und Reducer bleiben offen. |
| 2026-07-21 | Projektgebundene GPO-Submission umgesetzt: sichere GrÃ¶ÃŸen-/Base64-PrÃ¼fung an der HTTP-Grenze, Projekt- und Worker-VorprÃ¼fung vor Aufbewahrung, `secret`-SensitivitÃ¤t, Webroot-TrennungsprÃ¼fung, unverÃ¤nderte Speicherung sowie deterministische Artefakt- und idempotente JobidentitÃ¤t. API und Client geben keine SpeicherschlÃ¼ssel oder geparsten Inhalte aus. Additive PostgreSQL-Migration 004 ergÃ¤nzt `analyze-gpo-backup`; realer Persistenz-/Lease-Test gegen kurzlebiges PostgreSQL 16 erfolgreich. 210 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf Ã¼bersprungen und separat 5 von 5 erfolgreich. AusschlieÃŸlich synthetische Daten; Testcontainer anschlieÃŸend entfernt. JobausfÃ¼hrung und relationale GPO-Ergebnispersistenz bleiben offen. |
| 2026-07-20 | Phase-13B-Vertikalschnitt erweitert: backendkontrollierter Rohartefaktspeicherbaustein mit zufÃ¤lligen SchlÃ¼sseln, Staging, Flush, tatsÃ¤chlicher SHA-256-/GrÃ¶ÃŸenprÃ¼fung, Ã¼berschreibungsfreier VerÃ¶ffentlichung und verifizierten Reads; selektiver verifizierter ZIP-Zugriff; begrenzter XML-Metadatenparser im GPO-Worker; konservative Backupinstanzen aus getrennten GPO-/Backup-IDs und Same-root-Evidenz. Namen werden nicht als IdentitÃ¤t verwendet, Konflikte blockieren fail-closed und `cpassword`-Werte werden nicht ausgegeben. 201 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich, 5 optionale PostgreSQL-Tests Ã¼bersprungen; ausschlieÃŸlich synthetische Daten, keine SchemaÃ¤nderung. Ã–ffentliche API-/Job-/Projektbindung und relationale GPO-Persistenz bleiben offen. |
| 2026-08-01 | Minimierte Result-Fenster: automatisches sequentielles Stapeln in Ã–ffnungsreihenfolge umgesetzt; ab 2 minimierten Fenstern erscheint oben links am ersten Result ein Verschiebe-Viereck mit 4-Pfeile-Symbol zum Verschieben des gesamten Clusters. Das Minimieren/Maximieren-Symbol wurde links neben den "To Matrix" ("To Report") Button platziert. 475 Unit-Tests, Local-only-SicherheitsprÃ¼fungen, Designsystem-Zusagen und Client-/Server-Produktionsbuild erfolgreich verifiziert. |
| 2026-07-20 | Sichere GPO-ZIP-Inventarisierung umgesetzt: eigener produktiv gebauter Backend-Worker mit Eingabe-, ParallelitÃ¤ts-, Heap- und Zeitgrenzen; vollstÃ¤ndige PrÃ¼fung von Zentralverzeichnis und lokalen Headern, Pfaden, Unicode-/Case-Kollisionen, Typen, Datenbereichen, tatsÃ¤chlichen GrÃ¶ÃŸen und KompressionsverhÃ¤ltnissen, CRC und SHA-256. Links, Spezialdateien, verschachtelte Archive und Strukturkonflikte blockieren atomar; Inhalte werden nur im Speicher geprÃ¼ft und nicht ausgeschrieben. GPO-Pfade erzeugen ausschlieÃŸlich vorsichtige Rollen-/Abschnittsklassifikation mit inventory-only oder unsupported; Parser- und Geheimnisstatus bleiben explizit offen. 189 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Serverbuild erfolgreich, 5 optionale PostgreSQL-Tests Ã¼bersprungen; ausschlieÃŸlich synthetische ZIP-Fixtures, keine SchemaÃ¤nderung. |
| 2026-07-20 | Phase 13B begonnen: GPO-Bestandsaufnahme und Bedrohungsmodell dokumentiert, gemeinsame sichere relative Artefaktpfade gehÃ¤rtet sowie versionierte GPO-Backup-, Inventar-, Abschnitts-, DomÃ¤nen-, Erhebungs-, Backupsatz- und SnapshotvertrÃ¤ge implementiert. Der deterministische Builder trennt historische Sets und DomÃ¤nen, blockiert Duplikate, Konflikte und unzulÃ¤ssige Erhebungszeitspannen und erlaubt Set-Abwesenheitsaussagen nur fÃ¼r konsistente manifestgestÃ¼tzte vollstÃ¤ndige Exporte; Scope oder tatsÃ¤chliche Wirksamkeit werden nicht behauptet. AusschlieÃŸlich synthetische Regressionen ergÃ¤nzt; 182 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 5 optionale PostgreSQL-Integrationstests im Standardlauf Ã¼bersprungen. Sichere Container-Ingestion, Speicher, Parser und Evaluation bleiben offen. |
| 2026-07-20 | Phase 13A abgeschlossen: Scannerpersistenz auf das bestÃ¤tigte versionierte Candidate-Mapping migriert, plattformneutrale kanonische Candidate-Projektion ergÃ¤nzt, native JSON-Provenienz erhalten, Vorschau-/PersistenzzÃ¤hlung vereinheitlicht und offene beziehungsweise manipulierte native Candidate-Entscheidungen abgesichert. Purple Knight, PingCastle, CIS-CAT, Maester, generischer Fallback sowie semantisch Ã¤quivalente CSV-/JSON-Inhalte wurden synthetisch bis ins kanonische Modell regressionsgeprÃ¼ft; Architekturchecks verhindern Toolwissen in Formatadaptern und Parser-/Mappinglogik in React. 176 Standardtests, Local-only-/ArchitekturprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf Ã¼bersprungen und separat 5 von 5 gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich. |
| 2026-07-20 | Phase-13A-Persistenzunterbau umgesetzt: allgemeine projektgebundene Importartefakte, unverÃ¤nderliche versionierte Processing Runs und persistente idempotente Ingestion Jobs mit atomaren Claims, begrenzten Leases und Versuchen, Recovery sowie Dead Letter in DomÃ¤nenmodell, lokalem Repository und PostgreSQL-Migration 003 ergÃ¤nzt. Projektgrenzen, sichere relative Pfade, Hashes, Speicherreferenzen, Export, LÃ¶schung und revisionsneutrale Wiederholungen sind validiert. 168 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf Ã¼bersprungen und separat 5 von 5 gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich. Phase 13A bleibt bis zur Scanner-Migration in Schritt 9 in Arbeit. |
| 2026-07-20 | Phase-13A-Finding-IdentitÃ¤t abgesichert: versionierte dauerhafte/unresolved IdentitÃ¤tsstrategien eingefÃ¼hrt, unsicheren Titel-Fallback im kanonischen Import entfernt, automatische Titel-/Asset-/Merkmalsmatches im Vergleich entfernt, ProfilvergleichsschlÃ¼ssel auf Regel-IDs begrenzt und explizit bestÃ¤tigte lokale Regeln mit strikter EindeutigkeitsprÃ¼fung erhalten. Synthetische IdentitÃ¤ts-, Vergleichs-, Mehrdeutigkeits- und Validierungsregressionen ergÃ¤nzt; 163 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Mappingtrennung umgesetzt: versionierte Candidate-Mapping-VertrÃ¤ge und eine gemeinsame Feldrollen-Evidenz fÃ¼r Recognition und Mapping eingefÃ¼hrt, Extractor- und Mappingprofil-Provenienz getrennt sowie Mapping nach bestÃ¤tigten Profil-/Feldentscheidungen deterministisch neu berechnet. Originalwerte und Locators bleiben erhalten; die kanonische Persistenz bleibt bis Schritt 9 auf dem bestehenden Pfad. Synthetische Mapping-, Varianten-, Provenienz- und BestÃ¤tigungsregressionen ergÃ¤nzt; 159 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Source-Extractor-Registry umgesetzt: neutrale FindingCandidate-VertrÃ¤ge, statische deterministische Registry, nativer JSON-Objektextractor und generischer Tabellenfallback eingefÃ¼hrt sowie parallel in die plattformneutrale Importpipeline aufgenommen. Bestehende kanonische Persistenz bleibt bis zur Mappingmigration unverÃ¤ndert. Synthetische Registry- und Strukturtreuetests ergÃ¤nzt; 154 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Formaterkennung umgesetzt: zentrale evidenzbasierte Parserwahl mit Excel-/OLE-/ZIP-Signaturen, Inhaltsstruktur, Endungs- und MIME-Hinweisen eingefÃ¼hrt; tatsÃ¤chliches Format steuert Sicherheitslimits, generische ZIPs, unbekannte BinÃ¤rdaten und vorgetÃ¤uschte Excel-Dateien werden kontrolliert abgewiesen. Synthetische Spoofing- und Ressourcenregressionen ergÃ¤nzt; 152 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Vertragsblock umgesetzt: DecodedSourceDocument, gemeinsame Source-Locators, versionierte Adapter-/Transformationsprovenienz und deterministische Processing-States eingefÃ¼hrt; JSON-/XML-Originalstrukturen und bereinigter HTML-Text bleiben zusÃ¤tzlich zur bestehenden tabellarischen UI-Projektion erhalten. Synthetische Architekturregressionen ergÃ¤nzt; 148 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase 13A begonnen: Profilauswahl auf die gemeinsame Recognition Engine vereinheitlicht, Dateiname-only- und mehrdeutige Erkennung auf explizite BestÃ¤tigung begrenzt, BestÃ¤tigungs-Overrides durch Client und Backend konsistent und serverseitig validiert verarbeitet sowie Scan-Lauf-Werkzeug und Dateiprofil getrennt. Synthetische Regressionen ergÃ¤nzt; 147 Standardtests, Local-only-SicherheitsprÃ¼fung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemÃ¤ÃŸ Ã¼bersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Verbindliche Planung fÃ¼r Ingestion 2.0 und GPO-/Baselineanalyse ergÃ¤nzt: neue offene Phasen 13A und 13B, gemeinsame Adapter-/Extractor-/Mappinggrenzen, eigenes PolicyObservation- und Evaluationsmodell, sichere Artefaktaufbewahrung, Analysesnapshots, CSE-spezifische Reduktion, typisierte Comparatoren, vollstÃ¤ndigkeitsgesicherter Baseline-Consensus, Mehrquellen-Evidenz, Reprocessing sowie neue Entscheidungen und Risiken dokumentiert. Es wurden keine Implementierung und keine Meilensteinabnahme vorgenommen. |
| 2026-07-18 | Mandantenladen auf vollstÃ¤ndige Historie erweitert: Open lÃ¤dt nun alle Assessment-Modelle parallel, vereinigt sÃ¤mtliche Scan-LÃ¤ufe und Findings im Projektblatt und erhÃ¤lt pro Quelltabelle eine getrennte, laufbezogene Work-Ansicht. Die Regression wurde ausschlieÃŸlich mit synthetischen CSV- und Excel-Assessments geprÃ¼ft; reale Mandantendaten wurden nicht gelesen. 145 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-18 | Open-to-Work-LÃ¼cke geschlossen: Beim Ã–ffnen eines Mandanten werden dessen Assessments abgefragt, das neueste kanonische Modell geladen und aus Originalfeldern, Quelldateien und Quelltabellen wieder als Work-Dataset aufgebaut. Der reale PostgreSQL-Mandant Test01 Ã¶ffnet damit 162 PurpleKnight-DatensÃ¤tze in neun auswÃ¤hlbaren Ansichten; Graph wird gleichzeitig nutzbar. 144 Tests, Local-only-PrÃ¼fung, Produktionsbuild und Browser-End-to-End-PrÃ¼fung erfolgreich. |
| 2026-07-18 | Phase-12-Datahub nachgeschÃ¤rft: Mehrdatei-Uploads werden nach Scan-Lauf gruppiert und vorhandene achtteilige PurpleKnight-CSV-Exporte als ein PurpleKnight-Bericht angezeigt; neue Importe Ã¼bertragen ein eindeutig erkanntes Batch-Werkzeug auf generische Begleitdateien. Der Mandanteneditor scrollt vollstÃ¤ndig, verwendet die flache Work-Designsprache und besitzt oben Import Data, Save sowie bestÃ¤tigtes Datenbank-Feedback; der alte Formularfooter wurde entfernt. AuÃŸer Datahub bleibt die Navigation bis zum expliziten Open deaktiviert. 142 Tests, Local-only-PrÃ¼fung, Client-/Serverbuild, PostgreSQL-Health und Browser-End-to-End-PrÃ¼fung erfolgreich. |
| 2026-07-17 | Phase-12-Mandantenbedienung prÃ¤zisiert: Open aktiviert den Mandanten und wechselt nach Work; Work ist ohne Mandanten deaktiviert. Edit wurde vom abgedunkelten Popup in eine eigene Datahub-Seite mit Name, Bemerkung, Consultant, Import Data und chronologischer Dateihistorie Ã¼berfÃ¼hrt; Delete behÃ¤lt den geforderten Warnungsdialog. 138 Tests, Local-only-PrÃ¼fung, Client-/Serverbuild, PostgreSQL-Health und Browser-Rendering erfolgreich. |
| 2026-07-17 | Phase-12-Mandantenworkflow vervollstÃ¤ndigt: Der Datahub ist alleinige Import-Schaltzentrale; Mandantenkacheln besitzen Open/Edit/Delete, die Detailansicht Import Data und bestÃ¤tigungspflichtiges Delete sowie eine nach Quelldatum sortierte Scanberichtshistorie. Zielimporte aktualisieren bestehende Mandanten transaktional, ohne deren Namen zu Ã¼berschreiben; eine schlanke Repository-/API-Abfrage liefert Importdateien ohne vollstÃ¤ndigen Finding-Export. 138 Tests, Local-only-PrÃ¼fung und Client-/Serverbuild erfolgreich. |
| 2026-07-17 | Frontend- und Betriebsregression nach Phase 13 behoben: Datahub, Work und Graph besitzen wieder klar getrennte OberflÃ¤chen; Reader-Toolbar und Filter erscheinen nur im Arbeitsbereich. Vite leitet /api im Entwicklungsbetrieb an das lokale Backend weiter, der Client prÃ¼ft die Verbindung erneut und start:local lÃ¤dt die vorhandene PostgreSQL-Konfiguration. Client-/Serverbuild, 136 Tests, Local-only-PrÃ¼fung, PostgreSQL-Health und direkter sowie proxied API-Aufruf erfolgreich; Browseransicht bei 1440 Ã— 900 gerendert. |
| 2026-07-17 | Phase-13-UI-NachhÃ¤rtung: Finding-Auswahl von vollstÃ¤ndiger Filter-/Facettenberechnung entkoppelt, Kacheln, Titel und Result-VerknÃ¼pfungen memoisiert, verknÃ¼pfte Result-Tabellen bis zum Ã–ffnen lazy gerendert, lokale Review-Persistenz aus dem sichtbaren Update verschoben und Result-Farbzuordnung im Light Mode korrigiert; Regressionstests, Standardsuite und Produktionsbuild erfolgreich. |
| 2026-07-17 | PingCastle-HTML-NachhÃ¤rtung: stackabhÃ¤ngige Base64-RegelprÃ¼fung, DOM-Volltextauswertung, Tabellenbreiten- und Zahlenbereichsberechnung durch iterative Verfahren ersetzt; begrenzte Extraktion fÃ¼r groÃŸe oder tief verschachtelte HTML-Berichte ergÃ¤nzt und mit 5,9-MB-PingCastle-Fall, 140.000 Zeilen sowie echtem Produktionsworker verifiziert. |
| 2026-07-17 | Phase 13 abgeschlossen: zentrale Importressourcenrichtlinie, ZIP-/XML-/HTML-/VBA-HÃ¤rtung, CSV-Formelschutz, isolierte Parserworker mit Zeit-, Speicher- und Warteschlangengrenzen, begrenzter Vorschaucache sowie erweiterte Audit-, Sicherheits- und Lasttests integriert; 49 Testdateien mit 139 Tests, Local-only-PrÃ¼fung, Produktionsbuild, Worker-API-Smoke-Test und echte PostgreSQL-16-Integration erfolgreich. |
| 2026-07-17 | Phase 12 abgeschlossen: heterogener Vorschau- und Freigabeworkflow, erklÃ¤rbare Zuordnungen, kontrollierte Einzelfehler, SHA-256-Dublettenerkennung, dauerhafte Fingerprint-Historie, kanonische Batchkonvertierung und atomarer PostgreSQL-Abschluss integriert; 44 Testdateien mit 119 Tests, SicherheitsprÃ¼fung, Produktionsbuild und echter PostgreSQL-16-Integration erfolgreich. |
| 2026-07-17 | Phase 11 abgeschlossen: PostgreSQL-Repository, relationales JSONB-Hybridschema, prÃ¼fsummengeschÃ¼tzte Migrationen, atomare Importtransaktionen, Volltext-/JSONB-Indizes, Docker-Entwicklungsbetrieb und sicherer Backendstart integriert; 40 Testdateien mit 108 Tests, echter PostgreSQL-16-Lauf, Produktionsbuild, Health-PrÃ¼fung sowie praktischer Backup-/Restore-Test erfolgreich. |
| 2026-07-17 | Phase 10 abgeschlossen: lokales Node.js-Backend, versionierte Same-Origin-API, serverseitige Importengine fÃ¼r CSV, JSON, HTML, XML und Excel, statische Browserauslieferung, Sicherheitsheader, Requestschutz, strukturierte Fehler und Audit-Ereignisse integriert; 36 Testdateien mit 101 Tests, SicherheitsprÃ¼fung, Produktionsbuild und gestarteter localhost-PrÃ¼fung erfolgreich. |
| 2026-07-17 | Phase 9 abgeschlossen: datenbankunabhÃ¤ngiger Repository-Vertrag, atomare Importtransaktionen, optimistische KonfliktprÃ¼fung sowie Verwaltung von Reviews, Profilen, Mappingregeln, Vergleichen, Export und LÃ¶schung integriert; 33 Testdateien mit 91 Tests, Local-only- und ArchitekturprÃ¼fung sowie Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 8 abgeschlossen: reproduzierbare Mehrlauf-Vergleichsengine, eindeutiges Stufenmatching, Lebenszyklus- und Ã„nderungsanalyse sowie wiederverwendbare lokale Mappingregeln integriert; 32 Testdateien mit 85 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 7 abgeschlossen: dynamische Kategorie-, Zahlen-, Datums-, Herkunfts- und Reviewfacetten sowie sichtbare Import- und MappingqualitÃ¤t integriert; 31 Testdateien mit 79 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 6 abgeschlossen: versioniertes Profilschema, gemeinsame Profil-Fabrik und Profile fÃ¼r Generic, Purple Knight, PingCastle, CIS-CAT Pro und Maester integriert; 29 Testdateien mit 74 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 5 abgeschlossen: erklÃ¤rbare Quellen-, Tabellen- und Feldrollenerkennung, vier Konfidenzklassen, verlustfreier Fallback und Korrekturschnittstelle integriert; 28 Testdateien mit 68 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 4 abgeschlossen: plattformneutraler Bytequellen-Engine-Einstieg, Browseradapter fÃ¼r Datei/Text/Markup/Storage/Download, injizierbarer Clock und ArchitekturprÃ¼fung ergÃ¤nzt; 26 Testdateien mit 63 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 3 abgeschlossen: universelles ImportDocument, gemeinsame Adapterpipeline, Roh-/Dekodiertwerte, Datentypen, Kopfzeilenkandidaten, Quellpositionen und strukturierte Diagnosen fÃ¼r alle Formate ergÃ¤nzt; 24 Testdateien mit 60 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 2 abgeschlossen: kanonisches Assessment- und Finding-Modell, Referenzvalidator, Pilotquellen-Abbildung und Modelldokumentation ergÃ¤nzt; 22 Testdateien mit 55 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 1 abgeschlossen: synthetische, quellengestÃ¼tzte Fixtures fÃ¼r PingCastle, CIS-CAT und Maester ergÃ¤nzt und Ã¼ber den generischen Importweg automatisiert geprÃ¼ft; 21 Testdateien mit 51 Tests, Local-only-PrÃ¼fung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 1 begonnen: Format- und Fehlerfalltests erweitert, generische Fixture und Testbaseline ergÃ¤nzt, Gesamtworkflow und BelastungsfÃ¤lle automatisiert, leere Importe abgewiesen und englische Titelzuordnung korrigiert; Phase bleibt bis zum vollstÃ¤ndigen Quellenkorpus in Arbeit. |
| 2026-07-17 | Ersten versionierten Umsetzungsplan mit Zielarchitektur, Phasen, Abnahmekriterien, Entscheidungen und Risiken angelegt. |