docs: Phase 13E Kontext-Engine und Kontext-Layer planen

Nutzerfreigabe 2026-09-30: kuratierter, quellenbelegter Katalog,
UI-Reihenfolge und Work-Facette Kontext-Cluster. Der Kontext ist eine
parallele, abschaltbare Lesart und beeinflusst nie Verdict, Score,
Filter, Reviews oder Result DB. Kernregel in AGENTS.md aufgenommen;
offene Report-Engine-Entscheidungen im Plan vermerkt. Nur Dokumentation,
Produktversion unveraendert.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

AGENTS.md

@@ -33,6 +33,14 @@
 - Treat Tauri as the current local shell and a possible optional future shell. Do not make new domain logic depend on Tauri when a platform-neutral boundary is possible.
 - The target deployment is an internal browser application with a backend and PostgreSQL. The browser must not access the database directly.
 
+## Context layer (Phase 13E)
+
+- Explicit user decision 2026-09-30: the context engine is a parallel, derived and switchable second reading of stored ASSESSOR results. The technical view stays authoritative. Context never changes, overrides or questions a verdict, score, technical filter or status, review, risk acceptance, Result DB row or Priority Finding. The authoritative ASSESSOR verdict is only displayed next to context, never re-derived. Context produces no pass/fail, no secure/insecure judgement, no platform-default misconfiguration from `Not configured` and no normalized priority. The remediation lever is a plain count of affected conditions and clusters, with no rank, effort or risk score.
+- The data flow is one-way: ASSESSOR results -> context engine -> UI and Report Engine. The engine lives in a platform-neutral module, runs in the backend and reads through a read-only repository port and read-only database access. It never writes to ASSESSOR data and never populates the evaluator's `PolicyRiskRule`, `PolicyDependencyRule` or `stronger/weaker` hooks. It has no own persistence until separately approved with backup and migration. UI and reports read the same context results with the same engine and catalog version.
+- Every context statement comes from a versioned catalog rule with a cited, offline-stored source. Uncatalogued settings stay `not semantically mapped` and are never guessed. Statements are labelled `Kontext`, carry catalog version and source, and say `begünstigt`, never `exploitable` or `confirmed`. Unknown conditions are shown separately and never count as satisfied or unsatisfied. GPO facts describe backup configuration only, never effective host state. They are kept per backup instance with no asserted precedence, and `Not linked`, conflicts and duplicates stay marked. ATT&CK and relationship derivations never enter the Result DB.
+- Switched off means no request, no computation, no rendered context element and no active context filter. Switching off removes an active `Kontext-Cluster` filter. The layer defaults to off, and the choice is stored locally per user. The `Kontext-Cluster` Work facet is visible only while the layer is on; `Source: Scan` stays last. Context uses existing tokens and no pass/fail status colors.
+- Keep a permanent acceptance test: Work, Client Info, score and Result DB show identical counts and verdicts with the layer on and off, and an engine run leaves stored data unchanged. Scope, UI order and acceptance criteria are in `docs/IMPLEMENTATION_PLAN.md`, Phase 13E.
+
 ## Canonical local PostgreSQL
 
 - The single canonical local ASSESSOR datastore for this workspace is the existing Docker Compose project `assessor-2_0`, container `assessor-2_0-postgres-1`, database `assessor`, and volume `assessor-2_0_assessor-postgres-data` on `127.0.0.1:5432`.

docs/IMPLEMENTATION_PLAN.md

@@ -1,5 +1,7 @@
 # ASSESSOR – Umsetzungsplan
 
