# ASSESSOR – Umsetzungsplan

## Management Report text revision (2026-10-04, Phase 7)

Explicit user request: the report repeated the same generic sentences in every row and theme. Report Engine only (no Core change): renderer 3.3.0, Business Impact mapping 2.1.0 with fuller theme impact text, new versioned `management-report-texts.ts` 1.0.0 with a German name, Sachverhalt, Einordnung and Ansatzpunkt per Context category, written from the catalog conditions of each category. Theme sheets get a data-derived Kernaussage and per-category blocks; the Summary gets data-derived statements; disclaimers appear once in Lesehinweise und Aussagegrenzen; the 38-row observation table becomes one count/date-range sentence; the redundant Findings row is replaced by the deviation rate; Base Severity stays out of theme sheets as before. Permanent test: every category has complete text, no scanner names, the proof disclaimer occurs once. Reviewed with a local Dummy rendering from the stored Context result. Reporting and Context tests pass (126). Shipped within 2.16.4.

## Business Impact - independent Work filter and clickable bars (2026-10-04, Phase 7)

Current user correction: Business Impact must have its own selection, never select or replace the Context Cluster filter. The four Client Info columns open Work with the independent `report:business-impact` facet. The same four filters appear underneath Security Domains in the Work sidebar, with counts, a persistent selection marker and a second click to clear that theme. Existing Context selection is preserved on chart navigation and on sidebar selection; normal filter intersections still apply. Context Cluster remains directly before Source: Scan. Unassigned remains omitted. These are authorized Core Presentation extension points; no evaluation, verdict, source data or stored client data changes.

The facet reads the same published counting keys and theme assignments as the existing report/chart, not every category attachment. This excludes category attachments without published deviation evidence, which direct Dummy verification found could inflate Control & trust by three. The Context index publishes the existing immutable report projection alongside its unchanged cluster facet. Optional engines hide the extension; disabling Report clears only Business Impact, while disabling Context clears both derived selections. Synthetic exact-interaction acceptance in Dark/Light covers clicking a chart, visible separate dropdown selections, retaining a selected cluster, sidebar toggle, exact matching records, input immutability, optional-engine behavior and an attachment without deviation evidence. Patch 2.16.5 is the backward-compatible release for this refinement; final activation and full verification are recorded below. No phase is marked complete.

Verification completed: 1,909 tests passed, 15 optional skips; local-only and design checks passed. Both production builds passed, with the existing bundle-size advisory. Product package/lockfile and UI/API version contracts agree on 2.16.5. Existing report-export test expectations were synchronized with the already changed heading and count-column position, without changing report text. Direct Dummy interaction in both themes confirms 221 / 63 / 121 / 69 in chart, sidebar and Work, Context stays All on theme selection, and clearing Resilience preserves an explicitly selected Detection Blind Spots cluster. Screenshots saved outside the repository. The canonical backend was restarted from the verified bundle; health confirms 2.16.5, PostgreSQL and unchanged revision 540. No report was generated or stored during these interactions.

## One finding, one category - Context and Business Impact (2026-10-04, Phase 13E / Phase 7)

Explicit user decision supersedes multiple cluster membership in counts and the six overlapping Business Impact themes: a deviation is never counted twice. Context Engine 1.11.0 keeps exactly one primary cluster per finding and GPO setting in `clusterIds` (order: catalogued before recognized before estimated, then most supporting evidence, then base severity, then ID); further clusters stay traceable in `secondaryClusterIds`. Catalog 1.10.0 declares `primaryClusters` for all eight conditions several clusters list (ESC8 -> AD CS Escalation; CIS Printers -> Host Credential & Privilege; delegatable admins -> Kerberos Delegation Abuse; privileged SPN and service-account policy -> Kerberoasting; password-never-expires rules -> Password Guessing); catalog validation rejects a shared condition without one. The heatmap counts each deviation only in its primary cluster, so its cells add up to the unique finding total; cluster condition states are unchanged. Report mapping 2.0.0 has four disjoint themes (Kontrolle & Vertrauen, Informationen & Daten, Betriebsfähigkeit, Widerstandsfähigkeit & Wiederanlauf); every category belongs to exactly one, AD Reconnaissance to Informationen & Daten. Financial and compliance consequences are one prose note, never a counted theme. Dummy with the stored context: heatmap 474 = 474 unique (previously 499); themes 221 / 63 / 121 / 69, plus 3 deviations without a Context category = 477. Permanent tests: heatmap sum equals unique count, missing primary cluster is a catalog error, every category in exactly one theme. Client Info (released Presentation, Core Tests, Platform): the Business Impact row has four equal columns in theme order with English labels; its permanent test checks four bars, labels and no Financial/Compliance bar in both themes. Verified in the browser with Dummy: 4 columns, 221 / 63 / 121 / 69, no overflow. Shipped as patch 2.16.4 (the pending, not yet documented working-tree version); full npm test passed with 1,908 tests and 15 optional skips, client and server production builds passed. Open: the 3 deviations without a Context category are not yet explained. No phase is marked complete.

## Client Info - possible Business Impact columns (2026-10-04, Phase 7)

User-authorized Presentation/Platform/Core Tests refinement: six vertical columns below Security Domains show the existing deterministic primary Business Impact distribution, with English labels and counts. The user explicitly excludes the unassigned column here. The total and Security Domains remain authoritative and unchanged; financial/compliance possible consequences remain available in the report even when their primary counts are zero. The Report Engine counting-key helper is shared with the live Client Info workspace; current source selection limits the population without changing Context assignments. This is a pinned read-only presentation extension to published Context and Report results, covered by architecture tests. No external service, model, database write, score change or historical report rewrite is introduced.

Verified with the actual Dummy Client Info, Scan All: 121 / 0 / 57 / 221 / 0 / 69; six columns only, no unassigned label, Core total still 477. Actual Light rendering inspected and saved outside the repository; synthetic interaction tests cover both themes, optional-engine toggles, request reuse, input immutability and unchanged Core presentation. Full npm test: 1,906 passed, 15 optional skips; local-only and design checks passed. Both production builds passed with the existing bundle-size advisory. Backward-compatible presentation refinement released as patch 2.16.4; package/lockfile and UI/API version contracts synchronized. The identified existing backend was restarted using the canonical PostgreSQL configuration; health confirms 2.16.4 and unchanged revision 540. Report renderer remains 3.2.3. Excluding unassigned means the six displayed values sum to 468 rather than changing the 477 total; this is the explicit requested display decision. No phase is marked complete.

## Management Report - exclusive finding distribution (2026-10-04, Phase 7)

Explicit user correction supersedes overlapping counts in the Business Impact overview: its table and chart must distribute all 477 Dummy deviations exactly once. Report-only mapping 1.1.0 assigns a category's direct consequence to its main theme; financial/compliance downstream consequences remain in the possible-impact prose. Conflicting or missing primary assignments stay in Nicht eindeutig zugeordnet, with no arbitrary tie-break. The authoritative summary workspace additionally publishes the exact deviation counting keys; only these keys enter named bars. Stored Core data, verdicts, scores and Context associations remain unchanged. Complete Context evidence stays in theme details and the technical report. No phase is marked complete.

Authorized direct Dummy verification uses all 477 current Work deviations at revision 540 and the corresponding archived Context publication: Betriebsfähigkeit 121, Finanzielle Auswirkungen 0, Informationen & Daten 57, Kontrolle & Vertrauen 221, Compliance & Haftung 0, Widerstandsfähigkeit & Wiederanlauf 69, Nicht eindeutig zugeordnet 9; sum exactly 477. Synthetic acceptance covers overlapping technical evidence, conflicting primary themes, unmapped findings, out-of-scope keys, order independence, unchanged inputs and equal table/chart totals. The corrected Dummy preview is saved outside the repository in the task's visualization directory. Product/backend activation awaits a current Platform/Core Tests release.

Release completed after current Platform/Core Tests consent: patch 2.16.3 and renderer 3.2.3, package/lockfile and UI/API version contracts synchronized. Full npm test passed with 1,904 tests and 15 optional skips, including the actual export-button interaction checking that chart counts sum to the full unfiltered population. Architecture, Core/Context/Report invariance, local-only and design checks passed. Both production builds passed. The identified backend was restarted from the verified bundle; health confirms 2.16.3, canonical PostgreSQL and unchanged revision 540. The regular report-run API generated Dummy archive 20261004T160231Z-5340b9c2; independent extraction verifies all seven table counts sum exactly to 477 and agree with the diagram. The final API HTML is saved as the reviewable Dummy artifact outside the repository; no historical report or real customer report was rewritten. No phase is marked complete.

## Context heatmap - total beside heading (2026-10-04, Phase 7 / 13E)

Explicit user refinement of the compact header: show `Findings: <count>` directly beside `Context heatmap`, aligned on the text baseline. The existing Context Engine's unique heatmap-finding count is reused; overlapping category membership never increases the total. The scope subtitle and legend remain absent, and the reduced top spacing remains intact. Only Context Engine component, styles and acceptance tests changed; no Core extension point, count contract, report or stored data is modified. Synthetic scope-change, overlap, empty-state and click-path tests pass in both themes: 20 focused tests, including Core/Context invariance. Design-language check passed. Cosmetic display refinement only, no separate product release or backend restart; concurrent work is preserved.

## Report wording refinements (2026-10-04, Phase 7)

Counting correction (Phase 7 / 13E): published Context cluster evidence previously exposed multiple technical result IDs per rolled-up GPO setting; the theme union incorrectly counted those IDs as individual findings. The publication now additionally provides immutable counting keys (scanner occurrence and GPO scope/setting identity). Report themes union those keys, preserving all original result IDs and cross-theme membership. Summary reads the shared Core workspace summary with current GPO evaluations through an additional existing read-only repository method, instead of historical GPO evaluation row counts. No verdict, stored data, Core count or scoring changes. Synthetic tests reproduce 482 evidence rows for 477 unique findings, check overlapping themes and the displayed table/chart/summary, and preserve inputs. Read-only verification of Dummy at revision 540 reproduces the exact screenshot: previous theme counts 193/305/482/294/112/208 become 167/279/399/229/112/190. Context currently maps 474 unique findings; the user's 477 total is not substituted by that mapped count in Summary. Initial backend activation and product release awaited current Platform/Core Tests consent.

Release verification: subsequent current Platform/Core Tests consent authorizes patch 2.16.2 and renderer 3.2.2, including the preceding wording refinements. Full suite: 1,903 passed, 15 optional skipped. The final workspace-summary integration passed 76 focused Report/Context, export-click, architecture and UI/API version tests. Direct canonical read-only Report execution confirms 477 deviations / 759 assessed at unchanged revision 540, and a new Dummy report was archived successfully; historical archives remain unchanged. No real customer report was generated. The first compiled API export check returned a generic internal error; direct source runtime and archive verification succeeded after the final summary integration. Both final production builds and backend API activation are checked before reporting release complete. No phase is marked complete.

Final activation verified: both production builds passed after the final summary integration, and the identified backend was restarted with that bundle against the canonical PostgreSQL datastore. The regular report-run API successfully generated and archived Dummy run 20261004T153811Z-0ec39826 at unchanged repository revision 540. Its Summary states 477 deviations / 759 assessed, the six theme counts are 167/279/399/229/112/190, and all user-removed notes are absent. This resolves the earlier compiled-export verification failure. Existing HTML exports remain immutable and must be regenerated to display this release.

Further screenshot correction: remove the technical sentence about findings without a cluster assignment from Summary. Underlying assignments and appendix data remain unchanged; the synthetic renderer test permanently checks that the sentence is absent.

The subsequent screenshot correction also removes the count/overlap note beneath the theme bar chart. The diagram and its counts remain unchanged; synthetic rendering verifies the note is absent.

Another explicit screenshot correction removes the automatic-assignment/specialist-review note from each theme sheet. Conditional impact wording and underlying confidence data are preserved; a permanent synthetic renderer assertion checks the sentence is absent.

Explicit screenshot corrections: remove the technical overlap/absence-of-evidence note beneath the Business Impact overview, use Summary for both first-sheet summary labels, present Handlungsfelder as a heading with bullet points for evidenced themes, and replace Blätter with Angaben in the introductory prose. Counting, absent-evidence handling and stored data remain unchanged. These small Report Engine presentation refinements do not create a separate product release. Fourteen synthetic renderer tests pass, including both Summary labels, the omitted note, the exact evidenced-theme list and the revised introductory wording. The local synthetic preview is regenerated; production backend activation remains separate from source/preview changes. No phase is marked complete.

## Management Report - ASSESSOR overview and confidentiality (2026-10-04, Phase 7, 2.16.1)

Explicit user correction: the report presents ASSESSOR only, with no scanner names or source breakdowns. Management appears only in the repeated page header; every header and footer states Streng vertraulich. Evidence columns show plain finding counts, and the theme overview includes a bar chart of those counts. These presentation requirements supersede earlier visible attribution and confidence breakdowns; retained source data and published Context assignments remain unchanged. Possible Business Impact stays conditional, with no impact grades or amounts. Generation remains entirely offline, without Internet or LLM.

The first sheet now displays the existing ASSESSOR Overall Score as a full-circle SVG donut beside the summary. It reads the shared report projection directly without changing Core scoring: zero is valid, and absent or invalid scores show unavailable rather than an invented zero. Theme counts deduplicate findings within each theme; overlapping themes are never summed into a total. Historical report archives remain unchanged. Renderer 3.2.1 and the binding report template record the refinement.

Verification: full npm test passed with 1,901 tests and 15 optional skips; architecture, local-only, engine invariance and design checks passed. Permanent tests cover the actual report-export click, score rendering including zero and missing values, scanner-name suppression, header-only Management wording, confidentiality, count-only tables, chart counts and input immutability. Both production builds passed after the final diagram placement, as did the UI/API version contracts. A synthetic production-renderer preview was inspected locally; no customer report was generated or replaced. Current Platform and Core Tests consent authorized patch release 2.16.0 -> 2.16.1 and backend activation. Health confirms 2.16.1, PostgreSQL and unchanged repository revision 540. Concurrent Client Info changes are preserved; no phase is marked complete.

## Client Info - remove standalone trigger and simplify heatmap header (2026-10-04, Phase 7)

Explicit user correction with current Presentation and Core Tests consent: remove only the Client Information button from the Dashboard action row, retaining its data, API and standalone browser. Management Report and Technical Report remain blue. The Context heatmap header now contains only its title: remove the scope subtitle, total-findings display and legend. Existing category colors, per-tile findings, scope selection and exact Work navigation remain intact. Reduce the heatmap top margin from the shared space-8 to space-6 token (32px -> 24px); removing the subtitle also moves the grid upwards without changing the shared outer panel inset. This supersedes the preceding three-button and heatmap-header display agreements only for these visible elements. Twenty-eight synthetic tests passed across both themes, including retained standalone browser behavior, scope changes, Work navigation and Core/Context invariance; design-language checks passed. Cosmetic scope only: no separate product release, backend restart or customer-data operation. Concurrent Report Engine work is preserved.

## Client Info - blue action buttons (2026-10-04, Phase 7)

Explicit user colour-role exception with current Presentation, Platform and Core Tests consent: Client Information, Management Report and Technical Report use the same theme-aware blue background, text and border tokens as Engines, including hover and active states. A dedicated class limits the shared CSS rule to these three actions; geometry, engine activation and report behavior remain unchanged. Synthetic Dashboard interactions cover both themes and preserve disabled report buttons when Report Engine is off. Four focused Client Info tests and the design-language check passed. This small cosmetic refinement does not create a separate product release or change the shared product version. No backend restart or customer-data operation; concurrent Management Report work is preserved.

## Management Report - possible business impact (2026-10-04, Phase 7, renderer 3.2.0)

Explicit user decision: replace the category-first management reading with the six proposed management themes, labelled exclusively **Möglicher Business Impact**, with no impact grades, money amounts or actual client-impact assessment. Report generation must use no Internet or LLM. This supersedes the earlier content sequence and prohibition on business-consequence wording only for clearly conditional possible consequences; the approved export layout, Context evidence and all Core disclosure/verdict boundaries remain binding.

Implemented within Report Engine: versioned report-only mapping 1.0.0 from published Context category IDs to Betriebsfähigkeit, Finanzielle Auswirkungen, Informationen & Daten, Kontrolle & Vertrauen, Compliance & Haftung and Widerstandsfähigkeit & Wiederanlauf. Fixed German text describes possible consequences and action guidance only when corresponding evidence exists. Each theme contains observation, action, attribution, confidence and limits. Themes without evidence state no derivable impact; unknown or unmapped categories stay visible in the appendix. Counts deduplicate published result IDs within each theme and never add overlapping themes into a total. Summary and management overview precede six theme sheets; complete Context heatmap and method/technical domain appendix remain. Context Base Severity never becomes an impact rating. Core data, Context assignments and historical report archives are unchanged. The revised binding template records this user decision.

Verification: 44 focused Report Engine/export-button tests passed, including deterministic generation with network access stubbed to fail, overlap counting, empty/unknown categories, confidence, disclosure and input/storage invariance. Full `npm test`: 1,890 passed, 15 optional tests skipped; architecture, local-only, engine invariance and design checks passed. Client and server TypeScript checks passed. Final report-only table-width refinement passed all six affected renderer/export tests. A synthetic production-renderer preview was generated and inspected locally; it contains no customer data or remote assets. No customer report was generated or replaced. No phase is marked complete.

Remaining release step: Report renderer version advances 3.1.1 -> 3.2.0. Product-version reassessment recommends minor 2.15.2 -> 2.16.0 for this backward-compatible management-report capability. Package/lockfile, Core UI/API version tests, production builds and activation in the running backend await a current **Platform, Core Tests** release, as required by AGENTS.md; those Core files and the running backend were not changed for this request. Product version remains 2.15.2 until that release step is authorized and verified. Concurrent workspace changes are preserved.

Release completed (2026-10-04): the user's subsequent current **Platform, Core Tests** release authorized the remaining step. Minor product version 2.16.0 is synchronized in package/lockfile and Core UI/API version contracts. All 54 focused version, HTTP, Report Engine and export-button tests passed; both production builds passed, with the existing bundle-size warning only. The identified local backend was restarted with the verified bundle; health confirms 2.16.0, PostgreSQL and unchanged repository revision 540. The backend bundle contains renderer 3.2.0 and the new Business Impact template. The synthetic local preview was regenerated and returns HTTP 200 with version 2.16.0. New Management Reports use the new template; no customer report or historical archive was generated or replaced during release verification. The entire earlier report verification remains recorded above; no phase is marked complete and concurrent Client Info work is preserved.

## Data Hub - returning catalog versions update correctly (2026-10-04, Phase 7, 2.15.2)

Verified correction under current Reference Catalogs, Presentation, Platform and Core Tests consent. Reference recognition previously skipped a historical run with the same deterministic identity even when a newer run used different catalogs, leaving the status permanently pending after A -> B -> A. Reprocessing now checks the latest run's input, recognizer version and catalog hashes for unchanged work. Returning to a historical combination creates a new immutable reference run with a timestamp newer than previous runs and a distinct identity. Historical runs, source findings and reviews remain unchanged; no schema or repository contract changes are required. The existing detail panel explicitly reports an incomplete update when the subsequent status still contains pending scans, retains retry and only reports success when pending work is zero. No visual layout or theme change.

Verification: permanent synthetic service coverage includes repeated A -> B -> A transitions, a backwards-moving clock, unchanged retries and preserved historical runs/findings/reviews. Permanent click-path tests execute the real service through the API client boundary in both themes; incomplete-update feedback remains covered. All 26 focused tests passed. Full `npm test`: 1,888 passed, 15 optional tests skipped; local-only, architecture, engine invariance and design checks passed. Both production builds and UI/API version contracts passed. Patch 2.15.1 -> 2.15.2 records this backward-compatible correction; existing bundle-size warnings remain. The identified local backend was restarted from 2.15.0 to 2.15.2 against the unchanged canonical PostgreSQL datastore. LSW's regular reference-update API processed its one remaining pending scan after restart: 3 indexed scans, 0 pending. A second call returned 0 processed and 3 unchanged. This verification appended reference metadata only, with no reimport or destructive operation. Concurrent edits are preserved and no phase is marked complete.

## Data Hub - pending catalog references marked red (2026-10-04, Phase 7, 2.15.1)

Explicit user correction with current Presentation, Platform and Core Tests release: pending Catalog references recognition is important actionable maintenance and marks the client overview dot and Manage button red, including before client selection. This supersedes the earlier yellow overview treatment of pending references. A dedicated `reference-update` presentation state retains the reference-update explanation instead of classifying pending work as a processing failure. It takes precedence over yellow profile/re-evaluation/review notices; real processing errors retain priority and the tooltip preserves both causes. After successful recognition, the remaining processing state determines the color. The existing Catalog references detail panel and its Update references action stay intact; scanner outcomes, scores, imports and stored data are unchanged. No actual customer reference update was executed.

Verification: permanent synthetic DataHub interactions cover Dark/Light, initially unindexed and previously indexed outdated references, Manage/update/back, successful clearing, failed update and retry, status retry, catalog/import refresh and error priority. An additional check preserves a concurrent yellow profile-update task after reference recognition. Browser verification with synthetic clients confirms red pending-reference dots/Manage in both themes and green/red/yellow remaining states after simulated completion. All 24 focused tests passed; full `npm test`: 1,885 passed, 15 optional tests skipped. Architecture, engine invariance, local-only and design checks passed. Both production builds and UI/API version contracts passed; scoped diff whitespace checks clean. Patch 2.15.0 -> 2.15.1 records this backward-compatible UI correction. Existing bundle-size and unrelated React-key warnings remain. Concurrent edits and historical decisions are preserved; no phase is marked complete.

## Security Domains - strukturierte Zuordnung (2026-10-04, Phase 7 / Evaluation; umgesetzt, 2.15.0)

**Umsetzung und Verifikation (2026-10-04).** Die Umsetzung erfolgte mit Core-Freigabe `Evaluation, Ingest, Reference Catalogs, Presentation, Core Tests, Platform, Governance`; die Fortsetzung mit erneuter Freigabe `Evaluation, Ingest, Presentation, Core Tests, Platform`. Der Hook hatte die erste Freigabe nach einer Hintergrund-Benachrichtigung verworfen.

Umgesetzter Stand:
- **Klassifizierer:** ein einziger in `src/evaluation/security-domains.ts`, Version 2.0.0. Er liest nur Raw-Data-Felder; ein Werkzeug-Hinweis über die `toolId` des Blatts gilt für Einzelblätter ohne `Source: Scan`.
- **Zuordnungstabellen:** versioniert je Profil, in `src/profiles/{cis-cat,group-policy,maester,pingcastle,purple-knight}/*-security-domains.ts`. Maester akzeptiert auch die Feldnamen `Block`, `ID` und `Tag` (JSON-Listen).
- **Abgeleitete Raw-Data-Felder:**
  - `Benchmark section` für CIS-CAT (in `canonical-model-to-dataset.ts`).
  - Für Security-Template-Einstellungen ohne Vergleich: `Policy section`. Gelesen wird er aus dem ASSESSOR-eigenen Beobachtungstitel `<identity.section> · <identity.key>`, nur bei Übereinstimmung aller Quellen.
  - Für Security-Template `Registry Values`: `Registry path`, aus der Vergleichsidentität bzw. demselben Titel. Dieser Fall ergab sich erst aus der Dummy-Prüfung und betrifft 49 Einstellungen.
  - Offen: ein eigenes Projektionsfeld für Abschnitt und Schlüssel wäre sauberer. Es bräuchte Freigabe für Normalization und Disclosure.
- **Titelerkennung:** Sie ignoriert `Benchmark section` als Titelquelle (`record-builder.ts`).
- **Report:** `domainOf` nutzt den Work-Datensatz, über die Occurrence bzw. Scope und Technical Identity. Ohne Work-Datensatz greift der Klassifizierer auf die strukturierten Ergebnisfelder zurück.
- **Bereinigung:** Die `Unclassified`-Zweige in Client Info, Sidebar und Facet sind entfernt. Die Vereinbarungen in AGENTS.md sind ersetzt.
- **GPO-Tabelle:** Der Eintrag `File Security` ist entfallen, weil die Local-only-Prüfung das Wort `File` sperrt; er ergab dieselbe Domain wie die Auffangstufe.

Verifiziert:
- **Tests:** 13 neue synthetische Klassifizierer-Tests (eine Stufe je Test, keine `Unclassified`-Domain, Summe gleich Gesamtzahl, Unabhängigkeit vom Ergebnis, Werkzeug-Hinweis, Report-Rückfall). Dazu ein neuer Test, dass Report und Work für Scanner- und GPO-Ergebnisse dieselbe Domain liefern. Zehn bestehende Testdateien wurden an die neue Vereinbarung angepasst, darunter der dauerhaft beibehaltene Klickpfad-Test Client Info → Work-Facet.
- **Testsuite und Prüfungen:** `npm test` mit 1.882 bestandenen und 15 übersprungenen Tests; die Local-only- und Designprüfung bestanden.
- **Builds:** Beide Produktionsbuilds bestanden; die bekannte Warnung zur Bundle-Größe bleibt.
- **Version:** UI und API melden 2.15.0.
- **Browserprüfung mit dem freigegebenen Dummy:**
  - Client Info zeigt sechs Domains mit den Abweichungen Identity 112, Privileged 54, Infrastructure 19, Hardening 245, Cloud 7, Monitoring 40.
  - Der Klick auf System Hardening setzt das Work-Facet auf `hardening` mit 245 Datensätzen und Status `Deviation`.
  - Es gibt kein `Unclassified` und kein neues Facet `Benchmark section`.
- **Dummy-Verteilung nachher** (alle 1.833 Datensätze): Identity 302, Privileged 152, Infrastructure 58, Hardening 1.077, Cloud 149, Monitoring 95.
- **Herkunft der Zuordnungen:**
  - CIS: 411 über Stufe 2, davon 87 Pass und 323 Fail auf verschiedene Domains verteilt, statt 187 bei Identity.
  - Maester: 317 über die Stufen 1/3, 1 über Stufe 5.
  - PingCastle 37 und Purple Knight 119 über Stufe 1.
  - GPO: 880 über Stufe 4, 68 über Stufe 5.

Versionsentscheidung: Minor 2.14.3 → 2.15.0, weil sich die sichtbaren Domain-Kategorien und Domain-Pass-Raten ändern. Package, Lockfile und die Versionsverträge für UI und API sind synchronisiert. Historische Reports behalten ihre Domains. Für diese reine Neuzuordnung gespeicherter Felder ist kein Reimport und kein Verarbeitungsmanifest nötig. Die Phase wird nicht als abgeschlossen markiert.

Ursprünglicher Planungsstand: Bisher war nur die Planung erfolgt, noch kein Code geändert. Der Nutzer hat im Chat zwei Entscheidungen getroffen: **6 Domains** und **zuerst Plan plus Dummy-Vorher-Zahlen**. Die Umsetzung braucht eine eigene Core-Freigabe, die der Nutzer in seiner Nachricht selbst schreibt. Voraussichtlich nötig: `Evaluation, Ingest, Reference Catalogs, Presentation, Core Tests, Platform`. Die Freigabe-Zeile im eingefügten Vorschlag war nur ein Beispiel und gilt nicht als Freigabe.

**Problem (am Code bestätigt).** `src/features/dashboard/security-domains.ts` ordnet Prüfungen über Textmuster zu. Dabei gewinnt das erste passende Muster. Identity steht ganz oben und erkennt schon `user`, `account` und `password`. Die Beschreibung zählt mit, deshalb landet „Group Policy“ als Umsetzungsweg bei GPO. Die Maester-Suiten stehen in einer Feature-Datei statt im Profil. Außerdem gibt es zwei Klassifizierer: `securityDomainIdForRecord` für Work und Client Info, `securityDomainIdForUnifiedResult` für die Report-Projektion. Sie lesen unterschiedliche Felder.

**Entscheidung des Nutzers vom 2026-10-04 (wird mit der Umsetzung verbindlich).** Es gibt sechs Domains:
1. Identity & Authentication
2. Privileged Access & Delegation
3. AD Infrastructure & PKI
4. System Hardening
5. Cloud & Collaboration
6. Monitoring & Recovery

`GPO & Baseline` entfällt als Domain. Die GPO-Sicht bleibt über `Source: Scan = GPOs` und die GPO-Facets vollständig erhalten. Bei der Umsetzung werden diese Vereinbarungen in AGENTS.md abgelöst. Das braucht die Freigabe `Governance`:
- „Security Domain bietet alle acht Katalogeinträge“
- „reine GPO-Sicht = `GPO & Baseline`“
- die acht Knoten der Domain-Spine in Client Info
- die Domain-Pass-Raten im Report

`Unclassified` entfällt.

**Zielmodell.** Es gibt einen einzigen Klassifizierer in `src/evaluation/` für Work, Client Info, Work-Facet und Report-Projektion. Die Zuordnung hängt nur an der Prüfung, nie am Ergebnis. Pass und Fail folgen also denselben Regeln. Jede Prüfung bekommt genau eine Domain. Die erste Stufe mit einem Treffer entscheidet:
1. Native Kategorie bzw. exakte Regel-ID nach der Profiltabelle.
2. CIS-CAT-Abschnittstitel aus der Score-Tabelle desselben Laufs (`cis-benchmark-section-titles.ts`), nie die Nummer allein.
3. Maester-Suite bzw. Kontroll-ID.
4. GPO `Policy section` bzw. `Policy type`.
5. Auffangdomain je Quelle.

Jede Zuordnung trägt die Stufe und das Quellfeld mit. Je Quelle wird ausgewiesen, wie viele Prüfungen in Stufe 5 landen. Es gibt keine Textmuster über Titel oder Beschreibung. Die Tabellen sind versioniert und liegen im Scanner-Profil (analog `securityScoring`). Keine Abhängigkeit von der Context Engine.

**Dummy-Vorher-Stand (heutiger Klassifizierer, Projektblatt, 1.833 Datensätze, nur Zählwerte).**
- CIS-CAT (411):
  - Fail: `identity` 120, `gpo` 94, `hardening` 58, `authentication` 23, `infrastructure` 16, `cloud` 5, `privilege` 5, `recovery` 2
  - Pass: `identity` 67, `gpo` 8, `authentication` 4, `hardening` 2, `infrastructure` 2, `unclassified` 2, `privilege` 1, `recovery` 1
  - Die Härtung ist damit deutlich unterrepräsentiert.
- Maester (~ 330): fast alles `identity` (Fail 61, Pass 68, Skipped 86), nur 8 `cloud`. Das gilt auch für ORCA/Exchange.
- PingCastle (37): `identity` 25, `hardening` 4, `infrastructure` 3, `authentication` 2, `recovery` 2, `gpo` 1.
- Purple Knight AD (~ 120): überwiegend `identity`, 2 `unclassified`.
- GPOs (948): alle `gpo` (Fail 25, Pass 25, `Not configured` 879, `No baseline rule` 19).

**Verfügbarkeit der Quellfakten (Reimport-Prüfung).**
- CIS-CAT: Alle 411 Ergebnisse lösen einen Abschnittstitel desselben Laufs auf. Vorkommende Hauptabschnitte: Account Policies, Local Policies (Security Options, User Rights Assignment), System Services, Windows Defender Firewall, Advanced Audit Policy, Administrative Templates (Computer/User).
- Purple Knight: `Category` ist gespeichert. Werte: Account Security, AD Infrastructure Security, AD Delegation, Kerberos Security, Group Policy Security, Hybrid (AD).
- Maester: `Category`/Block ist gespeichert, ebenso die Regel-ID-Präfixe. Blocks: Maester/Entra, CISA, ORCA, EIDSCA, CIS, Exposure Management, Maester/Exchange, Teams, Intune, AzureConfig u. a. Präfixe: `CISA.MS.AAD`/`EXO`/`SHAREPOINT`, `EIDSCA.*`, `CIS.M365`, `MT.*`, `ORCA`.
- PingCastle: `Category` (Anomalies, Stale Objects, Privileged Accounts, Trusts) wird im HTML- und im XML-Pfad gespeichert, `Model` nur im XML-Pfad. Die Kategorie allein ist für Anomalies und Stale Objects zu grob. Vorschlag: eine exakte Regel-ID-Tabelle im Profil, mit der Kategorie als Rückfall. Dafür ist kein Reimport nötig, weil die Regel-ID immer gespeichert ist.
- GPO: Das Feld `Policy section` ist für Privilege Rights, System Access, Registry Values und Audit-Subkategorien gesetzt. Korrektur derselben Planung: Von den 825 Einstellungen ohne dieses Feld haben 810 einen gespeicherten Registry-Pfad. Das ist das Ziel `key` der technischen Policy-Identität. Die übrigen 15 sind Security-Template-Einstellungen (Kerberos Policy, Privilege Rights). Ihr Abschnitt steht strukturiert in `identity.target.section`. Stufe 4 liest deshalb die technische Identität: Security-Template- bzw. Audit-Abschnitt oder Registry-Schlüssel. Sie liest nicht die Feldbeschriftung oder den Titel.
  - Registry-Schlüssel werden über eine versionierte Präfix-Tabelle zugeordnet, der längste Treffer gewinnt. Der Vergleich ignoriert Groß- und Kleinschreibung, die Hive gehört nicht zum Schlüssel. Vorschlag:
    - `...\Windows\EventLog`, `...\PowerShell\ScriptBlockLogging`/`Transcription`, Audit → Monitoring & Recovery
    - `Control\Lsa`, `Kerberos`, `Biometrics`, `Windows\System` mit Logon-Werten → Identity & Authentication
    - `CredentialsDelegation`, `AdmPwd`/`LAPS`, `Services\NTDS` → Privileged Access & Delegation bzw. AD Infrastructure & PKI
    - `SystemCertificates` → AD Infrastructure & PKI
    - Defender, Firewall, FVE (BitLocker), Office, Internet Explorer, Edge, Tcpip, Netbt, LanmanServer, MrxSmb10, Print und alle übrigen Schlüssel → System Hardening
  - Die ADMX-Kategorie (Pfad in den Administrative Templates) ist im ADMX-Katalog nicht gespeichert. Sie würde eine Parser-Änderung und eine Neuauswertung der Baselines erfordern und ist für die Zuordnung nicht nötig.
  - Dummy-Verteilung der Schlüssel ohne Abschnitt: Internet Explorer 231, `Policies\Microsoft\Windows` 197, Office 191, Defender 51, Firewall 27 sowie kleinere Gruppen. `Policies\Microsoft\Windows` wird eine Ebene tiefer unterschieden.

**Nutzervorgabe 2026-10-04: Zuordnung grundsätzlich über Raw Data.** Raw Data entspricht `record.fields` mit Wert (`RawDataView.tsx`). Prüfung am Dummy-Projektblatt:
- PingCastle (37): `Source Rule ID` und `Category` sind zu 100 % vorhanden. `Model` fehlt (HTML-Import). Die Regel-ID-Tabelle reicht.
- Purple Knight (119): `Category` und `Source Rule ID` sind zu 100 % vorhanden. Reicht.
- Maester (318): `Category`/Block, `Source Rule ID` und `Tags` sind zu 100 % vorhanden. Reicht.
- CIS-CAT (411): **Lücke.** Raw Data enthält nur `Source Rule ID` (Nummer), `Benchmark Item` und `Control Mappings`, keinen Abschnittstitel. Der Titel steht nur in der Section-Score-Tabelle des Berichts und in der Record-Eigenschaft `benchmarkSectionTitles`. Vorschlag: ein zusätzliches Raw-Data-Feld `Benchmark section` mit dem Titelpfad aus derselben Lauftabelle, ohne Reimport. Alternativ dienen die nativen `Control Mappings` (CIS Controls) als gröbere Stufe.
- GPO (948): `Policy type` 100 %, `Registry path` 85 %, `Policy section` 13 %. **Lücke bei 15** Security-Template-Einstellungen mit `No baseline rule`: Sie haben weder Abschnitt noch Pfad. Abschnitt und Schlüssel stehen nur im erzeugten Titel, `Technical Identity` ist ein Hash. Vorschlag: `Policy section` auch für diese Zeilen aus `identity.target.section` füllen, statt den Titel zu zerlegen.
- `Source: Scan` (Stufe 5) ist überall zu 100 % vorhanden.

Ergebnis: Es ist voraussichtlich kein neues Verarbeitungsmanifest und kein Reimport nötig. Die Zuordnung liest nur bereits gespeicherte Felder.

**Entscheidungen des Nutzers vom 2026-10-04 (zweite Runde).**
- CIS-CAT bekommt das neue Raw-Data-Feld `Benchmark section`. Es enthält den Titelpfad aus der Section-Score-Tabelle desselben Laufs. Bei fehlendem oder mehrdeutigem Titel bleibt das Feld weg, es wird nichts erraten. Stufe 2 liest dieses Feld.
- Entra-Prüfungen (EIDSCA, CISA.MS.AAD, Maester/Entra, Conditional Access, MFA, Identity Protection) gehören zu `Identity & Authentication`. Exchange, Teams, SharePoint, ORCA, Intune und die übrige Tenant-Konfiguration gehören zu `Cloud & Collaboration`.
- Purple Knight `Group Policy Security` gehört zu `System Hardening`.
- GPO: `Policy section` wird auch für Security-Template-Zeilen ohne Baseline-Regel aus `identity.target.section` gefüllt. Das ist ein Vorschlag aus der Raw-Data-Prüfung, den der Nutzer nicht ausdrücklich beantwortet hat. Er ist als Teil der Umsetzung vorgesehen, sofern der Nutzer nicht widerspricht.

Damit sind alle inhaltlichen Fragen geklärt. Offen ist nur noch die Core-Freigabe, die der Nutzer selbst schreibt.

**Risiken.**
- `Not configured`-GPO-Einstellungen verteilen sich künftig auf Domains. Zu prüfen ist, dass sie in Domain-Scores weiterhin score-neutral bleiben.
- Gespeicherte lokale Facet-Auswahlen mit `gpo` oder `unclassified` müssen beim Laden still und sichtbar entfallen.
- Die Report-Pass-Raten ändern sich. Historische Reports behalten ihre Werte.

**Abnahme.**
- Synthetische Tests je Profil, eine Stufe pro Test.
- Kein `Unclassified`. Die Summe der Domains entspricht der Gesamtzahl.
- Gleiche Domain für dieselbe Prüfung in Work, Client Info und Report.
- Der Regressionstest für den Klickpfad Client-Info-Drilldown → Work-Facet bleibt erhalten.
- Dummy-Nachher-Verteilung gegen den Vorher-Stand oben.
- Versionsentscheidung (Minor, weil sich die sichtbaren Domain-Kategorien ändern) nach Abnahme.

## Operating systems - EOL overview removed (2026-10-04, Phase 7, 2.14.3)

Explicit user decision supersedes the earlier EOL overview-field implementation: remove `EOL OS` from the Operating systems tile because the lifecycle-reference effort does not provide enough value. Current Core release covers Presentation, Platform and Core Tests. The tile again uses only its existing source-backed inventory facts, with the existing empty Inventory marker. Original report tables and the Results interaction remain unchanged; no lifecycle catalogue, evaluation, reimport, migration or stored-data change is introduced. Historical decisions and source-verification notes below remain intact.

Verified: permanent synthetic interaction checks in Dark and Light assert that the tile contains no EOL field even when a retained source value exists, preserves inventory facts, opens original Results evidence and leaves the snapshot unchanged. Empty tiles also omit the EOL placeholder in both themes. Browser inspection with synthetic data confirms Dark/Light and the Results interaction. Full `npm test`: 1,869 passed, 15 optional tests skipped; local-only, design, architecture and engine-invariance checks passed. Both production builds, product-version UI/API contracts and scoped diff whitespace checks passed. Existing client bundle-size and unrelated React-key warnings remain. Patch 2.14.2 -> 2.14.3 records this backward-compatible presentation correction; package/lockfile and version contracts are synchronized. No phase is marked complete; concurrent workspace edits are preserved.

## EOL OS - source verification correction (2026-10-04, Phase 7 / 13C)

User reports that EOL OS does not work. Read-only audit found that the preceding implementation and test only accept a hypothetical `EOL OS` column: the synthetic import test explicitly injects that table into the fixture. This proves parser handling, not that a normal PingCastle export supplies the value. Public source verification of `netwrix/pingcastle` master found no EOL aggregate in `ReportHealthCheckSingle.cs`'s computer-account/OS table generator and no direct EOL aggregate in the inspected `HealthcheckData.cs`. Therefore the prior statement that EOL is a supported native overview value is not established and must not be repeated as verified scanner coverage.

PingCastle does publish individual ObsoleteOS rules, for example `S-OS-2012` in `HeatlcheckRuleStaledObsolete2012.cs`; this rule reads OS occurrence counts and respects a paid-support override. Such findings can be displayed as native scanner evidence, but they are not a complete, overlap-free EOL inventory. Missing rule findings do not establish zero EOL systems. Public sources: https://github.com/netwrix/pingcastle/blob/master/PingCastleCommon/Report/ReportHealthCheckSingle.cs and https://github.com/netwrix/pingcastle/blob/master/PingCastleCommon/Healthcheck/Rules/HeatlcheckRuleStaledObsolete2012.cs . No customer report was inspected and no Core file was changed in this audit. The unsupported overview field remains pending explicit current Core consent for its correction; no phase is marked complete. Historical verification notes below are retained and superseded by this source-coverage correction.

## Operating systems - EOL OS field (2026-10-04, Phase 7)

Explicit user request and current Ingest, Normalization, Presentation, Platform and Core Tests release: Client Info's Operating systems tile now reserves its second fact for `EOL OS`, including narrow tiles that display only two facts. It reads an explicit retained PingCastle Computer Information total with an EOL OS/OS EOL/end-of-life OS label. Zero is preserved; missing, malformed, unassessed, contradictory or multiple source totals show the existing unknown marker. No lifecycle judgement is inferred from an OS name or current vendor lifecycle dates, and separate reports/rows are never added. Results now includes the original EOL table alongside the OS inventory, with existing native evidence and source references. The generic importer already retains these fields, so no extractor, mapping, native overall score, persistence, migration or reimport changes were required.

77 focused synthetic import, OS-tile/Results, dashboard, evidence, architecture and UI/API-version tests passed. Permanent interactions cover both themes, the visible second fact, Original Results and unchanged observations; count checks cover zero, invalid, absent and multiple/conflicting sources. Browser inspection confirmed Dark/Light with synthetic data and the native EOL table under Results. Local-only and design checks passed. Patch 2.14.1 -> 2.14.2 records this backward-compatible presentation refinement; package/lock and UI/API version contracts are synchronized. Existing imported reports without an explicit retained EOL total remain unknown; actual customer report coverage was not validated. No phase is marked complete, concurrent changes preserved.

Final verification for the EOL OS batch: both production builds passed, including TypeScript checking of the synthetic fixtures; the final 12-test PingCastle import rerun passed and scoped `git diff --check` is clean. Existing client bundle-size warning remains.

## Cloud Information - konkrete Istwerte (2026-10-04, Phase 13C / 7, 2.14.2)

Nutzerkorrektur mit aktueller Core-Freigabe Ingest, Normalization, Presentation, Platform und Core Tests: Vier identische Verfuegbarkeitshinweise haben keinen ausreichenden Aussagewert. Die dauerhaft sichtbare Kachel zeigt jetzt je Cloud-Bereich einen konkreten, ausdruecklich berichteten Wert, etwa Authentifizierungsmethode, berichtete permanente Rollenzuweisungen, Admin-Consent-Request-State oder Gastrolle. Dies ersetzt die unten historisch dokumentierten Verfuegbarkeitshinweise aus 2.14.1. Fehlende/unassessed/unklare Werte erscheinen als `Not reported`; Konflikte werden sichtbar. Weitere Fakten und komplette Originalnachweise bleiben ueber Results erreichbar. Kompakte Labels und ein Wert pro Feld erhalten die gemeinsame 14px/16px-Typografie und quadratische Kachel ohne Inhalts-Scrollbar in den geprueften synthetischen Beispielen.

Die pure Normalisierung liest ausschliesslich bereits erhaltene Maester-Testdetails mit exakter nativer Regel-ID und ausdruecklichen Istwert-Templates/Tabellen. Passed/Failed oder Empfehlungen liefern niemals Konfigurationswerte. Zahlen werden als berichtete Testteilmengen gekennzeichnet, nicht als vollstaendige Tenant-Inventare. Mehrere Scan-/Tenant-Scopes werden nicht zusammengerechnet, widerspruechliche Quellen nicht aufgeloest. Offizielle Generatoren und Microsoft-Semantik wurden geprueft; Offline-Mapping und Grenzen stehen in `docs/CLIENT_INFORMATION.md`. Keine Onlineabfrage zur Laufzeit und keine Kundenberichte als Testdaten.

Der rueckwaertskompatible Client-Information-Lesevertrag 1.1.0 ergaenzt `cloudFacts` fuer den vollstaendig gefilterten Scope vor Pagination, mit kanonischer Property, Wert, Quellen-/Scan-/Dateibezug, Quellzeit, Scope und Mapping-Version. Future Engines nutzen weiterhin ausschliesslich den veroeffentlichten read-only Port. Keine Persistenz-, Schema-, Finding-, Score-, Result-DB- oder Engine-Aenderung. Bereits erhaltene passende Nachweise profitieren ohne Reimport; fehlen sie, bleibt regulaerer Reimport notwendig. Profil-/Extractor-Versionen bleiben unveraendert, da keine neue Extraktion stattfindet; der bestehende native Maester-Overall-Score-Vertrag bleibt erhalten.

Verifiziert: 23 fokussierte Leseport-/Cloud-/UI-/Importtests sowie 49 Import-/Scoring-/Architekturtests bestanden. Permanenter synthetischer UI-Test prueft vier konkrete Bereiche, Results mit Originaltabelle, Dark/Light, leere dauerhaft sichtbare Kachel und unveraenderte Quellen; die echte Dashboard-Interaktion bleibt abgedeckt. Drei Importformate liefern dieselbe Source-backed Normalisierung ohne veraenderte Finding-Outcomes. Vollstaendiges `npm test`: 1.867 bestanden, 15 optionale Tests uebersprungen; Local-only-/Design-, Architektur-, Disclosure- und Engine-Invarianztests bestanden. Browserpruefung bestaetigt Dark/Light, konkrete vier Felder, Results-Aufruf und leere Kachel. Beide Produktionsbuilds, UI/API-Versionsvertraege und `git diff --check` bestanden. Zwischenzeitliche Typfehler paralleler OS-Workspace-Aenderungen wurden dort korrigiert; anschliessender Build erfolgreich. Bestehende Bundle-Groessenwarnung bleibt; kein Meilenstein neu als abgeschlossen markiert.

Versionsentscheidung: Patch 2.14.2 als Verfeinerung der bestehenden Client-Information-Faehigkeit; die bereits parallel vorbereitete gemeinsame Package-/Lockfile-/UI-/API-Version 2.14.2 wurde beibehalten statt pro Teilbearbeitung weiter zu inkrementieren. Gleichzeitige lokale Arbeiten und historische Entscheidungen bleiben erhalten. Grenzen: ausschliesslich deklarierte native Ausgabeformen; keine pauschale Aussage ueber komplette Cloud-Konfiguration, eligible/permanent Gesamtzahlen oder Report-only-Policies.

## Engine outlines - contrast correction (2026-10-04, Phase 7)

User rejected the first outline as visually indistinguishable from related ordinary tiles and requested explicit Light-mode consideration. The engine identity frame now uses a 2px shared emphasis outline in the theme's neutral secondary-text color, including the left marker: light grey in Dark, dark grey in Light. It no longer shares the faint related-node border color. Blue remains the keyboard-focus role; yellow remains the selected frame and related-arrow role. The generic `engine: true` contract continues to apply to future Engines. This entry corrects the visual acceptance of the preceding implementation without rewriting its history.

Permanent Dark/Light interaction checks now guard the stronger identity outline as well as deselection and unchanged arrow behavior. 24 focused diagram, architecture and UI/API-version tests passed; browser inspection confirmed all three unselected Engine frames in both themes and yellow selection with exactly three highlighted Context connections. Both production builds and local-only/design checks passed. Version remains 2.14.1: correction of the same current UI batch, no independent capability release. No data, persistence, relationship or phase-completion change; unrelated workspace changes preserved.

## Engine outlines - user decision and implementation (2026-10-04, Phase 7)

Explicit user decision applies to every current and future Engine: its Data Flow tile always has a subtle neutral frame. Only selecting the Engine highlights its frame and related arrows in yellow; hovering or deselecting leaves arrows neutral. The shared engine style now supplies the full neutral border, and node descriptors declare `engine: true` instead of relying on a hardcoded list of three IDs. Future Engine descriptors must use this declaration to inherit the same visual contract. Existing initial Core selection, relationships and data flows remain unchanged.

Verified under the current Presentation, Platform and Core Tests release: 24 focused diagram-interaction, UI/API-version and architecture tests passed. Permanent synthetic interaction tests cover all three Engines, hover, selection and deselection in both themes. Browser inspection of the production component with synthetic data confirmed neutral unselected frames and yellow selected relationships in Dark/Light. Both production builds, local-only/design checks and `git diff --check` passed. Existing bundle-size warning remains; no persistence or engine behavior changed and no phase is marked complete. Product version retained at the already prepared 2.14.1 as part of the current shared patch batch; concurrent workspace changes preserved.

## Cloud Information - dauerhaft sichtbare Kachel (2026-10-04, Phase 7, 2.14.1)

Explizite Nutzerkorrektur: Die Cloud-Information-Kachel wird immer angezeigt, auch wenn keine Cloud-Nachweise importiert sind. Dies ersetzt die vorherige bedingte Einblendung als Vorschlag. Nach aktueller Core-Freigabe fuer Presentation, Platform und Core Tests ist die Kachel in der bestehenden Client-Info-Umgebungskachelreihe umgesetzt: vier Felder fuer Sign-in/Conditional Access, Rollen/Berechtigungen, Application consent und externen Zugriff/Sharing. Vorhandene beobachtete Nachweise erscheinen als `Source evidence available`; sonstige vorhandene Nachweise als `Source evidence not assessed`; fehlende als `No retained information`. Test-Outcomes liefern keine erfundenen Konfigurationswerte. Die Kachel verwendet die bestehenden quadratischen Kachelstile, vier Fakten, 14px Labels/16px Werte und den normalen Results-Button.

Results oeffnet den bestehenden Client-Information-Browser mit den vier Cloud-Bereichen und dem exakten Mandanten-/Timeslot-/Scan-Scope. Die Bereichsauswahl und Reset behalten den Cloud-Scope bei. Ohne gespeicherten Mandanten bleibt die Kachel sichtbar und Results zeigt den vorhandenen leeren Quellenhinweis. Scopewechsel schliessen das bisherige Datenfenster durch den Scope-Key. Der allgemeine Client-Information-Button bleibt unveraendert erreichbar. Keine neue Extraktion, Tabelle, Persistenz, API-/Engine-Beziehung oder Datenfluss; Work-Filter und Core-Werte bleiben unveraendert.

Verifikation: vollstaendiges `npm test` erfolgreich, 1.854 Tests bestanden, 15 uebersprungen; Local-only-/Design-, Architektur- und Engine-Invarianzpruefungen bestanden. Permanente synthetische Dashboard-Interaktionen pruefen Dark/Light, immer sichtbare vier Cloud-Felder ohne Daten, beobachtete und nicht bewertete Nachweise, den echten Results-Aufruf mit Originaldetails, Cloud-Filter/Reset, unveraenderte Work-Filter und deaktivierte optionale Engines. Bestehende Kachelanzahlpruefungen wurden um genau die neue Kachel erweitert. Browserpruefung mit synthetischen Daten bestaetigt Dark/Light, leere sichtbare Kachel und leeren Results-Aufruf. Beide Produktionsbuilds und UI/API-Versionsvertraege bestanden; `git diff --check` ohne Fehler. Laufender Backend-Healthcheck: 2.14.1, PostgreSQL.

Versionsentscheidung: Patch 2.14.0 -> 2.14.1 als UI-Ergaenzung des bestehenden Client-Information-Vertrags; Package/Lockfile und Versionsvertraege synchronisiert. Bestehende Bundle-Groessenwarnung und fremde React-Key-Testwarnung bleiben bestehen. Keine Phase als abgeschlossen markiert, keine Kundenberichte gelesen oder reimportiert, gleichzeitige lokale Arbeiten erhalten. Neue Maester-Nachweise erfordern weiterhin regulaeren Reimport; die Kachel behauptet weder vollstaendige Cloud-Konfiguration noch einen Livezustand.

## Client Information - Umsetzung 2026-10-04 (Phase 13C / 7; Version 2.14.0)

Nach expliziter Core-Freigabe fuer Ingest, Normalization, Store, Presentation, Platform und Core Tests ist der unten dokumentierte Auftrag umgesetzt und synthetisch verifiziert. Der neue Core-Lesevertrag `ClientInformationReadPort` 1.0.0 und der HTTP-Zugang `/projects/:id/client-information` erschliessen den vorhandenen Beobachtungs-/Berichtsbestand gezielt nach Mandant, Timeslot, Scanlauf, Bereich, Eigenschaft, Objekt, Scanner und Erfassungszustand. Client Info bietet dafuer den Button **Client Information** mit Filterung, Originalwerten/Tabellen, Provenienz, Details, Pagination und Retry. Optional deaktivierte Engines beeintraechtigen ihn nicht. Bestehende Snapshot-, Finding-, Review- und Exportvertraege bleiben erhalten; technische Additional-Information-Felder im Finding Reader wurden nicht pauschal umbenannt.

Entscheidungen: vorhandene Core-Tabellen weiterverwenden, keine Migration oder Datenkopie; aktuelle nicht ersetzte Importlaeufe als Standard, historische Laeufe nur explizit; keine Zusammenfuehrung widerspruechlicher Quellwerte und keine Livezustandsbehauptung. Jede Abfrage wird gegen die committed Repository-Revision geprueft. Exakte Quellverweise behalten ihre eindeutigen Ziele auch ueber Abschnittsseiten hinweg. Engines erhalten ausschliesslich den veroeffentlichten Leseport, gebunden an read-only Repository-/DB-Zugriff; bisherige Engines wurden nicht auf andere Inputs umgestellt. Die Data-Flow-Beschreibung des vorhandenen kanonischen Bestands nennt Client Information und den Leseport; es gibt keine neuen Tabellen oder Engine-Schreibbeziehungen.

Mehrwert: Maester 1.2.0 ergaenzt bekannte Cloud-Testdetailwerte aus HTML und Excel/CSV zu Authentifizierung/Conditional Access, Rollen, App-Zustimmung und externem Zugriff/Sharing. Originaltext und enthaltene Tabellen bleiben erhalten. Alle neuen Werte sind als `reported-test-evidence`, `inventoryComplete: false` mit exakter nativer Regel-ID und Quellstatus gekennzeichnet. Ein Teststatus wird niemals als Konfiguration interpretiert. Der native Overall-Score-Vertrag wurde geprueft und bleibt bei der expliziten Nichtverfuegbarkeit eines numerischen Gesamtscores; die gemeinsame Scoringlogik bleibt unveraendert. Historische Verarbeitungsmanifeste bleiben erhalten, fruehere Maester-Importe empfehlen Reimport. Es wurde kein Kunden-Reimport ausgefuehrt.

Verifikation: vollstaendiges `npm test` erfolgreich, **1.853 Tests bestanden, 15 uebersprungen** (darunter die nicht aktivierten echten PostgreSQL-Integrationstests). Neue synthetische Tests pruefen drei Importformate, unveraenderte Finding-Outcomes und Originalwerte, fehlende/unbekannte Nachweise, read-only PostgreSQL-Abfragen, Scopes/Historie, Revisionen, Pagination/Links, HTTP-Validierung und die echte Dashboard-Interaktion in beiden Themes inklusive Apply/Reset/Retry und veralteter Antworten. Architektur-, Engine-Invarianz-, Scoring-, Disclosure-, Local-only- und Designpruefungen bestanden. Veraltete Client-Info-Tests wurden an die bereits verbindliche Directory-Integration vom 2026-10-02 angepasst, mit vollstaendigen Domain-Information-Result-Pruefungen. Synthetische Browserpruefung bestaetigt Dark/Light, vorhandenes Datenfenster und Eigenschaftsfilter. Beide Produktionsbuilds und UI/API-Versionsvertraege bestanden, `git diff --check` ohne Fehler. Der laufende Backend-Healthcheck meldet 2.14.0 und PostgreSQL. Keine Kundendaten wurden fuer Implementierungstests gelesen.

Versionsentscheidung: rueckwaertskompatible neue Abfragefaehigkeit, daher Minor 2.13.5 -> **2.14.0**; Package, Lockfile und Versionsvertraege synchronisiert. Historische Report-/Versionsangaben bleiben unveraendert. Bestehende Warnungen fuer Client-Bundlegroesse und einen React-Key in einem fremden RichTextValue-Test bleiben bestehen. Keine Phase als abgeschlossen markiert; gleichzeitige lokale Arbeiten erhalten.

Offene Grenzen/Risiken: Vollstaendige Cloud-Konfigurationsinventare sind nicht durch Testnachweise ersetzt; unbekannte JSON/XML-/Exportstrukturen benoetigen weitere quellengestuetzte Profilerweiterungen. Die konkrete Abdeckung echter Kundenberichte wurde nicht verifiziert. Neue Extraktionen werden erst bei einem gesonderten regulaeren Reimport sichtbar. Der Port filtert derzeit den vorhandenen scoped Snapshot im Backend, nicht per neuen SQL-Indizes; grosse Scopes koennen entsprechend Arbeitsspeicher benoetigen. Mehrseitige Leser muessen Revisionen vergleichen. Interne Daten bleiben den bestehenden UI-/Export-Disclosure-Regeln unterworfen. Details, genaue ID-/Formatabdeckung und Engine-Nutzung: [CLIENT_INFORMATION.md](CLIENT_INFORMATION.md).

## Client Information - urspruenglicher Nutzerauftrag 2026-10-04 (Planungsstand vor Freigabe)

Der Nutzer benennt den bisher als Zusatzinformationen bezeichneten scannerbezogenen Mandanteninformationsbestand **Client Information**. Der Bestand soll alle bisher gewonnenen Informationen erhalten und gezielt sowohl fuer die heutige ASSESSOR-Anwendung als auch fuer spaetere Engines abrufbar sein. Dazu kommen die besprochenen Cloud-Konfigurationsinformationen, soweit die Originalberichte sie tatsaechlich enthalten. Dies ist eine dokumentierte Anforderung, noch keine implementierte oder verifizierte Core-Aenderung.

Umsetzungsumfang und Abnahmeentwurf:

- Den vorhandenen Bestand aus `EnvironmentObservation` und `ScannerReportSection` als Grundlage verwenden: Originalwerte, komplette Abschnitte/Tabellen, Erfassungszustaende und Datei-/Scan-Provenienz bleiben erhalten. Die einheitliche fachliche Bezeichnung lautet Client Information.
- Einen versionierten, gezielt abfragbaren Lesevertrag bereitstellen: Mandant, Assessment/Timeslot, Scanlauf, Informationsbereich, Eigenschaft und betroffenes Objekt. Client Info und Engines lesen denselben abgegrenzten Datenstand. Stabile fachliche Schluessel erlauben den Abruf ohne UI-Textsuche oder erneutes Parsen durch eine Engine.
- Der Jetzt-Zustand bezeichnet den aktuellen importierten Stand im gewaehlten Scope, mit Scan-/Erfassungszeit und Repository-Revision; er behauptet keinen Livezustand der Kundenumgebung. Historische Laeufe bleiben adressierbar. Widerspruechliche oder unterschiedlich alte Quellen bleiben zugeordnet sichtbar und werden nicht still zusammengefuehrt.
- Zusaetzliche Cloud-Bereiche anhand der tatsaechlichen Quellfelder erschliessen: Anmeldemethoden und Conditional-Access-Konfiguration samt berichteten Ausnahmen; Cloud-Rollen und berichtete aktive/berechtigte Zuweisungen; App-Consent-, Gastzugriffs- und externe Freigabeeinstellungen. Ein vorhandener Test oder Findingtitel beweist weder das Vorliegen der Konfigurationswerte noch ein vollstaendiges Inventar. Fehlende Angaben bleiben ausdruecklich fehlend.
- Engines konsumieren Client Information ausschliesslich ueber deklarierte Read-only-Ports und Read-only-Datenbankzugriff; der Bestand gehoert zum Core. Bestehende Privacy-/Disclosure-Regeln gelten auch fuer den neuen Lesevertrag. Keine engineeigene Kopie oder Schreibmoeglichkeit in Core-Daten.
- Namensaenderungen nach fachlicher Bedeutung vornehmen: Die bisherige Finding-Reader-Rubrik `Additional Information` enthaelt auch technische Einzelbefundfelder und ist nicht automatisch identisch mit dem Mandanteninformationsbestand. Keine pauschale Text-Ersetzung als Ersatz fuer den gemeinsamen Informationsvertrag.
- Synthetisch pruefen: gezielter Abruf bestehender und neuer Informationen, Scope-/Mandantentrennung, historische Datenstaende, fehlende/widerspruechliche Werte, Herkunftstreue, identische UI-/Engine-Grundmenge sowie unveraenderte Findings/Verdicts/Scores und Engine-Invarianz. Betroffene UI-Interaktionen dauerhaft absichern.

Bestandspruefung: `getEnvironmentSnapshot` existiert bereits im Repository und in der API; Context- und Report-Read-Ports nutzen ihn. Der jetzige Snapshot-Query grenzt nach Mandant, Assessment und Scanlaeufen ein; fachlich gezielte Abfragen sind darauf aufbauend zu gestalten. Die konkrete Cloud-Feldabdeckung der Kundenberichte ist noch nicht verifiziert. Bestehende Importe erhalten neue extrahierte Werte nur durch einen gesonderten regulaeren Reimport.

Core-Umsetzung wartet auf die Freigabe der betroffenen Bereiche Ingest, Normalization, Store, Presentation, Platform und Core Tests. Eine Schemaaenderung oder ein Reimport wurde weder vorgenommen noch durch diese Dokumentation freigegeben; falls erforderlich, gelten die bestehenden Backup-/Migrationsregeln. Dokumentationsaenderung ohne Produktversionsanhebung, ohne Laufzeitaenderung und ohne Phasenabschluss.

2026-10-02 - Phase 7 / approved Management Export assignment wording (Report renderer 3.1.1, verified): User explicitly selects Nach Katalog, Nach Befundmerkmalen and Thematisch eingeordnet. New Management Reports use these labels consistently in the reading key, category assignment tables and count summaries. Descriptions use plain technical/content-clue wording; thematic assignments explicitly remain pending professional confirmation. Report-authored Geschätzt/geschätzt and deterministic/anchor wording are removed from Management HTML. Internal catalogued/recognized/estimated values, counts, technical export, source data and historical archives are unchanged. The permanent Report Engine template records this user decision.

18 focused management, report-run/narrative, boundary and invariance tests passed, including a new synthetic export test with nonzero counts in all three tiers, exact labels throughout, preserved qualification and unchanged input. Synthetic management preview regenerated through the production renderer; server production build and design/local-only checks passed. Management renderer patch 3.1.0 -> 3.1.1 records the editorial change in new archive metadata. Product version reassessed and retained at 2.13.5: this is a terminology-only Report Engine edit with no Core/product capability, schema, data or layout change. No Core source/test/version files were edited. Existing local backend restarted to activate the renderer, retaining canonical PostgreSQL; frontend API health is ok. No phase completion or new dataflow relationship, no full-suite rerun.


2026-10-02 - Phase 7 / Activity reload control (2.13.5 patch, verified): Current Presentation/Core Tests/Platform release adds the requested neutral circular-arrow button immediately after History when loading ends incomplete or cancelled and no task remains active. Accessible name/title Reload application; mouse or native Enter reloads the current application page through window.location.reload. The same action remains available beside a manually minimized incomplete Activity indicator. It does not mark failures as recovered, clear history or alter readiness; running/queued work and recovered Ready suppress it. Existing green Ready dot, manual minimization, five-second automatic minimization and historical failure behavior remain. Shared button geometry, token-sized SVG and both themes retained.

Permanent synthetic React interactions in Dark/Light verify presence after failure, click callback from expanded/minimized states, unchanged activity records, absence while running and after same-operation recovery despite historical failure. 24 Activity/UI/API version tests passed; both production builds, design/local-only checks and diff check passed. Browser synthetic preview verified native Enter and mouse reload navigation, both themes and visible compact geometry; screenshot saved. Patch 2.13.4 -> 2.13.5 with package/lock/version contracts synchronized. No persistence, API/dataflow or engine relationship change, backend restart or full-suite rerun; existing bundle-size warning remains.


2026-10-02 - Phase 7 / approved Management Report template retained: user explicitly approved the implemented report and requested a permanent template inside Report Engine. Added src/reporting/MANAGEMENT_REPORT_TEMPLATE.md with binding visual/content/data contracts and linked it from REPORT_STRATEGY.md. Existing renderer remains the executable template. Documentation-only; no product version change or runtime changes. Dataflow inspection found Context -> Report still marked Planned in EngineDataFlow.tsx despite the implemented publication bridge; diagram update remains a separate Presentation/Core Tests/Platform released request. No phase completion claimed.

2026-10-02 - Phase 7 / Client Info layout rollback (2.13.4 patch, verified): Explicit user correction "Setz alles wieder zurueck! Wieder wie vorher!" followed by current Presentation/Core Tests/Platform release supersedes the compact-workspace selection documented below. Only the last Client Info layout batch is reverted: Overall Score and Security Domains again sit side by side with the established connectors, Data and Domain Information use their previous arrangement, the compact Context heatmap is full-width underneath, and square environment tiles return to their horizontally scrollable row. Original coverage/ring dimensions, responsive breakpoints and environment-tile first-read disclosure are restored. Accepted Risks and all earlier functionality, including six clickable Data facts, complete Domain Information Results, heatmap totals/cluster drilldowns, engine preferences and report actions, remain intact. No unrelated concurrent changes were reverted; frontend/backend continue running against the canonical datastore.

The permanent synthetic full-Dashboard regression now checks this restored layout in both themes, preserved source values/Core counts, complete native Domain Information Results and the exact Context-to-Work click. 63 focused layout, popup, disclosure, risk, report, engine-boundary/invariance and UI/API version tests passed; both production builds and design/local-only checks passed. Synthetic browser inspection confirms the restored geometry, both themes and 14px labels/16px values; screenshot saved. Product patch 2.13.3 -> 2.13.4 records the verified rollback without rewriting historical release/report versions. Existing client bundle-size warning remains. No schema/dataflow change, backend restart, full-suite rerun or phase completion claim.


2026-10-02 - Phase 7 / management report reference layout (2.13.2 patch, verified): User-provided Huntsman page explicitly becomes the exported Management Report's layout/style reference: white report sheets, ASSESSOR logo in header/footer, orange headings, dark table headers, alternating light rows, two-column explanatory/evidence blocks and factual bar charts. This export-only user decision supersedes earlier app-style guidance for this report's palette/layout; Core application views and tokens stay unchanged. Existing ASSESSOR logo and Inter are embedded offline. Overview and heatmap precede one sheet per populated Context category; each shows catalog description, separate scanner/GPO counts, category Base Severity, confidence and source attribution, followed by scope/method appendix. Footers number logical report sheets, not physical PDF pages. No invented time series, score, impacted endpoint count, ownership or business consequence. Coverage chart uses published assessed counts; category bars use published scanner/GPO counts. 51 distinct focused report/invariance/export/UI/API version tests passed (module-list sort corrected and rechecked), both production builds and design/local-only checks passed. Browser synthetic preview has loaded logo, two-column/table/chart layout and no horizontal overflow at the normal viewport. No PDF pagination or real customer regeneration acceptance claimed. Provided downloaded HTML was inspected read-only and remains unchanged. Product/lock/version contracts synchronized; no backend restart, no schema or engine relationship change; phase remains in progress.

2026-10-02 - Phase 7 / Client Info, selected compact workspace (2.13.3 patch, implemented and verified): User explicitly selected the attached third proposal, Kompakter Arbeitsbereich, then released Presentation, Core Tests and Platform. The existing Client Info now groups Overall Score and coverage, all Security Domains and the Context heatmap in the left analysis column; Data with its six clickable facts, Domain Information and all five Environment groups occupy the right column. Accepted Risks remains the existing full-width list/detail register below. This chosen layout supersedes the earlier six-square-tile environment row and side-by-side posture arrangement: environment groups are stacked flat reading surfaces, with existing first-read fields and complete Results retained. Decorative ring-to-domain connectors are hidden in the stacked arrangement; scores, source-balanced computation, population semantics, source selection, report actions, engine choices, native evidence, risk records and Work drilldowns are unchanged. No API request, parsing, persistence or engine relationship was added. The heatmap retains its compact 186px tiles with up to four columns, all 22 categories and unique Finding count. Narrow containers stack the columns; the shared root inset remains 20px and fields retain 14px labels/16px values in both themes.

Verification: permanent synthetic full-Dashboard interaction tests in Dark/Light check left/right placement, all eight domains plus applicable Unclassified, six Data facts, five environment groups, full-width risk register, all 22 heatmap categories, unchanged Core values when enabling Context, opening all eleven Domain Information fields and original evidence, closing Results and selecting the exact Work cluster, with unchanged input data. Existing six-fact popup, progressive disclosure, posture, risk, report-control, Context boundary and Report invariance checks remain. 63 focused tests passed, including UI/API product-version contracts; both production builds, local-only/design checks and diff check passed. Browser inspection used a static rendering of the actual synthetic Dashboard output to verify both themes, responsive stacking, typography and no horizontal overflow; event behavior was verified in the actual React interaction tests, not the static preview. Screenshot saved. Patch 2.13.2 -> 2.13.3, package/lock and both version contracts synchronized. Existing client bundle-size warning remains; no full-suite rerun, real-client data change, backend restart or phase completion claim. Concurrent changes preserved.


2026-10-02 - Phase 13B / Dataflow presentation clarification (2.13.1 patch, verified): Result DB materialization tile now states Data protection & disclosure and explicitly describes removal or masking of sensitive identity data, validation before storage and the shared controlled result set for Result DB UI and exports. This documents existing disclosure behavior only; internal-analysis remains distinct. No processing, schema, engine relationship, arrow style or selection change. Current Presentation/Core Tests/Platform consent; 17 focused Dataflow/UI/API version tests, design check and both production builds passed. Package/lock and version contracts synchronized. Existing client bundle size warning remains; no backend restart, no new phase completion, no screenshot acceptance claimed.

## Context-based Management Report (Phase 7 / published Phase 13E results)

2026-10-02 - Version 2.13.0, implemented and focused verification complete: current Presentation/Core Tests/Platform release connects the management export to Context Engine's published, frozen result contract. Report Engine does not import Context internals; the already pinned backend extension composes published Context results through the canonical read-only port. The same project, assessment IDs, scan-run IDs and repository revision are checked before rendering/archive; unstable reads retry, mismatched scope or absent producer blocks management generation. Core remains unchanged with engines off. New management generation is blocked in Client Info while Context is off and late UI output is suppressed; technical-only generation still works without computing Context, with no fallback management file. Historical archive renderers and projections are preserved.

Delivered: Management Summary, all 22 category tiles sorted by actual Context color, unique Finding total, populated problem fields with scanner/GPO counts and catalogued/recognized/estimated confidence, generic review guidance referencing original recommendations in the Technical Report, documented risk acceptance and selected work states, conditional existing delta evidence, environment/source/time coverage and Domain appendix. No invented business loss, probability, ownership, deadlines, effort, threat scenarios or new priority. General category descriptions are labelled as catalog explanation, not a proven shared attack path. Category Base Severity and technical verdicts stay distinct; neutral is not secure, overlapping clusters are not summed, GPO backups are not effective host observations. Missing comparison evidence is stated explicitly. Result IDs stay out of Management HTML and are preserved with matching Context counts in Report B and the confidential frozen archive JSON. Standalone HTML uses embedded existing Inter, no script or external resources. The export reads Context only on demand, reusing a matching cached result; no additional customer-load work.

Verified: 67 focused Report/Context/publication, actual Client Info export interaction, HTTP generation, archive/replay, on/off invariance, architecture and UI/API version tests passed; both final production builds, design/local-only checks and diff check passed. Synthetic browser preview uses the production Context publisher and renderer with 22 categories, no customer data. Existing client bundle-size warning remains. Capability release 2.13.0 supersedes concurrently established 2.12.6; package/lock and UI/API version contracts synchronized. Report Engine 0.3.0, projection 1.3.0 and management renderer 3.0.0 version the new artifact. No persistence migration, canonical datastore change, backend restart or phase completion claim. Current running backend must load the new build before the live export changes. New implemented data-flow relationship: published Context results -> Report Engine; remind the user to request the Engine diagram update separately. A real customer export and rescan-backed delta were not accessed in this side conversation.

## Context-Heatmap in Client Info (Phase 13E / 7)

2026-10-02 - Phase 7 / Data-Kennzahlen als Results-Einstieg (2.12.6, umgesetzt und fokussiert verifiziert): Aktuelle Presentation/Core-Tests/Platform-Freigabe macht AD Domains, Entra Tenant, User Accounts, Computer Objects, Domain Controllers und GPOs zu nativen klickbaren Kennzahl-Kacheln. Die bestehende EnvironmentResultsButton-/FloatingDataWindow-Interaktion zeigt den unveraenderten Uebersichtswert, passende retained Originalbeobachtungen mit Quelle/Scan und die jeweiligen originalen Reportabschnitte samt bestehenden Such-/Detail-/Paging-Funktionen. Eigene Evidenzgruppen begrenzen User-/Computer-/DC-/Domain-/Entra-/GPO-Inhalte. GPO Results zeigt die bereits geladenen verarbeiteten Backup-Dateien, Anzahl, Status und Zeit; der bestehende projektweite Zaehler und seine Datenpopulation bleiben erhalten und werden als All processed client backups benannt. Bestehende GPO-GUID- bzw. Maester-Praesenz-Fallbacks werden als solche erklaert, ohne Detailobjekte zu erfinden. Unbekannte Werte bleiben ein Gedankenstrich; fehlende Quellabschnitte bleiben explizit fehlend. Kachelgeometrie, beide Theme-Tokens und 14px-Daten/16px-Werte bleiben erhalten, Hover und blauer Tastaturfokus zeigen die neue Interaktion. Escape/Close stellt Fokus auf die ausloesende Kennzahl zurueck; Oeffnen aendert weder Work-Filter noch Daten und erzeugt keine neuen Requests. Permanente synthetische Tests klicken alle sechs echten Dashboard-Kennzahlen in beiden Themes, pruefen exakte Werte/passende Evidenz, getrennte User-/Computer-Inhalte, Backup-Herkunft, Escape/Fokus, Dateninvarianz und Requestzahl; separater Test prueft unbekannten Wert ohne erfundene Null/Zeilen. 53 unterschiedliche fokussierte Kennzahl-/Domain-/Evidenz-/Layout-/UI-API-Versionspruefungen bestanden (52 im ersten Lauf, abschliessend drei Kennzahltests einschliesslich neuer Missing-data-Abnahme); Design-/Local-only-Pruefung, diff check und beide Produktionsbuilds bestanden. Synthetische Browserabnahme mit Enter, Escape, Maus und Dark/Light; Screenshot gespeichert. Patch 2.12.5 -> 2.12.6, Package/Lockfile und Versionsvertraege synchron. Kein Vollsuite-Neulauf, Backend-Neustart, Persistence-/API-Vertrags- oder Engine-/Dataflow-Beziehungswechsel; bestehende Bundle-Warnung und concurrent changes bleiben, keine Phasenabschlussbehauptung.

2026-10-02 - Phase 13E / 7, eindeutige Heatmap-Gesamtzahl (2.12.5, umgesetzt und fokussiert verifiziert): Auf aktuelle Presentation/Core-Tests/Platform-Freigabe steht Findings: N unmittelbar links neben der Severity-Legende. Die Anzahl umfasst die eindeutigen Scanner-Abweichungen und GPO-Settings, die in der Heatmap des ausgewaehlten Timeslots vertreten sind. Die vorhandene Evidenzprojektion wird fuer Kacheln und Gesamtzahl gemeinsam verwendet; mehrere Bedingungen, Evidenzen oder Clusterzuordnungen desselben Findings erhoehen die Gesamtzahl nicht. Scanner und GPO behalten getrennte Identitaeten, GPOs ihren Scope; bestandene Ergebnisse bleiben ausgeschlossen und der bestehende Recognition-Reassignment-Ausschluss bleibt erhalten. Neue Context-Daten aktualisieren den memoisierten Zaehler, leere Daten zeigen 0; Lade-/Fehlerzustaende zeigen keine erfundene Zahl. Keine Quellen-, Verdict-, Katalog-, Persistenz- oder Engine-/Dataflow-Beziehungsaenderung. Permanente synthetische Komponenteninteraktion in beiden Themes prueft Position vor der Legende, 29 GPOs plus zwei Scanner, ueberlappende Cluster/Evidenz, Pass-Ausschluss, unveraenderte Daten, Cluster-Klick und Wechsel zu leerem Scope; Dashboard-Klick prueft zusaetzlich die Gesamtzahl. 30 fokussierte Heatmap-, UI/API-Versions- und Core-Grenztests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Synthetische Browserabnahme in Dark/Light und schmalem Container ohne Ueberlauf; Screenshot gespeichert. Patch 2.12.4 -> 2.12.5 fuer rueckwaertskompatible UI-Ergaenzung, Package/Lockfile und Versionsvertraege synchron. Kein Vollsuite-Neulauf oder Backend-Neustart; bestehende Bundle-Groessenwarnung bleibt, keine Phasenabschlussbehauptung und concurrent changes erhalten.

2026-10-02 - Phase 7 / Directory in Domain Information integriert (2.12.4, umgesetzt und fokussiert verifiziert): Nach aktueller Presentation/Core-Tests/Platform-Freigabe entfaellt die separate Directory-Kachel. NetBIOS name, Schema version, Domain created und Entra ID erscheinen zusammen mit den bestehenden Domain-Angaben in Domain Information. Der gemeinsame Results-Button verwendet die bestehende FloatingDataWindow-Interaktion und zeigt alle elf Domain-Information-Felder, einschliesslich der oben bereits dargestellten Domains-/DC-Zaehler und unbekannter Angaben, sowie die bisherigen Directory-Quelltabellen und Beobachtungen. Nur die erste Leselinie vermeidet weiterhin doppelte Zaehler; Results wird nicht durch diese Uebersichtsfilter gekuerzt. Keine neuen Quellen oder fachlichen Ableitungen. Permanenter synthetischer Dashboard-Klicktest in beiden Themes prueft die vier integrierten Werte, das Fehlen der Directory-Kachel, alle elf Result-Felder, Originalevidenz und unveraenderte Work-Filter. 50 fokussierte Dashboard-/Result-/UI-API-Versionspruefungen, Design-/Local-only-Pruefung, diff check und beide Produktionsbuilds bestanden. Patchversion fuer die rueckwaertskompatible UI-Zusammenfuehrung; Package/Lockfile und Versionsvertraege synchron. Abnahmegrenze: synthetische DOM-Interaktionen und bestehende Theme-Tokens, keine neue Browser-Screenshot-Abnahme. Bestehende Bundle-Groessenwarnung bleibt; kein Backend-Neustart, keine Persistenz- oder Engine-/Dataflow-Aenderung, keine Phasenabschlussbehauptung.

Build-Abnahme zur nachfolgenden Korrektur 2.12.3: Client- und Serverproduktionsbuild erfolgreich; bestehende Client-Bundle-Groessenwarnung bleibt. `git diff --check` ohne Fehler.

2026-10-02 - Context-Zaehlung und Smartcard-Zuordnung korrigiert (Phase 13E, Patch 2.12.3): Die Heatmap ignoriert den historischen Fallback-Condition-Eintrag eines GPO-Findings nach `assigned-by-recognition` und zaehlt es nur in seinen zugeordneten Clustern. Zuvor zeigte Other solche bereits zugeordneten GPO-Abweichungen weiterhin, waehrend Work sie korrekt ausschloss. Der permanente synthetische Dashboard-Interaktionstest reproduziert 29 neu zugeordnete GPO-Settings plus zwei verbleibende Scanner-Findings und prueft nach Kachel-Klick die Uebereinstimmung von Kachelzahl und Work-Facet-Mitgliedschaft. Katalog 1.9.1 ergaenzt Purple Knight SI000147 anhand des vom Nutzer vorgelegten Berichtstexts: deaktivierte Smartcard-only-Kennwortrotation gehoert zu Lateral Movement Exposure; eine eigene Bedingung und vorsichtige Aussage bewahren die konkrete Bedeutung, ohne eine ATT&CK-Technik oder einen kompromittierten Zustand zu behaupten. Die unspezifische Maester-Regel MT.1024 ohne konkrete Empfehlung bleibt Other; keine Zuordnung aus der generischen Rule-ID. Regressionen pruefen fail/warning, Pass-/Not-run-Ausschluss, unveraenderte Eingabedaten und exakte Regelzuordnung. 100 unterschiedliche fokussierte Context-, Reader-, Facet- und Produktversionspruefungen bestanden, einschliesslich erneuter Reader-Pruefung nach Anpassung des dynamischen Katalogversionsvertrags. Design-/Local-only-Pruefung bestanden. Produkt-Patchversion nach aktueller expliziter Platform/Core-Tests-Freigabe synchronisiert; keine Core-Finding-, Verdict-, Severity-, Datenbank- oder API-Vertragsaenderung. Kein Backend-Neustart oder Kundendatenzugriff; Phase bleibt in Arbeit. Produktionsbuild-Abnahme wird nach Abschluss unten ergaenzt.

2026-10-02 - Version 2.12.2, kompakte Heatmap und direkter Finding-Klickpfad umgesetzt und fokussiert verifiziert: Die ausdrueckliche Nutzerkorrektur ersetzt die nachfolgend historisch dokumentierte Detailauswahl. Jede Kachel zeigt nur Base Severity, Kategorie und die Gesamtzahl zugeordneter Scanner-/GPO-Findings. Die vorhandene Deduplizierung bleibt bestehen; Bedingungen sind keine Findings. Kacheln verwenden die gemeinsame kompakte Breite von 186px und werden stabil nach ihrer dargestellten Farbe sortiert: Critical, High, Medium, neutral. Klick, Enter und Leertaste oeffnen unmittelbar Work mit dem exakten Context-Cluster-Filter und Abweichungsstatus, ohne Heatmap-Detailansicht. Alte Such-/Source-/Arbeitsfilter werden zurueckgesetzt; aus einem einzelnen Quellblatt wird auf das befuellte Projektblatt gewechselt, damit die gesamte Clusterliste ueber alle Quellen erreichbar ist. Timeslot und Client bleiben erhalten. Keine Aenderung an Quellen, Katalog-Grundschwere, Verdicts, Core-Scores oder Persistenz; keine neue Engine-/Dataflow-Beziehung. Abnahme: 60 fokussierte Tests ueber Context, Architektur, Dashboard, Quellnavigation und UI/API-Versionsvertraege bestanden; Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Synthetische Browserpruefung in beiden Themes und bei 358px Containerbreite ohne Ueberlauf, mit Maus und Tastatur, bestanden. Permanente Interaktionsregression prueft den echten Dashboard-Klickpfad einschliesslich Quellblattwechsel. Patchversion fuer die rueckwaertskompatible Darstellungs-/Navigationskorrektur, Package/Lockfile und Versionsvertraege synchron. Bestehende Bundle-Groessenwarnung bleibt; kein Backend-Neustart und keine neue Abnahme realer Kundendaten. Phase 13E bleibt in Arbeit.

2026-10-02 - Version 2.12.0, umgesetzt und fokussiert verifiziert: Auf Nutzerauftrag ist die recherchierte Tabelle mit allen 22 bestehenden Context-Clustern als eigener versionierter Quellenkatalog `src/assessment-context/context-cluster-severity.ts` (1.0.0, Recherche-/Pruefdatum 2026-10-02) hinterlegt. Einstufung: vier Critical, 13 High, vier Medium, ein Undetermined. Jede fachlich eingestufte Kategorie besitzt Begruendung, Einschraenkung und lokal gespeicherte Quellenangaben; die Einstufung ist eine kuratierte ASSESSOR-Grundschwere und kein von den Quellen vergebener Cluster-Score. `Other Deviations` bleibt unbestimmt. Die bisherigen Security Domains und ihre Zuordnung bleiben unveraendert.

Entscheidung und begrenzte Erweiterung des bisherigen Context-Darstellungsvertrags: Die neue Heatmap darf die bestaetigte statische Kategorie-Grundschwere mit den bestehenden Severity-Farbtokens darstellen, wenn das vorhandene Context-Ergebnis Belege enthaelt. Sie erzeugt keine Finding-Severity, kein CVSS, keine normalisierte Prioritaet, kein Pass/Fail und keine clientbezogene Aussage zur Ausnutzbarkeit. Ohne Belege sowie bei unbestimmter Grundschwere bleibt eine Zelle neutral; neutral bedeutet nicht sicher. Bedingungen, Clusterzustand und Zuordnungssicherheit bleiben getrennt. Die Bedingungen und Cluster-Schwellen werden unveraendert aus Context uebernommen. Scanner-Abweichungen, GPO-Baseline-Abweichungen, deklarierte Techniken sowie erkannte und geschaetzte Zuordnungen werden aus dem vorhandenen Ergebnis gelesen und pro Cluster nach Finding-Occurrence bzw. GPO-Identitaet/Scope dedupliziert; es gibt keine neuen Quellen, Neuinterpretation von Verdicts oder Requests pro Zelle. Reine GPO-Konfigurationsbelege bleiben als Bedingungen erkennbar und werden nicht als beobachtete Host-Findings ausgegeben. Cluster duerfen ueberlappen; ihre Zahlen werden nicht zu einer vermeintlich eindeutigen Gesamtsumme addiert.

Client Info zeigt die Heatmap fuer den ausgewaehlten Timeslot ueber alle Quellen, ausdruecklich unabhaengig vom Source-Auswahlfeld. Sie nutzt denselben vorbereiteten Context-Abruf wie die bestehenden Leser. Ein Klick bzw. Enter/Leertaste markiert die Zelle gelb und oeffnet deren Grundschwere, Bedingungen, Zuordnungssicherheit, Begruendung und Quellen. Der Fokus wandert zu den Details und beim Schliessen zurueck zur Zelle. Bei Client-/Scope-/Revisionswechsel verfaellt die Auswahl. Context aus entfernt die Heatmap vollstaendig und erzeugt keine neuen Anfragen; spaete Antworten bleiben ausgeblendet. Ladefehler werden nicht als leere oder sichere Bereiche dargestellt. Der neue Core-Erweiterungspunkt in `DashboardPanel.tsx` ist nach aktueller `Core-Freigabe: Presentation, Core Tests, Platform` in der Architekturpruefung eingetragen; fachliche Core-Berechnungen bleiben frei von Context-Abhaengigkeiten.

Abnahme: 116 fokussierte Context-, Architektur-, Client-Info-, Navigations- und UI/API-Versionsvertragstests bestanden; anschliessender Fokus-/Tastaturtest 4/4 nach letzter Scrollkorrektur bestanden. Der synthetische Test mit dem echten Dashboard vergleicht die vollstaendige Core-Darstellung und Dataset-Werte bei aus-/eingeschalteter Engine. Weitere Tests pruefen Vollstaendigkeit aller 22 Eintraege, fehlende native Scanner-Severity, deduplizierte Scanner-/GPO-Zahlen, Passed-Ausschluss, unbekannte Bereiche, unveraenderte Context-Ergebnisse und spaete Antworten. Synthetische Browser-Sichtpruefung in Hell/Dunkel und bei 358px Containerbreite ohne horizontalen Ueberlauf, einschliesslich Maus, Enter, Leertaste und Fokusrueckkehr, bestanden. Beide Produktionsbuilds, Design- und Local-only-Pruefung bestanden; bestehende Bundle-Groessenwarnung bleibt. Minor-Version 2.12.0 fuer die neue rueckwaertskompatible Faehigkeit; Package, Lockfile und Versionsvertraege synchron. Kein Datenbankeingriff, keine Migration, kein Backend-Neustart und keine Phasenabschlussbehauptung. Abnahmegrenze: synthetische UI-/Datenpruefung, keine neue Pruefung eines realen Kundenbestands. Neue dargestellte Beziehung: Context Engine -> Client-Info-Heatmap; Engine-Diagramm-Aktualisierung bleibt ein gesonderter Nutzerauftrag gemaess Erinnerung unten.

## Verbindlicher Diagramm-Pfeilstandard

2026-10-02 - Phase 7 / Ready indicator and explicit minimization (2.12.1 patch, implemented and verified): current Presentation/Core Tests/Platform release adds the requested green system-status dot beside Ready in both expanded Activity and the single compact button. Ready text remains accessible; the decorative dot uses the existing theme-aware state-online token. A native minimize button with an × sits immediately right of History when Ready; clicking or pressing Enter collapses the panel and its disclosure without removing history or changing readiness. The existing five-second automatic minimization and new-work restoration remain unchanged. Permanent both-theme Activity interaction acceptance verifies the actual minimize/reopen path, retained failed history, dot presence only while Ready, action placement and absence while waiting/not ready. Verified: 22 Activity and UI/API version tests passed, security/design checks and both production builds passed. Synthetic production-component browser verification confirms both theme colors, automatic compact state, mouse/Enter minimization and history reopening; screenshot retained. Version decision: backward-compatible presentation refinement, patch from the concurrently established 2.12.0 to 2.12.1, package/lock and both version contracts synchronized. No full-suite rerun for this focused correction; existing client bundle warning remains. Concurrent changes preserved, no phase completion or engine/data-flow change.

2026-10-02 - Phase 7 / confirmed client identity edits (2.11.10 patch, implemented and verified): explicit user decision requires a mandatory warning before saving changes to the existing Client Information Name or Consultant. Current Presentation/Core Tests/Platform release implements that guard in the shared native form-submit path, including implicit Enter submission. The dialog lists only changed fields with previous and proposed persisted values. Cancel, Escape, close and backdrop dismissal write nothing and retain the draft for review; Confirm changes saves the reviewed form snapshot through the existing API and read-back verification. Re-submitting after cancellation requires confirmation again. Unchanged identity fields, Remarks-only edits and new-client creation retain their existing flow. Initial focus is Cancel, keyboard focus cycles inside the dialog and closure restores the prior focus; Enter on Cancel never confirms. A synchronous save guard prevents duplicate API writes. Existing project ID, creation time and unrelated attributes are retained; no repository/schema/API persistence contract change. Shared dialog, theme surfaces, control geometry and 14px labels/16px values are used; no new palette. Permanent actual DataHub interaction acceptance covers Name, Consultant and both changes, old/new values, no writes before confirmation, Escape/Cancel, native form resubmission, one confirmed save, read-back and preservation of unrelated data; Remarks-only edits remain direct. Verified: 19 Client Info/reference interaction/layout tests plus 15 version/API/Core-boundary tests passed; local-only security/design checks and both final production builds passed. Synthetic shared-dialog browser verification covers dark/light, Cancel and explicit confirmation by Enter, focus wrapping and readable old/new values. Version decision: backward-compatible presentation safety correction, patch 2.11.10. No full-suite rerun for this focused change, no phase completion claimed; existing bundle warning and concurrent changes preserved. No engine/data-flow relationship change or diagram update required.

2026-10-02 - Phase 7 / minimal Ready button (2.11.9 patch, implemented and verified): current Presentation/Core Tests/Platform consent implements the user's correction that the minimized Activity panel still obstructed work. Collapsed Activity now renders one neutral shared-geometry Ready button, with no panel surface, border, padding or second History control. Its transparent positioning wrapper fits the button instead of reserving the 560px panel width. Clicking or pressing Enter opens the existing panel with History already expanded. New work still opens the full current status and the existing five-second Ready timer is unchanged. Manual collapse of a non-ready state retains its actual status text rather than asserting Ready. Readiness, request identity, historical outcomes and data quality contracts remain unchanged. Permanent both-theme interaction acceptance now verifies a single Ready button, absence of the panel, direct history opening and automatic panel restoration from the tiny state when new work starts. Updated earlier interaction tests select the newly mounted compact control after collapse instead of clicking a detached panel button. Verified: 22 activity/UI/API version tests passed; local-only security and design checks and both production builds passed. Synthetic current-component browser checks confirm dark/light, mouse/Enter history opening and an approximately 66x28px compact control with a transparent, unpadded, borderless wrapper. Version decision: backward-compatible presentation refinement, patch 2.11.9. No full-suite rerun for this focused correction, no phase completion claimed; existing bundle warning and concurrent changes preserved. No engine/data-flow change or diagram update required.

2026-10-02 - Phase 7 / final Ready and timed minimization (2.11.8 patch, implemented and verified): current Presentation/Core Tests/Platform release implements the user's final-state correction. Activity shows Ready only when no operation is active/queued and the latest attempt for every tracked operation has completed. A successful retry replaces that operation's earlier failure for readiness while keeping the failed invocation in History. API operation identity includes backend, method and exact request path/scope; a success for a different client cannot resolve another client's request failure. Display labels can change without changing operation identity; identifiers/URLs remain internal and are never rendered. Latest operation outcomes are retained separately from pruned/cleared history, so clearing or dismissing rows cannot manufacture readiness. This is conservative: an outstanding unsuccessful operation still prevents Ready until the corresponding operation succeeds. Earlier failures/cancellations now appear only inside the optional History, without a Needs attention decision queue. This explicitly supersedes the 2.11.6 failure-first presentation and immediate all-success collapse. Ready stays expanded for five seconds, then automatically minimizes to the compact Activity/History bar. New work opens the panel, cancels an earlier timer and starts a fresh five-second interval after successful completion; manually reopening History after minimization stays open until another load cycle. No request is retried or changed by this UI. Native buttons, existing neutral styles and readable Ready content retained. Verified: twelve activity acceptance tests include both themes, recovered failures, exact 4,999/5,000ms boundary, queued/new work at an old deadline, reopening History, exact request-scope matching, clearing/dismissing/pruning invariance and concurrent API behavior. Full suite 1,807 passed, 15 skipped; local-only security/design checks and shared UI/API version contracts passed; both production builds passed. Synthetic production-component browser checks confirm Ready, automatic minimization and History reopening in dark/light. Version decision: backward-compatible status correction, patch 2.11.8. No source, assessment, engine execution, persistence or Data Flow relationship change; no diagram update required. Existing bundle warning remains, no phase completion claimed, concurrent work preserved.

2026-10-02 - Phase 7 / reachable Context Cluster options (2.11.7 patch, implemented and verified): current Presentation/Core Tests/Platform release applies the user's request to the shared Work filter projection. Context Cluster options with zero hits under the existing self-excluding facet counts are no longer offered. Search, status and other active restrictions still determine those counts; selecting a cluster does not hide reachable alternatives from that same facet. All remains available, including an empty scope. A currently selected cluster that becomes empty remains visible as a disabled current option so the UI does not silently drop a restriction; All explicitly clears it. This supersedes the earlier Work-control behavior of offering every catalog cluster at zero hits. The complete engine vocabulary and results, all other declared facets, filter counts and engine activation remain unchanged. Permanent actual SearchFilterBar acceptance covers selecting a cluster, narrowing search to another cluster, disabled zero-hit selection retention, choosing All and a completely empty result scope. Existing badge selection and both-theme checks remain. Verified: 49 filter/Context/GPO tests plus 20 UI/API version and architecture/invariance tests passed; local-only security and design checks and both production builds passed. Version decision: backward-compatible presentation correction, patch 2.11.7. No full-suite rerun for this small focused correction, no phase completion claimed; existing bundle warning and concurrent changes preserved. No data-flow or engine relationship change; no diagram update required.

2026-10-02 - Phase 7 / activity overview (2.11.6 patch, implemented and verified): current Presentation/Core Tests/Platform consent implements the approved compact activity design. Needs attention appears before running/waiting work, cancellations stay distinct, and the summary includes failures even while other operations run. The operation label is primary and the engine secondary. Successful history starts collapsed; an explicitly opened panel/history stays open through updates. Exact engine/label repeats form expandable groups retaining every recorded invocation. The fixed panel header sits above a scrolling body using the shared 20px inset, 14px informational text and existing controls/theme tokens. All-success state defaults to a compact header with History count. Durations below one second show <1s; active durations update from real timestamps, with no inferred percentage or ETA. Clear completed removes only successes. Failures and cancellations survive success-history pruning and can be acknowledged individually with Dismiss, which never removes active tasks. The existing 40-success history bound remains; acknowledged task records are UI telemetry, not assessment data. Legacy clearFinishedActivities remains for existing non-UI cleanup callers. No invented error detail or retry action: current telemetry contains a state, engine, operation label and timestamps only. No source, result, engine execution, database or Data Flow relationship changes; no diagram update required. Verification: eight activity acceptance tests include real concurrent API operations, exact grouping, opened-history invariance, failure/cancellation retention through pruning and success clearing, individual dismissal and active-task protection. Full suite 1,802 passed, 15 skipped; local-only security and design checks passed; shared UI/API version contracts and both production builds passed. Synthetic current-component browser checks cover light/dark, compact all-success state, keyboard history opening, group expansion and failure/active preservation after Clear completed. Version decision: backward-compatible UI/status refinement, patch 2.11.6. Existing client bundle-size warning remains; no phase completion claimed and concurrent work preserved.

2026-10-02 - Phase 7 / separate no-hit recovery actions (2.11.5 patch, implemented and verified): current Presentation/Core Tests/Platform release implements the user's correction in Work, Result DB and Pathfinder. The shared companion now has exactly two actions. Reset filters delegates to each view's existing normal reset, including Work/Pathfinder's existing My Workspace behavior and Result DB's default Deviation filter. Search all Findings clears result restrictions and selects All Findings within the current client, timeslot and active sheet; Result DB clears filter values while retaining the exact project/assessment/scan scope. The user's two-action correction explicitly supersedes the earlier separate source-preserving no-hit recovery button: Search all Findings also clears the source facet. Pathfinder retains its binding deviation-only graph scope; its Search all Findings action opens Work with the All filter through the existing navigation callback. No source, verdict, disclosure, persistence or engine behavior changes; no Data Flow diagram update required. Permanent synthetic interaction acceptance compares the no-hit Reset action directly with normal reset and verifies both actions in all three real views, Pathfinder-to-Work navigation, unchanged client/timeslot/sheet, unchanged source data and scoped Result DB queries. Verification: full suite 1,799 passed, 15 skipped; local-only security and design checks passed; UI/API product-version contracts and both production builds passed. The earlier import timeout did not recur in this run. Version decision: backward-compatible correction, patch 2.11.5 shared by UI and API. Existing client bundle-size warning remains; phase status unchanged and concurrent work preserved.

Visual verification for the 2.11.5 no-hit action correction: the shared production component's explicitly synthetic preview was inspected in light and dark; both native buttons remain readable and use the existing control styles. The preview supplies no customer data and does not replace the actual-view interaction acceptance above.

2026-10-02 - Phase 7 / process-arrow clearance correction: current Presentation/Core Tests/Platform release covers this local presentation fix. Fresh desktop geometry already cleared the earlier screenshot's intersections, but browser testing exposed direct upload and source-result paths crossing intervening tiles in the responsive one-column layout. Each proposed orthogonal path now checks every measured tile rectangle with stroke clearance; intersecting paths select a clear measured side rail. Source and destination ports stay 4px outside tile boundaries so triangular tips also clear the tiles. The existing engine arrow style, 17 declared deliveries, yellow connected-edge selection and table popup behavior are retained. Permanent synthetic acceptance selects a finding tile, resizes from unequal desktop lanes to stacked tiles, checks every segment against every tile, checks destination clearance and verifies retained selection. Verified: 17 focused diagram/UI/API version tests passed, security/design checks passed, both production builds passed. Live checks in light and dark at desktop width and in the stacked layout found zero arrow or label intersections. Existing bundle-size warning remains. Version decision: included in the related current 2.11.4 refinement batch already present in the shared workspace; no separate version edit. No API, persistence, engine behavior or phase-status change; concurrent work preserved.

2026-10-02 - Phase 7 / process tile selection and arrow spacing: current Presentation/Core Tests/Platform consent increases processing gaps from 64px to 96px and the shared maximum content width to 1266px, preserving 358px tiles. Clicking a tile surface or its native title button selects/deselects it independently of table detail selection. Selected tiles have the same yellow outline and side marker as engine modules. Every directly connected arrow is highlighted along its complete route, including labels and triangular arrowheads; unrelated arrows remain neutral, matching the engine diagram's connected-edge selection semantics. Consumer routes have more separated label levels. Table chips still open the existing popup and closing it preserves an independently selected tile. Permanent synthetic acceptance covers surface selection, exact connected paths, yellow-marker references, chip navigation, popup closing and deselection. Verified: 10 focused tests, security/design checks and production builds passed; live mouse and Enter-key selection/deselection plus light/dark styling verified. Version decision: same related unreleased 2.11.3 refinement batch, no separate version edit. No data-flow semantics, API, persistence or engine behavior change. Phase status unchanged; existing bundle warning remains.

Explizite Nutzerentscheidung 2026-10-02: Die bestehende Pfeildarstellung in `Engines & relationships` (`src/features/db-structure/EngineDataFlow.tsx`, `.db-engine-flow__edges` und `.db-engine-flow__edge-label` in `src/styles/datahub.css`) ist die verbindliche visuelle Referenz fuer Beziehungspfeile in Diagrammen. Auch der darunterliegende Data Flow uebernimmt diese Darstellung. Beziehungen werden als durchgehende, gerichtete Linien mit klarer dreieckiger Pfeilspitze und lesbarer Beziehungsbeschriftung dargestellt; rechtwinklige Verzweigungen verwenden denselben Stil. Implementierte Beziehungen sind durchgezogen, geplante Beziehungen gestrichelt und ausdruecklich als geplant beschriftet. Tatsaechlich bidirektionale Beziehungen tragen Pfeilspitzen an beiden Enden. Neutrale Linien verwenden `--line-strong`, ausgewaehlte Beziehungen `--marking-color`; Linienstaerke, Marker-Geometrie und Beschriftungsrollen folgen der genannten Referenz. Keine dekorativen Effekte oder neue Palette. Dieser Standard ersetzt ausschliesslich die Pfeildarstellung, nicht die bestehenden Interaktionen oder fachlichen Beziehungstypen anderer Diagramme.

Phase-7-Auftrag, zunaechst als Dokumentationsentscheidung gespeichert und am 2026-10-02 nach erneuter Freigabe umgesetzt: Fehlende sichtbare Beziehungen im unteren Data Flow ergaenzen und bestehende Verbinder an diesen Standard angleichen. Vor der Darstellung jede Verbindung gegen den implementierten Datenfluss pruefen; keine Beziehung allein aus der Kachelposition ableiten. Funktionen bleiben unveraendert. Keine Produktversionsaenderung fuer die urspruengliche Dokumentationsentscheidung.

2026-10-02 - Phase 7 / process relationship arrows: on current Presentation/Core Tests/Platform release, replaced disconnected CSS connector fragments with 17 labelled, directed SVG relationships using the existing engine diagram's 2px lines, 7px triangular markers and 14px labels. Added upload branches, processing chains, baseline input, source-result merge, disclosed-storage-to-Result-DB delivery, direct scanner/policy findings to Work and scanner history to comparison. Other tables remain unconnected because their processing assignment is unknown. Source checks: repository rebuildResultDb source readers, policy/scanner Work projections and compareProjectTimeslotEvidence. No Policy-history arrow: the implemented timeslot comparison consumes scanner runs. DOM geometry and ResizeObserver adapt routes to current tile sizes; merge paths clear taller GPO tiles, side routes bypass consumers, selected table endpoints highlight connected paths. Existing engine overview semantics, popup/table navigation, schema refresh and dictionary retained. Permanent synthetic interaction acceptance now verifies the previously missing relationships, arrow markers, selection/closing invariance and a resize with unequal lane heights. Verified: 10 focused tests passed; security/design checks and both final production builds passed; current-code light/dark browser inspection passed. Existing bundle-size warning remains. Version decision: same related unreleased 2.11.3 refinement batch; no separate version edit. Concurrent backend work untouched, no API/schema/engine behavior change, no phase completion claimed.

2026-10-02 - Phase 7 / shared filter-empty companion and direct reset (2.11.4 patch, implemented and verified): user chose Work, Result DB and Pathfinder, then renewed Presentation/Core Tests/Platform consent. Added an original local SVG companion with a magnifying glass and gentle searching motion to the completed no-hit states. It uses existing neutral theme roles, shared typography/control geometry and an 88px size token; reduced-motion preferences disable animation. It is decorative and hidden from assistive technology; the visible no-hit heading stays authoritative. Shared native Reset filters buttons support mouse and keyboard. Work and Pathfinder clear search, facets, status restrictions, My Workspace-only and path restrictions while preserving the client, timeslot and active sheet. Work retains its distinct Show all results for this source action, including the documented source-preserving behavior. Result DB uses its existing reset contract (Deviation enabled, remaining filters cleared) and preserves its exact project/assessment/scan scope. Pathfinder's empty overlay permits button clicks without intercepting the graph elsewhere. No engine, importer, evaluation, source, storage or disclosure changes; no Data Flow diagram update required.

Verification: 15 focused tests passed across new actual Work/Pathfinder/Result DB no-hit/reset interactions, GPO visibility and source recovery, graph text behavior and Result DB scope. Tests prove results return, all intended restrictions clear, source values stay unchanged and client/timeslot/sheet remain selected. Existing GPO source-action acceptance now identifies that action by its text instead of assuming the first button. Final three interaction tests passed again after a test-only optional-query typing correction. UI/API version contracts passed. Full suite: 1,794 passed, 15 skipped, one known default 5-second node-import-engine timeout; separate default reruns also timed out. Diagnostic rerun with a CLI-only 15-second timeout passed all five tests, with the affected format test taking 4,034ms; permanent acceptance deadlines remain unchanged and the default full suite is not claimed green. Security/design checks and both final production builds passed; existing client bundle-size warning remains. Dummy-client live Work inspection passed in light/dark; Pathfinder reset via Enter restored graph nodes. Shared component screenshots saved as filter-empty-light.png and filter-empty-dark.png. Result DB click verified with synthetic API data and the real component; live Result DB inspection was interrupted by the development backend rebuild/page reload, so no completed live Result DB reset claim. During the earlier live client opening, the separate Context request returned HTTP 500 after about five seconds; Core results opened through existing error handling. That runtime Context failure is an unresolved separate observation, not fixed or certified by this UI batch. App/backend health reports 2.11.4 with PostgreSQL revision 535 unchanged. Version decision: backward-compatible UI refinement, patch 2.11.3 -> 2.11.4; package/lock and UI/API version contracts synchronized. Phase status unchanged; no milestone completion claimed. Concurrent Data Flow/backend changes retained.

Additional visual acceptance fixture for the 2.11.4 empty-state batch: `tests/filter-empty-state-preview.html` renders the shared production component with explicitly synthetic text and no backend reads. Its complete captioned screenshot is `filter-empty-preview.png`; this is a component preview, not a substitute for the real reset-interaction tests described above.

## Verbindliche Erinnerung: Engine-Diagramm bei Data-Flow-Aenderungen

2026-10-02 - Phase 7 / Data Flow layout alignment: current Presentation/Core Tests/Platform consent covers a CSS-only follow-up. Summary, schema actions, engine diagram, inspector, process flow and dictionary now share the diagram's 1130px maximum content width and centered alignment. Reference data starts level with the processing lanes; lane tiles remain centered on their connector spines. Result DB and Work form a compact centered pair. All content, relationships, selections and detail-window behavior retained. Verified: 10 focused layout/flow/interaction tests passed after retaining the existing segment-inset contract; security/design checks, client and server production builds passed, with the client rebuilt after final CSS corrections. Live light/dark inspection confirms identical section width and alignment. Existing bundle-size warning remains. Version decision: included in the current unreleased 2.11.3 refinement batch already present in the shared workspace; no separate version edit. Concurrent backend/performance work was left untouched. Phase status unchanged; no architecture or data-flow semantics changed.

Explizite Nutzerentscheidung 2026-10-02: Bei jeder Umsetzung, die den dargestellten Data Flow betrifft, erinnert der bearbeitende Agent den Nutzer im Abschlussbericht daran, den Auftrag zur Aktualisierung des Engine-Diagramms zu geben. Ausloeser sind neue, entfernte oder geaenderte Engines, Datenquellen, Verarbeitungsschritte, Lese-/Schreibports, Speicherorte, UI-/Exportverbraucher und Beziehungen sowie der Wechsel einer dargestellten Beziehung zwischen geplant und implementiert. Die Erinnerung nennt konkret, welcher Teil der Darstellung betroffen ist.

Die Erinnerung lautet: "Diese Aenderung betrifft den Data Flow (<konkrete Aenderung>). Bitte gib mir den Auftrag: Aktualisiere das Engine-Diagramm."

Wenn die aktuelle Nachricht die Diagrammaktualisierung nicht bereits ausdruecklich beauftragt und die betroffenen Core-Bereiche freigibt, fuegt der Agent die erforderliche Freigabephrase hinzu: "Core-Freigabe: Presentation, Core Tests, Platform". Bestehende ausdrueckliche Auftraege werden innerhalb ihrer aktuellen Freigabe ausgefuehrt; keine doppelte Erinnerung fuer eine bereits erledigte Aktualisierung. Keine automatische Aktualisierung und keine Behauptung, das statische Engine-Diagramm erkenne Architekturveraenderungen selbst. Die bestehende nachrichtenbezogene Core-Freigaberegel bleibt unveraendert.

Dokumentationsentscheidung: dauerhaft im Implementierungsplan gespeichert; keine Code-, Governance-Datei- oder Produktversionsaenderung. Phasenstatus unveraendert.

2026-10-02 - Phase 7/13E / quality-preserving client read optimization (2.11.3 patch, implemented and verified): explicit Store/Platform/Presentation/Core Tests release; data quality takes precedence over speed. PostgreSQL internal-analysis pagination reuses complete source projections within the exact query scope (all arguments except offset/limit). Every call checks the live database revision before and after reading, including cache hits and commits from other backend/worker instances. A revision change discards the read and retries up to three times; repeated changes or an unverifiable revision fail explicitly. Concurrent identical reads share their source load; failed loads are evicted. Retention is process-local, bounded to eight entries and 32 MiB per repository; oversized results remain complete but are not retained. Returned pages and categories are independent copies. Result DB disclosure continues through its existing materialized, disclosure-checked path and never consumes the internal cache. Context additionally reuses full policy evaluations, baseline analyses, assessment lists and models only inside a single revision-checked attempt; retries and new Context runs have fresh read ownership. No schema, migration, persisted source, verdict, score, reference catalogue or engine activation change. Client opening still waits for enabled Context before publishing its workspace; original Raw Data and historical-score loading remain intact.

Verification and limits: the permanent synthetic PostgreSQL paging test compares every field, ordering and count for all 2,501 results across three pages against uncached derivation, with one instead of three full source loads. It covers caller mutation, same-count content changes through a live revision, scope separation and the separate disclosure path. Cache and Context tests cover concurrent reads, bounded retention without truncation, failure/retry and revision-change retry with complete Context equality. Full suite: 1,792 passed, 15 skipped; security and design checks passed. Final focused checks after query-snapshot/read-port tightening: 32 passed, including actual client opening/Context waiting and UI/API version contracts. Both final production builds passed; existing client bundle-size warning remains. App HTTP 200 and backend PostgreSQL health at 2.11.3, repository revision 535. Actual cold-client latency against the reported 80 seconds has not been measured under a controlled identical-client workload; no percentage or time reduction is claimed. Large initial reads and Context computation still run in full, and any repository commit invalidates reuse, including unrelated scopes. Version decision: backward-compatible performance refinement, patch 2.11.2 -> 2.11.3 with package/lock and both version contracts synchronized. Phase status unchanged; no milestone completion claimed. Data Flow follow-up: remind the user to request an Engine diagram update for the revision-checked Core read reuse and request-local Context read step; no automatic diagram edit.

2026-10-02 - Phase 7 / Data Flow process-tile refinement: with current Presentation/Core Tests/Platform consent, adapted the existing processing tiles to the engine tiles' flat neutral surfaces, square geometry and shared side marker. Limited tiles to the existing 358px content width and centered the three processing lanes within that width; retained typography, all source labels, table counts, connectors, table selection, relationship highlights and floating detail windows. Long table names wrap without truncation. CSS only; no data flow, API, engine or persistence changes. Verified: 20 focused flow/layout/interaction and UI/API version tests passed; final security/design checks and both production builds passed. Live inspection passed in light and dark, all 17 tiles had no horizontal content overflow, and the scan_runs detail window opened and closed normally. Existing bundle-size warning remains. Version decision: part of the same related unreleased 2.11.2 presentation refinement batch; no additional increment. Phase status unchanged.

2026-10-02 - Phase 7 / interactive Data Flow diagram (follow-up to the preceding overview): on renewed Presentation/Core Tests/Platform release, replaced the always-open engine table with an interactive architecture diagram. Nine selectable modules include all three engines, source inputs, canonical PostgreSQL, read-only port, UI consumers and report outputs. Nine labelled relationships show directional delivery, bidirectional Core database read/write and the dashed, explicitly Planned Context-to-Report target. Selection highlights connected edges and opens an inspector; native buttons support keyboard activation and deselection. The complete relationship table remains in a closed disclosure. Narrow views scroll the diagram without shrinking 14px information text; inspector stacks. Coordinates live in CSS classes, using current tokens and flat tiles, with no engine imports, requests or data writes. Existing schema flow, table popups and dictionary retained. Version decision: same unreleased, related 2.11.2 refinement batch; no additional version increment. Permanent synthetic tests cover module selection, deselection, directed/bidirectional markers, planned output and disclosure; 20 focused tests passed before the final CSS correction, and 14 final diagram/layout/import tests passed afterward. Full suite: 1783 passed, 15 skipped, one unrelated 5-second timeout in node-import-engine; all five tests in that unchanged suite passed in the separate rerun (format test 3504ms). Security/design checks passed. Both production builds passed; final client rebuild after the CSS-class and read/write-marker corrections also passed. Existing bundle-size warning remains. Live mouse/keyboard selection, both themes and horizontal overflow checked. Phase status unchanged; planned report Context integration remains outside this UI change.

2026-10-02 - Phase 7 / Data Flow engine overview (2.11.2 patch): renamed DB Structure to Data Flow in navigation and header. Added Core, Context and Report with nine directed data-delivery relationships, canonical PostgreSQL, read-only Core port, UI consumers and separate report archive. Context-to-Report is explicitly Planned: current report generation does not consume published Context results. Architecture includes disabled engines. Corrected obsolete Result DB wording and assigned result_db_rows/result_db_state to Core-owned disclosure materialization before its consumer. Existing table details preserved. No API, persistence or engine behavior changes. Verified: 1783 tests passed, 15 skipped; UI/API version contracts, architecture and engine invariance passed; security/design checks and both production builds passed, client build repeated after final order correction. Live inspection in both themes; backend healthy at 2.11.2 with PostgreSQL. Existing bundle warning remains. Version decision: backward-compatible refinement, patch 2.11.1 -> 2.11.2, package/lock synchronized. Phase status unchanged. Follow-up request for a more futuristic diagram awaits renewed Core consent under the per-message rule.

2026-10-01 - Phase 7/13 / Maester description table rendering: shared Markdown presentation recovers flattened pipe tables with retained line breaks inside prose cells, without crossing blank lines, headings, code fences, lists or another delimiter. The reader also handles tables mixed with supported inert inline HTML (links, emphasis and br); original retained fields are untouched. Shared rich-text tables use the agreed 14px data typography. Permanent synthetic reader regressions cover both cell-break representations, full cell text, headers, links and unchanged originals; the shared parser regression preserves a following list. Synthetic browser checks and visual inspection passed in dark and light. Verification: 1782 tests passed, 15 skipped; security/design checks passed; client and server production builds passed, including a refreshed client build after the typography correction. Version decision: bundled into the concurrently established 2.11.1 patch batch; package/lock and UI/API version checks already agree and were not overwritten by this change. No importer, persistence, verdict or score change; no reimport required. Ambiguous table structures remain source text. No phase completion claimed.

2026-10-01 - Phase 13E / client Context loading and All count (2.11.1): Client opening now prepares the enabled Context Engine after the canonical workspace is ready and before publishing the loaded client. A Core API request cache, weakly owned by the dataset and keyed by the exact scope, shares that attempt with every reader; no engine implementation is imported into Core. The Context hook makes no request for an empty dataset and never returns a previous scope's result while a new scope loads. Failed attempts remain visible instead of silently restarting on reader mount; Core results remain accessible, with an English notice to reopen the client to retry. Disabled Context makes no request. Work and Pathfinder's shared Context Cluster selector shows All (N), counting each matching record once, including records without cluster membership, while respecting other filters and excluding its own selection. Overlapping clusters do not inflate the total. Patch version 2.11.1 records this backward-compatible correction; package/lock and UI/API contracts agree. Verified: 37 focused tests passed, including the actual Open/client-switch interactions, deferred Context response, failure/reopen, disabled engine, scope changes, filtered and zero-hit All counts, and version contracts. Synthetic browser checks and visual inspection passed in dark and light. Both production builds passed; the final client build also includes the synchronous stale-scope guard. Local-only and design checks passed. Full suite: 1781 passed, 15 skipped, one unrelated failure in tests/shared/markdown.test.ts:40 (wrapped flattened table followed by a list); the Markdown source and test were not changed by this task. Running backend reports 2.11.1 and unchanged repository revision 535; frontend HTTP 200. Limits: the screenshot did not expose the original failed HTTP response, so its specific backend error was not independently reproduced. This change removes the verified premature/duplicate request path; it does not speed up Context computation itself. No persistence changes, no phase completion claimed.

2026-10-01 - Phase 7/13 / shared operation transparency (2.11.0 capability release): adds the English Activity panel across all views. A Core-owned, in-memory platform registry tracks parallel operations with area/engine, specific activity, elapsed time and Waiting/Running/Completed/Failed/Cancelled state. Active tasks survive clearing; completed history is bounded to 40 entries. Core never imports engine implementations. The shared API client names every request (except routine health polling), including Client/assessment/scan/model loading, Context calculation, Report generation, MITRE catalog refresh/download, baseline and evaluation catalogs, import preview/completion, GPO/policy work, Result DB/filter/schema refresh and persistence requests. Unknown future API operations get a generic public label; future engines can provide describeActivity or use beginActivity/trackActivity without a Core dependency on that engine. Local work is explicitly covered for client model conversion and review hydration, source-file preparation, GPO folder preparation, MITRE file validation, Result DB and Work exports, workspace snapshots, current-sheet export and clipboard preparation. Existing GPO status polling updates a queued/running activity; leaving that import control records stopped monitoring, not cancellation of the server job. Existing local progress dialogs remain in place. No invented percentages or simulated engine startup: cached/disabled/unused engines do not create fictitious work. Server calls show the known operation, not unsupported internal download/parse percentages. The browser is yielded before expensive local work while an activity view is subscribed. Failed activities retain their state even when a finally block runs. Labels contain no request URLs, query values, client IDs or response payloads. No schema, migration or durable activity history. Version increases from 2.10.0 to 2.11.0 because this is a new backward-compatible application-wide capability, with package/lock and UI/API contracts synchronized. Synthetic browser checks cover concurrent Core, Context, Report, catalog and future-engine tasks, waiting, failure, collapse and clear in both themes. Verification: full suite 1770 passed, 15 skipped; local-only and design checks passed. Additional final App/header/GPO and activity tests 13/13 passed. Product-version UI/API checks passed. Both production builds passed for 2.11.0; no phase completion claimed.


2026-10-01 - Phase 7/13 reader refinement / Maester: native TestScript now appears as a closed Test details disclosure, preserving the complete original code and whitespace. The section uses the retained Maester Title instead of the generic Finding label. If no displayable native result statement exists in the loaded record, a neutral missing-evidence notice appears; no problem statement, remediation or verdict is invented. Existing result-lead and remediation extraction remain unchanged. The source extractor already retains native ResultDetail.TestResult and non-object ResultDetail; the screenshot alone cannot establish whether the original MT.1024 report lacked that text. No extraction change or reimport is required for this presentation fix. Verified: 49 reader tests, including opening/closing full code and retaining a supplied native statement; synthetic browser interaction and visual checks in both themes; client/server builds, local-only security and design checks passed. Version remains 2.10.0 as part of the current unreleased refinement batch; no phase completion claimed.


2026-10-01 - Phase 13 / Result DB CSV export: adds Export CSV beside JSONL and Excel, using the complete filtered scope and the exact disclosed JSONL result projection. CSV uses UTF-8 BOM and semicolons, one row per result, complete nested values as JSON text, plus export date, disclosure policy and handling notice columns. Long values are not truncated. Spreadsheet formula neutralization also covers leading line breaks/control whitespace. Verified: all 33 export/disclosure tests passed, including 1001 filtered results through the CSV button and round-trip checks for quoting, Unicode, line breaks and long values. Browser CSV and Excel downloads and visual review passed in both themes; local-only and design checks passed. No schema or dependency change. This extends the same unreleased 2.10.0 export capability batch, so the product version remains 2.10.0; no phase completion claimed. CSV itself retains long values, but spreadsheet applications may impose their own import limits; XLSX explicitly splits oversized cells. Client and server production builds passed.


2026-10-01 - Phase 13 / Result DB Excel export (bundled into the existing unreleased 2.10.0 capability batch): Result DB offers Export Excel beside Export JSONL. It queries the complete filtered assessment scope through the existing pagination contract and converts the exact disclosed JSONL projection into XLSX; there is no second privacy policy or raw-data path. Results has one row per result, filterable columns and literal cells (no imported formulas); Export info retains the disclosure version and handling notice. Nested values remain JSON text; values above Excel's cell limit are preserved in ordered Long text parts, with explicit references in Results. Excel's worksheet limit produces an actionable error instead of a partial export. The existing xlsx dependency is loaded only when exporting. No schema, backend, dependency or product-version change; 2.10.0 remains the combined release, no phase completion claimed. Verification: 14 focused JSONL/Excel disclosure tests, including a 1001-result UI export across pages, exclusion of a passed result under the active deviation filter, long text reconstruction and literal formula-like text. Synthetic browser download and visual review passed in dark and light. Final verification: full suite 1753 passed, 15 skipped; local-only security and design checks passed; client and server production builds passed.


2026-10-01 - Phase 7/13E UI refinement (bundled into 2.10.0): shared Engines control added to Client Info and Pathfinder. Pathfinder filters now use Work's horizontal controls in the header; Details move to the left, explicitly superseding the earlier right-panel decision. Header grows when filters wrap; narrow graph actions wrap and the left inspector stays in place. No persistence/schema change. Verified: full suite 1738 passed, 15 skipped, security/design checks and both production builds passed; subsequent targeted navigation and graph interaction tests 6/6 passed. Synthetic browser acceptance covers both themes, filter wrapping, left-side Details, node selection and the locked Core Engine checkbox. New navigation acceptance retains optional-engine choices across Work, Client Info and Pathfinder. Version remains 2.10.0 as one related release batch; no phase completion claimed. Real customer data was not used for visual checks.


2026-09-30 - Phase 13E / UI-Stufe Pathfinder (in 2.10.0 gebuendelt, umgesetzt, per Test verifiziert; Sichtpruefung beider Themes steht aus): Bei eingeschaltetem Layer wird jeder Kontext-Cluster mit Befunden im Graphen ein eigener Knoten vom Typ `Context` im Beziehungsring. Jeder Befund, der Belege fuer den Cluster liefert, ist gestrichelt mit ihm verbunden. Cluster ohne Befunde im aktuellen Graphen erzeugen keinen verwaisten Knoten. Ein Klick auf den Cluster-Knoten setzt dieselbe Work-Facette `Context Cluster` wie der Filter; das Graph-Filter-Bridge ordnet einen Cluster-Knoten nie einer gleichnamigen anderen Facette zu. Die Details stehen ausschliesslich im rechten Panel: Zustand, Bedingungen (erfuellt von gesamt, erforderlich, unbekannt), Bedeutung und der Hinweis, dass es sich um eine abgeleitete zweite Lesart handelt. Befund-Details nennen zusaetzlich ihre Cluster. Die bestehenden Pathfinder-Regeln bleiben unveraendert: Text-Schalter, keine Karten im Graphen, Extract Path, Mark all und Reset view. Die Gestaltung nutzt die vorhandene Beziehungsfarbe `--graph-relation` mit groesserem Knotenradius und gestrichelten Kanten; es gibt keine neue Farbe und keine Statusfarbe. Ist der Layer aus, ist der Graph identisch mit dem Graphen ohne Kontext (Test). Tests: Graphaufbau mit und ohne Kontext, Filter-Bridge, Pathfinder-Interaktion mit echtem Engine-Lauf auf synthetischem Befund (Layer an und aus). Volle Suite: 1712 bestanden, 6 bekannte vorbestehende Fehler; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Katalog 1.8.0: GPO-Abweichungen im Kontext, Policy-Analyzer-Suchschluessel ausgeblendet (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, so umsetzen" nach der Feststellung, dass nur 3 von 25 abweichenden GPO-Einstellungen im Dummy einen Cluster hatten. Engine 1.8.0 liest das autoritative, zusammengefasste Baseline-Urteil aus `policy-evaluation` (Abweichung erfuellt die Bedingung, Passed widerlegt sie) und leitet nichts neu her. Den technischen Zielpfad liefert fuer schluesselbasierte Identitaeten wie SrpV2 die neue Lesemethode `listPolicyEvaluations` im Nur-Lese-Port. Katalog 1.8.0 enthaelt 15 Bedingungen und 42 Urteilsregeln: privilegierte Benutzerrechte, Delegierungsrecht, Netzwerk- und lokale Anmelderechte, Ueberwachungsrichtlinie, Firewall-Logging und -Profile, DNS-Client, Softwareeinschraenkung/AppLocker, Sperrzeiten, Kennwortlaufzeit, umkehrbare Speicherung, Anmeldezeiten und Office-Formularanmeldung. Dazu kommt die GPO-Auffangbedingung. Der spezifischste Schluessel entscheidet; katalogisierte Wertsemantiken haben Vorrang. Der Reader zeigt `Evaluated by ASSESSOR` mit dem Urteil. Ausserdem wurde nach Nutzerwunsch der Block `Policy Analyzer search key` im Reader-Kopf ausgeblendet; die Ableitung bleibt erhalten. Nur-Lese-Lauf gegen den Dummy-Client: alle 477 Abweichungen in Work sind in einem fachlichen Cluster (452 Scanner, 25 GPO), der Auffang-Cluster bleibt leer; Revision unveraendert. Volle Suite: 1708 bestanden, 6 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Context-Badges im Finding Reader (in 2.10.0 gebuendelt, umgesetzt, per Test verifiziert; Sichtpruefung steht nach Neustart des laufenden Backends noch aus): Nutzerwunsch: Die Kontext-Cluster eines Befunds erscheinen als etwas groessere Badges links in der Aktionszeile des Finding Readers (vor AI search). Sie nutzen denselben Kontextabruf und dieselbe Zuordnung wie der Context-Abschnitt, springen per Klick dorthin und erscheinen nur bei eingeschaltetem Layer. Die Gestaltung verwendet nur vorhandene Tokens: neutrale Kontur, 14px Semibold, kein Statusfarbton, Hover nur ueber die Flaeche. Der Abnahmetest `Reader ausserhalb des Kontexts mit Layer an und aus identisch` behandelt die Badges als Kontext-Element.

2026-09-30 - Phase 13E / Katalog 1.7.0: jede Abweichung im Kontext (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Jeder Fail oder jede Abweichung ist ein Befund, wird nicht in Frage gestellt und gehoert in einen Cluster; der Kontext ist das zentrale Werkzeug fuer die scanneruebergreifende Struktur. Das ersetzt die polaritaetsbasierten Ausschluesse aus Katalog 1.6.0; AGENTS.md wurde angepasst. Umsetzung: Die Bedingungen sind so formuliert, wie der Befund es aussagt. Beispiele: `LAN-Manager-Ebene unter NTLMv2 only, LM & NTLM verweigern` (zweite Bedingung auf derselben GPO-Semantik), `LDAP-Signierungsdurchsetzung nicht aktiviert`, `automatische Anmeldung nicht ausdruecklich abgeschaltet`, `Global-Admin-Anzahl ausserhalb der Empfehlung`. Engine 1.7.0 ordnet in dieser Reihenfolge zu: exakte Regel-ID; bei CIS-CAT sonst der spezifischste Abschnittstitel aus dem eigenen Report (75 Titel, zum Beispiel Printers, Microsoft Defender Antivirus, Remote Desktop Services, Data Collection and Preview Builds); sonst der sichtbare Cluster `Other Deviations (not yet catalogued)`. `warning` zaehlt jetzt wie `fail` als Abweichung. Katalog 1.7.0 bringt 54 Bedingungen und 38 exakte Regeln sowie die neuen Cluster Data Sharing & Privacy, Physical & Local Access, Patch & Configuration Drift und Other Deviations. Der Reader zeigt die Zuordnung ueber den Report-Abschnitt beziehungsweise `deviation not yet catalogued` an. Tests: Die Engine-Tests wurden auf die neue Regel umgestellt, darunter bleibt eine umnummerierte oder unkatalogisierte Abweichung sichtbar. Neu ist ein Test fuer die Abschnittszuordnung (spezifischster Titel, Elternabschnitt, Vorrang der exakten Regel, Fallback). Nur-Lese-Lauf gegen den Dummy-Client: Jede Abweichung hat einen fachlichen Cluster, der Fallback wird nicht benoetigt (0). 534 Scanner-Befunde sind zugeordnet, davon 288 ueber den Report-Abschnitt, 647 von 885 haben Kontext; alle fachlichen Cluster sind `present`; Revision unveraendert. Volle Suite: 1706 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen (der Abschnittstitel `File Explorer` steht wegen der Kernpruefung kleingeschrieben, der Vergleich ist ohnehin unabhaengig von Gross- und Kleinschreibung).

ISO-Korpus-Upload 2026-09-23 (Phase 13F, 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 13F bleibt in Arbeit.

2026-09-30 - Phase 13E / Katalog 1.6.0 und deklarierte D3FEND-Gegenmassnahmen (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, D3FEND einbauen und uebrige Luecken durchgehen". Engine 1.6.0 gruppiert vom Scanner deklarierte, aktive D3FEND-IDs getrennt von ATT&CK; der Finding Reader zeigt dafuer den Block `Declared D3FEND` mit dem Hinweis `Same countermeasure according to the scanners; not a proven common cause.` Lueckenauswertung: Die ausgefuehrten Befunde ohne Bedingung beim Dummy-Client wurden nach Themen durchgesehen, die in mehreren Scannern vorkommen. Die Bedeutung unklarer Regeln wurde am eigenen Reporttext geprueft. Katalog 1.6.0 ergaenzt 64 Bedingungen mit 113 exakten Regeln. Bestehende Cluster: Credential Relay (u. a. gehaertete UNC-Pfade, SMB-Gastanmeldung, unsichere DNS-Updates, CIS 5.1 Spooler, CIS 18.4.6 NetBT), Kerberoasting (CIS 2.3.11.4 RC4/DES), Password Guessing (Kerberos Armoring), Detection Blind Spots (CIS 17.x, Prozess-Befehlszeile, Sicherheitsprotokoll, NTLM-Audit, Firewall-Logging, Defender for Identity, Entra-Logweiterleitung und Rollenwarnungen), Lateral Movement (LAPS, RDP-Sitzungslimits und -Verbindungsschutz), Host Credential & Privilege (gefaehrliche Benutzerrechte, gespeicherte RDP-Kennwoerter, AlwaysInstallElevated, Remote Credential Guard), AD Privileged (DnsAdmins, Schema Admins) sowie Cloud Sign-in und Cloud Privileged. Neue Cluster: Malicious Code Execution, AD Persistence Indicators, AD Reconnaissance, AD Recovery Gaps, Cloud App Consent und Cloud External Access. Bewusst nicht zugeordnet: PingCastle A-DnsZoneAUCreateChild (der Report stuft ihn selbst als informativ und die Standardkonfiguration als sicher ein); CIS 2.3.11.6 LAN Manager (CIS verlangt Stufe 5, ein Fail auf Stufe 3 oder 4 belegt kein LM/NTLMv1); CIS 2.3.5.4 LDAP-Signierung Enforcement (ein Fail belegt nicht, dass keine Signierung verlangt wird); CIS 18.5.1 AutoAdminLogon (ein Fail belegt nur fehlende Abschaltung); die Global-Admin-Anzahl (ein Fail kann zu viele oder zu wenige bedeuten); MT.INV-Untersuchungen, ablaufende App-Anmeldedaten (Verfuegbarkeit) und reine CA-Pflegeregeln. Der MITRE-Titel T1204.002 steht wegen der Local-only-Pruefung (Muster `File`) als `Malicious file`. Tests: Engine-, Katalog- und Reader-Tests, darunter ein neuer D3FEND-Reader-Test. Nur-Lese-Lauf gegen den Dummy-Client: alle 17 Cluster sind `present`; 208 Scanner-Befunde haben eine exakte Bedingung (vorher 95), 613 von 885 insgesamt Kontext; ausgefuehrte Befunde ohne Bedingung 501 statt 614; Revision unveraendert. Volle Suite: 1705 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Katalog 1.5.0 Password Guessing Exposure (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Anlass war die Nachfrage des Nutzers, warum ein Befund wie Purple Knight SI000096 trotz ausreichender Angaben im Scan keinen Kontext hat. Die Luecke war eine Katalogluecke und keine Datenluecke. Neuer Cluster `password-guessing-exposure` (MITRE T1110.001/T1110.002) mit neun Bedingungen: Kennwortlaenge unter 14 bzw. unter 8 Zeichen, Komplexitaet aus, Sperrschwelle aus oder ueber 5, kurze Sperr-/Zuruecksetzzeit, schwache Richtlinie fuer privilegierte Nutzer, keine Richtlinie fuer lange Dienstkonto-Kennwoerter sowie die bestehenden Bedingungen fuer nie ablaufende Kennwoerter. Die Zuordnung erfolgt nur ueber exakte Regel-IDs mit dem nativen Regeltext: CIS-CAT 1.1.4/1.1.5/1.2.1/1.2.2/1.2.4, PingCastle A-MinPwdLen/S-PwdNeverExpires/A-NoServicePolicy und Purple Knight SI000096. Die Entra-Regeln EIDSCA.PR01/PR03 (Kennwortschutz) und PR05/PR06 (Smart Lockout) ergaenzen den bestehenden Cluster `cloud-sign-in-protection-gaps`, A-NoServicePolicy zusaetzlich `kerberoasting-exposure`. PingCastle P-ServiceDomainAdmin bleibt bewusst ungemappt, weil ein Pass (weniger als zwei Konten) die Bedingung nicht widerlegt. GPO: Die Kontorichtlinien aus [System Access] (MinimumPasswordLength, PasswordComplexity, LockoutBadCount) sind nun katalogisiert. Engine 1.5.0 liest dafuer nur exakte Ganzzahlen aus `scalar`-Werten; alles andere bleibt `unknown`. Tests: synthetischer Regressionstest mit GPO-Wert und Befunden aller Scanner, inklusive Widerspruch zwischen deklariertem und beobachtetem Wert und `not_run`. Nur-Lese-Lauf gegen den Dummy-Client: der Cluster ist `present` mit 9 von 9 Bedingungen, Entra-Anmeldeschutz 7 von 7. Eine GPO-Sicherung deklariert abgeschaltete Komplexitaet, waehrend CIS-CAT 1.1.5 auf dem Host besteht; das wird als Widerspruch angezeigt. 558 von 885 Scanner-Befunden haben Kontext; Revision unveraendert. Volle Suite: 1704 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen. Offen zur Nutzerentscheidung: Gruppierung nach vom Scanner deklarierten D3FEND-Gegenmassnahmen (Purple Knight: 70 Deklarationen in 19 Gruppen).

2026-09-30 - Phase 13E / CIS-Kontrollbereich (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, CIS-Kontrollbereich auch einbauen"; sie ersetzt den Vermerk im vorigen Eintrag, dass der CIS-Kontrollbereich nicht gewaehlt wurde. Engine 1.4.0 gruppiert CIS-CAT-Befunde nach der exakten Nummernhierarchie ihrer Regel-ID (`9.1.1` liegt in `9.1` und `9`), und zwar nur innerhalb desselben Scan-Laufs, weil andere Benchmarks dieselben Nummern verwenden. Titel und die vom Scan genannten Pass/Fail-Zahlen stammen aus der gespeicherten Abschnittstabelle `cis-cat-section-scores` desselben Reports (bestehender Helper `cisBenchmarkSectionTitles`); mehrdeutige Titel oder Zahlen entfallen. Dafuer liest der Nur-Lese-Port zusaetzlich `getEnvironmentSnapshot`, begrenzt auf die CIS-Laeufe im Scope. Der Finding Reader zeigt den Block `CIS control area` mit oberstem und naechstem Abschnitt, Anzahl im Timeslot, Fail/Pass und dem Abschnittsscore laut Scan-Report sowie dem Hinweis `Same benchmark section of this scan report; not a proven attack chain.` Tests: synthetische Engine-, Lauf- und Reader-Tests, u. a. fuer die Trennung nach Scan-Lauf und fuer mehrdeutige Tabellenzeilen. Nur-Lese-Lauf gegen den Dummy-Client: 551 von 885 Scanner-Befunden haben Kontext (vorher 171); 160 CIS-Abschnitte, alle mit Titel und Scan-Zahlen, und die Scan-Zahlen stimmen mit den importierten Befunden ueberein; Revision unveraendert. Volle Suite: 1702 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen (node-import-engine unter Volllast zeitweise instabil, einzeln 5/5); beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / deklarierte ATT&CK-Taktik und CIS-Cluster (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Vom Scanner deklarierte ATT&CK-Referenzen duerfen Befunde im Kontext verbinden, und zwar nur `declared`, aktiv und mit exakter ID; die Aussage lautet `gleiche Taktik laut Scanner`, nie `gleicher Angriffsweg`. AGENTS.md und REFERENCE_RECOGNITION.md wurden entsprechend angepasst. Engine 1.3.0 liest dafuer die gespeicherten Referenzlaeufe (neueste Laufe je Scan, nur Befunde des Timeslots; die Lesemethode `listReferenceRuns` wurde im Nur-Lese-Port ergaenzt). Der Reader zeigt den Block `Declared ATT&CK` mit Anzahl, Scannern und Fail/Pass. Katalog 1.4.0 (Nutzerwahl Richtung 1): Relay wurde um mDNS, NetBIOS und WPAD erweitert, Kerberos Delegation um das Hinzufuegen von Computerkonten (SI000011, S-ADRegistration). Neu sind `Lateral Movement Exposure` (RDP ohne NLA, WinRM Basic/unverschluesselt/Remote-Management, SMBv1, Firewall aus bzw. eingehend erlaubt, breite Netzwerk-Anmelderechte), `Host Credential & Privilege Exposure` (gespeicherte Netzwerk-Anmeldedaten, eigene SSPs in LSASS, WinRM-RunAs, UAC) und `Detection Blind Spots` (PowerShell-Logging, A-AuditPowershell, A-AuditDC). ATT&CK-IDs gibt es nur dort, wo MITRE den Zusammenhang dokumentiert (T1021.x, T1555.004, T1547.005, T1548.002, T1557.001); PowerShell-Logging, WPAD und WinRM-RunAs bleiben ohne ID. Der CIS-Kontrollbereich wurde nicht gewaehlt; der ARF-Import wird nicht verfolgt. Nur-Lese-Lauf gegen den Dummy-Client: 171 von 885 Scanner-Befunden haben Kontext (vorher 51), davon 82 ueber Cluster und 116 ueber deklarierte ATT&CK-IDs (beim Dummy deklariert nur Purple Knight); 0 abgewiesen, alle 10 Cluster `present`, Revision unveraendert.

2026-09-30 - Phase 13E / Work-Facette `Context Cluster` (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Die Facette erscheint nur bei eingeschaltetem und geladenem Layer, direkt vor `Source: Scan`. Beschriftet ist sie gemaess der UI-Sprachentscheidung englisch. Sie bietet alle Katalog-Cluster, auch mit 0 Treffern. Ein Record gehoert zu einem Cluster, wenn er Belege liefert: GPO-Zeilen ueber Technical Identity und Scope, Scanner-Befunde ueber die Finding-Occurrence. Die Facette wird zentral in `filterAndSortRecords` und `selectWorkFacets` eingehaengt; Liste, Zaehler, Facettenzaehlung, Sidebar-Domains und Work-Export nutzen denselben Index. Mit ausgeschaltetem Layer entfaellt sie, und diese Pfade laufen wie zuvor. Aenderungen am Assessor-Filtercode sind additiv: optionales `valuesFor` an `DynamicFacet`, optionales `contextClusters` in den Filteroptionen. Abschalten entfernt einen aktiven Kontextfilter ueber den bestehenden Abgleich der Filterleiste. Waehrend der Layer an ist und laedt, bleibt ein gesetzter Filter bestehen; eine Aktualisierung desselben Timeslots nutzt den letzten geladenen Stand weiter. Verifiziert: 5 Facettentests (Dauerpruefung an/aus identisch, exakte Clusterauswahl, alle Cluster, Position vor `Source: Scan`, Entfernen beim Abschalten, Erhalt beim Laden) und ein Grenztest (Client Info, Scoring, Result DB und Server-Persistenz ohne Kontextimport). Vollsuite 1696 bestanden; die bekannten 7 Fehler unveraendert. `tests/server/node-import-engine.test.ts` lief in der Vollsuite einmal in ein Timeout (`STACK_TRACE_ERROR`, keine fachliche Abweichung); einzeln besteht er 5/5. Er beruehrt den Import-Parser und nicht diese Aenderung und ist als zeitabhaengig wackelig vermerkt. Beide Builds, Local-only- und Design-Check bestanden. In der echten App mit dem Dummy-Client: Aus zeigt 477 Befunde ohne Facette; an zeigt 477 Befunde mit Facette vor `Source: Scan` und Zaehlungen je Cluster; `Credential Relay Exposure` gewaehlt zeigt 8 Befunde, und die Sidebar-Domains zaehlen mit; wieder aus entfernt Facette und Filter, und es sind 477 Befunde. Naechster Schritt laut Reihenfolge: Pathfinder.

2026-09-30 - Phase 13E / neue Reihenfolge Schritt 1: AD-Katalog-Batch (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Katalog 1.3.0 mit drei neuen Clustern. `Kerberos Delegation Abuse`: Purple Knight SI000079, SI000080, SI000066, SI000071, SI000070, SI000065, SI000099, SI000016, SI000031 sowie delegierbare Admins (P-Delegated). `AD CS Escalation`: SI000157, PingCastle A-CertTempCustomSubject, SI000156, SI000090, SI000091, SI000095. `Kerberoasting Exposure`: privilegierte SPNs, SI000152, SI000151, SI000067, SI000029. Erweitert wurden `Credential Relay Exposure` um Coercion ueber den Print Spooler auf DCs (SI000077, A-DC-Spooler; T1187) und ESC8 als Relay-Ziel sowie `AD Privileged Account Exposure` um Shadow Credentials (SI000351). ATT&CK-IDs stehen nur dort, wo MITRE die Technik dokumentiert (T1187, T1649, T1558.003). Fuer Delegation nennt keine gepruefte Technik S4U oder RBCD (T1558, T1550.003 geprueft); diese Aussagen tragen deshalb keine ATT&CK-ID und stuetzen sich auf die Microsoft-Doku zu Kerberos Constrained Delegation und den Scan-Report. Ausgeschlossen: A-WeakRSARootCert2 (kein Eskalationspfad). Ein Befund kann mehrere Cluster stuetzen (P-Delegated in zwei). Der Reader-Hinweis nennt jetzt die Abdeckung (`context covers X of Y scanner findings and Z GPO settings`). Ein gehaerteter Relay-Cluster aus reinen GPO-Werten ist jetzt korrekt `undetermined`, weil Spooler und ESC8 nur Scanner belegen; `not-present` ist mit passenden Scanner-Ergebnissen weiter getestet. Verifiziert: Vollsuite 1691 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 51 von 885 Scanner-Befunden zugeordnet (vorher 29), 0 abgewiesen, alle 7 Cluster `present`, Revision unveraendert. In der echten App zeigt der Nutzerbefund `Write access to RBCD on DC` (SI000079) jetzt Kontext; der Hinweis zeigt 51 von 885. Schalter und Suche wurden danach zurueckgesetzt. Naechster Schritt laut neuer Reihenfolge: Work-Facette `Kontext-Cluster`.

2026-09-30 - Phase 13E / Nutzerentscheidung neue Reihenfolge der UI-Stufen: Die Reihenfolge aus Freigabe (b) wird geaendert. Grund: Bei rund 3 % Katalogabdeckung wirken weitere Ansichten leer, und die dauerhafte Pruefung `Layer an/aus identisch` gehoert zur Work-Facette und soll stehen, bevor der Layer in weitere Ansichten wandert. Neue Reihenfolge: (1) AD-Katalog-Batch (Kerberos Delegation, AD CS, Erweiterung des Relay-Clusters um Coercion, Kerberoasting) und ein Hinweis mit Abdeckungszahl im Reader, (2) Work-Facette `Kontext-Cluster` mit dem Test, dass Work-Zahlen, Filter und Status mit Layer an und aus identisch bleiben, (3) Pathfinder, (4) Client Info. Die Freigaben (a) und (c) bleiben unveraendert; Stufe 1 Finding Reader ist erledigt.

2026-09-30 - Phase 13E / Nutzerentscheidung Scan-Report (Wortlaut): "Explicit user decision 2026-09-30: for every scanner, the official scan report is authoritative. Rule IDs, rule text and outcomes it states are accepted as they are; no separate verification against vendor documentation is required. Exact rule-ID matching and the rule that non-executed checks stay unknown remain unchanged." Umsetzung: Das Belegart-Feld `verifiedAgainst` und die Pflicht einer Dokumentationsquelle je Scanner-Regel entfallen. Eine Scanner-Regel braucht nur exakte Rule-ID, Regeltext aus dem Report und Polaritaet `fail-means-met`; vorhandene Herstellerquellen bleiben als optionale Leseverweise. Exakte Rule-ID-Zuordnung, CIS-Umnummerierungsschutz und `nicht ausgefuehrt = unbekannt` sind unveraendert. Verifiziert mit Tests (eine Regel ohne Dokumentationsquelle ist gueltig; ungueltiger optionaler Link und fehlender Regeltext werden weiter abgewiesen). Katalogversion 1.2.0 bleibt, weil sich keine Zuordnung und kein Ergebnis aendert.

2026-09-30 - Phase 13E / Kontext Schritt 3, weitere Cluster (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Katalog 1.2.0 und Engine 1.2.0 fuehren eigenstaendige Bedingungen ein, die nur Scanner beobachten (ohne GPO-Einstellung). Neue Cluster: `Cloud Privileged Access Exposure` (Maester CISA.MS.AAD.7.4, MT.1025, MT.1027, CISA.MS.AAD.7.3, CIS.M365.1.1.1, CISA.MS.AAD.3.6, MT.1024.adminMFAV2), `Cloud Sign-in Protection Gaps` (CISA.MS.AAD.1.1, MT.1024.blockLegacyAuthentication, CISA.MS.AAD.2.3, MT.1012, MT.1024.signinRiskPolicy, CISA.MS.AAD.3.1, CISA.MS.AAD.3.5) und `AD Privileged Account Exposure` (PingCastle P-Delegated, P-ProtectedUsers, P-AdminLogin; Purple Knight SI000020, SI000028, SI000019). Jede Aussage ist als `favours`/`begünstigt` formuliert und traegt eine geprueft verlinkte ATT&CK-Technik: T1078.004, T1110.003, T1078.002 oder T1558.003. Die Wortwahl-Pruefung hat zwei Aussagen mit `kompromittierter Konten` abgewiesen; sie lauten jetzt `Anmeldungen mit gestohlenen Zugangsdaten`. Bewusst ausgeschlossen: die Global-Admin-Anzahl (CISA.MS.AAD.7.1, MT.1032, CIS.M365.1.1.3), weil ein Fail `zu viele` oder `zu wenige` bedeuten kann. Nutzerentscheidung 2026-09-30: Der offizielle Scan-Report ist massgeblich. Eine dort genannte Regel gilt, auch wenn die Herstellerdoku hinterherhinkt (die veroeffentlichte PingCastle-Liste enthaelt z. B. die P-Regeln nicht). Die Belegart je Scanner-Regel heisst `scanner-report` bzw. zusaetzlich `vendor-documentation`, beide mit gleichem Gewicht; AGENTS.md wurde ergaenzt. Neue Invariante: Jede Cluster-Bedingung hat mindestens eine Belegquelle. Verifiziert: 2 neue Tests, Vollsuite 1691 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 29 von 885 Scanner-Befunden zugeordnet (vorher 9), 0 abgewiesen; alle vier Cluster sind `present` (Relay 4/7, Cloud Privileged 6/6, Sign-in 5/5, AD Privileged 3/4); die Revision blieb unveraendert.

2026-09-30 - Phase 13E / Kontext fuer alle Scans, Schritte 1 und 2 (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Auf Nutzerwunsch erscheint der Abschnitt `Context` jetzt bei jedem Finding aller Scanner; Befunde ohne Katalogeintrag erhalten den Hinweis `not in the context catalog ... yet`. Katalog 1.1.0: Die LLMNR-Bedingung ist praezisiert zu `LLMNR is not turned off` (GPO-Wert 1 erfuellt sie weiterhin), dazu kommen 9 Scanner-Zuordnungen mit exakter Tool- und Rule-ID, Polaritaet `fail-means-met`, Original-Regeltext und Quelle: PingCastle S-OldNtlm und A-NoGPOLLMNR, Purple Knight SI000154 und SI000153, CIS 2.3.9.2, 2.3.8.1, 2.3.11.8, 2.3.5.3 und 18.6.4.4. CIS-Zuordnungen verlangen zusaetzlich den exakten Einstellungsnamen im Befund als Schutz gegen Umnummerierung. Bewusst ausgeschlossen: CIS 2.3.11.6 (Fail heisst nur `nicht Stufe 5`, das beweist keine LM/NTLMv1-Antworten), CIS 2.3.5.4 (Semantik der neuen Enforcement-Einstellung nicht belegt) und Purple Knight SI000188 (anderes Thema). Fuer LDAP-Signierung und Channel Binding gibt es keine belegbare PingCastle-ID; die veroeffentlichte Regelliste ist aelter als A-NoGPOLLMNR, das nativ in den Daten vorkommt. Engine 1.1.0: Beobachtete Fakten (`observed-by-scanner`) stehen getrennt von den deklarierten (`declared-in-gpo-backup`). Fail erfuellt die Bedingung, Pass widerlegt sie, alle anderen Outcomes bleiben unbekannt. Neues Signal `declaredVersusObserved`, wenn GPO-Deklaration und Scanner-Beobachtung auseinandergehen; Anbindung an Scanner-Findings ueber die Finding-Occurrence. Die Timeslot-`scanRunIds` gelten nur fuer Scanner-Befunde, wie in Work. Der Reader zeigt je Bedingung alle Belege nebeneinander. Verifiziert: 5 neue Tests (exakte Zuordnung, Umnummerierungsschutz, gleichlautender Titel mit anderer Rule-ID wird nicht zugeordnet, not_run bleibt unbekannt, Widerspruchssignal, Timeslot-Filter, Scanner-UI). Vollsuite 1689 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 885 Scanner-Befunde, davon 9 zugeordnet und 0 durch den Schutz abgewiesen; der Cluster ist `present` (4 Bedingungen erfuellt, 3 nicht erfuellt, 0 unbekannt); die Revision blieb unveraendert. In der echten App zeigt der PingCastle-Befund S-OldNtlm den Context mit der Beobachtung und dem Cluster; der Schalter wurde danach zurueckgesetzt. Ein Screenshot war nicht moeglich, weil das Pane nicht zeichnete; die Pruefung lief ueber den DOM-Text.

2026-09-30 - Phase 13E / Kontext-Layer Stufe 1 Finding Reader (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Die englische Oberflaeche beschriftet den Layer mit `Context` und nutzt die englischen Aussagen (`favours`); `Kontext` und `begünstigt` gelten fuer deutsche Reports. AGENTS.md wurde entsprechend praezisiert. Der Schalter `Context` steht in der Work-Werkzeugleiste neben `My Workspace` im gemeinsamen Button-Stil (aria-pressed, gelbe Aktivmarkierung); Standard aus, lokal je Anwender gespeichert (`ASSESSOR.contextLayer`). Der Abschnitt `Context` im Finding Reader erscheint nur fuer GPO-Datensaetze und nur bei eingeschaltetem Layer, nach Problem, Next step, GPO-Quellen und Wertevergleichen und vor Description und Remediation. Er zeigt die deklarierten Backup-Werte mit Bedeutung und Link-Hinweis, Bedingungen mit Glyph und Text, `favours`-Aussage mit ATT&CK-ID, den Clusterzustand mit Zaehlwerten und die Quellen als https-Links mit `noopener noreferrer`. Nicht katalogisierte Einstellungen erhalten einen klaren Hinweis. Die Darstellung ist eine neutrale Tile-Flaeche ohne Statusfarbe und nutzt nur bestehende Tokens. Die Daten werden einmal je Scope und geladenem Datenstand angefragt, nicht je Datensatz. Verifiziert: 5 Verhaltenstests (aus: kein Request; an: ein Request und Inhalte; der Reader ausserhalb des Abschnitts ist mit Layer an und aus identisch; Abschalten entfernt den Abschnitt; Speicher; keine Filter-, Review- oder Schreibaufrufe im Layer-Code). Echte App mit dem freigegebenen Dummy-Client in Dark und Light: Schalter sichtbar, Abschnitt bei `RequireSecuritySignature` mit Katalogdaten, Abschalten entfernt ihn; Theme und Schalter danach zurueckgesetzt. Vollsuite 1684 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check (unveraendert 18 bestehende Treffer) bestanden. Offen: In der Backup-Zeile steht die ASSESSOR-Backup-Instanz-ID statt eines GPO-Namens, weil die Beobachtung keinen Anzeigenamen traegt; Pathfinder, Work-Facette und Client Info.

2026-09-30 - Phase 13E / Kontext-Engine und API (in 2.10.0 gebuendelt, umgesetzt und verifiziert; UI-Stufen offen): Neues Modul `src/assessment-context/` mit Katalog 1.0.0, Engine 1.0.0 und `context-run.ts`. Die Engine liest dieselben aktuellen `policy-observation`-Ergebnisse wie Work und deren gespeicherte Identitaetsaufloesung, prueft die Revision vor und nach dem Lesen und erzeugt kein Verdict, keine Prioritaet und keinen Hostzustand. Neuer Endpunkt `GET /api/v1/projects/:id/assessment-context?assessmentIds=...`: Timeslot ist Pflicht (400), Projektpruefung (404), 503 bei nicht verfuegbarer Engine, 409 bei wechselndem Datenstand; begrenzter Cache je Revision und Scope. Er nutzt denselben schreibgeschuetzten Leser wie die Report Engine. Layer-Andockpunkt: `settings` je Technical Identity und Scope, identisch zu den Feldern der Work-GPO-Zeile. Dazu kommen Vertragstyp `AssessmentContextResponse` und Client-Methode `getAssessmentContext`; die UI ruft noch nichts auf. Verifiziert: 12 neue Tests (Katalogvalidierung, Konflikte, unverlinkte Quellen, geloeschte und unbekannte Werte, Clusterzustaende, Determinismus, unveraenderte Eingaben, Revisionspruefung, Architekturgrenze, unveraenderte gespeicherte Daten) und HTTP-Tests. Nur-Lese-Lauf gegen den freigegebenen Dummy-Client: 51 Beobachtungen, davon 3 semantisch zugeordnet und 0 unaufgeloest; der Cluster ist `undetermined`, weil 2 Bedingungen nicht erfuellt und 5 nicht deklariert sind; die Revision blieb unveraendert. Vollsuite 1679 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only-Check (jetzt inklusive `src/assessment-context`) und Design-Check bestanden. Versionsentscheidung: in der noch nicht committeten Release 2.10.0 gebuendelt. Keine Reimport-, Schema- oder Datenbankaenderung.

2026-09-30 - Phase 7 / Report Engine v0.2 (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Die Nutzerentscheidung legt die Kernaussagen Gesamtbild, Schwerpunkt und Aussagegrenze fest, platziert unter den drei Kennzahlen des Management Reports, mit Belegen im Technical Report und im Archiv. `src/reporting/report-narrative.ts` (1.0.0) leitet die Aussagen deterministisch nur aus den Aggregaten ab. Gleichstaende nennen alle beteiligten Domains; Anteile werden exakt verglichen; eine Aussage ohne Datengrundlage entfaellt; es gibt keine Schwere-, Risiko- oder quellenuebergreifende Rangaussage. `report-statement-text.ts` enthaelt die feste deutsche Formulierung fuer beide Renderer. Ein positiver Anteil wird nie auf 0 % gerundet, sondern als `unter 1 %` angezeigt. Die Projektion 1.2.0 fuehrt ID-Listen je Security Domain und je Abdeckungsgruppe; die nicht bewerteten Gruppen zerlegen alle nicht bewerteten Ergebnisse vollstaendig. Management-Renderer 2.1.0 (Block `Kernaussagen`, ohne IDs) und Technical-Renderer 1.1.0 (`Belege der Kernaussagen` mit demselben Satz und den Result-IDs; Result-Index mit Result-ID-Spalte). Report-Engine-Version 0.2.0; das Archiv-Manifest fuehrt die Narrative-Version. Verifiziert: 5 neue synthetische Tests (Zahlen, Gleichstand, Einzahl/Mehrzahl, unter 1 %, fehlende Grundlage, Position unter den Kennzahlen, keine IDs im Management Report, Belege im Technical Report); Vollsuite 1667 bestanden, 15 uebersprungen, dieselben 7 bestehenden Fehler; TypeScript, beide Builds, Local-only- und Design-Check bestanden. Sichtpruefung mit synthetischen Beispieldaten ueber eine voruebergehende lokale Vorschau: Block unter den Kennzahlen im Stil des Abschnitts `Lesart`; bei 375 px kein horizontaler Ueberlauf und 16 px Randabstand. Die voruebergehende Startkonfiguration wurde wieder entfernt. Versionsentscheidung: v0.2 wird mit der noch nicht committeten v0.1 in 2.10.0 gebuendelt, keine weitere Versionserhoehung. Keine Reimport-, Schema- oder Datenbankaenderung.

2026-09-30 - Phase 7 / Report Engine v0.1 (2.10.0, umgesetzt und verifiziert mit einer offenen Teilabnahme): Die Report Engine laeuft eigenstaendig neben ASSESSOR und liest nur. Neu sind der Lese-Port `src/reporting/report-read-port.ts` (nur 11 Lesemethoden, eingefroren, ohne Schreibmethoden) und `report-run.ts` (Revision vor und nach dem Lesen, bis zu drei Versuche, sonst `ReportStateChangedError`/HTTP 409). Server-Adapter: `server/reporting/report-read-runtime.ts` mit eigenem Pool (`default_transaction_read_only=on`, `application_name` assessor-report-reader, max. 2 Verbindungen, keine Migrationen) und `server/reporting/report-archive.ts` (einmalig geschrieben, schreibgeschuetzt, Manifest mit SHA-256, Loeschung mit dem Client, Speicherort per `ASSESSOR_REPORT_ARCHIVE_DIR` bzw. lokalem Anwendungsdatenordner, nie in Repository, Anwendungsordner oder OneDrive). Ergaenzungen ausserhalb der Engine, ohne Aenderung der Assessor-Logik: `PostgresAssessorRepository.openReadOnly` (verweigert beschreibbare Sitzungen und stoesst keinen Result-DB-Neuaufbau an; noetig, weil `create()` schreibt), `sslConfiguration` exportiert, Startverdrahtung (faellt die Engine aus, laeuft ASSESSOR weiter und nur Reportlaeufe werden mit 503 abgelehnt), Archivloeschung beim Loeschen eines Projekts, Projektpruefung mit 404 in beiden Report-Routen, neuer Endpunkt `POST /projects/:id/report-runs`, und `report-projection` liest ueber den Port. Client Info laedt jetzt die serverseitig erzeugte, archivierte Datei; der Browser rendert keine Reports mehr, und der Report-Inhalt ist unveraendert. Compose-Deployment erhaelt ein eigenes Report-Archiv-Volume. Verifiziert: Vollsuite 1662 bestanden (13 neue Tests), 15 uebersprungen, dieselben 7 bestehenden Fehler; TypeScript fuer Client und Server, beide Builds, Local-only- und Design-Check; Architekturtest um Server-Adapter erweitert. Inhaltsfreie Pruefung gegen die kanonische Datenbank ohne Schreibversuch (schreibgeschuetzte Sitzung, Revision unveraendert, keine Schreibmethode erreichbar). Offen: Ausfuehrung des Integrationstests fuer eine abgelehnte Schreibanweisung mit einer Testdatenbank. Versionsentscheidung: Minor-Version 2.10.0 fuer die rueckwaertskompatible neue Faehigkeit (Archiv und Report-Lauf-API), zusammen mit der verhaltensneutralen Verschiebung. Keine Reimport-, Schema- oder Migrationsaenderung, und die Datenbank wird nicht veraendert.

2026-09-30 - Phase 7 / Report Engine Schritt 1: Verschiebung nach `src/reporting/` (umgesetzt und verifiziert): Projektion, Korrelation, Assembler, `client-report-projection` und beide Renderer liegen ohne Logikaenderung in `src/reporting/`, ihre Tests in `tests/reporting/`. Angepasst wurden nur Importpfade (API-Client nur Typimport, DashboardPanel, HTTP-Server). Neuer Architekturtest `tests/reporting/reporting-boundary.test.ts` erzwingt: Aus der Engine importieren nur DashboardPanel, HTTP-Server und API-Client (nur Typen); kein Aufruf schreibender `AssessorRepository`-Methoden; keine Imports aus React/Tauri/pg, `server/`, `src/app` oder `src/components`. Er wurde mit absichtlichen Verstoessen gegengeprueft. `src/reporting` ist zusaetzlich im plattformneutralen Local-only-Check. Verifiziert: Vollsuite 1649 bestanden (vorher 1645, plus 4 Grenztests), 14 uebersprungen; dieselben 7 bestehenden Fehler in 6 Dateien, kein neuer und keiner entfallen. TypeScript fuer Client und Server, beide Produktionsbuilds, Local-only- und Design-Check bestanden. Versionsentscheidung: keine Aenderung der Produktversion, weil es ein verhaltensneutraler Zwischenschritt ist; er wird mit Report Engine v0.1 gemeinsam versioniert. Keine Reimport-, Persistenz-, API- oder UI-Aenderung.

2026-09-30 - Phase 7 / Report Engine entschieden (geplant, keine Umsetzung): Der Nutzer entscheidet die Verschiebung der Report-Bausteine nach `src/reporting/` ohne Logikaenderung, ein serverseitiges unveraenderliches Reportarchiv ausserhalb von Repository und OneDrive (`ASSESSOR_REPORT_ARCHIVE_DIR`, Loeschung mit dem Client) und die vier Grenzen: gemeinsamer Domain-Katalog, Severity nur je Quelle, Review-Status nur als Selbstauskunft und nicht in Report A, Szenarien nur ueber Phase 13E. Einzelheiten und Abnahme stehen in Phase 7, Abschnitt Report Engine. Nur Plan-Dokumentation; Produktversion unveraendert.

2026-09-30 - Phase 13E / Kontext-Engine und abschaltbarer Kontext-Layer (geplant, Nutzerfreigabe, keine Umsetzung): Der Nutzer gibt (a) einen kuratierten, quellenbelegten und versionierten Semantic-/Relationship-/Cluster-Katalog, (b) die Reihenfolge Engine/API, Finding Reader, Pathfinder, Work-Facette, Client Info und (c) die nur bei eingeschaltetem Layer sichtbare Work-Facette `Kontext-Cluster` als Ergaenzung der GPO-Facettenliste frei. Der Kontext ist eine parallele, abschaltbare Lesart ueber gespeicherten Assessor-Ergebnissen. Er veraendert weder Verdict noch Score, technische Filter, Reviews, Result DB oder Priority Findings, und er speist spaeter auch die Report Engine. Kein `CANONICAL_MODEL v2`, weil Observation, Identitaet, Aggregation, Evaluation und Conflict/Duplicate in Phase 13B bereits bestehen. Einzelheiten, Grenzen und Abnahme: Abschnitt Phase 13E. Nur Plan-Dokumentation; Produktversion unveraendert.

Referenzerkennung 2026-09-26 (Phase 13D, erster Umfang umgesetzt und verifiziert, Version 2.8.0): ATT&CK/D3FEND werden gemeinsam aus gespeicherten Originalfeldern erkannt und mit Quellen-/Katalogherkunft in eigenen Laeufen gespeichert. Normale Batchimports leiten automatisch ab; bestehende Scans werden ueber `Recognize references` im Clientbereich explizit nachverarbeitet. Pathfinder und Reader nutzen die gespeicherten Referenzen. PostgreSQL-Migration 023 mit vorherigem verifiziertem Backup; keine Client-Datenbanktrennung, Finding-Identitaets-, Scoring- oder Review-Aenderung. Siehe Phase 13D und `docs/REFERENCE_RECOGNITION.md`.

Status: lebendes Projektdokument  

Gefiltertes Result-DB-ISO-Batchmapping 2026-09-16 (Phase 13F, 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 13F, 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 13F, 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 13F, 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 13F, 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 13F, 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 13F, 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.

2026-09-29 - Phase 7 / produktiver Management Report mit Heatmap und Ergebnisbalken (2.9.1, umgesetzt und fokussiert verifiziert): Die bestehende Client-Info-Aktion `Management Report` erzeugt fuer den gewaehlten Kunden und Timeslot jetzt den faktenbasierten HTML-Bericht aus der gemeinsamen Reportprojektion. Der alte Mixed-Method-Score, Donut, Domain-Spine, Priority-Finding-/Scannerlisten, Konvergenz, Massnahmen und Source Overview entfallen nur aus Report A; Report B bleibt technisch. Der Bericht zeigt erfasste DC, bewertete und abweichende Ergebnisse, eine Heatmap des Abweichungsanteils und die zusaetzlich vom Nutzer gezeigte Pass-/Abweichungs-Grafik mit Pass Rate und Stueckzahlen je Security Domain. Unbewertete Bereiche erhalten keine Prozentzahl; GPO-Ergebniszeilen und Policy-Vergleiche bleiben getrennte Zaehleinheiten. Keine LLM-, Internet-, Zeitfortschreibungs- oder Business-Risikoableitung. Der separate Dummy-HTML-Entwurf und sein Download-ZIP enthalten dieselbe zweite Grafik; die Produktionszahlen sind dynamisch, der Dummy-Entwurf bleibt ein gespeicherter Beispielstand. `docs/REPORT_STRATEGY.md` haelt die explizite Abloesung des frueheren Report-A-Inhaltsvertrags fest. Entscheidung: Patchversion 2.9.1 fuer die rueckwaertskompatible Export-Darstellung; keine Projektions-, API-, Persistenz-, Import- oder Datenbankaenderung. Verifiziert: 13 fokussierte Renderer-, Client-Info-Klickpfad- und UI/API-Versionsvertragstests, beide Produktionsbuilds, Design- und Local-only-Pruefung sowie `git diff --check`. Risiko/Abnahmegrenze: Die Security-Domain-Zuordnung bleibt die bestehende heuristische Zuordnung; die Grafik ist keine Risiko- oder Schutzgradbewertung. Eine visuelle Browserabnahme des produktiv heruntergeladenen HTML steht aus; der Phasenstatus wird nicht als neu abgeschlossen markiert. Nachpruefung 2026-09-30 vor dem Release-Commit: Vollsuite 1645 bestanden, 14 uebersprungen, 7 Fehler in 6 Dateien; dieselben 7 Fehler treten auf dem vorherigen Commit ohne 2.9.1 identisch auf und sind damit bestehend, nicht durch 2.9.1 verursacht. Client- und Serverproduktionsbuild bestanden.

2026-09-29 - Phase 7 / faktenbasierte Management-HTML mit Heatmap: Auf ausdrueckliche Nutzerkorrektur zeigt reports/management-dummy-fakten-heatmap-2026-09-29.html nur heute vorhandene Dummy-Reportwerte (ein erfasster DC; 998 bewertete, davon 579 abweichende Ergebnisse; neun Security-Domain-Zuordnungen einschliesslich Nicht zugeordnet). Die Heatmap kodiert ausschliesslich den Anteil abweichender bewerteter Ergebniszeilen je Bereich, nicht Risiko oder Schwere; GPO-Ergebniszeilen und gesonderte Policy-Vergleiche sind sichtbar als unterschiedliche Zaehleinheiten bezeichnet. Kein Mixed-Method-Score, keine scannerbezogene Rangliste, keine erfundenen Szenarien, Business-Auswirkungen oder Zeitfortschreibung. Statische Pruefung: neun Tilewerte und Farbstufen korrekt, Summen 579/998, lokale Assets vorhanden, keine Skripte. Dies ist ein separater HTML-Darstellungsentwurf aus bereits gespeicherten Dummy-Exportzahlen, keine produktive Generatoraenderung und kein frischer Datenbankabzug. Produktversion unveraendert; visuelle Browserabnahme wegen lokaler URL-Richtlinie offen.

2026-09-29 - Phase 7 / manuell redigierter Management-Brief zum freigegebenen Dummy: Nach Nutzerentscheidung, vorhandene Dummy-Befunde fachlich zu verdichten, wurde reports/management-dummy-managementbrief-2026-09-29.html als neuer einseitiger HTML-Entwurf erstellt. Der Brief nutzt das zuletzt gewuenschte neutrale ASSESSOR-Layout, trennt je Risikobereich Beobachtung, moegliche Betriebswirkung und offenen Nachweis und verzichtet auf Mischscore, Domain-Balken, Toolnamen, Findinglisten, erfundene Fristen und Fortschrittsbehauptungen. Die Aussagen zu geschuetzten AD-Rechten, Admin-Aktivitaet, Zertifikatsdiensten, einem erfassten DC, zuletzt gemeldetem Backupdatum und Cloud-Zugriffsschutz beruhen auf den zuvor gesicherten Dummy-Befunden; kritische Dienste, OT-Abhaengigkeiten, tatsaechliche Ausnutzung und Wiederherstellbarkeit bleiben offen. Dies ist manuelle Berichtserstellung und belegt noch keine entsprechende automatische ASSESSOR-Funktion. Statische HTML-/Daten- und lokale Assetpruefung bestanden (ein Blatt, drei getrennte Risikobereiche, keine Scanner-/Score-/Zeitvorgaben); Browser-Sichtpruefung bleibt wegen der lokalen URL-Sicherheitsrichtlinie offen. Produktive Report-Erzeugung und Produktversion unveraendert.

2026-09-29 - Phase 7 / Management-Report-Machbarkeitsansicht: reports/management-dummy-live-moeglich-2026-09-29.html zeigt im Look des zuletzt erarbeiteten Entwurfs ausschliesslich bereits vorhandene Report-Projektionsdaten aus dem zuvor erzeugten produktiven Dummy-Export (Projekt/Domaene, ein erfasster DC, 998 bewertete und 579 abweichende technische Ergebnisse, Reviewstatus nur soweit vorhanden). Es gibt keinen Mixed-Method-Score und keine manuell erfundenen Risikoszenarien, Business-Auswirkungen, Restaurierungsannahmen oder aktuellen Zustandsbehauptungen. Fehlende Business-/OT-Abhaengigkeiten und fehlende Szenarioregeln sind als Aussagegrenze sichtbar. Dies ist ein separater statischer HTML-Darstellungsentwurf, keine neue produktive Generatorfunktion und kein frischer Datenbankabzug. Statische Pruefung: lokale Assets und HTML-Struktur gueltig, Werte mit dem bestehenden Dummy-Export abgeglichen, keine Toolnamen oder Skripte. Produktive Report-Erzeugung und Produktversion bleiben unveraendert; visuelle und fachliche Abnahme offen.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf, Cloud-Pruefstatus aus Managementseite entfernt: Die Balkengrafik zur Auswertbarkeit importierter Cloud-Pruefungen lieferte keine eigenstaendige betriebliche Aussage und wurde aus Seite 1 der separaten Revision entfernt. Die unvollstaendige Pruefbasis bleibt einmal als Aussagegrenze direkt beim Cloud-Risiko auf Seite 2 genannt. Der Bericht behauptet aus der Testanzahl weder Schutzgrad noch Fortschritt. Produktive Report-Erzeugung und Produktversion unveraendert; visuelle Abnahme weiterhin offen.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf, Zeitbezug und Pruefstatus korrigiert: Die fruehere Grafik rechnete das zuletzt gemeldete Backupdatum vom 27.05.2026 bis zum Berichtsdatum fort und suggerierte damit ohne Nachweis eine 125 Tage andauernde fehlende Sicherung. Die korrigierte, separat gespeicherte Fassung reports/management-dummy-2026-09-29-revision.html zeigt nur die Ist-Angaben der Erhebung (ein erfasster DC, zuletzt gemeldetes Backupdatum). Die zweite Grafik heisst nun Auswertbarkeit der Cloud-Pruefungen und trennt 147 bewertete, 169 nicht ausgefuehrte und zwei weitere unbewertete Ergebnisse; sie ist keine Schutz- oder Umgebungsabdeckungsquote. Der zuvor gelieferte Berichtspfad wurde zwischenzeitlich anderweitig geaendert und deshalb nicht ueberschrieben. Keine Aenderung an produktiver Report-Erzeugung oder Produktversion; fachliche und visuelle Abnahme bleiben offen.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf 0.3, Nutzerkorrektur: Der Bericht ist ein ASSESSOR-Bericht, der die Scanner nur als Datenquellen nutzt, und eine Information fuer das Management, keine Anleitung. `reports/management-dummy-2026-09-29.html` nennt daher keine Werkzeuge und keine Scanner-Finding-Titel, enthaelt keine Etappen, Zeithorizonte, Owner oder Empfehlungslisten und verzichtet auf Kommentar- und Rechtfertigungssaetze. Aufbau: Kopfdaten, Zusammenfassung mit Kennzahlen, Gesamtbewertung mit drei statischen SVG-Grafiken (Ergebnis der 998 auswertbaren Pruefungen, Pass Rate und Abweichungen je Security Domain), sieben thematische Feststellungen mit Sachverhalt und Einordnung, Bewertungsgrundlage mit der verbindlichen GPO-/Mixed-Method-Formulierung. Die Optik der Fassung 0.2 ist nach Nutzerangabe die visuelle Zielvorgabe und wurde beibehalten. Zahlen stammen aus dem produktiven Dummy-Management-Export vom selben Tag. Browserpruefung: 3 Grafiken, 7 Feststellungen, kein horizontaler Ueberlauf, keine externen Ressourcen. Produktive Report-Erzeugung, `docs/REPORT_STRATEGY.md` und Produktversion unveraendert; fachliche Abnahme offen. Ersetzt die Fassungen darunter.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf, fachliche Nutzerkorrektur: Der separate Dummy-HTML-Bericht ist jetzt eine zweiseitige, sachliche Managementeinordnung statt einer Scannerliste mit Massnahmen-Roadmap. Toolnamen, Einzel-Finding-IDs, angenommene Owner, Aufwaende und fixe Fristen wurden aus dem Bericht entfernt. Die zwei Grafiken zeigen nur belegte Groessen: 125 Tage seit der zuletzt erfassten AD-Sicherung (27.05. bis 29.09.2026) und die Cloud-Pruefabdeckung mit 147 bewerteten von 318 Pruefungen; 169 von 318 wurden nicht ausgefuehrt. Risiken werden als moegliche betriebliche Folgen beschrieben; Kompromittierung, Restore-Faehigkeit sowie konkrete Dienste-/OT-Abhaengigkeiten bleiben ausdruecklich offen. Statische Pruefung: zwei Seiten, zwei Grafiken, lokale Assets vorhanden, Zahlen und Links konsistent. Eine visuelle Browserpruefung durch den Agenten war wegen der Browser-URL-Sicherheitsrichtlinie fuer lokale Dateien nicht moeglich. Die produktive Report-Erzeugung und Produktversion bleiben unveraendert; fachliche und visuelle Abnahme sind offen. Diese Korrektur ersetzt die Inhaltseinteilung des frueheren separaten Entwurfs vom selben Tag, nicht die produktive Reportstrategie.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf, Lesbarkeitskorrektur: Nach dem ersten Oeffnen zeigte der Quelltext lange Base64-Zeilen fuer Schrift und Logo. Beide Assets liegen jetzt als lokale Dateien unter `reports/assets/`, waehrend die HTML-Datei relative Pfade verwendet. Der Bericht bleibt ohne Netzwerkressourcen und kann als Paket aus HTML und Assets bearbeitet und weitergegeben werden. Keine Aenderung an der produktiven Report-Erzeugung oder Produktversion; fachliche Abnahme bleibt offen.

2026-09-29 - Phase 7 / Management-Report-Arbeitsentwurf fuer Dummy (eigenstaendige HTML-Datei, fachliche und visuelle Abnahme offen): `reports/management-dummy-2026-09-29.html` wurde als selbsttragende, statische Entscheidungsvorlage aus der gespeicherten Report-Projektion des freigegebenen Dummy-Projekts erstellt. Entscheidung fuer diesen Entwurf: Seite 1 nennt die ungeklärten AdminSDHolder-/Admin-Aktivitaets-Findings und drei begruendete Risikoszenarien ohne Mischscore; Seite 2 traegt Evidenz-IDs, angenommene Owner/Fristen/Aufwaende, Kontrollen und Restrisiken; der Anhang trennt Scanner-Findings und GPO-Zaehleinheiten. Die produktive Management-Overview-Erzeugung und `docs/REPORT_STRATEGY.md` bleiben unveraendert; dieser Entwurf ist keine Freigabe eines neuen Exportvertrags. Verifiziert: 8 HTML-Abschnitte, alle internen Evidenzlinks aufloesbar, keine externen Ressourcen und keine Registry-Pfade im sichtbaren Text; Browser-Vorschau geprueft. Risiken/offene Abnahme: Kritische Business Services und OT-Abhaengigkeiten, Change-Erklaerung, Gegenkontrollen, formelle Risikoakzeptanz und Beschlussdaten sind im Import nicht belegt; das Backupdatum ist 27.05.2026 (am Entwurfsdatum 125 Tage alt), waehrend die 55 Tage nur der alte PingCastle-Scantext sind. Kein Produktversionsschritt, weil nur ein separat bearbeitbarer Berichtsentwurf ohne Aenderung des Anwendungs-Vertrags entstanden ist.

2026-09-29 - Client-Info-Umgebungskacheln (Phase 7, Darstellung umgesetzt; visuelle Abnahme offen): Die sechs vorhandenen Kacheln bleiben bei Vollbildbreite in einer Rasterzeile, haben gleiche quadratische Geometrie und laufen bei schmaleren Fenstern innerhalb des Rasters horizontal statt nach unten umzubrechen. Jede Kurzansicht zeigt hoechstens vier quellengestuetzte Fakten, in schmalen Quadraten zwei; alle weiteren Werte und Quelltabellen bleiben ueber den jeweiligen Results-Button zugaenglich. Die Betriebs- und Scandaten wurden nicht veraendert. Acht fokussierte Tests einschliesslich synthetischem Results-Klickpfad, die Designpruefung, der Produktversionsvertrag und beide Produktionsbuilds bestanden. Risiko/Abnahmegrenze: Der lokale Browser zeigte sechs gleich grosse Quadrate in einer Zeile; bei 260px Breite verdeckten lange Fakten vor der Nachkorrektur teilweise die zweite Faktenzeile. Die daraufhin ergaenzte Containerregel ist gebaut und getestet, aber ein erneuter sichtbarer Dark-/Light-Vergleich bei normalem Vollbildzoom ist wegen stockender Client-Navigation noch ausstehend. Die bestehende Version 2.9.0 wird wegen dieser offenen UI-Abnahme und weiterer paralleler, noch nicht gemeinsam freigegebener Arbeitsstaende nicht fuer diese einzelne Aenderung erhoeht. Der Phasenstatus bleibt unveraendert.

2026-09-28 - Phase 13 / Result DB ohne Umgebungs-Fingerabdruecke (2.9.0, umgesetzt und verifiziert): Eine Threat-Model-Pruefung des JSONL-Exports zeigte zwei Probleme. Erstens ein Vertragsverstoss: Die Offenlegungsprojektion kopierte alle Felder, sodass `reviewStatus`, `reviewDisposition` (inklusive akzeptierter Risiken) und `reviewPriority` in Result DB API und JSONL gelangten. Zweitens erlaubten exakte Anzahlen, Zeitangaben, GPO-Istwerte mit Principals, Umgebungsbeobachtungen (DC-Anzahl, Funktionsebenen, Scores) und konkrete Baseline-Releases, die Umgebung wiederzuerkennen und den Angriffsaufwand zu kalibrieren. Neue verbindliche Nutzeranforderung: Die Result DB muss datenschutzkonform sein und darf keine Angriffsanleitung bieten; Exporte koennen an lokale und externe LLMs sowie Dritte gehen. Diese Anforderung ersetzt ausdruecklich die Entscheidung vom 2026-09-25, Istwert, Scannerwerte und Baseline-Release vollstaendig offenzulegen (AGENTS.md aktualisiert). Umsetzung: Disclosure Policy 3.0.0 mit kompilergepruefter Feldklassifikation `RESULT_DB_FIELD_DISCLOSURE`; Review-Spalte und Review-Facetten aus der Result DB entfernt; GPO nur noch mit Setting-ID, Sollwert, Relation und Baseline-Familie, zusammengefassten identischen Baseline-Erwartungen und ohne Quellenanzahl; Anzahlen, Datum, Zeit und Dauer in Scannerprosa ausser CIS-CAT als `[count]`/`[date]`/`[time]`/`[duration]` bei erhaltenen oeffentlichen Kennungen; Zusatzbeobachtungs-Policy 2.0.0 nur mit binaeren Konfigurationszustaenden; JSONL-Schema 3.0.0 mit `generatedOn` (nur Datum), datiertem Dateinamen und Kennzeichnung `confidential-security-posture`. Work und interne Analyse behalten alle Originale; keine Import-, Schema-, Persistenz- oder Bestandsmutation und kein Reimport. Risiko/Grenze: Oeffentliche Zahlenschwellen in Nicht-CIS-Empfehlungstexten (etwa Passwortlaengen) werden ebenfalls zu `[count]`, weil statischer und umgebungsbezogener Scannertext ohne Katalogbeleg nicht sicher unterscheidbar ist; das LLM verliert zudem Istwert und Mengen. Die inhaltsfreie Live-Pruefung gegen den laufenden Backend-Stand 2.9.0 mit der kanonischen PostgreSQL (nur Zaehler und Wahrheitswerte, keine Inhalte) fand drei weitere Punkte, die behoben sind: GPO-Titel aus Registry-Pfaden (`Software\Policies`) wurden seit Policy 2.5.0 faelschlich als `DOMAIN\Konto` in Principal-Platzhalter verwandelt (10.367 Zeilen; Titel behalten jetzt wie die Regel-ID ihre technische Identitaet), dokumentierte Microsoft-Principals im Sollwert nutzen jetzt die zentrale Liste `src/shared/windows-codes.ts` samt `NT SERVICE`/`NT VIRTUAL MACHINE`/`Window Manager`/`Font Driver Host`, und kompakte Dauerangaben (`24h`, `30d`) werden ersetzt. Live-Ergebnis: 14.726 Result-DB-Zeilen ohne Review-, Istwert-, Quellenanzahl- oder Identitaetsfelder, keine freistehende Ziffer in Nicht-CIS-Scannerprosa, alle GPO-Baselines nur als Familie, keine Istwerte in Varianten, Umgebungszeilen nur boolesch, keine Review-Facette; der Einzelabruf per ID ueber das PostgreSQL-Repository (28 Zeilen, darunter 8 mit internem Reviewstatus) gibt keine zurueckgehaltenen Felder aus; die Oberflaeche zeigt 9 Spalten ohne Review-Spalte und -Filter und im GPO-Detail nur Sollwert, Relation und Baseline-Familie. Grenze: 6 Sollwerte enthalten je einen nicht gelisteten Principal (SID-Muster `S-1-5-99-*`), der fail-closed als Platzhalter bleibt. Der PostgreSQL-Integrationstest wurde nicht ausgefuehrt, weil er Migrationen und Loeschungen ausfuehrt und laut `docs/POSTGRESQL.md` nie auf die produktive Datenbank zeigen darf, waehrend AGENTS.md eine zweite ASSESSOR-Datenbank verbietet. Tests: synthetische Fingerabdruck- und Ziffernwaechter-Tests fuer Projektion und JSONL, Baseline-Familie, Zusammenfassung der Varianten, Zusatzbeobachtungen, lokales Repository, angepasste PostgreSQL-Integrationserwartung (nicht gegen die kanonische Datenbank ausgefuehrt) und die Nutzerinteraktion `Export JSONL` in der Result DB. Fokussierte Tests, Typpruefung, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild bestanden; die volle Suite zeigt nur die 7 bereits auf dem unveraenderten Stand d8f131d fehlschlagenden Tests in Client-Info-/GPO-/Timeslot-Dateien. Nachtrag 2026-09-28 (Disclosure Policy 3.1.0, gleicher unveroeffentlichter Stand 2.9.0): Die Nutzerpruefung des Dummy-Exports (Policy 3.0.0; Dummy ausdruecklich zur Inhaltspruefung freigegeben) bestaetigte die Schliessung der Lecks und fand Ueberschwaerzung. Behoben: `[count].` statt Schrittnummern, Hersteller-Schwellenwerte im Empfehlungsfeld (Titel und Beschreibung bleiben voll geschwaerzt), CIS-Nummern und `Rule`-Verweise als `[ip]` (IPv4 nur noch alleinstehend, nie Teil laengerer Punktfolgen oder dokumentierter Bereichsgrenzen) sowie oeffentliche Richtlinien-/Registry-Pfade, umgebrochene Pfadzeilen und dokumentierte Windows-Autoritaeten als `[account]` (Dummy vorher 1.443 laut Nutzerauswertung, jetzt 1); der Handling-Hinweis nennt die erhaltenen oeffentlichen Baseline-Erwartungen. Live ueber alle Clients (nur Zaehler): 0 `[ip]`, 1 `[account]` (Named Pipe `SQL\QUERY`, bewusst fail-closed), 0 zerstoerte Listenmarker, keine freistehende Ziffer in Nicht-CIS-Titeln/-Beschreibungen. Offen: oeffentliche Domains, URLs und Graph-Berechtigungsnamen (`Directory.ReadWrite.All`) werden weiterhin zu `[domain]`/`[url]`; die Versionsfelder bleiben als Verfahrens- und Kompatibilitaetsangabe erhalten. Nachtrag 2 (Disclosure Policy 3.2.0, weiterhin unveroeffentlichter Stand 2.9.0): Die zweite Nutzerpruefung bestaetigte, dass meine vorherigen Dummy-Zaehler ungefiltert waren (4.760 statt 579 Abweichungszeilen) und die Listenmarker-Korrektur nur Zeilenanfaenge erfasste. Behoben im Exportumfang `deviation:true`: `[count].` in Inline-Aufzaehlungen 172 -> 1 (verbleibend eine einzelne Nummer ohne Folge), `[url]` 263 -> 2 (Platzhalter-Host `IP`), `[domain]` 58 -> 1 (Drittanbieter-Domain in einem Codebeispiel), `[account]` 0; ausserdem Zielwerte `set to N` in Empfehlungen, `adminCount=1`, Abschnittsnummern `CISA N.`, `Microsoft 365` und die Leerzeichen-Bereinigung vor `.onmicrosoft.com`. Die inhaltsfreie Pruefung ueber alle Clients fand 15 verbliebene `onmicrosoft.com`-Nennungen, alle generischer Maester-Text MT.1074 (`the .onmicrosoft.com domain`), kein Tenant-Name; 0 E-Mail-Adressen, 0 `[ip]`, keine Review- oder Istwertfelder. Nachtrag 3: Eine selbst eingefuehrte Luecke ist behoben: Links wurden erst nach dem Einsetzen von `[id]` bewertet, sodass ein Portal-Link an `[id]` abbrach und der Rest (etwa `/resourceGroups/<Name>`) im Klartext blieb. Links werden jetzt zuerst und als Ganzes bewertet; GUIDs, Platzhalter und Azure-Ressourcenpfade machen einen Link nicht oeffentlich. Synthetischer Regressionstest vorhanden. Nachtrag 4 (Phase 11/13, Migration 024 nach verifiziertem Backup `before-result-db-materialization-20260928.dump`, 388 TOC-Eintraege, SHA-256 im Manifest): Auf verbindliche Nutzeranforderung wird die Result DB beim Erzeugen geprueft und gespeichert (WYSIWYG fuer UI, API, Einzelabruf und JSONL) und traegt pro Zeile ein inhaltsfreies Protokoll; die Ansicht zeigt den Pruefstand und `Open original in Work`. Ein Identitaetswaechter pro Client (1.3.0) entfernt die eigenen Namen des Clients; drei Fehlalarmquellen (Asset-Kategorien, `*.name`-Umgebungsfelder, Registry-Pfade aus GPO-Werten) wurden an Dummy und ueber inhaltsfreie Zaehler gefunden und behoben. Live: 14.726 Zeilen, 0 Zeilen mit gesperrten Feldern, Aufbau rund 11 s nach Start. Ebenfalls auf Nutzerentscheidung: Maester zeigt die Ergebnisaussage (`ResultDetail` bzw. `Result` neben `Status`) wieder wortgetreu als `Problem`, live an Dummy bestaetigt. Der PostgreSQL-Integrationstest wurde nicht ausgefuehrt (keine erlaubte Testdatenbank). Die volle Suite zeigt nur die 7 bereits auf d8f131d fehlschlagenden Tests. Nachtrag 5 (2026-09-29, Disclosure Policy 3.3.1, weiterhin unveroeffentlichter Stand 2.9.0): Eine externe Bewertung des Dummy-Exports (Policy 3.2.0) fand drei Punkte, die am Code bestaetigt und behoben sind. Erstens verriet die Protokollliste `withheldFields`, bei welchen Zeilen der Client Reviewstatus, -prioritaet, -verantwortliche oder Faelligkeit gepflegt hatte; die Review-Felder werden jetzt zurueckgehalten, ohne im Protokoll zu erscheinen. Zweitens wurde `score` je Finding offengelegt; Purple-Knight-Indikatorscores und berechnete PingCastle-Punkte skalieren mit den betroffenen Objekten und werden jetzt zurueckgehalten. Drittens Ueberschwaerzung: `Limited` gilt nicht mehr als Rechtsform (Rechtsformen nur noch in registrierter Schreibweise), Versionen direkt am Namen (`Tls1.2`, `v1.0`), `Windows 95`, `2012-R2` sowie Verweise `step N`, `Option N` und `Page N` bleiben, dokumentierte Microsoft-GUIDs aus dem oeffentlichen Katalog (ASR-Regeln, erstanbieterseitige Anwendungs-IDs, eingebaute Rollenvorlagen, gegen Microsoft Learn geprueft) bleiben, jede andere GUID bleibt `[id]`. Die gemeldete ID-Kollision `18.10.42.11.1.1` war kein Parserfehler: Import und Original tragen `18.10.42.11.1.1.1` und `.2`, aber die Offenlegung liess nur sechs Ebenen durch; CIS-Nummern behalten jetzt bis zu acht Ebenen. Bewusst unveraendert, weil verbindlich: Zahlen in Titeln und Beschreibungen bleiben geschwaerzt (etwa CISA-Verhaeltnis, MachineAccountQuota-Standard), der Trace bleibt Teil jeder Zeile und des JSONL, GPO-Vergleiche werden weiter einzeln gezaehlt. Live nach automatischem Neuaufbau (Dummy freigegeben): 579 Dummy-Abweichungszeilen mit 0 `[organization]`, 0 `[id]`, 0 doppelten CIS-IDs; ueber alle Clients 14.726 Zeilen, 0 mit `score`, 0 mit Review-Feldnamen. Synthetische Regressionstests fuer Projektion, Protokoll und die Nutzerinteraktion Zeilendetail/`Export JSONL` mit gespeicherten Zeilen; keine Schema-, Import- oder Originaldatenaenderung, kein Reimport. Nachtrag 6 (2026-09-29, Disclosure Policy 3.4.0, gleicher Stand 2.9.0): Auf Nutzerentscheidung behaelt das Empfehlungsfeld zusaetzlich dokumentierte Herstellerwerte (`set <Objekt> to N` innerhalb eines Satzes ohne weitere Zahl, `value is N`, `the number N`, `assign N`, `N as the Value`, `N for <Name> mode`, Attributfilter wie `admincount=1`, `zero (0)`, `N+`, `N methods` und `only N will be listed`); Titel und Beschreibungen bleiben voll geschwaerzt, beobachtete Anzahlen im Empfehlungsfeld bleiben `[count]`. Dummy: `[count]` im Empfehlungsfeld 15 -> 0 (18 vor der `Option N`-Korrektur) (Titel 17, Beschreibung 9 unveraendert). Inhaltsfreie Pruefung ueber alle Clients: 16 Regeln mit neu erhaltenen Werten, jede mit genau einem Wertesatz ueber alle Clients, in denen sie vorkommt; 5 Regeln kommen nur bei einem Nicht-Dummy-Client vor, alle mit oeffentlicher Regel-ID und Anweisungsform (`set ... to N`, Attributfilter), nicht inhaltlich geprueft. Die volle Suite zeigt neben den 7 bekannten Fehlschlaegen 3 weitere in `client-info-facts.test.tsx`, die aus parallelen, nicht von dieser Aenderung stammenden Client-Info-Anpassungen (`DashboardPanel.tsx`, `OperatingSystemInventory.tsx`, `ui-tokens.css`) folgen.

2026-09-26 - Phase 7 / Doppelte Client-Info-Fakten entfernt (2.8.7, umgesetzt und verifiziert): Der zuvor erprobte Work-artige Dashboardumbau wurde auf ausdruecklichen Nutzerwunsch vollstaendig zurueckgenommen. Die anschliessend beauftragte kleine Bereinigung behaelt alle bestehenden Kacheln, Positionen, Donuts, Domainverbindungen, CSS-Regeln und Results-Popups. Domain, Forest, beide Functional Levels und DC OS stehen in Domain Information; NetBIOS, Schema, Erstellungsdatum und Entra-Identitaet in Directory; Bestandszahlen bleiben in Data. Directory und Inventory zeigen identische Uebersichtsfakten nicht nochmals; ihre Results behalten saemtliche Kategorienwerte und Originaltabellen. Verglichen werden nur dieselben benannten Fakten mit gleichem Anzeigewert, nie unterschiedliche Fakten allein wegen gleicher Werte. Abweichende oder nicht numerische Angaben bleiben erhalten; unbekannte Werte bleiben unbekannt. Entscheidung: Patchversion 2.8.7 fuer die rueckwaertskompatible Darstellungsbereinigung, keine Daten-, Import-, Scoring-, API- oder Persistenzaenderung. Verifikation: 52 fokussierte Tests einschliesslich befuellter/leerer Datenlage, nicht numerischer DC-Angabe, tatsaechlicher Directory-/Inventory-Results-Klickwege, Posture-Verbindungen und UI-/API-Versionsvertrag; beide Produktionsbuilds, Design-/Local-only- und Diffpruefung bestanden. Synthetische Light-/Dark-Browserpruefung bestaetigt 14px/16px Rollen, 20px Inset und vollstaendige Results. Die gebaute CSS-Datei ist unveraendert. Grenze: unterschiedliche Darstellungen desselben Quellwertes werden vorsichtshalber nicht als identisch unterdrueckt. Phasenstatus unveraendert.

2026-09-26 - Phase 6/7 / Scanner-Einstieg im Report, CIS-Abschnitte und Work-Zusammenfuehrung (2.8.6, umgesetzt und verifiziert): Purple-Knight-Scanlaeufe mit Umfangsnamen (`for Active Directory`, `for Entra ID`, kombiniert) loesen ueber deklarierte Profil-`runNames` wieder auf das Purple-Knight-Profil auf; zuvor fielen sie in gemischtem Work auf generic zurueck (kein Problem/Next step, generische Status-, Facetten-, Result-Linker- und Graphlogik). Maester ohne Remediation-/HelpUrl-Feld zeigt den nativen Description-Abschnitt `#### Remediation action:` deklarativ (`firstRead.nextStepSection`) als Next step; der Text davor bleibt Hintergrund, jeder Text erscheint einmal. Eingefuehrte PowerShell-Befehle werden auch nach `script ...:` und bei Beginn mit Variablenzuweisung als Befehlsblock abgesetzt; exportbedingt flachgeklopfte Befehle erhalten nur in der Anzeige Zeilen an eindeutigen Grenzen (Anweisung nach schliessender Klammer, Pipeline), ausschliesslich Leerraum aendert sich. Purple-Knight-`Likelihood of compromise` endet vor dem angehaengten nativen `References`-Abschnitt (`firstRead.impactReferenceMarker`); die Referenztitel erscheinen an der Referenzposition, verlorene Absatzumbrueche werden angezeigt. CIS-Abschnittsnamen stammen ausschliesslich aus der gespeicherten Section-Score-Tabelle des eigenen Scanlaufs: `CIS Category` zeigt Nummer und Namen in numerischer Ordnung; Work-Ueberschriften ersetzen nach Nutzerkorrektur die fuehrende Regelnummer durch den Titel des umgebenden Abschnitts, die Nummer bleibt Source Rule ID, Plaketten zeigen Nummer plus Tooltip; widerspruechliche oder fehlende Titel lassen die Nummer stehen. Ursache fuer im Dummy nicht sichtbare Titel und Referenzen: Die Zusammenfuehrung von All Records mit GPO-Ergebnissen kopierte eine manuelle Feldliste. `withRebuiltLayout` uebernimmt jetzt alle Datensatzmetadaten und ersetzt nur Layoutfelder (id, index, title, fields, filled, meta, sourceFile, sourceSheet, highlighted); ein Schutztest mit synthetischem unbekanntem Zusatzfeld sichert kuenftige Metadaten. Dummy ueber den realen Work-Ladeweg (nur Zaehlungen): 411/411 CIS-Datensaetze mit Titeln und Referenzen, 160/160 benannte CIS-Kategorien, 92/92 getrennte Purple-Knight-Referenzabschnitte. Entscheidung: Patchversion 2.8.6 fuer rueckwaertskompatible Korrekturen und Verfeinerungen ueber gespeicherte Fakten; kein Reimport, keine Schema-, Import-, Scoring- oder Review-Aenderung. Verifikation: synthetische Regressionen fuer die tatsaechlichen Pfade (gemischtes Work mit und ohne GPO, Reader, Facetten, Kacheln, Zusammenfuehrung), Versionsvertragstests, beide Produktionsbuilds; Gesamtsuite 1.608 bestanden, 14 uebersprungen, dieselben sechs vorbestehenden fachfremden Fehler in GPO-/Security-Domain-/Result-DB-/Dashboard-Tests. Risiken/Grenzen: Security-Domain-Zuordnung bleibt stichwortbasiert (gesonderte Entscheidung offen); Pathfinder und Graphansichten zeigen CIS-Titel weiterhin mit Nummer; Purple-Knight-Referenztitel ohne Trennzeichen bleiben ein Textblock. Phasenstatus unveraendert.

2026-09-26 - Phase 7 / Finding-Reader-Abstaende (2.8.4, umgesetzt und verifiziert): Die gemeinsame Abschnittsregel umfasst jetzt div und section, damit GPO-Quellen und Baseline-Vergleich denselben Tokenabstand verwenden: space-4 (16 px) vor/nach der Trennlinie, space-2 (8 px) zwischen Feldueberschrift und Text. Redundante Abschlusslinien am letzten Quellblock und letzten Reader-Feld entfernt; Problem-/Next-step-Sonderabstaende bleiben erhalten. Synthetischer permanenter Klicktest prueft den gerenderten GPO-Reader vor, nach und nach erneutem Schliessen des Baseline-Disclosures. 44 gezielte Reader-/UI-/API-Versionsvertragstests, beide Produktionsbuilds, Design-/Local-only- und Diffpruefung bestanden. Synthetische Light-/Dark-Sichtpruefung bestaetigt jeweils rund 16 px Abschnittsabstand. Patchversion fuer die gemeinsame Darstellungskorrektur; keine Daten-, Import-, Bewertungs- oder Persistenzaenderung. Risiko: Die gemeinsame Regel wirkt auch auf weitere native Reader-Abschnitte; fokussierte Reader-Regressionen decken die bestehenden Faelle ab. Phasenstatus unveraendert.

MITRE-Onlineaktualisierung und Originaldownload 2026-09-26 (Phase 7, Nutzererweiterung, umgesetzt und verifiziert): Data Hub bietet `Update from MITRE`, `Download from MITRE` und den weiterhin vorhandenen manuellen `Import JSON file` als Fallback. Update holt das aktuelle offizielle Enterprise-STIX-Bundle serverseitig, prueft Format und Versionsnummer und aktiviert nur eine neuere Version als gemeinsam gespeicherten kompakten Katalog. Die Datei liegt atomar im privaten Artefaktverzeichnis; kein PostgreSQL-Schema und keine Assessment-Daten werden geaendert. Download liefert die unveraenderte originale MITRE-Datei mit Versionsnamen und aktiviert sie nicht. Der App-Start laedt den gemeinsamen Katalog auch bei direktem Pathfinder-Einstieg; ein aktiver Graph aktualisiert sich im aktuellen Browser sofort. Ein lokaler manueller Override bleibt bewusst browserlokal und wird durch einen erfolgreichen Update-Klick im selben Browser entfernt; andere Browser behalten ihren eigenen Override. Entscheidung: rueckwaertskompatible neue Faehigkeit, daher Minorversion 2.7.0. Risiken/Grenzen: Onlineaktionen benoetigen Erreichbarkeit des offiziellen MITRE-GitHub-Repositories; die bereits gebuendelte v19.2 und der manuelle Import bleiben offline verfuegbar. Ein fremder Browser mit lokalem Override sieht die gemeinsame neue Version erst nach dessen Entfernung. Synthetische Service-/HTTP-/UI-Regressionen, 16 fokussierte MITRE-/Versions-/Data-Hub-Tests, Local-only- und Designpruefung sowie beide Produktionsbuilds bestanden. Ein Live-Updateabruf bestaetigte v19.2 als aktuellen Stand (`updated=false`); der Live-Download antwortete mit HTTP 200, Originaldateiname `enterprise-attack-v19.2.json` und 53.835.637 Bytes. App/Backend laufen mit 2.7.0 und dem kanonischen PostgreSQL; Health `ok`, Repository-Revision 496. Die Gesamtsuite meldete vor Korrektur eines neuen Test-API-Mocks 1.550 bestandene, 13 uebersprungene und sieben fehlgeschlagene Tests; der Mock-Test wurde anschliessend fokussiert erfolgreich erneut geprueft. Sechs vorbestehende fachfremde Fehler in GPO-/Security-Domain-/Result-DB-/Dashboard-Tests bleiben. Der dokumentierte Phasenstatus bleibt unveraendert.

MITRE-ATT&CK-Katalog 2026-09-26 (Phase 7, umgesetzt und verifiziert): Der versionierte Standardkatalog wurde aus MITREs offiziellem Enterprise-STIX-2.1-Bundle v19.2 reproduzierbar erzeugt (15 Taktiken, 697 aktive Techniken, 1.057 aktive Entitaeten). Der Data-Hub-Upload ist wieder sichtbar und akzeptiert offizielles Enterprise-STIX sowie das bisherige kompakte ASSESSOR-JSON; Reset und aktive Versionsanzeige bleiben erhalten. Der geoeffnete Pathfinder uebernimmt Upload und Reset ohne Remount. Die bisherige v18.1-Datei wurde als nicht mehr genutzter Standard entfernt. Entscheidung: rueckwaertskompatible Patchversion 2.6.47, keine Scanner-, API-, Schema-, Datenbank- oder Bestandsdatenmutation. Risiken/Grenzen: Individuelle Matrizen bleiben browserlokale Overrides; ein vorhandener Custom-Stand kann daher weiter aelter als der neue Standard sein, wird aber als `Custom` kenntlich. Im schmalen Codex-Browser war die Karte per Accessibility sichtbar; ein vollbreiter visueller Dark-/Light-Vergleich wurde dort nicht abgenommen. 21 fokussierte MITRE- und UI-/API-Versionsvertragstests, Data-Hub-Layouttest, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden; laufendes Backend meldet 2.6.47, `ok` und `postgresql`, App HTTP 200. Gesamtsuite: 1.548 bestanden, 13 uebersprungen, sechs fachfremde bestehende Fehler in GPO-/Security-Domain-/Result-DB-/Dashboard-Tests. Der dokumentierte Status von Phase 7 (`abgeschlossen`) bleibt unveraendert; dieser Nachtrag ist separat verifiziert.

Pathfinder-Details-Wertespalte 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die Faktenzeilen im rechten Detailsbereich nutzten eine automatische Wertespalte, die zusaetzlich auf 66 Prozent ihrer eigenen Breite begrenzt war und Woerter sowie Zahlen mit `overflow-wrap: anywhere` in einzelne Silben beziehungsweise Ziffern zerlegte. Die Werte erhalten jetzt eine feste flexible Spalte mit mehr Platz; mehrteilige Werte brechen nur an Wortgrenzen um, lange ungetrennte technische Kennungen bleiben in ihrem eigenen Bereich horizontal lesbar. Schriftrolle, Quellwerte und semantische Statusfarben bleiben unveraendert. Ein synthetischer Finding-Klicktest prueft die tatsaechlich angewandte Spalten- und Umbruchregel; 14 fokussierte Graph- und UI-/API-Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Backend 2.6.46 am bestehenden kanonischen PostgreSQL gestartet; Health `ok`, App HTTP 200, Repository-Revision 496. Entscheidung: rueckwaertskompatible Patchversion 2.6.46 ohne Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

DB-Structure-Einfuehrung entfernt 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Der redundante `Database dictionary`-/`Relational schema`-Textblock oberhalb der Kennzahlen und der erklaerende Satz unter `Data flow` sind entfernt. Schema-Status, `Refresh schema`, Kennzahlen, Ablaufueberschrift, Tabellenbuttons, Popups und Schichtenverzeichnis bleiben erreichbar. Unbenutzte CSS-Regeln fuer beide Texte sind entfallen; die Aktionszeile bleibt am rechten Rand. Der synthetische Klicktest bestaetigt das Fehlen beider Texte bei weiter bedienbarem Refresh-Button und Ablauf; die vorhandenen Popup- und Dictionary-Klickpfade bestehen weiter. 17 fokussierte UI-/API- und Versionsvertragstests, Design-/Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Backend 2.6.45 am bestehenden kanonischen PostgreSQL gestartet; Health `ok`, App HTTP 200, Repository-Revision 496. Entscheidung: rueckwaertskompatible Patchversion 2.6.45 ohne Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

DB-Structure-Tabellenpopup 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Ein Klick auf einen Tabellenbutton im Datenfluss oeffnet Spalten, Constraints und Beziehungen wieder im gemeinsamen verschiebbaren Tabellenpopup statt in einem Inline-Abschnitt unter dem Ablaufplan. Referenzierende Tabellen bleiben als Buttons im selben Fenster erreichbar; Schliessen und Escape beenden das Popup und lassen den Ablaufplan unveraendert. Das supersediert nur die Detailplatzierung der juengsten DB-Structure-Ablaufplanentscheidung; das getrennte Schichtenverzeichnis behaelt seine Offenlegung. Ein synthetischer Klicktest prueft Button, Popup-Inhalt, Tabellenwechsel im Popup und Escape; insgesamt 16 fokussierte UI-/API- und Versionsvertragstests, Design-/Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Backend 2.6.44 am vorhandenen kanonischen PostgreSQL gestartet; Health `ok`, App HTTP 200, Repository-Revision 496. Entscheidung: rueckwaertskompatible Patchversion 2.6.44 ohne Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Pathfinder-Extract-Path 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): `Extract` heisst nun `Extract Path`. Die Aktion benoetigt einen tatsaechlich ausgewaehlten Graphknoten und zeigt nur diesen Knoten, seine direkten Nachbarn und die direkt von ihm ausgehenden Kanten. Eine blosse Filterauswahl oder `Mark all` extrahiert keinen ganzen Graphen und erweitert den Pfad nicht ueber Nachbarn hinaus. `Exit Extract Path` stellt die vorherige Auswahl, Markierung und Kamera wieder her; die getrennte Zweigsemantik von `Mark all` bleibt bestehen. Dies supersediert die bisherige breite Zweigextraktion, ohne deren historische Entscheidung umzuschreiben. Ein synthetischer aktiver Klicktest prueft deaktivierte Extraktion ohne Knotenauswahl, Kategorie- und Finding-Pfad sowie Rueckkehr zum vollstaendigen Graphen; der reine Graphhelfer prueft die Grenze an gemeinsam genutzten Beziehungen. 22 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Backend 2.6.43 am bestehenden kanonischen PostgreSQL gestartet; Health `ok`, App HTTP 200, Repository-Revision 496. Entscheidung: rueckwaertskompatible Patchversion 2.6.43 ohne Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Pathfinder-Finding-Details 2026-09-25 (Phase 7, Nutzererweiterung, umgesetzt und verifiziert): Der rechte `Details`-Bereich zeigt fuer Finding-Knoten nun dasselbe Severity-Sechseck wie die Work-Kachel neben dem vollstaendigen Titel. Zusaetzliche, nur bei vorhandener Quelle sichtbare Fakten sind nativer Source status, Werkzeugname, exakte `Source Rule ID`, Kategorie und MITRE-ATT&CK-Kennungen; der bisherige abgeleitete Risikowert ist als `Graph risk` kenntlich. Relation-Knoten erhalten weder Finding-Sechseck noch Finding-Fakten. Die vollstaendigen Inhalte bleiben ueber `Open in Work` und `Results` erreichbar. Der synthetische aktive Pathfinder-Klicktest prueft High-Sechseck, Quellstatus, Regel-ID, Kategorie, Technik und den Relation-Gegenfall; 18 fokussierte Graph-/Filter- und UI-/API-Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Backend 2.6.42 am bestehenden kanonischen PostgreSQL gestartet. Entscheidung: rueckwaertskompatible Patchversion 2.6.42 ohne beabsichtigte Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Pathfinder-Text statt Graphkarten 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die frueheren `Off`-/`Labels`-/`Text`-Modi und die Hover-/Auswahlkarten im Graphen sind durch einen einzigen `Text`-Schalter ersetzt. Knotentext startet sichtbar und bleibt beim Klick auf einen Punkt sowie beim Abwaehlen, Markieren und Extrahieren in seinem gewaehlten Zustand. `Reset view` stellt den sichtbaren Text wieder her. Knoteninformationen und Aktionen erscheinen nur im rechten `Details`-Bereich; die Graphflaeche behaelt ihre Knoten, Kanten und kompakten Knotentexte. Die Kollisionsberechnung des standardmaessig aktiven Texts beachtet nur Knoten im sichtbaren Graphausschnitt. Dies supersediert ausdruecklich die Pathfinder-Graphkarten- und Labelmodus-Entscheidungen vom 2026-08-22; deren historische Eintraege bleiben dokumentiert. Ein synthetischer aktiver Graph-Klicktest prueft Standard, Auswahl/Abwahl, Detailbereich, Text-Toggle und Reset; 18 fokussierte Graph-/Filter- und UI-/API-Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. App HTTP 200; Backend 2.6.41 am bestehenden kanonischen PostgreSQL gestartet. Entscheidung: rueckwaertskompatible Patchversion 2.6.41, keine beabsichtigte Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Finding-Reader-Befehl lesbar 2026-09-25 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Ein im ersten Remediation-Absatz ausdruecklich eingeleiteter PowerShell-Befehl lief bislang im Fliesstext weiter. Der Finding Reader zeigt den erklaerenden Satz und den vollstaendigen Befehl jetzt als getrennte, umbruchfaehige Lesebereiche. Die Originalzeichenfolge bleibt im Befehlsblock kopierbar; der gespeicherte Quellwert, seine Parameter und die bestehende Absatzgrenze zur aufklappbaren `Full remediation` bleiben unveraendert. Das verwendet die vorhandenen Theme- und Typografierollen in Light und Dark ohne neue Farbrolle. Ein synthetischer PingCastle-Reader-Test deckt genau diesen Klick-/Leseweg ab; 21 fokussierte Reader- und UI-/API-Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Backend am kanonischen PostgreSQL auf 2.6.40 neu gestartet; Health `ok`, `postgresql`, Repository-Revision 471 unveraendert. Entscheidung: rueckwaertskompatible Patchversion 2.6.40 ohne Daten-, Import-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Tabellenzeilen-Markierungsblau 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die Lesemarkierung angeklickter Datenzeilen in nativen Tabellen und der Result DB verwendet nun in beiden Themes einen eigenen blauen Farbtoken fuer Kontur und transparente Flaeche. Dies ersetzt nur die gelbe Farbe der Tabellenzeile; Kachel-/Steuerelementauswahl bleibt gelb und Tastaturfokus behaelt seinen getrennten Token. Pass-/Fail- und Evidenzfarben sowie Klickaktionen bleiben erhalten. Der synthetische Klicktest prueft beide Tabellenarten, horizontales Scrollen und die blauen Stilrollen; 16 fokussierte Tabellen-, Design- und UI-/API-Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Das Backend wurde am kanonischen PostgreSQL von 2.6.38 auf 2.6.39 neu gestartet; Health meldet `ok`, `postgresql` und die unveraenderte Repository-Revision 471. Entscheidung: rueckwaertskompatible Patchversion 2.6.39 ohne Daten-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Work-Quellenwechsel setzt Filter zurueck 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt): Beim Wechsel von `Source: Scan` in Work blieben zuvor Suche, Ergebnisstatus, andere Facetten, Record-/Pfadumfang oder `My Workspace` aktiv und konnten die neu gewaehlt Quelle leer erscheinen lassen. Die Auswahl setzt diese alten Einschraenkungen jetzt auf den bindenden Work-Standard `Deviation` samt Standardsortierung zurueck und wendet danach die neue Source-Auswahl an. Das gilt auch fuer `Source: Scan: All`; die Ansicht sowie Client und Timeslot bleiben erhalten. Eingehende Client-Info-/Pathfinder-Drilldowns behalten ihren bewusst gesetzten Kontext bis zu einem tatsaechlichen Quellenwechsel in Work. Ein synthetischer Test mit echtem AppProvider waehlt GPOs, setzt widersprechende Filter, wechselt zu Maester und zurueck auf All und prueft jeweils sichtbare Datensaetze sowie den vollstaendigen Filterzustand. 37 fokussierte Quellen-/Facettentests, UI-/API-Versionsvertrag, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.38; keine Daten-, API-, Import-, Schema- oder Persistenzaenderung. Grenze: Eine Source ohne Abweichungen hat unter dem bindenden Standardstatus `Deviation` weiterhin null Treffer; `Result Status: All` bleibt dafuer waehlbar. Phase 7 bleibt offen.

Tabellenzeilen markieren 2026-09-25 (Phase 7, ausdruecklicher Nutzerwunsch, umgesetzt): Ein Klick in eine Datenzeile setzt pro Tabelle eine sichtbare Lesemarkierung ueber die gesamte Zeilenbreite, auch beim horizontalen Scrollen. Die gemeinsame Ereignisbehandlung erreicht native Tabellen in Work, Client Info und schwebenden Results-Fenstern sowie die zeilenbasierte Result DB; Tabellenkoepfe und Virtualisierungsplatzhalter bleiben ausgenommen. Die Markierung kombiniert die bestehende gelbe Auswahlrolle mit einer transparenten Toennung ueber der vorhandenen Zellenflaeche, sodass fachliche Pass-/Fail- und Evidenzfarben erkennbar bleiben. Zeilenaktionen und Links laufen weiter; das Work-Grid merkt die ausgewaehlte Datensatz-ID beim vertikalen Virtualisieren und trennt die Auswahl beim Blattwechsel. Die Regel steht dauerhaft in AGENTS.md. 42 fokussierte synthetische UI-/API-, Tabellen- und Klicktests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.37, keine Daten-, API-, Import-, Schema- oder Persistenzaenderung. Risiko: Die frueheren acht fachfremden Fehler im Gesamttestlauf bleiben separat offen; eine Inhaltspruefung an realen Mandantendaten erfolgt gemaess Privacy-Regel nicht. Phase 7 bleibt offen.

Donut-Bogenkante 2026-09-25 (Phase 7, erneute Nutzerkorrektur, umgesetzt): Der gestrichelte SVG-Kreis hinterliess am Start des Farbbogens bei 12 Uhr eine sichtbare schraege Kante. Alle Bildschirm-Donuts in Data Hub und Client Info, einschliesslich Score- und mehrteiliger Verteilungsringe, zeichnen den Anteil nun als gefuelltes Ringsegment mit exakt radialen, flachen Enden. Die neutrale volle Spur, die semantischen Farben, Anteile, Beschriftungen und Klickziele bleiben erhalten. Die zusaetzliche Lesbarkeitsmarkierung fuer Anteile unter 2 % beginnt jetzt ebenfalls genau am Segmentanfang. Ein synthetischer Mandantenauswahltest und Geometrietests decken 0, sehr kleine, 10-, 25- und 100-Prozent-Faelle ab; 38 fokussierte UI-, Interaktions- und UI-/API-Versionspruefungen sowie Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Der isolierte Browser-Sichttest konnte wegen der Browser-URL-Richtlinie nicht ausgefuehrt werden. Der Gesamttestlauf hatte acht weitere Fehler in bereits separat veraenderten Client-Info-, GPO-, Result-DB- und Reader-Bereichen; sie betreffen nicht die hier geaenderte Ringgeometrie und bleiben als offenes Risiko bestehen. Entscheidung: rueckwaertskompatible Patchversion 2.6.36, keine Daten-, Import-, Schema- oder Persistenzaenderung. Phase 7 bleibt offen.

Client-Info-Donut ohne Innenrahmen 2026-09-25 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Der `Deviations`-Donut in der `Data`-Kachel erbte im hellen Theme den neutralen Tile-Rahmen der allgemeinen Donut-Karte und zeigte dadurch ein zweites Rechteck innerhalb der bereits gerahmten Data-Kachel. Nur dieser verschachtelte Donut verwendet jetzt die transparente gemeinsame Segment-Rahmenrolle; die aeussere Kachel und der blaue Tastaturfokus bleiben erhalten. Synthetische Sichtpruefung in Light und Dark zeigt Titel, Ring, Wert und Interaktion ohne innere Kontur. Der vorhandene Client-Info-Results-Klicktest wurde auf die seit 2.6.31 verbindliche direkte Tabellendarstellung aktualisiert. 31 fokussierte Layout-, Interaktions- und UI-/API-Versionspruefungen, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.35, ausschliesslich Darstellung und Testpflege, keine Daten- oder Persistenzaenderung. Phase 7 bleibt offen.

Client-Info ohne Import-Artefakte 2026-09-25 (Phase 7/13C, Nutzerkorrektur, umgesetzt und verifiziert): `Source text` war ein ASSESSOR-Steuerelement; `Tabelle 35` stammt aus dem generischen HTML-Ersatznamen. Die bisherige Filterung erfasste nur den Tabellennamen, waehrend Titel sowie Teilabschnitts-/Zeilenanzahl-Beobachtungen ihn erneut einblenden konnten. Alle Titelpfade der Client-Info-Results, einschliesslich nativer Popup- und Inline-Ziele, entfernen nun reine Tabellen-Ordnungsnummern und angehaengte generierte Ordinaltitel. Belegte native Ueberschriften wie `Azure AD Connect settings` bleiben erhalten; ohne nativen Tabellentitel steht die vollstaendige Tabelle unter ihrer Abschnittsueberschrift. Die Nutzerkorrektur ersetzt ausdruecklich die `Source text`-Entscheidung aus 2.6.31: Der generierte Aufklapper und zusammengezogene historische Quellprosa erscheinen nicht mehr im Client-Info-Results-Fenster. Strukturierte native Erklaertexte bleiben sichtbar, gespeicherte Originaltexte und Tabellen unveraendert. Synthetischer Directory-Results-Klicktest prueft die berichtete Konstellation, Popup, Inline-Details und Unveraendertheit der Eingaben; alle Results-Kategorien, Betriebssystemtabellen und UI-/API-Versionsvertrag mit insgesamt 39 Tests bestanden. Sichtpruefung ausschliesslich synthetisch in Light und Dark, Design-/Local-only-Pruefung sowie beide Produktionsbuilds erfolgreich. Entscheidung: Patchversion 2.6.34; reine Leseprojektion ohne Import-, Schema-, Persistenz- oder Reimportaenderung. Grenze: Ein nicht gespeicherter nativer Titel wird nicht erfunden. Phase 7/13C bleibt offen.

Kleine Donut-Anteile 2026-09-25 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Der Data Hub rundete Anteile vor dem Zeichnen auf ganze Prozent; ein positiver Anteil unter 0,5 % erschien dadurch als leerer Ring, und 1 % nur als kaum erkennbarer Splitter. Die sechs Data-Hub-Ringe und die Client-Info-Ringe zeichnen nun den ungerundeten Anteil. Positive Anteile unter 2 % erhalten zusaetzlich eine schmale, flache Markierung in derselben semantischen Bogenfarbe; Null bleibt ohne Markierung. Unter 0,5 % steht `<1%` statt `0%`. Dasselbe Verhalten gilt fuer die weiteren Bildschirm-Donuts und den Management-Report; ein Score unter 0,5 von 100 zeigt `<1/100` statt `0/100`. Ringgeometrie, Metrik und Farbrollen bleiben erhalten. Ein synthetischer Data-Hub-Test deckt Mandantenauswahl, Ladezustand und den realen Anteil 4/1833 ab; Komponenten- und Reporttests pruefen 0, 1 und Anteile unter 1 %. Synthetische Sichtpruefung bei normaler kompakter Ringgroesse in Light und Dark; 34 fokussierte Tests inklusive UI-/API-Versionsvertrag, Design- und Local-only-Pruefung sowie Client-/Server-Produktionsbuild bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.33, keine Daten-, Import-, Schema- oder Persistenzaenderung. Grenze: Die zusaetzliche Markierung ist ein Lesbarkeitsindikator; die SVG-Bogenlaenge bleibt der exakte Anteil. Phase 7 bleibt offen.

Data-Hub-Kennzahlen vorladen 2026-09-25 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Bisher begann die Abfrage der sechs Statusdonuts erst nach der Mandantenauswahl; der Browser verwarf die fertigen Werte bei jedem Wechsel. Die neuesten scannergebundenen Timeslot-Zusammenfassungen werden jetzt bereits angefordert, sobald die Metadaten des jeweiligen Mandanten vorliegen, waehrend weitere Uebersichtsdaten noch laden. Ein browserseitiger Cache teilt laufende Abfragen, behaelt hoechstens 32 fertige Zusammenfassungen und begrenzt die spekulative Warteschlange auf 32 Eintraege. Zwei Abfragen laufen gleichzeitig; die Auswahl zieht eine wartende Abfrage nach vorne. Wiederverwendung umfasst Repository-Revision, Projekt, Assessment- und Scanlauf-IDs; dieselbe Revision wird bei Data-Hub-Rueckkehr ueber Health geprueft. Import-/Daten-/GPO-Aenderungen und geaenderter GPO-Jobstatus entwerten die Werte, verspätete Antworten ersetzen weder neuere Werte noch eine andere Auswahl. Es werden ausschliesslich die sechs berechneten Kennzahlen vorgeladen, keine Rohberichte oder vollstaendigen Browser-Workspaces. Synthetischer Test am echten DataHub-Klickpfad belegt Anfrage vor Abschluss der Uebersicht, Wiederverwendung laufender Abfragen, null neue Kennzahlenanfragen beim unveraenderten Wechsel und Remount sowie frische Ergebnisse nach Aenderung. Weitere Tests sichern Parallelitaetsgrenze, Auswahlprioritaet, Scope-/Revisionstrennung, Verdraengung und Fehlerbehandlung. 26 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Inhaltsfreie Browsermessungen nach Vorladen: 316 ms Auswahl bis sechs bereite Ringe, 317 ms beim Zurueckwechseln, jeweils inklusive Browsersteuerung und ohne parallelen Build; Beobachtungen, keine allgemeine Latenzgarantie. App/Backend laufen mit 2.6.32 und kanonischem PostgreSQL, Repository-Revision unveraendert 471. Entscheidung: rueckwaertskompatible Patchversion 2.6.32, keine Kennzahlensemantik-, Schema-, Import- oder Bestandsaenderung. Grenze: Beim Kaltstart oder einer Auswahl vor Abschluss des Vorladens bleibt die echte Ladeanzeige bestehen; ueber die begrenzte spekulative Warteschlange hinausgehende Mandanten laden bei Auswahl. Phase 7 bleibt offen.

Client-Info-Tabellen einheitlich 2026-09-25 (Phase 7/13C, erneute Nutzerkorrektur, umgesetzt und verifiziert): Die 2.6.29-Korrektur war auf historische Admin Groups begrenzt und hatte entgegen der 2.6.14-Vereinbarung wieder Tabellen-Ordnungsnummern eingefuehrt. Der gemeinsame Results-Renderer zeigt jetzt alle gespeicherten Grundtabellen direkt, auch in Directory, Resilience, Password policy, Certificates & PKI, Operating systems und Overall Score sowie bei alten Imports ohne Praesentationsmetadaten. Die alten `Open table`-Eintraege, `Additional source tables`-Schranke und erfundenen `Table N of M`-Titel entfallen. Native Tabellen-/Teilueberschriften bleiben, zusammengezogene historische Quellprosa ist vollstaendig im separaten `Source text` erreichbar. Dies ersetzt ausdruecklich den historischen Popup-Fallback aus 2.6.4 und die Teilkorrektur 2.6.29; die nativen Interaktionsregeln aus 2.6.9/2.6.14 bleiben bindend: Zelllinks oeffnen Popups, Aussenlinks klappen inline auf. Verlinkte Unterabschnitte bleiben jetzt in ihrer Kategorie; Ziele sind auf exakten Scanlauf und Importdatei begrenzt, und alle Tabellen eines Ziels bleiben erreichbar. Facts stehen kompakt in Zellen, breite OS-/Quelltabellen scrollen innerhalb ihres Bereichs. Die Anfangsposition und Groessenanpassung des Results-Fensters verwenden dieselben Abmessungen, damit das Fenster im Viewport bleibt. UI-Abnahme mit ausschliesslich synthetischen Daten in Light/Dark: sechs Results-Fenster, native Popup-/Inline-Pfade, Suche, Tabellencontainment und berechnete 14px Daten/Labels, 16px Werte und 20px Inset. 53 fokussierte Tests einschliesslich echter Results-Klickpfade aller Kategorien, PKI-Unterabschnitten aus zwei Berichten, Tabellenextraktion und UI-/API-Versionsvertrag sowie Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.31, keine Daten-, Import-, Schema- oder Persistenzaenderung. App HTTP 200 und Backend-Health melden 2.6.31 mit kanonischem PostgreSQL und unveraenderter Repository-Revision 471. Risiko/Grenze: Native Detailverknuepfungen fehlen in alten Imports; ohne erhaltenes Original koennen sie nicht beweissicher nachgetragen werden. Die gespeicherten Tabellen bleiben unmittelbar lesbar, fehlende Beziehungen werden nicht geraten. Phase 7/13C bleibt offen.

Bedeutung von Windows-Standardcodes 2026-09-25 (Darstellung, Nutzerentscheidung, umgesetzt): `PathText` haengt jedem erkannten Standardcode seine dokumentierte Bedeutung an (bekannte SIDs, standardisierte Domaenen-RIDs ohne Aufloesung des Domaenenteils, User-Rights-Konstanten, Registry-Typcodes). Eine gemeinsame Liste in `src/shared/windows-codes.ts` ersetzt die bisherige Einzelloesung fuer SID-Namen; Namen stehen jetzt direkt hinter der jeweiligen SID statt gesammelt am Zeilenende. Unbekannte und kundenspezifische Codes bleiben unveraendert. Reine Darstellung, kein Reimport; Tests fuer das Modul und angepasste Reader-Erwartungen.

DB-Structure-Ablaufplan 2026-09-25 (Darstellung, Nutzerauftrag, umgesetzt und verifiziert): Die Ansicht beginnt mit einem Datenfluss im Stil eines Programmablaufplans: Projects & assessments und Upload & custody fuer beide Wege, danach die Spalten Scanner reports (Report processing, Recognition & mapping, Canonical model, Findings & evidence) und GPO backups (Backup inventory, Policy identity, Snapshot aggregation, Baseline evaluation, Policy findings), daneben Microsoft baselines als ausdruecklich beschrifteter Eingang zur Baseline evaluation, unten zusammengefuehrt in Work & review und Comparison over time. Die Zuordnung steht als reine Praesentationsdefinition in `src/features/db-structure/db-structure-flow.ts`; nicht zugeordnete Tabellen erscheinen unter `Other tables`, nichts wird ausgeblendet. Alle 50 aktuellen Tabellen sind zugeordnet. Eine gewaehlte Tabelle traegt die gelbe Auswahl, ihre ein- und ausgehend verknuepften Tabellen werden neutral hervorgehoben, Spalten und Beziehungen erscheinen darunter. Geschaetzte Zeilenzahl 0 wird im Ablauf nicht angezeigt (PostgreSQL-Statistik ohne Analyse). Das bisherige Schichtenverzeichnis bleibt als geschlossene Offenlegung `Table dictionary by layer` erhalten. Verifiziert am Live-Schema (nur Tabellen- und Spaltennamen) in Dark und Light, drei synthetische Tests. Keine Schema-, API- oder Persistenzaenderung. Nachtrag (Nutzerfrage 'Wo ist die Result DB?'): Die Result DB ist keine Tabelle, sondern eine zur Abfragezeit gebildete Leseansicht (Scanner-Findings, Environment Observations, GPO-Vergleiche, GPO-Findings, GPO-Konsistenz). Sie erscheint deshalb als eigene Station `Result DB` neben `Work & review`, wo beide Wege zusammenlaufen, mit ihren Quelltabellen als reinen Sprungverweisen; Auswahl- und Verknuepfungsmarkierung bleiben am besitzenden Schritt.

Kachel-Haarlinie im Light-Theme 2026-09-25 (Designsystem, ausdrueckliche Nutzerentscheidung, umgesetzt und verifiziert): Kachelflaeche `#F5F5F7` und App-Hintergrund `#F1F1F4` liegen im hellen Theme nur eine Nuance auseinander; alle Flaechenfarben sollen bleiben. Deshalb traegt im hellen Theme `--tile-border: #DCDDE3` eine neutrale 1-px-Haarlinie, im dunklen Theme bleibt sie transparent. Kachel-Hover hellt die Flaeche auf `#F8F8FA` auf und behaelt die Kontur (vorher dunkler als die Kachel und mit verschwindender Kontur). Kachelinterne Faktentrenner nutzen den neuen Token `--tile-divider`; das globale `--border-subtle` und damit die Work-Listentrenner bleiben unveraendert. Client-Info-, Datahub-, DB-Structure- und Policy-Analyse-Kacheln, die bisher `border: 0` setzten, verwenden jetzt denselben Token. AGENTS.md fuehrt die Ausnahme zur Regel ohne sichtbare Normalkontur als datierte Nutzerkorrektur. Token- und Grammatiktests angepasst und ergaenzt; synthetische Browserpruefung hell (Kontur sichtbar) und dunkel (unveraendert). Teil des noch nicht veroeffentlichten Stands 2.6.30.

GPO-Baselinevergleich im Finding Reader kompakt 2026-09-25 (Phase 13B, Nutzerauftrag, umgesetzt und verifiziert): Eine zusammengefasste GPO-Einstellung wiederholte bisher je Baselinepaket dieselbe Variantenzusammenfassung, dieselben Rollen- und Scope-Hinweise sowie identische Erwartungs- und Abweichungszeilen. Der Reader zeigt fuer eine aktuelle, vollstaendig strukturierte Variantenbewertung jetzt einen Abschnitt `Baseline comparison`: Sind alle Paketverdicts und alle Variantenergebnisse woertlich identisch, erscheint eine Aussage mit Varianten- und Paketanzahl sowie gemeinsamen zusaetzlichen/fehlenden Eintraegen; Rollen- und Scope-Hinweis stehen einmal. Jeder gespeicherte Einzelvergleich bleibt in `All baseline comparisons` erhalten, nach Nutzerkorrektur als gruppierte Liste statt fuenfspaltiger Tabelle: je Paket Titel und Verdict in einer Zeile, darunter je Variante Template und Setting reference; Umbrueche nur an Wortgrenzen, die globale Tabellen-Versalschrift entfaellt. Identische Werte werden je Variante nicht wiederholt; bei unterschiedlichen Ergebnissen ist die Aufschluesselung sofort geoeffnet und zeigt je Variante Ergebnis, Erwartung und Abweichung, ohne einen Konsenswert zu bilden. Synthetische Browserpruefung in Light/Dark bei schmaler und breiter Lesespalte. Zweite Nutzerkorrektur (Beispiel mit einheitlichem Fail, aber unterschiedlichen Sollwerten je Paket): Ergebnis- und Wertgleichheit werden getrennt bewertet. Ein einheitliches Ergebnis wird als solches benannt; unterschiedliche Sollwerte erscheinen einmal je Wertgruppe mit namentlich genannten Ausnahmepaketen, die groesste Gruppe mit Paketanzahl. Der separate Block `Expected baseline value` und die je Paket wiederholte Remediation werden im Reader durch diese Gruppen ersetzt; die Remediation behaelt den Hinweis, zuerst das zutreffende Template festzulegen, und kombiniert keine Werte. Die Aufschluesselung oeffnet sich nur bei abweichenden Ergebnissen. Dritte Nutzerkorrektur (Conflict/Duplicate): Tragen mehrere GPO-Backups bei, fasst eine neutrale Wertuebersicht oberhalb der unveraendert vollstaendig sichtbaren Quellabschnitte zusammen, welche Anweisung (Operation, Data, Type code) von wie vielen und welchen Backups stammt; ein nur in Gross-/Kleinschreibung abweichender Registry-Schluessel wird ausdruecklich benannt. Die Uebersicht entscheidet weder Verdict noch Conflict-/Duplicate-Flag und traegt keine rote Markierung; diese bleibt feldgenau im Quellabschnitt. Befund ohne Aenderung: Aggregation (`gpo-policy-snapshot-service.ts`) und Evaluation (`gpo-policy-evaluation-service.ts`) vergleichen Kundenwerte per `canonicalJson` einschliesslich der Schreibweise des Registry-Schluessels, sodass wertgleiche Beitraege mit abweichender Schreibweise als Conflict statt Duplicate gelten koennen. Eine Korrektur waere eine versionierte Engine-Aenderung mit Neuauswertung und wird nur nach ausdruecklicher Nutzerfreigabe umgesetzt. Vierte Nutzerkorrektur (Lesereihenfolge, Ziel: Problem in 2 Sekunden erkennbar): Der GPO-Reader beginnt nach der Einstellungsueberschrift mit einem Block `Problem` (bei anderen Verdicts `Summary`): Configured gegen Expected, beitragende GPO-Backups mit gleichem oder unterschiedlichem Wert, einheitliches oder abweichendes Baseline-Ergebnis, vorhandene Conflict-/Duplicates-Zusammenfassung samt Gross-/Kleinschreibungshinweis und `Next step` mit gruppierter Remediation und den nachweislich abweichenden Backups. Alle Teile stammen aus gespeicherten Werten, Vergleichen und Diagnosezusammenfassungen; der Block bewertet nichts neu und erscheint nur bei aktuellen strukturierten Vergleichen. Die GPO-Quellabschnitte folgen direkt darunter weiterhin vollstaendig ohne Aufklappen (Nutzerbestaetigung 2026-09-25); die Wertuebersicht erscheint dort nur noch bei unterschiedlichen Werten. Der Baseline-Vergleich wiederholt ein einheitliches Ergebnis nicht. Registry path, Technical Identity, Imported, Evaluated und Diagnostics stehen fuer GPO unter Additional Information; Scope bleibt gemaess Entscheidung 2026-09-06 im Report. Nutzerentscheidung: Die Arbeitsfelder Status, Priority, Owner/Team, Due Date, Review-Texte und Marker stehen fuer alle Werkzeuge in einem standardmaessig geschlossenen Abschnitt `Work tracking` unterhalb des Findings, dessen Kopfzeile Status, Priority und gesetzte Owner/Due-Werte zeigt. Fuenfte Nutzerkorrektur: `Problem` und `Next step` sind getrennte Bloecke mit je einem Markierungsstrich in `--marker-width` (Problem in der Outcome-Farbe, Next step im Orange `--next-step-accent` = `--sev-high`). Setzen mehrere GPO-Backups dieselbe Anweisung, liegen die vollstaendigen Quellabschnitte in einer geschlossenen Offenlegung (AGENTS.md-Korrektur 2026-09-25); unterschiedliche Anweisungen, Einzelquellen und historische Vergleiche bleiben sofort sichtbar. Bei gemischten Paketergebnissen erklaert der Problem-Block das Rollup (hoechstes Paketergebnis, Anzahl Fail/Review required, Pakete mit widerspruechlichen Templates), benennt Sollwertgruppen nach Template, sobald sich ein Paket auf mehrere Gruppen verteilt, und zeigt den Hinweis zur Template-Festlegung einmal statt je Paket. Keine Verdict-, Rollup- oder Engine-Aenderung. Sechste Nutzerentscheidung (Rot/Gruen): Falsche Einstellungen sind rot, richtige gruen. Gruen verlangt denselben Beweis wie Rot in Gegenrichtung (ganzer Wert passt zu jeder aktuellen Baseline-Variante bzw. Principal in jeder erwarteten Menge); nur teilweise passende, pruefpflichtige und historische Werte bleiben neutral. Umgesetzt in GPO-Quellabschnitten (`alignedItems`, `policy-source-aligned-value`), im Problem-Block (`Configured` je Eintrag, zusaetzliche Eintraege nicht mehr doppelt) und in den GPO-Konflikt-/Duplikatvarianten im Results-Fenster (Variante nur gefaerbt, wenn alle ihre Quellen dieselbe bewiesene Relation haben). AGENTS.md-Regel ergaenzt; weitere Scanner-Results nur mit quellseitigem Nachweis je Wert/Zeile, CIS-CAT unveraendert. Siebte Nutzerkorrektur: Auch bei unterschiedlichen Anweisungen mehrerer GPO-Backups liegen die vollstaendigen Quellabschnitte zugeklappt (`Show the N source instructions`); die sichtbare Wertuebersicht nennt jede Anweisung mit ihren Backups. Einzelquellen und historische Vergleiche bleiben offen. Rot/Gruen in Scanner-Results: Neue deklarative Profiloption `resultSheetRowStatusCells` faerbt eine Belegzeile nur bei ausdruecklichem quellseitigem Zeilenstatus (widerspruechliche Marker ergeben keine Farbe). Maester setzt sie fuer Haekchen/Kreuz- und Pass/Fail-Zellen seiner Ergebnistabellen; PingCastle und Purple Knight liefern je Zeile nur betroffene Objekte ohne Status und bleiben ungefaerbt; CIS-CAT unveraendert. Reine Darstellungsaenderung ueber bereits gespeicherte Werte, kein Reimport. Entscheidung GPO-Zielrolle je Backup 2026-09-25 (Nutzerentscheidung nach Messung, abgeschlossen): Der Umbau (Rolle je Backup, getrennte Befunde je Rolle, neue Evaluator-Version) wird nicht umgesetzt. Messung mit dem nur Zahlen ausgebenden Skript `scripts/gpo-role-impact.ts`, das die Nutzerin/der Nutzer selbst ausserhalb der App ausfuehrte, am Dummy und an einem echten Projekt: 58 aktuelle Fail-Einstellungen, davon 57 rollenunabhaengig (kein Template irgendeiner Rolle stimmt ueberein) und 1 rollenabhaengig; 0 nur durch nicht erkannte Templates abhaengig. Aus eindeutigen Belegen ableitbar waeren nur 2 von 184 Backups (Default Domain Controllers Policy, Verknuepfung nur mit `Domain Controllers`), 8 wirken domaenenweit, 145 bleiben unbekannt. Der Nutzen (1 von 58) rechtfertigt keinen Eingriff in Evaluation, Persistenz und Neuauswertung. Befund mit Folgeauftrag: 29 von 184 Backups sind nicht verknuepft; 2 Fail-Einstellungen stammen ausschliesslich aus solchen GPOs. Verdicts und Score bleiben dafuer unveraendert; ein Hinweis auf nicht verknuepfte GPOs wurde beauftragt. Umsetzung Hinweis (Phase 13B, Nutzerfreigabe inklusive Reprocessing): Metadatenparser 1.4.0 behaelt aus `GPReport.xml` nur Anzahl und aktivierte Anzahl der `LinksTo`-Eintraege (keine OU-/Domaenennamen); die Backupinstanz traegt `links` mit Validierung, die Unified-Projektion `policyBackupLinkStatus`. Finding Reader: Badge `Not linked` mit Hinweis je Quellabschnitt und `No effect`-Zeile im Problem-Block, wenn alle beitragenden GPOs unverknuepft sind (Teilmenge wird gezaehlt); GPO Processing zeigt `N not linked`. Versionen append-only: `gpo-backup-policy-analysis` und Jobprozessor 2.2.4 -> 2.2.5, damit bestehende Backups `Reprocessing required` zeigen; die Baseline-Vorlagenvariante bleibt 1.3.0. Keine Aenderung an Verdicts, Flags, Score, Evaluator oder SQL-Schema; REIMPORT_POLICY-Klarstellung und AGENTS.md-Regel ergaenzt. Synthetische Parser-, Ingestion-, Reader- und Statuszeilen-Tests. Scanner-Erstlesung (Nutzerentscheidung, alle vier Scanner in einem Schritt): PingCastle, Purple Knight, CIS-CAT und Maester erhalten denselben Aufbau wie GPO: `Problem` (Result, Expected/Found, Affected bzw. Results-Zeilen, Impact) und `Next step` (Remediation/Advised solution, erster Absatz sichtbar, Rest vollstaendig unter `Full remediation`; bei Maester der https-Dokumentationslink) vor Background und References. Die Feldzuordnung steht deklarativ in `presentation.firstRead` jedes Profils; der Reader blendet die verwendeten Felder nicht doppelt ein. Maester-ResultDetail bleibt ausschliesslich in Results. Nur Darstellung ueber gespeicherte Werte, kein Reimport. AGENTS.md-Abschnitt `UI Finding Reader first read` ergaenzt; fuenf synthetische Reader-Tests und angepasste Reihenfolgetests. Historische oder unvollstaendig strukturierte Vergleiche behalten die bisherige Volltextdarstellung. Die Felder Description, Baseline und Comparison bleiben fuer Work-Export, Suche und Filter unveraendert; nur der Reader blendet sie bei vorhandener Struktur aus. Dokumentierte, mandantenunabhaengige Windows-SIDs (z. B. S-1-5-32-549 Server Operators) erhalten neben dem unveraenderten Originalwert eine Namenshilfe; domaenenbezogene SIDs werden nie benannt. Vier synthetische Reader-Tests pruefen identische, abweichende und historische Vergleiche sowie die SID-Namen; bestehende GPO-Rollup-Tests und beide Produktionsbuilds bestanden. Acht Fehlschlaege der Gesamtsuite betreffen parallele, nicht zugehoerige Arbeitsstaende (Client-Info-Domaenenzeilen, Result-DB-Timeslots, Security-Domain-Filter, AppLocker-`<code>`-Pruefung) und wurden nicht veraendert. Keine Browserpruefung mit realen Daten (Privacy-Regel). Entscheidung: rueckwaertskompatible Patchversion 2.6.30, reine Darstellungsaenderung ohne Import-, Bewertungs-, Schema- oder Reimportfolgen. Phase 13B bleibt offen.

Historische PingCastle-Inventory-Results 2026-09-25 (Phase 7/13C, Nutzerkorrektur, umgesetzt und verifiziert): Die alte Admin-Groups-Projektion zeigte einen zusammengezogenen Quelltext sowie viele gleich benannte `Groups`-Buttons statt nutzbarer Ergebnisse. Fuer vorhandene PingCastle-Imports ohne gespeicherte Linkmetadaten steht die native `Admin groups list` jetzt unmittelbar als durchsuchbare, seitenweise lesbare Tabelle im Results-Fenster. Weitere Quelltabellen bleiben unter `Additional source tables` erreichbar; wiederholte native Titel erhalten eine eindeutige Ordnungsnummer. Generische `Groups`-Unterabschnitte verdecken den konkreteren nativen Tabellennamen nicht mehr. Wiederholte alte `Close`-/`Legend`-Steuertexte erscheinen nicht im Lesetext; der unveraenderte Quelltext bleibt in `Original source text` zugaenglich. Weder eine Gruppe-zu-Detailtabelle-Zuordnung noch ein fehlender Quellentitel wird erfunden. Ein synthetischer Klickpfad prueft die historische Admin-Groups-Liste, die getrennten Detailtabellen und den erhaltenen Originaltext; ein zweiter prueft die alten Graph-Steuertexte. 20 fokussierte UI-/Versions-/API-Tests, Local-only- und Designpruefung sowie beide Produktionsbuilds bestanden. Im vorhandenen Liftket-Bestand sind die native Uebersicht und eine Detailtabelle in Light und Dark lesbar; Light wurde wiederhergestellt. Entscheidung: rueckwaertskompatible Patchversion 2.6.29, reine Leseprojektion ohne Import-, Daten-, Schema- oder Persistenzaenderung. Backend-Health meldet 2.6.29 mit kanonischem PostgreSQL und unveraenderter Repository-Revision 471. Risiko: Alte Imports enthalten weiterhin keine Zuordnung einzelner Admin-Gruppen zu den namenlosen Detailtabellen; diese bleibt bis zu einem quellengestuetzten Reimport unbestimmt. Phase 7/13C bleibt offen.

Maester-Testresultat nur in Results 2026-09-25 (Phase 7/13C, erneute ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Der Finding Reader zeigt Maesters `ResultDetail` samt Markdown-Tabelle nicht mehr ein zweites Mal als `Test result` im Report. Das Results-Fenster zeigt den unveraenderten nativen Ergebnistext und die Tabelle weiterhin; Titel, Source Rule ID, Beschreibung, Test details, Tags und Review-Felder bleiben im Reader. Dies bekräftigt die Nutzerentscheidung vom 2026-07-28 und ersetzt nur die spaetere `Test result`-Zeile der Maester-Reader-Hierarchie vom 2026-09-22. Ein synthetischer Reader/Results-Klickpfad prueft genau die gemeldete Doppelanzeige. 63 fokussierte Tests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Im Dummy steht ein Maester-Testresultat in Light/Dark ausschliesslich im geoeffneten Results-Fenster; Light wurde wiederhergestellt. Entscheidung: rueckwaertskompatible Patchversion 2.6.28, keine Quellwert-, Import-, Schema- oder Persistenzaenderung. App und Backend melden 2.6.28 am bestehenden Port 4173 mit kanonischem PostgreSQL und unveraenderter Repository-Revision 471. Phase 7/13C bleibt offen.

Source-metrics-Kachel entfernt 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die Kachel `Source metrics` erscheint nicht mehr in der dauerhaft sichtbaren Client-Info-Umgebungsuebersicht. Die sechs uebrigen Kacheln ruecken in unveraenderter Reihenfolge auf; Quelldaten und Import bleiben unangetastet. Diese Entscheidung ersetzt die fruehere Anzeige der siebten Umgebungskachel in der Uebersicht. Entscheidung: rueckwaertskompatible Patchversion 2.6.27, keine Schema- oder Persistenzaenderung. 24 fokussierte Tests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Im Dummy zeigen Light und Dark genau die sechs erwarteten Umgebungskacheln ohne `Source metrics`; Light wurde wiederhergestellt. App und Backend melden 2.6.27 am bestehenden Port 4173 mit kanonischem PostgreSQL und unveraenderter Repository-Revision 471. Phase 7 bleibt offen.

Security-Domain-Zeilen ohne Rahmen 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die normalen Zeilenrahmen in Client Info entfallen. Die semantischen Kreise und Balken sowie der blaue 2-px-Tastaturfokus bleiben erhalten. Entscheidung: rueckwaertskompatible Patchversion 2.6.26, keine Daten- oder Persistenzaenderung. 34 fokussierte UI-/Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Im Dummy zeigen Light und Dark bei allen acht Domain-Zeilen berechnete `0px` Rahmenbreite; Light wurde wiederhergestellt. App und Backend melden 2.6.26 am bestehenden Port 4173 mit dem kanonischen PostgreSQL und unveraenderter Repository-Revision 471. Phase 7 bleibt offen.

Maester-Untertestkennungen 2026-09-25 (Phase 7/13C mit Disclosure-Grenze aus Phase 12/13B, erneuter Nutzerfehlerbericht, umgesetzt und verifiziert): Die vier weiter leeren Screenshotzeilen zu ablaufenden App-Credentials, MFA-Registrierung und Sign-in-/User-Risk-Policies besitzen exakte native MT.1024-Untertestkennungen. Die vorherige Ergaenzung war fuer diese Faelle unvollstaendig. 16 erhaltene Untertest-IDs wurden anhand der [oeffentlichen Maester-Erzeugungsregel](https://raw.githubusercontent.com/maester365/maester/main/tests/Maester/Entra/Test-EntraRecommendations.Tests.ps1), der [Microsoft-Graph-Empfehlungstypen](https://learn.microsoft.com/en-us/graph/api/resources/recommendation?view=graph-rest-beta) und der [Insider-Risk-Dokumentation](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-insider-risk-condition) einzeln validiert und exakt freigegeben. Hinzu kommt die historisch dokumentierte [MT.1040](https://maester.dev/docs/tests/MT.1040/). Die Regelsuche behaelt die volle Kennung und verlinkt MT.1024-Untertests auf die existierende Basisdokumentation. Lange Source-Rule-IDs umbrechen in der Result-DB-Spalte vollstaendig statt einer Ellipse. Entscheidung: Disclosure Policy 2.5.3 und Patchversion 2.6.25; keine pauschale Praefixfreigabe, keine Import-, Schema- oder Bestandsmutation. Der Dummy-Katalog deckt damit 308 von 318 verschiedenen Quellkennungen ab. Risiko/Grenze: Die zehn verbleibenden Kennungen, insbesondere die Screenshot-Warnung MT.INV.001, besitzen noch keinen exakten oeffentlichen Beleg; ihre Freigabe bleibt nach der bestehenden Regel gesperrt. 54 fokussierte Tests, Client-/Server-Produktionsbuild sowie Local-only-/Designpruefung bestanden. Die vier gemeldeten Untertests wurden per Live-API und in der Result DB bestaetigt; lange Kennungen bleiben in Light/Dark innerhalb ihrer Zellen lesbar. Light wurde wiederhergestellt. App/Backend melden 2.6.25 am bestehenden Port 4173 mit dem kanonischen PostgreSQL und unveraenderter Repository-Revision 471. Phase 7/13C und 12/13B bleiben offen.

Maester-Source-Rule-ID-Luecken 2026-09-25 (Phase 7/13C mit Disclosure-Grenze aus Phase 12/13B, Nutzerfehlerbericht, umgesetzt und verifiziert): Der kanonische Dummy-Bestand enthaelt fuer die im Result-DB-Screenshot leeren Maester-Zellen native Kennungen wie `CIS.M365.1.1.1` und `CISA.MS.AAD.2.3`; der Import hat sie nicht verloren. Die bisherige Disclosure-Freigabeliste kannte im Wesentlichen MT-Kennungen, weshalb die Result DB diese vorhandenen IDs ausgeblendet hat. Die Liste wurde um 245 exakt auf den offiziellen Maester-Suitenlisten dokumentierte IDs aus CIS, CISA, Entra ID SCA, ORCA und Maester erweitert. Im Dummy sind damit 291 von 318 verschiedenen Maester-Quellkennungen freigegeben; 27 Sonder-, historische oder instanzspezifische Kennungen bleiben mangels exakter oeffentlicher Validierung fail-closed. Die gemeinsame Liste versorgt Result DB, JSONL und die oeffentliche Regelsuche. Entscheidung: Disclosure Policy 2.5.2 und rueckwaertskompatible Patchversion 2.6.24, keine Import-, Schema-, Persistenz- oder Bestandsdatenmutation und kein Reimport. Risiko: Zukuenftige neue Maester-IDs benoetigen weiterhin eine dokumentierte Katalogergaenzung; dynamische Instanzsuffixe werden nicht allein durch ein bekanntes Basis-ID freigegeben. Der synthetische Result-DB-Zeilentest deckt die beiden gemeldeten CIS-/CISA-Beispiele einschliesslich Detailansicht ab; der Disclosure-Test prueft alle fuenf Suiten und die Sperre unbekannter IDs. 53 fokussierte Tests, Local-only-/Designpruefung und beide Produktionsbuilds bestanden. Phase 7/13C und 12/13B bleiben offen.

Result-DB-Disclosure-Praezisierung 2026-09-25 (Phase 12/13B, ausdrueckliche Nutzerentscheidung, umgesetzt und fokussiert verifiziert): Result DB API und JSONL behalten die konkreten quellengestuetzten Scannerbefunde, oeffentlichen Regelkennungen, Bewertungen, vorhandene Regeltexte und die GPO-Ist-/Sollwerte samt Baseline. Ein nicht vorhandener Scanner-Istwert wird nicht erfunden. Disclosure Policy 2.5.1 bewahrt numerische CIS-CAT-Regelkennungen im Titel und eng bekannte GPO-Richtlinienpfadteile vor falscher IP-/Konto-Redaktion; nicht oeffentliche technische SIDs erhalten stabile resultlokale Platzhalter, auch in verschachtelten Baselinevarianten. Kanonische Originale und internal-analysis bleiben unveraendert. Entscheidung: rueckwaertskompatible Patchversion 2.6.22; gemeinsame Disclosure-Projektion fuer API und JSONL, keine Daten-, Schema-, Import- oder Persistenzmutation. Risiko: Freie Quelltexte und die Kombination konkreter Sicherheitsresultate koennen auch nach Musterredaktion eine Kundenumgebung wiedererkennbar machen; dies ist keine pauschale Freigabe fuer beliebige externe Empfaenger. 25 fokussierte Disclosure-/JSONL-/API-/Versionsvertragstests, Local-only- und Designpruefung sowie beide Produktionsbuilds bestanden. Die Gesamtsuite meldet 1.478 bestandene, sieben fachfremde fehlgeschlagene und 13 uebersprungene Tests; die Fehler betreffen Dashboard-/GPO-XML-/Timeslot-UI-Vertraege ausserhalb dieser Aenderung. Das laufende kanonische PostgreSQL-Backend meldet weiterhin 2.6.21; wegen des dokumentierten automatischen GPO-Reconciliation-Risikos und zur Vermeidung einer Unterbrechung der Hauptaufgabe wurde es in diesem Schritt nicht neu gestartet. Phase 12/13B bleibt offen.

Client-Info-Kacheltypografie und Faktenkaestchen 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Alle Client-Info-Dashboardkacheln ausser Overall Score folgen nun Data mit 16 px fuer Titel und lesbare Werte sowie 14 px fuer Informationslabels. Die bisherigen 12-px-Informationslabels in Data wurden auf die verbindliche 14-px-Rolle angehoben. Domain Information und die sieben Umgebungskacheln zeigen jede Information als eigene flache Zelle mit feinen gemeinsamen Trennlinien; Security-Domain-Zeilen tragen denselben zurueckhaltenden Zellkontur. Overall Score, das separate Accepted-Risks-Master/Detail, Werte, Quellen, Scoresemantik und Drilldowns bleiben erhalten. Entscheidung: Die frueheren groesseren H3-/20-px-Schriften einzelner Client-Info-Kacheln werden durch diesen Nutzerwunsch ersetzt; rueckwaertskompatible Patchversion 2.6.23. Risiko: Laengere kuenftige Quelltexte koennen einzelne Kacheln natuerlich vergroessern; weder Informationen noch Schriftgroessen werden gekuerzt. 44 fokussierte UI-/API-/Versionsvertragstests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Am freigegebenen Dummy wurden Light, Dark und die schmale Ansicht ohne Ueberlauf geprueft; bei breitem Layout teilen Posture, Data und Domain Information dieselbe Unterkante. Light und die normale Browserbreite wurden wiederhergestellt. Backend-Health meldet 2.6.23 mit dem kanonischen PostgreSQL. Keine Import-, Daten-, API-, Schema- oder Persistenzaenderung; Phase 7 bleibt in Arbeit.

Client-Info-Hardfacts in doppelten Umgebungskacheln 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die sieben dauerhaft sichtbaren Umgebungskacheln verwenden nun die doppelte gemeinsame Kompaktbreite von 372 px. Ein zweispaltiges Faktenraster zeigt in Inventory alle acht ersten Hardfacts einschliesslich Enabled/disabled und Assessed host direkt in der Kachel. Resilience, Password policy und Certificates & PKI zeigen ihre vorhandenen Zusammenfassungen vollstaendig; Directory zeigt seine ersten sechs Fakten, waehrend weitere Angaben in Domain Information und Directory Results erreichbar bleiben. Source metrics zeigt bis zu acht vorhandene Kennzahlen, Operating systems vorhandene Gruppensummen und erste Quellzeilen; vollstaendige Listen, Originalbelege und OS-Tabelle bleiben in Results. Entscheidung: Die bisherige 186-px-/Ein-Fakt-Vorschau ist durch den Nutzerwunsch ersetzt; rueckwaertskompatible Patchversion 2.6.21. Risiko: Laengere kuenftige Quellwerte lassen betroffene Kacheln bei Bedarf natuerlich wachsen, statt Schrift unter die vereinbarten 14-/16-px-Rollen zu senken oder Inhalt abzuschneiden. 33 fokussierte UI-/API-/Versionsvertragstests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Im freigegebenen Dummy messen alle sieben Kacheln in Light und Dark 372 mal 372 px ohne Ueberlauf; Light wurde wiederhergestellt. Backend-Health meldet 2.6.21 mit dem kanonischen PostgreSQL. Keine Import-, Daten-, API-, Schema- oder Persistenzaenderung; Phase 7 bleibt in Arbeit.

Client-Info-Source-Overview-Kachel entfernt 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die markierte Source-Overview-Kachel ist aus dem dauerhaft sichtbaren Umgebungsraster entfernt; sieben kompakte 186-mal-186-px-Kacheln bleiben. Der vorhandene Overall-Score-Bereich traegt nun einen Results-Zugang zu den unveraenderten Quell-Score-Beitraegen, einzelnen Quellbefunden und Originalabschnitten, zur Restriktionsinformation, zu den Work-Drilldowns und zur Scoring Methodology. Der Score-Ring bleibt sein eigener Work-Einstieg. Directory zeigt in der kleinen Kachel die quellengestuetzte Domainanzahl statt eines getrennten Domainnamens; der volle Name bleibt in Domain Information und Directory Results. Entscheidung: rueckwaertskompatible Patchversion 2.6.20; die fruehere Pflicht einer eigenen Source-Overview-Kachel wird durch diesen Nutzerwunsch aufgehoben, die Scoresemantik und Provenienz bleiben erhalten. Risiko: Die Quellenliste liegt nun im Overall-Score-Results-Fenster und ist fuer neue Nutzer weniger unmittelbar sichtbar; der klar beschriftete Results-Button ist an der Score-Ueberschrift erreichbar. 44 fokussierte Dashboard-, Interaktions- und Versionsvertragstests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Der freigegebene Dummy zeigte sieben quadratische Kacheln ohne Ueberlauf, Directory mit `Domains 1`, Score-Results mit fuenf Quellen und Bewertungsaktion; Light und Dark wurden visuell geprueft und Light wiederhergestellt. Backend-Health meldet 2.6.20 mit dem kanonischen PostgreSQL. Keine Import-, Daten-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt in Arbeit.

Client-Info-Umgebungskacheln 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die bisher aufklappbare Environment-Detail-Huelle und ihre zusammenfassende Kopfzeile sind entfernt. Alle acht Gruppenkacheln stehen dauerhaft sichtbar in einem responsiv umbrechenden Raster aus kompakten quadratischen Kacheln. Jede zeigt nur einen priorisierten, quellengestuetzten Ueberblickswert; vollstaendige Faktlisten, Source-Score-Beitraege und Work-Drilldowns, Restriktionshinweise, Betriebssystemtabellen sowie Originalabschnitte und Einzelbeobachtungen bleiben ueber das jeweilige Results-Fenster erreichbar. Die Scoring-Methodology-Aktion ist in Source Overview Results erreichbar. Entscheidung: rueckwaertskompatible Patchversion 2.6.19; die frueher verbindliche Disclosure-, Vier-Spalten-, Dreiviertelhoehen- und Innen-Scroll-Regel wird durch diesen Nutzerwunsch ersetzt. Risiko: Lange kuenftige Quellenwerte duerfen weder gekuerzt noch verkleinert werden und koennen eine einzelne quadratische Kachel vergroessern; das bleibt bei unbekannten Quellen visuell zu pruefen. 32 fokussierte Tests, Design-/Local-only-Pruefung und beide Produktionsbuilds bestanden. Am freigegebenen Dummy wurden die dauerhaften Kacheln, Directory Results und Light/Dark geprueft; der Backend-Health meldet 2.6.19 mit kanonischem PostgreSQL. Keine Import-, Daten-, API-, Schema- oder Persistenzaenderung. Phase 7 bleibt in Arbeit.

Client-Info-Domainordnung und Data-Ring 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Domain Information zeigt unveraenderte, quellengestuetzte Werte in logischen Paaren: Domain als volle Zeile, dann NetBIOS name/Forest, Domains/Domain controllers, Domain functional level/Forest functional level, DC OS/Schema version und Domain created/Entra ID. Der klickbare Deviations-Donut nutzt innerhalb des bisherigen Data-Kopfbereichs einen 184-px-Ring statt 128 px; nur seine lokalen Innenabstaende sind verringert, die Ergebniszeile und das 3-mal-2-Faktenraster bleiben vollstaendig sichtbar. Am freigegebenen Dummy haben Posture, Data und Domain Information weiterhin dieselbe 487-px-Hoehe und Unterkante. Light und Dark wurden visuell geprueft, Light wiederhergestellt. 34 fokussierte Dashboard-, Interaktions- und Versionsvertragstests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestehen. Entscheidung: rueckwaertskompatible Patchversion 2.6.18 als reine Lese- und Layoutkorrektur; die fruehere Data-Hub-Ringdimension gilt fuer diesen Client-Info-Donut nicht mehr, Komponente, Titel ausserhalb des Rings, Wertsemantik und Work-Drilldown bleiben erhalten. Keine Daten-, API-, Schema- oder Persistenzaenderung. Risiko: Laengere neue Domainwerte koennen Zellen und damit die gemeinsame Kachelzeile natuerlich vergroessern; es wird nichts gekuerzt. Phase 7 bleibt in Arbeit.

Client-Info-Domainzeilen auf Kreismitte 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Domainname, Mengenbalken und rechte Anzahl stehen jetzt in derselben Rasterzeile wie ihr Scorekreis. Der bisherige Zwei-Zeilen-Span des Kreises hob die drei anderen Elemente um 10 px an; im freigegebenen Dummy betraegt die gemessene Abweichung nach der Korrektur fuer alle acht Zeilen nur noch etwa 0,01 px. Verbindungsboegen, 487-px-Kachelhoehe, Werte und Drilldowns bleiben erhalten. Light und Dark wurden bei normaler Browsergroesse visuell geprueft, Light wiederhergestellt. 31 fokussierte Dashboard-, Interaktions- und Versionsvertragstests, Design- und Local-only-Pruefung sowie Client- und Backend-Produktionsbuild bestehen. Entscheidung: rueckwaertskompatible Patchversion 2.6.17 als reine Layoutkorrektur ohne Daten-, API-, Schema- oder Persistenzaenderung. Risiko: Bei kuenftig mehrzeiligen Domainnamen waechst die betroffene Zeile natuerlich; sie wird nicht gekuerzt. Phase 7 bleibt in Arbeit.

Client-Info-Kachelhoehe und Gaps-Detail 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die eigenstaendige Assessment-Gaps-Kachel ist entfernt. Die autoritative, anklickbare Gaps-Kennzahl und ihr exakter Work-Drilldown bleiben in Data; die GPO-Quellenzeile meldet weiterhin notwendige Neuauswertungen. Security posture, Data und Domain Information besitzen in der breiten Hauptzeile dieselbe Hoehe und Unterkante. Score-Ring, acht Domainknoten, Namen, Mengen und Verbindungsboegen wurden innerhalb dieser Hoehe skaliert, ohne Informationsschrift unter ihre vereinbarten Rollen zu senken oder Inhalte abzuschneiden. Am freigegebenen Dummy wurden bei 1969 px Breite fuer alle drei Kacheln 487 px Hoehe und dieselbe Unterkante gemessen; die letzte Domainzeile endet 34 px oberhalb dieser Kante. Light und Dark wurden visuell geprueft, Light wiederhergestellt. 39 fokussierte Dashboard-, GPO-, Interaktions- und Versionsvertragstests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestehen. Der laufende lokale Backendprozess nutzt weiterhin den kanonischen PostgreSQL-Datastore und meldet nach gezieltem Neustart Version 2.6.16. Entscheidung: rueckwaertskompatible Patchversion 2.6.16 als reine UI-Korrektur ohne Daten-, API-, Schema- oder Persistenzaenderung; die fruehere Assessment-Gaps-Kachelentscheidung ist durch diesen Nutzerwunsch ersetzt. Risiko: Andere Quellwerte und sehr schmale Breiten koennen zusaetzliche Zeilen erzeugen; das responsive Layout laesst die Kacheln dann natuerlich wachsen statt Inhalte abzuschneiden. Phase 7 bleibt in Arbeit.

Data-Hub-Donut-Ladezeit und Designruecknahme 2026-09-25 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Der Ergebnisendpunkt verwendet fuer die sechs Donuts eine schlanke, schreibfreie Projektblattprojektion und laedt aus PostgreSQL nur die aktuell gueltigen GPO-Auswertungslaufe. Die Auswahl folgt denselben Profil-, Identity-Analyse-, Snapshot- und Evaluations-Supersession-Regeln wie die autoritative Policy-Uebersicht; historische Auswertungen bleiben gespeichert und fuer andere Ansichten verfuegbar. Der erste Aufruf am bestehenden Dummy sank lokal von etwa 13,0 auf 3,4 Sekunden. Alle sechs Werte blieben identisch (`1.833` gesamt, `477` Abweichungen, `282` Passed, `3` Not Applicable, `171` Not Run, `2` Error); der synthetische Mandantenauswahltest bestaetigt weiterhin den Ladezustand ohne falsche Null. Die Donut-Praesentation aus 2.6.12 wurde auf ausdruecklichen Wunsch zurueckgenommen: Titel stehen wieder ausserhalb der Ringe, Data-Hub-Ringe nutzen wieder 128 px und es gibt keinen Ringschatten. Die Wertsemantik und der Ladezustand aus 2.6.13 bleiben erhalten. Data Hub wurde am Dummy in Light und Dark visuell geprueft; Light wurde wiederhergestellt. Entscheidung: rueckwaertskompatible Patchversion 2.6.15, keine Schema-, Bestandsdaten- oder Persistenzmutation. Risiko: Bei groesseren kuenftigen Datenstaenden kann der erste Aufruf weiter mehrere Sekunden benoetigen; die Messung gilt fuer den derzeitigen lokalen Dummy und ersetzt keinen Lasttest. Phase 7 bleibt in Arbeit.

Environment-Detail-Originalueberschriften 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Die Results-Ansicht zeigt fuer Abschnitte und Tabellen nur belegte PingCastle-Ueberschriften. Zusaetzliche Berichtstitel wie `Original report sections`, `Original report section`, `Original report table`, `Mapped observations from this table`, `Further observations from ...` und die erfundene Tabellen-Ordinalzahl wurden entfernt; technische Beobachtungen bleiben ueber einen neutralen Disclosure erreichbar. Wenn ein vorhandener Abschnitt wegen der alten Extraktion den ersten Unterabschnitt als Label traegt, wird die exakte im gespeicherten Quelltext vor `This section` erhaltene Hauptueberschrift angezeigt; so erscheint `Trusts details` statt des technischen Schluessels `Trustsdetails`. Der doppelte Titel am Anfang der angezeigten Quellprosa entfaellt ohne Aenderung der gespeicherten Werte. Tabellenlinks oeffnen weiterhin Popups, Links ausserhalb der Tabellen klappen Inhalte inline auf. Beide Linkarten sind in Light und Dark blau und unterstrichen ueber `--text-link`. Acht synthetische Environment-Klickpfadtests, neun Versions-/API-Tests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.14; reine Leseprojektion und UI, keine Import-, Persistenz- oder Bestandsdatenaenderung. Risiko: Fehlt in einem historischen Import sowohl ein nativer Abschnittstitel als auch ein eindeutig identifizierbarer Quelltextanfang, bleibt dessen technisches Label sichtbar; es wird kein fachlicher Titel geraten. Phase 7 bleibt in Arbeit.

Data-Hub-Donuts waehrend des Ladens 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Die sechs Ergebnisringe zeigten beim Oeffnen der Ansicht und nach Auswahl eines Mandanten bisher voruebergehend `0 / 0 %`, weil fehlende, asynchron berechnete Timeslot-Metriken in der Praesentation zu Nullwerten umgedeutet wurden. Ein noch nicht geladener Wert erscheint jetzt als `—` mit `Loading…`; vor Mandantenauswahl steht `Select client`, bei einem Ladefehler `Unavailable`. Erst echte Quellergebnisse zeigen Zahlen und einen farbigen Bogen, einschliesslich eines belegten Nullwerts. Beim Mandantenwechsel werden die alten Metriken sofort geleert und der Ladezustand gesetzt, damit keine Zahl eines anderen Mandanten sichtbar bleibt. Ein permanenter synthetischer Klicktest prueft Auswahl, Ladephase und anschliessende Dummy-Werte (`1.833` gesamt, `477` Abweichungen, `26 %`); der Live-Browser bestaetigt die klare Ladephase und danach dieselben Werte. 26 fokussierte UI-/API-/Versionsvertragstests, Design- und Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.13 ohne Daten-, API- oder Persistenzaenderung. Phase 7 bleibt in Arbeit.

Donut-Darstellung nach neuer Bildreferenz 2026-09-24 (Phase 7, ausdrueckliche Nutzerentscheidung, umgesetzt und verifiziert): Die sichtbaren Ergebnis-Donuts in Data Hub und Client Info sowie der Overall Score tragen ihre Beschriftung nun innerhalb des Rings oberhalb des Hauptwerts. Der gemeinsame Ring ist in kompakten Kacheln groesser und erhaelt in beiden Themes einen dezenten, tokenisierten Schatten. Die ausdrueckliche Praezisierung `nur kein Verlauf` ersetzt das bisherige Schattenverbot ausschliesslich fuer Donut-Ringe: Statusboegen bleiben einfarbig, vollstaendig rund, im Uhrzeigersinn ab 12 Uhr und mit flachen Enden; kategorische Verteilungen und die Score-Semantik `/100` bleiben erhalten. Die Data-Hub-Kacheln, Client-Info-Overall-Score und Deviations wurden im freigegebenen Dummy visuell geprueft; Light und Dark sind lesbar, Light wurde wiederhergestellt. 34 fokussierte UI-/Versions-/API-Tests, Designpruefung und beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.12 ohne Daten-, API- oder Persistenzaenderung. Risiko: Sehr lange neue Donut-Titel brauchen bei 148-px-Ringen mehr als zwei Zeilen; die gegenwaertigen sechs Statusnamen passen ohne Abschneiden. Phase 7 bleibt in Arbeit.

Client-Info-Gaps-in-Data 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Die Data-Kachel zeigt `Gaps` als fuenfte anklickbare Kennzahl in der vorhandenen Ergebniszeile. Der Wert bleibt die autoritative Zahl nicht bewerteter, aber anwendbarer Records aus dem aktiven Sheet und optionalen Source-Kontext. Der Klick oeffnet Work mit genau diesen Record-IDs; damit stimmen angezeigte Zahl und geoeffnete Population auch bei gemischten Zustaenden wie `Not configured`, `Not Run`, Review und fehlender Evidenz ueberein. Der bisherige getrennte `Review gaps`-Pfad und die Assessment-Gaps-Detailkachel bleiben erhalten. Bei schmaler Breite ordnet sich die Zeile in zwei Spalten um. Im freigegebenen Dummy zeigt die neue Kennzahl 1.071 und der Live-Klick in Work `Shown 1,071`; Light und Dark sind lesbar, Light wiederhergestellt. 34 fokussierte Tests einschliesslich synthetischem Klickpfad und Versionsvertrag, Design-/Local-only-Pruefung sowie beide Produktionsbuilds bestanden. Entscheidung: rueckwaertskompatible Patchversion 2.6.11 ohne Daten- oder Persistenzaenderung. Phase 7 bleibt in Arbeit.

Client-Info-Data-und-Domain-Kacheln 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Der klickbare Deviations-Donut nutzt innerhalb der Data-Kachel den verfuegbaren Platz bis zum neuen gemeinsamen Groessentoken statt der kompakten Data-Hub-Ringbreite. Die Domain-Information-Kachel gibt dem Domainwert eine volle, typografisch hervorgehobene Zeile und verwendet fuer alle Fakten die vereinbarte 14-px-Label-/16-px-Wertrolle. `DC OS` stammt ausschliesslich aus beobachteten Domain-Controller-Zeilen; mehrere unterschiedliche DC-Systeme bleiben sichtbar, fehlende Evidenz wird als unbekannt gezeigt. Der bereitgestellte PingCastle-Bericht belegt im Dummy `Windows 2019`; die Browseransicht zeigt diesen Wert und den vergroesserten Ring in Light und Dark ohne Ueberlauf. 35 fokussierte Dashboard- und Produktversionstests, Design-/Sicherheitspruefung sowie beide Produktionsbuilds bestehen. Entscheidung: rueckwaertskompatible Patchversion 2.6.10; keine Schema- oder Persistenzaenderung. Risiko: Die kompakte DC-OS-Zeile kann bei vielen verschiedenen DC-Versionen mehrzeilig werden; Originalwerte bleiben in Environment Detail vollstaendig erhalten. Phase 7 bleibt in Arbeit.

PingCastle-Umweltdetails 2026-09-24 (Phase 7/13A, Nutzerpraezisierung, umgesetzt und verifiziert): Die vollstaendige native HTML-Struktur belegt drei verschiedene Interaktionen. Grundtabellen stehen beim Oeffnen der Kategorie direkt im Abschnitt; interne Links in Tabellenzellen zeigen die exakt adressierte Modaltabelle mit ihrem nativen Titel; Links ausserhalb einer Tabelle klappen ihre adressierten Tabellen oder Informationen unter den Grundtabellen auf. Dies gilt auch fuer denselben Collapse-Zielabschnitt mit einem Zahlenlink innerhalb und einem beschreibenden Link ausserhalb der Tabelle: Popup beziehungsweise verschachtelter Inline-Abschnitt folgen dem jeweiligen Ausloeser. Der PingCastle-Extractor speichert dafuer Ziel-ID, Darstellungsart und Zellkoordinaten als strukturelle Provenienz im vorhandenen Reportabschnitts-JSON. Reine Graph-Popups ohne Quelltabelle zeigen ihre statische Information und kennzeichnen den nur im Originalbericht verfuegbaren interaktiven Graphen. Andere Scanner und aeltere importierte Berichte behalten ihren bisherigen Tabellenzugriff. Die vorangegangene pauschale Popup-Entscheidung von 2.6.4 ist fuer neu importierte PingCastle-Berichte durch diese ausdrueckliche Nutzerpraezisierung ersetzt. Der bereitgestellte native Bericht wurde read-only geprueft: Admin Groups enthaelt eine Grundtabelle mit vier belegten Zellverweisen, vier Modaltabellen und vier ausserhalb liegende Collapse-Verweise; Control Paths enthaelt 26 adressierte Graph-Popups. Der bytegleiche Bericht wurde nach verifizierten kanonischen PostgreSQL-Dumps sicher im freigegebenen Dummy reimportiert (letzter Scanlauf ersetzt, Reviewtransfer 0/0); im finalen API-Snapshot sind alle Zellziele aufloesbar. Live-Klickpfade zeigen Grundtabelle, richtig benanntes Enterprise-Administrators-Popup, nachgeladene All-users-Tabelle und das Graph-Informationspopup. 27 fokussierte Tests, Local-only-/Designpruefung und beide Produktionsbuilds bestanden. Gesamtsuite vor der letzten Unterabschnitt-Ergaenzung: 1.472 bestanden, 13 optionale Skips und dieselben fuenf bekannten fachfremden Fehler. Entscheidung: Rueckwaertskompatible Patchversion 2.6.9 ohne Schemaaenderung; andere vorhandene gespeicherte Inhalte werden nicht still umgedeutet. Risiko: Nicht referenzierte native Modaltabellen bleiben verborgen; sie besitzen in der Quelle keinen belegten Oeffner.

Sidebar-Pfeil zurueckgesetzt 2026-09-24 (Phase 7, ausdrueckliche Nutzerkorrektur, umgesetzt und verifiziert): Die juengste Nutzerentscheidung ersetzt die Header-Position aus 2.6.5/2.6.7. Der Einklapppfeil steht wieder unten in der Sidebar links neben den Theme-Schaltern; im eingeklappten Zustand erscheint der Ausklapppfeil wieder am linken Rand der Arbeitsflaeche. Beide Pfeile bleiben ohne sichtbaren Einzelrahmen oder eigene Flaeche, entsprechend der anschliessenden 2.6.7-Stilkorrektur; Tastaturfokus bleibt blau. Der synthetische Work-Klickpfad prueft beide Positionen, beide Richtungen und das Fehlen eines Header-Pfeils. Data Hub wurde in Light und Dark sowie mit beiden Klapprichtungen live geprueft; Light und ausgeklappte Sidebar wurden wiederhergestellt. 12 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Designcheck und beide Produktionsbuilds bestanden. Entscheidung: Rueckwaertskompatible Positionskorrektur als Patchversion 2.6.8, ohne Daten- oder Persistenzaenderung. Phase 7 bleibt in Arbeit.

Header-Pfeil ohne Umrandung 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Der globale Sidebar-Umschalter im Header zeigt nur noch das Dreieck; sichtbarer Rahmen, Buttonflaeche und Hoverflaeche entfallen. Die blaue Fokusmarkierung bei Tastaturbedienung, Beschriftung und Ein-/Ausklappfunktion bleiben erhalten. Data Hub wurde in Light und Dark sowie mit beiden Klapprichtungen im freigegebenen Dummy geprueft; Light und der ausgeklappte Zustand wurden wiederhergestellt. 12 fokussierte Tests einschliesslich Sidebar-Interaktion und UI-/API-Versionsvertrag, Designcheck und beide Produktionsbuilds bestanden. Entscheidung: Rueckwaertskompatible visuelle Korrektur als Patchversion 2.6.7. Keine Daten- oder Persistenzaenderung; Phase 7 bleibt in Arbeit.

Work-Purple-Knight-Ergebnisverweis 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Ein technischer `Security_Assessment_Report_..._(SI...)`-Verweis aus einem `Result`-Feld erschien als Outcome in der Record-Liste und im Finding-Kopf. Die gemeinsame Statusauswahl ueberspringt diesen eindeutig geformten Verweis jetzt und verwendet einen vorhandenen tatsaechlichen Status wie `IOE Found`; der Originalwert bleibt fuer Results-Verknuepfung und Provenienz erhalten. Die Korrektur gilt auch bei gemischten Projektblaettern, deren Werkzeugkontext generisch ist. Ein synthetischer Karten-/Reader-Test mit beiden `Result`-Werten sichert die zwei Nutzerstellen und den erhaltenen Result-Verweis ab. Im freigegebenen Dummy zeigen Liste und Reader fuer SI000055 `IOE Found` statt des langen Verweises. 41 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Designcheck und beide Produktionsbuilds bestanden. Entscheidung: Rueckwaertskompatible Anzeigekorrektur als Patchversion 2.6.6; keine Import-, Daten- oder Persistenzaenderung. Risiko: Andere bisher unbekannte technische Verweisformen benoetigen eine eigene belegte Regel, falls sie auftreten. Phase 7 bleibt in Arbeit.

Sidebar-Umschalter im Header 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Der globale Pfeil zum Ein- und Ausklappen der Navigation steht in Work unmittelbar links von `Shown` und in den anderen Ansichten vor dem Seitentitel. Der bisherige Pfeil beim Theme-Schalter und der separate, links am Fensterrand eingeblendete Ausklapppfeil entfallen. Ein einziger beschrifteter Schalter bleibt in beiden Zustaenden an derselben Header-Position; Filter und Navigation bleiben unveraendert. Ein synthetischer Work-Klicktest prueft Reihenfolge, beide Richtungen und das Fehlen der alten Position. Im freigegebenen Dummy wurden Ein-/Ausklappen und die Darstellung in Light und Dark geprueft; Light wurde wiederhergestellt. 12 fokussierte Tests, Designcheck und beide Produktionsbuilds bestanden; Backend-Health und UI zeigen 2.6.5. Entscheidung: Rueckwaertskompatible UI-Korrektur als Patchversion 2.6.5. Keine Daten- oder Persistenzaenderung. Restrisiko: Bei sehr schmaler Bildschirmbreite bleibt die Work-Werkzeugleiste wie zuvor horizontal scrollbar. Phase 7 bleibt in Arbeit.

Environment-Detail-Originaltabellen 2026-09-24 (Phase 7, Nutzerreferenz fuer Tabellenfenster, umgesetzt und verifiziert): Jede im Results-Fenster aufgefuehrte Originaltabelle hat nun einen eigenen `Open table`-Eintrag statt einer sofort eingebetteten breiten Tabelle. Ein fokussiertes, ASSESSOR-gestaltetes Tabellenfenster zeigt die vollstaendigen nativen Spalten und Zeilen mit horizontalem Scrollen, Suche, 10/25/100 Zeilen pro Seite, Seitennavigation und den exakt dieser Quelltabelle zugeordneten Beobachtungen. Berichtsabschnitt und native Teilueberschrift stehen unmittelbar am Eintrag und im Fenstertitel; bei gleichnamigen Tabellen desselben Abschnitts unterscheidet eine Position wie `Table 4 of 5` die Quelle ohne unbelegte fachliche Zuordnung. `Escape` schliesst nur das Tabellenfenster, laesst das uebergeordnete Results-Fenster offen und stellt den Fokus auf den Oeffner zurueck. Entscheidung: Die vom Nutzer gezeigte PingCastle-Interaktion wird als Muster uebernommen, Farben und Geometrie folgen den freigegebenen ASSESSOR-Ansichten. 24 fokussierte Tests einschliesslich echter Results-Klickpfade und UI-/API-Versionsvertrag, Local-only-/Designcheck sowie beide Produktionsbuilds bestanden. Im freigegebenen Dummy wurden Inventory/Admin Groups, die breite 13-Spalten-Tabelle, Suche/Nulltreffer, Escape und Light/Dark visuell geprueft; Light wurde wiederhergestellt. Rueckwaertskompatible UI-Korrektur als Patchversion 2.6.4; keine Import-, Persistenz- oder Bestandsdatenaenderung. Risiko: Die vorhandene Quelle belegt fuer wiederholte `Admin groups detail`-Tabellen keinen individuellen Gruppennamen wie `Enterprise Administrators`; ein solcher Titel wird nicht aus Tabellenreihenfolge oder Mitgliederzahl geraten. Die Nummerierung unterscheidet sie nur innerhalb ihres Abschnitts, ohne eine Gruppenbeziehung zu behaupten. Phase 7 bleibt in Arbeit.

Work-Sidebar-Sicherheitsdomaenen 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): Die Domaenenliste wirkte durch eigene kleine Kachelflaechen, kompakte Informationsschrift und einen bis zum Sidebar-Ende gestreckten Rack wie ein fremdes Menue. Sie verwendet jetzt die vorhandene Sidebar-Navigationssprache: transparente, direkt unter der Navigation gruppierte Zeilen mit ruhigem Hover, einer dezenten Trennlinie und der gemeinsamen gelben Auswahlmarkierung. Domaenennamen und Trefferzahlen nutzen die vereinbarte 14px-Informationsrolle, lange Namen brechen nur an Wortgrenzen um; die Liste streckt sich nicht mehr ueber leeren Raum. Filterkatalog, Reihenfolge, Trefferzaehlung und Auswahlpfad bleiben erhalten. Im freigegebenen Dummy wurde Work mit 58 CIS-CAT-Abweichungen unter `System Hardening` in Light und Dark visuell geprueft; der Wechsel zu `Identity & Account Hygiene` zeigte 120 Treffer und die Rueckkehr 58. Light und der Ausgangsfilter wurden wiederhergestellt. 26 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Designcheck und beide Produktionsbuilds bestanden. Entscheidung: Rueckwaertskompatible reine UI-Korrektur als Patchversion 2.6.3. Kein Import-, Persistenz-, Klassifikations- oder Bestandsdateneingriff; Phase 7 bleibt in Arbeit. Restrisiko: Bei sehr niedriger Fensterhoehe scrollt die Liste innerhalb der Sidebar.

Security-Domain-Zuordnung im Dummy 2026-09-24 (Phase 7, Nutzerkorrektur, umgesetzt und verifiziert): 13 fehlgeschlagene CIS-CAT-Pro-Windows-Pruefungen zu Sperrbildschirm, SMB v1, IP-Quellrouting, ICMP-Redirects, KeepAlive, NetBIOS-Namensfreigabe, Router Discovery, TCP-Wiederholungen und Kernel-DMA-Schutz erschienen unter `Unclassified`, weil die gemeinsame Client-Info-/Work-Domaenenregel ihre konkreten Prueftitel nicht erkannte. Der gemeinsame Katalog ordnet diese eindeutig benannten Themen jetzt `System Hardening` zu; Status, Originalwerte und Provenienz bleiben unveraendert. Ein synthetischer Work-Facetten-/Filtertest reproduzierte die 13 falschen Zuordnungen vor der Korrektur und prueft ihre Zuordnung sowie einen weiterhin unklassifizierten Gegenfall; ein Komponenten-Klickpfad prueft die tatsaechliche Umschaltung von `Unclassified` nach `System Hardening` bei erhaltenem Status- und Quellfilter. 42 fokussierte Tests einschliesslich UI-/API-Versionsvertrag, Local-only- und Designcheck sowie beide Produktionsbuilds bestanden. Im freigegebenen Dummy zeigt Work bei `Deviation` nun `Unclassified · 0`; mit `Source: Scan = CIS-CAT Pro` stehen 58 fehlgeschlagene Pruefungen unter `System Hardening`, einschliesslich der betroffenen Titel. Entscheidung: Rueckwaertskompatible Klassifikationskorrektur als Patchversion 2.6.2. Restrisiko: Andere fachlich unbekannte Prueftitel bleiben zu Recht `Unclassified`, bis eindeutige Evidenz fuer eine Zuordnung vorliegt. Keine Import-, Persistenz-, Score- oder Bestandsdatenaenderung; Phase 7 bleibt in Arbeit.

Environment-Detail-Results-Werkzeugangaben 2026-09-24 (Phase 7, Nutzerpraezisierung zur laufenden 2.6.1-Korrektur, umgesetzt und verifiziert): Die sichtbare Herkunftskette der Originaltabellen nennt nur Berichtsabschnitt und native Teilueberschrift; Abschnittstitel und Einzelbeobachtungstabellen wiederholen den Werkzeugnamen nicht mehr. Die Quellwerkzeugidentitaet mit Version bleibt ausschliesslich im aufklappbaren `Show source details` als Provenienz erhalten, nicht als Tabellenzelle. Native Quellprosa bleibt unveraendert. Der fachliche Tabelleninhalt und die exakte Zuordnung von Beobachtungen bleiben unveraendert. 10 fokussierte Environment-Tests, beide Produktionsbuilds und Designcheck bestanden; die Inventory-Results-Ansicht im freigegebenen Dummy zeigt im Light Mode Abschnitt und Teilueberschrift ohne Werkzeugangabe, auch die geoeffnete Beobachtungstabelle besitzt keine Werkzeugspalte. Die Darstellung verwendet unveraenderte Theme-Tokens; Dark wurde in der zugehoerigen 2.6.1-Abnahme geprueft. Dieselbe noch uncommittete 2.6.1-UI-Korrektur wurde damit nach Nutzerfeedback verfeinert; kein weiterer Versionssprung oder Phasenabschluss. Keine Import-, Persistenz- oder Bestandsdatenaenderung.

Environment-Detail-Results-Herkunftskette 2026-09-24 (Phase 7 mit erhaltener Phase-13C-Quellprovenienz, Nutzerkorrektur, umgesetzt und verifiziert): Jede Originaltabelle zeigt jetzt unmittelbar Werkzeug, Berichtsabschnitt und, soweit eindeutig belegt, ihre native Teilueberschrift. Der Titel kennzeichnet sie ausdruecklich als Originaltabelle. Beobachtungen werden nur bei exakter Uebereinstimmung von Scanlauf, Importdatei, Abschnitt und eindeutigem Quelltabellenindex bei dieser Tabelle angezeigt. Die technische Beobachtungstabelle bleibt fuer Lesbarkeit zunaechst eingeklappt; abschnittsbezogene oder in der aktuellen Ansicht nicht eindeutig zuordenbare Beobachtungen bleiben separat und mit erklaerter Zuordnungsgrenze erreichbar. Keine Beobachtung wird verworfen oder mehrfach zugeordnet. Technische Abschnittsmetadaten sind ueber `Show source details` erreichbar. Entscheidung: Die Leseprojektion nutzt ausschliesslich erhaltene Provenienz und erfindet keine fachliche Zuordnung. 20 fokussierte Klickpfad-, Provenienz- und Produktversionstests, beide Produktionsbuilds, Local-only- und Designcheck bestanden; App HTTP 200 und PostgreSQL-Backend melden 2.6.1. Die geoeffnete Inventory-Results-Ansicht im freigegebenen Dummy wurde in Light und Dark auf Herkunftskette, eigenstaendige Originaltabellen, geschlossene Detailbeobachtungen und Lesbarkeit geprueft; Light wurde wiederhergestellt. Risiko: Generische oder maschinelle Quellbezeichnungen bleiben als solche sichtbar, wenn der Import keinen eindeutig belegten nativen Titel liefert. Phase 7 bleibt in Arbeit. Rueckwaertskompatible UI-Korrektur als Patchversion 2.6.1; keine Import-, Persistenz-, Score-, Disclosure- oder Bestandsdatenaenderung.

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]-<RID>`, bekannte Domainrollen zu `[DOMAIN]\\<Rolle>` 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 <Host>`, 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  
Zielzustand: interne Mehrbenutzer-Webanwendung mit Backend und PostgreSQL

## 1. Zweck

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

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

## 2. Produktziel

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

Vorrangige Quellformate:

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

Vorrangige Pilotquellen:

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

## 3. Leitprinzipien

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

## 4. Zielarchitektur

```text
Browser der Mitarbeitenden
        ↓ HTTPS
ASSESSOR-Backend im Unternehmensnetz
  ├─ Authentifizierung und Autorisierung
  ├─ Dateiannahme und Importsteuerung
  ├─ Parsing und Strukturanalyse
  ├─ Toolerkennung und semantisches Mapping
  ├─ Normalisierung und Vergleich
  ├─ Review- und Workflowlogik
  └─ Export und Audit
        ↓
PostgreSQL
        ↓
optionaler geschützter Originaldateispeicher
```

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

**Zielbild fuer autonome Client-Datenbanken (Nutzerentscheidung 2026-09-26; geplant, nicht umgesetzt):** Im spaeteren Mehrclientbetrieb erhaelt jeder Client eine eigene fachliche PostgreSQL-Datenbank. Das Backend loest den autorisierten Client auf und verwendet ausschliesslich dessen Datenbank und privaten Artefaktspeicher fuer Stammdaten, Timeslots, Scan- und GPO-Quellen, Analysen, Bewertungen, Reviews und Historie. Die Browsergrenze bleibt die Backend-API. Ein zentraler, versionierter Referenzkatalog verwaltet unveraenderliche offizielle MITRE-ATT&CK-Staende und Microsoft Security Baselines; er enthaelt keine Client-Ergebnisse. Die clientgebundene Auswahl und gegebenenfalls clientindividuelle Baselinepakete gehoeren zum Client. Jede Auswertung dokumentiert die exakt verwendeten Referenzversionen und ihren Hash; ein zentrales Update veraendert weder die Auswahl noch historische Ergebnisse stillschweigend. Fuer eine wirklich autarke Sicherung/Wiederherstellung enthaelt das Client-Backup auch die exakten verwendeten Referenzbytes oder unveraenderliche, mitgesicherte Artefakte und alle clientgebundenen Originale. Ein Restore muss ohne Zugriff auf den zentralen Katalog lesbare Historie und reproduzierbare Auswertungsgrundlagen liefern. Allgemeine Update-/Downloadaktionen bleiben in der Referenzverwaltung; der Client-Bereich zeigt und verwaltet seine verwendeten Versionen. Das ist eine Zielentscheidung fuer die spaetere Mandanten-/Betriebsarchitektur (Phase 14 mit Vorarbeiten an Repository-, Referenz- und Artefaktgrenzen aus Phasen 9-11/13B), keine Aussage ueber den aktuellen lokalen Speicher. Die kanonische lokale PostgreSQL-Datenbank und alle bestehenden Daten bleiben bis zu einer gesondert geplanten, gesicherten Migration unveraendert.

## 5. Statusdefinitionen

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

## 6. Phasenübersicht

| Phase | Inhalt | Status |
|---|---|---|
| 0 | Plan und Arbeitsregeln etablieren | abgeschlossen |
| 1 | Bestehenden Funktionsumfang und Testkorpus absichern | abgeschlossen |
| 2 | Kanonisches Finding- und Assessment-Modell definieren | abgeschlossen |
| 3 | Universelles Import-Zwischenmodell stabilisieren | abgeschlossen |
| 4 | Importengine vollständig von UI und Plattform trennen | abgeschlossen |
| 5 | Erkennungs- und Mapping-Engine mit Konfidenzen | abgeschlossen |
| 6 | Deklarative Toolprofile und generischer Fallback | abgeschlossen |
| 7 | Automatische Filter- und Darstellungslogik | abgeschlossen |
| 8 | Vergleichsengine für Assessment-Läufe | abgeschlossen |
| 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 |
| 12 | Mehrdatei-Importworkflow und Importdiagnostik | abgeschlossen |
| 13 | Sicherheits- und Belastbarkeitshärtung | abgeschlossen |
| 13A | Ingestion 2.0: Formatadapter, Source Extractors und Mappingprofile konsolidieren | abgeschlossen |
| 13B | Deterministische GPO-Backup- und Microsoft-Baseline-Analyse | in Arbeit |
| 13C | Scanner Context und Environment Inventory | in Arbeit |
| 13D | Referenzerkennung und katalogbasierte Einordnung (ATT&CK/D3FEND erster Umfang) | in Arbeit |
| 13E | Kontext-Engine und abschaltbarer Kontext-Layer (GPO-Pilot, Ausgabe auch ueber Phase-7-Reports); Engine und API umgesetzt, UI-Layer offen | in Arbeit |
| 13F | Regulatorische Kontrollsuche und RAG-Grundlage mit Qdrant | in Arbeit |
| 14 | Mehrbenutzer- und Firmenbetrieb | offen |

## 7. Phasen im Detail

### Phase 0 – Plan und Arbeitsregeln etablieren

Status: abgeschlossen

Ergebnis:

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

Abnahmekriterien:

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

### Phase 1 – Bestehenden Funktionsumfang absichern

Status: abgeschlossen

Ziele:

- Den aktuellen lokalen Funktionsumfang als belastbare Ausgangsbasis festhalten.
- Regressionen während der Architekturarbeiten früh erkennen.

Arbeitspakete:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 2 – Kanonisches Finding- und Assessment-Modell

Status: abgeschlossen

Ziele:

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

Vorgesehene Kernobjekte:

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

Vorgesehene Finding-Felder:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 3 – Universelles Import-Zwischenmodell

Status: abgeschlossen

Ziele:

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

Vorgesehene Inhalte:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 4 – Plattformneutrale Importengine

Status: abgeschlossen

Ziele:

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

Zu kapselnde Bereiche:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 5 – Erkennungs- und Mapping-Engine

Status: abgeschlossen

Ziele:

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

Erkennungssignale:

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

Konfidenzklassen:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 6 – Deklarative Toolprofile

Status: abgeschlossen

Ziele:

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

Reihenfolge:

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

Ein Profil beschreibt:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

- Neue Profile benötigen keine Änderungen an React-Komponenten oder Formatparsern.
- Generischer Import bleibt bei nicht erkannten Quellen funktionsfähig.
- Profilversionen werden im Importergebnis festgehalten.

### Phase 7 – Automatische Filter und Darstellung

Status: abgeschlossen

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.
- Werkzeugübergreifende und quellenspezifische Filter kombinieren.

Universelle Filter:

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

Dynamische Filter:

- Facetten für Felder mit wenigen wiederkehrenden Werten
- Bereichsfilter für Zahlen und Daten
- Volltextsuche für Freitext
- zusätzliche werkzeugspezifische Attribute

Verifizierter Abschlussstand vom 2026-07-17:

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

Verifizierte Darstellungsnachschärfung vom 2026-08-02:

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

Verifizierte Graph-Darstellungsnachschaerfung vom 2026-08-22:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifizierte Datahub-Darstellungsnachschaerfung vom 2026-08-22:

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

Verifizierter Bearbeitungsschutz fuer Mandantenstammdaten vom 2026-08-22:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abnahmekriterien:

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

#### Report Engine als eigenstaendiger Nur-Lese-Baustein (entschieden 2026-09-30)

Status: in Arbeit (Verschiebung, v0.1 und v0.2 am 2026-09-30 umgesetzt; ein v0.1-Kriterium ist nur teilweise verifiziert, die Kontext-Eingabe aus Phase 13E ist offen).

Ziel: Technischer und Management Report ohne Internet und ohne LLM, erzeugt von einer eigenstaendigen Report Engine im Assessor. Sie nutzt nur benoetigte, gespeicherte Assessor-Daten und veraendert die Assessor-Logik nicht. Machbarkeitspruefung 2026-09-30 (nur gelesen): Report Model (`ReportProjection` 1.1.0), Korrelation (1.0.0), Assembler, beide Renderer und der API-Endpunkt `report-projection` existieren bereits und lesen ausschliesslich. Es fehlen ein eingefrorener, gespeicherter Stand, eine technisch erzwungene Nur-Lese-Grenze und ein konsistenter Lesezeitpunkt.

Verbindliche Nutzerentscheidungen 2026-09-30:
- Ablage im Code: Die bestehenden Report-Bausteine werden ohne Logikaenderung nach `src/reporting/` verschoben. Betroffen sind Projektion, Korrelation, Assembler, `client-report-projection` und beide Renderer. Das geschieht als eigener Schritt vor v0.1, und die Tests bleiben vor und nach der Verschiebung identisch gruen. Security-Domain-Katalog, Scoring und Review-Hydration bleiben Assessor-Bausteine und werden nur importiert, damit Report, Client Info und Work dieselben Zahlen zeigen. Ein Architekturtest erzwingt die Grenze: Ausserhalb von `src/reporting/` importieren nur die Report-Aktionen der UI und die Server-Route aus der Engine, und die Engine erreicht keine schreibenden Repository-Methoden.
- Eingefrorener Stand: Jeder Reportlauf wird serverseitig in einem eigenen, danach unveraenderlichen Archivordner gespeichert. Er enthaelt `projection.json`, beide HTML-Dateien und ein Manifest mit Datei-Hashes, Projektions-, Korrelations- und Renderer-Version, Repository-Revision, Scope und Zeitpunkt. Der Pfad ist ueber `ASSESSOR_REPORT_ARCHIVE_DIR` einstellbar; der Standard liegt im lokalen Anwendungsdatenordner, nie im Repository oder in OneDrive. Das Loeschen eines Clients loescht auch sein Archiv. Der HTML-Download bleibt wie heute. Die Datenbank wird nicht beruehrt; `projection.json` und Manifest sind intern und werden nie mit Report A ausgeliefert.
- Grenzen: nur der gemeinsame Security-Domain-Katalog; Severity nur je Quelle und nie als Summe ueber Scanner; Review-Status nur als `Selbstauskunft, nicht verifiziert` und nicht in Report A; Szenarien und Zusammenhaenge ausschliesslich aus der Kontext-Engine (Phase 13E). `docs/REPORT_STRATEGY.md` bleibt fuer Inhalte bindend.

Umsetzungsfolge:
1. Verschiebung nach `src/reporting/` und Architekturtest.
2. v0.1: Nur-Lese-Port-Typ, eigener Datenbank-Pool mit `default_transaction_read_only=on` nur fuer die Report Engine, Vergleich der Repository-Revision vor und nach dem Lesen mit Wiederholung, danach das Serverarchiv.
3. v0.2: deterministische Textbausteine ueber der Projektion und ID-Listen je Aggregat fuer die Beleg-Kette (Projektion 1.2.0).
4. Danach: Kontextergebnisse aus Phase 13E als Eingabe.

Abnahme v0.1:
- [x] Verschiebung ohne Logikaenderung; Tests vor und nach identisch; Architekturtest gruen. Umgesetzt und verifiziert am 2026-09-30, siehe Aenderungsprotokoll.
- [ ] Schreibversuch ueber den Report-Pool wird von PostgreSQL abgelehnt (Test); `PostgresAssessorRepository.create()` liest auf diesem Pool nur. Teilweise verifiziert 2026-09-30: Der Report-Leser nutzt `openReadOnly` statt `create()`, weil `create()` einen Result-DB-Neuaufbau (Schreibvorgang) anstoesst. Dass `openReadOnly` keinen Neuaufbau anstoesst, nur SHOW/SELECT ausfuehrt und eine beschreibbare Sitzung verweigert, ist synthetisch getestet. Gegen die kanonische Datenbank wurde inhaltsfrei bestaetigt: Die Sitzung ist schreibgeschuetzt, die Revision blieb unveraendert und keine Schreibmethode ist erreichbar. Der Test auf eine tatsaechlich abgelehnte Schreibanweisung existiert, laeuft aber nur mit `ASSESSOR_TEST_DATABASE_URL` und wurde mangels Testdatenbank nicht ausgefuehrt; gegen die kanonische Datenbank wurde bewusst kein Schreibversuch unternommen.
- [x] Revisionsaenderung waehrend des Lesens fuehrt zu Wiederholung oder klarem Fehler (synthetischer Test). HTTP 409 `report_state_changed`.
- [x] Erneutes Rendern aus dem archivierten `projection.json` ergibt byte-identisches HTML; die Manifest-Hashes stimmen, und eine veraenderte Datei wird beim Lesen erkannt.
- [x] Report A enthaelt keine technischen Kennungen (Leckagetests gruen). Das Archiv liegt ausserhalb von Repository, Anwendungsordner und OneDrive (Startpruefung getestet). Das Loeschen eines Clients entfernt sein Archiv (HTTP-Test).
- [x] `npm test`: 1662 bestanden, 15 uebersprungen; die 7 bestehenden, unabhaengigen Fehler in 6 Dateien sind unveraendert. Beide Produktionsbuilds bestanden; Plan und Produktversion 2.10.0 nachgefuehrt.

### Phase 8 – Vergleichsengine

Status: abgeschlossen

Ziele:

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

Matching-Reihenfolge:

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

Ergebnisse:

- neu
- weiterhin vorhanden
- behoben
- wieder aufgetreten
- Schweregrad geändert
- Status oder Evidenz geändert
- möglicherweise identisch
- nicht vergleichbar

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

#### 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

Ziele:

- Fachlogik von konkreter Datenbank und Transporttechnologie trennen.

Benötigte Operationen:

- Projekte und Assessments verwalten
- Importe starten, abschließen und zurückrollen
- Findings und Vorkommen speichern und abfragen
- Reviews aktualisieren
- Profile und bestätigte Mappings verwalten
- Vergleiche laden und speichern
- Daten exportieren und kontrolliert löschen

Verifizierter Abschlussstand vom 2026-07-17:

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

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.
- Fachlogik hängt weder von SQLite noch von PostgreSQL ab.
- Transaktionsgrenzen eines Imports sind definiert.

### Phase 10 – Lokales Backend

Status: abgeschlossen

Ziele:

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

Lokaler Aufbau:

```text
Browser
  ↓ http://localhost
ASSESSOR-Backend
  ↓
lokale Datenbank
```

Backend-Verantwortung:

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

Verifizierter Abschlussstand vom 2026-07-17:

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

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

Abnahmekriterien:

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

### Phase 11 – PostgreSQL

Status: abgeschlossen

Ziele:

- Dauerhafte, mehrbenutzerfähige Speicherung einführen.

Anforderungen:

- versionierte Datenbankmigrationen
- Fremdschlüssel und Integritätsregeln
- Transaktionen pro Import
- geeignete Indizes
- Volltextsuche
- Backup- und Restore-Verfahren
- nachvollziehbare Löschung

Verifizierter Abschlussstand vom 2026-07-17:

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

Abnahmekriterien:

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

### Phase 12 – Mehrdatei-Importworkflow

Status: abgeschlossen

Ziele:

- Mehrere heterogene Dateien gemeinsam in ein Assessment laden.

Ablauf:

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

### Phase 13 – Sicherheit und Belastbarkeit

Status: abgeschlossen (2026-07-17)

Ziele:

- Nicht vertrauenswürdige Dateien und große Datenmengen kontrolliert verarbeiten.

Mindestmaßnahmen:

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

Abnahmekriterien:

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

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

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

### Phase 13A – Ingestion 2.0 und Profilarchitektur

Status: abgeschlossen

Ziele:

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

Verbindliche Pipeline:

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

Architekturgrenzen:

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

Umsetzungsschritte:

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

Verifizierter Zwischenstand vom 2026-07-20:

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

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

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

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

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

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

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

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

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

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

Phase 13A ist damit vollständig verifiziert und abgeschlossen.

Persistenzprinzipien:

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

Abnahmekriterien:

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

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

Status: in Arbeit

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.
- Vorhandene Werte, explizite Abwesenheit, leere Bereiche, Zugriffsfehler, Lizenzgrenzen und Parserluecken fachlich unterscheidbar machen.
- Die Informationen in lokaler und PostgreSQL-Persistenz, Export, API, Result-DB-naher Snapshotabfrage und Dashboard bereitstellen.

Umgesetzter Stand vom 2026-08-23:

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

Abnahmekriterien:

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

### Phase 13B – GPO-Backup- und Microsoft-Baseline-Analyse

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 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:

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

Verbindliche Policy-Pipeline:

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

Fachliche Regeln:

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

Unterstützter erster Artefaktscope:

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

Sicherheitsanforderungen:

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

Persistenz und Versionierung:

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

Umsetzungsschritte:

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

Verifizierter Zwischenstand vom 2026-07-21:

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

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

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

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

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

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

Abnahmekriterien:

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

#### Spaeteres Arbeitspaket: automatische Security-Baseline-Updates

Nutzerentscheidung 2026-10-02: fuer spaeter vormerken, jetzt nicht implementieren. Zuordnung: Phase 13B, mit Backend-Betrieb aus Phase 10 und Kataloganzeige aus Phase 7. Status: geplant / zurueckgestellt; keine automatische Pruefung, kein Download und kein Zeitplan aktiviert.

- Ziel: Das Backend kann regelmaessig nach neuen Security-Baseline-Versionen suchen, sie herunterladen und ueber den bestehenden validierten Importweg als eigene Version aufnehmen. Der manuelle ZIP-Upload bleibt verfuegbar.
- Oberste Praemisse: Datenqualitaet vor Geschwindigkeit. Vor Uebernahme sind Herkunft aus festgelegten offiziellen Quellen, eindeutige Version, unterstuetztes Format und Vollstaendigkeit zu pruefen. Originalartefakt, Herkunft, Pruefsumme und Validierungsergebnis muessen nachvollziehbar erhalten bleiben.
- Fehler, unvollstaendige Pakete, unklare Versionen und nicht erreichbare Quellen duerfen die letzte gueltige Baseline nicht ersetzen. Gleiche Versionen duerfen keine doppelten Katalogeintraege erzeugen; neue Versionen bleiben getrennt von vorhandenen Releases.
- Bestehende Auswertungen und ihre Baseline-Zuordnung werden durch ein Update nicht automatisch ueberschrieben oder neu bewertet. Eine erneute Auswertung bleibt ein gesonderter Vorgang ueber den bestehenden kontrollierten Pfad.
- Vor Umsetzung klaeren: unterstuetzte Hersteller/Produkte und offizielle Downloadquellen, Pruefintervall, Proxy-/Offline-Betrieb sowie sichtbare Update- und Fehlerhinweise. Quellenwechsel und Formatdrift sind Risiken; die Update-Pruefung darf keine Mandantendaten an externe Dienste uebertragen.
- Spaetere Abnahme mit synthetischen Quellen/Paketen: gueltige neue Version, identische Version, falsche Herkunft, unklare Version, unvollstaendiges oder ungueltiges Paket und Netzwerkfehler; jeweils unveraenderte vorhandene Baselines und historische Auswertungen nachweisen. Umsetzung erfordert eine neue Freigabe der tatsaechlich betroffenen Core-Bereiche; diese Planaufnahme ist keine Implementierungsfreigabe.

### Phase 13D - Referenzerkennung und katalogbasierte Einordnung

2026-09-26 - Phase 13D / gemischte Work-Projektion (2.8.5, umgesetzt und verifiziert): Beim Anhaengen von GPO-Ergebnissen an All Records wird referenceRecognition jetzt vom jeweiligen Scannerbefund uebernommen. Zuvor blieben die Referenzlaeufe gespeichert, gingen aber beim Neuaufbau der Reader-Projektion verloren. Die Uebernahme bewahrt Referenzen, Quellenherkunft, Erkennerversion, Lauf und Katalogversion/-hash einschliesslich bewusst leerer Erkennung; GPOs und nicht indexierte Befunde erhalten keine fremden Referenzen. Synthetische Regression oeffnet Referenzdetails im echten FindingReader mit und ohne GPOs. 30 fokussierte Referenz-/GPO-/CIS-Tests und 9 UI-/API-Versionsvertragstests, beide Produktionsbuilds sowie Design-/Local-only- und Diffpruefung bestanden. Patchversion fuer rueckwaertskompatible Projektionskorrektur; keine Datenmutation und kein Reimport bzw. neuer Erkennungslauf erforderlich. Bereits geladene Workspaces muessen neu geladen werden. Phase 13D bleibt in Arbeit.

Status: in Arbeit (erster Umfang am 2026-09-26 umgesetzt und verifiziert; weitere Frameworks und Folgeetappen offen).

Ziel: gemeinsame, offline faehige Referenzerkennung aus behaltenen Originalfeldern mit unveraenderlicher Katalog- und Quellenherkunft. Erster Umfang: Enterprise ATT&CK und D3FEND; eigenstaendige Ableitung statt Finding-Identitaet oder Scoring-Eingriff. Einzelheiten und Grenzen: `docs/REFERENCE_RECOGNITION.md`.

Abnahme erster Umfang:
- [x] Frameworkweite Erkenner fuer IDs und eindeutige exakte Titel; declared/mentioned, unknown/deprecated/revoked getrennt.
- [x] Quelle mit Feld, Position, UTF-16-Offsets, Originaltext, Datei-/Input-/Kataloghash und Erkennerversion behalten.
- [x] Normale Batchimports speichern Ableitung und Kataloge atomar; bestehende Scannerlaeufe koennen pro Client explizit nachverarbeitet werden.
- [x] Append-only Referenzlaeufe und gemeinsame unveraenderliche Kataloge in PostgreSQL/Repository und Projektexport; synthetisch gegen kanonische PostgreSQL verifiziert.
- [x] Pathfinder liest gespeicherte aktive Referenzen; Reader zeigt auch historische/unbekannte Treffer und Provenienz. Keine neue automatische Finding-Korrelation.
- [x] Client-/Server-Produktionsbuilds und Produktversionsvertrag bestanden; beide Themes mit ausschliesslich synthetischen Komponenten bei normaler und 480px Readerbreite geprueft.

Entscheidungen 2026-09-26: Erkennerversion 1.0.0; gebuendelte Kataloge ATT&CK 19.2 und D3FEND 1.6.0. ATT&CK-Onlineupdate speichert den vollstaendigen Erkennungskatalog mit der Matrix, aendert aber keine frueheren Referenzlaeufe. D3FEND-Laufzeitupdate, weitere Frameworks, technische Identitaetsaufloesung und Korrelationsansicht gehoeren zu spaeteren Etappen. Eine Datenbank pro Client bleibt wie beauftragt ausschliesslich im Zielplan.

Risiken/Grenzen: Nur behaltene Felder koennen ohne Reimport erkannt werden; mehrdeutige Namen werden nicht geraten. Der historische Text `Account Monitoring` ist kein exakter Eintrag des gebuendelten D3FEND-Technikkatalogs und erzeugt deshalb keine freie Graphrelation mehr; der Originaltext bleibt sichtbar. Die manuelle Browsermatrix ist ein Matrixfallback und waehlt keine serverseitige Erkennungsversion. Sehr grosse Client-Nachverarbeitungen koennen spaeter einen persistierten Hintergrundjob benoetigen. Niedrigstufige Staging-API-Imports erhalten Referenzen ueber die explizite Nachverarbeitung. Details im Funktionsdokument.

Migration: 023 (021/022 in der kanonischen DB durch Timeslot-/Obligation-Arbeit belegt, unberuehrt). Vorheriger lokaler PostgreSQL-Backup verifiziert (Custom-Dump, TOC lesbar, SHA-256 dokumentiert in `.assessor-data/backups`; keine Kundendaten ausgegeben). Eigene synthetische Testdaten exakt geloescht.

Versionsentscheidung: neue rueckwaertskompatible Faehigkeit, Minor-Version 2.8.0, Produktversionsvertrag und beide Builds verifiziert; 2.7.0 bleibt als historischer MITRE-Update-Meilenstein dokumentiert. Keine Reimportpflicht fuer vorhandene Felder.

Nachpruefung 2026-09-26: Der Nutzer sah den Referenzbereich in einer bereits geoeffneten Clientansicht nicht. Frontend auf 5173 und Produktionsbundle auf 4173 enthielten die Funktion; nach Strg+F5 bestaetigte der Nutzer die Sichtbarkeit. Ergaenzter synthetischer Interaktionstest oeffnet den Client ueber Auswahl/Manage, prueft den Bereich unter den Stammdaten und verarbeitet per Button exakt den Client ueber alle Timeslots. Zusammen mit den zwei vorhandenen Referenz-UI-Tests bestanden (3/3). Kein Produktionscode geaendert, daher Version weiterhin 2.8.0. Bestehende Scans wurden bei dieser Pruefung nicht nachverarbeitet.

### Phase 13E - Kontext-Engine und abschaltbarer Kontext-Layer

Neueste Nutzerentscheidung 2026-10-01 / gemeinsame Engines-Steuerung (Phasen 13E und 7): Der blaue `Engines`-Button ersetzt den frueheren Context-Schalter an derselben Toolbar-Position. Das Popup zeigt Core Engine (immer aktiv, gesperrt), Context Engine und Report Engine; Standard fuer alle ist aktiv, optionale Auswahl wird lokal gespeichert. Context aus entfernt Kontextdarstellungen und den aktiven Clusterfilter und unterbindet neue Context-Anfragen. Report aus sperrt neue Report-Erzeugung in der UI. Bereits gestartete Serverlaeufe werden nicht abgebrochen; spaete UI-Ausgaben werden verworfen. Diese Entscheidung ersetzt die nachfolgend historisch dokumentierte Daueraktivierung und stellt die bedienbare Abschaltbarkeit wieder her. Die Aktivierung gehoert zum Core; Engines beziehen ihren Zustand daraus, ohne voneinander abzuhaengen. Die Freigabe fuer Presentation, Core Tests und Governance liegt vor.

Aktuelle Nutzerentscheidung 2026-10-01 (ersetzt die nachfolgenden historischen Schalter- und Plaketten-Sprungregeln): Context ist dauerhaft aktiv, ohne Toolbar-Schalter und ohne lokale An/Aus-Praeferenz. Ein Klick auf eine Context-Cluster-Plakette setzt den exakten Work-Filterwert und ersetzt eine vorige Cluster-Auswahl; andere Filter bleiben erhalten. Der Detailabschnitt bleibt pro Finding standardmaessig eingeklappt. Die Nur-Lese- und fachlichen Grenzen bleiben verbindlich. Die Core-Freigabe fuer Presentation, Core Tests und Governance wurde im Chat ausdruecklich erteilt. Die technische Funktionsfaehigkeit des Readers ohne Engine-Anbindung bleibt separat abgesichert.

Nutzerkorrektur 2026-10-01 (umgesetzt und verifiziert): `Context` im Finding Reader startet eingeklappt, auch beim Finding-Wechsel und nach erneutem Einschalten des Layers. Native Disclosure per Maus/Tastatur; Cluster-Plaketten oeffnen den Abschnitt vor dem Sprung. Der globale Layer-Schalter bleibt eine separate Funktion.

Status: in Arbeit (Engine, API, Finding Reader, Work-Facette und Pathfinder am 2026-09-30 umgesetzt und per Test verifiziert; die Sichtpruefung des Pathfinders in beiden Themes und die Stufe Client Info sind offen).

Ziel: Der Assessor erhaelt eine zweite, abschaltbare Betrachtungsweise fuer Gesamtzusammenhaenge. Die Kontext-Engine laeuft parallel zur bestehenden technischen Pipeline, liest deren gespeicherte Ergebnisse ausschliesslich lesend und leitet daraus belegte Zusammenhaenge ab. Die technische Betrachtung bleibt massgeblich und wird weder veraendert noch in Frage gestellt. Dieselben Kontextergebnisse speisen die Report Engine (Phase 7).

Ausgangslage (Pruefung 2026-09-30, nur gelesen): Observation, technische Policy-Identitaet, Snapshotaggregation, Baseline-Evaluation, `Not configured` sowie Conflict-/Duplicate-Diagnosen existieren bereits in Phase 13B. Deshalb entsteht kein `CANONICAL_MODEL v2` und kein Umbau dieser Schichten. Neu sind nur Semantic Catalog, Declared Fact, Bedingungen, Relationship-Katalog, Cluster und Remediation-Hebel. Die ungenutzten Evaluator-Anknuepfungspunkte `PolicyRiskRule`, `PolicyDependencyRule` und `stronger/weaker` werden fuer den Kontext nicht befuellt, weil sie Urteile und Severity des Assessors veraendern wuerden.

Verbindliche Nutzerentscheidungen 2026-09-30:
- (a) Ein kuratierter Katalog wird als neue Wissensbasis freigegeben: Semantic Definitions, Relationships und Cluster-Regeln. Jede Regel ist versioniert und traegt eine zitierte, offline gespeicherte Quellenangabe. Nicht katalogisierte Einstellungen bleiben ausdruecklich `nicht semantisch zugeordnet` und werden nie geraten.
- (b) Reihenfolge: zuerst Engine und API ohne UI, dann Finding Reader (Abschnitt `Kontext` nach Problem und Next step), dann Pathfinder (Cluster als Knoten/Zweig mit Details im rechten Panel; bestehende Pathfinder-Regeln bleiben), dann eine Work-Facette, zuletzt eine Client-Info-Uebersicht im bestehenden Kachelsystem nach gesonderter visueller Abnahme. Geaendert am 2026-09-30 auf Nutzerwunsch: nach dem Finding Reader folgen ein AD-Katalog-Batch, dann die Work-Facette, dann Pathfinder, zuletzt Client Info (siehe Aenderungsprotokoll).
- (c) Die Work-Facette `Kontext-Cluster` ergaenzt die festgelegte GPO-Facettenliste, ist aber nur bei eingeschaltetem Layer sichtbar. `Source: Scan` bleibt letzte Facette. Beim Abschalten wird ein aktiver Kontextfilter entfernt.

Verbindliche Grenzen des Kontext-Layers:
- Der Layer ist eine abgeleitete, abschaltbare Lesart. Er beeinflusst nie Verdict, Score, technische Filter und Status, Reviews, Risikoakzeptanzen, Result DB oder Priority Findings. ATT&CK-/Relationship-Ableitungen gelangen nie in die Result DB.
- Das Einhaltungsurteil bleibt das autoritative Assessor-Verdict. Die Kontext-Engine erzeugt kein eigenes Pass/Fail, kein `unsicher/sicher`-Urteil, keine Plattform-Default-Fehlkonfiguration aus `Not configured` und keine normalisierte Prioritaet. Der Remediation-Hebel ist nur eine Anzahl betroffener Bedingungen und Cluster, ohne Rang, Aufwand oder Risikoscore.
- Ausgeschaltet heisst: kein Request, keine Berechnung, kein gerendertes Kontextelement und kein aktiver Kontextfilter. Standard ist `aus`; die Wahl wird pro Anwender lokal gespeichert.
- Kontextaussagen sind als `Kontext` gekennzeichnet und tragen Katalogversion und Quelle. Sie formulieren `beguenstigt`, nie `ausnutzbar` oder `bestaetigt`. Unbekannte Bedingungen werden ausdruecklich getrennt angezeigt und zaehlen nie als erfuellt oder nicht erfuellt. Keine Pass/Fail-Statusfarben; visuelle Umsetzung nach `assessor-ui` mit bestehenden Tokens.
- Declared Facts beziehen sich auf die GPO-Backup-Konfiguration, nie auf effektive Host-Zustaende. Die Schluesselbestandteile sind Assessment-Lauf, Backup-Instanz, Semantic-ID und Computer-/User-Scope. Mehrere GPOs ergeben je einen Fact ohne behauptete Vorrangfolge. `Not linked`, Konflikte und Duplikate bleiben sichtbar markiert.
- Datenweg: plattformneutrales Modul (vorgesehen `src/assessment-context/`), Berechnung im Backend ueber eigenen API-Endpunkt, Nur-Lese-Repository-Port und Nur-Lese-Datenbankzugriff. Die Richtung ist fest: Assessor -> Kontext-Engine -> UI und Reporting, nie zurueck. Zunaechst keine eigene Persistenz: deterministische Berechnung bei Bedarf, begrenzter Cache nach Repository-Revision und Scope, frische Ergebnisse nach Import oder Neuauswertung. Eigene Tabellen nur nach gesonderter Freigabe mit Backup und Migration.
- UI und Report lesen dieselben Kontextergebnisse mit derselben Engine- und Katalogversion.

Abnahme erster Umfang (Pilot-Cluster `Credential Relay Exposure` mit etwa 8 bis 12 belegbaren GPO-Einstellungen):
- [x] Katalogformat, Validierung, Versionierung und Quellenpflicht fuer Semantic, Relationship und Cluster umgesetzt (`src/assessment-context/context-catalog.ts`, Katalog 1.0.0). Der Pilot umfasst sieben statt der geschaetzten 8 bis 12 Einstellungen, weil nur GPO-deklarierbare Einstellungen mit belastbarer Quelle aufgenommen wurden (LmCompatibilityLevel, SMB-Server- und SMB-Client-Signierung, LDAP-Server- und LDAP-Client-Signierung, LDAP Channel Binding, LLMNR). Registry-Ziele und Werte wurden am 2026-09-30 gegen Microsoft Learn, KB4520412 und MITRE T1557.001 (`Name Resolution Poisoning and SMB Relay`) geprueft; die Anwendung laedt keine Quelle.
- [x] Die Engine erzeugt Declared Facts je GPO-Backup, Bedingungen mit erfuellten, nicht erfuellten und unbekannten Belegen, Cluster (`present`, `not-present`, `undetermined`) und den Remediation-Hebel ausschliesslich aus gespeicherten Beobachtungen und deren gespeicherter Identitaetsaufloesung, mit Evidenz bis zur Observation-ID. Es gibt keine Titelheuristik; Konflikte zwischen GPOs und rein unverlinkte Quellen werden markiert.
- [x] Nur-Lese-Grenze technisch erzwungen: Port-Typ nur mit Lesemethoden, derselbe schreibgeschuetzte Datenbankleser wie die Report Engine, Architekturtest ohne Aufrufe schreibender Methoden und ohne UI-, Server-, Report- oder Datenbankimporte. Der Schreibablehnungstest mit einer separaten Testdatenbank steht wie bei Report Engine v0.1 noch aus.
- [x] Dauerhafter Abnahmetest: Work, Client Info, Score und Result DB liefern mit Layer an und aus identische Zahlen und Urteile; ein Engine-Lauf veraendert keine gespeicherten Daten. Erledigt am 2026-09-30: Ohne Kontextfilter sind Work-Liste und alle uebrigen Facettenzaehlungen mit Layer an und aus identisch (Test fuer die Status `all` und `deviation`); Client Info, Scoring, Result DB und die Server-Persistenz duerfen den Kontext nicht importieren (Grenztest); der Engine-Lauf laesst Revision und Projektexport unveraendert.
- [x] Ausgeschalteter Layer erzeugt keinen Request und keine Berechnung (Verhaltenstest; Standard aus, lokal je Anwender gespeichert, robust bei blockiertem Speicher). Abschalten entfernt einen aktiven Kontextfilter (Verhaltenstest an der echten Filterleiste, am 2026-09-30 zusaetzlich in der App geprueft); waehrend der Layer an ist und laedt, bleibt der Filter bestehen.
- [ ] UI-Stufen nach (b) jeweils mit synthetischem Interaktionstest und Pruefung beider Themes. Erledigt: Finding Reader, Work-Facette `Context Cluster` und Pathfinder (per Interaktionstest verifiziert; Sichtpruefung beider Themes steht nach Backend-Neustart aus). Offen: Client Info.
- [x] Ausschliesslich synthetische Fixtures mit festen Referenzausgaben; `npm test`: 1679 bestanden, 15 uebersprungen, die 7 bestehenden, unabhaengigen Fehler unveraendert; beide Produktionsbuilds bestanden.

Nutzerentscheidung 2026-09-30, hebt den Ausschluss der Scannerquellen auf: Der Kontext gilt fuer die Findings aller Scans. Umsetzung in zwei Schritten: (1) Abschnitt `Context` bei jedem Finding, (2) Scanner-Beobachtungen ueber exakt katalogisierte Rule-IDs; danach weitere Cluster. Weiter offen: weitere Cluster, Verlaufsbetrachtung ueber den bestehenden Timeslot-Vergleich (keine zweite Drift-Logik), Darstellung im Management Report.

### Phase 13F - 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`, gibt aber ausschliesslich katalogeigene Maester-/PingCastle-Regel-IDs, fest definierte oeffentliche Technikthemen und bekannte oeffentliche Toolnamen weiter. Rohtexte dienen nur lokaler Themenklassifikation; Titel, Beschreibung, Empfehlung, Asset, Pfade, Mandanten-/Projekt- und Reviewdaten werden nicht kopiert. Ohne oeffentliches Signal bleibt der Aufruf fail-closed und erreicht den Retriever nicht.
- 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.
- Ein manueller Work-Vertikalschnitt startet pro kanonischem Scanner-Finding einen idempotenten asynchronen Lauf, gruppiert die 32 Dense-Chunks auf acht Controls, validiert maximal fuenf LiteLLM-Vorschlaege gegen exakt gelieferte Evidenz und speichert Runs sowie optimistisch nebenlaeufigkeitsgeschuetzte Accept/Reject-Ereignisse append-only in PostgreSQL.
- 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.
- 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.
- 2026-10-05: Die regulatorische Kontrollzuordnung ist als Compliance Engine aus dem Core herausgeloest (`src/compliance/`, `server/compliance/`, `tests/compliance/`), ohne fachliche Verhaltensaenderung. Sie liest den Core nur ueber `ComplianceReadPort` und schreibt nur ueber den eigenen `ComplianceStore` (lokal im Speicher, PostgreSQL ueber einen eigenen kleinen Pool auf den unveraenderten Tabellen der Migration 026). Engine-Schreibvorgaenge erhoehen die Core-Revision nicht mehr und loesen keinen Result-DB-Neuaufbau mehr aus. Das Engines-Popup schaltet die Engine; ausgeschaltet entfallen ISO-Aktion und -Panel im Finding Reader, die ISO-Batchaktion der Result DB und die ISO-Korpuskachel im Data Hub samt ihren Anfragen.

Offen bis zur Phasenabnahme:

- Engine-Lesezugriff ueber eine read-only Datenbanksitzung wie bei der Report Engine (heute liest der Port ueber das laufende Core-Repository, weil ein Result-DB-Lesezugriff auf den Core-Neuaufbau warten koennen muss)
- Frameworkneutrale Erweiterung um weitere Korpora (zum Beispiel BSI, DORA) mit Framework-Auswahl in der UI; BSI Grundschutz++ ist als naechstes Framework beschlossen, siehe den folgenden Abschnitt
- 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.

#### BSI Grundschutz++ in der Compliance Engine (Nutzerentscheidung 2026-10-08, in Arbeit)

Quelle ist die BSI-Stand-der-Technik-Bibliothek (`github.com/BSI-Bund/Stand-der-Technik-Bibliothek`, OSCAL-JSON, CC BY-SA 4.0, rollierende Veroeffentlichung ohne Releases oder Tags; Version ist `metadata.version`). Explizite Nutzerentscheidungen vom 2026-10-08:

- Ansatz: direkte Zuordnung (A) mit der offiziellen BSI-Zuordnung ISO/IEC 27001:2022 Annex A -> Grundschutz++ (B) als guenstiger erster Stufe.
- Umfang: nur die 901 Kernel-Anforderungen (Klasse `BSI-Stand-der-Technik-Kernel-G0` im aufgeloesten Anwenderkatalog Grundschutz++). Methodik (95) und Risikomanagement (4) bleiben ausgeschlossen, weil Scannerbefunde kaum ISMS-Prozessanforderungen treffen und die Suche verwaessern wuerden.
- Katalogbeschaffung wie bei der MITRE-Matrix: ein kompakter, versionsgepinnter Snapshot mit Quell-URL, Quell-SHA-256, Quellversion und Lizenzhinweis liegt im Enginepfad und wird von einem Engine-Skript aus den offiziellen Dateien erzeugt. Ableitung und Zuordnung brauchen kein Netz. Eine spaetere Aktion `Update from BSI` nach dem Muster `Update from MITRE` laedt feste offizielle Dateien und stellt eine neue Version bereit, ohne bestehende Ergebnisse zu ersetzen; sie kommt erst mit Aktualisierung des Sicherheitsmodells fuer dieses ausgehende Ziel.
- Zuordnung zunaechst nur manuell: `Map new scans automatically` umfasst BSI nicht.

Stufen:

1. Stufe 1 (B, ohne Modell, ohne Migration): Aus den akzeptierten ISO-Kontrollen einer Regel werden ueber die BSI-Zuordnung Kernel-Anforderungen abgeleitet. Jede abgeleitete Anforderung nennt ISO-Quellkontrolle, Beziehung (`subset-of`, `equivalent-to`, `intersects-with`) und Zuordnungsversion, ist als abgeleitet gekennzeichnet, wird nicht als eigene Entscheidung gespeichert und aendert keine ISO-Entscheidung. Ziele der Zuordnung, die im Katalogsnapshot fehlen, werden als Diagnose ausgewiesen und nie umgedeutet (Stand Zuordnung 1.0.1-qa gegen Katalog vom 2026-09-24: `BER.5.1.2`, `BER.6.8`, `DET.3.1.13`, `GEB.5.4`; die uebrigen nicht aufloesbaren Ziele sind Methodik-IDs und fallen durch den Kernel-Umfang weg). Die 20 Praktiken (zum Beispiel `KONF`, `BER`, `DET`) uebernehmen die Rolle der ISO-Themen.
2. Stufe 2 (A, manuell): eigener BSI-Korpus (Anforderung und Erlaeuterung) im bestehenden Qdrant-/BGE-M3-Pfad unter eigenem `corpusId`, eigene Promptversion fuer die deutschen `MUSS`/`SOLLTE`-Anforderungen, Start nur ueber ausdrueckliche Aktion (Einzel-Finding und Result-DB-Batch). Die Stufe-1-Ableitung dient als Evaluationsreferenz (aggregierte Konsistenz), nicht als Wahrheit. `assessor_regulatory_mappings` (Eindeutigkeit ohne Korpus) und `assessor_regulatory_mapping_decisions` kennen kein Framework; Stufe 2 braucht deshalb einen Framework-/Korpusdiskriminator per Migration mit separater Freigabe und verifiziertem Backup.

Darstellung: BSI-Texte duerfen unter CC BY-SA 4.0 mit Namensnennung im Browser erscheinen, anders als die ISO-Texte. Neue oder geaenderte Erweiterungspunkte (Finding-Reader-Abschnitt, Work-Facetten fuer BSI-Anforderung und -Praktik, Framework-Wahl bei Einzel- und Batchzuordnung, Data-Hub-Katalogkachel) sind Core-Aenderungen (Presentation) und brauchen Core-Freigabe. Die BSI-Kachel im Client-Info-Tab `Compliance` belegt den dafuer vorgesehenen Platz der Frameworkkachelzeile.

Status:

- [x] Stufe 1 Datenschicht: Konverter `src/compliance/bsi-grundschutz.ts`, Generator `server/compliance/update-bsi-assets.mjs`, gepinnte Snapshots in `server/compliance/data/` (Katalog 2026-09-24, Zuordnung 1.0.1-qa, BSI-Commit `a128311`), Ableitung mit Diagnosen, synthetische Tests (2026-10-08)
- [x] Stufe 1 Darstellung: Client-Info-Kachel, Finding Reader, Work-Facetten (Produktversion 2.22.0, 2026-10-08; Sichtpruefung beider Themes in der laufenden App steht aus)
- [x] Stufe 2: BSI-Korpus, direkte Zuordnung, Migration 029 (Produktversion 2.23.0, 2026-10-09; Sichtpruefung beider Themes und ein erster echter BSI-Lauf in der laufenden App stehen aus)
- [x] Stufe 2 Konsistenzpruefung ISO <-> BSI mit Review im Tab `Compliance` (Produktversion 2.23.0, 2026-10-09)
- [x] `Update from BSI` mit Sicherheitsmodell-Aktualisierung (Data-Hub-Kachel, in Produktversion 2.22.0 enthalten, 2026-10-08)

##### Stufe 2 mit Konsistenzpruefung (Nutzerentscheidung 2026-10-09, umgesetzt in 2.23.0)

Ziel: Die ISO-Zuordnungen verbessern, indem das Modell Befunde zusaetzlich direkt BSI-Kernel-Anforderungen zuordnet und das Ergebnis je Regel mit der Stufe-1-Ableitung (akzeptierte ISO-Kontrollen -> offizielle BSI-Zuordnung) verglichen wird. Abweichungen erscheinen zur menschlichen Pruefung. Explizite Nutzerentscheidungen vom 2026-10-09:

- Umfang: vollstaendige Stufe 2 (eigener BSI-Korpus, direkte Zuordnung, Migration), keine reine Verifikation der abgeleiteten Anforderungen.
- Die vorlaeufige automatische Annahme der ersten zwei ISO-Vorschlaege bleibt unveraendert; eine Inkonsistenz haelt sie nicht zurueck.
- Die Pruefung findet im Client-Info-Tab `Compliance` statt (Engine-Code), nicht in einer neuen Work-Facette.
- Vorlaeufig (Nutzerentscheidung 2026-10-09, kann spaeter geaendert werden): auch direkte BSI-Zuordnungen nehmen wie ISO die ersten zwei Vorschlaege automatisch an, mit demselben Kommentar; eine bestehende Entscheidung bleibt erhalten.

Vergleichsregel (`src/compliance/bsi-consistency.ts`): Je Regel werden die direkt akzeptierten BSI-Anforderungen (juengste Entscheidung je Anforderung, also auch die automatisch angenommenen) mit den Zielen der akzeptierten ISO-Kontrollen in der BSI-Zuordnung verglichen. Ohne akzeptierte BSI-Anforderung gibt es nichts zu vergleichen; eine Regel mit akzeptierter ISO-Kontrolle zaehlt dann als `Not compared`. Drei Zustaende:

- `Consistent`: mindestens eine direkte Anforderung liegt in der Zielmenge einer akzeptierten ISO-Kontrolle. Ein Treffer genuegt, weil `subset-of` mehrere Anforderungen umfasst und ein Befund selten alle trifft.
- `Inconsistent`: mindestens eine direkte Anforderung ist ueber die BSI-Zuordnung erreichbar, aber keine liegt in der abgeleiteten Menge (auch ohne akzeptierte ISO-Kontrolle). Pruefpflichtig.
- `No reference`: keine direkte Anforderung ist ueber die BSI-Zuordnung von einer ISO-Kontrolle erreichbar (629 der 901 Kernel-Anforderungen). Keine Abweichung, sondern die Luecke, die die direkte Zuordnung schliesst.

Zusaetzlich als Hinweis die Gegenrichtung: Fuehrt eine direkte Anforderung rueckwaerts ueber die BSI-Zuordnung zu einer nicht akzeptierten ISO-Kontrolle, nennt die Pruefansicht diese Kontrolle als Kandidaten. Der Zustand wird deterministisch aus Entscheidungen, Laeufen und der aktiven Zuordnungsversion berechnet, nicht gespeichert. Uebereinstimmung belegt Konsistenz, nicht Richtigkeit: beide Zuordnungen stammen vom selben Modell und Befundtext.

Grenzen: Eine Inkonsistenz aendert, verwirft oder blockiert keine ISO-Entscheidung; abgeleitete Anforderungen werden weiterhin nie als Entscheidung gespeichert. Nur der Mensch entscheidet. `Map new scans automatically` umfasst BSI weiterhin nicht. BSI-Texte mit Namensnennung (CC BY-SA 4.0), ISO-Texte weiterhin nicht im Browser.

Umsetzung 2.23.0 (urspruenglicher Entwurf der Pruefansicht: Liste der Regeln mit Abweichungen des Timeslots, gruppiert nach Zustand (`Inconsistent` zuerst), je Regel akzeptierte ISO-Kontrollen mit ihrer abgeleiteten BSI-Menge, direkte BSI-Vorschlaege und die Kandidaten der Gegenrichtung. Aktionen: Accept/Reject der direkten BSI-Vorschlaege und der ISO-Kontrollen ueber den bestehenden Entscheidungsweg, `Mark reviewed` fuer eine bewusst belassene Inkonsistenz. `Mark reviewed` gilt fuer einen Fingerabdruck der verglichenen Mengen; aendern sich Entscheidungen oder Zuordnungsversion, erscheint die Regel erneut. Befundzahl und Sprung nach Work wie die bestehenden ISO-Drilldowns.)

- Datenhaltung: Migration 029 (`framework` in `assessor_regulatory_mappings` mit Eindeutigkeit einschliesslich Framework und in `assessor_regulatory_mapping_decisions`, Werte `iso27001`/`bsi-kernel`; neue Tabelle `assessor_regulatory_consistency_reviews`). Vor der Migration Backup `backups/assessor-pre-029-20261009.dump`, per Wiederherstellung in eine Pruefdatenbank verifiziert (Zaehler identisch); danach alle 162 Zuordnungen und 325 Entscheidungen `iso27001`. ISO-Objekte tragen im JSON kein Framework-Feld, ISO-Zuordnungs-IDs, Batch-Scope-Schluessel und URLs bleiben unveraendert.
- BSI-Korpus (`server/compliance/bsi-corpus.ts`): je Kernel-Anforderung ein deutsches Dokument (Aussage und Erlaeuterung mit eingesetzten Parametern) unter `corpusId` `bsi-grundschutz-kernel`, Version aus Katalogdatum und Quell-Hash. Er wird beim ersten BSI-Lauf aus dem aktiven Katalog gebaut (auch nach `Update from BSI`), aeltere Katalogstaende werden danach entfernt.
- BSI-Zuordnung: derselbe Dienst mit Framework-Parameter, Retrieval `bsi-dense-requirement-1.0.0` (40 Treffer, bis zu 12 Anforderungen, jeweils alle Chunks der Anforderung als Evidenz), Prompt `bsi-1.0.0`, Evidenz ohne Seitenangaben. Explizite Nutzerentscheidung 2026-10-09, spaeter am Tag (ersetzt die reine ISO-Historie der Entscheidung vom 2026-10-08): `Last mapping` und das Fenster, jetzt `Mapping history`, listen ISO- und direkte BSI-Laeufe (Batches und Einzelzuordnungen) gemeinsam; die Tabelle hat nach `Started` die Spalte `Framework` (`ISO 27001/27002`, `BSI Grundschutz++`), der Knopf nennt einen BSI-Lauf mit `· BSI` nach dem Datum, ein ISO-Lauf behaelt seine bisherige Beschriftung. `Map new scans automatically` umfasst BSI nicht.
- Startpunkte: Finding Reader, Abschnitt `BSI requirements` mit eigenem Teil `Mapped directly`, Knopf `Map BSI requirements` (Fenster `BSI requirement mapping` wie das ISO-Fenster) und dem Konsistenzzustand in der Zusammenfassung; der Abschnitt bleibt je Befund eingeklappt und erscheint fuer den direkten Teil erst, wenn das Backend den BSI-Zustand geliefert hat. Result-DB-Fenster `ISO mapping batch` mit zweitem Teil `BSI Grundschutz++ requirements` und `Start BSI mapping batch` fuer dieselben Filter.
- Pruefansicht: Kachel `ISO ↔ BSI review` in der Frameworkkachelzeile des Tabs `Compliance` (Compared rules, Inconsistent, No ISO reference, Consistent, Not compared, Reviewed; Gedankenstrich waehrend des Ladens). Ihr Results-Fenster listet die Regeln nach Zustand (Start `Inconsistent`), benannt nur ueber eine Result-DB-Zeile des Timeslots, nie ueber den internen Regelschluessel. Je Regel: akzeptierte ISO-Kontrollen (Reject), direkte BSI-Anforderungen mit Herkunft (Reject), ISO-Kandidaten der Gegenrichtung (Accept nur, wenn der aktuelle ISO-Lauf sie abgerufen hat), `Mark reviewed` mit optionalem Kommentar fuer den aktuellen Fingerabdruck.
- Core-Aenderungen mit Core-Freigabe Store, Presentation, Platform, Core Tests vom 2026-10-09: Migration und Tabellenklassifikation, HTTP-Routen (`framework`-Parameter, `regulatory-mapping-consistency`, `regulatory-mapping-consistency-reviews`), API-Client, Finding-Reader-Einbindung des BSI-Abschnitts, Batch-Ueberschriftenstil, Versionsvertragstests. AGENTS.md beschreibt Stufe 2 noch als ausstehend; die Aktualisierung braucht eine Governance-Freigabe.
- Verifikation: synthetische Tests fuer Vergleichsregel, BSI-Lauf und Entscheidungstrennung, Pruefliste mit `Mark reviewed`, Batch, Korpusaufbau, UI-Interaktionen (Kachel, Fenster, Batchdialog, Finding Reader), erweiterter Invarianztest; `npm test` (alle bestanden) und beide Builds. Ausstehend: Sichtpruefung beider Themes und ein erster echter BSI-Lauf in der laufenden App.

Urspruengliche Umsetzungsschritte (Entwurf):

1. Migration (Core `Store`, separate Freigabe, vorher verifiziertes Backup): `framework` (`iso27001`, `bsi-grundschutz-kernel`) in `assessor_regulatory_mappings` (Eindeutigkeit einschliesslich Framework) und `assessor_regulatory_mapping_decisions`; bestehende Zeilen erhalten `iso27001`. Neue Engine-Tabelle fuer `Mark reviewed` (Regel, Fingerabdruck, Kommentar, Zeit). Tabellenklassifikation im Repository.
2. BSI-Korpus (Engine): Anforderung und Erlaeuterung der 901 Kernel-Anforderungen aus dem aktiven Snapshot unter eigenem `corpusId` im Qdrant-/BGE-M3-Pfad, Neuaufbau bei `Update from BSI`.
3. BSI-Zuordnung (Engine): eigene Prompt- und Schemaversion fuer deutsche `MUSS`/`SOLLTE`-Anforderungen, Einzel- und Batchlauf ueber den bestehenden Dienst mit Framework-Parameter; Wiederverwendung erfolgreicher Laeufe je Regel wie bei ISO.
4. Startpunkte (Core `Presentation`, `Platform`): Framework-Wahl oder zweite Aktion bei `Map ISO controls` im Finding Reader und beim Result-DB-Batch; Framework-Parameter in den HTTP-Routen.
5. Konsistenzberechnung und Pruefansicht (Engine): reine Funktion mit synthetischen Tests fuer alle drei Zustaende, Gegenrichtung und Fingerabdruck; Pruefliste im Tab `Compliance`.
6. Finding Reader `BSI requirements` (Engine-Inhalt): direkte und abgeleitete Anforderungen getrennt kenntlich.
7. Invarianztest der Compliance Engine erweitern; `npm test`, beide Builds, Produktversion (Minor).

Vor der Umsetzung offen, am 2026-10-09 entschieden: Migration mit Backup und Core-Freigabe erteilt; direkte BSI-Vorschlaege werden vorlaeufig wie ISO automatisch angenommen (Nutzerentscheidung entgegen dem Vorschlag, nur manuell anzunehmen).

Risiko: Weil beide Seiten automatisch angenommen werden und vom selben Modell stammen, zeigt `Consistent` zunaechst nur die Uebereinstimmung zweier Automatiken; die Entscheidung ist ausdruecklich vorlaeufig.

#### Client-Info-Tab `Compliance`: Uebersichtszeile (Nutzerentscheidung 2026-10-08, umgesetzt)

Nach Freigabe eines lokalen, nicht versionierten Mockups mit synthetischen Daten steht ueber der unveraenderten Frameworkkachelzeile eine Uebersichtszeile in denselben sechs Spuren. Reiner Engine-Code (`src/compliance/ui/ComplianceOverview.tsx`, `compliance.css`, `server/compliance/regulatory-mapping-service.ts`); kein Erweiterungspunkt und keine Core-Datei geaendert.

- `Mapping coverage` (quadratisch, zwei Spuren): gemeinsamer Client-Info-Donut ueber die zuordenbaren Abweichungen des Timeslots (Scannerbefunde und GPO-Einstellungen, eine GPO-Einstellung einmal). Jede Abweichung zaehlt genau einmal im staerksten Zustand ihrer Regel: akzeptierte Kontrolle, sonst erfolgreiche Zuordnung ohne akzeptierte Kontrolle, sonst fehlgeschlagene juengste Zuordnung, sonst noch nicht zugeordnet (auch wartend oder laufend). `accepted` ist identisch mit `Findings` der ISO-Kachel. Die Antwort `coverage` enthaelt nur Zahlen; die Work-Filterzuordnungen tragen sie nicht.
- `Annex A footprint` (vier Spuren): alle 93 Kontrollen nach Thema (Organizational | People ueber Physical | Technological), Kontroll-ID je Zelle, Schattierung in einem neutralen Diagrammton in vier Stufen (1-2, 3-9, 10-24, 25+), keine Status- oder Severityfarbe. Nur Kontrollen und Themen mit Treffern oeffnen Work (`Deviation` plus `ISO control` beziehungsweise `ISO theme`), wie die Facetten. Eine Detailzeile nennt bei Hover oder Fokus ID, Thema, Titel und Befundzahl. Nutzerauftrag derselben Sitzung: auch Kontrollen ohne Befund tragen ihren Titel; er stammt aus den ISO/IEC-27001-Referenzdokumenten des aktiven lizenzierten Korpus (`annexATitles`, nur Titel, nie Klauseltext, je Korpusversion zwischengespeichert, ohne Index keine Titel), der Titel eines Zuordnungslaufs hat Vorrang. ISO-Texte werden weiterhin nicht im Repository gebuendelt. Die Legende sagt ausdruecklich, dass eine leere Zelle keine Konformitaetsaussage ist.
- Nutzerauftrag 2026-10-08, spaeter am Tag: Zwei Schaltflaechen neben der Ueberschrift (`ISO 27001/27002`, `BSI Grundschutz++`, Client-Info-Tabknoepfe mit `aria-pressed`) schalten nur die Uebersichtszeile um; die Frameworkkacheln bleiben unveraendert, Standard ist ISO. Die BSI-Ansicht (Nutzerwahl) zeigt `Mapping coverage` mit fuenf Zustaenden (mit BSI-Anforderung, ISO-Kontrolle ohne BSI-Anforderung, zugeordnet ohne akzeptierte Kontrolle, noch nicht zugeordnet, fehlgeschlagen; die ersten beiden teilen `accepted`) und `Kernel footprint` mit allen 901 Kernel-Anforderungen als unbeschriftete Zellen je Praktik in Katalogreihenfolge. Die 629 Anforderungen, die die BSI-Zuordnung von keiner ISO-Kontrolle erreicht, tragen nur eine kleine neutrale Markierung, damit eine leere Zelle nicht als Luecke dieses Clients gelesen wird. Hover oder Fokus nennen ID, Praktik, Titel und ISO-Weg abgeleiteter Anforderungen und die Befundzahl; nur Anforderungen und Praktiken mit Treffern oeffnen Work (`BSI requirement`, `BSI practice`). Nutzerkorrekturen derselben Sitzung: Jede Anforderung ist ein Quadrat mit nur ihrer Nummer innerhalb der Praktik (zum Beispiel `10.5`; das Praefix nennt die Praktikueberschrift), auch ohne Befund oder ohne ISO-Erreichbarkeit (gestrichelter Rand). Die Kachel zeigt nur die zwei Praktiken mit den meisten Befunden (absteigend, Gleichstand in Katalogreihenfolge), damit die Quadrate lesbar bleiben; `Show all` oeffnet alle Praktiken mit groesseren Quadraten (14px-Datenrolle) im gemeinsamen Results-Fenster, ein Work-Sprung dort schliesst das Fenster. Ohne abgeleitete Anforderung nennt die Kachel das ausdruecklich. Im `Show all`-Fenster bleiben Detailzeile und Legende unten angeheftet, waehrend das Raster scrollt; die Detailzeile nennt fuer jede Anforderung den veroeffentlichten Titel, auch ohne Zuordnung oder ISO-Erreichbarkeit. Die Kontrolluebersicht liefert dafuer `bsiFootprint` (IDs, Titel unter CC BY-SA 4.0 und Erreichbarkeit aus dem aktiven Katalog, keine Anforderungstexte); die Work-Filterzuordnungen tragen ihn nicht.
- Nutzerauftrag 2026-10-08 (Core-Freigabe Presentation): Die Legendenzeile `Mapping failed` der `Mapping coverage` (ISO- und BSI-Ansicht) ist bei mindestens einem Befund ueber die ganze Zeile klickbar und oeffnet Work mit dem Status `Deviation` und der neuen Compliance-Engine-Facette `ISO mapping` = `Mapping failed`; dort laesst sich jeder Befund ueber `Map ISO controls` im Finding Reader neu zuordnen. Die Facette steht nach `ISO theme`, erscheint nur, solange eine Zuordnung fehlgeschlagen ist, und matcht wie die Kontrollfacetten (Scannerbefunde nach Vorkommen, GPO-Einstellungen nach Scope und technischer Identitaet). Grundlage ist `failedFindings` der Work-Zuordnungen: zuordenbare Befunde, deren Regel keine akzeptierte Kontrolle hat und deren juengster Lauf fehlschlug, also dieselbe Zustandsregel wie die Abdeckungszahl. Core-Aenderung nur der neue Drilldown in `DashboardPanel.tsx` neben den bestehenden ISO-/BSI-Drilldowns.
- Nutzerauftrag 2026-10-08, spaeter (Core-Freigabe Presentation): Auch `ISO control, no BSI requirement` der BSI-Abdeckung oeffnet Work, ueber den zweiten Wert gleichen Namens der Facette `ISO mapping` (Befunde mit akzeptierter ISO-Kontrolle, von denen keine eine BSI-Anforderung erreicht; im Browser aus den Work-Zuordnungen berechnet). Der Drilldown in `DashboardPanel.tsx` ist dafuer allgemein `onOpenMappingState(state)`. Der Tab `Compliance` zeigt unter der Tableiste dieselbe Kontextzeile wie die Overview mit `Client` und `Assessment` (Timeslot-Wechsel), ohne `Source`, weil der Tab immer den ganzen Timeslot abdeckt (Nutzerzustimmung zum Vorschlag).
- Nutzerkorrektur 2026-10-12 (ersetzt nur die quadratische `Mapping coverage` und die zwei Praktiken der Kernel-Kachel): Die Uebersichtszeile ist nur so hoch, wie der hoehere Inhalt braucht, beide Kacheln sind gleich hoch. Die Zellen beider Footprints wachsen mit der Kachelbreite von der bisherigen Groesse bis hoechstens 64px (Seitenverhaeltnis 5:3, Nummern in der 14px-Datenrolle); jede Annex-A-Themenspalte ist nur so breit wie ihre sechs Zellen, die Spalten verteilen sich ueber die Kachel. Die BSI-Anforderungen fuellen ein Raster mit so vielen Spalten dieser Groesse, wie passen. Die Kernel-Kachel zeigt nur noch die eine Praktik mit den meisten Befunden (Gleichstand in Katalogreihenfolge); `Show all` bleibt unveraendert. Nur Engine-Code; synthetische UI-Tests angepasst.
- Nutzerkorrektur 2026-10-12, spaeter (ersetzt nur die feste Zahl von vier Praktiken der Frameworkkachel `BSI Grundschutz++`): Die Kachel zeigt nach `Requirements` und `Findings` mindestens vier und hoechstens zehn Praktiken mit den meisten Befunden, so viele, wie ihr Quadrat fasst (Containerabfragen auf die Innenbreite: sechs ab 17rem, acht ab 20.5rem, zehn ab 23.5rem); `Results` listet weiterhin alle. Die Formulierung in `AGENTS.md` ist mit `Core-Freigabe: Governance` entsprechend angepasst.
- Waehrend des Ladens Gedankenstrich, nichts klickbar; bei ausgeschalteter Engine nichts. Verifiziert durch synthetische UI- und Diensttests, `npm test` und beide Builds; Sichtpruefung beider Themes in der laufenden App mit gewaehltem Client steht aus (der laufende Server muss fuer `coverage` neu gestartet werden).

## 8. Aktuell empfohlene Umsetzungsetappe

2026-09-26 - Phase 13D / Phase 13C Darstellung (2.8.3, umgesetzt und verifiziert): Catalog references startet bei aktuellem Client eingeklappt; gruen vor Ueberschrift und aktuellem/erfolgreichem Status, orange und automatisch offen bei Handlungsbedarf oder Fehler. Pruefung, Verarbeitung und leere Clients bleiben neutral. Katalogversionen bleiben eingeklappt sichtbar, Erfolg nach Update bleibt offen, manuelles Umschalten funktioniert per Maus und Tastatur. Timeslots-Zeile mit gleichem Abstand oben/unten und gemeinsam zentrierten Controls. Purple-Knight-Timeslots benennen Active Directory, Entra ID oder kombinierten Scope aus bestehenden kanonischen Namen bzw. exakt lauf-/dateigebundenen gespeicherten Metadaten/Umgebungsbeobachtungen. Ohne Scopebeleg bleibt der Originalname; keine Vermutung aus Dateinamen oder fremden Scans, keine Persistenz-/Importer-/Scoringaenderung und keine neue Reimportpflicht. 36 gezielte Interaktions-/Layout-/Versionsvertragstests, beide Produktionsbuilds, Local-only-/Designcheck und synthetische Dark-/Light-Sicht- und Tastaturpruefung bestanden. App und Backend gesund auf 2.8.3 mit kanonischer PostgreSQL. Patchversion fuer zusammengehoerige UI-Korrekturen; Phase 13D bleibt in Arbeit. Die bekannte Gesamtsuite-Baseline mit sechs fachfremden Fehlern wurde nicht erneut ausgefuehrt.

2026-09-26 - Phase 13D Handlungstexte (2.8.2, umgesetzt und verifiziert): Allgemeiner Erklaerabsatz im linken Catalog-references-Bereich entfernt. Please update benennt Handlungsbedarf, Up to date / No action needed. den aktuellen Stand, Update successful den per erneutem Statusabruf bestaetigten Erfolg. Button heisst Update references; ATT&CK-/D3FEND-Versionen sowie Rot-bei-Bedarf/Gelb-sonst bleiben. Leere Clients, laufende Pruefung und Fehler erhalten eigene Texte; bei verbleibender Arbeit wird kein Erfolg behauptet. 25 gezielte UI-/Versionsvertragstests, beide Produktionsbuilds, Local-only-/Designcheck und synthetische Light-/Dark-Pruefung bestanden. Patchversion fuer reine UI-Korrektur, keine reale Nachverarbeitung oder Persistenzaenderung; Phase 13D bleibt in Arbeit. Die bekannte Gesamtsuite-Baseline mit sechs fachfremden Fehlern wurde fuer diese Textkorrektur nicht erneut ausgefuehrt.

Nachtrag Phase 13D, 2026-09-26, Version 2.8.1 (Nutzerkorrekturen umgesetzt und verifiziert): Die Clientuebersicht beruecksichtigt jetzt ausstehende Referenzerkennung sowie veraltete Erkenner-/Katalogstaende mit gelbem Statuspunkt und hervorgehobenem Manage, auch ohne Clientauswahl. Echte Erkennungsfehler sind rot; unbekannter Status bleibt als Pruefhinweis sichtbar und bietet einen Status-Retry. Bestehende Import-/GPO-Fehler behalten Vorrang. Statusabrufe laufen unabhaengig von den Uebersichtsdaten mit maximal drei gleichzeitigen Anfragen und ohne neues Polling; Daten-/Import- und erfolgreiche Katalogupdates aktualisieren sie. Ein neuerer Panelstatus gewinnt gegen verspätete Uebersichtsantworten.

Zusaetzliche explizite Nutzerentscheidung: Catalog references steht links direkt ueber Timeslots, auch bei Stammdatenbearbeitung. Recognize references ist bei Nachverarbeitungs- oder Wiederholungsbedarf rot, sonst standardgelb; dies ist eine begrenzte Ausnahme der allgemeinen Aktionsfarbe. Die linke Quellnavigation bleibt unterhalb des Clientkopfs scrollbar. Nach Erfolg aktualisieren sich Karte und Workspace. Risiken/Grenzen: Ausfuehrungsfehler sind aktueller UI-Zustand; nach erneutem Laden zeigt die persistierte Bereitschaft weiterhin den ausstehenden Lauf, ohne einen gespeicherten Hintergrundjob vorzutäuschen. Keine reale Client-Nachverarbeitung, Migration oder Scoring-/Importsemantikaenderung.

Verifikation: 25 gezielte Status-/UI-/Readiness-Tests; nach der Platzierungskorrektur 23 UI-/Layout-/Versionsvertragstests bestanden, einschliesslich sieben Tests fuer den Clientstatus und den tatsaechlichen Manage-/Nachverarbeitungs-/Rueckkehrpfad. Vollsuite waehrend dieses Batches: 1582 bestanden, 14 uebersprungen, dieselben sechs bestehenden Fehler in fuenf Dateien. Finale Client-/Serverbuilds, Local-only-, Design- und Diffpruefung bestanden. Synthetische Dark-/Light-Sichtpruefung bestaetigt Statusfarben, linke Platzierung, roten/gelben Button und Scrollbarkeit bei kleiner Fensterhoehe. App/Backend melden 2.8.1, HTTP 200 und kanonische PostgreSQL. Versionsentscheidung: rueckwaertskompatible Korrektur als Patch; Phase 13D bleibt fuer ihren weiteren Umfang offen.

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, 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 13F besitzt den lizenzierten ISO-Korpus-v2, die rebuildbare Qdrant-/Dense-Grundlage, den fail-closed Public-Signal-Pfad, den persistierten manuell reviewten Einzel-Finding-Workflow sowie das explizit vorgezogene gefilterte Result-DB-Batchmapping. Als naechste Etappe folgen ein unabhaengig gelabelter repraesentativer EN/DE-Evaluationssatz und die reale Dense-Baseline; Sparse/Hybrid, Reranking, Confidence-Kalibrierung und jede automatische Entscheidung bleiben bis zu dieser Bewertung 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.

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

- 2026-10-01, Core Engine und Engines (Nutzerentscheidung): Der Assessor mit allen bestehenden Funktionen heisst Core Engine, die Kontextanreicherung aus Phase 13E Context Engine; die nur lesende Report Engine aus Phase 7 ist ebenfalls eine Engine. Neue Features kommen als eigene Engines. Engines lesen den Core uneingeschraenkt, aber nur ueber einen erklaerten Nur-Lese-Port und den schreibgeschuetzten Datenbankzugang; sie schreiben, aendern oder uebersteuern ihn nie. Abhaengigkeiten zeigen nur von der Engine zum Core; der Core funktioniert mit allen Engines aus unveraendert, und jede Engine traegt einen dauerhaften An/Aus-Gleichheitstest. Eine Engine erzeugt keine Findings; Scanner-Profile, Importer und Parser sind immer Core. Eigene Speicherung einer Engine nur in eigenen Tabellen nach gesonderter Freigabe. Jede Core-Aenderung braucht die ausdrueckliche Freigabe des Nutzers fuer die konkrete Anfrage und den benannten Core-Bereich (Ingest, Normalization, Evaluation, Store, Disclosure, Reference Catalogs, Shared Kernel, Presentation, Platform, Core Tests, Governance). Erweiterungspunkte in Core-Ansichten (Context-Schalter, Facette `Context Cluster`, Reader-Abschnitt `Context`) sind Core-Code. Die verbindliche Fassung steht in AGENTS.md unter "Core Engine and engines", die Pfadzuordnung in `.claude/hooks/core-guard.mjs`. Der Projekt-Hook fragt vor schreibenden Werkzeugaufrufen auf Core-Pfaden nach; er ist Sicherheitsnetz, nicht Autoritaet.

- 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 · <Pfad>` 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-15 (Phase 13F, 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 13F, 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.

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

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

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

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

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

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

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

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

## 10. Offene Entscheidungen

Report-Vormerkung 2026-09-30 (Nutzerwunsch, Phase 7; noch keine Umsetzung): „Sicherheit kann nicht verbessert werden, indem man Symptome bekämpft“. Den Satz fuer eine spaetere Aufnahme in Reports vormerken. Der Nutzer arbeitet daran mit Claude; weder Report-Inhalte noch Vorlagen jetzt deswegen aendern. Platzierung und Verwendung bleiben offen.

Report Engine 2026-09-30 (Phase 7): Am 2026-09-30 entschieden und damit nicht mehr offen. Die Ablage in `src/reporting/`, das serverseitige unveraenderliche Reportarchiv und die vier Grenzen stehen in Phase 7 unter "Report Engine als eigenstaendiger Nur-Lese-Baustein".

Autonome Client-Datenbanken 2026-09-26: Das Zielbild "eine fachliche Datenbank pro Client" und die autarke Wiederherstellung einschliesslich verwendeter Referenzstaende sind entschieden; Implementierung und Migration sind nicht beauftragt. Vor einer Umsetzung sind Client-Routing und Autorisierung, Ort und Lebenszyklus des zentralen Katalogs, Bindung und Pruefsummen der Referenzartefakte, Backup-/Restore-Paketformat, Lizenz-/Bezugsgrenzen der Microsoft-Pakete, clientindividuelle Overrides, Update-/Rollback-Ablauf und Migration des bestehenden kanonischen Bestands zu spezifizieren und mit synthetischen Isolation-, Historien- und Offline-Restore-Tests abzusichern. Die genaue SSO-, Rollen- und Betriebsplattform bleibt offen.

Bericht A/B 2026-09-23: Die Nutzeranforderung beauftragt die HTML-Erzeugung direkt aus Client Info und ordnet die UI-Anbindung Phase 7 zu. Die veroeffentlichten Report-Inhalte bleiben durch `docs/REPORT_STRATEGY.md` gebunden. Offen ist die endgueltige Vollstaendigkeitsabnahme des Technical Reports ueber alle Quellformate und Reimport-/Diagnostic-Klassen; sie wird nicht aus dem Vorhandensein des Buttons abgeleitet.

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
- Freigabeverfahren fuer einen optionalen externen LGPO.exe-Adapter, falls spaetere nicht unterstuetzte Registry.pol-Varianten ihn erfordern
- Bezugs-, Lizenz- und Freigabeverfahren für versionierte Microsoft-Baselines und ADMX-/ADML-Metadatenkataloge
- optionaler Import von `Get-GPOReport`-, Group-Policy-Results-, `gpresult`- oder anderer RSoP-Evidenz in einer späteren Ausbaustufe
- genaue SSO-Integration im Unternehmensnetz
- SSO-gebundene Rollen, Berechtigungen und Client-Routing innerhalb des entschiedenen Eine-Datenbank-pro-Client-Zielbilds
- Aufbewahrungs- und Löschfristen
- betriebliche Anpassung der festgelegten Importgrenzen an die Firmeninfrastruktur
- Umgang mit manuell bestätigten Mappings zwischen Projekten
- Deployment-, Monitoring- und Backup-Plattform

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

## 11. Risiken

- 2026-10-05, Compliance Engine (Phase 13F): Die Engine liest den Core noch ueber das laufende Core-Repository statt ueber eine read-only Datenbanksitzung; die Schreibsperre ergibt sich nur aus dem Port-Typ. Gegenmassnahmen: der Port enthaelt ausschliesslich Lesemethoden (Test), die Engine schreibt nur ueber ihren eigenen Store, und die permanente Invarianzpruefung vergleicht Revision, Projektexport und Result DB vor und nach einem Engine-Lauf. Ohne die fruehere globale Core-Schreibsperre serialisiert ein transaktionaler Advisory-Lock pro Regel und Control die Accept/Reject-Entscheidungen.

- 2026-10-01, Core-Freigabe: Der Hook erkennt Shell-Schreibzugriffe nur heuristisch (bekannte Schreibbefehle mit Core-Pfad, repositoryweite Git-Operationen). Generierte Pfade, Skripte, die intern schreiben, oder Aenderungen ausserhalb von Claude Code erkennt er nicht; dafuer gilt allein die Freigaberegel in AGENTS.md. Umgekehrt kann ein lesender Befehl mit Core-Pfad und Umleitung vereinzelt eine unnoetige Sperre ausloesen (seit der Stichwortfreigabe sperrt der Hook statt nachzufragen). Ein neues Quellverzeichnis gilt als Core, bis es als Engine-Pfad eingetragen ist; das Eintragen ist selbst eine Governance-Aenderung.

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.

- 2026-09-30, Reportarchiv (Phase 7): Das Archiv enthaelt mit `projection.json` vollstaendige technische Kundendaten ausserhalb der Datenbank. Gegenmassnahmen: Speicherort ausserhalb von Repository und OneDrive, Loeschung zusammen mit dem Client, Kennzeichnung als sensibler lokaler Speicher in `SECURITY.md` bei der Umsetzung und nie gemeinsame Auslieferung mit Report A.

- 2026-09-30, Kontext-Layer (Phase 13E): Kontextaussagen koennten als zweites Urteil oder als bestaetigter Angriffsweg gelesen werden. Gegenmassnahmen: kein eigenes Verdict, Kennzeichnung `Kontext` mit Quelle und Version, `beguenstigt`-Formulierung, sichtbare unbekannte Bedingungen und der dauerhafte An/Aus-Gleichheitstest. Der Katalog ist die fachliche Hauptlast; eine unbelegte Regel wuerde eine erfundene Aussage erzeugen und ist deshalb ohne Quelle unzulaessig.

- 2026-09-26, autonome Client-Datenbanken: Eine getrennte Datenbank allein garantiert keine Autarkie, wenn Baseline-/MITRE-Versionen oder GPO-/Baseline-Originale nur zentral verfuegbar sind. Backup, Restore und Loeschung muessen Datenbank und private Artefakte gemeinsam behandeln. Zentrale Referenzupdates duerfen historische Urteile nicht still neu berechnen und ein Clientwechsel darf keine Datenbank oder Artefakte eines anderen Clients erreichen. Die bisher globale Baseline-Liste und der serverweite MITRE-Katalog sind noch nicht clientgebunden; ihre blosse Verschiebung in der UI waere keine Isolation. Ein Migrationskonzept mit verifiziertem Backup ist vor jeder Bestandsaenderung erforderlich. Diese Risiken sind als Planungsaufgaben offen; keine Implementierung oder Abnahme wird behauptet.

- 2026-09-23, HTML-Reports: Die Management-Datei darf keine internen Source-IDs, Assets oder technischen Rohwerte enthalten, auch wenn beide Renderings dieselbe interne Projektion nutzen. Separate Dateien und ein synthetischer Leckagetest sichern die Grenze. Der Technical Report kann nur gespeicherte Originalfelder und GPO-Anweisungen zeigen; fehlende Ist-/Sollstruktur, Source-Evidence oder Parserdiagnose wird nicht erfunden. Ein umfassender Vollstaendigkeits- und Theme-Test im freigegebenen Dummy ist noch offen; bis dahin gilt die A/B-Abnahme nicht als abgeschlossen.

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

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.

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.

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

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

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

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


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

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

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

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

## 12. Änderungsprotokoll

2026-10-08 - Phase 13F / Fehlerbehebung: fruehere ISO-Entscheidung nach Neuzuordnung ablehnbar (Nutzermeldung; nur Engine-Code): Eine Neuzuordnung mit unveraenderten Pipelineversionen ueberschreibt den einzigen Lauf der Regel (deterministische Mapping-ID). Schlug das Modell eine frueher akzeptierte Kontrolle nicht mehr vor, lag sie in keinem gespeicherten Lauf mehr, und Ablehnen scheiterte mit `Decision control was not a grounded candidate.` Beide Engine-Stores (PostgreSQL, Speicher) erlauben eine Entscheidung jetzt auch, wenn fuer Regel und Kontrolle bereits eine Entscheidung besteht; die Kette `previousDecisionId` fuehrt zum begruendenden Lauf zurueck. Eine nie vorgeschlagene Kontrolle bleibt abgelehnt. Keine Migration. Regressionstest der genauen Interaktion (zuordnen, neu zuordnen, frueher akzeptierte Kontrolle ablehnen) gegen den echten Speicher-Store; alle Testdateien bestanden, beide Builds erfolgreich.

2026-10-08 - Phase 13F / Client-Info-Tab `Compliance`: Uebersichtszeile `Mapping coverage` und `Annex A footprint` (Nutzerauftrag nach Mockup-Freigabe; nur Engine-Code, keine Core-Freigabe): Neue Zeile ueber den Frameworkkacheln mit Umschaltung ISO/BSI (BSI: Kernel footprint, in der Kachel die zwei Praktiken mit den meisten Befunden, `Show all` mit allen 901 Anforderungen), Details in Abschnitt 7, Phase 13F. Die Kontrolluebersicht liefert zusaetzlich `coverage` und `bsiFootprint` (Zahlen sowie IDs, Titel und Erreichbarkeit der BSI-Anforderungen). Alle Testdateien bestanden (373, 7 uebersprungen); Local-only-, Designpruefung und beide Builds erfolgreich. Produktversion vorerst unveraendert, weil `package.json` zum Core-Bereich Platform gehoert; Anhebung auf 2.23.0 (neue Faehigkeit) nach Core-Freigabe Platform.

2026-10-08 - Phase 13F / Client-Info-Tab `Compliance` mit `Last mapping` (Nutzerauftrag; Core-Freigabe Presentation, Governance, Platform, Core Tests; Produktversion 2.21.0): Die Compliance-Zeile ist aus der Overview in einen eigenen Client-Info-Tab `Compliance` gewandert (nach Overview und Microsoft Defender for IoT, vor `AI Overview`; sichtbar bei aktiver Engine, verbundenem Backend und gewaehltem Timeslot). Die Rahmenwerkskachel und ihr `Results`-Fenster bleiben auf Nutzerwunsch unveraendert, damit weitere Regelwerke als Kacheln folgen koennen. Neu ist der Button `Last mapping: <Datum, Uhrzeit> · Automatic|Manual` (ohne Lauf `No mapping yet`), der in einem Fenster die letzten zehn Batches des Timeslots mit Start, Ausloeser, Status und den inhaltsfreien Zaehlern Findings, Sent to model, Reused, Succeeded und Failed zeigt. Die Engine liefert diese Zusammenfassungen nur in der Client-Info-Uebersicht (`mappingBatches`), ohne Scope, Filter oder Schluessel; Automatic erkennt sie an den gemeinsamen Schluesselpraefixen `auto:`/`auto-gpo:` des Watchers. Waehrend ein Batch laeuft, aktualisiert sich der Tab alle 5 s ohne Gedankenstrich-Rueckfall. Core-Aenderung (Presentation): `DashboardPanel.tsx` fuehrt den Tab und zieht `jump` vor die Tab-Rueckgaben. `AGENTS.md` haelt die Entscheidung fest. Synthetische Tests: Tab-Platzierung und Drilldowns, Last-mapping-Button und Fenster, leerer Zustand, Aktualisierung waehrend eines Laufs, Batch-Zusammenfassung im Service. `npm test` mit 2.143 bestandenen und 18 uebersprungenen Tests, beide Produktionsbuilds erfolgreich. Versionsentscheidung: neue rueckwaertskompatible Faehigkeit, Minor 2.20.0 -> 2.21.0. Darstellung in beiden Themes nicht live geprueft, weil die laufende Anwendung reale Daten enthaelt. Kein Reimport. Nachtrag desselben Tages (Nutzerrueckmeldung "laedt jedes Mal neu", nur Engine-Code): Der Tab wird beim Wechsel ausgehaengt und begann deshalb jedes Mal mit Gedankenstrichen. Die Engine merkt sich die letzte Uebersicht je Kunde und Timeslot im Speicher (hoechstens acht Timeslots, nur Laufzeit), zeigt sie beim Zurueckkehren sofort und fordert bei jedem Besuch, jeder Entscheidung und waehrend eines Laufs trotzdem eine frische Uebersicht an, die sie ersetzt; ein fehlgeschlagenes Auffrischen laesst die gezeigten Werte stehen. Synthetischer Test fuer Verlassen und Zurueckkehren (sofort Werte, Hintergrundabfrage, Ersetzung). `npm test` 2.144 bestanden; ein lastbedingter Zeitfehler in `sheet-selection-cost` besteht einzeln; beide Produktionsbuilds erfolgreich; Version bleibt 2.21.0. Zweiter Nachtrag (Nutzerrueckmeldung "zeigt nur Batches, nicht die Einzelzuordnungen", nur Engine-Code): Jeder Zuordnungslauf speichert jetzt seinen Ausloeser (`trigger: single | batch`, im JSON des Engine-Laufs, keine Migration). Das Fenster `ISO mapping history` zeigt neben den Batches die Einzelzuordnungen (`Single finding`) der Regeln mit Abweichungen im Timeslot, gemeinsam nach Startzeit sortiert, hoechstens zehn Eintraege; Zaehler je Einzelzuordnung: Findings des Timeslots zu dieser Regel, 1 an das Modell, Erfolg oder Fehler. Einzelzuordnungen sind global je Regel und koennen deshalb aus einem anderen Kunden stammen. Laeufe vor 2.21.0 tragen keinen Ausloeser und erscheinen nicht als Einzelzuordnung, weil sie nicht von Batch-Laeufen zu unterscheiden sind. Behoben: Die Ausloeserspalte erschien in 16 px, weil die gemeinsame Tabelle ihre zweite Spalte als Wert formatiert; die Verlaufstabelle haelt 14 px. `npm test` 2.144 bestanden, beide Produktionsbuilds erfolgreich. Offen: `AGENTS.md` nennt noch "die letzten zehn Batches" und schliesst Einzelzuordnungen aus (Governance nicht freigegeben). Dritter Nachtrag (Nutzerentscheidung 2026-10-08 "Zuordnungen sind global, also zeigt der Verlauf alles"; Auswahl "Everything, all clients" und 50 Eintraege): Der Verlauf listet jetzt jeden Batch aller Kunden und jede Einzelzuordnung, gemeinsam nach Startzeit, hoechstens 50. Eine neue Spalte `Scope` sagt `This timeslot`, `Other timeslot` (Batch eines anderen Kunden oder Timeslots) oder `All clients` (Einzelzuordnung); der Button `Last mapping` zeigt den neuesten Eintrag global und nennt den Scope, wenn es nicht dieser Timeslot ist. Einzelzuordnungen haben keine eigene Findingzahl (Gedankenstrich); Batches anderer Kunden zeigen ihre eigenen Zaehler. Eintraege bleiben inhaltsfrei (Zeit, Ausloeser, Scope-Markierung, Zaehler; kein Kunde, keine Regel, keine Scope-IDs). `npm test` 2.145 bestanden, beide Produktionsbuilds erfolgreich. Offen wie zuvor: `AGENTS.md`-Wortlaut (Governance). Vierter Nachtrag (Core-Freigabe Governance): `AGENTS.md` haelt den globalen Verlauf (alle Batches aller Kunden und alle Einzelzuordnungen, hoechstens 50, Spalte Scope, Ausloeser je Lauf ab 2.21.0) und den begrenzten Speicher beim Zurueckkehren zum Tab als spaetere Nutzerentscheidung desselben Tages fest; die offenen Punkte zum Wortlaut sind erledigt. Fuenfter Nachtrag (Core-Freigabe Core Tests): Der in den vorigen Laeufen lastbedingt fehlschlagende Test `tests/features/sheet-selection-cost.test.tsx` erzeugte 2.537 synthetische Arbeitsblaetter und damit zweimal Tausende jsdom-Optionen (allein rund 2,4 s, unter Parallellast ueber dem 5-s-Limit). Weil der Sheet-Selektor seine Optionen unabhaengig von der Anzahl zurueckhaelt, prueft er jetzt dasselbe Verhalten mit 300 Blaettern (162 ms); alle Zusicherungen bleiben (eine Option bis Fokus, alle nach Fokus und Pointer, Auswahl erhalten). Drei aufeinanderfolgende vollstaendige `npm test`-Laeufe mit je 2.145 bestandenen und 18 uebersprungenen Tests ohne Fehler. Sechster Nachtrag (Nutzerkorrektur "Scope soll sagen, woher die Zuordnung kam", nur Engine-Code): Die Spalte `Scope` nennt jetzt die Herkunft relativ zum gezeigten Timeslot: `This timeslot`, `Other timeslot` (derselbe Kunde), `Other client` oder `Unknown`. Batches tragen Kunde und Timeslot bereits. Eine Einzelzuordnung sendet aus dem Finding Reader den gezeigten Timeslot mit; der Server prueft ihn gegen den Kunden und speichert nur SHA-256-Merkmale von Kunde, Assessment und Scanlauf (`origin`), weil Zuordnungslaeufe global sind und mit jedem Kundenexport ausgeliefert werden; ein ungueltiger Timeslot hinterlaesst nur den Kunden. Einzelzuordnungen ohne gespeicherte Herkunft (vor dieser Aenderung) erscheinen als `Unknown`. Synthetische Tests: alle vier Herkunftsfaelle fuer Batches und Einzelzuordnungen, keine Klar-IDs im gespeicherten Lauf, ungueltiger Timeslot, Finding Reader sendet den Timeslot. `npm test` 2.147 bestanden, beide Produktionsbuilds erfolgreich. Offen: `AGENTS.md` nennt noch `Other timeslot` fuer jeden anderen Batch und `All clients` fuer Einzelzuordnungen (Governance nicht freigegeben). Siebter Nachtrag (Core-Freigabe Governance): `AGENTS.md` haelt die Herkunftsspalte (`This timeslot`, `Other timeslot`, `Other client`, `Unknown`) und die gehashte Herkunft der Einzelzuordnungen als Nutzerkorrektur fest; der offene Punkt ist erledigt.

2026-10-08 - Phase 13F / Automatische ISO-Zuordnung neuer Uploads (Nutzerauftrag; Engine-Code, dazu Core-Freigabe Platform, Core Tests; Produktversion 2.20.0): Die Compliance Engine ordnet neu hochgeladene Scans und GPO-Auswertungen automatisch ISO-Kontrollen zu, solange der neue Schalter `Map new scans automatically` in der Data-Hub-Kachel `ISO Control Corpus` aktiv ist (Standard aus). `server/compliance/regulatory-auto-mapping.ts` liest den Core ausschliesslich ueber `ComplianceReadPort`: alle 10 s die Projekt-, Timeslot- und Scanlauflisten sowie je Timeslot die GPO-Abweichungszeilen als gefilterte Result-DB-Seiten (`audience: result-db`, `sourceKind: policy-evaluation`, `deviation: true`), weil GPO-Backups keinen Scanlauf erzeugen. Je neuem, nicht abgeloesten Scanlauf startet der bestehende Batch ueber dessen Abweichungen; je Timeslot mit neuen GPO-Abweichungszeilen ein Batch ueber dessen GPO-Abweichungen. Bereits zugeordnete Regeln werden wiederverwendet, sodass nur neue Regeln das Modell erreichen; die vorlaeufige automatische Annahme der ersten zwei Vorschlaege gilt unveraendert. Was beim Start oder Einschalten existiert, ist die Basislinie und wird nicht nachtraeglich zugeordnet; ohne aktiven Korpus warten neue Uploads, bis die Zuordnung verfuegbar ist. Idempotenzschluessel je Scanlauf bzw. je Menge neuer GPO-Zeilen verhindern doppelte Batches. Der Schalter liegt in der Engine-eigenen Datei `regulatory-corpora/auto-mapping.json` (keine Tabelle, keine Migration) und wird im Corpus-Status als `autoMapping` geliefert. Core-Aenderungen (Platform): Route `PUT /reference-data/iso-corpus/auto-mapping` und Methode `setIsoAutoMapping` im API-Client. Synthetische Tests: Watcher (Standard aus ohne Core-Lesezugriff, Basislinie, neuer Scan, neue GPO-Zeilen mit getrennten Batches, abgeloeste Laeufe, Warten auf Verfuegbarkeit, Persistenz und Ausschalten), HTTP-Route und Klickinteraktion der Kachel. `npm test` mit 2.138 bestandenen und 18 uebersprungenen Tests, beide Produktionsbuilds erfolgreich. Versionsentscheidung: rueckwaertskompatible neue Faehigkeit, Minor 2.19.1 -> 2.20.0. Offen: Der Engine-Abschnitt in `AGENTS.md` nennt den Schalter noch nicht (Governance nicht freigegeben); Darstellung in beiden Themes nicht live geprueft, weil die laufende Anwendung reale Daten enthaelt. Kein Phasenstatus geaendert, kein Reimport. Nachtrag desselben Tages (Nutzerauftrag mit Core-Freigabe Presentation): Das Abschalten der Compliance Engine im Engines-Popup schaltet die automatische Zuordnung serverseitig aus. `src/app/engine-preferences.ts` exportiert dafuer `subscribeEnginePreferences`; das Engine-Modul `src/compliance/ui/auto-mapping-engine-link.ts` wird mit der Data-Hub-Kachel beim App-Start geladen und sendet beim Wechsel von an nach aus einmal `setIsoAutoMapping(false)`. Erneutes Einschalten laesst die Zuordnung aus; laufende Batches werden nicht abgebrochen. Die lokale Engine-Wahl wirkt damit auf eine serverweite Einstellung (bei gemeinsamem Server fuer alle Nutzer). Dauerhafter Interaktionstest ueber das Engines-Popup (aus sendet einmal, an sendet nichts, andere Engine sendet nichts); `npm test` mit 2.140 bestandenen und 18 uebersprungenen Tests, beide Produktionsbuilds erfolgreich; Version bleibt 2.20.0 (derselbe noch nicht festgeschriebene Stand). Zweiter Nachtrag (Core-Freigabe Governance): `AGENTS.md` haelt Schalter, Watcher, Basislinie, Wiederverwendung und die Kopplung an das Abschalten der Compliance Engine als Nutzerentscheidung vom 2026-10-08 fest; der offene Punkt dazu ist erledigt.

2026-10-07 - Ingest / PingCastle-HTML-Gesamtstruktur aus Configuration-DN (Nutzerentscheidung Option 2; Core-Freigabe Ingest, Normalization, Core Tests; Produktversion 2.19.1): Der PingCastle-HTML-Bericht enthaelt kein Feld fuer den Gesamtstrukturnamen, nur die Gesamtstruktur-Funktionsebene. Vollstaendige DNs `CN=Configuration,DC=...` stehen nur in PingCastles eingebetteten Graphdaten (`<script type="application/json" data-pingcastle-selector=...>`); im sichtbaren Text ist der DC-Teil abgeschnitten. Extraktor 2.4.0 liest diese Bloecke als inerte Daten (hoechstens 64 Bloecke, je 5 Mio. Zeichen, nur `JSON.parse`, nur Zeichenketten `nodes[].name`), nimmt jeden DN der Form `[CN=...,]CN=Configuration,DC=...` und leitet daraus die Gesamtstruktur-Stammdomaene ab, weil der Configuration-Namenskontext stets unter ihr liegt. `forest.name` entsteht nur, wenn alle Fundstellen dieselbe Stammdomaene nennen; es traegt `derivation: configuration-partition-dn`, die Bezeichnung `Derived from the configuration partition path`, die Fundstellenzahl und den Quellpfad der ersten Fundstelle. Widersprechende Stammdomaenen ergeben die Warnung `pingcastle-forest-root-conflict` und keinen Wert; fehlende, abgeschnittene, nicht-JSON- oder unlesbare Daten ergeben keinen Wert. Nie aus dem Domaenennamen geraten. Profil PingCastle 1.7.0 mit append-only Manifest (`reimportRequired`, `environment-context`). Nachtrag mit Core-Freigabe Presentation: Client Info (Domain Information und Directory) waehlt fuer `Forest` zuerst eine native Beobachtung ohne Ableitung (PingCastle-XML, Purple Knight) und erst sonst die abgeleitete; eine abgeleitete zeigt nach dem Wert gedaempft `(derived from configuration path)` ueber das neue optionale Feld `note` von `DashboardFact` und die Klasse `.client-fact-note` (vorhandene Tokens `--muted`, `--fw-regular`). Synthetische Renderpruefung: nur abgeleitet mit Hinweis, nativ plus abgeleitet nur nativ, ohne Beobachtung Gedankenstrich. Nachtrag mit Core-Freigabe Core Tests: dauerhafter Verhaltenstest in `tests/features/dashboard-layout.test.ts` (nur abgeleitet mit Hinweis im gerenderten `dd`, nativ vor abgeleitet in beiden Reihenfolgen, nicht beobachtete native Werte ignoriert, ohne Beobachtung Gedankenstrich, nativ ohne Hinweisklasse); `npm test` mit 2.131 bestandenen und 18 uebersprungenen Tests. Offen: der Management Report (`src/reporting/client-report-projection.ts`, Report Engine) liest `forest.name` weiter ohne Vorrang und Hinweis; beide Themes nicht live geprueft, weil die laufende Anwendung reale Daten enthaelt. Verifikation: synthetischer Test fuer Uebereinstimmung, Konflikt und Nichtableitung; Dummy-Bericht ergibt `sevenkingdoms.local` aus vier Fundstellen ohne Konflikt; `npm test` 2.129 bestanden, ein lastbedingter Zeitfehler in `datahub-metrics-prefetch` besteht einzeln; beide Produktionsbuilds erfolgreich. Kein Phasenstatus geaendert.

2026-10-07 - Ingest / PingCastle-XML-Domaenenfakten (Core-Freigabe Ingest, Core Tests; danach Ingest, Normalization, Platform; Produktversion 2.19.1): Der XML-Import legte jedes `HealthcheckData`-Element nur unter einer pfadbasierten Eigenschaft `pingcastle.xml.*` ab; Client Info, Data Hub und Report fanden deshalb weder Domaene noch die uebrigen Domaenenfakten (nur das Scoring las `DomainFQDN` ueber einen Leseadapter). Extraktor 2.3.0 ordnet jetzt ausschliesslich die exakten Top-Level-Blaetter `DomainFQDN`, `NetBIOSName`, `ForestFQDN`, `DomainCreation`, `DomainFunctionalLevel`, `ForestFunctionalLevel`, `SchemaVersion`, `IsRecycleBinEnabled`, `NumberOfDC`, `GenerationDate` und `EngineVersion` denselben Eigenschaften wie der HTML-Import zu (`domain.fqdn`, `domain.netbios_name`, `forest.name`, ...). Originalwert und XML-Pfad bleiben erhalten; Funktionsebenen bleiben die numerischen XML-Codes und werden nicht uebersetzt; `DomainSid` und verschachtelte gleichnamige Elemente erhalten keine semantische Eigenschaft. Profil PingCastle 1.6.0 mit neuem, append-only Manifest (`reimportRequired`, Dimension `environment-context`); da Manifeste je Profil gelten, empfiehlt Data Hub den Reimport auch fuer HTML-Importe, die dadurch nichts gewinnen. Synthetischer Test fuer Zuordnung, ausgenommene SID und verschachtelte Elemente; Pruefung gegen den freigegebenen Dummy-Export. Nachtrag mit Core-Freigabe Core Tests: Die Tests, die PingCastle 1.5.0 als aktuelles Profil pinnten, sind auf 1.6.0 angeglichen; 1.5.0 ist als reimportpflichtig abgesichert. `npm test` mit 2.129 bestandenen und 18 uebersprungenen Tests sowie beide Produktionsbuilds erfolgreich. Versionsentscheidung: rueckwaertskompatible Korrektur, faellt in den noch nicht festgeschriebenen Patch 2.19.1. Kein Phasenstatus geaendert.

2026-10-07 - Phase 7 / Engine-Diagramm: Context -> Report als implementiert (Core-Freigabe Presentation, Core Tests, Platform; Produktversion 2.19.1): In `Engines & relationships` war die Beziehung Context Engine -> Report Engine noch als geplant gestrichelt. Sie ist seit 2.13.0 implementiert: Das Core-Backend liefert die versionierte Context-Publikation (`publishContextReport`) ueber `readContext` an den Management Report, ohne dass eine Engine die andere importiert. Die Beziehung ist jetzt durchgezogen mit der Beschriftung `Published` und entsprechender Detailbeschreibung; keine Beziehung ist mehr als geplant markiert. Der bestehende Diagrammtest prueft das. Ergaenzend neues Onboarding-Dokument `docs/ONBOARDING.md` mit statischen Diagrammen unter `docs/images/onboarding/`. Versionsentscheidung: rueckwaertskompatible Darstellungskorrektur, Patch 2.19.0 -> 2.19.1. Kein Phasenstatus geaendert.

2026-10-05 - Phase 13F / AI-Integration in die Compliance Engine verlegt (Nutzerentscheidung; Core-Freigabe Platform, Presentation, Disclosure, Store, Normalization, Core Tests, Governance; per Test verifiziert; in Produktversion 2.19.0 enthalten, keine weitere Versionserhoehung): Die AI-Uebersicht (Dienst `server/compliance/ai-overview-service.ts`, Modell `src/compliance/ai-overview.ts`, Panel und CSS unter `src/compliance/ui/`) und der Privacy-Safe-Export (`src/compliance/privacy-safe-export.ts`, vorher `src/exports/result-db-copy.ts`) gehoeren jetzt zur Compliance Engine. Der Dienst liest ueber `ComplianceReadPort` und speichert ueber `ComplianceStore` (Postgres und lokal); die Tabelle aus Migration 025 behaelt Namen und Daten und gehoert der Engine, ohne Migration oder Schemaaenderung. Das Core-Repository verliert die AI-Methoden, das Feld im Core-Projektexport und die Loeschkaskade; die Engine liefert die erfolgreichen Laeufe neben dem Core-Export und entfernt Laeufe geloeschter Timeslots beim Start und beim Lesen selbst. `server/ai/litellm-client.ts` bleibt Core und hat einen eigenen Tokenzaehler-Typ. Neue Erweiterungspunkte: Client-Info-Tab `AI Overview` und Result-DB-Aktion `Export JSON`, beide nur bei eingeschalteter Engine. `Export JSON` (Schema 2) enthaelt 1:1, was die KI erhaelt: `aiOverviewInput` aus derselben Funktion, die die AI-Uebersicht hasht und sendet (deterministische Reihenfolge), und `isoMappingQueries` mit jeder verschiedenen ISO-Anfrage und ihren Result-DB-Zeilen; die abgerufenen Kandidatenkontrollen haengen vom Index ab und sind nicht enthalten. Tests verschoben nach `tests/compliance/`; neu: 1:1-Export, Engine-Schalter fuer AI-Tab und Export, Bereinigung geloeschter Timeslots, Core-Export ohne AI-Laeufe. Gesamtsuite gruen bis auf einen lastbedingten Timeout von `sheet-selection-cost` (einzeln 0,7 s gruen); beide Builds, Local-only- und Designpruefung bestanden.

2026-10-05 - Phase 13F / GPO-Einstellungen in den Work-ISO-Facetten (Engine-Arbeit, Nutzerentscheidung Option 1 mit Core-Freigabe Governance, per Test verifiziert): Die Engine liest ueber `ComplianceReadPort` zusaetzlich die internen `policy-evaluation`-Zeilen desselben Projekts und Timeslots, ausschliesslich um die von der Result DB zurueckgehaltene technische GPO-Einstellungs-ID zu erhalten. Damit zaehlt eine GPO-Einstellung exakt wie ihr Work-Datensatz (auch bei gleichem Titel verschiedener Einstellungen), und die Work-Facetten `ISO control`/`ISO theme` finden GPO-Einstellungen. Die ID wird nie angezeigt oder exportiert; Mapping und Entscheidungen bleiben je offengelegtem Titel. Die zugehoerige AGENTS.md-Regel wurde am selben Tag mit erneuter Governance-Freigabe nachgetragen.

2026-10-05 - Phase 13F / GPO-Kontext in der ISO-Mapping-Anfrage (Engine-Arbeit, per Test verifiziert): Die Anfrage einer GPO-Abweichung bestand bisher praktisch nur aus Einstellungstitel und einem festen Beschreibungssatz. Sie enthaelt jetzt aus offengelegten Result-DB-Feldern Einstellungsart (Scope, Auslieferungsmechanismus), Policy-Abschnitt bzw. Registry-Schluessel, den in Woerter zerlegten Einstellungsnamen (`MinimumPasswordLength` -> `Minimum Password Length`, damit auch die Themenerkennung greift), Baseline-Familie, empfohlenen Baselinewert und den bewiesenen Befund (nicht konfiguriert, widerspruechlich oder abweichend). Eine Richtung (schwaecher/staerker) wird nur genannt, wenn der Vergleich sie festhaelt; alle aktuellen Vergleiche sind Gleichheitsvergleiche und beweisen nur `different`, daher wird z. B. nicht behauptet, eine Passwortlaenge liege unter 14. Der Kundenwert wird nie gelesen. Neue Version `REGULATORY_GPO_QUERY_VERSION` (gpo-baseline-context-1.0.0) geht nur in die Mapping-ID von GPO-Regeln ein; der naechste Batch erzeugt GPO-Mappings neu, Scanner-Mappings bleiben wiederverwendet. Bestehende Entscheidungen bleiben je Regel erhalten; die vorlaeufige Auto-Akzeptanz nimmt bei neuen Laeufen bis zu zwei noch unentschiedene Vorschlaege hinzu.

2026-10-05 - Phase 13F / Compliance Engine zaehlt eine GPO-Einstellung einmal (Engine-Arbeit, per Test verifiziert): Die Result DB fuehrt je Baselinevergleich eine Zeile (Beispiel: 127 Zeilen fuer 25 abweichende Einstellungen) und haelt die interne Kennung `gpo-policy-identity-*` zurueck. Die Engine fiel dadurch fuer GPO auf die vergleichsbezogene `sourceResultId` zurueck und zaehlte im Client-Info-Bereich `ISO controls` und im Batch (`Eligible/Unsupported findings`) je Vergleich. Neu identifiziert die Engine eine GPO-Einstellung ueber Scope und offengelegten Titel (die technische Einstellungsidentitaet), wenn keine oeffentliche Kennung vorliegt; `Filtered results` bleibt die Result-DB-Zeilenzahl. Keine Core-Aenderung. Offener Befund: Die Work-Facetten `ISO control`/`ISO theme` ordnen GPO-Einstellungen ueber `sourceRuleId` zu, die in Result-DB-Zeilen fehlt; GPO-Einstellungen erscheinen dort deshalb nicht. Eine Loesung erfordert eine Nutzerentscheidung (Read-Port-Vertrag oder Result-DB-Offenlegung).

2026-10-05 - Phase 13B / GPO-Domaenenschluessel aus Backup-GPO-Ordnern (Core-Freigabe Normalization, Ingest, Core Tests; per Test und am gespeicherten Artefakt inhaltsfrei verifiziert): Ein Standard-`Backup-GPO`-Ordner nennt die Domaene in `bkupInfo.xml` per `GPODomainGuid` und in `Backup.xml`/`GPReport.xml` per DNS-Name. `aggregateGpoBackupMetadata` verglich `domain-guid:` und `dns:` als einen Wert und meldete `gpo-metadata-domainKey-conflict`; jede GPO blieb mit `metadata-conflict` unaufgeloest und blockiert, Data Hub zeigte `Limited analysis`. Seit dd92aa2 (2026-09-06, DNS auch aus `Backup.xml`/`GPReport.xml`) betraf das jeden Standardexport. Korrektur: GUID und DNS-Name sind zwei Kennungsarten derselben Domaene; ein Konflikt besteht nur bei zwei verschiedenen Werten derselben Art, die GUID hat Vorrang. Append-only `gpo-backup-policy-analysis` und Jobprozessor 2.2.5 -> 2.2.6; betroffene Backups zeigen `Reprocessing required` (kein Upload, keine SQL-Migration, Metadatenparser 1.4.0 unveraendert). Lokale Backup-Zeiten ohne Zeitzone bleiben wie bisher unaufgeloest. Zwei synthetische Regressionstests (Standardlayout aufgeloest; abweichende DNS-Namen neben GUID weiterhin blockiert). Gesamtsuite: ein nicht zugehoeriger Fehlschlag (`unified-result-jsonl` erwartet Disclosure-Policy 3.5.0, paralleler Arbeitsstand 3.6.0). Produktversion nicht angehoben, da der Bereich Platform nicht freigegeben war.

2026-10-06 - Phase 13F / Windows-Code-Bedeutungen in der GPO-ISO-Mapping-Anfrage (Engine-Arbeit, per Test verifiziert): Die Anfrage nennt zu Einstellungsname und empfohlenem Baselinewert jetzt die dokumentierte Bedeutung standardisierter Windows-Codes aus derselben Liste, die der Finding Reader anzeigt (`src/shared/windows-codes.ts`): `Setting name: Se Backup Privilege (Back up files and directories)`, `*S-1-5-32-544 (Administrators)`. Nur feste oeffentliche Microsoft-Namen; Domaenen-SIDs werden wie bisher nur ueber ihre Standard-RID benannt, der Kundenwert wird nie gelesen. `REGULATORY_GPO_QUERY_VERSION` 1.0.0 -> 1.1.0; der naechste Batch erzeugt GPO-Mappings neu, Scanner-Mappings und bestehende Entscheidungen bleiben. Keine Core-Aenderung, keine Produktversionsanhebung (Engine-Verfeinerung im laufenden Stand 2.19.0). Korrektur desselben Tages: Die GPO-Query-Version ging nur in die Mapping-ID ein, nicht in das eindeutige Identitaetstupel der Tabelle `assessor_regulatory_mappings` (rule_key, corpus_version, retrieval_version, prompt_version, model). Ein Neulauf alter GPO-Regeln scheiterte daher mit `Regulatory mapping identity conflicted with another pipeline tuple.`. GPO-Laeufe speichern ihre `promptVersion` jetzt als `1.2.0+gpo-baseline-context-1.1.0`; Scanner-Laeufe und alle IDs bleiben unveraendert, keine Migration. Zweite Korrektur: Entscheidungen gelten global je Regel, das Fenster `Map ISO controls` listete aber nur Kontrollen des aktuellen Laufs. Eine von einem frueheren Lauf automatisch akzeptierte Kontrolle, die der neue Lauf nicht mehr abruft, blieb in der Finding-Reader-Sektion `ISO controls` (ohne Titel) und liess sich nicht ablehnen. Die Antwort traegt jetzt `earlierControls` (entschiedene, im aktuellen Lauf nicht abgerufene Kontrollen, Titel aus aelteren Laeufen der Regel); das Fenster zeigt sie unter `Earlier decisions` mit Accept/Reject, die Sektion uebernimmt ihren Titel. Synthetischer Interaktionstest (Reject auf einer frueheren Kontrolle) und Servicetest. Dritte Korrektur: Der Store verlangt, dass eine Entscheidung auf einen Lauf zeigt, der die Kontrolle abgerufen hat (`Decision control was not a grounded candidate.`); eine Entscheidung zu einer frueheren Kontrolle verweist deshalb auf den neuesten aelteren erfolgreichen Lauf der Regel, der sie abgerufen hat. Der Servicetest lehnt die fruehere Kontrolle jetzt ab.

2026-10-06 - Phase 6 / Result DB: eine GPO-Zeile je Einstellung wie Work, Disclosure Policy 3.8.0 (Nutzerentscheidung Option b nach Zaehlvergleich Work 948 / Result DB 1.111 auf Dummy-Daten; Core-Freigabe Normalization, Disclosure, Core Tests, Governance; per Test verifiziert): Ersetzt den Eintrag 3.7.0 darunter. Fehler in 3.7.0: Die offengelegte Zeile traegt keine technische Setting-ID, daher fasste der Inhaltsvergleich auch verschiedene Einstellungen mit gleichem sichtbarem Inhalt zusammen (710 statt 929 bewerteter Einstellungen sichtbar). Jetzt gruppiert `materializeResultDb` GPO-Vergleiche nach Projekt, Aggregationslauf, Scope und technischer Identitaet (nur zur Gruppierung, weiterhin zurueckgehalten), wie Works `settingKey`. Die Zeile nennt alle verglichenen Baseline-Familien, fuehrt jede eindeutige Erwartung, uebernimmt das staerkste Urteil in Works Reihenfolge, behaelt die ID des Vergleichs, den Work zuerst referenziert (Compliance-Engine-Verweise bleiben gueltig), und vermerkt `baseline-comparisons-combined` im Trace. Erwartete Restdifferenz zu Work: Einstellungen mit `No baseline rule` oder `Not comparable` haben keinen Baselinevergleich und sind keine Result-DB-Vergleichszeilen. Produktversion weiterhin nicht erhoeht (Platform nicht freigegeben). Test: `tests/domain/result-db-materialization.test.ts`, inklusive verschiedener Einstellungen mit identischem sichtbarem Inhalt.

2026-10-06 - Phase 6 / Result DB: identische GPO-Vergleichszeilen zusammengefasst, Disclosure Policy 3.7.0 (Nutzerentscheidung; Core-Freigabe Disclosure, Normalization, Core Tests, Governance; per Test verifiziert): Die GPO-Evaluation speichert je verglichenem Baseline-Release einen Vergleich. Da die Result DB nur die Baseline-Familie offenlegt, erschienen Vergleiche derselben Einstellung gegen mehrere Releases als identische Zeilen (lokal inhaltsfrei gezaehlt: 3.873 GPO-Zeilen, 2.762 davon inhaltsgleich mit einer anderen Zeile derselben Einstellung). `materializeResultDb` speichert GPO-Vergleiche derselben Einstellung und desselben Zeitfensters, deren vollstaendige offengelegte Zeile identisch ist, jetzt einmal und vermerkt `identical-comparisons-collapsed` im inhaltsfreien Trace. Andere Baseline-Familie, Erwartung, Ergebnis oder Diagnose behalten ihre eigene Zeile; Scannerfindings werden nie zusammengefasst; ein echtes GPO-Duplikat bleibt ein Vergleich mit `Duplicates`. Damit gilt die bisherige Regel "Result DB zaehlt einzelne Vergleiche" fuer diesen Fall nicht mehr (AGENTS.md ergaenzt). Die Policy-Erhoehung baut die gespeicherte Result DB ohne Reimport neu auf. Produktversion nicht erhoeht: `package.json` (Platform) war fuer diese Anfrage nicht freigegeben; Patch-Erhoehung im naechsten Release-Batch vorgesehen. Test: `tests/domain/result-db-materialization.test.ts`.

2026-10-06 - Phase 13F / Client-Info-Abschnitt `ISO controls` nach Themen gruppiert (Nutzerentscheidung Option B nach Feedback "wird zu gross"; Core-Freigabe Governance, Presentation; per Test verifiziert): Statt einer Kachel je akzeptierter Kontrolle zeigt der Abschnitt die Kontrollen nach ISO-27002-Thema in ISO-Reihenfolge (Themen ohne Treffer entfallen). Jede Themenueberschrift nennt Kontroll- und eindeutige Findinganzahl und oeffnet Work mit `Deviation` und dem Thema in der Facette `ISO theme` (neue Drilldown-Verdrahtung in `DashboardPanel.tsx`). Darunter fliessen kompakte Zeilen in Spalten doppelter Kompaktkachelbreite, nach Findinganzahl sortiert: Annex-A-ID, vollstaendiger umbrechender Titel, dekorativer neutraler Mengenbalken (`--client-info-neutral`, relativ zur groessten Kontrolle) und massgebliche Zahl; eine Zeile oeffnet Work wie bisher die Kachel. Die Projektregeln halten die Entscheidung neben der unveraenderten vom 2026-10-05 fest. Verifikation: `npm test` mit 2.122 bestandenen und 18 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich; inhaltsfreie DOM-Messung im laufenden Client bei 1440 px: drei Spalten je Thema, kein Abschneiden, kein Ueberlauf, 14/16-px-Rollen. Beobachtung: bei 20 Kontrollen 622 px Hoehe, weil lange Titel in rund der Haelfte der Zeilen umbrechen; die gruppierte Darstellung ist nicht automatisch niedriger als die Kachelflaeche. Nachtrag desselben Tages (Nutzerauftrag, nur Engine-Code): Der Mengenbalken ist entfernt; die Zeile zeigt nur noch ID, Titel und Zahl. Messung bei 1440 px: 601 px statt 622 px; der Titel erhaelt 336 px statt rund 266 px, die Haelfte der Zeilen bricht weiterhin zweizeilig um, weil die ISO-Titel lang sind. Der Projektregeltext nennt den Balken noch und wird erst mit erneuter Governance-Freigabe angeglichen. Zweiter Nachtrag desselben Tages (Nutzerauftrag mit Core-Freigabe Governance): Je Thema erscheinen die sechs Kontrollen mit den meisten Findings (`ISO_CONTROLS_PER_THEME`); darunter erweitert `Show all N controls` dieses Thema und `Show top 6` klappt es wieder ein (`aria-expanded`). Jedes Thema startet fuer einen neuen Timeslot eingeklappt, eine gespeicherte Entscheidung laesst ein geoeffnetes Thema offen; die Themenueberschrift oeffnet weiter alle Kontrollen des Themas in Work. Der Regeltext ist angeglichen (Balken entfernt, Begrenzung ergaenzt). Synthetischer Interaktionstest fuer Begrenzung, Erweitern, Erhalt nach Entscheidung und Einklappen. Messung bei 1440 px: eingeklappt 459 px mit 11 Zeilen, erweitert 633 px mit 20 Zeilen; kein Abschneiden oder Ueberlauf, Button 28 px/13 px. Dritter Nachtrag desselben Tages (Nutzerentscheidung: eigene Compliance-Zeile, Kachelfakten Controls/Findings/zwei Themen; Core-Freigabe Presentation, Governance): Die Liste steht nicht mehr in der Seite. Client Info zeigt eine Zeile \`Compliance\` mit einer Kachel je Rahmenwerk in exakt der Umgebungskachel-Geometrie; die Kachel \`ISO 27001/27002\` zeigt \`Controls\`, \`Findings\` und die zwei Themen mit den meisten Findings (Gedankenstrich waehrend des Ladens), ihr \`Results\`-Fenster die vollstaendige Themenliste ohne Begrenzung; Themenueberschrift und Zeile schliessen das Fenster und oeffnen Work. Die Sechserbegrenzung entfaellt. \`DashboardFactList\`, \`DashboardGlyph\` und \`DashboardFact\` liegen jetzt im Core-Modul \`src/features/dashboard/ClientTileParts.tsx\` (Presentation), damit die Engine sie ohne Zirkelimport wiederverwendet; \`DashboardPanel\` re-exportiert \`DashboardFact\`. Nebenbei behoben: ein Einfuegefehler des zweiten Nachtrags hatte die Hover-Regel der Themenueberschrift zerstoert, sodass Themennamen immer unterstrichen waren. Synthetische Interaktionstests: Kachelfakten, Gedankenstrich beim Laden, Fenster ueber den \`Results\`-Button, Drilldown aus Zeile und Thema mit Schliessen, Neuladen nach Entscheidung, leerer Zustand. Messung bei 1440 px: Kachel 260 x 260 px wie die Umgebungskacheln, vier Fakten in 14/16 px ohne Scrollen, gesamte Zeile 308 px statt 601 px; im Fenster 20 Zeilen in zwei Spalten ohne Abschneiden oder Ueberlauf, Escape schliesst. Die Zeile hat eine eigene Klasse \`client-compliance-grid\` mit einem separaten Regelblock gleicher Werte in \`datahub.css\`; ein erster Versuch mit der gemeinsamen Klasse \`client-environment-grid\` liess bestehende Core-Tests sieben statt sechs Umgebungskacheln zaehlen und wurde verworfen. Live erneut gemessen: sechs Umgebungskacheln, ISO-Kachel 260 x 260 px mit gleicher Flaeche, Titelgroesse und linker Kante. Helles Theme nicht gesondert geprueft; die Kachel nutzt dieselben Tokens wie die Umgebungskacheln. Vierter Nachtrag desselben Tages (Nutzerauftrag, nur Engine-Code): Die Kachel zeigt nach \`Controls\` und \`Findings\` alle vier Themen in ISO-Reihenfolge, je mit Findinganzahl (\`0 findings\` ohne Treffer, Gedankenstrich beim Laden). Ein Thema mit Treffern ist ueber die ganze Zelle klickbar und oeffnet Work mit \`Deviation\` und dem Thema in \`ISO theme\` (bestehende Verdrahtung); ein Thema ohne Treffer ist nicht klickbar, weil die Facette nur Werte mit Treffern anbietet. Hover aendert nur die Flaeche, Tastaturfokus zeigt den blauen Ring. Die Engine rendert dafuer das Faktenraster selbst mit denselben Klassen statt \`DashboardFactList\`; fuer diese Kachel bleiben alle sechs Fakten auch unterhalb der 294-px-Schwelle sichtbar, unter der Umgebungskacheln zwei zeigen. Messung: bei 1440 px Kachel 260 x 260 px, bei 1920 px 300 px, jeweils sechs Fakten ohne Scrollen oder Ueberlauf; alle vier Ecken jeder klickbaren Zelle treffen den Button; ein echter Klick oeffnet Work mit gesetzter \`ISO theme\`-Auswahl. Der Projektregeltext nennt noch "die zwei Themen mit den meisten Findings" und wird erst mit Governance-Freigabe angeglichen. Nachtrag mit Core-Freigabe Governance, Platform: Die Projektregeln halten die Vier-Themen-Kachel als spaetere Entscheidung desselben Tages fest. Die Produktversion bleibt 2.19.0, weil die Versionsvertragstests (`tests/app/app-version.test.ts`, `tests/server/assessor-http-server.test.ts`) zum Bereich Core Tests gehoeren, der nicht freigegeben war; der Patch-Schritt auf 2.19.1 steht weiter aus. Produktversion unveraendert 2.19.0; ein Patch-Schritt steht aus, weil Platform fuer diese Anfrage nicht freigegeben war. Kein Reimport, keine Datenaenderung.

2026-10-02 - Nutzerwunsch fuer spaeter dokumentiert: automatische Security-Baseline-Updates als zurueckgestelltes Arbeitspaket in Phase 13B, mit Phase-10-Backend und Phase-7-Anzeige. Datenqualitaet, Herkunft/Version/Format/Vollstaendigkeit, Erhalt der letzten gueltigen Baseline und unveraenderte historische Auswertungen sind Abnahmekriterien; Quellen und Intervall bleiben offen. Ausschliesslich Planaufnahme, keine Implementierung, Automatisierung oder Produktversionsaenderung.


2026-10-01 - Phase 13E / Vokabular anhand zweier Result-DB-Exporte des Nutzers erweitert (Engine-Arbeit, per Test verifiziert): Der Nutzer stellte zwei gefilterte Result-DB-Exporte (zusammen 953 Abweichungen) zur Analyse bereit; gelesen wurden Tool, Regel-ID und Regeltext, nichts davon wurde gespeichert oder in Code oder Tests uebernommen. Vorher blieben ueber Katalog und Vokabular 498 offen (GPO 449, Purple Knight 22, PingCastle 15, Maester 12), danach 26 (14, 7, 2, 3; die Simulation beruecksichtigt keine GPO-Katalogregeln, Anker, Aehnlichkeit oder Kategorien, die echte Engine liegt darunter). Klarstellung: `purple-knight-ad`/`-entra` sind nur Bezeichnungen der Result-DB-Projektion; die Engine liest die interne Tool-ID `purple-knight`, die Katalogregeln greifen. Ergaenzt: Kontorichtlinien-Schluessel (Password Guessing), Benutzerrechte `Se...Privilege` (Host Credential), Anmelderechte und DCOM-Gruppe (Lateral Movement), `SeEnableDelegationPrivilege` (Delegation), UAC-Werte, gespeicherte Browser-Passwoerter, Druckertreiber-Installation (Host Credential), LAPS/`AdmPwd`, NTLM-Audit-Werte und Alerts (Detection), Office-Sicherheitspfade, Internet Settings/ZoneMap (Malicious Code), Bildschirmsperre (Physical), AD-Berechtigungsdelegation und Kontrollpfade (AD Privileged), Aenderungsindikatoren (AD Persistence), Seamless SSO, Security Defaults und Modern Authentication (Cloud Sign-in), App-Registrierung (App Consent), Skype-Foederation und Speicheranbieter (External Access), MailTips (E-Mail), Customer Lockbox (Data Sharing), RMAU und SSPR fuer privilegierte Rollen (Cloud Privileged), NTFRS und nicht unterstuetzte Windows-Versionen (Patch Drift); Pfadmuster greifen auch am Schluesselende. Vertrauenswuerdige Standorte nur im Office-Sicherheitspfad, weil Conditional Access den Begriff anders nutzt. Aenderungsindikatoren werden jetzt AD Persistence zugeordnet (vorher bewusst offen). Praezision an allen 332 Katalogtexten 100 %, alle katalogisierten Registry-Ziele widerspruchsfrei. `npm test` gruen (1.774), Typpruefung, beide Produktionsbuilds. Server-Neustart noetig. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Registry-Policy-Bereiche im Vokabular (Engine-Arbeit, per Test verifiziert): Anlass: Eine GPO-Abweichung unter `...\Internet Settings\Zones\2\1201` (Internet-Explorer-Zonenaktion, ActiveX) blieb trotz vollstaendiger Raw Data in `Other Deviations`, weil das Vokabular keine Begriffe fuer diesen Policy-Bereich kannte. Ergaenzt um Registry-Pfadsegmente und Wertnamen der Microsoft-Baselines, die genau einen Angriffsweg benennen: IE-Zonen/ActiveX/URL-Aktionen, Defender-Pfade, Makro-Werte, Attachment Manager, Safer/SrpV2/AppLocker/WDAC (Malicious Code); `WindowsFirewall` (Lateral Movement) und deren `Logging` (Detection); PowerShell-Protokollierung (Detection, ohne ExecutionPolicy); Lanman, Hardened Paths, DNS-Client, Drucker, NetBT (Credential Relay); CredentialsDelegation, DeviceGuard, Installer, LSA-Schutz (Host Credential); DataCollection/CloudContent/Telemetrie (Data Sharing); WindowsUpdate (Patch Drift). Ganze Produktbaeume wie Office oder Edge werden bewusst nicht zugeordnet, weil der Katalog selbst eine Office-Einstellung Host Credential zuordnet. Messung: alle katalogisierten Registry-Ziele ohne Widerspruch (10 von 11 erkannt, die Office-Einstellung bewusst nicht), alle 332 Katalogtexte weiter 100 % praezise, Abdeckung 73,2 %. Dauertests fuer den Zonen-Pfad und den Abgleich mit den katalogisierten Registry-Zielen. `npm test` gruen (1.772), Typpruefung, beide Produktionsbuilds. Server-Neustart noetig. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Zweite Fehlerbehebung Context-Abruf unter Last (behoben und per Test verifiziert, Live-Pruefung nach Server-Neustart offen): Nach dem Neustart antwortete `/assessment-context` einzeln mit HTTP 200 (erster Aufruf 9 s, danach 0,2 s aus dem Zwischenspeicher), scheiterte aber beim Oeffnen des Dummy in der App nach 32 s mit HTTP 500, waehrend die Core-Ladevorgaenge parallel liefen; kurz zuvor war der Server einmal nicht erreichbar (`ERR_CONNECTION_REFUSED`, Ursache nicht belegt). Wahrscheinliche Ursache: Seit der Template-Aenderung lud jeder Context-Abruf parallel zu den uebrigen Abfragen alle Microsoft-Baseline-Analysen samt ADMX-Katalogen ueber den kleinen Nur-Lese-Pool. Korrektur in `context-run.ts`: Baseline-Templates und Raw Data werden nur geladen, wenn nach dem ersten Durchlauf Abweichungen ohne Katalogzuordnung bleiben, nacheinander und nach den uebrigen Abfragen; Baseline-Analysen nur fuer die Baselines, mit denen die offenen GPO-Einstellungen verglichen wurden, einzeln. Beim Dummy entfallen beide Abfragen. `npm test` gruen, beide Produktionsbuilds.

2026-10-01 - Phase 13E / Fehlerbehebung Context-Abruf HTTP 500 nach Raw-Data-Lesen (behoben und per Test verifiziert, Live-Pruefung nach Server-Neustart offen): Nach dem Neustart lieferte `/assessment-context` fuer Dummy HTTP 500 nach etwa 7 s. Ursache (aus dem Pool-Aufbau abgeleitet, nicht im Serverprotokoll belegt): Der Raw-Data-Lader lief parallel zu sieben weiteren Abfragen auf dem Nur-Lese-Pool mit hoechstens 2 Verbindungen und 5 s Verbindungs-Wartezeit (`server/reporting/report-read-runtime.ts`). Derselbe Lauf ueber die HTTP-API (ohne diesen Pool) war fehlerfrei. Korrektur in `context-run.ts`: Raw Data wird erst nach den uebrigen Abfragen und nur dann gelesen, wenn Abweichungen ohne Katalogzuordnung bleiben (beim Dummy entfaellt das Laden); scheitert das Lesen, rechnet die Engine ohne Raw Data weiter und meldet `rawDataRead: false`, statt den Context abzubrechen (Test). Simulation am Dummy mit ausgeblendeten Maester-Katalogregeln: Raw Data gelesen, 69 von 73 Maester-Abweichungen zugeordnet, davon eine ueber ein Raw-Data-Feld. `npm test` gruen (1.765), beide Produktionsbuilds.

2026-10-01 - Phase 13E / Context Engine liest alles, was Raw Data zeigt (Nutzerentscheidung, Engine-Arbeit, per Test verifiziert): Raw Data in Work zeigt `record.fields` der Work-Datensaetze (`src/features/dataset-viewer/RawDataView.tsx`), erzeugt von `loadCanonicalProjectWorkspace`. `context-run.ts` nutzt jetzt denselben Lader lesend ueber den Nur-Lese-Port (wie die Report Engine im Backend) und uebergibt fuer jede Abweichung alle Felder ihres Work-Datensatzes ohne Kuerzung: Scanner-Datensaetze ueber die Finding Occurrence, GPO-Datensaetze ueber Scope und technische Identitaet. Die fruehere Variante mit den Originalfeldern der Occurrence und 4000-Zeichen-Grenze entfaellt. Reihenfolge bei Scanner-Befunden und GPO-Einstellungen: Regeltext bzw. Einstellungsname, Beschreibung/Empfehlung bzw. Registry-Pfad und Baseline-Template, jedes kurze Feld bis 200 Zeichen (ein Begriff, Beleg nennt Feld), ganzer Datensatz (zwei verschiedene Begriffe eines Clusters), technische Anker; die Aehnlichkeitsstufe nutzt die kurzen Felder mit. Nur Abweichungen ohne Katalogzuordnung werden so gelesen. Der Grenztest der Context Engine erlaubt unter `src/features` ausschliesslich diesen Lader (Datenprojektion ohne Darstellung); alle anderen UI-Importe bleiben verboten. Verarbeitung vollstaendig lokal im Backend, kein externer Dienst. `npm test` gruen (1.764), Typpruefung, Local-only- und Designpruefung, beide Produktionsbuilds. Server-Neustart noetig. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Context-Erkennung liest den kompletten Datensatz und GPO-Technik (Engine-Arbeit, per Test verifiziert): Nutzerhinweis: Die Erkennung las nur Titel, Beschreibung und Empfehlung; Felder wie Block, Tags oder Testskript eines Maester-Befunds und Registry-Pfad oder Baseline-Template einer GPO-Einstellung blieben ungenutzt. Jetzt liest `context-run.ts` ueber den bestehenden Nur-Lese-Port zusaetzlich die Originalfelder jeder Finding Occurrence (`loadAssessmentModel`, Werte auf 4000 Zeichen begrenzt) und die Template-Namen der Microsoft-Baseline-Einstellungen (`listMicrosoftSecurityBaselineAnalyses`, nur Namen aufgeloester Einstellungen). Reihenfolge fuer Scanner-Befunde: Regeltext, Beschreibung/Empfehlung (zwei Begriffe), jedes kurze strukturierte Feld bis 200 Zeichen (ein Begriff, Beleg nennt Feld und Begriff), gesamter Datensatz (zwei verschiedene Begriffe eines Clusters), technische Anker; die Aehnlichkeitsstufe nutzt die kurzen Felder mit. GPO-Einstellungen: Einstellungsname, dann Registry-Pfad und Baseline-Template-Namen als technischer Anker (zum Beispiel `...\Power\PowerSettings\...` oder `... - BitLocker`). Vokabular 1.1.0 ergaenzt um BitLocker/FVE, Ruhezustand, DMA, Sperrbildschirm/Kamera/Biometrie (Physical & Local Access), EventLog-Pfad (Detection) und Outlook-Add-ins bzw. von Nutzern installierte Apps (App Consent). Praezision an allen 332 Katalogtexten weiter 100 %, Abdeckung 72,9 %. Synthetische Tests fuer Tag-Feld, langes Skript mit zwei und mit einem Begriff, Registry-Pfad und Template-Name. Kundendaten aus den Nutzerbeispielen wurden nicht gespeichert. `npm test` gruen (1.763), Typpruefung, Local-only- und Designpruefung, beide Produktionsbuilds. Server-Neustart noetig. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Katalog 1.9.0 mit E-Mail-Cluster, Vokabular 1.1.0 und Regelfamilien (Engine-Arbeit, umgesetzt und per Test verifiziert): Anlass: Beim Nutzer blieben viele Maester-Abweichungen zu Exchange Online und Defender (zum Beispiel DKIM) in `Other Deviations`, weil der Katalog keinen E-Mail-Angriffsweg kannte und Maester-Kategorien die Regel-ID selbst enthalten (jede Kategorie einmalig, keine Mehrheit moeglich). Neu: Cluster `Email Spoofing & Phishing Exposure` mit den Bedingungen Absenderauthentifizierung (SPF/DKIM/DMARC), Bedrohungsschutz (Anti-Phishing, Safe Links/Attachments, Malware-/Spamfilter) und externe Weiterleitung; Quellen MITRE T1566, Microsoft Learn, CISA ScubaGear EXO und Defender. Die Bedingungen sind bis zur Katalogisierung exakter Regeltexte aus einem Scan-Report nur ueber die Erkennung erreichbar (im Bedingungstest ausdruecklich ausgenommen; Regeltexte werden nicht aus dem Gedaechtnis eingetragen). Vokabular 1.1.0: E-Mail-Begriffe (mit Schutz gegen `phishing-resistant` MFA und Skript-Erweiterungen), DLP/Vertraulichkeitsbezeichnungen/Aufbewahrung und Kalenderfreigabe (Data Sharing), Audit-Protokolle von Cloud-Diensten (Detection), Teams-Fremdzugriff (External Access) mit Schutz der AD-Aufklaerung vor `anonymous` bei Besprechungen. Regelfamilien, die Maester in seinen Regel-IDs angibt (`MS.EXO`, `MS.DEFENDER`, `ORCA`, `CIS.M365.2`, `MS.TEAMS`, `CIS.M365.8`, `MS.SHAREPOINT`, `CIS.M365.7`, `MS.POWERPLATFORM`, `CIS.M365.3`), schaetzen einen Cluster nur, wenn Begriff, Anker und aehnlicher Befund nichts liefern (angezeigt als Scanner-Kategorie mit Familie als Beleg, damit keine Core-Aenderung der Methodenliste noetig ist). Kategorie-Mehrheiten brauchen jetzt mindestens zwei Stimmen und die Haelfte. Praezision des Vokabulars an allen 332 Katalogtexten weiter 100 %; keine Regelfamilie widerspricht einer katalogisierten Maester-Regel (Dauertest). End-to-End am Dummy unveraendert bis auf PingCastle (geschaetzt 3 statt 6, 3 ohne Context). Kundendaten wurden nicht gespeichert; alle Tests sind synthetisch. `npm test` gruen (1.760), Typpruefung, Local-only- und Designpruefung, beide Produktionsbuilds. Server-Neustart noetig. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Context Engine 1.10.0: Context fuer jede Abweichung (Nutzerentscheidung "nicht paepstlicher als der Papst", `Core-Freigabe: Governance, Presentation, Core Tests`; umgesetzt und per Test verifiziert, Live-Pruefung nach Server-Neustart offen): AGENTS.md um die Entscheidung ergaenzt; die Trennung der Stufe 2 und "never guessed" sind dafuer abgeloest. Neues Engine-Modul `src/assessment-context/context-assignment.ts` ordnet jede nicht katalogisierte Abweichung in fester Reihenfolge zu: Fachbegriff im Regeltext (recognized), mindestens zwei Begriffe eines Clusters in Beschreibung/Empfehlung oder technischer Anker (recognized), aehnlichster zugeordneter Befund oder Katalogtext per TF-IDF mit Mindestaehnlichkeit 0,2 und mindestens zwei gemeinsamen Fachwoertern (estimated), haeufigster Cluster derselben Scanner-Kategorie im Scope (estimated). Nur Abweichungen ohne verwertbares Signal bleiben in `Other Deviations`. Erkannte und geschaetzte Zuordnungen zaehlen in Clustern, Badges und Facette und tragen `clusterConfidence`, Methode und Beleg; Verdicts, Scores, Result DB und Work-Zaehlungen ausserhalb der Context-Facette bleiben unberuehrt (Invarianztests gruen). Deterministisch: Eingaben werden sortiert, Gleichstaende fest aufgeloest, Test mit umgekehrter Eingabereihenfolge. UI: Badge zeigt `recognized`/`estimated` als gedaempften Text ohne neue Farbe, Finding-Reader-Block `Recognized context`/`Estimated context` mit Methode und Beleg, `Context gaps` wird zur Pruefliste mit Bestaetigen-Haekchen, Vokabelvorschlaegen und gemeinsamem Freigabetext; Tabellenkoepfe der Liste auf 14 px. End-to-End-Messung am Dummy mit jeweils ausgeblendeten Katalogregeln eines Tools: CIS-CAT (268 Abweichungen, ungesehene echte Titel) 133 recognized zu 99 % richtig, 88 estimated zu 78 % richtig, 47 ohne Context; Purple Knight, PingCastle und Maester recognized 100 % (geschoent, Vokabular stammt aus diesen Texten), estimated PingCastle 6 zu 33 %, Maester 13 zu 54 %, Maester 5 ohne Context. Neue Tests `tests/assessment-context/context-assignment.test.ts`, angepasste Engine-, Luecken- und Reader-Tests; `npm test` gruen (1.757), Typpruefung Client und Server, Local-only- und Designpruefung, beide Produktionsbuilds. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Context-Luecken mit Vokabelvorschlaegen und Anzeige der Stufe 2 (umgesetzt und per Test verifiziert, `Core-Freigabe: Presentation`; Live-Sichtpruefung steht nach Server-Neustart aus): Neues Engine-Modul `src/assessment-context/context-gaps.ts`, im Backend von `context-run.ts` berechnet und als `gapReport` mit der Context-Antwort ausgeliefert; der Browser rechnet nichts selbst (Grenztest). Inhalt: Abdeckung je Tool (Abweichungen, katalogisiert, deklarierte Technik, erkannt, Luecken), Liste der Abweichungen ohne Context, Vokabelvorschlaege und haeufige Begriffe ohne eindeutigen Cluster. Ein Begriff wird nur vorgeschlagen, wenn mindestens zwei katalogisierte Texte ihn enthalten und alle demselben Cluster angehoeren; so kann ein Vorschlag dem Katalog nicht widersprechen (Beispiel: `winrm` wird nicht vorgeschlagen, weil der Katalog es zwei Clustern zuordnet). Nichts wird gespeichert: Die Freigabe ausgewaehlter Vorschlaege erzeugt einen Text zum Kopieren; die Begriffe kommen als gepruefte, versionierte Vokabelaenderung ins Repository. Anzeige im Finding-Reader-Abschnitt `Context` (bestehende Andockstelle, kein neuer Core-Import): Block `Automatically recognized (suggestion)` mit Cluster und getroffenem Begriff, getrennt von Badges und Clustern, sowie Button `Context gaps` mit Anzahl, der das gemeinsame schwebende Fenster oeffnet. Styles nur aus bestehenden Tokens. Tests: `tests/assessment-context/context-gaps.test.ts` und ein Bedienungstest in `tests/features/finding-context-layer.test.tsx` (Vorschlag nicht als Badge, Fenster oeffnen, Vorschlag waehlen, Freigabe kopieren). `npm test` gruen (1.753), Local-only- und Designpruefung, beide Produktionsbuilds. In 2.10.0 gebuendelt.

2026-10-01 - Phase 13E / Messung: Context-Erkennung fuer unbekannte Tools (nur gemessen, keine Aenderung): Jedes Tool des Dummy wurde einmal als unbekannt behandelt (seine Katalogregeln ausgeblendet) und die werkzeugunabhaengigen Signale gegen die Katalogzuordnung gemessen (Abdeckung / Praezision). Fachbegriffe im Titel: CIS-CAT 38 % / 94 % an 323 ungesehenen echten Titeln; Purple Knight, Maester und PingCastle 75 bis 100 % / 100 %, aber geschoent, weil das Vokabular aus diesen Regeltexten entstand. Technische Anker aus fremden Katalogteilen (Einstellungsnamen, Registry-Werte, Benutzerrechte ueber `src/shared/windows-codes.ts`): 0 bis 14 % / 77 bis 100 %. Fachbegriffe in Beschreibung und Empfehlung mit mindestens zwei Begriffen je Cluster: 11 bis 32 % / 100 %. Vom Tool erwaehnte ATT&CK-Techniken: 0 % (kein Tool nennt welche). Aehnlichster zugeordneter Befund anderer Tools (TF-IDF): 5 bis 58 % / 0 bis 84 %, verworfen. Kombiniert fuer ein wirklich unbekanntes Tool (CIS-CAT als Referenz): 41 % / 90 %. Ergebnis: 100 % Abdeckung ist ohne Raten nicht erreichbar, weil viele Befunde nur eine Einstellung ohne Angriffsweg nennen. Vorschlag an den Nutzer: Lueckenliste je Tool mit automatisch erzeugten, gegen den Katalog gemessenen Vokabel- und Ankervorschlaegen und gesammelter Freigabe.

2026-10-01 - Phase 13E / Context Engine 1.9.0: selbststaendige Erkennung in zwei Stufen (umgesetzt und gemessen; Anzeige der Stufe 2 offen): Engine-Code ohne Core-Aenderung. Stufe 1 (`techniqueAssignments`): Eine Abweichung, fuer die ihr Scanner eine aktive ATT&CK-Technik deklariert, kommt in den Cluster, den die belegten Katalog-Beziehungen fuer diese Technik nennen, nur wenn genau ein Cluster und dort mindestens zwei Beziehungen sie nennen (17 Techniken, z. B. T1557.001 Credential Relay, T1110.001 Password Guessing, T1021 Lateral Movement); mehrdeutige oder nur einmal genannte Techniken (z. B. T1078.004, T1566), Taktiken, erwaehnte Referenzen und bestandene Ergebnisse ordnen nie zu. Dummy deklariert derzeit keine Techniken; Stufe 1 ordnet dort nichts zu. Stufe 2 (`recognitions`, `recognizedClusterIds`, Vokabular `src/assessment-context/context-recognition.ts` 1.0.0, 96 Begriffe mit Ausschlussmustern): nur fuer Abweichungen ohne Katalog-, Abschnitts- oder Technikzuordnung, aus Regeltext bzw. GPO-Einstellungsname; getrennt von `clusterIds`, Cluster-Zustaenden und Zaehlern, der Befund bleibt in `Other Deviations`. Messung: an allen 332 katalogisierten Regeltexten und Abschnittstiteln Praezision 100 %, Abdeckung 71,7 % (Dauertest); an 288 echten, vom Vokabular ungesehenen CIS-CAT-Titeln des Dummy 58 erkannt, Praezision 87,9 % gegen die grobe Abschnittszuordnung des Katalogs (7 Abweichungen sind Firewall- bzw. Event-Log-Einstellungen, die das Vokabular als Detection erkennt, der Abschnitt aber Lateral Movement zuordnet; die Einzelregel `Firewall Logging` ordnet der Katalog selbst Detection zu); vorher 60,3 %, korrigierte Fehlgriffe als Negativtests festgehalten. 34 nicht katalogisierte Purple-Knight-Regeltitel: 21 mit fachlich stimmigem Vorschlag, 13 bewusst ohne. Abdeckung echter Titel 17,7 %: das Vokabular erkennt nur unterscheidende Fachbegriffe. Neue Tests `tests/assessment-context/context-recognition.test.ts` (Trennung von Stufe 2 und Katalog bei identischen Clustern, Stufe-1-Grenzen); `npm test` gruen (1.747), Typpruefung Client und Server. Offen: Die Anzeige von Stufe 2 in Finding Reader und Work braucht `Core-Freigabe: Presentation`; der laufende Server nutzt die neue Engine erst nach Server-Build und Neustart.

2026-10-01 - Governance / Context-Engine erkennt selbststaendig (Nutzerentscheidung "Weg 1 und 2 umsetzen, so valide wie moeglich", `Core-Freigabe: Governance`): AGENTS.md erlaubt zwei Stufen ueber den Katalog hinaus. Stufe 1: vom Scanner deklarierte, aktive ATT&CK-Technik (exakte ID) ordnet ueber eine katalogisierte Technik-Cluster-Zuordnung zu und zaehlt wie eine Katalogregel; Taktiken und erwaehnte Referenzen ordnen nie zu. Stufe 2: lokale, deterministische Erkennung aus dem Regeltext ueber ein versioniertes Vokabular unterscheidender Fachbegriffe; gekennzeichnet als `automatically recognized`, getrennt vom Katalog, ohne Einfluss auf Cluster-Zustand, Zaehler, Work-Facette, Badges, Score, Result DB und Reports; der Befund bleibt zusaetzlich in `Other Deviations`. Kein externer Dienst, kein KI-Modell. Messung vor Umsetzung mit Dummy: kein Scanner deklariert eine ATT&CK-Technik (Purple Knight 116 von 118 Befunden nur Taktik, PingCastle, Maester und CIS-CAT keine Angabe); Stufe 1 ordnet mit heutigen Daten nichts zu und wirkt erst, wenn Scanner Techniken liefern.

2026-10-01 - Presentation / Context-Badges im Finding Reader untereinander mit Kennpunkt (Nutzerwunsch, umgesetzt und im Browser verifiziert, `Core-Freigabe: Presentation, Core Tests`, in 2.10.0 gebuendelt): Mehrere Context-Badges stehen untereinander statt nebeneinander. Die Aktionszeile beginnt in der Titelspalte (`grid-column: 2 / -1`), damit die Badges buendig mit der Badge-Zeile darueber stehen; AI search, Bookmark und Results bleiben oben rechts. Jeder Context-Badge traegt einen Punkt in der App-ueblichen Punktgroesse `--space-2`. Farbe: neues Rollen-Token `--context-marker`, das auf `--graph-relation` verweist (dieselbe Farbe wie die Context-Knoten in Pathfinder; kein Fokus-, Markierungs- oder Statuston); Nutzerentscheidung nach Abwaegung, weil Blau fuer Fokus und Tabellenzeilenmarkierung reserviert ist. Im dunklen Theme liegt der Ton nahe am Fokusblau; als kleiner Punkt, nicht als Rahmen, bleibt er unterscheidbar. Gemessen mit Dummy bei 1920 px in Dark und Light: linke Kante beider Badges 0 px gegen die Badge-Zeile darueber, 8 px Abstand untereinander, Werkzeuge rechts und oben buendig mit dem ersten Badge. Unter 620 px Breite gilt weiter die bestehende Schmalregel. Neuer Vertragstest `tests/features/context-badge-layout.test.ts`; `npm test` gruen (1.735 bestanden), Typpruefung und Designpruefung bestanden.

2026-10-01 - Phasen 13E / 7: gemeinsame Engines-Steuerung (umgesetzt und verifiziert; Core-Freigabe: Presentation, Core Tests, Governance): Core-eigener Aktivierungsvertrag `src/app/engine-preferences.ts` mit Core/Context/Report, Standard aktiv, Core unveraenderlich aktiv und lokaler Auswahl unter ASSESSOR.engines.v1. Der Engines-Button steht an der frueheren Context-Position und bleibt in beiden Themes blau (dedizierte Rollen als explizite Nutzer-Ausnahme); das gemeinsame Dialog-Popup bietet Checkboxen, Fokusfuehrung, Escape und Rueckkehr zum Button. Context aus unterbindet neue Anfragen, entfernt Reader-Inhalte, Cluster-Facette und Graph-Kontext und bereinigt den Clusterfilter zentral auch ausserhalb von Work. Report aus sperrt die beiden Reportaktionen und deren Anfragepfad; spaete Antworten werden bei ausgeschalteter Engine nicht heruntergeladen. Bereits gestartete Backendlaeufe werden nicht abgebrochen: lokale Aktivierung, keine serverweite Abschaltung und keine API-/Persistenzaenderung. Engine-Code liest den Core-Vertrag; keine neue Engine-zu-Engine-Abhaengigkeit. Permanente synthetische Tests fuer Standard, gesperrten Core, Speicher/Fehlerfall, Filterbereinigung, Reader-Invarianz und Report-Aus/An; Browserpruefung und synthetische Sichtpruefung Dark/Light inklusive unveraenderter blauer Markierung auf Hover, Maus und Tastatur bestanden. Vollsuite: 1735 bestanden, 15 uebersprungen, keine Fehler; beide Produktionsbuilds, Produktversionsvertraege sowie Local-only- und Design-Check bestanden (18 bestehende Design-Treffer). App HTTP 200 und Backend ok. Versionsentscheidung: mit der noch unveroeffentlichten Engine-Faehigkeit in 2.10.0 gebuendelt, keine weitere Einzel-Patchversion. Die allgemeine Phase 13E bleibt in Arbeit; diese Bedienungsstufe ist verifiziert.

2026-10-01 - Phase 13E / Context dauerhaft aktiv und Cluster-Plaketten als Filter (umgesetzt und verifiziert; Core-Freigabe: Presentation, Core Tests, Governance): Der globale Context-Button und die lokale Schalterpraeferenz entfallen. Eine alte gespeicherte Aus-Einstellung wird ignoriert. Finding Reader und Work/Pathfinder laden Context fuer den vorhandenen Scope; Plaketten setzen die exakte Context-Cluster-Facette ueber die bestehende Core-Filteraktion. Der Detailabschnitt bleibt geschlossen und wird nur ueber seine Summary geoeffnet. Ein optionaler App-Kontext haelt den eigenstaendigen Reader ohne Provider unveraendert funktionsfaehig und ohne Context-Anfrage. Veraltete direkte Engine-Erweiterungspunkte in App/FindingReader sind aus dem Architekturtest entfernt; die verbleibende FindingContext-Anbindung bleibt explizit verzeichnet. Tests: permanente synthetische Plakette -> sichtbare Filterauswahl -> Record-Set-Pruefung in beiden Themes, Disclosure und Alt-Praeferenz, Reader-Invarianz ohne Provider; Browserpruefung in Dark/Light mit Maus/Enter/Leertaste bestanden. 72 gezielte Reader-/Architekturtests bestanden; anschliessende Vollsuite 1726 bestanden, 15 uebersprungen, vier Fehler durch fehlenden useOptionalApp-Export in drei alten Test-Mocks. Diese Mocks wurden ergaenzt; der gezielte Nachlauf aller drei Dateien bestand mit 11 Tests, keine verbleibenden bekannten Fehler dieses Laufs. Beide Produktionsbuilds, Local-only- und Design-Check bestanden (18 bestehende Design-Treffer). App HTTP 200, Backend ok. Versionsentscheidung: mit der noch unveroeffentlichten Context-Faehigkeit in 2.10.0 gebuendelt; keine Einzel-Patchversion. Keine Engine-, Daten-, Schema- oder API-Vertragsaenderung. Die uebrigen offenen Phase-13E-Abnahmen bleiben offen; der Layer-An/Aus-Vertrag und der Plaketten-Sprung sind durch die heutige explizite Nutzerentscheidung ersetzt, die fachlichen Grenzen bleiben bestehen.

2026-10-01 - Governance / Core-Regeln werkzeugneutral (`Core-Freigabe: Governance`): AGENTS.md stellt klar, dass die Core-/Engine-Regeln und die Freigabe per `Core-Freigabe: <Bereich>` fuer jeden Coding-Agenten gelten (zum Beispiel Claude Code und Codex), auch ohne die Projekt-Hooks. Ein Agent ohne Hooks bestimmt den Bereich selbst aus `.claude/hooks/core-areas.mjs`, liest die Freigabe nur aus der aktuellen Nutzernachricht und behandelt Shell-Befehle, Skripte und generierte Dateien wie direkte Aenderungen. Die Hooks sind als Claude-Code-spezifisches Sicherheitsnetz beschrieben; kein Agent legt die Freigabedatei an. `npm test` vor jedem Commit ist als werkzeugunabhaengige Pruefung festgehalten. Das Beispiel der Freigabeformel ist auf `Core-Freigabe: Evaluation` vereinheitlicht. Grenze: Fuer Codex bleibt die Einhaltung eine Anweisung ohne technische Sperre; der Codex-Worktree unter `.codex/worktrees/ab89` steht auf `03ea022` und sieht die Regeln erst nach Commit und Aktualisierung.

2026-09-23 (Phase 13F): Token-geschuetzten ISO-Doppel-PDF-Upload, privaten Korpusstand, begrenzten Parserworker, Embeddingfortschritt, Indexvollstaendigkeitsanzeige, versionsgebundene Qdrant-Ersetzung und Aktivierung nach erfolgreichem Indexlauf implementiert. Synthetische HTTP-, UI-, Client- und Indexregressionen ergaenzt; Standardlauf vor letzter Statuspraezisierung 1.584 bestanden/16 opt-in uebersprungen, danach fokussiert 29/29 und beide Typechecks. Beide Builds sowie Local-only-/Designpruefung vor der Statuspraezisierung erfolgreich. Echte Lizenzdateien und Zielserver bleiben fuer eine gesonderte Abnahme unberuehrt. Keine PostgreSQL-Migration und kein Scanner-Reimport.

2026-10-01 - Versionsentscheidung Umgebungskacheln (Nutzerentscheidung): Die Verfeinerung `overflow: auto` und Faktenschwelle `16.25rem` wird in die noch unveroeffentlichte Version 2.10.0 gebuendelt, statt auf 2.10.1 zu erhoehen. `package.json`, `package-lock.json` und der Versionsvertrag bleiben bei 2.10.0 unveraendert.

2026-10-01 - Core Tests / Testvertrag der Umgebungskacheln nachgezogen (`Core-Freigabe: Core Tests`): `tests/features/dashboard-environment-detail.test.ts` verlangt jetzt `overflow: auto`, schliesst `overflow: hidden` fuer die Kacheln aus und prueft die Schwelle `16.25rem`. `npm test` vollstaendig gruen (1.726 bestanden). Versionsentscheidung offen: Die sichtbare Verfeinerung waere eine Patchversion; die Erhoehung betrifft `package.json` (Platform) und braucht eine eigene Freigabe.

2026-10-01 - Presentation / Umgebungskacheln `overflow: auto` und neue Faktenschwelle (umgesetzt und im Browser gemessen, `Core-Freigabe: Presentation`; Testvertrag offen): `src/styles/datahub.css` setzt die sechs Client-Info-Umgebungskacheln auf `overflow: auto`, damit ein laengerer Wert eines anderen Mandanten erreichbar bleibt statt stillschweigend abgeschnitten zu werden. Die Container-Schwelle fuer zwei statt vier Fakten sinkt von `17rem` auf `16.25rem` (Innenbreite). Messung mit Dummy: Vier Fakten passen erst ab etwa 294 px Kachelbreite ohne Scrollen, weil Zeitstempel und zweizeilige Bezeichnungen in der schmalen Spalte sonst umbrechen; ein Versuch mit `13rem` zeigte vier Fakten schon ab 260 px, liess Directory und Resilience bei 1280 und 1920 px Fensterbreite aber 15 bis 18 px ueberlaufen und wurde verworfen. Ergebnis: vier Fakten ab etwa 296 statt 305 px Kachelbreite; bei 260, 290, 294, 310 und 370 px keine Kachel mit Scrollbalken. Bei Full HD (263 px) bleiben es zwei Fakten; vier waeren dort nur mit kleinerer Schrift oder weniger Polsterung moeglich, was die verbindlichen Typografie- und Kachelregeln verbieten. Designpruefung bestanden; `tests/features/dashboard-environment-detail.test.ts` schreibt noch `overflow: hidden` und `17rem` fest und schlaegt bis zur Anpassung (benoetigt `Core-Freigabe: Core Tests`) fehl. Keine Produktversionsaenderung, da der Testvertrag noch offen ist.

2026-10-01 - Presentation / Pruefung `overflow: hidden` der Client-Info-Umgebungskacheln (nur gemessen, keine Aenderung): Im laufenden Server (Port 4173, aktuelles CSS) mit dem freigegebenen Mandanten Dummy technisch gemessen, je Kachel Inhalts- gegen Sichthoehe und Lage aller sichtbaren Kindelemente zum Innenrand, bei 1280, 1920, 2000, 2190 und 2560 px Fensterbreite. Ergebnis: in keinem Fall abgeschnittener Inhalt, kein Element ueber dem Kachelrand, mindestens 102 px freier Raum unter den Fakten. Befund: Die Container-Abfrage `max-width: 17rem` misst die Innenbreite ohne Polsterung; vier Fakten erscheinen erst ab etwa 305 px Kachelbreite, also erst ab rund 2190 px Fensterbreite. Bei 1280 bis 2000 px zeigen alle Kacheln zwei Fakten. Restrisiko: `overflow: hidden` wuerde bei laengeren Werten anderer Mandanten stillschweigend abschneiden; mit Dummy nicht nachweisbar.

2026-10-01 - Governance / AGENTS.md-Umgebungskacheln bereinigt (`Core-Freigabe: Governance`): Die drei Regeln vom 2026-09-25 zu acht, sieben und doppelt breiten Umgebungskacheln tragen jetzt einen vorangestellten Vermerk, welcher Teil abgeloest ist; ihr Wortlaut bleibt unveraendert. Die Regel vom 2026-10-01 nennt nun auch die am Code gepruefte Geometrie der Umsetzung vom 2026-09-29: sechs gleich breite Quadrate in einer Zeile, horizontales Scrollen statt Umbruch, zwei Fakten in schmalen Quadraten (`src/styles/datahub.css`). Offener Befund ohne Aenderung: Die Kacheln setzen `overflow: hidden`; ob langer Inhalt im Quadrat abgeschnitten wird, ist gegen die Regel "kein Abschneiden" visuell noch zu pruefen (siehe offene Abnahme vom 2026-09-29). Keine Anwendungsaenderung, keine Produktversionsaenderung.

2026-10-01 - Governance / Core-Engine-Grenze pruefbar gemacht (umgesetzt und verifiziert, `Core-Freigabe: Governance, Core Tests`): (1) Neuer Core-Bereich `Client Records` in `.claude/hooks/core-areas.mjs` vor Normalization, Store und Presentation: `src/domain/review.ts`, `src/domain/risk-acceptance.ts`, `src/domain/reimport-review-transfer.ts`, `src/persistence/review-store.ts`, `src/features/review-workspace/`, `src/features/dashboard/RiskRegister.tsx`; Aliasse `Client Records`, `Kundendaten`, `Reviews`. Die Server-Persistenz bleibt im Store-Repository. (2) `tests/architecture/core-engine-boundary.test.ts` liest die Engine-Pfade aus derselben Bereichstabelle wie der Guard und prueft: Daten-, Bewertungs- und Regelbereiche importieren keine Engine; uebrige Core-Dateien erreichen eine Engine nur ueber eine von 14 festgehaltenen Andockstellen (Context-Schalter, Work-Facette, Reader-Abschnitt, Pathfinder/Sidebar, typisierter API-Vertrag, Server-Verdrahtung); die Liste kann nicht veralten; Engines importieren einander nicht. Gegenprobe: Entfernen einer Andockstelle laesst den Test mit genauer Angabe fehlschlagen. Befund: Der Core haengt heute an diesen 14 Stellen bewusst von Engines ab; die AGENTS.md-Regel "der Core haengt nie von einer Engine ab" gilt damit fuer die Daten- und Bewertungsbereiche streng, fuer Presentation und Platform nur ueber Andockstellen. (3) `tests/reporting/report-engine-invariance.test.ts`: Ein echter Report-Lauf ueber den Nur-Lese-Port erzeugt beide Reportdateien und laesst Repository-Revision und exportierte Projektdaten unveraendert. AGENTS.md um Bereich und Tests ergaenzt. Hook-Pruefung (39 Faelle) und `npm test` (1.726 bestanden) gruen; `tests/server/node-import-engine.test.ts` fiel einmal unter Volllast aus und besteht einzeln und im Wiederholungslauf. Keine Anwendungsaenderung, keine Produktversionsaenderung.

2026-10-01 - Core Tests / veraltete Tests nachgezogen (umgesetzt und verifiziert, `Core-Freigabe: Core Tests` bzw. `Core Tests, Governance`): Nutzerentscheidung: Fuer die Client-Info-Umgebungskacheln gilt die Umsetzung vom 2026-09-29 mit hoechstens vier Fakten je Kachel; sie ersetzt die Faktenzahlen der AGENTS.md-Korrektur vom 2026-09-25 (Inventory acht, Directory sechs) und gilt nicht fuer Data, Overall Score und Domain Information. AGENTS.md um diese Entscheidung ergaenzt. Angepasst wurden nur Tests, deren Erwartung durch spaetere dokumentierte Entscheidungen ueberholt war: Donut-Vertragstest liest CSS zeilenendenunabhaengig (CRLF bei `core.autocrlf=true`); Kosten-Test prueft den Ergebnisstatus-Cache im ausgelagerten Modul `dashboard-result-state.ts`; Result-DB-Timeslot-Test erwartet den Projektnamen als viertes `openProject`-Argument; GPO-Sichtbarkeitstest oeffnet die Quellzeile im Overall-Score-Results-Fenster (Source Overview entfernt 2026-09-25); Security-Domain-Test und Umgebungskacheltest erwarten sechs Kacheln (`Source metrics` entfernt 2026-09-25) und hoechstens vier Fakten. Kein Anwendungscode geaendert, keine Produktversionsaenderung. `npm test` vollstaendig gruen.

2026-10-01 - Governance / Core-Guard laesst Pruefungen zu (umgesetzt und synthetisch verifiziert, `Core-Freigabe: Governance`): Der Guard sperrte lesende und pruefende Befehle, sobald irgendwo im Befehl eine Umleitung wie `>/dev/null` stand und irgendein Core-Pfad vorkam (zum Beispiel `node tests/local-only-check.mjs >/dev/null`, ein Vitest-Lauf mit `--config vitest.config.ts` in einer Wegwerf-Kopie). Damit blockierte er genau die Tests, die bestehende Funktionen absichern. `core-guard.mjs` zerlegt Shell-Befehle jetzt ausserhalb von Anfuehrungszeichen in Teilbefehle und prueft nur echte Schreibziele: Umleitungsziele (nie `/dev/null`, `$null`, `&N`) und Pfade in Teilbefehlen mit Schreibbefehl (`sed -i`, `rm`, `tee`, `Set-Content`, `writeFileSync` usw.). `npm install/ci/uninstall/update/version` gilt als Platform-Aenderung an `package.json`/`package-lock.json`. Repositoryweite Git-Operationen, Schutz der Freigabedatei und alle Bereichszuordnungen bleiben unveraendert. `core-release.mjs` erkennt die Freigabe jetzt auch, wenn in derselben Zeile nach einem Strich oder Satzzeichen weiterer Text folgt (`Core-Freigabe: Shared Kernel – ...`); vorher wurde sie stillschweigend nicht erkannt. Korrektur zum Eintrag in Abschnitt 9: Die Pfadzuordnung liegt in `.claude/hooks/core-areas.mjs`, nicht in `core-guard.mjs`. Verifiziert mit 39 synthetischen Hook-Faellen in einem Wegwerf-Projektordner: Testlaeufe, Builds, Lesebefehle, Umleitung in den Scratchpad und Engine-/Doku-Aenderungen passieren; Schreiben per Umleitung, `sed -i`, `rm` nach einem Lesebefehl, `tee`, `writeFileSync` (auch mit `;` in Anfuehrungszeichen), `npm install`, `git reset --hard`, PowerShell-Schreib-Cmdlets, Edit auf Core, Governance, unregistrierte Quellpfade und die Freigabedatei werden gesperrt; Freigabe mit Folgetext, eigener Zeile, mehreren Bereichen, Aliassen, `alle` ohne Governance und Ablauf mit der naechsten Nachricht. Restgrenze: Maskierte Anfuehrungszeichen (`\"`) koennen die Zerlegung verschieben; die Freigaberegel in AGENTS.md gilt unabhaengig davon. Keine Anwendungsaenderung, keine Produktversionsaenderung.

2026-10-01 - Governance / Core-Freigabe per Stichwort (Skripte umgesetzt und synthetisch verifiziert; Registrierung des Nachrichten-Hooks in `.claude/settings.json` steht aus): Nutzerentscheidung nach dem Live-Test der Rueckfragekarte, weil eine Klickfreigabe aus Gewohnheit erteilt werden kann. Eine Core-Freigabe entsteht nur noch durch die Nachricht `Core-Freigabe: <Bereich>[, <Bereich>]`; `alle` gibt jeden Bereich ausser Governance frei. Die Freigabe gilt fuer diese eine Nachricht und verfaellt mit der naechsten. `.claude/hooks/core-release.mjs` (UserPromptSubmit) liest das Stichwort und schreibt die git-ignorierte Datei `.claude/core-release.json`; `.claude/hooks/core-guard.mjs` sperrt Core-Aenderungen ohne passende Freigabe hart statt nachzufragen und zeigt `CORE-ÄNDERUNG GESPERRT` mit Bereich und Stichwort; freigegebene Aenderungen zeigen einen sichtbaren Hinweis. Die Bereichstabelle liegt in `.claude/hooks/core-areas.mjs`. Claude darf die Freigabedatei weder anlegen noch aendern. Verifiziert mit synthetischen Hook-Eingaben in einem Wegwerf-Projektordner: keine Freigabe sperrt, Engine und Doku passieren, Freigabe gilt nur fuer den genannten Bereich und dieselbe Sitzung, mehrere Bereiche mit Komma/`und`, `alle` ohne Governance, repositoryweite Git-Operation nur mit `alle`, Ablauf mit der naechsten Nachricht, Schutz der Freigabedatei (Write und Shell), unbekannter Bereich wird gemeldet, Aliasse (`UI`, `Plattform`), Fehler sperrt. AGENTS.md entsprechend ergaenzt. Keine Anwendungsaenderung, keine Produktversionsaenderung.

2026-10-01 - Governance / Core Engine und Engines (umgesetzt und verifiziert): Nutzerentscheidung zur Benennung (Core Engine, Context Engine) und zur Freigabepflicht fuer Core-Aenderungen in AGENTS.md (neuer Abschnitt "Core Engine and engines") und Abschnitt 9 festgehalten; Risiko in Abschnitt 11. Neuer Projekt-Hook `.claude/hooks/core-guard.mjs`, registriert in `.claude/settings.json` (PreToolUse fuer Edit, Write, NotebookEdit, Bash und PowerShell): Er fragt mit Nennung des Core-Bereichs nach, sobald ein Werkzeugaufruf einen Core-Pfad schreiben wuerde; Context Engine, Report Engine und `docs/` passieren ohne Rueckfrage, Fehler fuehren zur Rueckfrage. Verifiziert mit synthetischen Hook-Eingaben: Core-Dateien mit Schraeg- und Rueckstrichpfaden, Disclosure, Governance, unregistriertes Quellverzeichnis, NotebookEdit, `sed -i`, Umleitung, PowerShell `Set-Content`/`Remove-Item` mit absolutem Pfad und `git reset --hard` fragen nach; Engine-Dateien, Plan-Dokumentation, Dateien ausserhalb des Repositorys, lesende Befehle (`cat`, `grep ... 2>/dev/null`, `Get-Content`, `node -e` mit Pfeilfunktion), `npm test` und `git status` passieren; ungueltige Eingabe fragt nach. Keine Aenderung an Anwendungscode, Daten, API oder Build; deshalb keine Produktversionsaenderung und kein Testlauf der App-Suite.

2026-10-01 - Phase 13E / Context standardmaessig eingeklappt (umgesetzt und verifiziert, in 2.10.0 gebuendelt): FindingContext verwendet eine native details/summary-Disclosure mit dem bestehenden Dreieck und gemeinsamen Tokens. Jeder Finding-Wechsel und erneutes Einschalten startet geschlossen; eine Cluster-Plakette oeffnet vor dem Scrollen. Synthetischer permanenter FindingReader-Interaktionstest fuer beide Themes; synthetische Browserpruefung fuer initial geschlossene Inhalte sowie Maus, Enter und Leertaste in Dark und Light bestanden. 21 gezielte Tests einschliesslich Produktversion UI/API bestanden; beide Produktionsbuilds und Local-only-/Design-Check bestanden (18 bestehende Design-Treffer). Vollsuite: 1713 bestanden, 15 uebersprungen, dieselben 7 dokumentierten vorbestehenden Fehler. Versionsentscheidung: Bestandteil der noch uncommitteten Context-Faehigkeit 2.10.0, keine zusaetzliche Patch-Version pro Einzelschritt. Keine Daten-, API- oder Engine-Aenderung; bestehende offene Phase-13E-Abnahmen bleiben offen.


2026-09-30 - Phase 13E / UI-Stufe Pathfinder (in 2.10.0 gebuendelt, umgesetzt, per Test verifiziert; Sichtpruefung beider Themes steht aus): Bei eingeschaltetem Layer wird jeder Kontext-Cluster mit Befunden im Graphen ein eigener Knoten vom Typ `Context` im Beziehungsring. Jeder Befund, der Belege fuer den Cluster liefert, ist gestrichelt mit ihm verbunden. Cluster ohne Befunde im aktuellen Graphen erzeugen keinen verwaisten Knoten. Ein Klick auf den Cluster-Knoten setzt dieselbe Work-Facette `Context Cluster` wie der Filter; das Graph-Filter-Bridge ordnet einen Cluster-Knoten nie einer gleichnamigen anderen Facette zu. Die Details stehen ausschliesslich im rechten Panel: Zustand, Bedingungen (erfuellt von gesamt, erforderlich, unbekannt), Bedeutung und der Hinweis, dass es sich um eine abgeleitete zweite Lesart handelt. Befund-Details nennen zusaetzlich ihre Cluster. Die bestehenden Pathfinder-Regeln bleiben unveraendert: Text-Schalter, keine Karten im Graphen, Extract Path, Mark all und Reset view. Die Gestaltung nutzt die vorhandene Beziehungsfarbe `--graph-relation` mit groesserem Knotenradius und gestrichelten Kanten; es gibt keine neue Farbe und keine Statusfarbe. Ist der Layer aus, ist der Graph identisch mit dem Graphen ohne Kontext (Test). Tests: Graphaufbau mit und ohne Kontext, Filter-Bridge, Pathfinder-Interaktion mit echtem Engine-Lauf auf synthetischem Befund (Layer an und aus). Volle Suite: 1712 bestanden, 6 bekannte vorbestehende Fehler; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Katalog 1.8.0: GPO-Abweichungen im Kontext, Policy-Analyzer-Suchschluessel ausgeblendet (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, so umsetzen" nach der Feststellung, dass nur 3 von 25 abweichenden GPO-Einstellungen im Dummy einen Cluster hatten. Engine 1.8.0 liest das autoritative, zusammengefasste Baseline-Urteil aus `policy-evaluation` (Abweichung erfuellt die Bedingung, Passed widerlegt sie) und leitet nichts neu her. Den technischen Zielpfad liefert fuer schluesselbasierte Identitaeten wie SrpV2 die neue Lesemethode `listPolicyEvaluations` im Nur-Lese-Port. Katalog 1.8.0 enthaelt 15 Bedingungen und 42 Urteilsregeln: privilegierte Benutzerrechte, Delegierungsrecht, Netzwerk- und lokale Anmelderechte, Ueberwachungsrichtlinie, Firewall-Logging und -Profile, DNS-Client, Softwareeinschraenkung/AppLocker, Sperrzeiten, Kennwortlaufzeit, umkehrbare Speicherung, Anmeldezeiten und Office-Formularanmeldung. Dazu kommt die GPO-Auffangbedingung. Der spezifischste Schluessel entscheidet; katalogisierte Wertsemantiken haben Vorrang. Der Reader zeigt `Evaluated by ASSESSOR` mit dem Urteil. Ausserdem wurde nach Nutzerwunsch der Block `Policy Analyzer search key` im Reader-Kopf ausgeblendet; die Ableitung bleibt erhalten. Nur-Lese-Lauf gegen den Dummy-Client: alle 477 Abweichungen in Work sind in einem fachlichen Cluster (452 Scanner, 25 GPO), der Auffang-Cluster bleibt leer; Revision unveraendert. Volle Suite: 1708 bestanden, 6 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Context-Badges im Finding Reader (in 2.10.0 gebuendelt, umgesetzt, per Test verifiziert; Sichtpruefung steht nach Neustart des laufenden Backends noch aus): Nutzerwunsch: Die Kontext-Cluster eines Befunds erscheinen als etwas groessere Badges links in der Aktionszeile des Finding Readers (vor AI search). Sie nutzen denselben Kontextabruf und dieselbe Zuordnung wie der Context-Abschnitt, springen per Klick dorthin und erscheinen nur bei eingeschaltetem Layer. Die Gestaltung verwendet nur vorhandene Tokens: neutrale Kontur, 14px Semibold, kein Statusfarbton, Hover nur ueber die Flaeche. Der Abnahmetest `Reader ausserhalb des Kontexts mit Layer an und aus identisch` behandelt die Badges als Kontext-Element.

2026-09-30 - Phase 13E / Katalog 1.7.0: jede Abweichung im Kontext (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Jeder Fail oder jede Abweichung ist ein Befund, wird nicht in Frage gestellt und gehoert in einen Cluster; der Kontext ist das zentrale Werkzeug fuer die scanneruebergreifende Struktur. Das ersetzt die polaritaetsbasierten Ausschluesse aus Katalog 1.6.0; AGENTS.md wurde angepasst. Umsetzung: Die Bedingungen sind so formuliert, wie der Befund es aussagt. Beispiele: `LAN-Manager-Ebene unter NTLMv2 only, LM & NTLM verweigern` (zweite Bedingung auf derselben GPO-Semantik), `LDAP-Signierungsdurchsetzung nicht aktiviert`, `automatische Anmeldung nicht ausdruecklich abgeschaltet`, `Global-Admin-Anzahl ausserhalb der Empfehlung`. Engine 1.7.0 ordnet in dieser Reihenfolge zu: exakte Regel-ID; bei CIS-CAT sonst der spezifischste Abschnittstitel aus dem eigenen Report (75 Titel, zum Beispiel Printers, Microsoft Defender Antivirus, Remote Desktop Services, Data Collection and Preview Builds); sonst der sichtbare Cluster `Other Deviations (not yet catalogued)`. `warning` zaehlt jetzt wie `fail` als Abweichung. Katalog 1.7.0 bringt 54 Bedingungen und 38 exakte Regeln sowie die neuen Cluster Data Sharing & Privacy, Physical & Local Access, Patch & Configuration Drift und Other Deviations. Der Reader zeigt die Zuordnung ueber den Report-Abschnitt beziehungsweise `deviation not yet catalogued` an. Tests: Die Engine-Tests wurden auf die neue Regel umgestellt, darunter bleibt eine umnummerierte oder unkatalogisierte Abweichung sichtbar. Neu ist ein Test fuer die Abschnittszuordnung (spezifischster Titel, Elternabschnitt, Vorrang der exakten Regel, Fallback). Nur-Lese-Lauf gegen den Dummy-Client: Jede Abweichung hat einen fachlichen Cluster, der Fallback wird nicht benoetigt (0). 534 Scanner-Befunde sind zugeordnet, davon 288 ueber den Report-Abschnitt, 647 von 885 haben Kontext; alle fachlichen Cluster sind `present`; Revision unveraendert. Volle Suite: 1706 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen (der Abschnittstitel `File Explorer` steht wegen der Kernpruefung kleingeschrieben, der Vergleich ist ohnehin unabhaengig von Gross- und Kleinschreibung).

2026-09-30 - Phase 13E / Katalog 1.6.0 und deklarierte D3FEND-Gegenmassnahmen (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, D3FEND einbauen und uebrige Luecken durchgehen". Engine 1.6.0 gruppiert vom Scanner deklarierte, aktive D3FEND-IDs getrennt von ATT&CK; der Finding Reader zeigt dafuer den Block `Declared D3FEND` mit dem Hinweis `Same countermeasure according to the scanners; not a proven common cause.` Lueckenauswertung: Die ausgefuehrten Befunde ohne Bedingung beim Dummy-Client wurden nach Themen durchgesehen, die in mehreren Scannern vorkommen. Die Bedeutung unklarer Regeln wurde am eigenen Reporttext geprueft. Katalog 1.6.0 ergaenzt 64 Bedingungen mit 113 exakten Regeln. Bestehende Cluster: Credential Relay (u. a. gehaertete UNC-Pfade, SMB-Gastanmeldung, unsichere DNS-Updates, CIS 5.1 Spooler, CIS 18.4.6 NetBT), Kerberoasting (CIS 2.3.11.4 RC4/DES), Password Guessing (Kerberos Armoring), Detection Blind Spots (CIS 17.x, Prozess-Befehlszeile, Sicherheitsprotokoll, NTLM-Audit, Firewall-Logging, Defender for Identity, Entra-Logweiterleitung und Rollenwarnungen), Lateral Movement (LAPS, RDP-Sitzungslimits und -Verbindungsschutz), Host Credential & Privilege (gefaehrliche Benutzerrechte, gespeicherte RDP-Kennwoerter, AlwaysInstallElevated, Remote Credential Guard), AD Privileged (DnsAdmins, Schema Admins) sowie Cloud Sign-in und Cloud Privileged. Neue Cluster: Malicious Code Execution, AD Persistence Indicators, AD Reconnaissance, AD Recovery Gaps, Cloud App Consent und Cloud External Access. Bewusst nicht zugeordnet: PingCastle A-DnsZoneAUCreateChild (der Report stuft ihn selbst als informativ und die Standardkonfiguration als sicher ein); CIS 2.3.11.6 LAN Manager (CIS verlangt Stufe 5, ein Fail auf Stufe 3 oder 4 belegt kein LM/NTLMv1); CIS 2.3.5.4 LDAP-Signierung Enforcement (ein Fail belegt nicht, dass keine Signierung verlangt wird); CIS 18.5.1 AutoAdminLogon (ein Fail belegt nur fehlende Abschaltung); die Global-Admin-Anzahl (ein Fail kann zu viele oder zu wenige bedeuten); MT.INV-Untersuchungen, ablaufende App-Anmeldedaten (Verfuegbarkeit) und reine CA-Pflegeregeln. Der MITRE-Titel T1204.002 steht wegen der Local-only-Pruefung (Muster `File`) als `Malicious file`. Tests: Engine-, Katalog- und Reader-Tests, darunter ein neuer D3FEND-Reader-Test. Nur-Lese-Lauf gegen den Dummy-Client: alle 17 Cluster sind `present`; 208 Scanner-Befunde haben eine exakte Bedingung (vorher 95), 613 von 885 insgesamt Kontext; ausgefuehrte Befunde ohne Bedingung 501 statt 614; Revision unveraendert. Volle Suite: 1705 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / Katalog 1.5.0 Password Guessing Exposure (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Anlass war die Nachfrage des Nutzers, warum ein Befund wie Purple Knight SI000096 trotz ausreichender Angaben im Scan keinen Kontext hat. Die Luecke war eine Katalogluecke und keine Datenluecke. Neuer Cluster `password-guessing-exposure` (MITRE T1110.001/T1110.002) mit neun Bedingungen: Kennwortlaenge unter 14 bzw. unter 8 Zeichen, Komplexitaet aus, Sperrschwelle aus oder ueber 5, kurze Sperr-/Zuruecksetzzeit, schwache Richtlinie fuer privilegierte Nutzer, keine Richtlinie fuer lange Dienstkonto-Kennwoerter sowie die bestehenden Bedingungen fuer nie ablaufende Kennwoerter. Die Zuordnung erfolgt nur ueber exakte Regel-IDs mit dem nativen Regeltext: CIS-CAT 1.1.4/1.1.5/1.2.1/1.2.2/1.2.4, PingCastle A-MinPwdLen/S-PwdNeverExpires/A-NoServicePolicy und Purple Knight SI000096. Die Entra-Regeln EIDSCA.PR01/PR03 (Kennwortschutz) und PR05/PR06 (Smart Lockout) ergaenzen den bestehenden Cluster `cloud-sign-in-protection-gaps`, A-NoServicePolicy zusaetzlich `kerberoasting-exposure`. PingCastle P-ServiceDomainAdmin bleibt bewusst ungemappt, weil ein Pass (weniger als zwei Konten) die Bedingung nicht widerlegt. GPO: Die Kontorichtlinien aus [System Access] (MinimumPasswordLength, PasswordComplexity, LockoutBadCount) sind nun katalogisiert. Engine 1.5.0 liest dafuer nur exakte Ganzzahlen aus `scalar`-Werten; alles andere bleibt `unknown`. Tests: synthetischer Regressionstest mit GPO-Wert und Befunden aller Scanner, inklusive Widerspruch zwischen deklariertem und beobachtetem Wert und `not_run`. Nur-Lese-Lauf gegen den Dummy-Client: der Cluster ist `present` mit 9 von 9 Bedingungen, Entra-Anmeldeschutz 7 von 7. Eine GPO-Sicherung deklariert abgeschaltete Komplexitaet, waehrend CIS-CAT 1.1.5 auf dem Host besteht; das wird als Widerspruch angezeigt. 558 von 885 Scanner-Befunden haben Kontext; Revision unveraendert. Volle Suite: 1704 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen; beide Builds und die Local-only-Pruefung sind gruen. Offen zur Nutzerentscheidung: Gruppierung nach vom Scanner deklarierten D3FEND-Gegenmassnahmen (Purple Knight: 70 Deklarationen in 19 Gruppen).

2026-09-30 - Phase 13E / CIS-Kontrollbereich (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung "Ja, CIS-Kontrollbereich auch einbauen"; sie ersetzt den Vermerk im vorigen Eintrag, dass der CIS-Kontrollbereich nicht gewaehlt wurde. Engine 1.4.0 gruppiert CIS-CAT-Befunde nach der exakten Nummernhierarchie ihrer Regel-ID (`9.1.1` liegt in `9.1` und `9`), und zwar nur innerhalb desselben Scan-Laufs, weil andere Benchmarks dieselben Nummern verwenden. Titel und die vom Scan genannten Pass/Fail-Zahlen stammen aus der gespeicherten Abschnittstabelle `cis-cat-section-scores` desselben Reports (bestehender Helper `cisBenchmarkSectionTitles`); mehrdeutige Titel oder Zahlen entfallen. Dafuer liest der Nur-Lese-Port zusaetzlich `getEnvironmentSnapshot`, begrenzt auf die CIS-Laeufe im Scope. Der Finding Reader zeigt den Block `CIS control area` mit oberstem und naechstem Abschnitt, Anzahl im Timeslot, Fail/Pass und dem Abschnittsscore laut Scan-Report sowie dem Hinweis `Same benchmark section of this scan report; not a proven attack chain.` Tests: synthetische Engine-, Lauf- und Reader-Tests, u. a. fuer die Trennung nach Scan-Lauf und fuer mehrdeutige Tabellenzeilen. Nur-Lese-Lauf gegen den Dummy-Client: 551 von 885 Scanner-Befunden haben Kontext (vorher 171); 160 CIS-Abschnitte, alle mit Titel und Scan-Zahlen, und die Scan-Zahlen stimmen mit den importierten Befunden ueberein; Revision unveraendert. Volle Suite: 1702 bestanden, 7 bekannte vorbestehende Fehler, 15 uebersprungen (node-import-engine unter Volllast zeitweise instabil, einzeln 5/5); beide Builds und die Local-only-Pruefung sind gruen.

2026-09-30 - Phase 13E / deklarierte ATT&CK-Taktik und CIS-Cluster (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Vom Scanner deklarierte ATT&CK-Referenzen duerfen Befunde im Kontext verbinden, und zwar nur `declared`, aktiv und mit exakter ID; die Aussage lautet `gleiche Taktik laut Scanner`, nie `gleicher Angriffsweg`. AGENTS.md und REFERENCE_RECOGNITION.md wurden entsprechend angepasst. Engine 1.3.0 liest dafuer die gespeicherten Referenzlaeufe (neueste Laufe je Scan, nur Befunde des Timeslots; die Lesemethode `listReferenceRuns` wurde im Nur-Lese-Port ergaenzt). Der Reader zeigt den Block `Declared ATT&CK` mit Anzahl, Scannern und Fail/Pass. Katalog 1.4.0 (Nutzerwahl Richtung 1): Relay wurde um mDNS, NetBIOS und WPAD erweitert, Kerberos Delegation um das Hinzufuegen von Computerkonten (SI000011, S-ADRegistration). Neu sind `Lateral Movement Exposure` (RDP ohne NLA, WinRM Basic/unverschluesselt/Remote-Management, SMBv1, Firewall aus bzw. eingehend erlaubt, breite Netzwerk-Anmelderechte), `Host Credential & Privilege Exposure` (gespeicherte Netzwerk-Anmeldedaten, eigene SSPs in LSASS, WinRM-RunAs, UAC) und `Detection Blind Spots` (PowerShell-Logging, A-AuditPowershell, A-AuditDC). ATT&CK-IDs gibt es nur dort, wo MITRE den Zusammenhang dokumentiert (T1021.x, T1555.004, T1547.005, T1548.002, T1557.001); PowerShell-Logging, WPAD und WinRM-RunAs bleiben ohne ID. Der CIS-Kontrollbereich wurde nicht gewaehlt; der ARF-Import wird nicht verfolgt. Nur-Lese-Lauf gegen den Dummy-Client: 171 von 885 Scanner-Befunden haben Kontext (vorher 51), davon 82 ueber Cluster und 116 ueber deklarierte ATT&CK-IDs (beim Dummy deklariert nur Purple Knight); 0 abgewiesen, alle 10 Cluster `present`, Revision unveraendert.

2026-09-30 - Phase 13E / Work-Facette `Context Cluster` (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Die Facette erscheint nur bei eingeschaltetem und geladenem Layer, direkt vor `Source: Scan`. Beschriftet ist sie gemaess der UI-Sprachentscheidung englisch. Sie bietet alle Katalog-Cluster, auch mit 0 Treffern. Ein Record gehoert zu einem Cluster, wenn er Belege liefert: GPO-Zeilen ueber Technical Identity und Scope, Scanner-Befunde ueber die Finding-Occurrence. Die Facette wird zentral in `filterAndSortRecords` und `selectWorkFacets` eingehaengt; Liste, Zaehler, Facettenzaehlung, Sidebar-Domains und Work-Export nutzen denselben Index. Mit ausgeschaltetem Layer entfaellt sie, und diese Pfade laufen wie zuvor. Aenderungen am Assessor-Filtercode sind additiv: optionales `valuesFor` an `DynamicFacet`, optionales `contextClusters` in den Filteroptionen. Abschalten entfernt einen aktiven Kontextfilter ueber den bestehenden Abgleich der Filterleiste. Waehrend der Layer an ist und laedt, bleibt ein gesetzter Filter bestehen; eine Aktualisierung desselben Timeslots nutzt den letzten geladenen Stand weiter. Verifiziert: 5 Facettentests (Dauerpruefung an/aus identisch, exakte Clusterauswahl, alle Cluster, Position vor `Source: Scan`, Entfernen beim Abschalten, Erhalt beim Laden) und ein Grenztest (Client Info, Scoring, Result DB und Server-Persistenz ohne Kontextimport). Vollsuite 1696 bestanden; die bekannten 7 Fehler unveraendert. `tests/server/node-import-engine.test.ts` lief in der Vollsuite einmal in ein Timeout (`STACK_TRACE_ERROR`, keine fachliche Abweichung); einzeln besteht er 5/5. Er beruehrt den Import-Parser und nicht diese Aenderung und ist als zeitabhaengig wackelig vermerkt. Beide Builds, Local-only- und Design-Check bestanden. In der echten App mit dem Dummy-Client: Aus zeigt 477 Befunde ohne Facette; an zeigt 477 Befunde mit Facette vor `Source: Scan` und Zaehlungen je Cluster; `Credential Relay Exposure` gewaehlt zeigt 8 Befunde, und die Sidebar-Domains zaehlen mit; wieder aus entfernt Facette und Filter, und es sind 477 Befunde. Naechster Schritt laut Reihenfolge: Pathfinder.

2026-09-30 - Phase 13E / neue Reihenfolge Schritt 1: AD-Katalog-Batch (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Katalog 1.3.0 mit drei neuen Clustern. `Kerberos Delegation Abuse`: Purple Knight SI000079, SI000080, SI000066, SI000071, SI000070, SI000065, SI000099, SI000016, SI000031 sowie delegierbare Admins (P-Delegated). `AD CS Escalation`: SI000157, PingCastle A-CertTempCustomSubject, SI000156, SI000090, SI000091, SI000095. `Kerberoasting Exposure`: privilegierte SPNs, SI000152, SI000151, SI000067, SI000029. Erweitert wurden `Credential Relay Exposure` um Coercion ueber den Print Spooler auf DCs (SI000077, A-DC-Spooler; T1187) und ESC8 als Relay-Ziel sowie `AD Privileged Account Exposure` um Shadow Credentials (SI000351). ATT&CK-IDs stehen nur dort, wo MITRE die Technik dokumentiert (T1187, T1649, T1558.003). Fuer Delegation nennt keine gepruefte Technik S4U oder RBCD (T1558, T1550.003 geprueft); diese Aussagen tragen deshalb keine ATT&CK-ID und stuetzen sich auf die Microsoft-Doku zu Kerberos Constrained Delegation und den Scan-Report. Ausgeschlossen: A-WeakRSARootCert2 (kein Eskalationspfad). Ein Befund kann mehrere Cluster stuetzen (P-Delegated in zwei). Der Reader-Hinweis nennt jetzt die Abdeckung (`context covers X of Y scanner findings and Z GPO settings`). Ein gehaerteter Relay-Cluster aus reinen GPO-Werten ist jetzt korrekt `undetermined`, weil Spooler und ESC8 nur Scanner belegen; `not-present` ist mit passenden Scanner-Ergebnissen weiter getestet. Verifiziert: Vollsuite 1691 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 51 von 885 Scanner-Befunden zugeordnet (vorher 29), 0 abgewiesen, alle 7 Cluster `present`, Revision unveraendert. In der echten App zeigt der Nutzerbefund `Write access to RBCD on DC` (SI000079) jetzt Kontext; der Hinweis zeigt 51 von 885. Schalter und Suche wurden danach zurueckgesetzt. Naechster Schritt laut neuer Reihenfolge: Work-Facette `Kontext-Cluster`.

2026-09-30 - Phase 13E / Nutzerentscheidung neue Reihenfolge der UI-Stufen: Die Reihenfolge aus Freigabe (b) wird geaendert. Grund: Bei rund 3 % Katalogabdeckung wirken weitere Ansichten leer, und die dauerhafte Pruefung `Layer an/aus identisch` gehoert zur Work-Facette und soll stehen, bevor der Layer in weitere Ansichten wandert. Neue Reihenfolge: (1) AD-Katalog-Batch (Kerberos Delegation, AD CS, Erweiterung des Relay-Clusters um Coercion, Kerberoasting) und ein Hinweis mit Abdeckungszahl im Reader, (2) Work-Facette `Kontext-Cluster` mit dem Test, dass Work-Zahlen, Filter und Status mit Layer an und aus identisch bleiben, (3) Pathfinder, (4) Client Info. Die Freigaben (a) und (c) bleiben unveraendert; Stufe 1 Finding Reader ist erledigt.

2026-09-30 - Phase 13E / Context-Schalter Hover-Korrektur (umgesetzt und verifiziert): Im ausgeschalteten Zustand bleibt der Button auch unter dem Mauszeiger neutral; Gelb erscheint ausschliesslich nach Aktivierung und bleibt bei Hover erhalten. Erneutes Klicken stellt sofort die neutrale Flaeche wieder her. Dauerhafter synthetischer Browsertest `tests/context-toggle-browser-check.mjs` verwendet das originale Toolbar-JSX, den echten Preference-Hook und die App-Styles und prueft Hover, Aktivierung und Deaktivierung in Dark und Light. Beide Themes, 16 fokussierte Tests einschliesslich UI/API-Versionsvertrag, beide Produktionsbuilds und Designcheck bestanden (18 unveraenderte Altbestandstreffer). Versionsentscheidung: kleine Korrektur im laufenden, bereits auf 2.10.0 gesetzten Kontext-Release gebuendelt; kein zusaetzlicher Versionssprung. Kein Eingriff in Report-Implementierung, Engine oder Persistenz; keine neuen fachlichen Risiken, offene Phase-13E-Abnahmen bleiben offen. Der gewuenschte Report-Satz ist ausschliesslich unter offenen Entscheidungen vorgemerkt.

2026-09-30 - Phase 13E / Nutzerentscheidung Scan-Report (Wortlaut): "Explicit user decision 2026-09-30: for every scanner, the official scan report is authoritative. Rule IDs, rule text and outcomes it states are accepted as they are; no separate verification against vendor documentation is required. Exact rule-ID matching and the rule that non-executed checks stay unknown remain unchanged." Umsetzung: Das Belegart-Feld `verifiedAgainst` und die Pflicht einer Dokumentationsquelle je Scanner-Regel entfallen. Eine Scanner-Regel braucht nur exakte Rule-ID, Regeltext aus dem Report und Polaritaet `fail-means-met`; vorhandene Herstellerquellen bleiben als optionale Leseverweise. Exakte Rule-ID-Zuordnung, CIS-Umnummerierungsschutz und `nicht ausgefuehrt = unbekannt` sind unveraendert. Verifiziert mit Tests (eine Regel ohne Dokumentationsquelle ist gueltig; ungueltiger optionaler Link und fehlender Regeltext werden weiter abgewiesen). Katalogversion 1.2.0 bleibt, weil sich keine Zuordnung und kein Ergebnis aendert.

2026-09-30 - Phase 13E / Kontext Schritt 3, weitere Cluster (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Katalog 1.2.0 und Engine 1.2.0 fuehren eigenstaendige Bedingungen ein, die nur Scanner beobachten (ohne GPO-Einstellung). Neue Cluster: `Cloud Privileged Access Exposure` (Maester CISA.MS.AAD.7.4, MT.1025, MT.1027, CISA.MS.AAD.7.3, CIS.M365.1.1.1, CISA.MS.AAD.3.6, MT.1024.adminMFAV2), `Cloud Sign-in Protection Gaps` (CISA.MS.AAD.1.1, MT.1024.blockLegacyAuthentication, CISA.MS.AAD.2.3, MT.1012, MT.1024.signinRiskPolicy, CISA.MS.AAD.3.1, CISA.MS.AAD.3.5) und `AD Privileged Account Exposure` (PingCastle P-Delegated, P-ProtectedUsers, P-AdminLogin; Purple Knight SI000020, SI000028, SI000019). Jede Aussage ist als `favours`/`begünstigt` formuliert und traegt eine geprueft verlinkte ATT&CK-Technik: T1078.004, T1110.003, T1078.002 oder T1558.003. Die Wortwahl-Pruefung hat zwei Aussagen mit `kompromittierter Konten` abgewiesen; sie lauten jetzt `Anmeldungen mit gestohlenen Zugangsdaten`. Bewusst ausgeschlossen: die Global-Admin-Anzahl (CISA.MS.AAD.7.1, MT.1032, CIS.M365.1.1.3), weil ein Fail `zu viele` oder `zu wenige` bedeuten kann. Nutzerentscheidung 2026-09-30: Der offizielle Scan-Report ist massgeblich. Eine dort genannte Regel gilt, auch wenn die Herstellerdoku hinterherhinkt (die veroeffentlichte PingCastle-Liste enthaelt z. B. die P-Regeln nicht). Die Belegart je Scanner-Regel heisst `scanner-report` bzw. zusaetzlich `vendor-documentation`, beide mit gleichem Gewicht; AGENTS.md wurde ergaenzt. Neue Invariante: Jede Cluster-Bedingung hat mindestens eine Belegquelle. Verifiziert: 2 neue Tests, Vollsuite 1691 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 29 von 885 Scanner-Befunden zugeordnet (vorher 9), 0 abgewiesen; alle vier Cluster sind `present` (Relay 4/7, Cloud Privileged 6/6, Sign-in 5/5, AD Privileged 3/4); die Revision blieb unveraendert.

2026-09-30 - Phase 13E / Kontext fuer alle Scans, Schritte 1 und 2 (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Auf Nutzerwunsch erscheint der Abschnitt `Context` jetzt bei jedem Finding aller Scanner; Befunde ohne Katalogeintrag erhalten den Hinweis `not in the context catalog ... yet`. Katalog 1.1.0: Die LLMNR-Bedingung ist praezisiert zu `LLMNR is not turned off` (GPO-Wert 1 erfuellt sie weiterhin), dazu kommen 9 Scanner-Zuordnungen mit exakter Tool- und Rule-ID, Polaritaet `fail-means-met`, Original-Regeltext und Quelle: PingCastle S-OldNtlm und A-NoGPOLLMNR, Purple Knight SI000154 und SI000153, CIS 2.3.9.2, 2.3.8.1, 2.3.11.8, 2.3.5.3 und 18.6.4.4. CIS-Zuordnungen verlangen zusaetzlich den exakten Einstellungsnamen im Befund als Schutz gegen Umnummerierung. Bewusst ausgeschlossen: CIS 2.3.11.6 (Fail heisst nur `nicht Stufe 5`, das beweist keine LM/NTLMv1-Antworten), CIS 2.3.5.4 (Semantik der neuen Enforcement-Einstellung nicht belegt) und Purple Knight SI000188 (anderes Thema). Fuer LDAP-Signierung und Channel Binding gibt es keine belegbare PingCastle-ID; die veroeffentlichte Regelliste ist aelter als A-NoGPOLLMNR, das nativ in den Daten vorkommt. Engine 1.1.0: Beobachtete Fakten (`observed-by-scanner`) stehen getrennt von den deklarierten (`declared-in-gpo-backup`). Fail erfuellt die Bedingung, Pass widerlegt sie, alle anderen Outcomes bleiben unbekannt. Neues Signal `declaredVersusObserved`, wenn GPO-Deklaration und Scanner-Beobachtung auseinandergehen; Anbindung an Scanner-Findings ueber die Finding-Occurrence. Die Timeslot-`scanRunIds` gelten nur fuer Scanner-Befunde, wie in Work. Der Reader zeigt je Bedingung alle Belege nebeneinander. Verifiziert: 5 neue Tests (exakte Zuordnung, Umnummerierungsschutz, gleichlautender Titel mit anderer Rule-ID wird nicht zugeordnet, not_run bleibt unbekannt, Widerspruchssignal, Timeslot-Filter, Scanner-UI). Vollsuite 1689 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check bestanden. Nur-Lese-Lauf gegen den Dummy-Client: 885 Scanner-Befunde, davon 9 zugeordnet und 0 durch den Schutz abgewiesen; der Cluster ist `present` (4 Bedingungen erfuellt, 3 nicht erfuellt, 0 unbekannt); die Revision blieb unveraendert. In der echten App zeigt der PingCastle-Befund S-OldNtlm den Context mit der Beobachtung und dem Cluster; der Schalter wurde danach zurueckgesetzt. Ein Screenshot war nicht moeglich, weil das Pane nicht zeichnete; die Pruefung lief ueber den DOM-Text.

2026-09-30 - Phase 13E / Kontext-Layer Stufe 1 Finding Reader (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Nutzerentscheidung: Die englische Oberflaeche beschriftet den Layer mit `Context` und nutzt die englischen Aussagen (`favours`); `Kontext` und `begünstigt` gelten fuer deutsche Reports. AGENTS.md wurde entsprechend praezisiert. Der Schalter `Context` steht in der Work-Werkzeugleiste neben `My Workspace` im gemeinsamen Button-Stil (aria-pressed, gelbe Aktivmarkierung); Standard aus, lokal je Anwender gespeichert (`ASSESSOR.contextLayer`). Der Abschnitt `Context` im Finding Reader erscheint nur fuer GPO-Datensaetze und nur bei eingeschaltetem Layer, nach Problem, Next step, GPO-Quellen und Wertevergleichen und vor Description und Remediation. Er zeigt die deklarierten Backup-Werte mit Bedeutung und Link-Hinweis, Bedingungen mit Glyph und Text, `favours`-Aussage mit ATT&CK-ID, den Clusterzustand mit Zaehlwerten und die Quellen als https-Links mit `noopener noreferrer`. Nicht katalogisierte Einstellungen erhalten einen klaren Hinweis. Die Darstellung ist eine neutrale Tile-Flaeche ohne Statusfarbe und nutzt nur bestehende Tokens. Die Daten werden einmal je Scope und geladenem Datenstand angefragt, nicht je Datensatz. Verifiziert: 5 Verhaltenstests (aus: kein Request; an: ein Request und Inhalte; der Reader ausserhalb des Abschnitts ist mit Layer an und aus identisch; Abschalten entfernt den Abschnitt; Speicher; keine Filter-, Review- oder Schreibaufrufe im Layer-Code). Echte App mit dem freigegebenen Dummy-Client in Dark und Light: Schalter sichtbar, Abschnitt bei `RequireSecuritySignature` mit Katalogdaten, Abschalten entfernt ihn; Theme und Schalter danach zurueckgesetzt. Vollsuite 1684 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only- und Design-Check (unveraendert 18 bestehende Treffer) bestanden. Offen: In der Backup-Zeile steht die ASSESSOR-Backup-Instanz-ID statt eines GPO-Namens, weil die Beobachtung keinen Anzeigenamen traegt; Pathfinder, Work-Facette und Client Info.

2026-09-30 - Phase 13E / Kontext-Engine und API (in 2.10.0 gebuendelt, umgesetzt und verifiziert; UI-Stufen offen): Neues Modul `src/assessment-context/` mit Katalog 1.0.0, Engine 1.0.0 und `context-run.ts`. Die Engine liest dieselben aktuellen `policy-observation`-Ergebnisse wie Work und deren gespeicherte Identitaetsaufloesung, prueft die Revision vor und nach dem Lesen und erzeugt kein Verdict, keine Prioritaet und keinen Hostzustand. Neuer Endpunkt `GET /api/v1/projects/:id/assessment-context?assessmentIds=...`: Timeslot ist Pflicht (400), Projektpruefung (404), 503 bei nicht verfuegbarer Engine, 409 bei wechselndem Datenstand; begrenzter Cache je Revision und Scope. Er nutzt denselben schreibgeschuetzten Leser wie die Report Engine. Layer-Andockpunkt: `settings` je Technical Identity und Scope, identisch zu den Feldern der Work-GPO-Zeile. Dazu kommen Vertragstyp `AssessmentContextResponse` und Client-Methode `getAssessmentContext`; die UI ruft noch nichts auf. Verifiziert: 12 neue Tests (Katalogvalidierung, Konflikte, unverlinkte Quellen, geloeschte und unbekannte Werte, Clusterzustaende, Determinismus, unveraenderte Eingaben, Revisionspruefung, Architekturgrenze, unveraenderte gespeicherte Daten) und HTTP-Tests. Nur-Lese-Lauf gegen den freigegebenen Dummy-Client: 51 Beobachtungen, davon 3 semantisch zugeordnet und 0 unaufgeloest; der Cluster ist `undetermined`, weil 2 Bedingungen nicht erfuellt und 5 nicht deklariert sind; die Revision blieb unveraendert. Vollsuite 1679 bestanden, dieselben 7 bestehenden Fehler; beide Builds, Local-only-Check (jetzt inklusive `src/assessment-context`) und Design-Check bestanden. Versionsentscheidung: in der noch nicht committeten Release 2.10.0 gebuendelt. Keine Reimport-, Schema- oder Datenbankaenderung.

2026-09-30 - Phase 7 / Report Engine v0.2 (in 2.10.0 gebuendelt, umgesetzt und verifiziert): Die Nutzerentscheidung legt die Kernaussagen Gesamtbild, Schwerpunkt und Aussagegrenze fest, platziert unter den drei Kennzahlen des Management Reports, mit Belegen im Technical Report und im Archiv. `src/reporting/report-narrative.ts` (1.0.0) leitet die Aussagen deterministisch nur aus den Aggregaten ab. Gleichstaende nennen alle beteiligten Domains; Anteile werden exakt verglichen; eine Aussage ohne Datengrundlage entfaellt; es gibt keine Schwere-, Risiko- oder quellenuebergreifende Rangaussage. `report-statement-text.ts` enthaelt die feste deutsche Formulierung fuer beide Renderer. Ein positiver Anteil wird nie auf 0 % gerundet, sondern als `unter 1 %` angezeigt. Die Projektion 1.2.0 fuehrt ID-Listen je Security Domain und je Abdeckungsgruppe; die nicht bewerteten Gruppen zerlegen alle nicht bewerteten Ergebnisse vollstaendig. Management-Renderer 2.1.0 (Block `Kernaussagen`, ohne IDs) und Technical-Renderer 1.1.0 (`Belege der Kernaussagen` mit demselben Satz und den Result-IDs; Result-Index mit Result-ID-Spalte). Report-Engine-Version 0.2.0; das Archiv-Manifest fuehrt die Narrative-Version. Verifiziert: 5 neue synthetische Tests (Zahlen, Gleichstand, Einzahl/Mehrzahl, unter 1 %, fehlende Grundlage, Position unter den Kennzahlen, keine IDs im Management Report, Belege im Technical Report); Vollsuite 1667 bestanden, 15 uebersprungen, dieselben 7 bestehenden Fehler; TypeScript, beide Builds, Local-only- und Design-Check bestanden. Sichtpruefung mit synthetischen Beispieldaten ueber eine voruebergehende lokale Vorschau: Block unter den Kennzahlen im Stil des Abschnitts `Lesart`; bei 375 px kein horizontaler Ueberlauf und 16 px Randabstand. Die voruebergehende Startkonfiguration wurde wieder entfernt. Versionsentscheidung: v0.2 wird mit der noch nicht committeten v0.1 in 2.10.0 gebuendelt, keine weitere Versionserhoehung. Keine Reimport-, Schema- oder Datenbankaenderung.

2026-09-30 - Phase 7 / Report Engine v0.1 (2.10.0, umgesetzt und verifiziert mit einer offenen Teilabnahme): Die Report Engine laeuft eigenstaendig neben ASSESSOR und liest nur. Neu sind der Lese-Port `src/reporting/report-read-port.ts` (nur 11 Lesemethoden, eingefroren, ohne Schreibmethoden) und `report-run.ts` (Revision vor und nach dem Lesen, bis zu drei Versuche, sonst `ReportStateChangedError`/HTTP 409). Server-Adapter: `server/reporting/report-read-runtime.ts` mit eigenem Pool (`default_transaction_read_only=on`, `application_name` assessor-report-reader, max. 2 Verbindungen, keine Migrationen) und `server/reporting/report-archive.ts` (einmalig geschrieben, schreibgeschuetzt, Manifest mit SHA-256, Loeschung mit dem Client, Speicherort per `ASSESSOR_REPORT_ARCHIVE_DIR` bzw. lokalem Anwendungsdatenordner, nie in Repository, Anwendungsordner oder OneDrive). Ergaenzungen ausserhalb der Engine, ohne Aenderung der Assessor-Logik: `PostgresAssessorRepository.openReadOnly` (verweigert beschreibbare Sitzungen und stoesst keinen Result-DB-Neuaufbau an; noetig, weil `create()` schreibt), `sslConfiguration` exportiert, Startverdrahtung (faellt die Engine aus, laeuft ASSESSOR weiter und nur Reportlaeufe werden mit 503 abgelehnt), Archivloeschung beim Loeschen eines Projekts, Projektpruefung mit 404 in beiden Report-Routen, neuer Endpunkt `POST /projects/:id/report-runs`, und `report-projection` liest ueber den Port. Client Info laedt jetzt die serverseitig erzeugte, archivierte Datei; der Browser rendert keine Reports mehr, und der Report-Inhalt ist unveraendert. Compose-Deployment erhaelt ein eigenes Report-Archiv-Volume. Verifiziert: Vollsuite 1662 bestanden (13 neue Tests), 15 uebersprungen, dieselben 7 bestehenden Fehler; TypeScript fuer Client und Server, beide Builds, Local-only- und Design-Check; Architekturtest um Server-Adapter erweitert. Inhaltsfreie Pruefung gegen die kanonische Datenbank ohne Schreibversuch (schreibgeschuetzte Sitzung, Revision unveraendert, keine Schreibmethode erreichbar). Offen: Ausfuehrung des Integrationstests fuer eine abgelehnte Schreibanweisung mit einer Testdatenbank. Versionsentscheidung: Minor-Version 2.10.0 fuer die rueckwaertskompatible neue Faehigkeit (Archiv und Report-Lauf-API), zusammen mit der verhaltensneutralen Verschiebung. Keine Reimport-, Schema- oder Migrationsaenderung, und die Datenbank wird nicht veraendert.

2026-09-30 - Phase 7 / Report Engine Schritt 1: Verschiebung nach `src/reporting/` (umgesetzt und verifiziert): Projektion, Korrelation, Assembler, `client-report-projection` und beide Renderer liegen ohne Logikaenderung in `src/reporting/`, ihre Tests in `tests/reporting/`. Angepasst wurden nur Importpfade (API-Client nur Typimport, DashboardPanel, HTTP-Server). Neuer Architekturtest `tests/reporting/reporting-boundary.test.ts` erzwingt: Aus der Engine importieren nur DashboardPanel, HTTP-Server und API-Client (nur Typen); kein Aufruf schreibender `AssessorRepository`-Methoden; keine Imports aus React/Tauri/pg, `server/`, `src/app` oder `src/components`. Er wurde mit absichtlichen Verstoessen gegengeprueft. `src/reporting` ist zusaetzlich im plattformneutralen Local-only-Check. Verifiziert: Vollsuite 1649 bestanden (vorher 1645, plus 4 Grenztests), 14 uebersprungen; dieselben 7 bestehenden Fehler in 6 Dateien, kein neuer und keiner entfallen. TypeScript fuer Client und Server, beide Produktionsbuilds, Local-only- und Design-Check bestanden. Versionsentscheidung: keine Aenderung der Produktversion, weil es ein verhaltensneutraler Zwischenschritt ist; er wird mit Report Engine v0.1 gemeinsam versioniert. Keine Reimport-, Persistenz-, API- oder UI-Aenderung.

2026-09-30 - Phase 7 / Report Engine entschieden (geplant, keine Umsetzung): Der Nutzer entscheidet die Verschiebung der Report-Bausteine nach `src/reporting/` ohne Logikaenderung, ein serverseitiges unveraenderliches Reportarchiv ausserhalb von Repository und OneDrive (`ASSESSOR_REPORT_ARCHIVE_DIR`, Loeschung mit dem Client) und die vier Grenzen: gemeinsamer Domain-Katalog, Severity nur je Quelle, Review-Status nur als Selbstauskunft und nicht in Report A, Szenarien nur ueber Phase 13E. Einzelheiten und Abnahme stehen in Phase 7, Abschnitt Report Engine. Nur Plan-Dokumentation; Produktversion unveraendert.

2026-09-30 - Phase 13E / Kontext-Engine und abschaltbarer Kontext-Layer (geplant, Nutzerfreigabe, keine Umsetzung): Der Nutzer gibt (a) einen kuratierten, quellenbelegten und versionierten Semantic-/Relationship-/Cluster-Katalog, (b) die Reihenfolge Engine/API, Finding Reader, Pathfinder, Work-Facette, Client Info und (c) die nur bei eingeschaltetem Layer sichtbare Work-Facette `Kontext-Cluster` als Ergaenzung der GPO-Facettenliste frei. Der Kontext ist eine parallele, abschaltbare Lesart ueber gespeicherten Assessor-Ergebnissen. Er veraendert weder Verdict noch Score, technische Filter, Reviews, Result DB oder Priority Findings, und er speist spaeter auch die Report Engine. Kein `CANONICAL_MODEL v2`, weil Observation, Identitaet, Aggregation, Evaluation und Conflict/Duplicate in Phase 13B bereits bestehen. Einzelheiten, Grenzen und Abnahme: Abschnitt Phase 13E. Nur Plan-Dokumentation; Produktversion unveraendert.

2026-09-26 - Phase 6/7 / Scanner-Einstieg, CIS-Abschnitte, Work-Zusammenfuehrung (2.8.6, umgesetzt und verifiziert): Purple-Knight-Umfangsnamen loesen ueber Profil-`runNames` auf; Maester-Abschnitt `Remediation action` als Next step; PowerShell-Skripte nach `script ...:` bzw. mit Variablenzuweisung als Befehlsblock mit Anzeige-Zeilenumbruechen; Purple-Knight-Likelihood ohne angehaengte Referenzen; CIS-Abschnittsnamen aus dem eigenen Scanlauf in `CIS Category`, Work-Ueberschriften und Plaketten-Tooltips; `withRebuiltLayout` erhaelt beim GPO-Anhang alle Datensatzmetadaten. Patchversion, kein Reimport; Details im Statusnachtrag oben.

2026-09-26 - Phase 13D / gemischte Work-Projektion (2.8.5, umgesetzt und verifiziert): Beim Anhaengen von GPO-Ergebnissen an All Records wird referenceRecognition jetzt vom jeweiligen Scannerbefund uebernommen. Zuvor blieben die Referenzlaeufe gespeichert, gingen aber beim Neuaufbau der Reader-Projektion verloren. Die Uebernahme bewahrt Referenzen, Quellenherkunft, Erkennerversion, Lauf und Katalogversion/-hash einschliesslich bewusst leerer Erkennung; GPOs und nicht indexierte Befunde erhalten keine fremden Referenzen. Synthetische Regression oeffnet Referenzdetails im echten FindingReader mit und ohne GPOs. 30 fokussierte Referenz-/GPO-/CIS-Tests und 9 UI-/API-Versionsvertragstests, beide Produktionsbuilds sowie Design-/Local-only- und Diffpruefung bestanden. Patchversion fuer rueckwaertskompatible Projektionskorrektur; keine Datenmutation und kein Reimport bzw. neuer Erkennungslauf erforderlich. Bereits geladene Workspaces muessen neu geladen werden. Phase 13D bleibt in Arbeit.

2026-09-26 - Phase 7 / Finding-Reader-Abstaende (2.8.4, umgesetzt und verifiziert): Die gemeinsame Abschnittsregel umfasst jetzt div und section, damit GPO-Quellen und Baseline-Vergleich denselben Tokenabstand verwenden: space-4 (16 px) vor/nach der Trennlinie, space-2 (8 px) zwischen Feldueberschrift und Text. Redundante Abschlusslinien am letzten Quellblock und letzten Reader-Feld entfernt; Problem-/Next-step-Sonderabstaende bleiben erhalten. Synthetischer permanenter Klicktest prueft den gerenderten GPO-Reader vor, nach und nach erneutem Schliessen des Baseline-Disclosures. 44 gezielte Reader-/UI-/API-Versionsvertragstests, beide Produktionsbuilds, Design-/Local-only- und Diffpruefung bestanden. Synthetische Light-/Dark-Sichtpruefung bestaetigt jeweils rund 16 px Abschnittsabstand. Patchversion fuer die gemeinsame Darstellungskorrektur; keine Daten-, Import-, Bewertungs- oder Persistenzaenderung. Risiko: Die gemeinsame Regel wirkt auch auf weitere native Reader-Abschnitte; fokussierte Reader-Regressionen decken die bestehenden Faelle ab. Phasenstatus unveraendert.

2026-09-26 - Phase 13D / Phase 13C Darstellung (2.8.3, umgesetzt und verifiziert): Catalog references startet bei aktuellem Client eingeklappt; gruen vor Ueberschrift und aktuellem/erfolgreichem Status, orange und automatisch offen bei Handlungsbedarf oder Fehler. Pruefung, Verarbeitung und leere Clients bleiben neutral. Katalogversionen bleiben eingeklappt sichtbar, Erfolg nach Update bleibt offen, manuelles Umschalten funktioniert per Maus und Tastatur. Timeslots-Zeile mit gleichem Abstand oben/unten und gemeinsam zentrierten Controls. Purple-Knight-Timeslots benennen Active Directory, Entra ID oder kombinierten Scope aus bestehenden kanonischen Namen bzw. exakt lauf-/dateigebundenen gespeicherten Metadaten/Umgebungsbeobachtungen. Ohne Scopebeleg bleibt der Originalname; keine Vermutung aus Dateinamen oder fremden Scans, keine Persistenz-/Importer-/Scoringaenderung und keine neue Reimportpflicht. 36 gezielte Interaktions-/Layout-/Versionsvertragstests, beide Produktionsbuilds, Local-only-/Designcheck und synthetische Dark-/Light-Sicht- und Tastaturpruefung bestanden. App und Backend gesund auf 2.8.3 mit kanonischer PostgreSQL. Patchversion fuer zusammengehoerige UI-Korrekturen; Phase 13D bleibt in Arbeit. Die bekannte Gesamtsuite-Baseline mit sechs fachfremden Fehlern wurde nicht erneut ausgefuehrt.

2026-09-26 - Phase 13D Handlungstexte (2.8.2, umgesetzt und verifiziert): Allgemeiner Erklaerabsatz im linken Catalog-references-Bereich entfernt. Please update benennt Handlungsbedarf, Up to date / No action needed. den aktuellen Stand, Update successful den per erneutem Statusabruf bestaetigten Erfolg. Button heisst Update references; ATT&CK-/D3FEND-Versionen sowie Rot-bei-Bedarf/Gelb-sonst bleiben. Leere Clients, laufende Pruefung und Fehler erhalten eigene Texte; bei verbleibender Arbeit wird kein Erfolg behauptet. 25 gezielte UI-/Versionsvertragstests, beide Produktionsbuilds, Local-only-/Designcheck und synthetische Light-/Dark-Pruefung bestanden. Patchversion fuer reine UI-Korrektur, keine reale Nachverarbeitung oder Persistenzaenderung; Phase 13D bleibt in Arbeit. Die bekannte Gesamtsuite-Baseline mit sechs fachfremden Fehlern wurde fuer diese Textkorrektur nicht erneut ausgefuehrt.

2026-09-26 - Phase 13D Status-/Bedienkorrektur (2.8.1): Referenzbereitschaft in Client-Punkt/Manage aufgenommen, asynchron begrenzt geladen und nach Katalog-/Datenupdates sowie Nachverarbeitung aktualisiert. Catalog references auf Nutzerwunsch links ueber Timeslots; Aktionsbutton rot bei Bedarf, sonst gelb. Synthetische Klickpfade, beide Themes und finales Buildpaar verifiziert; bekannte sechs Gesamtsuitefehler unveraendert. Keine echte Client-Nachverarbeitung. Siehe Nachtrag in Abschnitt 8.

2026-09-26 - Phase 13D erster Umfang (2.8.0): ATT&CK 19.2/D3FEND 1.6.0, versionierter frameworkweiter Erkenner, append-only PostgreSQL-Referenzlaeufe und immutable Katalog-Snapshots samt Export, atomare Ableitung im normalen Batchimport, explizite Client-Nachverarbeitung, Pathfinder-/Reader-Anbindung. Migration 023 nach verifiziertem Backup. Historischer Projektexport ergaenzt auch ersetzte Scannerlaeufe und deren Originalfelder, damit alte Referenzlaeufe keine verwaisten Quellen erhalten; durch synthetischen Scanersatz gegen PostgreSQL verifiziert. 48 fokussierte Tests und separat PostgreSQL-Pruefung bestanden; anschliessende Versions-/API-/Reader-Verifikation ebenfalls bestanden. Gesamtsuite: 1569 bestanden, 14 uebersprungen, dieselben 6 vorherigen Fehlschlaege in 5 Dateien (GPO-Evaluation-Visibility 2, Security-Domain-Interaktion 1, AppLocker-HTML-Pruefung 1, Result-DB-Scope-Quelltextpruefung 1, Dashboard-Cache-Quelltextpruefung 1). Keine neu aufgetretenen Testfehler. Client-/Serverbuild, Local-only- und Designcheck bestanden; synthetische Light-/Dark-Sichtpruefung. Bestehende Kundenscans nicht automatisch nachverarbeitet. App/Backend wieder auf 5173/4173 mit kanonischer PostgreSQL gestartet. Die weitergehende Phase 13D und die geplante Client-Datenbanktrennung bleiben offen.

2026-09-26: Nutzerentscheidung fuer das spaetere Zielbild autonomer Client-Datenbanken aufgenommen. Zentrale, unveraenderlich versionierte MITRE-/Microsoft-Referenzkataloge bleiben von clientgebundener Auswahl und Auswertung getrennt; verwendete Referenzbytes gehoeren zur autarken Client-Sicherung. Phase 14 mit Vorarbeiten an Repository-/Artefaktgrenzen, offene Detailentscheidungen und Risiken dokumentiert. Reine Planfortschreibung: keine Anwendungsaenderung, Datenbank-/Schema-/Artefaktmigration, Tests oder Produktversionsaenderung; bestehender Phasenstatus bleibt unveraendert.

2026-09-23: Client Info erhielt Management Report und Technical Report als getrennte HTML-Downloadaktionen. Beide lesen den ausgewaehlten Timeslot vollstaendig ueber die API und ignorieren den momentanen Source-Filter. Report-Projektion 1.1.0 traegt interne technische Fakten nur fuer den Technical-Cut; der Management-Renderer gibt keine Assets aus. Der neue Technical-Renderer listet gespeicherte Originalfelder, GPO-Quellanweisungen, Ist-/Sollwerte, Provenienz, Inventory, Diagnostics und Result-Index; belegte Felddifferenzen bleiben feldspezifisch. Synthetische Klickpfad-/Renderer-Regressionen und beide Produktionsbuilds bestanden; Vollstaendigkeits-/Theme-Abnahme bleibt offen. Kein Kundendatenzugriff oder Bestandsmutation. Minorversion 2.6.0.

2026-09-23: Environment-Results-Tabellenkoepfe berichtigt (Phase 7/13C). Eindeutige Quell-Unterabschnittslabels werden tabellengenau aus behaltenen Beobachtungen derselben Lauf-/Datei-/Abschnittsidentitaet gelesen. `Honey Pot` steht nicht mehr als Sammelueberschrift ueber `Account analysis`; generische `Tabelle n`- und sichtbare `Source table index`-Zeilen entfallen. Zweispaltige Label-Wert-Metadaten und horizontal zusammenbleibende native Kopf-/Datenzellen verbessern die schmale Ansicht. 32 fokussierte synthetische Tests sowie beide Produktionsbuilds, Local-only- und Designcheck bestanden; keine Bestandsmutation oder Kundeninspektion. Patchversion 2.5.15.

2026-09-23: Nutzerkorrektur fuer alle acht Environment-Detail-Results (Phase 7/13C): Statt duplizierter Kachelwerte zeigen die Fenster gespeicherte native Berichtstabellen, Prosa, Original-/Normalbeobachtungen, Erfassungszustand und Quellherkunft; Source Overview umfasst auch unbekannte Abschnitte, die zugrundeliegenden Quell-Findingfelder sowie Source-/Scan-Score-Beitraege. Progressive Zeilen-/Abschnitts-/Findinganzeige bewahrt alle Fakten. Synthetische Klickpfad-, Gruppierungs- und Mehr-als-100-Zeilen-Regressionen sowie beide Produktionsbuilds, Versionsvertrag, Local-only- und Designcheck bestanden. Keine Kundendateninspektion oder Bestandsmutation; keine reale Theme-Abnahme. Die in 2.5.13 dokumentierte Inhaltduplikation ist durch 2.5.14 abgeloest.

2026-09-23: Results-Button der Operating-systems-Kachel als gemeinsame Environment-Detail-Aktion auf alle acht Kacheln ausgedehnt (Phase 7). Quelle und sechs Faktgruppen oeffnen denselben Floating-Window-Typ mit ihren unveraenderten angezeigten Werten; kachelspezifische Dialoglabels, Fokus-Rueckgabe, Scoring-Aktion und schmaler Umbruch sind erhalten. 42 fokussierte Tests, beide Produktionsbuilds, Local-only- und Designcheck bestanden; Gesamtlauf 1.453 bestanden, 13 Skips, fuenf vorbestehende fachfremde Fehler. Keine Kundendaten oder Bestandsmutation. Produktversion 2.5.13.

2026-09-23: Vorherigen Abschluss 2.5.11 fuer den gemeldeten PingCastle-Fall korrigiert (Phase 7/13C und 12/13B). Getrennte HTML-/XML-Vorkommnisse derselben Regel werden in der Work-Leseprojektion berichtsspezifisch abgeglichen; oeffentlich dokumentierte PingCastle-IDs werden in der Result DB mit nativer Gross-/Kleinschreibung sichtbar. Unbekannte IDs bleiben fail-closed, widerspruechliche Titel werden nicht erraten. Synthetische Work-/Result-DB-Regressionen, kein Kundendatenzugriff, keine Migration und kein Reimport. Patchversion 2.5.12, Disclosure Policy 2.5.0.

2026-09-23: Scanner-Ueberschriften zwischen Result DB und Work vereinheitlicht (Phase 7/13C). Work verwendet in Aggregat- und Quellansicht den kanonischen Definitionstitel, den auch die Result DB fuehrt; ein abweichender nativer Scannertext bleibt als `Native source heading` sichtbar und im kanonischen Original unveraendert. Eine synthetische PingCastle-Regression prueft den konkreten regelorientierten Quelltitel gegen den besser zuordenbaren anzahlbezogenen Result-DB-Titel in beiden Work-Pfaden. 42 fokussierte Tests, beide Produktionsbuilds, Local-only- und Designpruefung bestanden; Gesamtsuite 1.448 bestanden, 13 optionale Skips und fuenf bekannte fachfremde Vertragsfehler. Keine Migration, Reimporte oder Bestandsmutation. Produktversion 2.5.11.

2026-09-23: Disclosure Policy 2.4.0 fuer LLM-faehige GPO-Ergebnisse umgesetzt (Phase 12/13B). Technische Settingidentitaet, Pfad, Operation, Typ, Ist-/Sollwert, Vergleich, oeffentliche Baseline, Diagnose, Aussagegrenze und Verarbeitung bleiben nutzbar; Kunden-/Projekt-/Domain-/GPO-/Backup-/Datei-/Locator-/Zeit-/Reviewidentitaet und interne Hash-/Baseline-IDs entfallen. Wohlbekannte Principals bleiben erhalten, Domain-SIDs und konkrete Domainprincipals werden rekursiv und resultlokal pseudonymisiert, einschliesslich Baselinevarianten. Synthetische Disclosure-, sichtbare Result-Row- und JSONL-Regressionen pruefen Nutzbarkeit und Abwesenheit der Identitaeten. 70 fokussierte Tests, beide Produktionsbuilds, Local-only- und Designpruefung bestanden; Work/GPO Analysis und kanonische Originale bleiben unveraendert. Keine Migration, Reimporte oder Bestandsmutation. Produktversion 2.5.10.

2026-09-23: Security-Domain-Klassifikation auf eine gestufte, quellengestuetzte Evidenzlogik erweitert: Kernfelder und Source Rule ID zuerst, danach technische Erklaerung, Rationale, Empfehlung, Remediation, Loesung, Impact und Details nur bei einer eindeutigen Domain. `Unclassified` bleibt bei fehlender oder widerspruechlicher Evidenz erhalten, damit keine Kategorie erfunden wird. Das allgemeine Vokabular umfasst Spooler-Haertung; `A-DC-Spooler` ist nur ein Regressionstest, keine Sonderlogik (Phase 7/13C). Die zentrale Work-Suche wurde zugleich gegen gemischte Gross-/Kleinschreibung sowie Rand-Leerzeichen gehaertet. 44 fokussierte Tests, beide Produktionsbuilds, Local-only- und Designpruefung bestanden; synthetische Regressionen verwenden ausschliesslich Dummywerte. Keine Import-, Persistenz-, Score-, Reimport- oder Bestandsdatenmutation. Produktversion 2.5.9.

2026-09-23: Source Rule ID als gemeinsame sichtbare Scanneridentitaet in Result DB und Work ergaenzt (Phase 7/13C, Disclosure Policy 2.3.0). Result DB traegt eine feste Spalte; Work benennt das kanonisch zugeordnete Quellfeld in der Leseprojektion einheitlich und zeigt es einmal im Finding Reader. Originalfelder bleiben erhalten, leere IDs werden nicht erfunden, GPO-Setting-Identitaeten bleiben fachlich getrennt bezeichnet. Der Scope-Fall fuer Purple Knight AD/Entra/kombiniert behaelt nun ebenfalls gueltige `SI...`-IDs. 133 fokussierte Tests, beide Produktionsbuilds, Local-only- und Designpruefung sowie die ausschliessliche Dummy-Live-Abnahme in beiden Themes bestanden. Gesamtsuite: 1.444 bestanden, 13 optionale Skips und fuenf bekannte fachfremde Vertragsfehler. Keine Bestandsmutation. Produktversion 2.5.8.

2026-09-23: GPO-Vergleiche in Result DB wieder fachlich nutzbar gemacht und Purple Knight for Entra ID als eigenen Result-DB-Quellenscope eingefuehrt (Phase 7/13C, Disclosure Policy 2.2.0). Konkreter Settingtitel/Pfad, Ist-/Sollwert, Baselinevarianten und lesbare technische IDs ersetzen generische Vergleichstitel und leere Detailfelder; interne Hash-IDs entfallen aus der Anzeige. AD, Entra ID und kombinierte Purple-Knight-Laeufe bleiben ein Profil, sind aber getrennt filterbar und lesbar bezeichnet. Historische unspezifische Laeufe werden nicht heuristisch umklassifiziert. Synthetische UI-, Domain-, Export-, Persistenz- und Serverregressionen sowie Live-Abnahme nur auf `Dummy`; keine Bestandsmutation. Produktversion 2.5.7.

2026-09-22: Maester-Darstellung im Work-Finding-Reader an die native Informationshierarchie angeglichen (Phase 7/13C). Die Ueberschrift verwendet `Title` ohne doppeltes ID-Praefix; die ID bleibt als eigene technische Zeile sichtbar, gefolgt von Test result, Test details, Category, Tags und Source. Technische Ausfuehrungsfehler bleiben eingeklappt, waehrend doppelte Index-/Dauer-/Rohfelder entfallen. Statuswerte werden nicht mehr als fehlende Results-Dateiverweise behandelt. `CISA.MS.EXO.17.3` ist als exakte oeffentliche Maester-Regel hinterlegt und fuehrt die AI-Suche zu Microsoft Purview Audit Retention statt Windows Audit Policy. Read-only Bestandspruefung und 83 fokussierte Tests sowie beide Produktionsbuilds bestanden; keine Quellwert-, Import-, Persistenz- oder Bestandsaenderung, kein Reimport.

2026-09-22: PingCastle-Domainzuordnung fuer neun eindeutige Work-Findings erweitert (Phase 7/13C). Obsolete Betriebssysteme, Hardened Paths, Script Engines und CVEs werden System Hardening, LDAP-/TLS-Bindings Authentication & Access sowie OU-Loeschschutz und NTFRS/SYSVOL AD Infrastructure & PKI zugeordnet. Ein synthetischer Verhaltenstest verlangt fuer exakt diese Titel null `Unclassified`; 28 fokussierte Domain-, Sidebar- und Filtertests sowie beide Produktionsbuilds bestanden. Keine Import-, Status-, Score-, Persistenz- oder Reimportaenderung.

2026-09-22: Data-Hub-Reimporthinweise den betroffenen Scans direkt zugeordnet (Phase 7/13B). Der timeslotweite Sammelblock wurde durch eine flache Hinweiszeile unmittelbar unter jeder betroffenen Toolzeile ersetzt; Erklaerung und Reimport-/Uebernahmeaktion bleiben quellenlokal. Responsive Anordnung und synthetischer Quelltext-Verhaltenstest ergaenzt. 61 fokussierte Tests, beide Produktionsbuilds und die Live-Pruefung des Liftket-Timeslots bestanden; ASSESSOR 2.5.6 wird nach gezieltem Neustart von App und PostgreSQL-Backend sichtbar ausgeliefert. Keine Import-, Review-, Persistenz- oder Ersatzsemantikaenderung.

2026-09-22: Maester-`Unclassified` fuer stabile Suitekennungen korrigiert (Phase 7/13C). ORCA/EXO und Entra-Suiten werden in der gemeinsamen Work-/Client-Info-Projektion als enger Fallback `Cloud & Applications` zugeordnet; beschreibende Domainregeln behalten Vorrang. Der synthetische Work-Verhaltenstest deckt ORCA.104, EIDSCA und Conditional Access samt Facettenfilter ab. Keine Persistenz-, Import-, Score- oder Reimportaenderung.

2026-09-22: Produktversion von 2.5.5 auf 2.5.6 angehoben und die kuenftige Versionspflege in `AGENTS.md` verankert. Die zentrale Paketversion, Lockdatei sowie Header-/About- und Health-API-Vertragstests sind synchron; nach jedem materiellen verifizierten Umsetzungspaket ist Patch/Minor/Major bewusst neu zu bewerten. Historische Berichte bleiben unveraendert. Patch-Release, keine Schema-, API- oder Bestandsdatenmigration.

2026-09-22: Nutzerkorrektur zur Scanneridentitaet abgesichert (Phase 13A/13B). `Purple Knight for Active Directory` bleibt in Import, ScanRun, Umgebungsbeobachtungen, Scoring und Darstellung ausschliesslich Purple Knight und ist niemals Maester oder Entra ID. Der irrefuehrend nach Maester benannte Kompatibilitaetsexport der inzwischen werkzeuguebergreifenden Tenant-Zaehlung wurde entfernt. Ein synthetischer End-to-End-Regressionstest prueft Tool-ID, Anzeigename und das Ausbleiben jedes `maester.*`-/`entra.*`-Kontexts; 53 fokussierte Tests gruen. Keine Migration oder Bestandsmutation.

2026-09-22: Purple Knight for Entra ID als eigener Assessment-Scope umgesetzt (Phase 13A/13B). Profil 1.4.0 erkennt die Entra-Summary inhaltsbasiert, persistiert Tenant, nativen Posture-Score, Zaehler und Kategoriescores und bezeichnet ScanRun/Scorequelle getrennt von Purple Knight for Active Directory. Client Info zaehlt und zeigt den Tenant aus der gemeinsamen Environment-Grenze. Synthetische Entra-Summary prueft Erkennung, Provenienz, Scanlabel und nativen Score; zusammen 109 fokussierte Tests und beide Builds gruen. Read-only Bestandsdiagnose: der aktive Liftket-Entra-Lauf besitzt 56 Findings und eine erhaltene generische Summary, aber keine kanonischen Environment-Beobachtungen. Kein stiller Bestandsumbau; Reimport der nicht gespeicherten Originaldateien erforderlich. Keine Migration oder Bestandsmutation.

2026-09-20: Maester-Import mit nativem Unicode-Nullzeichen repariert (Phase 13A/13C). Die reale PostgreSQL-Fehlermeldung belegte `unsupported Unicode escape sequence` fuer `\\u0000` im Finding-JSONB. `escapeJsonUnicodeNulls` arbeitet rekursiv an der kanonischen Modellgrenze und repraesentiert jedes Vorkommen sichtbar als `\\u0000`; `unicode-null-escaped` dokumentiert Anzahl und Darstellung pro Importdatei. Der Auto-Import behaelt eine bereits erfolgreiche Vorschau bei einem Abschlussfehler, statt eine leere Fehler-Vorschau zu erzeugen. 26 fokussierte Maester-/HTTP-Tests, beide Produktionsbuilds, Local-only- und Designpruefung erfolgreich; der einmal parallel gestartete zusaetzliche npm-Testlauf traf einen Windows-`spawn EPERM`, die identischen fokussierten Tests liefen davor und danach erfolgreich. Keine Migration oder Bestandsdatenmutation; laufender Backendprozess benoetigt den aktualisierten Build.

2026-09-22: Nutzbarkeit der LLM-faehigen Result DB nach Nutzerkorrektur wiederhergestellt (Phase 12/13B). Disclosure Policy 2.1.0 behaelt bei CIS-CAT, Maester, PingCastle und Purple Knight redigierte Regel-Titel, Beschreibungen und Empfehlungen; Purple Knight behaelt validierte `SI`-IDs. Typisierte Platzhalter ersetzen identifizierende Inhalte, Assets/Reviewpersonen/Scope-/Provenienzfelder bleiben entfernt, HTML-Regelprosa wird Klartext. Ein synthetischer ResultRow-Test sichert das konkrete Aufklappen mit sichtbarer Empfehlung und verborgenem Konto. 45 fokussierte Tests bestanden. Live: 530/530 Purple-Knight-Zeilen mit aussagekraeftigem Titel, Beschreibung und SI-ID, 501 mit Empfehlung, null Asset-Wiederholungen sowie null E-Mail-/UPN-, Domain-SID- oder Firmensuffixmuster. Keine Migration, Reimporte oder Bestandsmutation.

2026-09-22: Allgemeine LLM-Datenschutzgrenze der Result DB umgesetzt (Phase 12/13B). `result-db-disclosure` 2.0.0 reduziert Scanner-, GPO- und Environment-Zeilen fail-closed auf kontrollierte Metadaten und normalisierte Urteile; Repository/API, Suche, Facetten, Einzelzeile und ResultRow verwenden dieselbe Projektion, waehrend `internal-analysis` Originale fuer Work bewahrt. JSONL 2.0.0 entfernt zusaetzlich alle internen Scope-/Result-/Run-/Artefakt-IDs, Zeitpunkte, Suchtexte und konkreten Filterwerte. Synthetische Regressionen enthalten absichtlich Person, Firmenname, UPN, Domain, SID, Pfad, GPO-/Backupidentitaet und Reviewperson und sichern deren Abwesenheit in Result-DB-UI und Export. 43 fokussierte Tests und beide Produktionsbuilds bestanden; Live-API ueber 14.762 PostgreSQL-Ergebnisse ohne E-Mail-/UPN-, domaenenspezifische SID-, private Zeit- oder gesperrte Inhaltsfelder. Keine Migration, Reimporte oder Bestandsmutation. Gesamtlauf nach Aenderung: 1.429 bestanden, 13 optionale Skips, fuenf bereits vorhandene fachfremde Quelltext-/UI-Vertragstests weiterhin rot; der einzige durch die Datenschutzgrenze betroffene GPO-Detailtest wurde anschliessend fokussiert gruen verifiziert.

2026-09-20: Mengenbalken fuer die Security-Domain-Verteilung in Client Info umgesetzt und nach Nutzerkorrektur von Text und Zahl getrennt sowie mit dem Overall-Score-Donut farblich gekoppelt (Phase 7). `DashboardDomainRow` verwendet seinen ohnehin sichtbaren Abweichungs- oder Review-only-Wert; `DashboardPanel` bildet einmal die Summe der angezeigten Domains und uebergibt sie als Nenner. Ein gemeinsames Vier-Spalten-CSS-Subgrid bemisst Score, laengsten Domainnamen, Balkenflaeche und breiteste gerenderte Zahl. Das dekorative `aria-hidden` Balkenelement belegt ausschliesslich die dritte Spalte, endet bei jeder Zeile an derselben Kante und waechst nach links. `dashboardScoreTone` setzt denselben Overall-Tone am Posture-Bereich und am Donut; alle Balken lesen dessen `--chart-color` exakt, waehrend Domainknoten ihre eigene Tone-Klasse behalten. Ein synthetischer 3:1-Fall sichert exakt `75 %`/`25 %`, alle acht Katalogzeilen sowie Subgrid- und gemeinsame Tone-Geometrie. 23 fokussierte Tests, Designsprachpruefung und Client-/Server-Produktionsbuild bestanden. Live am Dummy: neun getrennte Zeilen, je rund 12 px zwischen Text/Balken und Balken/Zahl, Donut und alle Balken exakt `rgb(232, 33, 79)` in Light/Dark, keine Ueberlaeufe; Light wiederhergestellt. Keine Daten-, Import-, API-, Persistenz-, Schema-, Klassifikations-, Score- oder Drilldownmutation.

2026-09-20: Verbindliche 14-/16-px-Lesetypografie in Client Info umgesetzt (Phase 7, Nutzerentscheidung). `AGENTS.md` unterscheidet nun primaere Informationslabels und strukturierte Tabellen-/Kachelinhalte mit mindestens 14 px von lesbaren Werten und Fliesstext mit 16 px; nur Controls, technische Metadaten und Badges duerfen kompakter bleiben. Environment Detail verwendet die Rollen fuer Faktlabels/-werte, Source-Overview-Metadaten, Operating-systems-Hinweis, Gruppen, Tabellenkoepfe und Quellspalten. Synthetische CSS-Vertragstests sichern die Rollen. 23 fokussierte Tests, Designsprachpruefung und Client-/Serverbuild erfolgreich. Live in Light und Dark: `Domain` 14 px/700, `sevenkingdoms.local` 16 px/400, Source-Information und OS-Tabelle 14 px, kein horizontaler Ueberlauf der Directory-Kachel; Light wiederhergestellt. Keine Daten-, Import-, API-, Persistenz-, Schema- oder Bewertungsmutation.

2026-09-20: PingCastle-Zustandswerte in Client Info ergaenzt (Phase 7, Nutzererweiterung). Die bestehende Operating-systems-Tabelle fuehrt vier neue strukturierte Zahlenspalten `Active`, `Inactive`, `Enabled` und `Disabled`. `operatingSystemInventory` liest die bereits verlustfrei gespeicherten PingCastle-Labels nur aus exakt derselben Source Row wie Betriebssystem und `Nb OS`; mehrdeutige, fehlende, negative oder fremdzeilige Werte bleiben unbekannt. Ein synthetischer Extraktionsfall und zwei UI-/Joinregressionen sichern vollstaendige Darstellung sowie das Verbot quellenuebergreifender Uebernahme. 28 fokussierte Tests, Design-/Local-only-Pruefung und Client-/Serverbuild erfolgreich. Live read-only am Dummy bestaetigt `Windows Server 2019 1809` mit Devices/Active/Inactive/Enabled/Disabled `1/1/0/1/0`, getrennte unquantifizierte Quelle mit Gedankenstrichen, kein horizontaler Ueberlauf bei 568 px sowie lesbare Light-/Dark-Rollen; Light wiederhergestellt. Keine Import-, API-, Persistenz-, Schema- oder Datenmutation.

2026-09-20: Deviation-Anzeige zwischen Data Hub und Client Info vereinheitlicht (Phase 7, Nutzerkorrektur). Die Data-Hub-Statuszeile laedt nun den explizit ausgewaehlten gemischten Timeslot inklusive assessmentgebundener GPO-/Policy-Beobachtungen und wertet dessen Projektblatt mit derselben aus React herausgezogenen Zustandsklassifikation wie Client Info aus. Die Timeslot-Auswahl traegt dafuer neben Run-IDs auch Assessment-IDs; GPO bleibt fachlich eine eigene Quelle und wird nicht in einen Scanner-Run umgedeutet. Client Info verwendet fuer `Deviations` dieselbe `datahub-reference-knob`-Variante ohne lokale Flaechen-/Typografieueberschreibung. Ein synthetischer Mischfall sichert Scanner- plus GPO-Deviations dauerhaft; weitere Quelltext- und Interaktionstests sichern Scope, Rendering und Work-Drilldown. 32 fokussierte Tests, Design-/Local-only-Pruefung und Client-/Serverbuild erfolgreich. Live am Dummy: Data Hub und Client Info jeweils `477 / 1.833 / 26 %`; Light-/Dark-Styles fuer Flaeche, Ring, Padding, Typografie und Farben identisch, Light wiederhergestellt. Keine Daten-, API-, Persistenz-, Schema- oder Bewertungsmutation.

2026-09-20: Violett als UI-Rolle vollstaendig entfernt (Nutzerentscheidung 2026-09-20, AGENTS.md "UI segments and tiles", reiner Darstellungsfix ueber bereits aufbewahrten Fakten). Die violette Akzentfamilie `--accent`/`-hover`/`-active`/`-on`/`-subtle` ist aus `src/styles/ui-tokens.css` geloescht statt umgeleitet, weil jeder ehemalige Verbraucher direkt auf die passende Rolle umgestellt wurde: Tastaturfokus (Eingabefelder, `.segmented__item`) auf `--focus-ring`, Auswahl-/Aktivzustand (Segmented Tabs, Finding-Card-Auswahl, Checkboxen, Ergebnisfenster-Umriss, diverse Hoverzustaende) auf `--marking-color`/`--button-marked-bg`/`--button-marked-text`. Zusaetzlich identifiziert und behoben, weil dieselbe verbindliche Regel jeden violett aufloesenden Token verbietet: die violett getoente Auswahlflaeche `--surface-selected` (jetzt aus `--marking-color` gemischt, betraf u. a. generische `.row`/`.table`-Auswahl, Data-Hub-Verlaufszeilen und die Checkbox-Indeterminate-Flaeche), die violetten Pathfinder-Graph-Knoten-/Kantenfarbe `--graph-relation` sowie der violette Results-Action-Umriss `--border-results-action`/`--text-results-action`, beide neu auf einen dedizierten, nicht-violetten Ton bzw. auf `--marking-color` gestellt, der violette Donut-/Client-Info-Status `--donut-not-applicable` (inkl. der irrefuehrend benannten Alias-Rolle `--client-info-purple`) auf einen dedizierten Rosaton, der violette Diagrammton `--viz-1` auf Oliv-Gruen sowie der zu nah an Violett liegende Orchid-Ton `--viz-6` auf ein eindeutiges Pink. Ein neuer Token `--chart-tone-emphasis` (beide Themes) ersetzt die Wiederverwendung von `--accent` fuer Kategorie-/Chart-Flaechen (PKI-Chart-Ton `.tone-pki`/`.tone-accent`, IOE-Summenzahl, Bar-Track- und Ring-Fallback, `origin-pill.native`). Zwei hartkodierte Hex-Paletten fuer die Fensterunterscheidung gleichzeitig geoeffneter Result-Fenster (`DatasetViewer.tsx`, `MitreGraphView.tsx`, `ObsidianGraphView.tsx`) enthielten ebenfalls violette Eintraege und sind ersetzt. Reine Farbtoken-/CSS-Aenderung ohne Scoring-, Persistenz- oder API-Beruehrung, daher keine Reimport-Manifestversion. Eine bestehende Regression in `tests/features/obsidian-graph.test.ts` pruefte woertlich den alten violetten Hex-Wert und ist auf eine themenoffene, aber violett-ausschliessende Pruefung umgestellt. `npm test`: 1.416 bestanden, 13 uebersprungen, derselbe fachlich unabhaengige, durch isolierten Stash-Vergleich bestaetigte Vorbestand (`tests/features/gpo-xml-presentation.test.tsx`) faellt nachweislich auch ohne diese Aenderung; Client- und Serverbuild erfolgreich. Keine Live-Browserabnahme durchgefuehrt, Verifikation ausschliesslich ueber Tokenverfolgung, Build und Testlauf.

2026-09-18: Client Info tatsaechlich an die freigegebene Ableton-Designsprache angeglichen (Phase 7, Folgeauftrag zur Designverankerung). Gemeinsame Theme-/Statusrollen, flache eckige Tiles, standardisierte Aktionen, kompakte Quellenkacheln, aufklappbare Environment-/Risiko-Details und ruhigere Domaenenzeilen. Die vom Nutzer ausdruecklich geschuetzten Overall-zu-Domaenen-Kurven bleiben dynamisch vermessen. 47 fokussierte synthetische Tests, Client-/Server-Typechecks, separater Client-Produktionsbuild, Design-/Local-only-Pruefung und synthetische Browserabnahme beider Themes bei vier Breiten bestanden. Keine Daten-, Scoring-, API-, Persistenz- oder Dienstenaenderung. Einschraenkungen und Messumfang im aktuellen Status und Risikoabschnitt dokumentiert; Phasenstatus unveraendert.

2026-09-18: Ableton-Designvertrag auf ausdrueckliche Nutzerkorrektur verankert (Phase 7). AGENTS.md benennt die freigegebenen Data-Hub-, Work- und Pathfinder-Ansichten als verbindliche Referenzen fuer alle Ansichten und Designartefakte, einschliesslich Client Info. Die bisherige visuelle Client-Info-Ausnahme und der verpflichtende dunkle Faktenstreifen sind ausdruecklich supersediert. Lokaler assessor-ui-Skill und seine Referenzdokumente benennen den Vorrang der aktuellen Projektregeln; die README-Kopieranleitung fuer veraltete Skill-Assets wurde entfernt. Die drei generischen Client-Info-Mockups gelten als verworfen. Pruefumfang: Dokumentkonsistenz, relative Verweise und Patch-Whitespace; keine Runtime-, CSS-, Komponenten-, Daten- oder Persistenzaenderung, deshalb kein Build und keine behauptete visuelle Abnahme. Fachliche Client-Info-/Scorevertraege und vorhandene Phasenstatus bleiben erhalten.

2026-09-18: Management-Overview-Renderer umgesetzt (Artefakt A der Berichtsstrecke, `docs/REPORT_STRATEGY.md`). `src/exports/management-overview-report.ts` erzeugt ein selbsttragendes, statisches HTML-Dokument in Deutsch: kein Script, kein Inline-Handler, keine externe URL, kein Link, kein `url()` und damit kein Netzwerkzugriff beim Oeffnen. Die Abschnittsfolge ist Assessment-Identitaet, Overall Posture mit Security Domains, Priority Findings, Remediation-Status, Abdeckung und Luecken, Source Overview. Priority Findings sind nach Security Domain gruppiert und innerhalb je Quelle nach deren deklariertem Maßstab geordnet, der im Dokument benannt wird; eine quellenuebergreifende Rangfolge entsteht nicht. GPO bleibt gleichgewichtig mit Verdiktzaehlern, getrennten Conflict-/Duplicate-Angaben, ausgewiesener Score-Neutralitaet und Scope-Hinweis. Der Remediation-Abschnitt entfaellt ohne Reviews und ist sonst ausdruecklich als Selbstauskunft ohne technischen Nachweis gekennzeichnet. Verbindliche Scoreformulierung uebernommen; `Baseline-Compliance` und `Baseline-Abdeckung` sind durch Tests ausgeschlossen. Unbekanntes rendert als Gedankenstrich, ein fehlender Score zeichnet keinen Nullbogen. Donutgeometrie entspricht dem Vertrag: volle 360 Grad, neutraler Track, Wertbogen im Uhrzeigersinn ab zwoelf Uhr, flache Enden, zentrierter Wert mit kleinerer Einheit; Bereichsueberschreitungen werden geklemmt. Ausschliesslich Tokenwerte aus `src/styles/ui-tokens.css`, Light als Dokumentstandard und Dark ueber `prefers-color-scheme` aus denselben Rollen, eigener Druckzweig. 17 synthetische Tests einschliesslich Struktur-, Escaping- und Donutgeometriepruefung bestanden; Client- und Serverbuild, Local-only- und Designpruefung erfolgreich; Gesamtlauf 1.399 bestanden, 13 uebersprungen, derselbe fachlich unabhaengige Vorbestand (`tests/features/gpo-xml-presentation.test.tsx`) faellt weiterhin auch ohne diese Aenderung. Abweichung benannt: Ein ausgeliefertes Dokument verwendet bewusst keine Applikationsshell (Sidebar, Topbar, Command Band) und keinen der vier Seitenarchetypen; Typografie-, Donut-, Tile-, Segment- und Statusregeln gelten unveraendert. Rein additiv, kein Reimport erforderlich.

2026-09-18: Prioritaetsbasis als Profilpflicht deklariert (Berichtsstrecke, Festlegungen in `docs/REPORT_STRATEGY.md`). `ToolPriorityBasisDefinition` ist auf jeder `ToolProfileDefinition` verpflichtend und nennt exakte gemappte Eigenschaften, Skala, Richtung und Semantik oder einen ausdruecklichen Grund, warum keine belastbare Basis existiert. Purple Knight und Maester deklarieren native Severity, PingCastle deklariert Points, weil seine Severity abgeleitet und bauartbedingt bei `high` gedeckelt ist, CIS-CAT und Generic deklarieren `unavailable` mit Begruendung. Zusaetzlich werden ausgeschlossene Eigenschaften mit Grund festgehalten: CIS `Level 1`/`Level 2` ist eine Haertungsprofilstufe und darf nie zur Kritikalitaet befoerdert werden, PingCastles Punkteschema-Beschreibung und Domainrisiko sind keine Einzelfundraenge. `reportPriorityBasisFrom` macht aus einer `unavailable`-Deklaration eine ausdrueckliche `equal-weight`-Basis mit der Profilbegruendung, sodass ein Bericht die Unranked-Lage benennt statt eine fehlende Deklaration zu suggerieren. Zehn zusaetzliche synthetische Tests einschliesslich Vertragspruefung aller registrierten Profile bestanden; Client- und Serverbuild erfolgreich; Gesamtlauf 1.382 bestanden, 13 uebersprungen, derselbe fachlich unabhaengige Vorbestand (`tests/features/gpo-xml-presentation.test.tsx`) faellt weiterhin auch ohne diese Aenderung. Rein additive Profilfelder: keine Erkennung, Extraktion, Zuordnung, Normalisierung, Bewertung oder Persistenz veraendert, daher kein Reimport erforderlich.

2026-09-18: Report-Projektion als plattformneutrales Domain-Modul umgesetzt (neue Berichtsstrecke, noch keiner Phase zugeordnet; Festlegungen in `docs/REPORT_STRATEGY.md`). `src/domain/report-projection.ts` liefert die gemeinsame Grundlage fuer Management Overview, Technical Report, Arbeitsgrundlage und Delta Report: sprachneutral, ohne Uhr, Speicher, Netzwerk oder Praesentationstypen. Prioritaet wird nie quellenuebergreifend gebildet; eine deklarierte Severity-Basis ohne Severity-Abdeckung faellt nachweisbar auf `undeclared` mit eigener Diagnose zurueck. GPO bleibt gleichgewichtig, selbstgemeldete Reviewstatus werden nie zu behobenen Findings, und ein Delta entsteht ausschliesslich aus einem gespeicherten Vergleich mit gewaehltem Referenzlauf. Die Sicherheitsdomaenen-Zuordnung wird injiziert, damit die Domaenenschicht nicht auf die Featureschicht zeigt. 14 neue synthetische Tests bestanden, Client- und Serverbuild erfolgreich; Gesamtlauf 1.372 bestanden, 13 uebersprungen, ein fachlich unabhaengiger Vorbestand (`tests/features/gpo-xml-presentation.test.tsx`) faellt auch ohne diese Aenderung. Rein additiv: keine bestehende Datei, kein Schema, keine Pipeline und keine Kundendaten beruehrt.

2026-09-18: Vollstaendigen Client-Info-Security-Domain-Katalog fuer Work freigegeben (Phase 7, Nutzerkorrektur). Alle acht Domains bleiben mit exakten gemeinsamen Labels und auch bei null Treffern auswaehlbar; aktive Status-/Facettenauswahlen bleiben bei leeren Schnittmengen erhalten. Client-Info-Deviation-Domaindrilldown auf sichtbaren gemeinsamen Filter umgestellt, feste Record-ID-Einschraenkung dort entfernt. Vier permanente synthetische UI-Regressionen und 40 fokussierte Tests bestanden; keine Mandantendaten oder Klassifikations-/Persistenzlogik veraendert.

2026-09-18: GPO-Zaehlerabgleich Result DB/Work (Phase 7/13B) umgesetzt: SQL-Laufauswahl auf verschiedene verglichene Baseline-Pakete angeglichen und anzeigewertbasierte Unterdrueckung autoritativer Fail-Urteile entfernt. 50 fokussierte Tests einschliesslich fuenf real ausgefuehrter synthetischer PostgreSQL-SELECT-Faelle, zwei Work-Einstiege und Result-DB-Interaktion gruen; beide Produktionsbuilds und Local-only-/Designpruefung bestanden. Dummy ausschliesslich lesend abgenommen: 127 Vergleiche zu 25 Einstellungen, gleiche aktuelle Run-ID, keine versteckten Fail-Eintraege oder zusaetzlichen Paare. Keine Migration oder Datenmutation. Bestehende fremde XML-Reader-Testabweichung bleibt dokumentiert; keine Phasenabnahme behauptet.

2026-09-18: Result-DB-Filterbenennung mit Work vereinheitlicht und Deviation-Ausnahme entfernt (Phase 7/13B, Nutzerkorrektur). Gemeinsame Labels in Work, Result-DB-Facette und Details; Zaehler beachten Deviation, Statusaktionen erhalten die gesetzte Auswahl, Nulltrefferfilter bleiben abwaehlbar. Zwei permanente synthetische Browserkomponenten-Interaktionstests decken beide Timeslotarten ab. 45 fokussierte Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Keine Dateninspektion, Bestandsmutation, SQL-Migration oder Bewertungsveraenderung.

2026-09-18: Ueberhang langer Security-Template-Registrytitel behoben (Phase 7/13B). `PathText` erkennt neben `registry ·` nun den tatsaechlich angezeigten Vertrag `Registry Values · MACHINE\\...`/`USER\\...`, ohne allgemeine Security-Template- oder AppLockertexte umzudeuten. Reader-Heading und Summary nutzen damit die begrenzte technische Pfaddarstellung und ueberlagern `Accepted Risk` nicht mehr. Zwei synthetische Regressionen ergaenzt; 1.351 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Produktionsbuild erfolgreich. Keine Dateninspektion, Bestandsmutation, Migration, Reimport oder Neuauswertung.

2026-09-18: GPO-Mehrfachdarstellung in Work behoben (Phase 7/13B). Neun Baselinepakete derselben Einstellung ergeben eine Work-Zeile mit allen Einzelvergleichen und genau einer Quellanzeige. Gemeinsame Urteilprioritaet, individuelle Baselinefacette, paketbezogene Sollwerte, sichere Wertmarkierungen, historische Readiness und Erhalt frueherer lokaler Reviews implementiert. Zehn neue synthetische Regressionen; Gesamtsuite 1.349 bestanden, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und beide Builds erfolgreich. Keine Dateninspektion, Bestandsmutation, Migration, Reimport oder Neuauswertung; Result DB und gespeicherte Baselinevergleiche unveraendert.

Verifiziert 2026-09-18 (Phase 13B, Work-Listenstabilitaet und lange Registrytitel): Die einzelne FindingCard fuehrt bei Auswahl kein eigenes glattes `scrollIntoView` mehr aus; der virtuelle Listencontainer bleibt alleinige Scrollautoritaet und springt nur bei ausserhalb liegenden Eintraegen ohne Animation. `scrollbar-gutter: stable` reserviert die Scrollbarspur der Datensatzliste und verhindert wechselnde Textbreite. `PathText` erkennt nun den bestehenden Titelvertrag `registry · <Pfad>` und rendert den unveraenderten Registrypfad im Finding-Reader und in dessen Finding-Ueberschrift mit der gemeinsamen technischen Pfaddarstellung; volle Breite, `border-box` und bestehendes `overflow-wrap: anywhere` halten lange Pfade innerhalb der Lesespalte, ohne Accepted Risk oder Aktionen zu ueberlagern. Ein Interaktionstest waehlt eine sichtbare mehrzeilige Registrykarte und belegt null kartenlokale Scrollanimationen; Pfad-, Typografie- und GPO-Darstellungstests sichern den zweiten Screenshotfall. `npm test`: 1.339 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Bestehende Chunkgroessenwarnung unveraendert; die Laufzeitpruefung blieb auf den vom Nutzer gezeigten LSW-Kontext begrenzt, Bestandsdaten wurden nicht veraendert. Keine API-/SQL-/Persistenz-/Fachlogikaenderung.

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.

Verifiziert 2026-09-17 (Phase 13B, Originalschreibweise durchgaengig bis Work): Der Parser-Fix allein reichte nicht. Der angezeigte Titel eines bewerteten Settings stammt aus der Baselineseite, deren Analysen mit dem alten Parser erzeugt worden waren; die Kundenbeobachtungen trugen die Originalform bereits, die Work-Zeile weiterhin nicht. Baselineanalyzer append-only auf 1.4.0 erhoeht, elf Baselinepakete neu analysiert, neu ausgewertet: 593 von 593 Security-Template-Zeilen tragen jetzt die geschriebene Form. Zwei Folgefehler derselben Klasse dabei behoben. Erstens waehlte die automatische Pipeline alle nicht abgeloesten Analysen und verglich vier Baselines doppelt, weshalb jeder frische Lauf sofort wieder als re-evaluierungsbeduerftig galt; die Auswahl kollabiert jetzt ausschliesslich Generationen desselben Pakets, wodurch die dokumentierte Vereinbarung zu unabhaengigen aktiven Analysen woertlich erhalten bleibt und ihr Vertragstest unveraendert besteht. Zweitens bevorzugte die Laufauswahl den Lauf mit mehr Analyse-Referenzen, wodurch der veraltete Lauf mit vier doppelten Generationen den korrigierten verdraengte; gemessen wird jetzt die Zahl tatsaechlich verglichener Baselines, mit Rueckfall auf die deklarierten Referenzen, wenn die Ergebnisse keine Baseline nennen. Ausserdem festgestellt und behoben: der konfigurierte Artefakt-Store war leer, weil die Quelldateien geschrieben wurden, als ASSESSOR in der Codex-App lief und Windows LOCALAPPDATA in den Paketcontainer umleitete; die dreizehn Objekte wurden pruefsummenverifiziert in den konfigurierten Store kopiert, das Original blieb unangetastet. Nebenbefund ohne Fix: die Persistenz behauptet `backend-controlled`-Aufbewahrung, ohne die Erreichbarkeit der Bytes zu pruefen, was sich erst nach drei verbrauchten Versuchen als Dead-Letter zeigt statt als `not-retained`. `npm test`: 1.320 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Work-Abdeckung unveraendert vollstaendig: 3.552 Beobachtungen, null ohne Zeile. Keine SQL-Migration, keine Evaluatoraenderung, keine Bestandsloeschung.

Verifiziert 2026-09-17 (Phase 13B, Originalschreibweise nativer Policyeinstellungen): Der Security-Template-Parser schrieb den Abschnittsnamen beim Parsen klein und verwarf die Originalform; aus `[Privilege Rights]` wurde unwiderruflich `privilege rights`. Das verletzte die Regel, dass Normalisierung keine Quelldaten zerstoeren darf. Der Parser behaelt jetzt die geschriebene Form von Abschnitt und Schluessel; die case-gefalteten Formen bleiben intern fuer Grammatikauswahl, Gruppierung und Identitaetsdigest, wodurch bestehende Beobachtungs- und Identitaets-IDs stabil bleiben. Der native Target-Resolver legt die geschriebene Form im aufbewahrten Target ab, genau wie der Registry-Resolver es bereits tat; Work zeigt damit `Privilege Rights - SeCreateTokenPrivilege` und der Wert ist gegen Microsoft-Dokumentation und externe Tabellen suchbar. Die Resolverversion bleibt bewusst unveraendert, weil die Validierung persistierter Identitaeten exakt auf sie prueft und ein Bump historische Datensaetze ungueltig machen wuerde; die Provenienz traegt stattdessen die Analyzer- und Parserversion. Weil sich persistierte Parsingausgabe aendert, ist dies ein Verarbeitungsversions-Schritt: Parser 1.1.0 auf 1.2.0, GPO-Analyzer 2.2.3 auf 2.2.4, Jobprozessor 2.2.3 auf 2.2.4. Damit die Erhoehung nicht still bleibt, meldet der GPO-Status jetzt einen veralteten Analysestand: Data Hub zeigt `Reprocessing required` mit beiden Analyzerversionen und bietet die bestehende Reprocess-Aktion auf der gespeicherten Quelle an, ohne erneuten Upload; abgeloeste Analysen fordern keine Arbeit an. Reprocessing rangiert vor Re-Evaluation, auch in der Client-Readiness. Eine synthetische Abnahmepruefung deckt die exakte Nutzerinteraktion ab. `npm test`: 1.318 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Keine SQL-Migration, keine Evaluatoraenderung, keine Bestandsmutation; historische Werte bleiben unveraendert erhalten.

Verifiziert 2026-09-17 (Phase 13B, Aufraeumen der Analyseluecken): Vor dem Aufraeumen nachgemessen statt der eigenen Annahme gefolgt. Die Behauptung des vorigen Eintrags, beide Gap-Kacheln seien strukturell leer, war fuer `parser-gap` falsch: `unsupported-setting` wird von jeder Engine 1.3.0 bis 1.8.0 erzeugt, zuletzt 141 Ergebnisse; die Null unter 1.9.0 entsteht erst durch die aufgeloesten Security-Template-Vergleiche gegen die aktuelle Baselineanalyse. Die Kachel `Comparison not supported` bleibt deshalb erhalten und ist mit einer synthetischen Abnahmepruefung gegen stille Entfernung gesichert. Entfernt wurde nur wirklich Totes: die Kachel `Baseline mapping unavailable`, deren `catalog-gap` ausschliesslich Engine 1.2.0 erzeugt hat und die aktive Engine nicht mehr setzen kann, sowie die nirgends importierte Datei `server/gpo/gpo-policy-evaluation-rule-engine.ts`. Die Review-Queue behaelt das Kategorielabel `Baseline mapping unavailable` fuer historische Laeufe; die abgeleiteten Zaehler `catalogGaps`/`parserGaps` bleiben im Domaenenvertrag, weil sie fuer aufbewahrte Historie weiterhin korrekt sind. Die Sektion nennt jetzt Beobachtungsdiagnostik statt eines fehlenden Pass/Fail-Urteils und verweist fuer unaufgeloeste Identitaeten auf das Work-Verdict `Not comparable`. `npm test`: 1.317 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Keine Evaluatorversion, SQL-Migration, Reimportpflicht oder Bestandsmutation.

Verifiziert 2026-09-17 (Phase 13B, Verdict `Not comparable` und Gap-Entdopplung): Die 242 unaufgeloesten Beobachtungen des aktiven Laufs sind ausnahmslos Group Policy Preferences (145 Registry, 70 Drive Maps, 16 Local Users and Groups, 11 Services) und erschienen in Work bisher gar nicht. Auf ausdrueckliche Nutzerentscheidung erhalten sie das score-neutrale Verdict `Not comparable`; die verbindliche GPO-`Result Status`-Liste in AGENTS.md ist mit Zustimmung um diesen achten Wert erweitert und die Semantik dort als eigene Regel dokumentiert. Preferences werden bewusst nicht in Policy-Identitaeten aufgeloest und nicht mit Microsoft-Baselines verglichen: Aktion, Item-Level-Targeting und Apply-once-Semantik unterscheiden sich von einer Policy-Einstellung, ein Baselineurteil darueber waere erfunden. Die Leseprojektion zeigt zusaetzlich die bereits aufbewahrte CSE, Aktion und Targeting-Status; diese bleiben in den vereinbarten GPO-Spalten lesbar, ohne eine neue Spalte oder Facette einzufuehren. Gleiche oder abweichende Preference-Anweisungen sind keine belegten Duplikate oder Konflikte, deshalb traegt `Not comparable` kein Diagnoseflag. Zusaetzlich behoben: die Snapshot-Aggregation meldete jede unaufgeloeste Identitaet ihrer Quellanalysen ein zweites Mal, wodurch dieselben Beobachtungen einmal korrekt und einmal als namenloses `Review required` in der Review-Queue standen; der Kategoriematcher erkannte den Resolver-Code nicht. Beides ist korrigiert, die Gap-Zahl bleibt unveraendert. Zwei neue synthetische Abnahmepruefungen fuer die exakten Nutzerinteraktionen (`Result Status = Not comparable` waehlt die Preferences mit lesbarer CSE, Aktion und Targeting und liefert weder Deviation noch `No baseline rule`; unaufgeloeste Identitaet genau einmal mit autoritativem Grund) plus angepasste Vertragstests. `npm test`: 1.316 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Reine Leseprojektion ueber bereits aufbewahrte Fakten: keine Evaluatorversion, SQL-Migration, Reimportpflicht oder Bestandsmutation. Korrektur zum naechsten Eintrag: die hier als gemeinsam "strukturell leer" bezeichneten Gap-Kacheln sind nicht gleichwertig; `parser-gap` ist erreichbar und bleibt erhalten.

Verifiziert 2026-09-17 (Phase 13B, Verdict `No baseline rule`): Die Evaluationsschleife laeuft ausschliesslich ueber Baselineeintraege; aggregierte Kundenzustaende ohne Gegenstueck fielen bisher lautlos heraus und erschienen in Work weder als Verdict noch als Analyseluecke. Auf ausdrueckliche Nutzerentscheidung erhaelt jeder aufgeloeste Kundenzustand jetzt genau ein Verdict: ein bewertetes Urteil, wo eine Baselineregel existiert, sonst das score-neutrale `No baseline rule`. Die verbindliche GPO-`Result Status`-Liste in AGENTS.md ist mit Zustimmung des Nutzers um diesen siebten Wert erweitert; die Semantik ist dort als eigene Regel dokumentiert und von `Not configured` abgegrenzt. `Conflicts`/`Duplicates` sind konsequent Diagnoseflags auf der Zeile des Settings und ersetzen dessen Verdict nicht mehr; Zaehlung, Facettenauswahl und Result-DB-Projektion folgen dem Flag statt dem Zeilenstatus. Der zuvor dokumentierte stille Abbruch fuer Vergleiche ohne sicheres Urteil ist beseitigt: solche Vergleiche bleiben `Review required`. Beobachtungen, die bereits einen bewerteten Vergleich belegen - einschliesslich Kindwerten einer Registry-Key-Anforderung - werden nicht doppelt gemeldet; unaufgeloeste Identitaeten bleiben ausserhalb des Verdicts und behalten ihre eigene Lueckenmeldung. Neue synthetische Abnahmepruefung fuer die exakte Nutzerinteraktion (`Result Status = No baseline rule` in Work waehlt das konfigurierte Setting mit erhaltenem Originalwert, nicht Deviation oder Not configured) plus angepasste Vertragstests. `npm test`: 1.313 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Reine Leseprojektion ueber bereits aufbewahrte Fakten: keine Evaluatorversion, SQL-Migration, Reimportpflicht oder Bestandsmutation. Offen bleiben die GPP-Kategorie und die strukturell leeren Gap-Kacheln `catalog-gap`/`parser-gap`.

Verifiziert 2026-09-17 (Phase 13B, aktuelle Baselineanalyse-Generation): Die GPO-Re-Evaluation reichte bisher die `baselineAnalysisIds` des vorherigen Laufs unveraendert weiter. Dadurch blieb eine Evaluation dauerhaft an die Baselineanalyse-Generation ihres allerersten Laufs gebunden, auch nach jedem Engine-Upgrade. `gpoEvaluationUpdates` loest jetzt jede aufbewahrte Baselinereferenz auf ihre aktuelle, nicht abgeloeste Analyse auf und erweitert den bewerteten Baselinesatz nie: eine unbekannte Referenz und eine Baseline ohne neuere Generation behalten ihre eigene Analyse-ID. Die Readiness beruecksichtigt zusaetzlich zur Engineversion die Baselineanalyse; `reasons` benennt die Ursache, Data Hub und Client-Readiness zeigen sie getrennt an. Die Auswahl der aktuellen Generation ist mit `buildActions` zu einem gemeinsamen Helfer zusammengefasst. Vier neue synthetische Tests pruefen die exakte Nutzerinteraktion (Re-evaluate-Aktion sendet die neuere Generation, keine Erweiterung des Baselinesatzes, Ursachenanzeige bei reiner Baselineaenderung) und das Verstummen nach erfolgter Neuauswertung. `npm test`: 1.310 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Keine Engineversion, SQL-Migration, Bestandsmutation oder Reimportpflicht; bestehende Laeufe bleiben als Historie erhalten und werden erst durch die ausdrueckliche Re-evaluate-Aktion ersetzt. Abgrenzung in REIMPORT_POLICY.md ergaenzt. Phase 13B bleibt in Arbeit; die uebrigen dokumentierten GPO-Analyseluecken (Kundeneinstellungen ohne Baselineregel, GPP-Kategorie, immer leere Gap-Kacheln) bleiben offen.

Verifiziert 2026-09-17 (Phase 7/13B, Quellenzuordnung): Originalanweisungen je GPO-Backup sofort im Reader sichtbar, native Identitaeten/Quellsequenz aus vorhandener Persistenz projiziert und fehlende Conflict-Kennzeichnung fuer delete-value durch autoritative Zustandsableitung korrigiert. Unabhaengig belegte Unterschiede bleiben bei zusaetzlichen indeterminate-Beitraegen sichtbar, ohne fruehere Einzelanweisungen unsicherer Backups als separate GPOs zu behandeln. Entscheidung und Ablosung der Results-only-Verbergung in AGENTS.md dokumentiert. 20 neue synthetische Tests einschliesslich exakter Work-Interaktion in GPO-Blatt und Source-Scan-Kontext; 1.304 Gesamttests, Local-only-/Designcheck und beide Builds erfolgreich, acht optionale PostgreSQL-Tests uebersprungen. Keine Bestandsmutation oder Reimportpflicht; fehlende GPO-Namen und unbelegte Wirksamkeit bleiben transparente Grenzen.

Verifiziert 2026-09-17 (Phase 7/13B): Den ausdruecklich angeforderten Work-Filter `GPO backups with failing settings` mit Einzel-/Gesamtauswahl umgesetzt und den GPO-Facettenvertrag in AGENTS.md erweitert. Gemeinsame Quellenidentitaet mit der Processing-Kachel, additive Datensatzprovenienz, unveraenderte Vergleiche und historische Statusgrenze. Vier neue synthetische Regressionen; 1.284 Gesamttests, Local-only-/Designcheck und beide Produktionsbuilds erfolgreich, acht optionale PostgreSQL-Tests uebersprungen. Keine Kundeninhalte gelesen oder Bestandsdaten veraendert.

Verifiziert 2026-09-14 (Phase 7/13B, GPO-Baselinevarianten): Evaluator 1.5.0 und additiven Variantenvertrag mit gespeicherten Originalwerten, Einzelurteilen und Quellenreferenzen implementiert. Eindeutiger Fail/Pass ohne PingCastle, Review bei gemischten/unlesbaren Varianten oder widerspruechlichen Eintraegen derselben Baseline-GPO, Not configured nur mit Abwesenheitsevidenz. Bestehende Rollenwahl bleibt explizit; ADMX-/wertunabhaengige Baseline-Metadatenluecken bleiben sichtbar. Work, Guidance, Result DB und JSONL behalten alle Varianten ohne synthetischen Gesamt-Sollwert; alte Runs 1.3.3/1.4.0 werden nicht umgeschrieben. Vertrag in GPO_BASELINE_EVALUATION.md und Re-evaluation-Abgrenzung in REIMPORT_POLICY.md. Synthetische Gesamtsuite: 1.250 bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung erfolgreich. Fokussierte Regressionen pruefen gespeicherte Evidenz, Kontenlisten, Typen, Metadaten, Historie, Work-Filter und gerenderte Result-DB-Details. Client-/Server-Produktionsbuild erfolgreich; bestehende Bundlegroessenwarnung bleibt. Keine Realdateninspektion, Datenmigration, Neuimport oder automatische Bestandsneuauswertung; laufendes Backend nicht neu gestartet. Phasenstatus unveraendert.

Implementiert 2026-09-11 (Phase 8, Timeslotvergleich P0/P1): P0-Audit fuer Scanner/Format/GPO abgeschlossen und additiven P1-Domaenenvertrag 1.0.0 begonnen. Identitaet verlangt deklarierte Granularitaet, Scope und bei Objektvergleich Typ/Namespace/Schluessel; technische Behebung verlangt gleiche Identitaet, kompatible Verarbeitung und neuere belastbare Evidenz. Ungeklaerte Zwischenstaende erhalten Verpflichtungsherkunft, auditierter Scope-Ausstieg wird separat validiert. Sechs synthetische Domainregressionen, Local-only-/Designcheck und beide Builds erfolgreich. Gesamtlauf 1.224 bestanden, acht optionale DB-Tests uebersprungen; ein Node-Importtest lief unter Gesamtlast ueber sein unveraendertes 5-Sekunden-Limit und bestand isoliert 5/5 in 1.193 ms. Keine Anbindung an laufende Engine/Persistenz/API/UI, keine Importversion, Reimporte oder Datenmutation. P1 bleibt in Arbeit, P2-P6 offen.

Geplant 2026-09-11 (Phase 8, ausdruecklicher Planauftrag): Detailplan fuer belastbare A/B-Vergleiche mit sieben offenen Umsetzungspaketen P0-P6, fachlichen Entscheidungsregeln, Reimport-/Neuberechnungsgrenze, Risiken und synthetischer Abnahmematrix angelegt. Phasenuebersicht und aktuelle Etappe unterscheiden historischen Abschluss von offener Erweiterung; Vergleichs- und Scoringdokumentation erhalten datierte Statushinweise. Neue lokale Dokumentationsverweise, Hauptplananbindung, Paketvollstaendigkeit und Patchformat geprueft. Keine Implementierung, Migration, Reimporte oder Laufzeittests; npm test/build wegen ausschliesslicher Dokumentationsaenderung nicht erneut ausgefuehrt.

Verifiziert 2026-09-11 (Phase 7, Client-Info-Risikoregister): Zweigeteilte Accepted-Risks-Kachel unter den bestehenden Client-Informationen implementiert. Linke Auswahl zeigt Quelle, Zustand und Wiedervorlage; rechte Ansicht zeigt den vollstaendigen aktuellen Entscheidungsinhalt und alle Versionen. Kanonische Vorkommnisse werden blattuebergreifend dedupliziert, schmale Ansichten stapeln ohne Textverlust. Zwei neue Registertests und 18 fokussierte Tests erfolgreich; Gesamtlauf 1.218 bestanden und acht optionale DB-Tests uebersprungen, ein paralleler Fuenf-Sekunden-Ausreisser bestand isoliert in 4.971 ms. Local-only-/Designchecks, beide Builds und synthetische Browserpruefung erfolgreich. Keine API-, Persistenz-, Import-, Score-, Reimport- oder Datenmutation.

Verifiziert 2026-09-10 (Phase 7/9-11/13, Accepted Risk): Findingheader-Button, vollstaendiger Entscheidungsdialog, Entwurf/Annahme/Widerruf und versionierte Review-JSONB-Ablage ueber geschuetzte API implementiert. Best-Practice-Ausgangspunkt gemaess Nutzerantwort, getrennte Freigabedokumentation und verbindliche Fristen; keine behauptete Signaturpruefung. Reimport erhaelt Originalentscheidungen mit erneuter Pruefung fuer den Ersatzbefund. 1.214 Tests, Local-only-/Designchecks, beide Builds und synthetische Browserpruefung erfolgreich; acht optionale DB-Integrationstests uebersprungen. Frontend/Backend HTTP 200. Keine Migration oder Realdatenmutation; Firmenfreigaben und unabhaengige Aufbewahrung bleiben in Phase 14 offen.

Verifiziert 2026-09-15 (Phase 13F, llama.cpp/BGE-M3): Lokalen Server Health/Modellmetadaten geprueft, sechs rein synthetische EN/DE-Dokumente ueber den produktiv gebauten Embedding-/Ingestionpfad als sechs 1.024-dimensionale Chunks indexiert und drei Cross-Language-Cases ausgewertet. HitRate@3, Recall@3 und MRR jeweils 1,0; alle Ziele Rang 1. Ergebnis als Wiring-Smoke-Test, nicht als Produktionsqualitaet dokumentiert. Qdrant enthaelt sechs synthetische Punkte; PostgreSQL/Realdaten unberuehrt. 1.285 Standardtests bestanden, acht PostgreSQL- und ein Qdrant-Integrationstest uebersprungen; Local-only-/Designcheck und beide Builds erfolgreich.

Implementiert 2026-09-15 (Phase 13F, lokales Embedding): Autorisierte Legacy-Collection geloescht, alten leeren Qdrant-1.12.4-Container entfernt und dessen Volume bewahrt; authentifizierten 1.19.1-Dienst auf kanonischen Loopback-Port 6333 verschoben und Auth/Collectionstatus erneut bestaetigt. BGE-M3/1.024 als lokale llama.cpp-Dense-Baseline festgelegt. Embeddingadapter um strikt loopbackbegrenztes HTTP und optionalen `dimensions`-Request fuer spaeteres `text-embedding-3-large` via HTTPS-LiteLLM erweitert; llama.cpp bleibt auf nativer Dimension. 1.285 Standardtests bestanden, acht PostgreSQL- und ein Qdrant-Integrationstest uebersprungen; Local-only-/Designcheck und beide Builds erfolgreich. Kein PostgreSQL- oder Realdatenzugriff, kein Reimport. BGE-M3-GGUF/Serverstart und echte Modellmetriken bleiben offen.

Verifiziert 2026-09-15 (Phase 13F, WSL-Qdrant): Docker in WSL erkannt, kanonisches PostgreSQL gesund und unberuehrt bestaetigt. Alten nichtleeren Qdrant 1.12.4 auf 6333 bewahrt; neuen authentifizierten Qdrant 1.19.1 im kanonischen Compose-Projekt auf temporaerem Loopback-Port 6334 gestartet. Auth 401/200, gruene Collection, Dense 1.024/Cosine, Sparse-Slot, neun Payloadindizes sowie synthetisches Replace/Filter/Retrieval live verifiziert; Testkorpus danach geloescht, null Punkte verblieben. Synthetischen EN/DE-Smoke-Korpus, drei Cross-Language-Labelcases und opt-in Integrationstest hinzugefuegt. Reale Ingestion vor Versand gestoppt, weil die konfigurierte lokale HTTP-Embedding-URL unzulassig und nicht erreichbar ist. 1.284 Standardtests bestanden, acht PostgreSQL- und ein Qdrant-Integrationstest uebersprungen; Qdrant separat 1/1 bestanden, Local-only-/Designpruefung und beide Builds erfolgreich. Keine PostgreSQL-Mutation, keine Realdateninspektion und kein Reimport.

Implementiert 2026-09-15 (Phase 13F, Finding-Retrievalgrenze): Bestehende Unified Results ueber einen fail-closed Public-Signal-Query-Builder backendintern an den Regulatory Retriever angebunden; katalogeigene Maester-/PingCastle-Regel-IDs und fest definierte Technikthemen verhindern die Kopie von Rohbericht-, Asset-, Pfad-, Mandanten-, Review- und Provenienzdaten in Embeddingrequests. Versionierten begrenzten EN/DE-Evaluationsvertrag und Aggregat-CLI fuer HitRate@K, Recall@K und MRR hinzugefuegt. 1.283 synthetische Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Kein API-/UI-Pfad, keine Datenbankmutation, keine Mappingbehauptung und kein Reimport; Datenschutzfreigabe, Korpus und reale Dense-Baseline bleiben offen.

Implementiert 2026-09-15 (Phase 13F): Qdrant-Compose-Service, versionierter regulatorischer Dokument-/Chunkvertrag, deterministischer Chunker, OpenAI-kompatibler mehrsprachiger Embeddingadapter, Collection-/Payload-Indexverwaltung, dokumentweiser Replace-Ingestion, gefiltertes Dense Retrieval sowie Candidate-/Reranker-Erweiterungsgrenzen und CLI-Ingestion hinzugefuegt. 1.275 synthetische Tests bestanden, acht optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. PostgreSQL-, Scanner- und UI-Vertraege bleiben unveraendert; keine Mappingbehauptung und kein Reimport. Docker fehlt auf dem Host, daher keine Compose-/Qdrant-/Embedding-Liveabnahme. Betriebs- und Sicherheitsgrenzen in `docs/REGULATORY_RAG.md` dokumentiert.

Verifiziert 2026-09-10 (Phase 7/13C, Purple-Knight-Scorezuordnung): Separate native Summary und eindeutige Findings desselben Scanlaufs werden sicher verbunden. Regression 65 native/96 Passed/19 Deviations ergibt 65 Native score in der Dashboardprojektion. 1.199 Tests, Sicherheits-/Designchecks und beide Produktionsbuilds erfolgreich. Keine Datenmutation oder Realdateninspektion.

Verifiziert 2026-09-10 (Phase 6/13C/7, weitere Scanner): Native-first-Regel in verpflichtende Profildefinitionen und gemeinsamen Katalogpfad ueberfuehrt. Zehn neue Regressionen; 1.198 Tests, Sicherheits-/Designchecks und beide Produktionsbuilds erfolgreich. Keine Migration, Reimportmutation oder Backendneustart.

Verifiziert 2026-09-10 (Phase 7/13C/8, Hybridscore): Native Beitraege mit berechnetem Fallback, feste Quellgewichte, genaue Provenienz, Lauf-Deduplikation, Domain-Pass-rates und Methodikdialog implementiert. Zeitvergleich trennt gemeinsame aktuelle Evidenz und historische offene Scannerverpflichtungen. 1.188 Tests, Local-only-/Designchecks und beide Produktionsbuilds erfolgreich; kleine Ergaenzung der vorhandenen Testfixture-Typdeklaration beseitigt TS7016. Keine SQL-Migration oder Realdatenmutation; verbleibende Phase-8-Workflowgrenzen explizit dokumentiert.

Verifiziert 2026-09-10 (Phase 7): Source-Auswahl bleibt in Client Info bzw. der bestehenden Work-Unteransicht. Dashboard-Ergebniszahlen folgen dem Source-Filter; Scan All, Timeslotwechsel, Quellenauswahl im Cache und unveraenderter Wiederbesuch synthetisch geprueft. 1.157 Tests, Local-only-/Designpruefung und Clientbundle erfolgreich; Gesamtbuild am vorbestehenden TS7016 der HTML-Testfixture blockiert. Keine Datenmutation oder Phasenstatusaenderung.

Verifiziert 2026-09-10 (Phase 7, PurpleKnight): Native HTML-/CSV-Statusunterschiede im freigegebenen read-only Abgleich bestaetigt; keine Anpassung gespeicherter Ergebnisse. Client Info schliesst Not Relevant aus Assessment Gaps und Coverage-Nenner aus und erhaelt Not selected/Canceled als nicht ausgefuehrt. Vier neue Regressionen; 1.152 Tests, Local-only-/Designpruefung und Clientbundle erfolgreich. Gesamtbuild am vorhandenen TS7016 der HTML-Testfixture blockiert. Keine Migration, kein Reimport, Phasenstatus unveraendert.

Verifiziert 2026-09-09 (Phase 13/13A, HTML-Timeout): Linearer Attributleser und importlokaler Verweisindex beseitigen den synthetisch reproduzierten 30-Sekunden-Abbruch. Derselbe 3.159.338-Byte-Bericht liefert im gebauten Worker alle 40 Regeln/Detailtabellen in 1.590 ms bei unveraenderten Sicherheitslimits. Neun neue Regressionen; 1.131 Tests bestanden und acht PostgreSQL-Tests uebersprungen, beide Builds sowie separate Designpruefung erfolgreich. Die nachgeschaltete globale Sicherheitspruefung bleibt an einem unabhaengig geaenderten GPO-Metadatenparser offen; kein Eingriff in diese fremde Aenderung. Kanonischer Datastore bestaetigt, aktualisiertes Backend und App/Proxy HTTP 200, synthetischer Parse-only-HTTP-Check ohne Revisionsaenderung. Originaldatei aus dem Screenshot nicht gelesen, keine Importpersistenz oder Schemaaenderung. Vorgaben aktualisiert; temporaere Diagnosepruefungen entfernt, dauerhafter Workerlasttest dokumentiert. Phasenstatus unveraendert.

Verifiziert 2026-09-09 (Phase 13A/13C): PurpleKnight-Auditkorrekturen mit Profil 1.3.0 umgesetzt. 25 neue synthetische Tests sichern Workbook-Komposition, HTML-Kontext, native Feldpfade, volle Zeitpraezision, defekte/mehrdeutige Payloads, Summenabgleich, Null-/Leerfaelle und sichere CSV-Erkennung. Gesamtpruefung: 1.122 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Sicherheits-/Designcheck und beide Produktionsbuilds erfolgreich. Dummy: je 119 Ergebnisse fuer CSV/XLSX/HTML; 19 beziehungsweise 20 eindeutig verknuepfte Detailtabellen; HTML 45 Kontextbeobachtungen, 4.743 Originalfelder und 213 Detailzellen exakt. Parse-only-Abgleich aller 24 Dateien sowie finaler Drei-Format-Backendcheck erfolgreich, Repositoryrevision unveraendert. Backend verwendet weiterhin den verifizierten kanonischen Datastore. Keine Migration oder Reimportmutation. AGENTS.md, SECURITY.md, Importgrenzen und Pruefbericht aktualisiert; temporaere Pruefdateien entfernt. Phasenstatus unveraendert.

Verifiziert 2026-09-09 (Phase 13A/13C): PingCastle-Auditpunkte 1-3 umgesetzt und auf Profil 1.5.0 / Extractor 2.2.0 versioniert. Exakte XML-Attribute/Leere, HTML-Attributgrenzen und native ID-/Zaehlerdiagnosen mit 21 neuen Regressionen abgesichert. 1.096 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designcheck und Client-/Serverbuild erfolgreich. Dummy: beide Formate 37 Regeln; XML 403 Attribute und 70 leere Blaetter vollstaendig, HTML 125 Tabellen und 1.513 Kontextbeobachtungen ohne Attributreste. Parse-only im neu gestarteten Backend bestaetigt Zahlen und unveraenderte Repositoryrevision; kanonischer PostgreSQL-Container gesund, App/Backend/Proxy HTTP 200. Kein Reimport oder Persistenzeingriff. AGENTS.md und Sicherheitsvorgaben ergaenzt; historischer Pruefbericht um verifizierten Umsetzungsstand erweitert, temporaere Pruefdatei entfernt. Auditpunkte 4-5 und Phase-13C-Abnahme bleiben offen.

Verifiziert 2026-09-09 (Phase 13A/13C): Maester-HTML-Objektliterale sicher und ohne Ausfuehrung eingelesen, Excel-Result/Status kontextabhaengig getrennt, Originale und Berichtskontext erhalten, native Zaehler gegen Einzeltests validiert und Client-Info-Kontext um getrennte Maester-Fakten erweitert. Maester-Verarbeitungsmanifest 1.1.0 mit Reimportempfehlung, unveraenderter Historie und kompatibler Normalisierung. 47 neue synthetische Regressionen; Gesamtlauf 1.075 bestandene Tests, acht optionale PostgreSQL-Tests uebersprungen, Sicherheits-/Designpruefung und beide Builds erfolgreich. Dummy unabhaengig feldweise und anschliessend ueber den laufenden Parse-only-HTTP-Pfad geprueft: Excel/HTML je 318 Tests und 297 Evidenzen, HTML 39 Kontextwerte, zwei explizite Zaehlerwarnungen. App/Backend/Proxy HTTP 200, kanonischer PostgreSQL-Datastore bestaetigt, Repositoryrevision waehrend der HTTP-Pruefung unveraendert. Keine Migration oder Speicherung von Importdaten. Schutz- und Vollstaendigkeitsvorgaben in AGENTS.md, SECURITY.md und docs/IMPORT_SECURITY_LIMITS.md ergaenzt; temporaere Auditdateien entfernt.

Verifiziert 2026-09-09 (Phase 7): Bereichswechsel beschleunigt und Performance-Vorgaben in AGENTS.md sowie docs/architecture/navigation-performance.md verankert. Gemeinsame Ableitungen, lazy Rohtexte/Exporte/Blattoptionen, begrenztes erstes Rendering und pausierter versteckter Graph. 1.024 Tests, Local-only-/Designpruefung und beide Builds erfolgreich; acht optionale PostgreSQL-Tests uebersprungen. Dummy-Work: 5.324 ms initial beobachtet, abschliessend 121-211 ms bei unveraenderten Wiederbesuchen. Native Auswahl weiterhin vollstaendig, versteckte Graphfilter bei Reaktivierung aktuell; keine gezielte Datenmutation.

Verifiziert 2026-09-08 (Phase 7/13B): GPO-Quellenkorrektur fuer Work und Client Info. Aktuelle Evaluationen aus dem vorhandenen autoritativen Readmodell statt ergebnisabhaengiger Backupgruppierung; Import- und Auswertungszeit getrennt, Source-Scan-Provenienz auch auf GPO-only-Blaettern. 1.014 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Builds erfolgreich. Dummy lesend bestaetigt: eine statt drei GPO-Quellenoptionen, 3.805 aktuelle Zeilen, elf historische Evaluationen unveraendert. Keine Persistenzmutation oder Neuanalyse.

| Datum | Änderung |
| 2026-10-09 | Phase 13F, Korrekturen nach 2.23.0 (nur Engine-Code, Version unveraendert, da unveroeffentlicht): (1) `Mapping failed` im Tab `Compliance` oeffnete Work ohne Filter, wenn eine Zuordnung nach dem Laden der Work-Zuordnungen fehlschlug, weil ein Fehlschlag keine Entscheidung ist und Work den alten Stand behielt. Der Tab meldet jetzt jede Aenderung von Abdeckung oder Zuordnungshistorie; Work laedt dann neu und bietet bis dahin keinen veralteten Stand an, sodass der gewaehlte Filter erhalten bleibt (Regressionstests fuer Tab und Work). (2) Die Hybridsuche lieferte viele Treffer je Kontrolle, die alle ueber die Obergrenze hinaus behalten wurden; eine Purple-Knight-Zuordnung scheiterte mit `regulatory_mapping_prompt_too_large`. Treffer zaehlen jetzt in Rangfolge zur Obergrenze von 8.000 Zeichen je Kontrolle, der beste bleibt immer (Regressionstest). |
| 2026-10-09 | Governance (Core-Freigabe Governance): AGENTS.md uebernimmt die Entscheidungen des Tages, BSI Stufe 2 mit Migration 029, Konsistenzpruefung und Kachel `ISO ↔ BSI review`, Hybridsuche, volle ISO-27002-Kontrolltexte, `Compliance mapping` statt `Map all ISO controls`, `Mapping history` mit ISO und BSI, BSI-Suchindex in der Data-Hub-Kachel und die automatische Annahme nur starker Vorschlaege. |
| 2026-10-09 | Phase 13F, in Produktversion 2.23.0 enthalten (unveroeffentlicht; Core-Freigabe Presentation, Platform), Nutzerauftrag: Die Result-DB-Aktion `Map all ISO controls` heisst `Compliance mapping` (Fenster `Compliance mapping`, Aktivitaeten `Starting/Loading compliance mapping batch`), weil sie ISO und BSI startet. Die Data-Hub-Kachel `BSI GRUNDSCHUTZ++ KERNEL` zeigt den Suchindex des aktiven Katalogs (`Built`, `Building` mit Fortschritt, `Not built`, `Outdated`, `Build failed`, `Unavailable`) und bietet `Build search index` beziehungsweise `Rebuild search index`; neue Routen `GET /reference-data/bsi-grundschutz/search-index` und `POST .../search-index/build` (202, `force` fuer den Neuaufbau). Eine BSI-Zuordnung baut einen fehlenden Index weiterhin selbst. Mit Datenbankbereinigung: auf Nutzerwunsch wurden alle Zuordnungsdaten (242 Laeufe, 355 Entscheidungen, 5 Batches) nach verifizierter Sicherung `backups/assessor-pre-clear-mappings-20261009.dump` geloescht; neu zugeordnet wird durch den Nutzer. |
| 2026-10-09 | Phase 13F, in Produktversion 2.23.0 enthalten (unveroeffentlicht, nur Engine-Code), Nutzerentscheidung (ersetzt die vorlaeufige Annahme der ersten zwei Vorschlaege vom 2026-10-05 fuer ISO und BSI): automatisch angenommen werden hoechstens die ersten zwei starken Vorschlaege in Modellreihenfolge, also `primary` mit Konfidenz `high` oder `medium`; schwaechere Vorschlaege warten auf eine Person, ohne starken Vorschlag wird nichts angenommen. Bestehende Entscheidungen bleiben unveraendert. Auf den 20 Purple-Knight-Validierungslaeufen: ISO 21 von 25 automatischen Annahmen in der Referenz (vorher 29 von 39), BSI 16 von 26 (vorher 18 von 37). AGENTS.md beschreibt noch die alte Regel; die Anpassung braucht eine Governance-Freigabe. |
| 2026-10-09 | Phase 13F, in Produktversion 2.23.0 enthalten (unveroeffentlicht, nur Engine-Code), Nutzerauftrag: Hybridsuche fuer ISO und BSI. Je Lauf formuliert das Modell die oeffentliche Abfrage einmal auf Deutsch (`de-expansion-1.0.0`, je Abfrage geteilt zwischen ISO und BSI, im Lauf als `expansion` gespeichert); drei Ranglisten (dichte Suche Englisch, dichte Suche Deutsch, BM25 ueber die deutschen Begriffe im Speicher, `server/compliance/regulatory-lexical-index.ts`) werden per Reciprocal Rank Fusion auf Kontrollebene vereint. BSI laesst BES, DLS, GEB und PERS aus und sendet 16 statt 12 Kandidaten. Ohne deutsche Umformulierung bleibt es bei der englischen dichten Suche. Retrieval-Versionen `hybrid-rrf-de-1.0.0` und `bsi-hybrid-rrf-de-1.0.0`. Abfrage-Korrektur: Purple Knight wird unter `purple-knight-ad/-entra/-combined` erkannt, Indikator-IDs `SI` plus sechs Ziffern zaehlen als oeffentliche Regel-ID. Validierung an den 20 Purple-Knight-Regeln gegen die Referenztabelle: ISO-Referenz in den Kandidaten 42/50 (vorher 33), BSI 21/45 (vorher 4); automatisch angenommene Vorschlaege in der Referenz ISO 29/39 (vorher 28/39), BSI 18/37 (vorher 5/25). Die Laeufe nahmen 19 ISO- und 28 BSI-Entscheidungen automatisch an. |
| 2026-10-09 | Phase 13F, in Produktversion 2.23.0 enthalten (unveroeffentlicht, nur Engine-Code), Nutzerentscheidung: ISO-Prompt 1.3.0. Das Retrieval waehlt weiterhin die 8 Kontrollen; das Modell erhaelt je Kontrolle den 27001-Kontrolltext und den vollstaendigen 27002-Text (Kontrolle, Zweck, Leitlinien in Dokumentreihenfolge, danach weitere Informationen, soweit Platz), hoechstens 8.000 Zeichen je Kontrolle bei stets enthaltenen Treffern; Promptgrenze 96.000 Zeichen, bis zu 24 Evidenzabschnitte je Kandidat. Der Browser erhaelt weiterhin nur Zitate. Validierung an 20 Purple-Knight-Regeln (Client mit Nutzerfreigabe): erfolgreich, Prompt-Tokens Median 7.225 -> 17.994; die ersten zwei Vorschlaege bleiben bei 12 Regeln gleich, bei 8 aendern sie sich ohne messbare Verbesserung gegen die Referenz; Engpass bleibt die Kandidatenauswahl des Retrievals. Der Lauf nahm 9 Kontrollen automatisch neu an. |
| 2026-10-09 | Phase 13F, in Produktversion 2.23.0 enthalten (noch unveroeffentlicht, daher kein eigener Versionssprung; nur Engine-Code), Nutzerentscheidung: `Last mapping` und das Fenster `Mapping history` zeigen auch direkte BSI-Laeufe mit Spalte `Framework`; ein BSI-Lauf heisst auf dem Knopf `· BSI`. Synthetische Dienst- und UI-Tests angepasst und ergaenzt. |
| 2026-10-09 | Phase 13F, Produktversion 2.23.0 (Minor: neue sichtbare Faehigkeit; Core-Freigabe Store, Presentation, Platform, Core Tests): BSI Grundschutz++ Stufe 2. Direkte BSI-Zuordnung mit eigenem Korpus und Prompt, Migration 029 nach verifiziertem Backup, Konsistenzpruefung ISO <-> BSI mit Kachel und Pruefliste im Tab `Compliance`, BSI-Teil im Finding Reader und im Batchdialog; vorlaeufig automatische Annahme auch fuer BSI. Details im Abschnitt Stufe 2 mit Konsistenzpruefung. |
| 2026-10-08 | Phase 13F, in Produktversion 2.22.0 enthalten (nur Engine-Code), Nutzerentscheidung: Der Finding-Reader-Abschnitt `BSI requirements` war in Work zu gross. Er startet jetzt wie `Context` eingeklappt (Zusammenfassung mit Anzahl), gruppiert die Anforderungen unter ihrer ISO-Kontrolle (`A.5.18 · subset-of`, die Beziehung gilt fuer die ganze BSI-Gruppe) als einzeilige Eintraege und zeigt den Anforderungstext erst beim Aufklappen eines Eintrags; die Quellenangabe ist eine kurze Zeile, der vollstaendige Lizenzhinweis bleibt im Client-Info-Results-Fenster. Ein ueber zwei ISO-Kontrollen erreichte Anforderung steht unter beiden. Ein gemeinsamer `Compliance`-Kasten fuer ISO und BSI wurde erwogen und vom Nutzer verworfen; `ISO controls` bleibt unveraendert offen. Test: eingeklappt, Gruppen, Aufklappen eines Eintrags, neues Finding wieder eingeklappt, Engine aus. |
| 2026-10-08 | Phase 13F, in Produktversion 2.22.0 enthalten (noch unveroeffentlicht, daher kein eigener Versionssprung; Core-Freigabe Presentation, Platform, Governance, Core Tests), Nutzerauftrag: Data-Hub-Kachel `BSI GRUNDSCHUTZ++ KERNEL` wie die MITRE-Matrix unter der ISO-Korpus-Kachel, nur bei eingeschalteter Engine. Plakette mit Katalogdatum, Zuordnungsversion und Herkunft (`Bundled`/`Updated`); `Update from BSI` laedt im Backend genau die zwei festen offiziellen Dateien vom BSI-Branch `main` (HTTPS, keine Weiterleitung, 120 s, 32 MiB je Datei), prueft sie fail-closed mit dem Konverter, aktiviert nie einen aelteren Stand und speichert den kompakten Stand mit Quell-URL und SHA-256 atomar und privat in `regulatory-corpora/bsi/active-catalog.json`; `Use bundled catalog` erscheint nur danach und kehrt zu den gepinnten Snapshots zurueck. Engine-Dienst `BsiCatalogService`, die Ableitung liest den aktiven Stand; Routen `GET /reference-data/bsi-grundschutz`, `POST .../refresh` und `POST .../reset` (Fehler 502 mit Code, ohne Dienst 503); Aktivitaetslabels; nach Update oder Ruecksetzen laden Client Info und Work neu. Sicherheitsmodell in `SECURITY.md` fuer das neue ausgehende Ziel ergaenzt (Nutzerfreigabe), `AGENTS.md` fortgeschrieben. Tests: Dienst (Standard, Update, unveraendert, kein Rueckschritt, Fehlerfaelle ohne Aenderung, Ruecksetzen, beschaedigter und veralteter Speicher), Routen, Kachelinteraktion, Engine aus, Platzierung, Ableitung aus dem aktiven Stand. Kein Live-Abruf gegen GitHub in Tests. |
| 2026-10-08 | Phase 13F, Produktversion 2.22.0 (Minor: neue sichtbare Faehigkeit; Core-Freigabe Presentation, Platform, Core Tests, Governance): BSI Grundschutz++ Stufe 1 sichtbar. Der Engine-Dienst haengt an Einzelzuordnung (`GET regulatory-mappings`), Client-Info-Uebersicht und Work-Zuordnungen ein optionales `bsi`-Feld mit den aus akzeptierten ISO-Kontrollen ueber die gepinnte BSI-Zuordnung abgeleiteten Kernel-Anforderungen (Anforderungstext mit aufgeloesten Parametern, ISO-Route und Beziehung, Katalog-/Zuordnungsversion, CC-BY-SA-Hinweis, fehlende Ziele); ohne Ableitung entfaellt das Feld, ISO-Antworten bleiben unveraendert; keine neue Route. Finding Reader: Abschnitt `BSI requirements` direkt nach `ISO controls`. Client Info `Compliance`: Kachel `BSI Grundschutz++` neben ISO mit `Requirements`, `Findings` und den vier Praktiken mit den meisten Findings (ein Finding zaehlt je Praktik einmal); `Results` listet alle Anforderungen nach Praktik in Katalogreihenfolge mit ISO-Route, Quelle und fehlenden Zielen; Zeile und Praktik oeffnen Work mit `Deviation` und der Facette `BSI requirement` bzw. `BSI practice`. Work: beide Facetten nach den ISO-Facetten und vor `Source: Scan`, nur wenn eine Anforderung abgeleitet ist; Werte in Kleinschreibung wie `ISO theme`. `AGENTS.md` nennt Entscheidung und Erweiterungspunkte. Tests: Dienst (Ableitung, Ablehnung entfernt sie), Kachel und Results-Fenster, Finding-Reader-Abschnitt mit Engine aus, Work-Facetten und Filterung, Client-Info-Drilldown; `npm test` 2165 bestanden, 18 uebersprungen; beide Produktionsbuilds bestanden. Sichtpruefung in der laufenden App (beide Themes) steht aus. |
| 2026-10-08 | Phase 13F, BSI Grundschutz++ Stufe 1 Datenschicht (nur Engine-Code, keine Produktversion, weil noch nicht sichtbar): Konverter fuer die Kernel-Anforderungen des aufgeloesten Anwenderkatalogs (Klasse `BSI-Stand-der-Technik-Kernel-G0`, 901 Anforderungen; Praktik, Elternanforderung, Anforderungs- und Erlaeuterungstext unveraendert mit OSCAL-Parameterplatzhaltern, Parameterwert oder -bezeichnung, Modalverb, Sicherheits- und Aufwandsstufe) und fuer die BSI-Zuordnung ISO 27001 Annex A -> Kernel (83 Eintraege, Beziehung unveraendert). Fehlerhafte Eingaben (fehlende Version, ID oder Anforderung, wiederholte IDs, unbekannte Parameter, Beziehungen oder Quellen) scheitern ausdruecklich. Snapshots werden wie die MITRE-Kataloge aus den offiziellen Dateien des gepinnten BSI-Commits mit Quell-URL, Quell-SHA-256 und CC-BY-SA-Hinweis erzeugt; die Erzeugung ist bytegleich reproduzierbar. `deriveBsiRequirements` leitet aus akzeptierten ISO-Kontrollen Kernel-Anforderungen mit jeder ISO-Route reihenfolgeunabhaengig ab und weist im Katalog fehlende Ziele aus (`BER.5.1.2`, `BER.6.8`, `DET.3.1.13`, `GEB.5.4`). Das Generatorskript ist `.mjs`, weil die Server-Typpruefung keine `.ts`-Importendungen erlaubt. Tests: `tests/compliance/bsi-grundschutz.test.ts` (9); `npm test` 2156 bestanden, 18 uebersprungen; beide Typpruefungen bestanden. |
| 2026-10-05 | Phasen 6/13F, in Produktversion 2.19.0 enthalten, Disclosure Policy 3.6.0 (Core-Freigabe Normalization, Disclosure, Presentation, Core Tests): Neues allgemeines Result-DB-Feld `technicalExplanation` fuer die technische Erklaerung einer Regel, wo ein Scanner sie liefert (heute PingCastle `Technical explanation`; andere Werkzeuge lassen es leer). Es wird beim Aufbau der Result DB aus dem bereits importierten Originalfeld gelesen (Schluessel `technical-explanation` oder Bezeichnung `Technical explanation`), daher ohne Reimport, in Local- und PostgreSQL-Repository ueber dieselbe Funktion. Es ist oeffentliche Regelanleitung wie `Description`, wird genauso streng redigiert (nur bekannte Scanner, unbekannte Quellen fail-closed, GPO ohne Feld), vom Identitaetsschutz geprueft und im inhaltsfreien Trace gefuehrt; `Details` mit Umgebungswerten bleibt zurueckgehalten. Die Policy-Erhoehung baut die gespeicherte Result DB neu auf. Result-DB-Details zeigen das Feld, Excel und CSV fuehren die Spalte nach `Description`. Die ISO-Zuordnung nimmt die redigierte technische Erklaerung in Suche und Modellanfrage auf; bestehende Zuordnungen behalten ihre ID. Tests: beide Importwege, Redaktion, Trace, Identitaetsschutz, fail-closed, interne Analyse mit Original, ISO-Abfrage. |
| 2026-10-05 | Phase 13F, Produktversion 2.19.0 (Minor: neue Work-Faehigkeit; Core-Freigabe Governance, Presentation, Platform, Core Tests): Work erhaelt die Compliance-Engine-Facetten `ISO control` (je akzeptierter Kontrolle, `A.8.20 · Networks security`) und `ISO theme` (Organizational, People, Physical, Technological) wie die Context-Cluster-Facette, direkt vor dem permanenten `Source: Scan`, in gemischtem Work und beiden GPO-Einstiegen (Erweiterung der GPO-Facettenliste per Nutzerentscheidung). Grundlage ist der neue Endpunkt `GET /projects/:id/regulatory-control-assignments` mit den akzeptierten Kontrollen aller zuordenbaren Findings des Timeslots (nicht nur Abweichungen), damit der Work-Statusfilter wie gewohnt wirkt; Scanner-Findings ueber das Vorkommen, GPO-Einstellungen ueber Scope und technische Identitaet (gemeinsamer Helfer `gpoWorkSettingIdentity`). Eine Anfrage je Timeslot fuer alle fuenf Work-Verbraucher, Neuladen nach jeder Entscheidung, aktive Auswahl bleibt waehrend des Ladens; ausgeschaltet entfallen die Facetten und ein aktiver ISO-Filter wird entfernt. Themenwerte werden kleingeschrieben verglichen, die Anzeige bleibt ISO-Schreibweise. Die Client-Info-Kachel oeffnet Work jetzt mit Status `Deviation` und der Kontrolle im `ISO control`-Filter statt einer festen Record-Liste. Aktivitaetslabel `Loading ISO control filters`. Tests: Werte, Zaehlung gegen andere Filter, Scanner- und GPO-Abgleich, Thema, Position vor `Source: Scan`, geteilte Anfrage, Neuladen, Engine aus mit Filterentfernung, Kachel-Sprung; Version-UI/API-Tests und beide Builds. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten (nur Engine-Code), vorlaeufige Nutzerentscheidung: Nach einer erfolgreichen Zuordnung werden die ersten zwei Vorschlaege in der Reihenfolge des Modells automatisch akzeptiert (bei nur einem Vorschlag nur dieser), mit dem Kommentar `Accepted automatically: one of the first two proposals of the mapping.`; eine Kontrolle mit bestehender Entscheidung behaelt sie, ein manuelles Reject wird also nie ueberschrieben, und ein Fehler dabei laesst die Zuordnung erfolgreich. Gilt fuer Einzel- und Batchzuordnung. Einmalige Nachholung ueber die normale Entscheidungs-API fuer die bestehenden 130 Regeln mit erfolgreichem Lauf (129 mit Vorschlaegen, 1 ohne): 210 Entscheidungen fuer 112 Regeln angelegt (98 mit zwei, 14 mit einer akzeptierten Kontrolle), 33 bereits entschiedene Kontrollen uebersprungen, keine Fehler. Die Regel steht seit der Governance-Freigabe vom selben Tag als vorlaeufige Nutzerentscheidung in den verbindlichen Projektregeln. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten (nur Engine-Code): Das Aktivitaetspanel sprang waehrend laufender ISO-Arbeit, weil jede Statusabfrage (alle 1,5 s bei Zuordnung und Batch, alle 2 s beim Korpus-Embedding) einen neuen Eintrag startete; das Panel oeffnet sich bei jedem neuen Eintrag und klappt die Historie zu, kurz sichtbar wurden dabei die Core-Gruppen der Historie. Wiederholte Statusabfragen laufen jetzt ueber einen eigenen Client ohne Protokolleintrag (`describeActivity`); der eine Eintrag je laufender Arbeit bleibt, das erste Laden jeder Ansicht wird weiter protokolliert. Tests ersetzen die Anfrage unterhalb der Protokollierung und pruefen, dass waehrend des Laufs kein neuer Eintrag startet; ohne die Korrektur scheitern sie. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten (nur Engine-Code): Seit `Map ISO controls` ein Fenster ist, endete der Protokolleintrag `Mapping ISO controls` beim Schliessen des Fensters mit `continues in the backend`, und das Protokoll meldete `All tasks completed`, waehrend das Modell noch lief. Ein Lauf-Tracker der Engine haelt den Eintrag jetzt je laufender Zuordnung bis zum Endzustand des Backends, unabhaengig von Fenster, Finding und Ansicht; Fenster und Reader-Abschnitt uebernehmen seine Statusaktualisierungen, sodass nur einmal gepollt wird. Ausschalten der Engine beendet nur die Beobachtung. Tests fuer geschlossenes Fenster bis Abschluss und fuer einen fehlgeschlagenen Lauf. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten (Core-Freigabe Governance, Presentation, Platform, Core Tests): ISO-Kontrollen als Fenster und als eigene Abschnitte. `Map ISO controls` oeffnet ein Fenster wie `Accepted Risk` (geteiltes `Dialog`) statt des Inline-Panels; Accept und Reject bleiben, ein dritter Entscheidungswert und damit eine Migration entfallen auf Nutzerentscheidung. Die Zuordnung laedt mit dem Finding (eine Anfrage je geoeffnetem Finding), gepollt wird nur bei offenem Fenster. Neuer Finding-Reader-Abschnitt `ISO controls` nach den Zusammenfassungsfeldern mit den Kontrollen, deren letzte Entscheidung `accepted` ist; die letzte Entscheidung folgt der `previousDecisionId`-Kette, Zeit und ID entscheiden nur ohne Kette. Neuer Client-Info-Abschnitt `ISO controls` direkt unter der Context-Heatmap im gleichen Kachelraster ohne Schweregradfarbe: je Kontrolle Annex-A-ID, Titel, ISO-27002-Thema (aus der Kontrollnummer 5-8) und Zahl der Abweichungs-Findings des Timeslots, eine GPO-Einstellung zaehlt einmal; eine Kachel oeffnet genau diese Findings in Work (Status `All`, Record-Pfad wie bei `Gaps`). Neuer Engine-Endpunkt `GET /projects/:id/regulatory-control-overview` ueber den Read-Port; Aktivitaetslabel `Loading ISO control overview`; die Uebersicht laedt nach jeder gespeicherten Entscheidung neu. Neue Erweiterungspunkte im Grenztest (Client Info) und in `AGENTS.md`. Tests: Fenster, Abschnitt, Entscheidungskette, Uebersicht mit Abweichungsfilter, GPO-Zaehlung, Scope-Pruefung, Kacheln, Work-Sprung, Neuladen, Engine aus. |
| 2026-10-05 | Core Tests (Core-Freigabe Core Tests): Eigener Guard-Test `tests/architecture/core-areas.test.ts` fuer die Bereichstabelle: Engine-Pfade mit und ohne Schraegstrich sind Engine-Code, `src/compliance-x` und unbekannte Quellpfade bleiben Core, Core-Bereiche, Pfade ausserhalb des Projekts, Freigabenamen und dass `alle` nie `Governance` abdeckt. Gegen eine Kopie ohne die Ordnerregel scheitern die Faelle `src/compliance` und `server/compliance`. |
| 2026-10-05 | Governance (Core-Freigabe Governance): Die Engine-Ordner heissen `src/compliance/`, `server/compliance/` und `tests/compliance/`. Der Core-Guard (`.claude/hooks/core-areas.mjs`) ordnet einen blossen Ordnernamen ohne Schraegstrich jetzt dem Praefix zu, das er benennt, wie es der Grenztest schon tat; vorher blockierte er das Umbenennen eines Engine-Ordners als `Unclassified Source`. Ein laengerer Name wie `src/compliance-x` bleibt Core. Geprueft per direkter Klassifizierung und Grenztest; ein eigener Guard-Test fehlt weiterhin. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten: Die Compliance Engine steht im Engine-Diagramm der Ansicht Data Flow (Core-Freigabe Presentation, Core Tests). Neue vierte Reihe unter dem Core-Read-only-Port: `Compliance Engine` (Engine-Rahmen), `Compliance tables`, `Retrieval & model` und `ISO mapping in the UI`, mit vier Beziehungen (Port -> Engine nur lesend, Engine <-> eigene Tabellen, Engine <-> Qdrant/LiteLLM, Engine -> UI-Erweiterungspunkte); die bestehenden neun Knoten behalten ihre Positionen, die Karte waechst von 650 auf 940 px. Die Port-Beschreibung nennt offen, dass die Compliance Engine noch ueber das laufende Core-Repository liest; die Beziehungszahl im Verzeichnis wird aus der Liste berechnet (13). Geometrie, beide Themes und die Hervorhebung der vier Pfeile im laufenden Frontend geprueft; Diagrammtest erweitert. |
| 2026-10-05 | Phase 13F, in Produktversion 2.18.0 enthalten: Aktivitaetsprotokoll fuer die Compliance Engine korrigiert. Ihre API-Anfragen fielen auf die generischen Core-Muster und erschienen als `Core Engine · Loading clients`, `Processing clients` oder `Loading application data`; `src/api/request-activity.ts` ordnet die Routen fuer Zuordnung, Vorschlaege, Entscheidungen, Batch und ISO-Korpus jetzt vor den Projektmustern der `Compliance Engine` zu (Core-Freigabe Platform). Zusaetzlich haelt die Engine je laufender Backendarbeit (`Mapping ISO controls`, `Mapping all ISO controls`, `Embedding ISO corpus`) einen Eintrag offen, bis das Backend einen Endzustand meldet; ein Fehlschlag wird als fehlgeschlagen gefuehrt, und eine Ansicht, die nicht mehr beobachtet, beendet den Eintrag mit dem Hinweis `continues in the backend`. Tests fuer alle Routen und fuer laufenden, abgeschlossenen, fehlgeschlagenen und nicht mehr beobachteten Batch. |
| 2026-10-05 | Phase 13F, Produktversion 2.18.0 (fasst das unveroeffentlichte 2.17.1 mit ein): ISO-Zuordnung als Compliance Engine ausgelagert, Nutzerentscheidung mit Core-Freigabe. Name `Compliance Engine`, bestehende drei Tabellen bleiben und gehen an die Engine, in diesem Schritt nur Verschiebung ohne Verhaltensaenderung; die frameworkneutrale Erweiterung folgt getrennt. 41 Dateien verschoben (23 Quell-, 18 Testdateien); der Filtertyp `ResultDbFilters` liegt jetzt in `src/domain/result-db-query.ts`. Die neun Regulatory-Methoden und drei Exportfelder sind aus `AssessorRepository`, Local- und PostgreSQL-Repository entfernt; `LocalComplianceStore` und `PostgresComplianceStore` uebernehmen sie unveraendert, der Projektexport fuegt die Engine-Daten an der HTTP-Route hinzu. `RegulatoryMappingService` erhaelt Read-Port und Store getrennt. Engine-Pfade in `.claude/hooks/core-areas.mjs`, neue Extension Points (Finding Reader, Result DB, Data Hub, API-Vertrag und -Client typ-only, Serververdrahtung) im Grenztest, Entscheidung in `AGENTS.md`. Neue Tests: permanente Invarianz (Revision, Projektexport und Result DB unveraendert nach Einzelzuordnung, Entscheidung und Batch; Port ohne Schreibmethode), Schalter in Finding Reader, Result DB und Data Hub, Projektexport mit und ohne Engine. |
| 2026-10-05 | Phase 13F, Produktversion 2.17.1: Merge-Regression der ISO-Kontrollzuordnung behoben. Seit 2.9.0 liefert `getUnifiedResultById` Result-DB-Zeilen ohne echte Scope-IDs (`projectId: scoped-project`); der Zuordnungsdienst verglich danach `finding.projectId` mit dem Projekt und meldete fuer jedes Finding `The selected finding does not exist in this project.` Die Lesemethode nimmt jetzt optional `projectId` und filtert in PostgreSQL ueber die vorhandene Spalte `project_id` (lokal vor dem Entfernen der Scope-IDs); der Dienst nutzt diese Abfrage. Die zurueckgegebene Zeile und die Result-DB-Offenlegung bleiben unveraendert. Der Mock im Dienst-Test bildet die Entfernung der Scope-IDs jetzt nach; neuer Regressionstest fuer Laden, Start und Entscheidung im eigenen Projekt und deren Ablehnung fuer ein fremdes Projekt, dazu Pruefungen der Projektbindung im lokalen und im PostgreSQL-Repository (Letztere ohne Testdatenbank uebersprungen). |
| 2026-10-05 | Phasen 6/7/13A, Produktversion 2.17.0: `merge/defender-for-iot` auf `250c213` (Michael, Business Impact + Management Report, 2.16.5) rebased; Michaels Commit ist die Basis, die 25 Branch-Commits liegen darauf. Die Minor-Erhoehung der Defender-Serie (zuvor 2.11.2 -> 2.12.0, Eintrag unten historisch) wird auf dieser Basis 2.16.5 -> 2.17.0; `package.json`, Root-Eintraege in `package-lock.json` und die Versionsvertragstests sind synchron. Korrektur aus `2b5fdf3`: `isDeviationRecord` uebersprang Maester `Result` immer als Ergebnisnachricht; nach AGENTS.md ist `Result` nur neben einer eigenen Statusspalte Evidenz, sonst der native Status. Michaels neuer Sidebar-Test deckte das auf; synthetische Regression in `tests/domain/deviation-predicate.test.ts`. Michaels Result-DB-Leerzustandstest erwartet nun das mit `55da786` eingefuehrte `audience: 'result-db'`. Kein Reimport, keine Migration, nicht im Browser geprueft. Verifikation: Gesamtlauf mit 2.049 bestandenen und 18 uebersprungenen Tests, beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 13A, Disclosure Policy 3.5.0: Defender-Teil von `21a6266` uebernommen; `48a1888` (PingCastle-Aggregate, steht gegen die Zaehlwert-Grenze der Policy 2.0.0) und `78ea9a6` auf Nutzerentscheidung ausgelassen. Die Result DB kennt Microsoft Defender for IoT als Werkzeug statt `Security assessment`; freigegeben wird nur eine formal gueltige oeffentliche CVE-ID als Rule ID und zugleich als Titel. Geraete-, Site-, Sensor- und Zaehlwerte bleiben ausgeschlossen, `affectedAsset` bleibt zurueckgehalten; das Alerts-Profil bleibt generisch. Die zurueckgestellte `securityToolId`-Zeile aus `c056c21` bildet beide Defender-Namen auf den Schluessel `defender-for-iot` ab. Regression: Work und Result DB benennen ein Defender-Finding ueber die Projektion mit seiner CVE. `docs/RESULT_CONTRACT.md` beschreibt 3.5.0; die Versionsaufzaehlung der Result-DB-Regel in `AGENTS.md` ist nicht angepasst (Governance nicht freigegeben). Die materialisierte Result DB wird nach dem naechsten Backendstart mit der neuen Policy neu aufgebaut. Verifikation: beide Typechecks, Gesamtlauf mit 1.921 bestandenen und 18 uebersprungenen Tests sowie dem bekannten lastbedingten Ausfall von `sheet-selection-cost.test.tsx` (allein bestanden), Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 13A: Geraeteteil von `95ec322` nachgezogen. `defenderRiskTargetsForOccurrences` ordnet Devices ueber die Quellzeilen der jeweiligen Occurrence zu statt ueber die CVE allein; fuehren zwei Occurrences dieselbe CVE mit unterschiedlichen Devices, bleibt jedes Device bei seiner eigenen Occurrence, und ein `device-finding` fuer ein Device ausserhalb der gewaehlten Occurrence wird abgelehnt. Das stuetzt die Regel, dass eine geraetebezogene Entscheidung nur ihre erfassten Occurrences deckt. Zwei Regressionen (Domain, lokales Repository) uebernommen. Keine API-, SQL- oder Persistenzaenderung. Verifikation: beide Typechecks, Gesamtlauf mit 1.922 bestandenen und 18 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 7: Defender-Teil von `3f6259d` (Stile und Dashboardtest) nachgezogen. Kennzahlbeschriftungen und Tabellenkoepfe des Defender-Panels nutzen die 14px-Tabellenrolle statt der 12px-Labelrolle; die Kennzahlen stehen als kompakte Kacheln (`--tile-compact-width`) in einem Segment statt in sechs festen Spalten; der Zeilenmarker nutzt `--marker-width`. Beibehalten gegenueber dem Original: Kachelkontur `--tile-border`, gemeinsame Textrollen und die blaue Tabellenzeilen-Markierung. Nur CSS und Testassertions; nicht im Browser geprueft. Verifikation: beide Typechecks, Gesamtlauf mit 1.920 bestandenen und 18 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/7/13A, Produktversion 2.12.0: `fdd46e8` (Profil Microsoft Defender for IoT Alerts) angepasst uebernommen. Profil `defender-for-iot-alerts` 1.6.0 mit Domain-Modell, Source Extractor, Manifestzeilen und deklarierten Scoring-/Prioritaets-/Timeslot-Vertraegen (kein nativer Gesamtscore, native Alarm-Severity, kein Timeslot-Vergleich). Alarme werden je Alarmtyp gruppiert; unterschiedliche Beschreibungen eines Typs erscheinen als gemeinsame Woerter mit `…`, die zugehoerige Nutzerregel steht mit ausdruecklicher Governance-Freigabe in `AGENTS.md`. Werkzeuguebergreifend: Unterstriche innerhalb eines Wortes sind in `markdown.ts` keine Auszeichnung mehr; ein Profil kann per `selectExtractedTables` die Tabellen behalten, aus denen sein Extractor Findings gebildet hat; ein Statusmapping kann sein Outcome deklarieren; beide Repositories setzen eine bereits durch einen ersetzten Lauf belegte Scan-Sequenz hinter alle gespeicherten Laeufe. Die Ausblendung von `Source Observations` liegt auf dieser Basis in `FindingReader.tsx`. Zwei Korrekturen aus spaeteren Commits waren fuer Defender auf dieser Basis noetig und sind vorgezogen: aus `210bbc0` der Titel-Rueckfall in `recordTitleFor` (eine leere gewaehlte Titelspalte faellt wieder auf den Datensatztitel zurueck; mit `7d3ef5f` war dieser Rueckfall fuer alle Scanner verloren gegangen) samt Regression fuer die GPO-Zeile, und aus `21a6266` die Ausnahme in `withSourceRuleId`, die eine native ID-Spalte nicht in `Source Rule ID` umbenennt, wenn sie zugleich der Finding-Titel ist (Defender `CVE`, Alert `Title`); die Regel-ID wird dann zusaetzlich angefuegt. Nicht uebernommen: die Versionsangabe 2.10.8 des Originals. Produktversion: Minor-Erhoehung von 2.11.2 auf 2.12.0 fuer die Defender-Serie (zwei neue Scannerprofile, geraetebezogene Risikoakzeptanz); `package.json`, Root-Eintraege in `package-lock.json` und die Versionsvertragstests sind synchron. Die `securityToolId`-Zeile aus `c056c21` folgt mit dem Result-DB-Werkzeugeintrag aus `21a6266`. Neue Profile, daher kein Reimport bestehender Importe; keine SQL-Migration. Nicht im Browser geprueft. Verifikation: beide Typechecks, Gesamtlauf mit 1.920 bestandenen und 18 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 7/13A: `d9ff6a8` (geraetebezogene Risikoakzeptanz fuer Defender) angepasst uebernommen. Neben der bestehenden Akzeptanz des ganzen Findings gibt es die Ziele `device-finding` (ein Device mal eine CVE) und `device-snapshot` (alle aktuellen CVEs eines Device) mit unveraenderlichem Zielabbild und append-only Historie. Migration `028_scoped_risk_acceptances.sql` legt die projektgebundene Tabelle `assessor_scoped_risk_acceptances` an (Cascade bei Projektloeschung); beide Repositories, `GET`/`POST /api/v1/projects/:id/risk-acceptances/scoped`, App-State, Defender-Panel (Abdeckungszeile, deckende Entscheidungen, `Accept all current findings`), Finding Reader/Dialog und das Accepted-Risks-Register sind erweitert. Nutzerentscheidung 2026-10-02, abweichend vom Original: (1) Die Zaehlung `current` im Register bleibt bei der Basisregel `Accepted`, `Scheduled`, `Review due`, `Review required`. (2) Geraetebezogene Entscheidungen folgen der Regel fuer ganze Findings: sie decken nur die erfassten Occurrences; nach einem Reimport oder entfernten Scan-Lauf sowie bei einer nicht erfassten Occurrence desselben Device und derselben CVE bleibt die Entscheidung mit vollstaendiger Historie erhalten, zeigt `Review required` und deckt nichts. Der Marker `capturedScopeReplaced` wird bei jedem Lesen aus den aktuellen Scan-Laeufen abgeleitet und nie gespeichert. Offen: Ersetzte geraetebezogene Entscheidungen fliessen nicht in die Reimport-Transferzaehlung je Datei und damit nicht in den Data-Hub-Verarbeitungsstatus ein; das Defender-Panel listet nur deckende Entscheidungen. Neue Regressionen: Domain (erfasste gegen ersetzte Occurrence, Marker, Widerruf, keine Persistenz des Markers), lokales Repository (Reimport desselben Berichts mit geaenderter Device-Identitaet) und Register. Der opt-in PostgreSQL-Integrationstest lief nicht; der PostgreSQL-Lesepfad des Markers ist damit nur typgeprueft. Vor der Migration wurde das verifizierte Backup `backups/assessor-pre-028-20261002-132810.dump` erstellt. Nicht im Browser geprueft. Verifikation: beide Typechecks, Gesamtlauf mit 1.908 bestandenen und 18 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/7: Defender-Teile von `b438f25` uebernommen (nach `c7c716c`, weil der Commit zunaechst nur als NVD-Korrektur eingeordnet war). CVE-, Device- und Site-Tabelle des Defender-Panels klappen ihre Details direkt unter der angeklickten Zeile auf und wieder zu (Dreieck-Schalter, `aria-expanded`/`aria-controls`); die CVE-Tabelle fuehrt die Beschreibung nur noch im Detail. Der Extractor gibt die Tabelle `Affected Devices` als `Name`, `IP Address`, `Scanner`, `Site` aus. Abweichend vom Original nutzt die aufgeklappte Zeile nach Nutzerentscheidung die blaue Tabellenzeilen-Markierung (`--table-row-marking`, `--table-row-marking-surface`) statt Gelb, und der Drilldown bleibt auf den gemeinsamen Kachelrollen. Nicht uebernommen: die `baseSeverity`-Korrektur im NVD-Client samt Test (CVE-Anreicherung ausgelassen) und der `.gitignore`-Eintrag. Kein Profilversionssprung wie im Original; die Tabellenspalten liegen bereits unter dem danach uebernommenen Profil 1.2.0, die lokale Datenbank enthaelt keine Defender-Importe. Nicht im Browser geprueft. Verifikation: beide Typechecks, Gesamtlauf mit 1.896 bestandenen und 17 uebersprungenen Tests (ein lastbedingter Einzelausfall in `node-import-engine.test.ts` im ersten Lauf, allein und im Wiederholungslauf bestanden), Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/13A: `c7c716c` vollstaendig uebernommen. Das Defender-Profil 1.2.0 mit Extractor 1.1.0 erkennt zusaetzlich das synthetische `Mock-Defender`-CSV-Paar aus CVE-Export und Device-Inventar ueber Header-Aliase, verwendet eine quellnative `Device ID` als erste Identitaetsmethode vor MAC, IP und Name, legt Inventar-Devices auch ohne CVE an und bewahrt jede nicht kanonische Spalte als zusaetzliches Quellfeld. Neue Manifestzeile 1.2.0, 1.1.0 ist nicht mehr aktuell; der Kompatibilitaetsschluessel bleibt wie im Original `-v2` bei Reimport-Pflicht, die lokale Datenbank enthaelt keine Defender-Importe. Die auf dieser Basis verpflichtenden Scoring-, Prioritaets- und Timeslot-Deklarationen des Profils bleiben unveraendert. Keine API-, SQL- oder Persistenzaenderung. Verifikation: beide Typechecks, Gesamtlauf mit 1.895 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 7: `08771d5` angepasst uebernommen; `c056c21` (CWE-Links, baut auf der ausgelassenen CVE-Anreicherung auf) ausgelassen, seine Scoring-Zeile fuer `securityToolId` folgt mit dem Result-DB-Werkzeugeintrag. `findingOutcomeMark` liefert die Outcome-Marke fuer Work-Karte und Finding-Reader-Kopf; Werkzeuge ohne Statusspalte erhalten sie aus `missingStatusOutcome` (Defender: `Warning`), alle anderen behalten ihr eigenes Statuswort. Die GPO-Diagnoseplaketten der Karte und die Vergleichs-Outcome-Ableitung des Readers bleiben unveraendert. Das Defender-Panel nutzt den Client-Info-Kopf (`Client`, `Assessment`, `Source`) und eine sechsspaltige Kennzahlzeile mit Container-Queries. Abweichend vom Original bleiben Kacheln, Sichten und Drilldowns auf den gemeinsamen Rollen `--tile-surface`, `--tile-border`, `--tile-radius`, `--text`, `--heading` und `--muted` statt `--client-info-*`, `border: 0` und `--btn-radius`, damit die verbindliche Kachelregel durchgehend gilt. Nicht im Browser geprueft, weil die lokale Datenbank keine Defender-Importe enthaelt. Keine API-, SQL- oder Persistenzaenderung. Verifikation: beide Typechecks, Gesamtlauf mit 1.893 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 13A: Aus `33d2019` nur die Dokumentation uebernommen. `docs/CANONICAL_MODEL.md` beschreibt `vulnerability_finding` als additive ASSESSOR-Erweiterung des externen `result_type`-Katalogs; der Kommentar an `CanonicalResultType` verweist darauf. Nicht uebernommen: die Backfill-Migration (frueher 023) samt Katalogeintrag und Schema-Assertions, weil die neu angelegte lokale Datenbank keine Defender-Occurrences enthaelt, sowie auf Nutzerentscheidung der lesende Outcome-Fallback in `unified-result.ts` mit seinem Test; neue Importe erhalten `warning` bereits ueber `missingStatusOutcome`. Keine Verhaltens-, API-, SQL- oder Persistenzaenderung. Verifikation: beide Typechecks, Gesamtlauf mit 1.890 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/13A: `fe71246` uebernommen; `e048295` (NVD-CVE-Anreicherung) auf Nutzerentscheidung vorerst ausgelassen. Der Result-Contract kennt den Typ `vulnerability_finding`; Defender-Findings erhalten ihn. Ein Profil kann `missingStatusOutcome` deklarieren, Defender setzt `warning`, weil jede CVE-Zeile selbst der Befund ist. Das Defender-Profil steigt auf 1.1.0 mit Kompatibilitaetsschluessel `-v2` (semantic-breaking, Reimport erforderlich; die lokale Datenbank enthaelt keine Defender-Importe), 1.0.0 ist nicht mehr aktuell. Der Work-Filter `Deviation` aller Scanner nutzt statt der Regex-Liste `UNIVERSAL_DEVIATION_PATTERNS` nun `isDeviationRecord` und damit das kanonische Result-DB-Praedikat; die GPO-Statuslogik, der Statuscache und die uebrigen Statusfilter der Basis bleiben unveraendert davor. Alle bestehenden Work-, Filter- und Scannertests bestehen unveraendert; eine vollstaendige Gleichwertigkeit fuer jeden realen Statuswert ist damit nicht bewiesen. Migration `027_vulnerability_finding_result_type.sql` (frueher 022) erweitert nur den Check-Constraint und schreibt keine Occurrences um; ohne die ausgelassene CVE-Tabelle. Vor der Anwendung wurde das verifizierte Backup `backups/assessor-pre-027-20261002-123608.dump` erstellt. Verifikation: beide Typechecks, Gesamtlauf mit 1.890 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/7/13A: `5fbbda2` uebernommen. Der Defender-Extractor erzeugt nun ein Finding je CVE statt je Device-mal-CVE und liefert `Affected Device Count` sowie die Tabelle `Affected Devices` (Device, Scanner, Site); das Profil bildet die Anzahl auf die Asset-Rolle ab, nutzt `Affected Devices` als Ergebnisabschnitt und vergleicht nur noch ueber die CVE. Der Finding Reader blendet das Rohfeld `Source Observations` fuer Defender aus, es bleibt als Provenienz im Datensatz. Nicht uebernommen: die Umbenennung der Asset-Zeile im Result-DB-Zeilendetail, weil die Disclosure-Policy `affectedAsset` fuer jede Zeile zurueckhaelt und eine Device-Anzahl dort nicht erscheinen soll. Die Finding-Identitaet aendert sich wie im Original ohne Profilversionssprung; die neu angelegte lokale Datenbank enthaelt keine Defender-Importe, der Versionssprung folgt mit `c7c716c`. Keine API-, SQL- oder Persistenzmigration. Verifikation: beide Typechecks, Gesamtlauf mit 1.883 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phasen 6/7/13A: `7d3ef5f` (Microsoft Defender for IoT, Grundlage) auf Michaels Basis uebernommen. Profil `defender-for-iot-vulnerabilities` 1.0.0 mit Manifestzeile, Source Extractor, Domain-Modell, Client-Info-Panel sowie Titel je Datensatzprofil (`recordTitleFor`) in Work und Pathfinder. Angepasst: Das Profil deklariert die auf dieser Basis verpflichtenden `securityScoring` (kein nativer Gesamtscore, mit Begruendung), `priorityBasis` (native CVE-Severity) und `timeslotComparison` (nicht verfuegbar). Client Info fuehrt Defender als dritten Tab neben Overview und AI Overview; ein reiner Defender-Timeslot startet in der Defender-Sicht. `recordTitleFor` ersetzt nur den Titelkandidaten, die Maester-/CIS-Titelregeln bleiben. `canonicalModelsToDataset` laesst zusaetzlich Modelle mit befuellten Quelltabellen zu, das leere All-Records-Blatt bleibt bestehen. Die Kompatibilitaetspruefung bevorzugt den gespeicherten `processedWith.profileId`; der sichtbare Importvertrag steigt auf 1.4.0. Die kopierten `.client-info-tabs`-Regeln sind aus `ai-overview.css` entfernt und liegen nur noch in `defender-for-iot.css`. Nicht uebernommen: `.gitignore`-Eintrag, `--tile-inset`, der bereits vorhandene `fileProfile`-Vorrang und die alte Versionspruefung. Neues Profil, daher kein Reimport bestehender Importe; keine API-, SQL- oder Persistenzmigration. Die Produktversion wird am Ende der Defender-Serie einmal neu bewertet. Verifikation: beide Typechecks, Gesamtlauf mit 1.883 bestandenen und 17 uebersprungenen Tests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. |
| 2026-10-02 | Phase 7/13F: Aus `95ec322` die AI-Overview- und ISO-Mapping-Korrekturen uebernommen. Schlaegt eine Regeneration fehl oder laeuft sie noch, liefert der AI-Overview-Service zusaetzlich `previousSuccessfulRun`; das Panel zeigt die letzte gespeicherte Uebersicht mit der Fehlermeldung weiter, `Stale` gilt nur fuer einen erfolgreichen, veralteten Lauf. Ein gespeichertes ISO-Mapping bleibt lesbar, wenn Qdrant oder der Embeddingdienst nicht erreichbar ist; die Generierung bleibt dann deaktiviert. Synthetische Service- und Paneltests. Die Defender-Geraete-Risikoakzeptanz desselben Commits folgt mit den Defender-Commits. |
| 2026-10-02 | Phase 7/13F: Aus `3f6259d` nur den Stale-State-Schutz uebernommen. `useAiOverview` und `useRegulatoryMapping` binden jede Antwort an ihren Anfrage-Scope (Client, Timeslot bzw. Result-DB-Zeile); eine verspaetete Antwort einer frueheren Auswahl wird verworfen. Zwei synthetische Interaktionstests. Die gemeinsame Result-Fenster-Farbpalette, die Entfernung des Pfadverlaufs in `MitreGraphView` und die Defender-Stile desselben Commits wurden auf Nutzerentscheidung nicht uebernommen. |
| 2026-10-02 | Phase 13F, ausdruecklicher Nutzerauftrag: ISO-Control-Mapping auf GPO-Baselinevergleiche erweitert. `policy-evaluation`-Zeilen werden wie Scannerfindings gemappt (Einzelmapping im Finding Reader und gefiltertes Result-DB-Batch); Query und Mapperkontext entstehen aus Titel, Guidance und Empfehlung nach der Result-DB-Disclosure-Projektion, der Kundenwert bleibt zurueckgehalten. Globaler Regelschluessel `GPOs:<technische Setting-ID>`, daher teilen alle Baselinepakete einer Einstellung ein Mapping. Work-GPO-Zeilen tragen dafuer `policyComparisonId` ihres aktuellen Vergleichs; historische Vergleiche bieten kein Mapping. Rohe GPO- und Environment-Observations bleiben ausgeschlossen (Batchanzeige `Excluded context rows`). Retrievalversion auf Nutzerentscheidung unveraendert; die fruehere Festlegung `nur Scanner-Findings` ist damit fuer GPO-Vergleiche aufgehoben. Der Commit `18c6180` (Hybrid-/Finding-only-Retrieval 1.2-1.6) wurde auf Nutzerentscheidung nicht uebernommen; es gilt weiter das einfache Dense-Retrieval. Synthetische Tests fuer Querygrenze, Einzel- und Batchmapping sowie die Work-Zeilenidentitaet; kein realer Mappinglauf gegen Qdrant/LiteLLM. |
| 2026-10-02 | Phase 7: Privacy-Safe-`Export JSON` um GPO-Vergleiche ergaenzt. Handlungsrelevante `policy-evaluation`-Findings tragen einen `policy`-Block (Status, Baseline-Familie, Sollwert, Vergleich, Kundenzustand, Scope, Delivery, Diagnosecodes) ausschliesslich aus der bestehenden Result-DB-Disclosure-Projektion; der Kundenwert bleibt zurueckgehalten. Rohe `policy-observation`-Zeilen zaehlen nicht mehr als Findings, sondern separat als `policyObservationResults`; `policyStatuses` zaehlt die GPO-Urteile. Synthetischer Test in `tests/exports/result-db-copy.test.ts`. |
| 2026-10-02 | Phase 7: AI-Integration auf den aktuellen Michael-Stand uebernommen (Branch `merge/michael-binh`). Der Privacy-Safe-`Export JSON` aus `result-db-copy` ergaenzt die Result DB als vierte Exportaktion; `Export JSONL`, `Export Excel` und `Export CSV` bleiben unveraendert. Die Einzelaktions-Festlegung vom 2026-09-14 gilt auf diesem Stand deshalb nicht als Ersatz des JSONL-Exports. Die Beispieldateien `test.json`, `test-output.json` und `artifacts/test-output-*` wurden nicht uebernommen. |
| 2026-09-26 | Phase 7: MITRE-Onlineaktualisierung aus offizieller Enterprise-STIX-Quelle, separater Download der originalen MITRE-Datei und weiterhin manueller JSON-Import. Gemeinsam gespeicherter privater Katalog, sofortige Graphaktualisierung, Same-Origin-API; keine Assessment-/DB-Migration. Minorversion 2.7.0; synthetische Service-/HTTP-/UI-Tests, Live-Update und Originaldownload, Design-/Local-only-Pruefung sowie beide Builds verifiziert. Sechs vorbestehende fachfremde Tests bleiben offen. |
| 2026-09-26 | Phase 7: MITRE-Standardkatalog v19.2 aus offiziellem STIX, sichtbarer STIX-/JSON-Upload im Data Hub und sofortige Pathfinder-Aktualisierung bei Upload/Reset. Reproduzierbare Quelle und Browser-Override-Grenze in `docs/MITRE_CATALOG.md`; Patchversion 2.6.47. 21 fokussierte Tests, Data-Hub-Layouttest, Design-/Local-only-Pruefung und beide Builds bestanden; Gesamtsuite mit sechs fachfremden bestehenden Fehlern. |
| 2026-09-25 | Phase 7: Pathfinder-Detailswerte erhalten eine breite flexible Spalte ohne erzwungene Wort- und Ziffernumbrueche; lange technische IDs bleiben innerhalb ihres Bereichs scrollbar. 14 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.46 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: Redundanten DB-Structure-Einfuehrungsblock und den Erklaersatz unter `Data flow` entfernt. Schemaaktion, Kennzahlen, Ablauf und Popups bleiben erhalten. 17 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.45 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: DB-Structure-Datenflussbuttons oeffnen die ausgewaehlte Tabelle wieder im gemeinsamen Popup statt inline. Referenzierende Tabellen sind im Fenster navigierbar; Escape schliesst es. 16 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.44 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: `Extract Path` isoliert den ausgewaehlten Knoten samt direkten Nachbarn und Kanten; Filter und `Mark all` loesen keine breite Extraktion mehr aus. Rueckkehr stellt die vorherige Ansicht wieder her. 22 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.43 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: Der rechte Pathfinder-Detailbereich zeigt das gemeinsame Severity-Sechseck und vorhandene Quellangaben zu Finding-Knoten; Relation-Knoten bleiben ohne Finding-Symbole. 18 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.42 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: Pathfinder zeigt Knotentext standardmaessig; nur `Text` schaltet ihn, Knotenklick aendert ihn nicht. `Off`, `Labels` und Graphkarten entfernt; Informationen und Aktionen stehen im rechten `Details`-Bereich. 18 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.41 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: Explizit eingeleitete PowerShell-Befehle im Finding-Reader-`Next step` stehen lesbar unter dem Erklaersatz statt im Fliesstext. Vollstaendige Quellzeichenfolge und `Full remediation` bleiben erhalten. 21 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Patchversion 2.6.40 am kanonischen PostgreSQL bereitgestellt. |
| 2026-09-25 | Phase 7: Die Tabellenzeilen-Lesemarkierung nutzt auf ausdruecklichen Nutzerwunsch einen eigenen Blauton in beiden Themes; gelbe Auswahl ausserhalb der Tabellen bleibt erhalten. 16 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden; Backend mit kanonischem PostgreSQL auf Patchversion 2.6.39 aktualisiert. |
| 2026-09-25 | Phase 7: Work setzt beim Wechsel von `Source: Scan` die bisherigen Such-, Status-, Facetten-, Pfad- und Workspace-Filter sowie die Sortierung auf den Standard zurueck und behaelt die neue Quelle. Synthetischer echter Quellenwechsel GPOs/Maester/All regressionsgeprueft; Patchversion 2.6.38, keine Datenmutation. |
| 2026-09-25 | Phase 7: Alle interaktiven Datentabellen markieren angeklickte Zeilen ueber die volle horizontale Breite; Result DB und Floating Results eingeschlossen, Work-Grid-Auswahl bleibt bei vertikaler Virtualisierung erhalten. Bestehende Zeilenaktionen und Evidenzfarben bleiben erhalten. 42 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds bestanden. Patchversion 2.6.37; keine Datenmutation. |
| 2026-09-25 | Phase 7: Client-Info-Kacheln ausser Overall Score auf Data-Schriftrollen (16-px-Titel/Werte, 14-px-Informationslabels) vereinheitlicht; jedes Faktum erhaelt eine flache, fein getrennte Zelle. 44 fokussierte Tests, Design-/Local-only-Pruefung, beide Builds sowie Dummy Light/Dark und schmale Ansicht erfolgreich. Patchversion 2.6.23; Backend am kanonischen PostgreSQL neu gestartet. |
| 2026-09-25 | Phase 7: Sieben Umgebungskacheln auf 372 px verdoppelt und erste Hardfacts als zweispaltige Kachelansicht; Inventory mit allen acht Fakten. Vollstaendige Listen und Quellbelege bleiben in Results. 33 fokussierte Tests, Design-/Local-only-Pruefung, beide Builds und Dummy Light/Dark erfolgreich. Patchversion 2.6.21; Backend am kanonischen PostgreSQL neu gestartet. |
| 2026-09-25 | Phase 7: Source-Overview-Kachel entfernt, sieben 186-px-Umgebungskacheln behalten. Quellenbelege, Drilldowns und Bewertungsmethode ueber Overall Score Results; Directory-Kurzvorschau ohne getrennten Domainnamen. 44 fokussierte Tests, Design-/Local-only-Pruefung, beide Builds und Dummy Light/Dark erfolgreich. Patchversion 2.6.20; Backend am kanonischen PostgreSQL neu gestartet. |
| 2026-09-25 | Phase 7: Environment Detail als Disclosure entfernt, acht kompakte quadratische Kacheln dauerhaft sichtbar; vollstaendige Details und Quellbelege in Results. 32 fokussierte Tests, Design-/Local-only-Pruefung, beide Builds und Dummy Light/Dark geprueft. Patchversion 2.6.19; Backend am kanonischen PostgreSQL neu gestartet. |
| 2026-09-25 | Phase 7: Domain Information in fachlich zusammenhaengende Paare sortiert und Client-Info-Deviations-Ring von 128 auf 184 px vergroessert, bei gleicher 487-px-Kachelhoehe. Light/Dark, 34 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds erfolgreich. Patchversion 2.6.18. |
| 2026-09-25 | Phase 7: Schrift, Mengenbalken und Anzahl jeder Security Domain an der Kreismitte ausgerichtet; gemessenen 10-px-Versatz beseitigt. Acht Zeilen in Light/Dark geprueft, 31 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds erfolgreich. Patchversion 2.6.17. |
| 2026-09-25 | Phase 7: Separate Assessment-Gaps-Kachel entfernt; Gaps bleibt in Data anklickbar. Posture, Data und Domain Information am Dummy auf gleiche 487-px-Hoehe gebracht; alle acht Domains und Score vollstaendig sichtbar. Light/Dark, 39 fokussierte Tests, Design-/Local-only-Pruefung und beide Builds erfolgreich. Patchversion 2.6.16; Backend am kanonischen PostgreSQL neu gestartet. |
| 2026-09-25 | Phase 7: Donut-Erstaufruf am Dummy von etwa 13,0 auf 3,4 Sekunden gesenkt; nur aktuelle GPO-Auswertungen und ein schlankes Projektblatt geladen, Werte unveraendert. Donut-Design aus 2.6.12 auf Nutzerwunsch zurueckgenommen, Ladezustand erhalten. Light/Dark und Mandantenklick geprueft. Patchversion 2.6.15, keine Datenmutation. |
| 2026-09-24 | Phase 7: Gaps als fuenfte klickbare Kennzahl in Data ergaenzt. Der Klick selektiert genau die 1.071 im Dummy gezaehlten nicht bewerteten Records in Work, statt nur einen Teilstatus zu filtern. Light/Dark, 34 fokussierte Tests, Design-/Sicherheitspruefung und beide Builds bestanden. Patchversion 2.6.11 ohne Datenmutation. |
| 2026-09-24 | Phase 7: Data-Donut innerhalb seiner Kachel vergroessert, Domain Information mit voller Domain-Zeile und quellengebundenem DC OS versehen. Dummy zeigt Windows 2019; Light und Dark geprueft. 35 fokussierte Tests, Design-/Sicherheitspruefung und Client-/Server-Build erfolgreich. Patchversion 2.6.10 ohne Datenmutation. |
| 2026-09-24 | Phase 7/13A: PingCastle-Grundtabellen, Zell-Modalverweise und ausserhalb liegende Collapse-Verweise anhand des bereitgestellten HTML getrennt erfasst und dargestellt. Native Ziel-IDs und Titel bleiben erhalten. Bytegleicher Dummy-Scan nach verifiziertem Backup sicher reimportiert; Live-Klickpfad, 27 fokussierte Tests, Sicherheits-/Designpruefung und beide Builds erfolgreich. Gesamtsuite: 1.472 bestanden, dieselben fuenf bekannten fachfremden Fehler. Patchversion 2.6.9; andere bestehende Berichte brauchen fuer die neuen Verweise einen sicheren Reimport. |
| 2026-09-24 | Phase 7: Nutzer setzt die Header-Position des Sidebar-Pfeils aus 2.6.5/2.6.7 zurueck. Einklappen wieder unten neben Theme-Schaltern, Ausklappen wieder am linken Rand; weiterhin ohne einzelnen Rahmen. Data Hub Light/Dark und beide Richtungen geprueft, 12 fokussierte Tests, Designcheck und beide Builds erfolgreich. Patchversion 2.6.8 ohne Datenmutation. |
| 2026-09-24 | Phase 7: Sidebar-Pfeil im Header ohne sichtbaren Rahmen und Buttonflaeche dargestellt; Fokusmarkierung und beide Klapprichtungen erhalten. Data Hub Light/Dark im Dummy geprueft, 12 fokussierte Tests, Designcheck und beide Builds erfolgreich. Patchversion 2.6.7 ohne Datenmutation. |
| 2026-09-24 | Phase 7: Purple-Knight-Ergebnisverweis aus `Result` nicht mehr als Outcome in Work-Liste und Finding-Kopf dargestellt; vorhandenes `IOE Found` erscheint dort, Originalverweis bleibt fuer Results erhalten. Dummy SI000055 verifiziert, 41 fokussierte Tests, Designcheck und beide Builds erfolgreich. Patchversion 2.6.6 ohne Datenmutation. |
| 2026-09-24 | Phase 7: Globalen Sidebar-Umschalter in den Header verschoben, in Work direkt vor Shown; derselbe Pfeil klappt dort ein und aus. Alte Theme- und Randposition entfernt. Dummy Light/Dark und beide Klickrichtungen geprueft; 12 fokussierte Tests, Designcheck und beide Builds erfolgreich. Patchversion 2.6.5, keine Datenmutation. |
| 2026-09-24 | Phase 7: Originaltabellen im Environment-Results-Fenster als einzeln geoeffnete, ASSESSOR-gestaltete Tabellenfenster mit Quellkontext, Suche, horizontalem Scrollen, Seitensteuerung und exakt zugeordneten Beobachtungen umgesetzt. Gleichnamige Quelltabellen erhalten eine eindeutige Position statt erfundener Gruppennamen. Dummy Light/Dark und Escape-Verhalten geprueft; 24 fokussierte Tests, Local-only-/Designcheck und beide Builds erfolgreich. Patchversion 2.6.4, keine Datenmutation. |
| 2026-09-24 | Phase 7: Work-Sidebar-Domaenenliste von kleinen Kacheln auf die bestehende Navigationssprache umgestellt. Transparente Zeilen, 14px-Namen und Zaehler, geteilte gelbe Auswahlmarkierung, keine Flaechenstreckung; Filtersemantik unveraendert. Light/Dark im Dummy sowie Wechsel 58/120/58 Treffer geprueft. 26 fokussierte Tests, Designcheck und beide Produktionsbuilds erfolgreich; Patchversion 2.6.3. |
| 2026-09-24 | Phase 7: 13 konkrete Windows-CIS-CAT-Abweichungen des freigegebenen Dummy aus `Unclassified` nach `System Hardening` korrigiert. Gemeinsame Domainregel fuer Work und Client Info erweitert, synthetischer Work-Filter-Gegenfall und der Umschalt-Klickpfad dauerhaft abgesichert. Live in Work: `Unclassified · 0` unter `Deviation`, 58 CIS-CAT-Abweichungen unter `System Hardening`. 42 fokussierte Tests, Local-only-/Designcheck und beide Produktionsbuilds erfolgreich; UI und Backend melden Patchversion 2.6.2. Keine Quelldaten- oder Persistenzmutation; unbekannte Themen bleiben bewusst unklassifiziert. |
| 2026-09-16 | Phase 7/13B: Registry.pol-Zustandsregeln persistent verankert und mit Evaluator 1.9.0 umgesetzt. Delete-value/Delete-all/Create-key und typisierte Leerwerte sind vergleichbar; Schluesselziele beziehen konfigurierte Kindwerte samt Evidenzreferenzen ein. Gewoehnliche fehlende Empfehlungen bleiben Not configured, waehrend fehlende ausdruecklich verlangte Schluessel- oder Leerwertpraesenz Fail ist. Historie bis 1.8.0 bleibt unveraendert und wird nur ausdruecklich neu ausgewertet. 32 fokussierte Tests und exakte Work-Statusregressionen, 1.280 bestandene Gesamttests, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Kein Reimport, Processing-Manifest- oder SQL-Schemawechsel; keine reale Bestandsneuauswertung. |
| 2026-09-15 | Phase 7: Work verwendet beim normalen Einstieg und bei neu initialisierten Projekt-, Timeslot-, Blatt-, Import- und Reset-Zustaenden immer `Deviation`. Die bisherige automatische GPO-Ausnahme `All` ist durch die ausdrueckliche Nutzerentscheidung ersetzt. Bereits gesetzte Filter aus Client Info, Pathfinder und anderen Drilldowns bleiben beim Wechsel nach Work erhalten; explizit gesetztes `All` bleibt damit ebenfalls moeglich. Permanente synthetische Navigations- und GPO-Regressionen, 1.270 bestandene Gesamttests, acht optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Keine Daten-, Verarbeitungs- oder Reimportaenderung. |
| 2026-09-15 | Phase 7/13B: Irrefuehrende manuelle Aufforderung am partiellen GPO-Import entfernt. Der gelbe technische Zustand lautet wieder `Limited analysis`; er ist keine Aufgabe, kein automatisches Manage-Signal und keine Aufforderung zur Einzelvalidierung. Damit wird die bindende Produktentscheidung vom 2026-09-06 wiederhergestellt und die zwischenzeitliche Formulierung `Partial · review required` ausdruecklich ersetzt. Synthetischer Rendergegenfall, 17 fokussierte Tests, 1.268 bestandene Gesamttests, Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich; acht optionale PostgreSQL-Tests uebersprungen. Keine Daten- oder Verarbeitungssemantikaenderung. |
| 2026-09-15 | Phase 7/13B: GPO Analysis verwendet fuer seine Baseline-Ergebniszaehler jetzt dieselben backendautoritativen aktuellen Aggregationslaeufe wie Work und Client Info. Historische Aggregationen bleiben in der Evaluationshistorie, werden aber nicht mehr zu aktuellen Pass-/Fail-/Not-configured-Zaehlern addiert. Review required ist in der Zusammenfassung sichtbar. Exakte synthetische Mehrlauf-/Ein-Timeslot-Komponentenregression, 26 fokussierte Tests, 1.267 bestandene Gesamttests plus isoliert bestandener bekannter Last-Timeout und beide Produktionsbuilds erfolgreich; acht optionale PostgreSQL-Tests uebersprungen. Keine Datenmutation, Neuauswertung, Import-, Persistenz-, Schema-, Manifest- oder Reimportaenderung. |
| 2026-09-15 | Phase 13/9-11: Timeslot-Importlast korrigiert. Inaktive GPO-Importsteuerelemente in Timeslotzeilen erzeugen keine eigenen Poller mehr; sichtbare Statusansichten und der Data Hub fragen nur waehrend queued/running ab, bewahren unveraenderte Zustandsobjekte und berechnen Result-Facetten nur bei einer echten Statusrevision neu. Datei- und Definitionszuordnung im PostgreSQL-Commit ist je Import vorindiziert. Gemessener Ausgangszustand: 4,4 s Vorschau, 200,3 s Commit unter 270 Facetten- und 326 Statusabfragen in fuenf Minuten. Synthetische Interaktionsregression, 30 fokussierte Tests, 1.266 bestandene Gesamttests plus isoliert bestandener bekannter Last-Timeout, Local-only-/Designpruefung und beide Builds erfolgreich; acht optionale PostgreSQL-Integrationstests uebersprungen. Keine Schema-, Daten-, Importsemantik-, Manifest- oder Reimportaenderung. Restrisiko serieller PostgreSQL-Einzelwrites dokumentiert. |
| 2026-09-14 | Phase 7/13B: Regression im Work-Filterkontext korrigiert. `Source: Scan = GPOs` reduziert auf dem All-Records-Blatt nun vor Priorisierung und Facettenlimit auf den GPO-Vertrag; das Statusmenue wird unabhaengig von einem separaten GPO-Blatt mit All, Deviation, Passed, Not configured, Conflicts und Duplicates vollstaendig erzeugt, fachliche Nullwerte bleiben waehlbar. GPO-Statuswerte werden ausschliesslich gegen das aktuelle Statusfeld geprueft; ein Pass-Vergleichswert kann einen Not-configured-Datensatz nicht mehr als Passed filtern. Fremde Scannerfacetten und ungueltige gesetzte Altfilter werden entfernt, `Source: Scan` bleibt vollstaendig und rechts; ohne Quellrestriktion kehrt der Mischkontext zurueck. Exakte synthetische Interaktionsregressionen pruefen Anzeige, tatsaechliche Filterwirkung und den gemeldeten Gegenfall; 51 fokussierte Tests sowie der Gesamtlauf mit 1.243 bestandenen und acht uebersprungenen Tests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. `AGENTS.md` bindet dokumentierte Nutzerentscheidungen als Abnahmekriterien und verlangt transparente Meldung vor regelwidrigen Aenderungen. Keine Daten-, Import-, API-, Persistenz-, Score- oder Reimportaenderung; ausschliesslich synthetische Inhaltspruefung. |
| 2026-09-16 | Phase 13F, ausdruecklicher Nutzerauftrag: Gefiltertes Result-DB-ISO-Batchmapping umgesetzt. Der gemeinsame Scope-Builder garantiert dieselbe vollstaendige Filter-/Timeslot-Abfrage wie Export JSON und entfernt Pagination sowie nicht autoritative Client-Scopewerte. Projektgebundene GET-/POST-APIs, Migration 027, Local-/PostgreSQL-Paritaet, Export und Loeschung speichern den normalisierten Scope, kanonischen Filterhash, Idempotenz, Lifecycle und Fortschritt; globale Regelmappings bleiben autoritativ. Stabile serverseitige Mehrseitenabfrage mit Total-Drift-Abbruch, deterministische `ruleKey`-Repraesentanten, erfolgreiche/aktive Wiederverwendung, einmaliger Failed-Retry, atomare Mappingclaims und eine gemeinsame Zwei-Pipeline-Queue sind implementiert. Result DB zeigt `Map all ISO controls`, Trefferzahl, Status und Zaehler, verhindert veraltete Filterantworten und behaelt Accept/Reject manuell in Work. Synthetische Regressionen decken alle Filterfamilien, Standardabweichungsfilter, Scopebereinigung, Mehrseitenlauf, Total-Drift, Ausschluesse, globale Deduplikation, Partial Failure, Retry/Reuse, Single-/Batch-Nebenlaeufigkeit und UI ab. `npm test`: 1.315 bestanden, zehn opt-in Integrationen uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Kein Manifestbump oder Reimport. Nach der Anwendung von 027 wurde dieselbe Datei faelschlich um eine reine Sortiersequenz erweitert; der Checksum-Schutz stoppte den Backendstart. Die Datei ist exakt auf den angewandten SHA-256-Stand `d89055c3e723b09d8d8be7f4225bfd08442f0d66e4e0b4ea3aa62ae6209e9ee9` zurueckgesetzt und mit einer Regression gesperrt, die Abfragen verwenden wieder den vorhandenen `created_at, id`-Index. Keine Migration 028 und keine weitere Datenbankmutation. Fuenf fokussierte Suites mit 16 Tests, Servertyppruefung und Serverbuild erfolgreich. Nach freigegebenem WSL-Neustart: kanonischer PostgreSQL-Container gesund, Port/Volume korrekt, Ledger 027 checksum-identisch, 028 nicht vorhanden und Backend-Health HTTP 200 mit PostgreSQL-Persistenz. |
| 2026-09-14 | Phasen 7/13C und 11: Work-LiteLLM-gestuetztes AI Overview umgesetzt. Der Backend-Service liest den kompletten Timeslot ueber das bestehende Privacy-Safe-Result-DB-JSON, hasht ihn deterministisch, zerlegt grosse Payloads nur zwischen vollstaendigen Eintraegen und konsolidiert sie mit maximal 64 explizit nicht wiederholten LiteLLM-Aufrufen. Der HTTPS-Client haelt URL, Modell und Bearer-Key ausschliesslich in Server-Secrets, lehnt lokale/unsichere Ziele und Redirects ab und begrenzt Zeit sowie Antwortbytes. Ausgabevalidierung prueft das vollstaendige Dashboard-Schema, Laengen, Roadmap 0-4, exakte Finding-/Gap-IDs und Environment-Properties. Same-Origin-GET/POST, Migration 024, lokale/PostgreSQL-Repositoryparitaet, Projekt-Export/-Loeschung, Idempotenz und ein aktiver Run je Scope sind ergaenzt. Client Info rendert alle Analyseabschnitte mit Generate/Regenerate, Polling nur bei aktiven Runs sowie stale/failed/disabled Zustaenden. Sicherheits- und Deploymentdokumentation beschreibt den genehmigten Corporate-Gateway-Vertrag. 1.262 synthetische Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und beide Produktionsbuilds erfolgreich. Der inhaltsfreie Workstation-Livecheck erreichte Work-LiteLLM, erhielt aber HTTP 401; Providerbody und Secrets wurden nicht ausgegeben. Docker/kanonisches Backup, Migrationanwendung, PostgreSQL-Integration sowie erfolgreicher Workstation-/Server-Livecheck bleiben offen; keine Realdateninspektion oder Reimportaenderung. |
| 2026-09-14 | Rebase der AI-Integration auf defender-iot: Die einzelne AI-Commit-Aenderung wurde neu aufgesetzt und die kollidierende Result-DB-LLM-Uebergabe zusammengefuehrt. Das versionierte, datensparsame Privacy-Safe-JSON-Schema dieses Branches ist nun das Result-DB-Exportformat und wird als einzelne Aktion `Export JSON` ueber den gemeinsamen Browser-Download-Adapter als `.json`-Datei geladen; damit ersetzt es sowohl den zuvor auf defender-iot vorhandenen `Export JSONL`-Download als auch die fluechtige `Copy JSON`-Zwischenablageaktion. Der Builder wurde zu `resultsToPrivacySafeExportJson` mit begleitendem Dateinamens-Helfer `privacySafeResultJsonFileName` umbenannt; Entscheidungs-, Risiko- und Testeintraege wurden entsprechend angeglichen. Alle uebrigen defender-iot-Inhalte (CVE-Enrichment, GPO-/Policy-Ergebnisse, Timeslot-Scope) bleiben unveraendert. 1248 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. |
| 2026-09-08 | Phase 7: Verbindungskurven der Client Info treffen ihre Domainknoten wieder. Feste Zielkoordinaten in einem verzerrten SVG-Koordinatensystem durch eine aus dem Layout gemessene Geometrie ersetzt, Neumessung ueber Groessenbeobachter und Fensterereignis. Am Dummy bei drei Breiten geprueft: Abweichung 0 Pixel statt bis zu 80. Keine Aenderung an Werten oder Kachelgeometrie. 1.011 Tests, Local-only-/Designpruefung und Builds erfolgreich. |
| 2026-09-08 | Phase 7: Aufbauzeit der Client Info von ueber vier Sekunden auf unter 100 Millisekunden gebracht. Ableitung je Datensatz einmal statt je Rendern, ein Durchlauf statt vierzehn Punkteberechnungen, Domainzuordnung mit einmaligem Klassifikationstext, schwache Verweise je Datensatz sowie ansichtsuebergreifender Zwischenspeicher fuer Facetten und Auswertung; Herkunftswerte je Datensatzliste einmal gezaehlt. Gemessen am freigegebenen Dummy mit 8.257 Datensaetzen: Ableitung 3.123 ms -> 0 ms, laengste blockierende Aufgabe > 4.000 ms -> < 100 ms. Keine Aenderung an Werten, Zaehlungen, Darstellung oder der geteilten Statuslogik. 1.007 Tests, Local-only-/Designpruefung und Builds erfolgreich. |
| 2026-09-08 | Phase 7/13C: Dummy-Reimport abgeschlossen. Purple-Knight-Scan nach Backendneustart ueber den Importdialog ersetzt; alle aktiven Scans tragen den aktuellen Verarbeitungsstand (Purple Knight 1.2.0, CIS-CAT 1.4.0, PingCastle 1.4.0, Maester 1.0.0), Datahub meldet durchgehend `Ready`. Befunde und Umgebungskontext unveraendert; keine Code-, Schema- oder Persistenzaenderung. |
| 2026-09-08 | Phase 7/13C: Freigegebenen Dummy ueber den regulaeren Reimportweg mit identischen Originaldateien neu importiert (verifiziertes Backup vorab, SHA-256-Gleichheit aller 26 Dateien, Befundzahlen unveraendert, abgeloeste Laeufe als Historie erhalten). CIS-CAT-Kontext auf die tatsaechliche Berichtstitelseite umgestellt: Host, Zielnetzadresse, Benchmark mit Version, Profil, Zeitpunkt, Dauer und Assessor-Version; lesbarer Benchmarkname auch aus einer XCCDF-Ergebniskennung. Purple-Knight-Profil 1.2.0 und CIS-CAT-Profil 1.4.0 als kontextbezogene, kompatible Verarbeitungsstaende registriert. Client Info zeigt fuer den Dummy 49 Faktenzeilen ohne unbekannte Werte. 1.004 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Offen: Backendneustart und ein erneuter Purple-Knight-Reimport, damit die bestaetigungspflichtige Indicators-Datei die aktuelle Profilversion traegt. |
| 2026-09-08 | Phase 7/13C: Purple-Knight-Zusammenfassung und CIS-CAT-Kopfangaben als Umgebungskontext erschlossen. Neuer kontextreiner Purple-Knight-Extractor (Posture Score, sechs Kategoriewerte, Auswertungsbilanz, Edition, Forest, Domainzahl) ohne Findingkandidaten, zwei neue Inhaltssignale fuer die Quellenerkennung; CIS-CAT-Extractor 1.3.0 mit beschrifteten Systemangaben, Benchmarkidentitaet, Gesamtscore, deklarierten Ergebniszahlen und Abschnittsscores. Client Info erhaelt die Zone `Environment Detail`, Domainknoten mit vergleichbarem ASSESSOR-Score, Quellkacheln mit Score zuerst und beschrifteter Toolzahl daneben sowie die GPO-Anzahl aus der Sicherungsverarbeitung. Unbekanntes bleibt `—`, lizenzbeschraenkte Abschnitte bleiben ausdruecklich Restricted. 1.003 Tests bestanden, acht optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Schema-, Migrations- oder Persistenzaenderung; neue Beobachtungen entstehen erst bei erneutem Import. Ausschliesslich synthetische Inhaltspruefung. |
| 2026-09-08 | Phase 13B: Security-Template-Parser 1.1.0 ueberspringt unbekannte/metadatenhaltige Abschnitte vor der Key/Value-Grammatikpruefung und erhaelt gueltige Instruktionen bei isolierten defekten Eintraegen mit Status partial. Struktur- und Ressourcengrenzen bleiben blockierend. Baseline-Analyzer 1.2.0, GPO-Processing/Analyzer 2.2.3 und analysegebundene ADMX-Katalog-IDs ermoeglichen versionierte Neuanalyse mit erhaltener Historie. Synthetische Regressionen pruefen Service-Zeilen, Einzelfehler, leere Rechtezuweisungen, Quellzeilen, Strukturgrenzen, gemeinsame Kunden-/Baseline-Pipeline, Legacy-Reprocessing, Idempotenz und Katalogreferenzen. 990 Tests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich; acht optionale PostgreSQL-Tests uebersprungen. Backup verifiziert; elf Baselinepakete neu analysiert, alte Analysen erhalten, Privilege Rights 146 -> 400. Dummy-Evaluation fuer konfigurierte Kundenwerte: 113 Matches, 98 Abweichungen, 15 Baseline-Consensus-Reviews; 28 neue Rechteabweichungen, 13 bisherige Abweichungen -> Review, zwei alte Reviews unveraendert. Die bestehende automatische projektuebergreifende Job-Reparatur erzeugte beim ersten Neustart unbeabsichtigt einen zusaetzlichen Evaluationslauf ausserhalb von Dummy; im Risikoabschnitt dokumentiert, Originale/Historie erhalten, danach keine weitere fremde Evaluation. HTTP-Health direkt und via Client erfolgreich. Keine SQL-Migration, Phase bleibt in Arbeit. |
| 2026-09-07 | Phase 7/13B: GPO-Konsistenzklassifikation in der Result DB ergaenzt. Baselinevergleiche tragen Misconfigured, Not configured, Match, Conflict oder Review required; identische beziehungsweise abweichende Mehrquellenbelegungen werden ueber dieselbe aktuelle Policy-Beobachtungsgruppierung wie Work als eigene Duplicate-/Conflict-Leseprojektionen bereitgestellt. Neue Facette, Queryparameter und Detailanzeige gelten identisch fuer Local und PostgreSQL. Conflict/Duplicate bleiben Outcome warning und ausdruecklich `Deviation: No`; die Facette bleibt trotz Standard-Deviationfilter sichtbar und hebt diesen bei Klassenauswahl auf. Keine Persistenz-/Schemaaenderung, Migration, Neubewertung oder Originaldatenmutation. 976 Tests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Inhaltspruefung. |
| 2026-09-07 | Phase 7: `Source: Scan` von einer blattlokalen Facette zur workspaceweiten Scannavigation erweitert. Die vollstaendige Liste stammt aus dem projektweiten All-Records-Blatt und bleibt auch in GPO sowie unter anderen aktiven Filtern vollstaendig. Eine konkrete Auswahl aus einem dedizierten Fachblatt navigiert auf das Aggregat und setzt dort atomar den stabilen Provenienzfilter; die Quellspaltenposition ist fuer die Filter-ID und Wertauflosung nicht mehr relevant. 33 fokussierte synthetische Filter-/GPO-Regressionen gruen; 971 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Bestehender Bundle-Groessenhinweis; keine Daten-, API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-07 | Phase 7: Filterleiste der reinen GPO-Ansicht auf die geforderte stabile Ordnung gebracht. Die fachlichen Controls ruecken ohne kuenstlichen Flex-Zwischenraum nach links; `Source: Scan` bleibt als letzter Filter in jeder Ansicht ganz rechts. Einwertige Source-Scan-Facetten werden nicht mehr verworfen, fehlende explizite Felder erhalten einen praesentativen Provenienzfallback, und das GPO-Limit wurde auf elf sichtbare Facetten angehoben, damit kein Fachfilter verdraengt wird. 32 fokussierte synthetische Filter-/GPO-Regressionen gruen; 970 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Bestehender Bundle-Groessenhinweis; keine Daten-, API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-07 | Phase 7/13B: Kundenanzeige aller GPO-Sources auf GPO-interne Referenzen minimiert. Ein zentraler Presenter entfernt Laufwerks-, lokale Ordner-, Backup- und Artefaktpraefixe und gibt nur `{GUID}/DomainSysvol/GPO/...` beziehungsweise den sicher erkannten internen Strukturteil aus; unbekannte Formen liefern fail-closed keinen Originalpfad. Normale Sources und Conflict-/Duplicate-Evidence verwenden denselben Vertrag. Evidence zeigt jede Referenz sofort in der technischen Pfadschrift, ohne `Show source`, fette Wiederholungsueberschrift oder Klickpflicht. Originaldaten/Persistenz unveraendert; technische Backup-/Record-IDs bleiben eingeklappt. 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-Groessenhinweis; ausschliesslich synthetische Daten, keine API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-07 | Phase 7/13B: GPO-Duplicate-Results an die neue Conflict-Lesepipeline angeglichen. `Duplicate detected` erklaert identische Mehrquellenbelegung und grenzt sie von einer Baselineabweichung ab; danach folgen `Setting details`, eine gemeinsame `Observed value`-Tabelle mit Value, Type und Evidence sowie `Technical source details`. Quellen bleiben direkt in der Evidence-Zelle aufklappbar, vollstaendige Pfade/IDs und exakte Leer-/Whitespacewerte erhalten. Shared Renderer/Envelopeprojektion unterstuetzt nun Conflict und Duplicate, sicherer Tabellenfallback 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-Groessenhinweis; ausschliesslich synthetische Daten, keine Daten-, API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-07 | Phase 7/13B, unmittelbare Nutzerkorrektur der GPO-Conflict-Results: Lesereihenfolge auf `Conflict detected` -> `Setting details` -> `Observed variants` -> `Technical source details` festgelegt. Die zuvor eingefuehrten Variantenkarten durch eine gemeinsame responsive Tabelle mit Variant, Value, Type und Evidence ersetzt; Quellen bleiben in der jeweiligen Tabellenzeile aufklappbar. Vollstaendige Umbrueche ohne Clipping/Truncation, lokale horizontale Tabellenrollflaeche bei schmalen Fenstern und technische IDs als letzte eingeklappte Stufe. Neutralitaet, exakte Leer-/Whitespacewerte, Envelopevalidierung und Tabellenfallback unveraendert. Elf Konfliktregressionen und 34 fokussierte Resulttests gruen; 965 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Bestehender Bundle-Groessenhinweis; ausschliesslich synthetische Daten, keine Daten-, API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-07 | Phase 7/13B: GPO-Conflict-Results von zwei generischen Tabellen auf eine erklaerende Vergleichsansicht umgestellt. Kurzer Settingtitel, Scope und neutraler Konflikthinweis stehen vor responsiven, nicht gestreckten Variantenkarten mit exaktem Wert, lesbarem Registrytyp, Quellenanzahl und direkt zugeordneten aufklappbaren Quellen. Leere Strings und reine Whitespacewerte sind sichtbar bezeichnet; Registrykontext steht einmal separat, vollstaendige Source paths sowie interne Backup-/Record-IDs bleiben unter `Technical source details` erhalten. Keine Gewinner-/Praezedenzbehauptung, keine Rot-/Gruenwertung. Die strukturierte Sicht wird erst nach vollstaendiger Envelopevalidierung aktiviert; sicherer Tabellenfallback und Duplicate-Results 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-Groessenhinweis; ausschliesslich synthetische Daten, keine Daten-, API-, Persistenz- oder Schemaaenderung und keine Realdateninspektion. |
| 2026-09-06 | Phase 7: GPO-Work-Kacheln gegen ueberlappende lange Registry- und Policy-Pfade abgesichert. `group-policy`-Kacheln tragen eine explizite Toolkennung und erlauben im Titel sichere Umbrueche innerhalb ungeteilter Pfadsegmente; Titel bleiben in ihrer mittleren Gridspalte und ueberdecken weder Bookmark noch Nachbarkachel. Andere Findingtitel behalten die bestehende wortbasierte Typografie. 42 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 7/13B: GPO-only-Timeslotfreigabe auf alle Clientansichten vereinheitlicht. Die zentrale Scope-Regel akzeptiert mindestens eine Scanner-Run-ID oder Assessment-ID; Client Info, Work, Result DB und Pathfinder behandeln damit reine GPO-Timeslots als ausgewaehlt, waehrend Datahub und DB Structure scannertypunabhaengig bleiben. Result-DB-Laden und -Export verwenden denselben projekt- und assessmentgebundenen Scope. Kein automatisches Beimischen anderer Timeslots oder Scannerlaeufe. 25 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 7: Englisch als verbindliche Sprache fuer saemtliche nutzerseitig sichtbaren ASSESSOR-Texte festgelegt, einschliesslich Navigation, Labels, Aktionen, Status-, Lade-, Leer-, Fehler-, Bestaetigungs- und Dialogtexte sowie kuenftiger Funktionen. Deutsche Texte bleiben auf interne Dokumentation, Kommentare oder ausdruecklich angeforderte Exportinhalte begrenzt. Den verbliebenen deutschen Ladehinweis der Data-Hub-Historie auf `Loading clients …` umgestellt. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 7: Gemeinsamen markenfreien Panel-Ladezustand eingefuehrt. Der konkrete Ladetext wird mit der aus den Processing-Pop-ups wiederverwendeten quadratischen Ladeanimation direkt daneben im verfuegbaren Inhaltsbereich zentriert. Client Info, DB Structure, Result DB, Data-Hub-Historie, Timeslot-Liste und Policy Analysis verwenden denselben Vertrag, eingebettete Bereiche in einer kompakten Variante. Fehler-, Leer- und Operationszustaende bleiben getrennt. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 7/13B: Erfolgreich fertig verarbeitete GPO-Backups werden in der Timeslot-Quellenzeile als `Ready` statt `Imported` bezeichnet. Die Aenderung betrifft ausschliesslich das Label des Endzustands `succeeded`; Queue-, Verarbeitungs-, Teil-, Fehler- und Recovery-Zustaende bleiben getrennt. Zehn fokussierte synthetische Tests und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 7: ASSESSOR-Branding auf eine gemeinsame transparente rote Marke umgestellt. Weisser Hintergrund, weisses A-Innenfeld und Haken sind echte transparente Aussparungen; Sidebar, Empty Workspace, Favicon und About verwenden dasselbe Asset. Der Brand-Trigger bleibt klickbar und zugaenglich beschriftet, besitzt aber keinen sichtbaren Hover-Buttonzustand. About zeigt das Logo mit 160 px prominent. Transparenz inhaltsfrei auf Alpha und fehlende deckende Weisspixel geprueft; fuenf fokussierte Tests sowie Client-/Serverbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 13B: GPO-Importduplikatfehler, veraltete Kontextpflicht und Upload-Snapshotzerlegung korrigiert. Observation-IDs aller Policy-Reducer binden neben Backupinstanz und Datei-Hash nun auch den exakten Quellartefaktpfad ein; byte-identische Dateien an unterschiedlichen GPO-Pfaden bleiben dadurch getrennte gueltige Beobachtungen. Reine GPO-Backups werden ohne zusaetzlichen OS-Scan automatisch gegen alle `eligible` importierten Microsoft-Baselines als getrennte Benchmarks ausgewertet; vorhandene DC-Kontexte bleiben Evidenz. Ein gemeinsam hochgeladener `selected-gpos`-Satz bleibt bei fehlenden oder gemischten Domainmetadaten ein einzelner partieller Snapshot. Parser-/Analyzervertrag auf 2.2.2, Snapshotaggregation auf 1.1.0 und Produktversion als kompatibler Patch auf 2.5.1 angehoben. Regressionen fuer identische Dateien, kontextfreien Auto-Vergleich, Baseline-Auswahl, gemischte Uploadmetadaten und 2.300-GPO-Lastfall gruen. Inhaltsfreie technische Kontrolle am betroffenen Import: HTTP 200, kein fehlgeschlagener Job, 184 erkannte GPOs und 3.638 Work-Ergebnisse (162 Uebereinstimmungen, 3.358 Abweichungen). Gesamtlauf 835 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine SQL-Migration. |
| 2026-09-06 | Phase 7: Echte ASSESSOR-Produktversion 2.5.0 eingefuehrt und von Processing-/GPO-Komponentenversionen getrennt. Der klickbare Markenblock oeffnet ein kompaktes About-Popup mit Buildzeit, Backend-Release, Importvertrag, GPO-Evaluation, Vergleich, Baselineanalyse, Snapshotaggregation, Policy-Identitaet und Credits fuer Michael Lukas und Binh Karl. Health meldet die Backend-Produktversion. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Serverbuild erfolgreich. Keine Daten- oder Schemamigration. |
| 2026-09-06 | Phase 13B: GPO-Benchmark auf die fachlich bestaetigte Microsoft-Sollwertsemantik begrenzt. Evaluator 1.3.3 waehlt nur zur beobachteten Umgebung passende Baselines, ignoriert leere Baselinezeilen und verhindert Pass/Fail bei nicht vergleichbaren Sollwerten. Security-Template-Registrywerte sind typbewusst vergleichbar. Nur Dummy neu ausgewertet: 363 Failed, 13 Passed, 8 Review/Warning und 0 Pass/Fail ohne Baselinewert. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine anderen Mandanten oder Originaldaten veraendert. |
| 2026-09-06 | Phase 13B: GPO-Baseline-Abweichungen als regulaere `Failed`-Zeilen in Work angebunden. Das eigene Blatt sowie Kategorie und Quelle heissen einheitlich `GPOs`; der normale Abweichungsfilter zeigt die Ergebnisse ohne Policy-Analyse-Zwischenschritt. Die Workspace-Ladung verwendet den aktuellen Evaluator und pro GPO-Backup den vollstaendigsten Baseline-Lauf, damit spaetere Teillaeufe keine vollstaendige Auswertung verdraengen. Den veralteten View-Hinweis im leeren Clientzustand entfernt. 825 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine Daten- oder Persistenzmutation. |
| 2026-09-06 | Phase 8/9/10: Das vereinbarte Quellen-Fortschreibungsmodell fuer unvollstaendige Folgetimeslots konkret geplant: drei Evidenzzustaende, getrennte Kennzahlen fuer gemessenen Fortschritt, Gesamtexposition und Evidence Coverage/Freshness, keine automatische Behebung oder Scoreverbesserung bei fehlender Quelle sowie auditierter Scope-Ausstieg. Zugleich die vollstaendige FindingReader-Bearbeitung an die bestehende Datenbank-Reviewgrenze angeschlossen. Stabile Occurrence-IDs verbinden Aggregate und Werkzeugblaetter; Bookmark, Status, Prioritaet, Owner/Team, Due Date, fuenf Freitextfelder und alle fuenf Marker werden optimistisch versioniert gespeichert. Vorhandene Browserreviews werden ohne Datenbankgegenstueck uebernommen, Datenbankreviews haben Vorrang. Additive JSONB-Erweiterung ohne SQL-Migration; 43 fokussierte synthetische Tests, 825 Standardtests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Keine realen Kundendaten gelesen oder veraendert. |
| 2026-09-06 | Phase 13B auf den vom Nutzer bestaetigten Policy-Analyzer-Vergleich umgestellt: Evaluator 1.3.1 fuehrt je aktiver Baseline einen baseline-getriebenen Left Join gegen den importierten GPO-Istbestand aus. Gleich ist Passed, verschieden oder fehlend ist Abweichung, ohne Baselineempfehlung bleibt unbewertet; mehrere Baselines werden getrennt statt als Kontextmehrdeutigkeit behandelt. Konflikte und technisch unvergleichbare Werte bleiben Review, neutrale Vergleiche erzeugen keine Severity oder Findings. Migration 020 bindet jedes Ergebnis an genau eine Baselineanalyse und erlaubt fuer fehlende Ist-Werte eine NULL-Aggregationsreferenz. Work projiziert jeden Baselinevergleich als eigene Zeile mit kurzem Baseline-Namen; deduplizierte GPO-Reimporte koennen die aktuelle Baseline-Menge erneut auswerten. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only, Designpruefung und Client-/Serverbuild erfolgreich. Vor der Dummy-Neuauswertung wurde ein Custom-Format-Backup erstellt. Ausschliesslich Dummy wurde neu ausgewertet: 3.638 Ergebnisse, 55 Passed, 3.556 Abweichungen, 27 Review; davon 3.483 explizit fehlende Ist-Werte. Keine anderen Mandanten ausgewertet. Phase 13B bleibt in Arbeit. |
| 2026-09-06 | Phase 7/13B: In jeder Timeslot-GPO-Zeile steht nun eine eigene Delete-Aktion neben Evaluate beziehungsweise Retry. Der Warnungsdialog benennt den exakten GPO-Eintrag und garantiert den Erhalt des Timeslots und aller anderen Quellen. Der bestehende bestaetigungspflichtige DELETE-Endpunkt wurde von Dead Letter auf alle beendeten GPO-Importe erweitert; Queue/Running bleibt gesperrt. Local- und PostgreSQL-Persistenz entfernen atomar das Artefakt sowie direkt und transitiv abhaengige Processing-, Identity-, Snapshot-, Evaluation- und Finding-Derivate, waehrend die persistente Artefakt-Loesch-Outbox erhalten bleibt. Synthetische Regressionen pruefen erfolgreichen Import samt Snapshot und Reprocessing-Kette, Dead Letter, parallele Queue-Sperre, HTTP-Bestaetigung und Clientroute. 829 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Der GPO-Pfad benoetigt keine neue SQL-Migration und hat keine kanonischen Fachdaten mutiert. Beim anschliessenden Neustart wurde die bereits anstehende Migration 020 nach eindeutiger Benennung ihrer beiden CHECK-Constraints auf dem kanonischen 2.0-Bestand erfolgreich registriert; App und PostgreSQL-Backend liefern HTTP 200. Keine Realdaten gelesen und keine neue Datenbank erzeugt; Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. |
| 2026-09-06 | Phase 7: Timeslot-Auswahl und Expansion wieder strikt getrennt. Ausschliesslich ein Klick auf die Checkbox markiert beziehungsweise demarkiert den Timeslot; Datum, freie Balkenflaeche, Zaehler und Dreieck gehoeren zur auf- und zuklappbaren Summary. Die bisherige Label-Klickflaeche um Datum und Checkbox wurde durch einen neutralen Container ersetzt, nur die Checkbox stoppt die Summary-Interaktion. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-06 | Phase 7/13B: die vorhandene Fortschrittsanzeige als gemeinsame, nicht vorzeitig schliessbare Progress-Dialogkomponente fuer Scanimporte, Security-Baseline-Uploads, GPO-Ordner-/ZIP-Uploads sowie Profil-, Snapshot-, Baseline- und Finding-Berechnungen vereinheitlicht. GPO-Upload und Retry bleiben ueber die persistierte Job-ID bis zum Endzustand sichtbar statt bereits nach dem Queuing zu verschwinden; Texte sind bewusst auf einen kurzen aktuellen Arbeitsschritt begrenzt. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. |
| 2026-09-06 | Phase 13B: Baseline-Delete fuer Vollreimporte erweitert. Nach ausdruecklicher Bestaetigung werden referenzierende, reproduzierbare Policy-Evaluation-/Finding-Ketten entfernt; Kunden- und GPO-Quelldaten bleiben erhalten. Dialogtext verkuerzt. Fokussierte 20 Tests und Client-/Serverbuild erfolgreich. Vor dem Eingriff kanonisches PostgreSQL-Backup erstellt und lesbar geprueft; den letzten blockierten Baselineeintrag geloescht. Verifiziert: Katalog 0, Backend PostgreSQL gesund, App HTTP 200 und 51 GPO-Beobachtungen unveraendert vorhanden. |
| 2026-09-06 | Phase 12/13B um die verbindliche Datenschutzgrenze der Result DB erweitert. PingCastle- und kuenftige Scanner-Zusatzinformationen werden nur ueber `result-db-supplemental-disclosure` 1.0.0 freigegeben: exakte Tool-/Property-Allowlist, enge Wertevalidatoren und kontrolliert neu aufgebaute Titel/Subject-Klassen; Identitaet, Originalwert, Attribute, Asset, Abschnitt, Locator und Quellzeitpunkt bleiben intern. Rohe GPO-Policy-Beobachtungen sind nur noch im expliziten `internal-analysis`-Modus fuer Work/Data-Hub-Auswertung verfuegbar, waehrend bestaetigte Policy-Findings in der Result DB bleiben. JSONL-Schema 1.1.0 erzwingt die Klassifikation und entfernt gesperrte Felder nochmals vor Serialisierung. 31 fokussierte Tests, alle 826 Standardtests, 8 erwartungsgemaess uebersprungene PostgreSQL-Tests, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Daten verwendet; keine Original-, Persistenz- oder Schemaaenderung. |
| 2026-09-06 | Phase 13B/13C: automatische timeslotgebundene PingCastle-DC-Kontexte, GPMC-Core-/GPReport-Metadaten, begrenzter SAX-Parser, gemeinsame native Security-/Audit-Ziele, Import-Folgepipeline und Work-Bewertungsspalten implementiert. Migration 019 nach lesbar geprueftem Backup auf dem kanonischen Bestand angewandt; ausschliesslich Dummy neu verarbeitet: 51 Beobachtungen, 50 Review-Ergebnisse. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only, Designpruefung und Client-/Serverbuild erfolgreich. Fehlendes Baselineoriginal und unzureichende Backupvollstaendigkeit bleiben dokumentierte Blocker; kein abgeschlossener Baseline-Abgleich und keine visuelle Browserabnahme behauptet. Temporaeren Dummy-QA-Test entfernt, Backup behalten. |
| 2026-09-06 | Phase-7/12-Timeslotnavigation auf einen einzigen vertikalen Scrollcontainer vereinheitlicht: Die Quellenliste innerhalb eines ausgeklappten Timeslots besitzt keine eigene Maximalhoehe und keine eigene Scrollbar mehr. Ein Timeslot waechst mit allen Quellen und Aktionen; gescrollt wird ausschliesslich die gesamte aeussere Timeslot-Liste mit ihrem unteren Abstand. Die fokussierte Strukturregression trennt den erlaubten aeusseren `overflow-y`-Vertrag von der verbotenen inneren Scrollbegrenzung. Keine Daten-, API-, Persistenz- oder Fachlogikaenderung; Phase 7 und 12 bleiben abgeschlossen. |
| 2026-09-06 | Phase-7/12-Timeslotnavigation nach Nutzerhinweis gegen eine optisch abgeschnittene letzte ausgeklappte Karte korrigiert: Der eigene scrollbare Timeslotlistenbereich behaelt seitlich und oben seine kompakte Geometrie, erhaelt unten jedoch den gemeinsamen 20-px-Abstand. Dadurch koennen Abschlusskontur und letzte Aktion vollstaendig ueber die Viewport-Unterkante gescrollt werden. Drei fokussierte Strukturtests, Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich; keine Daten-, API-, Persistenz- oder Fachlogikaenderung. Phase 7 und 12 bleiben abgeschlossen. |
| 2026-09-06 | Phase-11-Lokalbetrieb auf ausdruecklichen Nutzerwunsch konsolidiert: Der bekannte Datenstand `assessor-2_0` ist als einziger kanonischer lokaler ASSESSOR-PostgreSQL-Bestand festgelegt. `docker-compose.postgres.yml` verwendet dauerhaft den Compose-Projektnamen `assessor-2_0` und bindet `assessor-2_0_assessor-postgres-data` als vorhandenes externes Volume; `AGENTS.md` verbietet alternative ASSESSOR-Datenbanken und Fallbackports. Zwei fokussierte Konfigurationsregressionen, Compose-Validierung, Client-/Server-Produktionsbuild sowie HTTP-Health von Client und Backend sind erfolgreich. Der Gesamttest besitzt weiterhin genau den bereits dokumentierten unabhaengigen statischen Data-Hub-Open-Befund zur alten Quelltextformatierung. Keine Schema- oder Fachdatenaenderung; die separat bestaetigte Bereinigung der ASSESSOR-Container und -Volumes fuer 2.5, 2.4.1, 2.4 und den Phase-13-Testbestand betraf weder den kanonischen 2.0-Bestand noch fremde Docker-Anwendungen. Phase 11 bleibt abgeschlossen. |
| 2026-09-04 | Phase-13B-GPO-Ordnerimport gegen einzelne nicht oeffenbare Windows-Verzeichniseintraege gehaertet: Direkter Picker und Fallback behandeln `getFile`-, Verzeichnisiterator- und Byte-Lesefehler pro Eintrag, behalten alle lesbaren Dateien und melden die Anzahl ausgelassener Eintraege ausdruecklich in der Erfolgsnachricht statt den gesamten Import mit der rohen Browser-NotFound-DOMException abzubrechen. Sind keine Dateien lesbar, bleibt der Import geschlossen. Metadaten- und Ressourcengrenzen gelten vor der Byteerfassung weiter. Eine neue synthetische Regression kombiniert lesbaren Inhalt, nicht oeffenbaren Handle und nicht lesbaren Dateikoerper; insgesamt 16 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; die UI macht eine moegliche Unvollstaendigkeit sichtbar, Phase 13B bleibt in Arbeit. |
| 2026-09-04 | Phase-13B-GPO-Ordnerauswahl nach wiederholtem Windows-Dateireferenzfehler auf einen neuen Primaerpfad umgestellt: `Import GPO Folder` verwendet bei Verfuegbarkeit den explizit durch den Nutzer freigegebenen File-System-Access-Verzeichnispicker, traversiert ausschliesslich den gewaehlen Baum read-only und konstruiert stabile relative Pfade; der bisherige `webkitdirectory`-Selektor bleibt nur fuer Browser ohne diese API als Fallback bestehen. Beide Pfade laufen weiterhin durch denselben Metadaten-Preflight, die unmittelbare Byteerfassung, deterministische ZIP-Kompression und die unveraenderte projekt-/timeslotgebundene Submission. Eine neue synthetische Rekursionsregression sichert den direkten Verzeichnisvertrag; insgesamt 15 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert, keine allgemeinen Dateisystemrechte und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-04 | Phase-13B-GPO-Verzeichnisupload nach erneuter Realfehler-Rueckmeldung auf sofortige Dateierfassung umgestellt: Alle Browser-Leseoperationen werden jetzt noch synchron im Auswahlereignis gestartet, bevor Windows einzelne spaeter sequenziell geoeffnete Verzeichnisreferenzen verlieren kann; die bereits erfassten Bytes werden anschliessend deterministisch komprimiert. Ein gemeinsamer plattformneutraler Metadaten-Preflight prueft Anzahl, Einzel- und Gesamtdatenmenge vor dem Start irgendeiner Leseoperation, sodass die sofortige Erfassung die bestehenden Ressourcengrenzen nicht umgeht. Drei neue synthetische Regressionen sichern gleichzeitigen Lesestart, begrenzte NotFound-Abbildung und Ablehnung vor dem Lesen; insgesamt 14 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-04 | Phase-13B-GPO-Dateiauswahl gegen waehrend der asynchronen Kompression verlorene Browser-Dateireferenzen gehaertet: Ordner- und ZIP-Input werden nicht mehr unmittelbar nach dem Change-Ereignis geleert, sondern erst nachdem Einlesen, Verpacken und Submission beendet sind. Der Ordnerpfad uebergibt zuvor eine stabile File-Liste; ein tatsaechlich nicht lokal verfuegbarer Eintrag liefert eine konkrete, inhaltsfreie Handlungsanweisung statt der rohen Browser-DOMException. Elf fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-04 | Phase-13B-GPO-Ordnertransport an die vorhandenen sicheren Archivgrenzen angeglichen: Der Browser erzeugt fuer einen ausgewaehlten Backupordner nun ein deterministisches ZIP mit verlustfreier Deflate-Kompression pro Datei und behaelt unveraendert CRC-, Pfadnormalisierungs-, Kollisions-, Eintrags-, Einzeldatei- und Transportpruefungen. Dadurch darf der gepruefte Ordnerinhalt bis zur bereits serverseitig geltenden Grenze von 512 MiB reichen, waehrend die tatsaechlich uebertragene ZIP-Datei weiterhin auf 100 MiB begrenzt bleibt; nicht komprimierbare Inhalte koennen diese Transportgrenze weiterhin nicht umgehen. Eine synthetische Byte-fuer-Byte-Regression belegt, dass Quellinhalt oberhalb einer kleineren Transportgrenze komprimiert, serverseitig verifiziert und identisch wiederhergestellt wird. Neun fokussierte GPO-Transport-/HTTP-Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 791 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen Dashboard-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-04 | Phase-7/13B-Work-Quellenfilter nach der additiven GPO-Projektion korrigiert: Die projektweite Facette `Source: Scan` bleibt innerhalb der auf zehn sichtbare Filter begrenzten Leiste verbindlich als letzter sekundaerer Filter erhalten und kann dadurch nicht mehr von den zusaetzlichen GPO-Feldern verdraengt werden. Bestehende Scannerblaetter und Werkzeugwerte bleiben unveraendert; `Group Policy` wird nur als weitere Quelle und als eigenes Beobachtungsblatt ergaenzt. Zwei neue synthetische Regressionen sichern vier Scannerwerkzeuge plus GPO sowie die Filtergrenze ab. 15 fokussierte Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 790 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen Dashboard-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit. |
| 2026-09-03 | Phase-7-Client-Info-Standardansicht nach Nutzerreferenz festgelegt: `Assessment Status` startet als einzige geoeffnete Informationskarte; Directory Coverage, Certificates & PKI, Infrastructure Details, Identity & Privilege, GPO & Password Hygiene, Control Paths & Trusts, Infrastructure & Resilience, Severity Distribution und Directory Overview starten minimiert und vollbreit. Alle Karten bleiben ueber die gemeinsamen Dreiecke individuell schaltbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Detailkorrektur umgesetzt: minimierte Informationskarten behalten mit voller Spaltenbreite dieselbe Breite wie im maximierten Zustand; Collapse reduziert nur die Hoehe. Der PingCastle-Engine-Hinweis wurde aus `Directory Overview` entfernt, ohne die normalisierte Quellprovenienz zu veraendern. 13 fokussierte Dashboard-/Interaktionstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info auf stabile Spalten und eine geschlossene Kopfzone korrigiert. Das laufzeitgemessene dichte Masonry wurde durch drei feste, semantisch zugeordnete Kartenstapel mit 3/2/2 Karten ersetzt; minimierte und maximierte Karten bleiben dadurch immer in ihrer Spalte und nur nachfolgende Karten derselben Spalte ruecken auf. Die sechs KPI-Kacheln fuellen auf Desktop gemeinsam die Hoehe von `Assessment Status`, sind groesser typografiert und folgen nun Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections. Compliance ist als H1 hervorgehoben; ausschliesslich Deviation und High Severity sind klickbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 780 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet noch die alte einzeilige Quelltextdarstellung der weiterhin korrekt vorhandenen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Collapse geometrisch korrigiert und Plus/Minus durch Standarddreiecke ersetzt. Ein eigener `DashboardMasonryGrid` misst die zehn Karten, aktualisiert ihre Rasterspannen per ResizeObserver und packt sie dicht; dadurch rueckt die naechste Karte nach dem Schliessen sofort direkt unter die verkleinerte Kopfzeile. Vor erfolgreicher Messung beziehungsweise ohne ResizeObserver bleibt das normale sichere Grid aktiv. Beide gemeinsamen Kartentypen zeigen nun das App-weite SVG-Dreieck nach unten fuer offen und nach rechts fuer geschlossen. 16 fokussierte synthetische Dashboard-/Interaktions-/Masonry-/Icon-Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 781 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet noch eine alte einzeilige Quelltextdarstellung der weiterhin korrekt vorhandenen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase 13B um die konkrete GPO-Sicht in Work und Result DB erweitert. Aktuelle Policy-Beobachtungen werden ohne Datenkopie aus Artefakt-, Processing-, Backup- und Identity-Persistenz als `policy-observation` projiziert, ueber `assessmentIds` demselben fachlichen Timeslot wie die Scannerlaeufe zugeordnet und mit Werten, technischen Identitaeten, Scope, Delivery Mechanism, Diagnosen und Quell-Locator exportierbar gemacht. Work besitzt ein eigenes Blatt `Group Policy · Observations` und fuehrt die Zeilen zusaetzlich in `All Records` mit `Source: Scan = Group Policy`; die Result DB zeigt sie unter dem Standardfilter als Kontext mit Strichen fuer IOE/Deviation. Die laufende Dummy-API wurde mit 51 GPO-Beobachtungen und zusammen 503 Resultaten im ausgewaehlten historischen Scope verifiziert. 13 fokussierte Tests, 781 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration, keine Mutation der Dummy- oder Originaldaten; bestaetigte GPO-Findings bleiben weiterhin von Environment Profile, Identity-/Baseline-/Regelkatalog und Finding Factory abhaengig. |
| 2026-09-03 | Phase-7-Client-Info-Faktenblock auf Nutzerwunsch als eigene Kachel umgesetzt. `Infrastructure & Resilience` zeigt nur noch seine Risiko-/Mengenwerte; die neue minimierbare Kachel `Infrastructure Details` enthaelt `Marked findings` und alle sieben bestehenden Environment-Fakten in der vollstaendigen responsiven Faktenliste. Der gemeinsame Kartenvertrag wurde fuer eine titel-only Kopfzeile optional erweitert; die Ansicht besitzt nun zehn Informationskacheln. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung erfolgreich. Der vollstaendige TypeScript-Build bleibt durch eine unabhaengige parallel hinzugekommene GPO-Testfixture ohne `ImportProcessorReference.kind` blockiert; der nachgelagerte direkte Vite-Build konnte wegen Sandbox-`spawn EPERM` nicht separat ausgefuehrt werden. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Maester-Fehlermeldungen lesbar strukturiert. Ein neuer reiner Parser erkennt ausschliesslich eindeutige `Invoke-MgGraphRequest`-Ausfuehrungsfehler, extrahiert Graph-Meldung, Fehlercode, HTTP-Status, Methode/Endpunkt, Skriptzeile, Zeit und Korrelations-IDs und bewahrt den unveraenderten Rohtext. Das Results-Fenster zeigt die Ursache prominent, technische Werte in einer responsiven Feldmatrix und den Rohbeleg standardmaessig eingeklappt; normale Resultate bleiben unveraendert. 48 fokussierte synthetische Result-/Reader-Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 777 Tests; eine unabhaengige statische Result-DB-Scope-Regression ist aufgrund einer parallel vorhandenen `assessmentIds`-Quelltextergaenzung rot, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Minimierung korrigiert und alle neun Informationskacheln geprueft. Die sechs Mengen-/Faktenkarten und die drei Karten der rechten beziehungsweise oberen Donut-/Faktenzone starten vollstaendig sichtbar mit Minus; ein Klick reduziert jede Karte auf die reine Kopfzeile mit Plus und intrinsischer Kopfzeilenhoehe, ein weiterer stellt den vollstaendigen Inhalt wieder her. Damit bleibt eine minimierte Karte auch neben einer hoeheren geoeffneten Rasterkarte nicht als leere Vollhoehenflaeche stehen. Beide gemeinsamen Kartenkomponenten verwenden denselben zugaenglichen Inhaltscontainer, die sechs reinen Zahlenkacheln bleiben unveraendert. 13 fokussierte Dashboard-/Interaktionstests, 776 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Testdaten verwendet; keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase 13B um die erreichbare GPO-Analyse im Data-Hub-Clientdetail erweitert. Erfolgreiche GPO-Zeilen zeigen statt einer ausgegrauten Scanner-Checkbox eine eigenstaendige GPO-Markierung und `View`; die Aktion oeffnet die vorhandene projektgebundene Workflow-, Summary-, Historien- und Review-Oberflaeche und bietet den Rueckweg zu den Clientinformationen. Der Scanner-Provenienzfilter bleibt unveraendert scannerbezogen. Am freigegebenen Dummy-Client wurde die Anzeige mit einem vollstaendig verarbeiteten Drei-GPO-Paket, 51 Beobachtungen und 48 aktuellen Review-Eintraegen inhaltsbezogen verifiziert. Sieben fokussierte Tests, 775 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-03 | Phase 13B um die fehlende Data-Hub-Sichtbarkeit und den direkten ZIP-Auswahlweg fuer GPO-Backups ergaenzt. GPO-Artefakte erscheinen nun als eigene Quellenzeilen im zugeordneten Timeslot, fliessen in dessen Zaehler ein, zeigen ihren technischen Verarbeitungszustand und bieten bei Dead Letter Wiederholung beziehungsweise Loeschung. Ein `assessor:gpo-changed`-Refresh macht neue Einreichungen unmittelbar sichtbar. Die getrennten Buttons `Import GPO Folder` und `Import GPO ZIP` fuehren normalen Ordner beziehungsweise vorhandenes Archiv derselben bestehenden Backend-Ingestion zu; der Ordner wird zuvor weiterhin lokal deterministisch verpackt. 14 fokussierte Tests, 774 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-03 | Phase 13B um die Betriebsgrenze fuer kuratierte Policy-Regelkataloge erweitert: optionale lokale JSON-Datei mit verpflichtendem SHA-256-Pin, 5-MiB-Limit, Regular-file-/Symlink-Schutz, fataler UTF-8-/JSON-Pruefung und bestehender geschlossener fachlicher Freigabevalidierung. Ungueltige oder unvollstaendige Konfiguration stoppt vor Repository- und Serverstart; ohne Datei bleibt der fachlich leere sichere Katalog aktiv. Konfiguration in `docs/LOCAL_BACKEND.md` dokumentiert. Drei neue synthetische Loaderregressionen, 28 fokussierte Tests und Gesamtlauf mit 773 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests erfolgreich; Local-only-, Designpruefung und Client-/Serverbuild gruen. Keine Netzwerk-, API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt bis zur fachlichen Regel- und Inbox-ADMX-/ADML-Kuratierung in Arbeit. |
| 2026-09-03 | Phase 13B um snapshotbezogene Ergebnisdeduplizierung erweitert: Das additive `current`-Readmodell verfolgt die aktive Profil-/Identity-/Aggregation-/Evaluation-/Finding-Kette, waehrend `summary`, Evaluationen und Reviewdaten der vollstaendigen Audit-Historie erhalten bleiben. Die sichtbare Summary und Current Review Queue nutzen nur den aktiven Zustand; die Evaluation History bleibt separat sichtbar. Evaluate- und Finding-Aktionen fuer veraltete Ketten werden nicht mehr angeboten. Drei Domainregressionen sowie Panel-, Actions- und HTTP-Regression erfolgreich; Gesamtlauf 770 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL- oder Persistenzaenderung, keine Realdaten gelesen; Phase 13B bleibt in Arbeit. |
| 2026-09-03 | Phase-7-Client-Info-Infopanels auf die abschliessend bestaetigte Bildreferenz korrigiert: Minimiert enthalten alle neun Panels nur die luftige Kopfzeile mit `Titel — Primaermenge` und Plus, ohne Balken. Expandiert zeigen Mengenbereiche 120-px-Datenzeilen mit 72-px-dicken Mengenbalken; Assessment Status und Severity Distribution wurden von Donuts auf dieselbe Balkenkomponente umgestellt, wobei ihre Filteraktionen erhalten bleiben. Faktenzeilen wachsen mit 72-px-Mindesthoehe, die kompakte Resilience-Ausnahme wurde entfernt und schmale Ansichten stapeln Wert und 44-px-Balken responsiv. Die sechs Zahlenkacheln blieben unveraendert. 12 fokussierte Tests, 774 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info abschliessend an die neue Gesamtansicht angepasst: sechs unveraenderte Zahlenkacheln oben, darunter sechs dauerhaft sichtbare Mengenpanels als dreispaltige Matrix und rechts eine eigene Rail mit Assessment-/Severity-Donuts sowie Directory Overview. Plus/Minus blendet nur Zusatzinformationen ein; die Kernzeilen bleiben sichtbar. Die Mengenzeilen entsprechen mit 64-px-Zeilen und 30-px-Balken der kompakten Bildgeometrie, nutzen reale Werte und behalten bestehende Filteraktionen der Donutlegenden. Responsive Breakpoints reduzieren die Matrix auf zwei/eine Spalte und stapeln die Rail. 12 fokussierte Tests, 774 bestandene Standardtests, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Kopfzeile verdichtet: Die sechs quadratischen Zahlenkacheln belegen als verkleinerte Sechserspur die linken drei Viertel; die Assessment-Status-Donutkarte steht im rechten Viertel derselben ersten Reihe. Severity Distribution und Directory Overview ruecken dadurch in der rechten Rail nach oben. Die Kopfzone stapelt sich ab 1100 px; die Kennzahlen wechseln dort auf drei und ab 800 px auf zwei Spalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Standardziel von `Open Client` in Phase 7 von Work auf Client Info umgestellt. Der zentrale Data-Hub-Auswahlcallback aktiviert `dashboard` und oeffnet weiterhin exakt das gewaehlte Projekt mit denselben ScanRun-IDs; dadurch gilt die Aenderung sowohl fuer Quick Open als auch fuer Open aus der Clientdetailseite. Neun fokussierte Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Sichtbare Phase-7-Breitenabweichung der expandierten Client-Info-Karten korrigiert: Statt auf der minimierten Zwei-Spalten-Breite zu bleiben, belegen geoeffnete Panels nun sechs Rasterspalten; bei 800 beziehungsweise 560 px wechseln sie auf die gesamte verfuegbare Vier- beziehungsweise Zwei-Spalten-Breite. Dadurch liegen Label/Wert und der 72-px-Mengenbalken wie in der Referenz nebeneinander innerhalb der Karte, ohne Nachbarflaechen zu ueberdecken. Bereits im Kopf dargestellte Primaerwerte sind aus den expandierten Zeilen entfernt; neutrale Serien folgen der roten, orangen, gelben und violetten Referenzfolge, waehrend bestehende Fachfarbgruppen unveraendert bleiben. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info nach freigegebenem Telemetrieentwurf auf Progressive Disclosure umgestellt: Die sechs Zahlenkacheln sind unveraendert. Assessment Status, Severity Distribution, Directory Overview, Directory Coverage, Identity & Privilege, Control Paths & Trusts, Certificates & PKI, GPO & Password Hygiene sowie Infrastructure & Resilience starten kompakt mit ihrer realen Primaermenge und einem Mengenbalken. Plus/Minus blendet pro Karte die vollstaendigen bestehenden Donut-, Mengenbalken- und Fakteninformationen ein beziehungsweise aus; es wurden keine im Mockup erfundenen Bereiche oder Verlaufsdaten implementiert. 15 fokussierte Dashboard-/Interaktions-/Inset-Tests, 774 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Unmittelbare Phase-7-Nutzerkorrektur fuer echte responsive Kartenhoehen: Die zuvor gesetzten drei festen Rasterzeilen wurden wieder entfernt. Breakpointabhaengige Rastereinheiten bilden nun nur noch die Mindesthoehe; `minmax(..., auto)` und `min-content` lassen Inhaltskarten anhand ihrer vollstaendigen Werte wachsen. `Infrastructure & Resilience` verwendet automatische Inhaltshoehe, waehrend andere Karten quadratisch bleiben, solange ihr Inhalt hineinpasst. 14 fokussierte Dashboard-/Inset-Tests, 770 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Infrastructure-&-Resilience-Kachel gegen Inhaltsueberlauf korrigiert: Die Karte reserviert nun drei Rasterzeilen und hebt nur fuer diese inhaltsreiche Ausnahme das starre Quadratverhaeltnis auf. Damit bleiben auch lange vollstaendige OS-Aufzaehlungen innerhalb der Flaeche, waehrend Faktenlayout und alle uebrigen quadratischen Karten unveraendert bleiben. 14 fokussierte Dashboard-/Inset-Tests, 769 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Work-Finding-Kacheln auf das bestaetigte Referenzformat vereinheitlicht: 358 px feste Breite, 223 px Mindesthoehe, keine Restbreitenstreckung und weiterhin wachsender Inhalt. Kopfaufteilung mit Hexagon links sowie Bookmark/Results rechts bleibt erhalten; die Metadaten stehen stabil als Status, Kategorie, Severity plus Weight und Score. Die Regel ist auf direkte Work-Rasterkacheln begrenzt, sodass Pathfinder-Micro-Cards kompakt bleiben. 16 fokussierte Kachel-/Typografie-/Pathfinder-Tests, 768 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Result-DB auf `Deviation = Yes` als initialen und Reset-Filter gestellt und gefilterten JSONL-Export ergaenzt. Der Button laedt alle Treffer des aktuellen Projekt-/Timeslot- und Nutzerfilterzustands in stabilen 1.000er-Seiten, bricht bei veraenderter Gesamtmenge fail-closed ab und erzeugt ein versioniertes Manifest plus eine vollstaendige JSON-Zeile je Unified Result. Drei fokussierte Export-/Scope-Tests, 767 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Balkenlisten bereinigt: Label, Balken und Wert verwenden nun ein identisches Dreispaltenraster; eine kompakte zweite Wertzeile ist auch ohne Hinweis reserviert, sodass `Restricted` keine einzelnen Zeilen mehr verschiebt. Zahl und optionale Einheit sind getrennt formatiert und bleiben rechtsbuendig zusammen. Die Resilience-Kompaktkarte setzt die Standardplatzierung explizit auf ihr Einspaltenlayout zurueck. 13 fokussierte Dashboard-/Kacheltests, 767 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-26 | Phase-13B-Regelkatalog-Freigabegrenze gehaertet: Runtimevalidierung fuer geschlossene Auslieferungsmechanismen, Baseline-Dispositionen, Comparatorvarianten/-modi und Severitywerte ergaenzt; ueberlappende Selektoren, mehrdeutige kontextspezifische Regeln sowie widerspruechliche Risiko- und Abhaengigkeitsdefinitionen werden vor Serviceaktivierung fail-closed abgelehnt. Der fachliche Produktivkatalog bleibt bewusst leer. Der lokale private Artefaktspeicher zeigt wieder auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots; Backend `ok`, App HTTP 200 und vorhandener Speicherroot wurden ohne Inhaltszugriff bestaetigt. Neun neue synthetische Katalogtests, 25 fokussierte GPO-/Katalogtests, 764 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. |
| 2026-09-03 | Phase-7/13C-nahe, lokale Result-DB-LLM-Uebergabe optimiert und nach Nutzerpraezisierung angepasst: `Copy JSON` erzeugt ein versioniertes Dashboard-Envelope mit deterministischer Summary, ausschliesslich handlungsrelevanten Findings, kompakten Not-Run-Eintraegen und gruppierten freigegebenen Environment-Fakten. Findings und Not-Run-Checks verwenden ihre Scanner-Regel-ID; bei fehlender Quell-ID steht `null`, ohne erfundene Ersatzidentitaet. Vorhandene Beschreibungen und Empfehlungen werden unabhaengig von der Severity uebernommen; Review, Processing, leere Werte, `None`, Passed-Details und nicht freigegebene Environment-Werte entfallen. Eingebettete E-Mail-Adressen werden redigiert. Ein separater Prompt definiert untrusted Input, regel-ID-gebundene Referenzen und ein strikt versioniertes JSON-Ausgabeformat fuer die spaetere Dashboarddarstellung. 758 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine externe Uebertragung, API-, Persistenz- oder Datenbankschemaaenderung; Phase 7 bleibt abgeschlossen und Phase 13C in Arbeit. |
| 2026-08-25 | Phase-7-Markierungsfarbe appweit auf Gelb vereinheitlicht: Der neue Theme-Token `--marking-color` traegt in Dark und Light denselben Wert und steuert Kachelauswahl, allgemeine Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl. Die violette Datahub-Auswahlkontur entfaellt. Tastaturfokus bleibt blau, Scanner-/Workflow-/Severitystatus behalten ihre fachlichen Farben. Projektregel und Kachelregression wurden aktualisiert. 24 fokussierte Auswahl-/Dashboard-/Graphtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Kachelstandard appweit auf die freigegebene flache Client-Info-Geometrie umgestellt: `--tile-border` ist in beiden Themes transparent, `--tile-radius` verwendet den zentralen Nullradius und `--tile-card-shadow` ist deaktiviert. Datahub-, Dashboard-, Sidebar-, Work- und Pathfinder-Hover veraendern die Flaeche ohne dekorative Kontur; Fokus, Auswahl und Statusmarkierungen bleiben sichtbar. `AGENTS.md` und die gemeinsamen Kachelregressionen wurden auf den neuen verbindlichen Standard aktualisiert. 24 fokussierte Kachel-/Dashboardtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Client-Info-Kacheldesign nach erneutem Referenzabgleich korrigiert: Die quadratischen Kennzahl- und Inhaltskacheln verwenden im Normalzustand keine helle Aussenkontur, keinen Kartenschatten und keine Rundung; auch die dekorative Linie unter Inhaltskartentiteln entfaellt. Flaechenkontrast und gemeinsamer Rasterabstand trennen die Kacheln wie im Sollbild, waehrend Hover, Tastaturfokus und aktive Filter funktional sichtbar bleiben. Neun fokussierte Dashboardtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Client-Info nach Nutzerreferenz auf ein quadratisches SOC-Raster verdichtet: Alle sechs Kennzahlen sind kompakte 1-x-1-Kacheln, alle neun Inhaltskarten einheitliche 2-x-2-Kacheln im selben responsiven `dense`-Raster. Die bisherigen separaten Sechser- und Dreispaltenraster, gestreckten Kennzahlen sowie 384-px-Mindesthoehen entfallen; Faktenzeilen wurden innerhalb der quadratischen Karten kompakter angeordnet. Neun Dashboard-Regressionen, Gesamtlauf mit 755 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Eine Live-Browser-Geometriepruefung war in der Sitzung mangels Browser-Verbindung nicht verfuegbar. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-PurpleKnight-Altlabel korrigiert: Der FindingReader behandelt nun `Short Name` mit Leerzeichen ebenso wie `ShortName` als technische Kennung und zeigt beide ausschliesslich unter Additional Information. Eine synthetische Regression prueft Summary-Ausschluss und Additional-Zuordnung; alle 15 FindingReader-Tests sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Ergebnis- und Timeslot-Dichte nach Nutzerkorrektur nachgeschaerft: Im Resultfenster verwenden ausschliesslich Fenstertitel und wiederholte Inhaltsueberschrift H4 mit 16 px statt H3 mit 18 px. Die Finding-Trefferliste behaelt die verbindliche 16-px-Inhaltsuntergrenze, verwendet fuer Titel aber Regular 400, eine kompaktere Zeilenhoehe sowie schmalere Iconspalte, Abstaende und Innenraender; dadurch stehen mehr Zeichen pro Zeile ohne schwer wirkende Fettschrift zur Verfuegung. Timeslots besitzen in jedem Zustand eine 1-px-Kontur, 12 px Abstand und getrennte Interaktionszonen: links Checkbox plus Datum ausschliesslich fuer die Auswahl, rechts Zaehler plus Dreieck ausschliesslich zum Auf- und Zuklappen; Auswahl und Expansion sind nicht mehr gekoppelt. Am freigegebenen Dummy-Client wurden 16 px/400, 1-px-Kontur, 12-px-Abstand und die unabhaengigen Zustandswechsel geometrie- und zustandsbasiert verifiziert. Acht fokussierte Regressionen sowie der Gesamtlauf mit 753 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7/13A-Rueckwaertskompatibilitaet fuer bereits persistierte PurpleKnight-HTML-Altimporte ergaenzt: Das fruehere `ResultDetail`-JSON wird read-only und begrenzt als `Column: value`-Tabelle projiziert, aktiviert damit das vorhandene Results-Fenster und wird bei vorhandener strukturierter Tabelle nicht mehr zusaetzlich im Finding oder unter Additional Information angezeigt. Das alte `Framework`-JSON wird ohne Ausfuehrung in lesbare MITRE- und ANSSI-Felder aufgeloest; die nur im alten HTML-Schema zusaetzlich sichtbaren Rohfelder `Grade` und `Exposure Type` werden in diesem Kompatibilitaetsfall ausgeblendet. Originalwerte und Persistenz bleiben unveraendert, ein Reimport ist fuer die Darstellungskorrektur nicht erforderlich. Zwei synthetische Regressionen pruefen JSON-Tabellenprojektion, Framework-Aufloesung und die Unterdrueckung redundanter Rohfelder. Gesamtlauf 753 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Profil- oder Persistenzmigration; Phase 13A bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Kachelunterbau auf ausdruecklichen Nutzerwunsch anwendungsweit entfernt: Die gemeinsamen Segmenttokens fuer Flaeche und Kontur sind in dunklem und hellem Skin transparent. Donut-Racks, Mandantenkachelgruppen, Dashboardgruppen, Work-Matrix, Policy-, Pathfinder- und weitere tokengebundene Kachelgruppen behalten Radius, Inset und den 12-px-Gap, zeigen aber keine zweite sichtbare Gruppenflaeche oder Aussenkontur mehr. Einzelkacheln behalten unveraendert Flaeche, graue Kontur, Auswahlzustand und Schatten. Die verbindliche Projektregel wurde auf transparente Layoutsegmente aktualisiert. Im Browser wurden Data-Hub-Donutgruppe, Mandantenkachelgruppe und Work-Matrix in beiden Skins mit `rgba(0, 0, 0, 0)` fuer Hintergrund und Kontur verifiziert; die Work-Kachelkontur blieb sichtbar. Dreizehn fokussierte Segment-/Dashboardtests sowie der Gesamtlauf mit 751 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Client-Info-Kopf um den aktiven Clientkontext ergaenzt: Direkt hinter der H1 `Client Info` stehen jetzt das vorhandene rechtsgerichtete Dreieck im gelben Aktivton und der Name des aktiven Clients auf der H3-Typografiestufe. Der bisher rechtsbuendig gerenderte Clientname wird im Dashboard unterdrueckt, damit er nicht doppelt erscheint; Verbindungsstatus und die Kopfgeometrie der uebrigen Ansichten bleiben unveraendert. Am freigegebenen Dummy-Client wurden Reihenfolge `Client Info` → gelbes 24-px-Dreieck → `Dummy`, Aktivfarbe `rgb(217, 150, 42)` und die Abwesenheit einer zweiten rechten Namensinstanz verifiziert. Sechs fokussierte Header-/Icontests sowie der Gesamtlauf mit 751 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Client-Info um eine Timeslotauswahl in der oberen Kontextzeile ergaenzt: Das Dashboard verwendet die bereits bestehende zentrale WorkTimeslotControl und damit dieselbe servergestuetzte Timeslotliste, aktive ScanRun-Auswahl und `openProject`-Grenze wie Work; keine zweite Auswahl- oder Ladefachlogik wurde eingefuehrt. Der Selektor steht rechtsbuendig neben Client-, Bericht- und Datensatzkontext. Am freigegebenen Dummy-Client wurde der Wechsel von 18.08.2026 mit 318 Datensaetzen auf 22.07.2026 mit vier Scanberichten und 885 Datensaetzen in derselben Client-Info-Ansicht verifiziert. Elf fokussierte Dashboard-/Timeslottests sowie der Gesamtlauf mit 750 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Donut-Units auf Nutzerwunsch vereinfacht: Die farbigen horizontalen Akzentstriche am oberen Rand der gemeinsamen DonutMetricCard wurden zentral samt ungenutzter Aufbauanimation entfernt. Ringtrack, Wertbogen, Kartenkontur, Titel, Werte, Prozentunit und alle Tonfarben bleiben unveraendert; die Aenderung gilt damit konsistent fuer Datahub und kompakte Sidebar-Donuts. In der laufenden Data-Hub-Ansicht wurden alle sechs Statusunits geprueft, ihr ehemaliges Pseudoelement liefert jeweils `content: none`. Sechs fokussierte Donut-/Datahubtests sowie der Gesamtlauf mit 750 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der zuvor dokumentierte PurpleKnight-Extractorfehler wurde unabhaengig davon im unmittelbar vorhergehenden Phase-13A-Schritt behoben; keine Fachlogik-, API-, Persistenz- oder Schemaaenderung, Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-13A-PurpleKnight-HTML-Paritaet zur Excel-Anzeige nachgehaertet: Extractor 1.1.0 projiziert die 26 Spalten von `Indicators results` in identischer Reihenfolge und mit Excel-kompatiblen Status-, Hybrid-, Laufzeit-, Framework-, Result- und Zeitwerten. Eingebettete `IndicatorReportObjects` werden ueber den neuen generischen `supportingTables`-Vertrag als eigenstaendige SI-Ergebnisblaetter erhalten und durch das vorhandene Result-Feld verlinkt; React enthaelt weiterhin keine Quellformatlogik. Die doppelte Source-Table-ID bei HTML mit bereits dekodierten Tabellen wurde durch explizit kollisionsfreie Tabellenindizes behoben. Synthetische Regressionen pruefen 26 Hauptspalten, Result-Verweis, Detailkopf/-zeile, Excel-Zeitformat und kanonische Result-Verknuepfung. Die beiden ausdruecklich freigegebenen Dummyberichte wurden read-only gegengeprueft: 119/119 Hauptzeilen, alle nicht-prosaischen Hauptfelder sowie alle 20 Detailtabellen einschliesslich jeder Kopfzeile und Zelle stimmen ueberein; Inhalte wurden weder als Fixture uebernommen noch dauerhaft protokolliert, temporaere Pruefartefakte wurden entfernt. Gesamtlauf 750 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzmigration; Phase 13A bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Severity-Verteilung um den unbezeichneten CIS-CAT-Anteil ergaenzt: Der bisher nur als dunkle Trackflaeche sichtbare Rest wurde am freigegebenen Dummy-Timeslot fachlich geprueft. Von 413 Datensaetzen ohne Severity stammen exakt 411 aus CIS-CAT und 2 aus Maester. Nur die 411 CIS-CAT-Datensaetze erscheinen deshalb als eigener neutralgrauer Abschnitt `CIS-CAT` mit 46 Prozent; die zwei Maester-Datensaetze bleiben ein ehrlicher, winziger unklassifizierter Rest. Die CIS-CAT-Legende fuehrt ueber die vorhandene Scanquellenfacette nach Work, statt einen nicht vorhandenen Severity-Wert vorzutaeuschen. Im Browser wurden Beschriftung `CIS-CAT`, Anzahl 411, Anteil 46 Prozent und die graue Segmentfarbe `rgb(138, 142, 149)` verifiziert. Acht Dashboardtests, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bereits dokumentierte fachfremde PurpleKnight-Extractorfehler im Gesamtlauf bleibt unveraendert; keine Import-, API-, Persistenz- oder Schemaaenderung, Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Dashboard nach Nutzerkorrektur bereinigt: Die Directory-overview-Kachel verwendet keine violett-blaue Akzentkante mehr, sondern rundum die normale gemeinsame 1-px-Kachelkontur. In den Statuskacheln stehen Prozentwerte nur noch zentriert im Donut; ausserhalb bleiben die absoluten Werte fuer Deviation, Passed und Not Run sowie die fachliche Erlaeuterung des Compliance Score. Am freigegebenen Client Dummy wurden ausschliesslich Geometrie- und Elementzustaende verifiziert: Directory overview rundum `rgb(85, 91, 101)` bei 1 px, keine aeusseren Prozentwerte, Donutwerte weiterhin vorhanden. Sieben Dashboard-Regressionspruefungen, Local-only-Sicherheitscheck, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der Gesamtlauf erreichte 748 bestandene und 8 uebersprungene Tests; ein fachfremder PurpleKnight-HTML-Extractor-Test bleibt wegen einer doppelten synthetischen Source-Table-ID rot und wird durch diese reine Dashboardaenderung nicht beruehrt. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Segmentabstand auf Nutzerwunsch vergroessert: Das gemeinsame `--segment-gap` verwendet jetzt 12 px statt 8 px und gilt damit konsistent fuer alle Kachelsegmente. Die Work-Matrix fuehrt denselben Wert in ihrer Spaltenberechnung und eine entsprechend angepasste virtuelle Zeilenhoehe, damit CSS-Layout und Scrollmathematik uebereinstimmen. Im laufenden, ausdruecklich freigegebenen Client Dummy wurden ausschliesslich Geometriesignale geprueft: horizontaler und vertikaler Abstand jeweils exakt 12 px, Kachelbreite weiterhin 320 px. Drei fokussierte Vertragsregressionen sowie der Gesamtlauf mit 748 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitspruefung, Designcheck und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7/12/13A-Reimportzielbindung fuer zusammengefuehrte historische Timeslots korrigiert: Der werkzeugspezifische Reimport verwendet jetzt die Assessment-ID des konkret zu ersetzenden ScanRuns statt pauschal der ersten Assessment-ID des kalendarisch gruppierten Timeslots. Dadurch bleibt die serverseitige fail-closed-Pruefung unveraendert wirksam, ohne gueltige Altimporte abzulehnen, deren vier Scannerlaeufe historisch in getrennten Assessments gespeichert und im Datahub zu einem Tag zusammengefuehrt werden. Zwei UI-Vertragsregressionen und neun HTTP-Reimporttests sind gruen. Am ausdruecklich freigegebenen Client Dummy wurde der Fehler mit dem unveraenderten PingCastle-Original reproduziert und nach der Korrektur bis zur sicheren, vorausgewaehlten Vorschau `Expected replacement source` verifiziert; die Vorschau wurde abgebrochen, kein Reimport abgeschlossen und keine Daten veraendert. Gesamtlauf 748 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Schema- oder Persistenzaenderung; Phasen 7, 12 und 13A bleiben abgeschlossen. |
| 2026-08-25 | Phase-13A-Scanner-HTML-Erweiterung umgesetzt: Neue versionierte Source Extractors lesen PurpleKnight-HTML aus `reportJSON` plus Kategorie-Indikatorzuweisungen und erzeugte Maester-Einzel- beziehungsweise Multi-Tenant-HTML-Berichte aus ihrem eingebetteten Ergebnis-JSON, ohne JavaScript auszufuehren. Originalwerte und Objektpfade bleiben erhalten; HTML-Inhalt wird nur fuer sichere Anzeigewerte in Klartext dekodiert. Script-only-Berichte gelten nach der Formatdekodierung als auswertbar, sobald ein registrierter Extractor FindingCandidates liefert. Synthetische Fixtures und vier End-to-End-Regressionen pruefen Profilwahl, Einzel-/Multi-Tenant-Extraktion, aktive Script-Inhalte, Feldabbildung und kanonische Persistenzprojektion. Der ausdruecklich bereitgestellte PurpleKnight-Dummy wurde nur ueber inhaltsfreie technische Signale erfolgreich gegen Profil und Extractor verifiziert; die bereitgestellte Maester-Datei ist ein Report-Template ohne `Tests` und wird folgerichtig nicht als Ergebnisbericht extrahiert. Gesamtlauf 748 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, Designcheck und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Persistenz- oder Profilversionsaenderung; Phase 13A bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Typografiedichte auf Nutzerentscheidung gezielt teilzurueckgenommen: Inter, H1 56 px, H2 32 px, H3 18 px, H4 16 px, 20-px-Detailtitel und kontinuierlicher Lesetext mit 16 px bleiben unveraendert. Neu getrennte strukturierte Datenrollen setzen Tabellen-, Grid- und Raw-Data-Inhalte auf 14 px; Controls auf 13 px; Labels, Metadaten und Tabellenkoepfe auf 12 px; Badges auf 11 px. Allgemeine Tabellenzellen, Work Grid, Raw Data und Kompatibilitaetstokens verwenden die neuen Rollen, ohne Dashboard-, Importer-, API-, Persistenz- oder Schemaaenderung. Vier fokussierte Testdateien mit 10 Tests sowie der Gesamtlauf mit 744 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-14-Containerverbindung korrigiert: Die Repository-Laufzeit uebernimmt `ASSESSOR_POSTGRES_HOST` in die PostgreSQL-Verbindungszeichenfolge, sodass der App-Container den Compose-Dienst `postgres` statt seines eigenen Loopbacks anspricht. `ASSESSOR_DATABASE_URL` behaelt Vorrang und `127.0.0.1` bleibt der lokale Standard. Docker-Hostname und lokaler Fallback sind synthetisch regressionsgeprueft; Gesamtlauf 735 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Schema- oder Datenmigration; Phase 14 bleibt offen. |
| 2026-08-24 | Phase-7-Segment-/Kachelgrammatik nach Nutzerreferenz anwendungsweit umgesetzt und als Projektvorgabe verankert: gemeinsame Segment- und Kacheltokens fuer Flaeche, Kontur, Radius, Inset, Gap, Schatten, Auswahl und Breiten; flache Gruppencontainer; gleichartige Inhalts-, Aktions- und Hinzufuegekacheln; Statusfarben nur als Akzent; unvollstaendige Zeilen bleiben unstretched. Datahub, Dashboard, Sidebar, Work-TileGrid, DB Structure, Policy Analysis und statische Pathfinder-Karten verwenden den Vertrag. Die verbindliche Nutzerregel verbietet abgeschnittene, geklemmte, ellipsierte oder verborgene Titel, Werte, Labels, Zusatztexte und Aktionen. Dashboardstatuskarten wurden auf 290 beziehungsweise 210 px abgestimmt; Anzahl und Prozentwert stehen getrennt, sodass `Compliance` und Werte wie `453` vollstaendig bleiben. Das Donut-Raster nutzt auf Desktop sechs Spalten und die Matrix verteilt ihre feste Spaltenzahl ueber die volle Segmentbreite. Bei Platzmangel wird Inhalt neu angeordnet oder die Kachel verbreitert beziehungsweise responsiv umgebrochen. Sechzehn fokussierte Layout-/Donuttests und der Gesamtlauf mit 736 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung mit 0 Rohfarben sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Titelhierarchie nach visueller Nutzerkorrektur nachgeschaerft: Trefferlistentitel bleiben 16 px, verwenden aber Medium 500 statt Semibold; der geoeffnete Finding-Titel verwendet eine neue zentrale 20-px-Detailtitelrolle mit Semibold. Finding-Abschnitt 18 px, Matrixkacheln 16 px und die 16-px-Untergrenze fuer Inhalt bleiben unveraendert. Titel brechen nur an Wortgrenzen. Drei fokussierte Typografieregressionen sowie der Gesamtlauf mit 736 bestandenen und 8 uebersprungenen Tests, Local-only-/Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Labels nach Nutzerkorrektur verdichtet: Outcome (`Failed`/`Passed`), Weight, Severity, Category, Score, CIS- und MITRE-Zuordnungen verwenden in Reader und regulaeren Matrixkacheln nun einen zentralen 12-px-Badgetoken statt der bisherigen 13-px-Labelstufe. Farb-, Glyph-, Rahmen-, Reihenfolge- und Statussemantik bleiben unveraendert; inhaltstragender Text wird nicht verkleinert. Fuenf fokussierte Typografieregressionen, 736 Standardtests, Local-only-Pruefung, Designpruefer und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Finding-Typografie nach Nutzerkorrektur verdichtet: Der Reader-Titel und die Finding-Abschnittsueberschrift verwenden jetzt die bestehende H3-Rolle mit 18 px statt H2 mit 32 px; Titel in Trefferlisten und regulaeren Matrixkacheln verwenden die H4-Rolle mit 16 px statt der bisherigen 18-px-Heading-Rolle. Lange Scannerbezeichnungen beanspruchen damit weniger Zeilen, waehrend inhaltstragender Text die verbindliche 16-px-Untergrenze behaelt. Die Aenderung betrifft ausschliesslich bestehende Work-Selektoren; globale Seitentitel, Pathfinder-Micro-Cards, Daten-, Import- und Persistenzlogik bleiben unveraendert. Zwei neue Typografieregressionen, 735 Standardtests, Local-only-Pruefung, Designpruefer und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Donut-Innenraum nach visueller Nutzerpruefung korrigiert: Zahl, Prozentzeichen und vorhandener Unterwert bleiben unveraendert im Ring, duerfen seine Kontur aber nicht beruehren. Die Zahl ist unabhaengig von der Einheit geometrisch zentriert; dreistellige Prozentwerte erhalten eine automatische Kompaktstufe. Fuer die kleineren Sidebar-Ringe sind Wert, Einheit und Einheitenabstand ueber eigene gemeinsame Tokens reduziert. 13 fokussierte Donut-, Sidebar- und Datahub-Regressionen, Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Filter-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Donutstandard nach Nutzerreferenz vereinheitlicht und verbindlich dokumentiert: Datahub-Statuskarten und Sidebar-Severity-Karten verwenden statt offener 270-Grad-Gauges nun vollstaendige neutrale Ringspuren mit farbigem Uhrzeigersinnbogen ab 12 Uhr, flachen Enden und mittigem Prozentwert samt kleiner Einheit; der absolute Wert bleibt als dezente Sekundaerinformation erhalten. Dashboard-Statusringe verwenden dieselbe Spur und Strichstaerke. Die mehrteilige Risk-Severity-Verteilung behaelt ihre fachlichen Segmente, uebernimmt aber Geometrie, Spur, Strichstaerke, Startposition und zentrierte Prozentdarstellung. 730 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, Filter-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Typografiesystem vereinheitlicht und als verbindliche Projektvorgabe verankert: Inter Variable wird ausschliesslich lokal gebuendelt und ersetzt abweichende System- und Display-Schriften. Zentrale semantische Rollen definieren H1 bis H4, Fliesstext, UI-Labels, Metadaten, Tabellenkoepfe und Buttons; Uppercase ist auf Tabellenkoepfe und kurze technische Kennzeichnungen begrenzt. Datahub, Bereichsheader, Mandantendetail, Tabellen, Controls, Raw Data und Kennzahlen verwenden die gemeinsame Hierarchie. 730 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Designkonflikte bereinigt: Mandantenkarten und die gemeinsam verwendeten Data-/Pathfinder-Tiles tragen weder regulaere noch Hover-Schatten und verwenden keinen Hover-Lift; Interaktion bleibt ueber Haarlinie und Hintergrund sichtbar. Redundante Pathfinder-Null-Ueberschreibungen wurden entfernt, Radius-/Control-Verweise auf vorhandene Tokens vereinheitlicht, die dynamische Dashboard-Segmentbreite erhielt einen CSS-Fallback und berechnete Result-Spaltenbreiten bleiben als erlaubte Geometrie gekapselt. Die Schattenobergrenze fuer `legacy-views.css` wurde von sechs auf drei abgesenkt. 728 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-Sicherheitspruefung, vollstaendiger Designcheck mit 0 Rohfarben sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-13A-HTML-Import gegen den reproduzierten 30-Sekunden-Abbruch mittelgrosser Scannerberichte nachgehaertet: Die gemeinsame Browser-/Node-Umschaltung verwendet den bereits begrenzten lexikalischen HTML-Extraktor nun ab mehr als 1 MiB statt erst oberhalb von 4 MiB. Worker-Timeout und Ressourcenlimits bleiben unveraendert. Ein synthetischer 1,6-MiB-PingCastle-Bericht bestaetigt Format, Profil, Tabelleninhalt und `html-bounded-extraction`; 30 fokussierte Parser-/Worker-/PingCastle-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen, keine API-, Persistenz-, Schema- oder Profilversionsaenderung; Phase 13A bleibt abgeschlossen. |
| 2026-08-24 | Phase-7-Dashboard-IOE-Kennzahl als Filtereinstieg umgesetzt: `IOEs found` ist bei vorhandenem Trefferbestand anklickbar, setzt bestehende Dashboardfilter zurueck, uebergibt exakt die als explizite `IOE Found`/`IOEs found` gezaehlten Datensatz-IDs an die vorhandene Work-Teilmenge und oeffnet Work. Bei null Treffern bleibt das Steuerelement deaktiviert, damit kein ungefilterter Bestand erscheint. Zehn fokussierte Dashboard- und Filtertests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Ringspur nach Nutzerreferenz sichtbar gemacht: Der bislang mit dem Panel verschmelzende ungefuellte Anteil der oberen Statusringe verwendet nun den vorhandenen neutralgrauen Donut-Rahmentoken; Farbbogen, Geometrie, Werte und Interaktionen bleiben unveraendert. Sieben fokussierte Dashboardtests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Statusleiste nach Nutzerreferenz korrigiert: Die sechs gleichartigen Donutkarten sind durch eine fuenfteilige Leiste ersetzt. Compliance Score erhaelt den grossen Ring mit Formelhinweis; Deviation, Passed und Not Run verwenden kompakte Ringe mit realer Anzahl und Prozentwert. Not Applicable und Error stehen gemeinsam in einer Zusammenfassung neben `IOEs found`. Der IOE-Wert zaehlt ausschliesslich explizite `IOE Found`-/`IOEs found`-Quellenfelder und wird nicht aus Deviations abgeleitet; Statuskarten bleiben direkte Filtereinstiege in Work. 14 fokussierte Dashboard-, Donut- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Risk-Profile-Selektor um `Full Risk Profile` erweitert: Dieser Modus umfasst alle aktiven Findings, zeigt links statt Kategorien die real vorhandenen Werkzeuge mit ueber mehrere Zeitstaende aggregierten Findingzahlen und berechnet Severity-Ring, Marked-Zahl und Deviation-Nenner ueber den Gesamtbestand. Ein Werkzeugklick oeffnet Work mit genau diesem Quellenfilter; Werkzeugprofile behalten links ihre eigenen Kategorien. PingCastle bleibt beim ersten Oeffnen der Standard, sofern vorhanden. 18 fokussierte Dashboard-, Facetten- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-PingCastle-Risk-Profile um explizite Nullkategorien korrigiert: Die vier feste Scanner-Skala Anomalies, Stale Objects, Privileged Accounts und Trusts wird aus den strukturierten `risk.*`-Environment-Beobachtungen aufgebaut und filtert Nullwerte nicht mehr weg; `Trusts 0` bleibt damit sichtbar. Aeltere Importe ohne Risk-Observations fallen auf die werkzeugbezogenen Facettenzaehler zurueck, behalten aber alle vier Zeilen. Environment Snapshot wird fuer Directory Overview und Risk Profile gemeinsam einmal geladen. 15 fokussierte Dashboard- und Facettentests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Risk-Profile werkzeugbezogen korrigiert: Die bisherige statische Panelueberschrift ist ein klickbarer Tool-Selektor fuer PingCastle, PurpleKnight, CIS-CAT, Maester und alle weiteren real vorhandenen Scanquellen. Mehrere Zeitstaende desselben Werkzeugs werden zu genau einer Auswahl gruppiert; PingCastle ist der Standard, wenn vorhanden. Kategorien, Severity-Ring, Legendenzahlen, Marked-Zahl und Deviation-Nenner werden ausschliesslich aus den Datensaetzen des gewaehlten Werkzeugs neu gezaehlt. Kategorie- und Severity-Klicks uebergeben Werkzeug plus Auswahl gemeinsam an Work. 17 fokussierte Dashboard-, Facetten- und Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Unterzeile nach Nutzerreferenz korrigiert: Directory Overview zeigt vier getrennte Coverage-Kennzahlen oberhalb eines festen vierspaltigen Faktenrasters; die bisherigen Coverage-Chips und die wiederholte Summenzeile entfallen. Das rechte Panel ist nun ein Risk Profile mit `Marked for report` im Kopf, den vier staerksten realen Kategorien links sowie einem segmentierten Severity-Ring und Legende rechts. Kategorien und Severity bleiben direkte Filtereinstiege in Work; bei fehlenden Facetten erscheinen ehrliche Leerzustaende. Sieben fokussierte Dashboard-/Inset-Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard-Scanquellen nach Nutzerkorrektur gekuerzt: Die Legende der Scan Source Distribution entfernt ausschliesslich einen abschliessenden gueltigen ISO-Tag beziehungsweise ISO-Zeitstempel aus `Werkzeug · Zeitstempel`; Werkzeugname, interner Facettenwert, Provenienz und Filter-Sprung nach Work bleiben unveraendert. Drei fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-24 | Phase-7-Dashboard nach Nutzerreferenz als kompaktes Analyseboard neu geordnet: Der bestehende Donut-Standard zeigt Compliance Score sowie reale Statuszahlen fuer Deviation, Passed, Not Applicable, Not Run und Error; Statuskarten bleiben direkte Filtereinstiege in Work. Severity und Scanquellen erscheinen als zweispaltige segmentierte Verteilungen mit anklickbarer Legende, Directory Overview und Reportmarkierung bilden die untere Informationszeile. Der verbindliche 20-px-Panelinset und 16-px-Inhaltstext bleiben erhalten; keine erfundenen Kennzahlen, keine Import-, API-, Persistenz- oder Schemaaenderung. Neun fokussierte Layout-/Donut-/Inset-Tests sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Gesamtlauf: 721 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; ein fachfremder CRLF-sensitiver Quelltexttest in `results-browser-timeslot-scope.test.ts` bleibt rot. Der bekannte Designcheck bleibt an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Phase 7 bleibt abgeschlossen. |
| 2026-08-24 | Phase-13C-PingCastle-Environment-Subjects nachgehaertet: Profil 1.4.0, Mapping 1.2.0 und Extractor 2.1.0 verwenden normalisierte PingCastle-Berichtsnamen und Punktpfade fuer jeden sichtbaren Environment-Unterpunkt. Dazu gehoeren unter anderem `domain-information.entra-id-configuration`, die User-/Computer-Analysen, Admin-Groups-/Control-Paths-Unterpunkte, Trusts, PKI, alle Infrastructure-, Anomalies-, Password-Policies- und GPO-Unterpunkte. Leere Tabellen werden ueber Row Count/Presence, tabellenlose H2-Bereiche ueber eine quellentreue Presence-Beobachtung sichtbar; Backup, LAPS, WEF und krbtgt sind entsprechend dem Bericht unter Anomalies korrigiert. Finding-Regeldetailbereiche bleiben ausgeschlossen und unbekannte Tabellen behalten `pingcastle-table-row`. Ein ausschliesslich temporaerer, danach entfernter Read-only-Test gegen den ausdruecklich freigegebenen Dummy-Bericht bestaetigte 48 hierarchische Unterpunkt-Typen; persistierte Inhalte wurden nicht veraendert. 47 fokussierte synthetische Tests, Local-only-Sicherheitspruefung und Client-/Server-Produktionsbuild erfolgreich. Gesamtlauf: 718 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; ein fachfremder CRLF-sensitiver Quelltexttest in `results-browser-timeslot-scope.test.ts` bleibt rot. Der Designcheck bleibt an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine API-, SQL- oder Migrationsaenderung; bestehende PingCastle-1.3.0-Importe benoetigen einen Reimport. Phase 13C bleibt in Arbeit. |
| 2026-08-24 | Phase-7/12/13A-Reimportidentitaet fail closed nachgehaertet: Ein zielgebundener Scanner-Reimport akzeptiert nur noch das exakte SHA-256-Multiset aller Dateien des zu ersetzenden ScanRuns. Preview prueft die hochgeladenen Bytes vor Parsing und Persistenz; Complete prueft die final ausgewaehlten Vorschauobjekte erneut; Local- und PostgreSQL-Repository erzwingen die Invariante bei kanonischem Ersatz und bei der Uebernahme eines bereits importierten Ersatzlaufs. Fehlende Originalhashes, abweichende Bytes, fehlende oder zusaetzliche Dateien sowie der nicht verifizierbare Offline-Fallback werden mit eindeutiger Fehlermeldung abgelehnt; der alte Scan bleibt aktiv. Datahub bietet einen vorhandenen Ersatzlauf nur bei Hashgleichheit an, und der Reimportdialog akzeptiert keine bloss wahrscheinliche Dublette mehr. 31 fokussierte synthetische Tests und der vollstaendige Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 718 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die Reimportaenderung erzeugt keinen neuen Designbefund. Keine Migration, keine Realdaten gelesen oder mutiert; Phasen 7, 12 und 13A bleiben abgeschlossen. |
| 2026-08-24 | Phase-7/12-Datahub-Readiness auf mandantenweite Vergleichsbereitschaft korrigiert: Die Kachel fasst nicht mehr nur den neuesten `Open`-Timeslot zusammen, sondern alle aktiven scannergebundenen Timeslots. Sobald irgendein aktiver Altstand einen Reimport auf den aktuellen ASSESSOR-Verarbeitungsvertrag benoetigt, erscheint der Mandant gelb und `Manage` dauerhaft; inkompatible oder unbekannte Vertraege bleiben rot. `Manage` klappt saemtliche betroffenen Timeslots automatisch auf, auch wenn sie weder aktuell noch ausgewaehlt sind; `Open` oeffnet weiterhin den neuesten Timeslot. Damit kann ein aktueller neuer Stand einen fuer spaetere Lifecycle-Vergleiche relevanten Altstand nicht mehr gruen ueberdecken. Zwoelf fokussierte Datahub-Tests sowie Client-Bundle und Server-Produktionsbuild erfolgreich; Gesamtlauf 715 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der vollstaendige Client-Typecheck ist durch zwei parallele Pathfinder-Typfehler in `ObsidianGraphView.tsx` blockiert; der bekannte Designcheck bleibt nur an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 und 12 bleiben abgeschlossen. |
| 2026-08-24 | Phase-7-Kopfbereich um den dauerhaft sichtbaren ASSESSOR-Verarbeitungsstand erweitert: Unter dem Markennamen erscheint ausschliesslich die zentrale Processing-Version, aktuell `1.3.0`, ohne `Version`, `v` oder weiteren Begleittext. Die Anzeige verwendet `CURRENT_ASSESSOR_PROCESSING_VERSION` aus dem Processingvertrag und ist bewusst von der technischen npm-Paketversion getrennt. Kompakte Metadaten-Typografie und tabellarische Ziffern veraendern Logo, Navigation und Kopfgeometrie nicht. Fuenf fokussierte Header-/Versionsregressionen sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 712 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die Versionsanzeige erzeugt keinen neuen Befund. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Reimport-Hinweispanel fachlich praezisiert: Ueberschrift und Einleitung benennen jetzt ein neues internes `ASSESSOR processing profile` statt eines unspezifischen Processing-Updates. Die laufbezogene Erklaerung zeigt den Versionswechsel als `1.2.0 → 1.3.0`, erklaert die zusaetzliche Environment-Context-Erfassung und sagt ausdruecklich, dass der PingCastle-Bericht selbst unveraendert ist. Status-Tooltips verwenden dieselbe ASSESSOR-Verantwortungsgrenze. Acht fokussierte Datahub-, Readiness- und Reimport-Texttests sowie vollstaendiger Client-/Serverbuild erfolgreich; keine Parser-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-23 | Phase-7/12/13A-Reimportdialog semantisch entwirrt: Ein identischer Bericht erscheint im zielgebundenen Ersatzworkflow nicht mehr als gelbes `Duplicate`, sondern gruen als `Expected replacement source` mit ausdruecklichem Hinweis, dass die Uebereinstimmung erwartet ist. Exakte und wahrscheinliche Ersatzquellen erhalten getrennte positive Erklaerungen; die Datei bleibt vorausgewaehlt, der Hauptbutton lautet `Reimport and replace`, und der Erfolgsbericht spricht von abgeschlossenem Replacement statt von gefundenen Dubletten. Der normale Import behaelt seine bisherige Dublettenwarnung und Abwahl. 20 fokussierte Dialog-, Auswahl-, Readiness- und HTTP-Tests, 705 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie vollstaendiger Client-/Serverbuild erfolgreich. Nur der bekannte globale Designcheck fuer `datahub-redesign.css` Zeilen 39/42 bleibt rot. Keine Parser-, API-, Schema-, Persistenz- oder Realdatenaenderung. |
| 2026-08-23 | Phase-13C-Versionsvertrag nach realer inhaltsfreier Laufzeitdiagnose korrigiert: Fuenf aktive PingCastle-Laeufe besassen trotz aktueller Anzeige null ReportSections und null EnvironmentObservations; der aktuelle Parser erzeugte aus der bereitgestellten Quelldatei dagegen 17 Abschnitte und 1.501 Beobachtungen. Ursache war kein Parser- oder Result-DB-Fehler, sondern ein unter Profil 1.2.0 nicht unterscheidbarer Import durch einen aelteren Backendstand. PingCastle 1.3.0 ist nun der erste eindeutig aktuelle Environment-Context-Vertrag; 1.2.0 bleibt historisch, wird automatisch `reimport-recommended` und verwendet weiterhin denselben Finding-Kompatibilitaetsschluessel. 33 fokussierte Tests und der vollstaendige Client-/Serverbuild erfolgreich; Gesamtlauf 704 bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only gruen. Nur der bekannte Designcheck in `datahub-redesign.css` Zeilen 39/42 bleibt rot. Der Entwicklungsstarter wechselte automatisch auf den neuen Backendrelease; die Live-Facette weist alle vorhandenen PingCastle-Resultate jetzt als reimportbeduerftig aus. Keine realen Inhalte gelesen oder ausgegeben und keine Scandaten mutiert; der Nutzer muss den betroffenen Bericht einmal mit Profil 1.3.0 reimportieren. Phase 13C bleibt in Arbeit. |
| 2026-08-23 | Phase-13C-Environment-Daten in die Unified Result DB integriert: `EnvironmentObservation` wird als eigener Result-Typ `environment-observation` neben Findings und Policy-Ergebnissen projiziert. Local- und PostgreSQL-Readmodelle, Same-Origin-Listen-/Facetten-/Detail-API, Clientquery und Result-DB-Oberflaeche liefern Property, Subject, Erfassungszustand, Original-/Normalwert, Abschnitt, Locator sowie Import-, Profil- und Mappingprovenienz. Eigene Environment-Facetten sind filterbar; Severity, IOE, Abweichung und Review werden nicht als Environment-Fachaussage dargestellt. Keine neue Migration, da die Projektion auf Migration 018 aufsetzt. 36 fokussierte synthetische Tests und der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich; Gesamtlauf 703 bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only gruen. Nur der bekannte Designcheck fuer `datahub-redesign.css` Zeilen 39/42 bleibt rot. Keine realen Scan-Inhalte gelesen oder Daten migriert; bestehende Altimporte benoetigen weiterhin einen erfolgreichen Reimport, bevor Environment-Resultate vorhanden sind. Phase 13C bleibt bis zur realen PostgreSQL-Laufzeitintegration in Arbeit. |
| 2026-08-23 | Phase-10-Server-Readiness im lokalen Entwicklungsbetrieb nachgehaertet: `npm run dev` fuehrt einmalig den Server-Typecheck aus, betreibt danach einen Vite-Watch-Build und startet den Client erst nach einem Health-Nachweis fuer exakt die SHA-256-Release- und zufaellige Entwicklungsinstanzkennung des gebauten Backends. Erfolgreiche Server-Rebuilds wechseln den eigenen Backendprozess geordnet; fehlgeschlagene Builds lassen den letzten gesunden Prozess aktiv. Eine kleine Laufzeitdatei unter `node_modules` erlaubt nach einem Starterabbruch ausschliesslich die Rueckforderung des exakt ausgewiesenen Entwicklungsprozesses, waehrend fremde oder inkompatible Portbelegung fail closed bleibt. Praktischer Watch-Test: PID 5068 wurde nach Buildsignal automatisch durch PID 18240 ersetzt, anschließend Frontend und Backend HTTP 200. 25 fokussierte und 698 Standardtests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an `datahub-redesign.css` Zeilen 39/42 rot. Keine Scan-, Schema-, Migrations- oder Persistenzdaten geaendert; Phase 10 bleibt abgeschlossen. |
| 2026-08-23 | Reimport-Nachhaertung nach reproduziertem Versionskonflikt zwischen aktuellem Frontend und seit 19:09 Uhr laufendem, vor dem aktuellen Serverbundle gestarteten Backend: Die Preview-API spiegelt das exakte `replacesScanRunId` vor jeder Persistenz zurueck, der Client bricht bei fehlender oder abweichender Bestaetigung vor dem Commit ab und kontrolliert auch die Abschlussantwort. Fuer den bereits als normaler zweiter Scan gespeicherten Sonderfall bietet der Datahub einen expliziten Weg, den neueren bereiten Scan desselben Werkzeugs im selben Timeslot ohne erneuten Upload und ohne Loeschung als auditierbaren Ersatz zu uebernehmen; Local- und PostgreSQL-Repository verknuepfen beide aktiven Laeufe atomar und pruefen Mandant, Timeslot, Werkzeug, Aktivstatus und Zeitfolge. 22 fokussierte sowie 693 Standardtests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen; Local-only-Sicherheitspruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der bekannte Designcheck bleibt ausschliesslich an `datahub-redesign.css` Zeilen 39/42 rot. Keine realen Scan-Inhalte gelesen oder veraendert; die Reparatur bleibt eine explizite Nutzeraktion. Phase 7/12/13A-Status unveraendert. |
| 2026-08-23 | Phase-7/12/13A-Reimportworkflow umgesetzt: Jeder Scanbericht kombiniert seine bisherige Viewability mit dem versionierten Processingvertrag; ein erforderlicher Reimport erscheint nicht mehr gruen als `Recognized`, sondern rot als `Reimport required`. Unter jedem betroffenen Timeslot steht ein kompaktes Erklaerpanel mit Profilstand und eigener `Reimport <Tool>`-Aktion. Da normale Scanneroriginale bewusst nicht gespeichert werden, fordert die Aktion den Original-Dateisatz erneut an, bindet Vorschau und Abschluss an Mandant, Timeslot und aktiven ScanRun und lehnt Werkzeug- oder Zielabweichungen ab. Der neue ScanRun supersediert den alten innerhalb derselben Repositorymutation; der Vorgaenger samt Findings und Vergleichen bleibt auditierbar, wird aber aus aktiven Datahub-, Work-, Result- und Environment-Projektionen ausgeblendet. 38 fokussierte API-, Repository-, HTTP- und UI-Tests sowie der Gesamtlauf mit 692 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-Sicherheitspruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der Designcheck bleibt ausschliesslich an den zwei bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine Realdaten gelesen, geloescht oder reimportiert; keine Migration erforderlich, reale PostgreSQL-Laufzeitpruefung blieb offen. Phase 7 und 12 bleiben abgeschlossen, Phase 13A bleibt abgeschlossen. |
| 2026-08-23 | Phase-7/12-Datahub-Hinweisfuehrung nachgeschaerft: `Reimport recommended` ist nun in Kachelpunkt, Scanstatus und Erklaerpanel gelb; Rot bleibt ausschliesslich `Incompatible` und `Unknown` vorbehalten. Bei Update oder Fehler ist `Manage` auch ohne Auswahl dauerhaft sichtbar und statusbezogen dezent umrandet. `Manage` klappt alle betroffenen Timeslots automatisch auf, damit Erklaerung und Reimportaktion unmittelbar sichtbar sind; mehrere Hinweise koennen gleichzeitig offen sein. Statuslogik, Reimportvertrag und Bestandsschutz bleiben unveraendert. Zwölf fokussierte Datahub-Tests und Server-Produktionsbuild erfolgreich, Local-only gruen; Gesamtlauf 705 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und ausschliesslich durch eine parallele Pathfinder-Regression in `obsidian-graph.test.ts` blockiert. Der Client-Typecheck ist ebenfalls durch parallele unvollstaendige `ObsidianGraphView.tsx`-Aenderungen blockiert. Der bekannte Designcheck bleibt nur an den unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; die neue Hinweisgestaltung erzeugt keinen weiteren Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 und 12 bleiben abgeschlossen. |
| 2026-08-23 | Phase-7-Datahub-Processingindikator als deutliches Eckelement nachgeschaerft: Rot und Gruen verwenden nun denselben 14-px-Kreis mit 4 px Abstand zur oberen und linken Kartenkante und sitzen damit sichtbar in der 8-px-Kartenrundung. Statuslogik, ARIA-Label, Tooltip, Kachelgeometrie und Bedienung bleiben unveraendert. Die statische Layoutregression sichert Groesse und tokenisierten Eckabstand. Fokustest und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 705 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der Gesamtskriptstatus bleibt ausschliesslich am bekannten Designcheck fuer die unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; der Indikator erzeugt keinen neuen Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Datahub-Mandantenkacheln um einen kleinen Processing-Readiness-Punkt links oben erweitert. Die Anzeige verwendet den bestehenden versionierten Processingvertrag und ausschliesslich den neuesten scannergebundenen, ueber `Open` erreichbaren Timeslot: `Current`/`Compatible older` erscheinen gruen, `Reimport recommended`/`Incompatible`/`Unknown` rot; Mandanten ohne Scannerstand zeigen keinen Punkt. Historische Altstaende halten einen aktuellen Mandanten nicht rot. ARIA-Label und Tooltip ergaenzen die Farbaussage. Sieben fokussierte synthetische Tests, 689 bestandene Standardtests, Local-only-Pruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der Designcheck bleibt ausschliesslich an den zwei bereits bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot; der neue Punkt erzeugt keinen weiteren Befund. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kacheln als eigenstaendiges Designelement `Pathfinder Micro Card` formalisiert, ohne die bestaetigte Darstellung zu veraendern: wrapperfreie Finding-/Relation-Varianten, Category als groessere Relation-Auspragung, unveraenderte Masse 240x176, 148x72 und 196x116 sowie gemeinsamer Graphfaktor 0,4. Titel 16 px, Finding-Badges 11 px, Relation-Badges 12 px, Aktionen 10 px und bestehende 8-/6-px-Aktionsradien sind nun eigene Tokens. Der optionale Extract-View-Ref ist typkorrekt, rohe Schwarz-/Weisswerte und `!important` wurden wertgleich durch Tokens und lokale Selektorspezifitaet ersetzt. 11 fokussierte Pathfinder-/Connector-/TileCard-Tests, 685 bestandene Standardtests, Local-only-Pruefung und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der Designcheck ist fuer `obsidian-graph.css` gruen und bleibt ausschliesslich an den zwei bekannten Schattenregeln in `datahub-redesign.css` Zeilen 39/42 rot. Keine Import-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase 13C begonnen und PingCastle-Environment-Context vertikal umgesetzt: vollstaendige quellengetreue HTML-Abschnitte und Tabellen, XML-Hierarchie, typisierte AD-/PKI-/OS-/Trust-/LAPS-/Backup-/WEF-/krbtgt-/Scannerbeobachtungen, explizite Erfassungszustaende, kanonische Persistenz, Migration 018, Local-/PostgreSQL-Repositories, Projekt-Export, scanlaufgebundene Environment-Snapshot-API/Client und Dashboard-Overview. 43 fokussierte synthetische Tests sowie Server-TypeScript erfolgreich. Gesamtlauf: 684 Tests bestanden und 8 optionale PostgreSQL-Tests uebersprungen; anschliessend blockiert nur der vorbestehende Designcheck durch rohe Farbwerte in `obsidian-graph.css`. Der Produktionsbuild bleibt durch zwei vorbestehende TypeScript-Fehler in `ObsidianGraphView.tsx` blockiert; reale PostgreSQL-Integration fuer Migration 018 bleibt offen. Keine Realdaten gelesen oder migriert; bestehende Importe benoetigen einen Reimport, um den neuen Kontext zu erhalten. |
| 2026-08-23 | Phase-7-Pathfinder-Kachelpositionen von Kamera und Viewport entkoppelt. Die bisherige freie Bildschirmseitenwahl, Randklemmung und viewportgebundene Kollisionsverschiebung ist entfernt; Kachelseite, Abstand und vertikale Ausweichposition werden nun ausschliesslich im Graphkoordinatensystem aus Knotenlage, Graphmitte und stabiler Pin-Reihenfolge bestimmt. Beim Ein-/Ausklappen der Hauptsidebar verschieben sich daher Punkt und Kachel nur noch gemeinsam als Graph, ohne dass die Kachel zum Panelrand rutscht. Dummy-Browserpruefung mit zwei Maester/Intune-Findings: Graphflaeche beim Sidebar-Wechsel von 1670,89 auf 1888,88 px verbreitert und um 217,98 px verschoben, beide Kacheltransformationen blieben bytegleich und beide relativen Punktabstaende bis auf unter 0,001 px Rundungsdifferenz identisch. Drei fokussierte Tests sowie 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot; der Produktionsbuild ist weiterhin durch parallele, fachfremde TypeScript-Fehler in `tests/persistence/assessor-repository.test.ts` blockiert. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Badges korrigiert: Die starre halbe Spaltenbreite und der feste 40-px-Badgebereich entfallen. Status-, Kategorie- und Severity-Labels verwenden innerhalb der unveraenderten 240-mal-176-px-Findingkachel nun den kompakten 11-px-Standardtoken `--fs-micro`, ihre tatsaechliche Inhaltsbreite und bei Bedarf weitere Zeilen in den vorhandenen freien Raum nach unten; der 16-px-Findingtitel bleibt unveraendert. Dummy-Browserpruefung an beiden `Maester/Intune`-Findings bestaetigt vollstaendige Labels `Failed`, `Maester/Intune` und `Medium`, jeweils `scrollWidth <= clientWidth`, innerhalb der Kachel und mit unveraenderter Kachelgroesse. Neun fokussierte Tests sowie 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot; der Produktionsbuild ist aktuell durch parallele, fachfremde TypeScript-Fehler in `tests/persistence/assessor-repository.test.ts` blockiert. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Verbindliche Processing-Version-Nachhärtung für Phasen 5/6/8/9/12/13A umgesetzt: getrennte Profil-, Mapping-, Normalisierungs- und Darstellungsstände, append-only Kompatibilitätsmanifest, kanonischer Kompatibilitätsschlüssel, Import-/Repository-Barrieren, fail-closed Vergleich und sichtbarer Readiness-Status. PingCastle 1.2.0 persistiert nun korrekt Profil 1.2.0 bei weiterhin fachlichem Mapping/Normalisierung 1.1.0; technische Einzelstände bleiben in der Result-DB-Provenienz, die doppelten Hauptfilter entfallen zugunsten von Processing Status. Historische Daten wurden nicht umgeschrieben. 677 Standardtests bestanden, 8 optionale PostgreSQL-Tests übersprungen, Local-only und vollständiger Client-/Serverbuild erfolgreich. Der bekannte Designcheck bleibt ausschließlich an den vorbestehenden Schattenregeln in `datahub-redesign.css` 39/42 rot; keine reale PostgreSQL- oder Reimportmutation ausgeführt. |
| 2026-08-23 | Pathfinder-Kacheln in eine eigene oberste SVG-Ebene verschoben und ihre Mehrfachplatzierung abgesichert. Karten waehlen automatisch die raeumlich groessere Punktseite, halten etwa 15 px Bildschirmabstand, werden innerhalb der Graphflaeche geklemmt und bei Kollisionen abwechselnd vertikal versetzt. Der Kachelinhalt besitzt feste Titel-, Zwei-Zeilen-Badge- und Aktionsbereiche; bei mehr als vier Badges bleiben Status sowie fachlich wichtige Werte sichtbar und der Rest erscheint als `+N`. Dummy-Browserpruefung mit sieben gleichzeitig gepinnten CIS-Findings: Ebenenfolge Kanten, Knoten, Karten; null Kartenueberschneidungen, null Randverletzungen, alle Karten links oder rechts ihres Punkts, vier sichtbare vollstaendige Badges in zwei Zeilen und kein abgeschnittenes Kindelement. Neun fokussierte Tests, der Gesamtlauf mit 673 bestandenen und 8 uebersprungenen Tests, Local-only sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Der bekannte Designcheck bleibt nur an `datahub-redesign.css` 39/42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Pathfinder-Kachel anhand der expliziten Positiv-/Negativbildreferenz neu festgelegt: Finding-Kachel als vollstaendige 240-mal-176-px-Vorlage mit fuenf Titelzeilen, Status, Gewicht, CIS-Hierarchie-Badges, Bookmark und Results; Rollenkachel bleibt eine eigene 148-mal-72-px-Vorlage. Beide werden mit einem unveraenderlichen Faktor 0,4 in Graphkoordinaten eingebettet und zoomen danach als geschlossene Komposition. Die zwischenzeitliche 148-mal-72-px-Findingverdichtung und das Auslassen der CIS-Badges sind damit ersetzt. Dummy-Browserpruefung am Finding `18.10.18.3`: auf der Referenzzoomstufe rund 211 mal 154 px, fuenf Badges, zwei Aktionen und null ausserhalb liegende Kindelemente; ein Zoomschritt skaliert Flaeche, Titel, Badgebereich und Aktion jeweils exakt mit Faktor 1,2. Acht fokussierte Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 671 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Textuelle Verbindungsanzeige im gesamten Bereichsheader durch zwei kompakte quadratische Zustandsfelder ersetzt und direkt vor den Clientnamen gesetzt. Gruen markiert die bestaetigte Serververbindung, Rot fehlende beziehungsweise noch ungepruefte Verbindung; der inaktive Gegenstatus ist gedimmt. Pillenrahmen und sichtbare Texte wie `Server connected` entfallen, ARIA-Label und Tooltip bleiben semantisch. Dummy-Browsermessung bestaetigt genau eine Anzeige, zwei randlose 9-mal-9-px-Quadrate, voll sichtbares Gruen bei bestehender Verbindung, gedimmtes Rot sowie die direkte Geschwisterreihenfolge vor `Dummy`. Fuenf fokussierte Tests und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 671 bestanden, 8 optionale PostgreSQL-Tests uebersprungen und Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kachelzoom abschliessend auf eine eingefrorene 148-mal-72-px-Komposition umgestellt: Die zuvor eingefuehrte inverse Inhaltskompensation ist entfernt; Kachelflaeche, 16-px-Titel, Hexagon, Status, Gewicht, Aktionen, Abstaende und Konturen zoomen nun gemeinsam wie ein Bild. Redundante CIS-Hierarchie-Badges bleiben in Work und am Finding sichtbar, entfallen aber in der Pathfinder-Kachel zugunsten der bereits verbunden dargestellten CIS-Kategorie-Knoten. Dummy-Browserpruefung fuer `CIS 18.9.29`: keine gerenderten Kindelemente ausserhalb der Kachel, logische Masse konstant 144 mal 68 px innen und nach einem Zoomschritt identische Bildschirm-Skalierung von Kachel, Titel und Symbol mit Faktor 0,8333 bei `transform: none`. 669 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Work-Abstand als verbindlichen Designstandard fuer alle abgerundeten Hauptpanels festgeschrieben: neuer kanonischer Token `--panel-content-inset: 20px` mit bestehendem Alias `--panel-inset`, genau einmal je Root-Inhaltscontainer. Work-Varianten, Datahub, Dashboard, DB Structure, Result DB, Client-Detail und Pathfinder angeglichen; abweichende responsive Reduktionen entfernt. `AGENTS.md` schreibt denselben Wert und die Einmal-Regel auch fuer kuenftige Panels vor. Acht fokussierte Tests, 669 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Pathfinder-Kacheltypografie auf die tatsaechlich sichtbare Groesse der 16-px-Punktbeschriftung korrigiert. Finding- und Rollenkacheln erhalten den inversen Kamerafaktor; Titel, Hexagone, Aktionssymbole, Badges, Abstaende und Konturen bleiben dadurch beim Hineinzoomen kompakt, waehrend die 148-mal-72-px-Kachelflaeche weiterhin proportional mit dem Graphen zoomt. Drei fokussierte Tests, 666 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Aktiven Clientnamen in alle Bereichs-Header aufgenommen: rechtsbuendiger reiner 16-px-Text mit Randabstand, ohne Rahmen oder Hintergrund und bei Platzmangel mit Ellipsis. Work integriert ihn neben der Werkzeugleiste; die anderen Bereiche fuehren ihn als letztes Kopfelement. Der Data-Hub-Detailkopf verwendet auch ohne geladenen Workkontext den konkret verwalteten Clientnamen und faellt nach Verlassen auf den aktiven Client zurueck. Drei fokussierte Tests, 666 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-23 | Phase-7-Pathfinder-Kacheln vereinheitlicht: Finding-Kacheln von 240 mal 176 px auf die 148 mal 72 px der Rollenkachel reduziert und ihre Matrixstruktur Pathfinder-spezifisch verdichtet. Titel in Finding- und Rollenkacheln verwenden nun exakt die 16 px der Textbeschriftung neben den Punkten; die regulaere Matrixansicht bleibt unveraendert. Drei fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Rollenkacheln im Pathfinder von 116 auf 148 px verbreitert und erzwungene Umbrueche innerhalb einzelner Woerter entfernt. Kurze Kategorien wie `Anomalies` bleiben zusammen; lange mehrteilige Titel duerfen weiter an Wortgrenzen innerhalb der bestehenden Zeilenbegrenzung umbrechen. Drei fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Path-Snapshot-Auswahl in Work auf einen separaten temporaeren Finding-ID-Scope umgestellt: Die Auswahl bleibt in Work und zeigt nur die im Pfad enthaltenen Findings, ohne Workspace oder Reviews zu mutieren. Der Pathfinder bleibt ausserhalb seines Bereichs verborgen montiert und bewahrt Kamera, Pins, Auswahl, Kacheln und Anzeigeoptionen; ein Refit erfolgt nur nach einer geaenderten Graphsignatur. Dummy-Browserpruefung bestaetigt `Shown 1` sowie eine exakt unveraenderte Kameratransformation, einen aktiven Punkt und eine sichtbare Kachel nach `Open in Work` und Rueckkehr; QA-Snapshot entfernt und Work auf `Shown 453` zurueckgesetzt. 19 fokussierte Tests, 665 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Fachdatenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Kacheln nach erneuter Nutzerkorrektur proportional an den Graphzoom gebunden und nicht mehr invers bildschirmstabil gehalten. Finding- und Rollenkacheln schrumpfen bei minimalem Zoom mit dem Netz; die Finding-Grundhoehe steigt von 144 auf 176 px, damit die wiederverwendete Matrixkachel keine untere Badgezeile abschneidet. Dummy-Browsermessung: Fit rund 85,72 mal 62,86 px, `scrollHeight = clientHeight` und damit kein interner Beschnitt; bei Zoomminimum rund 19,20 mal 14,08 px. Auswahl und Zoom danach zurueckgesetzt. Drei fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Strukturknoten im Pathfinder einheitlich violett dargestellt: Kategorie-, D3FEND-, Target-, Technik- und Taktikpunkte samt Ring und optionaler Rollenkachel verwenden in Dark und Light exakt `#9333EA`; Finding-Punkte behalten ihre Severity-Farbe. Dummy-Browsermessung bestaetigt `rgb(147, 51, 234)` an 160 Kategorien, sechs D3FEND-Knoten, einem Target und sechs Taktiken sowie weiterhin Critical-Rot am Finding; im aktuellen Stand gab es keine Technik-Knoten. Drei fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Kopf um eine dynamische aktive Filterspur ergaenzt: Bei mindestens einem Nutzerfilter steht rechts neben dem Titel ein gelbes Rechtsdreieck, danach Filtername und Auswahl; mehrere Filter trennt ein gelbes Plus. Suche, sichtbare Facetten, Mehrfachwerte, Wertebereiche und My Workspace stammen direkt aus dem gemeinsamen Filterzustand. Fester Deviation-Scope und ausgeblendete technische Facetten bleiben aus der Spur heraus; ohne Auswahl ist sie unsichtbar. Dummy-Browserpruefung bestaetigt `Severity: Critical + Category: Account Security`, gelbe Marker `rgb(217, 150, 42)`, rund 18 px Titelabstand und den leeren Zustand nach Reset. Sieben fokussierte Tests, 663 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Darstellung in zwei unabhaengige Schalter getrennt: `Labels On/Off` blendet ausschliesslich die Kacheln gepinnter Knoten ein beziehungsweise aus; der neue benachbarte Schalter `Text On/Off` steuert die Punktbeschriftungen und startet standardmaessig auf `Off`. Labels starten auf `On`. Dummy-Browserpruefung bestaetigt beide Defaults, null initiale Punkttexte, eine Kachel nach Auswahl, null Kacheln nach `Labels Off` und 626 Texte nach `Text On`; danach wurden die Defaults wiederhergestellt. Drei fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Pathfinder-Quellenwahl auf den gemeinsamen Work-Filter umgestellt: Der technische Quellblatt-Selector und seine `Source`-Beschriftung entfallen; `Source: Scan` ist als vorhandene dynamische Facette mit Scanner, Scanzeitpunkt und Trefferzahlen sichtbar. Gemeinsamer AppProvider-Zustand, Filterengine und Reset bleiben unveraendert. Dummy-Browserpruefung: genau eine Source-Scan-Facette, fuenf Optionen, keine separate Blatt-Combobox; eine Auswahl reduziert den Graphen von 626 auf 466 Knoten und wurde danach auf `All` zurueckgesetzt. Zwoelf fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphbereich sichtbar in `Pathfinder` umbenannt: Sidebar-Navigation und grosse Bereichsueberschrift verwenden denselben Namen; der interne `graph`-Schluessel und damit Navigation, Styles, Path Snapshots und Zustand bleiben unveraendert. Dummy-Browserpruefung bestaetigt genau einen Pathfinder-Navigationseintrag, keine alte Graph-Beschriftung, die Pathfinder-Ueberschrift und den weiterhin gerenderten Netzwerkgraphen. Zwei fokussierte Tests, 661 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-CIS-CAT-Results semantisch eingefaerbt: `Criterion`-Zeilen zeigen die konkrete Bestehens-/Sollbedingung gruen; die vom CIS-CAT-Bericht als ausgewertet markierten Istwerte erscheinen als Verstoss rot statt blau. Der bestehende Informationshinweis fuer nicht gefundene Systemelemente bleibt blau. Die CIS-spezifische Erkennung liegt deklarativ im Toolprofil, die gemeinsame Results-Komponente rendert nur `criterion`, `violation` oder `highlight`; Quellwerte und Importmarker bleiben erhalten. Dummy-Browsermessung: Dark Criterion `rgb(23,107,70)`, Verstoss `rgb(152,27,55)`; Light Criterion `rgb(203,239,217)`, Verstoss `rgb(255,212,219)`. 47 fokussierte Tests, 660 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Path-Snapshots umgesetzt: Die Graph-Aktion heisst `Path Snapshot`, bleibt ohne gepinnten Knoten deaktiviert und speichert alle gepinnten Punkte plus ihre direkten Nachbarn. Mehrfachauswahl markiert die inzidenten Kanten aller aktiven Punkte rot. Normale und Path Snapshots teilen im vorhandenen Client-/Timeslot-Scope maximal sieben Plaetze; Path-Eintraege sind in Work rot umrandet. Ein Klick aus Work wendet den gespeicherten View an, wechselt in den Graphen und restauriert die noch vorhandenen aktiven Knoten. Browserpruefung im Dummy bestaetigt Buttonzustand, einen gespeicherten Pfad mit acht roten Direktkanten, rote Work-Kennzeichnung und vollstaendige Wiederherstellung; der temporaere QA-Eintrag wurde entfernt. Elf fokussierte Tests, 658 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Backend- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graph-Panel um die wieder angeforderte Work-Bedienung ergaenzt: Unter den fachlichen Filtern steht `My Workspace` als Checkbox mit demselben `actionOnly`-/Reviewzustand wie Work; ohne markierte Findings ist sie deaktiviert. Direkt darunter rendert der Graph den bestehenden `ViewBookmarks`-Baustein fuer client- und timeslotgebundene Ansichts-Snapshots, ohne zweite Speicher- oder Anwendungslogik. Browserpruefung im Dummy bestaetigt beide Controls sowie Oeffnen und Abbrechen des Snapshot-Dialogs ohne Testartefakt. Sieben fokussierte Tests, 656 Standardtests, Local-only und vollstaendiger Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-CIS-CAT-Hierarchie durchgaengig ergaenzt: Eine gemeinsame profilgebundene Ableitung liest zuerst `Rule ID`, ersatzweise `Benchmark Item` beziehungsweise Titel, und erzeugt aus einer Regel wie `17.2.4` ausschliesslich ihre Eltern `CIS 17` und `CIS 17.2`. Diese Kategorien bilden ringmarkierte Graphbeziehungen, stehen als dynamischer `CIS Category`-Filter zur Verfuegung und erscheinen als Badges im Finding-Kopf sowie auf Matrix-/Graphkacheln. Originalnummer, Originaltitel, Quellwerte und Persistenz bleiben unveraendert. Dummy-CIS-CAT-Browserpruefung: 143 Hierarchieknoten; sichtbarer Filter mit positiven Zaehlern; `CIS 17.2` reduziert den Deviation-Graphen auf vier Findings; Finding `2.2.2` zeigt `CIS 2` und `CIS 2.2`. 36 fokussierte Tests, 656 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphprojektion fachlich auf Abweichungen begrenzt: Der Graph verwendet unabhaengig vom geteilten Work-Status ausschliesslich `deviation`; der dadurch gegenstandslose Result-Status-Selector ist im Graph ausgeblendet. Der bisherige Kategorienfallback vom fehlenden Category-Feld auf `sourceSheet` ist entfernt, sodass Mandant, Quellblatt und `Dummy · All Records` nur Filterkontext bleiben und weder Sammelknoten noch Massenkanten erzeugen. Kategorien, ATT&CK und D3FEND stammen weiterhin aus den Finding-Feldern; explizite Target-/Asset-/Host-/Domain-Felder werden neu als eigene ringmarkierte Target-Beziehungsknoten projiziert. Dummy-Browserpruefung im Aggregat `Dummy · All Records · 885`: null All-Records-Knoten, 453 Deviation-Findings, ein expliziter Target-Knoten und kein Status-Control im Graph. 16 fokussierte Tests, 653 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Zoomverhalten der Graphkacheln auf ausdruecklichen Nutzerwunsch erneut korrigiert und die unmittelbar vorherige proportionale Skalierungsentscheidung fuer Kacheln ersetzt: Finding-Kacheln verwenden nun wie Punktlabels eine inverse Kameraskalierung. Damit bleiben die kompakte Matrixkachel mit 240 mal 144 px und ihr 16-px-Titel bei jeder Graph-Zoomstufe visuell konstant, waehrend Knoten, Kanten und Kartenposition weiterhin mit der Kamera reagieren. Dummy-Browsermessung bestaetigt eingepasst 239,98 mal 144,00 px und auf maximaler Zoomstufe 239,98 mal 144,00 px bei jeweils 16 px Titeltext. Sieben fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln nach Nutzerkorrektur verdichtet und auf Klick begrenzt: Finding- und Rollenkarten erscheinen nicht mehr beim Hover, sondern ausschliesslich bei einem gepinnten Knoten. Die weiterhin direkt wiederverwendete Matrix-`TileCard` besitzt im Graphen eine kompakte 240-mal-144-Grundeinheit mit engeren Abstaenden und Aktionen; der inhaltstragende Titel bleibt 16 px gross und die gesamte Kachel skaliert weiterhin proportional mit dem Kamerazoom. Dummy-Browserpruefung bestaetigt null Kacheln vor und nach Hover, genau eine Kachel nach Klick, eine eingepasste Darstellung von rund 100 mal 60 px sowie Breiten- und Hoehenfaktor 1,2 bei einem Zoomschritt. Sieben fokussierte Tests, 652 Standardtests, Local-only und Client-Produktionsbuild erfolgreich; der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Rollenknoten visuell von Findings getrennt: Category, D3FEND, Technique und Tactic erhalten einen farbgleichen transparenten Aussenring; Findings bleiben ringlos und tragen weiterhin ausschliesslich ihre Severity-Farbe. Hover und Pin verstaerken beziehungsweise markieren Ring und Kern gemeinsam. Dummy-Browserpruefung bestaetigt 17 Ringe auf 17 strukturellen Knoten und null Ringe auf 20 Findings. Drei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Finding-Vorschau auf die Originalkachel des Matrixbereichs umgestellt: Der Graph rendert fuer Findings direkt `TileCard` statt der verkleinerten Nachbildung. Vollstaendiger Titel, Severity-Hexagon, Outcome, Badges, Bookmark und Results-Aktion bleiben erhalten; die Kachel skaliert im Graph-Koordinatensystem proportional mit Zoom, waehrend Rollen-Vorschauen weiterhin zoomstabil bleiben. Dummy-Browsermessung bestaetigt Originaltitel, zwei Kachelaktionen sowie beim Zoomfaktor 1,2 Breiten- und Hoehenverhaeltnis jeweils 1,2. Sieben fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz-, Schema- oder Datenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphlegende auf Nutzerwunsch vollstaendig entfernt: Der unten links eingeblendete Block fuer Finding, Category, D3FEND, Technique und Tactic sowie seine gesamten CSS-Regeln entfallen. Knotenfarben, Severity-Semantik, direkte rote Pfade und Interaktionen bleiben unveraendert. Drei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Graphfarben und direkte Pfade nachgeschaerft: Finding-Punkte tragen Critical-, High-, Medium-, Low- oder Info-Farbe aus der bestehenden Produktskala; `unknown` verwendet einen eigenen neutralblauen Token und kein Grau. Der fruehere zusaetzliche Hochrisiko-Marker entfaellt. Hover oder Pin faerbt ausschliesslich alle direkt inzidenten Kanten des aktiven Knotens rot und hebt sie mit 2 px hervor. Dummy-Browserpruefung: 20 Severity-gefaerbte Findings (6/7/3/2/2) und bei `Lateral Movement` exakt drei rote direkte Pfade. Sieben fokussierte Tests und Client-Produktionsbuild erfolgreich; keine Import-, API-, Persistenz-, Schema- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphprojektion und Darstellung nach der Nutzerreferenz korrigiert: Kategorien und D3FEND werden als eigene Beziehungsknoten gezeigt; Findings ohne Technik-ID verbinden sich mit jeder vorhandenen ATT&CK-Taktik statt nur mit `primaryTactic`. Der Dummy-PurpleKnight-Stand zeigt damit 20 Findings als 37 Knoten und 61 Links (20 Kategorie, 30 ATT&CK, 11 D3FEND); `Lateral Movement` besitzt drei direkte Findingbeziehungen. Gelbe Findingpunkte wurden durch eine ruhige Grau-/Blau-/Blaugruen-Palette mit rotem Hochrisikomarker ersetzt, das Layout deutlich aufgezogen und alle Labels standardmaessig als zoomstabile, praesentativ gekuerzte 16-px-Texte kollisionsfrei platziert. Browserpruefung bestaetigt 37 von 37 sichtbare Knoten, null Labelueberschneidungen sowie weiterhin sichtbare Filter bei minimierter Sidebar. Sieben fokussierte Tests und der vollstaendige Client-/Server-Produktionsbuild erfolgreich; Gesamtlauf 652 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only gruen. Der globale Designcheck bleibt ausschliesslich an den zwei vorbestehenden Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Import-, API-, Persistenz-, Schema- oder Datenmutation; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graph-Panel vom Navigationszustand entkoppelt: Die Collapse- und Mobile-Sichtbarkeitsregeln zielen nur noch auf das direkte Hauptnavigations-`aside`, nicht auf verschachtelte Filter- oder Inspektorbereiche. Graph-Filter und Details bleiben deshalb bei minimierter Sidebar sichtbar. Fokussierter Graph-Test, 650 Standardtests, Local-only und Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Designcheck unveraendert nur wegen `datahub-redesign.css` 39/42 rot; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Graph-Panel reduziert: `Result message`, `SI version`, `Source: Scan` und `My Workspace only` aus der linken Graph-Filteranzeige entfernt. Die uebrigen gemeinsamen Controls und die auf `useFilteredRecords()` beruhende Filtersemantik bleiben unveraendert; in Work gesetzte Filter wirken weiterhin. Graph-Test, 650 Standardtests, Local-only sowie Client-/Server-Produktionsbuild erfolgreich, 8 optionale PostgreSQL-Tests uebersprungen. Designcheck unveraendert nur wegen `datahub-redesign.css` 39/42 rot; keine Import-, API-, Persistenz-, Schema- oder Datenaenderung. |
| 2026-08-22 | Phase-7-Timeslot-Scope fail closed gehaertet: `All timeslots` aus dem Work-Selector entfernt und ohne gesetzten Scope automatisch den neuesten konkreten Timeslot geladen. Result DB fragt ohne aktive ScanRun-Menge nicht mehr den gesamten Client ab; der Graph baut in diesem Zustand ebenfalls keine Aggregatprojektion. Datenaktualisierungen des aktiven Clients bewahren den Scope. Sechs fokussierte Suites mit 21 Tests, 650 Standardtests, Local-only und vollstaendiger Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Facetten appweit auf erreichbare Werte begrenzt: Work- und Result-DB-Filter zeigen unter aktivem Client, Timeslot, Blatt, Suche und Fremdfiltern nur Optionen mit mehr als null Treffern. Die eigene Facette bleibt bei der Alternativzaehlung ausgenommen; unmoeglich gewordene Work- und Statusauswahlen werden automatisch bereinigt. 22 fokussierte und 650 Standardtests, Local-only sowie Client-/Server-Produktionsbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Radiusbudget nach vorheriger Kartenreduktion von 5 auf 4 gesenkt; Designcheck bleibt nur an zwei bekannten Schattenregeln rot. Keine API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-DataHub-Clientkarten um eine direkte gelbe `Open`-Aktion unten rechts erweitert. Sie oeffnet den neuesten scannergebundenen Timeslot samt exakter ScanRun-Menge unmittelbar in Work; `Manage` bleibt oben rechts fuer Clientdaten und Timeslotverwaltung. Ohne Scan-Daten ist Open sichtbar deaktiviert. Vier fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-Importvorschau kosmetisch reduziert: Umrandete Dateikarten, Kartenhintergrund und Statuspills entfernt; Eintraege sind nun flache, optional durch Haarlinien getrennte Abschnitte. Exakte und moegliche Dubletten erscheinen als englischer `Duplicate found`-Hinweis mit mindestens 16 px grossem Fliesstext. Lange Dateinamen, Hashes und Quellen umbrechen, horizontaler Listen-Scroll entfaellt. Checkbox, Mappingbestaetigung sowie Cancel/Import selection bleiben unveraendert. Sechs fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine Fachlogik-, API-, Persistenz-, Schema- oder Datenänderung. |
| 2026-08-22 | Phase-7-Result-DB an den aktiven Timeslot gebunden: App und ResultsBrowser geben die aktuell geladenen ScanRun-IDs an Treffer- und Facettenabfragen weiter; der additive Unified-Result-Queryparameter `scanRunIds` wird als wiederholter URL-Wert geparst und in Local- sowie PostgreSQL-Persistenz angewendet. `All timeslots` bleibt der ausdrueckliche projektweite Aggregatmodus. 22 fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; Gesamtsuite 647 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only gruen. Der globale Designcheck bleibt nur an zwei unveraenderten Schattenregeln rot. Keine Migration oder Realdatenpruefung. |
| 2026-08-22 | Phase-7-Work-Zustand pro Timeslot getrennt: Snapshot-Lesezeichen und My-Workspace-/Review-Markierungen verwenden nun einen stabilen Client-plus-ScanRun-Scope. Timeslot- und Blattwechsel laden die Statusfilterdefaults des tatsaechlich aktiven Toolprofils und leeren alte Facetten. Gemischte Aggregate vereinigen die Statusfilter aller enthaltenen bekannten Profile, Einzelblaetter bleiben exakt Maester, PingCastle, Purple Knight oder CIS-CAT zugeordnet. 24 fokussierte Tests erfolgreich. Produktionsbuild unabhaengig durch bereits vorhandene fehlende Graph-Filtervariablen in `ObsidianGraphView.tsx` blockiert; keine API-, Backend-, Persistenzschema- oder Datenbankaenderung. |
| 2026-08-22 | Phase-7-Importfortschritt visuell korrigiert: Der rotierende Kreis im Fortschritts-Pop-up wurde durch vier kleine Quadrate auf einer gedachten Kreisbahn ersetzt; jeweils ein rotes Quadrat wird im Uhrzeigersinn weitergeschaltet. Der Status bleibt textlich zugaenglich, Reduced Motion zeigt einen statischen Zustand. Fuenf fokussierte Tests und Client-/Serverbuild erfolgreich; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Aktionszustand sicherer gemacht: Sobald Stammdaten editiert werden, verschwindet `Delete client` gemeinsam mit Edit vollstaendig und nur der gelbe Save-Button bleibt an derselben Position. Edit, Save und Delete verwenden identische 96-px-Mindestbreiten, sodass der Wechsel keinen Groessensprung erzeugt. Drei fokussierte Tests und Client-/Server-Produktionsbuild erfolgreich; keine Delete-, Save-, API-, Persistenz- oder Schemafachlogik veraendert. |
| 2026-08-22 | Phase-7-Work-Kopf um eine direkte Timeslot-Auswahl rechts neben der bestehenden Client-/Blattauswahl erweitert. `All timeslots` laedt weiterhin den gesamten Mandanten; ein Stichtag uebergibt nur dessen persistierte ScanRun-IDs an den vorhandenen `openProject`-Pfad. Optionen stammen aus Assessment-Historie und Importdateiliste der Same-Origin-API und aktualisieren sich nach Datahub-Aenderungen. Drei fokussierte UI-Tests, Local-only und Client-/Serverbuild erfolgreich. Gesamtlauf: 639 bestanden, 8 optionale PostgreSQL-Tests uebersprungen, ein unabhaengiger Result-Fenster-Test einmal rot und anschliessend isoliert mit 16 von 16 gruen. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, Mapping-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Maximaltabellen kompakter ausgerichtet: Vor einer manuellen Anpassung verwenden maximierte Result-Tabellen ihre ungebrochene intrinsische Inhaltsbreite statt die volle Fensterbreite. Echte Ueberbreite bleibt horizontal scrollbar; nach Nutzeranpassung gilt unveraendert die explizite Spaltenbreite. Zwei fokussierte Suites mit 27 Tests und Gesamtlauf mit 642 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Result-Spaltenbreiten auf alle frei stehenden Fenster erweitert: Herausgezogene, normal grosse, manuell skalierte und maximierte Results besitzen die bestehenden Spaltengriffe, Auto-Fit und Tastaturbedienung. Nur das weiterhin im Findings-Cluster eingereihte aktive Result und minimierte Slots bleiben unveraenderbar. Drei fokussierte Suites mit 32 Tests und Gesamtlauf mit 640 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Aktionen nach Nutzerreferenz neu geordnet: `Open` steht oben rechts im linken Timeslot-Navigatorkopf. Rechts folgen `Delete client` und der gelbe `Edit`-Textbutton; waehrend der Bearbeitung ersetzt `Save` den Edit-Button. Bleistift und separater Delete-Footer sind entfernt, bestaetigungspflichtiges Delete sowie Open-/Save-Fachlogik bleiben unveraendert. Vier fokussierte UI-Tests und Gesamtlauf mit 639 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Fachlogik-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Work-Kopf gegen abgeschnittene Controls nachgeschaerft: `My Workspace` bleibt mit 112 px Mindestbreite einzeilig; View-Tabs, Actionlist-Exportgruppe und direkte Toolbar-Aktionen schrumpfen nicht mehr und behalten ihre sichtbaren Kanten. Bei echter Unterbreite ist die Werkzeugzeile horizontal erreichbar statt verdeckt. Die toolabhaengige Filterableitung bleibt unveraendert. Zwei fokussierte Layouttests und Gesamtlauf mit 639 bestandenen Tests, 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Filter-, Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Result-Tabellen um Excel-artige Spaltenbreiten ergaenzt: Im maximierten Fenster erscheinen fokussierbare Separatoren zwischen Kopfzellen. Ziehen veraendert die linke Spalte, Doppelklick/Enter passt sie an den laengsten ungebrochenen Inhalt an; Pfeiltasten aendern um 16 px. Breiten bleiben lokaler UI-Zustand, sind auf 72 bis 720 px begrenzt und nutzen bei Ueberbreite den bestehenden Horizontal-Scroll. Direkte Ergebnisblaetter und Markdown-Tabellen verwenden denselben React-Baustein; normale Fenster bleiben unveraendert. Drei fokussierte Suites mit 28 Tests und Gesamtlauf mit 637 bestandenen Tests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Import-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Graphansicht nach Nutzerreferenz als ruhiges Dreispaltenlayout umgesetzt: gemeinsame fachliche Filter links, kompakter Netzwerkgraph mittig und permanenter Detailinspektor rechts. Work und Graph teilen Suche, Quellblatt, Status, dynamische Facetten und Workspace-Einschraenkung bidirektional ueber den bestehenden AppProvider; lokale Graphfilter entfallen. Zwei fokussierte synthetische Graph-Tests und 647 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen; Local-only und separater Client-Bundlebuild erfolgreich. Baseline-Build derzeit nur durch den vorbestehenden fremden TypeScript-Fehler in `server/assessor-http-server.ts` Zeile 196 blockiert; bekannter Designcheck-Befund unveraendert `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Remarks-Editor auf Langtextnutzung ausgerichtet: Das Textarea belegt nun 100 Prozent der Client-Dokumentbreite, verwendet 10 statt 5 Zeilen und eine von vier auf acht 32-px-Rastereinheiten verdoppelte Mindesthoehe; vertikale Nutzeranpassung bleibt aktiv. Name und Consultant bleiben einzeilig. Fokussierter Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-ScanRun-Tabelle fuer die schmale Clientnavigation nachgeschaerft: Scannername bleibt 16 px, Datei-/Format-Metazeile wird kompakter. Die Scan-Spalte erhaelt eine kontrollierte Mindestbreite, Imported waechst von 104 auf 136 px und beginnt dadurch weiter links, damit Datum und Uhrzeit nicht vorzeitig abgeschnitten werden. Status und Delete bleiben unveraendert. Fokussierter Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Timeslotstandard korrigiert: Beim Oeffnen einer Client-Ansicht sind alle Timeslots eingeklappt. Der neueste Timeslot bleibt wie zuvor vorausgewaehlt; nur dessen Detailtabelle wird nicht automatisch geoeffnet. Manuelles Aufklappen und alle bestehenden Aktionen bleiben unveraendert. Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild sind erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Delete vereinheitlicht: Die rechte Aktion ist nun ausdruecklich ein umrandeter destruktiver Textbutton `Delete client` mit fester Buttonbreite; Papierkorb, SVG, Bild- und Iconpfad entfallen vollstaendig. Der fokussierte Strukturtest mit 3 Tests, 634 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only sowie Client-/Serverbuild sind erfolgreich. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Neueste Phase-7-Nutzerkorrektur umgesetzt und die unmittelbar vorherige Namensentdoppelung ausdruecklich abgeloest: Rechts stehen wieder Name, Consultant und Remarks als drei vertikale Dokumentabschnitte. Jede 14-px-Bezeichnung steht direkt ueber ihrem linksbuendigen 16-px-Wert; die linke Identitaet bleibt statisch. Zwei fokussierte Suites mit 4 Tests erfolgreich. Inhaltsarme Browsergeometrie bestaetigt fuer alle drei Paare gleiche linke Kante, Wert unter Label, 14/16 px und linke Ausrichtung. Gesamtlauf: 634 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only erfolgreich. Der bekannte Designcheck bleibt ausschliesslich wegen der unveraenderten Schattenregeln in `datahub-redesign.css` 39/42 rot. Client-/Serverbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Client-Reader entdoppelt: Name erscheint nur links oberhalb der Timeslots; rechts verbleiben Consultant und Remarks. In Create/Edit wird der linke Titel zum erforderlichen, dem bestehenden `tenant-editor-form` zugeordneten Namensfeld, sodass Save unveraendert bleibt. Zwei fokussierte Suites mit 4 Tests, 634 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt zwei rechte Abschnitte, null rechte Namenslabel sowie linken Titel/Editinput und Save. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7-Shelltitel an den Data-Hub-Kontext gebunden: Hauptansicht zeigt `Data Hub`, Client-Neuanlage und -Detail zeigen `Client`; Back und Bereichswechsel setzen auf `Data Hub` zurueck. Fokustest, 634 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt Data Hub -> Client -> Data Hub ohne Inhaltszugriff. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
| 2026-08-22 | Phase-7/12-Timeslot-Scans an der Baseline-Tabelle ausgerichtet: fuenf kompakte Spalten fuer Auswahl, Scan, Imported, Status und Actions; Size entfaellt. Readiness verwendet die bestehende Work-Grenze aus persistiertem Run und kanonischen Occurrences: Recognized, Generic, Not viewable sowie technisch getrennt Unavailable/Checking. Nicht darstellbare Runs sind nicht auswaehlbar und werden vor Open aus der Einzel-/Mehrfachprojektion entfernt. ScanRun- und Mandanten-Delete verwenden ausgeschriebene Buttons; kein Delete-Papierkorb verbleibt. Zwei fokussierte Suites mit 5 Tests und 633 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung: fuenf Spalten, kein Overflow, vier recognized, vier Text-Deletes, null Delete-SVG/Papierkorbpfade. Bekannter Designcheck-Befund unveraendert nur `datahub-redesign.css` 39/42. Keine API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Mandantendetail nach den drei Nutzerreferenzen final korrigiert: Die verbliebene zweispaltige Formular-Altregel ist im Detail auf ein einspaltiges Readerlayout begrenzt. Name, Consultant und Remarks sind im Lesemodus echte vertikale Dokumentabschnitte mit neutralen Ueberschriften und 16-px-Werttext; erst Edit zeigt Inputs. Timeslot-/ScanRun-Checkboxen und Auswahlmarker sind bernsteinfarben, die Auswahlflaeche neutral statt violett. GPO- und Scanimport sind identisch gelbe Primaerbuttons, Delete bleibt neutral. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt drei vertikale Abschnitte, neutrale Label, bernsteinfarbene Auswahl und zwei gelbe Importaktionen. Bekannter Designcheck-Befund unveraendert nur in `datahub-redesign.css` Zeilen 39/42. Keine API-, Persistenz-, Schema-, Fachfunktions- oder Realdatenaenderung. |
| 2026-08-22 | Mandantendetail nach Nutzerkorrektur verdichtet: Das 44/56-Raster ist durch die exakte Work-/Reports-Listenbreite `clamp(420px, 27vw, 520px)` ersetzt. Die read-first Mandanteninformation ist eine maximal 794 px breite transparente Reader-Dokumentflaeche ohne Aussenrahmen, Karten oder Labelkaesten; Werte stehen als Fliesstext unter Abschnittsueberschriften mit feinen Trennern, Eingaberahmen erscheinen nur im Editzustand. Die Timeslotliste verwendet entsprechend flache rahmenlose Work-Eintraege. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browsermessung bestaetigt 520 px Navigator, 794 px rahmenlose Dokumentflaeche und unabhaengiges Scrollen. Der globale Designcheck bleibt ausschliesslich an den zwei dokumentierten unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema-, Fachfunktions- oder Realdatenaenderung; Phase 7/8/12-Status bleibt abgeschlossen. |
| 2026-08-22 | Mandantendetail nach der ausgewaehlten Work-/Reports-Referenz als vollflaechige 44/56-Master-Detail-Ansicht umgesetzt: links Mandantenkopf und unabhaengig scrollender Timeslot-/ScanRun-Navigator, rechts read-first Client Information mit explizitem Edit/Save, Open und getrenntem Mandanten-Delete. Persistierte Timeslots lassen sich aufklappen; ihre realen ScanRuns bleiben mit vorhandenen Metadaten, Auswahl und bestaetigungspflichtigem Delete sichtbar. Einzelne Runs koennen lokal fuer Open ausgeschlossen werden; neue Importe bleiben eingeschlossen und die sichere Mehrfach-Timeslot-Schnittmenge bleibt erhalten. Drei fokussierte Tests und 631 Standardtests gruen, 8 optionale PostgreSQL-Tests uebersprungen, Local-only und Client-/Serverbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt Raster, Scrollgrenze, Controls, Scan-Abwahl und Laufzeitstabilitaet. Der globale Designcheck bleibt ausschliesslich an den bereits dokumentierten unveraenderten Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7/8/12-Status bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphsteuerung um einen gemeinsamen `Reset` direkt neben `Filters` erweitert. Die Aktion wird nur bei aktivem Suchtext, Kategorie-, Severity- oder Mappingfilter freigeschaltet und setzt diese vier Zustaende atomar auf ihre Defaults zurueck; `Labels` bleibt als unabhaengige Darstellungsoption unveraendert. Zwei fokussierte Graph-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung erfolgreich: initial gesperrt, nach Suche aktiv, danach Suche leer und wieder gesperrt. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphauswahl auf unabhaengige Mehrfach-Pins erweitert: Jede angeklickte Punktkachel bleibt sichtbar, weitere Knoten koennen gleichzeitig angepinnt werden und ein erneuter Klick entfernt nur die betreffende Kachel. Der Inspektor folgt dem zuletzt aktivierten Pin und wechselt beim Entfernen auf den zuletzt verbleibenden; Tastatur und Schliessen verwenden dieselbe Toggle-Semantik. Zwei fokussierte Graph-Tests und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln nach Nutzerreferenz auf kleine quadratische Work-Miniaturen korrigiert: Findings verwenden die bestehende `data-tile`-Struktur mit Severity-Hexagon, zweizeiligem Inhaltstitel, normalisiertem Outcome und der vorhandenen Badge-Reihenfolge; Technik und Taktik verwenden quadratische reduzierte Rollenvarianten. Karten erscheinen standardmaessig nur bei Hover oder Auswahl, die Labelumschaltung kann alle anzeigen. Die gesamte Karte nimmt Pointerereignisse an und bleibt per Klick umschaltbar. Zwei fokussierte Graph-Tests sowie der vollstaendige Client-/Server-Produktionsbuild erfolgreich; 630 Standardtests bestanden und 8 optionale PostgreSQL-Tests wurden uebersprungen. Local-only ist gruen, der globale Designcheck bleibt ausschliesslich an den zwei bereits vorhandenen Schattenregeln in `datahub-redesign.css` Zeilen 39 und 42 rot. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Graphkacheln um persistentes Klick-Toggle erweitert: Ein Klick pinnt die Mini-Kachel und den Detailinspektor, ein zweiter Klick auf denselben Knoten hebt die Auswahl wieder auf; Tastaturaktivierung besitzt dieselbe Semantik und `aria-pressed` macht den Zustand zugaenglich. Eine Bewegung ab 3 px gilt als Knotendrag und schaltet die Auswahl nicht versehentlich um. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphlabels nach Nutzerkorrektur als zoomstabile Mini-Kacheln umgesetzt: Findings zeigen neben ihrem Knoten eine verkleinerte Work-Kachel mit Severity-Marker, Severity-Label und zweizeiligem 16-px-Titel; Technik- und Taktikknoten verwenden reduzierte Varianten mit eigener Rollenfarbe. Die Kacheln erscheinen fuer Taktiken dauerhaft sowie fuer Findings und Techniken bei Auswahl, Hover oder aktivierter Labelansicht, skalieren nicht mit dem Graphzoom und kuerzen nur ihre Vorschau; der vollstaendige Titel bleibt im Inspektor erhalten. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphbeschriftung korrigiert: SVG-Knotentexte werden nicht mehr mit der Zoomkamera vergroessert oder verkleinert, sondern bleiben unabhaengig von Fit, Pan und Zoom konstant in der verbindlichen 16-px-Inhaltsschrift. Sehr lange Knotentitel werden nach 56 Zeichen mit Auslassungspunkt gekuerzt; der vollstaendige Titel bleibt im Detailinspektor erhalten. Fokussierter Graph-Test und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Korrektur der unmittelbar folgenden Phase-7-Hintergrundausweitung auf ausdruecklichen Nutzerwunsch: Der tokenbasierte Punkthintergrund ist nun ausschliesslich an `.app-area-graph` gebunden. Datahub, Dashboard, DB Structure, Results und Work verwenden wieder ihre ungepunkteten Standardflaechen; die Dark-/Light-Anpassung fuer den Graph bleibt erhalten. Fokussierter Graph-/Hintergrundtest und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-22 | Phase-7-Graphansicht nach Nutzerreferenz vollstaendig durch einen Obsidian-aehnlichen interaktiven Netzwerkgraphen ersetzt: Findings, MITRE-Techniken und Taktiken bilden deterministisch verbundene Knoten; Zoomen am Mauszeiger, Flaechenverschiebung, Knotendragging, Auswahl/Hover, Suche, Kategorie-/Severity-/Mappingfilter, Labelumschaltung, Fit-Steuerung, Detailinspektor sowie vorhandene Work-, Results- und Workspace-Aktionen sind integriert. Die bisherige Graphkomponente und ihr Stylesheet werden nicht mehr geladen. Der gepunktete Graphhintergrund ist als tokenbasierte Standardflaeche auf Datahub, Dashboard, Graph, DB Structure und Results ausgedehnt, Work bleibt unveraendert; Lightmode besitzt eine eigene helle Punktfarbe. Fuenf fokussierte synthetische Graph-/MITRE-Tests, Client-/Server-Produktionsbuild, 630 Standardtests und Local-only-Pruefung erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Inhaltsarme Browserpruefung bestaetigt den gepunkteten Nicht-Work-Hintergrund einschliesslich Lightmode; die Graphansicht war dort mangels geladenem Datensatz bewusst nicht aktivierbar. Der globale Designcheck bleibt ausschliesslich an zwei bereits vorhandenen Schattenregeln in datahub-redesign.css rot. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-13A-PingCastle-Reader bereinigt: Das technische Feld `Verwandte Daten` einschliesslich der importdateigebundenen Sektions-ID wird in der sichtbaren Finding-Zusammenfassung und unter `Additional Information` ausgeblendet. Das Feld bleibt unveraendert im Datensatz und speist weiterhin den exakten PingCastle-Results-Linker; kein Reimport erforderlich. Zwei fokussierte Suites mit 26 bestandenen Tests bestaetigen Ausblendung und fortbestehende Verknuepfung, der Client-Produktionsbuild ist erfolgreich. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 13A bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantendetail auf Nutzerkorrektur vollstaendig linienfrei gestellt: Nach der oberen wurde nun auch die untere Trennlinie des Aktionsbereichs entfernt. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (beide Linien 0 px) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantendetail optisch bereinigt: Die obere Trennlinie zwischen Identitaetskopf und Aktionszeile wurde entfernt; die untere Linie des Aktionsbereichs bleibt unveraendert bestehen. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (oben 0 px, unten weiterhin vorhanden) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenkacheln an den Matrix-Hover angeglichen: reale Mandanten- und Plus-Kacheln wechseln bei Hover beziehungsweise Tastaturfokus auf staerkere Kontur und Hoverflaeche, erhalten den erhoehten Schatten und heben sich mit identischer 120-ms-Transition um 2 px an. `prefers-reduced-motion` unterdrueckt die Bewegung; Auswahlzustand und Aktionen bleiben unveraendert. Zwei fokussierte Datahub-Tests, Client-Produktionsbuild und inhaltsarme Browser-Stilpruefung erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Kopfzeilentypografie erneut auf die praezisierte Nutzerreferenz angeglichen: Die regulaeren Bereichsnamen verwenden nun exakt dieselben berechneten Werte wie der grosse Mandantentitel (`Dummy`-Referenz): 54 px, Gewicht 600, 62,1 px Zeilenhoehe und -2,16 px Laufweite bei aktueller Tokenbasis. Designpruefung, Client-Produktionsbuild und inhaltsarme Browser-Gleichheitspruefung erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Work-Kopf nach Nutzerreferenz angepasst: Das Freitextfeld und seine Loeschaktion verwenden nun `Search` beziehungsweise `Clear search` statt `Filter text`. Die gemeinsame Such-/Result-Dock-Gruppe wird in der unteren Kopfzeile bei regulaerer Breite exakt mittig positioniert und faellt unter 1200 px kollisionsfrei in den normalen Fluss zurueck; Bookmarks, Filterlogik und Result-Docking bleiben erhalten. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung erfolgreich: genau ein `Search`, kein altes Placeholder, Feldmitte innerhalb 4 px der Kopfzeilenmitte. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Kopfzeilentypografie auf Nutzerkorrektur praezisiert: Die zuvor eingefuehrte Grossbuchstaben-Transformation und Laufweite sind wieder entfernt. Bereichsnamen bewahren ihre normale Schreibweise wie `Datahub` und werden stattdessen zentral auf 27 px mit kompakter Zeilenhoehe vergroessert; die Regel gilt weiterhin fuer alle regulaeren Kopfpanels. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung (27 px, `text-transform: none`) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Anwendungskopf vereinheitlicht: Alle regulaeren, dort eingeblendeten Bereichsbezeichnungen werden ueber die gemeinsame `.area-topbar`-Regel in Grossbuchstaben mit dezenter Laufweite dargestellt; damit gilt die Vorgabe automatisch fuer Datahub und die weiteren Kopfpanels. Der funktionale Work-Kopf und die Sidebar-Navigation bleiben unveraendert. Designpruefung, Client-Produktionsbuild und inhaltsarme Browserpruefung (`text-transform: uppercase`, wirksame Laufweite) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Timeslot-Typografie nach Nutzerreferenz nachgeschaerft: Die Ueberschrift verwendet nun 18 px (`--fs-xl`); die Auswahlzusammenfassung darunter ist ohne Rahmen und Innenabstand in der regulaeren 14-px-UI-Schrift (`--fs-md`) dargestellt. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (18-px-Ueberschrift, 14-px-Auswahltext, 0-px-Rahmen) erfolgreich. Keine Fachlogik-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Timeslot-Bereich der Mandantenansicht mit der sichtbaren Ueberschrift `Timeslots` direkt oberhalb der Datumszeilen ergaenzt. Auswahl, geschlossener Tabellenzustand, Datumsanlage und Importlogik bleiben unveraendert. Zwei fokussierte UI-Tests, Client-Produktionsbuild und inhaltsarme Browserpruefung (je eine Timeslot-Region und -Ueberschrift) erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Baselinekatalog startet auf ausdruecklichen Nutzerwunsch standardmaessig eingeklappt. Zaehler, Upload-Aktion und manuelles Aufklappen bleiben unveraendert verfuegbar. Fokussierter Datahub-Test, Client-Produktionsbuild und inhaltsarme Browserpruefung (ein Katalog, kein `open`, eine sichtbare Upload-Aktion) erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7/8/12-Timeslot-Workflow in der Mandantendetailansicht umgesetzt: `Scan History · Linked Scan Reports` ist nun eine standardmaessig geschlossene Timeslot-Tabelle mit einer Checkbox je fachlichem Assessment-Stichtag. Ein Plus oeffnet einen kleinen Datumsdialog und legt ueber die bestehende Assessment-API einen leeren, anschliessend ausgewaehlten `effectiveAt`-Timeslot an. `Open` benoetigt eine Auswahl; bei einem Stand oeffnet es dessen Scannerlaeufe, ab zwei Staenden nur die Schnittmenge sicher erkannter, in allen Staenden vorhandener Scannerwerkzeuge. GPO-Abdeckung wird separat beruecksichtigt und niemals als ScanRun modelliert; ausgeschlossene Quellen werden sichtbar genannt. Einzelne Scanberichte bleiben innerhalb der Timeslot-Zeile loeschbar. Drei fokussierte Suites mit 12 Tests und `npm test` mit 621 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt geschlossenen Default, Plus-/Datumsdialog, Abbruch ohne Anlage, Checkboxen und Open-Freigabe ohne Datenmutation. Keine neue Entitaet, Migration oder API; Phase 7, 8 und 12 bleiben abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-13B-Baselinekatalog um kontrolliertes Loeschen erweitert: Jede Zeile der an Scan History angeglichenen Tabelle besitzt nun eine Actions-Spalte mit Delete-Button und Warnungsdialog. Der neue Same-Origin-DELETE-Pfad verlangt explizite Bestaetigung, ist in API-Client und Service verdrahtet und entfernt nicht referenzierte Katalogeintraege einschliesslich Klassifikationen und Analysen in Local- und PostgreSQL-Persistenz; vorhandene Policy-Evaluationsquellen blockieren mit Konflikt. Das private Originalobjekt wird nach erfolgreichem Repository-Commit best-effort entfernt. Synthetische UI-, Client-, Service- und Persistenzregressionen ergaenzt; `npm test`: 620 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration und keine Realdatenpruefung; Phase 13B bleibt in Arbeit. |
| 2026-08-22 | Phase-7-Datahub-Geometrie beim Baseline-Expander stabilisiert: Die vertikale Scrollbar-Gutterbreite der Datahub-Ansicht wird nun dauerhaft reserviert. Beim Auf- und Zuklappen von `Imported Security Baselines` kann der Scrollbalken damit erscheinen beziehungsweise verschwinden, ohne die zentrierte Inhaltsflaeche seitlich zu verschieben. Fokussierter Datahub-Layouttest und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Zuruecknavigation der Mandantenansicht verdeutlicht: Das Richtungsdreieck wurde auf 28 px vergroessert und um den sichtbaren Text `Back` ergaenzt. Beide Elemente liegen in derselben semantischen Schaltflaeche mit gemeinsamem Klickbereich, Fokus und zugaenglichem Namen `Back to client overview`. Vier fokussierte Tests und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenkopf nach Nutzerreferenz nachgeschaerft: Die grosse einzeilige Titelbox wurde nach unten erweitert; Zeilenhoehe 1,15 und tokenbasierter unterer Innenabstand verhindern abgeschnittene Schrift beziehungsweise Unterlaengen, waehrend Ellipse, Kopfaufteilung und Aktionen unveraendert bleiben. Fokussierter Datahub-Test und Client-Produktionsbuild erfolgreich. Keine API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-22 | Phase-7-Mandantenaktionen fuer jeden bestehenden Mandanten freigegeben: `Import Data` und `GPO Backup Folder` werden nicht mehr von einer bereits vorhandenen Assessment-/Timeslot-ID ausgeblendet. Eine vorhandene Ziel-ID wird unveraendert weitergereicht; leere Mandanten nutzen den bereits bestehenden optionalen Erstimportpfad. Der fokussierte Datahub-Test prueft die entfernte Sperre. Eine inhaltsarme Browserpruefung bestaetigt beide Aktionen jeweils genau einmal in allen zwei vorhandenen Mandantenansichten, ohne Upload oder Datenmutation. `npm test`: 620 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, Importlogik-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7-Mandantenstammdaten gegen versehentliche Aenderungen abgesichert: Bestehende Mandanten zeigen Name, Consultant und Remarks zunaechst schreibgeschuetzt. Ein zugaenglich beschrifteter, rahmenloser Stift unmittelbar hinter `Master Data · Client Data` aktiviert als einzige UI-Aktion die Bearbeitung und blendet erst dann `Save` ein; der Submit-Handler weist Speicherversuche ohne aktiven Bearbeitungsmodus ebenfalls ab. Neuanlagen sind sofort editierbar, nach erfolgreichem Speichern oder Verlassen wird wieder gesperrt. Zwei fokussierte Suites mit vier Tests und der Gesamtlauf mit 620 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Die anschliessende Platzierungsnachschaerfung ist mit zwei fokussierten Tests und Client-Build verifiziert. Inhaltsarme Browserpruefung bestaetigt Read-only-/Edit-Zustand, Stiftschalter, bedingte Speicheraktion und Rueckkehr ohne Speichern. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7-Datahub-Uebersicht nach Nutzerreferenz neu geordnet: Die sechs bestehenden Statusdiagramme stehen oben. Darunter werden ausschliesslich persistierte Mandanten als diagrammlose Karten im verbindlichen Donut-Kacheldesign sowie genau eine dezente Plus-Karte angezeigt; die frueheren acht Spalten, `Empty`-Slots und Timeslotzeilen sind entfernt. Ein Kartenklick waehlt exklusiv einen Mandanten, umrandet nur ihn, zeigt nur dort `Show` und speist die Diagramme aus dessen neuestem scannergebundenen Timeslot; Mandanten ohne Scanbestand liefern Nullwerte. `Show` oeffnet die unveraenderte Mandantenansicht. Vier fokussierte Suites mit 11 Tests und der Gesamtlauf mit 620 bestandenen Tests sowie 8 uebersprungenen optionalen PostgreSQL-Tests sind gruen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsarme Browserpruefung bestaetigt eine Auswahl, einen `Show`-Button, null Platzhalter, eine Plus-Kachel, den erwarteten Diagrammwechsel und die Mandantennavigation. App und Backend laufen nach kontrolliertem Neustart wieder lokal. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-22 | Phase-7/9/10/12-Timeslot-Aktionen korrigiert: Nur angehakte Datumszeilen zeigen `Delete`, `Import Scan` und `Import GPO Backup Folder (Zip)`; beide Importe sind an die Assessment-ID genau dieses Slots gebunden. Der bestehende Mandanten-Delete bleibt oben unveraendert. Ein neuer projektgebundener, bestaetigungspflichtiger Assessment-DELETE-Pfad entfernt ausschliesslich den Timeslot-Teilbaum samt Scan-, GPO-, Finding-, Evidenz- und Mappingdaten in Local- und PostgreSQL-Persistenz; Mandant und andere Timeslots bleiben erhalten. Keine SQL-Migration. Fuenf fokussierte Suites mit 32 Tests, `npm test` mit 626 bestandenen Tests und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-, Designpruefung sowie vollstaendiger Client-/Server-Produktionsbuild erfolgreich. Keine Realdatenpruefung. |
| 2026-08-22 | Phase-7/12-Timeslot-Vorauswahl ergaenzt: Beim Oeffnen eines bestehenden Mandanten wird der erste Eintrag der chronologisch absteigend sortierten Timeslotgruppe automatisch markiert und als aktiver Stand gesetzt. Eine bewusste Abwahl bleibt moeglich. Zwei fokussierte Suites mit sechs Tests und Client-Produktionsbuild erfolgreich; keine API-, Persistenz-, Schema- oder Realdatenaenderung. |
| 2026-08-21 | PingCastle-`Details` auf Nutzerwunsch wieder aus dem Reader entfernt: Bei mindestens einem strukturierten Results-Blatt wird das Feld weder im Fliesstext noch unter Additional Information gerendert; der vollstaendige Inhalt bleibt im geordneten Results-Popup. Ohne strukturierte Results bleibt `Details` als verlustfreier Fallback lesbar. 38 fokussierte synthetische Tests, die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich. Keine Import-, API-, SQL-, Schema-, Persistenz- oder Realdatenaenderung; bereits gespeicherte Findings profitieren ohne Reimport. Phase 7 bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | PingCastle-Results auf den vollstaendigen Detailspfad ausgerichtet: Extractor 1.8.0 sortiert rekursive Zielcontainer nach ihrer Definition im HTML; der Linker rekonstruiert pro Finding exakt dessen Section-ID-Reihenfolge statt der globalen Blattreihenfolge. Profil 1.2.0 aktiviert hierarchische Results-Ueberschriften (`Details`, `Admin Groups`, `Admin Groups → …`) und blendet das technische Praefix aus. Fachliche Abschnittsprosa steht als Preamble direkt vor der zugehoerigen Tabelle; reine Modal-Titel und `Close` werden nicht doppelt ausgegeben. Damit ist zugleich der im unmittelbar folgenden Protokolleintrag dokumentierte unabhaengige `Close`-Preamble-Testfehler behoben. 49 fokussierte Tests sowie die vollstaendige Testsuite einschliesslich Local-only- und Designpruefung und der Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL-, Schema- oder Realdatenaenderung; fuer bereits gespeicherte PingCastle-HTML-Laeufe ist ein Reimport erforderlich. Phase 13A und Phase 7 bleiben abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-7-Result-Fenster nach Nutzerreferenz erweitert: Doppelklick auf die freie Kopfzeile eines geoeffneten Results maximiert es nun auf die groesstmoegliche sichtbare Flaeche unterhalb des statischen Headers; ein einfacher Klick auf die maximierte Titelleiste stellt die vorherige Position, Groesse und Clusterzugehoerigkeit wieder her. Ein minimiertes Result wird per Doppelklick weiterhin normal aufgeklappt, Kopfzeilenbuttons bleiben ausgenommen und Resize-Kanten sind im maximierten Zustand deaktiviert. Der synthetische Interaktionstest deckt Maximierung, Ein-Klick-Rueckkehr und die Unterdrueckung einer sofortigen Wiedermaximierung durch das zugehoerige Doppelklickereignis ab und besteht mit 13 von 13 Tests; der Client-/Server-Produktionsbuild ist erfolgreich. Im abschliessenden Gesamtlauf bestanden 617 Tests, 8 optionale PostgreSQL-Tests wurden uebersprungen; ein parallel hinzugekommener, fachlich unabhaengiger PingCastle-Projektionstest blieb wegen eines unerwarteten `Close`-Preambles rot, waehrend der Result-Fenster-Test gruen blieb. Die separate Browserpruefsitzung war leer, daher wurden bewusst keine Scan- oder Testdaten im laufenden Backend angelegt. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen und Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-13A-PingCastle-Results vollstaendig und sicher auf HTML-Linkgraphen umgestellt: Extractor 1.7.0 verfolgt interne `href`, `data-bs-target` und `aria-controls` rekursiv ueber Subsections, Tabellenzellen, Modals und Collapse-Container, maskiert Kindziele im Elternblock und projiziert jeden erreichten Tabellenendpunkt separat in den bestehenden Results-Vertrag. Mehrfachtabellen, Zyklen, fehlende/mehrdeutige Ziele und Ressourcenlimits sind synthetisch abgesichert; aktive und externe Ziele bleiben ausgeschlossen. Results-Sections sind pro Importdatei namespaced. Nach ausdruecklicher Nutzerkorrektur werden PingCastle-HTML und -XML nicht mehr gegenseitig angereichert: nur HTML besitzt Results, XML bleibt eigenstaendig und erzeugt die Importwarnung `pingcastle-xml-results-unavailable`. Der freigegebene Dummy-Bericht bestaetigt inhaltsarm fuer `P-Delegated` sieben Bloecke mit insgesamt 33 Zeilen; der temporaere Realdatei-Test wurde entfernt. `npm test`: 616 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Aktualisierte App und Backend laufen lokal und liefern HTTP 200. Keine API-, SQL- oder Persistenzaenderung; neue HTML-Results erfordern eine erneute Verarbeitung des Berichts. Phase 13A bleibt abgeschlossen, Phase 13B unveraendert in Arbeit. |
| 2026-08-21 | Phase-7-PingCastle-Darstellung nach ausdruecklicher Nutzerkorrektur angepasst: `Details` wird auch bei verknuepften strukturierten Ergebnissen als normaler Reader-Abschnitt direkt nach `Technical explanation` und vor `Advised solution` gerendert und verschwindet aus `Additional Information`. Originalfeld, strukturierte Results und Provenienz bleiben unveraendert. Synthetischer Finding-Reader-Test und kurzlebige synthetische Browserpruefung bestaetigen Reihenfolge, Absatzdarstellung und fehlende Zusatzinformationstabellenzeile; das temporaere Browserartefakt wurde entfernt. `npm test`: 615 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz-, Schema- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen und Phase 13B bleibt in Arbeit. |
| 2026-08-17 | Korrektur der unmittelbar folgenden Ein-Worker-Zwischenloesung: Die drei konkreten Parallelitaetsassertions wurden aus dem Config-Separation-Test entfernt. Kontrollierte Gesamtlaeufe mit aktivem File-Parallelismus und unveraendertem `forks`-Pool waren mit 2 Workern in 203,48 s und mit 4 Workern in 122,45 s erfolgreich; ein zweiter 4-Worker-Lauf ueber den oeffentlichen `npm test`-Pfad bestand in 121,03 s mit 614 bestandenen und 8 uebersprungenen Tests sowie erfolgreicher Local-only- und Designpruefung. `vitest.config.ts` begrenzt deshalb nur `maxWorkers` auf 4 und laesst Dateiparallelitaet aktiv. Die CPU-basierte Defaultzahl bleibt fuer das synchronisierte Laufwerk als instabil belegt; `threads` wurde bewusst noch nicht getestet, um nur eine Variable zu aendern. Keine Phasenstatus-, Fach-, Import-, API-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-17 | **Zwischendiagnose, durch den unmittelbar vorherigen Benchmarkeintrag ersetzt:** Phasenuebergreifende Verifikationshaertung fuer Phase 1/13: Der vermeintliche Server-Build-Haenger wurde widerlegt (`tsc` 6,6 s, isolierter Server-Vite-Build 1,2 s; kompletter Client-/Serverbuild 15,3 s). Der Vitest-Lauf hing nicht nach fertigen Tests an einem offenen Handle: der Standard-Fork-Pool liess auf dem synchronisierten `G:`-Laufwerk 130 von 136 Dateien `queued` und brach nach rund 9,5 Minuten mit `UNKNOWN: unknown error, read` ab. Worker-, Workflow- und Server-Cleanup-Tests terminierten fokussiert. Ein Worker ohne Dateiparallelitaet lieferte zunaechst den Stabilitaetsnachweis; diese Grenze wurde anschliessend nicht dauerhaft festgeschrieben. `npm run build` ist fuer Client und Server erfolgreich. Keine Fach-, Import-, API-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-17 | Phase-7-Severity-Bedienung um echte Mehrfachauswahl erweitert: Critical, High, Medium, Low und Info lassen sich ueber die Donuts unabhaengig kombinieren und mit erneutem Klick wieder entfernen; der letzte entfernte Wert hebt den Severity-Filter vollstaendig auf. Die Resultliste verwendet die vorhandene ODER-Semantik der Kategorie-Facette. Das Filterfeld zeigt Mehrfachauswahlen in fester Reihenfolge als `Crit-High-Med-Low-Inf` oder entsprechende Teilfolge. 17 fokussierte synthetische Tests sowie Client-/Server-Produktionsbuild erfolgreich; App und Backend liefern HTTP 200. Datahub, Import, API und Persistenz bleiben unveraendert. |
| 2026-08-17 | Phase-7-Darstellung und Filterinteraktion nach Nutzerreferenz korrigiert: fuenf groessere untereinander stehende Severity-Donuts fuer Critical, High, Medium, Low und Info; der bisher aus leeren oder nicht zuordenbaren Quellwerten normalisierte sichtbare `Unknown`-Sammelwert entfaellt. Donuts sind zugreifbare Filterbuttons und markieren die aktive Severity. Arbeitsdiagramme folgen dem persistenten Result-Status, initial `Deviation`; Projekt-, Blatt- und Ansichtswechsel aendern eine bewusste Nutzerauswahl nicht. Datahub bleibt unveraendert eine ungefilterte statistische Timeslot-Uebersicht mit `Results All` und allen Statuskarten. 601 Tests im Gesamtlauf bestanden, zwei durch parallele Windows-Worker-/Dateisystemfehler unterbrochene Suiten anschliessend isoliert mit 7 von 7 Tests bestanden; Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, API-, Persistenz- oder Realdatenaenderung. |
| 2026-08-05 | Bindenden Donut-Standard proportional an das Datahub-Gesamtbild angepasst: Kartenmindesthoehe von 226 auf 196 px, Ring von 158 auf 128 px, Ringstrich auf 11 px, Rackinnenabstand auf 12 px und Kartenabstand auf 8 px reduziert; Titel, Absolutwert und Prozentwert entsprechend kleiner skaliert. Dark-/Lightmode, Sechserausrichtung, Animation und 1180-px-Rahmen bleiben unveraendert. 601 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browsermessung bestaetigt kompakte Rack-, Karten- und Ringproportionen sowie fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Bindenden Donut-Standard nach ausdruecklicher Referenz eingefuehrt: wiederverwendbare DonutMetricCard, gemeinsamer Sechskarten-Rack, grosser animierter 270-Grad-Ring, sichtbarer Nullpunkt, Zentralwert, Prozentwert, farbiger Kopfstrich, Referenztypografie sowie eigene Dark- und Lightmode-Tokens. Datahub auf den Standard umgestellt; Komponentenvertrag, Skill-Assets und eng begrenzte Designpruefungsausnahme fuer Referenzradius und tokenisierte Tiefenschatten ergaenzt. 601 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung mit 0 rohen Farben und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt Referenzproportionen, sechs Karten/Farben/Animationen, Theme-Rollen und fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Timeslotstatus auf sechs animierte 270-Grad-Diagramme erweitert: Results All als feste 100-Prozent-Referenz sowie Deviation, Passed, Not Applicable, Not Run und Error mit Zahl, Anteil und semantischen Tokenfarben. Mehrere ScanRuns des ausgewaehlten Timeslots werden kanonisch aggregiert; reduzierte Bewegung zeigt den finalen Bogen ohne Animation. Responsive Umbrueche auf drei beziehungsweise zwei Spalten ergaenzt. 599 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt sechs Werte, sechs Prozentanzeigen, sechs Animationen, sechs eindeutige Farben, Results All bei 100 Prozent, korrekte Auswahl, Ausrichtung und fehlenden Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Mandantendetail nach ausdruecklicher Bildreferenz neu aufgebaut, ohne Breite oder Position des bisherigen 1180-px-Datahub-Rahmens zu veraendern: grosser Name mit Datum, zwei rein praesentative Rackmodule, Open, Aktionsleiste mit Delete/Import Data/GPO Backup Folder/Save, Master Data mit Name/Consultant/Remarks sowie aufklappbare Scan History je ScanRun mit alleiniger Delete-Aktion. Timeslot-Verwaltung, GPO-Statusliste und Policy-Analysepanel aus diesem View entfernt. 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt 1180 px, deckungsgleiche Ausrichtung, zwei Rackmodule, acht Regler, keine Zusatzpanels und keinen horizontalen Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub nach direktem Ist-/Soll-Bildvergleich auf Bild 2 korrigiert und die vorherige kompakte Zentrierung verworfen: volle Rackbreite, acht sichtbare Mandantenslots mit rein praesentativen `Empty`-Spalten, 66-px-Plusspalte, violetter aktiver Mandant/Timeslot, Timeslotanzahl im Spaltenfuss sowie vier kleine 270-Grad-Zustandsregler in zwei getrennten Paaren. Der grosse Vergleichskasten entfällt; Auswahl ueber Dreieck und Oeffnen ueber Datum bleiben getrennt, der Vergleich startet bei zwei Staenden automatisch. `npm test` 596 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Referenzlayout mittig und inhaltsbasiert begrenzt: die fehlerhafte spezifische Vollbreitenregel entfernt, Rackmodule auf maximal 1180 px zentriert, Historie und Zustandsblock auf `max-content` mit sicherer 100-Prozent-Obergrenze gestellt, Mandantenspalten auf 190 px, Hinzufuegen auf 62 px und die vier Donutspalten auf 148 px begrenzt. Mehrmandanten-Scrollen und bestehende Responsive-Breakpoints bleiben erhalten. Neue statische Layoutregression; `npm test` 596 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Historie auf das korrigierte fachliche Timeslot-Modell umgestellt: ein Mandanten-Bewertungsstand umfasst alle Scannerquellen und den GPO-Snapshot desselben Stichtags. Bestehende vier Scannerlaeufe vom 22.07 werden als eine Zeile projiziert; neue explizite Timeslots koennen im Mandanteneditor angelegt und aktiv ausgewaehlt werden. Importvorschau/-abschluss und GPO-Upload bewahren die Assessment-ID, mehrere Scannerlaeufe werden im selben Assessment fortgeschrieben, Work und Vergleich laden alle Quellen des gewaehlten Stands. Assessment-History-API, Local-/PostgreSQL-Repository und read-only Mehrquellenvergleich ergaenzt. Synthetische Domain-, HTTP-, Client-, Gruppierungs-, Vergleichs- und Darstellungsregressionen: `npm test` 595 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration; reale Mandanteninhalte wurden nicht inspiziert. |
| 2026-08-04 | Datahub-Redesign gemaess Referenz umgesetzt: horizontale Mandanten-/Datums-Matrix, getrenntes Oeffnen und Zwei-Staende-Auswahl, read-only Vergleich ueber persistierte Assessments desselben Mandanten sowie vier SVG-Donut-Zustandsanzeigen fuer offen, behoben, kritisch und geprueft. MITRE- und Baselinekatalog sind rackartig neu dargestellt; bestehende Upload- und Wartungsfunktionen bleiben erhalten. Ein Datumsstand laedt in Work nur den gewaehlten ScanRun. Synthetische Vergleichs-, Projektions- und UI-Grenztests ergaenzt. `npm test`: 591 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt vier Donuts, vier Rackmodule, responsive Einspaltigkeit und keinen horizontalen Seiten-Overflow. Keine Migration oder Persistenzaenderung; reale Mandanteninhalte wurden nicht inspiziert. |
| 2026-08-04 | Phase-13B-Schritt-11 um die projektgebundene Policy-Orchestrierung erweitert: typisierte Backend-Aktionsbereitschaft fuer Reprocessing, Aggregation, Evaluation und Finding Factory; Datahub-Formular fuer neue oder supersedierende Environment Profiles mit Betriebssystem-, optionalem Produkt-, Rollen-, Scope- und Domaenenkontext; explizite Ready-, Review-only-, Completed- und Blocked-Zustaende samt Diagnosecodes. Nur aktive Profil-/Identity-Revisionen, der letzte Processing Run und pro Kontext exakt ausgewaehlte aktive Baselineanalysen werden angeboten. Alle Mutationen verwenden die vorhandenen autoritativen idempotenten Services; Review-only bleibt finding-ineligible, bis jede nachgelagerte Invariante erfuellt ist. Synthetische Bereitschafts-, Supersession-, Baselineauswahl-, HTTP- und Renderregressionen ergaenzt. `npm test`: 588 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; Phase 13B bleibt fuer reale Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs, aktuelle Ergebnisdeduplizierung und Exportdetails in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-11 um eine projektgebundene Policy-Analyseansicht erweitert: typisiertes Backend-Readmodell, read-only API/Client und Datahub-Darstellung fuer Laufhistorie, Evaluationen, bestaetigte Findings sowie severity-freie Konflikt-, Identitaets-, Katalog-, Parser-, Targeting-, Partial- und Factory-Review-Datensaetze. Die UI weist die fehlende RSoP-/GP-Results-Evidenz aus und trennt konfigurierte Abweichungen von tatsaechlich erzeugten Findings. Synthetische Domain-, HTTP-, Client- und Renderregressionen sichern, dass Review und unvollstaendige Evidenz keine Findings werden. `npm test`: 582 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Migration oder Persistenzaenderung; Phase 13B bleibt fuer Profilorchestrierung, reale Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs und Exportdetails in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-10/11 umgesetzt: versionierte fail-closed Finding Factory, Migration 017, gemeinsame Finding-Definitionen mit getrennten Policy-Occurrences, Local-/PostgreSQL-Persistenz, projektgebundene API/Client und `policy-evaluation`-Projektion in das bestehende Unified Result Model. Nur vollstaendig belegte `eligible` konfigurierte Abweichungen werden projiziert; Review, Nichtanwendbarkeit, Konflikte, Parser-/Katalogluecken und manipuliert unvollstaendige Evidenz bleiben ohne Finding. Scope bleibt unbekannt und Wirksamkeit nicht verifiziert. `npm test`: 577 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. PostgreSQL: 8 von 8 gegen isoliertes PostgreSQL 16, Migrationen 001 bis 017 und Factory-Idempotenz verifiziert; Container und synthetische Daten entfernt. UI und reale Regel-/Inbox-ADMX-Kuratierung bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-9/11-Vertikalschnitt umgesetzt: versionierte typisierte Comparatorbibliothek, konservative Evaluation Engine sowie Migration 015 fuer Evaluation Runs, Baselinequellen, PolicyEvaluationResults und Mehrquellen-Evidenz integriert. Ein Run bindet Aggregation, Profilrevision und eindeutige Baselineanalysen; nur vollstaendige Evidenz und eindeutiger Consensus koennen eine bestaetigte konfigurierte Abweichung als finding-berechtigt klassifizieren. Unvollstaendigkeit, Konflikt, Katalogluecke, Mehrdeutigkeit und Unvergleichbarkeit bleiben Review; Wirksamkeit bleibt unbekannt und projectedFindingCount ist relational null. Local-/PostgreSQL-Repositories, API und Client bieten Auswertung und Liste mit deterministischer Idempotenz. `npm test`: 564 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die komplette PostgreSQL-Suite lief gegen eine frische PostgreSQL-16-Instanz mit 8 von 8 Tests erfolgreich; Migrationen 001 bis 015, Evaluationpersistenz, Idempotenz und Projektloeschung wurden synthetisch verifiziert, Testcontainer und Testdaten entfernt. Reale Baselinepakete bleiben wegen fehlender Windows-Inbox-ADMX-Kataloge partial und damit review-only. Dependency-/Override-/Risikoregeln, explizite Nichtanwendbarkeit, Finding-Erzeugung, Unified-Result-Projektion und UI bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-Schritt-8/11-Vertikalschnitt umgesetzt: Migration 014, unveraenderliche revisionsverkettete Environment Profiles, persistente versionierte Snapshot-Aggregationslaeufe mit expliziten Identity-Analysis-Quellen und konservative Registry-Policy-Zustandsreduktion integriert. Reihenfolge, Delete, Scope, Domaene, Snapshotkonsistenz und GPO-uebergreifende Konflikte werden beruecksichtigt; unvollstaendige, unaufgeloeste, getargetete oder vorzustandsabhaengige Faelle bleiben Reviewhinweise. API und Client bieten Profilanlage/-liste sowie Aggregation/-liste. Die Stufe setzt Wirksamkeit immer auf unbekannt und erlaubt niemals Findings. npm test: 551 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Produktionsbuild erfolgreich. Die vollstaendige PostgreSQL-Suite lief gegen eine frische PostgreSQL-16-Instanz mit 8 von 8 Tests erfolgreich; der kurzlebige Container samt synthetischer Testdaten wurde entfernt. Phase 13B bleibt bis typisierter Evaluation, Consensus/Risiko, Ergebnis-/Evidenzpersistenz und Unified-Result-Projektion in Arbeit. |
| 2026-08-04 | Phase-13B-Schritte 6/7/11 produktiv angebunden: Migration 013, Local-/PostgreSQL-Repositoryvertraege, begrenzte GPO-Identity- und Microsoft-Baseline-Workerpfade, atomare Analysepersistenz, deterministische Idempotenz/Supersession, Restart-Reconciliation sowie projekt- und referenzdatengebundene Read-/Reprocess-APIs implementiert. Synthetische Tests decken technische Aufloesung, `not-found`, Baselinekataloge, Crash-Retry, Reprocessing und stale-predecessor-Konflikte ab. `npm test`: 543 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ein synthetischer Fresh-PostgreSQL-Test ist ergaenzt, seine reale Ausfuehrung bleibt mangels lokalem Image und nicht freigegebenem externen Download offen. Phase 13B bleibt in Arbeit; Snapshotaggregation, Environment Profile, Evaluation und Result-Projektion sind nicht als abgeschlossen markiert. |
| 2026-08-04 | Phase-13B-Schritt-6/7-Analysevertrag umgesetzt: stabile technische Registry-Zielidentitaet aus Scope/Hive/Schluessel/Ziel, getrennte optionale ADMX-Referenz aus Zielnamespace/Policy/Element sowie lokalisierungsneutrale ADML-Ressourcen. Ein begrenzter read-only ADMX-/ADML-Parser und ein selektiver Microsoft-Baseline-ZIP-Adapter verarbeiten ausschliesslich Backup.xml, Registry.pol, ADMX und ADML; XLSX/PDF/Skripte bleiben opak. Baseline-Registryeinstellungen laufen durch denselben PReg-Parser und Reducer wie GPMC-Backups, einschliesslich Byteoffset-Provenienz und fail-closed Typpruefung. 537 Standardtests, Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen. Die 11 freigegebenen unveraenderten Dummy-Baselineoriginale wurden read-only ohne Persistenzmutation geprueft: 11/11 Pakete erfolgreich, 79 GPO-Backups, 89 Registry.pol-Dateien, 3.580 stabile technische Einstellungen, davon 185 eindeutig an mitgelieferte ADMX-Definitionen gebunden. Alle Analysen bleiben bewusst partial, weil Microsoft nur ergaenzende und keine vollstaendigen Windows-Inbox-ADMX-Kataloge mitliefert. Worker-/Repository-Persistenz, Kunden-Reprocessing und Evaluation bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase-13B-`Registry.pol`-Vertikalschnitt umgesetzt: begrenzter read-only PReg-Parser, geordnete typisierte Registry-Instruktionen, Delete-/SecureKey-/Soft-Semantik, Byteoffset-Provenienz und bestehende unveraenderliche Beobachtungspersistenz. Der reale GPMC-Kompatibilitaetsfall REG_NONE wird nur als leere Schluesselanlage akzeptiert; andere nicht freigegebene Typen bleiben blockiert. 532 Standardtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Der unveraenderte freigegebene Mandantenbestand wurde ohne Persistenzmutation ueber den Produktionsworker geprueft: ein Quellartefakt mit korrekter Integritaet, drei Backups, eine von einer `Registry.pol`-Datei unterstuetzt, vier technische Registry-Beobachtungen und keine Integritaets-, Worker- oder Blockierungsfehler. ADMX-/Baseline-Identitaet und PolicyEvaluation bleiben offen; Phase 13B bleibt in Arbeit. |
| 2026-08-04 | Phase 13B um sichtbare GPO-Scan-Historie und Microsoft-Security-Baselinekatalog erweitert. Dummy zeigt nun fuenf Scanberichte und eine eigene GPO-Zeile mit drei Backupinstanzen. Migration 011, globale Repository-/API-Persistenz, privater SHA-256-Artefaktspeicher, ZIP-Mehrfachupload, Deduplizierung, Metadatenerkennung sowie fail-closed Auswahl (`selected`, `no-match`, `ambiguous`) implementiert. Baselineoriginale sind in der Orphan-Reconciliation referenziert. Real verifiziert: Migration angewendet, Baseline-API HTTP 200, leerer Katalog `no-match`, Datahub zeigt Katalog und GPO-Zeile. 523 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Integrationstests uebersprungen. Einstellung-gegen-Einstellung-Evaluation bleibt offen. |
| 2026-08-04 | Baseline-Metadatenerkennung nach realem Abgleich der 11 freigegebenen Originalpakete korrigiert. Migration 012 speichert 11 unveraenderliche Klassifikationsrevisionen fuer 11 Originalpakete; kombinierte Windows-10-/Windows-Server-ZIPs besitzen mehrere Produktkontexte, Microsoft 365 Apps wird als Version 2512 erkannt. Alle hochgeladenen Dateien stimmen per SHA-256 bytegenau mit den Originaldownloads ueberein. Auswahltests fuer Windows Server 2016, Windows 10 1809, Windows Server 20H2 und Microsoft 365 Apps 2512 liefern jeweils genau ein erwartetes Paket; Datahub zeigt alle 11 Kontexte korrekt. 524 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Einstellung-gegen-Einstellung-Evaluation bleibt offen. |
| 2026-08-04 | GPO-Inventarstatus aus Mandanten-Berichtzaehler und Linked Scan Reports entfernt. Der freigegebene Dummy fuehrt wieder vier echte Scanberichte; die drei GPO-Backupinstanzen bleiben getrennt unter GPO Processing mit ihrem Teilstatus sichtbar. Ein GPO-Bericht darf erst aus einem persistierten Baseline-Evaluation-Run entstehen. Zwei neue Regressionen sichern diese Darstellungsgrenze. 526 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Keine Daten- oder Schemamigration. |
| 2026-08-04 | GPO-Uploadsemantik korrigiert: Ein hochgeladener Hauptordner ist ein Mandanten-GPO-Backup-Snapshot, die drei Dummy-Unterordner sind drei enthaltene GPOs. Ingestion vergibt eine gemeinsame selected-gpos-Set-ID; Snapshotbildung gruppiert auch bestehende unveraenderliche Datensaetze ueber das gemeinsame Quellartefakt. Status-API und UI zeigen 1 Mandanten-GPO-Backup mit 3 GPOs; der bisherige technische Zaehler bleibt nur als kompatibler Alias. Keine Vollstaendigkeits-, Link-, Scope- oder Wirksamkeitsbehauptung. 526 Tests, Local-only- und Designpruefung sowie Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests uebersprungen. Keine SQL-Migration. |
| 2026-08-04 | Phase-13B-GPMC-Kompatibilitaet nach realer, ausdruecklich freigegebener Dummy-Pruefung nachgehaertet: synchrone Parserablehnungen verlassen den Worker nicht mehr als generischer Absturz; GPMC-Zeiten ohne Offset bleiben als Zeitzonenluecke `partial`, ohne separat belegte Identitaet und Domaene zu verwerfen. Die fachfremde XLSX im Auswahlroot bleibt als verschachteltes Archiv sicher abgewiesen. Die 13 GPO-Backupdateien wurden ueber den Produktionsworker und die reale API in Dummy persistiert: drei Backupinstanzen, drei aufgeloeste Identitaeten und Domaenen, drei vollstaendige Inventare, 47 Policy-Beobachtungen, Status `partial`, ein Versuch, kein Fehlercode. Der lokale private Artefaktspeicher ist auf NTFS ausserhalb des Webroots konfiguriert. 519 Standardtests, Local-only- und Designpruefung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen. Phase 13B bleibt in Arbeit. |
| 2026-08-02 | Phase-7-Result-Cluster nach Nutzerreferenz angepasst: Jeder Minimierungsvorgang parkt den Cluster viewport-sicher bei 80 px rechts und 76 px oben; der minimierte Cluster bleibt danach verschiebbar. Der Reader-Results-Button übernimmt bei offenem Fenster dessen individuelle Result-Farbe, identisch zur vorhandenen Kachelmarkierung. Zwei synthetische Regressionen für Parkkoordinaten und Buttonfarbe ergänzt; 21 fokussierte Tests sowie die Client-Typescript-Prüfung bestanden. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Result-Fenster nach Nutzerkorrektur bereinigt: Den falschen Zeichenrest aus der Titeltrennung durch einen eindeutigen Unicode-Gedankenstrich ersetzt, die Quellblattüberschrift und den fehlerhaft kodierten sichtbaren Minimieren-Button entfernt. Der Finding-Titel bleibt auf ausdrücklichen Nutzerwunsch zusätzlich als Überschrift im Rumpf erhalten. Doppelklick auf die freie Kopfzeile minimiert beziehungsweise stellt wieder her. Drei synthetische Regressionen decken Titeltrennung, fehlenden Button, unterdrückte Blattüberschrift und die zusätzliche Finding-Überschrift ab; 19 fokussierte Tests sowie die Client-Typescript-Prüfung bestanden. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Result-Cluster korrigiert: Minimierte Result-Fenster werden nicht mehr ausgeblendet, sobald ein Result maximiert ist, sondern verbleiben als 14-px-Reiter im Cluster und erhalten eine sichtbare Farbkante. Das Herausziehen des maximierten Fensters ist damit unabhängig vom minimierten Stapel erkennbar und bedienbar. Eine zusätzliche synthetische Renderregression prüft den minimierten Farbreiter. Die vollständige lokale Unit-Suite läuft über die funktionsfähige JavaScript-Testkonfiguration mit 102 bestandenen Testdateien und 487 bestandenen Tests; 7 optionale PostgreSQL-Tests werden übersprungen. Client-Typescript-, Local-only- und Designprüfung sind erfolgreich. Vollständiger npm-test- und Build-Lauf bleibt durch einen vorhandenen Syntaxfehler in vite.config.ts (Zeile 17) blockiert; keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
|---|---|
| 2026-08-05 | Vier Datahub-Regler fachlich an den zuletzt angewählten Mandanten-Timeslot gebunden und in `Results All`, `Deviation`, `Passed`, `Error` umbenannt. Alle Scannerlaeufe des Timeslots werden gemeinsam aus kanonischen Finding-Vorkommen gezaehlt; das bestehende Abweichungspraedikat trennt fachliche Abweichungen von technischen Errors. Neuester vorhandener Timeslot wird auch bei nur einem Stand standardmaessig ausgewaehlt; mittlere Trennlinie und Einheiten entfernt. 599 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browserpruefung bestaetigt Auswahlbindung, vier numerische Werte, korrekte Labels, 1180-px-Ausrichtung und keinen Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-05 | Datahub-Uebersicht nach neuester ausdruecklicher Bildreferenz innerhalb des unveraenderten zentrierten 1180-px-Rahmens neu aufgebaut: acht Mandantenslots plus schmale Plusspalte, vier rein praesentative Transpose-/Detune-Regler, MITRE-Rack mit 3x3-Matrixmarke sowie Microsoft-Baseline-Rack mit `BASELINES`-Liste und Referenzbeschriftungen. Alte Donuts und das Mandanten-Zusatzmenue entfernt; vorhandene Auswahl-/Oeffnen-, MITRE-JSON- und Baseline-ZIP-Funktionen bleiben erhalten. 598 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Inhaltsfreie Browsermessung bestaetigt vier deckungsgleiche Racks mit 1179,98 px, acht Slots, vier Regler, neun MITRE-Felder und keinen Seiten-Overflow. Keine Daten-, API- oder Persistenzaenderung. |
| 2026-08-02 | Phase-7-Result-Cluster bei kurzem Inhalt korrigiert: Ein maximiertes, weiterhin angedocktes Result erhält nun mindestens die gemeinsame Stapelhöhe aller dahinterliegenden minimierten Kopfzeilen. Dadurch bleiben außer den vorgesehenen 14-px-Farbreitern keine unteren Result-Titelleisten sichtbar. Die Mindesthöhe ist am verfügbaren Viewport begrenzt; frei herausgezogene Fenster bleiben unverändert. Die 34-px-Stapelhöhe wird für Position, Clustergrenze und Abdeckung zentral geteilt. Zwei synthetische Geometrie-/Renderregressionen ergänzen den kurzen Acht-Fenster-Fall und den Viewport-Grenzfall. 105 Testdateien mit 517 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Purple-Knight-Statusanzeige korrigiert: Reader, Datensatzkarte und Kachel verwenden nun dieselbe profilgesteuerte Statusauswahl. Das Purple-Knight-Profil priorisiert `Status` vor `Result`, sodass eine dort wiederholte SI-Kurzkennung nicht länger als Status erscheint. Rein visuelle Regeln beschriften `Pass` mit `Passed` und `IOE Found` mit `Failed`, ohne Originalwerte oder Provenienz anzutasten; Rohberichte mit ausschließlich `Result` bleiben kompatibel. Synthetische Regressionen sichern beide Datenformen, beide Beschriftungen und alle drei Darstellungen. 105 Testdateien mit 515 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-CIS-CAT-Result-Hierarchie und Assessment-Markierung nach Nutzerpräzisierung vervollständigt: Framework-Versionen erscheinen einmal als Hauptüberschrift ihrer Tabellengruppe; jeder Control-Listenpunkt wird direkt zur Überschrift seiner Tabelle. Zusätzlich markiert das CIS-CAT-Profil `No matching system items were found.` über `resultSheetHighlightedRowPatterns` mit derselben `rich-text-table-row--evaluated`-Darstellung und denselben blauen Evidence-Tokens wie bereits ausgewertete Tabellenzeilen. Die generische Tabellenkomponente erhält nur die profilgesteuerte Markierungsentscheidung; bei anderen Werkzeugen bleibt derselbe Text unverändert. Mehrere Controls derselben Version, zukünftige Frameworks, unvollständige Tabellenzuordnung sowie die echte Hinweiszeile sind synthetisch regressionsgeprüft. 105 Testdateien mit 506 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Results global verdichtet: Die äußeren Kästen um Ergebnisüberschrift und Tabelle wurden aus dem gemeinsamen `.result-block` entfernt (`padding: 0`, `border: 0`, transparenter Hintergrund). Tabellenzelllinien, fachliche Haupt- und Tabellenüberschriften sowie die blaue Evidence-Markierung bleiben unverändert. Ein neuer synthetischer CSS-Vertrag verhindert die Rückkehr der platzraubenden Containerform. 105 Testdateien mit 507 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, API-, Server-, Datenbank- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phasen-10/13-Entwicklungsstart nachgehärtet: `npm run dev` startet über `scripts/dev-local.mjs` den vollständigen lokalen Stack. Der Starter verwendet ausschließlich inhaltsfreie Health-Signale, übernimmt ein bereits gesundes Backend oder baut und startet ein fehlendes Backend über `vite.server.config.ts` auf `127.0.0.1:4173`; der Client über `vite.client.config.ts` folgt erst nach erfolgreicher Health-Prüfung fest auf `127.0.0.1:5173`. `npm run dev:client` bleibt als eindeutig benannter Client-only-Weg. Lokale Backend-Dokumentation repariert und ergänzt; eine dritte synthetische Konfigurationsvertragsregression schützt Reihenfolge, Adressen und Konfigurationsgrenzen. `npm test` mit 105 bestandenen Testdateien und 499 Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie `npm run build` für Client und Server erfolgreich; Test und Build liefen parallel ohne Kollision. Keine Import-, Persistenz-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Dreiecksdarstellung nach Nutzerkorrektur vervollständigt: Spezifischere Filter-, Hover-, Dashboard- und Graph-Styles verwenden für Select-Zustände nur noch `background-color` und löschen dadurch die zentrale SVG-Dreiecksmarkierung nicht mehr. In Result-Titelleisten ersetzt das individuelle farbige Zustandsdreieck den Würfel vollständig; minimiert zeigt es nach rechts, maximiert nach unten, und der Klick verwendet denselben Minimieren-/Wiederherstellen-Pfad wie der Kopfzeilen-Doppelklick. Ein zusätzlicher synthetischer CSS-Vertrag sowie erweiterte Result-Render-/Interaktionsregressionen schützen Sichtbarkeit, Farbe, Richtung und Funktion. 105 Testdateien mit 500 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich; Test und Build liefen parallel ohne Kollision. Keine Import-, Persistenz-, Server-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phasen-10/13-Buildnachhärtung umgesetzt: Die zuvor gemischte und syntaktisch beschädigte `vite.config.ts` ist durch getrennte Client-, Server- und Testkonfigurationen ersetzt. Client (`dist`, `.vite-client`), Server (`dist-server`, `.vite-server`) und Vitest (`.vite-tests`) besitzen isolierte Zuständigkeiten; Dev-, Build-, Watch-, Standard- und PostgreSQL-Testskripte wählen ihre Datei explizit. Ein schmaler `vite.config.ts`-Clientalias erhält Kompatibilität für Claude Code, Gemini, IDE-Plugins und andere generische Vite-Aufrufe. Die Test-Include-Regel erfasst ausdrücklich `.test.ts` und `.test.tsx`. Zwei synthetische Konfigurationsvertragsregressionen ergänzt. `npm test` mit 105 bestandenen Testdateien und 498 Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only- und Designprüfung sowie `npm run build` für Client und Server erfolgreich; Test und Build liefen zusätzlich parallel ohne Kollision, alle vier Konfigurationsdateien sind typgeprüft. Veraltete generierte `vite.config.js`-/`vite.config.d.ts`-Artefakte und die Node-Buildinfo wurden entfernt; `tsconfig.node.json` verhindert neue Emits. Ein generischer `vite build` ohne `--config` lief erfolgreich über den Kompatibilitätsalias; seine temporäre Ausgabe wurde entfernt. Keine Import-, Persistenz-, API-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Darstellung nach Nutzerreferenz korrigiert: Minimierte Results parken nicht mehr im Filter-/Statusband, sondern bei jedem Minimieren 80 px vom rechten Viewportrand und 46 px unterhalb der gemessenen Arbeitsflächen-Oberkante; kurze Viewports bleiben geklemmt. Funktionale Richtungsanzeigen in Reader-, Such- und Sidebarnavigation, Datahub-Zurückweg, DB-/Result-Aufklappern, Finding-Details und nativen Selects verwenden jetzt dieselbe gefüllte, schriftunabhängige Dreiecksgeometrie; die fehlerhaft dekodierten Reader-Zeichen entfallen. Zwei neue synthetische Regressionen plus angepasste Reader-Verträge; 104 Testdateien mit 496 bestandenen Standardtests, 7 erwartungsgemäß übersprungenen optionalen PostgreSQL-Tests, Local-only-, Design- und Client-Typprüfung sowie Client- und Server-Produktionsbuild erfolgreich. Der normale npm-test-Einstieg bleibt unabhängig von dieser Änderung durch den vorhandenen Syntaxfehler in vite.config.ts Zeile 17 blockiert; der identische vollständige Vitest-Lauf wurde über die intakte Server-Konfiguration ausgeführt. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-13A-Result-Linker werkzeugsicher nachgehärtet: Maester-Findings können keine CIS-CAT-Detailblätter mehr übernehmen. Der Linker ermittelt die Finding-Herkunft aus Blattmetadaten oder Source: Scan, verwirft ausdrücklich abweichende toolIds bei direkten und unscharfen Verweisen und bewertet freien Ergebnistext nicht mehr als Dateiverweis; nur Datei- und stabile Regel-ID-Verweise bleiben für die unscharfe Zuordnung zugelassen. Echte CIS-CAT-source-table- sowie Purple-Knight-Datei-/SI-ID-Links bleiben regressionsgeprüft. Drei neue ausschließlich synthetische Kreuzverknüpfungstests ergänzt. 485 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Persistenz-, Schema-, Importdaten- oder Realdatenänderung; kein Reimport erforderlich. |
| 2026-08-02 | Phase-7-Result-Fenster um Kopfzeilen-Doppelklick ergänzt: Doppelklick auf ein minimiertes Result stellt es wieder her, Doppelklick auf ein maximiertes Result minimiert es über denselben bestehenden Zustandsübergang. Bookmark-, Minimieren-, Matrix-/Report- und Schließen-Buttons sind vom Kopfzeilen-Doppelklick ausgeschlossen und behalten ihre Funktionen. Ein echter synthetischer DOM-Test prüft beide Richtungen und die Button-Ausnahme. 482 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-08-02 | Phase-7-Result-Cluster nach Nutzerkorrektur nachgeschärft: Beliebig viele aus dem Cluster gezogene Results können gleichzeitig maximiert bleiben; Öffnen, Wiederherstellen, Datensatzauswahl und Matrix-/Report-Wechsel verändern entkoppelte Fenster nicht. Erst Minimieren führt ein Fenster in den Cluster zurück. Das Zielbild verwendet hinter dem aktiven Fenster nur noch 14 px breite vertikale Farbreiter statt horizontal sichtbarer Results-Beschriftungen. Cluster und freie Fenster werden bei Öffnen, Verschieben, Skalieren und Viewport-Änderung vollständig innerhalb der Anzeige gehalten; übergroßer Inhalt scrollt im Fenster. Sechs synthetische Zustands- und Renderregressionen ergänzt. 481 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only- und Designprüfung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Import-, Persistenz-, Server-, Datenbank- oder Realdatenänderung. |
| 2026-07-31 | Schlüssel/Wert-Tabellen ohne Kopfzeile: Die CIS-Control-Tabellen zeigten im Results-Fenster eine einzige Spalte „Label:" mit der Zeile „Description:" und keinen einzigen Wert. Eine `table.enum` ist eine reine Schlüssel/Wert-Tabelle mit spaltenübergreifender Titelzeile; `detectHeaderRow` machte den Wert der längsten Zeile zur Spaltenüberschrift und verwarf alles darüber. `analyzeRows` erkennt sie jetzt an zwei Spalten mit durchgängigen Bezeichnern auf Doppelpunkt, vergibt `Feld`/`Wert` und behält jede Zeile; die Titelzeile bleibt Titel. Wirkt erst mit erneutem Import, weil Quelltabellen aus der Analyse persistiert werden. 464 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only-, Designprüfung und Client-/Serverbuild grün. Am freigegebenen Dummy nach Neuimport bestätigt: Regel 17.7.5 zeigt beide Steuerungstabellen vollständig mit Werten (V7.0 vier Angaben, V8.0 sechs). Bekannter Rest ohne Informationsverlust: im bounded-lexical Pfad fällt die äußere Complex-Check-Tabelle wegen ihrer dreispaltigen ersten Zeile aus der Erkennung; ihr `Criterion:` steht vollständig im folgenden Block. Keine SQL-Migration. |
| 2026-07-31 | Phase-13A-CIS-CAT-Results-Verknüpfungskorrektur: Am freigegebenen Dummy führte eine einzelne Regel 3.294 Zeilen aus rund 50 identischen Belegtabellen. Ursache war der Ergebnis-Linker: in der Projektansicht trägt `record.sourceFile` den Projektnamen, nicht die Quelldatei, der exakte `source-table:`-Verweis fand deshalb kein Blatt und die Namensähnlichkeit zog jede gleichnamige Tabelle des Berichts herein. Der Linker nutzt jetzt das Provenienzfeld „Quelle: Datei" und behandelt einen Quelltabellenverweis als abschließend — ohne Treffer bleibt das Ergebnis leer statt Ersatz zu erfinden. Dazu zwei nur real sichtbare Beschriftungsfehler behoben: Aufklappblöcke, die Bedienwort und Bezeichnung auf `span.action`/`span.caption` verteilen (dadurch entstand keine Marke und die Belegtabellen erbten „Impact"), und fette Steuerungen mit Doppelpunkt innerhalb der Zuordnungsliste, die als Abschnittsüberschrift galten. References ist über seinen Behälter von den Zuordnungen getrennt; die Fixture bildet alle drei realen Strukturen ab. 463 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only-, Designprüfung und Client-/Serverbuild grün. Am freigegebenen Dummy neu eingelesen (411 Occurrences, überholter Lauf entfernt, wieder vier Scanberichte): Regel 17.7.5 zeigt 130 statt 3.294 Zeilen in sieben korrekt benannten Blöcken, ohne XML und References im Fenster, mit geschlossenem XML-Detail im Reader. Keine SQL-Migration. |
| 2026-07-31 | Phase-13A-CIS-CAT-Results-Vollständigkeit: Alle verlinkten und im Bericht nur aufgeklappten Inhalte erscheinen im Results-Fenster. Die Abschnittszuordnung liest ihre Überschriften wörtlich aus dem Bericht (Aufklappverweise und fette Überschriften mit Doppelpunkt) statt aus einer festen Liste; eine neue Fassung wie „CIS Controls V8“ oder ein fremdes Rahmenwerk wird dadurch richtig benannt statt als „Rule Result XML“ aussortiert und samt Tabelle verloren zu gehen. XML-Doppeltabellen werden über ihren Behälter ausgeschlossen. Neues Feld `Control Mappings` mit dem bisher nie ausgegebenen Zuordnungstext ohne die Bedienbeschriftung „More“; Detailtabellen ohne Caption übernehmen ihre Kopfzelle als Namen. Neues profilgetriebenes `resultSectionHeaders` bringt `Control Mappings` als benannten Abschnitt in das Fenster und blendet das Feld im Reader aus. Das Rule Result XML bleibt auf Nutzerkorrektur vom selben Tag ein geschlossenes Detail im Finding und erscheint im Fenster an keiner Stelle; Legacy-Sammelfelder bleiben ohne Reimport lesbar. Das Fenster trägt jetzt beliebig viele benannte Abschnitte statt eines einzelnen Textes, in Datensatz- und Graphansicht gleich. 460 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only-, Designprüfung und Client-/Serverbuild grün. Neue synthetische Fixture mit neuer CIS-Fassung und fremdem Rahmenwerk sichert die Regression bis in die gerenderte Fensterausgabe. Keine visuelle Abnahme an realen Daten; neue Felder entstehen erst beim nächsten Import. Keine SQL-Migration. |
| 2026-07-30 | Phase-13B-Result-DB-Abweichungs- und Titelkorrektur: Das versionierte Prädikat 1.1.0 zählt `fail` unabhängig von IOE als Abweichung; CIS-CAT-Compliance-Checks bleiben IOE Nein und werden Abweichung Ja. PostgreSQL-Vorfilter, Projektion, Facetten und Filter verwenden identisch `fail`/`warning`. Importregression sichert Benchmark Item als FindingDefinition-Titel und schließt Quelle: Datei/Dateiname aus. 443 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only-, Designprüfung und Client-/Serverbuild grün. Im freigegebenen Dummy bestätigt: Regel 2.2.2 mit vollständigem Titel, fail/Ja, kein Quelle-Datei-Titel sowie funktionsfähiger Ja-(323)-Filter mit 323 Treffern. Keine SQL-Migration und kein Reimport. |
| 2026-07-30 | Phase-13A-CIS-CAT-Results-Darstellungskorrektur: Results zeigt nur noch verlinkte Assessment-Evidence- und CIS-Control-Tabellen; Finding-Fließtext bleibt im Finding. Rule Result XML ist dort standardmäßig geschlossen und fehlt im Results-Fenster. Legacy-Sammelfelder bleiben ohne Reimport lesbar; neue Importe speichern XML separat. Blattspezifische Profilwahl korrigiert in gemischten Projekten den Titel auf Benchmark Item. 440 Standardtests bestanden, 7 optionale PostgreSQL-Tests übersprungen; Local-only-, Designprüfung und Client-/Serverbuild grün. Im freigegebenen Dummy an Regel 2.2.2 mit vollständigem Titel, geschlossenem XML und acht verlinkten Results-Blöcken ohne Volltext/XML visuell bestätigt. Keine SQL-Migration. |
| 2026-07-30 | Phase-13A-CIS-CAT-Results-Nachhärtung: Interne `#detail-*`-Verweise werden durch einen eigenen Source Extractor verlustfrei in 411 Candidate-Findings aufgelöst; `Benchmark Item`/Rule ID ersetzen den falschen W-/1.0-Titel. Description, Rationale, Remediation/Impact, Assessment Evidence, Rule Result XML, References und CIS Controls V7/V8 erscheinen über sicheren Klartext und exakt dateigebundene SourceTable-Referenzen im Results-Vertrag; verschachtelte bounded-lexical Tabellenindizes sind korrigiert und XML-Doppeltabellen ausgeschlossen. Strukturierte Originalwerte und Provenienz bleiben erhalten. 437 Standardtests, Local-only- und Designprüfung sowie Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests übersprungen. Realer freigegebener Dummy-Preflight: 411 Findings, 1.815 Quelltabellen und für Regel 2.2.2 sechs Evidence- plus zwei Control-Tabellen. Zwei alte CIS-CAT-Testläufe wurden durch einen geprüften Lauf ersetzt; Dummy enthält wieder vier Scanberichte. Visuelle Work-Popup-Abnahme durch Browser-URL-Policy blockiert, Daten-, Projektions- und Readervertrag automatisiert und real technisch verifiziert. Keine SQL-Migration. |
| 2026-07-29 | Appweite Kopfsektion als gemeinsamer `div`-Container umgesetzt (Phase 7, reine Präsentation): Work-Werkzeugleiste, Filter und Status wurden aus zwei Shell-Ebenen in `.app-header-panel` zusammengeführt; Datahub, DB-Struktur, Result DB und Graph verwenden dieselbe Hülle, der Graph behält sein zustandsführendes Portal. Kopf- und Inhaltscontainer nutzen gemeinsam `--surface-app` und 10 px Rundung; die linke und rechte Kante sind an der Inhaltsfläche ausgerichtet. Alte leere Workspace-Header entfallen. Nach einer Nutzerkorrektur wurde die tatsächlich fehlende `.reader-toolbar`-Flexregel ergänzt und `.toolbar` von flächenfüllendem Wachstum auf ihre ursprüngliche Inhaltsbreite zurückgestellt. Damit stehen Zähler und Werkzeugleiste wieder gemeinsam und ohne große Zwischenlücke auf der ersten Zeile; Filterband und Statusinformationen behalten die zweite beziehungsweise dritte Zeile. Der statische Preview-Build wurde anschließend neu erzeugt; der Designvertrag erzwingt nun sowohl die Flexzeile als auch `flex: 0 0 auto` für die Werkzeugleiste. Keine Import-, Persistenz-, Server- oder Datenänderung. Verifiziert mit 420 Standardtests (7 optionale PostgreSQL-Tests übersprungen), Local-only-Prüfung, Designprüfung, Client-/Server-Produktionsbuild und inhaltsfreier Browsermessung (genau ein Kopfcontainer, korrekter Hintergrund/Radius, keine Überlagerung, keine Konsolenfehler). |
| 2026-07-28 | Der Nutzer erklärt den aktuellen `Work`-Stand (Dark und Light) zum verbindlichen Wunschdesign des gesamten Assessors; Funktionen bleiben unangetastet. Erste Angleichung genau der Abweichungen, die sich gegen diese Referenz **messen** lassen — ermittelt über berechnete Stile aller fünf Bereiche, weil in dieser Umgebung keine Screenshots möglich sind (Browser-Pane wird nicht dargestellt). (1) Der Systemstatus-Block der Sidebar (`.sidebar-context`/`.sidebar-server-card`, `App.tsx`) entfällt: er erschien nur auf drei von fünf Bereichen und wiederholte dabei die Verbindungsanzeige, die die Topbar auf genau diesen Bereichen ohnehin trägt (`.area-topbar` mit `.connection-pill`); in `Work` steht der Zustand in der Statuszeile. Die Sidebar trägt damit wie in der Referenz ausschließlich Navigation, ohne Informationsverlust. (2) Datahub führte den Seitennamen dreifach: Topbar, Hero-Überschrift (21,5 px) und Sektionsüberschrift der Liste. Eyebrow und Hero-Überschrift entfallen in beiden Hero-Abschnitten; Einordnungszeile und Aktionen bleiben. Damit trägt keine Ansicht mehr einen Inhaltstitel über 18 px, `Work` hat keinen. (3) Die Graph-Filter waren als einzige Ansicht 40 px hoch mit `--ui-body-size`; sie verwenden jetzt `--control-height` und `--ui-control-size` wie die Filter im Command Band von `Work`. Verifiziert mit `npm test` (420/420 bestanden), `npm run build`, Designprüfer (0 rohe Farbwerte, verbotene Muster von 40 auf 39 gesunken) sowie einer Messung aller fünf Bereiche in Dark und Light: kein Sidebar-Statusblock mehr, keine Inhaltstitel über 18 px, Graph-Filter 30 px/13 px identisch zu `Work`, Seitentitel und Verbindungszustand weiterhin in der Topbar, keine Konsolenfehler. Offen bleiben die strukturellen Punkte der Korrekturliste (`review-checklist.md` §6.4 Datahub als Tabellenarchetyp, §6.5 Inspector und Virtualisierung in Ergebnisse, §6.6 Graph-Karten): sie ändern Aufbau und Bedienung und brauchen eine ausdrückliche Freigabe, weil der Auftrag Funktionen ausdrücklich unangetastet lässt. |
| 2026-07-28 | Die Maester-Ergebnisdarstellung wird auf Nutzerentscheidung zur verbindlichen Ergebnisform des gesamten Assessors, unabhängig vom Scanbericht; dabei kam ein Abschneidefehler zutage. (1) Jedes Ergebnis — werkzeuggelieferter Text wie verknüpftes Blatt — steht jetzt im selben Ergebnisblock (`.result-block`: neutraler Kasten `--panel`/`--line`, Titel in `--ui-reading-heading-size`), und jede Ergebnistabelle trägt dieselbe Darstellung (`.rich-text-table` in `.rich-text-table-wrap`: Zellrahmen rundum, Versalienkopf auf `--surface-inset`, oben ausgerichtet). Verknüpfte Blätter verwendeten zuvor die allgemeine Tabellenform mit klebendem Kopf und Unterstreichungen und sahen dadurch je nach Werkzeug anders aus. (2) **Abschneidefehler behoben:** `.results-window` definierte seine Rumpfzeile als `minmax(0,auto)`. Die Zeile wuchs damit auf die volle Inhaltshöhe (bei 78 Ergebniszeilen 2607 px in einem 635 px hohen Fenster), das Fenster schnitt sie über `overflow: hidden` ab, und der Rumpf bekam nie eine Rollfläche — lange Ergebnistabellen brachen ohne jeden Hinweis ab. Mit `minmax(0,1fr)` bleibt das Fenster bei kurzem Inhalt inhaltshoch und begrenzt den Rumpf an der Fenstergrenze, sodass er rollt. (3) `min-width: 0` auf `.linked-results` und `.result-block`: ohne diese Angabe wuchs das Rasterelement auf die Inhaltsbreite seiner breitesten Tabelle, der Tabellenbehälter wurde nie schmaler als sein Inhalt und rollte deshalb nicht selbst — stattdessen rollte das gesamte Fenster seitlich. (4) Überlaufende Ergebnisbehälter deklarieren eigene Scrollbalken (`--line-strong` auf `--surface-inset`, 11 px) und schalten damit die überlagerten, erst beim Scrollen sichtbaren Balken ab: sobald der Inhalt überläuft, ist die Rollfläche dauerhaft sichtbar, weil eine nur teilweise sichtbare Tabelle sonst wie eine abgeschnittene aussieht. Der Vertrag ist als Abschnitt 17 „Ergebnisblock (Results)" in `.claude/skills/assessor-ui/references/components.md` verankert und in Abschnitt 12 (Floating Window) verlinkt; er ersetzt dort die frühere Zusage „Inhalt ist immer eine `.table`". Verifiziert mit `npm test` (420/420 bestanden, zwei neue Regressionen in `linked-results.test.ts`, die Blockform und Tabellenklasse für Blatt und Werkzeugtext gleichermaßen erzwingen), `npm run build`, Designprüfer (0 rohe Farbwerte, unveränderte Verbotsbudgets) sowie live in Dark und Light: 78-Zeilen-Tabelle rollt mit 10 px breitem Balken statt abzubrechen, 8-Spalten-Tabelle rollt waagerecht im eigenen Behälter ohne das Fenster mitzuziehen, kurzer Ergebnistext hält das Fenster weiterhin klein. |
| 2026-07-28 | Markdown-Darstellung der Maester-Ergebnistexte durchgängig korrigiert; die Nutzerbeispiele deckten fünf getrennte Ursachen auf. (1) `LinkedResults` gab den Ergebnistext als reinen Text aus statt über `RichTextValue` — die eigentliche Ursache aller gezeigten Fälle: Rauten, Sternchen, Pipe-Ketten und Verweisklammern standen wörtlich im Ergebnisfenster. (2) `parseInlineTable` verwarf eine vollständig erkennbare Tabelle, sobald hinter der letzten Datenzeile noch ein Hinweissatz stand (Zellenzahl kein Vielfaches der Spaltenzahl); der Nachtext wird jetzt an der fehlenden Abschluss-Pipe erkannt, abgetrennt und als eigener Absatz ausgegeben, die strenge Vielfachenprüfung bleibt für geschlossene Tabellen erhalten. (3) Die Vortextgrenze (`before`) wurde über eine Längenrechnung der Kopftexte bestimmt und ließ dadurch die erste Kopfzelle in der Überschrift stehen ("Impacted resources  Status"); sie wird jetzt zellenweise von rechts gesucht. (4) Eine Überschrift läuft bis zum Zeilenende und verschluckte in einer kollabierten Zeile die gesamte nachfolgende Tabelle; `parseMarkdownBlocks` trennt Überschrift, Tabelle und Nachtext nun auf. (5) `cellText` faltet jeden Leerraum innerhalb einer Zeile zu einem Leerzeichen — die Markdown-Einrückung vor Aufzählungszeichen ist in der Anzeige also grundsätzlich verloren, weshalb die am 2026-07-28 eingeführte einrückungsbasierte Erkennung dort nie greifen konnte. Sie ist durch `breakInlineUnorderedLists` ersetzt: Unterscheidungsmerkmal ist wie bei den nummerierten Listen die Wiederholung (ab zwei Markierungen je Zeile), Markierungen innerhalb einer Verweisauszeichnung und Tabellenzeilen zählen nicht mit. Zusätzlich ist das Verweismuster als `LINK_PATTERN` an einer Stelle vereinheitlicht (Erkennung, Auswertung, Schutzbereiche) und erfasst nun verschachtelte Titelklammern (`[[RaviK] - Require app protection policy](Adresse)`) sowie leere Adressen (`[name@example.invalid]()`). Verifiziert mit `npm test` (418/418 bestanden, neun neue Regressionen in `markdown.test.ts` und `linked-results.test.ts`), `npm run build`, einem Durchlauf über alle 249 markdownhaltigen Maester-`Result`-Werte (0 verbliebene Rohauszeichnungen) sowie live an den vier vom Nutzer gemeldeten Funden. Bekannte Restfälle: zwei `Description`-Werte mit fehlerhafter Quellsyntax (Backslash-Escape `**\*.onmicrosoft.com**`, Adresse mit Leerzeichen) — Backslash-Escapes sind eine bewusst nicht unterstützte Markdown-Erweiterung. |
| 2026-07-28 | Nutzerkorrektur zum Maester-Ergebnistext vom selben Tag: Der Text erscheint jetzt ausschließlich im Results-Fenster über die Results-Schaltfläche (wie Maesters eigene HTML-Ansicht "Test result"), nicht mehr im Finding-Fliesstext. `FindingReader.tsx` wurde auf sein ursprüngliches Verhalten zurückgesetzt ("Result" bleibt für jedes Werkzeug einheitlich ausgeblendet). Neue Funktion `resultMessageFor` (`features/linked-results/result-message.ts`) löst den werkzeuggebundenen Ergebnistext über das Toolprofil auf; `LinkedResults`/`FloatingResultsWindow` zeigen ihn als neutralen Kasten (`--panel`/`--line`, keine Warnfarbe), sobald keine verknüpfte Ergebnisdatei vorliegt. `DatasetViewer.tsx` aktiviert die Results-Schaltfläche (Kachel- und Datensatzansicht) jetzt auch ohne verknüpfte Ergebnisdatei, sofern ein solcher Text vorliegt, und filtert ihn aus den Referenzhinweisen heraus, damit der bisherige irreführende Inline-Kasten "Results (Referenz gefunden)" für diesen Fall nicht mehr erscheint. Grund: Dieselbe Aussage soll nicht doppelt (Fliesstext und Popup) stehen, und das Ergebnisfenster ist bereits der etablierte Ort für Ergebnisevidenz jeder Art. Verifiziert mit `npm test` (411/411 bestanden), `npm run build` sowie live am Datensatz CIS.M365.1.1.3 im Dummy-Mandanten (Text erscheint nur noch im Popup, Finding-Text und der alte Referenz-Hinweis sind frei davon). |
| 2026-07-28 | Eingebettete Aufzählungen in Fliesstextfeldern (Remediation-Anleitungen von CIS-CAT/Maester) verschwanden ununterscheidbar im Absatz, weil die Werkzeuge echte Zeilenumbrueche beim Export zu einzelnen Leerzeichen kollabieren. `src/shared/markdown.ts` erkennt jetzt zwei zusaetzliche, konservative Signale: (1) eine lueckenlos ab 1 aufsteigende Zahlenfolge mit `.`-Terminator (`breakInlineOrderedLists`) - eine einzelne Ziffer bleibt bewusst Fliesstext, da `1.` ebenso gut eine Kennung wie "1.1.3 (L1)" sein kann; (2) ein Aufzaehlungszeichen nach drei oder mehr Leerzeichen (`INDENTED_BULLET`) - die urspruengliche Markdown-Einrueckung vor einem `-`/`*`/`+` bleibt beim Kollabieren erhalten und ist von gewoehnlichem Fliesstext (max. zwei Leerzeichen als Absatzabstand im Datenbestand) zuverlaessig unterscheidbar. Keine Verschachtelung: mehrere direkt aufeinanderfolgende nummerierte Abschnitte verschmelzen zu einer flachen Liste, bleiben aber als Listenpunkte lesbar statt als ein Absatz. Verifiziert mit `npm test` (407/407 bestanden, vier neue Regressionen in `markdown.test.ts`), `npm run build` und live am Datensatz CIS.M365.1.1.3 im Dummy-Mandanten (Remediation-Anleitung erscheint als 14 Listenpunkte statt Fliesstext). |
| 2026-07-28 | Maester-Excel-Ergebnistext im Reader korrigiert: (1) `ToolProfileDefinition.presentation` um optionales `resultMessageHeaders` erweitert (`tool-profile-definition.ts`), damit ein Toolprofil erklären kann, dass sein Feld "Result" der beschreibende Ergebnistext ist statt eines kurzen Status-Badges (Purple-Knight-Konvention bleibt unverändert Standard); Maester-Profil setzt `resultMessageHeaders: [/^result$/i]` (`maester-definition.ts`). (2) `FindingReader.tsx` loest das Toolprofil ueber die bereits vorhandene werkzeuggebundene Datensatzherkunft (`toolIdForRecord`) auf und zeigt das Feld dann als priorisierten Fliesstext statt es wie einen reinen Status-Header auszublenden; ein als Statusfeld verwendetes Vorkommen desselben Feldes wird weiterhin nicht doppelt angezeigt. (3) `isFileReference` in `result-linker.ts` verlangt jetzt zwingend eine erkannte Dateiendung oder einen Pfadtrenner, damit ein gewöhnlicher Ergebnissatz (z. B. Maesters Klartextmeldung) nicht mehr fälschlich als Dateiverweis in der "Results (Referenz gefunden)"-Box erscheint. Grund: Maester und Purple Knight benennen ihre Excel-Spalte identisch ("Result"), meinen aber unterschiedliche Dinge — ohne diese Unterscheidung verschwand Maesters einziger Beleg für ein Finding vollständig aus der Anzeige. Verifiziert mit `npm test` (403/403 bestanden, neue Regressionen in `finding-reader.test.ts` und `result-linker.test.ts`) und `npm run build` (Client und Server grün). |
| 2026-07-28 | Maester-Excel-Ergebnistext im Reader korrigiert: (1) `ToolProfileDefinition.presentation` um optionales `resultMessageHeaders` erweitert (`tool-profile-definition.ts`), damit ein Toolprofil erklären kann, dass sein Feld "Result" der beschreibende Ergebnistext ist statt eines kurzen Status-Badges (Purple-Knight-Konvention bleibt unverändert Standard); Maester-Profil setzt `resultMessageHeaders: [/^result$/i]` (`maester-definition.ts`). (2) `FindingReader.tsx` loest das Toolprofil ueber die bereits vorhandene werkzeuggebundene Datensatzherkunft (`toolIdForRecord`) auf und zeigt das Feld dann als priorisierten Fliesstext statt es wie einen reinen Status-Header auszublenden; ein als Statusfeld verwendetes Vorkommen desselben Feldes wird weiterhin nicht doppelt angezeigt. (3) `isFileReference` in `result-linker.ts` verlangt jetzt zwingend eine erkannte Dateiendung oder einen Pfadtrenner, damit ein gewöhnlicher Ergebnissatz (z. B. Maesters Klartextmeldung) nicht mehr fälschlich als Dateiverweis in der "Results (Referenz gefunden)"-Box erscheint. Grund: Maester und Purple Knight benennen ihre Excel-Spalte identisch ("Result"), meinen aber unterschiedliche Dinge — ohne diese Unterscheidung verschwand Maesters einziger Beleg für ein Finding vollständig aus der Anzeige. Verifiziert mit `npm test` (403/403 bestanden, neue Regressionen in `finding-reader.test.ts` und `result-linker.test.ts`) und `npm run build` (Client und Server grün). |
| 2026-07-27 | MITRE ATT&CK Matrix Aktualisierbarkeit & Panel-Redesign: (1) Dynamischer Lade- und Validierungs-Mechanismus in `mitre-graph.ts` (`validateMitreMatrixData`, `loadStoredMitreMatrix`, `saveStoredMitreMatrix`, `clearStoredMitreMatrix`) inklusive Dateiupload- und Reset-Steuerung im DataHub (`DataHub.tsx` & `datahub.css`) zum lokalen Einspielen neuer STIX/JSON-Matrizen (z. B. v19.x) ohne externe APIs; (2) Neugestaltung des MITRE Attack Paths Panels (`MitreGraphView.tsx` & `mitre-graph.css`) mit Path Risk Index Banner, Schnell-Preset „Kritischste Kette", Nativ vs. Abgeleitet Mappings, klarer Unterscheidung in der Spalte „Nicht zugeordnet" für werkzeugfremde Befunde (Maester, CIS-CAT) und strukturiertem 3-Spalten Detail-Inspector; (3) Sämtliche übrigen Anwendungsbereiche (Shell, Topbar, Sidebar, Work) blieben optisch zu 100 % unverändert. Verifiziert mit `npm test` (399/399 bestanden), `design-language-check.mjs` und `npm run build` (Client & Server grün). |
| 2026-07-27 | UI-Korrekturen und Provenienz-Facettenbereinigung auf Nutzerwunsch: (1) Sechseck-Hakenposition in `.record-card`, `.data-tile-hex` und `.reader-title-hex` im unteren linken Bereich des Hexagons platziert (`left: 2px` bzw. `translate(-6.5px, 0.5px)` in `legacy-views.css` und `components.css`), exakt entsprechend der visuellen SOLL-Vorlage; (2) Badge im Results-Fenster (`.results-window-badge`) sowie geöffnete Results-Schaltflächen (`.results-btn.is-open`, `.tile-results-btn.is-open`) auf immer weiße Schrift (`color: var(--text-on-accent)`) umgestellt; (3) Redundante Herkunftsfilter `Quelle: Datei`, `Quelle: Blatt` und das virtuelle `Quelldatei`-Facet in `dynamic-facets.ts` automatisch unterdrückt, sobald `Quelle: Scan` vorhanden ist — Datenmodell, Datensätze, Exporte und der Finding Reader behalten alle Provenienzdaten zu 100 % bei. Verifiziert mit `npm test` (399/399 bestanden) und `npm run build` (Client und Server grün). |
| 2026-07-27 | Werkzeugtexte werden lesbar dargestellt statt als Markdown-Quelltext. Neu: `src/shared/markdown.ts` (Ueberschriften, Aufzaehlungen, Tabellen, Fett/Kursiv/Code/Verweise, rekursiv fuer verschachtelte Auszeichnung), angewendet in `RichTextValue` fuer unausgezeichnete wie fuer HTML-Werte. Maester liefert seine Tabellen einzeilig, deshalb erkennt der Parser auch die Pipe-Kette ohne Zeilenumbrueche und trennt Ueberschriften, die mitten in der Zeile stehen; nummerierte Aufzaehlungen bleiben bewusst unangetastet, weil `1.` ebenso eine Kennung wie "1.1.1 (L1)" sein kann. Ergebnistabellen aus Textfeldern (`ResultDetail`) werden als Blatt projiziert und sind ueber die Results-Schaltflaeche erreichbar; der Hinweis "keine Ergebnisdatei gefunden" nennt nur noch echte Dateiverweise. Zusaetzlich behebt `cellText` den Verlust der Zeilenstruktur in `buildRecord`. Verifiziert an der laufenden Anwendung: ueber 80 Maester-Datensaetze null rohe Markdown-Textknoten bei 138 Ueberschriften, 93 Aufzaehlungen, 264 Verweisen und 433 Fettstellen; PingCastle (37) und Purple Knight (40) unveraendert ohne Reste; Ergebnisfenster eines Warning-Funds zeigt die Tabelle mit 4 Spalten und 2 Zeilen; Kacheln mit Ergebnistabelle von 59 auf 72 gestiegen. |
| 2026-07-27 | Abweichungsachse in Work nachgezogen: der Ergebnisstatus erscheint in Kachel, Fundkarte und Reader nicht mehr als neutrale Plakette, sondern als Outcome mit Textfarbe und Glyph (`.outcome-mark`, eine gemeinsame Definition fuer Work und Result DB). Dabei fiel auf, dass die Projektaggregation eines Mandanten die Profil-ID `generic` traegt: PingCastles `Matched` wurde dadurch ueber die generische Rueckfallregel als `warning` statt als `fail` gelesen, Work zeigte 40 Warnungen gegenueber 3 in der Result DB. Die Werkzeugherkunft wird jetzt je Datensatz aus der Provenienzspalte „Quelle: Scan" aufgeloest (`toolIdForRecord`), Einzelblaetter tragen zusaetzlich `DatasetSheet.toolId`. Verifiziert: Work meldet mit Standardfilter 130 Treffer (127 `fail`, 3 `warning`) und ohne Filter 474 (169 `pass`, 127 `fail`, 169 `not_run`, 4 `not_applicable`, 3 `warning`, 2 `execution_error`) - identisch zur Result DB und zur Datenbank. |
| 2026-07-27 | Abweichungsachse eingefuehrt und Maester-`Investigate` damit sichtbar gemacht. Neu: versioniertes Praedikat `isDeviation`, abgeleitetes Projektionsfeld, Queryparameter und Facette `deviation` (In-Memory und PostgreSQL-Vorfilterung), Spalte und Segmentfilter „Abweichung" in der Result DB, Outcome-Zelle nach Designvertrag mit Textfarbe und Glyph statt Klartext. Maester-Standardfilter von `failed` auf `deviation` umgestellt; die Filter `failed`, `passed` und `skipped` bleiben unveraendert erhalten, ebenso Severity, `is_ioe` und `exposure_state` jedes Funds. Verifiziert gegen die laufende Datenbank: `deviation=true` (130) = `isIoe=true` (127) + `outcome=warning` (3), `deviation` true/false ergibt zusammen die Gesamtmenge (474), `pass` (169) and `fail` (127) unveraendert, Schnittmenge `deviation` mit `pass` leer. `npm test` (367 Tests) und `npm run build` gruen. |
| 2026-07-27 | Seitenkopf vereinheitlicht: Eyebrow-Label ueber dem Topbar-Titel (`area-topbar-kicker`) sowie die Hero-Bloecke in Result DB und DB-Struktur entfernt, Seitentitel verbleibt in der Topbar. Nav- und Topbar-Bezeichnung „Ergebnisse" zu „Result DB" geaendert. Die „Aktualisieren"-Aktion beider Seiten sitzt jetzt in der Metazeile (`.page-actions-row`). |
| 2026-07-27 | **Die zweite Agentensitzung (2026-07-26 18:42 bis 2026-07-27 01:44) wurde vollständig zurückgenommen.** Auftrag war die Wiederherstellung der Optik. Grundlage war das Sitzungsprotokoll dieser Sitzung (`~/.codex/sessions/2026/07/26/rollout-*.jsonl`, 669 Werkzeugaufrufe, 51 Dateien mit nachgewiesenen Schreibzugriffen): Je Datei wurde der letzte vollständige Lesestand **vor** dem ersten Schreibzugriff extrahiert; wo kein solcher Lesestand vorlag, wurde die im Protokoll dokumentierte Ersetzung am Ist-Stand invertiert — jeweils mit Prüfung auf exakte Textgleichheit und Abbruch bei Abweichung, damit keine Datei auf Verdacht geändert wird. 58 Dateien wiederhergestellt, 11 Neuschöpfungen entfernt (`SeverityHex`, `OutcomeIndicator`, `severity-normalization.ts` samt Test, `work-reference.css` in Projekt und Skill, `color-and-severity.md`, drei weitere neue Testdateien, dazu die schon zuvor geleerte Hülle `themes.css`). Zurückgenommen wurden insbesondere: die neue Shell in [App.tsx](../src/app/App.tsx) samt Umbenennung von sechs Klassennamen auf `legacy-*` in 20 Dateien; die kanonische Severity-Stufe `warning` über Domänenmodell, Maester-Profil, Facetten, Graph und Work-Projektion; die Aufspaltung der Filterleiste in Primär- und Nebenfilter; sowie die geänderte Severity- und Akzentpalette. **Drei Fehler entstanden in der Wiederherstellung selbst und wurden gefunden und behoben:** (1) Beim Wiedereinsetzen von `normalizeSeverity` wurden die Wortgrenzen `\b` als Backspace-Zeichen (0x08) geschrieben, wodurch die Funktion jede Severity auf `unknown` abbildete — sichtbar geworden durch `tests/importers/canonical-candidate-migration.test.ts`. (2) Die Protokollausgabe war latin1-dekodiert; 25 Umlaute und Trennzeichen in sieben Dateien waren dadurch doppelt kodiert und wurden gezielt zurückgerechnet. (3) `dynamic-facets.ts` musste aus zwei Teilausgaben zusammengesetzt werden und verlor dabei die Severity-Synonymnormalisierung; die Prüfung ergab, dass diese Normalisierung selbst eine Ergänzung der zweiten Sitzung war (22:07) und samt ihrem Test entfällt — der Testbestand liegt damit wieder bei 359 statt 360. Verifikation gegen die Baseline desselben Tages: 359 Standardtests und 7 übersprungene, Local-only-Prüfung, Designprüfer mit 0 rohen Farbwerten, 38 verbotenen Mustern und 179 Tokens, Client- und Serverbuild erfolgreich. Im Browser inhaltsfrei gemessen: die alte Shell ist vorhanden (`area-topbar`, `sidebar-context`, `sidebar-theme-panel`), von der neuen keine Spur (`context-strip`, `status-bar`, `band`, `segmented`, `severity-hex`); Tokens `--bg #121215`, `--panel #1A1A1E`, `--state-active #D9962A`, `--legacy-accent #7C5CF5`, `--critical #E8214F`, `--medium-badge #A16207`, `--control-height 30px`. **Bewusst nicht zurückgenommen:** Die Designsprache-Arbeit vom Nachmittag (Schritte 1 und 2) bleibt nach Nutzerentscheidung bestehen. Die als Referenz gelieferten Screenshots zeigen den Stand **vor** dieser Arbeit; die gemessenen Abweichungen sind Auswahlfläche `rgb(42,36,64)` statt Blau `#4a6f96`, Arbeitsfläche `rgb(18,18,21)` statt `#2b2b2b`, Kachelradius 3px statt 8px und fehlende Kachelschatten. Der Nutzer hat diese Abweichung ausdrücklich akzeptiert. Die zwölf Protokolleinträge und drei Architekturentscheidungen der zweiten Sitzung bleiben als Historie erhalten und sind in Abschnitt 9 als zurückgezeichnet gekennzeichnet. Keine Schema-, Persistenz- oder Mandantendatenänderung. |
| 2026-07-30 | Titel-Zuordnung, Kachel-Raster, CIS-CAT-Zeilenumbrüche, Rule Result XML Formatierung, Ergebnis-Zuordnung und Detailblock-Verlinkung korrigiert: (1) Befund-Titel zeigten fälschlicherweise Dateinamen oder Regel-IDs. Behoben in `record-builder.ts`, `generic-definition.ts` und `generic-field-rules.ts`. (2) Kachelansicht stellte sich beim ersten Öffnen einzeilig dar. Behoben in `DatasetViewer.tsx`. (3) In CIS-CAT-Textfeldern standen vereinzelte Satzzeichen (`.`, `:`) auf eigenen Zeilen. Behoben durch `cleanLineBreaks` in `markdown.ts` und `cis-cat-source-extractor.ts`. (4) Bei Regeln mit Apostrophen/Sonderzeichen im Titel (z. B. Rule 2.2.2 `Ensure 'Access this computer...'`) schlug der reine Titel-String-Match fehl, weshalb `Description`, `Rationale`, `Remediation` und die Evidenz-Tabellen fehlten. Behoben in `cis-cat-source-extractor.ts` durch direkte Extraktion der `href="#detail-..."`-ID aus der Tabellenzelle, sodass alle Assessment-Evidenztabellen, Beschreibungen und Controls zu 100 % ausgelesen und zugeordnet werden. `npm test` (454 Tests passed), `npm run build` und Local-only-Check erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-30 | Titel-Zuordnung für CIS-CAT, PurpleKnight und generische Berichte korrigiert: Befund-Titel in Karten, Kacheln und Lesespaltentitel zeigten fälschlicherweise den Dateinamen (z. B. `WIN-...html`) oder die Regel-ID (z. B. `SI000055`) anstelle des tatsächlichen Namens (`Permission changes on AdminSDHolder object`). Ursache 1: `titleTokens` in `record-builder.ts` prüfte `label.includes('name')`, wodurch `ShortName` vor `Name` gematcht wurde. Ursache 2: `titleTokens` enthielt weder `benchmark item`, `benchmark` noch `recommendation` und wich auf `Quelle: Datei` als erste gefüllte Spalte aus. Ursache 3: ID-Kopfzeilen (`ShortName`, `Rule ID`, `Control ID`, `ID` etc.) wurden bei der Token-Abfrage nicht gefiltert. Behoben in `record-builder.ts` (`isIdHeader` filtert ID-Spalten bei der Titel-Suche aus, `titleTokens` um `benchmark item`, `benchmark`, `recommendation` erweitert, Provenienzspalten vom Fallback ausgeschlossen) sowie in `generic-definition.ts` und `generic-field-rules.ts`. Regressions-Tests in `analysis.test.ts` ergänzt. `npm test` (451 Tests passed), `npm run build` und Local-only-Check erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-27 | Visuelle Korrektur innerhalb Schritt 5 der UI-Konsolidierung umgesetzt, ohne eine Hauptphase als abgeschlossen zu markieren: Work verwendet wieder eine deutliche Ableton-orientierte Flaechenhierarchie statt nahezu gleich heller generischer Karten. Skill und Laufzeit definieren fuer Dark und Light dieselben abgeleiteten Rollen fuer Master-Rail, Arbeitsobjekte und Hover; Listen, Tiles und kuenftige datenreiche Ansichten verwenden sie gemeinsam. Reader-Inset und vertikale Leerstelle wurden auf das 4-px-Raster reduziert, die maximale Lesebreite zentralisiert und Kopfaktionen bleiben auf breiten Flaechen in derselben kompakten Zone. Tile-Badges sind auf vier sichtbare Werte mit `+n` begrenzt. Bestaetigte Regeln fuer Primaer-/Nebenfilter, Auswahlblau, Aktionsviolett, Severitys, Warning und Sechseck blieben unveraendert. Inhaltsfreie Browserpruefung bestaetigte die ausgelieferten Light-Rollen sowie identische Dark-/Light-Vertraege. `npm test`: 372 bestanden, 7 optionale PostgreSQL-Tests erwartungsgemaess uebersprungen; Local-only- und Designpruefung gruen, 194 Tokens, 0 Rohfarben und 18 verbleibende Alt-Muster. Client-/Serverbuild erfolgreich; bekannte Chunkgroessenwarnung bei 896,53 kB bleibt. Keine Schema-, Persistenz- oder Datenaenderung. |
| 2026-07-26 | Nutzerkorrektur der Farbrollen als querschnittliche UI-Konsolidierung zwischen Schritt 3 und 4 umgesetzt, ohne Phasenabnahme: Das Auswahlblau `#85BFF2` bleibt für aktive Navigation, Auswahl, Information und Fokus unverändert. Die separate Filterfarbe `#677DBF` und ihre vier `--filter-active*`-Tokens wurden entfernt; Primäraktionen, aktive Ansichten und alle Work-/Command-Band-Filter verwenden jetzt in beiden Themes `#A68AF9` mit weißer Tinte. Gesetzte Filter bleiben über Wert beziehungsweise Trefferzahl sowie stärkere Gewicht erkennbar. Skill- und Laufzeittokens, zentrale Band-Komponente, Work-Übergangsregel, Farb-/Zustandsreferenz, Review-Checkliste und Drift-Test sind synchronisiert. Inhaltsfreie Browserprüfung bestätigte in Light und Dark `#A68AF9`/`#FFFFFF` für die Aktions-/Filterrolle, `#85BFF2` für aktive Navigation und das Fehlen der entfernten Filterrolle; das Ausgangstheme Light wurde wiederhergestellt, zwei Verbindungsindikatoren blieben aktiv. 359 Standardtests, Local-only- und Designprüfung erfolgreich; 7 optionale PostgreSQL-Integrationen erwartungsgemäß übersprungen, 181 Tokens, 0 Rohfarben und 30 verbleibende Alt-Muster. Client- und Serverbuild erfolgreich; bekannte Größenwarnung des 890,33-kB-Clientchunks unverändert. Keine Schema-, Persistenz- oder Datenänderung. |
| 2026-07-26 | Schritt 1 und 2 der Designsprache abgeschlossen: **kein roher Farbwert mehr außerhalb der Tokendateien** (85 → 0). Umgestellt wurden `mitre-graph.css` (34), `components.css` (30), `layout.css` (20) und `import-workflow.css` (1). Ersatzlos entfernt statt umgestellt: der Dateistatus-Block der Topbar (`.topbar-project-kpis`, `.topbar-kpi`, vier `.kpi-*`), dessen Markup schon am 2026-07-25 entfallen war; die doppelten Neomorph-Schatten und der 12px-Radius der Kachel samt Hover-Versatz; die weiche Aura des Verbindungspunktes; der Ring-Schatten der Graph-Auswahl; und zehn Light-Sonderregeln in `mitre-graph.css` sowie drei in `components.css`. Verbliebene Light-Regeln sind vier Logotausche über Deckkraft — ein zweifarbiges Logo ist keine semantische Rolle. Zustandsdarstellungen an die Sprache angeglichen: die Trefferlistenauswahl trägt getönte Fläche plus Akzentrahmen statt Vollfüllung, damit die Severity-Kante daneben sichtbar bleibt; die Workspace-Schaltfläche unterscheidet leer (gedämpft), gefüllt (Erledigt-Ton als Umriss) und aktiv (Akzentfläche), statt drei Grüntöne zu mischen. **Abweichung von der Designsprache, mit Messung begründet:** deren Severity-Palette mit `--sev-on` (weiß) erreicht auf 11px-Versaltext nur 2.65:1 (medium) bis 4.41:1 (critical) und verfehlt damit die 4.5:1, die Abschnitt 4 derselben Checkliste fordert. Die dunkleren Alt-Töne halten 5.02:1 bis 6.29:1 und bleiben als `--*-badge` in `tokens.css` stehen, bis die Rolle in `ui-tokens.css` nachgezogen ist; für dunkle Tinte auf gefüllter Signalfläche (Hexagon, Badge „medium") gibt es das Token `--severity-ink`. Der Prüfer führt die Verbotsliste jetzt vollständig: rohe Farbwerte 0, verbotene Muster 102 → 38 (`!important` 5, Radien über 4px 7, Schatten außerhalb der Overlay-Rollen 22, Light-Fixes 4, Seitenselektoren 0). Im Browser in beiden Skins gemessen: Textkontrast auf der Arbeitsfläche 15.3:1 dunkel und 15.84:1 hell, Sidebar `rgb(13,13,16)` beziehungsweise `rgb(228,228,234)`, Statuspunkt `rgb(46,158,107)` beziehungsweise `rgb(30,122,80)` und ohne Schatten, keine unaufgelösten Tokens. 359 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder Komponentenänderung. |
| 2026-07-26 | Designsprache Schritt 1 und 2: Altwerte auf die neuen Rollen abgebildet, Themedatei entfallen, Prüfer um die Verbotsliste erweitert. (1) [tokens.css](../src/styles/tokens.css) enthält keinen eigenen Farb- oder Maßwert mehr, sondern leitet jeden Altnamen an eine semantische Rolle aus `ui-tokens.css` weiter; vier Ausnahmen sind einzeln begründet (`--radius-pill` für den auf Nutzerwunsch runden Ansichtsmodus, `--reader-inset`, `--ui-glyph-size` für Symbolschaltflächen, die gemischte Fehlerfläche `--danger-surface`). (2) [themes.css](../src/styles/themes.css) ist damit gegenstandslos und aus `main.tsx` entfernt: der helle Skin entstand dort als eigener Tokenblock plus zwanzig Klassenregeln, die den Skinwechsel für `layout.css`, `components.css` und `legacy-views.css` nachreichten — beides ersetzt die Rollendefinition beider Skins in `ui-tokens.css`. (3) Der Prüfer setzt jetzt zusätzlich die Verbotsliste aus Abschnitt 1 der Review-Checkliste durch: `!important`, Radien über 4px, Schatten außerhalb der Overlay-Rollen, seitenspezifische Überschreibungen und Light-Mode-Fixes per Selektor, jeweils als ausschließlich schrumpfende Obergrenze je Datei. Seitenselektoren prüfen bewusst nur `.page-*`; die von der Checkliste zusätzlich genannten `.view-*` und `.screen-*` sind im Bestand Komponentennamen (`.view-tabs`, `.view-table`) und keine Seitenskopierung. Jede der fünf Regeln wurde einzeln durch einen absichtlich eingefügten Verstoß als wirksam nachgewiesen, ebenso die Absenkmechanik. **Sichtbare Folgen, bewusst in Kauf genommen:** die Arbeitsfläche des dunklen Skins wird von `#2b2b2b` auf `#121215` dunkler und die des hellen von mittelgrau `#bfbfbf` auf `#F1F1F4` mit weißen Panels heller — beides kehrt die frühere Ableton-Festlegung „Chrome ist mittelgrau, nie weiß, nie fast schwarz" um; Steuerelemente wachsen von 24px auf 30px, Zeilen von 26px auf 32px, Radien von 2/3px auf 3/4px, Abstände rastern auf 4/8/12/16/20/24px; Kachelschatten entfallen ersatzlos. Im Browser in beiden Skins gemessen: dunkel `--bg #121215`, `--panel #1A1A1E`, `--text #E8E8EC`; hell `--bg #F1F1F4`, `--panel #FFFFFF`, `--text #17171C`; `--control-height` 30px, `--legacy-radius-sm` 3px, `--shadow-raised: none`; 116 referenzierte Tokens, keine unaufgelösten außer den beiden komponentenlokalen `--severity` und `--kpi-accent`. Verbotene Muster im Restbestand von 102 auf 62 gesunken, Stildateien von 110 Zeilen `themes.css` befreit. 359 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder Komponentenänderung. **Offen:** die leere Hülle `src/styles/themes.css` ist noch nicht gelöscht. |
| 2026-07-26 | Designsprache als Projektskill installiert und ihr Tokenset additiv in den Build gezogen: `.claude/skills/assessor-ui/` (SKILL.md, `assets/tokens.css`, `assets/components.css`, vier Referenzdateien) ist ab jetzt die verbindliche Quelle für alles Sichtbare. Die Übernahme erfolgte **nicht** als Ersetzung der bestehenden Stildateien, wie in der Installationsanleitung des Pakets vorgesehen: Ein Abgleich vor dem Kopieren ergab zwei disjunkte Vokabulare — 33 der 70 im Projekt referenzierten Tokens wären undefiniert geblieben (`--bg`, `--panel`, `--critical`, `--ui-body-size` …) und keine der 48 Altklassen wäre weiter bedient worden. Umgesetzt ist deshalb: (1) `src/styles/ui-tokens.css` als Projektkopie des Skill-Tokensets, geladen als erste Tokenquelle; (2) `src/styles/layers.css` mit der zwingenden Reihenfolge `@layer tokens, base, shell, components, utilities;` als erstes Stylesheet; (3) Auflösung der zehn Namenskollisionen durch Umbenennung im Altbestand auf `--legacy-accent`, `--legacy-accent-active`, `--legacy-radius-sm`, `--legacy-radius-md` und `--legacy-space-1` bis `--legacy-space-6` — Werte unverändert, 197 Referenzen in acht Stildateien; (4) `src/styles/ui-components.css` liegt im Projekt, ist aber **bewusst noch nicht in `main.tsx` importiert**. Grund für (4) war eine im Browser gemessene stille Regression: `.btn`, `.icon-btn`, `.input`, `.select`, `.tile-grid` und `.is-bookmarked` existieren in beiden Systemen, und da der Altbestand außerhalb der Layer liegt, gewinnt er nur bei gemeinsamen Eigenschaften — die zusätzlichen Eigenschaften der neuen Regel wirkten trotzdem und setzten bestehende Schaltflächen auf `height: 30px`, `gap: 8px`, `justify-content: center` statt der bisherigen Mindesthöhe von 24px. Nach Rücknahme des Imports messen bestehende Schaltflächen wieder 27,5px Höhe bei 24px Mindesthöhe, Radius 2px, kein `gap`. Der Designprüfer wurde an die neue Sprache angepasst: `ui-tokens.css` gilt als Tokenquelle, die Schriftgrößenuntergrenze sinkt nach Nutzerentscheidung von 12px auf 11px (kleinste Stufe `--fs-micro`, ausschließlich Versal-Badges, Spaltenköpfe und Zähler), und die Prüfung erfasst zusätzlich die `--fs-*`-Tokendefinitionen, die sie bisher nicht sah. Baseline der Verbotsliste aus `references/review-checklist.md` gegen den Ist-Stand: 115 rohe Farbwerte außerhalb der Tokendateien, 5 `!important`, 13 Radien über 4px, 29 `box-shadow` außerhalb der Overlay-Rollen, 3 seitenspezifische Überschreibungen, 1 Schriftgröße außerhalb der Skala, 56 `[data-theme="light"]`-Überschreibungen außerhalb der Tokendateien. 359 Standardtests, Local-only-Prüfung, Designprüfer (13 Stildateien, 179 Tokens) und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder Komponentenänderung; ausschließlich Stildateien, `main.tsx`, der Designprüfer und der neue Skill. |
| 2026-07-26 | Ergebnistabellen ausschließlich schwebend, mittig geöffnet und über die Schaltfläche umschaltbar: (1) Der Reader rendert die verknüpften Tabellen nicht mehr inline — sie standen dort ein zweites Mal in der Lesespalte. Der Aufklapper bleibt nur für den Fall erhalten, dass eine Referenz vorliegt, die zugehörige Ergebnisdatei aber nicht geladen ist; dann ist die Results-Schaltfläche abgeschaltet und der Hinweis die einzige Erklärung. (2) Das Fenster öffnet mittig: eine erste Schätzung aus den Höchstmaßen des Stils, unmittelbar nach dem Einhängen einmalig anhand der tatsächlichen Größe nachzentriert; mehrere gleichzeitig geöffnete Fenster versetzen sich weiterhin über `offset`. (3) Ein zweiter Klick auf die Results-Schaltfläche schließt das Fenster wieder — in Datensatzansicht und MITRE-Graph gleichermaßen; nach vorn geholt wird ein Fenster über einen Klick auf das Fenster selbst. Im Browser gemessen: Fenstermitte [924, 595] gegenüber Bildschirmmitte [925, 595], keine Inline-Tabelle im Reader, zweiter Klick schließt das Fenster und nimmt die Einfärbung der Schaltfläche zurück. Die Zusage in `tests/features/finding-reader.test.ts` wurde auf das neue Verhalten gezogen und um den Hinweisfall ergänzt. 359 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | Ergebnisfenster und Reader-Überschrift aufgeräumt: Die Kopfleiste des Ergebnisfensters trägt nur noch die Kennzeichnung („Results (n)"); der Fundname steht jetzt als Überschrift im Fensterrumpf und ersetzt dort die zuvor wiederholte Dateibezeichnung der Ergebnisquelle — eine Angabe, die im Reader ohnehin unter den Zusatzinformationen steht. Da die Kopfzeile den Namen nicht mehr enthält, trägt der Dialog seinen Namen über `aria-label` statt über einen Verweis auf die Kopfzeile. Die Überschrift im Rumpf nutzt dieselbe Typografie wie die Finding-Überschrift des Readers. Der Fundname im Reader steht ebenfalls auf dieser Stufe (18px statt `clamp(18px, 1.6vw, 23px)`) und nutzt die volle Breite der Lesespalte: die Schaltflächen Bookmark und Results rücken in eine eigene Zeile darunter, statt den Titel zu beschneiden. Im Browser gemessen: Kopfleiste enthält nur „Results (2)", Dateibezeichnung nicht mehr vorhanden, Überschrift im Rumpf und Reader-Titel je 18px, Titelbreite 792 von 834 Pixeln der Lesespalte. 358 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | **Verweisziele aus Berichten bleiben erhalten — Sicherheitsmodell geändert (Nutzerfreigabe).** Die Belegstellen der Werkzeuge gingen an zwei Stellen verloren: Der Excel-Importer las über `sheet_to_json` nur Zellwerte, während Excel das Ziel als eigene Zelleigenschaft führt; und die HTML-Extraktion entfernte `href` pauschal als aktives Attribut. Zusätzlich lieferte `textFromNode` Tabellenzellen als reinen Text, sodass selbst ein erhaltenes `href` den Feldwert nie erreicht hätte. Neue Regel statt pauschaler Entfernung: `href` bleibt ausschließlich an einem Anker und ausschließlich als `http:`/`https:`-Adresse erhalten, jedes andere Schema sowie `xlink:href` und alle übrigen aktiven Attribute werden unverändert entfernt; übernommene Werte werden normalisiert neu geschrieben, und Zellen mit Verweisen maskieren ihren Textinhalt, damit ein Bericht kein eigenes Markup einschleusen kann. Die Darstellung prüft über `safeHref` ein zweites Mal und rendert nur mit `target="_blank"` und `rel="noopener noreferrer"`. Excel übernimmt das zellgebundene Ziel derselben Prüfung; das Format kennt höchstens ein Ziel je Zelle, mehrere Belegstellen in einer Zelle bleiben daher unverlinkter Text. CSV benötigt keine Änderung, da nackte Adressen bereits in der Darstellung erkannt werden. [SECURITY.md](../SECURITY.md) um den Abschnitt „Verweisziele aus Berichten" ergänzt. Drei Regressionen ergänzt beziehungsweise geschärft: HTML (Web-Adresse bleibt, `javascript:`, `data:` und `file:` verschwinden, eingeschleustes Markup wird maskiert), Excel (Zellverweis wird übernommen, Skriptschema nicht), Node-Importlaufzeit (Ereignisattribute fallen weiterhin heraus, sichere Verweise überleben). Die frühere Zählzusage `removedContentCount >= 3` wurde durch inhaltliche Prüfungen ersetzt, da ein erhaltenes `href` die Zahl zu Recht senkt. **Bereits importierte Berichte tragen die Ziele nicht; sie erscheinen erst nach einem Reimport.** 358 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schemaänderung. |
| 2026-07-26 | Facettenzähler auf echte Facettenlogik umgestellt und Arbeitsgruppe durchgehend eingefärbt: (1) Die Zähler arbeiteten kaskadierend von links nach rechts, wodurch eine Auswahl bei „Category" die davor stehende Facette „Severity" unverändert ließ, obwohl sich deren Treffermenge geändert hatte. Jede Facette zählt jetzt gegen **alle übrigen** gesetzten Filter (`recountFacetsAgainstActiveFilters`); der eigene Filter bleibt ausgenommen, sonst zeigte eine gesetzte Facette für alle nicht gewählten Werte null. Beide Richtungen im Browser geprüft: Category „Anomalies" korrigiert Severity auf Summe 20 (High 0, medium 4, low 7, info 9) bei 20 Treffern; Severity „Critical" korrigiert Category auf Summe 6, wobei die jeweils gesetzte Facette ihre vollständigen Zahlen behält. (2) Die violette Gruppenfläche ist entfallen — sie verwässerte den Aktivton; das Token `--accent-surface` wurde ersatzlos entfernt. (3) Alle Arbeitsfilter sind durchgehend im Aktivton gefüllt, nicht mehr nur die gesetzten; die aufgeklappte Optionsliste bleibt in der gewohnten Darstellung. Ob ein Filter wirkt, bleibt an der Beschriftung ablesbar (Wert samt Trefferzahl gegenüber „: Alle"), gesetzte Filter zusätzlich durch stärkeres Schriftgewicht. (4) Purple Knight legt seine Belegstellen als Abschnitt „References" in dieselbe Zelle wie den vorangehenden Fließtext; der Reader trennt den Block jetzt in ein eigenes Feld ab. Die Aufteilung geschieht bewusst in der Darstellung und nicht beim Import, damit der kanonische Feldwert die Quellzelle bleibt (AGENTS.md: Originalwerte und Provenienz erhalten) und bereits importierte Berichte ohne erneuten Import profitieren. Die Verweisziele bleiben verloren, da Purple Knight sie als Hyperlinks der Excel-Zelle hinterlegt und der Importer nur den Zelltext liest. Im Browser verifiziert: „References" erscheint als eigenes Feld, „Likelihood of compromise" enthält den Block nicht mehr. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | Kennzeichnung offener Ergebnisfenster und gesetzter Filter vereinheitlicht: (1) Die Results-Schaltfläche im Reader trug bisher keinen Zustand — nur die Kacheln zeigten über `resultColor` an, dass ein Ergebnisfenster zu diesem Fund offen ist. `DatasetViewer` reicht den Zustand jetzt als `resultsOpen` an `FindingReader` durch, die Schaltfläche nutzt dieselbe `.results-btn.is-open`-Kennzeichnung wie die Kacheln. (2) Gesetzte Filter tragen den Aktivton als **Vollfläche** statt als Rahmen: die Arbeitsgruppe ist selbst umrandet, wodurch ein weiterer Rahmen darin zu leise blieb; die gefüllte Fläche ist davon eindeutig unterscheidbar. (3) Der Rahmen der Arbeitsgruppe wechselt vom Markenton auf den Aktivton und ist 2px stark. (4) „Result message" gehört jetzt zu den Arbeitsfiltern. Im Browser gemessen: Gruppe enthält Ergebnisstatus, Severity, Category, MITRE ATT&CK, MITRE D3FEND, Target und Result message; Gruppenrahmen 2px `rgb(255,168,37)`; gesetzter Filter Fläche `rgb(255,168,37)` mit Schrift `rgb(31,31,31)`; Results-Schaltfläche wechselt beim Öffnen des Fensters auf denselben Ton. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | Zurücksetzen behält den gelesenen Fund: `resetFilters` setzte die Auswahl bedingungslos auf den ersten Datensatz des Blattes, wodurch man beim Aufheben eines Filters die Stelle verlor, an der man gerade gearbeitet hat. Der ausgewählte Fund bleibt jetzt erhalten, solange er im Standardfilter vorkommt; andernfalls fällt die Auswahl auf den obersten sichtbaren Fund. Die Ersatzwahl nutzt bewusst `filterAndSortRecords` mit denselben Vorgaben wie die Trefferliste — eine erste Fassung filterte nur den Status und landete dadurch auf dem ersten Fund der unsortierten Blattreihenfolge statt auf dem obersten angezeigten. Im Browser beide Fälle geprüft: ein im Standardfilter enthaltener Fund bleibt über einen gesetzten und wieder zurückgesetzten Kategoriefilter hinweg ausgewählt; ein bestandener Fund (Status „Bestanden") wird nach dem Zurücksetzen durch den obersten sichtbaren ersetzt. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | Trefferliste, Lesespalte und Filtermarkierung nachgeschärft: (1) Gesetzte Filter tragen statt einer Haarlinie einen 2px-Rahmen mit Versatz und zusätzlichem Innenring — auf der eingefärbten Gruppenfläche des hellen Skins war die Haarlinie kaum zu sehen. (2) Die Karten der Trefferliste sind höher (62 → 78px), stehen mit 8px Abstand statt 3px, tragen 8px-Ecken und denselben Schattenwurf wie die Kacheln; sie liegen damit auf `--panel-raised` und heben sich beim Überfahren um 1px. Die Position des Hakens im Severity-Hexagon folgt jetzt der Polsterung, statt auf einen festen Pixelwert der alten Dichte zu zeigen. (3) Die Lesespalte war in ihrer Spalte zentriert, wodurch auf breiten Bildschirmen eine große leere Fläche zwischen Trefferliste und Text stand. Sie steht jetzt linksbündig mit festem Abstand über das neue Token `--reader-inset` (80px), das auf schmalen Fenstern über Medienabfragen auf 22px beziehungsweise 12px zurückgeht. Im Browser gemessen: Kartenhöhe 78px, Ecken 8px, Abstand 8px, Schatten gesetzt, Abstand Trefferliste zu Text exakt 80px, Filterrahmen 2px in `rgb(255,168,37)`. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | „Target" in die hervorgehobene Filtergruppe aufgenommen und deren Zusammensetzung an die Bedeutung gebunden: Die Gruppe wurde bisher über eine feste Anzahl (die ersten fünf Facetten) bestimmt. Bei einem Bericht ohne eine dieser Facetten wäre dadurch eine beliebige andere nachgerückt. Stattdessen entscheidet jetzt dieselbe Liste, die auch die Reihenfolge festlegt: Ergebnisstatus plus die als Arbeitsfilter benannten Spalten (`isPrimaryFacet` in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts)). Reihenfolge damit Ergebnisstatus → Severity → Category → MITRE ATT&CK → MITRE D3FEND → Target. Im Browser verifiziert: die sechs genannten Facetten liegen in der Gruppe, Quelle-, Result-message- und SI-version-Filter außerhalb. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-26 | Lesespalte auf die fachliche Aussage reduziert und nackte Adressen anklickbar gemacht: Herkunftsfelder (`Quelle: Datei`, `Quelle: Blatt`, `Quelle: Scan`), Kennungen (`Rule ID`, `ShortName`, `SI version`, `Target`, `Runtime`), `Points Scale` und die ANSSI-Referenzen erscheinen nicht mehr im Finding-Abschnitt, sondern unter den Zusatzinformationen — sie sind über die Filterleiste erreichbar beziehungsweise reine Nachschlagewerte und drückten die eigentliche Aussage nach unten. Zusätzlich erkennt [RichTextValue](../src/components/RichTextValue/RichTextValue.tsx) jetzt nackte http- und https-Adressen im Fließtext und rendert sie als Verweise: mehrere Werkzeuge liefern ihre Belegstellen als reine Textliste — PingCastle etwa das Feld „Documentation" mit aneinandergereihten Microsoft-Learn-Adressen —, die mangels HTML-Auszeichnung bisher toter Text blieben. Abschließende Satzzeichen und Klammern gehören nicht zur Adresse; innerhalb bereits ausgezeichneter Anker wird nicht erneut verlinkt, sodass keine verschachtelten Anker entstehen. Die erzeugten Verweise tragen dieselbe Absicherung wie bestehende Anker (`target="_blank"`, `rel="noopener noreferrer"`, ausschließlich http/https), da Berichtsinhalte als nicht vertrauenswürdig gelten. Im Browser verifiziert: PingCastle-Fund zeigt im Finding-Abschnitt nur noch Description, Advised solution, Documentation, Technical explanation und Verwandte Daten; Purple-Knight-Fund nur Result message, Number of results, Description, Remediation und Likelihood of compromise; die vier Dokumentationsadressen sind Verweise mit korrektem `target` und `rel`. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Filterleiste als Arbeitswerkzeug geschärft: (1) **Kaskadierende Zähler** — jede Facette zeigt jetzt die Trefferzahlen, die sich aus den davor stehenden Filtern ergeben, statt gegen den unveränderten Gesamtbestand zu zählen (`cascadeFacetCounts` in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts)). Der eigene Filter greift bewusst erst nach dem Zählen, sonst zeigte jede gesetzte Facette für alle nicht gewählten Werte null; die Werteliste bleibt vollständig, damit eine Auswahl nicht verschwindet, sobald sie gerade keine Treffer hat. (2) **Feste Arbeitsreihenfolge** Ergebnisstatus → Severity → Category → MITRE ATT&CK → MITRE D3FEND, danach Herkunfts- und Reviewfacetten. Die Reihenfolge hängt zusätzlich an der Spaltenüberschrift, weil die Rollenerkennung bei Purple Knight „Severity" und „Category" nur als `additional` einstuft — die Rollenpriorisierung griff dort nicht und die wichtigsten Filter standen am Ende. (3) Die fünf vorderen Facetten liegen in einer **mit dem Markenton hinterlegten Gruppe** (`--accent-surface`). (4) **Gesetzte Filter bleiben umrandet** (`is-filtered`, Aktivton). (5) „Standardfilter" heißt jetzt **„Zurücksetzen"** und ist dauerhaft im Aktivton eingefärbt bei unveränderter Funktion; die Regel braucht erhöhte Spezifität, da die Übergangsregel für `.btn` im hellen Skin sonst gewinnt. (6) Die rohe Statusspalte erscheint nicht mehr zusätzlich als Filter, da die Facette „Ergebnisstatus" dieselbe Aufgabe erfüllt — bisher wurde sie nur bei sicher erkannter Rolle ausgeblendet. Im Browser verifiziert: Reihenfolge und Gruppenzugehörigkeit korrekt, Zurücksetzen `rgb(240,160,32)`, Severity- und Category-Zähler summieren sich auf 57 statt 156, nach Wahl von „Critical · 6" fallen die Category-Zähler auf Summe 6 und die Trefferanzeige auf 6. Die Zusage in `tests/features/dynamic-facets.test.ts` wurde auf das neue Verhalten gezogen. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Lesestufe eingeführt und PingCastle-Detailfließtext aus dem Finding-Abschnitt genommen: Die Ableton-Dichte war für die Lesespalte zu weit getrieben — der Fließtext des Finding-Abschnitts war von zuvor 17px auf 14px gefallen. Neue Tokens `--ui-reading-size` (1rem/16px) und `--ui-reading-heading-size` (1.125rem/18px) trennen die Lesefläche von der dichten Werkzeugtypografie: `.reader-summary` und das Ergebnisfenster stehen auf der Lesestufe, während Plaketten und Tabellenköpfe bei 12px, Bedienelemente bei 13px und Listen bei 14px bleiben. Am laufenden Reader gemessen: h3 18px, h4 16px, Fließtext und `rich-text-value` 16px. Zusätzlich wird das PingCastle-Feld „Details" nicht mehr im Finding-Abschnitt gerendert, sobald strukturierte Ergebnisse vorliegen: PingCastle liefert dieselben Beweisdaten doppelt — einmal als Abschnitte, die das Ergebnisfenster als Tabelle rendert, und einmal als Fließtext, in dem die Tabellen ohne Spaltengrenzen aneinandergereiht sind und der die halbe Lesespalte füllte. Das Feld wandert unter „Zusatzinformationen" und bleibt dort vollständig erhalten; ohne strukturierte Ergebnisse bleibt es unverändert im Finding-Abschnitt, damit keine Evidenz verlorengeht. Im Browser verifiziert: „Details" nicht mehr unter den Finding-Beschriftungen, aber im aufgeklappten Zusatzblock vorhanden. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Ergebnisfenster in das Farbschema des Fundes eingefügt und Lesefläche vergrößert: Das Popup trug eine violette Umrandung und eine eigene, fast schwarze Fläche (`#0b0c10`) und stand damit sichtbar außerhalb der Designsprache. Es nutzt jetzt dieselbe Fläche wie der Reader dahinter (`--bg`) und grenzt sich über eine kräftigere Haarlinie (`--line-strong`) ab; der Fenstertitel trägt die Typografie der Finding-Überschrift `.reader-summary h3` (16px, `--ui-strong-weight`), der Rumpf `--ui-body-size` statt 16px. Das Token `--result-color` wechselt wie angekündigt vom Markenton auf `--state-active` (Bernstein), da ein geöffnetes Ergebnisfenster eine Werkzeugfunktion ist; die drei zuvor darauf hart gesetzten weißen Schriftfarben tragen jetzt die dunkle Tinte des Aktivtons. Dabei fiel eine Folgeursache auf: `themes.css` setzte den Reader im hellen Skin über eine Übergangsregel auf `--panel-raised`, wodurch er sich von jeder anderen Fläche unterschied — die Regel stammte aus der Zeit vor der Tokenisierung von `legacy-views.css` und `base.css` und ist samt der Überschreibungen für Rohdatenansicht, Reviewfelder und Tabellenköpfe ersatzlos entfallen. Zusätzlich liegen die Feldbeschriftungen im Finding-Abschnitt (`.reader-summary h4`) jetzt auf der Fließtextstufe (14px) statt auf der kleineren Label-Stufe der Bedienleisten. Rohe Farbwerte von 89 auf 85 gesunken, Obergrenze für `components.css` auf 30 nachgezogen. Im Browser in beiden Skins gemessen: Reader und Popup tragen identische Flächen (dunkel `rgb(43,43,43)`, hell `rgb(191,191,191)`), kleinste Schriftgröße im Finding-Abschnitt 14px. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Typografie auf `rem` mit 12px-Untergrenze umgestellt: Die Schriftgrößen-Tokens in [tokens.css](../src/styles/tokens.css) stehen jetzt in `rem` statt `px` und folgen damit der im Browser eingestellten Standardschriftgröße, die `px` ignoriert — ein Barrierefreiheitsgewinn. Bewusst **kein** Responsive-Mechanismus: `rem` reagiert nicht auf die Fensterbreite, damit Tabellen und Plaketten bei jeder Fenstergröße gleich umbrechen; Rahmenstärken und Radien bleiben in `px`. Neue Skala: Label, Small und Value 0.75rem (12px), Control 0.8125rem (13px), Body 0.875rem (14px), dazu neu Heading 1rem (16px) und Glyph 1.3125rem (21px) für Symbolschaltflächen. 81 fest verdrahtete `font-size`-Werte in sechs Stildateien wurden auf die Skala abgebildet; übrig bleiben nur `clamp()`-Überschriften mit Untergrenzen von 17px aufwärts. Damit verschwinden die bisherigen 8px- und 9px-Stellen (Topbar-Kennzahlen, Bereichs-Kicker, Status- und Severity-Plaketten, Kartenstatus) sowie sämtliche 10px- und 11px-Werte. Der Designprüfer erhält eine dritte Regel: jede absolute Schriftgröße in einer `font-size`-Deklaration und in jedem Typografie-Token muss mindestens 12px beziehungsweise 0.75rem betragen, `clamp()` eingeschlossen; die Regel wurde durch einen absichtlich eingefügten 9px-Verstoß als wirksam nachgewiesen. Im Browser gemessen: kleinste tatsächlich gerenderte Schriftgröße 12px, Verteilung 12/13/14/16/21/23px. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Standardansicht zeigt nur noch Abweichungen: Ursache der bisher mit angezeigten bestandenen Prüfungen war nicht der jeweilige Werkzeugstandard, sondern das **generische Profil** — der betroffene Bericht wurde keinem Werkzeug zugeordnet und lief unter `generic`, das gar keine Statusfilter besaß (`statusFilters: []`, `defaultStatusFilter: 'all'`). Es erhält jetzt ein werkzeugunabhängiges Statusvokabular (Abweichung, Bestanden, Nicht anwendbar, Nicht ausgeführt, Fehler) mit `deviation` als Standard; die Muster treffen die in `ImportProfile.matchesStatus` bereits vereinheitlichte Schreibweise, decken das Vokabular aller unterstützten Werkzeuge ab und halten „failed to run" bewusst vom fachlichen Scheitern getrennt. Ergänzend stehen CIS-CAT und Maester auf `failed` statt `all`; Purple Knight stand bereits auf `ioes-found`. Die Profilversion des generischen Profils bleibt bewusst auf 1.0.0, weil sich nur eine Ansichtsvorgabe ändert und die Version je Vorkommen als Provenienz gespeichert wird. Zusätzlich erscheinen erzählende Spalten nicht mehr als Auswahlfilter: Wird ihre Rolle nur als `additional` erkannt, griff die bisherige Rollenprüfung nicht — „Remediation" landete dadurch als Filter in der Leiste, obwohl Abhilfetexte je Finding einzigartig sind. Eine zusätzliche Prüfung der Spaltenüberschrift in [dynamic-facets.ts](../src/features/search-filter/dynamic-facets.ts) schließt sie jetzt unabhängig von der Rollenerkennung aus. Die Filterleiste bleibt unverändert als Auswahlfelder über der Ansicht. Im Browser verifiziert: Statusfilter steht auf „Abweichung", Optionen Abweichung · 57, Bestanden · 95, Nicht anwendbar · 4; angezeigt werden 57 Karten, keine davon mit Pass-Kennzeichnung. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Reader-Aufbau geschärft und Designsprache Stufe 2 für die Reader-Ansichten abgeschlossen: (1) Die Überschrift des Finding-Abschnitts trägt jetzt den Inhalt von „Check title" (die Pruefbeschreibung der Regel) statt des generischen Wortes „Finding"; das Feld wird dafür in [FindingReader.tsx](../src/features/finding-reader/FindingReader.tsx) erst nach der Sichtbarkeitsberechnung aus der Zusammenfassung gelöst, damit es nicht zusätzlich unter den Zusatzinformationen erscheint, und der eigene „Check title"-Block entfällt. Die Versalien der Überschrift wurden aufgehoben, da sie nun einen Satz trägt. (2) Der erläuternde PingCastle-Score-Absatz wurde samt Markup und Stilregel entfernt. (3) `.bookmark-label` war hellviolett und im hellen Skin kaum lesbar, jetzt `--text`. (4) **Grauwerte des hellen Skins nach den Vorlagen korrigiert:** Wertfelder sind in Ableton Light *heller* als ihre Fläche, nicht dunkler — `--surface-inset` wurde von `#bdbdbd` auf `#d5d5d5` gedreht und die gesamte Skala auf Abletons Bereich gesetzt (Arbeitsfläche `#bfbfbf`, Bedienelemente `#d8d8d8`, Auswahl `#b8d8f5`, Text `#101010`). Im dunklen Skin bleibt das Verhältnis wie gehabt umgekehrt. (5) [legacy-views.css](../src/styles/legacy-views.css) vollständig auf Tokens umgestellt: Neomorph-Schatten, 12px-Radien, Hover-Versatz und der komplette Sonderblock für den hellen Skin entfallen; Auswahl nutzt `--state-selected`, gemerkte Einträge und geöffnete Ergebnisse `--state-active`, Severity-Hexagone und -Plaketten die Severity-Tokens. Damit war der weiße Arbeitsbereich beseitigt, der zuvor aus `html[data-theme="light"] .viewer { background: #fff }` stammte und die themes.css-Regel überschrieb, weil diese Datei zuletzt geladen wird. Rohe Farbwerte von 211 auf 96 gesunken, `legacy-views.css` von 114 auf **0**; Obergrenzen des Prüfers nachgezogen, der Eintrag für die Datei entfällt. Im Browser in beiden Skins verifiziert: Überschrift ohne Versalien in `rgb(0,0,0)`, „Check title"-Block und Score-Absatz nicht mehr im DOM, Bookmark-Label `rgb(16,16,16)`. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Seitenleisten-Navigation auf den Aktivton umgestellt: Der aktive Bereich trägt jetzt `--state-active` (Bernstein) in Schrift und Symbol; der zuvor links gesetzte rote Markierungsbalken (`.sidebar-primary-actions button.active::before`, dunkel `#b3123f`, hell violett) entfällt ersatzlos, da die Farbe die Markierung übernimmt. Die gesamte Navigation läuft über Tokens, wodurch sechs Sonderregeln des hellen Skins entfallen. Der Ansichtsmodus ist in der Seitenleiste horizontal zentriert und bleibt auf ausdrücklichen Wunsch rundlich (40×40, Radius 50 %) — als dokumentierte Ausnahme von der sonst eckigen Formensprache. Rohe Farbwerte von 217 auf 211 gesunken (`layout.css` von 26 auf 20), Obergrenze des Prüfers nachgezogen. Im Browser in beiden Skins verifiziert: aktive Navigation `rgb(255,168,37)` dunkel und `rgb(240,160,32)` hell, Markierungsbalken nicht mehr gerendert, Schalter mittig. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Sidebar nach Nutzerabnahme bereinigt und Farbrolle der Nebenfunktionen festgelegt: Der Dateistatus-Block (Datensätze, Felder, Blätter, Format) wurde samt Markup in [App.tsx](../src/app/App.tsx) und seinen Stilregeln (`.sidebar-kpis`) ersatzlos entfernt; der Systemstatus-Block bleibt unverändert. Beim Ansichtsmodus entfällt die Überschrift „Ansicht"; die drei Schaltflächen sind eckig mit Haarlinie statt kreisrund mit Neomorph-Schatten, das Symbol steht auf 21px. **Neue verbindliche Rolle:** Werkzeug- und Nebenfunktionen tragen den Aktivton `--state-active` (Bernstein), der Markenakzent `--accent` (Violett) bleibt der primären Aktion vorbehalten; die Regel ist im Kopf von [tokens.css](../src/styles/tokens.css) dokumentiert, zusammen mit dem Grundsatz, dass Akzentfarben Zustände markieren und niemals Text. Da Abschnittstitel und Ansichtsmodus jetzt vollständig über Tokens laufen, entfallen vier Sonderregeln des hellen Skins ersatzlos. Rohe Farbwerte von 224 auf 217 gesunken (`layout.css` von 33 auf 26), Obergrenze des Prüfers nachgezogen. Im Browser in beiden Skins verifiziert: Dateistatus und „Ansicht"-Überschrift nicht mehr im DOM, drei Schaltflächen, aktive Fläche `rgb(240,160,32)` hell und `rgb(255,168,37)` dunkel. 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema- oder Persistenzänderung. |
| 2026-07-25 | Lesbarkeitskorrektur nach Nutzerabnahme der neuen Designsprache: **Überschriften und Beschriftungen tragen keine Akzentfarbe mehr.** Betroffen waren die Abschnittsüberschriften der verknüpften Ergebnisse (`.linked-results section > strong`, zuvor fest `#c9bedf`) — im hellen Skin heller Violettton auf grauer Fläche und damit praktisch unlesbar —, die Aufklapper „Verknüpfte Results" und „Zusatzinformationen" (`.all-fields summary`), die Reader-Navigation, die Merkschaltfläche, die Fließtextverweise, `.workbar-action b`, `.area-kicker` sowie `.finding-techniques`. Alle nutzen jetzt `--heading` beziehungsweise `--text`/`--muted`: im hellen Skin dunkelgrau (`#0f0f0f`), im dunklen nahezu weiß (`#ececec`), gemessen rund 15:1 und 9:1 Kontrast gegen die jeweilige Panelfläche. Ebenfalls korrigiert: die Reviewbeschriftungen (`.dashboard-grid label`, `.review-grid > label`) standen fest auf Weiß und ergaben im hellen Skin weiße Schrift auf grauer Fläche; und die aufgeklappte Zeile des Ergebnis-Browsers nutzte die Auswahlfarbe `--state-selected` als Fläche, worauf der Detailfließtext schlecht lesbar war — Aufklappen ist kein Auswahlzustand und erhält jetzt die neutrale Fläche `--panel-raised`. Rohe Farbwerte von 229 auf 224 gesunken, Obergrenzen des Prüfers entsprechend nachgezogen (`legacy-views.css` 114, `components.css` 35, `mitre-graph.css` 34). 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich. Keine Schema-, Persistenz- oder Komponentenänderung. |
| 2026-07-25 | Designsprache auf Ableton Live umgestellt, Stufe 1 und Musterbildschirm: `tokens.css` ist jetzt die einzige Quelle für Farbe, Dichte und Typografie und trägt eine vollständige Skala (Flächen inklusive eingesenkter Wertfelder, Haarlinien, Text, Zustände, Semantik, Severity, Abstände, Radien, Rahmenstärke, Steuerelementhöhe, Typografie). Neu ist die aus Ableton übernommene **Rollentrennung der Akzente**: `--state-selected` (blau) für Auswahl, `--state-active` (bernstein) für aktiv/scharf, `--accent` (violett) bleibt der Markenton für die primäre Aktion. Chrome ist in beiden Skins durchgehend grau — hell mittelgrau statt weiß, dunkel mittelgrau statt fast schwarz —, Schatten entfallen (`--shadow: none`), Radien auf 2px, Grundschrift von 14px auf 12px. `themes.css` überschreibt nur noch Tokenwerte; seine Klassenregeln sind als Übergangsbestand markiert und enthalten keine rohen Farbwerte mehr. Die Typografie-Tokens lagen bisher am Ende der Ladereihenfolge in `legacy-views.css` und hätten die Sprache überschrieben — sie sind nach `tokens.css` gewandert. Vollständig umgestellt: `tokens.css`, `themes.css`, `base.css` (alle Steuerelemente), `datahub.css` (Datahub, DB-Struktur, Ergebnis-Browser). Damit sinken die rohen Farbwerte von 443 auf 229, alle im noch nicht umgestellten Restbestand. Neu ist der Prüfer [tests/design-language-check.mjs](../tests/design-language-check.mjs) (`npm test`, `npm run test:design`) nach dem Vorbild von `local-only-check.mjs`: er verbietet rohe Farbwerte außerhalb von Token-Deklarationen, erzwingt, dass jedes referenzierte Token definiert ist, verbietet Inline-Styles in React und führt eine ausschließlich schrumpfende Obergrenze je Altbestandsdatei. Er hat sofort zwei stille Defekte derselben Klasse gefunden: `--panel-hover` ([layout.css:74](../src/styles/layout.css:74)) und `--result-color` ([components.css:43](../src/styles/components.css:43), [legacy-views.css:277](../src/styles/legacy-views.css:277)) wurden referenziert, ohne definiert zu sein — die betroffenen Hover- und „Ergebnisse geöffnet"-Zustände rendeten ersatzlos; beide Tokens sind jetzt definiert. Offen für Stufe 2: `legacy-views.css` (115), `components.css` (38), `mitre-graph.css` (35), `layout.css` (33), `dynamic-filters.css` (7), `import-workflow.css` (1). 355 Standardtests, Local-only-Prüfung, Designprüfer und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Keine Schema-, Persistenz- oder Komponentenänderung; ausschließlich Stildateien, `package.json` und der neue Prüfer. |
| 2026-07-25 | Seit 2026-07-23 gemeldeten Dauerausfall in `tests/server/gpo-artifact-reconciler.test.ts` behoben: Der Test injizierte eine fest datierte Uhr (`2026-07-23T08:00:00.000Z`) bei 60 Sekunden Karenz, schrieb die unreferenzierte Waisendatei aber real über den Artefaktspeicher, sodass sie die echte Systemzeit als mtime trug. Sobald die reale Uhr dieses Datum überschritt, lag die mtime dauerhaft hinter dem Alterungs-Cutoff (`information.mtimeMs > objectCutoff`, [server/artifacts/backend-artifact-store.ts](../server/artifacts/backend-artifact-store.ts)), die Waise wurde fail-safe zurückbehalten und die Zusage `removedUnreferencedObjects: 1` schlug unabänderlich fehl. Reine Testkopplung, kein Produktionsfehler: Die Reconciliation selbst verhielt sich unverändert korrekt, weshalb ausschließlich der Test geändert wurde. Der Reconciliationszeitpunkt wird jetzt relativ zur realen Uhr abgeleitet (`Date.now() + 24 h`), womit real geschriebene Objekte immer vor dem Cutoff altern und kein kalendarisches Ablaufdatum mehr entsteht. Die fachliche Zusage bleibt unverändert: referenziertes Artefakt wird repariert, integritätsgeprüft gelesen und behalten, nur die gealterte Waise wird entfernt, genau ein Objekt bleibt liegen. Die beiden Retentionstests derselben Datei prüfen dadurch zusätzlich schärfer, weil sie das Zurückbehalten nun allein über die Sperren „kein vertrauenswürdiger Referenzbestand“ beziehungsweise „ungültige Legacy-Speicherreferenz“ belegen und nicht mehr beiläufig über eine noch junge mtime. 355 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; keine offenen Testausfälle mehr. Keine Produktions-, Schema- oder Mandantendatenänderung. |
| 2026-07-25 | PingCastle-Befunde werden wieder als IOE geführt (Profil 1.0.0 → 1.1.0): PingCastle berichtet ausschließlich ausgelöste RiskRules und setzt dafür den Status „Matched". Das PingCastle-Profil deklarierte für diesen Wert kein Mapping, sodass die generische Rückfallregel `matched|detected` griff und den Treffer bewusst als bloßen Hinweis las (`open`/`warning`). Über die Vertragskette bedeutete das: `deriveExposureState` kennt `warning` nicht und liefert `unknown`, `deriveIsIoe` verlangt aber `detected` — dadurch war **kein einziger** PingCastle-Befund `is_ioe`, obwohl `result_type` korrekt `exposure_finding` war. Das PingCastle-Profil deklariert den exakten Wert „Matched" jetzt selbst als `failed`; damit greift der bereits vorhandene Vorrang des Profil-Mappings vor der generischen Regel ([src/importers/status-normalization.ts](../src/importers/status-normalization.ts)) und die Kette löst sich zu `fail` → `detected` → `is_ioe = true` auf. Unspezifische Treffertexte (z. B. „detected") bleiben unverändert ein Hinweis, andere Werkzeuge sind nicht betroffen, da nur das PingCastle-Profil eine eigene Statusliste erhält. Die Profilversion wurde angehoben, weil die Profilversion je Vorkommen persistiert wird; **bereits importierte Läufe behalten ihren alten Status und benötigen für die IOE-Sicht einen Reimport**. Synthetische Regressionen ergänzt (`tests/importers/status-normalization.test.ts`: „Matched" → fail sowie die vollständige Kette bis `is_ioe`); die Versionszusage in `tests/profiles/declarative-profiles.test.ts` prüft nun gegen den Profilkatalog statt gegen eine feste Zahl. 354 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; derselbe unabhängige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverändert fort. Keine Schemaänderung. |
| 2026-07-23 | PingCastle-Details-Vervollständigung nach Nutzerabnahme (Extractor 1.6.0): Vier verifizierte Korrekturen. (1) Eine Regel kann die direkt eingebettete Beweistabelle UND einen Ankerverweis zugleich tragen (z. B. A-DC-Spooler); bisher verdrängte die eingebettete Tabelle die Ankerauflösung — jetzt werden beide Quellen erfasst, das "Verwandte Daten"-Feld trägt eine Liste von Sektionen und der Results-Popup zeigt mehrere Blätter; dadurch werden auch acht zuvor verdeckte Ankerziele (u. a. useraccountanalysis, gpofirewall, auditsettings, admincountequalsone) erstmals aufgelöst. (2) Der Fundtitel folgt jetzt dem PingCastle-Card-Header (identisch zur XML-Rationale, z. B. "The spooler service is remotely accessible from 1 DC") statt der generischen h3-Prüfbeschreibung; die Prüfbeschreibung bleibt als neues Feld "Check title" erhalten, HTML- und XML-Import erzeugen damit denselben Fundnamen. (3) Die beim Import abgeleitete kanonische Severity wird deterministisch als Anzeigefeld "Severity" gespiegelt (nur wenn kein natives Severity-/Criticality-/Priority-Feld existiert), womit Karten, Kacheln und Reader-Hexagone erstmals gefärbt werden — zuvor lag der Wert nur am Occurrence-Objekt, das die Work-Felderansicht nicht liest. (4) Zielabschnitte, deren Tabelle keine Datenzeilen hat (der Report listet dort nur nicht aufgetretene Ausnahmen), fallen auf ihre Fließtextdarstellung zurück, sodass der Results-Popup nie leer erscheint. Synthetische Regressionen ergänzt (Extractor: kombinierte Quellen, Card-Header-Titel; Projektion: Prose-Fallback, Severity-Spiegelung). 331 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; derselbe unabhängige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverändert fort. Keine Schemaänderung; das Payload-Format des "Verwandte Daten"-Felds wurde auf eine Sektionsliste umgestellt, bestehende Läufe benötigen für den Popup einen Reimport. |
| 2026-07-23 | PingCastle-"Details:"-Ankerauflösung: Verweist "Details:" nicht auf eine direkt eingebettete Tabelle (bereits gehärtet), sondern per internem Dokumentanker (`<a href="#id">Label</a>`) auf einen eigenständigen Datenabschnitt an anderer Stelle im selben Bericht (z. B. "LAPS", "Admin Groups", "Domain controllers"), wird der Abschnitt jetzt bis zu seinem strukturellen Ende (`<!-- SubSection Name -->` … `<!-- SubSection Name end -->` … nächste SubSection) aufgelöst und als Fließtext plus enthaltene Tabellen an das Details-Feld angehängt; zuvor blieb nur der einleitende Verweissatz sichtbar. Zwei sicherheitsrelevante Vorstufen waren dafür nötig: `sanitizeHtmlText` entfernt regulär sowohl `href`-Attribute als auch HTML-Kommentare (beides richtig gegen aktiven Inhalt); ein eng begrenzter Vorlauf überführt ausschließlich `href="#<sicheres Zeichenset>"` sowie PingCastles eigene `SubSection`-Kommentare vor der Sanitisierung in inerte Marker, jeder andere `href`- oder Kommentarwert bleibt unverändert der regulären Entfernung unterworfen. Gegen den ausdrücklich freigegebenen Dummy-Report gegengeprüft: 37 Regeln, keine Ausreißergröße (max. 5.250 Zeichen bei einer tabellenreichen Zielsektion), Grenzen halten exakt an der nächsten SubSection. Synthetische Regression ergänzt (`tests/importers/pingcastle-source-extractor.test.ts`). 328 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; derselbe unabhängige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverändert fort. Keine Schemaänderung. |
| 2026-07-23 | PingCastle-Details-Ergebnis-Popup: Der HTML-Extraktor liefert die aufgelöste Zielsektion einer "Details:"-Ankerverlinkung nun zusätzlich strukturiert (Header/Zeilen) über ein eigenes Feld `Verwandte Daten`, statt nur als Fließtext. `canonical-model-to-dataset.ts` baut daraus je eindeutigem Zielabschnitt genau ein Tabellenblatt mit deterministischer ID (mehrere Regeln, die auf denselben Abschnitt verweisen, teilen sich ein Blatt statt zu duplizieren) und blendet den rohen Strukturwert aus der normalen Feldanzeige aus, sodass nur die kurze Abschnitts-ID sichtbar bleibt. Ein neues, PingCastle-eigenes Verknüpfungsmodul (`pingcastle-section-links.ts`) verlinkt per exakter ID-Gleichheit statt der bei Purple Knight verwendeten Text-Heuristik und speist den bestehenden Results-Button/Popup-Mechanismus zusätzlich zur bisherigen Purple-Knight-Verlinkung. Synthetische Regression ergänzt (`tests/features/canonical-model-to-dataset.test.ts`: ein Abschnitt, zwei referenzierende Findings, ein gemeinsames Blatt, exakte Verlinkung). 329 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; derselbe unabhängige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverändert fort. Keine Schemaänderung. |
| 2026-07-23 | PingCastle-Severity-Ableitung aus Points: PingCastle-Regeln besitzen kein natives Severity-Feld, nur Points je Regel. Eine neue, versionierte, werkzeuggebundene Regel (`pingcastle-severity-from-points@1.0.0`, [src/profiles/pingcastle/pingcastle-severity.ts](../src/profiles/pingcastle/pingcastle-severity.ts)) übernimmt PingCastles eigene Score-Legende (0 = informativ, 1–10 = low, 11–30 = medium, > 30 = high) von der Kategorieebene auf die einzelne Regel; `critical` bleibt für PingCastle bewusst unerreichbar, bis eine gesondert versionierte Zusatzschwelle definiert wird. Eine neue werkzeuggebundene Registry ([src/importers/severity-from-score-registry.ts](../src/importers/severity-from-score-registry.ts)) greift ausschließlich, wenn kein natives Severity-Feld erkannt wurde; andere Werkzeuge sind unverändert. Der Nativwert (Points) und eine erklärende Provenienz bleiben nachvollziehbar. Ziel ist die tooluebergreifende Filterbarkeit über `severity_normalized` in der Unified-Result-Projektion. Synthetische Regression ergänzt (`tests/profiles/pingcastle-severity.test.ts`, erweitertes `tests/importers/pingcastle-source-extractor.test.ts`). 328 Standardtests, Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen; derselbe unabhängige, bereits gemeldete Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` besteht unverändert fort. Keine Schemaänderung. |
| 2026-07-23 | PingCastle-HTML-Detailtabellen-Nachhärtung: Rendert PingCastle nach "Details:" unmittelbar eine eingebettete Tabelle (kein externer Verweis, sondern nur ein interner Dokumentanker), wurde diese bislang stillschweigend verworfen und nur der einleitende Satz übernommen. Der HTML-Extraktor erfasst nun eine direkt folgende Tabelle als Teil des Details-Feldwerts (Extractor-Version 1.1.0 → 1.2.0). Zusätzlich wurde der aus Purple Knight stammende, generische Ergebnisverweis-Mechanismus (`resultReferenceFields`) von der Feldbezeichnung „Details" entkoppelt, die bei Purple Knight nie verwendet wird, aber bei PingCastle zu einem irreführenden „Keine passende Ergebnisdatei gefunden"-Hinweis führte, obwohl die Daten inline vorlagen. Ursache wurde am ausdrücklich freigegebenen Dummy-Mandanten (PingCastle-Report `ad_hc_sevenkingdoms.local`) verifiziert: von 34 Regeln mit „Details:" enthalten 18 eine eingebettete Tabelle; die zugehörige XML-Exportvariante trägt für 36 von 37 Regeln überhaupt keinen Detail-Knoten und bleibt daher strukturell auf die HTML-Begleitdatei angewiesen. Synthetische Regression ergänzt (`tests/importers/pingcastle-source-extractor.test.ts`, `tests/profiles/result-linker.test.ts`). 323 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Ein einzelner, von dieser Änderung unabhängiger Testausfall in `tests/server/gpo-artifact-reconciler.test.ts` (zeitbasierte Testkopplung zwischen injizierter Uhr und echter Dateisystem-mtime) wurde separat gemeldet, nicht behoben. Keine Schemaänderung, keine Mandantendaten verändert. |
| 2026-07-22 | Phase-13A-PurpleKnight-Results wiederhergestellt: Der kanonische SourceTable-Vertrag bewahrt Zeilen nicht ausgewählter Workbook-Tabellen als Originalfelder, während Finding-Tabellen keine redundante Kopie erhalten. Die Work-Projektion rekonstruiert unterstützende Tabellen nach den fachlichen Ansichten; bestehende Result-Referenzen öffnen wieder das Results-Fenster. Synthetische Persistenz-, Projektions-, Linker- und PingCastle-Reihenfolgeregressionen ergänzt. 291 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Der freigegebene reviewfreie Dummy-PurpleKnight-Lauf wurde mit derselben lokalen XLSX ersetzt und im Codex-Browser auf 20 Results-Buttons sowie die erwartete Ein-Zeilen-/Vier-Spalten-Tabelle geprüft. Die abschließende Bestandsprüfung stellte den bereits zuvor fehlenden separaten PingCastle-XML-Lauf aus der lokalen freigegebenen Datei mit 37 Findings wieder her; Dummy enthält im Browser erneut 193 Findings aus PurpleKnight, PingCastle HTML und PingCastle XML. Additive kanonische JSON-Vertragserweiterung, keine SQL-Migration. |
| 2026-07-22 | Phase-13A-PingCastle-Auswertung vervollständigt: XML-Extractor auf individuelle Regelpunkte, vier Kategorie-Scores, Domain Risk Level sowie strukturierte Details/ExtraDetails erweitert; HTML-Kategorien normalisiert. Exakte projektlokale HTML/XML-Begleiter werden in Work über Dateistamm plus Rule ID statisch angereichert, ohne Originalfelder oder dynamische Scanwerte zu überschreiben; die Regeltext-Quelle bleibt sichtbar. Score-Badges und Herstellerformel werden im Reader erklärt. Synthetische Regressionen ergänzt; 289 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich, 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Der ausdrücklich freigegebene Dummy-Abgleich reproduziert 37 Rule IDs und die Herstellerformel exakt; der reviewfreie alte XML-Lauf wurde ersetzt, der HTML-Lauf ergänzt und im Codex-Browser auf zwei getrennte 37er-Ansichten, Regeltexte, Score-Badges und ExtraDetails geprüft. Keine Schemaänderung. |
| 2026-07-22 | Phase-13A-Work-Darstellung nach Import korrigiert: Auto-Commit und bestätigter Batch-Commit laden nun anhand der serverseitigen Projekt-ID das persistierte kanonische Mandantenmodell; auch openProject verwendet denselben Loader. PingCastle-XML erscheint als fachliche RiskRules-Ansicht statt als generischer HealthcheckData-Elementbaum, und Title ist die Standardüberschrift. Synthetische End-to-End-Projektionsregression ergänzt. 287 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; die laufende PostgreSQL-Anwendung ist gesund und Dummy wurde rein lesend auf 37 XML-Findings, vorhandene XML-Unteransicht, ausgewählten Titel und nicht sichtbaren DomainSid-Knoten geprüft. Keine Persistenz- oder Schemaänderung. |
| 2026-07-22 | Scan-Historie nachgehärtet: projektgebundene Löschung eines einzelnen Scan Runs mit exakter Bestätigung in Repository, PostgreSQL, lokaler Persistenz, API, Client und Datahub ergänzt; Abhängigkeiten, verwaiste Definitionen/Fingerprints und ungültige Vergleiche werden kontrolliert bereinigt. Bekannte Scannerläufe mit höchstens 60 Sekunden auseinanderliegenden Dateizeitpunkten werden in der Historie und bei zielmandantengebundener Uploadvorschau als auswählbares „Mögliches Duplikat“ markiert; exakte SHA-256-Dubletten bleiben blockierend getrennt. Synthetische Domain-, UI-Helfer-, Repository-, API- und HTTP-Regressionen ergänzt. 286 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich. PostgreSQL-Löschpfad zusätzlich über zwei synthetische Scan-IDs in der laufenden API geprüft und vollständig aufgeräumt; Dummy im Codex-Browser nur hinsichtlich Markierung, Schaltfläche und Dialog geprüft, keine Löschung ausgeführt. |
| 2026-07-22 | Native Work-Projektion für PingCastle und andere dateibasierte Source Extractors ergänzt: Persistierte Finding-Vorkommen ohne künstliche `SourceTable` erhalten je Importdatei eine auswählbare Unteransicht mit Werkzeug, Scandatum und Format. Die freigegebenen Dummy-PingCastle-Dateien wurden rein lesend verifiziert und erzeugen im aktuellen Importer jeweils 37 von 37 Candidates ohne offene oder ausgeschlossene Mappings; reale Inhalte wurden nicht in Tests übernommen. Synthetische Projektionsregression ergänzt. 282 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Keine Persistenz- oder Schemaänderung. |
| 2026-07-22 | Native PingCastle-Erkennung nachgehärtet: dedizierten sicheren Source Extractor für HTML-Regelblöcke und `HealthcheckData/RiskRules`-XML ergänzt, wiederholte HTML-Renderings je Rule ID dedupliziert, Rule-ID-Identität formatübergreifend vereinheitlicht und dateibezogene Vorkommen samt Locators erhalten. Synthetische HTML-/XML-Paritäts-, Sicherheits- und Persistenzregressionen ergänzt. 281 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Keine Persistenz- oder Schemaänderung. |
| 2026-07-22 | GPO-Ordner-Submission nachgehärtet: vollständige sichere Containerprüfung bleibt im begrenzten Worker, die Vorstufe übernimmt nur noch eine kompakte Erkennung; vollständiges Inventar und Parsermodelle bleiben an der Jobgrenze. Workerfehler werden ohne rohe Meldungen in sichere Kategorien überführt. Der synthetische Produktionslauf mit 91.316.402 Bytes, 2.040 Einträgen, 300 Backupinstanzen und 45.000 Beobachtungen ist bei 512 MB einschließlich Vorstufe erfolgreich. 281 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild grün; Phase 13B bleibt in Arbeit. |
| 2026-07-22 | Zweiten scannerseitigen Unified-Result-Vertikalschnitt umgesetzt: `FindingOccurrence` besitzt getrennte optionale `MappedValue`-Dimensionen für fachliches Outcome und technische Ausführung; der Candidate-Importer persistiert beide und klassifiziert „Failed to run“ als `execution_error`/`failed` statt als fachliches `fail`. Additive Migration 007 ergänzt geprüfte, indexierte Spalten sowie namespaced, profilversionierte Resultkategorien und eine mehrwertige Occurrence-Relation mit Backfill. Beide PostgreSQL-Importpfade schreiben Dimensionen und Kategorien atomar; Legacy-Daten bleiben über den alten Status lesbar. 277 Standardtests, Local-only-Prüfung und Client-/Serverbuild erfolgreich; 7 von 7 PostgreSQL-Integrationstests nacheinander gegen frisches PostgreSQL 16 erfolgreich. Ausschließlich synthetische Daten; temporärer Testcontainer entfernt. Phase 13B bleibt in Arbeit. |
| 2026-07-22 | Schritt 0 der Datenmodellkonsolidierung in `docs/UNIFIED_RESULT_MODEL.md` dokumentiert und ersten scannerseitigen Unified-Result-Vertikalschnitt umgesetzt: plattformneutraler Read-Typ mit getrennten Severity-, Outcome-, Execution-, Review-, Lifecycle- und Effective-Dimensionen; strukturierte namespaced Kategorien; Result-, Facetten-, Kategorien- und Detailmethoden im `AssessorRepository`; gleiche Local-/PostgreSQL-Semantik; versionierte Read-API und Client. Equal-Title- und Status-/Kategorien-/Reviewregressionen sowie HTTP-/Clienttests ergänzt. GPO-PolicyObservation bleibt außerhalb der Projektion, bis PolicyIdentity, Baseline und Evaluation umgesetzt sind. Keine Migration. 274 Standardtests, Local-only-Prüfung und Client-/Serverbuild erfolgreich; PostgreSQL-Integration 7 von 7 erfolgreich. Ausschließlich synthetische Daten. Phase 13B bleibt in Arbeit. |
| 2026-07-22 | GPO-Worker-Speicherfehler vollständig nachgehärtet: Zunächst wurde die quadratische Quellzeilenberechnung von Registry Preferences, Local Users and Groups, Services und Drive Maps durch einen linearen Scanner ersetzt. Nachdem der konkrete Fehler weiterhin auftrat, reproduzierte ein verschärfter synthetischer Produktionsworker-Test den zweiten Peak bei 512 MB. Der Persistenzpfad verarbeitet Policydateien nun backupwurzelweise und gibt Parser-Zwischenmodelle sofort frei; die Worker-Rückgabe enthält weder vollständigen Container noch Dokumentmodelle. Registry Preferences werden mit dem fest versionierten lokalen SAX-Parser `saxes` 6.0.0 ereignisbasiert verarbeitet, während DTD, Entitäten, Includes, Schemas und fremde Processing Instructions weiterhin vor dem Parser blockiert werden. Derselbe zuvor fehlschlagende Lauf mit 91.316.402 Bytes, 2.040 Einträgen, 300 Backupinstanzen und 45.000 Beobachtungen ist bei 512 MB erfolgreich. 270 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich; 7 optionale PostgreSQL-Tests erwartungsgemäß übersprungen. Keine realen GPO- oder Mandanteninhalte gelesen; Phase 13B bleibt in Arbeit. |
| 2026-07-21 | Phase-13B-Fehlerverwaltung und Lastgrenze gehärtet: Dead-Letter-GPO-Analysen können in der Mandantenansicht ohne erneuten Upload kontrolliert neu eingeplant werden. Ein explizit bestätigtes Löschen entfernt ausschließlich die ASSESSOR-Kopie samt relationaler Historie; Migration 006 persistiert zuvor einen unabhängigen Löschauftrag, den Start-/Stunden-Reconciliation nach einem Prozessabbruch wiederaufnimmt. Große Worker-Eingaben werden als eigene Bytekopie per Transferliste übergeben; der weiterhin begrenzte Standardheap wurde auf 1.024/128 MB angehoben. Zusätzlich werden JSDOM-Fenster nach jedem Metadaten-/Preference-Dokument garantiert geschlossen und nur persistenzrelevante Ergebnisse über die Workergrenze übertragen. Ein synthetischer Lastlauf mit 1.740 Dateien, 80.186.702 Bytes und 300 Backupinstanzen war unter derselben 1-GB-Grenze erfolgreich. 267 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 7 von 7 PostgreSQL-Integrationstests gegen frisches PostgreSQL 16 erfolgreich. Eine nicht unterstützte synthetische Legacy-Speicherreferenz blockiert reguläre Orphan-Löschungen fail-safe, ohne die Reconciliation abzubrechen. Nur synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Persistente GPO-Statusanzeige und Orphan-Reconciliation ergänzt: Die Mandantenansicht lädt und aktualisiert Queue-, Lauf-, Erfolgs-, Teil-, Dead-Letter- und Recoveryzustände aus der Datenbank einschließlich Versuchen, Zeitpunkten, Fehlercode und erkannter Backupinstanzzahl. GPO-Artefakt und Analysejob werden atomar angelegt; fehlgeschlagene Dateischreib-/DB-Kombinationen werden sofort kompensiert. Eine beim Backendstart und stündlich laufende Reconciliation repariert fehlende Jobs und entfernt ausschließlich mindestens 24 Stunden alte, unreferenzierte reguläre Objekte beziehungsweise Stagingreste, begrenzt auf 100 je Lauf; bei leerem vertrauenswürdigem Referenzbestand ist jede Objektlöschung gesperrt. 259 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; PostgreSQL separat 6 von 6 gegen frisches PostgreSQL 16 einschließlich Transaktionsrollback. Nur synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Phase-13B-GPO-Ordnerimport ergänzt: Im Datahub kann für einen bestehenden Mandanten unter Chrome das vollständig entpackte Backupverzeichnis ausgewählt werden. Relative Pfade werden streng normalisiert und kollisionsgeprüft; bis zu 20.000 Einträge und 100 MB werden sequenziell sowie bytegleich in einen deterministischen unkomprimierten Transportumschlag geschrieben und über die bestehende projektgebundene GPO-Ingestion erneut im gehärteten Worker geprüft. UI-Status meldet Annahme beziehungsweise Deduplizierung als Queuezustand. 253 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 von 5 PostgreSQL-Integrationstests gegen frisches PostgreSQL 16 erfolgreich. Ausschließlich synthetische Daten; Testcontainer entfernt. |
| 2026-07-21 | Phase-13A-Zielkontextfehler behoben: Beim Wechsel eines bestätigungspflichtigen Imports in die Vorschau wird der bestehende Workflowkontext einschließlich `targetProjectId` nun erhalten. PingCastle- und andere Scannerimporte werden nach manueller Freigabe weiterhin dem ausgewählten Mandanten zugeordnet, statt unbeabsichtigt einen neuen Mandanten anzulegen. Synthetische Zustandsregression ergänzt; 249 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich. Keine Schemaänderung und keine realen Mandanteninhalte für Tests verwendet. |
| 2026-07-21 | Phase-13A-Regressionsfix für umfangreiche HTML-Scannerberichte: Quelltabellen-IDs um den stabilen Tabellenindex ergänzt und unverändert in die Dataset-Projektion übernommen. Wiederholte Caption-/Tabellennamen bleiben dadurch getrennte Source Tables; die kanonische Validierung meldet keine künstlichen `duplicate-id`-Fehler mehr. Synthetische Regression mit zwölf identisch benannten HTML-Tabellen ergänzt. 248 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; keine Datenbankänderung und keine realen Mandanteninhalte verwendet. |
| 2026-07-21 | Group-Policy-Preferences um Drive Maps erweitert: technische Drives-/Drive-CLSIDs, kanonische Item-UIDs, C/D/R/U, Common Options und Targeting werden validiert. User-Scope wird erzwungen; UNC-Ziel, Persistenz, Label, optionales NETBIOS-Konto, Buchstabe, `useLetter` und getrennte Sichtbarkeit bleiben erhalten. Die aktionsabhängigen Auswahlmodi `exact`, `delete-range`, `first-available` und `first-mapped-in-range` verhindern eine falsche Endwertaggregation. `cpassword` wird nie übernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 247 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Group-Policy-Preferences um den CSE Services erweitert: technische NTServices-/NTService-CLSIDs, kanonische Item-UIDs, Common Options und Targeting werden validiert. Services verwendet die CSE-spezifische Instruktion `configure`; `serviceAction`, `startupType`, Dienstkonto, Desktopinteraktion, Fehleraktionen und dokumentierte Zeit-/Recovery-Felder bleiben getrennt und unverändert. Nur Computer-Scope wird reduziert; User-Scope und unbekannte Eigenschaften bleiben `partial`, fehlerhafte unterstützte Werte blockieren fail-closed. `cPassword` wird nie übernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 242 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Group-Policy-Preferences um den CSE Local Users and Groups erweitert: technische Groups-/User-/Group-CLSIDs, Item-UIDs, Aktionen, Common Options und Targeting werden validiert; Benutzer-, Gruppen- und Mitgliedschaftswerte bleiben getrennt. SID-Priorität, Delete-all-users/-groups vor der geordneten Memberliste und Add/Remove je Mitglied werden erhalten. `cpassword` wird niemals übernommen, nur `passwordAttributePresent` und ein Geheimnisindikator werden persistiert. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 237 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Ersten Group-Policy-Preferences-Vertikalschnitt umgesetzt: begrenzter XML-Parser mit Ablehnung aktiver/externer Konstrukte, strikter CLSID-/UID-/Attributprüfung und Geheimnisindikator; eigener Registry-Preference-Reducer bewahrt Create/Delete/Replace/Update, Reihenfolge, Disabled, Remove-on-unapply, Apply-once und nicht ausgewertetes Item-Level-Targeting. Unbekannte CSEs und Registry-SubProperties bleiben `partial`, fehlerhafte unterstützte Strukturen blockieren ohne Salvage und `effectiveState` bleibt `unknown`. Worker, Backupinstanz, atomarer Job-Commit, lokaler Export und PostgreSQL-JSONB-Roundtrip sind integriert. 234 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Advanced-Audit-Vertikalschnitt umgesetzt: Der allgemeine CSV-Pfad stellt nur begrenzte lexikalische Dekodierung und physische Quellzeilen bereit; ein eigener versionierter Parser/Reducer wertet technische Subcategory-GUIDs und numerische Auditflags 0 bis 3 aus, ignoriert lokalisierte Anzeigenamen, unterstützt vorerst nur Systemziele und hält benutzerspezifische Ziele `partial`. Abweichende Dubletten werden Konflikte, fehlerhafte unterstützte Zeilen blockieren ohne Salvage und `effectiveState` bleibt `unknown`. Beobachtungen durchlaufen Worker, Backupinstanz, atomaren Job-Commit, lokalen Export und PostgreSQL-JSONB-Roundtrip. 228 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Ersten artefaktspezifischen Phase-13B-Parser umgesetzt: begrenztes UTF-8/BOM-UTF-16-INF-Parsing für Security Templates, getrennte Instruktionen für System Access, Kerberos, Privilege Rights und Registry Values sowie versionierter Reducer zu validierten Policy-Beobachtungen. Quellzeilen, Parser-/Reducer-Version, technischer Artefaktbezug und rohe typisierte Werte bleiben erhalten; abweichende Dubletten werden Konflikte, unbekannte Abschnitte `partial`, ungültige unterstützte Werte blockiert und `effectiveState` bleibt `unknown`. Beobachtungen durchlaufen Worker, Backupinstanz, atomaren Job-Commit, lokalen Export und PostgreSQL-JSONB-Roundtrip. 222 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Nur synthetische Daten; Container entfernt und Docker Desktop gestoppt. |
| 2026-07-21 | Lease-basierte GPO-Jobausführung und unveränderliche Ergebnispersistenz umgesetzt: Der begrenzte Runner claimt nur `analyze-gpo-backup`, liest das projektgebundene Original über den integritätsprüfenden Artefaktspeicher und persistiert versionierten Processing Run plus Backupinstanzen atomar vor dem Jobabschluss. Deterministische IDs ermöglichen revisionsneutrale Wiederaufnahme nach einem Crash zwischen Commit und Queue-Abschluss; abweichende Historie wird abgelehnt. Migration 005 ergänzt die relationale Tabelle mit zusammengesetzter Projekt-/Artefakt-/Run-Referenz. 215 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests separat 5 von 5 gegen frisches PostgreSQL 16 erfolgreich. Ausschließlich synthetische Daten; Testcontainer entfernt und Docker Desktop gestoppt. Weitere Policy-Artefaktparser und Reducer bleiben offen. |
| 2026-07-21 | Projektgebundene GPO-Submission umgesetzt: sichere Größen-/Base64-Prüfung an der HTTP-Grenze, Projekt- und Worker-Vorprüfung vor Aufbewahrung, `secret`-Sensitivität, Webroot-Trennungsprüfung, unveränderte Speicherung sowie deterministische Artefakt- und idempotente Jobidentität. API und Client geben keine Speicherschlüssel oder geparsten Inhalte aus. Additive PostgreSQL-Migration 004 ergänzt `analyze-gpo-backup`; realer Persistenz-/Lease-Test gegen kurzlebiges PostgreSQL 16 erfolgreich. 210 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf übersprungen und separat 5 von 5 erfolgreich. Ausschließlich synthetische Daten; Testcontainer anschließend entfernt. Jobausführung und relationale GPO-Ergebnispersistenz bleiben offen. |
| 2026-07-20 | Phase-13B-Vertikalschnitt erweitert: backendkontrollierter Rohartefaktspeicherbaustein mit zufälligen Schlüsseln, Staging, Flush, tatsächlicher SHA-256-/Größenprüfung, überschreibungsfreier Veröffentlichung und verifizierten Reads; selektiver verifizierter ZIP-Zugriff; begrenzter XML-Metadatenparser im GPO-Worker; konservative Backupinstanzen aus getrennten GPO-/Backup-IDs und Same-root-Evidenz. Namen werden nicht als Identität verwendet, Konflikte blockieren fail-closed und `cpassword`-Werte werden nicht ausgegeben. 201 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich, 5 optionale PostgreSQL-Tests übersprungen; ausschließlich synthetische Daten, keine Schemaänderung. Öffentliche API-/Job-/Projektbindung und relationale GPO-Persistenz bleiben offen. |
| 2026-08-01 | Minimierte Result-Fenster: automatisches sequentielles Stapeln in Öffnungsreihenfolge umgesetzt; ab 2 minimierten Fenstern erscheint oben links am ersten Result ein Verschiebe-Viereck mit 4-Pfeile-Symbol zum Verschieben des gesamten Clusters. Das Minimieren/Maximieren-Symbol wurde links neben den "To Matrix" ("To Report") Button platziert. 475 Unit-Tests, Local-only-Sicherheitsprüfungen, Designsystem-Zusagen und Client-/Server-Produktionsbuild erfolgreich verifiziert. |
| 2026-07-20 | Sichere GPO-ZIP-Inventarisierung umgesetzt: eigener produktiv gebauter Backend-Worker mit Eingabe-, Parallelitäts-, Heap- und Zeitgrenzen; vollständige Prüfung von Zentralverzeichnis und lokalen Headern, Pfaden, Unicode-/Case-Kollisionen, Typen, Datenbereichen, tatsächlichen Größen und Kompressionsverhältnissen, CRC und SHA-256. Links, Spezialdateien, verschachtelte Archive und Strukturkonflikte blockieren atomar; Inhalte werden nur im Speicher geprüft und nicht ausgeschrieben. GPO-Pfade erzeugen ausschließlich vorsichtige Rollen-/Abschnittsklassifikation mit inventory-only oder unsupported; Parser- und Geheimnisstatus bleiben explizit offen. 189 Standardtests, Local-only-Sicherheitsprüfung und Client-/Serverbuild erfolgreich, 5 optionale PostgreSQL-Tests übersprungen; ausschließlich synthetische ZIP-Fixtures, keine Schemaänderung. |
| 2026-07-20 | Phase 13B begonnen: GPO-Bestandsaufnahme und Bedrohungsmodell dokumentiert, gemeinsame sichere relative Artefaktpfade gehärtet sowie versionierte GPO-Backup-, Inventar-, Abschnitts-, Domänen-, Erhebungs-, Backupsatz- und Snapshotverträge implementiert. Der deterministische Builder trennt historische Sets und Domänen, blockiert Duplikate, Konflikte und unzulässige Erhebungszeitspannen und erlaubt Set-Abwesenheitsaussagen nur für konsistente manifestgestützte vollständige Exporte; Scope oder tatsächliche Wirksamkeit werden nicht behauptet. Ausschließlich synthetische Regressionen ergänzt; 182 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 5 optionale PostgreSQL-Integrationstests im Standardlauf übersprungen. Sichere Container-Ingestion, Speicher, Parser und Evaluation bleiben offen. |
| 2026-07-20 | Phase 13A abgeschlossen: Scannerpersistenz auf das bestätigte versionierte Candidate-Mapping migriert, plattformneutrale kanonische Candidate-Projektion ergänzt, native JSON-Provenienz erhalten, Vorschau-/Persistenzzählung vereinheitlicht und offene beziehungsweise manipulierte native Candidate-Entscheidungen abgesichert. Purple Knight, PingCastle, CIS-CAT, Maester, generischer Fallback sowie semantisch äquivalente CSV-/JSON-Inhalte wurden synthetisch bis ins kanonische Modell regressionsgeprüft; Architekturchecks verhindern Toolwissen in Formatadaptern und Parser-/Mappinglogik in React. 176 Standardtests, Local-only-/Architekturprüfung und Client-/Server-Produktionsbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf übersprungen und separat 5 von 5 gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich. |
| 2026-07-20 | Phase-13A-Persistenzunterbau umgesetzt: allgemeine projektgebundene Importartefakte, unveränderliche versionierte Processing Runs und persistente idempotente Ingestion Jobs mit atomaren Claims, begrenzten Leases und Versuchen, Recovery sowie Dead Letter in Domänenmodell, lokalem Repository und PostgreSQL-Migration 003 ergänzt. Projektgrenzen, sichere relative Pfade, Hashes, Speicherreferenzen, Export, Löschung und revisionsneutrale Wiederholungen sind validiert. 168 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich; 5 optionale PostgreSQL-Tests im Standardlauf übersprungen und separat 5 von 5 gegen eine frische kurzlebige PostgreSQL-16-Instanz erfolgreich. Phase 13A bleibt bis zur Scanner-Migration in Schritt 9 in Arbeit. |
| 2026-07-20 | Phase-13A-Finding-Identität abgesichert: versionierte dauerhafte/unresolved Identitätsstrategien eingeführt, unsicheren Titel-Fallback im kanonischen Import entfernt, automatische Titel-/Asset-/Merkmalsmatches im Vergleich entfernt, Profilvergleichsschlüssel auf Regel-IDs begrenzt und explizit bestätigte lokale Regeln mit strikter Eindeutigkeitsprüfung erhalten. Synthetische Identitäts-, Vergleichs-, Mehrdeutigkeits- und Validierungsregressionen ergänzt; 163 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Mappingtrennung umgesetzt: versionierte Candidate-Mapping-Verträge und eine gemeinsame Feldrollen-Evidenz für Recognition und Mapping eingeführt, Extractor- und Mappingprofil-Provenienz getrennt sowie Mapping nach bestätigten Profil-/Feldentscheidungen deterministisch neu berechnet. Originalwerte und Locators bleiben erhalten; die kanonische Persistenz bleibt bis Schritt 9 auf dem bestehenden Pfad. Synthetische Mapping-, Varianten-, Provenienz- und Bestätigungsregressionen ergänzt; 159 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Source-Extractor-Registry umgesetzt: neutrale FindingCandidate-Verträge, statische deterministische Registry, nativer JSON-Objektextractor und generischer Tabellenfallback eingeführt sowie parallel in die plattformneutrale Importpipeline aufgenommen. Bestehende kanonische Persistenz bleibt bis zur Mappingmigration unverändert. Synthetische Registry- und Strukturtreuetests ergänzt; 154 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Formaterkennung umgesetzt: zentrale evidenzbasierte Parserwahl mit Excel-/OLE-/ZIP-Signaturen, Inhaltsstruktur, Endungs- und MIME-Hinweisen eingeführt; tatsächliches Format steuert Sicherheitslimits, generische ZIPs, unbekannte Binärdaten und vorgetäuschte Excel-Dateien werden kontrolliert abgewiesen. Synthetische Spoofing- und Ressourcenregressionen ergänzt; 152 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase-13A-Vertragsblock umgesetzt: DecodedSourceDocument, gemeinsame Source-Locators, versionierte Adapter-/Transformationsprovenienz und deterministische Processing-States eingeführt; JSON-/XML-Originalstrukturen und bereinigter HTML-Text bleiben zusätzlich zur bestehenden tabellarischen UI-Projektion erhalten. Synthetische Architekturregressionen ergänzt; 148 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Phase 13A begonnen: Profilauswahl auf die gemeinsame Recognition Engine vereinheitlicht, Dateiname-only- und mehrdeutige Erkennung auf explizite Bestätigung begrenzt, Bestätigungs-Overrides durch Client und Backend konsistent und serverseitig validiert verarbeitet sowie Scan-Lauf-Werkzeug und Dateiprofil getrennt. Synthetische Regressionen ergänzt; 147 Standardtests, Local-only-Sicherheitsprüfung und Client-/Server-Produktionsbuild erfolgreich, 4 optionale PostgreSQL-Integrationstests erwartungsgemäß übersprungen. Phase 13A bleibt in Arbeit. |
| 2026-07-20 | Verbindliche Planung für Ingestion 2.0 und GPO-/Baselineanalyse ergänzt: neue offene Phasen 13A und 13B, gemeinsame Adapter-/Extractor-/Mappinggrenzen, eigenes PolicyObservation- und Evaluationsmodell, sichere Artefaktaufbewahrung, Analysesnapshots, CSE-spezifische Reduktion, typisierte Comparatoren, vollständigkeitsgesicherter Baseline-Consensus, Mehrquellen-Evidenz, Reprocessing sowie neue Entscheidungen und Risiken dokumentiert. Es wurden keine Implementierung und keine Meilensteinabnahme vorgenommen. |
| 2026-07-18 | Mandantenladen auf vollständige Historie erweitert: Open lädt nun alle Assessment-Modelle parallel, vereinigt sämtliche Scan-Läufe und Findings im Projektblatt und erhält pro Quelltabelle eine getrennte, laufbezogene Work-Ansicht. Die Regression wurde ausschließlich mit synthetischen CSV- und Excel-Assessments geprüft; reale Mandantendaten wurden nicht gelesen. 145 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-18 | Open-to-Work-Lücke geschlossen: Beim Öffnen eines Mandanten werden dessen Assessments abgefragt, das neueste kanonische Modell geladen und aus Originalfeldern, Quelldateien und Quelltabellen wieder als Work-Dataset aufgebaut. Der reale PostgreSQL-Mandant Test01 öffnet damit 162 PurpleKnight-Datensätze in neun auswählbaren Ansichten; Graph wird gleichzeitig nutzbar. 144 Tests, Local-only-Prüfung, Produktionsbuild und Browser-End-to-End-Prüfung erfolgreich. |
| 2026-07-18 | Phase-12-Datahub nachgeschärft: Mehrdatei-Uploads werden nach Scan-Lauf gruppiert und vorhandene achtteilige PurpleKnight-CSV-Exporte als ein PurpleKnight-Bericht angezeigt; neue Importe übertragen ein eindeutig erkanntes Batch-Werkzeug auf generische Begleitdateien. Der Mandanteneditor scrollt vollständig, verwendet die flache Work-Designsprache und besitzt oben Import Data, Save sowie bestätigtes Datenbank-Feedback; der alte Formularfooter wurde entfernt. Außer Datahub bleibt die Navigation bis zum expliziten Open deaktiviert. 142 Tests, Local-only-Prüfung, Client-/Serverbuild, PostgreSQL-Health und Browser-End-to-End-Prüfung erfolgreich. |
| 2026-07-17 | Phase-12-Mandantenbedienung präzisiert: Open aktiviert den Mandanten und wechselt nach Work; Work ist ohne Mandanten deaktiviert. Edit wurde vom abgedunkelten Popup in eine eigene Datahub-Seite mit Name, Bemerkung, Consultant, Import Data und chronologischer Dateihistorie überführt; Delete behält den geforderten Warnungsdialog. 138 Tests, Local-only-Prüfung, Client-/Serverbuild, PostgreSQL-Health und Browser-Rendering erfolgreich. |
| 2026-07-17 | Phase-12-Mandantenworkflow vervollständigt: Der Datahub ist alleinige Import-Schaltzentrale; Mandantenkacheln besitzen Open/Edit/Delete, die Detailansicht Import Data und bestätigungspflichtiges Delete sowie eine nach Quelldatum sortierte Scanberichtshistorie. Zielimporte aktualisieren bestehende Mandanten transaktional, ohne deren Namen zu überschreiben; eine schlanke Repository-/API-Abfrage liefert Importdateien ohne vollständigen Finding-Export. 138 Tests, Local-only-Prüfung und Client-/Serverbuild erfolgreich. |
| 2026-07-17 | Frontend- und Betriebsregression nach Phase 13 behoben: Datahub, Work und Graph besitzen wieder klar getrennte Oberflächen; Reader-Toolbar und Filter erscheinen nur im Arbeitsbereich. Vite leitet /api im Entwicklungsbetrieb an das lokale Backend weiter, der Client prüft die Verbindung erneut und start:local lädt die vorhandene PostgreSQL-Konfiguration. Client-/Serverbuild, 136 Tests, Local-only-Prüfung, PostgreSQL-Health und direkter sowie proxied API-Aufruf erfolgreich; Browseransicht bei 1440 × 900 gerendert. |
| 2026-07-17 | Phase-13-UI-Nachhärtung: Finding-Auswahl von vollständiger Filter-/Facettenberechnung entkoppelt, Kacheln, Titel und Result-Verknüpfungen memoisiert, verknüpfte Result-Tabellen bis zum Öffnen lazy gerendert, lokale Review-Persistenz aus dem sichtbaren Update verschoben und Result-Farbzuordnung im Light Mode korrigiert; Regressionstests, Standardsuite und Produktionsbuild erfolgreich. |
| 2026-07-17 | PingCastle-HTML-Nachhärtung: stackabhängige Base64-Regelprüfung, DOM-Volltextauswertung, Tabellenbreiten- und Zahlenbereichsberechnung durch iterative Verfahren ersetzt; begrenzte Extraktion für große oder tief verschachtelte HTML-Berichte ergänzt und mit 5,9-MB-PingCastle-Fall, 140.000 Zeilen sowie echtem Produktionsworker verifiziert. |
| 2026-07-17 | Phase 13 abgeschlossen: zentrale Importressourcenrichtlinie, ZIP-/XML-/HTML-/VBA-Härtung, CSV-Formelschutz, isolierte Parserworker mit Zeit-, Speicher- und Warteschlangengrenzen, begrenzter Vorschaucache sowie erweiterte Audit-, Sicherheits- und Lasttests integriert; 49 Testdateien mit 139 Tests, Local-only-Prüfung, Produktionsbuild, Worker-API-Smoke-Test und echte PostgreSQL-16-Integration erfolgreich. |
| 2026-07-17 | Phase 12 abgeschlossen: heterogener Vorschau- und Freigabeworkflow, erklärbare Zuordnungen, kontrollierte Einzelfehler, SHA-256-Dublettenerkennung, dauerhafte Fingerprint-Historie, kanonische Batchkonvertierung und atomarer PostgreSQL-Abschluss integriert; 44 Testdateien mit 119 Tests, Sicherheitsprüfung, Produktionsbuild und echter PostgreSQL-16-Integration erfolgreich. |
| 2026-07-17 | Phase 11 abgeschlossen: PostgreSQL-Repository, relationales JSONB-Hybridschema, prüfsummengeschützte Migrationen, atomare Importtransaktionen, Volltext-/JSONB-Indizes, Docker-Entwicklungsbetrieb und sicherer Backendstart integriert; 40 Testdateien mit 108 Tests, echter PostgreSQL-16-Lauf, Produktionsbuild, Health-Prüfung sowie praktischer Backup-/Restore-Test erfolgreich. |
| 2026-07-17 | Phase 10 abgeschlossen: lokales Node.js-Backend, versionierte Same-Origin-API, serverseitige Importengine für CSV, JSON, HTML, XML und Excel, statische Browserauslieferung, Sicherheitsheader, Requestschutz, strukturierte Fehler und Audit-Ereignisse integriert; 36 Testdateien mit 101 Tests, Sicherheitsprüfung, Produktionsbuild und gestarteter localhost-Prüfung erfolgreich. |
| 2026-07-17 | Phase 9 abgeschlossen: datenbankunabhängiger Repository-Vertrag, atomare Importtransaktionen, optimistische Konfliktprüfung sowie Verwaltung von Reviews, Profilen, Mappingregeln, Vergleichen, Export und Löschung integriert; 33 Testdateien mit 91 Tests, Local-only- und Architekturprüfung sowie Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 8 abgeschlossen: reproduzierbare Mehrlauf-Vergleichsengine, eindeutiges Stufenmatching, Lebenszyklus- und Änderungsanalyse sowie wiederverwendbare lokale Mappingregeln integriert; 32 Testdateien mit 85 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 7 abgeschlossen: dynamische Kategorie-, Zahlen-, Datums-, Herkunfts- und Reviewfacetten sowie sichtbare Import- und Mappingqualität integriert; 31 Testdateien mit 79 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 6 abgeschlossen: versioniertes Profilschema, gemeinsame Profil-Fabrik und Profile für Generic, Purple Knight, PingCastle, CIS-CAT Pro und Maester integriert; 29 Testdateien mit 74 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 5 abgeschlossen: erklärbare Quellen-, Tabellen- und Feldrollenerkennung, vier Konfidenzklassen, verlustfreier Fallback und Korrekturschnittstelle integriert; 28 Testdateien mit 68 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 4 abgeschlossen: plattformneutraler Bytequellen-Engine-Einstieg, Browseradapter für Datei/Text/Markup/Storage/Download, injizierbarer Clock und Architekturprüfung ergänzt; 26 Testdateien mit 63 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 3 abgeschlossen: universelles ImportDocument, gemeinsame Adapterpipeline, Roh-/Dekodiertwerte, Datentypen, Kopfzeilenkandidaten, Quellpositionen und strukturierte Diagnosen für alle Formate ergänzt; 24 Testdateien mit 60 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 2 abgeschlossen: kanonisches Assessment- und Finding-Modell, Referenzvalidator, Pilotquellen-Abbildung und Modelldokumentation ergänzt; 22 Testdateien mit 55 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 1 abgeschlossen: synthetische, quellengestützte Fixtures für PingCastle, CIS-CAT und Maester ergänzt und über den generischen Importweg automatisiert geprüft; 21 Testdateien mit 51 Tests, Local-only-Prüfung und Produktionsbuild erfolgreich. |
| 2026-07-17 | Phase 1 begonnen: Format- und Fehlerfalltests erweitert, generische Fixture und Testbaseline ergänzt, Gesamtworkflow und Belastungsfälle automatisiert, leere Importe abgewiesen und englische Titelzuordnung korrigiert; Phase bleibt bis zum vollständigen Quellenkorpus in Arbeit. |
| 2026-07-17 | Ersten versionierten Umsetzungsplan mit Zielarchitektur, Phasen, Abnahmekriterien, Entscheidungen und Risiken angelegt. |