diff --git a/.claude/skills/assessor-ui/README.md b/.claude/skills/assessor-ui/README.md index 75c991e..0008f80 100644 --- a/.claude/skills/assessor-ui/README.md +++ b/.claude/skills/assessor-ui/README.md @@ -20,23 +20,14 @@ cp -r assessor-ui ~/.claude/skills/ ## Einbindung im Projekt -Die Token- und Komponentendateien sind nicht nur Dokumentation, sondern die Implementierungsbasis: - -```bash -cp .claude/skills/assessor-ui/assets/tokens.css src/styles/tokens.css -cp .claude/skills/assessor-ui/assets/components.css src/styles/components.css -``` - -Einstiegspunkt des Stylesheets: - -```css -@layer tokens, base, shell, components, utilities; - -@import "./styles/tokens.css"; -@import "./styles/base.css"; -@import "./styles/shell.css"; -@import "./styles/components.css"; -``` +Nutzerkorrektur 2026-09-18: Data Hub, Work und Pathfinder sind die verbindlichen +Ableton-inspirierten Referenzen, auch fuer Client Info, Mockups und Prototypen. +Zuerst [AGENTS.md](../../../AGENTS.md#binding-assessor-design-language) und den +Vorrangabschnitt in `SKILL.md` lesen. Die aktuellen Projekt-Tokens liegen in +`src/styles/ui-tokens.css`; bestehende Komponenten und Styles werden weiterverwendet. +Die Dateien unter `assets/` und aeltere Referenzskizzen sind historische Beispiele. +Sie duerfen nicht ueber die aktuellen Styles kopiert oder erneut in den Build +eingebunden werden. Die fruehere Kopieranleitung ist hiermit ausdruecklich aufgehoben. Theme und Dichte am Wurzelelement: @@ -63,7 +54,7 @@ Erlaubte Werte: `data-theme` = `dark` oder `light`, `data-density` = `compact`, Der Skill triggert automatisch bei UI-Aufgaben an ASSESSOR. Erzwingen laesst er sich mit: ```text -Nutze den Skill assessor-ui. Baue die Datahub-Uebersicht auf Archetyp D um. +Nutze den Skill assessor-ui. Gestalte Client Info mit der bestehenden Designsprache von Data Hub, Work und Pathfinder. ``` Vor dem Abschluss einer Aenderung: diff --git a/.claude/skills/assessor-ui/SKILL.md b/.claude/skills/assessor-ui/SKILL.md index 973ed4e..d59f536 100644 --- a/.claude/skills/assessor-ui/SKILL.md +++ b/.claude/skills/assessor-ui/SKILL.md @@ -16,6 +16,36 @@ description: >- Verbindliches Designsystem fuer ASSESSOR. Keine Empfehlung, keine Inspiration: Vorschrift. +## Verbindliche Referenzen und Vorrang, Nutzerkorrektur 2026-09-18 + +Die aktuell vom Nutzer freigegebenen Ansichten **Data Hub, Work und Pathfinder** +sind die konkrete Ableton-inspirierte ASSESSOR-Referenz. Sie gelten ausdruecklich +auch fuer **Client Info**, einschliesslich Source Overview, Environment Detail und +Accepted Risks, sowie fuer Bildentwuerfe und Prototypen. Die drei am 2026-09-18 +verworfenen generischen Client-Info-Mockups sind keine freigegebenen Vorlagen. + +Massgeblich sind [AGENTS.md](../../../AGENTS.md#binding-assessor-design-language), +die aktuellen Komponenten und [ui-tokens.css](../../../src/styles/ui-tokens.css). +Die fruehere Client-Info-Designausnahme ist aufgehoben. Fachliche Inhalte, +Scoresemantik und Drilldowns bleiben erhalten; ihre Darstellung folgt denselben +Flächen-, Tile-, Button-, Typografie-, Abstands- und Zustandsregeln wie die Referenzen. + +Diese datierte Festlegung hat Vorrang vor allen aelteren Beispielen und Tabellen +in diesem Skill, seinen `references/` und `assets/`. Insbesondere sind eine violette +Auswahl/Primaeraktion, kleine Fliesstextrollen, starre gekuerzte Tiles, dekorative +Donutschatten/Verlaeufe, ein erzwungener Tabellenumbau von Data Hub und eine neue +Shell keine aktuellen Vorgaben. Die aktuelle gelb/bernsteinfarbene Markierung und +Aktionsfarbe, der blaue Tastaturfokus, Inter, die 16px-Lese- und 14px-Datenrolle, +20px Panel-Inset sowie flache Tiles und volle 360-Grad-Donuts sind verbindlich. +Bestehende runde Hauptpanels behalten ihre gemeinsame Geometrie; die Tiles darin +bleiben eckig. Historische Skill-Assets niemals ueber die aktuellen Styles kopieren. + +Vor jeder Abnahme ist der Entwurf bei normalem App-Zoom direkt mit Data Hub, Work +und Pathfinder abzugleichen: Er muss auch ohne Logo wie dieselbe Anwendung wirken. +Mockups verwenden nur eindeutig synthetische Beispieldaten und die echten +Referenzansichten als Stilvorlage; sie erfinden weder Kennzahlen noch eine neue +Navigation. Verankerung, Vorschlag und tatsaechliche UI-Umsetzung getrennt benennen. + ## Zweck ASSESSOR ist ein Analysewerkzeug fuer Active-Directory-Sicherheitsbefunde aus PingCastle, @@ -28,17 +58,17 @@ Loesung erfindet. Genau das hat den heutigen Zustand erzeugt: `Work` sieht ander ## Ablauf bei jeder UI-Aufgabe -1. `assets/tokens.css` und `assets/components.css` lesen. Beide sind die Implementierungsbasis. -2. Betroffenen Seitenarchetyp bestimmen (siehe `references/page-archetypes.md`). +1. Die aktuellen UI-Vereinbarungen in `AGENTS.md`, `src/styles/ui-tokens.css` und die betroffenen bestehenden Komponenten lesen. Die Skill-Assets sind historische Referenzen, keine zu kopierende Implementierungsbasis. +2. Die freigegebene Referenzansicht und das bestehende Layout bestimmen. `references/page-archetypes.md` nur ergaenzend unter dem Vorrang der Nutzerkorrektur vom 2026-09-18 verwenden. 3. Pruefen, ob eine bestehende Komponente ausreicht. Neue Komponente nur, wenn keine Variante passt. 4. Implementieren, ausschliesslich mit Tokens und bestehenden Klassen. -5. Gegen `references/review-checklist.md` pruefen, in Dark UND Light. +5. Direkt gegen Data Hub, Work und Pathfinder sowie die aktuellen AGENTS-Regeln pruefen; fuer Implementierungen in Dark UND Light. `references/review-checklist.md` unter ihrem datierten Vorranghinweis verwenden. 6. Abweichungen benennen, nicht stillschweigend loesen. ## Referenzdateien -- `assets/tokens.css` — alle Farben, Masse, Radien, Schatten, Typografie. Einzige Quelle. -- `assets/components.css` — Referenzimplementierung aller Kernkomponenten. +- `src/styles/ui-tokens.css` (Projektwurzel) — aktuelle Farben, Masse und Typografierollen. +- `assets/tokens.css` und `assets/components.css` — historische Beispiele; bei Abweichungen gelten ausschliesslich die aktuellen Projektvertraege und Implementierungen. - `references/state-model.md` — Zustandsdimensionen und ihre Darstellung. Vor jeder Badge-/Statusarbeit lesen. - `references/components.md` — Komponentenvertraege mit festen Massen und Aufbau. - `references/page-archetypes.md` — Shell und die vier erlaubten Seitenlayouts. @@ -93,7 +123,9 @@ Diese Regeln gelten ohne Ausnahme. Ein Verstoss ist ein Fehler, keine Stilfrage. - Buttonform ist verbindlich und ueberall dieselbe, unabhaengig von der Farbe: `--btn-radius` (abgerundete Ecken), `--btn-h` als Hoehe, `--btn-pad-x` als waagerechtes Polster, senkrecht kein eigenes Polster. Keine Ansicht setzt eine eigene Buttonhoehe, einen eigenen Radius oder - ein eigenes Polster. Ausgenommen sind nur zusammengesetzte Reiter (View-Tabs, Sidebar). + ein eigenes Polster. Auch zusammengesetzte Reiter, Sidebar-Aktionen, Icon-, Disclosure- und + Segment-Schaltflaechen verwenden den gemeinsamen Radius. Echte Kreis-/Donut-Interaktionen und + quadratische Inhaltskacheln behalten ihre semantische Geometrie. - Traegt eine Schaltflaeche Farbe, ist es `--button-accent` (Standardgelb `#E9A63C`, in beiden Skins gleich) mit `--button-accent-text`. Nie ein anderes Gelb, nie der Ton des Command Bands. - Rahmen: 1 px. 2 px ausschliesslich fuer Auswahl- und Fokusrahmen. @@ -103,8 +135,16 @@ Diese Regeln gelten ohne Ausnahme. Ein Verstoss ist ein Fehler, keine Stilfrage. - Schatten: nur `--shadow-overlay` und `--shadow-popover`, nur an echten Overlays. Kein Schatten an Panels, Tiles, Zeilen, Buttons, Tabellen. - Kein Glassmorphism, kein Neumorphismus, kein Farbverlauf als Flaeche, kein Hover-Lift, kein Scale-Effekt. -- Der Akzent (Violett) bedeutet ausschliesslich: Primaeraktion, aktive Ansicht, Auswahl. - Nie Severity, nie Erfolg, nie Markierung, nie Dekoration. +- Violett ist als UI-Rolle vollstaendig entfernt (Nutzerentscheidung 2026-09-20, AGENTS.md `UI segments and tiles`). + Aktive Ansicht, Primaeraktion und Auswahl sind `--marking-color` (Gelb/Bernstein), Tastaturfokus ist + `--focus-ring` (Blau). Kein Token, keine Komponente und kein Graph-/Chart-Ton darf violett aufloesen + oder `--accent*` fuer Auswahl oder Fokus lesen. Eine Tool-/Kategoriefarbe (z. B. ein Chart-Ton) braucht + bei Bedarf einen eigenen, dediziert nicht-violetten Tokenwert statt der fruesheren `--accent`-Wiederverwendung. +- Jeder Farbtoken hat genau eine semantische Rolle (Markierung, Fokus, Severity, Kategorie/Chart-Ton, ...). + Ein Token wird nie in einer Komponente fuer seine dokumentierte Rolle und in einer anderen Komponente + fuer eine zweite Rolle gelesen — das ist exakt der Fehler, der die violette Auswahl/Fokus-Verwechslung + von 2026-09-20 verursacht hat. Vor dem Wiederverwenden eines bestehenden Tokens dessen dokumentierte + Rolle in `ui-tokens.css` und in diesem Skill pruefen. ### Zustaende diff --git a/.claude/skills/assessor-ui/references/page-archetypes.md b/.claude/skills/assessor-ui/references/page-archetypes.md index 903aa15..2aa6f69 100644 --- a/.claude/skills/assessor-ui/references/page-archetypes.md +++ b/.claude/skills/assessor-ui/references/page-archetypes.md @@ -1,5 +1,13 @@ # Shell und Seitenarchetypen +> Nutzerkorrektur 2026-09-18: Dieses Dokument beschreibt historische Layoutbeispiele. +> Massgeblich sind die heute freigegebenen Data-Hub-, Work- und Pathfinder-Ansichten +> und [AGENTS.md](../../../../AGENTS.md#binding-assessor-design-language), auch fuer +> Client Info. Weder die nachfolgende 18px-Topbar-Skizze noch Archetyp D autorisieren +> einen Umbau der aktuellen Shell oder den Ersatz der freigegebenen Data-Hub-Tiles +> durch eine Tabelle. Client Info verwendet dieselbe vorhandene Shell und dieselben +> Komponentenregeln; seine fachliche Anordnung darf innerhalb dieser Sprache variieren. + Es gibt eine Shell und vier Archetypen. Jede Seite von ASSESSOR ist genau einem Archetyp zugeordnet. Eine fuenfte Seitenform wird nicht erfunden. diff --git a/.claude/skills/assessor-ui/references/review-checklist.md b/.claude/skills/assessor-ui/references/review-checklist.md index f139da4..67e36cd 100644 --- a/.claude/skills/assessor-ui/references/review-checklist.md +++ b/.claude/skills/assessor-ui/references/review-checklist.md @@ -1,5 +1,31 @@ # Abnahme und Korrekturliste +## Verbindlicher Abgleich seit 2026-09-18 + +Die Nutzerreferenzen Data Hub, Work und Pathfinder sowie +[AGENTS.md](../../../../AGENTS.md#binding-assessor-design-language) haben Vorrang +vor der historischen Checkliste unten. Das gilt auch fuer Client Info und Mockups. +Insbesondere sind die frueheren Donutschatten-/Radiusausnahmen, der Tabellenumbau +von Data Hub, gekuerzte Tile-Inhalte, die alte Titelskala und violette Auswahl keine +gueltigen Abnahmekriterien. Bewusst freie Restflaeche in einer unvollstaendigen +Tile-Reihe ist zulaessig; Tiles werden nicht zum Fuellen der Breite gestreckt. + +- Ist die Ansicht ohne Logo als dieselbe Anwendung wie alle drei Referenzen erkennbar? +- Entsprechen neutrale Flaechen, eckige Tiles, transparente Segmente, Linien, Controls, + Inter-Typografie und 20px Panel-Inset den gemeinsamen aktuellen Tokens? +- Bleiben gelb/bernsteinfarbene Auswahl/Aktionen, blauer Tastaturfokus und fachliche + Statusfarben unterscheidbar? Keine neue Palette oder neue Shell fuer Client Info. +- Verwenden Donuts volle 360 Grad, flache Bogenenden und korrekt zentrierte Zahlen? +- Sind Lesetext und strukturierte Daten bei normalem Zoom in ihren 16px-/14px-Rollen + lesbar, ohne Clamping, Ellipsen, Ueberlagerung oder eine Wand aus Mikroschrift? +- Behalten Kennzahlen, Source Overview und Drilldowns ihre dokumentierte Bedeutung? + Mockups kennzeichnen synthetische Daten; verworfene Bilder sind keine Stilreferenz. +- Bei Umsetzung: beide Themes, responsive Umbrueche und betroffene Interaktionen + pruefen. Reine Dokumentationsverankerung ist keine visuelle Laufzeitabnahme. + +Die folgenden Abschnitte bleiben als historische Referenz erhalten; widersprechende +Punkte werden durch die obigen Kriterien und AGENTS.md ausdruecklich ersetzt. + ## Inhaltsverzeichnis 1. Automatisierbare Pruefungen diff --git a/.env.postgres.example b/.env.postgres.example index 7f1aaba..7aa0fd8 100644 --- a/.env.postgres.example +++ b/.env.postgres.example @@ -10,16 +10,37 @@ ASSESSOR_GPO_JOB_LEASE_MS=60000 ASSESSOR_GPO_JOB_RETRY_MS=5000 ASSESSOR_GPO_JOB_POLL_MS=1000 -# Optional AI Overview. Leave ASSESSOR_AI_MODE unset to keep outbound AI disabled. -# ASSESSOR_AI_MODE=local -# ASSESSOR_AI_BASE_URL=http://127.0.0.1:11434/v1/ -# ASSESSOR_AI_MODEL=local-model-name -# ASSESSOR_AI_API_KEY= -# ASSESSOR_AI_TIMEOUT_MS=120000 -# ASSESSOR_AI_MAX_PROMPT_CHARS=12000 -# ASSESSOR_AI_MAX_CHUNK_CHARS=60000 -# ASSESSOR_AI_MAX_OUTPUT_CHARS=24000 -# ASSESSOR_AI_MAX_OUTPUT_TOKENS=3000 -# ASSESSOR_AI_JOB_POLL_MS=1000 +# Qdrant is a rebuildable regulatory retrieval index. A key is optional for an unsecured loopback/internal self-host, but required for remote hosts. +ASSESSOR_QDRANT_URL=http://127.0.0.1:6333 +ASSESSOR_QDRANT_PORT=6333 +ASSESSOR_QDRANT_API_KEY=replace-with-a-long-random-local-qdrant-key + +# Required only for regulatory ingestion/retrieval. Use an approved multilingual embedding model. +# ASSESSOR_RAG_EMBEDDING_BASE_URL=https://work-litellm.example/v1 +# ASSESSOR_RAG_EMBEDDING_MODEL=approved-multilingual-embedding-model +# ASSESSOR_RAG_EMBEDDING_API_KEY=replace-with-work-litellm-key +# ASSESSOR_RAG_EMBEDDING_DIMENSIONS=1024 +# Set true only when the provider supports OpenAI's dimensions request (for example text-embedding-3-large). +# Leave false/unset for llama.cpp, which returns the model's native dimension. +# ASSESSOR_RAG_EMBEDDING_REQUEST_DIMENSIONS=false +# ASSESSOR_RAG_EMBEDDING_TIMEOUT_MS=60000 +# ASSESSOR_RAG_CHUNK_CHARACTERS=1600 +# ASSESSOR_RAG_EMBEDDING_BATCH_SIZE=32 +# Operator-only ISO PDF upload in Data Hub. Use an independent random secret of at least 32 characters. +# ASSESSOR_ISO_UPLOAD_TOKEN=replace-with-a-long-random-upload-token +# The mapping API is enabled only for this explicit, already-ingested corpus. +# ASSESSOR_RAG_ACTIVE_CORPUS_ID=iso-27001-27002-de +# ASSESSOR_RAG_ACTIVE_CORPUS_VERSION=din-2024-de-example + +# Optional work LiteLLM AI Overview. Leave ASSESSOR_AI_MODE unset to keep outbound AI disabled. +# Store real values only in the ignored .env.postgres or deployment environment secret. +# ASSESSOR_AI_MODE=litellm +# ASSESSOR_AI_BASE_URL=https://work-litellm.example/v1 +# ASSESSOR_AI_MODEL=approved-model-alias +# ASSESSOR_AI_API_KEY=replace-with-work-litellm-key +# ASSESSOR_AI_TIMEOUT_MS=60000 +# ASSESSOR_AI_CHUNK_CHARS=80000 +# ASSESSOR_AI_MAX_OUTPUT_BYTES=262144 +# ASSESSOR_AI_MAX_CALLS=64 # ASSESSOR_AI_JOB_LEASE_MS=300000 diff --git a/.gitea/workflows/deploy.yml b/.gitea/workflows/deploy.yml index b18e836..38d01e9 100644 --- a/.gitea/workflows/deploy.yml +++ b/.gitea/workflows/deploy.yml @@ -3,8 +3,9 @@ # experimental -> experimental (10.0.0.154:4174) # # The existing HTTPS production deployment is not managed by this workflow. -# Both new environments use separate Compose projects, databases and artifact -# volumes. Their complete environment files come from different Gitea secrets. +# Both new environments use separate Compose projects, databases, artifact +# volumes and rebuildable Qdrant indexes. Their complete environment files come +# from different Gitea secrets. name: Deploy on: @@ -33,7 +34,7 @@ jobs: fi printf '%s\n' "$ASSESSOR_ENV_FILE" > .env chmod 600 .env - for key in ASSESSOR_POSTGRES_DB ASSESSOR_POSTGRES_USER ASSESSOR_POSTGRES_PASSWORD; do + for key in ASSESSOR_POSTGRES_DB ASSESSOR_POSTGRES_USER ASSESSOR_POSTGRES_PASSWORD ASSESSOR_QDRANT_API_KEY; do if ! grep -q "^${key}=." .env; then echo "::error::PROD_ENV_FILE does not contain a value for ${key}." exit 1 @@ -57,7 +58,7 @@ jobs: fi printf '%s\n' "$ASSESSOR_ENV_FILE" > .env chmod 600 .env - for key in ASSESSOR_POSTGRES_DB ASSESSOR_POSTGRES_USER ASSESSOR_POSTGRES_PASSWORD; do + for key in ASSESSOR_POSTGRES_DB ASSESSOR_POSTGRES_USER ASSESSOR_POSTGRES_PASSWORD ASSESSOR_QDRANT_API_KEY; do if ! grep -q "^${key}=." .env; then echo "::error::STAGING_ENV_FILE does not contain a value for ${key}." exit 1 @@ -118,7 +119,7 @@ jobs: services="$(docker ps -a --filter "label=com.docker.compose.project=$ASSESSOR_STACK" --format '{{.Label "com.docker.compose.service"}}' | sort -u)" for service in $services; do case "$service" in - app|postgres) ;; + app|postgres|qdrant) ;; *) echo "::error::Compose project $ASSESSOR_STACK contains an unexpected service." exit 1 diff --git a/.gitignore b/.gitignore index 36e6b37..59291df 100644 --- a/.gitignore +++ b/.gitignore @@ -10,6 +10,11 @@ src-tauri/gen/ vite.config.js vite.config.d.ts *.png +!src/assets/branding/*.png +artifacts/ +Mock-Defender/ +outputs/ +evaluation/ .env.postgres .assessor-data/ @@ -17,3 +22,6 @@ vite.config.d.ts .claude/scheduled_tasks.lock .codex-patches/ .tmp/ +/ISO27001 2024.PDF +/ISO27002 2024.PDF +backups/ diff --git a/AGENTS.md b/AGENTS.md index d2136ed..bd5a27e 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -9,23 +9,57 @@ - After a material, verified implementation step, update the plan's status, decisions, risks, and change log in the same change. Do not rewrite historical decisions silently. - If the requested implementation conflicts with the plan, explain the conflict and update the plan only with the user's agreement or when the request explicitly supersedes it. +## ASSESSOR product version + +- `package.json` is the single source of truth for the visible ASSESSOR product version. Header, About dialog and backend health response must continue to read that shared value; keep the root `package-lock.json` entry and version contract tests synchronized. +- Reassess the product version after every material, verified implementation batch. Increment the patch version for backward-compatible corrections and refinements, the minor version for a backward-compatible capability release, and the major version only for an intentionally breaking product or deployment contract. +- Do not increment the product version for documentation-only edits, test-only maintenance, unfinished work or every individual commit. Batch related work into one release version and record the decision in `docs/IMPLEMENTATION_PLAN.md`. +- A version change is complete only after the product-version UI/API tests and both production builds pass. Historical reports retain the version they documented at creation time and must not be rewritten. + +## Binding agreements and rule conflicts + +- Treat documented user decisions, this file, and the implementation plan as binding acceptance criteria. Before changing an affected behavior, identify and preserve every relevant agreement; later work must not silently weaken, replace, or bypass it. +- If a requested change conflicts with a binding project rule, security boundary, or documented decision, stop that conflicting part and tell the user which rule blocks it and why. Do not implement a quiet approximation. Change the governing rule only after the user explicitly agrees, or when the request explicitly supersedes it. +- Every regression fix for a documented agreement must add a synthetic behavioral test for the exact user interaction that regressed, not only a lower-level helper or adjacent route. Keep that test as a permanent acceptance check. +- When requirements appear ambiguous, distinguish the supported interaction paths explicitly. Do not claim an agreement is fulfilled when only one path satisfies it and another normal path exposes different behavior. + ## Architectural boundaries - Keep format parsing, structural analysis, semantic mapping, normalization, comparison, persistence, and presentation separated. - Preserve original source values and provenance; normalized values must not destroy source data. - Known tool profiles must extend the generic import pipeline rather than bypass it. +- Every new or extended scanner profile must first check its supported report formats for a usable native overall score. Declare `securityScoring` in the profile with exact mapped properties, overall scope, scale, direction and result-population semantics, or an explicit reason why no usable native score is available. Native values take priority over calculated pass rates through the shared scoring engine; never infer overall-score semantics from an arbitrary field named score, a category score or a finding weight. Preserve source values and file/run provenance, version extraction changes and verify native priority, missing/invalid/conflicting values and safe fallback with synthetic fixtures. See `docs/SCORING_MODEL.md`. - React components must not contain source-specific parsing or direct database logic. - 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. +## 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`. +- Every local App/Backend start must reuse that datastore. Never create an alternative ASSESSOR database, Compose project, PostgreSQL volume, or fallback port for this workspace. +- If the canonical datastore is unavailable or port `5432` is occupied by a different container, stop and report the conflict instead of spawning or selecting another database. +- `docker-compose.postgres.yml` must keep the canonical Compose project name and external volume binding. Never delete, replace, recreate, or initialize the canonical volume as an empty datastore. +- Before an approved persistence migration or destructive database operation, create and verify a backup. Unrelated Docker applications, containers, and volumes remain out of scope. + +## Binding ASSESSOR design language + +- Explicit user correction 2026-09-18: the current, user-approved Data Hub, Work, and Pathfinder screens are the binding visual references for ASSESSOR's Ableton-inspired design language. This applies to every view, explicitly including Client Info, and to proposals, generated images, prototypes, and production implementation. +- Before any visual task, read `.claude/skills/assessor-ui/SKILL.md` and the relevant current components and `src/styles/ui-tokens.css`. The approved views and these current project agreements take precedence over older skill examples, copied asset templates, and superseded Client Info exceptions. +- Use Data Hub for flat square tiles, full-circle donuts, compact action buttons and branding; Work for list/detail hierarchy, typography, badges and reading surfaces; Pathfinder for stable filter/work/detail zones and compact controls. Preserve these approved views as references; do not redesign them as a side effect of Client Info work. +- Keep the current neutral theme surfaces, transparent segments, flat tiles, subtle separators, local Inter typography, shared 20px panel inset and shared control geometry. Reuse existing tokens and components. Do not reinterpret Ableton as a new palette, a literal copy of another application, or a return to obsolete UI dimensions. +- Use the shared yellow/amber roles for primary actions and persistent selection, blue for keyboard focus, and semantic status colors for the established status and data-visualization roles. A tool or graph-category color does not authorize a new selection or button color. No gradients, decorative shadows, glass effects, hover lift, generic rounded dashboard cards, new navigation shell, new logo, or Client-Info-only visual theme. +- Improve quick comprehension through grouping, alignment, readable labels, a small set of relevant overview values and existing detail/disclosure patterns. Never shrink body text or structured data below their agreed roles to fit more content, stretch sparse tiles across unused space, or invent metrics to populate a layout. +- All mockups must use the approved views as actual visual references, preserve the existing shell and metric meanings, and clearly identify synthetic example data. A rejected generated image is not a design reference. The three generic Client Info mockups rejected on 2026-09-18 are explicitly not approved. +- Visual acceptance: a Client Info proposal or implementation must be recognizable as the same application as Data Hub, Work and Pathfinder even without its logo. Check the shared surfaces, typography, buttons, selection, spacing and donut geometry at normal application zoom; inspect both themes for implementation. Distinguish a documented rule, a proposal and an implemented/verified UI change. + ## UI typography -- Use the locally bundled Inter variable font as the single application typeface. Do not introduce view-specific display, condensed, serif, or monospace families; hierarchy comes from size and weight. +- Use the locally bundled Inter variable font as the application typeface. Do not introduce view-specific display, condensed or serif families; hierarchy comes from size and weight. Explicit user exception: paths use the shared technical-path textbox and local system monospace stack; other content remains Inter. Do not download additional fonts. - Use only the visual weights Regular 400, Semibold 600, and Bold 700. Bold is reserved for branding and exceptional emphasis. -- Use the semantic typography roles: H1 56px/600, H2 32px/600, H3 18px/600, detail titles 20px/600, H4 16px/600, continuous prose 16px/400, structured table/Grid/Raw Data content 14px/400, labels and table headers 12px/600, metadata 12px, badges 11px, and buttons/controls 13px/600. +- Use the semantic typography roles: H1 56px/600, H2 32px/600, H3 18px/600, detail titles 20px/600, H4 16px/600, continuous prose and readable tile values 16px/400, structured table/Grid/Raw Data content and informational field labels 14px/400, compact control labels and metadata 12px, badges 11px, and buttons/controls 13px/600. - Preserve normal title case for H1-H4, field labels, and buttons. Uppercase is limited to compact table headers, badges/categories, and the ASSESSOR wordmark. -- Render continuous prose such as finding and report text at no less than `16px`. Structured data in tables, Grid, and Raw Data uses the dedicated compact 14px role. -- Compact interface text such as button captions, field labels, metadata, badges, and comparable control annotations may use a smaller type size. +- Explicit user decision 2026-09-20: the smallest text intended to communicate application information is `14px`; this includes table cells, table headings, tile content and informational field labels. Readable values and continuous prose use `16px`. For example, the Client Info Directory tile renders `Domain` at 14px and `sevenkingdoms.local` at 16px. Do not demote either role to a metadata or compact-control token merely to fit more content. +- Compact interface text such as button captions, technical metadata, badges and comparable control annotations may use a smaller type size. These exceptions must not carry primary table, tile, field-label or prose information. - When adding or changing styles, preserve this distinction instead of reducing content text to a compact UI-label token. ## UI panel spacing @@ -35,34 +69,146 @@ - Apply the inset exactly once on the view's root content container. Split panes and edge-to-edge structures belong inside that inset and must not add a second outer inset. - Keep the 20px outer inset at responsive breakpoints unless the user explicitly changes this standard. +## UI Work filter context + +- Explicit user extension 2026-09-18: the Work toolbar's `XLSX`, `MD` and `HTML` buttons export the complete current filtered/sorted Work record set, including the same linked and embedded Results used by the Results window. Marking alone does not select export rows; `My Workspace` restricts them only when active, alongside ordinary filters and drilldowns. Markdown and HTML use exactly two content columns, `Soll-Zustand` and `Abweichungen`, with source-backed remediation/verification, original technical facts, scoped GPO provenance, and explicit missing-evidence notices. Preserve neutral verdicts and review-versus-rescan boundaries. Build the frozen projection only on export, not on navigation. Oversized Excel cells use explicitly identified continuation rows of the same finding without truncation. Explicit user corrections 2026-09-24: `XLSX` replaces the former `CSV` button and mirrors the Work finding reader instead of the two-column layout: an `Übersicht` sheet with the export context, per-tool counts and the review/GPO reading boundaries, then one sheet per tool in Work order with one row per finding. Columns are Nr, Finding, Status, Severity, Badges and Source Rule ID, then the reader's own fields under their reader labels in reader order (reusing `selectFindingFields`, e.g. Description, Advised solution, Configured customer value, Expected baseline value, GPO sources), then Hinweise for status-specific neutral notes, Results (the Results window content including missing-evidence notices), Additional Information, Review and Record ID; empty optional columns are omitted per sheet. Cells are literal strings (never formulas); the status cell is highlighted only when Work's own Deviation predicate matches. This view snapshot is separate from the curated Arbeitsgrundlage in `docs/REPORT_STRATEGY.md`. + +- A unique `Source: Scan` selection is a semantic tool context even when Work remains on the project-wide `All Records` sheet. Visible and active facets must follow the selected tool context rather than the aggregate sheet profile. +- For a GPO-only Work context, whether reached through the dedicated GPO sheet or `Source: Scan = GPOs`, show only `Result Status`, the available GPO facets `Baseline`, `Comparison`, `Conflict`, `Description source`, `Diagnostics`, `Duplicates`, `Imported`, `Policy section`, `Policy type`, and the permanent final `Source: Scan` control. Do not show CIS, severity, category, MITRE, target, result-message, review, or scanner-specific facets. +- Explicit user correction 2026-09-17 supersedes only the category exclusion in the preceding GPO-context rule: `Category` is a permanent GPO Work filter in both supported entry paths, including when its only current value is `GPOs`. Keep it directly after `Result Status`. Severity, CIS, MITRE, target, result-message, review and scanner-specific facets remain excluded from the GPO-only context; `Source: Scan` remains last. +- Explicit user extension 2026-09-17: Work also exposes a distinct `Security Domain` facet immediately after `Category`. It must use the exact shared Client Info security-domain catalog and record assignment, never a second filter-only categorization. It is available in mixed Work and both GPO entry paths; a pure GPO scope maps to `GPO & Baseline`. Domain selection and Client Info drilldown must therefore select the same record identities, while ordinary active Work filters continue to apply. `Source: Scan` remains last. +- Explicit user correction 2026-09-18: `Security Domain` always offers all eight Client Info catalog entries in catalog order, including selectable zero-hit domains in mixed Work and both GPO entry paths. `Unclassified` remains an additional option only when present in the loaded sheet. Counts respect the other active filters; a zero-hit selection must not silently remove itself, the active status, or another still-valid facet selection. A Client Info domain-deviation drilldown uses this visible domain facet rather than a fixed record-ID path, so the user can change domains in Work. Explicit review-only and individual-finding paths retain their separate scope semantics. +- Explicit user decision 2026-09-17 supersedes the previous six-value list: the GPO `Result Status` choices are exactly `All`, `Deviation`, `Passed`, `Not configured`, `No baseline rule`, `Not comparable`, `Conflicts`, and `Duplicates`. Keep the seven non-All choices selectable at zero hits; never merge scanner-only status vocabularies into a GPO-only context. `Deviation`, `Passed`, `Not configured`, `No baseline rule` and `Not comparable` match the authoritative rolled-up policy verdict; `Conflicts` and `Duplicates` match the corresponding diagnostic category flags. One policy setting may therefore belong to both `Deviation` and `Conflicts` or `Duplicates`. +- Explicit user decision 2026-09-17: `No baseline rule` is the score-neutral verdict for a retained customer setting whose resolved technical identity has no applicable Microsoft baseline recommendation in the compared baseline set. Every aggregated customer state must reach Work under exactly one verdict: an evaluated verdict where a baseline rule exists, otherwise `No baseline rule`. It is distinct from `Not configured`, which is a recommended baseline setting absent from the analyzed backup set, and it must never be presented as a deviation, remediation obligation or score input. A diagnostic `Conflicts`/`Duplicates` flag marks such a setting without replacing its verdict; unresolved identities stay out of this verdict and take `Not comparable` instead. +- Explicit user decision 2026-09-17: `Not comparable` is the score-neutral verdict for a retained customer setting whose delivery mechanism has no comparable technical policy identity. Today this is always a Group Policy Preference. Never resolve a preference into a policy identity and never compare it with a Microsoft baseline recommendation: its action, item-level targeting and apply-once semantics differ from a policy setting, so a baseline verdict over it would be invented. Keep the retained CSE, action and item-level targeting readable in the agreed GPO columns; do not add a GPO Work column or facet for them. Identical or differing preference instructions are not proven duplicates or conflicts, so `Not comparable` carries no diagnostic flag. The observation-level unresolved-identity gap reporting stays in place and must report each observation once with its authoritative resolver reason, never restated a second time by snapshot aggregation. +- Never infer a GPO verdict from comparison prose, historical results, baseline text, guidance or evidence. Use only the authoritative rolled-up policy verdict and explicit conflict/duplicate flags. A foreign `Pass` string must not make a not-configured, review or failed policy setting match `Passed`. +- When the selected tool context makes an existing facet filter invalid, remove that incompatible filter so it cannot remain invisibly active. Removing the tool restriction restores the appropriate aggregate facets without changing source data. +- Explicit user extension 2026-09-17: also offer `GPO backups with failing settings` in the GPO Work context. Its all-counted and individual-backup selections use the Processing tile's exact project/assessment/backup-instance identity and select source-linked Fail comparisons, not inferred per-backup verdicts. Keep all contributing evidence, conflict/duplicate flags and historical evaluation readiness intact; Source: Scan remains last. This extends the facet list above. + +## UI Result DB filter consistency + +- Explicit user correction 2026-09-20: in linked CIS-CAT Results evidence, an evaluated source row must follow the actual finding outcome. Highlight the confirmed configured row with the shared green match treatment when the finding outcome is `Pass`, and use the red violation treatment only when the outcome is `Fail`; unknown, neutral or unavailable outcomes must not be guessed into either state. The criterion row remains the separately identified expected state. +- Explicit user correction 2026-09-18: Result DB uses the shared Work vocabulary for its GPO `Result Status` filter and details: `Deviation`, `Passed`, `Not configured`, `Conflicts`, and `Duplicates`; `Review required` remains an independent unresolved result. Stored classification/query values stay unchanged. Status facet counts must honor all other active filters, including Deviation; only their own status selection is excluded to keep alternatives reachable. Selecting or clearing a status must never silently reset Deviation. Selected zero-hit values stay visible and removable. This supersedes the earlier Result DB exception that ignored and automatically cleared Deviation. Result DB still counts individual comparisons, while Work counts rolled-up settings; no extra public observation types or invented statuses are introduced. + +## GPO Registry baseline comparison + +- Treat retained `Registry.pol` `delete-value`, `delete-all-values`, and `create-key` instructions as explicit, comparable target states rather than unavailable baseline values. The comparison remains scoped to imported backup configuration and must never claim effective endpoint registry state. +- A delete-value requirement passes when that value is absent from the analyzed backup set or explicitly deleted, and fails when the value is set. A delete-all-values requirement passes only when no value is configured below that key or the delete-all instruction is explicit; any retained configured child value fails it. A create-key requirement passes when the key is explicitly created or a retained configured child proves its presence, and fails when the key is absent. +- A typed empty `REG_SZ` or `REG_EXPAND_SZ` is a present value. Compare its registry type and exact empty content; never convert it to missing/unavailable. Missing required presence is Fail, while ordinary missing value recommendations remain score-neutral `Not configured`. +- Preserve contributing child-state IDs and observation provenance for key-level comparisons. Unsupported Registry.pol special operations remain `Review required`; do not guess their semantics. + +## GPO analysis and scoring scope + +- Explicit user decision 2026-09-17: the Finding Reader must immediately show contributing GPO backup instances and attribute every retained operation/value to its source, including deletion instructions. Group by exact project/assessment/backup-instance identity, not title, registry value or observation count; retain source-local sequence and never present different GPOs as one execution chain. Show retained native GPO/backup IDs; do not infer missing friendly names from paths. This inline source attribution supersedes any earlier Results-only hiding of these sources, while Results remains available for variant comparisons. +- Explicit user decision 2026-09-17: render that inline attribution as one flat table with the columns `GPO source`, `Operation`, `Data`, `Type`, and `Evidence`, one row per exact backup identity, a compact status marker, and expandable `Show source details`. The expansion retains full GPO/backup identity, source-local sequence, safe evidence reference, key, value name and every original instruction. Bold Operation and Data. Mark `Conflicting contribution` only when the retained current baseline variants independently prove that single source member differs; mark alignment only when every retained variant independently matches. Do not derive source markers from historical evaluations, multiple instructions inside one backup, GPO precedence or endpoint effectiveness. +- Explicit user correction 2026-09-17 supersedes the flat table presentation above: show each exact GPO backup identity again as a complete, vertically stacked source section with Evidence, source-local sequence and every original instruction immediately visible. Use a restrained red background and red leading accent for a source section only when the retained current baseline variants independently prove that single source member differs. Keep aligned, unassessed and ambiguous sections neutral; retain the same historical, precedence and endpoint-effectiveness boundaries. +- Explicit user correction 2026-09-17 supersedes the whole-section red treatment above: keep every GPO source section neutral and apply the restrained red background only to the exact displayed field value proven different from every retained current baseline variant. Highlight `Operation` for an operation mismatch, `Data` for a data mismatch and `Type code` for a registry-type mismatch; several fields may be marked only when each is independently proven. Do not highlight a whole source, heading, path, key, value name or conflict badge, and do not guess a field when variants disagree about the cause. +- Explicit user extension 2026-09-17: every proven GPO source-value deviation must receive the same restrained red value treatment. Keep registry-policy differences field-specific for `Operation`, `Data` and `Type code`, including simultaneous differences. For other comparable GPO value kinds, or when all retained variants prove a difference but no one field is the common cause, mark the displayed source value as a whole without asserting a narrower cause. Review-required, unassessed and aligned values remain neutral; never color the whole source section, heading, evidence path or diagnostic badge. +- Explicit user correction 2026-09-17: a principal-set is a collection comparison, not one indivisible value block. Mark only configured principals absent from every retained current baseline variant. A principal also present in the expected baseline remains neutral even when neighboring principals deviate. If the deviation consists only of a missing expected principal, do not color an existing configured principal as its substitute; the expected-baseline block remains the evidence for that absence. +- For versioned member comparisons, derive the Conflict flag from the retained authoritative customer state, not from a set-value-only subset of original instructions. Reduced-identical contributions from multiple backups may be Duplicate; multiple earlier instructions inside a single backup are not duplicate GPOs or independent current conflicts. Keep these diagnostic flags separate from the policy verdict and preserve historical evaluation readiness. +- An additional indeterminate GPO must not hide an independently proven difference between other GPO backups. Retain that diagnostic only when distinct, unambiguous backup contributions of the same technical setting prove different supported signatures also present in retained compared values. Exclude the whole uncertain backup from that proof; its earlier writes may remain in retained values and must not be mistaken for separate GPOs. The overall verdict remains Review required. + +- The operational GPO assessment is misconfiguration-first and limited to customer settings that are actually configured, technically comparable and in the explicitly applicable Microsoft-baseline scope. Do not turn every recommended but absent baseline setting into an operational finding, remediation obligation or score penalty. A complete-baseline rollout is a separate, explicitly commissioned hardening track. +- `Not configured` remains a score-neutral policy verdict. `Duplicates` and `Conflicts` remain visible, mutually distinct diagnostic categories on a policy setting; they are not alternative verdicts that can suppress `Passed`, `Fail` or `Review required`. +- Roll member comparisons up once per technical policy-setting identity. If at least one independently comparable, in-scope configured member value is a valid `Fail`, the whole policy setting verdict is `Fail`, while its conflict/duplicate flags remain visible. If every applicable member passes, the policy verdict is `Passed`. If member applicability, precedence or comparison is unresolved, use `Review required` rather than inventing a fail. Source multiplicity, duplicate rows and diagnostic flags must never multiply the setting's score weight. +- Label the GPO score as conformance of configured, comparable in-scope settings. Never describe it as full Microsoft-baseline compliance, baseline coverage or proof that all recommended settings are implemented. +- Keep absent recommended settings available under `Not configured` for transparent inspection, but exclude them from Priority Findings, default remediation scope and score unless the user explicitly starts a separate baseline-hardening scope. +- `Not configured` is scoped to the analyzed GPO backup set: if an applicable baseline recommendation has no observed configured value in that set, keep it filterable as `Not configured` even when the import is a selected subset. Retain a scope-limit diagnostic and never turn this into a domain-wide or effective-device absence claim without complete collection evidence or RSoP/GP Results. + ## UI segments and tiles - Treat segments and tiles as a binding two-level visual grammar independent of their content. A segment is a transparent grouped layout; a tile is a flat, square-cornered surface inside it. - Use only the shared `--segment-*` and `--tile-*` tokens for segment surfaces, borders, radii, insets, gaps, tile surfaces, shadows, widths, hover states, and selected contours. Do not create view-local substitute geometry. - Segments are visually transparent and have no visible border or shadow. They retain `--segment-radius`, one uniform inset, and one uniform gap as shared layout geometry. - Tiles use the common white or theme-equivalent surface without a visible normal-state border, radius, or shadow. Hover changes the surface only and must not add a decorative contour, lift, or translation. +- Explicit user correction 2026-09-20: in the light theme, tile surfaces use the shared neutral gray `--tile-surface` instead of pure or near white to reduce glare; the current approved value is `#F5F5F7`. Keep the surrounding app surface, input surface and established hierarchy distinct; do not reproduce this with view-local overrides. - Status color belongs only in a small accent line, marker, data visualization, or selected contour. Never fill the complete tile with a status color. - Keyboard focus and selected tiles use the shared functional focus or selected outline. Action tiles and add tiles use the same flat geometry as content tiles. +- Explicit user correction 2026-09-20: the persistent yellow outline of the selected Data Hub tenant tile is one hairline thicker than the shared 2px selection outline, composed from `--bw-emphasis` plus `--bw-hairline`. This is a scoped Data Hub tenant-selection exception; keyboard focus remains the separate shared blue 2px outline, and no other tile-selection width changes. - The persistent marking and selection color is always the shared yellow `--marking-color` in both themes. Purple must not be used for selected contours or markers. Blue remains reserved for keyboard focus, while green, red, orange, and severity colors remain domain status signals rather than selection colors. - Keep unused segment space intentionally empty: lay tiles out from the start at their shared compact or content width and never stretch a partial final row merely to fill the container. +- Explicit user correction 2026-09-20: the Data Hub result-donut row and the client/add-tile row below share the exact same six-column track geometry at wide widths. Every column start, width and gap must align vertically without cumulative horizontal offset; all six result donuts remain on one line. At narrower widths both rows return to the same compact responsive tile contract. - Tile content must never cross the tile boundary or cover a neighboring tile. Nothing may be clipped, clamped, truncated, or replaced by an ellipsis. Text and actions reflow inside the tile; media scales within the available inner area. If content does not fit, enlarge or reflow the tile. - Avoid line breaks in compact tile labels where practical. If wrapping is necessary, wrap only at word boundaries: never split ordinary words or numeric values across lines. Use a wider or responsive tile whenever a complete word or value cannot fit. +- Explicit user decision 2026-09-20: purple/violet is removed as a UI role entirely, not only as a selection color. The `--accent`/`--accent-hover`/`--accent-active`/`--accent-on`/`--accent-subtle` tokens in `src/styles/ui-tokens.css` must not resolve to a violet value and must not be read wherever the consuming rule means keyboard focus (use `--focus-ring`) or active/selected state (use `--marking-color` and its existing selection/marker roles). A tool- or graph-category tone (for example the PKI chart tone) that previously reused `--accent` gets its own dedicated, non-violet, non-focus, non-marking category color instead of being retargeted onto focus or marking roles. This closes the drift documented in Client Info/Work/Pathfinder screenshots reviewed 2026-09-20, where the same segmented-tab-selection component rendered amber in one view and violet in another because `--accent` was simultaneously documented (superseded `assessor-ui` skill text) as meaning both "primary action / active view / selection" and used in code for `:focus-visible`, conflicting with the yellow-marking/blue-focus rule above. ## UI donut charts - Every donut chart uses the same full 360-degree geometry: a continuous neutral-gray track and a colored clockwise value arc starting at 12 o'clock. - Donut arcs use flat ends and the shared `--donut-ring-stroke`, `--donut-track`, value, and typography tokens. Do not introduce 270-degree gauges, open gaps, rounded arc caps, or local substitute geometry. -- Place the primary numeric value itself on the exact visual center of the ring. Append a percent sign or other short unit to its right on the same baseline in the smaller shared UI size without letting that unit shift the number away from the center. Supporting counts may remain as subdued secondary text inside the ring, but every text element must stay fully within the clear inner area and must never touch or overlap the ring at any supported value width. +- Explicit user correction 2026-09-20: every count/percentage donut places the absolute count as the bold first line and the percentage as a regular-weight second line below it. Every donut readout, including score rings, keeps a visible safety gap from the inner edge of the ring at every supported ring size and value width. A score ring such as Overall Score retains its score-specific `/100` semantics instead of inventing an absolute count. +- Center the complete two-line readout as one unit inside the ring without letting either line shift horizontally. Keep every text element fully within the clear inner area and never let it touch or overlap the ring at any supported value width. - Multi-segment distributions retain their categorical segments, but use the same track, stroke proportion, start position, centered value treatment, and shared tokens as single-value donuts. +## UI Client Info dashboard + +- Explicit user correction 2026-09-20: the former Client Info `Priority Findings` tile is named `Data`, sits to the left of `Domain Information`, and shows the total `Deviations` value plus the separate additional-result-state row only. Do not show duplicate `Critical` or `High` summary values in that tile. The remaining deviation value occupies the full header width and is a keyboard-accessible button that opens Work with the standard `Deviation` filter. +- Explicit user correction 2026-09-18 supersedes the previous Client Info visual exception: `.client-command-center` follows the same Ableton-inspired ASSESSOR language as the approved Data Hub, Work and Pathfinder. Client Info may organize its own domain content, but has no exception for palette, surfaces, tiles, typography, controls, selection, branding, spacing or chart geometry. Existing `--client-info-*` roles are legacy implementation details, not authority for a separate visual theme; reuse the shared roles when bringing this view into conformity. +- Treat Client Info as one connected executive security-posture canvas, not as a collection of unrelated report cards or a spreadsheet. Its stable reading order is environment facts, overall posture, security domains, priority findings and assessment gaps, then source evidence. +- Keep environment facts in a compact evidence rail, using the same neutral theme-aware tiles as Data Hub. Wrap at readable widths instead of forcing one tiny-text row. The former mandatory dark-tile treatment is superseded by the 2026-09-18 correction. +- Explicit user correction 2026-09-20 supersedes the separate evidence rail above: AD Domains, Entra Tenant, User Accounts, Computer Objects, Domain Controllers and GPOs live inside the `Data` tile as one flat 3-by-2 fact grid, retaining their existing glyphs. Do not render a separate top-level Environment Facts tile row. The six facts are not nested tiles; use transparent cells and subtle separators inside `Data`. +- Present Overall Score and Security Domains together on one shared posture surface. Overall Score is the dominant visual anchor; domain scores form a visibly connected branch or spine beside it and must not look like a conventional data table. +- Explicit user correction 2026-09-20: at wide desktop widths, the posture surface and action rail each use exactly one half of the available row width. This supersedes the earlier two-to-one proportion. Every tile aligned in one row must always share the same height and bottom edge; never use intrinsic-height staggering within a row. This also supersedes the earlier instruction to keep the posture surface shorter than the action rail. +- Explicit user correction 2026-09-20: the top of the Client Info action rail is an exact 50/50 row. `Domain Information` sits on the left and `Priority Findings` on the right with identical height; `Assessment Gaps` spans the full action-rail width below. Domain Information contains every fact from the Environment Detail `Directory` group—Domain, NetBIOS name, Forest, Domains, domain functional level, forest functional level, schema version, domain created and Entra ID—plus the separately requested domain-controller count. All values come only from the same normalized Environment Snapshot. Missing facts remain an em dash and must never be inferred as zero. +- Explicit user correction 2026-09-20: the Overall Score block does not repeat a textual score status below the ring and does not repeat the critical-finding count already present in Priority Findings. Assessment Coverage uses at most 70% of the Overall zone and never exceeds the shared compact tile-content width; it must end before the curved domain connectors, which may never cross its label, bar or supporting count. +- Explicit user correction 2026-09-20: the Overall Score block also omits the secondary `Unassessed` and `Lowest domain pass rate` fields completely, including their divider container. `Unassessed controls` remains visible only in Assessment Gaps; domain pass rates remain visible on their individual Security Domain nodes. +- Explicit user decision 2026-09-18: preserve the thin curved fan connections from Overall Score to every displayed Security Domain during the Ableton-style alignment. They are a binding visual feature, not optional decoration. Derive their endpoints from the rendered ring and domain nodes and remeasure on resize/content changes. Preserve the existing stacked narrow-screen fallback; never keep desktop coordinates on a stacked layout. +- Explicit user correction 2026-09-20: Security Domain rows show the domain name in the shared detail-title role without the former passed/not-configured/duplicate/conflict/review metadata line underneath. The score node and right-hand deviation or review count remain. The Overall Score ring is a keyboard-accessible entry to Work's clean remediation default: clear prior search, source, domain, severity, record-ID and workspace filters, select `Deviation`, and open the standard Work overview. +- Explicit user correction 2026-09-20: Every displayed Security Domain row carries a subtle amount bar in its own shared grid column between the longest rendered domain label and the widest rendered amount. Keep the shared gap on both sides so a bar can never grow into text or behind a number. All bars share one right edge and extend left from that edge. The later color correction supersedes the preceding categorical-color decision: every amount bar uses the exact current semantic color of the Overall Score donut and changes with that score's critical, medium, passed, or unknown tone. Do not use selection, focus, per-domain score, or a separate palette. Bar width is that row's displayed deviation amount divided by the sum of the displayed domain amounts; review-only rows use their already-displayed review amount. Keep the exact right-aligned number visible as the authoritative value, make the bar decorative and hidden from assistive technology, and never change counts, scoring, classification, or drilldown semantics to produce the visualization. +- Explicit user correction 2026-09-20 supersedes the transparent Client-Info donut treatment above: the total `Deviations` donut in Client Info's `Data` tile uses the exact Data Hub `datahub-reference-knob` visual variant, including its tile surface, dimensions, spacing, title and hover state. Data Hub and Client Info derive its count and percentage denominator from the same selected mixed-timeslot project sheet, including assessment-bound GPO/policy observations as well as scanner records; never calculate the Data Hub value from scanner run IDs alone. The complete donut remains a keyboard-accessible action to Work with the `Deviation` filter. +- Explicit user extension 2026-09-20: Client Info's Operating systems table shows PingCastle's row-bound `Nb Active`, `Nb Inactive`, `Nb Enabled` and `Nb Disabled` counts beside `Nb OS`. Join each value only to the exact retained report, source table and row of that operating-system entry; never derive one state from another, borrow a value from a different row or add overlapping inventories. Missing values render as an em dash. Other scanners and older imports remain visible without invented state counts. +- Keep Client Info immediately scannable: Environment Detail starts collapsed with its evidence/restriction counts visible; the Accepted Risks master/detail summary remains visible, while its complete context, controls, approval, evidence and decision history are individually expandable. Disclosure must remain keyboard accessible and must not change source data, scoring, risk decisions or drilldown identity. +- Explicit user correction 2026-09-20: every Environment Detail tile heading, including Source Overview and Operating systems, carries one restrained existing ASSESSOR line glyph before its title. All fact groups reuse Source Overview's list spacing and row padding for one consistent, airy rhythm; fixed tile heights, the four-column grid and internal scrolling remain unchanged. +- Explicit user correction 2026-09-20: Accepted Risks adopts the Data Hub `Manage Client` master/detail interaction and geometry. The fixed-width, independently scrolling navigation on the left owns the register heading, count, selection and compact state/date rows; the equally tall information pane on the right owns the selected risk, summary and expandable detail groups. Yellow marks persistent selection, risk state remains a separate text-and-dot signal, Arrow Up/Down/Home/End move the selected risk, and `Open finding` opens that exact record in Work. At narrow widths the panes stack without horizontal overflow. +- Explicit user correction 2026-09-20: Accepted Risks adopts the Data Hub `Manage Client` master/detail interaction and geometry. The fixed-width, independently scrolling navigation on the left owns the register heading, count, selection and compact state/date rows; the equally tall information pane on the right owns the selected risk, summary and expandable detail groups. Yellow marks persistent selection, risk state remains a separate text-and-dot signal, Arrow Up/Down/Home/End move the selected risk, and `Open finding` opens that exact record in Work. At narrow widths the panes stack without horizontal overflow. +- Explicit user correction 2026-09-20: Accepted Risks reuses the Data Hub client-detail geometry one-to-one: a fixed compact selection rail at the left using `clamp(420px, 27vw, 520px)`, the information surface at the right, and the established stacked narrow-screen fallback. Do not reintroduce a proportional wide list column. +- Keep Priority Findings and Assessment Gaps in a dedicated action rail. Use status color only for finding markers, score arcs, score nodes, and progress bars; avoid large colored fills and nested card stacks. +- Explicit user correction 2026-09-20 supersedes the standalone Source Overview rail: source scores live inside the expanded `Environment Detail` as one compact plain list with separators, never as tiles. Preserve every source's actual versioned ASSESSOR score contribution, method label, native context and Work drilldown. A run/file-bound native score takes priority when supported and pass rate is the fallback; PingCastle uses the explicit `100 - native risk` convention and retains raw risk as secondary context. Never insert a raw lower-is-better risk value directly into the overall scale. Follow `docs/SCORING_MODEL.md`; Security Domain values are pass rates, not a decomposition of the mixed-method index. +- Explicit user extension 2026-09-20 supersedes only the preceding container geometry: all expanded Environment Detail groups form an equal four-column tile grid. `Source Overview` occupies one group tile while its individual source entries remain the agreed plain separated list, never individual source tiles. The six fact groups and Operating systems each occupy one tile. Every tile is exactly three quarters of the currently rendered Overall Score tile height; derive that height from the rendered element and keep overflow inside the affected tile with a scrollbar. Preserve four columns on narrow layouts through horizontal grid scrolling rather than changing tile width or column count. +- Explicit user correction 2026-09-20: Source Overview never renders a `Tabular Data` tile. Generic tabular imports remain available through their supported data and filter paths, but they are not a security-scoring source tile. +- Unknown or unavailable facts render as an em dash and never as an inferred zero. Keep the dashboard English-only and omit explanatory prose that does not support an immediate first-meeting statement or action. +- The content hierarchy, score semantics, source provenance and drilldowns remain binding. Their layout must use the shared ASSESSOR components and tokens; a connected briefing layout does not permit a dedicated palette or geometry. Source Overview, Environment Detail and Accepted Risks obey this same rule, including their collapsed, expanded and selected states. + ## UI branding position - Use the Data Hub header as the binding position reference for the ASSESSOR logo, wordmark, and version. - Keep the brand container geometry identical across every application view; do not add area- or view-specific brand padding, margin, alignment, height, or transforms. - Switching views must never move the logo, wordmark, or version. +## UI backend connection state + +- Data Hub, Result DB and DB Structure must present a checking or unavailable local backend through the shared ASSESSOR dialog rather than an embedded page banner. +- Keep that dialog dismissible so the user can inspect the underlying view. The application continues its existing automatic health checks; reconnecting removes the offline branch without requiring a reload. +- Keep the copy limited to the affected capability and the automatic connection check. Do not expose response bodies, project data or imported content in this technical connection state. + +## Navigation and rendering performance + +- Treat area switches as a performance-sensitive path. Measure the first visit and repeated visits separately after the workspace has loaded; distinguish main-thread rendering from asynchronous API readiness. Use the local procedure in `docs/architecture/navigation-performance.md`. +- Share expensive filtering, sorting and facet counts between their consumers. Component-local `useMemo` does not survive an area unmount. Use bounded, dataset/sheet-owned caches with immutable input identities and all semantic dependencies (profile, dataset, reviews, filters, search, sort and timeslot/path scope); never cache solely by a reusable entity ID. Verify invalidation as well as reuse. +- Build raw text, detailed result projections, graph layouts and other large derived content only when the corresponding view needs it. Virtualized views must not serialize or derive presentation fields for every offscreen record. The initial render must also be bounded by the viewport plus overscan. +- Large native selectors must not mount thousands of unused options during area navigation. Show the current selection immediately and prepare the complete option list before pointer opening or keyboard focus; verify keyboard access and selection preservation. Construct export payloads only after the export action. +- Classify shared headers once per derivation, normalize sort keys once per record, and count facets in a shared pass. Rejected numbered column groups must not trigger repeated scans of all their siblings. Stop category eligibility checks once their cardinality limit is exceeded, while preserving exact counts for eligible facets. +- Retained views mount on their first activation. While hidden, freeze their input context and stop geometry observers and animation frames; resume with current inputs when activated. Reset retained state when the workspace scope changes. Keep selections and original source values intact. +- Polling an unchanged health/status value must return the existing state instead of rerendering the application. Do not introduce keep-alive polling or data caches without explicit freshness and invalidation behavior. +- For performance fixes, add behavioral cost checks (for example, zero source-field reads on an unchanged repeat visit, bounded mounted rows, and fresh results after changed inputs). Record wall-clock measurements as observations rather than fragile CI assertions; run browser comparisons without simultaneous builds or load tests. +- Follow the privacy-safe testing rules below. Local opt-in measurements may contain only area names, durations, counters and technical states; no report text, tenant identifiers, filenames, external telemetry or production instrumentation. + ## Security and verification +- HTML attribute readers must advance monotonically across boolean, quoted, unquoted, malformed, and long valueless attributes; do not use unanchored `name=value` searches that retry every suffix. Resolve repeated internal IDs/names through an import-local index tied to the exact protected markup, preserving duplicate diagnostics, target order, and source offsets. Guard character work and complete source coverage with synthetic regressions; validate timeout fixes in the built isolated worker without raising its time or memory limits. +- Context-only extractors must not consume finding tables elsewhere in the same workbook. Compose them with the generic table extractor, keep original table indices, and verify summary, findings, and supporting sheets together through canonical projection and result linking. +- Embedded scanner globals must be located lexically outside strings, comments, HTML attributes, and other raw-text containers. Missing IDs, unreadable payloads, conflicting assignments, repeated IDs, and declared-count mismatches require explicit diagnostics. A declared empty report is distinct from an unreadable nonempty report; explicit null result tables with zero results are valid. +- Keep native detail timestamps at their full precision and preserve exact source values and field paths, including explicit nulls and unknown fields. Derived display fields reference their real input objects; never invent native paths for generated compatibility columns. Test source-path resolution and detail-cell equality, not only row counts. +- Scanner coverage must be verified against independently counted source records and source status totals, not just a successful parser return. Preserve declared totals and emit a diagnostic when they disagree with individual results; never drop records to make totals agree. +- Preserve XML attributes as exact name/value pairs with attribute-level source paths, including namespaces, zero, false and empty values. Explicitly empty leaves must remain distinguishable from absent data; never reconstruct attributes from an ambiguous display serialization. +- Lexical HTML readers must respect quoted attribute boundaries, raw-text elements and malformed/unquoted attributes without treating tooltip markup as visible tags. Sanitize complete attributes, not attribute-like strings inside other values. Bounded excerpts must not expose a partial trailing tag or discard subsequent source sections. Verify table/section coverage as well as clean cell text in both runtimes. +- Missing native rule IDs must fail explicitly. Diagnose repeated IDs even when an established first-presentation policy retains one finding. Compare matched counts by category, not catalog size; preserve the original counters and distinguish a declared empty report from an announced but unreadable result set. +- Embedded report data is inert input. Support only an explicitly bounded static data grammar; never evaluate scripts, calls, getters, spreads, computed properties or template substitutions. Unsupported or malformed recognized reports must fail explicitly instead of becoming successful zero-finding imports. Keep production/browser and server behavior aligned. +- Mapping rules for ambiguous labels must include their table or candidate context. In Maester, `Result` beside `Status` is evidence; native `Result` without a separate status column is the status. Preserve original values and exact source paths through both variants. +- Retain scanner-level metadata separately from findings, including unknown nested fields. Distinguish scanner-runtime machine information from assessed-environment assets. Version extraction/mapping changes and recommend reimport without rewriting historic imports. +- Apply `docs/REIMPORT_POLICY.md` to every importer and profile change. Any change to recognition, parsing/extraction coverage, persisted context/evidence, finding identity, mapping, normalization, status/outcome/severity/IOE, completeness diagnostics, or newly captured score inputs must add an append-only processing manifest version and mark affected historical imports for reimport. Presentation-only changes over already retained facts do not require reimport. +- A reimport may replace scanner-derived records only. Preserve complete client-owned review objects, including future fields and accepted-risk data, through a unique scanner/rule/asset identity. Keep the prior review and surface a persistent unresolved state when matching is absent or ambiguous; never guess by title or position. + - Preserve local-only behavior until a server transition is explicitly implemented and documented. - Do not introduce external uploads, telemetry, CDN assets, network APIs, shell access, or broader Tauri capabilities without explicit user approval and a security-model update. - Treat imported HTML, XML, Excel, JSON, and CSV files as untrusted input. Never execute active content from imported files. diff --git a/SECURITY.md b/SECURITY.md index d0494d4..cac36a5 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,7 +1,64 @@ # Sicherheitsmodell +## ISO-Korpus-Upload und Embedding (Phase 13D) + +Die beiden lizenzierten DIN-ISO-PDFs werden nur durch eine bewusste Aktion im +Data Hub an die Same-Origin-API uebertragen. Der Upload erfordert zusaetzlich +einen serverseitig konfigurierten, mindestens 32 Zeichen langen Operator-Token; +der Backendvergleich erfolgt zeitkonstant vor dem Lesen des Anfrageinhalts. +Der Token wird nicht in Browser-Storage, URLs, Antworten oder Logs abgelegt. +Er ist eine Uebergangsberechtigung fuer diese eine globale Aktion und ersetzt +keine Nutzerverwaltung oder allgemeine Autorisierung. + +Jedes PDF ist auf 32 MiB begrenzt. Die bestehende serverseitige PDF.js-Pruefung +verlangt kopierbaren Text, passende Struktur und dieselben 93 Kontrollen. +Das Parsing laeuft in einem begrenzten Worker. Die Original-PDFs liegen nur +waehrend des Jobs in einem privaten Verzeichnis und werden danach entfernt. +Die daraus erzeugte versionierte JSON-Korpusquelle liegt dauerhaft im privaten +Artefakt-Volume, damit der abgeleitete Qdrant-Index wiederhergestellt werden +kann. Es gibt keinen API-Endpunkt zum Lesen der PDFs oder des Kontrolltexts; +die Status-API zeigt nur Version, Zaehlwerte und Quellhashes. Server- und +Volume-Administratoren koennen die Quelle technisch weiterhin lesen. + +Beim Embedding geht der ISO-Kontrolltext nur vom Backend an den konfigurierten, +fuer diesen lizenzierten Inhalt freigegebenen Embedding-Endpunkt. Bei +fehlgeschlagener Verarbeitung bleibt die bisher aktivierte Version erhalten. +Die neue Version wird erst nach vollstaendigem Indexlauf aktiviert. Qdrant +bleibt ableitbar; PostgreSQL-Findings und Review-Entscheidungen werden durch +den Upload nicht veraendert. Phase-14-Authentifizierung und Rollen bleiben +offen. + +## Accepted Risk: dokumentierte externe Entscheidung + +Ergaenzung 2026-09-10: Der lokale Accepted-Risk-Dialog speichert begruendete, +befristete Entscheidungen mit Verantwortlichen, separater Freigabedokumentation, +Massnahmen, Wiedervorlage und vollstaendiger Versionshistorie im bestehenden +Review-JSONB. Der eigene Same-Origin-Endpunkt prueft Projektzugehoerigkeit, +Pflichtangaben und erwartete Revision; die Repository-Transaktion haengt eine +serverdatierte Version an. Allgemeine Reviewaenderungen duerfen die vorhandene +Historie nicht ersetzen. Originalbefunde und technische Bewertungen bleiben erhalten. + +Namen und Freigabereferenzen sind Angaben zu einer externen Entscheidung, keine +authentifizierten Signaturen. Das Formular verifiziert weder Personen noch +Nachweisinhalte oder Freigabeberechtigungen. Referenzen bleiben inerter Text; +es gibt keine neuen Uploads, Netzfreigaben oder externen Dienste. JSONB-Historie +und Revisionsschutz sind kein Schutz gegen Datenbankadministratoren und kein +unabhaengiges Aufbewahrungsarchiv. Bestehende Loeschregeln bleiben anwendbar. +SSO, Rollen, verbindliche Freigaberegeln und manipulationsnachweisbare Aufbewahrung +bleiben Voraussetzungen fuer den Firmenbetrieb in Phase 14. Details und die +geplante normalisierte Ablage stehen in [RISK_ACCEPTANCE.md](docs/RISK_ACCEPTANCE.md). + ## Lokale Datenverarbeitung +HTML-Parser-Nachhaertung 2026-09-09: Attributnamen und -werte werden linear +gelesen, einschliesslich langer wertloser beziehungsweise fehlerhafter Attribute. +Dies vermeidet quadratisches Regex-Backtracking vor der eigentlichen Extraktion. +PingCastle-Verweisziele werden pro unveraendertem Markup indiziert; doppelte +Definitionen bleiben mehrdeutig, Zielreihenfolge und Quellpositionen erhalten. +Die Indizes leben nur im aktuellen Import. Workerzeit, Speichergrenzen und +Netzwerk-/Persistenzberechtigungen werden nicht erweitert. Der im Screenshot +gezeigte Report wurde nicht gelesen; die Reproduktion verwendet synthetische Daten. + ASSESSOR besitzt zwei kontrollierte lokale Betriebsarten: 1. Im empfohlenen Browserbetrieb liefert das lokale Node.js-Backend die React-App @@ -10,8 +67,10 @@ ASSESSOR besitzt zwei kontrollierte lokale Betriebsarten: 2. Im Vite-Entwicklungs- oder optionalen Tauri-Modus bleibt der vorhandene Browserparser als Fallback aktiv. -Es gibt keinen Upload an externe Dienste, keine Telemetrie und keine externen -Anwendungs-APIs. Das lokale Backend bindet standardmäßig nur an `127.0.0.1`. +Es gibt keinen Upload von Importdateien an externe Dienste und keine Telemetrie. +Die freigegebenen externen Anwendungs-APIs sind die unten beschriebene, +manuell ausgelöste NVD-CVE-Anreicherung sowie das ausdruecklich konfigurierte +Work-LiteLLM fuer AI Overview. Das lokale Backend bindet standardmäßig nur an `127.0.0.1`. Eine Freigabe im Firmennetz ist erst mit HTTPS, Authentifizierung und Berechtigungen in Phase 14 zulässig. @@ -21,6 +80,45 @@ Dokumentstruktur bereit. Skriptausführung ist nicht aktiviert; aktive HTML-Elemente werden vor der Tabellenauswertung entfernt. Umfangreiche oder tief verschachtelte HTML-Berichte verwenden automatisch eine begrenzte, nicht rekursive Tabellenextraktion. Excel-Formeln werden nicht ausgewertet; verschlüsselte Archive und eingebettete VBA-Projekte werden abgewiesen. Spreadsheet-orientierte CSV-Exporte neutralisieren formelaktive Zellanfänge. +### PurpleKnight-Berichte + +Workbook-Zusammenfassungen werden mit der generischen Tabellenextraktion +kombiniert, nicht anstelle der Indikatoren verarbeitet. HTML liest ausschließlich +inert eingebettete, begrenzte Datenobjekte aus lexikalisch erkannten +`window.reportJSON`- und `window["Category_n"]`-Zuweisungen. Zeichenketten, +Kommentare, HTML-Attribute und andere Raw-Text-Elemente sind keine Datenquellen. +Beschädigte Objekte, fehlende native IDs und konkurrierende Zuweisungen werden +abgewiesen. Wiederholte IDs und abweichende native Ergebnis-/Detailzähler +erzeugen Warnungen ohne stilles Verwerfen von Vorkommen. Null-Details ohne +Ergebnisse und ausdrücklich deklarierte leere Berichte bleiben zulässig. +Originalwerte, vollständige Zeitstempel, unbekannte Felder und native Quellpfade +bleiben erhalten; Summary und Berichtskontext sind von Findings getrennt. +Es entstehen keine neuen Ausführungs-, Netzwerk- oder Datenbankrechte. + +### Strukturtreue bei PingCastle + +XML-Attribute werden als separate Originalwerte mit exakten Quellpfaden geführt; +ausdrückliche Leere wird nicht als nicht erhoben interpretiert. Lexikalische +HTML-Auswertung respektiert zitierte Attribute und Raw-Text-Grenzen, sodass +Tooltip-Markup weder zu scheinbaren Tabellen noch zu Zelltext wird. Aktive +Attribute werden nur als vollständige Tag-Attribute entfernt. Fehlende native +Rule IDs, Dubletten und abweichende deklarierte Trefferzahlen besitzen explizite +Diagnosen; ein angekündigter, aber nicht lesbarer Befundbestand darf nicht als +erfolgreicher Nullbefund gelten. Regeln und Originalzähler bleiben getrennt. +Diese Änderung öffnet keine aktive HTML-, Netzwerk- oder Persistenzberechtigung. +Details und Grenzen: `docs/IMPORT_SECURITY_LIMITS.md`. + +### Eingebettete Maester-Berichtsdaten + +Maester-HTML kann neben JSON ein minifiziertes JavaScript-Objektliteral enthalten. +Der Quellenextractor liest daraus ausschließlich statische Daten: Objekte, Arrays, +Zeichenketten (auch mehrzeilig ohne Interpolation), endliche Zahlen, Boolean und +Null sowie die festen Boolean-Schreibweisen `!0`/`!1`. Er führt keinerlei Code aus. +Aufrufe, Variablenzugriffe, Getter, Spread, berechnete Schlüssel, doppelte Schlüssel +und Template-Interpolation werden abgewiesen. Die Grenzen und Regressionen sind in +`docs/IMPORT_SECURITY_LIMITS.md` beschrieben. Importierte Skripte bleiben inaktiv; +es gibt keine neue Netzwerk-, Shell- oder Tauri-Berechtigung. + ### Verweisziele aus Berichten Berichte führen fachlich notwendige Belegstellen als Verweise mit (Purple @@ -69,6 +167,51 @@ maskiert), `tests/importers/excel-importer.test.ts` (Zellverweis wird vor dem Parsing geprüft. Große Base64-Zeichenfolgen werden iterativ validiert, damit die API-Prüfung selbst keinen JavaScript-Stacküberlauf erzeugt. +### Externe NVD-CVE-Anreicherung + +- Ein Import löst niemals selbst einen externen Netzwerkzugriff aus. Die + Anreicherung wird je bereits gespeichertem Defender-for-IoT-CVE bewusst über + `POST /api/v1/cves/:cveId/enrich` gestartet. +- Nur das Backend verbindet sich mit dem fest codierten Ursprung + `https://services.nvd.nist.gov/rest/json/cves/2.0`; die Browser-App bleibt auf + der Same-Origin-API. Benutzerkontrollierte Ziel-URLs werden nicht abgerufen. +- Zulässig sind ausschließlich normalisierte CVE-IDs. Vor dem Abruf muss die ID + von einem gespeicherten Defender-for-IoT-Finding referenziert werden, sodass + der Endpunkt nicht als allgemeiner externer Proxy verwendet werden kann. +- Antworten besitzen ein 8-MiB-Limit und ein konfigurierbares Timeout. Es werden + nur normalisierte öffentliche CVE-Felder gespeichert; optionale NVD-API-Keys + kommen ausschließlich aus `NVD_API_KEY`, werden nicht persistiert, + zurückgegeben oder protokolliert. +- Von NVD gelieferte Referenzziele gelten als nicht vertrauenswürdig. Es werden + nur `http:`/`https:`-Adressen übernommen und mit `target="_blank"` sowie + `rel="noreferrer"` gerendert. + +### Externes Work-LiteLLM fuer AI Overview + +- AI Overview ist ohne `ASSESSOR_AI_MODE=litellm` deaktiviert. URL, Modellalias + und Bearer-Key kommen ausschliesslich aus der Backendumgebung und werden nie + an den Browser, Exporte, Persistenz oder Logs weitergegeben. +- Eine externe Anfrage entsteht nur nach ausdruecklichem Generate/Regenerate. + Uebertragen wird ausschliesslich der bestehende versionierte + `resultsToPrivacySafeExportJson`-Inhalt des vollstaendigen aktiven Timeslots; + Rohdateien, Reviews, Quelltabellen, Storage Keys und nicht freigegebene + Environmentfelder bleiben lokal. +- Der konfigurierte Ursprung muss HTTPS verwenden, darf keine Credentials, + Query, Fragmente oder Loopbackadresse enthalten und kann nicht ueber die API + beeinflusst werden. Redirects sind verboten; Timeout und Antwortgroesse sind + begrenzt. +- Assessmentwerte bleiben nicht vertrauenswürdige Daten. Modellantworten werden + als inertes JSON geparst und lokal gegen Schema, Laengen, Quell-IDs, + Environment-Properties und direkte E-Mail-/IP-Identifier geprueft. React + rendert ausschliesslich Text, kein HTML oder Markdown. +- Persistiert werden nur Laufmetadaten und ein erfolgreich validiertes + Endergebnis. Prompts mit Assessmentdaten, Chunk-Zwischenergebnisse und + Providerantworten werden nicht aufbewahrt. Fehlgeschlagene Calls werden nicht + automatisch kostenpflichtig wiederholt. +- Das Ergebnis ist beratend und kann weder Score, Finding, Review, Accepted Risk + noch Importdaten veraendern. Weitere Details stehen in + [docs/AI_OVERVIEW_SECURITY.md](docs/AI_OVERVIEW_SECURITY.md). + ## Batchimport-Grenze Mehrdateiimporte verwenden eine serverseitige Vorschau mit eindeutiger Batch- und Eintrags-ID. Der Abschluss enthält nur die ausgewählten IDs, SHA-256-Werte und Dateimetadaten; das Backend gleicht sie gegen die von ihm selbst geparste Vorschau ab. Geänderte, unbekannte, verdrängte oder nach 15 Minuten beziehungsweise einem Neustart abgelaufene Auswahlen werden vor jeder Persistenz abgewiesen. Der Vorschaucache ist zusätzlich auf 10 Batches und 256 MiB Quelldaten begrenzt. @@ -125,8 +268,9 @@ bleiben unabhängig davon eine Eingabegrenze. `npm test` führt Modul-, Server-, Parser-, API-, Migrations- und Repositorytests sowie `tests/local-only-check.mjs` aus. Die Architekturprüfung -erlaubt `fetch` nur im gekapselten Same-Origin-API-Client, verhindert fest -eingetragene externe Ursprünge, CORS-Freigaben, zusätzliche Netzwerkpfade, +erlaubt Browser-`fetch` nur im gekapselten Same-Origin-API-Client und prueft die +freigegebenen Backendclients fuer NVD sowie das explizite HTTPS-Work-LiteLLM; sie verhindert +CORS-Freigaben, zusätzliche Netzwerkpfade, externe Assets, erweiterte Tauri-Rechte und Datenbankzugriffe aus React-Modulen. Der PostgreSQL-Integrationstest verwendet eine ausdrücklich gesetzte diff --git a/artifacts/test-output-dashboard.html b/artifacts/test-output-dashboard.html new file mode 100644 index 0000000..ea7222a --- /dev/null +++ b/artifacts/test-output-dashboard.html @@ -0,0 +1,133 @@ + + + + + + ASSESSOR · Analysis preview + + + +
+ + + + diff --git a/artifacts/test-output-data.js b/artifacts/test-output-data.js new file mode 100644 index 0000000..4c02ae4 --- /dev/null +++ b/artifacts/test-output-data.js @@ -0,0 +1,540 @@ +window.ASSESSOR_PREVIEW_DATA = { + "schemaVersion": 1, + "executiveSummary": "The assessment indicates a critical posture driven by confirmed Tier 0 Active Directory and AD CS exposures. The authoritative summary reports 455 actionable findings, 450 failed results, and overall finding severity totals of 17 critical and 190 high. Critical indicators include AdminSDHolder permission changes, weak privileged password policy, unsafe certificate templates, AD CS web enrollment, an enabled domain-controller print spooler, and a Zerologon finding. Entra ID also shows recurring weaknesses in privileged-role governance, phishing-resistant MFA, risk-based access, legacy authentication, application consent, and external collaboration. Monitoring is weakened by failed centralized security-log and privileged-role alerting controls, while an unusual privileged sign-in warning requires investigation. Windows baseline deviations add legacy-protocol, auditing, firewall, and domain-controller hardening concerns. Coverage is incomplete because 169 checks were not run and 2 findings ended in execution errors; these gaps are not treated as passed or failed.", + "assessment": { + "riskLevel": "critical", + "confidence": "medium", + "rationale": "Multiple confirmed critical indicators affect Tier 0 identity infrastructure and AD CS, with additional high-risk identity and privilege-control deviations in Entra ID. Confidence is reduced by 169 not-run checks and 2 execution errors, but those gaps do not negate the confirmed critical evidence." + }, + "environmentOverview": { + "summary": "Observed context includes Windows Server 2016 domain and forest functional levels, Windows Server 2019 operating-system observations, a single domain controller, PKI certificate-template inventory, disabled AD Recycle Bin, and no WEF configuration observed. These observations provide context only and are not treated as security findings.", + "factsUsed": [ + "domain.functional_level", + "forest.functional_level", + "domain.controller_count", + "operating_system.name", + "inventory.sectionpki.certificate.templates.list.row_count", + "domain.recycle_bin_enabled", + "logging.wef.configuration_count" + ] + }, + "themes": [ + { + "id": "T1", + "title": "Tier 0 Active Directory exposure", + "riskLevel": "critical", + "confidence": "high", + "summary": "Confirmed deviations affect core domain-control paths, including AdminSDHolder permissions, Zerologon, domain-controller print services, writable RBCD paths, shadow credentials on privileged objects, dangerous GPO user rights, and weak privileged-account password controls.", + "findingIds": [ + "SI000055", + "SI000036", + "SI000077", + "SI000079", + "SI000080", + "SI000351", + "SI000302", + "SI000096", + "SI000067" + ] + }, + { + "id": "T2", + "title": "AD CS certificate abuse paths", + "riskLevel": "critical", + "confidence": "high", + "summary": "Certificate services expose multiple abuse paths: requester-controlled subject alternative names, web enrollment accepting an unsafe authentication path, and templates combining several insecure settings. These findings can undermine privileged authentication and require careful PKI remediation.", + "findingIds": [ + "SI000157", + "SI000095", + "SI000156" + ] + }, + { + "id": "T3", + "title": "Privileged access governance", + "riskLevel": "high", + "confidence": "high", + "summary": "Privileged access is insufficiently separated and time-bound. Findings cover synchronized or mail-enabled administrators, excessive or permanent high privilege, external privileged users, privileged service principals using client secrets, root-scope access, and weak Global Administrator governance.", + "findingIds": [ + "CIS.M365.1.1.1", + "CIS.M365.1.1.3", + "MT.1025", + "MT.1027", + "MT.1028", + "MT.1030", + "MT.1032", + "MT.1056", + "CISA.MS.AAD.7.1", + "CISA.MS.AAD.7.2", + "CISA.MS.AAD.7.3", + "CISA.MS.AAD.7.4" + ] + }, + { + "id": "T4", + "title": "Authentication and Conditional Access", + "riskLevel": "high", + "confidence": "high", + "summary": "Identity protection is weakened by failures involving phishing-resistant MFA, administrator MFA, risk-based access, legacy authentication blocking, weak authentication methods, secure MFA registration, and managed-device requirements. Changes should be staged to avoid lockout.", + "findingIds": [ + "CISA.MS.AAD.2.3", + "CISA.MS.AAD.3.1", + "CISA.MS.AAD.3.5", + "CISA.MS.AAD.3.6", + "CISA.MS.AAD.3.7", + "CISA.MS.AAD.3.8", + "CISA.MS.AAD.1.1", + "MT.1024.mfaRegistrationV2", + "MT.1024.signinRiskPolicy", + "MT.1024.userRiskPolicy", + "MT.1024.adminMFAV2", + "MT.1009", + "MT.1010", + "MT.1011", + "MT.1012", + "MT.1014" + ] + }, + { + "id": "T5", + "title": "Detection and privileged monitoring", + "riskLevel": "high", + "confidence": "high", + "summary": "Central security-log forwarding and privileged-role assignment or activation alerting are not meeting the assessed controls. A warning also identifies unusual privileged sign-in activity, which requires investigation rather than automatic classification as compromise.", + "findingIds": [ + "CISA.MS.AAD.4.1", + "CISA.MS.AAD.7.7", + "CISA.MS.AAD.7.9", + "MT.INV.001" + ] + }, + { + "id": "T6", + "title": "Application and external access governance", + "riskLevel": "high", + "confidence": "high", + "summary": "Application consent, privileged service principals, expiring application credentials, guest invitations, and SharePoint external sharing show governance weaknesses. Together they increase the likelihood of excessive application or external-party access.", + "findingIds": [ + "CISA.MS.AAD.5.2", + "CISA.MS.AAD.5.3", + "EIDSCA.CR01", + "MT.1024.applicationCredentialExpiry", + "MT.1027", + "CISA.MS.AAD.8.2", + "CISA.MS.SHAREPOINT.1.3" + ] + }, + { + "id": "T7", + "title": "Windows and domain-controller baseline drift", + "riskLevel": "medium", + "confidence": "medium", + "summary": "Confirmed baseline deviations include legacy LM or NTLM acceptance, missing LDAP channel-binding or signing enforcement, SMBv1 settings, firewall configuration, credential-validation auditing, and SYSVOL or NETLOGON path hardening. Source severity is unknown for several checks, so risk is assessed conservatively.", + "findingIds": [ + "S-OldNtlm", + "2.3.5.3", + "2.3.5.4", + "18.4.2", + "18.4.3", + "9.1.1", + "17.1.1", + "18.6.14.1" + ] + } + ], + "priorities": [ + { + "rank": 1, + "title": "Investigate Tier 0 compromise indicators", + "timeframe": "immediate", + "owner": "Incident Response Lead with Active Directory Security Owner", + "rationale": "AdminSDHolder permission changes are a critical indicator and unusual privileged sign-in activity is separately flagged for investigation. Establish whether changes and sign-ins were authorized before routine configuration work alters evidence.", + "expectedRiskReduction": "Rapidly distinguishes authorized change from active compromise and enables containment before an attacker can retain or expand privileged access.", + "validation": "Document the AdminSDHolder ACL review, correlate privileged sign-in evidence, confirm authorized ownership of observed changes, and record containment or closure decisions.", + "findingIds": [ + "SI000055", + "MT.INV.001" + ] + }, + { + "rank": 2, + "title": "Resolve critical domain-controller exposures", + "timeframe": "immediate", + "owner": "Active Directory Platform Owner", + "rationale": "The assessment confirms a Zerologon finding and an enabled print spooler on a domain controller. Both affect Tier 0 infrastructure and should be addressed before lower-severity baseline work.", + "expectedRiskReduction": "Reduces direct compromise and coercion or relay opportunities against domain-controller services.", + "validation": "Re-run the two source checks after remediation and verify the affected domain-controller configuration is in the intended state.", + "findingIds": [ + "SI000036", + "SI000077" + ] + }, + { + "rank": 3, + "title": "Close AD CS certificate abuse paths", + "timeframe": "immediate", + "owner": "PKI Owner with Active Directory Security Owner", + "rationale": "Critical AD CS findings expose unsafe certificate enrollment and template behavior. Changes must preserve required issuance workflows while removing unnecessary subject-name control and other insecure template settings.", + "expectedRiskReduction": "Reduces certificate-based privilege escalation and identity impersonation paths.", + "validation": "Inventory affected templates and enrollment endpoints, document approved business requirements, apply approved changes, and re-run all cited AD CS checks.", + "findingIds": [ + "SI000095", + "SI000157", + "SI000156" + ] + }, + { + "rank": 4, + "title": "Remove writable privilege-escalation paths in Active Directory", + "timeframe": "immediate", + "owner": "Active Directory Security Owner", + "rationale": "Writable RBCD on Tier 0 objects, shadow credentials on privileged objects, and dangerous GPO-granted rights create direct privilege-escalation paths. They should be reviewed and removed unless explicitly required.", + "expectedRiskReduction": "Eliminates high-impact paths that can convert lower privilege into control of privileged identities or systems.", + "validation": "Confirm each cited path has an approved owner and purpose, remove unauthorized access, and re-run the source checks to verify closure.", + "findingIds": [ + "SI000079", + "SI000080", + "SI000351", + "SI000302" + ] + }, + { + "rank": 5, + "title": "Harden privileged account password controls", + "timeframe": "short_term", + "owner": "Active Directory Identity Owner", + "rationale": "Privileged users are reported under a weak password policy and privileged passwords that never expire are also identified. Correcting privileged credential policy reduces persistence and password-based takeover risk.", + "expectedRiskReduction": "Reduces exposure from weak or indefinitely valid privileged credentials.", + "validation": "Confirm privileged accounts are covered by the approved stronger policy, remove unsupported non-expiring settings, and re-run the cited checks.", + "findingIds": [ + "SI000096", + "SI000067" + ] + }, + { + "rank": 6, + "title": "Rebuild privileged Entra access around least privilege and just-in-time activation", + "timeframe": "short_term", + "owner": "Entra ID Identity Governance Owner", + "rationale": "Multiple high findings show permanent, excessive, synchronized, mail-enabled, external, and service-principal privilege. Design emergency-access exceptions first, then reduce standing privilege and use eligible assignments where supported.", + "expectedRiskReduction": "Shrinks the standing cloud control-plane attack surface and limits blast radius from a compromised privileged identity.", + "validation": "Review privileged assignments, document approved exceptions, verify least-privilege role mapping, and re-run all cited privileged-access checks.", + "findingIds": [ + "CIS.M365.1.1.1", + "MT.1025", + "MT.1027", + "MT.1028", + "MT.1030", + "MT.1032", + "MT.1056", + "CISA.MS.AAD.7.2", + "CISA.MS.AAD.7.3", + "CISA.MS.AAD.7.4" + ] + }, + { + "rank": 7, + "title": "Stage phishing-resistant MFA and risk-based Conditional Access", + "timeframe": "short_term", + "owner": "Entra ID Conditional Access Owner", + "rationale": "High findings show gaps in MFA strength, administrator MFA, risky sign-in handling, legacy authentication blocking, secure registration, and device requirements. Use staged testing with emergency-access exclusions and rollback planning.", + "expectedRiskReduction": "Substantially reduces account takeover from phishing, legacy authentication, risky sessions, and unauthorized MFA registration.", + "validation": "Test policies with pilot populations, confirm emergency access remains usable, review sign-in impact, then re-run the cited controls after staged enforcement.", + "findingIds": [ + "CISA.MS.AAD.2.3", + "CISA.MS.AAD.3.1", + "CISA.MS.AAD.3.5", + "CISA.MS.AAD.3.6", + "MT.1024.adminMFAV2", + "MT.1009", + "MT.1010", + "MT.1011", + "MT.1012", + "MT.1014" + ] + }, + { + "rank": 8, + "title": "Restore centralized identity monitoring and privilege alerts", + "timeframe": "short_term", + "owner": "Security Operations Lead", + "rationale": "The assessment reports failed centralized Entra security-log collection and missing privileged-role assignment or activation alerting. These gaps delay detection and investigation of identity attacks.", + "expectedRiskReduction": "Improves detection, triage, and forensic visibility for sign-in, risk, application, and privileged-role events.", + "validation": "Verify required Entra logs reach the monitored security platform, generate test privileged-role events, and confirm alerts are received and triaged.", + "findingIds": [ + "CISA.MS.AAD.4.1", + "CISA.MS.AAD.7.7", + "CISA.MS.AAD.7.9" + ] + }, + { + "rank": 9, + "title": "Tighten application consent, service-principal credentials, and external sharing", + "timeframe": "medium_term", + "owner": "Cloud Security and Microsoft 365 Governance Owner", + "rationale": "High findings cover user consent, missing admin-consent workflow, privileged service principals using secrets, expiring credentials, guest invitations, and broad SharePoint external sharing. Remediation should preserve required integrations.", + "expectedRiskReduction": "Reduces illicit consent, long-lived application credential abuse, and unintended external data access.", + "validation": "Review approved applications and collaboration requirements, validate credential rotations, test consent workflow, and re-run the cited checks.", + "findingIds": [ + "CISA.MS.AAD.5.2", + "CISA.MS.AAD.5.3", + "MT.1027", + "MT.1024.applicationCredentialExpiry", + "CISA.MS.AAD.8.2", + "CISA.MS.SHAREPOINT.1.3" + ] + }, + { + "rank": 10, + "title": "Harden Windows and domain-controller security baselines", + "timeframe": "medium_term", + "owner": "Windows Platform Security Owner", + "rationale": "Confirmed baseline deviations include legacy authentication, LDAP protections, SMBv1, firewall state, auditing, and hardened domain paths. Apply changes in dependency order with compatibility testing, especially for legacy protocols.", + "expectedRiskReduction": "Reduces credential relay, downgrade, lateral-movement, and visibility risks across the Windows identity infrastructure.", + "validation": "Pilot baseline changes, review authentication and application impact, deploy approved settings, and re-run the cited checks.", + "findingIds": [ + "S-OldNtlm", + "2.3.5.3", + "2.3.5.4", + "18.4.2", + "18.4.3", + "9.1.1", + "17.1.1", + "18.6.14.1" + ] + } + ], + "roadmap": [ + { + "phase": 0, + "title": "Contain and validate Tier 0 risk", + "tasks": [ + "Investigate AdminSDHolder and privileged sign-in anomalies before configuration cleanup.", + "Resolve or formally disposition critical domain-controller and AD CS exposures.", + "Remove unauthorized Tier 0 write paths and preserve investigation evidence." + ], + "completionCriteria": [ + "All Tier 0 items cited in immediate priorities have documented owners, disposition, and re-test evidence.", + "Any suspected compromise has a recorded incident decision and containment status.", + "No critical change is closed solely on configuration intent without a successful validation check." + ] + }, + { + "phase": 1, + "title": "Secure privileged identities and authentication", + "tasks": [ + "Strengthen privileged account credential policy.", + "Redesign Entra privileged assignments around least privilege and eligible activation.", + "Pilot phishing-resistant MFA, risk policies, legacy-authentication blocking, and secure registration controls." + ], + "completionCriteria": [ + "Privileged role assignments have documented business justification and approved exceptions.", + "Emergency-access paths are tested before broad Conditional Access enforcement.", + "Pilot authentication policies show acceptable sign-in impact and have rollback procedures." + ] + }, + { + "phase": 2, + "title": "Improve monitoring and cloud governance", + "tasks": [ + "Send required identity security logs to the monitored security platform.", + "Enable and test privileged assignment and activation alerts.", + "Tighten application consent, service-principal credentials, guest invitation, and external sharing governance." + ], + "completionCriteria": [ + "Test identity and privileged-role events are visible to security operations.", + "Application and external-access exceptions have named owners and review dates.", + "Cited monitoring and governance findings are re-tested after changes." + ] + }, + { + "phase": 3, + "title": "Harden platform baselines and close coverage gaps", + "tasks": [ + "Remediate high-impact Windows and domain-controller baseline deviations with compatibility testing.", + "Re-run failed execution checks and grouped not-run control areas with the required permissions, licensing, or data access.", + "Address remaining confirmed medium and lower-priority deviations in risk order." + ], + "completionCriteria": [ + "Legacy protocol and domain-controller hardening changes pass technical validation.", + "Execution-error checks return a definitive assessed outcome.", + "Not-run areas have either evidence, a documented technical limitation, or an accepted coverage exception." + ] + }, + { + "phase": 4, + "title": "Institutionalize identity security governance", + "tasks": [ + "Establish recurring privileged-access reviews and certificate-template reviews.", + "Maintain tested emergency-access procedures and Conditional Access change control.", + "Schedule repeat assessments and track deviations to closure or formal risk acceptance." + ], + "completionCriteria": [ + "Recurring reviews have defined owners, cadence, and evidence retention.", + "Critical identity controls are included in change monitoring and incident procedures.", + "Repeat assessment results show documented disposition for previously cited priority findings." + ] + } + ], + "coverageGaps": [ + { + "title": "Exchange and email threat protection not assessed", + "impact": "Malware scanning, Safe Attachments, spam and phishing defenses, SMTP AUTH, DKIM or DMARC enforcement, and related mail controls remain unknown.", + "nextStep": "Re-run the Exchange and Defender checks with the required service access and licensing, then classify each result independently.", + "evidenceIds": [ + "CIS.M365.2.1.4", + "CIS.M365.2.1.5", + "CIS.M365.2.1.9", + "CISA.MS.EXO.10.1", + "CISA.MS.EXO.10.2", + "CISA.MS.EXO.11.1", + "CISA.MS.EXO.14.1", + "CISA.MS.EXO.5.1" + ] + }, + { + "title": "Microsoft 365 audit and alert coverage not assessed", + "impact": "Mailbox auditing, audit-log availability, security alerts, and Purview audit coverage cannot be confirmed from this run.", + "nextStep": "Provide the scanner access needed to query audit and alert configuration, then re-run the affected controls.", + "evidenceIds": [ + "CIS.M365.3.1.1", + "CISA.MS.EXO.13.1", + "CISA.MS.EXO.16.1", + "CISA.MS.EXO.17.1" + ] + }, + { + "title": "Data loss prevention coverage not assessed", + "impact": "The presence and effectiveness of email DLP controls for sensitive data remain unknown.", + "nextStep": "Run the DLP checks with access to the applicable Microsoft 365 or Purview configuration and capture definitive results.", + "evidenceIds": [ + "CISA.MS.EXO.8.1", + "CISA.MS.EXO.8.2", + "CISA.MS.EXO.8.3", + "CISA.MS.EXO.8.4" + ] + }, + { + "title": "Application attack-path checks not assessed", + "impact": "High-risk application permissions, paths to Global Administrator, app-owner MFA, and group-owner consent controls remain unknown.", + "nextStep": "Re-run application governance and attack-path checks with sufficient Graph and directory read permissions.", + "evidenceIds": [ + "CISA.MS.AAD.5.4", + "MT.1050", + "MT.1051", + "MT.1063" + ] + }, + { + "title": "Device and credential exposure checks not assessed", + "impact": "Exposure of vulnerable devices and protection of critical credentials by endpoint controls cannot be confirmed.", + "nextStep": "Provide the required endpoint-security telemetry and re-run the device and credential-protection checks.", + "evidenceIds": [ + "MT.1087", + "MT.1080", + "MT.1088", + "MT.1089" + ] + }, + { + "title": "Teams collaboration controls not assessed", + "impact": "Presenter, anonymous participant, lobby, external control, reporting, and unmanaged-user restrictions remain partially unknown.", + "nextStep": "Re-run Teams policy checks with access to the tenant collaboration configuration.", + "evidenceIds": [ + "MT.1037", + "CIS.M365.8.2.2", + "CIS.M365.8.5.3", + "MT.1042", + "MT.1046", + "MT.1047", + "MT.1048" + ] + }, + { + "title": "Authentication control coverage remains incomplete", + "impact": "Security Defaults, FIDO2 restrictions, modern Exchange authentication, and some legacy-authentication user checks were not assessed.", + "nextStep": "Resolve permission or licensing prerequisites and re-run the authentication checks without treating current not-run states as compliant.", + "evidenceIds": [ + "MT.1021", + "EIDSCA.AF05", + "MT.1044", + "MT.1033.0", + "MT.1033.1", + "MT.1033.2", + "MT.1033.3" + ] + }, + { + "title": "Hybrid identity checks failed to execute", + "impact": "Seamless SSO hardening and synchronized-object matching protections remain unknown because their checks returned execution errors.", + "nextStep": "Correct the scanner data or execution prerequisites and re-run both checks to obtain definitive outcomes.", + "evidenceIds": [ + "MT.1084", + "MT.1073" + ] + } + ], + "quickWins": [ + { + "title": "Investigate the unusual privileged sign-in warning using existing sign-in logs", + "findingIds": [ + "MT.INV.001" + ] + }, + { + "title": "Review AdminSDHolder ACL changes against approved change records", + "findingIds": [ + "SI000055" + ] + }, + { + "title": "Disable the domain-controller Print Spooler where it is not required", + "findingIds": [ + "SI000077" + ] + }, + { + "title": "Enable privileged-role assignment and activation alert recipients", + "findingIds": [ + "CISA.MS.AAD.7.7", + "CISA.MS.AAD.7.9" + ] + }, + { + "title": "Require write permission for creation of new management groups", + "findingIds": [ + "MT.1064" + ] + }, + { + "title": "Start NTLM auditing before any deny policy is introduced", + "findingIds": [ + "2.3.11.11", + "2.3.11.12", + "2.3.11.13" + ] + } + ], + "questions": [ + "Were the AdminSDHolder permission changes authorized, and is there a corresponding approved change record?", + "What evidence supports or contradicts active exploitation of the Zerologon and AD CS findings?", + "Which certificate templates and web-enrollment services are business-critical, and what existing mitigations are documented?", + "Which privileged Entra assignments must remain permanent because of emergency-access or non-interactive service requirements?", + "Are Entra ID P1 or P2 and Privileged Identity Management capabilities licensed and operationally available?", + "Are any Conditional Access policies currently in report-only mode or excluded from the scanner view?", + "Are Entra security logs already forwarded to another monitored platform through a path the assessment could not observe?", + "Which external collaboration and SharePoint sharing scenarios are formally approved by the business?", + "Which applications depend on client secrets or privileged service-principal roles, and what rotation constraints apply?", + "What caused the not-run and execution-error checks: permissions, licensing, connectivity, missing telemetry, or scanner limitations?" + ], + "assumptions": [ + "The summary object is treated as authoritative for all assessment counts.", + "Failed results and deviation flags are treated as confirmed configuration deviations, not proof of successful exploitation.", + "Indicators of exposure are prioritized above comparable non-IoE deviations.", + "Warnings require investigation and are not treated as confirmed compromise.", + "Not-run checks and execution errors are treated only as coverage gaps.", + "Environment facts are used only for context and are not promoted into findings.", + "No missing description or recommendation is inferred beyond the evidence provided." + ] +}; + diff --git a/docker-compose.deploy.yml b/docker-compose.deploy.yml index ca0b672..5e80cab 100644 --- a/docker-compose.deploy.yml +++ b/docker-compose.deploy.yml @@ -2,8 +2,9 @@ # The workflow always supplies a distinct project name and VPN-only host port: # assessor_prod -> 10.0.0.154:4173 # assessor_experimental -> 10.0.0.154:4174 -# Compose scopes both named volumes by project, so the environments never share -# PostgreSQL or artifacts. PostgreSQL is intentionally not published to the host. +# Compose scopes all named volumes by project, so the environments never share +# PostgreSQL, artifacts, or the rebuildable Qdrant index. PostgreSQL and Qdrant +# are intentionally not published to the host. name: ${ASSESSOR_STACK:-assessor_prod} services: @@ -22,6 +23,18 @@ services: ASSESSOR_POSTGRES_USER: ${ASSESSOR_POSTGRES_USER:?set ASSESSOR_POSTGRES_USER} ASSESSOR_POSTGRES_PASSWORD: ${ASSESSOR_POSTGRES_PASSWORD:?set ASSESSOR_POSTGRES_PASSWORD} ASSESSOR_DATABASE_SSL: disable + ASSESSOR_QDRANT_URL: http://qdrant:6333 + ASSESSOR_QDRANT_API_KEY: ${ASSESSOR_QDRANT_API_KEY:?set ASSESSOR_QDRANT_API_KEY} + ASSESSOR_RAG_EMBEDDING_BASE_URL: ${ASSESSOR_RAG_EMBEDDING_BASE_URL:-} + ASSESSOR_RAG_EMBEDDING_MODEL: ${ASSESSOR_RAG_EMBEDDING_MODEL:-} + ASSESSOR_RAG_EMBEDDING_API_KEY: ${ASSESSOR_RAG_EMBEDDING_API_KEY:-} + ASSESSOR_RAG_EMBEDDING_DIMENSIONS: ${ASSESSOR_RAG_EMBEDDING_DIMENSIONS:-} + ASSESSOR_RAG_EMBEDDING_REQUEST_DIMENSIONS: ${ASSESSOR_RAG_EMBEDDING_REQUEST_DIMENSIONS:-} + ASSESSOR_AI_MODE: ${ASSESSOR_AI_MODE:-} + ASSESSOR_AI_BASE_URL: ${ASSESSOR_AI_BASE_URL:-} + ASSESSOR_AI_MODEL: ${ASSESSOR_AI_MODEL:-} + ASSESSOR_AI_API_KEY: ${ASSESSOR_AI_API_KEY:-} + ASSESSOR_ISO_UPLOAD_TOKEN: ${ASSESSOR_ISO_UPLOAD_TOKEN:-} ports: - "${ASSESSOR_BIND:?set ASSESSOR_BIND}:${ASSESSOR_PUBLISH_PORT:?set ASSESSOR_PUBLISH_PORT}:4173" volumes: @@ -51,6 +64,16 @@ services: volumes: - assessor-postgres-data:/var/lib/postgresql/data + qdrant: + image: qdrant/qdrant:v1.19.1 + restart: unless-stopped + environment: + QDRANT__SERVICE__API_KEY: ${ASSESSOR_QDRANT_API_KEY:?set ASSESSOR_QDRANT_API_KEY} + QDRANT__TELEMETRY_DISABLED: "true" + volumes: + - assessor-qdrant-data:/qdrant/storage + volumes: assessor-artifacts: assessor-postgres-data: + assessor-qdrant-data: diff --git a/docker-compose.postgres.yml b/docker-compose.postgres.yml index b6b8e46..0a73246 100644 --- a/docker-compose.postgres.yml +++ b/docker-compose.postgres.yml @@ -1,3 +1,5 @@ +name: assessor-2_0 + services: postgres: image: postgres:16-alpine @@ -16,5 +18,20 @@ services: volumes: - assessor-postgres-data:/var/lib/postgresql/data + qdrant: + image: qdrant/qdrant:v1.19.1 + restart: unless-stopped + environment: + QDRANT__SERVICE__API_KEY: ${ASSESSOR_QDRANT_API_KEY:?ASSESSOR_QDRANT_API_KEY must be set} + QDRANT__TELEMETRY_DISABLED: "true" + ports: + - "127.0.0.1:${ASSESSOR_QDRANT_PORT:-6333}:6333" + volumes: + - assessor-qdrant-data:/qdrant/storage + volumes: assessor-postgres-data: + name: assessor-2_0_assessor-postgres-data + external: true + assessor-qdrant-data: + name: assessor-2_0_assessor-qdrant-data diff --git a/docs/AI_OVERVIEW_SECURITY.md b/docs/AI_OVERVIEW_SECURITY.md new file mode 100644 index 0000000..344decf --- /dev/null +++ b/docs/AI_OVERVIEW_SECURITY.md @@ -0,0 +1,59 @@ +# AI Overview security boundary + +AI Overview is an explicitly enabled server-side integration with the +company-managed LiteLLM gateway. It is disabled unless +`ASSESSOR_AI_MODE=litellm` and the HTTPS base URL, approved model alias, and API +key are all present in the backend environment. + +## Trust boundary and transmitted data + +The work LiteLLM service is an approved corporate processor outside the +ASSESSOR process. An explicit Generate or Regenerate action sends only the +versioned payload produced by `resultsToPrivacySafeExportJson`. ASSESSOR does +not send imported files, source tables, evidence records, reviews, unrestricted +environment observations, file paths, or storage keys. The gateway may retain +or route requests according to the company's own LiteLLM policy; that policy is +an operational prerequisite rather than something ASSESSOR can enforce. + +The JSON is still untrusted assessment data. System instructions tell the model +not to follow embedded commands, URLs, scripts, prompts, or markup. Returned +content is parsed as inert JSON and validated against the local output contract, +length limits, exact roadmap phases, and the source rule IDs and environment +properties present in the transmitted payload. It is rendered only as React +text and never interpreted as HTML or Markdown. + +## Network and secret controls + +- The browser talks only to `/api/v1` on its own origin. Content Security Policy + remains `connect-src 'self'`; the LiteLLM origin and key never enter a browser + response. +- The backend accepts only an absolute HTTPS LiteLLM URL without embedded + credentials, query parameters, fragments, or a loopback host. The destination + comes only from server configuration, never from an API request. +- Requests use bearer authentication, reject redirects, have a configured + timeout, and enforce a maximum response size. +- The API key is read from the backend environment. It is not committed, + persisted, exported, or logged. Provider response bodies, prompts containing + assessment data, and intermediate summaries are not persisted or logged. +- Automated retries are disabled because a retry can create another paid and + externally processed request. An interrupted or failed run requires an + explicit new Generate action. + +## Persistence and advisory status + +Migration 024 stores append-only generation-run identities and their lifecycle +state. A successful run retains only the validated final result and technical +metadata: scope, input hash, prompt/output versions, model alias, timestamps, +call/token counts, and a bounded safe error summary when applicable. One queued +or running record is allowed per project/timeslot scope. + +AI results are advisory. They never update findings, deterministic scores, +reviews, accepted-risk state, imports, or scanner processing data. A result is +marked stale when its privacy-safe input, model, prompt, or schema changes and +remains readable until the user explicitly regenerates it. + +## Verification boundary + +Automated tests use synthetic records and mocked LiteLLM responses. Live checks +must also use a synthetic project. Real tenant content must not be inspected, +logged, screenshotted, or sent merely to verify the integration. diff --git a/docs/CANONICAL_MODEL.md b/docs/CANONICAL_MODEL.md index 8922035..dc40d3f 100644 --- a/docs/CANONICAL_MODEL.md +++ b/docs/CANONICAL_MODEL.md @@ -95,3 +95,17 @@ Haupttabelle. Der unveränderte externe Vertragstext liegt unter und ihre Begründung stehen in [`RESULT_CONTRACT.md`](RESULT_CONTRACT.md#abweichungen-der-assessor-realisierung). Dieses Dokument bleibt der fachlich verbindliche, implementierte Stand. + +### ASSESSOR-Erweiterung: Vulnerability Finding + +Seit 2026-09-11 erweitert ASSESSOR den geschlossenen externen +`result_type`-Katalog additiv um `vulnerability_finding`. Der Typ bezeichnet +einen Scannerbefund zu einer konkreten Schwachstelle, ohne ihn als bestaetigten +Indicator of Exposure zu klassifizieren. Microsoft-Defender-for-IoT-CVEs werden +als `vulnerability_finding` mit `outcome = warning`, `is_ioe = false` und damit +`is_deviation = true` projiziert. Severity bleibt eine unabhaengige Achse. + +`environment-observation` bleibt dagegen ein `source_kind`, kein weiterer +`result_type`; diese Kontext- und Inventardaten werden als `informational` +projiziert. Der unveraenderte externe Referenzvertrag 1.0.0 wird durch diese +ASSESSOR-spezifische Erweiterung nicht rueckwirkend umgeschrieben. diff --git a/docs/COMPARISON_ENGINE.md b/docs/COMPARISON_ENGINE.md index 0012f9a..9520e39 100644 --- a/docs/COMPARISON_ENGINE.md +++ b/docs/COMPARISON_ENGINE.md @@ -3,6 +3,12 @@ Stand: 2026-07-17 Zugehörige Planphase: Phase 8 +## Statusklarstellung 2026-09-11 + +Der folgende Text dokumentiert den historischen Stand, nicht die Abnahme eines belastbaren objektgenauen Timeslotvergleichs. Insbesondere ist die unten beschriebene Regel `resolved = im Ziellauf nicht mehr vorhanden` kein ausreichender Behebungsnachweis. Die aktuelle Timeslot-Projektion kann Quell-/Verarbeitungsprüfungen umgehen; die automatisch verwendeten Regel-/Definitionsmatches garantieren keine gemeinsame Objektidentität. Die hier historisch genannten Regel-/Asset- und Merkmalsstufen sind kein Nachweis ihrer aktuellen automatischen Verdrahtung. + +Die Erweiterung in [TIMESLOT_COMPARISON_PLAN.md](TIMESLOT_COMPARISON_PLAN.md) definiert den Gegenprüfungs-, Identitäts- und Fortschreibungsvertrag sowie P0-P6 mit Abnahmetests. P0 ist abgeschlossen; P1/P2 sind in Arbeit. Der additive Domänenvertrag und `compareProjectTimeslotEvidence` arbeiten bereits profilgebunden mit echten Scannerläufen, Dateiprovenienz, Processingkompatibilität, eindeutigem Scope und neuerer Reportzeit. Abwesenheit bleibt konservativ ungeklärt. Dieser sichere Pfad ist noch nicht an Persistenz/API oder Oberfläche angebunden und ersetzt daher die unten dokumentierte Legacyengine im Produkt noch nicht; die frühere Beschreibung bleibt zur Nachvollziehbarkeit erhalten. + ## Zweck Die Vergleichsengine ordnet Finding-Vorkommen aus zwei Scan-Läufen reproduzierbar ein. Sie arbeitet ausschließlich auf dem kanonischen Assessment-Modell und benötigt weder React noch Browser-, Tauri- oder Datenbankfunktionen. diff --git a/docs/DEPLOYMENT.md b/docs/DEPLOYMENT.md index 049644c..a84ca9d 100644 --- a/docs/DEPLOYMENT.md +++ b/docs/DEPLOYMENT.md @@ -28,6 +28,60 @@ ASSESSOR_POSTGRES_PASSWORD=replace-with-a-long-random-experimental-password Do not reuse the stable database name, user, or password for experimental. Secret values must never be printed into an Actions log. +Optional CVE enrichment settings may be added to each environment secret: + +```text +NVD_API_KEY= +ASSESSOR_NVD_TIMEOUT_MS=15000 +``` + +The key is sent only by the backend to the fixed NVD CVE 2.0 endpoint. Imports +remain offline and deterministic; a user must start enrichment for an already +stored Defender-for-IoT CVE. + +Optional AI Overview settings may be added only when the company-managed +LiteLLM gateway is approved for the privacy-safe ASSESSOR payload: + +```text +ASSESSOR_AI_MODE=litellm +ASSESSOR_AI_BASE_URL=https://work-litellm.example/v1 +ASSESSOR_AI_MODEL=approved-model-alias +ASSESSOR_AI_API_KEY= +ASSESSOR_AI_TIMEOUT_MS=60000 +ASSESSOR_AI_CHUNK_CHARS=80000 +ASSESSOR_AI_MAX_OUTPUT_BYTES=262144 +ASSESSOR_AI_MAX_CALLS=64 +ASSESSOR_AI_JOB_LEASE_MS=300000 +``` + +Do not place these values in the repository or expose them through client-side +configuration. The workstation uses the ignored `.env.postgres`; staging and +production use their existing complete environment-file secrets. See +[`AI_OVERVIEW_SECURITY.md`](AI_OVERVIEW_SECURITY.md) for the transmitted-data +and trust-boundary contract. + +To upload the licensed DIN ISO 27001 and 27002 PDFs from Data Hub, add the +following values to the environment's `STAGING_ENV_FILE` or `PROD_ENV_FILE`: + +```text +ASSESSOR_QDRANT_API_KEY= +ASSESSOR_RAG_EMBEDDING_BASE_URL=https://approved-embedding-gateway.example/v1 +ASSESSOR_RAG_EMBEDDING_MODEL= +ASSESSOR_RAG_EMBEDDING_API_KEY= +ASSESSOR_RAG_EMBEDDING_DIMENSIONS=1024 +ASSESSOR_ISO_UPLOAD_TOKEN= +``` + +The operator enters the upload token in Data Hub; it is checked by the backend +before either PDF is read and is not saved in browser storage. Keep the +LiteLLM settings above as well to enable mapping after indexing. The upload +stores the generated corpus privately in the environment's artifact volume, +deletes temporary original PDFs after parsing, and activates a new version +only after successful embedding. No server shell or manual corpus-version +environment edit is needed for this workflow. Use an embedding destination +approved for the licensed ISO text. The token protects only this upload action; +it does not add general user authentication. + ## Mandatory server inventory Before the first push-triggered deployment, connect to the target server over @@ -48,7 +102,7 @@ Also identify the existing reverse proxy and firewall policy without changing them. Confirm that `10.0.0.154` is a host address, port 4174 is unused, the runner uses this Docker daemon, and `assessor_experimental` does not belong to an unrelated stack. Port 4173 and project `assessor_prod` are intentionally -adopted as stable; only its expected `app` and `postgres` services may exist. +adopted as stable; only its expected `app`, `postgres`, and `qdrant` services may exist. Any other conflict blocks deployment and is never resolved by stopping or deleting the existing resource. @@ -62,8 +116,10 @@ dependencies, runs the complete test suite and production build, validates the resolved Compose configuration, checks port/project isolation, backs up an existing target environment, then builds and starts only that environment. -Compose project scoping produces independent PostgreSQL and artifact volumes. -PostgreSQL has no host-published port. `restart: unless-stopped` preserves both +Compose project scoping produces independent PostgreSQL, artifact, and Qdrant +volumes. PostgreSQL and Qdrant have no host-published ports. Qdrant is an +authenticated, rebuildable regulatory index; its volume improves restart time +but is not a system-of-record backup. `restart: unless-stopped` preserves both environments across Docker daemon and server restarts. Feature promotion is a merge from `experimental` to `main`. Stable is rebuilt diff --git a/docs/GPO_BASELINE_EVALUATION.md b/docs/GPO_BASELINE_EVALUATION.md new file mode 100644 index 0000000..cb9ced5 --- /dev/null +++ b/docs/GPO_BASELINE_EVALUATION.md @@ -0,0 +1,76 @@ +# GPO-Backup-Vergleich mit Baselinevarianten + +Stand: 2026-09-16 · Phase 7/13B · Evaluator `policy-baseline-evaluation@1.9.0` + +## Prüfgegenstand + +Geprüft wird die importierte GPO-Backup-Konfiguration gegen die ausdrücklich referenzierten Microsoft-Baselineanalysen. Das ist kein Nachweis der effektiv angewendeten Gerätekonfiguration, der Erreichbarkeit eines Dienstes oder einer tatsächlich ausnutzbaren Überprivilegierung. Baselinepakete bleiben getrennte Prüfungen; ein Ergebnis gilt nicht automatisch für andere Pakete, Betriebssysteme oder Rollen. + +Ein PingCastle-Scan ist keine Voraussetzung. OS-Inventar und Domain Functional Level dürfen eine einzelne GPO weder automatisch einer Zielrolle zuordnen noch ihre Anwendung beweisen. Die vorhandene Vorlagenauswahl akzeptiert nur einen eindeutigen, expliziten Vergleichskontext; beobachtungsgebundene Inventarkontexte wählen keine Rolle aus. Unbekannte Vorlagen bleiben Kandidaten. Eine explizite Auswahl ohne passende Vorlage bleibt ungeklärt. + +## Operativer Scope und Score + +Die normale GPO-Analyse ist auf Fehlkonfigurationen innerhalb des tatsächlich konfigurierten, technisch vergleichbaren und ausdrücklich anwendbaren Kundenscopes begrenzt. Eine fehlende Microsoft-Empfehlung bleibt als `Not configured` transparent sichtbar, erzeugt aber weder ein operatives Finding noch eine Standard-Remediation oder einen Scoreabzug. Die vollständige Einführung einer Microsoft-Baseline ist ein eigener, ausdrücklich beauftragter Hardening-Scope. + +Präzisierung vom selben Tag: `Not configured` bleibt ein score-neutrales Policy-Urteil. `Duplicates` und `Conflicts` bleiben eigenständige Diagnosekategorien der technischen Policy-Einstellung, sind aber keine alternativen Urteile, die Pass, Fail oder Review required verdecken. Die Mitgliedsvergleiche werden genau einmal je technischer Policy-Identität zusammengeführt: Weicht mindestens ein konfigurierter, eindeutig vergleichbarer In-Scope-Wert nachweislich ab, lautet das Gesamturteil der Policy-Einstellung `Fail`; Conflict-/Duplicate-Merkmale bleiben zusätzlich sichtbar. Bestehen alle anwendbaren Mitglieder, lautet das Urteil `Pass`. Sind Anwendbarkeit, Vorrang oder Vergleich ungeklärt, bleibt das Urteil `Review required`. Mehrere Quellzeilen, doppelte Vorkommen und Diagnosemarker vervielfachen den Scorebeitrag nicht. + +Der GPO-Score ist deshalb ausschließlich als Konformität der konfigurierten, vergleichbaren In-Scope-Einstellungen zu bezeichnen. Er ist kein Nachweis vollständiger Microsoft-Baseline-Umsetzung oder -Abdeckung. + +## Entscheidungsvertrag + +Jede berücksichtigte Vorlage wird für dieselbe aufgelöste technische Einstellung einschließlich Computer-/Benutzerbereich einzeln verglichen. Der neutrale Vergleich verwendet exakte, typisierte Gleichheit. Bei Kontenlisten ist die Reihenfolge unerheblich; Originalwerte bleiben erhalten. Registrytypen und die Reihenfolge von REG_MULTI_SZ bleiben relevant. Abweichend bedeutet hier nicht automatisch schwächer: Eine gesonderte fachliche Regel wäre nötig, um eine strengere Einstellung als zulässig zu behandeln. + +| Nachgewiesener Zustand | Ergebnis in Work | +| --- | --- | +| Konfiguriertes IST erfüllt jede berücksichtigte Variante | Pass | +| Konfiguriertes IST weicht von jeder berücksichtigten Variante ab | Fail / Filter Deviation | +| Einzelurteile widersprechen sich | Review required | +| Wertvergleich, Kandidatenabdeckung oder explizite Anwendbarkeit ist ungeklärt | Review required | +| Empfohlenes Setting besitzt im analysierten Backupsatz keinen beobachteten konfigurierten Wert | Not configured; score-neutral | +| Der analysierte Backupsatz ist nur ein ausgewählter Teilbestand | Not configured mit Scope-Diagnose; keine behauptete Abwesenheit in Domäne oder effektivem Gerätezustand | +| Für die technische Einstellung existiert überhaupt kein Baselinewert | Kein erfundener Pass-/Fail-Vergleich | + +### Verbindliche Registry-Zustandsregeln + +Registry.pol-Anweisungen sind Sollzustände und keine fehlenden Baselinewerte. Innerhalb des analysierten Backup-Sets gelten deshalb folgende Regeln; sie behaupten weiterhin keinen effektiven Registry-Zustand auf einem Gerät: + +| Baseline-Sollzustand | Zustand im analysierten Kunden-Backup | Urteil | +| --- | --- | --- | +| Einzelnen Wert löschen | Zielwert nicht konfiguriert oder ausdrücklich gelöscht | Pass | +| Einzelnen Wert löschen | Zielwert wird gesetzt | Fail | +| Alle Werte eines Schlüssels löschen | Kein Wert für das Schlüsselziel konfiguriert oder ausdrückliche Delete-all-Anweisung | Pass | +| Alle Werte eines Schlüssels löschen | Ein Wert für das Schlüsselziel wird gesetzt | Fail | +| Schlüssel anlegen | Schlüsselanlage ist konfiguriert | Pass | +| Schlüssel anlegen | Schlüsselanlage fehlt | Fail | +| Typisierten leeren Text setzen | Wert existiert mit identischem Registrytyp und Inhalt `""` | Pass | +| Typisierten leeren Text setzen | Wert fehlt, besitzt einen anderen Typ oder ist nicht leer | Fail | + +Ein leerer `REG_SZ`- oder `REG_EXPAND_SZ`-Inhalt ist damit ein expliziter Wert und niemals allein wegen seiner Länge „Baselinewert nicht verfügbar“. Delete-, Delete-all- und Create-key-Anweisungen erhalten einen typisierten Registry-Zustand (`absent`, `key-empty`, `key-present`) in der gespeicherten Vergleichsevidenz. Andere Sonderoperationen bleiben fail-closed `Review required`, bis ihre Semantik separat vereinbart und getestet ist. + +Einträge außerhalb der Vereinigung aller erlaubten Kontenlisten weichen zwangsläufig von jeder dieser Varianten ab. Die Vereinigung ist dennoch **kein neuer Sollwert**. Auch innerhalb der Vereinigung ist bei exaktem Vergleich ein Fail möglich, wenn keine einzelne Variante vollständig erfüllt wird. Ein Treffer bei nur einer von mehreren widersprüchlichen Varianten ist kein Gesamt-Pass. + +Eine fehlende oder unlesbare Variante neben vorhandenen Empfehlungen wird nicht herausgefiltert, um Einigkeit herzustellen. Strukturell unvollständige oder nicht erklärbar partielle Baselineanalysen blockieren das Gesamturteil. Partielle Diagnosen werden auf den betroffenen Bereitstellungsmechanismus begrenzt: Eine fehlerhafte Security-Template-Zeile blockiert keinen separat technisch aufgelösten Registry-Policy-Vergleich. Für eine Security-Template-Einstellung bleibt dieselbe Diagnose dagegen ein Blocker. Nicht unterstützte Sektionen besitzen keine vergleichbare Identität und bleiben als Abdeckungslücke am Lauf sichtbar, ohne einen unabhängigen aufgelösten Wert zu entwerten. Ausschließlich fehlende/mehrdeutige ADMX-Metadaten blockieren ebenfalls keine bereits technisch aufgelösten nativen Werte; die Diagnose bleibt erhalten. + +Dasselbe gilt für explizit bekannte, wertunabhängige Metadatenlücken der Baseline: fehlende Domäne, Backupzeit oder Zeitzone. Diese Angaben belegen keine Gerätezielrolle und verändern den gelesenen Sollwert nicht. Unbekannte Diagnosen, fehlerhafte Metadatenstruktur und Identitätskonflikte werden nicht pauschal freigegeben. + +Mehrere widersprüchliche Einträge derselben Einstellung innerhalb derselben Baseline-GPO sind keine unabhängigen Rollenvarianten. Ohne eindeutig reduzierte Empfehlung bleibt dieser Fall Review required, auch wenn das IST von sämtlichen Einzelwerten abweicht. + +Unterschiedliche Baselineempfehlungen sind kein Kunden-GPO-Konflikt. Die bestehende Kundenquellenprüfung für Conflicts und Duplicates wird durch diese Änderung nicht neu definiert. Ihr Nachweis behauptet ebenfalls keine effektive Anwendung. Review required bleibt in Work unter All sichtbar; das verbindliche GPO-Statusmenü bleibt unverändert bei All, Deviation, Passed, Not configured, Conflicts und Duplicates. Eine Risikoakzeptanz verändert dieses technische Urteil nicht. + +Die spätere Nutzerpräzisierung vom 2026-09-16 ersetzt ausschließlich die frühere Interpretation score-neutraler Conflict-/Duplicate-Container: Der Container ist seit Evaluator 1.7.0 ein Diagnosemerkmal, das Policy-Gesamturteil wird separat aufgerollt. Work speichert das Urteil im Status und Conflict/Duplicate zusätzlich in den eigenen Feldern; die Statusfilter lesen diese Achsen getrennt. Dadurch kann dieselbe Zeile sowohl `Deviation` als auch `Conflicts` beziehungsweise `Duplicates` erfüllen, ohne einen zweiten Scorebeitrag zu erzeugen. Historische Evaluationen werden nicht rückwirkend umgedeutet. + +## Nachweis und Historie + +Praezisierung 2026-09-18 (Work-Zeilen): Mehrere Baselinepakete fuer dieselbe technische Einstellung werden in Work zu genau einer Zeile je Projekt, Snapshotaggregation und Computer-/Benutzerbereich zusammengefasst. Diese Zeile verwendet dieselbe Urteilprioritaet wie die bestehenden Policy-Zaehler (Fail, Review required, Pass, Not configured). Die innerhalb eines Pakets gespeicherte Variantenentscheidung bleibt unveraendert; ein dort gemischter Vergleich bleibt Review required. Der Baselinefilter waehlt Mitgliedschaften dieser gemeinsamen Zeile und berechnet ihr Gesamturteil nicht aus der Filterauswahl neu. Einzelne Paketvergleiche, Settingreferenzen und unterschiedliche Sollwerte bleiben im Reader und in Result DB nachvollziehbar; es entsteht kein synthetischer gemeinsamer Sollwert. Quellen werden anhand ihrer exakten Beobachtungsidentitaet dedupliziert, rote Markierungen muessen gegen alle erhaltenen aktuellen Varianten belegt sein. Historische oder nicht verfuegbare Bewertungen erlauben keine solche Markierung. + +Bestehende lokale Notizen zu frueheren Baselinezeilen bleiben im Reader unter `Previous baseline-specific reviews` lesbar. Uebereinstimmende Notizen werden fuer die gemeinsame Work-Zeile uebernommen; unterschiedliche Notizen werden nicht willkuerlich vereinigt. Risikoakzeptanzen werden niemals automatisch auf die gemeinsame Zeile umgehaengt. Die Projektion benoetigt weder Reimport noch Neuauswertung; gespeicherte Vergleiche und Datenbankschema bleiben unveraendert. + +Jedes neue Ergebnis speichert `baselineVariantAssessment` Version 1 mit Prüfgrenze `backup-configuration`, unveränderten Kunden-/Baselinewerten, Baseline-Settingreferenzen, typisierten Einzelvergleichen, Blockierungsdiagnosen und Gesamtentscheidung. Ausgewählte Settingreferenzen und sämtliche Auswahlkandidaten bleiben getrennt; die vorhandenen Evidenzreferenzen führen zu Analyse, Datei-/Hash-/Zeilenherkunft und Kundenbeobachtungen. Die Schreibvalidierung prüft Referenzabdeckung und Konsistenz von Einzelurteilen, Gesamturteil und Klassifikation. + +Ein einzelner aggregierter Baselinewert wird nur bei tatsächlich gemeinsamem Quellwert ausgegeben. Bei unterschiedlichen Werten zeigen Work, Result DB und der JSONL-Export die Einzelvarianten. Empfehlungen kombinieren niemals die Alternativen; vor einer konkreten Änderung muss die passende Vorlage feststehen. + +Evaluator 1.5.0 ersetzte die pauschale Sperre aus 1.4.0 bei unterschiedlichen Baselinewerten. Evaluator 1.6.0 begrenzt globale Parserdiagnosen auf den tatsächlich betroffenen Bereitstellungsmechanismus. Evaluator 1.7.0 vergleicht die erhaltenen Mitgliedswerte eines Kundenkonflikts einzeln und rollt einen nachgewiesenen Fail auf die technische Policy-Einstellung hoch. Evaluator 1.8.0 hält gewöhnliche fehlende Empfehlungen auch in einem ausgewählten analysierten Backupsatz als `Not configured` filterbar und markiert die begrenzte Aussage mit `policy-evaluation-customer-absence-scope-limited`; eine Domänen- oder Geräteabwesenheit wird nicht behauptet. Evaluator 1.9.0 behandelt die oben vereinbarten Delete-, Delete-all-, Create-key- und typisierten Leerwert-Sollzustände als vergleichbare Baselineevidenz. Alte Läufe werden nicht umgeschrieben. 1.3.3 bis 1.8.0 bleiben historisch lesbar; die aktuelle Version hat Vorrang. Data Hub fordert über den bestehenden Versionsvergleich eine explizite Re-evaluation der erhaltenen Eingaben an. Kein Scanner-Reimport, erneuter Upload oder SQL-Schemawechsel allein wegen dieses Bewertungswechsels; fehlende/unlesbare Ursprungsevidenz bleibt gesondert zu klären. + +## Verifikation und Grenzen + +Synthetische Regressionen prüfen zusätzliche und fehlende Konten, Treffer nur einer Variante, Übereinstimmung aller Varianten, vertauschte Kontenreihenfolge, Typunterschiede, unbekannte/fehlende/unlesbare Varianten, explizite und inventarbasierte Kontexte, fehlende Einstellungen bei vollständiger und partieller Erfassung, die vier Registry-Zustandsregeln einschließlich ihrer Work-Urteile, unveränderte Eingaben, serialisierte Evidenz, Schreibvalidierung, historische Versionsauswahl sowie Work-Filter, Guidance und gerenderte Result-DB-Details. Historische Kundendaten werden nicht automatisch neu bewertet. Die Standardprüfung ersetzt keine freigegebene Integration gegen den kanonischen PostgreSQL-Bestand und keinen RSoP-/GP-Results-Nachweis. diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md index 65dcec1..d19d2a5 100644 --- a/docs/IMPLEMENTATION_PLAN.md +++ b/docs/IMPLEMENTATION_PLAN.md @@ -1,6 +1,450 @@ # ASSESSOR – Umsetzungsplan Status: lebendes Projektdokument + +ISO-Korpus-Upload 2026-09-23 (Phase 13D, Nutzerauftrag): Data Hub nimmt die passenden DIN-27001-/27002-PDFs gemeinsam ueber eine token-geschuetzte Same-Origin-API an. Der vorhandene PDF-Parser laeuft in einem begrenzten Worker; der private versionierte JSON-Korpus bleibt als Wiederaufbauquelle im Artefakt-Volume, temporaere Original-PDFs werden nach dem Parsing und nach unterbrochenen Starts entfernt. Ein Hintergrundjob zeigt Parse-/Embedding-/Aktivierungsstatus und Chunkfortschritt; die Statusabfrage erkennt einen unvollstaendigen oder unerreichbaren Index. Qdrant-Ersatz ist nun auf die Korpusversion begrenzt; erst nach vollstaendigem Ingest wechselt die aktive Mappingversion, bei einer neuen fehlgeschlagenen Version bleibt die bisherige aktiv. Ein identischer Upload kann einen verlorenen Index anhand der erwarteten Chunkzahl neu aufbauen. Der Operator-Token ist eine Uebergangsberechtigung bis Phase 14 und schuetzt ausschliesslich diese globale Aktion. Der Nutzer hat Speicherung der privaten Korpusquelle und den konfigurierten Embedding-Endpunkt fuer diesen lizenzierten Inhalt bestaetigt. Vor der letzten Statuspraezisierung bestand der Standardlauf mit 1.584 Tests und 16 uebersprungenen opt-in Integrationen; danach bestanden die vier fokussierten HTTP-/UI-/Client-/Indexdateien mit 29 Tests sowie beide Typechecks. Beide Builds und Local-only-/Designchecks bestanden vor der Statuspraezisierung. Keine PostgreSQL-Migration oder Scanner-Reimport; die echte PDF-/Provider-/Qdrant-Abnahme auf dem Zielserver bleibt offen. Phase 13D bleibt in Arbeit. + +Review remediation 2026-09-23 (Phase 7 and Phase 13D, verified): Defender device-risk projection now preserves the exact source-occurrence/device relationship when separate occurrences in one run share a CVE; a synthetic repository acceptance test rejects a device absent from the selected occurrence. Saved regulatory mappings remain readable when the retrieval index is unavailable. A failed AI Overview regeneration reports the failed attempt while displaying the last successful overview. Existing risk decisions, scanner data, scoring, mapping decisions and database schema are unchanged; no reimport or migration is required. The remaining historical risk is that a previously recorded device-finding acceptance from a same-CVE multi-occurrence run may contain incorrect captured provenance and requires review before reliance. Focused tests pass 22/22 plus repository acceptance 16/16; the full standard suite passes 1,576 tests with 16 opt-in tests skipped, both production builds and typechecks pass, and local-only/design checks pass. Phases 7 and 13D remain in progress. + +Defender-device-scoped risk acceptance 2026-09-21 (Phases 7 and 9-11 extension with Phase 13 validation, explicit user request): Existing whole-finding acceptance remains unchanged. Work can record one CVE for one exact Defender device; Defender Device view can record one immutable snapshot of every detailed actionable CVE in the selected active scan-run scope. The shared platform-neutral projection uses the existing Defender identity model, rejects unresolved or ambiguous identities, retains canonical definition/CVE and exact occurrence provenance, and carries coverage forward only for the same project, exact device key and captured definition. Independent whole-finding, device-finding and device-snapshot decisions overlap without revoking each other. Migration 028, repository/API parity, project export/load, optimistic revision checks and the Accepted Risks register are implemented. The canonical PostgreSQL datastore was backed up and verified before migration; 028 is recorded and a synthetic PostgreSQL accept/conflict/revoke/export/cascade test passed with cleanup. Verification: 287 files and 1,567 tests passed with six files and 16 opt-in tests skipped; client/server TypeScript checks, local-only and design-language checks, both production builds and the dedicated canonical PostgreSQL integration passed. Phase 14 authentication, authorization, signing, evidence verification and retention remain explicitly unclaimed. + +Wiederholbarer ISO-Mappingvergleich 2026-09-18 (Phase 13D, ausdruecklicher Nutzerauftrag): Ein read-only Evaluationsskript vergleicht abgeschlossene PostgreSQL-Mappinglaeufe fuer PingCastle und Purple Knight mit einer versionierten manuellen Baseline und erzeugt eine reviewfaehige Excel-Datei mit Summary, Findingvergleich, Beziehungsdetails und Methodik. Ohne Parameter erkennt es die aktuelle Retrievalversion aus dem Produktivcode und waehlt die neueste vorherige Version mit vollstaendiger Scannerabdeckung; unvollstaendige neue Laeufe stoppen explizit. Die Baseline enthaelt ausschliesslich oeffentliche Rule-IDs und manuell bewertete Controlrollen, erlaubt null Primaercontrol und ist bewusst Evaluationsmaterial statt CI-Sollvertrag oder Produktmapping. Dauerhafte Tests verwenden nur synthetische Kontrollkennungen und pruefen Validierung, Retrieval-/Auswahl-/Rollen-/Extra-Trennung sowie Aenderungsklassifikation. Der erzeugte Smoke-Workbook bestand Import, Strukturscan, Formelpruefung und visuelle Kontrolle aller vier Blaetter. Beide Produktionsbuilds erfolgreich; der fokussierte neue Test besteht 3/3. Der Gesamtlauf erreicht 1.331 bestandene Tests und zehn opt-in-Skips, wird aber reproduzierbar durch den fachfremden vorhandenen 5-Sekunden-Timeout in `sheet-selection-cost.test.tsx` beendet; derselbe Test besteht isoliert in 0,9 Sekunden. Keine PostgreSQL-/Qdrant-Mutation, keine Mappingannahme, kein Manifestbump und kein Reimport. + +ISO-Full-Context-Familienfusion 2026-09-18 (Phase 13D, ausdruecklicher Nutzerauftrag): Die bestehende Finding-only Querygrenze bleibt unveraendert. Die mit vollstaendigem Findingtext ausgefuehrten `control`-, `purpose`- und `guidance`-Suchen werden jetzt zunaechst zu genau einer Control-Rangliste fusioniert; diese Full-Context-Familie stimmt anschliessend neben Problem- und optionaler Remediationrangliste in der finalen Control-RRF ab. Damit koennen Abschnittstreffer wieder Controls in die Zwolf-Control-Shortlist einbringen, ohne drei korrelierte Schlussstimmen zu erhalten. Retrievalversion `hybrid-finding-query-section-family-rrf-1.6.0` erzeugt append-only neue Mapping-IDs; Queryschema 4, Prompt 1.5.0, vollstaendige Kandidatenbewertung, deterministische Auswahl, Human Review und fehlender produktiver Reranker bleiben unveraendert. Synthetische Mechanikregressionen pruefen Eintritt eines Abschnittstreffers und die einzelne Familienstimme, aber keine versionsabhaengigen ISO-Sollzuordnungen. 1.329 Tests bestanden, zehn opt-in Integrationen uebersprungen; beide Typechecks, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Die reale Recall-/Praezisionswirkung bleibt durch einen neuen manuellen PingCastle-/Purple-Knight-Lauf zu bewerten. Keine PostgreSQL-/Qdrant-Mutation, keine Scannerverarbeitung, kein Manifestbump und kein Reimport. + +ISO-Finding-only-Retrieval 2026-09-18 (Phase 13D, ausdruecklicher Nutzerauftrag): Regulatory Queryschema 4 erzeugt ausschliesslich aus datenschutzsicherem Findingtitel, Beschreibung und Empfehlung eine Problemquery und optional eine Remediationquery; Scannername, Rule-ID, Regelkatalog und `public-security-topics.ts` beeinflussen weder Retrieval noch Mapperkontext. Die Themenliste bleibt nur im getrennten Public-Web-Search-Feature. Dense und BM25 werden je Query per Control-ID statt Chunk-ID fusioniert, sodass jedes Control pro Rangliste genau eine Stimme besitzt; rohe, zwischen Dense und Sparse nicht vergleichbare Scores entscheiden keine Gleichstaende mehr. Eine zweite Control-RRF waehlt hoechstens zwoelf Controls. Getrennte `control`-, `purpose`- und `guidance`-Suchen liefern danach nur Evidenz fuer bereits ausgewaehlte Controls und koennen weder Kandidaten hinzufuegen noch Stimmen vervielfachen. Retrievalversion `hybrid-finding-query-control-rrf-1.5.0` erzeugt append-only neue Mapping-IDs. Der produktive Runtimepfad aktiviert keinen Reranker; seine bestehende Schnittstelle bleibt nur als spaetere Erweiterungsgrenze. 1.328 Tests bestanden, zehn opt-in Integrationen uebersprungen; beide Typechecks, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine PostgreSQL-/Qdrant-Mutation, keine Scannerverarbeitung, kein Manifestbump und kein Reimport. + +ISO-Retrievaltests entkoppelt 2026-09-18 (Phase 13D, ausdrueckliche Nutzerkorrektur): Der eingecheckte PingCastle-Gap-Satz mit fest erwarteten ISO-Control-IDs und Topics wurde entfernt. Regulatorische Fassungen, fachliche Bewertungen und Retrievalergebnisse bleiben bewusst ausserhalb der verpflichtenden Testsuite und werden bei Bedarf ueber den manuellen Review-/Excelvergleich oder eine explizit gestartete Evaluation bewertet. Dauerhafte Tests pruefen nur synthetische, regulationsunabhaengige Mechanik wie Privacy-Grenze, Rankingfusion, Deduplizierung, Shortlistlimit, Vollstaendigkeit der Kandidatenbewertung und deterministische Auswahl. Dadurch kann eine neue Regulatory-Fassung die CI nicht allein wegen geaenderter Sollzuordnungen brechen. 1.327 Tests bestanden, zehn opt-in Integrationen wurden uebersprungen; beide Typechecks, Local-only- und Designpruefung sind erfolgreich. Produktivcode, Pipelineversionen, PostgreSQL und Qdrant blieben unveraendert. + +ISO-Hybridretrieval und Kandidatenbewertung 2026-09-18 (Phase 13D, ausdruecklicher Nutzerauftrag): Der Mappingpfad bewertet jetzt alle zwoelf gelieferten Controls einzeln als `primary`, `supporting` oder `irrelevant`; fehlende, doppelte, unbekannte oder nicht evidenzgebundene Bewertungen scheitern geschlossen. Ein deterministischer Reducer waehlt danach hoechstens ein Primaercontrol und drei Sekundaercontrols, erlaubt weiterhin Sekundaer-only und leitet `no_relevant_control` ausschliesslich aus vollstaendig irrelevanten Bewertungen ab. Promptversion 1.5.0 und Retrievalversion `hybrid-generic-reserved-section-rrf-1.4.0` erzeugen append-only neue Mapping-IDs; Persistenz-, Review- und UI-Vertraege bleiben unveraendert. Die Ingestion erzeugt zusaetzlich werkzeugunabhaengige gehashte BM25-Sparse-Vektoren aus Kontrolltitel und -text; der Candidate-Retriever vereinigt Dense- und Sparse-Rankings per RRF, bevor die vorhandene generische Reservierung und Abschnittsfusion die Zwolf-Control-Shortlist bilden. Der bestehende Qdrant-Korpus muss einmal aus der unveraenderten Korpusquelle neu ingestiert werden, damit Bestands-Punkte Sparse-Vektoren erhalten; Dense bleibt bis dahin funktionsfaehig. Der Aktivierungsversuch stoppte vor Qdrant-Aenderungen, weil der konfigurierte lokale Embeddingdienst nicht lief. 1.338 Tests bestanden, zehn opt-in Integrationen wurden uebersprungen; beide Typechecks, Produktionsbuild sowie Local-only- und Designpruefung sind erfolgreich. Keine PostgreSQL-Mutation, kein Scanner-Importvertrag, kein Manifestbump und kein Reimport. + +ISO-Mapping-Promptbalance 2026-09-17 (Phase 13D, ausdruecklicher Nutzerauftrag): Der Vergleich des vollstaendigen v1.3-Laufs bestaetigt den Retrievalgewinn (`69/78` erwartete Controls in der Shortlist), aber auch eine Ueberkorrektur des Prompts: nur `6/40` erwartete Sekundaerbeziehungen wurden ausgegeben, obwohl 30 fehlende Sollbeziehungen als Kandidaten vorlagen. Prompt 1.4.0 erlaubt deshalb ausdruecklich null oder ein Primaercontrol und null bis drei Sekundaercontrols. Ein Mapping ohne Primaercontrol ist gueltig, wenn relevante Controls materiell beitragen, aber keines eindeutig dominiert; `no_relevant_control` bleibt dem Fall ohne relevante Kandidaten vorbehalten. Materiell unterschiedliche Sekundaerbeziehungen duerfen nicht allein zur Verkuerzung entfallen, generische Wortnaehe bleibt ausgeschlossen. Retrieval v1.3, Zwolf-Control-Shortlist, Hardlimit von fuenf, Human Review und Persistenzvertrag bleiben unveraendert. Neue Runs erhalten append-only eine neue Mapping-ID. Client-/Server-Typecheck, Local-only- und Designpruefung erfolgreich; der fokussierte Vitest-Start bleibt an der bekannten Sandbox-Verweigerung fuer das uebergeordnete Verzeichnis blockiert. Keine Datenbankmutation, kein Reimport und keine automatische Entscheidung. + +ISO-Retrieval-Gesamtregression und Korrektur 2026-09-17 (Phase 13D, ausdruecklicher Nutzerauftrag): Der Abgleich aller 37 PingCastle-Findings gegen die unabhaengig erfassten 78 Primaer-/Sekundaerbeziehungen zeigte, dass die unmittelbar vorherige topic-zentrierte v1.2-Nachhaertung zwar die gezielten Luecken schloss, den Gesamt-Recall@12 aber von `61/78` auf `54/78` verschlechterte. Retrieval v1.3 schuetzt deshalb fuenf Controls aus einer werkzeugneutralen breiten Suche ueber Titel, Beschreibung und Empfehlung; eine optionale Topic-Query fuellt zusammen mit breiten sowie `control`-, `purpose`- und `guidance`-Rankings per RRF die restlichen sieben Plaetze. `public-security-topics.ts` ist damit nur Booster und keine Voraussetzung fuer neue Scanner. Der read-only BGE-M3-/Qdrant-Abgleich erreicht `68/78` (`87,2 %`; Primaer `33/38`, Sekundaer `35/40`) und liegt nahe am ausdruecklichen ungefaehren 90-%-Ziel mit Human Review. Queryschema 3, Retrievalversion `dense-generic-reserved-section-rrf-1.3.0` und Promptversion 1.3.0 erzeugen append-only neue Mapping-IDs; Accept/Reject bleibt autoritativ, keine Entscheidung wurde automatisch uebernommen. Client- und Server-Typecheck, Local-only- und Designpruefung sind erfolgreich. Der fokussierte Vitest-Lauf und der Vite-Build konnten in der Workspace-Sandbox wegen verweigertem Zugriff auf das uebergeordnete Verzeichnis nicht gestartet werden; eine Ausfuehrung ausserhalb der Sandbox war wegen erschoepftem Host-Freigabekontingent nicht moeglich. Keine Datenbankmutation, kein Importvertrag, kein Manifestbump und kein Reimport. + +ISO-Retrieval-Nachhaertung 2026-09-17 (Phase 13D, ausdruecklicher Nutzerauftrag): Der Embeddingpfad verwendet jetzt eine von der vollstaendigen Modellkontextquery getrennte, kurze Public-Signal-Query aus bereinigtem Findingtitel und kuratierten oeffentlichen Sicherheitskonzepten. ISO-27002-`control`- und `purpose`-Abschnitte werden mit BGE-M3 getrennt durchsucht, auf Control-Ebene per deterministischem Reciprocal Rank Fusion (`k=60`) vereinigt und zunaechst auf 24 Controls begrenzt; das Mappingmodell erhaelt daraus hoechstens zwoelf Controls und darf weiterhin maximal fuenf evidenzgebundene Beziehungen ausgeben. `REGULATORY_FINDING_QUERY_SCHEMA_VERSION` ist 2, `REGULATORY_RETRIEVAL_VERSION` ist `dense-section-rrf-control-grouping-1.2.0`; alte Runs bleiben unveraendert und neue Vorschlaege erhalten eine neue deterministische Mapping-ID. Ein eingecheckter oeffentlicher PingCastle-Gap-Vertrag umfasst zehn Regeln und 17 unabhaengig zuvor validierte Sollbeziehungen. Der produktiv gebaute lokale BGE-M3-/Qdrant-Pfad erreichte fuer diesen begrenzten Satz Recall@12 1,0; dies behebt die beobachteten Retrievalluecken, ersetzt aber keinen unabhaengig gelabelten repraesentativen EN/DE-Gesamtdatensatz. 1.329 Standardtests bestanden, zehn optionale Integrationen wurden uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Datenbankmutation, kein Importvertrag, kein Manifestbump und kein Reimport. + +Gefiltertes Result-DB-ISO-Batchmapping 2026-09-16 (Phase 13D, ausdruecklicher Nutzerauftrag): Result DB bietet `Map all ISO controls` neben Refresh und Export JSON. Export und Batch leiten ihren Scope aus demselben normalisierten `UnifiedResultQuery` ab; der gewaehlte Timeslot bleibt aeussere Grenze, alle aktiven Filter einschliesslich des Standardfilters `deviation: true` grenzen weiter ein, und Pagination/geladene Zeilen haben keinen Einfluss. Der Server liest stabil alle Treffer, bricht bei veraenderter Gesamtzahl sicher ab, zaehlt Nicht-Scanner und nicht unterstuetzte Findings getrennt, dedupliziert global nach `ruleKey`, verwendet erfolgreiche/aktive Mappings wieder und plant fehlende beziehungsweise zuvor fehlgeschlagene Regeln ueber dieselbe auf zwei parallele Retrieval-/Modellpipelines begrenzte Queue wie Einzelaktionen. Atomare deterministische Claims verhindern doppelte Modellaufrufe. Migration 027 speichert nur den projektgebundenen normalisierten Filter-/Timeslot-Snapshot, Hash, Idempotenz, Status und Aggregatfortschritt; globale Mappingzeilen bleiben autoritativ. Das Dialogfenster zeigt Treffer und Fortschritt, bindet laufende Batches an den beim Start erfassten Filterstand und erzeugt ausschliesslich Vorschlaege; Accept/Reject bleibt manuell in Work. Filterwerte, Occurrence-Assets, Pfade, Mandanten- und Reviewdaten gelangen nicht in Retrieval oder LiteLLM. Die fruehere Batch-Zurueckstellung ist fuer diesen manuellen gefilterten Lauf ausdruecklich aufgehoben; die repraesentative Retrievalbewertung bleibt offenes Qualitaetsrisiko. Keine Scannerverarbeitung, kein Manifestbump und kein Reimport. Verifikation: `npm test` mit 1.315 bestandenen Tests und zehn uebersprungenen opt-in Integrationen, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich (bestehender Bundlehinweis). Der synthetische regulatorische End-to-End-Integrationstest blieb ohne aktivierte lokale Abhaengigkeiten uebersprungen. Korrektur nach Anwendung von Migration 027: Eine nachtraeglich in dieselbe Datei aufgenommene reine Sortiersequenz verletzte die Migrationsimmutabilitaet und der Checksum-Schutz stoppte das Backend korrekt. 027 ist exakt auf den angewandten Stand ohne Sortiersequenz zurueckgesetzt und durch eine feste SHA-256-Regression (`d89055c3e723b09d8d8be7f4225bfd08442f0d66e4e0b4ea3aa62ae6209e9ee9`) geschuetzt; Repositoryabfragen verwenden wieder den bereits angelegten stabilen `created_at, id`-Index. Es gibt keine Migration 028 und keine neue Datenbankmutation. Nach freigegebenem WSL-Neustart wurden der gesunde kanonische Container, Port `127.0.0.1:5432`, Volume `assessor-2_0_assessor-postgres-data`, der identische Ledger-Checksum und das Fehlen von 028 read-only bestaetigt; der automatisch neu gestartete Backendprozess meldet HTTP 200 und `persistence=postgresql`. Kein Backup war fuer die Korrektur erforderlich, weil keine neue Migration ausgefuehrt wurde. + +ISO-27002-Mapping-Vertikalschnitt 2026-09-15 (Phase 13D, ausdruecklicher Nutzerauftrag): Die beiden lokal lizenzierten deutschen DIN-2024-PDFs werden serverseitig mit PDF.js und Positionsdaten in einen nicht eingecheckten Korpus-v2 ueberfuehrt. Passwortpflichtige, kopiergeschuetzte, textlose, uebergrosse oder strukturell unvollstaendige Dokumente scheitern geschlossen; ISO 27001 und 27002 muessen dieselben 93 Kontrollen mit 37/8/14/34 Themenkontrollen liefern. `assessor_regulatory_chunks_v2` enthaelt 705 mit lokalem BGE-M3 erzeugte, abschnitts- und kontrollsichere Chunks aus 558 Dokumenten, einschliesslich ISO-27001-Referenzen, Seiten-, Editions-, Parser- und Hashprovenienz; Sparse bleibt reserviert. Der Einzel-Finding-Dienst gruppiert 32 Dense-Treffer auf acht Kontrollen, bindet ISO-27001-Evidenz an, uebergibt nur die minimierte Public-Signal-Query und hoechstens 48.000 Zeichen ISO-Evidenz an das vorhandene Work-LiteLLM und akzeptiert ausschliesslich lokal validierte, evidenzgebundene JSON-Vorschlaege. Migration 025, beide Repositories und drei projektgebundene APIs speichern Runs und Accept/Reject-Entscheidungsereignisse append-only; Work zeigt den manuellen Ablauf inline mit Polling und Seitenbelegen. Ein realer synthetischer End-to-End-Test ueber kanonisches PostgreSQL, llama.cpp/BGE-M3, Qdrant und den freigegebenen LiteLLM-Gateway bestand einschliesslich Optimistic-Conflict und Cascade-Cleanup. Der laufende Entwicklungsserver wendete die additive Migration um 13:42 vor dem um 13:52 erstellten und verifizierten Backup automatisch an; beide neuen Tabellen waren leer. Diese Abweichung ist offen dokumentiert und wird nicht als Vorabbackup ausgegeben. Scannerverarbeitung blieb unveraendert; kein Manifestbump oder Reimport. + +Regulatory-RAG-Llama-Livebaseline 2026-09-15 (Phase 13D, Nutzerstart): Der lokal gestartete llama.cpp-Server Build 10472 meldet Health 200 und bedient BGE-M3 FP16 ueber den OpenAI-kompatiblen Endpoint. Die produktiv gebauten CLIs indexierten den eingecheckten ausschliesslich synthetischen EN/DE-Korpus mit sechs Dokumenten als sechs 1.024-dimensionale Chunks in den kanonischen Qdrant 1.19.1. Drei ausdruecklich sprachuebergreifende Smoke-Cases erreichten bei K=3 HitRate 1,0, Recall 1,0 und MRR 1,0; alle erwarteten Kontrollen standen auf Rang 1. Das belegt End-to-End-Verkabelung und grundlegende Sprachueberquerung, wegen nur drei klar getrennten Kontrollthemen aber keine produktive Retrievalqualitaet. Qdrant enthaelt sechs synthetische Punkte; PostgreSQL und Realdaten wurden nicht beruehrt. 1.285 Standardtests bestanden, acht optionale PostgreSQL- und ein optionaler Qdrant-Test uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich (bestehender Bundlehinweis). Ein repraesentativer autorisierter Korpus und unabhaengig gelabelter EN/DE-Satz bleiben fuer die reale Baseline erforderlich. + +Regulatory-RAG-Local-Embeddings 2026-09-15 (Phase 13D, Nutzerentscheidung): Die autorisierte Legacy-Collection `regulation_catalog_v1` wurde nach exakter Ein-Collection-Pruefung geloescht; der leere alte Qdrant-1.12.4-Container wurde entfernt, sein bisheriges Volume jedoch bewahrt. Der authentifizierte `assessor-2_0-qdrant-1` mit Qdrant 1.19.1 laeuft nun am kanonischen `127.0.0.1:6333`; Auth 401/200, gruene Collection und null Punkte sind bestaetigt. Fuer die lokale Dense-Entwicklung ist BGE-M3 mit llama.cpp festgelegt: multilingual, native 1.024 Dimensionen und damit passend zur Collection. Der Embeddingadapter erlaubt HTTP nur fuer Loopback, verlangt weiterhin einen Bearer-Key und lehnt Remote-HTTP ab. Ein neuer optionaler Request-Dimensionsschalter bleibt fuer einen spaeteren LiteLLM-Vergleich mit `text-embedding-3-large` standardmaessig aus, weil llama.cpp die native Modelldimension liefert. Das installierte llama.cpp Build 10472 ist vorhanden; ein BGE-M3-GGUF beziehungsweise dessen freigegebener Download und Serverstart fehlen noch. 1.285 Standardtests bestanden; acht optionale PostgreSQL- und ein optionaler Qdrant-Test uebersprungen, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich (bestehender Bundlehinweis). Keine PostgreSQL-Mutation, keine Realdateninspektion und kein Reimport. + +Regulatory-RAG-WSL-Liveabnahme 2026-09-15 (Phase 13D, Nutzerkorrektur): Docker Engine 29.7.2 und Compose 5.5.0 sind in WSL2/Ubuntu erreichbar. Der kanonische Container `assessor-2_0-postgres-1` ist gesund und bindet unveraendert `127.0.0.1:5432` mit dem kanonischen externen Volume; PostgreSQL wurde nicht gelesen oder mutiert. Da ein veralteter, unauthentifizierter Qdrant 1.12.4 aus dem separaten Compose-Projekt `assessor` Port 6333 und das nichtleere Collection-Label `regulation_catalog_v1` belegt, wurde er nicht gestoppt oder veraendert. Der neue authentifizierte `assessor-2_0-qdrant-1` mit Qdrant 1.19.1 wurde fuer die Abnahme auf Loopback-Port 6334 und dem getrennten rebuildbaren Volume gestartet. Ohne Key antwortet er 401, mit Key 200. Ein opt-in Produktioncode-Integrationstest erstellte die gruene Collection `assessor_regulatory_chunks_v1` mit Dense 1.024/Cosine, Sparse-Slot, neun Payloadindizes und einem synthetischen Punkt und pruefte Replace, Filter und Retrieval erfolgreich; sein reservierter synthetischer Korpus wurde danach geloescht und die Collection enthaelt wieder null Punkte. Der reale Ingestion-CLI-Lauf stoppte vor Provideraufruf und Qdrantmutation, weil die konfigurierte loopback-HTTP-Embedding-URL die verpflichtende HTTPS-Pruefung nicht besteht und lokal nicht erreichbar ist. 1.284 Standardtests bestanden; acht optionale PostgreSQL- und ein optionaler Qdrant-Test wurden im Standardlauf uebersprungen, der Qdrant-Test separat 1/1 bestanden. Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich (bestehender Bundlehinweis). Kein Realdatenzugriff, keine PostgreSQL-Mutation und kein Reimport. + +Regulatory-RAG-Finding-Retrieval 2026-09-15 (Phase 13D, ausdruecklicher Nutzerauftrag): Die bestehende `UnifiedResultProjection` ist ueber eine backendinterne fail-closed Grenze an den `RegulatoryRetriever` angebunden. Nur katalogeigene oeffentliche Maester-/PingCastle-Regel-IDs, fest definierte oeffentliche Technikthemen und bekannte oeffentliche Toolnamen gelangen in die Embeddingquery; Rohtexte werden ausschliesslich lokal zur Themenklassifikation gelesen, waehrend Titel, Beschreibung, Empfehlung, Assets, Pfade, Mandanten-/Projekt-/Review- und Provenienzdaten nicht kopiert werden. Ohne oeffentliches Signal findet kein Retrieval statt. Ein begrenzter versionierter EN/DE-Evaluationsvertrag und `rag:evaluate` messen HitRate@K, Recall@K und MRR auf Kontrollebene und geben nur Aggregatmetriken aus. 1.283 synthetische Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich (bestehender Bundlehinweis). Kein API-/UI-Pfad, keine Datenbankmutation, keine automatische Mappingbehauptung und kein Reimport. Organisatorische Datenschutzfreigabe, autorisierter Korpus und reale Dense-Baseline bleiben offen. + +Regulatory-RAG-Grundlage 2026-09-15 (Phase 13D, ausdruecklicher Nutzerauftrag): PostgreSQL bleibt alleinige fachliche Quelle fuer Mandanten, Assessments, Scans, Findings, Ergebnisse und Reviews. Qdrant 1.19.1 ist als authentifizierter, rebuildbarer regulatorischer Suchindex in lokale und Deployment-Compose-Stacks aufgenommen. Ein versionierter plattformneutraler Chunkvertrag, deterministische Kontrolltextsegmentierung, ein abgesicherter OpenAI-kompatibler Adapter fuer ein explizit konfiguriertes mehrsprachiges Embeddingmodell, Qdrant-Collection-/Payload-Indexverwaltung, dichte gefilterte Suche, ein CLI-Ingestionpfad und getrennte Candidate-/Reranker-Schnittstellen bilden den minimalen Vertikalschnitt. Die Sparse-Vektorposition ist fuer spaetere Hybridabfrage reserviert, wird aber noch nicht als implementierte BM25-/Sparse-Suche ausgegeben. Finding-Query-Builder, automatische Zuordnung, LLM-Klassifikation, Confidence-Kalibrierung, Nutzeroberflaeche und persistierte Mappingprovenienz bleiben offen. 1.275 synthetische Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich (bestehender Bundlehinweis). Docker ist auf diesem Host nicht installiert; deshalb keine Compose-Livevalidierung, kein Qdrant-Start und kein echter Embedding-/Korpuslauf. Keine Scanner-, PostgreSQL- oder Realdatenmutation und kein Reimport. + +Work-LiteLLM-AI-Overview 2026-09-14 (Phasen 7/13C mit Phase 11, ausdruecklicher Nutzerauftrag): Client Info besitzt eine eigene `AI Overview`-Registerkarte fuer normale, gemischte und reine Defender-Timeslots. Eine explizite Generate-/Regenerate-Aktion liest den gesamten aktiven Timeslot ohne Source- oder Darstellungsfilter, verwendet unveraendert den versionierten `resultsToPrivacySafeExportJson`-Vertrag, bildet daraus einen kanonisch sortierten SHA-256-Input und uebergibt ausschliesslich diesen datensparsamen Inhalt serverseitig an das konfigurierte Work-LiteLLM. HTTPS-Pflicht, fest konfigurierte Ziel-URL, Redirectablehnung, Bearer-Secret nur im Backend, Timeout, Antwortgroesse, objektgrenzenbasierte hierarchische Chunks, maximal 64 Aufrufe und lokale Schema-/Quell-ID-Pruefung begrenzen die externe Verarbeitung. Migration 024 und beide Repository-Implementierungen speichern append-only Runs mit eindeutiger Timeslot-Idempotenz, Lifecycle, Lease, Versions-/Hash-/Modellmetadaten und ausschliesslich dem validierten Endergebnis; Browser, Export und Logs erhalten weder API-Key noch Providerantworten oder Zwischenprompts. Gespeicherte Ergebnisse bleiben bei deaktivierter Generierung lesbar und werden bei Input-, Modell-, Prompt- oder Schemadrift als veraltet markiert. AI-Ausgaben sind rein beratend und veraendern keine Scores, Findings, Reviews, Imports oder Accepted-Risk-Daten. 1.262 synthetische Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich (bestehender Bundlehinweis). Die lokale Secretdatei enthaelt Modus, HTTPS-Work-URL, Modell und Key; ein minimaler synthetischer Workstation-Request erreichte den Gateway, wurde jedoch mit HTTP 401 abgewiesen, ohne den Providerbody auszulesen oder auszugeben. Docker ist auf diesem Ausfuehrungshost nicht verfuegbar; daher wurden weder kanonisches PostgreSQL-Backup noch Anwendung von Migration 024 oder PostgreSQL-Integration ausgefuehrt. Credentialfreigabe, erfolgreicher synthetischer Workstation-/Server-Liveaufruf und Migration bleiben Betriebsabnahme. Keine Realdateninspektion und kein Reimport erforderlich; Phasenstatus unveraendert. + +Defender-Mock-CVE-Kontext 2026-09-14 (Phase 6/13A mit Phase-7-Projektion, Nutzerkorrektur): Die synthetische `ot-sensor/data-mining/cves.csv` enthaelt jetzt je CVE-Zeile die ueber `Device ID` konsistent aus dem Mock-Inventar uebernommenen Felder `Site` und `Sensor`. Dadurch zeigt die CVE-Ansicht `Riverbend Plant` und `SENS-RB-01` auch dann, wenn nur die CVE-Datei importiert wird; der vorhandene Inventarjoin bleibt fuer gemeinsame Mehrdateiimporte erhalten. Beide Spalten sind in `schema_metadata.csv` ausdruecklich als simulierte Fixture-Felder gekennzeichnet, Spaltenzahl und SHA-256 im Pack-Manifest wurden aktualisiert und der Validierungsbericht prueft den Join. Der Parser konnte beide Felder bereits verlustfrei lesen, daher keine neue Profil-/Extractorversion und keine Reimportregel fuer echte Scannerberichte. Verifikation ausschliesslich synthetisch: alle 19 Mock-CSVs stimmen in Zeilen-, Spalten-, Schema- und Hashangaben mit dem Manifest ueberein; fuenf CVE-Kontexte stimmen mit dem Inventar ueberein; Artifact-Tool-Inspektion ohne Fehlerfund; 1.245 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Realdateninspektion, Datenbankmutation, Migration oder Backendneustart; Phasenstatus unveraendert. + +Defender-Mock-CSV-Import 2026-09-11 (Phase 6/13A mit Phase-7-Projektion, Nutzerauftrag): Da der bearbeitete Defender-Excelbericht nicht mehr als Rohquelle verwendbar ist, verarbeitet das Defender-Profil 1.2.0 vorlaeufig die synthetischen `Mock-Defender`-Dateien `cves.csv` und `device_inventory.csv` ueber den bestehenden generischen CSV-Adapter. CVE- und Inventarzeilen werden nur ueber die explizite `Device ID` verbunden; Site und Sensor stammen nur aus vorhandenen Inventarfeldern, fehlende Beschreibungen bleiben leer. `CVSS Score`, `Component` und der Mock-Workflowstatus bleiben unveraenderte Evidenz und werden weder als nativer Gesamtscore noch als Pass/Fail-Ergebnis interpretiert. Der Source Extractor ist auf 1.1.0 und das append-only Defender-Profil auf 1.2.0 versioniert; Profil 1.1.0 bleibt lesekompatibel, wird aber gemaess Reimport-Policy als aktualisierbar markiert. Verifikation ausschliesslich mit synthetischen Daten: 1.245 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Keine Realdateninspektion, Datenbankmutation, Migration oder Backendneustart; Phasenstatus unveraendert. + +Defender-Device-CVE-Kurzliste 2026-09-11 (Phase 7, Nutzerpraezisierung): Das Device-Detail und die dort wiederverwendete Device-Liste innerhalb eines Site-Details zeigen je zugeordnetem CVE nur noch CVE-Kennung und Severity. Description und Reporting sensors entfallen aus dieser Tabelle, weil die CVE-Beschreibung in der CVE-Ansicht und der Sensor bereits im Device-Kontext verfuegbar sind. Eine synthetische Interaktionsregression sichert den exakten Zwei-Spalten-Vertrag. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; Quelldaten bleiben im Modell erhalten, keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-CVE-Evidenzliste 2026-09-11 (Phase 7, Nutzerpraezisierung): Das geoeffnete CVE-Detail zeigt alle betroffenen Geraete und ihre Sensorbeobachtungen unmittelbar in einer gemeinsamen flachen Liste statt als einzeln aufklappbare Device-Gruppen. Die Liste enthaelt nur Device, IP, Site und Sensor; interne Source-row-Provenienz und die bereits durch das ausgewaehlte CVE feststehende Severity werden nicht redundant angezeigt. Die Detailprojektion wird nur fuer das aktuell geoeffnete CVE aufgebaut. Eine synthetische Regression mit zwei Geraeten fuer dasselbe CVE prueft fehlende Unter-Expander, beide sichtbaren Zeilen und den exakten Vier-Spalten-Vertrag. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; Quellprovenienz und Severity bleiben im Modell erhalten, keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-Inline-Detailflaeche 2026-09-11 (Phase 7, Nutzerkorrektur): Aufgeklappte CVE-, Device- und Site-Details verwenden wieder dieselbe themenabhaengige `--tile-surface` wie die zugehoerige Tabellenliste statt der deutlich dunkleren `--client-info-surface`. Gelbe Auswahlmarkierung, Detailgrenze, Inhalte und Interaktion bleiben unveraendert. Eine Stilregression sichert die gemeinsame Flaeche und schliesst den dunklen Client-Info-Token fuer `.defender-drilldown` aus. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-CVE-Observations nur im Detail 2026-09-11 (Phase 7, Nutzerpraezisierung): Die CVE-Uebersicht entfernt die fuer den aktuellen Ein-Sensor-je-Geraet-Datenstand redundante Observations-Spalte. Affected devices bleibt als eindeutige Geraetezahl sichtbar; die Anzahl der zugrunde liegenden Quellbeobachtungen bleibt je Geraet im aufgeklappten Evidenzdetail erhalten, damit kuenftige Mehrfachmeldungen weiterhin nachvollziehbar sind. Die synthetische Interaktionsregression prueft die nun fuenf Uebersichtsspalten und die unveraenderte Detaildarstellung. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-CVE-Beschreibung nur im Detail 2026-09-11 (Phase 7, Nutzerpraezisierung): Die CVE-Uebersicht entfernt die redundante Description-Spalte; die vollstaendige Beschreibung bleibt unveraendert direkt im aufgeklappten Inline-Detail sichtbar. Affected devices bezeichnet weiterhin die Anzahl unterschiedlicher betroffener Geraete, Observations die Anzahl der zugrunde liegenden Sensor-Quellzeilen und kann deshalb durch mehrere Sensoren oder wiederholte Meldungen groesser sein. Die synthetische Interaktionsregression prueft die sechs Uebersichtsspalten sowie die erhaltene Beschreibung im Detail. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-for-IoT-Inline-Drilldowns 2026-09-11 (Phase 7, Nutzerkorrektur): CVE-, Device- und Site-Details erscheinen jetzt unmittelbar unter der ausgewaehlten Tabellenzeile statt gesammelt am Ende der jeweiligen Liste. Die vorhandenen Bezeichnungsbuttons verwenden ein einheitliches Auf-/Zuklappdreieck, `aria-expanded` und stabile `aria-controls`-Ziele; ein erneuter Klick schliesst das Detail, eine andere Auswahl verschiebt das einzige offene Detail. Die ausgewaehlte Zeile nutzt die gemeinsame gelbe Markierung, waehrend der Tastaturfokus blau bleibt. Verschachtelte Evidenztabellen bleiben innerhalb ihrer Detailzeile horizontal scrollbar und werden weder abgeschnitten noch verkuerzt. Synthetische Interaktionstests pruefen Oeffnen, Verschieben, Schliessen, unmittelbare Zeilennachbarschaft und Zugaenglichkeitszustand in allen drei Ansichten. Verifikation: 1.243 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Reine Darstellungsaenderung; keine Datenmutation, API-, Persistenz-, Importer-, Profil-, Scoring- oder Reimportaenderung. Phasenstatus unveraendert. + +Defender-for-IoT-Client-Info-Stil 2026-09-11 (Phase 7, Nutzerpraezisierung): Microsoft Defender for IoT bleibt eine eigenstaendige Client-Info-Registerkarte mit unveraenderten CVE-, Device- und Site-Ansichten. Die Registerkarte verwendet jetzt denselben themenabhaengigen Client-Info-Canvas, dieselbe Client-/Assessment-/Source-Kopfzeile, denselben Panel-Inset sowie die flache Kachel-, Flaechen-, Typografie-, Auswahl- und Responsive-Grammatik wie Overview. Scannerprojektion, Finding-Semantik, Scoreberechnung, Import- und Persistenzvertraege bleiben unveraendert; kein Reimport erforderlich. Verifikation: 1.239 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich. Keine Datenmutation, Migration, Realdateninspektion oder Backendneustart; Phasenstatus unveraendert. + +Client-Info-HTML-Reports 2026-09-23 (Phase 7 UI-Anbindung, neuer querschnittlicher A/B-Deliverable; in Arbeit): Zwei flache Buttons erzeugen aus dem gewaehlten Timeslot getrennte, statische HTML-Dateien fuer Management und Technik. Die Report-Projektion 1.1.0 entsteht erst beim Export aus allen aktuellen Scanner- und Policy-Ergebnissen; der sichtbare Source-Filter veraendert sie nicht. Der bestehende Management-Renderer enthaelt keine technischen Einzelwerte oder Asset-IDs; der neue Technical-Renderer zeigt Result-Inventar, Findings, Originalfelder, Ist/Soll, GPO-Register samt retained Backup-Anweisungen, Diagnostics und vollstaendigen Result-Index. Unbelegte Angaben bleiben ausdruecklich unbekannt, GPO-Backups beweisen keinen effektiven Endpunktzustand, Review-Schritte sind unverifizierte Selbstauskunft. Kein Import-, Schema-, Persistenz- oder Result-DB-Disclosure-Eingriff. Synthetische Klickpfad- und Renderertests sowie beide Produktionsbuilds bestanden; weitere Vollstaendigkeitspruefung fuer Diagnostics, Reimport-Metadaten und alle Quellformate sowie visuelle Light-/Dark-Abnahme im Dummy bleiben offen. Rueckwaertskompatible Capability als Minorversion 2.6.0; Phase 7/13C und der A/B-Deliverable werden dadurch nicht als abgeschlossen markiert. + +Environment-Results-Tabellenueberschriften 2026-09-23 (Phase 7 mit erhaltener Phase-13C-Quellprovenienz, Nutzerkorrektur): Das 2.5.14-Fenster setzte eine aus dem ersten Unterabschnitt stammende Abschnittsueberschrift wie `Honey Pot` ueber weitere, fachlich andere Tabellen. Die reine Leseprojektion verbindet nun jede native Tabelle innerhalb exakt desselben Scanlaufs, derselben Importdatei und desselben Abschnitts ueber den bereits erhaltenen internen Tabellenindex mit der zugehoerigen Quell-Unterabschnittsueberschrift. Mehrdeutige Labels bleiben beim nativen Tabellennamen; ein generischer Zaehlname wie `Tabelle 40` wird bei eindeutigem Unterabschnitt nicht als Ueberschrift ausgegeben. Wenn ein breiter Abschnitt faelschlich den Namen seines ersten Unterabschnitts traegt, wird der technische Abschnittsschluessel lesbar als uebergeordneter Titel dargestellt. Abschnitts- und Snapshotmetadaten besitzen je Zeile nur noch ein Label-Wert-Paar; native Spaltenkoepfe bleiben mit ihren Daten in derselben horizontal scrollbaren Tabelle. Die sichtbare Zeile `Source table index` entfaellt, die technische Zuordnung bleibt intern erhalten. 32 fokussierte synthetische Import-, Klickpfad-, Konflikt- und Versionsvertragstests, beide Produktionsbuilds, Local-only- und Designcheck bestanden. Keine Kundendateninspektion, Bestandsmutation, Import-, Persistenz- oder Result-DB-Aenderung. Phase 7/13C bleiben in Arbeit; reale Theme-Abnahme nur im freigegebenen Dummy noch offen. Patchversion 2.5.15. + +Environment-Detail-Results Korrektur 2026-09-23 (Phase 7, mit read-only Scanner Context aus Phase 13C): Die vorherige 2.5.13-Umsetzung duplizierte im Results-Fenster nur die Kachelzusammenfassung und erfuellte damit die aktuelle Nutzeranforderung nicht. Die acht Buttons behalten Kachel, Fensterbedienung und Fokusvertrag, zeigen im Fenster aber jetzt die tatsaechlich gespeicherten Originalabschnitte mit allen Quelltabellenzeilen, Prosa, Zustand und Herkunft sowie die zugeordneten Einzelbeobachtungen mit getrenntem Original-/Normalwert. Source Overview enthaelt zusaetzlich die Quell- und Scan-Score-Beitraege, die vollstaendigen Quell-Findingfelder sowie alle behaltenen Abschnitte/Beobachtungen, auch nicht zuordenbare. Betriebssysteme behalten ihre gruppierte Tabelle und ergaenzen die nativen Tabellen. Umfangreiche Tabellen, Beobachtungen, Abschnitte und Findings werden in nachladbaren Bloecken vollstaendig zugaenglich; fehlender Kontext bleibt ausdruecklich leer statt erfunden. Reine bestehende Snapshot-/Record-Leseprojektion ohne Import-, Persistenz-, Result-DB-Disclosure-, Scoring- oder Reimportaenderung. Ausschliesslich synthetische Verhaltensdaten, kein Zugriff auf Kundendaten; fokussierte Interaktions-/Quelltests, Versionsvertrag, beide Produktionsbuilds, Local-only- und Designcheck bestanden. Reale Light-/Dark-Ansicht ist wegen der Dummy-Zugriffsgrenze nicht abgenommen. Phase 7/13C bleiben in Arbeit. Patchversion 2.5.14. + +Environment-Detail-Results 2026-09-23 (Phase 7, Nutzerwunsch, umgesetzt und synthetisch verifiziert): Alle acht bestehenden Environment-Detail-Kacheln (Source Overview, Directory, Resilience, Inventory, Password policy, Certificates & PKI, Source metrics und Operating systems) verwenden denselben `Results`-Button und dasselbe verschiebbare/maximierbare Floating Window wie zuvor Operating systems. Das Fenster wiederholt jeweils ausschliesslich die bereits sichtbaren Quelldaten der Kachel; unbekannte Fakten bleiben `—`, die Source-Overview-Drilldowns und die Scoring-Methodology-Aktion bleiben erhalten. Jeder Button hat den kachelspezifischen Dialognamen, den sichtbaren Open-Zustand und die Fokus-Rueckgabe nach dem Schliessen. Source Overview darf bei schmaler Kachelbreite umbrechen. 42 fokussierte Tests, darunter ein synthetischer Durchlauf aller acht normalen Buttons, sowie Client-/Server-Produktionsbuild, Local-only- und Designsprachenpruefung bestanden. Gesamtsuite: 1.453 bestanden, 13 optionale Skips und dieselben fuenf bekannten fachfremden Vertragsfehler. Laufende App auf 5173 und PostgreSQL-Backend auf 4173 erreichbar; Backend meldet Produktversion 2.5.13. Keine Kundendateninspektion, Import-, Persistenz-, Score- oder Reimportaenderung. Light/Dark wurde nicht an einem realen Mandanten visuell abgenommen; Token- und Strukturvertrag sind geprueft. Patchversion 2.5.13. + +Verifikation 2.5.12: 69 fokussierte Tests und beide Produktionsbuilds bestanden; die Gesamtsuite vor dem zusaetzlichen Routentest meldete 1.451 bestanden, 13 optionale Skips und dieselben fuenf bereits vorbestehenden fachfremden Vertragsfehler. Local-only-Sicherheitspruefung und Designsprachenpruefung bestanden. Laufendes lokales Backend auf Port 4173 meldet 2.5.12 mit PostgreSQL, App auf Port 5173 antwortet mit HTTP 200. Kein Zugriff auf den gemeldeten Kundenscope; dessen tatsaechliche Ansicht bleibt vom Nutzer zu pruefen. + +PingCastle-Titel-/ID-Korrektur 2026-09-23 (Phase 7/13C mit Disclosure-Grenze aus Phase 12/13B, Nutzerregression): Die vorherige 2.5.11-Abnahme erfasste nur unterschiedliche Titel innerhalb desselben kanonischen Occurrence; der gemeldete HTML-/XML-Zweiberichtsfall blieb dadurch falsch. Work gleicht nun ausschliesslich PingCastle-Vorkommnisse mit derselben Projekt-, Berichtsdatum-, Dateistamm- und nativen Regel-ID ab und bevorzugt den eindeutigen fachlichen Titel des zugehoerigen XML-/HTML-Berichts. Bei widerspruechlichen gleichwertigen Titeln wird nicht geraten; der native HTML-Checktitel bleibt als `Native source heading` erhalten. Die Result DB gibt oeffentlich dokumentierte PingCastle-Regel-IDs anhand des erweiterten offiziellen Katalogs frei und bewahrt deren native Schreibweise (`S-oldNtlm`); unbekannte IDs bleiben gesperrt. Disclosure Policy 2.5.0, Patchversion 2.5.12. Keine Kunden-/Bestandsdaten, Migration oder Reimporte veraendert; Verifikation ausschliesslich synthetisch; auch Dummy wurde in diesem Schritt nicht gelesen. + +Gemeinsame Result-DB-/Work-Ueberschrift 2026-09-23 (Phase 7/13C, Nutzerwunsch, umgesetzt und verifiziert): Work verwendet fuer Scannerfindings nun denselben kanonischen Definitionstitel wie die Result DB, statt die Ueberschrift erneut aus dem vorkommnisspezifischen nativen `Title`-Feld aufzubauen. Dadurch erscheint insbesondere bei verschiedenen PingCastle-Berichtsrepraesentationen die fachlich besser zuordenbare Result-DB-Ueberschrift einheitlich in Work-Aggregat, Quellansicht, Kartenliste und Finding Reader. Ein abweichender nativer Quelltitel bleibt in der reinen Leseprojektion als `Native source heading` sichtbar; Originalfelder, Provenienz, Identitaet und Persistenz bleiben unveraendert. Der konkrete Unterschied zwischen einem regelorientierten Checktitel und einem anzahlbezogenen kanonischen Titel ist mit ausschliesslich synthetischen Daten als Verhaltensregression abgesichert. 42 fokussierte Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung bestanden. Gesamtsuite: 1.448 bestanden, 13 optionale Skips und die fuenf bekannten fachfremden Vertragsfehler. Keine Bestandsdaten-, Import-, Persistenz- oder Reimportaenderung. Patchversion 2.5.11. + +LLM-Result-DB-GPO-Quellenentkopplung 2026-09-23 (Phase 12/13B, Nutzerpraezisierung, umgesetzt und verifiziert): Disclosure Policy 2.4.0 behaelt die vollstaendige technische GPO-Abweichung mit Titel, kontrollierter Source Rule ID, Policy-Pfad/Value Name, Operation, Typ, Ist-/Sollwert, Vergleich, Status, oeffentlicher Baseline, technischer Beschreibung/Empfehlung, belegten Diagnosen, Aussagegrenze und Verarbeitungsversionen. Gleichzeitig entfallen `policyIdentityKey`, interne Baseline-IDs, automatisch erzeugte `gpo-policy-identity-*`-Hashes sowie jede Projekt-, Domain-, GPO-, Backup-, Datei-, Locator-, Zeit- und Reviewidentitaet. Wohlbekannte oeffentliche Principals bleiben lesbar; Domain-SIDs werden zu `S-1-5-21-[DOMAIN]-`, bekannte Domainrollen zu `[DOMAIN]\\` und sonstige konkrete Principals zu stabilen resultlokalen `[DOMAIN_PRINCIPAL_n]`. Dieselbe Reduktion gilt rekursiv fuer Baselinevarianten. Work und GPO Analysis behalten unveraendert alle Originale. Die konkrete Dummy-GPO-Struktur ist als synthetischer Disclosure-, Result-Row- und JSONL-Leckagetest abgebildet. 70 fokussierte Tests, Produktversionsvertrag, Client-/Server-Produktionsbuild, Local-only- und Designpruefung bestanden; App und PostgreSQL-Backend liefern 2.5.10. Keine Bestandsdaten-, Persistenz-, Import- oder Reimportaenderung. Patchversion 2.5.10. + +Generische Security-Domain-Abdeckung und robuste Work-Suche 2026-09-23 (Phase 7/13C, Nutzerkorrekturen, umgesetzt und verifiziert): `Unclassified` ist ausschliesslich der letzte ehrliche Restfall, wenn keine belastbare Evidenz existiert oder eine Zuordnung mehrere Domains gleich plausibel machen und damit erfunden werden muesste. Die gemeinsame Klassifikation wertet zuerst Titel, beschreibende Kernfelder, Kategorien und `Source Rule ID` aus. Wenn diese keine Domain liefern, dienen technische Erklaerung, Rationale, Empfehlung, Remediation, Loesung, Impact und Details als zweite Evidenzstufe; diese darf nur bei genau einer passenden Domain zuordnen. `Print Spooler` beziehungsweise der eindeutige Token `Spooler` wird dabei werkzeugunabhaengig `System Hardening` zugeordnet. Die Implementierung kennt keine Sonderverzweigung fuer PingCastle oder `A-DC-Spooler`; der konkrete PingCastle-Fund, eine anders benannte Scannerregel, ein rein narrativer Fund und ein absichtlich mehrdeutiger Restfall sichern die Grenze. Die zentrale Work-Suche normalisiert den Suchbegriff selbst trim- und gross-/kleinschreibungsunabhaengig und durchsucht den sichtbaren Datensatztitel sowie alle erhaltenen Felder einschliesslich `Source Rule ID`. Aktive Status-, Facetten- und Scopefilter bleiben bewusst wirksam. 44 fokussierte Tests, Produktversionsvertrag, Client-/Server-Produktionsbuild, Local-only- und Designpruefung bestanden. Keine Kunden-, Import-, Persistenz-, Score- oder Reimportaenderung. Patchversion 2.5.9. + +Source-Rule-ID in Result DB und Work 2026-09-23 (Phase 7/13C mit Datenschutzgrenze aus Phase 12/13B, Nutzerwunsch, umgesetzt und verifiziert): Native Scanner-Regelkennungen erhalten in der Work-Projektion die werkzeugunabhaengige Bezeichnung `Source Rule ID` und erscheinen als eigenes technisches Feld im Finding Reader; Work-Exporte und die oeffentliche regelspezifische Suche erkennen dieselbe Bezeichnung. Die Result DB zeigt die nach Disclosure Policy 2.3.0 freigegebene Source Rule ID als feste Tabellenspalte und weiterhin im Detail. Die Korrektur umfasst auch explizit gescopte Purple-Knight-AD-/Entra-/Kombinationslaeufe, deren gueltige `SI...`-ID bisher durch die Scope-Bezeichnung verloren ging. Originalfelder und Provenienz bleiben unveraendert; fehlende IDs werden nicht erzeugt, unbekannte oder nicht oeffentlich validierte IDs bleiben in der Result DB fail-closed. GPOs behalten ihre getrennt bezeichnete technische Setting-ID, da sie keine native Scanner-Rule-ID liefern. 133 fokussierte Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung bestanden. Gesamtsuite: 1.444 bestanden, 13 optionale Skips und die fuenf bekannten fachfremden Vertragsfehler. Live-Abnahme ausschliesslich im Mandanten `Dummy`: Result-DB-Spalte und Work-Reader-Feld in Light und Dark lesbar. Keine Schema-, Import-, Persistenz-, Reimport- oder Bestandsdatenmutation. Patchversion 2.5.8. + +Result-DB-GPO-Nutzbarkeit und Purple-Knight-Entra-Scope 2026-09-23 (Phase 7/13C mit Datenschutzgrenze aus Phase 12/13B, Nutzerkorrektur, umgesetzt und verifiziert): Disclosure Policy 2.2.0 ersetzt fuer GPO-Vergleiche die unbrauchbaren generischen Titel und die vollstaendige Wertunterdrueckung. Result DB und ihr JSONL zeigen jetzt den konkreten Richtliniennamen beziehungsweise technischen Pfad, konfigurierte Kundenwerte, erwartete Baselinewerte, Baselinevarianten und eine nicht-hashartige technische Setting-ID; automatisch erzeugte `gpo-policy-identity-*`-Hashes werden nicht als vermeintlich hilfreiche Identitaet ausgegeben. Die bestehende Aussagegrenze bleibt sichtbar: Backupvergleich, kein Nachweis effektiver Endpunktkonfiguration. Scannerredaktion und Scope-Handle-Entfernung bleiben unveraendert. Purple-Knight-Findings tragen zusaetzlich einen kontrollierten Scope aus dem kanonischen ScanRun-Namen. `Purple Knight for Active Directory`, `Purple Knight for Entra ID` und ein explizit kombinierter Lauf erscheinen damit als getrennte Result-DB-Quellen und Filterwerte, waehrend Profil-ID und Scannerfamilie `purple-knight` bleiben. Historische unspezifische Purple-Knight-Laeufe werden nicht aus Titeln oder Regelnummern geraten und bleiben bis zum auditierten Reimport unter dem bisherigen Sammelwert. Verifikation ausschliesslich mit synthetischen Daten und im freigegebenen Mandanten `Dummy`: 50 fokussierte Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich; Gesamtlauf 1.443 bestanden, 13 optionale Skips und fuenf vorbestehende fachfremde Vertragsfehler. Keine Schema-, Import-, Persistenz- oder Bestandsdatenmutation. Patchversion 2.5.7. + +Maester-Finding-Reader 2026-09-22 (Phase 7/13C, Nutzerkorrektur, umgesetzt und verifiziert): Work bildet Maester-Findings nun aus den erhaltenen Originalfeldern in der fachlichen Berichtsreihenfolge `ID`, `Test result`, `Test details`, `Category`, `Tags`, `Source` ab. Die eigentliche Ueberschrift verwendet ausschliesslich Maesters `Title` und wiederholt die native Regel-ID nicht aus dem ID-praefigierten `Name`; die ID bleibt darunter als eigenes technisches Feld sichtbar. Ausfuehrungsfehler bleiben als eingeklappte technische Detailinformation erhalten; Dauer, Index und doppelte Rohfelder fuellen weder Lesespalte noch Additional Information. Ein statusartiger Maester-`Result`-Wert wie `Failed` erzeugt keinen falschen Hinweis auf eine fehlende Results-Datei. Die oeffentliche AI-Suche erkennt `CISA.MS.EXO.17.3` als exakte Maester-Regel zur Microsoft-Purview-Auditaufbewahrung und nicht mehr als generische Windows-Audit-Policy. Der reale LSW-Bestand bestaetigte read-only die vollstaendige Quellbasis (Title, Result, Severity, Tag, Block, ErrorRecord, ScriptBlockFile und ScriptBlock); keine Bestandsmutation und kein Reimport. 83 fokussierte Reader-, Such-, Linker-, Import-, Titel-, Facetten- und Viewer-Tests sowie Client-/Server-Produktionsbuild bestanden. + +PingCastle-Security-Domain-Vokabular 2026-09-22 (Phase 7/13C, Nutzerfehlerbericht, umgesetzt und verifiziert): `Unclassified` ist ausschliesslich eine fehlende Zuordnung zum gemeinsamen Security-Domain-Katalog und keine Aussage ueber Wichtigkeit, Severity, Ergebnis oder Scannererkennung. Der bisherige Katalog kannte mehrere eindeutige PingCastle-Begriffe nicht. `Obsolete OS`, `Hardened Paths`, Script Engines und CVE-Mitigation werden nun `System Hardening` zugeordnet; LDAPS, Channel/Anonymous Binding, rootDSE und veraltete LDAP-TLS-Versionen `Authentication & Access`; OU-Loeschschutz sowie NTFRS/SYSVOL `AD Infrastructure & PKI`. Ein synthetischer Work-Verhaltenstest bildet alle neun im Nutzerbeispiel sichtbaren Titel ab und verlangt null `Unclassified`. 28 fokussierte Domain-, Sidebar- und Filtertests sowie Client-/Server-Produktionsbuild bestanden. Reine gemeinsame Leseprojektion ohne Quellwert-, Severity-, Status-, Score-, Persistenz- oder Reimportaenderung. + +Data-Hub-Reimporthinweis-am-Tool 2026-09-22 (Phase 7/13B, ausdruecklicher Nutzerwunsch, umgesetzt und verifiziert): Processing-, Review- und Reimporthinweise stehen nicht mehr als timeslotweiter Sammelblock nach allen Quellen. Jeder betroffene Scan zeigt unmittelbar unter seiner eigenen Tabellenzeile eine flache Hinweiszeile mit konkreter Erklaerung und ausschliesslich seiner Reimport- beziehungsweise sicheren Uebernahmeaktion. Kurzstatus, Scan-Auswahl, Delete-Aktion, Preservation Contract und atomarer Ersatzpfad bleiben unveraendert. Die Darstellung verwendet bestehende Data-Hub-Flaechen, Statusrollen, Typografie und Buttongeometrie; bei schmaler Breite fliesst die Aktion unter den Text. 61 fokussierte Tests sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung am Liftket-Timeslot bestaetigt die beiden jeweils direkt unter ihrem PurpleKnight-Scan stehenden Hinweise, einen unbeeinflussten bereiten PingCastle-Eintrag und die sichtbare Produktversion 2.5.6. + +Maester-Unclassified-Suitefallback 2026-09-22 (Phase 7/13C, Nutzerfehlerbericht, umgesetzt): `Unclassified` bezeichnet in Work die fehlende Zuordnung zu einer der acht gemeinsamen Security Domains, nicht eine unbekannte Scannerherkunft. Maester-Felder `BLOCK`, `ID` und `TAG` waren bislang keine Domain-Evidenz; deshalb fielen insbesondere ORCA-/EXO-Findings trotz eindeutigem Exchange-Online-Suitecode in den Rest. Die gemeinsame Leseprojektion verwendet nun die stabilen Suitekennungen `ORCA`/`EXO`, `EIDSCA`, `CISA.MS.EXO`/`CISA.MS.AAD` und die entsprechenden Maester-Suiten ausschliesslich als Fallback fuer `Cloud & Applications`. Aussagekraeftige Titel-/Beschreibungsregeln behalten Vorrang, sodass etwa Conditional Access weiter `Authentication & Access` zugeordnet wird. Originalfelder, Scanneridentitaet, Ergebnisstatus, Score und Persistenz bleiben unveraendert; kein Reimport. + +ASSESSOR-Produktversion 2.5.6 am 2026-09-22 (querschnittlich, Nutzerhinweis, umgesetzt): Die seit 2.5.5 hinzugekommenen rueckwaertskompatiblen Korrekturen werden als Patch-Release 2.5.6 ausgewiesen. `package.json` bleibt die einzige Produktversionsquelle; Header, About-Dialog und Health-API lesen denselben Wert. Paket-Lock und die UI-/HTTP-Vertragstests erwarten ebenfalls 2.5.6. Historische Pruefberichte behalten ihren dokumentierten damaligen Stand 2.5.5. + +Purple-Knight-AD-ist-kein-Maester 2026-09-22 (Phase 13A/13B, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): `Purple Knight for Active Directory` ist ein eigenstaendiger Purple-Knight-Assessment-Scope und niemals Maester oder Entra ID. Sein kanonischer Tool-ID bleibt ausschliesslich `purple-knight`; AD-Zusammenfassungen erzeugen weder `maester.*`- noch `entra.*`-Kontext. Der historisch benannte Dashboard-Hilfsexport `dashboardMaesterTenantCount` wurde entfernt; die werkzeuguebergreifende Entra-Tenant-Zaehlung heisst ausschliesslich `dashboardEntraTenantCount`. Ein synthetischer Verhaltensregressionstest prueft den vollstaendigen AD-Import bis ScanRun, Tool-ID, Anzeigename und Umgebungsbeobachtungen. + +Purple-Knight-AD-/Entra-Trennung 2026-09-22 (Phase 13A/13B, Nutzerwunsch, umgesetzt und verifiziert): Profil 1.4.0 und Summary-Extractor 1.2.0 erkennen sowohl die native AD- als auch die Entra-ID-Zusammenfassung. Scanlaeufe werden bei gemeinsamer Profil-ID eindeutig als `Purple Knight for Active Directory` beziehungsweise `Purple Knight for Entra ID` bezeichnet. Entra-Tenant, nativer Entra-Posture-Score, IOE-/Evaluated-Zaehler und Entra-Kategoriescores werden kanonisch mit eigener Zielidentitaet gespeichert; AD-Werte bleiben Forest-gebunden und werden nicht vermischt. Client Info zaehlt Entra-Tenants werkzeuguebergreifend und zeigt den Tenant im internen Directory-Kontext. Der reale Liftket-Bestand bestaetigte die Ursache read-only: AD-XLSX mit 119 Findings und 22 AD-Beobachtungen; separater Entra-CSV-Lauf mit 56 Findings, aber wegen generisch importierter Summary bisher 0 Beobachtungen. Der bestehende Lauf bleibt unveraendert und benoetigt den ausdruecklichen Reimport derselben acht Originaldateien, die ASSESSOR nicht aufbewahrt. 109 fokussierte Tests sowie Client-/Server-Produktionsbuild bestanden; keine Migration, Reimporte oder Bestandsmutation. + +Result-DB-LLM-Datenschutzgrenze 2026-09-22 (Phase 12/13B, Nutzerkorrektur, umgesetzt und verifiziert): `result-db-disclosure` 2.1.0 behaelt bei bekannten Scannerprofilen die fuer ein LLM erforderlichen Finding-Titel, Beschreibungen, Empfehlungen und sicher validierten Regel-IDs. Personen-, Firmen-, Tenant-, Domain-, Host-, Konto-, Asset-, Pfad-, SID-, E-Mail- und interne Scope-/Provenienzwerte werden weiterhin entfernt oder in der Regelprosa durch typisierte Platzhalter ersetzt; HTML-Regelprosa wird zu lesbarem Klartext. Unbekannte Quellen, Zusatzbeobachtungen und kundenbezogene GPO-Werte bleiben fail-closed. Der explizite `internal-analysis`-Pfad behaelt Originale fuer Work und GPO Analysis; JSONL 2.0.0 wendet dieselbe Projektion erneut an und entfernt zusaetzlich Scope-/Result-/Run-/Artefakt-IDs, Zeitpunkte, Suchtext und konkrete Filterwerte. 45 fokussierte Domain-, Persistenz-, UI-, GPO- und Exporttests bestanden. Im laufenden PostgreSQL-Pfad besitzen alle 530 Purple-Knight-Zeilen wieder aussagekraeftige Titel/Beschreibungen und native SI-Regel-IDs, 501 eine Empfehlung; es wurden keine Asset-Wiederholungen, E-Mail-/UPN-, Domain-SID- oder Firmensuffixmuster ausgegeben. Keine Migration, Reimporte oder Bestandsdatenmutation; Phase 13B bleibt in Arbeit. + +Maester-Unicode-Null-Import 2026-09-20 (Phase 13A/13C, Nutzerfehlerbericht, umgesetzt und verifiziert): Ein nativer Maester-Fehlertext enthielt `U+0000`. Vorschau und Mapping waren erfolgreich, der atomare PostgreSQL-Abschluss scheiterte jedoch, weil `jsonb` dieses Zeichen nicht repraesentieren kann; die bisherige Auto-Import-Fehlerbehandlung ersetzte danach die erfolgreiche Vorschau irrefuehrend durch `0 of 0 files selected`. Die gemeinsame kanonische Importgrenze stellt jedes solche Zeichen nun explizit als lesbares `\\u0000` dar, behaelt den gesamten umgebenden Quellwert, Hash und Locator und erzeugt die Diagnose `unicode-null-escaped`. Andere Steuerzeichen, Parsing, Profilwahl, Normalisierung und Bewertung bleiben unveraendert. Nach einem Abschlussfehler bleibt die vorbereitete Dateizeile samt Wiederholungsmoeglichkeit sichtbar. Ein synthetischer Maester-XLSX-Test und der vollstaendige HTTP-Pfad Vorschau -> bestaetigte Zuordnung -> Import in vorhandenen Timeslot sichern genau die Regression; 26 fokussierte Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung bestehen. Der optionale PostgreSQL-Testlauf wurde gemaess kanonischer-Datastore-Regel nicht gegen die bestehende Kundendatenbank ausgefuehrt. Keine Migration, Schema- oder Bestandsdatenaenderung; Phase 13A bleibt abgeschlossen, Phase 13C in Arbeit. + +Client-Info-Security-Domain-Mengenbalken 2026-09-20 (Phase 7, ausdrueckliche Nutzerentscheidung und nachfolgende Ausrichtungs-/Farbkorrekturen, umgesetzt und verifiziert): Jede angezeigte Security-Domain-Zeile traegt einen dezenten Mengenbalken in einer eigenen gemeinsamen Rasterspalte zwischen dem laengsten gerenderten Domainnamen und der breitesten gerenderten Mengenspalte. Dadurch liegen beidseitig 12 px Abstand; kein Balken kann in Schrift oder hinter eine Zahl wachsen. Alle Balken enden an derselben Kante und wachsen von dort nach links. Seine Breite entspricht dem sichtbaren Abweichungs- beziehungsweise Review-only-Wert der Zeile geteilt durch die Summe aller angezeigten Domainwerte; die exakte rechtsbuendige Zahl bleibt die autoritative sichtbare Angabe. Die spaetere Nutzerkorrektur ersetzt die kurzzeitig gewaehlte kategoriale `--viz-*`-Folge: Jeder Balken liest nun exakt denselben aktuellen semantischen Farbwert wie der Overall-Score-Donut und wechselt gemeinsam mit dessen Critical-, Medium-, Passed- oder Unknown-Tone. Die Balken sind rein dekorativ und fuer assistive Technik verborgen. Vier fokussierte Suites mit 23 Tests, die Designsprachpruefung sowie Client-/Server-Produktionsbuild bestehen. Die Live-Pruefung am freigegebenen Dummy bestaetigt fuer alle neun Zeilen getrennte Text-/Balken-/Zahlenspalten, beide 12-px-Abstaende, identische Donut-/Balkenfarbe `rgb(232, 33, 79)` und keinen horizontalen Ueberlauf in Light und Dark; Light wurde wiederhergestellt. Keine Daten-, Klassifikations-, Score-, Drilldown-, API- oder Persistenzaenderung. + +Client-Info-Lesetypografie 2026-09-20 (Phase 7, ausdrueckliche Nutzerentscheidung, umgesetzt und verifiziert): Informationstragende Beschriftungen und strukturierte Tabellen-/Kachelinhalte verwenden mindestens die 14-px-Datenrolle; eigentliche Lesewerte und Fliesstext verwenden die 16-px-Leserolle. Kompakte Controls, technische Metadaten und Badges bleiben getrennte Ausnahmen. Environment Detail setzt den Vertrag fuer Fakten, Source Overview und Operating systems um; `Domain` rendert mit 14 px/700 und `sevenkingdoms.local` mit 16 px/400. Drei fokussierte Suites mit 23 Tests, Designsprachpruefung und Client-/Server-Build bestehen. Die Live-Pruefung bestaetigt dieselben Groessen in Light und Dark ohne horizontalen Kachelueberlauf; Light wurde wiederhergestellt. + +Client-Info-PingCastle-OS-Zustaende 2026-09-20 (Phase 7, ausdrueckliche Nutzererweiterung, umgesetzt und verifiziert): Die Operating-systems-Tabelle zeigt neben `Devices` nun die von PingCastle je Betriebssystemzeile gelieferten Werte `Active`, `Inactive`, `Enabled` und `Disabled`. Die Projektion verbindet diese Werte ausschliesslich ueber identischen Scanlauf, Importdatei, Abschnitt, Quelltabelle und Quellzeile; sie berechnet keinen Zustand aus einem anderen und addiert weiterhin keine ueberlappenden Inventare. Fehlende Werte aus aelteren oder anderen Quellen bleiben `—`. Die read-only-Pruefung am freigegebenen Dummy bestaetigt fuer `Windows Server 2019 1809` die Quellwerte `1 / 1 / 0 / 1 / 0`; die zweite unquantifizierte Quelle bleibt in allen fuenf Spalten unbekannt. Drei fokussierte Suites mit 28 Tests, Client-/Server-Build, Designsprachen- und Local-only-Sicherheitspruefung bestehen. Light und Dark wurden live geprueft; alle Spalten passen bei 568 px Kachelbreite ohne horizontalen Ueberlauf, Light wurde wiederhergestellt. + +Data-Hub-/Client-Info-Deviation-Abgleich 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Data Hub berechnet seine Ergebnisdonuts nicht mehr nur aus scannergebundenen Run-IDs, sondern aus demselben ausgewaehlten gemischten Timeslot-Projektblatt wie Client Info. Assessmentgebundene GPO-/Policy-Ergebnisse bleiben dadurch enthalten; der freigegebene Dummy zeigt in beiden Ansichten `477` Deviations bei `1.833` Gesamtdatensaetzen beziehungsweise `26 %`. Beide Ansichten verwenden dieselbe zentrale autoritative Ergebniszustandsklassifikation. Der Client-Info-Donut uebernimmt zudem exakt die Data-Hub-Referenzvariante samt Kachelflaeche, Groesse, Padding, Titeltypografie, Ringgeometrie, Farben und Hover. Beim Mandantenwechsel wird die vorige Kennzahl sofort geleert, damit waehrend der asynchronen Projektion keine Zahl eines anderen Mandanten sichtbar bleibt. Vier fokussierte Suites mit 32 Tests, Client-/Server-Build, Designsprachen- und Local-only-Sicherheitspruefung bestehen. Die laufende Dummy-Ansicht bestaetigt `477 / 1.833 / 26 %` in beiden Bereichen; berechnete Light- und Dark-Styles sind identisch und Light wurde wiederhergestellt. + +Data-Hub-Mandantenauswahlkontur 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die persistente gelbe Kontur der ausgewaehlten Mandantenkachel ist gezielt von 2 px auf 3 px verstaerkt. Die Breite wird aus den bestehenden Linienrollen `--bw-emphasis` und `--bw-hairline` zusammengesetzt; Farbe, Innenversatz, Kachelgroesse und Layout bleiben stabil. Diese Ausnahme gilt nur fuer die ausgewaehlte Data-Hub-Mandantenkachel. Der getrennte blaue 2-px-Tastaturfokus, Hover, nicht ausgewaehlte Kacheln und alle anderen Auswahlkonturen bleiben unveraendert. Zwei fokussierte Suites mit 10 Tests, Client-/Server-Build, Designsprachen- und Local-only-Sicherheitspruefung bestehen. Die laufende Data-Hub-Ansicht bestaetigt die staerkere gelbe Kontur und `aria-pressed=true` in Light und Dark; Light wurde anschliessend wiederhergestellt. + +Light-Mode-Kachelflaeche-Nachschaerfung 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die gemeinsame Light-Mode-Kachelflaeche wird von dem weiterhin zu hellen `#FAFAFC` auf das dezentere Neutralgrau `#F5F5F7` abgesenkt. Die Aenderung bleibt auf `--tile-surface` begrenzt und gilt damit konsistent fuer Data Hub, Work, Client Info, DB Structure und Pathfinder. Die Kacheln bleiben heller als der App-Hintergrund `#F1F1F4`; Hover-, Auswahl-, Fokus-, Status- und Dark-Mode-Rollen bleiben unveraendert. Vier fokussierte Suites mit 24 Tests, Client-/Server-Build, Designsprachen- und Local-only-Sicherheitspruefung bestehen. Die laufende Client-Info-Ansicht bestaetigt `rgb(245, 245, 247)` im Light Mode und den unveraenderten Dark-Mode-Wert `rgb(50, 50, 56)`; Light wurde anschliessend wiederhergestellt. + +Client-Info-Deviations-Donut 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die Gesamtzahl `Deviations` in der Kachel `Data` wird nun mit der bestehenden gemeinsamen `DonutMetricCard` als vollstaendiger 360-Grad-Ring dargestellt. Die absolute Anzahl steht fett und zentriert, darunter der Anteil an allen Datensaetzen des aktuellen Client-Info-Projekts; beim freigegebenen Dummy sind das `477` und `26 %` aus `477 / 1.833`. Der Donut liegt transparent in der vorhandenen Kachel, erzeugt keine verschachtelte Kachelflaeche und bleibt vollstaendig per Maus und Tastatur als Drilldown nach Work mit `Deviation` bedienbar. Vier fokussierte Suites mit 27 Tests, Client-Build, Designsprachen- und Local-only-Sicherheitspruefung bestehen. Die laufende Browseransicht wurde in Light und Dark geprueft; Ring, Innenabstand, Ausrichtung, Beschriftung und zugaenglicher Name `Deviations: 477, 26%` sind korrekt, der urspruengliche Light Mode wurde wiederhergestellt. + +Client-Info-Environment-Detail-Icons-and-Spacing 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Alle acht Kachelueberschriften in Environment Detail, einschliesslich `Source Overview` und `Operating systems`, tragen nun genau ein bestehendes dezentes ASSESSOR-Liniensymbol in der abgesetzten Textfarbe. Die Faktengruppen uebernehmen den Listenabstand und das Zeilenpolster von Source Overview (`12px 0 16px` beziehungsweise `12px 8px`) und wirken dadurch luftiger und einheitlich. Vierer-Raster, feste Kachelhoehen und internes Scrollen bleiben erhalten. Verifiziert wurden 28 fokussierte Vitest-Faelle, Client- und Server-Build, Designsprachen- und Local-only-Sicherheitspruefung sowie die laufende Browseransicht in Dark und Light mit acht Ueberschriften und acht Symbolen. + +Client-Info-Environment-Facts-in-Data 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die separate obere Environment-Facts-Kachelreihe wurde entfernt. AD Domains, Entra Tenant, User Accounts, Computer Objects, Domain Controllers und GPOs stehen nun samt ihrer bestehenden Symbole innerhalb der `Data`-Kachel unter den zusaetzlichen Ergebniszustaenden. Dort bilden sie ein flaches 3-mal-2-Raster mit transparenten Zellen und dezenten Trennlinien statt verschachtelter Kacheln. Werte, unbekannt-Semantik und Datenherkunft bleiben unveraendert. Ein synthetischer Interaktionstest sichert alle sechs Fakten, Symbole und die Abwesenheit der frueheren oberen Reihe dauerhaft ab. Verifiziert wurden 29 fokussierte Vitest-Faelle, Client- und Server-Build, Designsprachen- und Local-only-Sicherheitspruefung sowie die laufende Browseransicht mit exakt sechs Fakten und Symbolen, drei gleich breiten Spalten, entfernter alter Faktenleiste und ausgerichteten Unterkanten von `Data` und `Domain Information`. + +Client-Info-Environment-Detail-Kachelraster 2026-09-20 (Phase 7, ausdrueckliche Nutzererweiterung, umgesetzt und verifiziert): Der gesamte aufgeklappte Environment-Detail-Inhalt ist als achtteiliges Raster organisiert: Source Overview, sechs fachliche Faktengruppen und Operating systems. Das Raster behaelt immer vier gleich breite Kacheln pro Reihe. Ein `ResizeObserver` leitet die einheitliche Kachelhoehe aus 75 Prozent der tatsaechlich gerenderten Overall-Score-Kachel ab; ueberlange Inhalte scrollen innerhalb ihrer Kachel. Auf schmalen Ansichten bleiben Spaltenzahl und Kachelbreite durch horizontalen Raster-Scroll stabil. Die Source-Overview-Kachel behaelt innen die vereinbarte schlichte Quellenliste und alle Drilldowns. Die Live-Pruefung bestaetigt acht Kacheln, vier gleich breite Spalten zu rund 578 px und 504,4 px Kachelhoehe bei 672,6 px Overall-Score-Hoehe; Source Overview und Source metrics scrollen intern. 29 fokussierte Dashboard-/Environment-/Interaktionstests, Designsprachpruefung, Client-/Server-Produktionsbuild und Local-only-Sicherheitspruefung bestehen. + +Client-Info-dominante-Abweichungszahl 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die klickbare Gesamtzahl `Deviations` in der Kachel `Data` verwendet nun die vorhandene 56-px-H1-Rolle mit kompakter Zeilenhoehe und groesserem vertikalem Abstand. Die Beschriftung bleibt direkt darunter und ist als semibold Feldlabel klar lesbar; die vier zusaetzlichen Ergebniszustaende bleiben bewusst kleiner. Farbe, Datenwert, Kachelgeometrie und der bestehende Work-Drilldown bleiben unveraendert. Die Live-Pruefung bestaetigt `477` mit 56 px/600 sowie `Deviations` mit 12 px/600 ohne Hintergrund oder Schatten. 18 fokussierte Dashboard-/Interaktionstests, Designsprachpruefung, Client-/Server-Produktionsbuild und Local-only-Sicherheitspruefung bestehen. + +Client-Info-Quellenliste-im-Environment-Detail 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Der separate Bereich `Source Overview` wurde aus der Hauptansicht entfernt. Dieselben Quelleninformationen stehen nun im aufgeklappten `Environment Detail` als kompakte Aufzaehlung mit Trennlinien und transparenten Zeilen statt Kacheln. ASSESSOR-Score, Bewertungsmethode, native Kontextwerte, Provisional-Hinweis, Scoring-Methodology-Dialog und die bestehenden Work-Drilldowns bleiben erhalten. Die sechs fachlichen Environment-Gruppen und der initial eingeklappte Zustand bleiben unveraendert. Die Live-Pruefung bestaetigt fuenf Quellenzeilen innerhalb von `Environment Detail`, keinen eigenstaendigen Source-Overview-Bereich sowie transparente, schattenfreie Darstellung in Light und Dark. 29 fokussierte Dashboard-, Environment- und Interaktionstests, Designpruefung, Client-/Server-Build und Local-only-Sicherheitspruefung bestehen. + +Client-Info-Data-Kachel 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die ehemalige Kachel `Priority Findings` heisst nun `Data` und tauscht mit `Domain Information` die Position, sodass `Data` links und die Domaininformationen rechts stehen. Die doppelten Kennzahlen `Critical` und `High` sind entfernt; Gesamtzahl `Deviations` und die getrennte Zeile der zusaetzlichen Ergebniszustaende bleiben erhalten. Der Kopf verwendet eine einzige volle Rasterspalte ohne Versatz. Die Abweichungszahl ist eine tastaturbedienbare Schaltflaeche und oeffnet Work mit dem Standardfilter `Deviation`. Der nicht mehr benoetigte Severity-Zaehler wurde entfernt; ein synthetischer Interaktionstest sichert Beschriftung, Reihenfolge, reduzierte Kennzahlen und den Drilldown ab. Die Live-Pruefung bestaetigt `Data`, `477 Deviations`, die Reihenfolge Data/Domain Information/Assessment Gaps sowie die gemeinsame 4-px-Buttongeometrie; Light und Dark bleiben lesbar. 18 fokussierte Dashboardtests, Designpruefung, Client-/Server-Build und Local-only-Sicherheitspruefung bestehen. + +CIS-CAT-Result-Belegfarbe 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Ausgewertete Quellzeilen in verknuepften CIS-CAT-Results werden nicht mehr pauschal rot dargestellt. Das tatsaechliche Finding-Outcome wird in das Results-Fenster weitergereicht: `Pass` verwendet die eigene gruene Match-Rolle, `Fail` die rote Violation-Rolle; fuer unbekannte oder neutrale Outcomes wird keine Aussage erfunden. Erwartungskriterium und bestaetigter Ist-Wert bleiben semantisch getrennte Rollen. Ein synthetischer Interaktionstest sichert den Pass-Fall mit `Type = reg_dword` und `Value = 0` sowie den unveraenderten Fail-Fall ab. Die 22 fokussierten Results-/Layout-Tests, Designpruefung, Client-/Server-Build und Local-only-Sicherheitspruefung bestehen; die Theme-Pruefung bestaetigt die Match-Rollen im Light Mode (`#CBEFD9` / `#10261A`) und Dark Mode (`#176B46` / `#FFFFFF`). + +Light-Mode-Kachelflaeche 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die gemeinsame Kachelflaeche verwendet im hellen Theme statt Reinweiss nun das sehr dezente Neutralgrau `#FAFAFC`. Die Aenderung erfolgt ausschliesslich ueber `--tile-surface` und wirkt damit konsistent in Data Hub, Work, Client Info, DB Structure und Pathfinder; App-Hintergrund, Eingabeflaechen, Hover, Auswahl, Statusfarben und Dark Mode bleiben unveraendert. Die Live-Pruefung bestaetigt `rgb(250, 250, 252)` in Data Hub, Work und Client Info sowie den unveraenderten Dark-Mode-Wert `rgb(50, 50, 56)`; fokussierte Tile-/Layout-Tests, Design-Token-Pruefung, Client-/Server-Build und Local-only-Sicherheitspruefung bestehen. + +Client-Info-Environment-Feldueberschriften 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die Feldueberschriften in den aufgeklappten Environment-Detail-Gruppen, einschliesslich `Directory`, verwenden nun dieselbe Bold-Stufe 700 wie die kompakte Kachel `Domain Information`. Werte bleiben regulaer; Daten, Reihenfolge, Abstaende und Kachelgeometrie sind unveraendert. + +Accepted-Risk-Draft-Markierung 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die Kopfaktion `Accepted Risk` verwendet ausschliesslich im vorhandenen Zustand `Draft` eine blaue Flaeche mit weisser Schrift. Dafuer besitzt der Entscheidungsentwurf eine eigene semantische Farbrolle, getrennt von Auswahl, Severity und Tastaturfokus; der sichtbare Text `Draft` bleibt als zweites Zustandssignal erhalten. Leerer Zustand, angenommene, faellige, abgelaufene und widerrufene Entscheidungen bleiben unveraendert. + +Client-Info-Kachelflucht 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): In der breiten 1:1-Hauptzeile fuellt die rechte Aktionsspalte wieder exakt die Hoehe der Posture-Kachel. `Domain Information` und `Priority Findings` bleiben als gleich hohe obere Zeile erhalten; `Assessment Gaps` nimmt den verbleibenden Platz ein, sodass beide Hauptkacheln dieselbe Unterkante besitzen. Im gestapelten schmalen Layout bleiben alle Bereiche auf ihrer natuerlichen Inhaltshoehe. Inhalte, Daten und Aktionen sind unveraendert. + +Accepted-Risk-Leerzustand 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Solange fuer ein Finding keine Risikoakzeptanz erfasst ist, zeigt die bestehende Kopfaktion `Accepted Risk ?`. Sobald ein Eintrag vorhanden ist, ersetzt weiterhin dessen bestehender Entscheidungsstatus das Fragezeichen. Dialog, Risikoentscheidung, Persistenz und Findingdaten bleiben unveraendert. + +Client-Info-Domain-Information-Typografie 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): In der Kachel `Domain Information` sind der Kacheltitel und alle Feldueberschriften fett gesetzt. Die Werte behalten ihre regulaere Datenrolle, damit Ueberschrift und Inhalt eindeutig unterscheidbar bleiben; Daten, Reihenfolge und Kachelgeometrie sind unveraendert. + +Work-Sidebar-Security-Domains 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die bisherige Severity-Donut-Leiste in Work entfaellt vollstaendig. An ihrer Stelle stehen die acht gemeinsamen Client-Info-Security-Domains in Katalogreihenfolge untereinander; `Unclassified` erscheint nur, wenn es im geladenen Scope vorkommt. Jeder Eintrag zeigt die gegen alle anderen aktiven Work-Filter selbst-ausschliessend nachgezaehlten Treffer und setzt exakt dieselbe sichtbare `Security Domain`-Facette wie die Toolbar. Ein erneuter Klick auf die aktive Domain hebt die Auswahl auf, ein Klick auf eine andere Domain ersetzt sie; Nulltreffer bleiben gemaess Work-Vertrag anklickbar. Auswahl verwendet ausschliesslich die gemeinsame gelbe Markierung, Tastaturfokus bleibt blau. Quelldaten, Domainzuordnung und andere Filter bleiben unveraendert. + +Abnahme der Work-Sidebar-Security-Domains: 26 fokussierte Domain-, Interaktions-, Navigations-, Donut- und Designvertragstests sowie Client-/Server-Produktionsbuild und Designsprachpruefung bestanden. Die Live-Pruefung am freigegebenen Dummy bestaetigt in Light und Dark die vollstaendige Entfernung der Severity-Donuts, die gemeinsame Domainreihenfolge mit aktuellen Trefferzahlen, die gelbe aktive Auswahl und die bidirektionale Synchronisierung mit der sichtbaren Toolbar-Facette. `Identity & Account Hygiene` reduziert den Scope reproduzierbar von 477 auf 221 Treffer; erneuter Klick stellt `Security Domain: All` und 477 Treffer wieder her. Light und der ungefilterte Domainzustand wurden wiederhergestellt. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Info-Posture-Reduktion 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Der wiederholte Hinweis `Pass rates · … total deviations` entfaellt aus dem Security-Domains-Kopf. Die Domainzeilen behalten ihre klickbaren Scoreknoten und den numerischen Deviation-/Review-Zaehler, zeigen darunter jedoch keine wiederholte Bezeichnung mehr; die Bedeutung bleibt als Tooltip erhalten. Die komplette dreizeilige Finding-Vorschau und die Aktion `View findings` in Priority Findings entfallen. Die autoritativen Summen und klickbaren zusaetzlichen Ergebniszustaende bleiben erhalten; Findingdaten und die verbleibenden fachlichen Drilldowns bleiben unveraendert. + +Abnahme der Client-Info-Posture-Reduktion: Ein synthetischer Dashboard-Vertrag prueft dauerhaft die Abwesenheit des Gesamthinweises, aller sichtbaren Domain-Zaehler-Unterzeilen, der Finding-Vorschauliste und der Aktion `View findings`. 20 fokussierte Dashboard-/Posture-/Domainfiltertests, Client-/Server-Produktionsbuild sowie Designsprach- und Local-only-Pruefung bestanden. Die Live-Pruefung am freigegebenen Dummy bestaetigt in Light und Dark die reduzierte Darstellung, unveraenderte Kennzahlen und die gemeinsame Unterkante von Domain Information und Priority Findings; Light wurde als Ausgangsthema wiederhergestellt. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Globale Button-Abrundung 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Alle rechteckigen klickbaren Bedienelemente verwenden jetzt den gemeinsamen leichten `--btn-radius` von 4 px. Das umfasst Work-Aktionen wie `Snapshot` und `Reset`, View-Tabs, Sidebar-, Theme-, Icon-, Disclosure-, Segment-, Dialog- und Pathfinder-Schaltflaechen; eingebettete Randaktionen runden ihre sichtbaren Aussenkanten mit demselben Token. Echte Kreis-/Donut-Interaktionen und quadratische Inhaltskacheln behalten ihre fachliche Geometrie. Farben, Aktionen, Navigation und Datenlogik bleiben unveraendert. + +Abnahme der globalen Button-Abrundung: Der Designsprachtest sichert den gemeinsamen Basisvertrag, die zuvor abweichenden spaet geladenen View-Regeln sowie die beiden semantischen Ausnahmen dauerhaft ab. Client-/Server-Produktionsbuild, Designsprach- und Local-only-Pruefung bestanden. Die visuelle Live-Pruefung am freigegebenen Dummy bestaetigt Snapshot, Reset, View-Tabs, Export-, Icon- und Sidebar-Aktionen in Light und Dark; Light wurde als Ausgangsthema wiederhergestellt. Gesamtsuite: 1.419 bestanden, 13 optionale PostgreSQL-Tests uebersprungen; zwei fachfremde bestehende Quelltextannahmen zu einem erlaubten `code`-Element und der inzwischen erweiterten `openProject`-Signatur bleiben fehlgeschlagen. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Info-Domainzeilen-und-Score-Einstieg 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die Security-Domain-Zeilen zeigen den Domaenennamen jetzt in der 20-px-Detailtitelrolle und entfernen die bisherige Meta-Unterzeile mit Passed/Not configured/Duplicates/Conflicts/Review. Scoreknoten sowie rechter Deviation-/Review-Zaehler bleiben erhalten. Der Overall-Score-Ring ist nun eine per Maus und Tastatur bedienbare Aktion: Er oeffnet Work mit dem sauberen Remediation-Standard `Deviation`, entfernt vorherige Source-, Domain-, Severity-, Such-, Workspace- und Record-ID-Filter und zeigt die regulaere Work-Uebersicht. Score-, Domaenen- und Findingdaten bleiben unveraendert. + +Abnahme der Domainzeilen und des Score-Einstiegs: 26 fokussierte Dashboard-/Posture-/Domainfilter-/Navigationstests, Designsprach- und Local-only-Pruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung am freigegebenen Dummy bestaetigt die vergroesserten Domaenennamen ohne Meta-Unterzeilen in Light und Dark; der Score-Klick oeffnet Work mit `Deviation · 477` und allen Source-, Domain- und Severity-Filtern auf `All`. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Ladehinweis 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Der generische Text `Loading saved client …` ist durch `Loading Client: [Clientname]` ersetzt. Der Name wird beim Oeffnen direkt aus der ausgewaehlten Data-Hub-Projektidentitaet uebergeben und fuer nachfolgende Timeslot-/Refresh-Ladevorgaenge desselben Clients stabil wiederverwendet; der deaktivierte Sheet-Selector zeigt denselben dynamischen Status. Keine Lade-, Scope-, Daten- oder Persistenzlogik wurde geaendert. + +Abnahme des Client-Ladehinweises: Fuenf fokussierte Ladezustands-/Data-Hub-/Timeslot-Tests und Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung beim Oeffnen des freigegebenen Dummy bestaetigt sichtbar `Loading Client: Dummy`; der bestehende Bundlegroessenhinweis bleibt unveraendert. Phase 7 bleibt in Arbeit. + +Donut-Innenhierarchie 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Alle Anzahl-/Prozent-Donuts zeigen jetzt die absolute Anzahl fett in der ersten Zeile und den Prozentwert mit regulaerem Gewicht darunter. Ein gemeinsamer tokenbasierter Sicherheitsabstand haelt den vollstaendigen Readout bei grossen Data-Hub-, kompakten Sidebar-, Dashboard-Status-, Risk-Severity- und Client-Info-Verteilungsringen vom inneren Ringrand fern. Der Overall Score behaelt als Score-Ring seine fachlich abweichende `/100`-Semantik. Werte, Prozente, Filteraktionen und Scorelogik bleiben unveraendert. + +Abnahme der Donut-Innenhierarchie: 16 fokussierte Donut-/Data-Hub-/Sidebar-/Disclosure-/Tile-Vertragstests, Designsprach- und Local-only-Pruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung mit dem freigegebenen Dummy bestaetigt Anzahl oben, Prozent darunter sowie sichtbaren Innenabstand bei realen Werten in Light und Dark. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Info-vollstaendiger-Directory-Kontext 2026-09-20 (Phase 7, ausdrueckliche Nutzererweiterung, umgesetzt): `Domain Information` zeigt jetzt alle neun Fakten der Environment-Detail-Gruppe `Directory`: Domain, NetBIOS Name, Forest, Domains, Domain Functional Level, Forest Functional Level, Schema Version, Domain Created und Entra ID. Die zuvor gewuenschte Domain-Controller-Zahl bleibt als zusaetzlicher zehnter Fakt erhalten. Werte und Unbekanntbehandlung stammen unveraendert aus dem normalisierten Environment Snapshot; die 50/50-Geometrie und gleiche Kachelhoehe zu Priority Findings bleiben bestehen. + +Abnahme des vollstaendigen Directory-Kontexts: 22 fokussierte Dashboard-/Environment-/Quellenauswahltests, Designsprach- und Local-only-Pruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung am freigegebenen Dummy bestaetigt alle zehn Fakten ohne Abschneiden oder Ueberhang und die gemeinsame Unterkante mit Priority Findings in Light und Dark. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Data-Hub-Kachelflucht 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Ergebnis-Donuts und Mandanten-/Add-Kacheln verwenden auf breiten Flaechen jetzt dasselbe Sechs-Spalten-Raster. Spaltenstart, Spaltenbreite und Gap sind identisch; dadurch entfaellt der zuvor mit jeder Mandantenkachel anwachsende horizontale Versatz, waehrend alle sechs Donuts in einer Zeile bleiben. Unterhalb des Wide-Breakpoints gilt fuer beide Reihen wieder derselbe kompakte responsive Tile-Vertrag. Inhalte, Auswahl, Status und Navigation bleiben unveraendert. + +Abnahme der Data-Hub-Kachelflucht: 14 fokussierte Donut-/Data-Hub-/Tile-Vertragstests, Designsprach- und Local-only-Pruefung sowie Client- und Server-Produktionsbuild bestanden. Die Live-Pruefung in Light und Dark bestaetigt durchgehend fluchtende Kanten fuer alle sechs Donuts sowie Dummy, Maester Test, LSW und die Add-Kachel. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Info-Domainkontext 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die obere Aktionsrail ist jetzt eine exakte 50/50-Zeile mit `Domain Information` links und `Priority Findings` rechts. Beide Kacheln besitzen dieselbe Hoehe und Unterkante; `Assessment Gaps` nutzt darunter wieder die komplette Railbreite. Domain, Domain Functional Level, Domain Controllers, Forest, Forest Functional Level und Schema Version stammen aus denselben normalisierten Environment-Snapshot-Beobachtungen wie Environment Detail. Fehlende Werte bleiben `—`; Score-, Finding-, Filter-, Drilldown- und Persistenzlogik sind unveraendert. + +Abnahme des Client-Info-Domainkontexts: 17 fokussierte Dashboard-/Quellenauswahltests, Designsprach- und Local-only-Pruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung mit dem ausdruecklich freigegebenen Dummy bestaetigt die gleich breite und gleich hohe obere Kachelzeile, die vollbreiten Assessment Gaps, quellengestuetzte Werte fuer DFL, DC, Forest, FFL und Schema sowie lesbare Umbrueche in Light und Dark. Der bestehende Bundlegroessenhinweis bleibt unveraendert; Phase 7 bleibt in Arbeit. + +Client-Info-Posture-/Risikoregister-Korrektur 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die breite Client-Info-Hauptzeile teilt die verfuegbare Breite jetzt exakt zur Haelfte zwischen Posture und Aktionsrail; diese spaetere Korrektur ersetzt die kurzzeitig verwendete 2:1-Aufteilung. Kacheln derselben Zeile besitzen ausnahmslos dieselbe Hoehe und Unterkante. Accepted Risks uebernimmt die bestehende Data-Hub-Clientgeometrie mit fester linker Auswahl `clamp(420px, 27vw, 520px)`, rechter Informationsflaeche und gestapeltem schmalem Fallback. Risiko-, Score-, Quellen-, Filter-, Drilldown- und Persistenzdaten bleiben unveraendert. + +Overall-Score-Verdichtung 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die wiederholte Statuszeile unter dem Donut und der dort doppelt gezeigte Critical-Findings-Zaehler entfallen vollstaendig; Priority Findings bleibt der autoritative sichtbare Ort fuer diesen Zaehler. Assessment Coverage ist auf hoechstens 70 Prozent der Overall-Zone und zusaetzlich auf die gemeinsame kompakte Inhaltsbreite begrenzt, damit Label, Balken und Zaehler nicht von den gebogenen Domaenenverbindungen ueberlagert werden. Daten, Score, Statusableitung, Filter und Drilldowns bleiben unveraendert. + +Abnahme der Overall-Score-Verdichtung: 19 fokussierte Dashboard-Tests, Designsprachpruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Messung am Dummy ergibt 354,15 px Coverage-Breite innerhalb einer 537,92-px-Overall-Zone und null Schnittpunkte mit allen neun Verbindungskurven. Posture und Aktionsrail bleiben mit jeweils 1.324,02 px exakt gleich breit und besitzen dieselbe Unterkante. + +Source-Overview-Korrektur 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Die generische Quelle `Tabular Data` wird nicht mehr als Source-Overview-Kachel dargestellt. Ihre importierten Daten und unterstuetzten Filterpfade bleiben erhalten; sie ist jedoch keine eigenstaendige Security-Scoring-Quelle. Ein synthetischer Render-Test sichert die Abwesenheit der Kachel bei gleichzeitig sichtbarer erkannter Scannerquelle. + +Abnahme der Source-Overview-Korrektur: 16 fokussierte Dashboard-/Quellenauswahltests, Designsprachpruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung am Dummy bestaetigt in Light und Dark null `Tabular Data`-Kacheln und weiterhin fuenf erkannte Security-Scoring-Quellen; Dark wurde als Ausgangsthema wiederhergestellt. + +Accepted-Risks-Manage-Client-Uebernahme 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Accepted Risks verwendet nun die Data-Hub-Manage-Client-Logik als feste Master-/Detail-Flaeche. Links liegen Ueberschrift, Zaehler, eigenstaendig scrollende Risikoauswahl, gelbe persistente Auswahlmarkierung sowie getrennte Status-/Reviewangaben; rechts liegen `Risk Information`, der vollstaendige ausgewaehlte Datensatz, die einzeln aufklappbaren Detailgruppen und die Aktion `Open finding`. Pfeil hoch/runter sowie Home/End wechseln Auswahl und Fokus gemeinsam; schmale Breiten stapeln beide Bereiche ohne horizontalen Ueberhang. Risikodaten, Historie und Governance-Zustaende bleiben unveraendert. + +Abnahme der Accepted-Risks-Uebernahme: 18 fokussierte Dashboard-/Risk-Register-/Quellenauswahltests, Designsprachpruefung sowie Client-/Server-Produktionsbuild bestanden. Am Dummy messen Navigation und Information dieselbe 557,50-px-Hoehe; die Navigation verwendet die freigegebene 520-px-Obergrenze. `Open finding` wurde live gegen den richtigen Work-Datensatz geprueft. Light und Dark sind visuell geprueft; Client Info und Dark wurden danach wiederhergestellt. + +Overall-Score-Sekundaerwerte 2026-09-20 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): `Unassessed` und `Lowest domain pass rate` sowie ihr kompletter Trenn-/Layoutblock entfallen aus Overall Score. Die autoritativen Darstellungen bleiben unveraendert in Assessment Gaps beziehungsweise an den einzelnen Security-Domain-Knoten; Daten, Scoreberechnung und Drilldowns werden nicht geaendert. + +Abnahme der Sekundaerwert-Entfernung: 19 fokussierte Dashboardtests, Designsprachpruefung sowie Client-/Server-Produktionsbuild bestanden. Die Live-Pruefung am Dummy bestaetigt in Light und Dark null Sekundaercontainer und keine beiden Labels im Overall-Bereich; `Unassessed controls` bleibt in Assessment Gaps sichtbar. Dark wurde als Ausgangsthema wiederhergestellt. + +Abnahme dieser Korrektur: 12 fokussierte synthetische Dashboard-/Risikoregistertests, Client-/Server-Produktionsbuild sowie Local-only-/Designpruefung bestanden. Gesamtsuite: 1.416 bestanden, 13 optionale PostgreSQL-Tests uebersprungen; der bekannte fachfremde XML-Reader-Test mit seiner zu breiten `code`-Element-Annahme bleibt unveraendert fehlgeschlagen. Die abschliessende Breitenmessung am ausdruecklich freigegebenen Dummy bestaetigt fuer Posture und Aktionsrail exakt 1324,02 px bei 2660,02 px Gesamtbreite sowie dieselbe 744,80-px-Hoehe und Unterkante. Accepted Risks verwendet 520 px fuer die Auswahl und die restliche Breite fuer die Informationsflaeche. Light und Dark sind visuell geprueft; bei 700 px stapelt das Register ohne horizontalen Ueberhang. Bestehender Bundlegroessenhinweis und Phasenstatus bleiben unveraendert. + +Client-Info-Designangleichung 2026-09-18 (Phase 7, ausdruecklicher Nutzerauftrag, umgesetzt): Die Oberflaeche verwendet nun gemeinsame Theme-/Statusrollen, eckige flache Tiles, kompakte Controls und lesbare Inter-Rollen entsprechend Data Hub, Work und Pathfinder. Die ausdruecklich gewuenschten dynamischen Kurven vom Overall Score zu den Security Domains bleiben als verbindliches Merkmal erhalten. Source Overview nutzt nicht gestreckte Kachelbreiten; seine Methodik-Schaltflaeche erbt nicht mehr versehentlich die Geometrie einer Quellenkachel. Environment Detail startet als aufklappbare Evidenzzeile; das Accepted-Risks-Register behaelt seine sichtbare Auswahl/Zusammenfassung und bietet einzeln aufklappbare vollstaendige Details. Wiederholte Null-Kontextangaben an Domaenen entfallen, positive Diagnose-/Reviewzahlen bleiben sichtbar. Daten, Scoreberechnung, Provenienz, Filter-/Drilldownidentitaeten und Risikoentscheidungen bleiben unveraendert. + +Abnahme dieser Designangleichung: 47 fokussierte synthetische Dashboard-, Risk-Register-, Inventar- und Domain-Interaktionstests bestanden. Client-/Server-Typechecks, isolierter Client-Produktionsbuild und Design-/Local-only-Pruefung bestanden. Zusaetzlicher synthetischer Edge-Browsercheck in Light/Dark bei 1600, 1100, 860 und 390 px: kein horizontaler Ueberhang, eckige Tiles, exakt zentrierte Scorezahl, 28px Methodik-Control, acht Kurven mit weniger als 1px Zielabweichung in der nebeneinanderstehenden Darstellung sowie Auf-/Zuklappen per Tastatur und Reset beim Risikowechsel. Schmale Ansichten behalten den bisherigen gestapelten Fallback ohne waagerechte Kurven. Screenshots sind ausschliesslich synthetisch. Keine Kundendaten, laufenden Dienste oder regulaeren Build-Verzeichnisse veraendert; keine gesamte Projektsuite behauptet. Bestehender Bundlegroessenhinweis und Phasenstatus bleiben unveraendert. + +Work-Ansichtsexport 2026-09-18 (Phase 7, ausdruecklicher Nutzerauftrag, verifiziert): Die bestehenden CSV-/MD-/HTML-Buttons exportieren jetzt alle aktuell gefilterten/sortierten Work-Treffer einschliesslich verknuepfter und eingebetteter Results statt aller markierten Eintraege ueber mehrere Blaetter. Eine gemeinsame klickzeitgebundene Projektion liefert genau zwei Inhaltsspalten, Soll-Zustand und Abweichungen, mit nativen Anleitungen, Pruefnachweisen, Originalwerten, Baselinevarianten, GPO-Quellbelegen und offen ausgewiesenen Evidenzluecken. Aktives My Workspace, Timeslot, Suche, Facetten und Drilldown bleiben wirksam. HTML ist skriptfrei, offline mit eingebettetem lokalem Inter; lange CSV-Zellen erhalten verlustfreie Fortsetzungszeilen derselben Finding-ID. Dies ist ein Ansichtssnapshot, kein Ersatz fuer die kuratierte Arbeitsgrundlage oder die vier Artefakte der Reportstrategie. Keine Daten-/Schema-/Scoring-/Importaenderung. + +Abnahme und Risiko Work-Ansichtsexport: 53 fokussierte Export-/Results-Tests bestanden; nach finaler Inter-Einbettung nochmals alle 16 neuen Export-/Interaktionstests bestanden. Gesamtsuite: 1.412 bestanden, 13 optionale PostgreSQL-Tests uebersprungen, ein bekannter fachfremder XML-Reader-Test unveraendert fehlgeschlagen; keine vollstaendig gruene Gesamtabnahme behauptet. Client-/Server-Produktionsbuild sowie Local-only-/Designpruefung bestanden; App HTTP 200, Backend ok. Nur der ausdruecklich freigegebene Dummy wurde lesend geprueft, einschliesslich seiner referenzierten oeffentlichen Baseline-Anleitungen: All 1.833 Work-Treffer / 9.917 Results-Zeilen / 27.059 gepruefte Zellen / 708 Textabschnitte; Deviation 477 Treffer / 7.599 Results-Zeilen. CSV-Roundtrip vollstaendig, keine Zelle ueber Excel-Limit und keine fehlenden Result-Referenzen im Dummy. Synthetischer Browsercheck bei normaler Breite und 390 px ohne horizontalen Ueberhang. Bestehender Bundlegroessenhinweis bleibt; sehr grosse Ansichten erzeugen entsprechend grosse statische Dokumente. Phasenstatus unveraendert. + +Designverankerung 2026-09-18 (Phase 7, ausdrueckliche Nutzerkorrektur): Die aktuell freigegebenen Ansichten Data Hub, Work und Pathfinder sind die verbindlichen Referenzen der Ableton-inspirierten ASSESSOR-Designsprache, ausdruecklich auch fuer Client Info, Bildentwuerfe und Prototypen. Die bisherige visuelle Client-Info-Ausnahme ist aufgehoben; fachliche Inhalte, Scoresemantik, Provenienz und Drilldowns bleiben bindend. AGENTS.md, lokaler assessor-ui-Skill, Referenzvorrang und veraltete Asset-Kopieranleitung wurden auf diesen Vertrag ausgerichtet. Status: Designvertrag verankert; die drei verworfenen generischen Mockups sind nicht freigegeben, eine entsprechende Client-Info-UI-Neugestaltung ist damit noch nicht umgesetzt oder visuell abgenommen. Bestehende Phasenstatus unveraendert; keine App-, Daten-, API- oder Persistenzaenderung in diesem Dokumentationsschritt. + +Security-Domain-Korrektur 2026-09-18 (Phase 7, ausdruecklicher Nutzerauftrag): Work bietet alle acht unveraenderten Client-Info-Security-Domains in Katalogreihenfolge dauerhaft an, einschliesslich null Treffern in gemischtem Scope und beiden GPO-Einstiegen. Vorhandenes Unclassified bleibt zusaetzlich erhalten. Die Zaehler beachten andere aktive Filter; ausgewaehlte Nulltreffer bleiben sichtbar, ohne Status oder weitere gueltige Filter automatisch zu entfernen. Ein Client-Info-Domain-Deviation-Klick setzt den sichtbaren Domainfilter statt einer festen Record-ID-Auswahl, sodass nach dem Wechsel weitere Domains gewaehlt werden koennen. Vier neue synthetische UI-Interaktionstests sichern den Ein-Domain-Fall, beide GPO-Einstiege, Nulltrefferauswahl, Status-/Severity-Erhalt und Client-Info-Wechsel mit Quellfilter. 40 fokussierte Tests bestanden; abschliessende Build-/Gesamtabnahme folgt unten. Keine Klassifikations-, Score-, API-, Import- oder Persistenzaenderung; keine Mandantendaten gelesen. Phasenstatus unveraendert. + +Abnahme Security-Domain-Korrektur 2026-09-18: 40 fokussierte Tests, Client-/Server-Produktionsbuild, Local-only-/Designpruefung und technische App-/Backend-Erreichbarkeit bestanden. Gesamtsuite: 1.381 bestanden, 13 optionale PostgreSQL-Tests uebersprungen; zwei Fehler (bekannte fachfremde XML-Reader-Testannahme und Timeout des allgemeinen Node-Importtests). Der isolierte Wiederholungslauf des Node-Importtests bestand mit allen fuenf Tests; Timeouts wurden nicht angehoben. Der unveraenderte XML-Test bleibt offen. Keine Kunden-/Dummy-Dateninspektion; kein Reimport, keine Neuauswertung, kein Schema-/Datenbankeingriff. Phasenstatus unveraendert. + +Abschliessender Gesamtlauf zum GPO-Zaehlerfix 2026-09-18: 1.358 Tests bestanden, 13 optionale PostgreSQL-Tests uebersprungen, ein unveraenderter fachfremder XML-Reader-Test fehlgeschlagen; keine Timeout-/RPC-Fehler im Wiederholungslauf. Die fuenf neuen optionalen PostgreSQL-Paritaetstests wurden separat tatsaechlich ausgefuehrt und bestanden. Local-only-/Designpruefung separat gruen. Keine vollstaendig gruene Gesamtsuite behauptet. + +Verifiziert 2026-09-18 (Phase 7/13B, Result-DB-/Work-Zaehlerabgleich): PostgreSQL waehlt aktuelle Policy-Evaluationen jetzt nach der Anzahl verschiedener tatsaechlich verglichener Baseline-Pakete, mit Analyseverweisen nur als Fallback bei fehlenden Baseline-IDs und danach Zeit/ID als Tie-Breaker, entsprechend dem bestehenden Work-Selektor. Wiederholte Analysegenerationen desselben Pakets verdraengen damit keinen neueren gleich breit abdeckenden Lauf. Work-Deviation folgt dem autoritativen Fail-Urteil, auch bei explizit erforderlicher, aber fehlender Registry-Praesenz; gewoehnliche fehlende Empfehlungen bleiben Not configured. 50 fokussierte Tests inklusive fuenf direkt in PostgreSQL ausgefuehrter rein synthetischer SELECT/CTE-Paritaetsfaelle bestanden; Client-/Server-Produktionsbuild sowie Local-only-/Designpruefung erfolgreich. Ausdruecklich freigegebener Dummy lesend geprueft: 127 aktuelle Fail-Vergleiche, exakt dieselben 25 technischen Identitaeten in Work, Deviation 25, keine ausgeblendeten Fail-Urteile und keine zusaetzlichen Vergleichspaare. Keine Bestandsmutation, Migration, Reimport oder Neuauswertung; Fremdkunden nicht gelesen. Die Gesamtsuite ist wegen einer unabhaengigen bestehenden XML-Reader-Testannahme nicht vollstaendig gruen; Details im Abnahmebericht. Phasenstatus unveraendert. + +Verifiziert 2026-09-18 (Phase 7/13B, konsistente Result-DB-Statusfilter): Result DB und Work verwenden denselben Bezeichnungskatalog; Match wird Passed, Misconfigured wird Deviation, Conflict/Duplicate werden Conflicts/Duplicates und die Result-DB-Gruppe heisst Result Status. Auch Resultdetails verwenden diese Labels. Die Statuszaehler beachten Deviation und alle anderen aktiven Filter; nur die eigene Auswahl wird fuer erreichbare Alternativen ausgenommen. Statusauswahl und Abwahl setzen Deviation nicht mehr automatisch zurueck. Ausgewaehlte Status- und boolesche Nulltrefferfilter bleiben sichtbar und abwaehlbar. Zwei neue synthetische Result-DB-Interaktionstests sichern reine GPO- und gemischte Timeslots, Yes/No/All, Mehrfachauswahl, Nulltreffer, Detailbezeichnung und Scope; 45 fokussierte Tests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild bestanden. Gespeicherte Klassen, Einzelvergleichszaehlung und Datenschutzgrenze bleiben erhalten; keine Kunden-/Dummy-Dateninspektion. Phasenstatus unveraendert. + +Verifiziert 2026-09-18 (Phase 7/13B, langer Security-Template-Registrytitel): Der vorherige Ueberhangfix erfasste nur Titel mit `registry ·`, waehrend Security-Template-Findings den Vertrag `Registry Values · MACHINE\\...` verwenden. `PathText` erkennt nun auch diesen exakten Titelvertrag und behandelt `MACHINE\\`/`USER\\` nur in diesem Registry-Values-Kontext als technischen Pfad. Dadurch umbrechen Reader-Heading und Summary innerhalb ihrer Minmax-Spalte und bleiben vor `Accepted Risk`; allgemeine AppLocker-/User-group-Texte werden nicht als Pfad umklassifiziert. Zwei synthetische Regressionen sichern den konkreten langen Titel, Suchmarkierung, beide Readerpositionen und den bewusst unveraenderten allgemeinen `MACHINE\\`-Fall. Gesamtsuite: 1.351 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Produktionsbuild erfolgreich. Keine Kunden-/Dummy-Daten gelesen oder geaendert, keine API-, SQL-, Persistenz- oder Fachlogikaenderung. Phasenstatus bleibt in Arbeit. + +Verifiziert 2026-09-18 (Phase 7/13B, eine Work-Zeile je GPO-Einstellung): Mehrere Baseline-Paketvergleiche derselben technischen Identitaet werden innerhalb desselben Projekts, Aggregationslaufs und Scopes zu einer Work-Zeile zusammengefuehrt. Der bestehende Policy-Zaehler und die Zeile teilen dieselbe Urteilprioritaet. Individuelle Baselinefilter, alle Empfehlungen/Settingreferenzen, Quellprovenienz, historische Readiness sowie echte Conflict-/Duplicate-Merkmale bleiben erhalten. Wertmarkierungen pruefen alle beteiligten aktuellen Varianten; unbekannte/historische Varianten werden nicht aus dem Beweis entfernt. Alte lokale Baseline-Notizen bleiben lesbar; nur uebereinstimmende Notizen werden uebernommen, keine Risikoakzeptanz wird umgehaengt. Zehn neue synthetische Tests sichern den Neun-Pakete-Fall in beiden Work-Einstiegen, Filter, unterschiedliche Sollwerte, Historie, Scopegrenzen und Review-Erhalt. Gesamtsuite: 1.349 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Kunden-/Dummy-Daten gelesen oder geaendert, keine API-/SQL-/Persistenz-/Evaluatoraenderung. Phasenstatus bleibt in Arbeit. + +GPO-Quellwiederherstellung 2026-09-17 (Phase 13B, Nutzerauftrag, verifiziert): Fehlende GPO-Artefaktdateien ergeben jetzt bereits beim Statuslesen Upload required mit gezieltem ZIP-/Ordnerupload; Zugriffsprobleme bleiben separat Storage unavailable. Reconciler, Retry und Reprocess pruefen vor dem Einreihen, nachtraeglich fehlende Quellen beenden einen bereits gestarteten Job nach einem Versuch. Der Originalupload prueft Projekt/Artefakt/Timeslot, Groesse und SHA-256, repariert auch den normalen Dublettenpfad und stellt nur fehlende Bytes atomar unter derselben Speicher-ID wieder her. Aktuelle Analysen, Originalzeitpunkte und Historie bleiben erhalten; reine Re-evaluation ueber erhaltene Eingaben bleibt erreichbar. 16 neue synthetische Regressionen sichern Service, HTTP, API-Client, beide Oberflaechen mit ZIP/Ordner, automatische Reparatur, ersten Fehler, Zugriffsfehler, falsche Quelle, fremde Scopes, Wiederherstellung ohne Revisionswechsel sowie Local-/PostgreSQL-Jobverhalten und konkurrierende Dateiwiederherstellung. npm test: 1.336 bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Kein Parser-/Analyzer-/Manifestbump, keine SQL-Migration, kein Zugriff auf Kundeninhalte, keine Live-Datenmutation und kein Backendneustart. Bestehender Bundlegroessenhinweis bleibt; Phase 13B bleibt in Arbeit. + +Principal-Abweichungen mitgliedsgenau markiert 2026-09-17 (Phase 7/13B, Nutzerfehlerbericht, zielgerichtet verifiziert): Die Ursache der falschen roten Flaeche war der zuvor eingefuehrte Ganzwert-Fallback fuer nicht-Registry-GPO-Werte. Ein Principal-Set wurde dadurch trotz eines mit der Baseline uebereinstimmenden Mitglieds vollstaendig rot dargestellt. Principal-Sets werden jetzt auf Mitgliedsebene verglichen: Nur konfigurierte Principals, die in keiner aktuellen Baselinevariante erwartet werden, erhalten die rote Wertmarkierung; gemeinsame Principals bleiben neutral. Besteht die Abweichung ausschliesslich in einem fehlenden Soll-Principal, wird kein vorhandener korrekter Principal ersatzweise rot markiert. Synthetische Regressionen sichern zwei zusaetzliche, einen gemeinsamen und einen ausschliesslich fehlenden Principal sowie Suche, Filter und Navigation. 26 fokussierte GPO-Quellen-/Conflict-/Duplicate-Tests und beide Produktionsbuilds erfolgreich. Der parallele Gesamtlauf war nicht vollstaendig gruen: 1.312 Tests bestanden, acht optionale PostgreSQL-Tests wurden uebersprungen und fuenf fachlich unabhaengige Servertests trafen waehrend gleichzeitiger Security-Template-Aenderungen auf geaenderte Section-Casing-/Parser-/Analyzer-Versionen; ein aktueller fokussierter Wiederholungslauf bestaetigte den Principal-Fix und zeigte noch drei fremde Versionsannahmen (`1.1.0`/`2.2.3` gegen `1.2.0`/`2.2.4`). Reine Read-/Praesentationskorrektur ohne Reimport, Neuauswertung, API-, Persistenz-, Schema- oder Kundendatenzugriff; Phasenstatus unveraendert. + +Alle belegten GPO-Wertabweichungen rot markiert 2026-09-17 (Phase 7/13B, ausdrueckliche Nutzererweiterung, verifiziert): Die rote wertgenaue Markierung ist nicht mehr auf einzelne Data-Faelle beschraenkt. Registry.pol-Quellen markieren jetzt jede belegte abweichende Operation, Data und jeden abweichenden Type code, auch mehrere Felder gleichzeitig. Vergleichbare andere GPO-Wertarten erhalten dieselbe rote Wertmarkierung. Wenn jede aktuelle Baselinevariante eine Abweichung belegt, aber keine einzelne Feldursache allen Varianten gemeinsam ist, wird sicher der dargestellte Wert als Ganzes markiert, ohne eine spezifische Ursache zu erfinden. Review-required, unbewertete und passende Werte sowie Quellenabschnitt, Heading, Evidence-Pfad und Diagnose-Badges bleiben neutral. Synthetische Regressionen sichern Operation, Data, Type code, kombinierte Feldabweichungen, skalare GPO-Werte, Suche, Filter und Navigation. 1.317 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; beide TypeScript-Ziele, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine aktuelle Read-/Praesentationsprojektion ohne Reimport, Neuauswertung, API-, Persistenz-, Schema- oder Kundendatenzugriff; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +Backend-Verbindungsstatus als ASSESSOR-Popup 2026-09-17 (Phase 7, ausdrueckliche Nutzerkorrektur, verifiziert): Die bisherige eingebettete Warnflaeche fuer `Backend is unreachable` ist in Data Hub, Result DB und DB Structure durch einen gemeinsamen ASSESSOR-Standarddialog ersetzt. Titel, Warnmarker, bereichsspezifische Auswirkung und der Hinweis auf die automatische Verbindungspruefung bleiben sichtbar; der Dialog ist schliessbar, waehrend die zugrunde liegende Ansicht erhalten bleibt. Die bestehende Health-Pruefung laeuft unveraendert weiter und entfernt den Offline-Zweig nach erfolgreicher Verbindung automatisch. Permanente synthetische Regressionen pruefen Portal-/Dialogstil, Meldung, Schliessen und alle drei Einstiegspfade. 1.313 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; beide TypeScript-Ziele, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine Praesentationsaenderung ohne API-, Import-, Persistenz-, Schema-, Reimport- oder Kundendatenzugriff; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +Client-Info-Security-Domains als Work-Filter 2026-09-17 (Phase 7, ausdrueckliche Nutzererweiterung, verifiziert): Work besitzt jetzt direkt nach `Category` die eigene Facette `Security Domain`. Sie verwendet denselben extrahierten Katalog und dieselbe gecachte Datensatzzuordnung wie die acht Security Domains in Client Info; es existiert keine zweite Filterklassifikation. Damit filtern unter anderem `Identity & Account Hygiene`, `System Hardening`, `GPO & Baseline` und `Monitoring & Recovery` exakt die von Client Info derselben Domain zugeordneten Datensaetze. Die Facette ist im gemischten Work-Kontext sowie in beiden GPO-Einstiegen sichtbar; ein reiner GPO-Scope zeigt `GPO & Baseline`. `Source: Scan` bleibt der letzte Filter und bestehende aktive Work-Filter gelten weiter. Permanente synthetische Regressionen sichern gemeinsamen Katalog, identische Record-Identitaeten, Filterwirkung, GPO-Einwertscope, Reihenfolge, Zaehler und Kontextwechsel. 1.307 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; beide TypeScript-Ziele, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine gemeinsame Ableitungs-/Facettenkorrektur ohne Import-, Persistenz-, Schema-, Reimport- oder Kundendatenzugriff; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +GPO-Category-Filter wiederhergestellt 2026-09-17 (Phase 7/13B, Nutzerfehlerbericht und ausdrueckliche Korrektur, verifiziert): Die Ursache war die fruehere GPO-Kontext-Sonderregel, die `Category` sowohl bei `Source: Scan = GPOs` als auch auf dem dedizierten GPO-Blatt aktiv ausblendete. `Category` ist jetzt in beiden unterstuetzten GPO-Einstiegen wieder der permanente zweite Filter direkt hinter `Result Status`; er bleibt auch sichtbar, wenn `GPOs` der einzige aktuelle Kategorienwert ist. Im gemischten Work-Kontext bleibt die bisherige Category-Facette unveraendert. Andere im reinen GPO-Kontext ausgeschlossene Scannerfacetten bleiben ausgeschlossen und `Source: Scan` bleibt der letzte Filter. Permanente synthetische Regressionen sichern beide GPO-Einstiege, die exakte Reihenfolge, GPO-exklusive Zaehler, die Einwertkategorie, Kontextwechsel und Filterwirkung. 1.306 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; TypeScript-, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine Facetten-/Praesentationskorrektur ohne Import-, Bewertungs-, Persistenz-, Schema-, Reimport- oder Kundendatenzugriff; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +GPO-Abweichung nur am Wert 2026-09-17 (Phase 7/13B, ausdrueckliche Nutzerkorrektur, verifiziert): Die rote Flaeche und Akzentlinie am gesamten GPO-Quellenabschnitt sind entfernt. Jeder Quellenabschnitt bleibt neutral; rot hinterlegt wird ausschliesslich die konkrete dargestellte Zeile, deren Feld gegen jede gespeicherte aktuelle Baselinevariante eindeutig abweicht: `Operation` bei einer Operationsabweichung, `Data` bei einer Datenabweichung und `Type code` bei einer Typabweichung. Mehrere Felder werden nur markiert, wenn jedes unabhaengig belegt ist; bei uneinheitlicher Variantenursache wird kein Feld geraten. Conflict-Badge, Heading, Evidence, Key und Value name erhalten keine rote Hinterlegung. Synthetische Regressionen pruefen `Operation: delete-value`, `Data: 0`, einen reinen Typfehler, exakt eine Markierung im Finding sowie Suche, Filter und Navigation. 1.305 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; TypeScript-, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine aktuelle Read-/Praesentationsprojektion ohne Reimport, automatische Neuauswertung, Migration oder Kundendateninspektion; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +GPO-Quellenabschnitte mit roter Abweichung 2026-09-17 (Phase 7/13B, ausdrueckliche Nutzerkorrektur, verifiziert): Die unmittelbar zuvor gewaehlte flache Tabelle ist ausdruecklich wieder durch vollstaendige, untereinanderliegende GPO-Quellenabschnitte ersetzt. Evidence, quelllokale Sequenz sowie Operation, Key, Value name, Data und Type code sind ohne Aufklappen sichtbar; Operation und Data bleiben fett. Nur ein durch die gespeicherten aktuellen Baselinevarianten fuer diesen einzelnen Quellwert eindeutig belegter abweichender Abschnitt erhaelt eine dezente rote Flaeche, eine rote linke Akzentlinie und `Conflicting contribution`. Passende, historische, mehrdeutige oder innerhalb eines Backups aus mehreren Anweisungen bestehende Quellen bleiben neutral; GPO-Praezedenz und effektiver Endgeraetewert werden nicht erfunden. Permanente synthetische Regressionen sichern Darstellung, rote Quellenklasse, vollstaendige Fakten, beide Work-Einstiege, Deviation/Conflicts, Suche, Navigation und unveraenderte Originale. 1.305 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; TypeScript-, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine aktuelle Read-/Praesentationsprojektion ohne Reimport, automatische Neuauswertung, Migration oder Kundendateninspektion; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +GPO-Quellenzuordnung als Tabelle 2026-09-17 (Phase 7/13B, ausdrueckliche Nutzerentscheidung, verifiziert): Die zuvor gestapelten Quellenabschnitte sind im Finding Reader durch die gewaehlte flache Tabelle mit exakt `GPO source`, `Operation`, `Data`, `Type` und `Evidence` ersetzt. Jede exakte Backupidentitaet belegt eine Zeile; Operation und Data bleiben fett, Data und Typ stehen in kompakten Feldern, und der sichere Evidence-Pfad bleibt unmittelbar sichtbar. `Show source details` erhaelt vollstaendige native GPO-/Backupidentitaet, quelllokale Sequenz, Evidence, Key, Value name und jede Originalanweisung. Ein roter Marker und `Conflicting contribution` erscheinen nur, wenn die gespeicherten aktuellen Baselinevarianten den einzelnen Quellwert unabhaengig als abweichend belegen; Gruen nur bei Uebereinstimmung mit allen Varianten. Historische Auswertungen, mehrere Anweisungen innerhalb desselben Backups, GPO-Praezedenz und effektiver Endgeraetewert werden nicht als Einzelquellenurteil erfunden. Permanenter synthetischer Interaktionstest sichert beide Work-Einstiege, Deviation/Conflicts, Suche, Navigation, die fuenf Spalten, Details und unveraenderte Originale. 1.305 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; TypeScript-, Local-only-, Design- sowie Client-/Server-Produktionsbuild erfolgreich. Reine aktuelle Read-/Praesentationsprojektion ueber erhaltene Fakten, ohne Reimport, automatische Neuauswertung, Migration oder Kundendateninspektion; Phasenstatus unveraendert. Bestehender Bundlegroessenhinweis bleibt. + +GPO-Quellenzuordnung 2026-09-17 (Phase 7/13B, ausdruecklicher Nutzerauftrag, verifiziert): Der Finding Reader zeigt Originalanweisungen sofort getrennt nach exakter Projekt-/Assessment-/Backupinstanzidentitaet, mit Quellenzahl, erhaltenen nativen GPO-/Backup-IDs, internem Quellpfad und quelllokaler Sequenz. Operation und Data bleiben fett; Loeschung, leerer String, Leerzeichen und 0 bleiben unterscheidbar. Mehrere GPOs werden nicht als Ausfuehrungskette oder wirksamer Endgeraetewert dargestellt. Die unmittelbare Quellenzuordnung ersetzt die bisherige Results-only-Verbergung; Results bleibt fuer Varianten erhalten. Die gemeinsame Local-/PostgreSQL-Readprojektion reicht nur bereits gespeicherte Identitaeten/Sequenzen additiv weiter; lesbare GPO-Namen sind nicht gespeichert und werden nicht erfunden. Fehlerursache der fehlenden Conflict-Kennzeichnung: Die alte Ableitung beruecksichtigte nur set-value-Beobachtungen. Versionierte Vergleiche verwenden jetzt den erhaltenen autoritativen customerState; fruehere Anweisungen derselben GPO erzeugen keine zusaetzliche Konfliktzeile und reduzierte identische Beitraege mehrerer Backups bleiben Duplicate. Bei indeterminate bleiben nur durch verschiedene eindeutige Backups und erhaltene Vergleichswerte belegte Unterschiede als Conflict sichtbar; unsichere Backups liefern dafuer keine Einzelwertbeweise. Urteil, Score und historische Re-evaluation-Grenze bleiben erhalten. 20 neue synthetische Regressionen sichern beide Work-Einstiege, Deviation/Conflicts, Suche, Quellenzuordnung, Datensatzwechsel, Identitaeten, Sequenz 0, partielle Konfliktbeweise und unveraenderte Originale. 1.304 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. App und Backend inhaltsfrei gesund geprueft. Kein Reimport, keine automatische Neuauswertung, Datenmigration oder Kundendateninspektion; Projekt zum erneuten Laden der Readprojektion neu oeffnen. Restrisiko: GPO-Namen fehlen weiterhin, Geltungsbereich/Praezedenz und effektiver Endgeraetewert bleiben unbelegt; bestehender Bundlegroessenhinweis. Phasenstatus unveraendert. + +GPO-Wertdarstellung 2026-09-17 (Phase 7, Nutzerwunsch, verifiziert): Operation und Data samt Werten werden im Policy-Vergleich des Finding Readers mit dem gemeinsamen Bold-Token 700 hervorgehoben. Pfadtextboxen, Suchmarkierung, Originaltext und Bewertungslogik bleiben erhalten. Bestehende synthetische Readerregression erweitert; 1.284 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Reine Darstellung ohne Reimport oder Neuauswertung; kein neuer fachlicher Risikoeingriff und Phasenstatus unveraendert. Die Reihenfolge dargestellter Quellen ist weiterhin kein Nachweis einer GPO-uebergreifenden Ausfuehrungsreihenfolge. + +GPO-Quellenfilter 2026-09-17 (Phase 7/13B, ausdruecklicher Nutzerauftrag, verifiziert): Work ergaenzt im GPO-Blatt und bei Source: Scan = GPOs den Filter `GPO backups with failing settings`, mit Gesamtauswahl und einzelnen GPO-Backupinstanzen. Entscheidung: Filter und Processing-Kachel verwenden denselben exakten Projekt-/Assessment-/Backupinstanzschluessel und dieselben Quellen der Fail-Vergleiche; es werden keine Einzel-GPO-Urteile erfunden. Die Auswahl setzt Result Status explizit auf All, damit historische Fail-Vergleiche trotz ihres erhaltenen Review-required-Status sichtbar bleiben; weitere Filter gelten weiter. Source: Scan bleibt zuletzt, inkompatible Filter verschwinden beim Kontextwechsel, native Optionen werden erst vor Pointer-/Tastaturzugriff vollstaendig montiert. Vier neue synthetische Tests sichern 26 Quellen jenseits des allgemeinen Kategorienlimits, Einzel-/Gesamtauswahl, den passenden Mitgliedswert eines gemeinsamen Fail, beide Work-Einstiege, Historie, Statuskombination, Reset, Kontextwechsel, exakte Identitaeten und Cacheinvalidierung. 1.284 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Restrisiko/Lesart: Quellenbeteiligung ist kein eigener Fail jeder GPO; Work ist auf den geladenen Scope begrenzt, die Processing-Kachel bleibt projektweit. Reine Darstellung ueber erhaltene Fakten, kein Reimport, keine Neuauswertung, Migration oder Kundendateninspektion. Phasenstatus bleibt unveraendert; bestehender Bundlegroessenhinweis bleibt. + +GPO-Registry-Zustandsvergleich 2026-09-16 (Phase 7/13B, ausdrueckliche Nutzerentscheidung): Evaluator 1.9.0 behandelt `delete-value`, `delete-all-values`, `create-key` und typisierte leere Zeichenfolgen als ausdrueckliche Sollzustaende statt als `Baselinewert nicht verfuegbar`. Delete-Anforderungen bestehen bei Abwesenheit beziehungsweise passender Delete-Instruktion und schlagen bei einem gesetzten Ziel fehl; Delete-all beruecksichtigt konfigurierte Kindwerte desselben Schluessels. Create-key besteht bei expliziter Anlage oder durch konfigurierte Kindwerte belegter Schluesselanwesenheit und schlaegt bei Abwesenheit fehl. Leere REG_SZ/REG_EXPAND_SZ bleiben vorhandene, typisierte Werte. Schluesselvergleiche speichern alle beitragenden Aggregationszustands- und Beobachtungsreferenzen. Die Regeln gelten nur fuer die analysierte Backup-Konfiguration, nicht fuer effektiven Geraetezustand. Historische Laeufe bis 1.8.0 bleiben unveraendert und benoetigen eine ausdrueckliche Re-evaluation; kein Quelldatei-Reimport, Processing-Manifest- oder SQL-Schemawechsel. 32 fokussierte Comparator-/Evaluatorregressionen sowie exakte Work-Statuspruefungen bestanden; Gesamtlauf mit 1.280 bestandenen Tests und acht uebersprungenen optionalen PostgreSQL-Integrationstests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phasenstatus bleibt in Arbeit. + +GPO-Not-configured im analysierten Backup-Scope 2026-09-16 (Phase 7/13B, Nutzerfehlerbericht): Der Result-Status-Filter war vorhanden, erhielt jedoch fuer einen ausgewaehlten beziehungsweise technisch partiellen GPO-Backupsatz keine Treffer, weil Evaluator 1.7.0 jede dort nicht beobachtete anwendbare Empfehlung pauschal als `Review required` sperrte. Evaluator 1.8.0 klassifiziert diese Abwesenheit jetzt als score-neutrales `Not configured` innerhalb genau des analysierten Backupsatzes und erhaelt `policy-evaluation-customer-absence-scope-limited` als sichtbare Diagnose. Das ist weder eine Aussage ueber die gesamte Domaene noch ueber den effektiven Geraetezustand. Work projiziert das Urteil in den autoritativen Status; die direkte Nutzerinteraktion `Result Status = Not configured` liefert die Zeile und `Deviation` nicht. Historische Evaluationen bis 1.7.0 werden nicht still umgedeutet: Data Hub bietet dafuer die bestehende ausdrueckliche Re-evaluation der erhaltenen Eingaben an; kein Quelldatei-Reimport, Processing-Manifest- oder Schemawechsel. 56 fokussierte GPO-Bewertungs-, Projektions-, Filter- und Panelregressionen sowie die exakte Work-Interaktion bestanden. Vollstaendiger Lauf mit 1.277 bestandenen Tests und acht uebersprungenen optionalen PostgreSQL-Integrationstests, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Phasenstatus bleibt in Arbeit. + +GPO-Analyse-Zaehlebenen bereinigt 2026-09-16 (Phase 7/13B, Nutzerfehlerbericht): Die Data-Hub-GPO-Analyse mischt keine Analyse-Laeufe, Baseline-Vergleichszeilen, technischen Einstellungen, Backups und Diagnoseereignisse mehr in einer scheinbar addierbaren Ergebnisgruppe. `Policy verdicts` zaehlt je Aggregation/Timeslot und technischer Policy-Identitaet genau ein Urteil mit der Prioritaet Fail vor Review required vor Pass vor Not configured; damit koennen mehrere Baseline-Vergleiche derselben Einstellung die fachliche Zahl nicht mehr vervielfachen. Conflict und Duplicate stehen separat als ueberlappende, score-neutrale `Diagnostic flags`. `Analysis gaps` trennt Unresolved identity, Comparison not supported und Baseline mapping unavailable. Die irrefuehrende Bezeichnung `GPO sources` fuer einen Analyse-Lauf sowie der zusammengeworfene Wert `Unsupported settings` wurden entfernt; GPO-Backups mit fehlgeschlagenen Einstellungen stehen als eigene Provenienzkennzahl. Technische Einzelereignisse bleiben in Review Queue und Evaluation History nachvollziehbar, ohne als Findings ausgegeben zu werden. 28 fokussierte GPO-Panel-, Rollup-, Overview- und Statusregressionen, vollstaendiger Lauf mit 1.275 bestandenen Tests und acht uebersprungenen optionalen PostgreSQL-Integrationstests, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Reine Read-/Praesentationsableitung ueber erhaltene Fakten; kein Reimport, keine Bestandsmutation, Schema- oder Manifestaenderung. Phasenstatus bleibt in Arbeit. + +GPO-Verdict mit Diagnose-Badge 2026-09-16 (Phase 7/13B, Nutzerpraezisierung): Work zeigt das fachliche Policy-Urteil weiterhin als primaeren Status und ergaenzt Conflict/Duplicate additiv. Ein fehlgeschlagener Eintrag bleibt deshalb in Status, Filter und Score `Fail`/`Deviation`; in der linken Trefferliste und im geoeffneten Finding steht daneben das sichtbare Badge `CONFLICT` beziehungsweise `DUPLICATE`. Die Diagnose ersetzt das Urteil nicht und erzeugt keinen zweiten Scorebeitrag. Explizit negative Diagnosefelder wie `No`, `None`, `false` oder `0` erzeugen kein Badge. 61 fokussierte Finding-, Reader-, Badge- und GPO-Work-Regressionen sowie Client-/Server-Produktionsbuild erfolgreich; reine Darstellung ueber bereits projizierte Felder, daher kein Reimport, keine Neuauswertung, Schema- oder Manifestaenderung. Phasenstatus bleibt in Arbeit. + +GPO-Policy-Rollup bei Conflicts/Duplicates 2026-09-16 (Phase 7/13B, ausdrueckliche Nutzerpraezisierung, umgesetzt): Mit `Endpunkt` ist die zusammengefasste technische Policy-Einstellung gemeint, nicht ein Server oder Client. Evaluator 1.7.0 vergleicht die erhaltenen konfigurierten Mitgliedswerte eines Kundenkonflikts einzeln. Mindestens ein unabhaengig vergleichbarer In-Scope-Mitgliedswert mit belastbarem Fail macht die gesamte Policy-Einstellung einmalig zu Fail; ein ungeklaertes Mitglied blockiert nur, wenn kein belastbarer Fail vorliegt. Work fuehrt Verdict und Conflict-/Duplicate-Flags getrennt, projiziert keine zweite Diagnosezeile fuer dieselbe ausgewertete Einstellung und laesst dieselbe Zeile zugleich auf Deviation und Conflict/Duplicate filtern. Dashboard-Score und Policy-Impact zaehlen nur das Verdict; Diagnosezaehler werden je technischer Identitaet dedupliziert. `Not configured` bleibt score-neutral. Historische Laeufe bis 1.6.0 bleiben unveraendert und werden ueber den bestehenden Data-Hub-Pfad zur ausdruecklichen Re-evaluation angeboten; kein Scanner-Reimport, Schema- oder Processing-Manifestwechsel. 51 fokussierte Bewertungs-, Work-, Filter- und Duplicate-Regressionen sowie Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 1.270 Tests unmittelbar; die eine geaenderte Duplicate-Regression und der bekannte lastabhaengige Node-Import-Timeout bestanden danach isoliert (14/14), acht optionale PostgreSQL-Integrationstests blieben uebersprungen. App und Backend wurden anschliessend gegen den gesunden kanonischen PostgreSQL-Datastore gestartet und antworten auf 5173/4173 mit HTTP 200. Phasenstatus bleibt in Arbeit. + +GPO-Misconfiguration-Scope und score-neutrale Kontextkategorien 2026-09-16 (Phase 7/13B, ausdrueckliche Nutzerentscheidung): Die normale GPO-Analyse bewertet ausschliesslich tatsaechlich konfigurierte, technisch vergleichbare Kundeneinstellungen im ausdruecklich anwendbaren Microsoft-Baseline-Scope. Eine empfohlene, aber fehlende Einstellung bleibt als `Not configured` sichtbar, erzeugt jedoch weder operatives Finding, Standard-Remediation noch Scoreabzug; eine vollstaendige Baseline-Einfuehrung ist ein separat beauftragter Hardening-Track. `Not configured`, `Duplicates` und `Conflicts` bleiben eigenstaendige score-neutrale Kategorien ausserhalb von Pass und Fail. Ausnahme: Ein konfigurierter Einzelwert innerhalb eines Duplicate-/Conflict-Containers, der bei eindeutiger Identitaet und Baseline fuer sich belastbar fehlschlaegt, zaehlt genau einmal als Fail; Quellmultiplikation und Containerstatus erzeugen oder vervielfachen keinen Fail. Der GPO-Score ist als Konformitaet der konfigurierten, vergleichbaren In-Scope-Einstellungen zu bezeichnen, niemals als vollstaendige Microsoft-Baseline-Compliance. Diese Festlegung ist in AGENTS.md, SCORING_MODEL.md und GPO_BASELINE_EVALUATION.md bindend dokumentiert. Dokumentations-/Vertragsentscheidung ohne Laufzeit-, Daten-, Persistenz-, Schema- oder Bestandsneuauswertung; die Einzel-Fail-Ausnahme muss vor Implementierungsabnahme durch deduplizierte Ergebnisidentitaet, synthetische Conflict-/Duplicate-Fixtures und gegebenenfalls neue Evaluator-/Scoringversion verifiziert werden. Phasenstatus bleibt in Arbeit. + +Work-Filter bei Source All 2026-09-16 (Phase 7, Nutzerfehlerbericht): `Source: Scan = All` zeigt wieder den gemischten Scannerkontext. GPO-exklusive Facetten wie Baseline, Comparison, Conflict, Description source, Diagnostics, Duplicates, Imported, Policy section und Policy type werden dort nicht mehr in die allgemeine Zehnerauswahl aufgenommen und koennen deshalb die Scannerfacetten nicht mehr verdraengen. Der vollstaendige GPO-Filtersatz bleibt unveraendert auf dem GPO-Blatt und bei einer eindeutigen GPO-Quellenauswahl verfuegbar. Beim Wechsel von GPOs zurueck zu All werden nicht mehr sichtbare kontextspezifische Auswahlen entfernt, sodass kein GPO-Filter unsichtbar weiterwirkt. Ein permanenter synthetischer Interaktionstest sichert den exakten Nutzerpfad `Source: Scan = GPOs` -> `Source: Scan = All`; 22 fokussierte Filter-/Interaktionstests, 1.272 Gesamttests, acht uebersprungene optionale PostgreSQL-Integrationstests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Reine Praesentations-/Filterzustandskorrektur ohne Daten-, Import-, Bewertungs-, API-, Persistenz-, Schema-, Manifest- oder Reimportaenderung; Phasenstatus unveraendert. + +Work-Ansichtssnapshots 2026-09-16 (Phase 7, Nutzerfehlerbericht): Ein Work-Snapshot speichert wieder die vollstaendig wirksame, gerade angezeigte Ansicht. Neben Blatt, Darstellungsmodus, Suche, Sortierung, Result Status, Facetten, My Workspace und aktueller Auswahl gehoert nun auch der durch Client-Info-/Pathfinder-Drilldowns gesetzte Finding-Scope zum gespeicherten Ansichtsstand; beim Oeffnen wird eine unabhaengige Kopie dieses Scopes atomar wiederhergestellt. Vorhandene Snapshots ohne Scopefeld bleiben lesbar und bedeuten wie bisher keine zusaetzliche Finding-Einschraenkung. Ein permanenter synthetischer Interaktionstest sichert den exakten Nutzerpfad Snapshot -> Name -> Save -> gespeicherten Snapshot oeffnen. Acht fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 1.270 Tests, acht optionale PostgreSQL-Integrationstests wurden uebersprungen; der bekannte kombinierte Node-Importtest ueberschritt unter Gesamtlast einmal sein unveraendertes Fuenf-Sekunden-Limit und bestand isoliert mit 5/5 Tests in 4.709 ms. Local-only-/Designpruefung erfolgreich. Reine lokale Ansichtsstatuskorrektur ohne Daten-, Import-, Bewertungs-, Backend-, Persistenzschema-, Processing-Manifest- oder Reimportaenderung; Phasenstatus unveraendert. + +Work-Standardfilter 2026-09-15 (Phase 7, ausdrueckliche Nutzerentscheidung): `Result Status` startet beim normalen Einstieg in Work, beim Projekt-/Timeslot-/Blattwechsel, nach Importabschluss und nach Reset immer mit `Deviation`. Der bisherige GPO-Sonderfall mit automatischem `All` ist damit ausdruecklich ersetzt. Kommt der Einstieg dagegen aus Client Info, Pathfinder oder einem anderen Drilldown mit bereits gesetztem Such-, Facetten-, Pfad- oder Action-Filter, bleibt dieser Kontext einschliesslich eines dort bewusst gesetzten Status erhalten. Die normale Work-Navigation unterscheidet diese beiden Pfade jetzt explizit; eine GPO-Quellenauswahl setzt den Status nicht mehr eigenmaechtig auf `All`. Permanente synthetische Interaktionstests sichern normalen Einstieg, Client-Info-Filteruebergabe, GPO-Quelle, GPO-Blatt und expliziten GPO-Drilldown. Verifiziert mit 1.270 bestandenen Tests und acht uebersprungenen optionalen PostgreSQL-Integrationstests, Local-only-/Designpruefung sowie erfolgreichem Client-/Server-Produktionsbuild. Reine Zustands-/Navigationskorrektur ohne Daten-, Import-, Bewertungs-, Persistenz-, Schema-, Manifest- oder Reimportaenderung. + +GPO-Importstatus ohne manuelle Review-Aufforderung 2026-09-15 (Phase 7/13B, ausdrueckliche Nutzerkorrektur): Ein technisch partieller GPO-Verarbeitungslauf wird im Timeslot wieder als `Limited analysis` dargestellt. Er fordert weder zur manuellen Einzelpruefung hunderter GPOs auf noch erzeugt er daraus eine automatische Arbeitsaufgabe. Damit gilt die bereits am 2026-09-06 festgelegte Trennung zwischen gelber technischer Analysegrenze und echtem Handlungsbedarf erneut; die zwischenzeitliche Beschriftung `Partial · review required` war eine irrefuehrende UI-Regression und ist durch diese Entscheidung ersetzt. Die fail-closed Fachgrenze bleibt unveraendert: Nicht vollstaendig automatisch auswertbare Bereiche werden nicht als vollstaendig bewertet, aber auch nicht als manuelle Pflicht dargestellt. Exakte synthetische Renderregression prueft `Limited analysis` sowie die Abwesenheit von `review required` und `Imported`; 17 fokussierte Status-/Readiness-Tests, Gesamtlauf mit 1.268 bestandenen und acht uebersprungenen optionalen PostgreSQL-Tests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, Bewertungs-, Persistenz-, Schema-, Manifest- oder Reimportaenderung. + +GPO-Analysezaehler 2026-09-15 (Phase 7/13B, Nutzerfehlerbericht): Die Ergebniszusammenfassung in Data Hub bindet ihre Vergleichsprojektion nun wie der Timeslot-Workspace an die vom Backend als aktuell ausgewiesenen Aggregationslaeufe. Ein historisch aufbewahrter Evaluationslauf aus einer ueberholten Aggregation kann dadurch nicht mehr gleichzeitig mit dem aktuellen Lauf in Misconfigured, Pass oder Not configured eingehen; die Historie bleibt ausschliesslich unter den technischen Evaluationsdetails sichtbar. `Review required` wird in der Baseline-Zusammenfassung explizit ausgewiesen, damit ein partieller GPO-Backupsatz und nicht belegte Abwesenheit nicht als bestaetigtes Not configured erscheinen. Permanente synthetische Komponentenregression bildet exakt einen Timeslot mit aktueller und historischer Aggregation ab. 26 fokussierte GPO-/Workspace-Tests und Client-/Server-Produktionsbuild erfolgreich. Gesamtlauf: 1.267 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; der bekannte kombinierte Node-Importtest ueberschritt unter Gesamtlast einmal sein unveraendertes Fuenf-Sekunden-Limit und bestand isoliert mit 5/5 Tests in 3.885 ms. Bestehender Bundlegroessenhinweis. Reine Read-/Praesentationskorrektur ohne Persistenz-, Bewertungs-, Import-, Schema-, Manifest- oder Reimportaenderung; keine Kundendatenmutation. + +Timeslot-Importlast 2026-09-15 (Phase 13 sowie Persistenz aus Phase 9-11): Ein gemeldeter Scannerimport wurde ausschliesslich ueber technische Audit-, Laufzeit- und Prozesssignale untersucht. Die Vorschau war nach 4,4 Sekunden abgeschlossen, waehrend der atomare Abschluss 200,3 Sekunden benoetigte. Gleichzeitig erzeugten dauerhaft montierte Data-Hub-Steuerelemente in fuenf Minuten 270 vollstaendige Result-Facettenabfragen und 326 GPO-Statusabfragen; auch reine Timeslot-Importknopfe mit `showStatus=false` pollten alle zwei Sekunden, und der globale Fuenf-Sekunden-Poll berechnete die Oeffnungsbereitschaft fuer alle Timeslots ohne Zustandsaenderung neu. Inaktive Importsteuerelemente fragen nun keinen Status ab, sichtbare Statusbereiche pollen nur bei queued/running, der Data Hub pollt nur Projekte mit laufenden GPO-Jobs und behaelt unveraenderte Status-/Readiness-Objekte. Teure Facetten werden erst nach einer wirklichen GPO-Statusrevision neu berechnet. Der PostgreSQL-Commit verwendet zusaetzlich einmalig aufgebaute Datei-/Definitionsindizes statt wiederholter linearer Suchen je Finding; Transaktion, Originalwerte, Klassifikation und Schema bleiben unveraendert. Permanente synthetische Interaktionstests sichern null Statusabfragen eines inaktiven Timeslot-Importknopfs und genau einen Abruf eines sichtbaren abgeschlossenen Status. 30 fokussierte Import-/Persistenz-/UI-Tests und beide TypeScript-Pruefungen erfolgreich. Gesamtlauf: 1.266 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; der bekannte kombinierte Node-Importtest ueberschritt unter Gesamtlast einmal sein unveraendertes Fuenf-Sekunden-Limit und bestand isoliert in 3.887 ms. Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Kundendateninspektion, Datenmutation, Migration, Processing-Manifest- oder Reimportaenderung. Restrisiko: Die relationale Persistenz sendet Datensaetze weiterhin einzeln an PostgreSQL; falls ein ruhiger synthetischer Lasttest nach dieser Lastkorrektur noch einen relevanten Commitanteil zeigt, ist gebuendeltes Schreiben ein eigener vertragserhaltender Folgeschritt. + +Verifikation GPO-Verarbeitungskorrektur 2026-09-15: 1.265 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-Sicherheitspruefung, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Die fokussierten Tests sichern 65 Bewertungs-, Versions-, Work- und Statusfaelle. Das laufende Backend meldet fuer den betroffenen 184-GPO-Lauf technisch `partial` und bietet nach dem Enginewechsel genau ein Update von 1.5.0 auf 1.6.0. Read-only-Browserpruefung zeigt im betroffenen Timeslot `Re-evaluation required` mit dem vorhandenen `Re-evaluate`-Bedienelement. Es wurde nicht ausgeloest; keine Kundendatenmutation. + +GPO-Verarbeitung statt globalem Review 2026-09-15 (Phase 7/13B): Der gemeldete Clientzustand wurde ausschliesslich ueber technische Status-, Zaehler- und Diagnosecodes untersucht. Der GPO-Import enthielt 184 Backupinstanzen und stand serverseitig auf partial, waehrend Data Hub irrefuehrend nur Imported anzeigte. Evaluator 1.5.0 versah alle aktuellen Vergleiche mit `policy-evaluation-baseline-incomplete`, weil globale Baselineparser-Diagnosen aus Security Templates auch separat aufgeloeste Registry-Policy-Kandidaten blockierten. Evaluator 1.6.0 begrenzt partielle Parserdiagnosen auf den betroffenen Bereitstellungsmechanismus: korrekt gelesene Registry-Werte bleiben vergleichbar, Security-Template-Lesefehler blockieren weiterhin Security-Template-Kandidaten, und unbekannte Diagnosen bleiben fail-closed. Fehlende Kundenwerte bleiben ohne nachgewiesenen vollstaendigen Backupsatz Review required; es werden keine Abwesenheit oder Abweichung erfunden. Data Hub bezeichnet einen partiellen GPO-Lauf jetzt sichtbar als `Partial · review required` statt `Imported`. Permanente synthetische Regressionen sichern Pass und Deviation fuer den unabhaengigen Registry-Pfad, die bestehenden Sicherheitsgrenzen und den gerenderten partiellen Status. Historische 1.5.0-Laeufe bleiben unveraendert und werden durch den bestehenden Data-Hub-Versionspfad zur ausdruecklichen Re-evaluation angeboten. Keine automatische Bestandsneuauswertung, Datenmutation, Quelldateiinspektion, SQL-Migration oder Scanner-Reimportaenderung; Phasenstatus unveraendert. + +Verifikation Dummy-Anzeigekorrektur 2026-09-14: Abschliessend `npm test` mit 1.263 bestandenen und acht optional uebersprungenen PostgreSQL-Tests; Local-only-/Designpruefung sowie `npm run build` fuer Client und Server erfolgreich. Zwei zuvor fehlgeschlagene Quelltext-Strukturpruefungen wurden an die durch Verhaltenstests gesicherte neue GPO-Navigation angepasst; ein Import-Test-Timeout im ersten Gesamtlauf bestand isoliert und im unveraenderten abschliessenden Gesamtlauf. App, Entwicklungsserver und Backend antworten mit HTTP 200; die App liefert das neu gebaute Frontend aus. Live-Browserkontrolle ausschliesslich am freigegebenen Dummy, keine anderen Clientinhalte gelesen; temporaerer Prueftab geschlossen. + +GPO-Anzeige am freigegebenen Dummy 2026-09-14 (erneute Nachkorrektur, Phase 7/13B): Die vorherige Anzeige-Nachkorrektur erfasste nur die GPO-Quellkachel, nicht den normalen Source-Dropdown. Der ausdruecklich freigegebene Dummy bestaetigte den verbleibenden Fehler: Client Source GPOs -> Work behielt Deviation und zeigte null Treffer. Die gemeinsame App-Zustandsgrenze initialisiert eine neue eindeutige GPO-Source-Auswahl sowie ein GPO-Blatt jetzt mit All; spaetere ausdrueckliche Statusauswahlen bleiben auch bei null Treffern erhalten. Eine Domain mit ausschliesslichem Pruefbedarf zeigt dessen Anzahl und oeffnet genau diese gespeicherten Ergebnisse; vorhandene Deviation-Drilldowns bleiben unveraendert. Live am Dummy verifiziert: beide Source-Auswahlwege zeigen 3.873 GPO-Datensaetze; der Domain-Link oeffnet 3.872 Review-Ergebnisse; Passed bleibt gezielt mit null Treffern waehlbar. Die gespeicherte aktuelle Evaluation 1.5.0 enthaelt selbst Review-required-Urteile mit unvollstaendiger Baseline-Evidenz, nicht nur historische Urteile. Daher werden weder aktuelle Pass-/Fail-Urteile noch ein Score aus alten Laeufen rekonstruiert. Vier permanente synthetische Interaktionstests mit echtem AppProvider sichern Client-Dropdown, Work-Dropdown, GPO-Blatt und Domain-Link einschliesslich expliziter Nulltreffer-Auswahl. Nur Praesentation/Navigation; keine Neuauswertung, Datenmutation, Import-/Reimport- oder Bewertungsregel-Aenderung. Die bisherigen Verifikationsaussagen waren fuer den normalen Dropdown-Pfad unzureichend; Phasenstatus unveraendert. + +GPO-Anzeige nach Evaluatorwechsel 2026-09-14 (Nachkorrektur, Phase 7/13B): Der anschliessende Nutzer-Screenshot widerlegte die vorherige Aussage, die Timeslotkorrektur habe den gemeldeten Anzeigeausfall vollstaendig behoben. Geladene historische GPO-Vergleiche wurden als Review required zurueckgehalten, im Dashboard aber als fehlende Evidenz gezaehlt; der Source-Drilldown setzte Deviation und fuehrte damit in eine leere Work-Ansicht. Client Info unterscheidet jetzt ausstehende Neuauswertung, aktuellen manuellen Pruefbedarf und fehlende Evidenz. Die GPO-Quellkachel oeffnet All; explizite Statusaktionen behalten ihre Filter. Work zeigt bei null Filtertreffern den vorhandenen Datenbestand und bietet eine Aktion zum Anzeigen aller Ergebnisse unter Beibehaltung der gewaehlten Quelle. Die verbindlichen sechs GPO-Statusoptionen bleiben erhalten. Sieben synthetische Interaktionstests sichern die historischen Versionen 1.3.3/1.4.0, den aktuellen Pruefzustand und den Auswahl-/Wiederherstellungspfad in allen vier Work-Ansichten. Explizite Nutzerentscheidung dieses Schritts: nur Anzeige korrigieren, keine reale Neuauswertung. Historische Werte werden nicht als aktuelle Pass-/Fail-Urteile oder Scores ausgegeben; keine Persistenz-, Import- oder Reimportaenderung. Phasenstatus unveraendert. + +Verifikation der Anzeige-Nachkorrektur: 1.258 Tests im Gesamtlauf bestanden, acht optionale PostgreSQL-Tests uebersprungen. Ein bestehender Blattauswahl-Performance-Test ueberschritt unter Gesamtlast sein unveraendertes Fuenf-Sekunden-Limit und bestand isoliert in 2.409 ms. Alle sieben neuen Interaktionstests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Der laufende Entwicklungsserver liefert beide korrigierten UI-Module mit HTTP 200; ihre Auslieferung wurde anhand von Code-Markern ohne Domaininhalte bestaetigt. Keine reale Neuauswertung oder Datenmutation. + +GPO-Anzeige im gemischten Timeslot 2026-09-14 (Phase 7/13B, Nutzerfehlerbericht): Beim Oeffnen eines Timeslots mit Scannerlaeufen und separat assessmentgebundenen GPO-Ergebnissen bleibt der vollstaendige Assessment-Scope jetzt neben dem eingeschraenkten Scanner-Run-Scope erhalten. Data Hub und die automatische Work-Timeslotauswahl reichen beide Identitaeten weiter; der gemeinsame Workspace-Loader verwendet die ausdruecklich gewaehlten Assessments fuer Policy-Beobachtungen. Dadurch erscheinen dieselben GPO-Ergebnisse wieder in Client Info und Work, ohne fremde Scannerlaeufe einzubeziehen. Synthetische Interaktions- und Loaderregression fuer den zuvor defekten Mischpfad sowie 27 fokussierte GPO-/Navigationstests und Client-/Serverbuild erfolgreich; Gesamtlauf mit 1.252 bestandenen und acht uebersprungenen Tests sowie Local-only-/Designpruefung erfolgreich. Reine Lade-/Praesentationskorrektur ohne Import-, Persistenz-, Score-, Schema- oder Reimportaenderung; Phasenstatus unveraendert. + +GPO-Baselinevarianten 2026-09-14 (Phase 7/13B, ausdruecklicher Nutzerauftrag): Evaluator 1.5.0 ersetzt die pauschale Sperre bei unterschiedlichen Sollwerten durch unabhaengige, typisierte Einzelvergleiche. Alle Varianten bestanden ergibt Pass; konfiguriertes IST gegen alle Varianten abweichend ergibt Fail; gemischte, unlesbare oder unvollstaendige Evidenz bleibt Review required. Fehlende Einstellungen ergeben nur bei belegter Satzvollstaendigkeit Not configured. Kein PingCastle erforderlich; OS-/DFL-Inventar waehlt keine GPO-Zielrolle. Widerspruechliche Werte derselben Baseline-GPO sind keine Rollenalternativen. Versionierte Originalwerte, Einzelurteile und Settingreferenzen bleiben in Ergebnis-JSON/JSONB erhalten; Work, Result DB und Export zeigen keine erfundene Baselinevereinigung. Die bestehenden fuenf GPO-Statusfilter bleiben unveraendert; Review required ist unter All sichtbar. Historische Runs 1.3.3/1.4.0 bleiben lesbar und verlangen die vorhandene explizite Data-Hub-Neuauswertung. Keine SQL-Migration, Scanner-Manifestversion, Kundendateninspektion oder reale Neuauswertung. Vertrag und Grenzen: [GPO_BASELINE_EVALUATION.md](GPO_BASELINE_EVALUATION.md). Verifikation siehe datierter Protokolleintrag; Phase 13B bleibt in Arbeit. + +GPO-Work-Filterkontext 2026-09-14 (Phase 7/13B, Nutzerkorrektur und verbindliche Vorgaben): Eine eindeutige Auswahl `Source: Scan = GPOs` gilt nun auch auf dem projektweiten All-Records-Blatt als reiner GPO-Werkzeugkontext. Facetten werden vor allgemeiner Priorisierung und Zehnerlimit auf den GPO-Vertrag reduziert: Result Status, die verfuegbaren neun GPO-Fachfacetten und der dauerhaft letzte workspaceweite Source-Filter. Das Statusmenue wird aus dem festen GPO-Vertrag erzeugt und enthaelt auch dann ausschliesslich All, Deviation, Passed, Not configured, Conflicts und Duplicates, wenn kein separates GPO-Blatt geladen ist; die fuenf fachlichen Werte bleiben bei null Treffern waehlbar. GPO-Statusfilter lesen ausschliesslich das aktuelle Feld `Status`; ein `Pass` in Comparison, Historical result, Baseline, Guidance oder Evidence darf niemals einen aktuell als Not configured, Conflict, Duplicate oder Deviation klassifizierten Datensatz unter Passed aufnehmen. Scanner-, CIS-, Severity-, Category-, MITRE-, Target-, Result-message- und Reviewfacetten sowie deren Statusvokabular erscheinen nicht. Bereits gesetzte, im GPO-Kontext ungueltige Facetten werden entfernt, damit kein unsichtbarer Fremdfilter weiterwirkt; nach Aufhebung der Quelle kehrt der Mischkontext zurueck. Die synthetischen Regressionen pruefen den zuvor defekten Auswahlweg ohne separates GPO-Blatt, die Wirksamkeit eines zuvor vom Mischlimit verdraengten GPO-Filters, einen Not-configured-Datensatz mit fremdem Pass-Vergleichswert und die Rueckkehr; 51 fokussierte Filter-/Profil-/GPO-Pruefungen sowie der Gesamtlauf mit 1.243 bestandenen und acht uebersprungenen Tests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Reine Praesentations- und Filterkontextkorrektur ohne Import-, Persistenz-, API-, Score- oder Reimportaenderung. Die Projektvorgaben behandeln dokumentierte Nutzerentscheidungen jetzt ausdruecklich als bindende Abnahmekriterien: spaetere Arbeiten duerfen sie nicht still abschwaechen; Konflikte mit Regeln sind vor einer Umsetzung transparent zu melden und Regelanpassungen benoetigen Nutzerzustimmung. Phasenstatus unveraendert. + +GPO-Neuauswertung und OS-Inventar 2026-09-11 (Phase 7/13B/13C, Nutzerauftrag): Data Hub erhaelt einen vom Scanner-Reimport getrennten Hinweis und eine explizite Re-evaluate-Aktion fuer gespeicherte GPO-Vergleiche mit alter Engine. Die Zuordnung folgt ausschliesslich aktiven Profil-/Snapshot-/Identity-/Artefaktreferenzen; ueberholte Verarbeitungsketten erzeugen keinen falschen Hinweis. Der bestehende API-Aufruf wertet gespeicherte Eingaben aus und behaelt historische Runs. Die abgeleitete Bereitschaft ist je Repository revisionsgebunden und auf 128 Projekte begrenzt gecacht; unveraenderte Statusabrufe lesen keine Evaluationen erneut. Work zeigt alte Ergebnisse als Review required mit separatem Historical result, prominentem Versionshinweis und neutralen gespeicherten Ist-/Sollwerten. Fehlende Beschreibung und Ladefehler sind getrennt. Client Info ersetzt die kommagetrennte OS-Zeile durch Servers, Clients und Other / unclassified mit OS-Anzahlen und nur bei eindeutiger Datenbasis einer Gruppensumme. PingCastle-Name und Nb OS werden ueber exakten Lauf, Datei, Sektion, gespeicherten Quelltabellenindex und Zeile verbunden; ueberlappende Inventare werden nicht addiert, unbekannte Anzahlen bleiben ein Gedankenstrich. Originalwerte, Importprofile, Scores und Persistenzschema bleiben unveraendert; kein neuer Processing-Vertrag oder Reimport fuer diese Darstellung erforderlich. Verifiziert: 1.238 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Zusaetzlich synthetischer Import-bis-OS-Anzahl-Test und Browserpruefung bei 640/320 Pixeln ohne Inventarueberlauf sowie Statusaktionswechsel/historische Neutraldarstellung; temporaere Vorschau entfernt. Zwischenzeitliche Buildfehler im parallel bearbeiteten Timeslot-Vertrag waren beim abschliessenden Build behoben, ohne diese fremden Aenderungen zu bearbeiten. Keine Realdateninspektion, Neuauswertung oder Datenmutation; laufendes Backend nur technisch auf HTTP 200 geprueft und nicht neu gestartet. Fuer den neuen Backend-Statusvertrag ist dessen Neustart erforderlich. Phasenstatus unveraendert. + +Timeslot-Vergleich P0-P2 2026-09-11 (Phase 8, Nutzerauftrag): P0 ist abgeschlossen. Der additive Vertrag `timeslot-comparison` 1.0.0 trennt Regeldefinition, scope-/objektbezogene Vergleichsidentitaet, Reportzeit, Gegenpruefung und Verpflichtung. Jedes registrierte Profil deklariert nun Scope, Zeitquelle, Ergebnisart und Negativnachweis; die aktuellen Scanner bleiben scopeweit, Generic ist nicht automatisch vergleichbar und Abwesenheit beweist nirgends automatisch Behebung. P2 ist mit einer sicheren Scannerpaarung begonnen: echte Tool-/Run-/File-Provenienz, Processingvertrag, eindeutiger Scope, neue Reportzeit und Diagnosen werden vor Fail-to-Pass geprüft; fehlende Quelle, bloße Abwesenheit und Reimportzeit bleiben ungeklärt oder nicht vergleichbar. 23 fokussierte synthetische Tests sowie Client-/Serverbuild erfolgreich. Der ausdrücklich freigegebene Mandant Dummy wurde ergänzend nur lesend geprüft und bestätigt die konservativen Grenzen; keine Datenmutation. P1 bleibt wegen Persistenz/API/Übergang offen, P2 wegen GPO/Historie/Integration offen, P3-P6 offen. Kein Processing-Manifest oder Reimport, da keine importierten Fakten geändert werden; bisherige Produktengine und UI sind noch nicht umgestellt. + +Verifikation dieses Schnitts: Projektweiter Lauf mit 1.240 bestandenen Tests und acht übersprungenen optionalen PostgreSQL-Tests. Der bekannte fachfremde kombinierte Node-Importtest überschritt unter Gesamtlast einmal sein unverändertes Fünf-Sekunden-Limit und bestand isoliert mit 5/5 Tests in 3.661 ms. Local-only-, Designsprache-, Client- und Serverprüfung sind erfolgreich; kein Testlimit wurde erhöht. + +Client-Info-Risikoregister 2026-09-11 (Phase 7, Nutzerauftrag): Client Info zeigt unter den bestehenden Informationsbereichen eine eigene Accepted-Risks-Kachel. Das Register dedupliziert dieselbe kanonische Finding-Vorkommnis ueber mehrere Blattprojektionen, listet links alle gespeicherten Risikentscheidungen mit Quelle, abgeleitetem Zustand und Wiedervorlage und zeigt nach Auswahl rechts den vollstaendigen aktuellen Entscheidungsinhalt sowie die unveraenderte Versionshistorie. Accepted, Scheduled, Review due, Review required, Draft, Expired und Revoked bleiben unterscheidbar; lange Inhalte werden nicht gekuerzt. Breite Ansichten verwenden die verlangte Liste-/Detailteilung, schmale Ansichten stapeln beide Bereiche. Die Darstellung liest ausschliesslich bereits geladene Reviewdaten; keine API-, Persistenz-, Scanner-, Score- oder Reimportaenderung. Zwei neue synthetische Registertests, 18 fokussierte Dashboard-/Accepted-Risk-Tests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Gesamtlauf: 1.218 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; ein kombinierter Node-Importtest ueberschritt unter paralleler Last einmal sein unveraendertes Fuenf-Sekunden-Limit und bestand isoliert in 4.971 ms. Synthetische Browserpruefung bestaetigt Auswahlwechsel, vollstaendige Detailanzeige, Umbruch und schmale Stapelung; temporaere Vorschau entfernt. Keine Realdateninspektion oder Datenmutation; Phasenstatus unveraendert. + +Mehrdatei-Reimportstatus 2026-09-11 (Phase 7, Nutzerfehlerbericht): Die Bereitschaftsanzeige bewertet gespeicherte Verarbeitungskontrakte gemeinsam je exaktem Scanlauf. Generische Begleitdateien neben genau einem erkannten Scannerprofil erzeugen bei gueltigen Vertraegen keinen falschen Pruefstatus mehr; andere Laeufe, echte Versions-/Kompatibilitaetsfehler und nicht eindeutig uebertragene Kundenreviews bleiben getrennt beruecksichtigt. Reine Pruefhinweise bieten keinen wirkungslosen erneuten Reimport an. Keine Umklassifizierung, Extraktions-/Mappingaenderung oder Datenmutation; kein neuer Processing-Vertrag und kein Reimport erforderlich. Synthetischer 22-CSV-Import samt erneutem Import und serialisierten Dateirecords sowie Schutzfaelle bestehen in 13 fokussierten Tests. Gesamtpruefung: 1.216 bestanden, acht optionale DB-Tests uebersprungen, ein fachfremder Auswahllisten-Test am Zeitlimit gescheitert; isolierte Wiederholung besteht in 1.838 ms ohne Limitaenderung. Local-only-/Designchecks und Client-/Serverbuild erfolgreich. Laufende App liefert das korrigierte Statusmodul mit HTTP 200; keine Live-Inhaltsinspektion. Phasenstatus unveraendert. + +CSV-Workerstart 2026-09-11 (Phase 13, Nutzerfehlerbericht): Der isolierte Importworker initialisierte fuer jede CSV auch die vollstaendige jsdom-Abhaengigkeit innerhalb seines 30-Sekunden-Budgets. Der Node-Markupadapter laedt die fest benannte lokale Bibliothek jetzt erst beim tatsaechlichen DOM-Bedarf; CSV/JSON/Excel und begrenzte lexikalische HTML-Verarbeitung vermeiden diese Startlast. Parsergrammatik, Extraktion, Mapping und gespeicherte Fakten bleiben identisch; deshalb kein neuer Processing-Vertrag oder pauschaler Reimportbedarf. Der konkrete gemeldete Timeout wurde ohne Realdatenzugriff nicht reproduziert; die unnoetige DOM-Initialisierung wurde im gebauten Worker vor dem Fix durch einen fehlschlagenden Kostentest nachgewiesen. Nach dem Fix verarbeitet `node tests/server/import-worker-startup-check.mjs` 22 synthetische Domain-CSVs mit vollstaendigem Originalwertabgleich in beobachteten 14.170 ms ohne DOM-Laden, bei unveraenderten Zeit-/Speicherlimits. Laufendes Backend: synthetischer Parse-only-Aufruf HTTP 200 in 515 ms, Repositoryrevision unveraendert. 1.214 Tests bestanden, acht optionale DB-Tests uebersprungen; Local-only-/Designchecks und beide Builds erfolgreich. Kein Backendneustart, keine Realdatenmutation; Phasenstatus unveraendert. + +Accepted-Risk-Speicherpruefung 2026-09-11 (Phase 7 mit bestehender Persistenz aus Phase 9-11, Nutzerpraezisierung): `Save draft`, `Record acceptance` und `Revoke acceptance` speichern nicht mehr unmittelbar nach der Formularvalidierung, sondern zeigen zuerst einen kompakten ASSESSOR-Pruefbericht der tatsaechlich ausgefuellten Angaben. `Change` kehrt ohne Eingabeverlust in die Maske zurueck; `OK` fuehrt erst dann die bestehende geschuetzte Speicheroperation aus. Fehler erhalten alle Eingaben, erfolgreiche Speicherung wird im Formular ausdruecklich bestaetigt. Keine Aenderung an Review-JSONB, API, Validierung, Reimportvertrag oder Datenbankschema. Verifikation: sechs fokussierte Domain-/Dialogtests, 1.214 Gesamttests, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich. Phasenstatus unveraendert. + +Accepted Risk 2026-09-10 (Phase 7 mit Persistenz/API aus Phase 9-11 und Sicherheit aus Phase 13, Nutzerauftrag): Button im Findingheader und strukturierter Dialog fuer Scope, Risikoszenario, Begruendung/Alternativen, initiales und verbleibendes Risiko, kompensierende Kontrollen, Verantwortliche, getrennte externe Freigabedokumentation, Nachweise, Befristung, Wiedervorlage und Ausstieg implementiert. Entwurf, Annahme und Widerruf erzeugen vollstaendige Versionen im bestehenden Review-JSONB; Same-Origin-API mit Projektpruefung, serverseitiger Validierung und atomarer Revisionspruefung. Native Befunde und Scores bleiben erhalten. Reimport erhaelt die Historie, fordert fuer einen anderen Zielbefund aber erneute Pruefung. Ablagevertrag und geplanter Ausbau in `docs/RISK_ACCEPTANCE.md`; keine SQL-Migration oder Realdatenmutation. Verifikation: 1.214 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Synthetische Browserpruefung bestaetigt Dialog, Pflichtfeldsperre und fehlerfreie Breite; temporaere Vorschau entfernt. Frontend und Backend-Health antworten HTTP 200. Keine reale Datenbank-Schreibprobe. Phasenstatus unveraendert. + +Reimport-Schutz 2026-09-10 (Phase 6/8/9/13C mit Phase-7-Hinweis, ausdruecklicher Nutzerauftrag): Verarbeitungsrelevante Aenderungen an Formaterkennung, Parser/Extractor, Scannerprofil, stabiler Identitaet, Mapping, Normalisierung, Status-/Evidenzvertrag oder nativer Scoregewinnung muessen ueber append-only Processing-Manifeste versioniert und fuer bestehende Importe als Reimportbedarf sichtbar werden; reine Darstellungsaenderungen auf bereits gespeicherten Daten benoetigen keinen Reimport. Generische/tabellarische Importe ohne belastbares Profil erscheinen vorsorglich als gelber Pruefstatus. Direkter Reimport und die Uebernahme eines bereits importierten Ersatzlaufs uebertragen kundenbezogene Finding-Reviews atomar in lokaler und PostgreSQL-Persistenz. Die Zuordnung verwendet ausschliesslich die eindeutige stabile Identitaet aus Scannerwerkzeug, nativer Regel-ID und betroffenem Asset; bei fehlender oder mehrdeutiger Zuordnung wird nicht nach Titel oder Position geraten. Der vollstaendige Reviewvertrag wird kopiert und erhaelt dadurch Status, Prioritaet, Action-Plan-Zuordnung, Owner, Termin, Kommentar, Voraussetzungen, Zugriffe, naechsten Schritt, Akzeptanzevidenz, Marker/Accepted Risk sowie spaetere additive JSON-Felder. Bereits vorhandene Angaben am Ersatzlauf haben Vorrang. Nicht eindeutig uebertragbare Angaben bleiben am auditierbar erhaltenen Ursprungslauf gespeichert; Anzahl und dauerhafter `Review required`-Hinweis werden am Ersatzimport persistiert. Original-SHA, Vorgaengerbezug und Uebertragungsherkunft bleiben nachvollziehbar. Regeln und Szenarien stehen in `docs/REIMPORT_POLICY.md`. Verifikation: 1.205 Tests bestanden, acht optionale Tests uebersprungen; Local-only- und Designpruefung erfolgreich. Keine SQL-Migration, Realdateninspektion oder kanonische Datenmutation; Phasenstatus unveraendert. + +Purple-Knight-Scorezuordnung 2026-09-10 (Phase 7/13C, Nutzerkorrektur): Eine native score-only Assessment Summary und die eindeutige Findings-Datei desselben Scanlaufs werden nun ueber Assessment, Werkzeug, Scanlauf und Verarbeitungskontrakt verbunden. Der native Wert bleibt der Scorebeitrag; Passed-/Deviation-Zahlen stammen aus der Findings-Datei. Die Zuordnung scheitert geschlossen bei mehreren nativen Traegern oder mehrdeutigen Ergebnispopulationen. Die synthetische Regression mit nativ 65, 96 Passed und 19 Deviations liefert in der Dashboardprojektion 65 Native score statt Pass rate 83 und behaelt 19 Deviations. 1.199 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designchecks sowie Client-/Serverbuild erfolgreich. Keine Datenmutation, Migration, Realdateninspektion oder Backendneustart; Phasenstatus unveraendert. + +Native Scores fuer weitere Scanner 2026-09-10 (Phase 6/13C mit Phase 7, Nutzerpraezisierung): Jedes deklarative Scannerprofil enthaelt jetzt verpflichtend eine versionierte Scoredefinition mit nativen Gesamtwertfeldern, Skala, Richtung und Fallbackpopulation oder einer begruendeten Nichtverfuegbarkeit. Die gemeinsame Berechnung liest den Profilkatalog statt einer separaten Scannerliste; neue Profile erhalten automatisch den nativen Vorrang. Zehn neue synthetische Regressionen sichern den Profilvertrag und einen zusaetzlichen Scanner einschliesslich Dashboardprojektion, Nullwert, Risikoinversion, fehlerhaften/fremden Werten und Findings-only-Fallback. 1.198 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designchecks und Client-/Serverbuild erfolgreich. Vorhandene Scoremethoden, Importversionen und Daten bleiben unveraendert; Phasenstatus unveraendert. + +Hybridscore 2026-09-10 (Phase 7/13C mit Phase-8-Vergleichsschutz, ausdruecklich freigegeben): Regel 1.0.0 verwendet den exakt datei-/laufgebundenen nativen Purple-Knight-/CIS-CAT-Score beziehungsweise `100 - PingCastle-Risiko`, sonst eine belastbare Bestehensquote. Feste Quellgewichte, verifizierte Lauf-/Hash-Deduplikation, ungerundete Berechnung und gekennzeichnete Datenluecken verhindern doppelte oder still falsch zugeordnete Beitraege. Security Domains heissen Pass rates; Source Overview und der neue Methodikdialog zeigen Beitrag, Verfahren, Gewicht, Pruefbasis und Quellzeit. Neue Assessments speichern die Regel im bestehenden JSON/JSONB-Vertrag; fehlende historische Angaben bedeuten dauerhaft Version 1.0.0. Historische offene Scannerverpflichtungen werden fuer den Scorevergleich read-only mit Herkunft fortgefuehrt, Fortschritt nur bei unveraendertem Scope/Verfahren und aktueller Evidenz berechnet. Das weitergehende persistierte Phase-8-Backlog-/Retirement-Arbeitspaket bleibt offen. Entscheidungsregeln, Herstellerbelege und Grenzen stehen in `docs/SCORING_MODEL.md`. Verifikation: 1.188 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designchecks und Client-/Serverbuild erfolgreich; die vorbestehende TS7016-Blockade wurde durch die fehlende Typdeklaration der synthetischen HTML-Fixture behoben. Keine SQL-Migration, Realdateninspektion, Datenmutation oder Backendneustart; Phasenstatus unveraendert. + +Source-Wechsel ohne Ansichtswechsel 2026-09-10 (Phase 7, Nutzerkorrektur): Der Client-Info-Source-Selektor verwendete den Findings-Drilldown und oeffnete dadurch Work. Die kontrollierte Auswahl setzt jetzt ausschliesslich den gemeinsamen Source-Filter, wechselt bei Bedarf auf das Timeslot-Aggregatblatt und behaelt Bereich sowie Work-Unteransicht. Scan All entfernt den Source-Filter. Score, Domain-/Prioritaetszahlen, Statuszaehler und Source Overview werden innerhalb Client Info aus der gefilterten Ergebnismenge abgeleitet; alle Quelloptionen bleiben erreichbar. Der blattgebundene Cache beruecksichtigt die unveraenderliche Quellenauswahl, damit Wechsel frische Werte liefern und unveraenderte Wiederbesuche keine Quellfelder erneut lesen. Explizite Finding-Drilldowns bleiben Navigation und uebernehmen den gewaehlten Source-Kontext. Fuenf synthetische Interaktionstests decken Client Info, die vier Work-Unteransichten, Scan All, Wiederbesuch und Austausch des Timeslot-Datensatzes ab. Verifikation: 1.157 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Clientbundle erfolgreich. Gesamtbuild weiterhin am vorbestehenden TS7016 fuer html-timeout-fixture.mjs blockiert. Keine API-/Persistenz-/Schemaaenderung, kein Reimport oder Backendneustart; Phasenstatus unveraendert. + +PurpleKnight-Statusabgleich 2026-09-10 (Phase 7, Diagnose mit Bezug zu 13A/13C): Der ausdruecklich auf Statusfelder und Zaehler freigegebene read-only Abgleich zeigt zwei unterschiedliche native Ergebnisstaende in HTML und CSV; die gespeicherten HTML-Originalstatusfelder und Summenzaehler stimmen mit der ASSESSOR-Zaehlung ueberein. Keine Importkorrektur oder Angleichung an fremde Summarywerte. Bestaetigter separater Darstellungsfehler behoben: Client Info erkennt die deklarierten PurpleKnight-Filter Not Relevant als not-applicable sowie Not selected/Canceled als not-run. Nicht anwendbare Kontrollen zaehlen damit nicht als Assessment Gaps oder zum Coverage-Nenner; Passed/Deviation und Originaldaten bleiben unveraendert. Vier neue synthetische Regressionen pruefen Profil-/Mischansicht, echte Luecken, Coverage und unveraenderte Quelldaten; elf fokussierte Dashboardtests und 49 Import-/Status-/Facettentests erfolgreich. Gesamtlauf: 1.152 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only- und Designpruefung erfolgreich. Clientbundle erfolgreich; Gesamtbuild bleibt am vorbestehenden TS7016 fuer tests/importers/html-timeout-fixture.mjs blockiert. Keine Persistenzmutation, Migration, Importversionierung, Reimport oder Backendneustart; temporaeres Diagnoseskript entfernt. Phasenstatus unveraendert. + +Work-GPO-Statusfilter wiederhergestellt 2026-09-09 (Phase 7/13B, Nutzerkorrektur): Der Versionssprung auf Evaluator 1.4.0 hatte gespeicherte 1.3.3-Vergleiche im Work-Ladepfad ausgeblendet. Work darf diese lesekompatiblen Ergebnisse jetzt ausschliesslich als Anzeigeersatz verwenden, solange fuer dieselbe aktive Aggregation keine aktuelle Evaluation vorliegt. Die Backendfreigabe des Aggregationskontexts und die vollstaendige Beobachtungs-/Timeslotabgrenzung bleiben erhalten; historische Profile/Snapshots werden nicht wieder aktiviert. Aktuelle Engineversion hat Vorrang, innerhalb derselben Version gilt weiterhin vollstaendigste Baselineabdeckung und danach Aktualitaet. Beschreibung und Evaluation-readiness-Feld kennzeichnen Altwerte ausdruecklich als neu auszuwerten. Der Standardselektor fuer aktuelle Result-DB-Projektion und fachliche Verarbeitung bleibt strikt, alte Laeufe gelten nicht als abgeschlossene Neuauswertung. GPO-Statusoptionen bleiben in GPO-/gemischten Workspaces auch bei null Treffern auswaehlbar; andere Facetten behalten ihre bisherige Trefferbegrenzung. Synthetische End-to-End-Regression bestaetigt Laden von Altwerten, Conflicts/Not configured/Duplicates/Passed mit je einem filterbaren Treffer, sichtbare Nulloptionen, Kennzeichnung und unveraenderte Originaldaten. 34 gezielte Tests und Gesamtlauf mit 1.148 Tests erfolgreich, acht optionale Datenbanktests uebersprungen; Local-only-/Designpruefung und Serverbuild erfolgreich. Clientbuild bleibt an der unabhaengigen fehlenden Typdeklaration fuer html-timeout-fixture.mjs blockiert. Keine Datenmutation, Neuauswertung, SQL-/API-Aenderung oder Backendneustart. Fuer die Filterkorrektur genuegt erneutes Oeffnen des Kunden mit aktualisiertem Frontend; die fachliche Neuauswertung bleibt getrennt erforderlich. Phasenstatus unveraendert. + +GPO-Vorlagenkontext 2026-09-09 (Phase 13B, expliziter Nutzerauftrag): Baselineanalyzer 1.3.0 erhaelt Namen jeder enthaltenen GPO-Vorlage aus begrenzten Backup.xml-/bkupInfo.xml-/GPReport.xml-Feldern mitsamt Quellpfad und SHA-256. Der bestehende SAX-Parser liest diese Namen nur per Opt-in; Kundenidentitaeten bleiben unveraendert. Eine enge Namensgrammatik erkennt Windows-Client, Member Server und Domain Controller samt Version; RS1 wird fuer den Vergleich zu 1607 normalisiert, der Originalname bleibt erhalten. Fehlende, unbekannte oder widerspruechliche Namen erzeugen keine geratene Rolle. Evaluator 1.4.0 waehlt Vorlagen nur bei genau einem expliziten, passenden Vergleichskontext ohne Inventarherkunft; unbekannte Vorlagen werden nicht ausgeschlossen. Gleiche Empfehlungen bleiben auch ohne Rollenwahl vergleichbar. Bei unterschiedlichen Empfehlungen ohne Zuordnung bleibt die bisherige Konflikt-/Reviewdarstellung bestehen, jetzt mit ausdruecklicher Erklaerung, dass kein Kunden-GPO-Konflikt bewiesen ist. Kein passender Kontext erzeugt keinen Pass/Fail. Alle Kandidaten und Auswahlreferenzen bleiben als Evidenz erhalten. Die Detailanzeige unterscheidet Paket und Vorlagenname, markiert ausgewaehlte Empfehlungen und fuehrt gleiche Werte verschiedener Vorlagen nicht mehr zusammen. 50 abschliessende synthetische Tests erfolgreich; Gesamtdurchlauf 1.146 Tests erfolgreich, acht optionale Datenbanktests uebersprungen. Local-only-Pruefung semantisch auf Opt-in und unveraenderte technische Identitaet praezisiert; Local-only/Design separat erfolgreich. Serverbuild erfolgreich. Client-Gesamtbuild durch unabhaengige fehlende Typdeklaration in html-attribute-performance.test.ts fuer html-timeout-fixture.mjs blockiert; direkter Bundleversuch durch Sandbox spawn EPERM blockiert. Keine SQL-Migration, Datenmutation, Live-Inhaltspruefung oder Backendneustart. Aktivierung fuer bestehende Daten erfordert Neuanalyse der Original-Baselinepakete und anschliessende neue Evaluation; alte Analysen/Laeufe werden nicht ueberschrieben. Die automatischen Inventarkontexte bleiben bewusst kein Beweis der Kunden-GPO-Anwendbarkeit. Phase 13B bleibt in Arbeit. + +HTML-Timeout-Nachhaertung 2026-09-09 (Phase 13/13A): Der Screenshot meldet einen Parserabbruch nach 30 Sekunden; der betreffende Report wurde nicht gelesen. Ein unabhaengiger synthetischer 3.159.338-Byte-Fall reproduziert denselben Fehler im bisherigen Produktionsworker nach 30.011 ms. Gemeinsamer linearer Attributleser ersetzt unbeschraenkte name=value-Suchwiederholungen; importlokaler Elementindex ersetzt wiederholte Volltextsuchen nach PingCastle-Verweiszielen. Formatadapter HTML 1.1.1, PingCastle-Extractor 2.2.1 und CIS-CAT-Extractor 1.3.1; unveraenderte Profile, Mappingvertraege, Zeit-/Speicherlimits und Persistenz. Neun neue synthetische Regressionen erfolgreich; der gebaute Worker erhaelt alle 40 Regeln und 40 verknuepften Tabellen in beobachteten 1.590 ms. 1.131 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Client-/Serverbuild und separate Designpruefung erfolgreich. npm test endet anschliessend an einem fachfremden GPO-Sicherheitscheck (tests/local-only-check.mjs:211: displayName-Verbot gegen unabhaengig geaenderten gpo-metadata-parser); diese Dateien wurden nicht veraendert. Kanonischer PostgreSQL-Container samt bestehendem Volume und Portbindung geprueft, Backend neu gestartet. Synthetischer Parse-only-HTTP-Abgleich bestaetigt 40 Regeln/Tabellen und unveraenderte Repositoryrevision; App/Backend/Proxy HTTP 200. Temporaere Diagnosepruefungen entfernt, dauerhafter isolierter Lasttest bleibt wiederholbar. Keine Phase wird hierdurch neu abgeschlossen. + +PurpleKnight-Vollstaendigkeit 2026-09-09 (Phase 13A/13C, freigegebener Fix des Audits): Profil 1.3.0, HTML-Extractor 1.2.0 und Summary-Extractor 1.1.0 verarbeiten Workbook-Summary und Findingtabellen gemeinsam ueber die generische Pipeline. HTML liefert getrennten Berichtskontext, exakte Originalwerte/Quellpfade und vollstaendige Detailzeitstempel. Lexikalisch erkannte statische Zuweisungen bleiben inert; defekte Payloads, fehlende IDs und konkurrierende Bindings scheitern explizit, doppelte IDs und deklarierte Zaehlerabweichungen erzeugen Warnungen ohne Datenverlust. Native Null-Details und deklarierte leere Berichte bleiben gueltig. CSV-Indikatorerkennung kombiniert Name und Schema; Dateiname allein reicht nicht. 25 neue synthetische Regressionen, insgesamt 1.122 Tests bestanden und acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich. Dummy: XLSX/HTML je 119 Vorkommen und 20 verknuepfte Detailtabellen mit 46 Zeilen, XLSX 22 und HTML 45 Kontextbeobachtungen; CSV 119 Vorkommen und alle 19 Details mit 45 Zeilen. 4.743 HTML-Originalfeldwerte samt Pfaden und alle 213 Detailzellen unabhaengig exakt geprueft. Alle 24 Dateien ueber Parse-only-HTTP abgeglichen; abschliessender Drei-Format-Check am finalen Backend bestaetigt die Zahlen und unveraenderte Repositoryrevision. Kanonischer PostgreSQL-Datastore unveraendert, Backend aktualisiert. Keine Schemaaenderung, Migration, Speicherung oder Reimport; alte Importe benoetigen expliziten Reimport. Vorgaben und historischer Pruefbericht aktualisiert, temporaere Auditdateien entfernt. Phase 13A bleibt abgeschlossen, Phase 13C bleibt in Arbeit. + +GPO-Empfehlungsanzeige vereinfacht 2026-09-09 (Phase 7/13B, Nutzerpraezisierung): Die Beschreibung zeigt nur noch Baselinebezeichnung und Sollwert. Gleiche Anzeigeempfehlungen innerhalb desselben Ergebnisses werden zusammengefasst; Source und Backupkennung bleiben in der gespeicherten Evidenz, entfallen aber hier. Die Vollstaendigkeitspruefung zaehlt geladene Referenzen unabhaengig von der Anzeigeverdichtung, damit zusammengefasste Werte nicht faelschlich als fehlend gelten. Keine Aenderung der Konfliktregel oder Zuordnung, keine Migration. 16 gezielte Tests, 1.122 Gesamttests erfolgreich, acht optionale Datenbanktests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Die beim vorherigen Durchlauf beobachteten Gesamtpruefblocker bestehen in diesem Durchlauf nicht mehr. Kein Phasenabschluss. + +GPO-Baselineempfehlungen 2026-09-09 (Phase 7 mit Bezug zu 13B, begrenzter Nutzerauftrag): Bei mehrdeutigen Baselineempfehlungen zeigt die Detailbeschreibung die referenzierten Empfehlungen mit Baselinebezeichnung, Sollwert, Quellpfad und Backupkennung. Die Zuordnung bleibt an die gespeicherte Analyse, Baseline und Einstellungsidentitaet gebunden; unbekannte Zielrollen werden nicht geraten. Explizit leere Kontenlisten und nicht ladbare Referenzen erhalten eigene Erklaerungen. Vorhandene Beschreibungen bleiben erhalten. Bewertung, Zaehler, Persistenz und Importdaten bleiben unveraendert; kein Reimport erforderlich. 16 gezielte synthetische Guidance-/Darstellungstests und Client-/Serverbuild erfolgreich, Designpruefung erfolgreich. Der parallel veraenderte Gesamtstand ist nicht vollstaendig gruen: beobachteter Purple-Knight-Profilversionstest (1.2.0/1.3.0) und Local-only-Pruefung in static-report-literal.ts ausserhalb dieser Aenderung. Kein Phasenabschluss und keine Live-Inhaltspruefung. + +PingCastle-Strukturtreue 2026-09-09 (Phase 13A/13C, freigegebene Auditpunkte 1-3): Profil 1.5.0 / Extractor 2.2.0 erhaelt XML-Attribute und explizite Leere, liest HTML-Tooltipattribute ohne Zelltextverunreinigung und diagnostiziert fehlende/doppelte Rule IDs sowie abweichende Kategorie-Trefferzahlen. HTML/XML-Formatadapter 1.1.0, unveraenderte Mapping-/Normalisierungsvertraege und Finding-Kompatibilitaet. Dummy-Abgleich: je 37 Regeln, XML 1.137 Beobachtungen mit allen 403 Attributwerten und 70 leeren Blaettern; HTML alle 125 Tabellen, 1.513 Beobachtungen, 17 bisherige Abschnitte plus separate Regelbilanz. Keine Attributreste in Kontext, Details oder verknuepften Detailtabellen. 21 neue synthetische Regressionen; 1.096 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Laufendes Backend nach kanonischer Datastorepruefung neu gestartet; Parse-only-HTTP-Abgleich bestaetigt Zahlen und unveraenderte Repositoryrevision, App/Backend/Proxy HTTP 200. Kein Reimport, keine Importpersistenz oder Schemaaenderung. Vorgaben und Sicherheitsdokumentation ergaenzt, temporaere Dummy-Pruefdatei entfernt. Auditpunkte 4-5 (semantischer XML-Kontextvertrag, Control-Path-JSON) bleiben offen; Phase 13A abgeschlossen und Phase 13C in Arbeit bleiben unveraendert. + +Maester-Vollstaendigkeit 2026-09-09 (Phase 13A/13C, ausdruecklicher Nutzerauftrag einschliesslich HTML): Der native HTML-Extractor 1.1.0 liest eingebettete statische JavaScript-Objektliterale ueber eine begrenzte Datengrammatik ohne Codeausfuehrung. Nicht unterstuetzte dynamische Ausdruecke, defekte Testeintraege und konkurrierende Berichtswurzeln scheitern mit einer Importdiagnose statt still null Befunde zu erzeugen. Native Strukturerkennung funktioniert auch hinter dem begrenzten Rohtext-Erkennungsausschnitt. Das Maester-Profil 1.1.0 trennt Excel-Result-Evidenz von einer vorhandenen Statusspalte; natives CSV/HTML-Result bleibt ohne separate Statusspalte der Ergebnisstatus. Berichtskontext, Originalfelder und Herkunft bleiben erhalten; Scanner-Rechner und PowerShell sind explizit Laufzeitkontext, keine bewerteten Assets. Deklarierte Zaehler und aus Einzeltests berechnete Werte bleiben getrennt, Widersprueche erzeugen Warnungen. Am freigegebenen Dummy liefern Excel und HTML jeweils 318 Kandidaten/Vorkommen und 297 Evidenzen; HTML liefert zusaetzlich 39 Umgebungsbeobachtungen und einen Berichtsabschnitt. IDs, Status und Severity stimmen fuer alle 318 Tests zwischen den Formaten ueberein; 6.235 extrahierte HTML-Originalfelder wurden unabhaengig gegen ihre Quellpfade geprueft. Zwei Quellwidersprueche sind belegt: TotalCount 315 statt 318 und FailedCount 67 statt 70. 1.075 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Damit sind auch die oben historisch dokumentierten temporaeren Maester-Test-/Buildblocker aufgeloest; temporaere Pruefdateien entfernt. Das neu gestartete Backend verwendet den verifizierten kanonischen PostgreSQL-Datastore; App, Backend und Proxy antworten mit HTTP 200. Parse-only-HTTP-Pruefung beider Dummy-Dateien bestaetigt Profil 1.1.0, dieselben Zahlen und unveraenderte Repositoryrevision. Keine Schemaaenderung, Migration oder Speicherung von Importdaten; bestehende Maester-Importe benoetigen einen expliziten Reimport. AGENTS.md, SECURITY.md und docs/IMPORT_SECURITY_LIMITS.md halten die Schutz- und Abnahmeregeln fest. Phase 13A bleibt abgeschlossen, Phase 13C bleibt in Arbeit. + +Client-Info Findinggrundlage 2026-09-09 (Phase 7 mit Bezug zu 13B, Nutzerkorrektur): Security Domains und Priority Findings verwenden jetzt dieselbe autoritative, disjunkte Deviation-Grundmenge. Ursache der ueberhoehten Domainzahlen war eine zweite Statusableitung: Abfragen nach in einem Profil nicht definierten Statuswerten wurden vom Profilfallback als Treffer behandelt; dadurch konnten insbesondere GPO-Kontextzeilen als Deviations gelten. Zusaetzlich durfte derselbe Datensatz mehreren Domains angehoeren. Kontextstatus werden nun vor Deviations getrennt, nur deklarierte Statusfilter abgefragt und jeder Datensatz genau einer primaeren Domain zugeordnet; nicht eindeutig klassifizierbare Deviations erscheinen transparent als `Unclassified`, sodass die Domaenenverteilung mit der Gesamtzahl reconciliert. Passed, Not configured, Duplicates und Conflicts stehen je Domain sowie global als separate, anklickbare Kontextzahlen bereit und fliessen nicht in Findings, Critical oder High ein. 38 fokussierte Dashboard-/GPO-Regressionen, Client-Typpruefung, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 1.070 Tests, acht optionale PostgreSQL-Tests wurden uebersprungen; zwei gleichzeitig bestehende Maester-Result-Message-Tests scheitern ausserhalb dieser Aenderung. Ausschliesslich synthetische Inhaltspruefung, keine Daten-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen; Risiko einer erzwungenen falschen Domainzuordnung wird durch den sichtbaren Unclassified-Rest vermieden. + +Work-Standardeinstieg 2026-09-09 (Phase 7, Nutzerpraezisierung): Jeder explizite Wechsel in den Bereich Work setzt die Ansicht jetzt auf Reports. Sidebar, Client-Info-Weiterleitung und Pathfinder-Fundsprung verwenden dafuer denselben Einstieg; gespeicherte Daten, Auswahlwerte und die anderen Work-Ansichten bleiben unveraendert. Die fokussierte Regression mit drei Tests sowie der Gesamtlauf mit 1.026 bestandenen Tests, acht uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung waren erfolgreich. Der Server-Produktionsbuild war erfolgreich. Der vollstaendige Build bleibt unabhaengig von dieser Aenderung an der bereits vorhandenen temporaeren Datei `tests/maester-audit.temporary.test.ts` blockiert (`DatasetSheet.headers` existiert im Typ nicht); der direkte Client-Bundle-Ersatzlauf war in der Sandbox wegen `spawn EPERM` nicht ausfuehrbar. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Bereichswechsel-Performance 2026-09-09 (Phase 7, Nutzerauftrag): Bremsen waren mehrfach ausgefuehrte Filter-/Facetten- und Statuspruefungen, quadratische Neulesung abgelehnter nummerierter Spaltengruppen, Normalisierung im Sortiervergleich, unsichtbare Raw-Data-/Exportaufbereitung, ein uebergrosses erstes Virtualisierungsfenster und 2.537 sofort gemountete Blattoptionen. Gemeinsame begrenzte blattgebundene Selektoren, profilgebundene Statusantworten, einmalige Gruppen-/Sortierschluessel sowie bedarfsgeladene Rohtexte, Exporte und native Optionen beseitigen diese Wiederholungen. Pathfinder startet erst bei Aktivierung, pausiert versteckte Kontext-/Geometriearbeit und verwirft alten Zustand bei Workspacewechsel; Textkollisionen laufen nur bei sichtbarem Text, MITRE-Header werden einmal klassifiziert. Unveraenderte Health-/Geometriewerte ersetzen keinen Zustand. Am ausdruecklich freigegebenen Dummy (1280 x 720) sank Work von anfangs 5.324 ms auf 121-211 ms bei unveraenderten Wiederbesuchen; nach Filterreset/Graphneubau ein Rueckwechsel 406 ms. Synthetisch mit 8.257 Records: wiederholte Ableitung 398 -> rund 1 ms, null erneute Quellfeldzugriffe. 1.024 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. App, Backend und Proxy HTTP 200; Messcode fehlt im Produktionsbundle. AGENTS.md und docs/architecture/navigation-performance.md enthalten Ursachen, Messverfahren und Regressionen. Keine Migration, kein Reimport oder gezielte Datenmutation; Prueftab geschlossen. Phase 7 bleibt abgeschlossen, andere Phasenstatus unveraendert. + +Client-Info Verbindungskurven 2026-09-08 (Phase 7, Nutzermeldung): Die Kurven zwischen Overall Score und Security Domains endeten sichtbar neben ihren Knoten. Ursache waren feste Zielkoordinaten in einem ungleichmaessig gestreckten Koordinatensystem (`viewBox="0 0 1000 640"` mit `preserveAspectRatio="none"`): sie trafen nur bei genau einer Fenstergroesse. Die Geometrie entsteht jetzt aus der tatsaechlichen Lage von Ring und Domainknoten, das Koordinatensystem entspricht der gemessenen Flaeche, und neu gemessen wird sowohl bei Groessenaenderungen der beteiligten Flaechen als auch beim Fensterereignis. Gemessen am freigegebenen Dummy bei 1.000, 820 und 805 Pixel Breite: Abweichung zwischen Kurvenende und Knotenmitte jeweils 0 Pixel, zuvor bis zu 80 Pixel. Unterhalb des Umbruchs bleiben die Kurven wie bisher ausgeblendet. Keine Aenderung an Werten, Farben oder Kachelgeometrie. 1.011 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. + +GPO-Quellenanzeige 2026-09-08 (Phase 7/13B, Nutzerkorrektur): Work verwendet die vom bestehenden Backend-Readmodell ausgewiesenen aktuellen Evaluationen und gruppiert Laeufe nach Aggregation statt nach der ergebnisabhaengigen Teilmenge referenzierter Backups. Reprocessing-Historie und abgeloeste Profil-/Snapshotkontexte erscheinen damit nicht als zusaetzliche Scans. Vergleichs-, Not-configured- und Konsistenzzeilen tragen den urspruenglichen Importzeitpunkt; der Auswertungszeitpunkt bleibt separat als `Evaluated` erhalten. `Source: Scan` steht auch auf einem reinen GPO-Blatt bereit. 48 fokussierte Tests und der Gesamtlauf mit 1.014 bestandenen Tests, acht uebersprungenen optionalen PostgreSQL-Tests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Read-only am ausdruecklich freigegebenen Dummy ueber den korrigierten Workspace-Lesepfad bestaetigt: genau eine GPO-Quellenoption mit 3.805 Zeilen, ein urspruenglicher Importzeitpunkt, ein aktueller Auswertungszeitpunkt und insgesamt fuenf Quellenoptionen; die elf historischen Evaluationen sind vor und nach der Pruefung unveraendert vorhanden. Liveausgabe ausschliesslich technische Zaehler, App und Backend HTTP 200. Keine Migration, Datenmutation, Neuanalyse oder Backendneustart; Phasenstatus unveraendert. + +Client-Info Antwortzeit 2026-09-08 (Phase 7, Nutzermeldung): Die Ansicht blockierte beim Aufbau messbar mehrere Sekunden. Ursache war nicht die Facettenableitung (5 ms), sondern die Ableitung je Datensatz: Ergebniszustand, Schweregrad, Domainzuordnung, Quellenzuordnung und vierzehn Punkteberechnungen liefen fuer alle Datensaetze des Mandantenblattes - im Dummy 8.257 - bei jedem Rendern erneut, also auch bei jeder Zustandsaenderung der Anwendung. Gemessen 3.123 ms je Aufbau. Die Ableitung entsteht jetzt einmal je Blatt: ein Durchlauf statt vierzehn, die Domainzuordnung baut den Klassifikationstext einmal statt achtmal, Zustand, Schweregrad und Klassifikationstext haengen als schwache Verweise am Datensatz, und Facetten samt Auswertung ueberdauern den Ansichtswechsel. Zusaetzlich bleiben die Umgebungsdetails und die Ersatzzaehlung der GPOs memoisiert, und die workspaceweiten Herkunftswerte werden je Datensatzliste einmal gezaehlt. Gemessen nach der Aenderung: Ableitung 0 ms je Aufbau, laengste blockierende Aufgabe beim Ansichtswechsel unter 100 ms statt ueber 4.000 ms. Fachliche Werte, Zaehlungen und Darstellung sind unveraendert; die geteilte Statuslogik der Profile wurde bewusst nicht angetastet, damit Client Info und Work weiterhin dieselben Zahlen zeigen. Der bekannt hohe Aufbau der Work-Ansicht bleibt davon unberuehrt und ist nicht Teil dieser Aenderung. 1.007 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. + +Abschluss Dummy-Reimport 2026-09-08 (Phase 7/13C): Der zuvor offene Punkt des vorherigen Eintrags ist erledigt. Nach dem Neustart des lokalen Backends wurde der Purple-Knight-Scan ueber den Importdialog erneut ersetzt (`run-batch-1788870808672-141`); die bestaetigungspflichtige Indicators-Datei traegt jetzt Profilversion 1.2.0 bei unveraenderter Mappingversion 1.1.0, die Zusammenfassungsdatei wird ohne Rueckfrage mit hoher Sicherheit als Purple-Knight-Quelle erkannt. Alle aktiven Scans des Dummy fuehren damit den aktuellen Verarbeitungsstand: Purple Knight 1.2.0 (20 generische Begleitdateien unveraendert 1.0.0), CIS-CAT 1.4.0, PingCastle 1.4.0, Maester 1.0.0. Datahub meldet fuer alle fuenf Eintraege `Ready`, die Reimportempfehlung ist verschwunden. Befundzahlen und Umgebungskontext unveraendert gegenueber der vorherigen Pruefung (119 Vorkommen, 22 Beobachtungen im Purple-Knight-Lauf), Client Info zeigt weiterhin 49 Faktenzeilen ohne unbekannte Werte. Keine Code-, Schema- oder Persistenzaenderung. + +Dummy-Reimport und CIS-CAT-Titelseite 2026-09-08 (Phase 7/13C, ausdrueckliche Nutzerfreigabe): Der freigegebene Dummy wurde ueber den regulaeren Reimportweg (`/import-batches/preview` und `/import-batches/complete` mit `replacesScanRunId`) mit exakt denselben Originaldateien neu importiert; die SHA-256-Identitaet aller 26 Dateien wurde vorab und serverseitig geprueft. Vor dem Schreiben entstand ein Custom-Format-Backup, dessen Archivinhalt (345 Eintraege) und Kopie per SHA-256 verifiziert wurden. Befundzahlen bleiben unveraendert (Purple Knight 119, Maester 318, CIS-CAT 411, PingCastle 37), abgeloeste Laeufe bleiben als Historie erhalten. Der bereits am 2026-08-25 abgeloeste PingCastle-Lauf wurde bewusst nicht angefasst. Die zuvor benutzerbestaetigte Werkzeugentscheidung der Indicators-Datei wurde unveraendert reproduziert. Am echten Bericht zeigte sich, dass CIS-CAT Pro System- und Benchmarkangaben nicht als beschriftete Wertepaare fuehrt, sondern auf der Titelseite: bewertetes System als `for `, Netzadresse als `Target IP Address`, Benchmark samt Version als Ueberschrift und Profil, Zeitpunkt sowie Dauer als unbeschriftete Listenpunkte. Die Auswertung liest jetzt vorrangig diesen Block, faellt auf beschriftete Wertepaare zurueck und leitet aus einer reinen XCCDF-Ergebniskennung im Titel einen lesbaren Benchmarknamen ab; die synthetische Fixture bildet diesen Aufbau nach. Ein Betriebssystemname entsteht weiterhin nicht, weil der Bericht keinen nennt. Purple-Knight-Profil 1.2.0 und CIS-CAT-Profil 1.4.0 sind als `compatible` mit `environment-context` und Reimportbedarf im Verarbeitungsmanifest registriert; Kompatibilitaetsschluessel, Feldabbildung und Normalisierung bleiben unveraendert. Client Info zeigt fuer den Dummy jetzt 49 Faktenzeilen ohne einen einzigen Gedankenstrich. 1.004 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Offen: Der lokale Backendprozess laeuft noch mit dem Stand vor dieser Aenderung, deshalb traegt die bestaetigungspflichtige Indicators-Datei weiterhin Profilversion 1.1.0 und der Purple-Knight-Scan bleibt als `Reimport recommended` markiert; nach einem Neustart des Backends genuegt ein erneuter Reimport dieses einen Scans. + +Werkzeugkontext ausserhalb der Findings 2026-09-08 (Phase 7/13C, ausdruecklicher Nutzerentscheid Variante b): Purple Knight und CIS-CAT liefern jetzt Umgebungskontext statt nur Befunde. Ein eigener Purple-Knight-Zusammenfassungsextractor liest die zweispaltige Kennzahlendatei als reine Umgebungsbeobachtungen ohne Findingkandidaten: Posture Score, sechs Kategoriewerte, Auswertungsbilanz (evaluated, IOEs found, passed, not selected, not relevant), Tooledition, Scandauer und Anforderer. Werkzeugneutrale Angaben werden auf die gemeinsamen Eigenschaften `forest.name`, `domain.count` und `report.generated_at` abgebildet, alles uebrige bleibt unter `purple_knight.*`. Zwei zusaetzliche Inhaltssignale fuehren die Datei als Purple-Knight-Quelle statt als generische Tabelle. Der CIS-CAT-Extractor 1.3.0 ergaenzt Systemangaben aus beschrifteten Wertepaaren (Host, Betriebssystem, IP, Profil, Zeitpunkt), Benchmarkname, Gesamtscore, die deklarierten Ergebniszahlen je Zustand sowie den Punktwert je oberster Benchmarkgliederung; die vollstaendige Abschnittsuebersicht bleibt als Berichtsabschnitt erhalten. Fehlt eine Beschriftung, entsteht keine Beobachtung statt eines geratenen Wertes. Client Info zeigt die neuen Werte in der zusaetzlichen Zone `Environment Detail` mit Verzeichnis, Bestand, Passwortrichtlinie, Zertifikaten/PKI, Wiederanlauf und beschrifteten Werkzeugkennzahlen; unbekannte Fakten bleiben `—`, lizenzbeschraenkte Abschnitte werden ausdruecklich als `Restricted` benannt und nie als Null gezaehlt. Die Security-Domain-Knoten tragen jetzt den vergleichbaren ASSESSOR-Domainscore, jede Quellkachel nennt zuerst diesen Score und die native Toolzahl nur beschriftet daneben. Die GPO-Anzahl stammt aus der Verarbeitungsliste der Sicherungen statt aus einer GUID-Schaetzung in Findingtexten. Keine Schema-, Migrations- oder Persistenzaenderung; bestehende Importe tragen die neuen Beobachtungen erst nach einem erneuten Import derselben Dateien. 1.003 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung mit 328 Tokens und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung; die Datenlage wurde am ausdruecklich freigegebenen Dummy nur strukturell erhoben. Offen bleibt die Textbereinigung der PingCastle-Zellattribute in der Quellextraktion, heute nur praesentativ abgefangen. Phase 7/13C bleiben in ihrem bisherigen Status. + +Security-Template-Parserkorrektur 2026-09-08 (Phase 13B): Parser 1.1.0 ueberspringt Metadaten und nicht unterstuetzte INF-Sektionen vor der Key/Value-Pruefung. CSV-artige Service-Eintraege lassen gueltige System-Access-, Kerberos-, Privilege-Rights- und Registry-Values-Instruktionen erhalten. Einzelne defekte unterstuetzte Eintraege degradieren das Dokument mit Diagnose auf `partial`; unsichere Abschnittsgrenzen und Ressourcenverletzungen bleiben blockiert. Baseline-Analyzer 1.2.0 und GPO-Processing/Analyzer 2.2.3 trennen Neuanalysen von unveraenderter Historie; alte Baseline-Analyserversionen bleiben lesbar. Analysegebundene ADMX-Katalog-IDs beheben den bei der Bestandsneuanalyse belegten PostgreSQL-Konflikt fuer unveraenderte Kataloginhalte. 990 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Custom-Format-Backup vor Live-Neuanalyse vollstaendig auf Archivlesbarkeit sowie die lokale Kopie per SHA-256 geprueft; kein Restore behauptet. Alle elf Baselinepakete neu analysiert: 5.031 statt 4.419 Einstellungen, darunter 1.039 statt 427 Security-Template- und 400 statt 146 Privilege-Rights-Eintraege. Alle elf alten Analysen bleiben erhalten, aktiv sind nur die elf Nachfolger. Dummy neu ausgewertet: konfigurierte Kundenwerte ergeben 113 Matches, 98 Abweichungen und 15 Reviews; 28 zuvor fehlende Privilege-Rights-Abweichungen kommen hinzu, 13 bisherige Abweichungen werden aufgrund der wiederhergestellten Baselinevarianten zu Review, zwei alte Reviews bleiben bestehen. Alle 15 Reviews enthalten den Baseline-Consensus-Konfliktcode. Zusaetzlich bestehen 3.575 Vergleiche mit fehlendem Kundenwert sowie 71 entsprechende Review-Faelle; diese sind keine konfigurierten Abweichungen. Die Erwartung 107 Abweichungen plus 2 Review wurde dadurch korrigiert. Unabhaengiger Abgleich gegen den Excel-Policy-Analyzer-Export des Dummy-Datensatzes bestaetigt die Korrektur: alle 109 dort sichtbaren Abweichungen sind je Baseline vollstaendig abgedeckt (Abweichung plus Review), zuvor waren es 83; Matches stimmen je Baseline ebenfalls ueberein. Vier zusaetzliche ASSESSOR-Abweichungen betreffen `SeEnableDelegationPrivilege` in 22H2, 23H2, 24H2 und 25H2, wo die Baseline das Recht ausdruecklich leer setzt; Policy Analyzer stellt diese explizit leere Empfehlung nicht von fehlender Abdeckung unterscheidbar dar. Der Vergleich erfolgte ausschliesslich auf dem Dummy-Datensatz. Betriebsnebeneffekt der automatischen Job-Reparatur siehe Risikoabschnitt; App, Backend und Proxy-Health HTTP 200. Phase 13B bleibt in Arbeit. + +GPO-Klassifikation in der Result DB 2026-09-07 (Phase 7/13B, ausdruecklicher Nutzerwunsch): Die Result DB behaelt Outcome als werkzeuguebergreifende Achse und ergaenzt die unabhaengige Facette `GPO Classification` mit Misconfigured, Not configured, Match, Conflict, Duplicate und Review required. Deterministische Kundenkonflikte und Dubletten werden aus den aktuellen Policy-Beobachtungen ueber dieselbe Gruppierungslogik wie Work als eigene reine Leseprojektionen erzeugt; beide bleiben `warning`, `Deviation: No` und veraendern weder Originale noch Evaluationen. Die Auswahl einer GPO-Klasse loest den standardmaessigen Deviation-Filter, damit nicht abweichungsartige Klassen erreichbar bleiben. Lokales und PostgreSQL-Repository verwenden denselben Domainvertrag; API-Query und Detailansicht fuehren die Klassifikation und bei Konsistenzgruppen die Quellenanzahl. Keine Migration, kein Reimport und keine Datenmutation. 976 Tests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung; Phasenstatus unveraendert. + +Client-Info Domain-Findinganzahl 2026-09-07 (Phase 7, Nutzerpraezisierung): Security Domains zeigt als primaere Zahl ausschliesslich die Anzahl der Deviations mit der Beschriftung Findings. Passzahlen, prozentuale Domainscores und Prozentbalken entfallen aus den Domainzeilen; der bestehende Deviation-Drilldown bleibt erhalten. Die neutralen Domain-Icons stellen keinen aus der Anzahl abgeleiteten Schweregrad dar. + +Client-Info Deviation-Drilldown 2026-09-07 (Phase 7, Nutzerpraezisierung): Fachliche Spruenge aus Client Info nach Work aktivieren standardmaessig `Deviation`, einschliesslich Security Domains, Prioritaeten und Quellen. Die bisherige ausdrueckliche All-Auswahl bei Domain-/Finding-Klicks entfaellt. Assessment Gaps behaelt seine separate Statusauswahl. Domain-Scoreberechnung bleibt unveraendert; der Work-Drilldown zeigt nur Abweichungen innerhalb der zugeordneten Record-IDs. Synthetische Regression deckt Failed, Passed und Skipped innerhalb einer Domain plus fachfremdes Failed ab. + +Verifikation Domain-Drilldown 2026-09-07: 974 Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Client-/Serverbuild sowie Local-only- und Designpruefung erfolgreich. Ausschliesslich synthetische Inhaltspruefung; keine erneute Live-Dateninspektion. + +Client-Info Domain-Drilldown 2026-09-07 (Phase 7): Die praesentative Domainzuordnung beruecksichtigt Titel und fachliche Beschreibungs-/Kategoriewerte statt saemtlicher Feldnamen und Evidence-Inhalte. Gemeinsame Aggregatspalten wie User/Baseline fuehrten zuvor dazu, dass einzelne Domains praktisch alle Records enthielten. Work erhaelt weiterhin die exakten Record-IDs der angeklickten Domain; der Wechsel deaktiviert eine vorherige My-Workspace-Einschraenkung. Fuenf synthetische Regressionen pruefen vier getrennte Domains durch den produktiven Work-Filter sowie fehlende Domainzuordnung; 17 fokussierte Tests erfolgreich. Domain-Scores koennen durch die korrigierte Zuordnung abweichen; Overall-Score und Persistenz bleiben unveraendert. + +Client-Info Work-Kachelfarbe 2026-09-07 (Phase 7, ausdrueckliche Nutzerpraezisierung): Alle Client-Info-Kacheln beziehen Oberflaeche, Hover, Text und Trennlinien jetzt aus denselben Theme-Rollen wie die Work-Kacheln (`--tile-surface`, `--tile-surface-hover` und zugehoerige semantische Rollen). Die Command-Center-Komposition und ihre fachlichen Akzentfarben bleiben gekapselt erhalten; damit bleibt der Kontrast auch bei einem Themewechsel valide. + +Client-Info Standardhintergrund 2026-09-07 (Phase 7, ausdrueckliche Nutzerpraezisierung): Die aeussere Client-Info-Seite verwendet wieder den gemeinsamen Theme-Hintergrund `--surface-app`. Struktur, Inhalte, Bewertung und Navigation bleiben unveraendert. Die gekapselte Client-Info-Designregel wurde entsprechend praezisiert und durch die folgende Work-Kachelfarbentscheidung weiter konkretisiert. + +Client-Info Security Command Center 2026-09-07 (Phase 7/13C, ausdruecklicher Nutzerentscheid): Die geladene Client Info verwendet jetzt die verbindliche dunkle Referenzkomposition statt der bisherigen allgemeinen Kacheloptik. Die Ansicht zeigt eine kompakte Icon-Faktenzeile fuer AD-Domains, Entra-Tenants, Benutzer, Computer, Domain Controller und eindeutig aus Provenienz ermittelte GPOs; darunter stehen Overall Score und acht per SVG-Kurven verbundene Security Domains, eine separate Priority-/Gap-Aktionsspalte und die werkzeugspezifische Source Overview fuer PingCastle, Purple Knight, Maester, CIS-CAT und GPO Analysis. Alle Werte entstehen aus dem aktiven Timeslot, normalisierten Findings und der vorhandenen Environment-Snapshot-Grenze; unbekannte Fakten bleiben `—`. Der Overall Score bleibt der gleichgewichtete Mittelwert verfuegbarer ASSESSOR-Quellenscores, Coverage und Critical Findings bleiben getrennte Guardrails. Native Toolmetriken werden nur eindeutig beschriftet in der Source Overview gezeigt. Die neue `.client-command-center`-Regel ist die einzige Ausnahme von der allgemeinen Kachelkomposition und kann nicht in andere Ansichten auslaufen. Keine Parser-, Import-, API-, Persistenz- oder Schemaaenderung. 969 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung mit 328 Tokens und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Live-Sichtpruefung ausschliesslich am ausdruecklich freigegebenen Dummy bestaetigte Fakten, Ring, Verbindungskurven, Domains, Prioritaeten, Gaps und Source-Metriken. Phase 7/13C bleiben in ihrem bisherigen Status. + +Workspaceweite Source-Scan-Navigation 2026-09-07 (Phase 7, ausdrueckliche Nutzerpraezisierung): `Source: Scan` wird in jeder Fachansicht aus dem gemeinsamen projektweiten All-Records-Blatt aufgebaut und bietet deshalb auch aus der reinen GPO-Ansicht jederzeit alle geoeffneten Scannerlaeufe an. Die Optionen werden weder durch das aktive Blatt noch durch andere Filter reduziert. Die Auswahl eines Scans aus einem dedizierten Fachblatt wechselt auf das gemeinsame Aggregat und setzt dort im selben Bedienvorgang den stabilen Provenienzfilter; `All` bleibt die ungefilterte Auswahl. Der Facettenvertrag verwendet dafuer unabhaengig von der Quellspaltenposition die feste ID `provenance:source-scan`. Daten, Scannerzuordnung und Persistenz bleiben unveraendert. 33 fokussierte Filter-/GPO-Regressionen gruen; 971 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion; Phasenstatus unveraendert. + +GPO-Filteranordnung 2026-09-07 (Phase 7, ausdruecklicher Nutzerwunsch): Die reine GPO-Ansicht zeigt ihre fachlichen Filter ohne kuenstlichen Zwischenraum von links nach rechts. Der Provenienzfilter `Source: Scan` ist in jeder Ansicht dauerhaft vorhanden und wird unabhaengig von Einwertigkeit oder GPO-Facettenlimit als letzter Filter ganz rechts angeordnet; fehlt eine gleichnamige Quellspalte, entsteht ein rein praesentativer Fallback aus der vorhandenen Scan-/Profilbezeichnung. Die GPO-Ansicht darf dafuer elf sichtbare Facetten fuehren, sodass Status, die neun GPO-Fachfacetten und `Source: Scan` gleichzeitig sichtbar bleiben. Filterwerte und Datensatzprojektion bleiben unveraendert. 32 fokussierte Filter-/GPO-Regressionen gruen; 970 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion; Phasenstatus unveraendert. + +Kundenreduzierte GPO-Quellenanzeige 2026-09-07 (Phase 7/13B, ausdruecklicher Nutzerwunsch): Sichtbare GPO-Sources bestehen nur noch aus der GPO-internen Referenz ab `{GPO-GUID}/DomainSysvol/GPO/...` beziehungsweise ersatzweise ab dem eindeutig erkannten `DomainSysvol/GPO/...`-Segment. Lokale Laufwerks-, Ordner-, Backup- und Artefaktpraefixe werden niemals gerendert; ohne sicher erkennbaren internen Anker erscheint fail-closed `GPO source reference unavailable`. Normale GPO-Sources sowie Conflict-/Duplicate-Evidence verwenden denselben reinen Presenter. In Results stehen die Referenzen sofort unter Evidence als einzelne technische Pfadzeilen, ohne `Show source` und ohne wiederholte fette Backup-/GUID-Ueberschrift. Vollstaendige Provenienz bleibt unveraendert gespeichert; Backup-/Record-IDs bleiben nur in der bestehenden eingeklappten technischen Detailstufe. Vier Source-, elf Conflict- und neun Duplicate-Regressionen sowie 36 fokussierte Tests gruen; 967 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Duplicate-Lesepipeline 2026-09-07 (Phase 7/13B): Duplicate-Results verwenden jetzt dieselbe erklaerende Reihenfolge wie Conflicts: `Duplicate detected` (warum) -> `Setting details` (was betroffen ist) -> `Observed value` (identischer Wert/Typ und Evidence) -> eingeklappte technische Quelldetails. Der Hinweis stellt klar, dass ein Duplicate allein keine Baselineabweichung ist und beabsichtigt sein kann. Der gemeinsame Wert erscheint in einer responsiven Tabelle; alle Quellen sind direkt am Evidence-Feld aufklappbar, vollstaendige Pfade und interne IDs bleiben in der letzten Detailstufe. Exakte Leer-/Whitespacewerte, 2.300-Quellen-Skalierung, sichere Envelopevalidierung und Tabellenfallback bleiben erhalten. Duplicate- und Conflictprojektionen teilen die neutrale strukturierte Darstellung, Bewertung/Persistenz/Originaldaten bleiben unveraendert. Neun Duplicate- und elf Conflictregressionen, 36 fokussierte Resulttests gruen; 967 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Conflict-Lesepipeline 2026-09-07 (Phase 7/13B, ausdrueckliche Nutzerkorrektur): Die Conflicts-Ansicht folgt jetzt `Conflict detected` (warum) -> `Setting details` (was betroffen ist) -> `Observed variants` (was beobachtet wurde) -> eingeklappte technische Quelldetails. Die unmittelbar zuvor eingefuehrten einzelnen Variantenkarten sind durch eine gemeinsame Tabelle mit Variant, Value, Type und Evidence ersetzt. Quellen bleiben je Variante direkt aufklappbar; lange Werte umbrechen vollstaendig und nur die Tabelle erhaelt an schmalen Viewports eine eigene horizontale Rollflaeche. Keine Gewinner-/Praezedenzbehauptung, Normalisierung oder Datenmutation. Elf Konfliktregressionen und 34 fokussierte Resulttests gruen; 965 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Conflict-Results-Erklaeransicht 2026-09-07 (Phase 7/13B): Die bisherige doppelte generische Tabellenansicht fuer GPO-Konflikte ist durch eine strukturierte, neutrale Variantenansicht ersetzt. Ein Warnhinweis erklaert Konflikt und unbekannte Wirksamkeit, Variantenkarten stellen exakte Werte, lesbare Registrytypen und zugeordnete Quellen gegenueber; leere und reine Whitespace-Werte werden ausdruecklich bezeichnet. Settingkontext folgt separat, interne Backup-/Record-IDs bleiben vollstaendig unter eingeklappten technischen Details erhalten. Die Darstellung entsteht erst nach vollstaendiger Validierung des begrenzten Evidence-Envelopes; ungueltige/alte Projektionen fallen auf die bestehende inerte Tabellenansicht zurueck. Duplicate-Results, Vergleich, Persistenz und Originaldaten bleiben unveraendert. Zehn Konfliktregressionen und 33 fokussierte Resulttests gruen; 964 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Ausschliesslich synthetische Inhaltspruefung, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Kachelbadges 2026-09-06 (Phase 7): TileCard verwendet jetzt dieselbe GPO-Kategorieableitung wie der FindingReader und ergaenzt Scope. Gilt auch fuer gemischte Workspaces; doppelte Kategorien/Scopes werden vermieden, andere Scanner bleiben unveraendert. Bestehende Badge-Matrix und unbegrenzte normale Kacheldarstellung werden weiterverwendet. Vier neue synthetische Regressionen; 962 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Daten-/Bewertungsaenderung, kein Reimport, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Duplicate-Results 2026-09-06 (Phase 7): Duplicates nutzen analog zu Conflicts den bestehenden Results-Button und dieselbe skalierbare Tabellenansicht. Eine Tabelle zeigt den gemeinsamen Originalwert, Typ und Quellenanzahl; eine zweite jede Quelle mit Source path, Backup und Record. Einstellung, Scope, Registry-Pfad und Value name stehen im Kontext. Keine Konflikt-/Gewinnermarkierung bei gleichen Werten. Der Reader zeigt eine kurze Duplicate-Zusammenfassung statt wiederholter Werte/Sources. Gemeinsame begrenzte, inerte Leseprojektion mit eindeutig getrennten Envelopes und Whitespace-Erhaltung; bei unvollstaendiger/mehrdeutiger Evidenz bleibt die bisherige Darstellung erhalten. Bewertung, Persistenz und Originaldaten unveraendert; kein Reimport erforderlich, bestehende Workspaces neu oeffnen. Sieben neue synthetische Regressionen inklusive 2.300 Quellen, Buttonaktivierung, Escaping, Fallback und unveraenderten Konflikten. 958 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +Tooluebergreifende AI search und GPO-Badges 2026-09-06 (Phase 7): FindingReader bietet die geschuetzte Google-AI-Suche fuer alle Scan-Tools und gemischte Workspaces an. Quellenbelegter lokaler Public-Identifier-Snapshot (67 Registryziele, 45 Rechte, 19 ASR-, 161 Maester- und 51 PingCastle-Kennungen) plus native System-Access-Einstellungen und feste Fachbegriffe liefern konkrete Identitaet, Konfigurationsort/Referenz, sicheren Benchmarkkontext und begrenzte numerische/boolesche Sollziele. Keine freie Weitergabe von Berichtstexten, Kundenwerten, Namen, Identitaeten oder Quellpfaden. Fehlende Katalogtreffer bleiben ausdruecklich Topic-Suche; keine Vollstaendigkeits-, Wirksamkeits- oder Datenschutzpauschalzusage. Vorhandene GPO-Sektionen erzeugen zusaetzliche System-Access-/Privilege-Rights-/Registry-Values- und Detailbadges; Registry/Software/System sind strukturelle Fallbacks hinter konkreten Produktfamilien. Keine Bewertungs-/Persistenzaenderung oder Reimporte. Sicherheitsmodell und Public-AI-Search-Vertrag mit Quellenpflege/Grenzen ergaenzt; historische Entscheidungen bleiben erhalten. 951 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Nur synthetische Inhaltspruefungen, keine Kundendateninspektion oder Google-Abfrage mit Findingdaten. Phasenstatus unveraendert. + +GPO-Kachelumbruch 2026-09-06 (Phase 7): Lange Registry- und Policy-Pfade in GPO-Work-Kacheln umbrechen innerhalb der verfuegbaren Titelspalte und koennen dadurch weder die Bookmark-Aktion noch benachbarte Kacheln ueberdecken. Die Regel ist ueber die bestehende Toolidentitaet gezielt auf `group-policy` begrenzt; normale Findingtitel behalten ihren wortbasierten Umbruch. 42 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Pfaddarstellung 2026-09-06 (Phase 7): Gemeinsame inerte PathText-Darstellung fuer Finding-/Reporttexte, GPO-Werte/Sources/Remediation und Results-Tabellen samt Kontext. Pfade erhalten einen dezenten Rahmen mit themegebundener Inset-Flaeche, vollstaendigem Umbruch und lokaler System-Monospace-Schrift. Ausdrueckliche Nutzerkorrektur zur bisherigen reinen Inter-Vorgabe: nur Pfade nutzen --font-path, Labels und sonstige Inhalte bleiben Inter; AGENTS.md entsprechend praezisiert. Keine Links, Dateizugriffe, Fontdownloads oder Aenderungen an Originalwerten/Vergleichen. Zwoelf synthetische Regressionen pruefen Pfadtypen, Labels, Escaping, Suchmarkierung, lange Pfade und Stilkontrakt. 923 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Conflict-Results 2026-09-06 (Phase 7): Kundenkonflikte mit mehreren belegten Wertvarianten nutzen den vorhandenen Results-Button samt verschiebbarem/skalierbarem Ergebnisfenster und gemeinsamer Tabelle. Gleiche typisierte Werte werden zu Varianten gruppiert, unterschiedliche Value-/Type-Spalten mit dem gemeinsamen Warning-Akzent markiert; keine Variante wird als Gewinner oder Baseline-Sollwert behauptet. Gemeinsame Einstellung/Scope/Pfad stehen einmal im Results-Kontext, eine zweite Tabelle bindet jede Source an Variante, Originalpfad, Backup und Record. Der Reader zeigt eine kurze Konfliktzusammenfassung statt wiederholter Kundenwerte/Sources; ohne gueltige strukturierte Details bleibt die bisherige Evidenzdarstellung erhalten. Inerte, begrenzte JSON-Leseprojektion mit Whitespace-Erhaltung, keine Migration/Neubewertung oder Originaldatenmutation. Acht synthetische Regressionen inklusive Typkonflikten, HTML-Inertheit, aktivem Results-Button, Fallback und 2.300 Quellen; 911 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert. + +GPO-Misconfiguration-Fokus 2026-09-06 (Phase 7/13B, ausdrueckliche Nutzerkorrektur): Deviation enthaelt fuer GPOs nur gesetzte Kundenwerte mit expliziter vorhandener Baseline und deterministischer Abweichung. Fehlende Einstellungen werden als Not configured/informational separat angezeigt, nicht als Fail/Deviation; Conflicts und Duplicates bleiben eigene Filter ohne Deviation-Zaehlung. Der neue reine Lesekontrakt gilt fuer Work, Dashboardfilter, Result-DB-Vergleichsprojektion und bereits materialisierte Factory-Ergebnisse (Rueckbindung an deren gespeicherten Vergleich, ohne fehlende Evidenz Fail zu behaupten). Gemischte Scanner/GPO-Profile behalten die separaten Filter; Scanner-Semantik unveraendert. GPO Analysis trennt Misconfigured/Not configured und zaehlt betroffene Settings sowie GPO-Backupinstanzen dedupliziert; alte Historienzaehler sind ausdruecklich als gespeicherte Mismatches einschliesslich fehlender Werte bezeichnet. Work-Projektion 1.2.0, Result-DB-Praesentation 1.1.0; keine Migration, Reimporte oder Mutation gespeicherter Evaluationen/Originale. Ersetzt die bisherige fehlende-Werte-als-Fail-Entscheidung; Vergleichs-/Resultvertrag angepasst. 903 Tests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich. Laufendes Entwicklungsbackend per inhaltsfreiem Health-/Buildhash-Abgleich aktuell; keine Kundendateninspektion oder Live-Inhaltsabnahme. Phasenstatus unveraendert. + +AI-Suchkontext 2026-09-06 (Phase 7): Auf Nutzerwunsch ergaenzt der Suchlink Scope, exakt freigegebene Baselinebezeichnungen und feste Vergleichsszenarien. Bekannte Audit-Abhilfe fuer System Integrity/Logoff wird aus eindeutigen booleschen Sollflags, Expected/Must include und passendem Titel/Scope aufgebaut; keine freie Textweitergabe. Description-Platzhalter und unverifizierte importierte Beschreibungen/Abhilfetexte bleiben ausgeschlossen. Sicherheitsmodell dokumentiert die eng begrenzte Freigabe und verbleibende Google-IP-/Kontodatenverarbeitung ohne DSGVO-Pauschalzusage. Sechs neue synthetische Datenschutz-/Kontexttests; 898 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Kundendateninspektion, Suchausfuehrung mit Findingdaten oder Datenmutation. Phasenstatus unveraendert. + +AppLocker-Wertdarstellung 2026-09-06 (Phase 7): AppLocker-XML erscheint als lesbare Regelfelder statt Roh-XML/Codeblock in Kundenwert, Baselinewert, abgeleiteter Remediation und Sources. Bedingungen, Ausnahmen, Versionsgrenzen, IDs und unbekannte Erweiterungen bleiben erhalten. Begrenzter SAX-Formatter in der Praesentationsschicht; fehlerhafte/unsupported Werte bleiben escapeter Originaltext ohne aktive Links oder HTML. Vergleich, Persistenz und Originaldaten unveraendert. Sieben neue synthetische Regressionen, bestehende Reader-Pruefung angepasst; 892 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Bestehender Bundle-Groessenhinweis; keine Realdateninspektion oder visuelle Live-Abnahme. Phasenstatus unveraendert. + +Remediation-Hervorhebung 2026-09-06 (Phase 7): Remediation-Abschnitte im FindingReader sind auf Nutzerwunsch mit derselben dezenten Gruenflaeche und Akzentlinie wie Expected baseline value hinterlegt. Gemeinsamer Success-Token fuer beide Themes; Beschreibung, Sources, Inhalte und Bewertung bleiben unveraendert. Synthetische Renderingregression; 885 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Datenmutation; Phasenstatus unveraendert. + +Praezise Google-AI-Suche 2026-09-06 (Phase 7): Der bisherige Web-search-Button heisst AI search und verwendet einen Google-AI-Mode-Deep-Link. Die oeffentliche Begriffsliste erkennt jetzt zwoelf konkrete Firewall-Einstellungen und deren Domain-/Private-/Public-Profil sowie feste Microsoft-Produktversionen; doppelte Oberbegriffe wie Windows Windows Firewall entfallen. Der Prompt fragt nach Sicherheitszweck, Konfigurationsort und versionsabhaengiger Microsoft-Baselineempfehlung mit offiziellen Quellen. Keine rohe Titel-/Pfad-/Wertweitergabe; unbekannte Einstellungsnamen bleiben bei einem allgemeinen Thema. Referrer-/Opener-Schutz und expliziter Klick bleiben unveraendert, Sicherheitsmodell fortgeschrieben. Google-Dokumentation bestaetigt den allgemein verfuegbaren AI Mode, waehrend Zusatzfunktionen/Limits/Kontoverfuegbarkeit anbieterabhaengig sind; keine Garantie fuer externe Antworten. 884 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Nur synthetische Datenschutz-/URL-/UI-Tests; ein oeffentlicher Deep-Link-Abruf war ueber das Recherchewerkzeug nicht verfuegbar, keine Live-Abnahme im Google-Konto. Keine Kundendaten oder Bewertungsaenderungen; Phasenstatus unveraendert. + +GPO-Sources-Darstellung 2026-09-06 (Phase 7): Sources wird aus den vorhandenen strukturierten Beobachtungen als getrennte, nummerierte Quellbloecke mit Source path, Scope, Registry path, Value name, Value, lesbarem Registrytyp und Operation projiziert. Backup-/Recordreferenzen und optionale Targets/Secure-Angaben bleiben erhalten; keine kompakte JSON-Kette fuer Registrywerte. Native Policywerte werden lesbar formatiert. Der Reader rendert Sources als escapeten Text mit Zeilenumbruechen und Pfadumbruch, nicht als HTML oder externe Links. Originaldaten und Vergleich bleiben unveraendert. Vier synthetische Regressionen einschliesslich Nullwert, mehreren/2.300 Quellen, Auditflags und inerten Pfaden; 880 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Realdateninspektion; Phasenstatus unveraendert. + +GPO-Beschreibung, Abhilfe und sichere Websuche 2026-09-06 (Phase 7/13B): Work laedt zu den ausgewaehlten Evaluationen einmal je referenzierter Baseline die vorhandenen Analysen ueber die bestehende API. Originale ADML-Erklaertexte werden ausschliesslich ueber die exakte Analysis-/Baseline-/Catalog-/Policy-/Sprachdateizuordnung aufgeloest (Englisch bevorzugt); fehlende oder widerspruechliche Texte werden nicht erfunden. Description source bleibt unter Additional Information. Remediation wird als Einstellungsziel und vorhandener Baseline-Sollwert mit Vergleichsoperator abgeleitet, nicht als behauptete Microsoft-Schrittanleitung; keine Abhilfe gegen leere oder widerspruechliche Vorgaben. Reine Leseprojektion fuer vorhandene Evaluationen, keine Reimporte, Neuauswertungen, Persistenz- oder Schemaaenderungen. Dokumentationsfehler blockieren Work nicht. Der Button Web search oeffnet erst bei Klick eine Google-Suche auf Microsoft Learn; Queries bestehen ausschliesslich aus fest freigegebenen oeffentlichen Begriffen (bekannte Einstellungen oder allgemeines Fachthema), niemals aus importierten Titeln, Kundendaten, Pfaden oder Werten. Referrer/Opener sind gesperrt, Beschreibung und Abhilfe bleiben inerte Textdarstellung. Die explizit freigegebene externe Navigation samt Grenzen ist im GPO-Bedrohungsmodell dokumentiert; Sentinal diente nur als UI-Referenz, dessen direkte Titelweitergabe wurde nicht uebernommen. 876 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Realdateninspektion und kein Test-Suchaufruf. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. + +Pass-Farbe 2026-09-06 (Phase 7, ausdrueckliche Nutzerkorrektur): Der gemeinsame Outcome-Token fuer Pass/Passed ist in beiden Themes gruen statt grau. Dies ersetzt die bisherige bewusste Gruen-Ausnahme fuer bestandene Ergebnisse; Severityfarben und fachliche Statusnormalisierung bleiben unveraendert. Liste, FindingReader und andere gemeinsame Outcome-Anzeigen nutzen denselben Token. Synthetische Regression prueft mindestens 4,5:1 Textkontrast auf Panel-, erhoehten, aktiven und ausgewaehlten Listenflaechen beider Themes. 866 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Datenmutation, keine Live-Inhaltsinspektion; Phasenstatus unveraendert. + +GPO-Scope-Badge 2026-09-06 (Phase 7): Der vorhandene Scope erscheint zusaetzlich als kompaktes Badge im FindingReader; das Scope-Feld in der Reportansicht bleibt unveraendert erhalten. Fehlende/leere Werte erzeugen kein Badge. Drei synthetische Regressionen fuer computer, user und fehlenden Scope; 864 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Daten- oder Bewertungsaenderung; Phasenstatus unveraendert. + +GPO-Kategorie-Badges 2026-09-06 (Phase 7): Der FindingReader zeigt neben GPOs kurze abgeleitete Produkt-/Bereichsbadges: Windows, Office, Edge sowie Audit, Defender, Firewall, BitLocker, LAPS oder allgemein Security. Die reine Praesentationszuordnung verwendet Baselinebezeichnung, expliziten Registry-Pfad und Policytyp/-sektion; unbekannte Einstellungen erhalten keine erratene Spezialkategorie. Baseline-only-Auditvergleiche bleiben auch ohne Kundenwert als Audit erkennbar. Produktbadges beschreiben den Benchmark, nicht die nachgewiesene Zielanwendbarkeit; die Bereichstaxonomie ist eine ASSESSOR-Anzeige, keine neue Microsoft-Bewertung. Keine Aenderung an Outcomes, Persistenz, API oder Quelldaten. 861 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Groessenhinweis). Nur synthetische Tests; keine Realdateninspektion oder visuelle Live-Abnahme. Phase 7 bleibt abgeschlossen. + +GPO-Finding-Ueberschrift 2026-09-06 (Phase 7, Produktversion 2.5.4): Der normalisierte `Value Name` einer GPO-Registry-Einstellung bildet jetzt die Ueberschrift des Finding-Abschnitts. Derselbe Wert wird im Block `Configured customer value` nicht wiederholt; konfigurierte und erwartete Werte bleiben direkt vergleichbar. Persistierte Quellwerte und Vergleichslogik bleiben unveraendert. 843 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Daten-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen. + +GPO-Analyse-UX-Korrektur 2026-09-06 (Phase 7/13B, Produktversion 2.5.3): Der nicht abgestimmte Sammelstatus `Limited analysis` ist wieder entfernt. Ein technisch partiell abgeschlossener GPO-Import wird im Timeslot als `Imported` und im Importdetail als `Imported with review items` ausgewiesen; ohne konkrete Nutzeraktion bleibt der Client bereit und erhaelt kein automatisches Manage. Die Standardansicht der GPO Analysis zeigt jetzt ausschliesslich Importumfang, Baselineergebnisse und konkret benannte Importprobleme; Abweichungen werden als einzelne Einstellungsvergleiche erklaert. Workflow, Historie, Review-Codes und Processing-Aktionen bleiben fuer Diagnosezwecke unter `Technical details` beziehungsweise `Processing controls` aufklappbar. Im Work-Finding stehen der konfigurierte Kundenwert und der erwartete Baselinewert direkt untereinander, werden fuer lesbare Anzeige formatiert und bei Abweichungen rot/gruen markiert; persistierte Quellwerte bleiben unveraendert. 843 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Daten-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. Diese Nutzerkorrektur ersetzt die unmittelbar vorherige Statusentscheidung fuer `Limited analysis`. + +GPO-only-Timeslot-Scope 2026-09-06 (Phase 7/13B): Alle Clientansichten erkennen einen ausgewaehlten Timeslot nun zentral sowohl ueber Scanner-Run-IDs als auch ueber Assessment-IDs. Damit funktionieren reine GPO-Timeslots in Client Info, Work, Result DB und Pathfinder, ohne faelschlich `No timeslot selected` anzuzeigen oder einen Scannerlauf aus einem anderen Stand einzumischen; Datahub und DB Structure bleiben wie bisher unabhaengig vom geladenen Scannertyp. Result-DB-Laden und -Export verwenden denselben projekt- und assessmentgebundenen Scope. 25 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit. + +Status und Aenderungsprotokoll 2026-09-06 (Phase 7, Produktversion 2.5.2): `Partial import` beziehungsweise `Partially processed` heisst jetzt `Limited analysis`. Abgeschlossene eingeschraenkte Analysen und laufende GPO-Jobs sind eigene gelbe Informationszustaende; sie loesen weder automatisches Manage noch eine automatische Expansion als Handlungsaufforderung aus. Fehler/Recovery und notwendige Scanner-Reimporte behalten Vorrang und automatisches Manage; die manuelle Verwaltung ausgewaehlter Clients bleibt verfuegbar. Diese Nutzerkorrektur ersetzt die bisherige Gleichsetzung aller nicht erfolgreichen GPO-Zustaende mit Handlungsbedarf. Analysegrenzen bleiben sichtbar und werden nicht als vollstaendige Auswertung bezeichnet. 839 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests; keine fachliche Pipeline-, Daten- oder Schemaaenderung. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. + +UI-Sprache 2026-09-06 (Phase 7, verbindliche Produktvorgabe): Saemtliche nutzerseitig sichtbaren Texte in ASSESSOR werden auf Englisch formuliert. Das gilt insbesondere fuer Navigation, Titel, Labels, Buttons, Status-, Lade-, Leer-, Fehler-, Bestaetigungs- und Dialogtexte sowie neu hinzukommende Funktionen. Deutsche Texte duerfen nur in interner Dokumentation, Kommentaren oder ausdruecklich angeforderten Exportinhalten vorkommen. Der verbliebene Ladehinweis der Data-Hub-Historie lautet nun `Loading clients …`. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Panel-Ladezustand 2026-09-06 (Phase 7): Inhaltsbereiche mit initialem, asynchronem Laden verwenden nun einen gemeinsamen, markenfreien Ladezustand: Der jeweils konkrete Ladetext steht mit der aus den Processing-Pop-ups bekannten quadratischen Ladeanimation unmittelbar daneben mittig im verfuegbaren Panelbereich. Client Info, DB Structure, Result DB, Data-Hub-Historie, Timeslot-Liste und Policy Analysis sind angebunden; kleinere eingebettete Bereiche verwenden dieselbe Darstellung kompakter. Fehler-, Leer- und laufende Operationsdialoge bleiben fachlich getrennt. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +GPO-Importkorrektur 2026-09-06 (Phase 13B): Byte-identische Policydateien an unterschiedlichen Pfaden erhalten nun unterschiedliche, weiterhin deterministische Observation-IDs, weil der exakte Quellartefaktbezug Bestandteil der ID ist. Damit wird ein gueltiges Kundenbackup nicht mehr als `duplicate-observation` atomar abgelehnt. Der automatische Pfad verlangt bei einem reinen GPO-Backup keinen zusaetzlichen Betriebssystemkontext mehr, sondern wertet alle importierten, als `eligible` klassifizierten Microsoft-Baselines als getrennte Benchmarks aus; erkannte DC-Kontexte bleiben als Evidenz erhalten. Ein gemeinsam hochgeladener `selected-gpos`-Satz bleibt auch bei fehlenden oder gemischten Domainmetadaten ein einzelner, bewusst partieller Snapshot statt in nicht auswertbare Einzelsnapshots zu zerfallen. Parser-/Analyzervertrag 2.2.2, Snapshotaggregation 1.1.0 und Produktversion 2.5.1 markieren die kompatible Fehlerkorrektur. Synthetische Regressionen fuer zwei identische Security-Template-Dateien an verschiedenen Pfaden, kontextfreien Auto-Vergleich, Baseline-Auswahl, gemischte Uploadmetadaten und den 2.300-GPO-Lastfall sind gruen. Inhaltsfreie technische Kontrolle am betroffenen Import: Status-API HTTP 200, kein fehlgeschlagener Job, 184 erkannte GPOs sowie 3.638 Work-Ergebnisse mit 162 Uebereinstimmungen und 3.358 Abweichungen; Quellinhalte wurden weder ausgegeben noch manuell inspiziert. Gesamtlauf: 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration; Phase 13B bleibt in Arbeit. + +GPO-Statuspraezisierung 2026-09-06 (Phase 7/13B): Ein vollstaendig erfolgreich verarbeiteter GPO-Backup-Eintrag zeigt im Timeslot `Ready` statt des rein uploadbezogenen `Imported`. Queued, Processing, Partial import, Failed und Recovery pending bleiben unveraendert, damit technische Zwischen-, Teil- und Fehlerzustaende weiterhin sichtbar sind. Zehn fokussierte synthetische Tests und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. + +Branding-Korrektur 2026-09-06 (Phase 7): Die ASSESSOR-Marke verwendet in Sidebar, leerem Arbeitsbereich, Favicon und About-Dialog ein gemeinsames PNG mit echter Transparenz; weisser Hintergrund, weisses A-Innenfeld und weisser Haken sind entfernt, nur die rote Marke bleibt. Der klickbare Brand-Trigger behaelt Position und zugaengliche About-Beschriftung, zeigt beim Hover jedoch keine Buttonflaeche. Der bestehende About-Dialog stellt die Marke mit 160 px dominant ueber den Produkt- und Processingdaten dar. Fuenf fokussierte Tests und Client-/Serverbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung, Phase 7 bleibt abgeschlossen. + +Review-Persistenz und Vergleichsplanung 2026-09-06 (Phase 8/9/10): Die FindingReader-Felder Bookmark, Status, Prioritaet, Owner/Team, Due Date, Prerequisites, Required Access/Roles, Next Step, Evidence/Acceptance Criteria, Comment und alle fuenf Marker sind ueber die bestehende Same-Origin-Review-API an das kanonische Finding-Vorkommen gebunden und werden in der ASSESSOR-Datenbank gespeichert. Aggregate und Werkzeugblatt teilen dadurch denselben Reviewstand; vorhandene Browserwerte bleiben als Rueckfallkopie erhalten und werden bei noch fehlendem Datenbankreview uebernommen. Additive JSONB-Vertragserweiterung, keine SQL-Migration und keine Realdateninspektion. Das unten in Phase 8 ausformulierte Quellen-Fortschreibungsmodell ist als spaeteres Arbeitspaket beschlossen, aber noch nicht implementiert. + +GPO-Loeschkorrektur 2026-09-06 (Phase 7/13B): Jeder beendete GPO-Eintrag im Timeslot besitzt neben Evaluate beziehungsweise Retry eine eigene Delete-Aktion mit Warnungsdialog. Die bestaetigte projekt-/artefaktgebundene Mutation entfernt das ausgewaehlte GPO-Original, Processing-/Identity-Historie und alle davon abhaengigen Snapshot-, Evaluation- und Finding-Derivate; Timeslot, Environment Profile, Scannerimporte und andere GPO-Eintraege bleiben erhalten. Queue-/Running-Zustaende sind gegen paralleles Loeschen gesperrt. 829 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Loeschtests; der GPO-Pfad benoetigt keine neue Migration und hat keine kanonischen Fachdaten mutiert. Beim anschliessenden Neustart wurde die bereits im Workspace anstehende Migration 020 nach Korrektur einer kollidierenden automatisch vergebenen Constraint-Bezeichnung auf dem kanonischen 2.0-Bestand angewandt; App und PostgreSQL-Backend melden HTTP 200. Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit. + +UI-Textstandard 2026-09-06 (Phase 7, verbindlicher Nutzerwunsch): Funktionen mit kurzen, praegnanten Namen benennen, moeglichst ein Wort oder eine kurze Aktion. Name und Bedienelemente genuegen; keine ungefragten Erklaerabschnitte oder begleitenden Funktionsbeschreibungen. Gilt auch fuer GPO Analysis. Zusaetzliche Erlaeuterungen nur auf Nutzerwunsch; notwendige Fehler-/Sicherheitsmeldungen knapp und konkret halten. Der Timeslot-Importbereich heisst jetzt "Add Entry" ohne Beschreibung. Ersetzt die vorherige Entscheidung fuer den langen Hinzufuegen-/Erhaltungshinweis; keine Funktionsaenderung. + +UI-Korrektur 2026-09-06 (Phase 7): Timeslot-Gridzeilen behalten ihre Inhaltshoehe statt lange Details am unteren Rand abzuschneiden. Die Quellenliste ist auf maximal 40vh/384px begrenzt und separat scrollbar; Importaktionen liegen ausserhalb und sind bei jedem aufgeklappten Slot unabhaengig von der Checkbox verfuegbar. 809 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Client-/Serverbuild, Local-only und Designpruefung erfolgreich. Keine Datenmutation oder visuelle Browserabnahme; Phasenstatus unveraendert. + +UI-Praezisierung 2026-09-06 (Phase 7): Eintragsaktionen bleiben auch in schmalen Timeslot-Listen rechts neben dem zugehoerigen Scan/GPO-Eintrag. Importaktionen sind als "Add entry to this timeslot" mit Erhaltungshinweis gekennzeichnet; "Entire timeslot / Delete timeslot" steht separat darunter. Der bestehende Importpfad fuegt ohne replacesScanRunId einen neuen Scan hinzu; keine Persistenzaenderung. 808 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Client-/Serverbuild, Local-only und Designpruefung erfolgreich. Keine visuelle Browserabnahme; Phasenstatus unveraendert. + +Praezisierung 2026-09-06 (Phase 7, Nutzerkorrektur zur Open-Freigabe): Open bleibt auf Client-Kachel und einzelnem Time-Slot deaktiviert, bis gespeicherte Scanner-Findings oder Policy-Observations fuer den Assessment-Scope nachgewiesen sind. Upload-/Jobstatus allein reicht nicht. Die vorhandene Facetten-API liefert die Ergebniszaehler; ungeklaerte/fehlgeschlagene Abfragen sperren Open. Manage/View behalten ihre Diagnosefunktion. 807 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only/Design erfolgreich. Keine neue API oder Datenmutation; Phase 7 bleibt abgeschlossen. Diese Freigaberegel ersetzt die vorherige Oeffnung leerer GPO-Workspaces. + +Korrektur 2026-09-06 (Phase 7 / 13B, ersetzt die vorherige GPO-Open-Sonderroute): Auf ausdruecklichen Nutzerwunsch oeffnet Open den Client in Client Info; ausschliesslich View fuehrt zur GPO-Analyse. GPO-only-Kacheln sind oeffenbar, der gewaehlte Assessment-Scope wird durch Workspace-Laden und Auffrischen weitergereicht und gegen automatische Scanner-Timeslot-Auswahl geschuetzt. Ohne Ergebnisse erscheint ein Client-Hinweis, alte Clientdaten werden beim Wechsel entfernt. Gemeinsame Hover-Regel fuer normale Quellenzeilenbuttons umfasst jetzt auch View in beiden Themes. Client-/Serverbuild, 14 fokussierte Tests sowie Local-only/Design erfolgreich. Gesamtlauf zuletzt 804 bestanden, 8 uebersprungen, ein anschliessend korrigierter synthetischer Test ohne Assessment-Zuordnung; betroffene Suite im fokussierten Nachlauf gruen. Fruehere Client-Open-Quelltextpruefung an neue Signatur und Whitespace angepasst. Keine Persistenz-/Backend-Aenderung oder visuelle Realdatenabnahme; Phasenstatus unveraendert. + +Nachpruefung 2026-09-06 (Phase 7 / GPO-Oberflaeche Phase 13B): Client-Verarbeitungsstatus umfasst jetzt Scanner und GPOs ueber alle Timeslots. Dead-letter und Recovery markieren den Client rot mit auswahlunabhaengigem Manage; ausstehende oder partielle GPO-Verarbeitung bleibt gelb, vollstaendig erfolgreiche gruen. GPO-Status wird alle fuenf Sekunden nachgeladen; Manage expandiert auch betroffene GPO-Timeslots. 13 fokussierte synthetische Tests inklusive unselektierter Fehlerkachel, Client-/Serverbuild sowie Local-only-/Designpruefung erfolgreich. Bekannter unabhaengiger Client-Open-Quelltexttest weiterhin rot. Keine Datenmutation oder visuelle Realdatenpruefung; Phasenstatus unveraendert. + +Nachpruefung 2026-09-06 (Phase 7): Retry in der GPO-Time-Slot-Zeile behaelt beim Hover die eigene Buttonflaeche und nutzt den gemeinsamen staerkeren Rand, damit es nicht mit dem Zeilenhover verschmilzt. Destruktiver Delete-Hover bleibt unveraendert. Client-/Serverbuild, Local-only und Designpruefung erfolgreich; der bekannte unabhaengige Client-Open-Quelltexttest bleibt rot. Rein lesende technische Jobpruefung: Ein GPO-Job steht nach 3/3 Versuchen wegen `gpo-metadata-size-limit` auf dead-letter; der Parser begrenzt einzelne Metadaten-XML-Dateien auf 2 MiB. Das Importlimit wurde nicht geaendert, kein Retry ausgeloest. Phase 7 bleibt abgeschlossen; keine visuelle Browserabnahme. + +Nachpruefung 2026-09-06 (Phase 7 / GPO-Oberflaeche Phase 13B): Schmale Time-Slot-Quellenlisten wechseln unter 620 px Containerbreite auf mehrzeilige Eintraege; Quellenzellen koennen schrumpfen und lange Dateinamen umbrechen. Open fuehrt bei einem einzelnen GPO-Time-Slot ohne anzeigbaren Scanner zur bestehenden projektweiten GPO-Analyse, auch waehrend der Verarbeitung. Mehrfachauswahl bleibt auf vergleichbare Scanner begrenzt. Vier fokussierte Tests und Client-/Serverbuild erfolgreich; Gesamtlauf: 798 bestanden, 8 uebersprungen, ein unabhaengiger Fehler im whitespace-abhaengigen Client-Open-Quelltexttest. Kein Nachweis fuer einen erfolgreich verarbeiteten realen GPO-Job und keine visuelle Browserabnahme; Phasenstatus unveraendert. Bestehende Datenbankkonfiguration bleibt unberuehrt. Erstellt: 2026-07-17 Zuletzt aktualisiert: 2026-08-25 Aktuelle Entwicklungsstufe: lokale React-/Tauri-Anwendung @@ -86,6 +530,7 @@ Die heutige Tauri-Anwendung bleibt zunächst eine lokale Laufzeitumgebung. Das | 6 | Deklarative Toolprofile und generischer Fallback | abgeschlossen | | 7 | Automatische Filter- und Darstellungslogik | abgeschlossen | | 8 | Vergleichsengine für Assessment-Läufe | abgeschlossen | +| 8 (Erweiterung 2026-09-11) | Belastbarer A/B-Timeslotvergleich und offene Verpflichtungen; P0 abgeschlossen, P1/P2 in Arbeit, P3-P6 offen | in Arbeit | | 9 | Fachliche Persistenzschnittstelle | abgeschlossen | | 10 | Lokales Backend über `localhost` | abgeschlossen | | 11 | PostgreSQL und Datenbankmigrationen | abgeschlossen | @@ -94,6 +539,7 @@ Die heutige Tauri-Anwendung bleibt zunächst eine lokale Laufzeitumgebung. Das | 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 | +| 13D | Regulatorische Kontrollsuche und RAG-Grundlage mit Qdrant | in Arbeit | | 14 | Mehrbenutzer- und Firmenbetrieb | offen | ## 7. Phasen im Detail @@ -358,6 +804,11 @@ Verifizierter Abschlussstand vom 2026-07-17: - 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. +Verifizierte Erweiterung vom 2026-09-10: + +- Das versionierte Profil `defender-for-iot-vulnerabilities` 1.0.0 erkennt kombinierte sowie einzelne Asset-Summary- und CVE-Detailtabellen ueber Strukturmerkmale und nutzt dieselbe Profilfabrik wie die bestehenden Scanner. +- CVE, Beschreibung, Severity, normalisierte Device-Identitaet und strukturierte Sensorbeobachtungen werden deklarativ auf kanonische Rollen abgebildet. Bestehende Profile und der generische Fallback bleiben unveraendert. + Abnahmekriterien: - Neue Profile benötigen keine Änderungen an React-Komponenten oder Formatparsern. @@ -368,6 +819,48 @@ Abnahmekriterien: Status: abgeschlossen +Verifizierte Produktversionsanzeige vom 2026-09-06: Der Markenblock zeigt die zentrale npm-Produktversion, aktuell `ASSESSOR 2.5.1`, statt des davon unabhaengigen Processingvertrags. Der gesamte Markenblock oeffnet ein kompaktes About-Popup mit Produkt-, Build-, Backend-, Import- und GPO-Komponentenversionen sowie den dezenten Credits Michael Lukas und Binh Karl. Die Health-API meldet die Backend-Produktversion, sodass Frontend- und Backendstand erkennbar sind. Version 2.5.1 ist der erste kompatible Patch nach Einfuehrung von 2.5.0 und korrigiert den GPO-Import byte-identischer Dateien an verschiedenen Pfaden. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phase 7 bleibt abgeschlossen. + +Verifizierte Result-DB-Filter-/Exportnachschaerfung vom 2026-09-03: Die Result DB startet und resettiert mit `Deviation = Yes`. Ein neuer `Export JSONL`-Button exportiert nicht nur die geladene Seite, sondern die vollstaendige aktuelle Filter- und Timeslot-Ergebnismenge ueber stabile Seitenabfragen. Zeile eins dokumentiert Format-/Schemaversion, Zeitpunkt, Scope, angewandte Filter und Ergebnisanzahl; danach folgt je Result genau ein vollstaendiges JSON-Objekt. Aendert sich die Ergebnismenge waehrend des Exports, wird der Download fail-closed abgebrochen. Drei fokussierte Export-/Scope-Tests und der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Balkenformatierung vom 2026-09-03: Die wiederverwendeten Kennzahlzeilen besitzen nun identische Label-, Balken- und Wertspalten sowie eine in jeder Zeile reservierte Statuszeile. Optionale `Restricted`-Hinweise verschieben dadurch keine Nachbarzeilen mehr; Zahlen, Einheiten und Balken bleiben ueber alle gleich breiten Karten ausgerichtet. Die kompakte Infrastructure-&-Resilience-Ausnahme behaelt ihre eigenstaendige Einspaltengeometrie. 13 fokussierte Dashboard-/Kacheltests, der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierter Work-Kachelvertrag vom 2026-09-03: Regulaere Finding-Kacheln verwenden die Nutzerreferenz als verbindliches Mindestformat mit 358 px Breite und 223 px Hoehe. Das Raster streckt unvollstaendige Reihen nicht mehr auf Restbreite; Hexagon, Titel und rechte Aktionsspalte bleiben im Kopf. Die Metadaten folgen einer festen semantischen Matrix aus Status, Kategorie, Severity plus Weight und Score. Die Hoehe darf bei laengerem Inhalt weiter wachsen; Pathfinder-Micro-Cards bleiben von der Work-spezifischen Anordnung ausgenommen. 16 fokussierte Kachel-/Typografie-/Pathfinder-Tests, der Gesamtlauf mit 768 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Infrastructure-&-Resilience-Korrektur vom 2026-09-03: Die inhaltsreiche Dashboardkachel reserviert drei statt zwei Rasterzeilen und ist als gezielte Ausnahme nicht mehr an ein starres Quadratverhaeltnis gebunden. Lange, vollstaendige OS-Aufzaehlungen bleiben dadurch innerhalb der Kartenflaeche; Faktenraster, Werte und die uebrigen quadratischen Dashboardkacheln bleiben unveraendert. 14 fokussierte Dashboard-/Inset-Tests, der Gesamtlauf mit 769 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Unmittelbare responsive Nutzerkorrektur vom 2026-09-03: Die feste Drei-Zeilen-Ausnahme wird durch inhaltsbasierte Rasterhoehen ersetzt. Jede Client-Info-Inhaltskarte behaelt ihre quadratische Mindestgeometrie, darf aber anhand ihres vollstaendigen Inhalts wachsen; `Infrastructure & Resilience` verwendet eine automatische Inhaltshoehe. Die breakpointabhaengige Rastereinheit bleibt als Mindesthoehe erhalten, waehrend `minmax(..., auto)` zusaetzlichen Platz ohne Ueberlauf bereitstellt. 14 fokussierte Dashboard-/Inset-Tests, der Gesamtlauf mit 770 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Progressive-Disclosure-Nachschaerfung vom 2026-09-03: Die sechs reinen Zahlenkacheln bleiben unveraendert quadratisch. Alle neun vorhandenen Detailbereiche starten dagegen als kompakte Telemetriekarten mit Titel, bestehender Metainformation, fachlicher Primaermenge und proportionalem Mengenbalken. Ein zugaenglicher Plus-/Minus-Schalter blendet die vollstaendigen bisherigen Donut-, Balken- und Fakteninhalte je Karte unabhaengig ein beziehungsweise aus. Erfundene Mockup-Bereiche wurden nicht uebernommen. Inhaltsbasierte Rasterhoehen verhindern Ueberlauf auch im expandierten Zustand. 15 fokussierte Dashboard-, Interaktions- und Inset-Tests, der Gesamtlauf mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Panelstil-Korrektur vom 2026-09-03: Die neun Infopanels folgen nun der ausdruecklichen Nutzerreferenz. Im minimierten Zustand ist ausschliesslich die luftige Kopfzeile `Titel — Primaermenge` mit Plus sichtbar; es gibt dort keinen Balken. Erst die aufgeklappte Ansicht zeigt hohe, grosszuegig getrennte Datenzeilen mit Label, Wert und einem 72 px dicken, breiten Mengenbalken. Assessment Status und Severity Distribution verwenden ebenfalls Mengenbalken statt Donuts, behalten aber ihre vorhandenen Filteraktionen. Faktenzeilen folgen derselben luftigen Vertikalgeometrie; die fruehere kompakte Resilience-Sonderdarstellung entfaellt. Die sechs reinen Zahlenkacheln bleiben unveraendert. 12 fokussierte Layout-/Interaktionstests, alle 774 Standardtests, Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden erwartungsgemaess uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Unmittelbare Breitenkorrektur der Client-Info-Infopanels vom 2026-09-03: Die aufgeklappte Karte belegt im regulaeren Raster sechs statt weiterhin nur zwei Spalten. Unterhalb von 800 px verwendet sie alle vier, unterhalb von 560 px alle zwei verfuegbaren Spalten. Damit bleibt die bestaetigte linke Label-/Wertzone neben dem breiten rechten Balkenbereich innerhalb derselben Kartenflaeche; die minimierte Zwei-Spalten-Kopfzeile bleibt unveraendert. Der in der Kopfzeile bereits dargestellte Primaerwert wird expandiert nicht als erste Zeile dupliziert. Neutrale Analysepanels uebernehmen fuer ihre restlichen Mengen die rote, orange, gelbe, violette und bei Bedarf neutrale Reihenfolge der Referenz; fachlich bereits festgelegte Status-, Coverage-, PKI- und GPO-Farben bleiben erhalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Abschliessende bildbezogene Client-Info-Layoutkorrektur vom 2026-09-03: Die sechs quadratischen Zahlenkacheln bilden wieder eine eigene obere Sechserspur. Darunter stehen die sechs real vorhandenen Mengenpanels dauerhaft sichtbar in einem dreispaltigen Telemetrieraster; Plus/Minus steuert nur zusaetzliche Angaben und entfernt die Mengenzeilen nicht. Assessment Status und Severity Distribution sind wieder als echte Donut-Kacheln hergestellt und bilden gemeinsam mit Directory Overview die rechte Nebenspalte. Mengenzeilen verwenden die kompakte Referenzgeometrie mit 64 px Zeilenhoehe und 30 px dicken Balken; die bisherige uebergrosse 120-/72-px-Ausfuehrung und die expandierte Sechs-Spalten-Sonderbreite sind damit supersediert. Bei kleineren Viewports reduzieren sich Mengenraster und Donutspalte kontrolliert beziehungsweise stapeln sich. 12 fokussierte Layout-/Interaktionstests, die Gesamtsuite mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Erstreihenkorrektur vom 2026-09-03: Die obere Zone teilt sich jetzt im selben 3:1-Verhaeltnis wie der Inhaltsbereich. Die sechs weiterhin quadratischen Zahlenkacheln belegen verkleinert das linke Dreiviertel; `Assessment Status` steht als Donut-Kachel direkt rechts daneben in Reihe 1. Dadurch ruecken `Severity Distribution` und anschliessend `Directory Overview` in der rechten Rail jeweils nach oben. Unterhalb von 1100 px stapelt sich die Kopfzone und die Zahlenkacheln wechseln kontrolliert auf drei, unterhalb von 800 px auf zwei Spalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Open-Standardansicht vom 2026-09-03: Das direkte Oeffnen eines Clients beziehungsweise seiner ausgewaehlten Timeslots aus Data Hub fuehrt ab jetzt in `Client Info` statt `Work`. Projektname, Projekt-ID und die konkrete ScanRun-Auswahl werden unveraendert uebernommen; nur das initial aktive Hauptgebiet aendert sich. Bewusste spaetere Navigation zu Work, Result DB oder Pathfinder bleibt unveraendert. Neun fokussierte Data-Hub-/Header-/Clientdetailtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Minimierkorrektur vom 2026-09-03: Alle neun Informationskacheln starten vollstaendig geoeffnet mit Minus und lassen sich nun ueber denselben zugaenglichen Schalter auf ihre reine Kopfzeile mit Plus minimieren. Das gilt einheitlich fuer die sechs Mengen-/Faktenkarten sowie Assessment Status, Severity Distribution und Directory Overview; beim erneuten Oeffnen wird der vollstaendige Inhalt wiederhergestellt. Minimierte Karten werden auch in Rasterzeilen mit hoeheren Nachbarkarten nicht mehr leer auf deren Hoehe gestreckt. Die sechs reinen Zahlenkacheln bleiben unveraendert. Die beiden gemeinsamen Kartenvertraege und alle neun konkreten Titel/Instanzen sind synthetisch beziehungsweise statisch regressionsgeprueft. 13 fokussierte Dashboard-/Interaktionstests, die Gesamtsuite mit 776 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Maester-Fehlerdarstellung vom 2026-09-03: Eindeutig erkannte `Invoke-MgGraphRequest`-Ausfuehrungsfehler werden im Results-Fenster nicht mehr als unstrukturierter Inline-Rohtext dargestellt. Die eigentliche Graph-Fehlermeldung steht als lesbare Primaeraussage oben; Fehlercode, HTTP-Status, Methode und Endpunkt, Skriptquelle, Zeit sowie vorhandene Request-IDs folgen als beschriftete strukturierte Felder. Der vollstaendige unveraenderte Quelltext bleibt unter `Technical details` einklappbar. Normale Maester-Ergebnisse und andere Werkzeuge verwenden weiterhin die generische Rich-Text-Darstellung. 48 fokussierte Result-/Reader-Tests und Client-/Server-Produktionsbuild, Local-only- sowie Designpruefung sind erfolgreich. Der parallele Gesamtlauf bestaetigt 777 Tests; genau eine fachlich unabhaengige statische Result-DB-Scope-Pruefung erwartet noch die alte Quelltextform vor der bereits parallel vorhandenen `assessmentIds`-Ergaenzung, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Infrastrukturtrennung vom 2026-09-03: Der Faktenblock mit `Marked findings`, AD Recycle Bin, Backupzeit, krbtgt-Aenderung, Legacy/Windows LAPS, WEF und vollstaendiger OS-Angabe ist aus `Infrastructure & Resilience` herausgeloest und steht als eigene minimierbare Kachel `Infrastructure Details` im dreispaltigen Inhaltsraster. Die Ursprungskachel enthaelt nur noch ihre Risiko-/Mengenwerte. Alle bestehenden Werte stammen unveraendert aus demselben normalisierten Environment Snapshot. Die Client-Info-Ansicht umfasst damit zehn statt neun Informationskacheln. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung sind erfolgreich. Der Baseline-Build ist derzeit unabhaengig von dieser Aenderung durch eine parallel hinzugekommene GPO-Testfixture mit fehlendem Pflichtfeld `ImportProcessorReference.kind` blockiert; ein separater direkter Vite-Lauf war in der Sandbox wegen `spawn EPERM` nicht zulaessig. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Masonry-/Dreieckskorrektur vom 2026-09-03: Das Inhaltsraster misst jede der zehn Informationskacheln individuell und weist ihr eine eigene feingranulare Rasterspanne zu. Bei Collapse sinkt die Kartenhoehe auf die Kopfzeile; nachfolgende Karten belegen per dichtem Auto-Flow unmittelbar den frei gewordenen Platz, statt bis zum Ende einer hoeheren Nachbarkarte zu warten. Ohne `ResizeObserver` bleibt das regulaere nicht ueberlappende Raster als Fallback aktiv. Die Plus-/Minus-Zeichen sind durch die gemeinsamen SVG-Dreiecke ersetzt: unten fuer geoeffnet, rechts fuer geschlossen. 16 fokussierte Dashboard-, Interaktions-, Masonry- und Dreieckstests sowie Client-/Server-Produktionsbuild, Local-only- und Designpruefung sind erfolgreich. Der Gesamtlauf bestaetigt 781 Tests; genau eine unabhaengige statische Data-Hub-Open-Regression erwartet noch die alte einzeilige Quelltextformatierung, obwohl dieselbe `dashboard`-Navigation weiterhin mehrzeilig vorhanden ist; 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Spalten-/KPI-Korrektur vom 2026-09-03: Die freie Masonry-Neuanordnung ist zugunsten drei dauerhafter Inhalts-Spalten mit der Kartenverteilung 3/2/2 ersetzt. Karten wachsen und schrumpfen nur innerhalb ihrer zugewiesenen Spalte; beim Minimieren rueckt ausschliesslich der darunterliegende Inhalt derselben Spalte nach oben. Die sechs KPI-Kacheln strecken sich in der Desktop-Kopfzone auf die Hoehe des danebenstehenden `Assessment Status`, sodass zwischen Kopf- und Inhaltszone keine uebergrosse Leerstelle verbleibt. Die Reihenfolge lautet Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections; nur Deviation und High Severity sind interaktiv. Alle KPI-Werte sind groesser, der Compliance Score verwendet die staerkste gemeinsame H1-Hierarchie. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Im Gesamtlauf bestanden 780 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin eine einzeilige Quelltextformatierung der funktional vorhandenen mehrzeiligen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Detailkorrektur vom 2026-09-03: Minimierte Informationskarten behalten nun mit `width: 100%` dieselbe volle Spaltenbreite wie ihre maximierte Form; nur die Kartenhoehe wird reduziert. Der werkzeugspezifische Hinweis `PingCastle` beziehungsweise dessen Engine-Version ist aus `Directory Overview` entfernt, waehrend die normalisierten Quelldaten unveraendert erhalten bleiben. 13 fokussierte Dashboard-/Interaktionstests und der Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Standardansicht vom 2026-09-03: Beim Oeffnen ist ausschliesslich `Assessment Status` expandiert. Die acht uebrigen Mengen-/Faktenkarten sowie `Severity Distribution` starten als vollbreite minimierte Kopfzeilen mit rechtem Dreieck und koennen weiterhin individuell geoeffnet werden. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und der Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte Client-Info-Titelleisteninteraktion vom 2026-09-04: Bei allen Mengen-, Fakten- und Donutkarten minimiert beziehungsweise maximiert ein Klick auf eine beliebige Stelle der gesamten Titelleiste den Karteninhalt. Der bestehende zugaengliche Pfeil-Button bleibt fuer Tastaturbedienung und `aria-expanded` erhalten; die gemeinsame Hoverflaeche macht die vergroesserte Klickzone sichtbar. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich. Der Gesamtlauf bestaetigt 780 bestandene Tests; genau eine unabhaengige statische Data-Hub-Open-Regression erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen mehrzeiligen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + +Verifizierte DB-Structure-Neugestaltung vom 2026-09-04: Die Datenbankansicht besitzt nun eine klare Informationshierarchie aus Einordnung und Schemaaktionen, vier kompakten Kennzahlen, fachlich beschriebenen Verarbeitungslayern und progressiv aufklappbaren Tabellendetails. Tabellen zeigen Spalten, Typen, Constraints und Beziehungen in strukturierten Inter-Zeilen; `Expand all` beziehungsweise `Collapse all` steuert die gesamte Ansicht. Segmente und Kacheln verwenden die gemeinsame transparente beziehungsweise flache, eckige Designsprache ohne Legacy-Akzentkontur, Schatten oder Monospace-Sondertypografie. Responsive Regeln erhalten die vollstaendige Lesbarkeit auf schmalen Viewports. Zwölf fokussierte Layout-, Interaktions-, Inset-, Typografie- und Kachelvertragstests, Local-only- und Designpruefung sowie der Client-Produktionsbuild sind erfolgreich. Der Gesamtlauf bestaetigt 783 bestandene Tests; zwei unabhaengige Regressionen betreffen weiterhin die einzeilige Data-Hub-Quelltextformatierung und eine parallel geaenderte GPO-Evaluationserwartung, 8 optionale PostgreSQL-Tests wurden uebersprungen. Der Server-Produktionsbuild ist durch eine fachfremde parallele Syntaxaenderung in `gpo-policy-evaluation-service.ts` blockiert. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. + Ziele: - Filter aus normalisierten Rollen und tatsächlichen Datenwerten erzeugen. @@ -401,6 +894,11 @@ Verifizierter Abschlussstand vom 2026-07-17: - Funktionsweise und Grenzen sind in docs/DYNAMIC_FILTERS.md dokumentiert. - 31 Testdateien mit 79 Tests, Local-only-Prüfung und Produktionsbuild laufen erfolgreich. +Verifizierte Erweiterung vom 2026-09-10: + +- Fuer Defender-for-IoT-Timeslots stellt Client Info getrennte CVE-, Device- und Site-Sichten bereit. In gemischten Timeslots bleibt die allgemeine Uebersicht erhalten und Defender erscheint als eigener Tab. Detail-Vorkommen, rohe Sensorbeobachtungen und nur aggregiert vorhandene Severity-Zahlen bleiben sichtbar getrennt; Zero und unavailable werden nicht gleichgesetzt. +- CVE- und Device-Auswahl sowie der verschachtelte Site-zu-Device-zu-CVE-Pfad machen die erhaltene Evidenz zugreifbar. Konflikte und Reconciliation-Diagnosen werden sichtbar gezaehlt, ohne Quellwerte still zu ueberschreiben. + 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. @@ -747,6 +1245,35 @@ Abnahmekriterien: - Unsichere Matches werden nicht automatisch als identisch gespeichert. - Benutzerbestätigungen können als lokale Mappingregel wiederverwendet werden. +#### Geplantes Arbeitspaket: faire Vergleiche bei fehlenden Folgequellen + +Statusklarstellung 2026-09-11: Der oben dokumentierte Abschluss betrifft den historischen Vergleichskern, nicht die nachfolgende Erweiterung. P0 ist abgeschlossen, P1 in Arbeit und P2-P6 sind offen. Der verbindliche Detailplan steht in [TIMESLOT_COMPARISON_PLAN.md](TIMESLOT_COMPARISON_PLAN.md): getrennte Regel-/Vorkommensidentitaet, profilgebundene Gegenpruefung, Erhaltung jeder offenen Verpflichtung bei Teilabdeckung, reparierte Quell-/Versionspruefungen und expliziter A/B-Bericht. Die nachfolgenden Festlegungen vom 2026-09-06 bleiben als Ausgangspunkt erhalten; ihre pauschale Abloesung durch einen neuen Quelllauf wird durch den verpflichtungsbezogenen Nachweisvertrag praezisiert. Alte UI-Abschlussnotizen sind kein Beleg fuer die heutige Produktanbindung. + +Ziel ist eine belastbare Fortschrittsaussage, auch wenn ein Kunde beim naechsten Timeslot nicht mehr alle bisherigen Scanner- oder GPO-Quellen liefert. Fehlende Evidenz darf weder als Verbesserung noch als Behebung erscheinen. + +Verbindliches Fachmodell: + +- Jede im Projekt erwartete Quelle besitzt je Timeslot genau einen Evidenzzustand: `observed-current` (im aktuellen Stand neu erhoben), `carried-forward-awaiting-revalidation` (letzter bekannter Stand, aktuell nicht erneut gemessen) oder `retired-out-of-scope` (ausdruecklich ab einem Stichtag aus dem Scope genommen). +- Fehlt eine zuvor erwartete Quelle, werden ausschliesslich ihre noch offenen Finding-/Review-Verpflichtungen fortgeschrieben. Der alte Scan, die alte GPO-Beobachtung und deren Zeitstempel werden nicht als aktuelle Messung in den neuen Timeslot kopiert; Original-Timeslot, Quelltool, letzter Beobachtungszeitpunkt und Alter bleiben sichtbar. +- Ein neuer Lauf derselben Quelle und desselben Scopes ersetzt den Fortschreibungszustand. Erst dann darf die Vergleichsengine `neu`, `weiterhin vorhanden`, `behoben` oder `wieder aufgetreten` fuer diese Quelle verifizieren. +- Das ausdrueckliche Beenden einer Quelle ist eine eigene, auditierbare Aktion mit Akteur, Wirksamkeitsdatum und Begruendung. Es loescht keine Historie und ist nicht mit dem normalen Auswahlhaekchen beziehungsweise Bookmark gleichzusetzen. +- GPO- und andere umgebungsbezogene Rohbeobachtungen bleiben als historische letzte Evidenz erhalten, werden aber ohne aktuellen Import nicht neu bewertet. Fortgeschrieben werden offene Findings und Arbeitsverpflichtungen, nicht behauptete aktuelle Konfigurationen. + +Vergleich und Score werden getrennt ausgewiesen: + +1. **Gemessener Fortschritt** verwendet nur die Schnittmenge der im Basis- und Ziel-Timeslot aktuell beobachteten, fachlich vergleichbaren Quellen. +2. **Gesamtexposition / offener Backlog** umfasst aktuelle Findings plus fortgeschriebene, noch nicht erneut verifizierte Findings. Fortgeschriebene offene Risiken behalten ihr Risikogewicht, damit das Weglassen eines Scans den Score nicht verbessert. +3. **Evidence Coverage / Freshness** zeigt separat, welcher Anteil aktuell gemessen, fortgeschrieben oder bewusst aus dem Scope genommen ist. Score und Abdeckung duerfen nie zu einer einzigen scheinbar praezisen Zahl verschmelzen. + +Vorgesehene Abnahmekriterien: + +- Ein fehlender Folgescan erzeugt weder `behoben` noch eine automatische Scoreverbesserung. +- Gemeinsam vorhandene Quellen liefern weiterhin einen normalen, reproduzierbaren Fortschrittsvergleich. +- Fortgeschriebene Findings sind optisch und maschinenlesbar von aktuell bestaetigten Findings getrennt und zeigen Quelle, Ursprungs-Timeslot und Alter. +- Ein spaeterer aktueller Scan beendet die Fortschreibung deterministisch und erzeugt den korrekten Lebenszyklus. +- `retired-out-of-scope` erfordert eine ausdrueckliche, auditierte Entscheidung; historische Findings bleiben erhalten. +- Scanner, GPOs und spaetere Tools benutzen denselben generischen Quellenzustandsvertrag, ohne toolbezogene Sonderlogik in React. + ### Phase 9 – Fachliche Persistenzschnittstelle Status: abgeschlossen @@ -780,6 +1307,13 @@ Verifizierter Abschlussstand vom 2026-07-17: - 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. +Nachtraeglicher verifizierter UI-Integrationsstand vom 2026-09-06: + +- Die in FindingReader gepflegten Workflowdaten werden nicht mehr ausschliesslich im Browser gespeichert. Kanonische Finding-Vorkommen tragen ihre stabile Datenbankidentitaet bis in jede Work-Projektion; alle Projektionen desselben Vorkommens teilen einen Review. +- Bookmark, exakter UI-Status, kanonischer Workflowstatus, Prioritaet, Owner/Team, Due Date, Prerequisites, Required Access/Roles, Next Step, Evidence/Acceptance Criteria, Comment und die Marker Question Needed, Permission Blocked, Quick Win, External Team sowie Not Relevant werden ueber die bestehende Review-API mit optimistischer Revision persistiert. +- Vorhandene datenbankgestuetzte Reviews haben beim Laden Vorrang. Ein bisher nur lokal vorhandener Review bleibt erhalten, wird auf alle Projektionen desselben Vorkommens vereinheitlicht und beim naechsten verbundenen Laden ohne bestehenden Datenbankreview migriert. Fuer rein lokale, noch nicht kanonisch persistierte Importe bleibt die Browserablage der sichere Rueckfall. +- Die Erweiterung nutzt das vorhandene JSONB-Reviewobjekt und benoetigt keine SQL-Migration. 43 fokussierte synthetische Roundtrip-, Repository-, Projektions-, Scope- und API-Tests, 825 Standardtests, Local-only-/Designpruefung sowie Client-/Serverbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen und keine realen Findinginhalte gelesen. + Abnahmekriterien: - React führt kein SQL aus. @@ -867,6 +1401,12 @@ Verifizierter Abschlussstand vom 2026-07-17: - 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. +Verifizierte Erweiterung vom 2026-09-10: + +- Migration 021 und beide Repository-Adapter fuehren einen tenant- und timeslotunabhaengigen CVE-Referenzbestand ein. Ein normalisierter CVE-Schluessel wird mit NVD-Beschreibung, Metriken, Schwachstellenklassen, Referenzen, betroffenen Konfigurationen, Quellzeitpunkten und Provenienz genau einmal gespeichert und in alle passenden Defender-Vorkommen projiziert. +- Import und Enrichment bleiben getrennte Schritte: Der Defender-Import erzeugt weiterhin deterministisch nur seine quellengetreuen Findings. Erst eine ausdrueckliche Backendaktion fuer eine bereits gespeicherte Defender-CVE ruft den festen NVD-CVE-2.0-Endpunkt auf und aktualisiert den gemeinsamen Referenzbestand; ein spaeter importierter Mandant mit derselben CVE erhaelt die vorhandene Anreicherung ohne erneuten Abruf. +- Repository-, Parser-, API-Client-, Migrations- und Sicherheitsregressionen sind synthetisch verifiziert. 45 fokussierte Tests, der vollstaendige Standardtestlauf und Client-/Server-Produktionsbuild sind erfolgreich. Migration 021 wurde zusaetzlich gegen die konfigurierte PostgreSQL-Instanz angewendet und ein Backendstart per HTTP-200-Healthsignal bestaetigt. Die Nummer 021 respektiert die dort bereits append-only belegten Versionen 019 `native-policy-targets` und 020 `baseline-driven-policy-evaluation`; deren Ledger-Eintraege wurden nicht veraendert. Es wurde weder realer Mandanteninhalt gelesen noch ein Live-NVD-Abruf ausgefuehrt. + Abnahmekriterien: - Fehlgeschlagene Importe hinterlassen keine Teilbestände. @@ -1013,6 +1553,12 @@ Verifizierter Abschlussstand von Phase 13 am 2026-07-17: Status: abgeschlossen +Verifizierte Erweiterung vom 2026-09-10: + +- Der Defender-for-IoT-Extractor 1.0.0 gruppiert Detailzeilen deterministisch zu Device-mal-CVE-Vorkommen und projiziert daraus fuer die generische Pipeline genau ein aggregiertes Finding je CVE, sodass Work eine CVE nicht mehr je Device dupliziert. Die betroffenen Devices erscheinen nicht mehr als eigene Findingfelder, sondern als `Affected Devices`-Tabelle (Device, Scanner, Site, eine Zeile je Device) im Ergebnisfenster; das Feld traegt eine Markdown-Tabelle, die dort ausgewertet wird. Die maschinenlesbaren `Source Observations` bleiben mit Tabellen- und Zeilenlocator als strukturierte Evidenz erhalten (die Defender-Sonderansicht rekonstruiert daraus ihr Modell) und werden in der Lesespalte ausgeblendet. Summary-Zeilen ohne CVE bestehen weiter als nicht-findingbezogene Quelltabelle. +- Identitaet folgt MAC, danach gueltiger IP-Adresse, danach normalisiertem Namen im Site-Scope. Wiederverwendete Adressen, unvollstaendige Identitaeten, widerspruechliche CVE-Metadaten, befuellte `NULL`-Spalten, Dubletten und Summary-/Detailabweichungen erzeugen reviewbare Diagnosen. +- 33 fokussierte synthetische Import-, Profil-, Persistenzprojektions-, Datahub-Readiness- und Dashboardtests sowie der Gesamtlauf mit 764 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitspruefung, Designpruefung und vollstaendiger Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzmigration; die Phase bleibt abgeschlossen. + Ziele: - Die in den Phasen 3 bis 6 begonnene Trennung von technischem Dateiformat, Quellwerkzeug, Reportvariante, fachlicher Beobachtung und kanonischem Finding verbindlich vervollständigen. @@ -1148,6 +1694,12 @@ Abnahmekriterien: Status: in Arbeit +Zwischenstand 2026-09-09 (PurpleKnight): Workbook-Findings neben Summary wiederhergestellt; HTML-Berichtskontext, Originalwerte/Provenienz, Null-Details und Vollstaendigkeitsdiagnosen verifiziert. Profil 1.3.0 empfiehlt Reimport bei unveraenderter Historie. Dummy-Abgleich und 25 synthetische Regressionen sind abgeschlossen; damit ist keine pauschale Abnahme aller Scanner-Versionen oder der gesamten Phase 13C verbunden. + +Zwischenstand 2026-09-09 (PingCastle-Auditpunkte 1-3): Strukturtreue der Attribute, Leerzustaende und HTML-Zellwerte mit synthetischen Browser-/Serverregressionen, unabhaengiger Dummy-Strukturzaehlung und produktivem Parse-only-HTTP-Abgleich verifiziert. Profil 1.5.0 empfiehlt Reimport, aendert aber keine Historie. XML bleibt vorerst generisch unter `pingcastle.xml.*`; gemeinsame semantische Schluessel und HTML-Control-Path-JSON sind weiterhin offen. Eine gleiche Findingzahl allein gilt nicht als Abnahme des gesamten Berichtskontexts. + +Zwischenstand 2026-09-06 (Baseline-Vollreimport): Der bestaetigte Delete-Pfad entfernt nun auch ausschliesslich reproduzierbare Policy-Evaluations- und Finding-Ketten, die die geloeschte Baselineanalyse referenzieren. Kundenimporte, GPO-Beobachtungen, Environment Profiles und Snapshotaggregationen bleiben erhalten. Damit ersetzt diese Entscheidung die fruehere Delete-Sperre fuer bereits verwendete Baselines. Vor der produktiven Loeschung wurde der kanonische PostgreSQL-Bestand als Custom-Format gesichert und der Dumpkatalog gelesen. Der letzte blockierte Baselineeintrag wurde geloescht; der Katalog ist leer und 51 GPO-Beobachtungen sind weiterhin vorhanden. Der Neuimport selbst erfolgt anschliessend durch den Benutzer. + Ziele: - Scannerinformationen ausserhalb einzelner Findings verlustfrei und mit Quellprovenienz erfassen. @@ -1174,14 +1726,46 @@ Abnahmekriterien: ### Phase 13B – GPO-Backup- und Microsoft-Baseline-Analyse +Verifizierter Zwischenstand 2026-09-18 (stabile Work-Liste und technische Pfadtitel): Die Datensatzwahl startet keine zweite kartenlokale `scrollIntoView`-Animation mehr; nur der virtuelle Listencontainer positioniert eine ausserhalb des Viewports liegende Auswahl und tut dies ohne Smooth-Animation. Die Trefferliste reserviert ihre schmale Scrollbarspur dauerhaft, sodass das Ein- und Ausblenden des Balkens die Textbreite und damit den Zeilenumbruch nicht verschiebt. Lange GPO-Registrytitel werden im Readerkopf und in der Finding-Ueberschrift ueber die gemeinsame `technical-path`-Darstellung mit Pfadschrift, vollstaendigem Inhalt und Umbruch innerhalb der Lesespalte ausgegeben; Accepted Risk und Kopfaktionen behalten ihre eigene Gridspalte. Die genaue Auswahlinteraktion und der lange Registrytitel sind synthetisch regressionsgesichert. 1.339 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Parser-, Bewertungs-, API-, SQL-, Persistenz- oder Bestandsdatenaenderung; Phase 13B bleibt in Arbeit. + +Verifizierter Zwischenstand 2026-09-06 (Benchmark-Semantik): Evaluator 1.3.3 erzeugt `Passed` oder `Failed` ausschliesslich aus einer zur beobachteten Umgebung passend ausgewaehlten Microsoft-Security-Baseline mit vorhandenem, technisch vergleichbarem Sollwert. Ein vorhandener Sollwert ohne Kundenwert ist `Failed`; identische Werte sind `Passed`, abweichende Werte `Failed`. Leere Baselinezeilen werden nicht bewertet, nicht unterstuetzte Werte bleiben Review/Warning und werden nie zu Pass/Fail umgedeutet. Security-Template-Registrywerte behalten Typ und Wert im Vergleich. Ausschliesslich Dummy wurde neu ausgewertet: 363 Failed, 13 Passed und 8 Review/Warning; 0 Pass/Fail-Zeilen ohne Baselinewert. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Phase 13B bleibt in Arbeit. + Status: in Arbeit +Verifizierter Zwischenstand 2026-09-06 (baseline-getriebener Soll-/Ist-Vergleich): Evaluator 1.3.1 startet je aktiver Microsoft-Baselineanalyse bei deren technisch aufgeloesten Empfehlungen. Ein identischer typisierter Ist-Wert wird `configured_match`/Passed, ein abweichender oder im importierten GPO-Backup fehlender Ist-Wert wird `confirmed_configured_deviation`; Einstellungen ohne Baselineempfehlung erzeugen kein Bewertungsergebnis. Mehrere Baselines werden unabhaengig ausgewertet und nicht mehr als mehrdeutige globale Betriebssystemauswahl blockiert. Konflikte, indeterminierte Werte und unvergleichbare Typen bleiben Review. Die neutrale Auswertung behauptet weder Wirksamkeit noch Severity und bleibt fuer die Finding Factory `ineligible`. Migration 020 erlaubt dafuer baseline-gebundene Ergebnisse ohne erfundenen Aggregationszustand; Work zeigt fehlende und vorhandene Vergleiche einzeln mit kurzem Baseline-Namen. Ein deduplizierter GPO-Reimport startet die aktuelle Auswertung erneut. Nach Datenbanksicherung wurde ausschliesslich der freigegebene Dummy neu ausgewertet: 3.638 Vergleiche, 55 Passed, 3.556 Abweichungen (davon 3.483 fehlende Ist-Werte) und 27 Review-Faelle. Kein anderer Mandant wurde ausgewertet. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Phase 13B bleibt fuer die Aufloesung der 27 Review-Faelle, weitere Preference-CSEs und Exportdetails in Arbeit. + +Verifizierter Zwischenstand 2026-09-06 (direkte Work-Anzeige): Baseline-Abweichungen werden in der regulaeren Work-Projektion als `Failed` dargestellt und erscheinen im eigenen Blatt sowie in der Kategorie und Quelle `GPOs`; passende Werte bleiben `Passed`, unentscheidbare Vergleiche `Investigate`. Damit greift der normale Work-Standardfilter fuer Abweichungen, ohne dass die separate Policy-Analyseansicht fuer die taegliche Findingsicht erforderlich ist. Beim Oeffnen werden ausschliesslich Ergebnisse des aktuellen Evaluators beruecksichtigt und pro GPO-Backup der vollstaendigste Baseline-Lauf gewaehlt; ein spaeterer Teillauf kann die vollstaendige Auswertung nicht mehr verdraengen. Der leere Clientzustand enthaelt keinen Verweis mehr auf die separate View. 825 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Regressionen verwendet; keine Kundendaten oder Persistenz veraendert. Phase 13B bleibt in Arbeit. + +Verifizierter Zwischenstand 2026-09-06 (direkte Result-DB-Anzeige): Der Local- und PostgreSQL-Read-Pfad projiziert nun jeden aktuellen, deterministischen Baselinevergleich direkt als `policy_deviation` unter dem Source Tool `GPOs`. Abweichung, Uebereinstimmung, Nichtanwendbarkeit und Review bleiben als `fail`, `pass`, `not_applicable` und `warning` getrennt; neutrale Vergleiche behalten Severity `unknown`. Ein bereits durch die Finding Factory angereicherter Vergleich ersetzt seine neutrale Zeile und wird ebenfalls unter `GPOs` gefuehrt, sodass keine Duplikate entstehen. Rohbeobachtungen bleiben ausschliesslich `internal-analysis`. Die PostgreSQL-Projektion materialisiert den grossen Evaluation-Run einmal je aktiver Aggregation statt ihn je Ergebniszeile erneut aus JSONB zu entpacken. Inhaltsfreie Laufzeitpruefung auf dem freigegebenen Dummy: Source Tool `GPOs` vorhanden, 3.638 aktuelle Vergleiche und 3.583 Abweichungen; Listen- und Facettenabfragen jeweils unter 0,5 Sekunden. 826 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Persistenzmutation und keine Einsicht in Kundeninhalte; Phase 13B bleibt fuer Review-Faelle, weitere Preference-CSEs und Exportdetails in Arbeit. + +Verifizierter Zwischenstand 2026-09-06 (Evaluation ohne Zusatzklick): Der bestehende automatische Jobpfad fuehrt nach Parsing und Identity-Analyse unmittelbar Snapshotaggregation, Baseline-Evaluation und Finding Factory aus und setzt den Importjob erst danach auf `succeeded`. Der irrefuehrende `Evaluate`-Button wurde aus erfolgreichen beziehungsweise partiellen GPO-Zeilen entfernt; `Retry` bleibt ausschliesslich fuer fehlgeschlagene Importjobs. Der vorhandene projektgebundene Evaluate-Endpunkt bleibt als technische Recovery-Grenze erhalten, ist aber kein regulaerer UI-Arbeitsschritt. Der Progressdialog bleibt waehrend Queue, Import und automatischer Auswertung geoeffnet. Ein neuer Regressionstest sichert die Reihenfolge Analyse -> automatische Evaluation -> Jobabschluss. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Bestandsdaten veraendert; Phase 13B bleibt in Arbeit. + +Zwischenstand 2026-09-06 (einzelnes GPO-Delete): Die bisher auf Dead-Letter-Artefakte begrenzte Loeschung gilt nach ausdruecklicher Bestaetigung fuer jeden beendeten GPO-Import. Abhaengige Policy-Snapshot-Aggregationen werden als reproduzierbare Derivate invalidiert; ihre Evaluationen und Findings folgen transitiv. Der Timeslot, andere Quellen und das Environment Profile bleiben erhalten. Laufende oder eingereihte Jobs blockieren die Mutation. Die UI bietet Delete direkt in jeder GPO-Zeile. Keine Migration und keine Mutation des kanonischen Bestands; Phase 13B bleibt in Arbeit. + +Zwischenstand 2026-09-06: Die automatische GPO-Pipeline nutzt zuerst beobachtete Betriebssystem-/DC-Daten aus dem EnvironmentSnapshot desselben Timeslots, mit Quellenreferenzen; Functional Levels sind kein Betriebssystemersatz. GPMC-CoreSettings und verschachtelte GPReport-Identitaeten werden nun gelesen. Der speicherbegrenzte SAX-Metadatenparser verarbeitet groessere Backups; eine synthetische Regression mit 2300 GPOs prueft ZIP und Ordnertransport. Security Templates und Advanced Audit erhalten auf Kunden- und Baselinenseite gemeinsame native Zielidentitaeten neben Registry.pol. Nach Import folgen bei eindeutigen Voraussetzungen Aggregation, Evaluation und die weiterhin freigabegesicherte Finding Factory; Work projiziert aktuelle Bewertung und Baselinewert neben den Beobachtungen. Evaluate ersetzt den obligatorischen View-Zwischenschritt. + +Verifiziert auf dem ausdruecklich freigegebenen Dummy: erneute Verarbeitung des erhaltenen Originals erfolgreich, 51 aktuelle Beobachtungen und 50 persistierte Bewertungsergebnisse. Diese stehen in Review, nicht auf bestaetigter Uebereinstimmung: Backup-ID/-zeit und Setvollstaendigkeit sind nicht ausreichend belegt; die vorhandene Baselineanalyse ist unvollstaendig. Das referenzierte Original der passenden Baseline fehlt sowohl im konfigurierten LocalAppData-Speicher als auch im vorhandenen Workspace-Speicher. Migration 019 erweitert nur erlaubte Policy-Zielarten; vorher wurde ein Custom-Format-Backup des kanonischen Bestands erstellt und per pg_restore --list auf Lesbarkeit geprueft, kein Restore behauptet. Kundenoriginale und bestehende Runs bleiben unveraendert. Keine anderen Kunden neu verarbeitet. Keine visuelle Browserabnahme; Phase 13B bleibt offen. + +Aktueller verifizierter Zusatzstatus vom 2026-09-04: Die nachtraeglich eingefuehrte Regelkatalog-Grenze blockiert den urspruenglich vorgesehenen neutralen Feinvergleich zwischen importierter Microsoft Security Baseline und technisch eindeutig aufgeloesten GPO-Einstellungen nicht mehr. Fehlt fuer alle anwendbaren Kontexte eine Katalogregel, verwendet Evaluator 1.2.0 den importierten Baselinewert direkt mit einem typgetreuen Equality-Comparator und erzeugt reproduzierbar `configured_match` oder `confirmed_configured_deviation`. Eine solche neutrale Abweichung besitzt keine erfundene Severity, keine Risikoregel und bleibt fuer die Finding Factory `ineligible`; erst eine eindeutige freigegebene Katalogregel darf staerker/schwaecher, Abhaengigkeiten, Risiko und Finding-Freigabe ergaenzen. Teilweise ADMX-Metadaten blockieren den exakten Vergleich einer bereits aufgeloesten Einstellung nicht, bleiben aber als Diagnose sichtbar; mehrdeutige oder nur fuer einen Teil der Kontexte passende Regeln, unvollstaendige Kundensnapshots, Baseline-Mehrdeutigkeit, Wertkonflikte und nicht vergleichbare Typen bleiben fail-closed in Review. Die Aktionsprojektion erkennt Evaluationen aelterer Engineversionen nicht mehr als aktuellen Abschluss und bietet fuer denselben Snapshot und dieselbe Baseline eine neue 1.2-Auswertung an. 36 fokussierte Policy-Tests und alle betroffenen GPO-Tests sind erfolgreich. Im Gesamtlauf bestanden 785 Tests; ein fachlich unabhaengiger bestehender statischer Data-Hub-Test erwartet eine einzeilige Quelltextformatierung, waehrend die bereits vorhandene uncommittete UI-Aenderung denselben Ablauf mehrzeilig schreibt; 8 optionale PostgreSQL-Tests wurden uebersprungen. Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt fuer den noch fehlenden Baseline-only/Subject-missing-Vergleich, fachliche Kataloganreicherung, weitere Preference-CSEs und Exportdetails in Arbeit. + +Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang fehlende GPO-Anbindung an Work und Result DB ist als additives, timeslotgebundenes Readmodell geschlossen. Jede aktuelle rohe `PolicyObservation` wird als eigener Quelltyp `policy-observation` mit Assessment-, Artefakt-, Backup-, Parser-, Reducer-, Identity-, Wert-, Diagnose- und Locator-Provenienz projiziert. Diese Datensaetze bleiben fachlich `informational`, zeigen IOE und Deviation als nicht anwendbar und werden auch unter dem Result-DB-Standardfilter `Deviation = Yes` als Kontext sichtbar; nur die Finding Factory darf weiterhin eine echte `policy_deviation` erzeugen. Work fuegt `Group Policy · Observations` als eigenes Blatt hinzu und nimmt dieselben Zeilen in `All Records` auf, sodass `Source: Scan` dort `Group Policy` anbietet. Der freigegebene Dummy-Timeslot liefert ueber die laufende PostgreSQL-API 452 Scannerabweichungen plus 51 GPO-Beobachtungen, insgesamt 503 sichtbare Resultate. 13 fokussierte Tests und der Gesamtlauf mit 781 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine SQL-Migration und keine Veraenderung der importierten Originaldaten; Phase 13B bleibt fuer fachliche Identity-/Regelkataloge und bestaetigte Policy-Findings in Arbeit. + +Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang implementierte, aber nicht erreichbare Policy-Analyseoberflaeche ist nun aus dem Data-Hub-Clientdetail zugreifbar. Eine erfolgreiche GPO-Quellenzeile verwendet keine irrefuehrende deaktivierte Scanner-Auswahlbox mehr, sondern eine eigene Quellenmarkierung und eine `View`-Aktion. Diese oeffnet die projektgebundene GPO-Analyse mit Reprocessing, Environment Profiles, Aggregation, Evaluation, Finding Factory, aktueller Summary, Historie und Review Queue; zur Stammdatenansicht kann direkt zurueckgewechselt werden. `Source: Scan` bleibt fachlich auf Scanner-Runs begrenzt. Sieben fokussierte Data-Hub-/Policy-UI-Tests, die Gesamtsuite mit 775 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. + +Aktueller verifizierter Zusatzstatus vom 2026-09-03: GPO-Backups sind im ausgewaehlten Data-Hub-Timeslot nun als eigene Quellenzeilen sichtbar und werden im Quellenzaehler beruecksichtigt. Die Ansicht aktualisiert sich unmittelbar nach einer GPO-Einreichung; Queue-, Verarbeitungs-, Teil-, Erfolgs-, Recovery- und Dead-Letter-Zustaende bleiben unterscheidbar, und fehlgeschlagene Importe koennen direkt wiederholt oder geloescht werden. Der Browser bietet getrennte Eingaben fuer einen normalen GPO-Backup-Ordner und ein bereits vorhandenes ZIP. Ein Ordner wird weiterhin lokal in ein deterministisches Transport-ZIP verpackt, waehrend ein ZIP unveraendert dieselbe projekt- und timeslotgebundene, gehaertete Backend-Ingestion durchlaeuft. 14 fokussierte Data-Hub-/Transport-/HTTP-Tests sowie die Gesamtsuite mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. + +Aktueller verifizierter Zusatzstatus vom 2026-09-03: Der bisher nur eingebettete fachlich leere Policy-Evaluation-Regelkatalog besitzt nun eine lokale, betriebsseitig kontrollierte Ladegrenze. Ein kuratierter JSON-Katalog wird ausschliesslich bei gemeinsam konfiguriertem Dateipfad und SHA-256 geladen, ist auf 5 MiB und regulaere Nicht-Symlink-Dateien begrenzt und wird erst nach Hash-, UTF-8-/JSON-, Struktur- und vollstaendiger fachlicher Katalogvalidierung aktiviert. Jede Abweichung verhindert den Serverstart noch vor Aufbau der Repository-Laufzeit; ohne Konfiguration bleibt der sichere leere Freigabekatalog aktiv. Drei neue synthetische Loaderregressionen, 28 fokussierte Katalog-/Evaluations-/HTTP-Tests sowie die Gesamtsuite mit 773 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Netzwerk-, API-, SQL- oder Persistenzaenderung; fachliche Regeln und Windows-Inbox-ADMX-/ADML-Inhalte bleiben bis zur autorisierten Kuratierung weiterhin leer beziehungsweise offen. + +Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die offene snapshotbezogene Ergebnisdeduplizierung ist als additive aktuelle Sicht im Policy-Analyse-Readmodell umgesetzt. Die unveraenderliche Run-Historie bleibt vollstaendig erhalten; Summary und Review Queue zaehlen dagegen nur die aktiven Ketten aus nicht ersetztem Environment Profile, neuester nicht ersetzter Identity-Analyse je Artefakt, dazu passender Snapshotaggregation, neuester Evaluation je Aggregation und neuestem Finding-Run je Evaluation. Veraltete Ketten werden auch nicht mehr als ausfuehrbare Evaluate-/Finding-Aktionen angeboten. Drei Domainregressionen sowie Panel-, Actions- und HTTP-Regression sind erfolgreich; Gesamtsuite mit 770 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind gruen. Keine Persistenz- oder SQL-Aenderung; das Readmodell wurde additiv erweitert und Phase 13B bleibt fuer fachliche Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs und Exportdetails in Arbeit. + +Aktueller verifizierter Zusatzstatus vom 2026-08-26: Die Freigabegrenze des weiterhin fachlich leeren Policy-Evaluation-Regelkatalogs validiert nun alle Runtime-Enumwerte fuer Auslieferungsmechanismus, Baseline-Disposition, Comparator und Severity, blockiert ueberlappende Selektoren beziehungsweise mehrdeutige Regeln und lehnt widerspruechlich wiederverwendete Risiko- oder Abhaengigkeits-IDs fail-closed ab. Es wurden keine Policyempfehlung und keine Severity erfunden oder freigegeben. Der lokale private Artefaktspeicher wurde vom veralteten fremden Benutzerpfad auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots korrigiert; Backend, App und Speicherroot sind inhaltsfrei technisch erreichbar. Neun neue Katalogregressionen, 25 fokussierte GPO-/Katalogtests, die Gesamtsuite mit 764 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt 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. +- Richtlinieneinstellungen technisch identifizieren, innerhalb eines konsistenten Kundensnapshots aggregieren, Konflikte erkennen und jede aktive importierte Baseline separat als nachvollziehbaren Soll-/Ist-Vergleich auswerten; Produkt- und Rollenfilter bleiben eine nachgelagerte Sicht statt einer globalen Importsperre. - Nur bestätigte konfigurierte Abweichungen als normale Findings erzeugen; tatsächliche Wirksamkeit ohne Scope- oder RSoP-Evidenz niemals behaupten. Gemeinsame und getrennte Grenzen: @@ -1328,13 +1912,61 @@ Abnahmekriterien: - 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. +### Phase 13D - Regulatorische Kontrollsuche und RAG-Grundlage + +Status: in Arbeit + +Ziele: + +- Regulatorische Kontrolltexte versioniert und reproduzierbar fuer mehrsprachige semantische Suche aufbereiten. +- Qdrant ausschliesslich als rebuildbaren Retrievalindex verwenden; PostgreSQL bleibt fachliche Quelle fuer Scans, Findings, Ergebnisse, Reviews, Mappinglaeufe und Entscheidungen. +- Retrieval, Embedding, Chunking, spaetere Hybridfusion, Reranking und Mapping als getrennte Backendgrenzen halten. + +Umgesetzter Grundstand vom 2026-09-15: + +- Lokaler und Deployment-Compose-Stack enthalten das gepinnte Qdrant-Image 1.19.1, einen API-Key, deaktivierte ausgehende Nutzungstelemetrie und ein getrenntes persistentes Volume. Lokal ist nur die REST-Schnittstelle auf Loopback veroeffentlicht; im Deployment bleibt Qdrant intern. +- `RegulatoryControlDocument` und `RegulatoryChunk` definieren einen versionierten, framework-/versions-/control-/chunk-/sprachgebundenen Vertrag. Chunk- und Inhaltsidentitaeten sind deterministisch; Originalkorpus und Korpusversion bleiben die Wiederaufbauquelle. +- Die aktive Collection `assessor_regulatory_chunks_v2` verwendet benannte Dense-/Sparse-Vektoren, Cosine fuer Dense und zwoelf Payloadindizes fuer alle Filterfelder. Sparse ist nur die vorbereitete Schema- und Schnittstellenposition, noch kein aktiver Retriever. +- Ein abgesicherter OpenAI-kompatibler Embeddingadapter verlangt fuer Remoteziele HTTPS, erlaubt HTTP nur auf Loopback fuer den lokalen llama.cpp-Testbetrieb und bindet ein ausdruecklich freigegebenes mehrsprachiges Modell an dessen exakte Dimension. Redirects, unbeschraenkte Antworten und Dimensionsdrift werden abgewiesen. Ein opt-in `dimensions`-Request unterstuetzt spaetere OpenAI-/LiteLLM-Vergleiche, bleibt fuer llama.cpp aus. +- CLI-Ingestion validiert und segmentiert einen begrenzten JSON-Korpus, bettet Chunks in Batches ein und ersetzt dokumentgebundene Qdrant-Punkte. Die Queryseite verwendet dasselbe Modell und kann Korpus, Framework, Version, Control und Sprache exakt filtern. +- `RegulatoryRetriever`, `RegulatoryCandidateRetriever` und `RegulatoryReranker` trennen Verbraucher, Candidate Retrieval und optionale Nachsortierung. Spaetere Hybridfusion kann die Candidate-Stufe ersetzen, ohne Mappingcode an Qdrant zu binden. +- Der Finding-Query-Builder akzeptiert die bestehende `UnifiedResultProjection` und trennt den vollstaendigen datenschutzsicheren regelbezogenen Modellkontext von den Retrievalsignalen. Eine generische Query aus Titel, begrenzter Beschreibung und Empfehlung funktioniert ohne Werkzeugkatalog; `public-security-topics.ts` erzeugt nur eine optionale zusaetzliche Topic-Query. Asset, Ergebnistabelle, Pfade, Mandanten-/Projekt-/Review- und Provenienzdaten werden nie gelesen oder kopiert. Nicht-Scanner und Findings ohne Titel bleiben fail-closed. +- Ein begrenzter versionierter Evaluationsvertrag und die CLI `rag:evaluate` messen HitRate@K, Recall@K und MRR auf Kontrollebene. Query- und erwartete Kontrollsprache sind getrennt deklariert; die CLI gibt nur Aggregatmetriken aus. Synthetische Unit-Rankings pruefen den Vertrag, gelten aber nicht als Qualitaetsnachweis des realen Modells. +- Ein eingecheckter synthetischer EN/DE-Smoke-Korpus und drei sprachuebergreifende Labelcases sichern den ausfuehrbaren Vertrag. Der opt-in WSL-Qdrant-Integrationstest prueft mit deterministischen synthetischen Vektoren den realen 1.19.1-Collection-/Index-/Replace-/Filter-/Retrievalpfad; er bewertet ausdruecklich keine Embeddingqualitaet. +- Der produktiv gebaute End-to-End-Pfad ist mit lokalem llama.cpp/BGE-M3 FP16 live gelaufen: sechs Dokumente/sechs Chunks; drei Cross-Language-Smoke-Cases bei K=3 jeweils Rang 1 und damit HitRate, Recall und MRR 1,0. Der Mini-Korpus ist nur ein Wiring-Smoke-Test, kein belastbarer Modellvergleich. +- Der Grundstand ist in `docs/REGULATORY_RAG.md` dokumentiert und mit synthetischen Vertrags-, Client-, Ingestion-, Retrieval- und Deploymenttests abgesichert. +- Der PDF.js-Importer erzeugt aus den explizit uebergebenen ISO-27001-/27002-Pfaden einen lokalen Korpus-v2 mit Quellhashes, Ausgaben, 93 geteilten Kontrollidentitaeten, Abschnittsarten und Seitenbereichen. Nur ISO-27002-Abschnitte werden semantisch gerankt; die entsprechende ISO-27001-Aussage wird als autoritative Referenzevidenz angehaengt. +- Data Hub bietet fuer genau diese beiden PDFs einen token-geschuetzten Upload mit begrenztem Parserworker und asynchronem Embeddingstatus. Die private Korpusquelle ueberlebt Serverneustarts, die Original-PDFs nicht; die Aktivierung erfolgt nach erfolgreichem Indexaufbau ohne manuellen CLI- oder Umgebungsversionsschritt. +- Ein manueller Work-Vertikalschnitt startet pro kanonischem Scanner-Finding einen idempotenten asynchronen Lauf. Eine breite generische Suche reserviert fuenf Controls; die optionale Topic-Query liefert eine breite sowie getrennte `control`-, `purpose`- und `guidance`-Suche, deren Control-Rankings per Reciprocal Rank Fusion die restlichen sieben Plaetze fuellen. Ohne Topic-Treffer wird dieselbe generische Query verwendet. LiteLLM erhaelt hoechstens zwoelf Controls; maximal fuenf Vorschlaege werden gegen exakt gelieferte Evidenz validiert und Accept/Reject-Ereignisse append-only in PostgreSQL gespeichert. +- Result DB startet auf ausdrueckliche Aktion einen projektgebundenen Batch fuer exakt denselben vollstaendigen normalisierten Filter-/Timeslot-Scope wie Export JSON. Der Dienst paginiert serverseitig unabhaengig von der Anzeige, dedupliziert Scanner-Vorkommen global nach `ruleKey`, verwendet erfolgreiche und aktive Mappings wieder, versucht fehlgeschlagene Regeln einmal erneut und begrenzt Einzel- plus Batchpipelines gemeinsam auf zwei. Migration 027 speichert nur Scope, Filterhash, Idempotenz, Status und Aggregatfortschritt; Entscheidungen bleiben manuell im bestehenden Work-Panel. + +Offen bis zur Phasenabnahme: + +- formaler Update-/Freigabeprozess fuer neue lizenzierte ISO-Ausgaben und Korpus-Rebuilds +- kuratierte Erweiterung der oeffentlichen Signal-/Regelkataloge +- repraesentativer freigegebener EN/DE-Evaluationssatz und dokumentierte reale Dense-Baseline gegen den autorisierten Korpus +- aktive Sparse-/BM25-Erzeugung, Hybridfusion und evaluierter Reranker +- Confidence-Kalibrierung, Mandanten-/Rollenabgrenzung, Betriebsmonitoring und Lasttest +- Betriebsprozess, der vor jeder kuenftigen Migration einen laufenden Hot-Reload-Backendprozess stoppt oder die Migration bis nach dem verifizierten Backup sperrt + +Abnahmekriterien: + +- Ein freigegebener synthetischer Referenzkorpus kann vollstaendig neu aufgebaut und sprachuebergreifend mit dokumentierten Qualitaetsmetriken abgefragt werden. +- Qdrant-Ausfall oder Rebuild veraendert keine fachlichen PostgreSQL-Daten. +- Jede gespeicherte Zuordnung referenziert Korpus-/Control-/Chunk-, Embedding-, Retrieval-, Reranker-, Prompt-/Schema- und Entscheidungsprovenienz. +- Unzureichende oder widerspruechliche Evidenz bleibt reviewpflichtig; Retrievalscore allein wird nie als fachliche Confidence ausgegeben. + ## 8. Aktuell empfohlene Umsetzungsetappe +Die naechste Umsetzung fuehrt Phase 13B fort und entwickelt parallel den ausdruecklich beauftragten Phase-13D-Vertikalschnitt: +Ergaenzung 2026-09-11 fuer den Timeslotvergleich: Nach dem jetzt dokumentierten Planauftrag beginnt eine spaeter beauftragte Implementierung mit P0/P1 aus [TIMESLOT_COMPARISON_PLAN.md](TIMESLOT_COMPARISON_PLAN.md), danach folgen P2-P6 in Abhaengigkeitsreihenfolge. Zuerst Vergleichsidentitaet und Gegenpruefung absichern, dann offene Verpflichtungen und A/B-Scorebasis, zuletzt die Oberflaeche. Dieser Dokumentationsauftrag startet keine Umsetzung und unterbricht keine unabhaengigen Phase-13B-Arbeiten. Die folgenden aelteren Empfehlungen bleiben als Projektkontext erhalten. + 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. +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, projektgebundene Review-/Orchestrierungsoberflaechen und die aktuelle snapshotbezogene Ergebnisdeduplizierung sind umgesetzt. Als naechste vertikale Etappe folgen fachlich kuratierte Policy-Regeln und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Kataloge; danach weitere Preference-CSEs und Exportdetails. Ohne RSoP/GP Results bleibt die effektive Anwendung weiterhin ausdruecklich nicht verifiziert. +3. Phase 13D besitzt den lizenzierten ISO-Korpus-v2, die rebuildbare Qdrant-Grundlage, werkzeugunabhaengiges Dense-/BM25-Hybridretrieval, Finding-only Problem-/Remediationqueries mit Control-level RRF, abschnittsspezifische Evidenzsuche, den persistierten manuell reviewten Einzel-Finding-Workflow sowie das explizit vorgezogene gefilterte Result-DB-Batchmapping. Der fruehere 37-Finding-PingCastle-Vergleich bleibt ein historisches Regressionssignal und kein verpflichtender CI-Vertrag oder Beleg fuer neue Werkzeuge. Als naechste Etappe folgen ein unabhaengig gelabelter repraesentativer EN/DE-Evaluationssatz mit mehreren Scannern und Negativfaellen; ein gelernter oder modellbasierter Reranker, Confidence-Kalibrierung und jede automatische Entscheidung bleiben bis zu einer gesonderten Entscheidung ausgeschlossen. +4. 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. @@ -1344,11 +1976,166 @@ Aktualisierung nach dem Schritt-9-Vertikalschnitt vom 2026-08-04: Versionierte E 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. +Aktualisierung nach der snapshotbezogenen Ergebnisdeduplizierung vom 2026-09-03: Das Policy-Analyse-Readmodell trennt nun den aktuellen aktiven Snapshotpfad von der weiterhin vollstaendigen Audit-Historie. Summary, Review Queue und ausfuehrbare Folgeaktionen verwenden nur die aktive Revisionskette; historische Evaluationen bleiben separat sichtbar. Als naechste fachliche Etappen verbleiben kuratierte Policy-Regeln und vollstaendige Windows-Inbox-ADMX-/ADML-Kataloge, danach weitere Preference-CSEs und Policy-Exportdetails. +Aktualisierung nach der Katalog-Ladegrenze vom 2026-09-03: Fachlich freigegebene Policy-Regeln koennen nun als lokal betriebener, SHA-256-gepinnter und vollstaendig validierter JSON-Katalog reproduzierbar aktiviert werden; der Default bleibt leer und fail-closed. Als naechster fachlicher Schritt sind ein autorisiert kuratierter Regelinhalt und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Quellen erforderlich; weitere Preference-CSEs und Policy-Exportdetails bleiben danach offen. ## 9. Bereits getroffene Architekturentscheidungen +Festlegung 2026-09-15 (Phase 13D, ISO-Mapping): ISO 27002 ist fuer alle 93 Controls der semantische Korpus; ISO 27001 Annex A bleibt autoritative Referenz und Vollstaendigkeitspruefung. Kanonische IDs sind `5.1` bis `8.34`, Aliaswerte `A.5.1` bis `A.8.34`. Ein Mapping bedeutet ausschliesslich fachliche Relevanz, niemals Compliance. Dense Retrieval gruppiert zuerst auf Control-Ebene; LiteLLM darf nur gelieferte Controls und Chunk-IDs ausgeben. Kein Confidencewert akzeptiert automatisch. Runs und Entscheidungen sind append-only in PostgreSQL, Qdrant bleibt jederzeit rebuildbar. Die erste UI bleibt beim einzelnen Finding; Batchmapping, Sparse/Hybrid und Reranking bleiben bis zur repraesentativen Retrievalbewertung ausgeschlossen. + +Festlegung 2026-09-15 (Phase 13D, Finding-Retrievalgrenze): Nur Scanner-Findings mit einem exakt katalogisierten oeffentlichen Maester-/PingCastle-Regel-ID oder einem lokal erkannten fest definierten oeffentlichen Technikthema duerfen eine Embeddingquery erzeugen. Freitext, kundenspezifische Tool-/Regel-IDs, Assets, Pfade, Werte, Mandanten-/Projekt-/Review- und Provenienzdaten werden nie kopiert; ohne oeffentliches Signal bleibt Retrieval fail-closed. Der lokale Source-Result-Bezug bleibt ausserhalb des Embeddingrequests. Diese technische Minimierung ersetzt keine organisatorische Datenschutzfreigabe. Evaluationsmetriken werden auf Kontrollebene ermittelt und Retrievalscores bleiben Kandidatenranking, keine fachliche Confidence. + +Festlegung 2026-09-15 (Phase 13D, Finding-Retrievalgrenze – Revision, ersetzt die vorstehende Festlegung auf ausdruecklichen Nutzerauftrag): Die ISO-Mappingquery wird nicht mehr aus einer festen Themenwhitelist erzeugt, sondern aus der gemeinsamen datenschutzsicheren Finding-Projektion (`src/domain/privacy-safe-finding.ts`, `privacySafeFinding`) – exakt derselben Grenze wie die KI-Uebersicht. Query-Quelle ist der regelbezogene Prueftext (Titel, sowie Beschreibung und Empfehlung, jeweils aus der je Regel deduplizierten Finding-Definition, mit E-Mail-Redaktion); katalogisierte Regel-IDs, oeffentlicher Toolname und erkannte Technikthemen bleiben nur noch Query-Anreicherung. Die Ergebnistabelle/Occurrence (affectedAsset, Source-Locator/Pfad, Objektwerte, Mandanten-/Review-/Provenienzdaten) wird nie gelesen. Dadurch mappt jedes Scanner-Finding mit Pruef-Titel; nur Nicht-Scanner-Datensaetze und Findings ohne Titel bleiben `insufficient-public-context`. `REGULATORY_RETRIEVAL_VERSION` auf `dense-control-grouping-1.1.0` erhoeht; kein Reimport, da Mappinglaeufe regenerierbar sind und keine persistierten Scannerdaten geaendert werden. Restrisiko: Die geteilte Redaktion entfernt nur E-Mail-Adressen und verlaesst sich auf regelgenerische Definitionen; eine haertere Redaktion (Host/IP/Pfad) waere eine gemeinsame Entscheidung fuer beide KI-Funktionen und bleibt offen. Folgeetappen: assessment-weites Batchmapping ueber alle Findings (dedupliziert je Regel/Definition, analog zum KI-Uebersicht-Scopelauf) und optional eine symmetrische Einzel-Finding-KI-Uebersicht. + +Praezisierung 2026-09-15 (Phase 13D, Mapping-Relevanz): Der Mapping-Systemprompt (`REGULATORY_MAPPING_PROMPT_VERSION` `1.2.0`) mappt jetzt ausdruecklich auf fachliche Themenrelevanz. Ein Kandidat wird zugeordnet, wenn er dasselbe Sicherheitsthema regelt (z. B. Passwort-/Authentisierungsverwaltung), auch wenn der ISO-Kontrolltext den konkreten Wert, Schwellwert oder Parameter des Findings nicht nennt; ISO-Controls sind prinzipienbasiert und wiederholen solche Spezifika selten. `no_relevant_control` gilt nur, wenn kein Kandidat das Thema regelt. Hintergrund: `A-MinPwdLen` wurde trotz korrekt abgerufenem Control `5.17` (Authentisierungsinformationen) faelschlich als nicht relevant zurueckgewiesen. Kein Reimport, da Mappinglaeufe regenerierbar sind. + +Festlegung 2026-09-15 (Phase 13D, globale ISO-Mappings, ausdruecklicher Nutzerauftrag): ISO-Mappings und Accept/Reject-Entscheidungen sind jetzt global und mandantenunabhaengig, analog zur CVE-Anreicherung. Migration `026` ersetzt die per-Occurrence-Tabellen `assessor_regulatory_mapping_runs`/`_decisions` (nur regenerierbare Testdaten, vor dem Drop gesichert) durch `assessor_regulatory_mappings` und ein globales `assessor_regulatory_mapping_decisions`. Schluessel ist die Regelidentitaet `ruleKey` (`tool:ruleId`, ersatzweise ein stabiler Titel-Hash) plus die Pipelineversionen (`UNIQUE(rule_key, corpus_version, retrieval_version, prompt_version, model)`); die Mapping-ID ist ein deterministisches Digest dieses Tupels, sodass ein Regel-Mapping genau einmal existiert und jede Occurrence in jedem Projekt es wiederverwendet. Entscheidungen sind append-only, per `(ruleKey, controlId)` gefuehrt, versionsunabhaengig und ueberleben Scan-, Assessment- und Projektloeschung. Der Dienst leitet nur die non-personale Regelidentitaet und den Pruefkontext aus dem Finding ab; Ergebnistabelle/Occurrence fliesst nie ein. Kein Reimport (kein Scanner-Import veraendert). Naechste Etappe: assessment-weites Batchmapping ueber distinct Regeln. + +Festlegung 2026-09-16 (Phase 13D, gefiltertes Result-DB-Batchmapping, ausdruecklicher Nutzerauftrag; begrenzte Aufhebung der frueheren Batch-Zurueckstellung): `All` bezeichnet alle Treffer der aktuell aktiven Result-DB-Filter innerhalb des gewaehlten Timeslots und ist exakt derselbe vollstaendige `UnifiedResultQuery`-Scope wie Export JSON. Offset, Limit, Load-more-Zustand und geladene Zeilen sind reine Darstellung. Der Standardfilter `deviation: true` bleibt wirksam, bis er geaendert oder zurueckgesetzt wird. Der beim Start normalisierte Snapshot bleibt fuer den Lauf unveraendert und wird projektgebunden mit kanonischem Hash und Idempotenz in Migration 027 gespeichert. Nur kanonische Scanner-Findings sind geeignet; Nicht-Scanner und fehlender oeffentlicher Pruefkontext werden gezaehlt, aber nie versendet. Vorkommen werden global nach `ruleKey` dedupliziert, erfolgreiche oder aktive Mappings wiederverwendet und fehlende beziehungsweise zuvor fehlgeschlagene deterministisch geclaimt. Einzel- und Batchaktionen teilen zwei parallele Retrieval-/Modellpipelines. Der Batch erzeugt ausschliesslich Vorschlaege; Accept/Reject bleibt manuell und es gibt weder Auto-Accept noch Batch-Entscheidungsqueue. Die vorgezogene Orchestrierung ist keine Aussage zur Retrievalqualitaet: repraesentative EN/DE-Evaluation, Sparse/Hybrid, Reranking und Confidence-Kalibrierung bleiben offen. Kein Importvertrag geaendert, daher kein Manifestbump oder Reimport. + +Festlegung 2026-09-17 (Phase 13D, Retrievalluecken, ausdruecklicher Nutzerauftrag; begrenzte Revision der Reranking-Zurueckstellung): Die vollstaendige datenschutzsichere Mappingquery bleibt Modellkontext, wird aber nicht mehr unveraendert eingebettet. Eine getrennte kurze Embeddingquery aus Titel und kuratierten oeffentlichen Konzepten erzeugt zwei Dense-Rankings fuer ISO-27002-`control` und `purpose`; diese werden ohne zusaetzliches Modell auf Control-Ebene per Reciprocal Rank Fusion vereinigt. Der Retriever behaelt 24 Controls, der Mappingprompt hoechstens zwoelf, und die fachliche Ausgabe bleibt auf fuenf manuell reviewpflichtige Beziehungen begrenzt. Der oeffentliche zehn-Finding-/17-Beziehungs-Gap-Satz erreichte im produktiv gebauten lokalen BGE-M3-/Qdrant-Pfad Recall@12 1,0. Dies erlaubt die deterministische Fusion, aber weiterhin weder Auto-Accept noch eine allgemeine Qualitaetsaussage; unabhaengige repraesentative Labels, Sparse/Hybrid und ein gelernter oder modellbasierter Reranker bleiben offen. Neue Retrieval- und Queryversionen erzeugen append-only neue Mapping-IDs; Scannerimporte und bestehende Entscheidungen werden nicht umgeschrieben. + +Festlegung 2026-09-17 (Phase 13D, Gesamtregression; ersetzt die unmittelbar vorherige v1.2-Retrievalzusammensetzung, nicht deren historischen Eintrag): Eine Scanner- oder Topic-Taxonomie darf die Kandidatensuche nur ergaenzen. Die generische Query aus datenschutzsicherem Findingtitel, Beschreibung und Empfehlung erzeugt immer eine breite Rangliste; ihre ersten fuenf Controls sind im zwoelfteiligen Shortlistbudget reserviert. Eine optionale Topic-Query liefert eine breite sowie `control`-, `purpose`- und `guidance`-Rangliste; RRF fuellt daraus sieben weitere eindeutige Controls, danach dient die generische Rangliste als Fallback. Damit bleibt `public-security-topics.ts` nutzbar, aber neue Werkzeuge benoetigen fuer eine erste Zuordnung keine Pflege dieses Katalogs. Der damalige Mappingprompt fordert die kleinste hinreichende Menge, normalerweise einen Primaer- und null bis zwei Sekundaercontrols; maximal fuenf und Human Review bleiben unveraendert. Queryschema 3, Retrieval 1.3 und Prompt 1.3 versionieren die Aenderung append-only. Der vollstaendige 37-Finding-/78-Beziehungs-Abgleich verbessert Candidate Recall@12 gegen v1.2 von `54/78` auf `68/78`; wegen Benchmarknaehe und fehlender Multi-Scanner-Negativfaelle bleibt dies ein Regressionssignal, keine allgemeine 90-%-Garantie. + +Festlegung 2026-09-17 (Phase 13D, Promptbalance; ersetzt Prompt 1.3, nicht Retrieval 1.3): Relevanz erzwingt kein Primaercontrol. Prompt 1.4 erlaubt null oder ein Primaercontrol und null bis drei Sekundaercontrols. Primaer wird nur vergeben, wenn ein Kandidat eindeutig die naechste Anforderung fuer das Wurzelsicherheitsthema ist. Sind mehrere Controls materiell relevant, ohne dass eines dominiert, ist ein `mapped`-Ergebnis nur mit Sekundaercontrols gueltig. Ein vorhandenes materiell eigenstaendiges Sekundaercontrol darf nicht allein zugunsten einer kurzen Liste entfallen; blosse generische Wortnaehe bleibt unzureichend. `no_relevant_control` gilt nur ohne relevante Kandidaten, `mapped` verlangt mindestens eine Beziehung. Das Validierungshardlimit von fuenf bleibt rueckwaertskompatibel, waehrend der Prompt hoechstens vier Beziehungen anfordert. Neue Runs sind append-only; Entscheidungen und Scannerimporte bleiben unveraendert. + +Festlegung 2026-09-18 (Phase 13D, Finding-only Retrieval; ersetzt die v1.4-Retrievalzusammensetzung, nicht deren historischen Eintrag): Regulatorische Kandidatensuche und Mapperkontext werden allein aus dem datenschutzsicheren Findingtitel, der Beschreibung und der Empfehlung erzeugt. Problem und Remediation bilden unabhaengige Queries; Scannername, Rule-ID, Catalog und kuratierte Topics sind keine Retrievalsignale. Dense-/Sparse-RRF und die anschliessende Query-RRF arbeiten auf Control-Ebene mit hoechstens einer Stimme je Control und Rangliste. Abschnittssuchen duerfen ausgewaehlte Controls mit `control`-, `purpose`- und `guidance`-Passagen belegen, aber die Zwolf-Control-Auswahl nicht veraendern. Queryschema 4 und Retrieval 1.5 versionieren die Aenderung append-only. Der produktive Runtimepfad verwendet keinen Reranker; ein solcher wird erst nach gesonderter Untersuchung aktiviert. Human Review, vollstaendige Kandidatenbewertung und deterministische 0-1/0-3-Auswahl bleiben verbindlich. + +Festlegung 2026-09-15 (Phase 13D, ausdruecklicher Nutzerauftrag): Qdrant ist der rebuildbare Suchindex fuer versionierte regulatorische Chunks und niemals fachliche Quelle fuer Scannergebnisse oder Mappingentscheidungen. PostgreSQL bleibt System of Record fuer Scans, Findings, Ergebnisse, Reviews und spaetere append-only Mappingprovenienz. Dense und Sparse sind benannte Vektorraeume; zunaechst wird nur mehrsprachiges Dense Retrieval aktiviert. Candidate Retrieval und optionaler Reranker bleiben getrennte Schnittstellen. Ein Modellwechsel darf alte Vektoren nicht still weiterverwenden; Modellname und Dimension werden explizit gebunden, Abfragen filtern auf das aktive Modell, und ein Korpus-Rebuild bleibt Pflicht. Der Embeddingdienst ist eine eigene externe Vertrauensgrenze; Findinginhalte duerfen erst nach einer getrennten Datenschutzfreigabe als minimierte Query uebertragen werden. + +- 2026-09-23, Tabellenueberschriften im Environment-Results: Gespeicherte Tabellen- und Beobachtungsprovenienz darf fuer eine rein lesende, tabellengenaue Ueberschriftenzuordnung kombiniert werden. Der interne `sourceTableIndex` ist ein Join-Schluessel, kein leserelevantes UI-Feld. Die eindeutige native Unterabschnittsueberschrift hat Vorrang vor einem generisch nummerierten Tabellennamen; bei Konflikt wird nicht geraten. Die Zuordnung bleibt auf Scanlauf, Importdatei und Abschnitt begrenzt, ohne kanonische Werte zu veraendern. + +- 2026-09-23, Korrektur Environment-Detail-Results: Der Results-Button ist eine vertiefende, rein lesende Sicht auf den vorhandenen EnvironmentSnapshot, Quell-Findingbestand und die vorhandenen Score-Beitraege, nicht die Wiederholung der Kachel. Fachgruppen erhalten Quellabschnitte/Beobachtungen aus demselben Snapshot; Source Overview bleibt die vollstaendige Auffangansicht fuer nicht zuordenbare Originalfakten und zeigt die zugrundeliegenden Findings mit Originalfeldern. Original-/Normalwerte und Herkunft werden getrennt gezeigt, grosse Mengen progressiv ohne Zeilenverlust. Die fruehere Entscheidung unmittelbar darunter zum duplizierten Fensterinhalt ist durch diese ausdrueckliche Nutzerkorrektur ersetzt; Dialogmechanik und Kachel bleiben erhalten. + +- 2026-09-23, Environment-Detail-Results: Die acht Kacheln teilen sich genau die bestehende Results-Dialogmechanik der Betriebssystemkachel. Fensterinhalte sind eine zweite Leseansicht derselben bereits abgeleiteten Kacheldaten, keine neue Datenquelle, Result-DB-Abfrage oder Bewertungssemantik. Dialogaktionen verwenden den konkreten Kacheltitel fuer barrierefreie Namen; der OS-Sondertext in der gemeinsamen Fensterkomponente ist damit ersetzt. + +- 2026-09-23, Korrektur zur gemeinsamen Finding-Ueberschrift: Ein PingCastle-Regel-ID-Treffer allein beweist nicht dieselbe Berichtsversion. Die Leseprojektion darf einen besseren Titel nur aus dem eindeutig gepaarten Bericht desselben Projekts, Datums und Dateistamms uebernehmen; bei gleichrangigen widerspruechlichen Titeln bleibt der eigene native Titel. Die fruehere Entscheidung fuer den kanonischen Definitionstitel gilt innerhalb eines Vorkommnisses weiter, war fuer getrennte HTML-/XML-Vorkommnisse aber unvollstaendig. Oeffentliche PingCastle-IDs werden nur gegen den dokumentierten Regelkatalog validiert und in nativer Schreibweise angezeigt. + +- 2026-09-23, gemeinsame Finding-Ueberschrift: Result DB und Work fuehren Scannerfindings mit dem kanonischen `FindingDefinition.title`. Vorkommnisspezifische native Titel duerfen die Work-Ueberschrift nicht mehr ueberschreiben; bei Abweichung bleiben sie als `Native source heading` in der Leseprojektion sichtbar. Diese Regel ist reine Praesentation und aendert weder Originalfeld noch Provenienz, Finding-Identitaet oder gespeicherte Daten. + +**Security-Domain-Mengenbalken (2026-09-20):** Die Verteilung innerhalb der sichtbaren Client-Info-Security-Domains wird als dezenter Balken in einer eigenen Subgrid-Spalte dargestellt. Das gemeinsame Raster bemisst links den laengsten Domainnamen und rechts die breiteste Mengenzahl; der Balken bleibt mit gemeinsamem Abstand vollstaendig dazwischen, endet bei allen Zeilen an derselben Kante und waechst nach links. Alle Balken erben exakt den gemeinsam am Posture-Bereich gesetzten Tone des Overall Scores; dadurch stimmen sie immer mit der aktuellen Donutfarbe ueberein, waehrend die einzelnen Domainknoten weiterhin ihre eigene Pass-Rate-Farbe besitzen. Bezugsmenge ist die Summe exakt der angezeigten Domainmengen; eine Zeile verwendet denselben Wert, den ihre rechte Zahl bereits zeigt, einschliesslich des bestehenden Review-only-Falls. Der Balken ergaenzt die Zahl nur visuell, ist `aria-hidden` und darf weder fachliche Mengen noch Bewertung, Klassifikation oder Navigation beeinflussen. + +- 2026-09-20, Mindestgroessen fuer Information und Lesetext: Primaere Information in Tabellen, Kacheln und Feldbeschriftungen darf nicht unter 14 px fallen; zu lesende Werte und fortlaufender Text verwenden 16 px. Kleinere Rollen sind ausschliesslich fuer kompakte Controls, technische Metadaten und Badges zulaessig und duerfen nicht zum Verdichten primaerer Information missbraucht werden. Bestehende semantische 14-/16-px-Tokens bleiben die Quelle; keine lokale Literal- oder View-Sondergroesse. +- 2026-09-20, PingCastle-OS-Zustandsprojektion: `Nb OS`, `Nb Active`, `Nb Inactive`, `Nb Enabled` und `Nb Disabled` sind voneinander unabhaengige, native Werte derselben retained source row. Die UI darf sie gemeinsam anzeigen, aber weder Differenzen berechnen noch Werte ueber Quellzeilen oder Inventare hinweg zusammenfuehren. Die vorhandene generische Umgebungsextraktion bleibt die Quelle; keine neue Parser- oder Persistenzsemantik ist erforderlich. +- 2026-09-20, gemeinsamer Deviation-Scope: Data Hub und Client Info verwenden fuer Ergebnisanzahl und Prozentnenner dasselbe gemischte, timeslotgebundene Projektblatt sowie dieselbe zentrale Zustandsklassifikation. Scanner-Run-IDs allein sind keine vollstaendige Ergebnisgrenze, weil aktuelle GPO-/Policy-Ergebnisse assessmentgebunden vorliegen. Der Data-Hub-Donut bleibt eine Statusprojektion und macht ein GPO-Backup nicht zu einem Scanner-Run. +- 2026-09-18, Client-Info-Praesentation: Die freigegebene Ableton-Designsprache gilt auch fuer Client Info. Der Nutzer verlangt ausdruecklich den Erhalt der gemessenen gebogenen Overall-zu-Domaenen-Verbindungen. Zusammenfassung vor aufklappbaren Evidenz-/Governancedetails; keine Aenderung der fachlichen Daten- und Scorevertraege. Der exakte Resize-/Disclosure-/Risikowechselpfad ist synthetisch abgesichert. +- 2026-09-20, Client-Info-Breiten- und Zeilenvertrag: Posture und Aktionsrail verwenden auf breiten Ansichten exakt 1:1 und teilen die verfuegbare Zeilenbreite zur Haelfte. Diese spaetere Nutzerkorrektur ersetzt die kurzzeitig dokumentierte 2:1-Aufteilung. Jede gemeinsame Kachelzeile behaelt identische Hoehe und Unterkante. Accepted Risks uebernimmt die feste linke Client-/Timeslot-Auswahlbreite `clamp(420px, 27vw, 520px)` und die rechte Informationsflaeche; unterhalb des bestehenden schmalen Breakpoints bleibt die Stapelung erhalten. +- 2026-09-20, Overall-Score-Inhaltsvertrag: Unter dem Score-Donut erscheinen weder eine textuelle Statuswiederholung noch ein zweiter Critical-Findings-Zaehler. Assessment Coverage bleibt auf die kompakte Inhaltsbreite begrenzt und darf die gebogenen Domaenenlinien nicht beruehren oder ueberlagern. + +**Verbindliche Ableton-Designreferenzen einschliesslich Client Info (2026-09-18):** Die ausdrueckliche Nutzerkorrektur ersetzt die bisherige Client-Info-Sonderpalette/-Geometrie durch denselben visuellen Vertrag wie Data Hub, Work und Pathfinder. Die drei bestehenden, freigegebenen Ansichten bleiben Referenzen; sie werden nicht an neue Entwuerfe angepasst. Aktuelle Projekt-Tokens und AGENTS.md haben Vorrang vor historischen Skill-Assets, Archetypen und verworfenen Bildentwuerfen. Der Vertrag gilt bereits fuer Designvorschlaege: gemeinsame neutrale Flaechen, transparente Segmente, flache eckige Tiles, vorhandene Controls, Inter, gelbe/bernsteinfarbene Auswahl und Aktionen, blauer Fokus, semantische Statusfarben, 20px Inset und volle 360-Grad-Donuts. Fachliche Client-Info-Hierarchie, Scoremodelle und Quelle-/Work-Drilldowns bleiben erhalten. Aeltere abweichende Entscheidungen im Verlauf sind historische Eintraege und durch diese Korrektur nur hinsichtlich der visuellen Ausnahme supersediert. + +**Vollstaendiger Security-Domain-Katalog im Work-Filter (2026-09-18):** Der unveraenderte gemeinsame Client-Info-Katalog ist der Optionsvertrag, nicht die aktuell gefilterte Treffermenge. Alle acht Domains bleiben bei null Treffern auswaehlbar; Unclassified wird nur bei vorhandenen unklassifizierten Datensaetzen ergaenzt. Eigene Auswahl bleibt bei der Facettenzaehlung ausgenommen; andere aktive Filter gelten weiter. Noch gueltige aktive Kategorie-/Statusauswahlen verschwinden bei null Treffern nicht automatisch. Der normale Domain-Deviation-Drilldown aus Client Info verwendet denselben sichtbaren Filter statt pathFindingIds; ausdrueckliche Review-only- und Einzelbefundpfade bleiben separat begrenzt. Quellen-/Timeslotgrenzen und Domainzuordnung werden nicht erweitert. + +**Aktuelle GPO-Laufauswahl und autoritative Statusfilter (2026-09-18, beauftragter Fehlerfix):** Work und PostgreSQL-Result-DB messen Laufabdeckung an verschiedenen Baseline-IDs in den erhaltenen Ergebnissen; mehrere Analyseversionen eines Pakets sind keine zusaetzliche Abdeckung. Fehlen solche IDs vollstaendig, bleiben deklarierte Analyseverweise der Fallback. Bei gleicher Abdeckung gewinnt der neuere Lauf, bei gleichem Zeitpunkt die ID. Historie bleibt unveraendert. Deviation darf ein autoritatives Fail nicht aufgrund des angezeigten Configured Value verwerfen; die vereinbarten Sonderfaelle fuer erforderliche Schluessel-/Leerstringpraesenz bleiben Fail, das gewoehnliche Not-configured-Urteil bleibt neutral. Result DB zaehlt weiterhin Vergleiche, Work Einstellungen. Synthetische Interaktionstests sichern beide GPO-Work-Einstiege sowie die Result-DB-Auswahl; optionale PostgreSQL-Paritaetstests verwenden ausschliesslich synthetische CTEs in einer read-only-Verbindung ohne Schema-/Tabellenanlage. + +**Result-DB-Statusfilterkorrektur (2026-09-18, ausdruecklicher Nutzerauftrag):** Die fruehere Ausnahme vom 2026-09-07, GPO-Klassifikationen unabhaengig von Deviation zu zaehlen und Deviation bei Auswahl zu entfernen, ist abgeloest. Result Status beachtet wie andere Facetten jeden fremden aktiven Filter und nimmt nur die eigene Auswahl aus seiner Alternativzaehlung aus. Ausgewaehlte Nulltreffer bleiben sichtbar. Gemeinsame Labels mit Work sind reine Praesentation; Result DB behaelt Einzelvergleiche, Work seinen technischen Setting-Rollup. Review required bleibt fachlich eigenstaendig; No baseline rule und Not comparable werden nicht durch Freigabe interner Beobachtungen fuer Result DB erfunden. + +**Work rollt Baselinepakete auf die technische Einstellung auf (2026-09-18):** Persistierte Paketvergleiche bleiben eigenstaendige Evidenz; Work zeigt je Projekt/Aggregation/Scope/Identitaet genau eine Zeile mit dem vorhandenen Zaehlerurteil. Baselineauswahl filtert die Mitgliedschaft, nicht das Urteil. Abweichende Sollwerte bleiben paketbezogen; Quellenmarkierungen benoetigen Evidenz gegen alle aktuellen Varianten. Alte lokale Review-Identitaeten werden fuer lesbaren Erhalt mitgefuehrt; widerspruechliche Reviews und Risikoakzeptanzen werden nicht automatisch vereinigt. Details siehe GPO_BASELINE_EVALUATION.md. + +**Work-Listenstabilitaet und technische Pfade (2026-09-18):** Eine Auswahl darf nicht gleichzeitig vom virtuellen Listencontainer und vom einzelnen Listenelement animiert werden. Der Container ist die einzige Scrollautoritaet und positioniert eine notwendige Auswahl deterministisch ohne Smooth-Animation; sichtbare Karten loesen keinen eigenen Scroll aus. Scrollbare Datensatzlisten reservieren ihre Scrollbarspur. Vollstaendige Registrypfade in Titeln verwenden dieselbe inerte `technical-path`-Darstellung wie Pfadfelder, bleiben vollstaendig lesbar und duerfen Kopfaktionen nicht ueberlagern. Der Titelvertrag umfasst `registry · ` sowie `Registry Values · MACHINE\\...`/`USER\\...`; nackte `MACHINE\\`-/`USER\\`-Texte ausserhalb dieses Vertrags werden nicht umklassifiziert. Diese Darstellungsentscheidung aendert weder Originaltitel noch Datensatzidentitaet. + +Festlegung 2026-09-17 (Phase 13B, GPO-Quellwiederherstellung): Die persistierte backend-controlled-Referenz bleibt als Provenienz erhalten; die aktuelle Dateiverfuegbarkeit wird separat und ohne Repository-Revisionscache gelesen. Nur ENOENT bedeutet fehlende Bytes und Upload required; Zugriffs-, Konfigurations- oder ungueltige Objektpfade ergeben Storage unavailable. Automatische Reparatur, Retry und Reprocess duerfen ohne verfuegbare Quelle keinen Job erzeugen; verschwindet sie nach dem Einreihen, endet der erste fehlgeschlagene Versuch ohne automatische Wiederholung. Der gezielte Originalupload bindet an Projekt/Artefakt und gegebenenfalls Timeslot, prueft Groesse und SHA-256 und stellt die urspruengliche Speicher-ID atomar ohne Ueberschreiben wieder her. Gespeicherte Analysen bleiben erhalten. Reine Neuauswertung erhaltener Eingaben bleibt moeglich; veraltete Analyzer benoetigen weiterhin zuerst Reprocessing. Kein Analyzerbump, keine neue Interpretation und keine Bestandsmutation allein durch die Verfuegbarkeitsanzeige. + +Festlegung 2026-09-16 (Phase 7/13B, Policy-Rollup-Praezisierung): Diese Entscheidung ersetzt die am selben Tag dokumentierte Interpretation, nach der Conflict-/Duplicate-Container trotz eines belegten Mitglieds-Fails score-neutral bleiben koennten. Verdict und Diagnose sind getrennte Achsen. Ein belegter Fail eines konfigurierten, vergleichbaren In-Scope-Mitglieds macht die technische Policy-Einstellung insgesamt genau einmal zu Fail; Conflict/Duplicate bleibt als zusaetzliches Merkmal. Ohne belegten Fail ergeben ausschliesslich Pass-Mitglieder einen Policy-Pass, waehrend ungeklaerte Anwendbarkeit oder Prioritaet Review required bleibt. Ein konkretes Geraet wird ohne Effective-State-/RSoP-Evidenz weiterhin nicht als verwundbar behauptet. + +Festlegung 2026-09-16 (Phase 7/13B, GPO-Bewertungsscope): Die operative GPO-Analyse ist misconfiguration-first. Scorefaehig sind nur konfigurierte, technisch eindeutig vergleichbare Kundeneinstellungen im anwendbaren Microsoft-Baseline-Scope. `Not configured`, `Duplicates` und `Conflicts` bleiben sichtbare, eigenstaendige und score-neutrale Containerkategorien. Ein unabhaengig belegter Fail eines darin enthaltenen konfigurierten Werts bleibt genau einmal scorewirksam; weder Containerstatus noch Quellanzahl erzeugen zusaetzliches Gewicht. Vollstaendige Baseline-Adoption ist ein eigener Hardening-Auftrag und darf aus dem normalen GPO-Score nicht behauptet werden. Diese Nutzerentscheidung ersetzt jede Lesart, nach der fehlende Microsoft-Empfehlungen ueber Coverage oder einen impliziten Nenner den operativen Score mindern. + +Festlegung 2026-09-16 (Phase 7, gemischter Work-Filterkontext): GPO-spezifische Facetten gehoeren ausschliesslich zum eindeutigen Werkzeugkontext `group-policy`, der durch das GPO-Blatt oder eine eindeutige GPO-Quellenauswahl entsteht. `Source: Scan = All` ist ein gemischter Kontext; dort bleiben Result Status, allgemeine Scannerfacetten und der permanente Source-Filter sichtbar, waehrend GPO-exklusive Felder nicht am allgemeinen Facettenlimit teilnehmen. Jeder Kontextwechsel entfernt gespeicherte Facettenauswahlen, die im neuen sichtbaren Vertrag nicht mehr gueltig sind. + +Festlegung 2026-09-16 (Phase 7, Work-Snapshots): Die vollstaendig wirksame Work-Projektion ist der Snapshotvertrag. Ein gespeicherter Ansichtsstand umfasst deshalb auch den Finding-Scope eines Drilldowns und darf ihn beim Wiederherstellen nicht pauschal leeren. Der Scope wird als Datensatz-ID-Liste lokal und timeslotgebunden gespeichert; alte Eintraege ohne Feld werden abwaertskompatibel als uneingeschraenkte Ansicht gelesen. Pathfinder-Snapshots behalten zusaetzlich ihre Graphknoten und wenden daraus weiterhin ihren exakten Finding-Scope an. + +Festlegung 2026-09-14 (GPO-Varianten, Nutzerfreigabe): Unbekannte Zielrolle verhindert kein eindeutiges Urteil ueber alle beruecksichtigten Baselinevarianten. Die Vereinigung von Kontenlisten ist kein neuer Sollwert; jede Variante behaelt ihr eigenes Einzelurteil. Dies ersetzt fuer neue Evaluationen die pauschale Review-/Konfliktsperre bei abweichenden Baselinewerten aus dem GPO-Vorlagenkontext vom 2026-09-09, nicht die historische Evidenz. Explizite Rollenwahl, Originalherkunft, fehlende Wirksamkeitsevidenz und strikte Trennung von Baselinealternativen und Kunden-GPO-Konflikten bleiben bestehen. Bewertungswechsel verlangt Evaluator 1.5.0 und explizite Neuauswertung, nicht automatisch einen Scanner-Reimport. + +Festlegung 2026-09-11 (Phase-8-Planergaenzung): Regeldefinition, objekt-/scopebezogene Vergleichsidentitaet und zeitgebundene Beobachtung bleiben getrennt. Abwesenheit ohne belastbare Gegenpruefung ist keine Behebung. Scorevergleich und Behebungsfreigabe erhalten unterschiedliche fachliche Bedingungen; teilweise neue Evidenz ersetzt nicht pauschal alle alten Verpflichtungen. A und B bleiben die ausdrueckliche Messbasis, aeltere Historie dient getrennt der Verpflichtungs-/Lifecycleverfolgung. Die Festlegung praezisiert das Quellenmodell vom 2026-09-06 und ersetzt fuer die kuenftige Implementierung die historische Regel `abwesend = resolved`; keine historischen Daten oder Ergebnisse werden umgeschrieben. Details und Grenzen: [TIMESLOT_COMPARISON_PLAN.md](TIMESLOT_COMPARISON_PLAN.md). + +Festlegung 2026-09-10 (Purple-Knight-Begleitdateien): Ein nativer Score darf aus einer separaten Summary auf die Findings desselben Scanlaufs uebertragen werden, wenn genau ein nativer Traeger und eine eindeutige Ergebnispopulation denselben Werkzeug- und Verarbeitungskontrakt teilen. Datei- und Vorkommensherkunft bleiben gemeinsam erhalten; Mehrdeutigkeit verhindert die Verbindung. + +Festlegung 2026-09-10 (weitere Scanner): Native Gesamtwerte werden bei jeder Profilerweiterung zuerst geprueft und deklarativ mit ihrer Bedeutung erfasst. Die Scoredefinition ist Pflicht, die Berechnung gemeinsam; ihre Version gehoert zur Vergleichskompatibilitaet. Extraktion und Originalherkunft bleiben im generischen Importpfad. AGENTS.md und docs/SCORING_MODEL.md halten die Erweiterungsregel fest. + +Festlegung 2026-09-10 (Phase 7/13C/8, Nutzerfreigabe): Die bisher nur sekundaere native Scoreanzeige wird durch das versionierte hybride Beitragsmodell in `docs/SCORING_MODEL.md` ersetzt. Unterschiedliche native Risikomodelle und Bestehensquoten bleiben ausdruecklich methodisch verschieden; keine Severitygewichte oder Domainzuordnungen werden erfunden. Scoring bleibt plattformneutrale Fachlogik ausserhalb von React. Originale und gespeicherte historische Assessments bleiben unveraendert. + +Festlegung 2026-09-09 (Phase 13/13A, HTML-Timeout): Attributtoken werden monoton und ohne unanchored name=value-Backtracking gelesen. Gemeinsam verwendete Verweisdefinitionen werden nur innerhalb ihres exakten unveraenderten Markups indiziert; keine globale oder dateinamenbasierte Wiederverwendung. Mehrdeutigkeit, erste Definition, Zielreihenfolge, Vollstaendigkeit und Originalwerte bleiben Vertragsbestandteile. Leistung wird ueber Zeichenarbeit und Inhaltsparitaet abgesichert; der gebaute isolierte Worker muss mit unveraenderten Sicherheitsgrenzen bestehen. Die Fehleranzeige allein ist kein Beleg fuer die konkrete Struktur der realen Quelldatei. + +Festlegung 2026-09-09 (Phase 13A/13C, PurpleKnight): Kontext-Extractors duerfen keine anderen Findingtabellen desselben Dokuments verdraengen; sie komponieren deren generische Extraktion unter Erhaltung der Quellindizes. Native Berichtssyntax gehoert in den registrierten Source Extractor, der gemeinsame statische Leser bleibt werkzeug- und plattformneutral. HTML-Metriken verwenden dieselben semantischen Kontextvertraege wie die Zusammenfassungstabellen; unbekannte Originaldaten bleiben separat erhalten. Abgeleitete Anzeigefelder zeigen auf reale Eingabeobjekte statt erfundene Quellfelder. Zeitpraezision wird nicht fuer Formatparitaet reduziert. Fehlende IDs und unlesbare/konkurrierende Objekte scheitern, doppelte Regel-IDs bleiben getrennte Vorkommen mit Diagnose. Profil 1.3.0 versioniert Erfassung und Evidenz; Mapping/Normalisierung/Praesentation 1.1.0 und kanonischer Kompatibilitaetsschluessel bleiben erhalten. Reimport ist empfohlen, aber ohne ausdruecklichen Auftrag nicht durchgefuehrt. + +Festlegung 2026-09-22 (Phase 13A/13B, Purple Knight AD und Entra ID): Active Directory und Entra ID sind getrennte Assessment-Scopes desselben Purple-Knight-Profils, nicht austauschbare Scanner. Der kanonische Tool-ID bleibt `purple-knight`, waehrend ScanRun und Scorequelle den Scope lesbar benennen. AD bindet Forest und `purple_knight.ad.*`; Entra bindet `entra.tenant_name` und `purple_knight.entra.*`. Native Scores duerfen nur innerhalb ihres Scopes verwendet werden. Ein Batch mit beiden Scopes wird ausdruecklich als kombiniert bezeichnet und nie still als AD oder Entra ausgegeben. Bestehende 1.3.0-Importe bleiben historisch unveraendert und benoetigen fuer den neuen Entra-Kontext einen auditierten Reimport. + +Festlegung 2026-09-22 (Phase 7/13C, Maester Security Domain): Eine vorhandene Maester-Scanneridentitaet und `Unclassified` sind verschiedene Achsen. `Unclassified` darf nur die fehlende fachliche Security-Domain-Zuordnung ausdruecken. Offizielle stabile Maester-Suite-/Control-Praefixe duerfen als enger Fallback dienen, wenn Titel und beschreibende Felder keine spezifischere gemeinsame Domain liefern; sie duerfen Status, Severity, Scanneridentitaet oder Quellkategorien nicht veraendern. ORCA/EXO und Entra-Suiten fallen dabei unter `Cloud & Applications`; spezifische Inhaltsregeln wie Conditional Access behalten Vorrang. + +Nutzerkorrektur 2026-09-22 (Phase 13A/13B, Purple Knight AD gegen Maester): `Purple Knight for Active Directory` ist kein Maester-Scan. Gemeinsame Directory-Anzeigeflaechen oder eine werkzeuguebergreifende Tenant-Zaehlung begruenden keinerlei Scanneridentitaet. Purple-Knight-AD behaelt Tool-ID `purple-knight`, AD-Scope und ausschliesslich AD-/Forest-Kontext; Maester behaelt Tool-ID `maester` und seinen eigenen Entra-Testkontext. Kein Import-, Scoring-, Filter- oder Darstellungspfad darf Purple-Knight-AD als Maester bezeichnen, klassifizieren oder auswerten. + +Festlegung 2026-09-09 (Phase 13A/13C, PingCastle): Originale bleiben unveraendert. XML-Attribute werden als exakte Name/Wert-Paare mit eigenen Quellpfaden neben Text und expliziter Leere gefuehrt; Attribut-Anzeigezeichenketten sind kein verlustfreies Austauschformat. Der generische HTML-Leser schuetzt zitierte Attributgrenzen, bereinigt nur ganze Attribute und behandelt abgeschnittene Textausschnitte getrennt von vollstaendigen Dokumenten. Native Rule IDs sind erforderlich. Die historische First-Presentation-Deduplizierung bleibt erhalten, wird aber mit einer Warnung sichtbar. Kategorie-Trefferzahlen werden gegen eindeutige Regeln, nicht gegen Kataloggroessen geprueft; Originalzaehler erhalten einen separaten Reportabschnitt ausserhalb der Assetbeobachtungen. Profil 1.5.0 und Extractor 2.2.0 versionieren die Aenderung; Mapping 1.2.0, Normalisierung 1.1.0 und Kompatibilitaetsschluessel bleiben erhalten. + +Festlegung 2026-09-09 (Phase 13A/13C, Maester): Eingebettete Berichtsdaten sind Daten, kein auszufuehrendes Programm. Der native Extractor erweitert die generische Pipeline und liefert codekontrollierte Werkzeugerkennung, vollstaendige Originalfelder mit Quellpfaden sowie getrennten Berichtskontext. Statische Objektliterale sind nur innerhalb der dokumentierten Grammatik und Ressourcengrenzen zulaessig; dynamische oder mehrdeutige Berichtswurzeln werden explizit abgelehnt. Semantisch mehrdeutige Feldnamen werden anhand der Spalten desselben Kandidaten beziehungsweise derselben Tabelle abgebildet, nicht anhand des Dateityps allein. Gruppierungs- und Wiederverwendungsschluessel beruecksichtigen diesen Kontext. Result-Nachricht und Statusfilter verwenden dieselbe Prioritaet; Evidenztext darf keinen zweiten Ergebnisstatus erzeugen. Native Summenzaehler werden nicht als Vollstaendigkeitsbeweis benutzt oder ueberschrieben, sondern gegen die Einzeltests abgeglichen. Maester-Profil, Mapping und Praesentation steigen auf 1.1.0 bei unveraenderter Normalisierung und Kompatibilitaetsschluessel; historische Verarbeitungsstaende bleiben lesbar und werden als Reimport empfohlen ausgewiesen. + +Festlegung 2026-09-09 (Phase 7, Navigationskosten): Unveraenderte Filter-, Sortier- und selbst-ausnehmende Facettenprojektionen werden zwischen Verbrauchern und Bereichsbesuchen geteilt. Begrenzte schwach blattgebundene Caches fuehren alle fachlichen Eingaben im Schluessel: Profil, Dataset, Reviews, Filter, Suchtext, Sortierung und Pfadscope. Komponenten-useMemo oder wiederverwendbare IDs allein reichen nicht. Unsichtbare Rohtexte, Exportpayloads, Optionslisten und Graphbeschriftungen werden erst bei Bedarf aufgebaut. Retained Views pausieren versteckte Arbeit und uebernehmen bei Aktivierung aktuelle Eingaben; Workspacewechsel verwerfen den alten Zustand. Datenschutzarme lokale Dev-Messung bleibt ausdruecklich opt-in und ausserhalb des Produktionsbundles. Verfahren und Abnahmeregeln stehen in docs/architecture/navigation-performance.md. + +Festlegung 2026-09-08 (Phase 7/13B, GPO-Quellen): Die bestehende Policy-Analyseuebersicht ist fuer aktuelle Profil-, Identity- und Snapshotrevisionen autoritativ. Work uebernimmt ihre aktuellen Evaluations-IDs; wechselnde Ergebnisabdeckung ist niemals eine Importidentitaet. Die zusaetzliche Auswahl je Aggregation verwendet den gemeinsamen versionierten Evaluationsselektor. Vergleiche duerfen nur erscheinen, wenn ihre referenzierten Beobachtungen vollstaendig zum geladenen Timeslot-Scope gehoeren. Import- und Auswertungszeit bleiben getrennt; fehlende Kundenwerte beziehen ihren Importzeitpunkt aus demselben Evaluationskontext. Persistierte Historie und Originale bleiben unveraendert. + +Festlegung 2026-09-08 (Phase 13B, ausdruecklicher Nutzerwunsch): Die Security-Template-Regel vom 2026-07-21, jeden defekten unterstuetzten Eintrag zum Anlass fuer die Verwerfung des gesamten Artefakts zu nehmen, wird gezielt ersetzt. Nicht unterstuetzte Sektionen besitzen keine Key/Value-Grammatikpflicht. Isolierte fehlerhafte Eintraege werden diagnostiziert und ausgelassen, gueltige Instruktionen mit Originalwert und Quellzeile bleiben bei Dokumentstatus `partial` erhalten. Beschaedigte Abschnittszuordnung, Dekodierungs- und Ressourcengrenzen bleiben fail-closed. Die Inventarprojektion weist Teilverarbeitung aus und behauptet keine Vollstaendigkeit. Baseline-Consensus-Konflikte bleiben Review; der Fix waehlt keinen Gewinner und aendert weder Comparatoren noch Deviationfilter. Jede Baselineanalyse besitzt einen eigenen versionierten ADMX-Katalogdatensatz: Die Katalog-ID bindet deshalb Analyse-ID und Inhaltsidentitaet, auch wenn ADMX/ADML unveraendert sind. Technische Policy-Identitaeten und Kataloginhalte bleiben gleich; historische Analysen werden nicht ueberschrieben. Damit wird der beim ersten Bestandsreprocessing belegte PostgreSQL-Schluesselkonflikt behoben, ohne das Schema zu aendern. + +Festlegung 2026-09-06 (Phase 8, fehlende Folgequellen): Timeslotvergleiche trennen kuenftig gemessenen Fortschritt, Gesamtexposition und Evidence Coverage/Freshness. Fehlende erwartete Quellen werden nicht als behoben interpretiert. Offene Verpflichtungen werden mit Herkunft und Alter als `carried-forward-awaiting-revalidation` fortgeschrieben und bleiben scorewirksam; Rohbeobachtungen werden nicht als aktuelle Evidenz kopiert. Ein Scope-Ende ist ausschliesslich ueber eine begruendete, auditierte `retired-out-of-scope`-Entscheidung moeglich. Dieser generische Vertrag gilt fuer Scanner, GPOs und spaetere Tools und wird nicht ueber ein primaeres manuelles Auswahlhaekchen gesteuert. + +Festlegung 2026-09-06 (Phase 9/10, FindingReader-Reviews): Bearbeitbare Workflowdaten gehoeren zum kanonischen Finding-Review und damit in die ASSESSOR-Datenbank, nicht nur in Local Storage. Die stabile Occurrence-ID verbindet Aggregate und Quellansicht; Datenbankwerte gewinnen beim Laden, Local Storage bleibt Rueckfall und Migrationsquelle. Der exakte UI-Status wird additiv neben dem kanonischen Workflowstatus bewahrt; unbekannte kuenftige Marker bleiben bei Updates erhalten. + +Festlegung 2026-09-06 (Phase 13B, einzelnes GPO-Delete): Ein ausdruecklich bestaetigtes, projekt- und artefaktgebundenes Delete ist fuer beendete GPO-Importe zulaessig und entfernt neben der backendkontrollierten Originalkopie alle direkt oder transitiv davon abhaengigen Processing-, Identity-, Snapshot-, Evaluation- und Finding-Derivate. Eine Aggregation mit mehreren Quellen wird vollstaendig invalidiert, sobald eine ihrer Quellen geloescht wird; die uebrigen Quellimporte und das Environment Profile bleiben bestehen und koennen neu aggregiert werden. Queue-/Running-Jobs bleiben gegen Loeschung gesperrt. Die persistente Loesch-Outbox bleibt die Grenze zwischen relationalem Commit und Dateientfernung. Diese Festlegung ersetzt die Entscheidung vom 2026-07-21, Delete ausschliesslich fuer vollstaendig fehlgeschlagene GPO-Artefakte zuzulassen. + +Festlegung 2026-09-06 (Phase 13B, Baseline-Reimport): Eine ausdruecklich bestaetigte Baseline-Loeschung darf referenzierende, reproduzierbare Evaluation-/Finding-Derivate transitiv entfernen. Unveraenderliche Kundenquellen, GPO-Processing-Runs, Beobachtungen, Environment Profiles und Snapshotaggregationen werden dadurch nicht geloescht. Diese Reimportfunktion ersetzt die Entscheidung vom 2026-08-22, referenzierte Baselines grundsaetzlich zu sperren. + +Festlegung 2026-09-06 (Phase 12/13B, Datenschutzgrenze der Result DB): Die Result DB enthaelt kanonische Findings und ausschliesslich explizit freigegebene, nicht identifizierende Zusatzbeobachtungen. Eine versionierte tool-/propertybezogene Allowlist rekonstruiert nur kontrollierte Titel, Klassen und eng validierte Aggregate, Konfigurationszustaende oder technische Metadaten; Subject-Identitaet, Originalwert, Attribute, Asset, Abschnitt und Locator bleiben intern. Unbekannte beziehungsweise zukuenftige Tools behalten ihre regulaeren Findings im generischen Importpfad, ihre Zusatzfelder bleiben jedoch bis zur Datenschutzklassifikation fail-closed ausserhalb der Result DB. Rohe GPO-Policy-Beobachtungen sind nur noch im ausdruecklichen internen Analysemodus fuer Work/GPO Analysis lesbar; bestaetigte Policy-Findings bleiben Result-DB-faehig. Diese Festlegung supersediert die Entscheidung vom 2026-09-03, rohe GPO-Policy-Beobachtungen auch in der Result DB darzustellen. + +Festlegung 2026-09-22 (Phase 12/13B, LLM-faehige Result DB): Das ausdrueckliche Nutzerziel supersediert den Teil der vorstehenden Entscheidung, nach dem regulaere Findings ihre importierten Regeltexte und GPO-Vergleiche ihre Kundenwerte in der normalen Result DB behalten duerfen. Die Result DB ist nun fuer jede Quellart eine Disclosure-Projektion 2.0.0. Nur kontrolliertes Produktvokabular, katalogeigene oeffentliche Regel-IDs, normalisierte Bewertungsachsen, kontrollierte Diagnosecodes und eng validierte nicht identifizierende Zusatzwerte duerfen passieren. Freie Quellprosa, Personen-/Firmen-/Tenant-/Domain-/Host-/Assetdaten, Reviewpersonen, Policy-Ist-/Sollwerte und interne Provenienz bleiben im `internal-analysis`-Pfad. Der JSONL-Export ist eine zweite unabhaengige Sperre und entfernt auch Scope-/Result-/Run-/Artefaktidentitaeten, Zeitpunkte und konkrete Such-/Filterwerte. Die Aussage betrifft Identifizierbarkeit; die anonymisierte technische Sicherheitsbewertung bleibt absichtlich erhalten, da andernfalls keine fachlich nutzbare LLM-Grundlage existiert. + +Nutzerkorrektur 2026-09-22 (Phase 12/13B, fachlich nutzbare Result DB): Die vollstaendige Ersetzung der Regelprosa durch generische Tooltitel war eine unbrauchbare Ueberkorrektur und wird durch Disclosure Policy 2.1.0 supersediert. Bekannte Scannerprofile behalten Titel, Beschreibung und Empfehlung als fachlichen Regelinhalt; Purple Knight behaelt zusaetzlich eng validierte native `SI`-Regel-IDs. Die Projektion entfernt exakte private Literale aus Asset-, Review-, Scope- und Locatorfeldern und redigiert E-Mail/UPN, Domain, SID, Directory-Objekt, Konto, IP/MAC, URL und Pfad sowie Organisationsnamen mit Rechtsformsuffix durch typisierte Platzhalter. Unbekannte Quellen bleiben generisch; Asset und Reviewperson selbst werden nicht ausgegeben. Eine UI-Regression muss sichern, dass das Aufklappen einer Result-DB-Zeile zugleich fachlichen Inhalt zeigt und das betroffene Objekt verbirgt. + +Festlegung 2026-09-06 (Phase 13B/13C, ausdruecklicher Nutzerwunsch): Vor Rueckfragen zum GPO-Zielkontext vorhandene Result-DB-/PingCastle-Umgebungsbeobachtungen im selben Assessment auswerten. Belegte DC-Betriebssystemkontexte duerfen mit Beobachtungsprovenienz automatisch entstehen; dies erweitert die bisherige ausschliesslich manuelle Profilwahl. Domain-/Forest-Functional-Level, Herkunft des Backups vom DC und Registry-Pfade allein beweisen weder Betriebssystemversion noch GPO-Anwendung auf DC/Member/Client. Gemischte oder unzureichend belegte Plattformen bleiben klaerungsbeduerftig. Technische Identitaeten gleichen konkrete Einstellungen ab, nicht GPO-Namen. + +Festlegung vom 2026-09-06 (Phase 11, lokaler Persistenzbetrieb): Der vorhandene Docker-Compose-Bestand `assessor-2_0` mit der Datenbank `assessor`, dem Container `assessor-2_0-postgres-1` und dem persistenten Volume `assessor-2_0_assessor-postgres-data` ist der einzige kanonische lokale ASSESSOR-Datenbestand fuer diesen Workspace. Lokale Starts verwenden ausschliesslich `127.0.0.1:5432`. Die Compose-Konfiguration bindet dieses Volume deshalb namentlich als `external`; bei fehlendem Bestand oder Portkonflikt muss der Start fehlschlagen, statt eine weitere ASSESSOR-Datenbank oder einen Ersatzport anzulegen. Diese ausdrueckliche Nutzerfestlegung ersetzt die bisherige implizite, verzeichnisabhaengige Compose-Projektidentitaet. Der interne Browser-/Backend-/PostgreSQL-Zielaufbau bleibt unveraendert. + | Datum | Entscheidung | Begründung | +| 2026-09-23 | Der globale ISO-Korpus wird bis zur Phase-14-Nutzerverwaltung nur mit einem separaten Operator-Upload-Token aus Data Hub erneuert. Die privaten versionierten JSON-Korpusquellen bleiben im Artefakt-Volume, Original-PDFs nur temporaer; der freigegebene Embedding-Endpunkt darf den lizenzierten Kontrolltext erhalten. | Der Nutzer hat Token, private Wiederaufbauquelle und Embedding-Ziel ausdruecklich bestaetigt. Eine fuer alle Projekte wirksame Korpusaktivierung darf nicht allein von der allgemeinen VPN-/App-Erreichbarkeit abhangen. | +| 2026-09-21 | Defender scoped risk acceptance keeps the one-finding-per-CVE projection. A device-finding decision binds one canonical CVE definition to one exact stable device key; a device-snapshot decision is a server-derived immutable set of all detailed actionable CVEs in the selected active scan-run scope. Coverage is the union of independent valid decisions and carries forward only inside the same project for the same exact device key and captured definition. | This preserves existing whole-finding behavior and source provenance while allowing the two requested device-level workflows. Server-derived membership prevents a client from omitting current CVEs; immutable keys and fail-closed unresolved/ambiguous identities prevent accidental cross-device or cross-import carry-forward. | +| 2026-09-15 | Nicht-personenbezogene Umgebungsaggregate (Konten-, Inventar-, Passwortrichtlinien- und Konfigurationszaehlungen bzw. -booleans) ueberschreiten die Result-DB-Offenlegungsgrenze und den AI-Datenvertrag ausschliesslich ueber exakte Property-Allowlist-Regeln; identifizierende Namen und alle Zeitstempel bleiben ausgeschlossen. Die Werte werden aus bereits extrahierten Rohbeobachtungen abgeleitet und unter stabilen Property-Namen statt fragiler `tabelle.N`-Schluessel emittiert. | Client Info zeigte diese Aggregate bereits aus dem Roh-Snapshot, waehrend Result DB und AI sie fail-closed verwarfen. Stabile Ableitungen erlauben eine explizite, pruefbare Offenlegung ohne die fail-closed Grenze zu einer generischen Freigabe zu oeffnen; der Nutzer hat den Umfang (Konten inkl. Aufschluesselung, Inventar, Richtlinie, Konfiguration) und den Ausschluss von Namen/Zeitstempeln ausdruecklich bestimmt. | +| 2026-09-14 | AI Overview verwendet ausschliesslich das per Backend konfigurierte, unternehmensverwaltete LiteLLM ueber HTTPS; ein lokales Modell oder Browserzugriff auf Gateway/Key ist nicht vorgesehen. Der vollstaendige aktive Timeslot wird ueber den bestehenden Privacy-Safe-JSON-Vertrag uebertragen, grosse Eingaben werden ohne Record-Trunkierung hierarchisch zusammengefuehrt, und nur validierte Endergebnisse werden je Timeslot persistiert. | Der Nutzer hat Work-LiteLLM samt URL, Modellalias und API-Key bereit. Die bestehende Exportgrenze verhindert einen zweiten, weiter gefassten AI-Datenvertrag; serverseitige Secrets, explizite Ausloesung, lokale Validierung und append-only Historie halten Netz-, Kosten-, Datenschutz- und Auditgrenzen nachvollziehbar. | +| 2026-09-14 | Die synthetische Mock-CVE-Datei wiederholt `Site` und `Sensor` je Zeile als ausdruecklich simulierte, ueber `Device ID` konsistent abgeleitete Fixture-Felder. Der Parser behandelt sie wie vorhandene optionale CVE-Kontextfelder; der Mehrdatei-Inventarjoin bleibt zusaetzlich bestehen. | Die CVE-Datei muss den Mockup auch als Einzelimport vollstaendig speisen. Die Kennzeichnung verhindert, dass die Zusatzspalten als behaupteter nativer Defender-Exportvertrag missverstanden werden. | +| 2026-09-11 | Bis ein unveraenderter nativer Defender-for-IoT-Export vorliegt, ist das synthetische `Mock-Defender`-Paket die Entwicklungs- und Testquelle fuer den Defender-Importer. Actionable CVEs kommen ausschliesslich aus der strukturell validierten `cves.csv`; optionale Device-Inventare reichern nur ueber die explizite `Device ID` an. | Das bearbeitete Excel ist keine belastbare Rohquelle mehr. Der enge CSV-Vertrag ermoeglicht reproduzierbare Entwicklung ohne erfundene Site-, Sensor-, Beschreibungs- oder Scoresemantik und laesst sich spaeter anhand eines echten Exports versioniert validieren. | +| 2026-09-07 | Die geladene Client Info ist innerhalb der Wurzelklasse `.client-command-center` eine feste dunkle Command-Center-Ausnahme von der allgemeinen Kachelkomposition. Die genehmigte Hierarchie ist Client/Assessment/Source, sechs Icon-Fakten, Overall Score mit acht visuell verbundenen Security Domains, Priority Findings plus Assessment Gaps und abschliessend fuenf werkzeugspezifische Source-Flaechen. | Die ausdruecklich genehmigte Referenz ist ein zusammenhaengendes Erstgespraechs-Dashboard und keine Sammlung allgemeiner Anwendungskacheln. Eine eng begrenzte Ausnahme bildet diese Hierarchie originalgetreu ab, ohne Data Hub, Work, Result DB, Pathfinder oder Shell visuell zu veraendern. | +| 2026-09-07 | Die Nutzerpraezisierung erweitert die unmittelbar folgende Positionsentscheidung: `Source: Scan` ist eine workspaceweite Navigationsfacette mit stabiler ID und vollstaendiger Optionsliste aus dem projektweiten All-Records-Blatt. Eine Auswahl aus einem dedizierten GPO-/Fachblatt wechselt auf dieses Aggregat und aktiviert dort direkt den ausgewaehlten Scan; lokale Facettennachzaehlung darf die Liste nicht reduzieren. | Der Filter soll nicht nur die aktuell sichtbaren Records einschraenken, sondern jederzeit den direkten Wechsel zu jedem geoeffneten Scan ermoeglichen. Nur die projektweite Quelle und ein positionsunabhaengiger Identifikator verhindern, dass ein Fachblatt alle anderen Scanner aus der Auswahl verliert oder der gesetzte Filter beim Blattwechsel unbrauchbar wird. | +| 2026-09-14 | Eine eindeutige `Source: Scan`-Auswahl ist auf dem projektweiten All-Records-Blatt ein bindender Werkzeugkontext. Fuer GPOs gelten dort derselbe Facetten- und Statusvertrag wie auf dem dedizierten GPO-Blatt; die Kontextreduktion geschieht vor allgemeiner Priorisierung und Facettenlimit, ungueltige Altfilter werden entfernt. Dokumentierte Nutzerentscheidungen sind Abnahmekriterien; ein Konflikt mit Projektregeln ist vor der Umsetzung zu melden und darf nicht still umgangen werden. | Eine reine Datensatzfilterung bei unveraendertem Mischprofil zeigt fachfremde Scannerfilter und kann unsichtbare Fremdfilter aktiv lassen. Der Kontext muss deshalb die angebotene und wirksame Filtermenge bestimmen. Transparente Konfliktmeldung erhaelt die Nachvollziehbarkeit bindender Vereinbarungen. | +| 2026-09-07 | `Source: Scan` ist ein permanenter Provenienzfilter jeder Work-/Graph-Ansicht und steht stets als letzter Filter ganz rechts. In der reinen GPO-Ansicht ruecken die fachlichen Filter linksbuendig zusammen; deren sichtbares Limit betraegt elf statt zehn, damit Status, neun GPO-Fachfacetten und die Source-Facette gleichzeitig erhalten bleiben. Ein fehlendes explizites Source-Feld wird praesentativ aus Scan-/Profilmetadaten ergaenzt. | Die Quellenherkunft muss unabhaengig vom aktiven Werkzeug jederzeit auffindbar und an einer stabilen Position bedienbar sein. Einwertige Source-Werte sind fuer Provenienz weiterhin relevant und duerfen weder durch die allgemeine Nuetzlichkeitspruefung noch durch das Facettenlimit verschwinden. | +| 2026-09-07 | Kunden sichtbare GPO-Quellen zeigen ausschliesslich die interne Referenz ab GPO-GUID beziehungsweise `DomainSysvol/GPO`; jeder lokale oder artefaktbezogene Praefix wird in der Praesentationsschicht entfernt. Quellen stehen unmittelbar als technische Pfadzeilen in der Evidence-Zelle, ohne aufklappbaren `Show source`-Zwischenschritt und ohne doppelte Textueberschrift. Nicht eindeutig sanitisierbare Pfade werden nicht teilweise angezeigt. | Lokale Ablage- und Backupordner sind fuer die fachliche Kundenbewertung irrelevant und koennen interne Namen offenlegen. Die GPO-GUID plus interner Policy-/Datei-Locator reicht fuer eindeutige, kundenfaehige Evidenz; fail-closed Reduktion verhindert versehentliche Preisgabe bei unbekannten Pfadformen. | +| 2026-09-07 | GPO-Duplicates folgen derselben vierstufigen Results-Lesepipeline wie Conflicts, verwenden aber `Observed value` mit genau einer gemeinsamen Wertzeile und einen informativen Duplicate-Hinweis. Dieser Hinweis behauptet weder Fehler noch Unbedenklichkeit, sondern ausschliesslich: identische Quellenbelegung und fuer sich allein keine Baselineabweichung. | Gleiche Informationsarchitektur macht Conflict und Duplicate vorhersehbar bedienbar. Die getrennte Semantik verhindert zugleich, dass reine Quellenredundanz als Fehlkonfiguration erscheint oder eine gegebenenfalls separate Baselineauswertung verdeckt. | +| 2026-09-07 | Die GPO-Conflict-Erklaeransicht folgt verbindlich der Reihenfolge Ursache, betroffenes Setting, beobachtete Varianten und technische Details. Varianten erscheinen in einer gemeinsamen Tabelle statt in Einzelkarten. Diese Nutzerkorrektur ersetzt fuer die Primaerdarstellung die unmittelbar folgende Kartenentscheidung; deren neutrale Semantik, Quellbindung, exakte Leer-/Whitespacewerte und sicherer Fallback bleiben erhalten. | Die Leserin soll zuerst verstehen, warum ein Konflikt vorliegt, danach den betroffenen Registrykontext erkennen und erst anschliessend die Werte zeilenweise vergleichen. Eine gemeinsame Tabelle bietet bei drei oder mehr Varianten die bessere Scan- und Vergleichbarkeit; technische IDs bleiben letzte Detailstufe. | +| 2026-09-07 | GPO-Konflikte verwenden in Results eine erklaerende Variantenprojektion statt zweier primaerer Evidenztabellen. Jede Variante bleibt neutral, bindet ihre Quellen direkt und zeigt leere beziehungsweise reine Whitespace-Werte explizit; wirksame GPO-Praezedenz wird nicht behauptet. Vollstaendige technische Pfade und IDs bleiben eingeklappt verfuegbar, die alte Tabellenprojektion bleibt sicherer Fallback. | Die primaere Nutzerfrage ist, welche Werte sich widersprechen und durch welche Quellen sie belegt sind. Generische Tabellen wiederholten Kontext, machten leere Werte unsichtbar und zwangen zum Querlesen technischer IDs. Progressive Disclosure verbessert die Erklaerung, ohne Evidenz zu normalisieren, einen Gewinner zu erfinden oder die bestehende Vergleichs-/Persistenzgrenze zu veraendern. | +| 2026-09-03 | Die verbindliche Client-Info-Startansicht expandiert nur `Assessment Status`; alle neun anderen Informationskarten starten minimiert. | Der Gesamtstatus bleibt ohne Interaktion sichtbar, waehrend die darunterliegende feste 3/2/2-Matrix und die rechte Rail als kompakte, stabile Navigation beginnen. Inhalte werden nicht entfernt und bleiben ueber die Standarddreiecke einzeln erreichbar. | +| 2026-09-03 | Minimierte Client-Info-Karten bleiben ueber die volle Breite ihrer festen Spalte gespannt. `Directory Overview` zeigt keine werkzeugspezifische PingCastle-Engine-Version mehr. | Collapse soll ausschliesslich die Hoehe reduzieren und darf die stabile Spaltengeometrie nicht veraendern. Die Directory-Karte beschreibt den Verzeichniszustand; eine Scanner-Engine-Version gehoert nicht zu diesem fachlichen Ueberblick und bleibt nur in der unveraenderten Provenienz erhalten. | +| 2026-09-03 | Das Client-Info-Hauptraster verwendet drei feste Karten-Spalten mit der dauerhaften Zuordnung 3/2/2 und keine dichte Masonry-Neuverteilung mehr. Collapse veraendert nur die Hoehe innerhalb derselben Spalte. Die Desktop-KPI-Matrix streckt ihre sechs Karten auf die Hoehe von `Assessment Status`; ihre feste Reihenfolge ist Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections. Nur Deviation und High Severity sind Filteraktionen. | Die ausdrueckliche Nutzeranforderung priorisiert stabile raeumliche Orientierung gegenueber global maximaler Verdichtung. Feste Spalten verhindern Positionswechsel beim Minimieren und Maximieren; die gemeinsame Kopfhoehe beseitigt die grosse Leerstelle. Begrenzte Klickziele vermeiden versehentliche Filterwechsel, waehrend die staerkere Compliance-Hierarchie den wichtigsten Gesamtwert hervorhebt. Diese Entscheidung supersediert die unmittelbar folgende Masonry-Entscheidung. | +| 2026-09-03 | Rohe aktuelle GPO-Policy-Beobachtungen werden als eigener Unified-Result-Quelltyp `policy-observation` timeslotgebunden in Result DB und Work dargestellt. Sie sind Kontext-/Reviewdaten mit nicht anwendbaren Finding-Achsen und werden niemals allein durch die Sichtprojektion zu Abweichungen oder Findings. Diese Nutzerkorrektur supersediert fuer die gemeinsame Work-Ansicht die unmittelbar folgende fruehere Beschraenkung von `Source: Scan`: Dort erscheint nun auch `Group Policy`; im Data-Hub bleibt das Backup weiterhin kein auswaehlbarer Scanner-Run. | GPO-Inhalte muessen nach dem Import konkret auffindbar und exportierbar sein, auch solange Identity-, Baseline- oder Risikokataloge noch keine bestaetigte Abweichung erlauben. Die getrennte Quellart schliesst die Sichtbarkeitsluecke, ohne die konservative Finding-Factory-Grenze aufzuweichen. | +| 2026-09-03 | GPO-Backups verwenden im Timeslot keine Scanner-Auswahlbox. Eine eigene Quellenmarkierung und `View` oeffnen die projektgebundene Policy-Analyse; `Source: Scan` bleibt ausschliesslich der Provenienzfilter fuer Scanner-Runs. | Ein GPO-Backup ist verarbeitbare Policy-Evidenz, aber kein kanonischer Scanner-Run. Eine deaktivierte Checkbox suggeriert fehlende Berechtigung oder Nichtauswaehlbarkeit, waehrend eine explizite Anzeigeaktion die vorhandenen Analysedaten erreichbar macht, ohne GPO-Evidenz faelschlich in den Scanner-Scope umzudeuten. | +| 2026-09-03 | GPO-Backups werden im Data-Hub-Timeslot als eigene Quellen neben Scanner-Reports dargestellt. Ordnerauswahl und vorhandenes ZIP sind getrennte UI-Wege, verwenden aber dieselbe projekt- und timeslotgebundene Backend-Ingestion; nur der Ordnerweg erzeugt zuvor lokal das deterministische Transport-ZIP. | Die bislang bereits gespeicherten GPO-Quellen duerfen nicht unsichtbar bleiben oder als Scanner-Run erscheinen. Zwei eindeutige Eingaben vermeiden Missverstaendnisse, ohne die gehärtete Validierungs-, Speicher- und Jobgrenze zu duplizieren oder aufzuweichen. | +| 2026-09-03 | Ein kuratierter Policy-Evaluation-Regelkatalog wird nur aus einer lokalen regulaeren Datei geladen, wenn Pfad und erwarteter SHA-256 gemeinsam konfiguriert sind. Der Hash wird vor Parsing und fachlicher Validierung geprueft; ohne Konfiguration bleibt der eingebettete leere Freigabekatalog aktiv. | Kataloginhalte bestimmen sicherheitsrelevante Abweichungen und Severities. Eine explizite Hashbindung macht den freigegebenen Stand betriebsseitig nachvollziehbar, verhindert stillen Dateidrift und bewahrt den local-only Betrieb ohne automatischen Download oder implizite Aktivierung. | +| 2026-09-03 | Das Policy-Analyse-Readmodell fuehrt neben der unveraenderlichen Run-Historie eine explizite aktuelle Sicht. Aktuell sind nur die durch aktive Profil- und Identity-Revisionen erreichbaren Aggregationen mit jeweils ihrer neuesten Evaluation und ihrem neuesten Finding-Run; Summary, Review Queue und Folgeaktionen werden daraus abgeleitet. | Reprocessing darf alte Konflikte, Katalogluecken, Abweichungen und Findings nicht als aktuellen Kundenzustand doppelt zaehlen. Gleichzeitig muss jeder fruehere Lauf fuer Audit und Reproduzierbarkeit erhalten bleiben. Dieselbe Aktivkettenselektion fuer Anzeige und Aktionen verhindert Bedienung auf veralteten Analysestaenden. | |---|---|---| +| 2026-09-14 | Rebase-Reconciliation AI-Integration auf defender-iot: Der Result-DB-LLM-Export verwendet das versionierte, datensparsame Privacy-Safe-JSON-Schema mit anwendungsseitig berechneter Summary, vorhandenen Scanner-Regel-IDs, ausschliesslich handlungsrelevanten Findingdetails, kompakten Nicht-ausgefuehrt-Checks und gruppierten freigegebenen Environment-Fakten; er wird als einzelne Aktion `Export JSON` ueber den gemeinsamen Download-Adapter als Datei heruntergeladen. Fehlt eine Regel-ID, wird `null` exportiert. Dies supersediert die JSONL-Exportfestlegung vom 2026-09-03 als Result-DB-Ausgabeformat. | Beide Branches definierten dieselbe LLM-Uebergabe unterschiedlich. Das datensparsame, e-mail-redigierte JSON ist fuer die LLM- und Dashboard-Nutzung token-effizienter und direkt konsumierbar; der Dateidownload ersetzt den fluechtigen Clipboard-Weg und verwendet denselben Adapter wie die uebrigen Exporte. | +| 2026-09-11 | ASSESSOR erweitert den unveraenderten externen `result_type`-Katalog additiv um `vulnerability_finding`. Defender-for-IoT-CVEs erhalten bei fehlendem Quellstatus deklarativ `outcome=warning`; sie sind damit Abweichungen, bleiben aber `is_ioe=false`. `environment-observation` bleibt eine Herkunftsart mit `result_type=informational`. | Eine konkrete CVE auf betroffenen Devices ist weder Compliance-Check noch Policy-Abweichung oder blosse Inventarinformation. `exposure_finding` wuerde die vorhandene Exposure-State-/IOE-Semantik unnoetig auf Schwachstellen ausdehnen. Der eigene Typ trennt Schwachstellenbefund, Dringlichkeit und bestaetigte Exposure weiterhin sauber. | +| 2026-09-10 | NVD `configurations` bleiben als top-level Konfigurationsgruppen erhalten. Vulnerable CPE-Matches bilden die betroffene Software je Gruppe; nicht vulnerable Matches derselben Gruppe werden getrennt als `Running on/with` gespeichert und dargestellt. Das Enrichment-Recordformat ist dafuer Version 2; Version-1-Flachsaetze bleiben lesbar, muessen fuer die verlustfreie Gruppierung aber erneut von NVD abgerufen werden. | Die NVD-Oberflaeche und API beschreiben eine logische Konfiguration aus betroffener Software und ihren Laufzeit-/Hardwarebedingungen. Ein flaches Match-Array ueberzaehlt Konfigurationen und verliert genau diese Beziehung. Die Gruppierung muss deshalb vor der Persistenz im externen Referenzadapter erhalten werden. | +| 2026-09-10 | CVE-Enrichment ist ein globaler, nach normalisierter CVE-ID identifizierter Referenzbestand und weder Bestandteil der tenant-/timeslotgebundenen FindingOccurrence noch der werkzeuggebundenen, durch Reimport ersetzbaren FindingDefinition. Defender-Import und NVD-Enrichment bleiben getrennt; nur eine ausdrueckliche Aktion fuer eine bereits gespeicherte Defender-CVE darf den festen NVD-Endpunkt abfragen. | Beschreibung, CVSS-Metriken, CWE, Referenzen und betroffene Konfigurationen beschreiben die CVE selbst. Ein gemeinsamer Datensatz vermeidet redundante, auseinanderlaufende Kopien und macht vorhandene Anreicherung fuer spaetere Mandanten automatisch wiederverwendbar, waehrend der Import ohne Netzabhaengigkeit reproduzierbar bleibt. | +| 2026-09-03 | Das Client-Info-Hauptraster verwendet eine Progressive-Enhancement-Masonry-Berechnung auf Basis real gemessener Kartenhoehen. Erst nach erfolgreicher Messung aktiviert es feine 1-px-Tracks und dichten Auto-Flow; ResizeObserver aktualisiert die Spannen bei Collapse, Inhalts- und Breitenwechseln. Zustandsbuttons verwenden das gemeinsame `TriangleIcon` unten/rechts. | Ein regulaeres CSS Grid reserviert pro Zeile die Hoehe der groessten Karte und kann kuerzere geschlossene Karten nicht unabhaengig nach oben packen. Die gemessene Span-Berechnung ermoeglicht echtes Nachruecken, waehrend das vor der Messung aktive Standardraster einen sicheren Fallback ohne Ueberlagerung bildet. Gemeinsame SVG-Dreiecke sind schrift- und kodierungsunabhaengig und entsprechen der bestehenden App-Konvention. | +| 2026-09-03 | Die Environment-Fakten `Marked findings`, AD Recycle Bin, Backup/krbtgt, LAPS, WEF und OS bilden eine eigene Client-Info-Kachel `Infrastructure Details`; `Infrastructure & Resilience` bleibt eine reine Mengen-/Risikokarte. Beide verwenden denselben gemeinsamen minimierbaren Kartenvertrag. | Risikoindikatoren und beschreibende Infrastrukturwerte sind zwei unterschiedliche Informationsarten. Eine eigene Kachel bewahrt die luftige Faktengeometrie, verhindert eine ueberlange Mischkarte und laesst beide Gruppen unabhaengig minimieren, ohne ihre gemeinsame Snapshotquelle zu veraendern. | +| 2026-09-03 | Maester-`Invoke-MgGraphRequest`-Ausfuehrungsfehler erhalten eine additive strukturierte Praesentation mit Primaermeldung, technischen Schluesselfeldern und standardmaessig eingeklapptem vollstaendigem Rohtext. Die Erkennung und Extraktion liegt in einem reinen werkzeugspezifischen Parser ausserhalb der React-Komponente; nicht erkannte Texte fallen verlustfrei auf die bestehende Rich-Text-Darstellung zurueck. | Lange PowerShell-/HTTP-/JSON-Ketten sind in einer Fliesstextzeile nicht diagnostizierbar. Die Trennung hebt die handlungsrelevante Graph-Ursache hervor, bewahrt Request-Korrelation und Originalbeleg und haelt source-spezifische Interpretation aus der allgemeinen Darstellungskomponente heraus. | +| 2026-09-03 | Alle neun Client-Info-Informationskacheln verwenden einen gemeinsamen vollstaendig minimierbaren Interaktionsvertrag: initial geoeffnet mit Minus, minimiert ausschliesslich die Kopfzeile mit Plus und intrinsischer Kopfzeilenhoehe, erneut geoeffnet mit vollstaendigem Inhalt. Die sechs reinen Zahlenkacheln bleiben nicht minimierbar und unveraendert. | Der vorherige Schalter veraenderte bei den sechs Mengen-/Faktenkarten nur optionale Zusatzangaben und fehlte bei Donutkarten teilweise, obwohl die Bedienung als Minimieren verstanden wird. Ein identischer Vertrag fuer beide gemeinsamen Kartenkomponenten plus ein explizites `align-self: start` im minimierten Zustand verhindert wirkungslose Schalter und leere, auf Nachbarhoehe gestreckte Karten. | +| 2026-09-03 | Die neueste bildlich bestaetigte Nutzerreferenz ersetzt den unmittelbar zuvor festgelegten minimierten Mengenbalken: Alle neun Client-Info-Infopanels zeigen minimiert nur `Titel — Primaermenge` und Plus. Expandiert verwenden alle mengenbezogenen Inhalte hohe Zeilen mit breitem 72-px-Mengenbalken; Assessment und Severity werden nicht mehr als Donut dargestellt. Faktenzeilen nutzen dieselbe luftige Vertikalordnung. Die sechs Zahlenkacheln bleiben unveraendert. | Der Balken ist Detailinhalt und darf die minimierte Uebersicht nicht erneut verdichten. Eine einheitliche expandierte Zeilengeometrie setzt die Referenz ueber alle Infopanels um, bewahrt reale Werte und vermeidet sowohl erfundene Verlaeufe als auch lokale kompakte Sonderlayouts. | +| 2026-09-03 | Die abschliessende Nutzerreferenz supersediert die unmittelbar vorherige reine Collapsed-/Expanded-Geometrie: Sechs Zahlenkacheln stehen oben; sechs Mengenpanels bleiben darunter permanent als dreispaltige Uebersicht sichtbar. Plus/Minus betrifft nur Zusatzdetails. Assessment und Severity bleiben Donut-Kacheln in einer rechten Nebenspalte, Directory Overview folgt dort als Faktenkarte. | Das Zielbild zeigt die Mengenzeilen bereits bei einem Pluszustand und fordert die Donuts ausdruecklich daneben. Eine getrennte Hauptmatrix und Verteilungsspalte bildet diese Hierarchie direkt ab, ohne reale Kennzahlen zu verbergen oder Donutverteilungen in Mengenbalken umzudeuten. | +| 2026-09-03 | Die Kopfzone von Client Info verwendet dasselbe 3:1-Verhaeltnis wie Hauptmatrix und rechte Rail: sechs verkleinerte quadratische Kennzahlen links, `Assessment Status` rechts in derselben ersten Reihe. | Der erste Donut soll ohne eine neue Zwischenreihe direkt neben den Zahlenkacheln stehen. Die gemeinsame Spaltenteilung richtet Kopf- und Inhaltszone aus und laesst die verbleibenden Rail-Karten automatisch nachruecken. | +| 2026-09-03 | `Open Client` aktiviert nach Uebernahme des Projekt-/Timeslot-Scope standardmaessig den Hauptbereich `Client Info`; `Work` bleibt eine anschliessend bewusst waehlbare Ansicht. | Die Client-Informationsansicht ist der vereinbarte Einstieg in einen geoeffneten Mandanten. Der Scopewechsel und die Wahl des ersten Darstellungsbereichs bleiben getrennte Verantwortlichkeiten. | +| 2026-09-03 | Ein expandiertes Client-Info-Infopanel belegt regulaer sechs Rasterspalten und an den Breakpoints die komplette verfuegbare Rasterbreite; minimiert bleibt es zwei Spalten breit. Der Kopf-Primaerwert wird im Body nicht wiederholt; neutrale Mengenserien verwenden die referenzierte ordinale Farbfolge. | Die Referenz besitzt eine breite linke Label-/Wertzone und eine ebenso breite rechte Visualisierungszone. Diese Geometrie ist in einer nur zwei Spalten breiten Karte nicht darstellbar und fuehrt zum sichtbaren Ueberlauf der Mengenbalken. Das Entfernen der ersten Doppelzeile stellt zugleich die Informationshierarchie und die vier sichtbaren Referenzreihen wieder her. | +| 2026-09-03 | Die ausdrueckliche AMD-Adrenalin-inspirierte Nutzerreferenz ersetzt den frueheren Quadratvertrag ausschliesslich fuer die neun Client-Info-Detailkarten. Diese starten kompakt mit einer Primaermenge und einem Mengenbalken; Plus/Minus steuert die vollstaendigen bisherigen Details je Karte. Die sechs Zahlenkacheln bleiben unveraendert quadratisch. | Progressive Disclosure erhoeht die Uebersicht, ohne Daten zu entfernen. Mengenbalken stellen den aktuellen Umfang korrekt dar, waehrend erfundene Verlaufsgraphen ohne Zeitreihe eine nicht vorhandene Entwicklung suggerieren wuerden. Die Trennung bewahrt die bestaetigte Zahlenzeile und macht alle real vorhandenen Detailbereiche bedarfsgesteuert erreichbar. | +| 2026-09-03 | Die responsive Nutzerkorrektur ersetzt die unmittelbar zuvor festgelegten drei Rasterzeilen: Client-Info-Rasterzeilen verwenden eine breakpointabhaengige Mindestgroesse mit inhaltsbasiertem Auto-Wachstum. Inhaltskarten sind mindestens quadratisch und wachsen bei Bedarf; `Infrastructure & Resilience` besitzt eine automatische Inhaltshoehe. | Eine feste Zahl von Rasterzeilen ist kein responsives Verhalten und kann bei anderer Breite oder Datenmenge erneut zu viel oder zu wenig Platz liefern. Inhaltsbasierte Trackgroessen reagieren sowohl auf den Viewport als auch auf die tatsaechlichen Werte, ohne Clipping oder starre Leerflaeche. | +| 2026-09-03 | Die inhaltsreiche Dashboardkachel `Infrastructure & Resilience` belegt drei Rasterzeilen und hebt ausschliesslich fuer sich das starre Quadratverhaeltnis auf; alle anderen Client-Info-Karten behalten die gemeinsame quadratische Geometrie. | Die vollstaendige dynamische OS-Liste darf weder abgeschnitten werden noch aus der Kachel herauslaufen. Eine gezielte Hoehenerweiterung bewahrt die bestehende Faktenstruktur und den dichten Gesamtrastervertrag, ohne andere Karten unnoetig zu vergroessern. | +| 2026-09-03 | Regulaere Work-Finding-Kacheln besitzen eine feste Inhaltsbreite von 358 px und eine Mindesthoehe von 223 px; sie duerfen fuer vollstaendigen Inhalt nach unten wachsen. Die Metadatenreihenfolge ist Status, Kategorie, Severity/Weight und Score. Pathfinder-Micro-Cards behalten ihre eigenstaendige kompakte Geometrie. | Das freigegebene Referenzformat muss die untere Groessengrenze jeder Matrixkachel bilden. Eine feste Breite verhindert das Aufziehen der letzten Reihe; eine Mindest- statt Fixhoehe bewahrt lange Titel und Metadaten ohne Clipping. Die semantische Badge-Matrix erzeugt unabhaengig von der Datensatzkombination dieselbe Lesereihenfolge. | +| 2026-09-03 | Die Result DB verwendet `Deviation = Yes` als initialen und durch `Reset filters` wiederhergestellten Arbeitszustand. Ihr LLM-Export ist versioniertes JSONL: ein Manifest mit aktivem Timeslot-/Projekt-Scope und allen Nutzerfiltern, danach eine Zeile pro vollstaendigem Unified Result. | Abweichungen sind die primaere Analysemenge. JSONL bewahrt verschachtelte Evidenz und Provenienz, bleibt an Datensatzgrenzen teilbar und ist fuer LLM- sowie maschinelle Weiterverarbeitung robuster als eine flache CSV- oder unstrukturierte Markdown-Ausgabe. Der Manifest-Snapshot macht die exportierte Auswahl reproduzierbar. | +| 2026-09-03 | Balkenlisten in den quadratischen Client-Info-Karten verwenden dieselben drei Spalten fuer Label, Track und Wert sowie eine stets reservierte zweite Wertzeile fuer optionale Quellenhinweise. Zahlen und Einheiten bleiben in einer nicht umbrechenden Wertgruppe; die Resilience-Kompaktkarte ueberschreibt diesen Vertrag lokal mit ihrer bestehenden Einspaltenanordnung. | Eine optionale Zusatzzeile darf weder die Hoehe einzelner Eintraege noch Track- oder Wertbreiten zwischen gleichartigen Karten veraendern. Gemeinsame Spaltenrollen machen die Werte visuell vergleichbar, ohne Daten oder Kartenstruktur umzudeuten. | +| 2026-08-26 | Ein Policy-Evaluation-Regelkatalog darf den Status `released` nur tragen, wenn seine Runtime-Vertraege geschlossen validiert sind und fuer dieselbe technische Identitaet, denselben Auslieferungsmechanismus und ueberlappende Produkt-/Versions-/Rollen-/Scope-Kontexte hoechstens eine Regel aufloesbar ist. Wiederverwendete Risiko- und Abhaengigkeits-IDs muessen katalogweit dieselbe Definition besitzen. | Der kuenftige fachlich kuratierte Katalog wird an einer sicherheitsrelevanten Finding-Grenze ausgefuehrt. TypeScript-Typen allein schuetzen weder geladene noch historisch persistierte Runtime-Daten; Mehrdeutigkeit oder unbekannte Enumwerte muessen deshalb vor jeder Freigabe fail-closed blockieren. | | 2026-08-25 | Die appweite persistente Markierungs- und Auswahlfarbe ist auf ausdrueckliche Nutzerfestlegung immer Gelb und wird in beiden Themes ueber `--marking-color` gefuehrt. Kachelauswahl, Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl verwenden diesen Token. Blau bleibt Tastaturfokus; Gruen, Rot, Orange und Severitytoene bleiben fachliche Statussignale. | Ein einzelner semantischer Markierungston verhindert violette oder skinabhaengig wechselnde Auswahlkonturen wie im Datahub-Screenshot und bewahrt gleichzeitig die Bedeutung bestehender Statusfarben. | | 2026-08-25 | Die unmittelbar zuvor fuer Client Info festgelegte flache SOC-Kachel ist auf ausdrueckliche Nutzerfestlegung der neue appweite Kachelstandard: keine sichtbare Normalzustandskontur, kein Radius und kein Schatten; Hover veraendert nur die Flaeche. Fokus, Auswahl und kleine Statusakzente bleiben funktionale Ausnahmen. Die gemeinsamen `--tile-*`-Tokens und Projektregeln tragen diesen Vertrag. | Ein zentraler Standard verhindert, dass neue oder bestehende Ansichten erneut weisse Konturen, Rundungen oder schwebende Schatten einfuehren. Flaechenkontrast und gemeinsamer Abstand erzeugen die gewuenschte ruhige, dichte SOC-Geometrie. | | 2026-08-25 | Das quadratische Client-Info-Raster uebernimmt die flache Kartenoberflaeche der Nutzerreferenz: regulaere Kennzahl- und Inhaltskacheln haben keine Aussenkontur, keinen Schatten, den zentralen Nullradius und keine dekorative Trennlinie unter dem Kartentitel. Farbige Fokus- und Auswahlkonturen bleiben als funktionale Zustaende erhalten. | In der Referenz werden Karten allein durch Flaechenkontrast und dunkle Zwischenraeume getrennt. Die bisherige helle Kontur, Rundung und Schattenkante erzeugten eine abweichende, unruhige zweite Geometrieebene. | @@ -1598,6 +2385,16 @@ Abnahme 2026-08-23: 677 Standardtests bestanden, 8 optionale PostgreSQL-Integrat ## 10. Offene Entscheidungen +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. + +Timeslotvergleich 2026-09-11: P0/P1 muessen pro Scanner/Format/GPO die belastbaren Objekt-/Scopefelder, Vergleichsgranularitaet und Negativnachweisfaehigkeit sowie die konkrete Reimportbetroffenheit bestimmen. Speicher-/API-Vertrag und Uebergang fuer offene Verpflichtungen und auditierte Scopeentscheidungen sind vor Migration festzulegen. Native Teilpopulationen duerfen nur mit separat belegten Beitraegen verglichen werden; ein zusaetzlicher risikogewichteter Expositionsindex ist nicht freigegeben. Siehe Detailentscheidungen in [TIMESLOT_COMPARISON_PLAN.md](TIMESLOT_COMPARISON_PLAN.md). + +Accepted-Risk-Entscheidung 2026-09-10: Der Nutzer hat keine bestehenden Freigaberegeln und beauftragt einen Best-Practice-Ausgangspunkt. Getrennter Risk Owner/Genehmiger, belegte externe Zustimmung, Befristung und Wiedervorlage sind Pflicht fuer eine Annahme. Es wird keine unbelegte allgemeingueltige Hoechstlaufzeit vorgegeben. Die lokale Ablage erfolgt additiv in `assessor_reviews.data.riskAcceptance` mit append-only Versionssnapshots. Fuer Phase 14 sind SSO-gebundene Akteure, kundengebundene Rollen, normalisierte Entscheidungs-/Versions-/Freigabe-/Evidenztabellen, manipulationsnachweisbare Aufbewahrung und serverseitige Fristenueberwachung vorgesehen; Umsetzungskriterien stehen in `docs/RISK_ACCEPTANCE.md`. Keine organisatorische Freigabe oder rechtliche Wirksamkeit wird aus einem ausgefuellten Formular abgeleitet. + +Festgelegte Versionsentscheidung vom 2026-09-06: Die sichtbare ASSESSOR-Version ist die eigenstaendige Produktversion und wird nicht aus Parser-, Mapping-, Processing- oder GPO-Evaluatorversionen abgeleitet. `2.5.1` bezeichnet den aktuellen Produktstand; technische Komponentenstaende bleiben im About-Popup und in der Ergebnisprovenienz getrennt sichtbar. Produktversionen folgen Semantic Versioning: Patch fuer kompatible Korrekturen, Minor fuer neue kompatible Funktionen, Major fuer bewusst inkompatible Produkt- oder Datenvertragswechsel. + +Festgelegte Fachentscheidung vom 2026-09-06: Ein GPO-Benchmark darf nur dann `Passed` oder `Failed` liefern, wenn die passend ausgewaehlte Microsoft-Security-Baseline einen vorhandenen und technisch vergleichbaren Sollwert vorgibt. Kundenwerte ohne Microsoft-Sollwert werden nicht als Abweichung gewertet; leere Sollwerte entfallen, nicht unterstuetzte Sollwerte bleiben Review/Warning. Die spaetere optionale Darstellung reiner Kundenkonfigurationen als Info bleibt offen. + - 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 @@ -1615,8 +2412,155 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode ## 11. Risiken +ISO-Frontend-Upload 2026-09-23: Der Token ist keine persoenliche Identitaet, Rolle oder allgemeine Sitzungsberechtigung; ein kompromittierter Token erlaubt bis zur Rotation eine globale Korpusneuerstellung. Der serverseitige Worker, Groessenlimits, private Quelle, keine Download-API und die Aktivierung nach erfolgreichem Ingest begrenzen die technische Wirkung. Der Embedding-Gateway erhaelt lizenzierten Kontrolltext und unterliegt seiner freigegebenen Aufbewahrungspraxis. Ein Prozessabbruch markiert den Job nach Neustart als fehlgeschlagen und entfernt temporaere PDFs; ein teilweise geschriebener neuer Qdrant-Index bleibt abgeleitet und kann per erneutem Frontend-Upload repariert werden. Der Betrieb mit mehreren gleichzeitig schreibenden App-Instanzen ist durch diesen Dateistatus nicht abgesichert; der aktuelle Compose-Stack startet genau eine. Reale DIN-PDFs, Gateway und Ziel-Qdrant wurden in dieser Implementierung nicht beruehrt. + +Regulatory RAG 2026-09-15: Regulatorische Texte koennen urheber-, lizenz- oder versionsgebunden sein; ein technisch lesbarer Korpus ist deshalb noch kein freigegebener Produktkorpus. Lokale llama.cpp-Embeddings bleiben auf Loopback, waehrend minimierte Querytexte bei einem spaeteren Work-LiteLLM-Vergleich die ASSESSOR-Prozessgrenze verlassen. Gegenmassnahmen sind ein autorisierter versionierter Korpus, explizite Modell-/Dimensionsbindung, Backend-only Secrets, Remote-HTTPS, begrenzte Requests und der implementierte fail-closed Public-Signal-Query-Builder; organisatorische Datenschutzfreigabe bleibt fuer externe Ziele erforderlich. Dense Similarity ist nur Kandidatenranking und weder Kontrollzuordnung noch Confidence; vor automatischer Nutzung sind reale sprachuebergreifende Evaluation, Hybrid-/Reranker-Vergleich, Schwellenkalibrierung und Human Review erforderlich. Qdrant-Dokumentersatz ist nicht transaktional mit einem Embeddingdienst; Fehler koennen einen unvollstaendigen abgeleiteten Index hinterlassen, der aus dem unveraenderten Korpus neu aufgebaut werden muss. Das Volume ist Betriebsbeschleunigung, keine fachliche Sicherung. Der autorisiert geloeschte alte Qdrant ist entfernt und 1.19.1 belegt kanonisch Port 6333; das alte Volume bleibt vorsorglich erhalten. Der lokale BGE-M3-End-to-End-Smoke-Test war mit drei klar getrennten Themen perfekt, ist statistisch und fachlich aber nicht repraesentativ. Ein kuratierter lizenzierter Korpus, schwierigere Negativ-/Mehrfachkontrollfaelle, unabhaengige Labels und der LiteLLM-Vergleich bleiben offen. + +Retrieval-Gap-Benchmark 2026-09-17, korrigiert 2026-09-18: Die zehn PingCastle-Faelle und 17 Sollbeziehungen stammten aus derselben manuellen Validierungsrunde, die die Luecken identifiziert hatte; Recall@12 1,0 auf diesem Satz belegte nur die konkrete Reparatur und war wegen Auswahl- und Konzeptkurationsbias kein unabhaengiger Gesamtqualitaetsnachweis. Auf ausdrueckliche Nutzerentscheidung wird dieser fachlich veraenderliche Satz nicht als feste Regression ausgefuehrt. Sollzuordnungen bleiben Human-Review-/Evaluationsdaten; die verpflichtende Suite prueft ausschliesslich regulationsunabhaengige Retrievalmechanik. + +Retrieval-Gesamtbenchmark 2026-09-17: Der nachtraegliche Abgleich aller 37 Findings belegte die Auswahlverzerrung des reinen Gap-Satzes: v1.2 traf dort `17/17`, verschlechterte ueber alle 78 erwarteten Beziehungen jedoch v1.1 von `61/78` auf `54/78`. Die generisch reservierte v1.3-Zusammensetzung erreicht `68/78` (`87,2 %`), wurde aber auf demselben PingCastle-Satz ausgewaehlt und kann deshalb ueberangepasst sein. Gegenmassnahmen sind die harte Abhaengigkeitsfreiheit vom Topic-Katalog, ein Unknown-Scanner-Vertrag, unveraendertes Human Review sowie als naechster Qualitaetsschritt ein separat gelabelter Multi-Scanner-Satz mit direkten, unterstuetzenden und bewusst nicht relevanten Controls. Candidate Recall darf weder als Mapperpraezision noch als Annahmequote oder Compliancebewertung ausgegeben werden. + +Work-LiteLLM 2026-09-14: Der Unternehmensgateway ist eine ausdruecklich freigegebene externe Vertrauensgrenze und kann Requests gemaess eigener Betriebsrichtlinie routen oder protokollieren; ASSESSOR kann diese Aufbewahrung nicht kontrollieren. Die API sendet deshalb nur den vorhandenen Privacy-Safe-Export nach explizitem Nutzerklick, nie Rohdateien, Reviews, Quelltabellen oder Storage Keys. Gatewayausfall, Modellwechsel oder ungueltige JSON-Ausgabe lassen den bisherigen erfolgreichen Run unveraendert und erfordern eine bewusste neue Generierung. Der synthetische Workstation-Connectivitycheck erreichte die konfigurierte URL, erhielt aber HTTP 401; Keyaktivierung, Berechtigung oder Gatewaykonfiguration muessen betrieblich geklaert werden, ohne Secrets oder Providerbody offenzulegen. Migration 024 ist in diesem Lauf mangels Docker weder auf den kanonischen lokalen Datastore angewandt noch per PostgreSQL-Integration verifiziert; vor Anwendung bleiben verifiziertes Backup und erfolgreicher synthetischer Workstation-/Server-Liveaufruf verpflichtend. + +- 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. + +- 2026-09-23, Environment-Unterabschnitte: Ein generischer Tabellenname und eine darueber stehende Abschnittsueberschrift beweisen nicht dieselbe fachliche Gruppe. Nur ein eindeutiger, exakt quellengebundener Unterabschnitt benennt die Tabelle neu; bei Konflikten bleibt ihr nativer Name stehen. Eine aus dem ersten Unterabschnitt uebernommene breite Abschnittsbeschriftung darf nicht andere Tabellen falsch vereinnahmen. Die synthetischen Regressionen sichern den Klickpfad, Dateiscope und Konfliktfall; realer Kundenscope wurde nicht gelesen. Schmale Fenster behalten interne horizontale Tabellenbewegung ohne Abschneiden von Spalten. + +- 2026-09-23, vertiefte Environment-Results: Ein Scannerabschnitt kann mehreren fachlichen Kacheln dienen oder nicht eindeutig zuordenbar sein. Mehrfachsicht ist erlaubt; unbekannte Abschnitte bleiben garantiert in Source Overview statt unter einer erfundenen Kategorie. Tabellen-/Abschnitts-/Beobachtungsseiten werden nur im geoeffneten Fenster aufgebaut und schrittweise erweitert, ohne Originalwerte zu kuerzen. Die Ansicht ist intern und uebernimmt keine Freigabegrenze der LLM-faehigen Result DB. Datenfehler oder fehlender Snapshot werden sichtbar gemeldet. Mit synthetischen Daten und Design-Tokens verifiziert; eine reale Light-/Dark-Abnahme darf nur im freigegebenen Dummy erfolgen und ist noch offen. + +- 2026-09-23, Environment-Detail-Results: Mehr Buttons duerfen in schmalen Kacheln weder Titel noch Aktionen abschneiden. Gemeinsame Header-/Action-Wrap-Regeln und die vorhandene interne Kachelscrollflaeche halten die Bedienung erreichbar; synthetische Interaktion und Designcheck sind bestanden, eine Live-Light-/Dark-Abnahme im freigegebenen Dummy steht noch aus. Der Fensterinhalt dupliziert nur die aktuelle Leseprojektion und darf keine zusaetzlichen Kundenattribute nachladen. + +- 2026-09-23, PingCastle-Berichtspaarung: Derselbe Dateistamm und dasselbe Berichtsdatum koennen theoretisch mehrere Importe umfassen. Widerspruechliche gleichrangige Titel werden deshalb nicht vereinheitlicht; ohne passende oeffentliche Regel-ID bleibt die Result-DB-ID aus Datenschutzgruenden leer. Die synthetischen Tests decken die HTML-Auswahl mit gepaartem XML sowie unpassende und widerspruechliche Berichte ab. Eine Abnahme im gemeldeten Kundenscope ist ausdruecklich nicht erfolgt. + +- 2026-09-23, gemeinsame Finding-Ueberschrift: Ein kanonischer Definitionstitel kann von einer konkreten Scannerdatei abweichen oder dort zusaetzliche vorkommnisspezifische Zahlen enthalten. Work verwendet ihn bewusst als gemeinsame fachliche Ueberschrift, darf den nativen Quelltitel aber nicht verlieren oder als kanonische Identitaet behandeln. Die synthetische Regression prueft deshalb beide normalen Work-Projektionen, die sichtbare native Ueberschrift und das unveraenderte Originalfeld. Datenschutzbedingte Result-DB-Redaktion bleibt eine separate Ausgabeschicht; Work uebernimmt den kanonischen Titel, nicht die externe Disclosure-Projektion. + +| Ein flaechenfuellender Mengenbalken kann in Domainnamen hineinwachsen, hinter unterschiedlich breiten Zahlen enden oder durch eine vom Overall Score abweichende Farbe eine zweite Bedeutung suggerieren. Eine Maximalwert-Normalisierung wuerde zudem keine Anteile an der Gesamtverteilung zeigen. | Ein gemeinsames Vier-Spalten-Subgrid fuer Score, laengsten Namen, Balken und breiteste Zahl verwenden. Balken bleiben mit gemeinsamem Abstand ausschliesslich in ihrer dritten Spalte, erben den am Posture-Bereich gesetzten Overall-Tone und werden gegen die Summe der angezeigten Domainmengen skaliert. Exakte Zahlen bleiben rechtsbuendig sichtbar und autoritativ; `aria-hidden`, synthetische 75/25-Regression sowie Light-/Dark-, Donutfarb-, Kanten- und Ueberlaufpruefung sichern die Grenze. | + +- 2026-09-20, Lesetypografie: Groessere 14-/16-px-Rollen koennen bei langen Werten mehr Zeilen und vertikalen Scrollbedarf erzeugen. Inhalte duerfen deshalb umbrechen oder in den bereits dafuer vorgesehenen Kacheln scrollen, aber niemals gekuerzt, ellipsiert oder wieder auf kleinere Schrift reduziert werden. Kompakte Metadatenrollen bleiben nur fuer tatsaechlich sekundaere technische Angaben zulaessig; ihre Verwendung fuer Primaerinformation waere eine Regression. +- 2026-09-20, PingCastle-OS-Zustaende: Active/Inactive und Enabled/Disabled sind getrennte Quellachsen und muessen nicht dieselbe Verteilung ausdruecken. ASSESSOR zeigt deshalb alle vier Werte unveraendert und behauptet weder eine Partition noch eine Konsistenzbeziehung zu `Devices`. Mehrere PingCastle-Berichte koennen dieselben Systeme ueberlappend inventarisieren; sie bleiben getrennte `Inventory n`-Zeilen ohne Summierung. Schmalere oder umfangreichere Tabellen duerfen innerhalb der bereits scrollbaren Kachel scrollen, aber keine Spalte abschneiden oder Werte aus Platzgruenden entfernen. +- 2026-09-20, gemischte Data-Hub-Metrikprojektion: Das vollstaendige Projektblatt kann bei grossen Timeslots merklich spaeter als die Mandantenliste bereitstehen, weil aktuelle Policy-Evaluationen und ihre autoritative Rollup-Projektion einbezogen werden. Die Statuszeile bleibt deshalb waehrend des Ladens `aria-busy`, verwirft verspätete Antworten nach einem weiteren Auswahlwechsel und zeigt niemals die vorherige Mandantenkennzahl weiter. Eine kuenftige Beschleunigung darf nur cachen oder denselben serverseitigen Projektionsvertrag bereitstellen; ein Rueckfall auf Scanner-only-Zaehlen waere fachlich falsch. Die aktuelle Live-Abnahme belegt Dummy und LSW, nicht jede denkbare Datenmenge. +- 2026-09-18, Client-Info-Designangleichung: synthetisch visuell und interaktiv in beiden Themes verifiziert, nicht als Abnahme jedes realen Datenumfangs auszugeben. Sehr lange Quellwerte muessen weiterhin umbrechen; aufklappbare Inhalte duerfen nicht zu Verlust oder Umdeutung von Evidenz fuehren. Der bestehende schmale Stapelmodus zeichnet keine waagerechten Kurven. Keine produktiven Daten oder laufenden App-/Backendprozesse wurden fuer diese Abnahme angefasst. +- 2026-09-20, Client-Info-Breitenkorrektur: Die breite Dummy-Ansicht und der gestapelte 700-px-Fallback sind verifiziert. Gleiche Zeilenhoehen koennen innerhalb der kuerzeren Kachel bewusst freie Flaeche erzeugen; ein Hoehenversatz ist jedoch ausdruecklich verboten und darf nicht erneut als Deadspace-Loesung verwendet werden. Sehr lange Accepted-Risk-Titel oder eine deutlich groessere Risikoliste koennen die linke Rail weiterhin vertikal verlaengern; Inhalte duerfen deshalb weder gekuerzt noch durch eine kleinere Schrift in die feste Breite gezwungen werden. Die Aenderung ist reine Praesentation und nimmt keine Score-, Risiko- oder Persistenzmutation vor. + +Designkonsistenz (2026-09-18): Historische assessor-ui-Assets und Archetyp-/Abnahmeskizzen enthalten ueberholte Farben, Schriftgroessen und Layoutvorschlaege. Ihre ausdrueckliche Unterordnung unter die freigegebenen Referenzen sowie das Entfernen der Kopieranleitung verhindert, dass sie erneut als aktuelle Implementierungsbasis behandelt werden. Die Verankerung allein korrigiert noch keine bestehende Client-Info-Darstellung. Deren spaetere Umsetzung benoetigt einen direkten Referenzabgleich bei normalem Zoom und eine Light-/Dark-Abnahme mit synthetischen Daten; generierte Mockups sind kein Nachweis fuer richtige Kennzahlen, Runtime-Verhalten oder bereits implementiertes Design. + +Security-Domain-Filter (2026-09-18): Die vollstaendige Auswahlliste behauptet keine vorhandenen Befunde in jeder Domain. Eine Domain mit null Treffern ergibt bewusst eine leere Ansicht; bestehende Quellen-, Status-, Such- und sonstige Filter muessen bei Bedarf vom Nutzer entfernt werden. Reine GPO-Datensaetze bleiben ausschliesslich GPO & Baseline zugeordnet. Review-only- und Einzelbefundpfade behalten ihre explizite Datensatzeinschraenkung; diese sind nicht mit dem jetzt frei wechselbaren Domain-Deviation-Drilldown gleichzusetzen. + +GPO-Zaehlerabgleich (2026-09-18): Unterschiedliche Zaehlobjekte bleiben beabsichtigt; bei unveraendertem Dummy entsprechen 127 Vergleiche genau 25 Einstellungen. Bereits geladene Ansichten koennen bis zum erneuten Laden ihren vorherigen Ergebnisbestand halten. Laufabdeckung bleibt eine Darstellungsauswahl und kein Nachweis von Baseline-Anwendbarkeit oder Endgeraetewirksamkeit. Die Gesamtsuite enthaelt eine fachfremde bestehende XML-Testannahme, die code-Tags im gesamten Reader verbietet und am vorhandenen Policy-Analyzer-Suchschluessel anschlaegt; dieser Fix veraendert weder den Reader noch diesen Test. + +Result-DB-Statusfilter (2026-09-18): Widerspruechliche explizite Kombinationen wie Passed mit Deviation Yes liefern bewusst null Treffer; beide Auswahlen bleiben sichtbar und koennen entfernt werden. Die Statusfacette zaehlt erreichbare Alternativen unter allen anderen Filtern, daher sind ihre Werte bei aktiver eigener Mehrfachauswahl keine additive Aufteilung der angezeigten Treffer. Result DB und Work behalten unterschiedliche Zaehlobjekte. Die synthetische Abnahme benoetigt keine Kundendaten. + +- Work-Baseline-Rollup (2026-09-18): Unterschiedliche fruehere lokale Bearbeitungsnotizen benoetigen eine bewusste Entscheidung fuer die gemeinsame Zeile; sie bleiben im Reader lesbar. Risikoakzeptanzen bleiben an ihrer Originalidentitaet. Der Fix ist ausschliesslich synthetisch geprueft; auf ausdruecklichen Nutzerwunsch wurden keine Kundendaten zur Laufzeit geoeffnet. Result DB behaelt absichtlich die einzelnen Paketvergleiche als Evidenz. + +Work-Listen- und Pfadtitel-Restgrenze 2026-09-18: Die Liste nutzt weiterhin eine geschaetzte Zeilenhoehe fuer die begrenzte Virtualisierung, waehrend sehr lange Titel hoeher umbrechen koennen. Der Overscan haelt die sichtbaren Knoten bereit; die beseitigten konkurrierenden Animationen und die reservierte Scrollbarspur verhindern den konkret beobachteten Auswahlversatz, sind aber noch kein gemessener variabel hoher Virtualizer. Bei kuenftig nachweisbarem Versatz waehrend rein manuellen Scrollens ist eine gemessene Hoehenkarte mit Ankerkorrektur erforderlich, ohne die verbindliche Begrenzung montierter Zeilen aufzugeben. Technische Pfade duerfen an beliebigen Zeichen umbrechen, werden jedoch nicht gekuerzt oder inhaltlich normalisiert. Der konkrete `Registry Values · MACHINE\\...`-Fall ist synthetisch im gerenderten Reader abgesichert; eine zusaetzliche Windows-UI-Sichtpruefung war in dieser Sitzung nicht verfuegbar. + +GPO-Quellverfuegbarkeit 2026-09-17: Der am selben Tag dokumentierte Drei-Versuche-/Dead-Letter-Nebenbefund ist fuer GPO-Quelldateien durch Livepruefung, Enqueue-Sperren und pruefsummengebundene Wiederherstellung adressiert. Die Statuspruefung belegt Erreichbarkeit, nicht Inhaltsintegritaet; die vollstaendige Hashpruefung bleibt am Lesen und Wiederherstellen. Ein Ordnerupload muss dasselbe unveraenderte Transportpaket reproduzieren; abweichende Bytes werden bewusst abgewiesen. Der Speicher kann zwischen Pruefung und Lesen verschwinden; deshalb bleibt der erste fehlgeschlagene Job als technischer Verlauf gespeichert, die UI zeigt Upload required. Zugriffsfehler werden nicht als Datenverlust bezeichnet. Keine automatische Suche in alternativen Speicherorten und kein Wechsel des konfigurierten Stores; PostgreSQL-Ausfuehrung hier synthetisch auf Transaktionsebene geprueft, kein Live-Datenbanktest oder Backendneustart. + +GPO-Policy-Rollup 2026-09-16: Ein konservatives Policy-Fail darf nicht mit der Behauptung verwechselt werden, ein bestimmter Server oder Client sei effektiv verwundbar; GPO-Backups belegen ohne RSoP/Effective State keine konkrete Anwendung. Umgekehrt darf ein Conflict-/Duplicate-Label keinen belegten Mitglieds-Fail verdecken. Die kuenftige Umsetzung muss Verdict und Diagnoseflags getrennt persistieren/projizieren, je technischer Policy-Identitaet exakt einmal zaehlen und mehrdeutige Anwendbarkeit als Review required halten. Bis diese Kriterien versioniert und synthetisch verifiziert sind, gilt die neue Regel als bindender Vertrag, nicht als abgenommene Laufzeitfunktion. + +GPO-Misconfiguration-Scope 2026-09-16: Der score-neutrale Ausschluss nicht konfigurierter Empfehlungen verhindert eine unbeherrschbare Baseline-Rolloutliste, bedeutet aber bewusst, dass der GPO-Score keine Aussage ueber vollstaendige Microsoft-Baseline-Abdeckung trifft. Diese Grenze muss in jeder Scoreanzeige und jedem Export sichtbar bleiben. Die Einzel-Fail-Ausnahme in Conflict-/Duplicate-Containern darf erst implementiert werden, wenn technische Identitaet und Ergebnisbeitrag dedupliziert sind; sonst koennten gleiche Quellwerte mehrfach zaehlen oder mehrdeutige Konflikte faelschlich als Fail erscheinen. Historische Evaluationen duerfen nach einer kuenftigen semantischen Umsetzung nicht ohne neue Vertragsversion und explizite Neuauswertung umgedeutet werden. + +Gemischter Work-Filterkontext 2026-09-16: GPO-spezifische Felder bleiben in den unveraenderten Datensaetzen des All-Records-Blatts vorhanden, werden bei Source All aber bewusst nicht als Facetten angeboten. Sie sind nach eindeutiger GPO-Auswahl vollstaendig verfuegbar. Neue GPO-Facetten muessen deshalb sowohl in den GPO-Vertrag als auch in die Liste der kontextgebundenen Facetten aufgenommen werden; ein fehlender Eintrag koennte sie im Mischkontext erneut sichtbar machen oder im GPO-Kontext ausblenden. Permanente Wechselregressionen begrenzen dieses Risiko. + +Work-Snapshots 2026-09-16: Gespeicherte Finding-IDs sind an den exakten Work-/Timeslot-Scope gebunden. Werden Ergebnisse in einem spaeter geladenen Verarbeitungsstand ersetzt, kann ein alter lokaler Snapshot auf nicht mehr vorhandene IDs zeigen und dadurch eine leere Ansicht ergeben; der Fix ordnet IDs nicht heuristisch neuen Findings zu. Die bestehende Scopebindung verhindert eine Anwendung auf einen anderen Timeslot. Eine kuenftige ueber Reimport stabile Snapshotmigration benoetigt eine ausdrueckliche Identitaets- und Konfliktregel. + +GPO-Varianten 2026-09-14: Pass/Fail gilt nur fuer die beruecksichtigte Baselineauswahl und importierte Backup-Konfiguration, nicht fuer einen unbekannten Geraetezielbestand oder effektive Sicherheit. Unvollstaendige Kandidatenerfassung und unbekannte strukturelle Teilanalysen verhindern belastbare Einigkeit. Bekannte wertunabhaengige ADMX-/Baseline-Domaenen-/Zeitmetadatenluecken bleiben diagnostiziert, blockieren aber technisch lesbare Werte nicht. Vor einer Aenderung bei unterschiedlichen Empfehlungen ist die passende Vorlage festzulegen. Historische Ergebnisse benoetigen nach Backendwechsel eine explizite Neuauswertung; keine reale Bestandsauswertung oder PostgreSQL-Integrationsabnahme in diesem Auftrag. + +Timeslotvergleich 2026-09-11: Der bisherige Zweilaufadapter kann Quellenidentitaet und Processingpruefungen umgehen; Regelmatches sind nicht objektgenau, und Abwesenheit wird teilweise als Behebung gewertet. Die Score-Pruefpopulation erkennt Assetwechsel nicht ausdruecklich. Teilweise Folgescans koennen alte Verpflichtungen aus der Anzeige verdraengen, ohne Originaldatensaetze zu loeschen. Deshalb keine Abnahme als belastbarer A/B-Bericht und keine blosse UI-Verdrahtung vor P2-P4. Das neue offene Arbeitspaket dokumentiert die Schutzregeln und Gegenbeispiele; alte Abschluss-/Testnotizen ersetzen diese Abnahme nicht. + +Accepted Risk 2026-09-10: Deklarierte Namen und Nachweisreferenzen sind keine authentifizierten Signaturen oder geprueften Berechtigungen. Bestehende Projektloeschung und Datenbankadministration begrenzen den Schutz der JSONB-Historie. Es gibt noch keinen unabhaengigen Archivierungs-/Legal-Hold-Vertrag und keinen Fristenbenachrichtigungsdienst. Diese Grenzen sind im Dialog und in `SECURITY.md` dokumentiert; der Ausbau bleibt Teil von Phase 14. Synthetische Repository-/SQL-Transaktionstests ersetzen keine freigegebene PostgreSQL-Integrationsabnahme. + +Purple-Knight-Begleitdateien 2026-09-10: Alte Importe koennen den nativen Wert noch nicht als Kontextbeobachtung enthalten. Dann kann die neue Leseprojektion ihn nicht nachtraeglich aus Rohtext erfinden und die betroffenen Summary-/Findings-Dateien muessen gemeinsam neu importiert werden. Mehrere unterschiedliche Ergebnisberichte in demselben Scanlauf werden bewusst nicht automatisch mit einem einzelnen Summarywert verbunden. + +Weitere Scanner 2026-09-10: Unbekannte Formate und anders skalierte oder mehrdeutige Kennzahlen benoetigen eine belegte Profilzuordnung; beliebige Scorefelder werden nicht automatisch als Gesamtwert interpretiert. Pflichtdeklaration und synthetische Regressionen sichern den Vorrang unterstuetzter nativer Werte, ersetzen aber keine fachliche Pruefung neuer Herstellerformate. + +Scoring 2026-09-10: Der hybride Index ist nicht empirisch zwischen Herstellern kalibriert. Unbekannte Ziel-/Laufidentitaet, fehlende Quellversionen, hybride native Berichte sowie unvollstaendige Pruefpopulationen begrenzen Deduplikation und Vergleich; die Oberflaeche kennzeichnet diese Faelle. Historischer Scorevergleich fuehrt offene Scannerreferenzen nur read-only fort; persistierte Workflow-Fortschreibung, GPO-Historie und auditierter Scope-Austritt bleiben im separaten Phase-8-Arbeitspaket. Historische Kontextlesefehler sperren Fortschrittsaussagen, nicht das Oeffnen des aktuellen Workspace. + +HTML-Timeout-Restgrenze 2026-09-09: Die konkrete Datei aus dem Screenshot wurde aus Datenschutzgruenden nicht geoeffnet. Reproduziert und behoben ist ein gleichartiger Timeout bei langen wertlosen Attributen, zusaetzlich wurden wiederholte Verweissuchen reduziert. Damit ist noch keine erfolgreiche Verarbeitung dieser konkreten Datei belegt; bei erneutem Fehler sind eine synthetische strukturgleiche Reproduktion oder eine ausdruecklich freigegebene minimale Inhaltspruefung erforderlich. Laufzeiten sind lokale Beobachtungen, keine CI-Millisekundengarantie. Fachliche Extraktion und Profile bleiben kompatibel; bestehende erfolgreiche Importe muessen wegen dieser Performancekorrektur nicht umgeschrieben werden, fehlgeschlagene Vorschauen muessen erneut gestartet werden. Keine SQL-/API-/Persistenzaenderung. Der globale Local-only-Check bleibt trotz 1.131 bestandener Tests an der fremden GPO-DisplayName-Aenderung offen; der HTML-Fix ist deshalb nicht als vollstaendig gruene npm-test-Gesamtkette ausgewiesen. + +PurpleKnight-Importgrenzen 2026-09-09 (Phase 13A/13C): Verifiziert sind die freigegebenen CSV-/XLSX-/HTML-Exporte und synthetische Varianten, nicht jede kuenftige Toolversion. Ohne deklarierte Summen ist kein vollstaendiger rechnerischer Bilanznachweis moeglich. Die statische Datengrammatik ist kein allgemeiner JavaScript-Interpreter; neue dynamische Exportvarianten benoetigen eine begrenzte Erweiterung, keine Ausfuehrung. Mehrfachvorkommen und Widersprueche bleiben sichtbar statt heuristisch zusammengefuehrt zu werden. Die gelieferten CSVs und HTML/XLSX stammen aus unterschiedlichen Scanzeitpunkten und duerfen nicht auf identische Statussummen gezwungen werden. Bestehende Importe bleiben unveraendert und benoetigen Reimport fuer neue Erfassungsdaten. AD-Domaenen-Begleitdateien bleiben als Rohquellen erhalten; die neue typisierte HTML-Domaenenliste ersetzt keine allgemeine Inventarmodellierung. Keine Persistenzmigration, optionale PostgreSQL-Integration nicht aktiviert; bestehender Client-Bundlegroessenhinweis bleibt offen. + +Purple-Knight-Entra-Risiko 2026-09-22: Ein Tenantname, der nur in einer alten generisch importierten Summary existiert, darf nicht aus Dateinamen, Findingtiteln oder AAD-Regelkennungen geraten werden. Profil 1.4.0 liest ihn ausschliesslich aus der nativen `Entra ID: tenant`-Zeile und speichert deren Quellposition. Fehlen Originaldateien fuer einen historischen 1.3.0-Lauf, bleibt Client Info unbekannt; ein stiller Bestandsumbau aus praesentativen Tabellen ist unzulaessig. AD- und Entra-Scores bleiben getrennt, auch wenn beide denselben numerischen Wert besitzen. + +PingCastle-Importgrenzen 2026-09-09 (Phase 13A/13C): Verifiziert sind das freigegebene Dummy-Paar und synthetische Varianten, nicht jede PingCastle-Version. Ohne native Zaehler kann kein rechnerischer Vollstaendigkeitsnachweis erfolgen. Doppelte IDs werden diagnostiziert, bleiben aber gemaess bisheriger Entscheidung ein Finding mit erster Darstellung; es findet keine automatische Zusammenfuehrung widerspruechlicher Darstellungen statt. Der bekannte fehlende HTML-Anker und die XML-Results-Einschraenkung bleiben sichtbare Warnungen. Generische XML-Attribute sind keine automatische Assetklassifikation; semantisches XML-Mapping und Control-Path-JSON bleiben offen. Alte Importe benoetigen Reimport. Keine Schema-/Datenmigration, optionale PostgreSQL-Integration nicht aktiviert; vorhandene Client-Bundlegroessenwarnung bleibt bestehen. + +Maester-Importgrenzen 2026-09-09 (Phase 13A/13C): Die statische Datengrammatik und der lexikalische Zuweisungsfinder sind kein allgemeiner JavaScript-Parser. Neue dynamische Exportvarianten benoetigen eine ausdrueckliche Erweiterung mit synthetischen Ablehnungs- und Vollstaendigkeitstests; ihre Ausfuehrung bleibt verboten. Verifiziert sind die bereitgestellten Dummy-Dateien und synthetische Varianten, nicht pauschal jede Maester-Version. Bekannte Zaehlerabweichungen markieren die Verarbeitung mit Warnungen, obwohl saemtliche Einzeltests erhalten bleiben. Bereits gespeicherte Importe erhalten weder die korrigierte Evidenzabbildung noch neuen HTML-Kontext automatisch. Excel und HTML bleiben eigenstaendige Quellen mit eigener Provenienz; gleichzeitiger Import beider Dateien erzeugt weiterhin separate Vorkommen und keine automatische dateiuebergreifende Deduplizierung. Der Maester-Laufzeitrechner darf nicht als bewertetes Zielsystem in die Assetzaehlung gelangen. Keine Persistenz- oder Schemaaenderung; optionale PostgreSQL-Integrationstests wurden nicht aktiviert. Die bestehende Client-Bundlegroessenwarnung bleibt offen. + +Navigationsperformance 2026-09-09 (Phase 7): Die Selektoren setzen unveraenderliche Quellrecords, Blaetter und Eingaben voraus; fachliche Aenderungen brauchen neue Objektidentitaeten. Wiederverwendung und Invalidierung sind getestet, Varianten je Blatt auf vier begrenzt. Zeitwerte haengen von Datenbreite, Browser und konkurrierender Last ab; CI sichert Verhalten und Operationen statt harter Millisekundenlimits. Notwendiger Kalt-/Neuaufbau bleibt teurer: nach Filterreset im Dummy rund eine Sekunde fuer Pathfinder beziehungsweise Client Info. Result DB, DB Structure und Datahub erreichten 34/44/109 ms bis zum dritten Frame; asynchrone Datenbereitstellung ist darin nicht enthalten. Die vorhandene Client-Bundlegroessenwarnung bleibt offen. Vollstaendige Einzelmessungen und Grenzen sind im Performance-Dokument festgehalten. + +GPO-Quellenrisiko 2026-09-08: Bei erneuter Evaluation kann die referenzierte Backupteilmenge wachsen, ohne dass ein neuer Import vorliegt. Die Auswahl ueber autoritative aktuelle Evaluationen und die stabile Aggregations-ID verhindert dadurch erzeugte Doppelzaehlungen. Ohne belegbaren Importzeitpunkt bleibt `Imported` leer und die Quellenbezeichnung neutral `GPOs`; der Laufzeitpunkt wird nicht als Importdatum erfunden. Der zusaetzliche projektgebundene Read-Aufruf darf bei einem Fehler nicht still auf Historie zurueckfallen. Synthetische Regressionen sichern 2-zu-3-Backup-Abdeckung, Supersession, getrennte echte Importe, Timeslotgrenzen, fehlende Kundenwerte, Konsistenzzeilen und unveraenderte Scannerzeilen. Keine automatische Reconciliation wird fuer diese reine Leseaenderung ausgeloest. + +Security-Template-Risiko 2026-09-08: Ein partiell verarbeitetes INF darf nicht als vollstaendig interpretiert werden; ausgelassene Eintraege sind keine belegte Abwesenheit. Diagnosecodes, `partial` und `inventory-only` bleiben deshalb entlang der Pipeline sichtbar. Vorhandene Baselineanalysen werden bis zur versionierten Neuanalyse nicht durch den Parserfix korrigiert; vorhandene Evaluationen benoetigen danach einen neuen Lauf. Die vom Nutzer genannten 109/109 beziehungsweise 107 Deviations plus 2 Review sind eine noch zu verifizierende Erwartung; wiederhergestellte Baselinevarianten koennen weitere Consensus-Konflikte aufdecken. Die bestehende Job-Reconciliation plant bei einer neuen GPO-Analyserversion projektuebergreifend veraltete Quellen neu ein. Beim ersten Neustart entstand dadurch unbeabsichtigt ein zusaetzlicher Evaluationslauf ausserhalb des freigegebenen Dummy-Scope; Originale und Historie blieben erhalten, Backend wurde angehalten und keine weiteren aktiven Jobs festgestellt. Dieser automatische Versionspfad ist bei kuenftigen projektbegrenzten Betriebsaktionen vor einem Neustart explizit zu beruecksichtigen. Inhaltspruefungen ausschliesslich synthetisch, Livekontrollen nur mit anonymisierten technischen Zaehlern. + +Festgelegtes Client-Info-Darstellungs- und Bewertungsrisiko vom 2026-09-07: Eine globale Sondergestaltung koennte andere Ansichten veraendern; native Tool-Scores koennten mit dem ASSESSOR Overall Score vermischt werden; heuristische Domain-Linsen koennten ueberlappende Findings wie unabhaengige Populationen erscheinen lassen; fehlende Environment-Fakten koennten als Null fehlinterpretiert werden. Gegenmassnahme: alle Sonderfarben und Geometrien ausschliesslich unter `.client-command-center` und `--client-info-*` kapseln, den Overall Score nur aus vergleichbaren ASSESSOR-Quellenscores bilden, native Metriken nur beschriftet in Source Overview zeigen, Domainzuordnung als rein praesentative Multi-Label-Linse ohne Einfluss auf Overall Score behandeln und unbekannte Fakten konsequent als Gedankenstrich anzeigen. Synthetische Regressionen pruefen Scoreaggregation, acht Domains, Source-Komposition und fehlende Werte; Live-Sichtpruefung bleibt auf den freigegebenen Dummy begrenzt. + +Festgelegtes Workspace-Navigationsrisiko vom 2026-09-07: Ein aus dem aktiven Fachblatt abgeleiteter oder gegen dessen Treffer nachgezaehlter Source-Filter kann alle anderen Scanner ausblenden; ein blosser Fremdwertfilter auf dem GPO-Blatt wuerde wiederum eine leere Ansicht statt des gewuenschten Scans erzeugen. Gegenmassnahme: Optionsliste ausschliesslich aus dem vorhandenen projektweiten Aggregat bilden, die stabile Provenienz-ID von Spaltenindizes entkoppeln, ihre Werte von lokaler Nachzaehlung ausnehmen und bei einer Auswahl aus einem Fachblatt zuerst auf dasselbe Aggregat wechseln. Regressionen pruefen drei unterschiedliche Scans, unveraenderte globale Optionen und das Navigationsziel. + +Festgelegtes GPO-Kontextregressionsrisiko vom 2026-09-14: Eine GPO-Auswahl ueber den workspaceweiten Source-Filter kann auf dem All-Records-Blatt zwar die Datensaetze reduzieren, aber weiterhin das zusammengefuehrte Multiple-Tools-Profil und dessen bereits begrenzte Facetten anzeigen. Dadurch erscheinen fachfremde Statuswerte und Scannerfilter; ausgeblendete Altfilter koennen unbemerkt weiterwirken. Ein profilweiter Wertvergleich ueber alle Felder kann zudem `Pass` aus Comparison oder Historical result als aktuellen Passed-Status missverstehen. Gegenmassnahme: den eindeutigen Quellwert ueber Datensatzprovenienz als Werkzeugkontext aufloesen, den GPO-Facetten- und Statusvertrag vor Priorisierung und Limit anwenden, GPO-Status ausschliesslich aus dem aktuellen Statusfeld bestimmen, inkompatible gesetzte Facetten entfernen und den exakten Source-Auswahlweg samt fremdem Pass-Wert und Rueckkehr zum Mischkontext dauerhaft synthetisch pruefen. + +Festgelegtes Facettenrisiko vom 2026-09-07: Die allgemeine Einwertigkeitspruefung oder ein kuenftiges Facettenlimit koennte `Source: Scan` erneut aus GPO- oder anderen Ansichten entfernen; flexible Gruppenbreite koennte den Filter ausserdem optisch zwischen Fachfacetten statt stabil ganz rechts platzieren. Gegenmassnahme: Source-Scan fachlich explizit erkennen beziehungsweise aus vorhandener Provenienz ableiten, von der Nuetzlichkeitsunterdrueckung ausnehmen, nach dem begrenzten Fachfacettensatz als letztes Element anfuegen und per eigener CSS-Klasse mit automatischem linken Rand an die rechte Kante setzen. Synthetische Tests pruefen GPO-Vollreihenfolge, Fallback, Klasse und Endposition. + +Festgelegtes GPO-Quellenpfadrisiko vom 2026-09-07: Source-Locators koennen lokale Laufwerke, Backupordner, Artefaktnamen oder kundenirrelevante Importstruktur vor der eigentlichen GPO-GUID enthalten; eine tolerante Teilanzeige koennte diese Informationen offenlegen. Gegenmassnahme: zentraler reiner Presenter mit geschlossener GUID-/`DomainSysvol/GPO`-Erkennung, Anzeige ausschliesslich ab dem erkannten internen Anker und fail-closed Platzhalter fuer jede andere Form. Originalprovenienz bleibt unveraendert gespeichert und wird nicht zur Navigation oder Dateiaufloesung verwendet. + +Festgelegtes Duplicate-Praesentationsrisiko vom 2026-09-07: Eine vereinfachte Duplicate-Anzeige koennte Quellenredundanz faelschlich als Deviation darstellen oder umgekehrt eine zusaetzliche echte Baselineabweichung als unkritisch erscheinen lassen. Gegenmassnahme: ausschliesslich die identische Mehrquellenbelegung beschreiben, explizit `A duplicate alone is not a baseline deviation` formulieren, keine Pass-/Failfarbe verwenden und Duplicate-/Baselineklassifikation im Domainmodell weiterhin als getrennte Aussagen behandeln. + +Festgelegtes Tabellenrisiko vom 2026-09-07: Mehrere Varianten, lange Pfade oder grosse Wertstrings koennen die gemeinsame Vergleichstabelle unlesbar verbreitern oder Inhalte abschneiden. Gegenmassnahme: semantische Mindestbreiten nur innerhalb eines eigenen horizontal rollbaren Tabellencontainers verwenden, alle Zellen an beliebigen sicheren Stellen umbrechen lassen, keine Clamps/Ellipsen einsetzen, Quellen pro Variante bedarfsgesteuert expandieren und die vollstaendige technische Provenienz in der nachgelagerten Detailstufe erhalten. + +Festgelegtes Praesentationsrisiko vom 2026-09-07: Eine vereinfachte Konfliktansicht koennte leere/Whitespace-Werte normalisieren, technische Provenienz verlieren oder durch Farb- und Sprachwahl faelschlich eine wirksame beziehungsweise bevorzugte Variante behaupten. Gegenmassnahme: Karten ausschliesslich aus dem vollstaendig validierten begrenzten Evidence-Envelope ableiten, Originalzellwerte unveraendert erhalten, leere und Whitespace-Werte explizit kennzeichnen, alle Quellen/IDs unter technischen Details bewahren, nur den neutralen Warning-Akzent verwenden und bei jeder Mehrdeutigkeit auf die bestehende inerte Tabellenprojektion zurueckfallen. + +| Die Produktversion bleibt trotz funktionaler Aenderungen unveraendert oder wird mit einer technischen Komponentenfassung verwechselt; Frontend und Backend koennen zudem unterschiedliche Builds ausliefern. | Produktversion zentral aus dem Paket beziehen, im Markenblock zeigen, Buildzeit und Backend-Release im About-Popup ausweisen und die Backend-Produktversion ueber Health melden. Releaseprozess und Tests muessen die bewusste SemVer-Aenderung pruefen. | + +| Leere oder technisch nicht normalisierbare Microsoft-Baselinewerte koennten als Abweichung erscheinen und die Work-Liste mit nicht belastbaren Findings aufblasen. | Baselinezeilen ohne Sollwert vor der Evaluation ausschliessen; Pass/Fail nur bei vorhandenem vergleichbarem Baselinewert zulassen; nicht unterstuetzte Werte als Review/Warning fuehren und synthetisch sowie per inhaltsfreier Zaehlerpruefung absichern. | + +Festgelegtes Vergleichsrisiko vom 2026-09-06: Wenn eine im Folgetimeslot fehlende Quelle still als nicht mehr vorhanden gilt, erscheinen offene Risiken faelschlich behoben und Score sowie Fortschritt lassen sich durch weniger Evidenz verbessern. Gegenmassnahme: erwartete Quellen explizit zustandsbehaftet fuehren, nur aktuell beidseitig beobachtete Quellen fuer gemessenen Fortschritt verwenden, offene letzte Findings separat und scorewirksam fortschreiben sowie Coverage/Freshness sichtbar ausweisen. Rohbeobachtungen duerfen dabei nicht als aktuelle Messung dupliziert werden. + +Festgelegtes Review-Persistenzrisiko vom 2026-09-06: Dieselbe Finding-Occurrence kann in mehreren Work-Blaettern unterschiedliche Anzeige-IDs besitzen; eine rein an diese IDs gebundene Browserablage kann Owner, Termine und Massnahmen auseinanderlaufen oder bei Browserwechsel verloren gehen. Gegenmassnahme: kanonische Occurrence-/Definition-IDs in die Projektion tragen, alle Projektionen synchronisieren, ueber die Same-Origin-API optimistisch versioniert speichern und die lokale Ablage nur als Rueckfall/Migrationsquelle behandeln. + +Festgelegtes Datenschutzrisiko vom 2026-09-06: Scanner-Zusatzinformationen und rohe Policy-Beobachtungen koennen Personen-, Konto-, Domain-, Host-, GPO-, Pfad- oder andere kundenidentifizierende Werte enthalten. Gegenmassnahme: Die Result-DB-Projektion arbeitet fail-closed mit einer versionierten Allowlist und engen Wertvalidatoren, verwendet kontrollierte Metadaten statt Quelllabels und entfernt Identitaeten, Originalwerte, Attribute und Locator. Der JSONL-Export prueft die Klassifikation erneut. Neue Tools liefern weiterhin kanonische Findings, aber keine ungeprueften Zusatzfelder; deren Freigabe erfordert eine synthetisch regressionsgepruefte Policy-Erweiterung. + +Festgelegtes Result-DB-/LLM-Risiko vom 2026-09-22: Selbst nach Musterredaktion koennen freie Titel, Beschreibungen, Kategorien, Baselinebezeichnungen oder scheinbar technische Werte unbekannte Personen- oder Firmennamen tragen; Regex-Sanitisierung ist deshalb keine ausreichende Datenschutzgrenze. Gegenmassnahme: Keine importierte Freitextzeichenkette wird in der normalen Result DB repariert oder teilweise freigegeben. Sichtbare Texte werden ausschliesslich aus kontrollierten Konstanten und katalogeigenen oeffentlichen IDs neu aufgebaut, Kundenwerte komplett verworfen und unbekannte Quellen generisch benannt. Suche und Facetten arbeiten auf derselben bereits reduzierten Projektion. Jede kuenftige fachliche Erweiterung muss einen synthetischen Leckagetest fuer UI/API und JSONL ergaenzen. Restrisiko: Auch anonymisierte Findings beschreiben den Sicherheitszustand des ausgewaehlten Unternehmensscopes; wer keinerlei Unternehmenssicherheitsdaten an ein externes LLM uebermitteln darf, darf auch diesen Export nicht verwenden. + +Risikokorrektur 2026-09-22: Die vorstehende vollstaendige Freitextsperre schuetzte zwar maximal, zerstoerte aber den beabsichtigten LLM-Nutzen und ist fuer bekannte Scannerprofile durch Policy 2.1.0 ersetzt. Regelprosa wird nur bei explizit bekannten Profilen freigegeben und zuvor aus privaten Begleitfeldern sowie festen Identifierklassen redigiert; unbekannte/generische Quellen bleiben gesperrt. Restrisiko bleibt, dass ein nicht als Identifier erkennbarer Eigenname ohne Rechtsformsuffix ausschliesslich in der Regelprosa stehen kann. Deshalb ist der Export eine technische Datenminimierung, keine automatische rechtliche Freigabe fuer beliebige externe LLMs; neue Profile benoetigen synthetische Leckage- und Nutzbarkeitstests. + +Risikokorrektur 2026-09-23 fuer GPO-Vergleiche: Der Nutzer hat die vollstaendige Pseudonymisierung technischer GPO-Werte als fachlich unbrauchbar verworfen. Disclosure Policy 2.2.0 gibt deshalb im internen Result-DB-Scope und im bewusst ausgeloesten JSONL-Export konkrete konfigurierte und erwartete GPO-Werte einschliesslich technischer Principals/SIDs frei. Projekt-, Assessment-, Run-, Artefakt-, Locator-, Review- und automatisch erzeugte Hashidentitaeten bleiben entfernt. Diese technische Evidenz kann kundenidentifizierend sein; Export oder Uebermittlung an externe LLMs ist keine automatische Datenschutzfreigabe und darf nur innerhalb der jeweils zulaessigen Vertrauensgrenze erfolgen. Die App erfindet keine GPO-Anwendung oder effektive Endpunktwirkung. + +Offen 2026-09-06 (Phase 13B): Die automatische Kontextableitung unterstuetzt derzeit belegte DC-Betriebssysteme; umfassende Member-/Client-/Produktableitung und kontextspezifische Baseline-Teilpakete sind nicht abgeschlossen. Ausgewaehlte/unvollstaendige Backups bleiben nach der bestehenden Bewertungsgrenze Review; ein neutraler Teilmengenvergleich ohne Vollstaendigkeitsaussage ist separat zu entwerfen. Fehlende Baselineoriginale verhindern Reprocessing aus Originalbytes, auch wenn alte Analysen noch lesbar sind. Erforderlich sind Wiederbereitstellung der identischen Originale oder ein neuer expliziter Import; keine Ersatzdaten und kein stiller Speicher-/Datenbankwechsel. + +Festgelegtes Betriebsrisiko vom 2026-09-06: Verzeichnisabhaengige Compose-Projektnamen oder spontane Portausweichungen koennen mehrere auseinanderlaufende ASSESSOR-Datenbanken erzeugen und die App unbemerkt mit einem anderen Datenstand verbinden. Gegenmassnahme: `assessor-2_0` und `assessor-2_0_assessor-postgres-data` sind in Compose und `AGENTS.md` kanonisch gebunden; das Volume ist extern, Port `5432` verbindlich, alternative ASSESSOR-Datenbanken und Fallbackports sind untersagt. Vor Persistenzmigrationen oder destruktiven Eingriffen ist ein verifiziertes Backup erforderlich; fremde Docker-Bestaende bleiben unberuehrt. + | Risiko | Gegenmaßnahme | +| A Defender device identity can change, collide, become ambiguous, or lack detailed CVE evidence; a mutable bulk scope could then silently cover the wrong device or newly discovered vulnerabilities. | Rebuild targets only through the shared Defender identity model, reject unresolved/ambiguous identities, store immutable device metadata and per-member occurrence/run/file/table/row provenance, derive snapshots server-side, and require a new decision for changed keys or new CVE definitions. Aggregate-only counts remain non-actionable. | +| Eine kuenftige Erweiterung der Umgebungsaggregate koennte identifizierende Daten (Domaenen-/Forest-/Hostnamen, Zeitstempel) versehentlich in Result DB oder AI Overview aufnehmen. | Offenlegung bleibt fail-closed mit exakter Tool-/Property-Allowlist und engen Wertvalidatoren; die Ableitung erzeugt ausschliesslich Zaehl-/Booleanwerte unter neutralem `active-directory-environment`-Subject ohne Quellidentitaet. Regressionstests pruefen gleichzeitig die Aufnahme der Aggregate und den fortgesetzten Ausschluss von `domain.fqdn`; neue offenzulegende Properties erfordern eine explizite Regel plus `SAFE_ENVIRONMENT_PROPERTIES`-Eintrag. | +| Eine spaetere Kartenrefaktorierung kann wieder alle Client-Info-Karten standardmaessig oeffnen und damit die vereinbarte kompakte Startansicht verlieren. | Den Startzustand an jeder konkreten Karteninstanz explizit setzen und statisch pruefen: neun `initiallyExpanded={false}` sowie genau ein nicht minimierter `Assessment Status`; die gemeinsame Komponente bleibt fuer gezielte Wiederverwendung konfigurierbar. | +| Eine minimierte Client-Info-Karte kann durch intrinsische Flexbreite schmaler als ihre Spalte werden; werkzeugspezifische Provenienz kann ausserdem erneut in einen fachlichen Verzeichnisueberblick geraten. | Collapsed-Karten explizit auf `width: 100%` setzen und diese Geometrie regressionspruefen. `directoryFacts` auf fachliche Directory-Felder begrenzen; Scanner-Engine-Versionen bleiben in der Quellprovenienz statt in `Directory Overview`. | +| Client-Info-Karten koennen beim Ein-/Ausklappen zwischen Spalten wechseln und dadurch die erlernte Position verlieren; unterschiedlich hohe Kopfbereiche koennen ausserdem eine grosse Leerstelle vor der Inhaltsmatrix erzeugen. | Karten statisch in drei semantische Spalten mit der Zuordnung 3/2/2 gruppieren und innerhalb jeder Spalte per Flex-Stack anordnen. Keine dichte Auto-Platzierung oder laufzeitbasierte Spannenberechnung verwenden. KPI-Matrix und Assessment-Status in derselben gestreckten Kopfzeile fuehren; an schmalen Breakpoints kontrolliert stapeln. Spaltenzahl, Karteninstanzen, Reihenfolge und Collapse regressionspruefen. | +| Ein lokal bereitgestellter Policy-Regelkatalog kann nach fachlicher Freigabe unbemerkt veraendert, nur teilweise konfiguriert, als Symlink umgebogen oder mit ungueltigen Runtime-Strukturen geladen werden und dadurch andere Findings erzeugen. | Pfad und SHA-256 als untrennbares Konfigurationspaar verlangen, nur regulaere Nicht-Symlink-Dateien bis 5 MiB lesen, Hash vor UTF-8-/JSON-Parsing vergleichen und danach den geschlossenen Katalogvertrag fail-closed validieren. Bei jedem Fehler vor Repository- und Serverstart abbrechen; Evaluation Runs bewahren weiterhin den vollstaendigen tatsaechlich verwendeten Katalog. | +| Historische GPO-Reprocessing-Ketten koennen alte Konflikte, Reviewhinweise, Abweichungen und Findings mehrfach als aktuellen Zustand erscheinen lassen; wenn UI und Aktionsableitung unterschiedliche Auswahlregeln verwenden, bleiben ausserdem veraltete Evaluationen bedienbar. | Aktive Profile und nicht ersetzte Identity-Analysen je Artefakt als Wurzel einer gemeinsamen deterministischen Aktivkette verwenden; nur dazu passende Aggregationen, jeweils neueste Evaluationen und Finding-Runs in die aktuelle Sicht aufnehmen. Historie getrennt erhalten und dieselbe Auswahlfunktion fuer Summary, Review Queue sowie Evaluate-/Finding-Aktionen regressionspruefen. | |---|---| +| Die in der Mock-CVE-Datei wiederholten Site-/Sensorwerte koennten vom Device-Inventar abweichen oder spaeter faelschlich als native CVE-Exportfelder gelten. | Beide Felder als `simulated_fixture_field` dokumentieren, ueber `Device ID` gegen genau eine Inventarzeile validieren und Manifesthash sowie Spaltenmetadaten bei jeder Aenderung gemeinsam aktualisieren. Ein echter unveraenderter Export bleibt vor Produktivnutzung erforderlich. | +| Die Mock-Defender-CSV-Header sind synthetisch und koennen von einem spaeteren nativen Produktexport abweichen; eine breite Heuristik koennte zudem fremde CVE- oder Inventarlisten als Defender erkennen. | Nur die vollstaendige bekannte Mock-CVE- beziehungsweise Inventarstruktur akzeptieren, Werte und Provenienz verlustfrei behalten und Device-Kontext ausschliesslich per `Device ID` verbinden. Einen echten unveraenderten Export vor Produktivnutzung mit synthetischen Regressionen validieren und jede notwendige Alias-/Semantikaenderung append-only versionieren. | +| Alte Defender-Importe mit Profil 1.0.0 tragen im gespeicherten Occurrence-JSON weiterhin `outcome=unknown`; wenn Work bereits die aktuelle Profilregel verwendet, koennten Projektion und SQL-Vorfilterung widerspruechlich werden. | Profil 1.1.0 als semantisch inkompatiblen Vertrag mit neuem Compatibility Key registrieren. Die unveraenderliche Migration 022 erweitert den Result-Type-Constraint; Migration 023 zieht ausschliesslich die abgeleiteten relationalen Read-Model-Spalten `result_type` und `outcome_normalized` fuer bestehende Defender-Vorkommen nach. Originalfelder, Occurrence-JSON und Profilprovenienz bleiben unveraendert. Die Leseprojektion behandelt einen nachweislich statuslosen historischen Vulnerability-Fund ebenso. Reimport/Reprocessing bleibt fuer einen vollstaendig aktuellen kanonischen Datensatz erforderlich. | +| NVD kann nicht erreichbar oder rate-limitiert sein, unerwartet grosse Antworten liefern oder externe Referenz-URLs enthalten; ein API-Schluessel darf nicht an Browser oder Logs gelangen. Eine automatische Anreicherung waehrend des Imports wuerde zudem dessen Reproduzierbarkeit und Verfuegbarkeit an einen externen Dienst koppeln. | Enrichment ausschliesslich separat und nutzerausgeloest im Backend ausfuehren, nur exakt gespeicherte Defender-CVE-IDs akzeptieren, Zielorigin und API-Pfad fest verdrahten sowie Timeout und 8-MiB-Antwortgrenze erzwingen. Den optionalen Schluessel nur aus `NVD_API_KEY` als Serverheader senden, Antwortfelder normalisieren, Referenzen nur als HTTP(S)-Links darstellen und Importfehler strikt vom Enrichment-Ergebnis trennen. | +| Defender-for-IoT-Summarys koennen Severity-Zahlen ohne einzelne CVEs enthalten; wiederholte Sensorzeilen koennen dieselbe Device-CVE-Beziehung mehrfach melden, und pseudonymisierte oder wiederverwendete Adressen koennen Identitaeten mehrdeutig machen. | Aggregate ohne Detail niemals in Findings umwandeln, Device-mal-CVE vor der kanonischen Projektion deduplizieren, alle Sensorzeilen als Evidenz erhalten, Identitaet nach der dokumentierten MAC-/IP-/Name-Site-Reihenfolge bilden und Konflikte beziehungsweise Reconciliation-Abweichungen diagnostizieren statt still zusammenzufuehren. | +| Ein gemischtes All-Records-Blatt kann den generischen Titel `Name` auf alle Scanner anwenden und dadurch bei Defender die Device-IP statt der CVE anzeigen; zugleich kann eine rein profilgebundene Client-Info-Sonderansicht in gemischten Timeslots verschwinden. | Titel im gemischten Blatt je Datensatz aus dessen `Source: Scan`-Provenienz und deklarativem Werkzeugprofil bestimmen. Die allgemeine Client-Info-Uebersicht beibehalten und die Defender-Projektion bei vorhandenen Defender-Quellblaettern als eigenen Tab anbieten. | +| Scannertexte koennen `U+0000` enthalten: Browser und In-Memory-Vorschau akzeptieren den Wert, PostgreSQL `jsonb` weist ihn beim Abschluss ab. Eine nur an der Datenbank vorgenommene Bereinigung wuerde ausserdem Vorschau und gespeichertes Modell auseinanderlaufen lassen. | Das Zeichen einmal an der gemeinsamen kanonischen Importgrenze in die explizite Darstellung `\\u0000` ueberfuehren, Anzahl und Repraesentation diagnostizieren und Hash/Locator unveraendert erhalten. Maester-XLSX und kompletter Preview-/Complete-HTTP-Pfad bleiben permanente Regressionen; Abschlussfehler duerfen die erfolgreiche Vorschau nicht mehr verwerfen. | +| Unterschiedlich hohe oder geschlossene Client-Info-Karten koennen in einem regulaeren Zeilenraster grosse Leerraeume hinterlassen; eine unbedingte JS-Masonry-Aktivierung koennte ohne Mess-API dagegen Karten ueberlagern. | Mit dem normalen Raster starten, Kartenhoehen inklusive gemeinsamem Segmentabstand messen und erst danach 1-px-Spannen mit `grid-auto-flow: row dense` aktivieren. Raster und jede Karte beobachten, nur geaenderte Spannen schreiben und bei fehlendem ResizeObserver im sicheren Standardraster bleiben. Synthetische DOM-Hoehen und Collapse werden regressionsgeprueft. | +| Infrastruktur-Fakten koennten bei einer spaeteren Dashboardverdichtung erneut mit Risiko-Mengenwerten in einer ueberlangen Mischkarte zusammengefuehrt oder zwischen beiden Karten doppelt dargestellt werden. | `Infrastructure & Resilience` ausschliesslich mit `risk.slice(1)` speisen und den vollstaendigen Faktenblock genau einmal in `Infrastructure Details` rendern. Instanzzahl, beide Titel, Trennung und vollstaendige Snapshot-Faktenliste statisch regressionspruefen; beide Karten ueber den gemeinsamen Collapse-Test absichern. | +| Maester-Fehlertexte koennen PowerShell-Kontext, HTTP-Antwort und verschachteltes JSON in einer langen Zeile mischen; eine aggressive Umformatierung koennte dabei Diagnosewerte verlieren oder normale Ergebnisprosa faelschlich als Fehler behandeln. | Nur die eindeutige Kombination aus Maester, Ausfuehrungsfehlerformulierung und `Invoke-MgGraphRequest` strukturiert parsen. Die Primaermeldung und bekannte technische Felder additiv extrahieren, den unveraenderten Rohtext stets einklappbar erhalten und bei jeder Nichterkennung auf den generischen Renderer zurueckfallen. Parser und Darstellung mit synthetischen Fehlern regressionspruefen. | +| Eine Client-Info-Kachel koennte einen Plus-/Minus-Schalter anzeigen, ohne ihren gesamten Inhalt zu minimieren, in einer hohen Rasterzeile als leere Vollhoehenkarte stehen bleiben oder zwischen Donut- und Faktenkarten unterschiedliche Zustandslogik verwenden. | Beide gemeinsamen Informationskartenkomponenten rendern im minimierten Zustand strukturell nur die Kopfzeile, verwenden dort intrinsische statt gestreckter Rasterhoehe und binden denselben `aria-expanded`-/`aria-controls`-Schalter an den vollstaendigen Inhaltscontainer. Interaktionstests decken beide Kartentypen ab; der Layouttest prueft alle neun konkreten Instanzen, Titel und die Collapsed-Geometrie. | +| Eine feste Rasterspan-Anzahl kann bei wechselnder Dashboardbreite und unterschiedlich langen Environment-Werten erneut Leerraum oder Ueberlauf erzeugen; rein automatische Tracks ohne Mindestmass koennten dagegen die quadratische Grundgeometrie aufloesen. | Die responsive Spaltenzahl weiterhin in eine gemeinsame Mindest-Rastereinheit uebersetzen, `grid-auto-rows` jedoch als `minmax(Mindestmass, auto)` definieren. Inhaltskarten erhalten `min-content` als Untergrenze; nur die datenreiche Resilience-Kachel hebt ihr bevorzugtes Quadratverhaeltnis auf. | +| Client-Info-Infopanels koennten in minimierter Ansicht erneut Balken oder weitere Inhalte zeigen, expandiert zu kompakte Zeilen verwenden oder fuer Assessment und Severity wieder auf eine abweichende Diagrammgeometrie zurueckfallen. | Minimiert strukturell nur Kopfzeile und Plus rendern. Den gemeinsamen expandierten Mengenvertrag mit 120-px-Zeilen, 72-px-Tracks, responsive gestapelter Schmalansicht und vollstaendig wachsenden Fakten anwenden. Alle neun Panelinstanzen sowie die Abwesenheit minimierter Balken und Client-Info-Donuts regressionspruefen. | +| Eine spaetere Progressive-Disclosure-Aenderung koennte die im Zielbild permanent sichtbaren Mengenzeilen erneut ausblenden oder die beiden Verteilungen aus der rechten Donutspalte entfernen. | Kerninhalt und optionale Zusatzdetails als getrennte DOM-Bereiche rendern; nur den Zusatzbereich an `aria-expanded` binden. Hauptmatrix, rechte Rail, zwei Donutkarten und sichtbaren Kerninhalt im Pluszustand gemeinsam regressionspruefen. | +| Eine getrennte volle Kennzahlenzeile koennte `Assessment Status` erneut in eine zweite Reihe zwingen oder bei schmalen Viewports zu kleine quadratische Zahlenkacheln erzeugen. | Kopfzone als 3:1-Raster aus Zahlenmatrix und Assessment-Donut aufbauen; bei 1100 px stapeln und die Zahlenmatrix danach auf drei beziehungsweise zwei Spalten reduzieren. Vorhandene Quadrat- und Kachelvertraege regressionspruefen. | +| Der Client-Open-Ablauf koennte bei spaeteren Data-Hub-Aenderungen wieder implizit in Work landen oder den gewaehlten Timeslot-Scope verlieren. | Zielbereich und `openProject(project.id, scanRunIds)` gemeinsam am zentralen `onProjectSelected`-Callback halten und durch eine Quellregression auf `dashboard` sowie die unveraenderte ScanRun-Uebergabe absichern. | +| Ein expandiertes Infopanel koennte trotz breiter interner Balkenspalte auf der kompakten Zwei-Spalten-Kartenbreite verbleiben; Inhalte wuerden dann aus der Kachel herausragen und Nachbarkacheln ueberdecken. | Expandierte Karten auf sechs Rasterspalten setzen und an 800-/560-px-Breakpoints auf die jeweils gesamte Rasterbreite reduzieren. Desktop- und Breakpoint-Spans statisch regressionspruefen; minimierte Kartenbreite nicht veraendern. | +| Progressive Detailkarten koennten Informationen versehentlich dauerhaft verbergen, unzugaengliche Symbolschalter verwenden oder mit erfundenen Zeitreihen eine nicht vorhandene Entwicklung suggerieren. Unterschiedliche expandierte Inhaltshoehen koennten erneut ueberlappen. | Jede Karte behaelt eine sichtbare Primaermenge mit echtem proportionalem Mengenbalken und rendert den unveraenderten vollstaendigen Inhalt ueber einen beschrifteten `aria-expanded`-/`aria-controls`-Schalter. Keine Sparklines ohne historische Daten erzeugen. Inhaltsbasierte Rastertracks und eine echte Klickregression sichern Ein-/Ausblenden, Balkenwert und ueberlauffreies Wachstum. | +| Dynamische OS-Aufzaehlungen koennen die feste 2-x-2-Quadratflaeche der Infrastructure-&-Resilience-Kachel ueberschreiten und darunterliegende Dashboardbereiche ueberdecken; eine globale Kartenvergroesserung wuerde dagegen das gesamte dichte Raster aufblaehen. | Nur die betroffene inhaltsreiche Kachel drei Rasterzeilen belegen und dort `aspect-ratio` aufheben. Vollstaendige Werte und normale Wortumbrueche beibehalten; die Ausnahme sowie die unveraenderte Faktenmatrix statisch regressionspruefen. | +| Feste Finding-Kachelbreiten koennen an schmalen Viewports weniger Spalten ergeben; lange Titel oder zusaetzliche Kategorien koennten bei einer zugleich festgeschriebenen Hoehe abgeschnitten werden. Eine globale Badge-Regel koennte ausserdem kompakte Pathfinder-Karten unbeabsichtigt vergroessern. | Nur die Breite und Mindesthoehe der regulaeren Work-Kachel zentral festschreiben, Zeilenhoehen fuer Virtualisierung daraus ableiten und Inhalt nach unten wachsen lassen. Die semantische Badge-Matrix strikt auf direkte Work-Rasterkacheln begrenzen; Pathfinder bleibt durch fokussierte Regressionen separat abgesichert. | +| Ein Result-DB-Export koennte nur die aktuell geladenen 50 Zeilen statt aller Filtertreffer enthalten oder bei paralleler Datenmutation Seiten aus unterschiedlichen Ergebnisstaenden vermischen. | Exportseiten mit identischem projekt-/timeslotgebundenem Filterquery deterministisch nachladen, die erwartete Gesamtzahl ueber alle Seiten konstant pruefen und bei Aenderung oder vorzeitig leerer Seite ohne Download abbrechen. Manifest und Ergebnisanzahl gemeinsam regressionspruefen. | +| Optionale Statushinweise oder unterschiedlich lange Zahlen-/Einheitentexte koennen die Balkenbreite und Zeilenhoehe einzelner Client-Info-Karten erneut verschieben; globale Balkenregeln koennen zugleich die kompakte Resilience-Karte ueberlagern. | Statusplatz in jeder Standardzeile reservieren, Label/Track/Wert ueber feste semantische Gridspalten ausrichten und Zahlen samt Einheit ohne Umbruch gruppieren. Die Resilience-Ausnahme setzt Zeilen und Platzierung explizit zurueck; beide Geometrien werden gemeinsam regressionsgeprueft. | +| Ein formal als `released` markierter Policy-Regelkatalog enthaelt unbekannte Runtime-Enumwerte, ueberlappende Kontextselektoren, mehrdeutige Regeln oder widerspruechlich wiederverwendete Risiko-/Abhaengigkeits-IDs und erzeugt dadurch nicht reproduzierbare beziehungsweise fachlich falsche Evaluationen oder Findings. | Die zentrale Katalogvalidierung prueft Auslieferungsmechanismen, Dispositionen, Comparatorvarianten und -modi, Severity, Kontextueberlappung sowie katalogweite ID-Definitionen geschlossen und fail-closed. Jede spaetere fachliche Katalogerweiterung benoetigt positive und negative synthetische Freigaberegressionen; der produktive Katalog bleibt bis zur fachlichen Kuratierung leer. | +| Ein LLM zaehlt Findings anders als die Anwendung, erfindet Referenzen oder liefert ein fuer das Dashboard ungueltiges beziehungsweise prompt-injiziertes Ergebnis. | Summarywerte vor dem Modellaufruf deterministisch in der Anwendung berechnen, Eingabedaten als untrusted behandeln, ausschliesslich vorhandene temporaere IDs erlauben, ein versioniertes exaktes JSON-Ausgabeformat verlangen und die spaetere Dashboardaufnahme gegen dieses Schema validieren. | | Auswahl, Fokus und fachlicher Status koennen erneut farblich vermischt werden, wenn Komponenten direkt Akzent-, Fokus- oder Severitytokens fuer eine persistente Markierung verwenden. | Persistente Auswahl ausschliesslich an `--marking-color` binden und in beiden Themes auf denselben Gelbwert regressionspruefen. `--focus-ring` bleibt nur fuer Tastaturfokus; Online-, Fehler-, Workflow- und Severityfarben bleiben fachlich getrennt. | | Einzelansichten koennten trotz flacher gemeinsamer Tokens im Hover erneut dekorative Konturen setzen oder den Standard mit lokalen Radien und Schatten umgehen. | Appweite Projektregel und Regression an die flachen `--tile-*`-Tokens binden; normale und Hover-Zustaende getrennt von Fokus, Auswahl und Statusakzenten pruefen. Lokale Kachelgeometrie bleibt unzulaessig. | | Kontur- und schattenlose Client-Info-Kacheln koennen bei spaeteren Themeaenderungen ihren Flaechenkontrast zum Dashboardgrund verlieren; interaktive Kacheln koennten ohne eigene Zustandsmarkierung schwer erkennbar werden. | Karten- und Grundflaeche ueber die bestehenden Theme-Tokens getrennt halten, Hover weiterhin ueber die Hoverflaeche zeigen und Fokus sowie Auswahl mit den vorhandenen farbigen Konturen sichern. Die Dashboardregression prueft den flachen Normalzustand getrennt von diesen Funktionszustaenden. | @@ -1687,6 +2631,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode | 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 einzelnes GPO-Delete koennte waehrend der Verarbeitung mit dem Worker konkurrieren oder nach einer bereits erfolgten Evaluation verwaiste Snapshot-/Finding-Derivate hinterlassen. | Queue-/Running-Jobs an der Repository-Grenze blockieren. Vor dem Artefaktdelete jede Snapshotaggregation entfernen, die eine Identity-Analyse dieses Artefakts verwendet; relationale Cascades beziehungsweise die identische lokale Projektion entfernen Evaluationen und Findings. Timeslot, andere Imports und Environment Profile erhalten und die Dateikopie ueber die persistente Outbox entfernen. | | 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. | @@ -1803,10 +2748,264 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode | 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. | +| Werkzeugerkennung und gespeichertes Verarbeitungsprofil koennen unterschiedliche IDs tragen; wenn die Werkzeug-ID den Profilvertrag ueberschreibt, erscheint ein registrierter Defender-Import faelschlich als unbekannt. | Kompatibilitaet ausschliesslich gegen `processedWith.profileId` und dessen Version pruefen. Die erkannte Werkzeug-ID bleibt Anzeige- und Gruppierungsmetadatum. Eine Regression sichert den abweichenden-ID-Fall, waehrend unbekannte Profil-/Versionspaare weiterhin fail closed bleiben. | +| A device-finding risk acceptance recorded before the 2026-09-23 fix may cite an occurrence that did not itself contain that device when two occurrences in one scan run shared a CVE. | The new source-row attribution and repository-command regression prevent future writes. Review affected historical decisions against retained source observations before relying on their captured provenance; do not rewrite approval history automatically. | ## 12. Änderungsprotokoll +2026-09-24 (Phase 7, Work-Ansichtsexport als Excel im Finding-Reader-Layout, ausdrueckliche Nutzerauftraege): Der Work-Button `CSV` ist durch `XLSX` ersetzt; `MD` und `HTML` bleiben zweispaltig unveraendert. Auf weitere Nutzerkorrekturen ist die Arbeitsmappe weder Zweispalten- noch Soll/Ist-Tabelle, sondern bildet den Work-Finding-Reader ab: Blatt `Übersicht` mit Exportkontext, Findings/Deviation je Tool und den einmal genannten Lesegrenzen (Review ist kein technischer Behebungsnachweis; GPO-Backupvergleich ist kein Nachweis wirksamer Endpoint-Konfiguration), danach ein Blatt je Tool in Work-Reihenfolge mit einer Zeile je Finding. Spalten: Nr, Finding, Status, Severity, Badges, Source Rule ID, dann die Readerfelder unter ihren Readerlabels in Readerreihenfolge ueber das wiederverwendete `selectFindingFields` (dafuer ohne Verhaltensaenderung aus der React-Komponente in das plattformneutrale `src/features/finding-reader/finding-fields.ts` verschoben, damit `src/exports` keine UI-Abhaengigkeit erhaelt) (z. B. Description, Technical explanation, Advised solution; bei GPO Configured customer value, Expected baseline value, GPO sources), danach Hinweise (nur statusbezogene score-neutrale Einordnung), Results (Inhalt des Results-Fensters samt fehlender Belege), Additional Information, Review und Record ID; leere optionale Spalten entfallen je Blatt. Die Deviation-Markierung der Statuszelle nutzt ausschliesslich Works eigenes Deviation-Praedikat. Fettgedruckte graue Kopfzeile, Autofilter, fixierte Kopfzeile und Spalten Nr/Finding, Umbruch oben ausgerichtet, Spaltenbreiten nach Inhalt begrenzt. Zellen ueber dem Excel-Limit laufen in markierten Fortsetzungszeilen weiter, Identitaetsspalten wiederholen sich. Alle Zellen sind literale Inline-Strings ohne Formel; Steuerzeichen bleiben per OOXML `_xHHHH_` exakt, Additional Information bleibt unformatierter Quelltext. Workbook-XML wird selbst geschrieben, weil SheetJS Community keine Zellstile schreibt; SheetJS `xlsx` 0.18.5 liefert nur den Zip-Container, keine neue Abhaengigkeit. `DownloadAdapter` akzeptiert zusaetzlich Binaerinhalt. Synthetische Unit- und Klickpfadtests (Blatt je Tool, Readerspalten und -reihenfolge, GPO-Werte/-Quellen, Results, Review, Hinweise, Uebersicht, Stile, Filter, Fixierung, keine Formeln, Steuerzeichen, Fortsetzungszeilen) bestanden; eine synthetische PingCastle/CIS-CAT/GPO-Datei oeffnet in Microsoft Excel ohne Reparaturhinweis. Keine Daten-, Import-, Score- oder Reimportaenderung. Nach Code-Review im selben Batch: Gruppierung je Tool linear statt quadratisch, Spaltenbreiten ohne Argument-Spread (250.000 synthetische Findings exportieren ohne Stackueberlauf), und ein Quellfeld mit dem Namen einer festen Spalte (z. B. `Nr`, `Review`) erhaelt eine eigene Spalte `