+2026-09-30 - Phase 13E / Kontext-Engine und abschaltbarer Kontext-Layer (geplant, Nutzerfreigabe, keine Umsetzung): Der Nutzer gibt (a) einen kuratierten, quellenbelegten und versionierten Semantic-/Relationship-/Cluster-Katalog, (b) die Reihenfolge Engine/API, Finding Reader, Pathfinder, Work-Facette, Client Info und (c) die nur bei eingeschaltetem Layer sichtbare Work-Facette `Kontext-Cluster` als Ergaenzung der GPO-Facettenliste frei. Der Kontext ist eine parallele, abschaltbare Lesart ueber gespeicherten Assessor-Ergebnissen. Er veraendert weder Verdict noch Score, technische Filter, Reviews, Result DB oder Priority Findings, und er speist spaeter auch die Report Engine. Kein `CANONICAL_MODEL v2`, weil Observation, Identitaet, Aggregation, Evaluation und Conflict/Duplicate in Phase 13B bereits bestehen. Einzelheiten, Grenzen und Abnahme: Abschnitt Phase 13E. Nur Plan-Dokumentation; Produktversion unveraendert.
+
 Referenzerkennung 2026-09-26 (Phase 13D, erster Umfang umgesetzt und verifiziert, Version 2.8.0): ATT&CK/D3FEND werden gemeinsam aus gespeicherten Originalfeldern erkannt und mit Quellen-/Katalogherkunft in eigenen Laeufen gespeichert. Normale Batchimports leiten automatisch ab; bestehende Scans werden ueber `Recognize references` im Clientbereich explizit nachverarbeitet. Pathfinder und Reader nutzen die gespeicherten Referenzen. PostgreSQL-Migration 023 mit vorherigem verifiziertem Backup; keine Client-Datenbanktrennung, Finding-Identitaets-, Scoring- oder Review-Aenderung. Siehe Phase 13D und `docs/REFERENCE_RECOGNITION.md`.
 
 Status: lebendes Projektdokument  
@@ -602,6 +604,7 @@ Die heutige Tauri-Anwendung bleibt zunächst eine lokale Laufzeitumgebung. Das
 | 13B | Deterministische GPO-Backup- und Microsoft-Baseline-Analyse | in Arbeit |
 | 13C | Scanner Context und Environment Inventory | in Arbeit |
 | 13D | Referenzerkennung und katalogbasierte Einordnung (ATT&CK/D3FEND erster Umfang) | in Arbeit |
+| 13E | Kontext-Engine und abschaltbarer Kontext-Layer (GPO-Pilot, Ausgabe auch ueber Phase-7-Reports) | offen |
 | 14 | Mehrbenutzer- und Firmenbetrieb | offen |
 
 ## 7. Phasen im Detail
@@ -1978,6 +1981,39 @@ Versionsentscheidung: neue rueckwaertskompatible Faehigkeit, Minor-Version 2.8.0
 
 Nachpruefung 2026-09-26: Der Nutzer sah den Referenzbereich in einer bereits geoeffneten Clientansicht nicht. Frontend auf 5173 und Produktionsbundle auf 4173 enthielten die Funktion; nach Strg+F5 bestaetigte der Nutzer die Sichtbarkeit. Ergaenzter synthetischer Interaktionstest oeffnet den Client ueber Auswahl/Manage, prueft den Bereich unter den Stammdaten und verarbeitet per Button exakt den Client ueber alle Timeslots. Zusammen mit den zwei vorhandenen Referenz-UI-Tests bestanden (3/3). Kein Produktionscode geaendert, daher Version weiterhin 2.8.0. Bestehende Scans wurden bei dieser Pruefung nicht nachverarbeitet.
 
+### Phase 13E - Kontext-Engine und abschaltbarer Kontext-Layer
+
+Status: offen (Umfang und verbindliche Grenzen am 2026-09-30 vom Nutzer freigegeben; keine Umsetzung begonnen).
+
+Ziel: Der Assessor erhaelt eine zweite, abschaltbare Betrachtungsweise fuer Gesamtzusammenhaenge. Die Kontext-Engine laeuft parallel zur bestehenden technischen Pipeline, liest deren gespeicherte Ergebnisse ausschliesslich lesend und leitet daraus belegte Zusammenhaenge ab. Die technische Betrachtung bleibt massgeblich und wird weder veraendert noch in Frage gestellt. Dieselben Kontextergebnisse speisen die Report Engine (Phase 7).
+
+Ausgangslage (Pruefung 2026-09-30, nur gelesen): Observation, technische Policy-Identitaet, Snapshotaggregation, Baseline-Evaluation, `Not configured` sowie Conflict-/Duplicate-Diagnosen existieren bereits in Phase 13B. Deshalb entsteht kein `CANONICAL_MODEL v2` und kein Umbau dieser Schichten. Neu sind nur Semantic Catalog, Declared Fact, Bedingungen, Relationship-Katalog, Cluster und Remediation-Hebel. Die ungenutzten Evaluator-Anknuepfungspunkte `PolicyRiskRule`, `PolicyDependencyRule` und `stronger/weaker` werden fuer den Kontext nicht befuellt, weil sie Urteile und Severity des Assessors veraendern wuerden.
+
+Verbindliche Nutzerentscheidungen 2026-09-30:
+- (a) Ein kuratierter Katalog wird als neue Wissensbasis freigegeben: Semantic Definitions, Relationships und Cluster-Regeln. Jede Regel ist versioniert und traegt eine zitierte, offline gespeicherte Quellenangabe. Nicht katalogisierte Einstellungen bleiben ausdruecklich `nicht semantisch zugeordnet` und werden nie geraten.
+- (b) Reihenfolge: zuerst Engine und API ohne UI, dann Finding Reader (Abschnitt `Kontext` nach Problem und Next step), dann Pathfinder (Cluster als Knoten/Zweig mit Details im rechten Panel; bestehende Pathfinder-Regeln bleiben), dann eine Work-Facette, zuletzt eine Client-Info-Uebersicht im bestehenden Kachelsystem nach gesonderter visueller Abnahme.
+- (c) Die Work-Facette `Kontext-Cluster` ergaenzt die festgelegte GPO-Facettenliste, ist aber nur bei eingeschaltetem Layer sichtbar. `Source: Scan` bleibt letzte Facette. Beim Abschalten wird ein aktiver Kontextfilter entfernt.
+
+Verbindliche Grenzen des Kontext-Layers:
+- Der Layer ist eine abgeleitete, abschaltbare Lesart. Er beeinflusst nie Verdict, Score, technische Filter und Status, Reviews, Risikoakzeptanzen, Result DB oder Priority Findings. ATT&CK-/Relationship-Ableitungen gelangen nie in die Result DB.
+- Das Einhaltungsurteil bleibt das autoritative Assessor-Verdict. Die Kontext-Engine erzeugt kein eigenes Pass/Fail, kein `unsicher/sicher`-Urteil, keine Plattform-Default-Fehlkonfiguration aus `Not configured` und keine normalisierte Prioritaet. Der Remediation-Hebel ist nur eine Anzahl betroffener Bedingungen und Cluster, ohne Rang, Aufwand oder Risikoscore.
+- Ausgeschaltet heisst: kein Request, keine Berechnung, kein gerendertes Kontextelement und kein aktiver Kontextfilter. Standard ist `aus`; die Wahl wird pro Anwender lokal gespeichert.
+- Kontextaussagen sind als `Kontext` gekennzeichnet und tragen Katalogversion und Quelle. Sie formulieren `beguenstigt`, nie `ausnutzbar` oder `bestaetigt`. Unbekannte Bedingungen werden ausdruecklich getrennt angezeigt und zaehlen nie als erfuellt oder nicht erfuellt. Keine Pass/Fail-Statusfarben; visuelle Umsetzung nach `assessor-ui` mit bestehenden Tokens.
+- Declared Facts beziehen sich auf die GPO-Backup-Konfiguration, nie auf effektive Host-Zustaende. Die Schluesselbestandteile sind Assessment-Lauf, Backup-Instanz, Semantic-ID und Computer-/User-Scope. Mehrere GPOs ergeben je einen Fact ohne behauptete Vorrangfolge. `Not linked`, Konflikte und Duplikate bleiben sichtbar markiert.
+- Datenweg: plattformneutrales Modul (vorgesehen `src/assessment-context/`), Berechnung im Backend ueber eigenen API-Endpunkt, Nur-Lese-Repository-Port und Nur-Lese-Datenbankzugriff. Die Richtung ist fest: Assessor -> Kontext-Engine -> UI und Reporting, nie zurueck. Zunaechst keine eigene Persistenz: deterministische Berechnung bei Bedarf, begrenzter Cache nach Repository-Revision und Scope, frische Ergebnisse nach Import oder Neuauswertung. Eigene Tabellen nur nach gesonderter Freigabe mit Backup und Migration.
+- UI und Report lesen dieselben Kontextergebnisse mit derselben Engine- und Katalogversion.
+
+Abnahme erster Umfang (Pilot-Cluster `Credential Relay Exposure` mit etwa 8 bis 12 belegbaren GPO-Einstellungen):
+- [ ] Katalogformat, Validierung, Versionierung und Quellenpflicht fuer Semantic, Relationship und Cluster umgesetzt; der Pilotinhalt ist fachlich belegt.
+- [ ] Die Engine erzeugt Declared Facts, Bedingungen, Cluster mit erfuellten/nicht erfuellten/unbekannten Bedingungen und den Remediation-Hebel ausschliesslich aus gespeicherten Assessor-Ergebnissen, mit Evidenz bis zur Observation.
+- [ ] Nur-Lese-Grenze technisch erzwungen (Port-Typ ohne schreibende Methoden, Nur-Lese-Datenbankzugriff) und getestet.
+- [ ] Dauerhafter Abnahmetest: Work, Client Info, Score und Result DB liefern mit Layer an und aus identische Zahlen und Urteile; ein Engine-Lauf veraendert keine gespeicherten Daten.
+- [ ] Ausgeschalteter Layer erzeugt keinen Request und keine Berechnung; Abschalten entfernt einen aktiven Kontextfilter (Verhaltenstest).
+- [ ] UI-Stufen nach (b) jeweils mit synthetischem Interaktionstest und Pruefung beider Themes.
+- [ ] Ausschliesslich synthetische Fixtures mit festen Referenzausgaben; `npm test` und beide Produktionsbuilds bestanden.
+
+Offen und nicht Teil dieser Freigabe: weitere Cluster, Verlaufsbetrachtung ueber den bestehenden Timeslot-Vergleich (keine zweite Drift-Logik), Facts aus Scannerquellen wie CIS-CAT oder PingCastle, Darstellung im Management Report.
+
 ## 8. Aktuell empfohlene Umsetzungsetappe
 
 2026-09-26 - Phase 13D / Phase 13C Darstellung (2.8.3, umgesetzt und verifiziert): Catalog references startet bei aktuellem Client eingeklappt; gruen vor Ueberschrift und aktuellem/erfolgreichem Status, orange und automatisch offen bei Handlungsbedarf oder Fehler. Pruefung, Verarbeitung und leere Clients bleiben neutral. Katalogversionen bleiben eingeklappt sichtbar, Erfolg nach Update bleibt offen, manuelles Umschalten funktioniert per Maus und Tastatur. Timeslots-Zeile mit gleichem Abstand oben/unten und gemeinsam zentrierten Controls. Purple-Knight-Timeslots benennen Active Directory, Entra ID oder kombinierten Scope aus bestehenden kanonischen Namen bzw. exakt lauf-/dateigebundenen gespeicherten Metadaten/Umgebungsbeobachtungen. Ohne Scopebeleg bleibt der Originalname; keine Vermutung aus Dateinamen oder fremden Scans, keine Persistenz-/Importer-/Scoringaenderung und keine neue Reimportpflicht. 36 gezielte Interaktions-/Layout-/Versionsvertragstests, beide Produktionsbuilds, Local-only-/Designcheck und synthetische Dark-/Light-Sicht- und Tastaturpruefung bestanden. App und Backend gesund auf 2.8.3 mit kanonischer PostgreSQL. Patchversion fuer zusammengehoerige UI-Korrekturen; Phase 13D bleibt in Arbeit. Die bekannte Gesamtsuite-Baseline mit sechs fachfremden Fehlern wurde nicht erneut ausgefuehrt.
@@ -2383,6 +2419,8 @@ Abnahme 2026-08-23: 677 Standardtests bestanden, 8 optionale PostgreSQL-Integrat
 
 ## 10. Offene Entscheidungen
 
+Report Engine 2026-09-30 (Phase 7): Die Report Engine soll als eigenstaendiger, rein lesender Baustein im Assessor arbeiten. Machbarkeit geprueft: Projektion, Korrelation, Assembler und beide Renderer existieren bereits. Noch nicht entschieden: Verschiebung nach `src/reporting/`, serverseitiges unveraenderliches Reportarchiv ausserhalb von Repo und OneDrive sowie die Bestaetigung der Kollisionsgrenzen (gemeinsamer Domain-Katalog, keine scanneruebergreifende Severity-Zaehlung, Review-Status nur als Selbstauskunft, Szenarien nur ueber Phase 13E). Die Kontextergebnisse aus Phase 13E sind als Eingabe der Report Engine vorgesehen.
+
 Autonome Client-Datenbanken 2026-09-26: Das Zielbild "eine fachliche Datenbank pro Client" und die autarke Wiederherstellung einschliesslich verwendeter Referenzstaende sind entschieden; Implementierung und Migration sind nicht beauftragt. Vor einer Umsetzung sind Client-Routing und Autorisierung, Ort und Lebenszyklus des zentralen Katalogs, Bindung und Pruefsummen der Referenzartefakte, Backup-/Restore-Paketformat, Lizenz-/Bezugsgrenzen der Microsoft-Pakete, clientindividuelle Overrides, Update-/Rollback-Ablauf und Migration des bestehenden kanonischen Bestands zu spezifizieren und mit synthetischen Isolation-, Historien- und Offline-Restore-Tests abzusichern. Die genaue SSO-, Rollen- und Betriebsplattform bleibt offen.
 
 Bericht A/B 2026-09-23: Die Nutzeranforderung beauftragt die HTML-Erzeugung direkt aus Client Info und ordnet die UI-Anbindung Phase 7 zu. Die veroeffentlichten Report-Inhalte bleiben durch `docs/REPORT_STRATEGY.md` gebunden. Offen ist die endgueltige Vollstaendigkeitsabnahme des Technical Reports ueber alle Quellformate und Reimport-/Diagnostic-Klassen; sie wird nicht aus dem Vorhandensein des Buttons abgeleitet.
@@ -2412,6 +2450,8 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
 
 ## 11. Risiken
 
+- 2026-09-30, Kontext-Layer (Phase 13E): Kontextaussagen koennten als zweites Urteil oder als bestaetigter Angriffsweg gelesen werden. Gegenmassnahmen: kein eigenes Verdict, Kennzeichnung `Kontext` mit Quelle und Version, `beguenstigt`-Formulierung, sichtbare unbekannte Bedingungen und der dauerhafte An/Aus-Gleichheitstest. Der Katalog ist die fachliche Hauptlast; eine unbelegte Regel wuerde eine erfundene Aussage erzeugen und ist deshalb ohne Quelle unzulaessig.
+
 - 2026-09-26, autonome Client-Datenbanken: Eine getrennte Datenbank allein garantiert keine Autarkie, wenn Baseline-/MITRE-Versionen oder GPO-/Baseline-Originale nur zentral verfuegbar sind. Backup, Restore und Loeschung muessen Datenbank und private Artefakte gemeinsam behandeln. Zentrale Referenzupdates duerfen historische Urteile nicht still neu berechnen und ein Clientwechsel darf keine Datenbank oder Artefakte eines anderen Clients erreichen. Die bisher globale Baseline-Liste und der serverweite MITRE-Katalog sind noch nicht clientgebunden; ihre blosse Verschiebung in der UI waere keine Isolation. Ein Migrationskonzept mit verifiziertem Backup ist vor jeder Bestandsaenderung erforderlich. Diese Risiken sind als Planungsaufgaben offen; keine Implementierung oder Abnahme wird behauptet.
 
 - 2026-09-23, HTML-Reports: Die Management-Datei darf keine internen Source-IDs, Assets oder technischen Rohwerte enthalten, auch wenn beide Renderings dieselbe interne Projektion nutzen. Separate Dateien und ein synthetischer Leckagetest sichern die Grenze. Der Technical Report kann nur gespeicherte Originalfelder und GPO-Anweisungen zeigen; fehlende Ist-/Sollstruktur, Source-Evidence oder Parserdiagnose wird nicht erfunden. Ein umfassender Vollstaendigkeits- und Theme-Test im freigegebenen Dummy ist noch offen; bis dahin gilt die A/B-Abnahme nicht als abgeschlossen.
@@ -2734,6 +2774,8 @@ Festgelegtes Betriebsrisiko vom 2026-09-06: Verzeichnisabhaengige Compose-Projek
 
 ## 12. Änderungsprotokoll
 
+2026-09-30 - Phase 13E / Kontext-Engine und abschaltbarer Kontext-Layer (geplant, Nutzerfreigabe, keine Umsetzung): Der Nutzer gibt (a) einen kuratierten, quellenbelegten und versionierten Semantic-/Relationship-/Cluster-Katalog, (b) die Reihenfolge Engine/API, Finding Reader, Pathfinder, Work-Facette, Client Info und (c) die nur bei eingeschaltetem Layer sichtbare Work-Facette `Kontext-Cluster` als Ergaenzung der GPO-Facettenliste frei. Der Kontext ist eine parallele, abschaltbare Lesart ueber gespeicherten Assessor-Ergebnissen. Er veraendert weder Verdict noch Score, technische Filter, Reviews, Result DB oder Priority Findings, und er speist spaeter auch die Report Engine. Kein `CANONICAL_MODEL v2`, weil Observation, Identitaet, Aggregation, Evaluation und Conflict/Duplicate in Phase 13B bereits bestehen. Einzelheiten, Grenzen und Abnahme: Abschnitt Phase 13E. Nur Plan-Dokumentation; Produktversion unveraendert.
+
 2026-09-26 - Phase 6/7 / Scanner-Einstieg, CIS-Abschnitte, Work-Zusammenfuehrung (2.8.6, umgesetzt und verifiziert): Purple-Knight-Umfangsnamen loesen ueber Profil-`runNames` auf; Maester-Abschnitt `Remediation action` als Next step; PowerShell-Skripte nach `script ...:` bzw. mit Variablenzuweisung als Befehlsblock mit Anzeige-Zeilenumbruechen; Purple-Knight-Likelihood ohne angehaengte Referenzen; CIS-Abschnittsnamen aus dem eigenen Scanlauf in `CIS Category`, Work-Ueberschriften und Plaketten-Tooltips; `withRebuiltLayout` erhaelt beim GPO-Anhang alle Datensatzmetadaten. Patchversion, kein Reimport; Details im Statusnachtrag oben.
 
 2026-09-26 - Phase 13D / gemischte Work-Projektion (2.8.5, umgesetzt und verifiziert): Beim Anhaengen von GPO-Ergebnissen an All Records wird referenceRecognition jetzt vom jeweiligen Scannerbefund uebernommen. Zuvor blieben die Referenzlaeufe gespeichert, gingen aber beim Neuaufbau der Reader-Projektion verloren. Die Uebernahme bewahrt Referenzen, Quellenherkunft, Erkennerversion, Lauf und Katalogversion/-hash einschliesslich bewusst leerer Erkennung; GPOs und nicht indexierte Befunde erhalten keine fremden Referenzen. Synthetische Regression oeffnet Referenzdetails im echten FindingReader mit und ohne GPOs. 30 fokussierte Referenz-/GPO-/CIS-Tests und 9 UI-/API-Versionsvertragstests, beide Produktionsbuilds sowie Design-/Local-only- und Diffpruefung bestanden. Patchversion fuer rueckwaertskompatible Projektionskorrektur; keine Datenmutation und kein Reimport bzw. neuer Erkennungslauf erforderlich. Bereits geladene Workspaces muessen neu geladen werden. Phase 13D bleibt in Arbeit.