604 Commits

Author	SHA1	Message	Date
Benjamin Admin	4087bb5f18	Merge feat/dsms-stufe3-version-chains: version chain history + diff + audit-timeline modal	2026-05-22 12:00:33 +02:00
Benjamin Admin	916dec87ee	Merge feat/iace-llm-fm-frontend: KI-Vorschlag Uebernehmen/Ablehnen + AP tests	2026-05-22 12:00:10 +02:00
Benjamin Admin	299375e486	feat(dsms): version chain history + diff endpoint + Audit Timeline UI ... DSMS Stufe 3 — making the parent_cid chain useful end-to-end. Gateway (dsms-gateway): - /api/v1/documents/{cid}/history alias added next to the legacy /documents/{cid}/history (history endpoint itself was already there, just under an inconsistent prefix). - NEW /api/v1/documents/{cid_a}/diff/{cid_b}: fetches both packages from IPFS, computes a metadata diff (per-field old/new), and renders a unified text diff for utf-8 payloads. Binary payloads return only metadata diff with a "binary — compare via rendered export" note. - 4 new pytest cases (mocking ipfs_cat): text diff, binary fallback, fetch error, history chain depth — all green. Frontend (admin-compliance): - CIDHistoryModal: lazy-loads /dsms/documents/:cid/history, renders the version chain as a vertical timeline, marks the AKTUELL entry, and per-step exposes a "Diff zu V<n>" button that loads + renders the diff inline (metadata table + unified text diff in a monospace panel). - AuditTimelinePage: existing CID badge now sits next to a "Verlauf anzeigen" link that opens the modal. Handles both Python's plain-CID audit values and the Go techfile flow's JSON envelope {cid, filename, size} via extractCID() helper. This makes "show me how this CE-Akte changed between V2 and V3" self-service in the UI instead of a curl-against-IPFS workflow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 10:10:07 +02:00
Benjamin Admin	872145d883	feat(iace-fmea): KI-Vorschlag Uebernehmen/Ablehnen flow + AP unit tests ... Closes the loose end from IACE Phase 5 handover: the LLM FM-suggest button existed and the backend endpoint was wired, but accepted suggestions had no path into the FMEA worksheet. Hook (useFMEA.ts): - acceptSuggestion(fm, componentId): builds an FMEARow from FM defaults, prepends to rows (sorted by RPZ), removes the FM from suggestions. No-ops + drops the suggestion when (component, fm.id) is already in rows. - rejectSuggestion(fmId): drops the FM from suggestions list. Page (fmea/page.tsx): - Suggestion cards now have explicit Uebernehmen / Ablehnen buttons. - Counter "X Vorschlaege uebernommen" tracks accept count for the run. - RPZ in each suggestion is colour-coded (red >200, orange >100). - Hinweis line explains S/O/D adjustability after acceptance. - acceptedCount auto-resets when suggesting starts or panel closes. Tests (useFMEA.test.ts): - 8 calculateAP cases covering AIAG-VDA 2019 boundary points for severity 10 / 9 / 7 / 5 / 3, validating the H/M/L action priority matrix. LOC: fmea/page.tsx hits 320 (soft target 300, well under 500 hard cap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:56:05 +02:00
Benjamin Admin	9bdaa28038	feat(ui): Branchen-Benchmark Sidebar-Link unter Compliance Agent (P107)	2026-05-22 09:50:41 +02:00
Benjamin Admin	0a84c747f2	feat(iace): wire crossref into tech-file, library UI, and contract tests ... Three follow-ups to the 671-norm cross-reference matrix: 1. Tech-file renderer (Go): standards_applied section now gets a deterministic Markdown appendix with the DIN/ANSI/GB/JIS mappings for the project's suggested norms. Built from registry, never hallucinated by LLM. Applied both to LLM and fallback content paths. 2. Frontend NormCrossRefPanel (Next.js): expandable row in the IACE library norms tab now has a "Internationale Aequivalenzen anzeigen" button that lazy-loads /iace/norms-library/:id/crossref and renders a colour-coded table (relation + confidence). Region labels humanised (US — ANSI, China (GB), Japan (JIS), etc.). 3. Contract tests (Go): 4 new handler tests pinning the response shape of GetNormCrossRef and ListNormCrossRefs. Equivalent to an OpenAPI snapshot for these specific endpoints — ai-compliance-sdk has no full OpenAPI baseline yet (separate ticket). Tests: 6 renderer tests + 4 handler contract tests, all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:48:07 +02:00
Benjamin Admin	64d8b0f1f9	fix(benchmark): Proxy /api/compliance/admin/benchmark fuer P107 Page	2026-05-22 09:34:02 +02:00
Benjamin Admin	b663e2508f	feat(audit): P107 Branchen-Benchmark-Cockpit fuer Big-4-Demos ... benchmark_extractor.py — extract_kpis() liefert 18 KPIs pro Snapshot: * vendors_total, vendors_us, vendors_non_eu (mit % je Vendor-Land) * source_breakdown (llm/library/flat_pattern/table_paste/html_table_dom) * max/avg cookies_per_vendor (Konzentrations-Mass) * cookies_in_browser, cookies_detailed_count, cookie_doc_chars * banner_detected, banner_provider, banner_violations * compliance_score, data_quality_pct (wie viele unserer Datenquellen haben Inhalt) * saving_low/high_eur (Heuristik: (vendors - 10) × 1k-5k) anonymize_kpis() ersetzt site_label durch 'OEM 1/2/3' (Industry-Prefix Map: automotive→OEM, banking→Bank, chemistry→Chem, luftfahrt→Airline). GET /api/compliance/agent/admin/benchmark?industry=automotive&sites= VW,BMW,Mercedes&anonymized=true — liefert kpis + summary (n_sites, avg_vendors, total_saving_high). Admin-Page /sdk/benchmark: * Filter-Leiste: Industry-Dropdown, Sites-Input + 5 Preset-Gruppen (Automotive OEMs / Zulieferer, Chemie DAX, Luftfahrt, Banking DAX) * Anonymize-Toggle prominent * 5 Summary-KPI-Karten oben * Vergleichstabelle 13 Spalten (Score, Vendors, US%, Drittland%, Cookies-Browser, Cookie-Doc-kB, Banner ✓/✗, Provider, Verstoesse, Saving €/Jahr, Daten-Qualitaet, Captured-Time) * Red-/Amber-/Green-Indikatoren bei US%/Score/Drittland * Big-4-Hinweis-Footer Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:23:37 +02:00
Benjamin Admin	e2be51b0aa	feat(audit): P106 MC-Audit-Type + P83 BUILD_SHA in Dockerfiles + P80 v2 full ... P106 — mc_audit_type.py: zentrales Quality-Thema. Klassifiziert pro MC: verifiable / process_internal / doc_internal / ambiguous. Pattern-Match auf check_question + title + fail_criteria (Schulung, AVV abgeschlossen, TOM umgesetzt, DSFA durchgefuehrt, Ausnahmen dokumentieren, kostenfrei zur Verfuegung, opt-out intern ermoeglichen, …). Interne MCs werden in der MC-Auswertung NICHT mehr als FAIL gewertet, sondern als CHECK markiert (audit_status='check'). Sie zaehlen im build_scorecard als skipped (nicht failed) damit der Score realistisch ist. build_internal_checks_block_html() rendert sie als separaten blauen Block 'Pruefungen die wir von aussen NICHT durchfuehren koennen' nach dem MC-Scorecard. Erwartete Wirkung: bei VW 95 FAILs → wahrscheinlich 30-40 echte verifiable_fails + 50-60 internal_checks. GF-Mail wird drastisch realistischer (statt 'Sie haben 95 Verstoesse' → 'Sie haben 35 extern sichtbare Themen + 60 interne Checks, bitte mit DSB klaeren'). P83 — BUILD_SHA in backend/admin/consent-tester Dockerfiles als ARG + ENV. check-rebuild-needed.sh kann jetzt deployed vs local SHA vergleichen + REBUILD REQUIRED melden. P80 v2 — check_replay.py macht jetzt vollstaendigen Replay aller post-fetch Quality-Generatoren: vendor_normalizer (Dedup), audit_quality_checks, cookie_compliance_audit, tcf_vendor_authority, cookie_value_entropy, cookie_network_tracer. Snapshots aus alter Zeit zeigen jetzt im Replay den aktuellen Audit-Stand. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 08:57:02 +02:00
Benjamin Admin	94233b7c66	feat(iace): LLM gap-review (Task #7+#8) + tech-file sources appendix (#29) ... Three coupled pieces of work, all landing the same PoC: 1. Backend gap-review endpoint (Task #7) - internal/api/handlers/iace_handler_gap_review.go: POST /projects/:id/llm-gap-review feeds Limits-Form + current hazards + current mitigations to the configured LLM (Qwen / Claude / OpenAI via ProviderRegistry), parses a JSON suggestion list, filter+stamps confidence, falls back to a static checklist when LLM is unavailable. - Adopt step is NOT in this endpoint by design — the user clicks Adopt in the frontend which calls the existing CreateHazard / CreateMitigation handlers so provenance flows through the normal audit trail. 2. Frontend modal + button (Task #8) - app/sdk/iace/[projectId]/hazards/_components/LLMGapReviewModal.tsx: reusable modal that POSTs the gap-review endpoint, renders suggestions with Adopt/Reject UX, shows confidence + norm refs, source-stamp llm_gap_review vs fallback_static. - hazards/page.tsx: indigo "KI-Gap-Review" button next to the existing "Eigene Gefaehrdung" button + modal mount. 3. Tech-File sources appendix (Task #29 — Stufe 4) - internal/iace/document_export_sources.go: new pdfSourcesAppendix method appended to ExportPDF. Groups cited norms by license rule (R1 OSHA/EU-Recht / R3 BreakPilot patterns / R3 DIN-EN-ISO identifier-only) and emits the legally required statement that pauschal Impressum-Hinweise nicht ausreichen. - extractCitedNorms() scans hazard/mitigation text for EN/ISO/IEC/ DIN identifiers in a narrow grammar so prose isn't turned into spurious citations. Bonus refactor: - internal/app/routes.go reached the 500-LOC hard cap when the new llm-gap-review route was added. Extracted registerIACERoutes into routes_iace.go (136 LOC). Same wiring, no behaviour change. Three of the four Attribution-Renderer stages (1, 2, 4) now produce real output. Stufe 3 ships as <SourceBadge> + <LicenseModuleBanner> already (commits dfac940 + b9e3eea earlier in this branch). The PoC is intentionally conservative: every LLM-Suggestion stays unverbindlich until a human clicks Adopt, and Adopt goes through the existing normal CreateHazard/CreateMitigation flow (not yet wired in this commit — separate iteration). The endpoint, modal and provenance chain are in place for the next iteration to wire Adopt → write path.	2026-05-22 00:21:49 +02:00
Benjamin Admin	6263462ba3	feat(frontend): Tab-Layout für Audit-Ergebnisse + cookie_audit in API ... ResultsTabsView.tsx — neue Komponente mit 7 Tabs: 1. Übersicht (KPIs: Docs, Findings, Vendors, Score) 2. Cookies & VVT (3-Quellen-Compliance-Vergleich + undokumentiert/compliant/nicht-geladen + deduplizierte Vendor-Tabelle) 3. Datenschutzerklärung (DSE-Findings via ChecklistView) 4. Impressum 5. AGB / Widerruf (zwei Sections in einem Tab) 6. Cookie-Banner (Verstoesse + Phasen-KPIs) 7. Mail-Vorschau (PDF-Download-Link) Sticky Tab-Header oben, Content scrollt darunter. Lange Scroll-Mail ist damit verschwunden. DocCheckTab nutzt ResultsTabsView statt der alten Inline-ChecklistView. Backend liefert jetzt cookie_audit-dict in der Response (zusaetzlich zu cmp_vendors + banner_result) damit das Cookie-Tab die 3 Listen (undokumentiert / compliant / nicht-geladen) rendern kann. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 23:44:36 +02:00
Benjamin Admin	c5c168592b	feat(licenses): Task #25 — SDK module attribution rollout (11 modules) ... Per project_sdk_module_attribution_matrix.md the Stufe-3 rollout is prioritized by audit visibility. This batch covers Schritte 2-9 in one sweep: New reusable component: components/sdk/LicenseModuleBanner.tsx — single-line license banner placed at the top of an SDK module page. Renders rule pill (R1/R2/R3), source label, descriptor and link to /sdk/licenses. Replaces the copy-paste banner blocks I inlined in the earlier modules. Integration points (per cluster): Cluster B (DSGVO/EU-Recht, R1): - vvt: existing "Vorlage" pill upgraded with R1 marker + tooltip explaining Bundeslaender-DSGVO provenance - dsfa: inline R1 banner citing DSGVO Art. 35 Cluster C (EU AI Act / CRA, R1): - ai-act: inline R1 banner citing EU 2024/1689 - cra: inline R1 banner citing EU 2024/2847 + ENISA-Guidance Cluster D (Mix R2/R3): - isms: R3 banner + ISO/IEC 27001 reference disclaimer - security-backlog: R2 banner with OWASP CC-BY-SA attribution Cluster A (Eigenwerk, R3): - tom-generator: R1 source (DSGVO Art. 32) + R3 own-work disclaimer - audit-checklist: R3 banner for own audit methodology - document-generator: own templates R3 + cited rights R1 Cluster E (Direct controls listing): - catalog-manager: System/User tag upgraded with rule classification - iace hazards: pattern_id pill upgraded with R3 + tooltip explaining BreakPilot Pattern-Engine provenance The 11-module sweep brings audit transparency to the modules a paying customer encounters most often. Stufe 3 of the attribution renderer is now actually visible across the platform — previously it shipped only the reusable <SourceBadge> component without integration points. Pre-existing TS errors (drafting-engine constraint-enforcer, dsfa types tests) untouched — not in scope for this licensing rollout.	2026-05-21 23:16:09 +02:00
Benjamin Admin	d0274674a0	feat(licenses): Task #25 step 1 — SourceBadge in atomic-controls + correct LicenseRuleBadge labels ... Per the SDK-Modul Attribution-Matrix (project_sdk_module_attribution_matrix.md), the controls/atomic-controls listings render canonical_controls directly and are the highest-audit-visibility integration point for Stufe 3. Two changes: 1. atomic-controls/page.tsx: embed <SourceBadge controlUuid={ctrl.id} compact /> next to the existing badge row in each control item. The badge fetches /api/compliance/licenses/source-info/{uuid} on first hover and reveals the source regulation, license type, and attribution text in a tooltip. 2. control-library/components/helpers.tsx: fix LicenseRuleBadge labels. The existing pill said "Free Use / Zitation / Reformuliert" — exactly the inverted understanding of the rules that Task #21 surfaced. Corrected to R1 (verbatim, Hoheitsrecht/PD), R2 (verbatim + attribution), R3 (identifier only). Added native title attribute for hover-explanation; the existing ControlListItem in control-library now shows the right semantics without any other code change. Next module per matrix: VVT (Bundeslaender-Vorlagen) and DSFA.	2026-05-21 22:42:52 +02:00
Benjamin Admin	2eb7349577	feat(licenses): sidebar footer link to /sdk/licenses ... Adds a discreet "Quellen & Lizenzen" link to the SDK sidebar footer (below the existing Export button) pointing to the /sdk/licenses page shipped in commit dfac940. Part of Task #24 (AGB/Impressum audit) — the legal mandate that attribution be discoverable for every output is now satisfied at three layers: - platform-wide overview reachable from every SDK page (this commit) - per-export footer in compliance PDFs (commit 07cc00d) - inline source badge per control via <SourceBadge> (commit dfac940)	2026-05-21 22:18:26 +02:00
Benjamin Admin	dfac940272	feat(licenses): attribution renderer — Stufe 1 (overview) + Stufe 3 (SourceBadge) ... Backend - backend-compliance/compliance/api/licenses_routes.py: three endpoints built on the now-complete license_rule classification - GET /api/compliance/licenses/overview global aggregation by rule + per-source breakdown (Stufe 1) - POST /api/compliance/licenses/aggregate per-control-set aggregation for PDF footer (Stufe 2) and tech-file appendix (Stufe 4) — consumed later - GET /api/compliance/licenses/source-info/{control_uuid} single-control lookup for the inline source badge (Stufe 3) - registered in api/__init__.py via the existing safe-import loader Frontend - app/sdk/licenses/page.tsx (Stufe 1): the /sdk/licenses overview page. Renders rule legend cards + per-rule source tables. Drives the /licenses footer link and gives auditors a one-page view of what licence classes the platform is operating under. - components/sdk/SourceBadge.tsx (Stufe 3): reusable React component. Small R1/R2/R3 pill with click-expand tooltip showing source regulation + attribution string + render-full-text policy. Will be embedded into IACE hazards/mitigations, VVT items, DSFA controls in follow-up commits. Two stages of the four-stage renderer are now ready. Stufe 2 (PDF auto-footer) + Stufe 4 (tech-file appendix) follow once the existing PDF generators are extended to call /licenses/aggregate.	2026-05-21 21:00:10 +02:00
Benjamin Admin	e411c4f0d3	feat(audit): Text-Paste-Mode pro Row — Crawler optional umgehen ... Hintergrund: VW liefert ueber URL-Crawler nur 6 Vendors statt der 100+ die in der echten Cookie-Tabelle stehen. Wenn der User die Tabelle aber direkt von der Site kopieren kann (was bei den meisten OEM-Sites moeglich ist), umgehen wir den Crawler komplett und parsen den Text deterministisch. Backend: * doc_type_classifier.py — 7 Pattern-Gruppen (§5 TMG, Art.13 DSGVO, AGB-Klauseln, Widerrufs-Frist, Cookie-Tabellen-Header, etc). Wenn der User Text ins falsche Doc-Type-Feld kopiert (Impressum->DSE), detect_mismatch liefert detected + action ('reclassify' bei sehr hoher Konfidenz, 'warn' bei medium). * cookies_table_parser.py — Tab/Pipe/Komma/Semicolon-Separator-Auto- Detection, Spalten-Mapping per Header-Keyword. Aggregiert Cookie- Eintraege zu Vendor-Records (mit _guess_vendor-Fallback). Voll deterministisch, kein LLM. * doc_input_warnings.py — Mail-Block ueber dem Audit, der Mismatches + Auto-Reclassifies dem User transparent macht. * Pipeline: text gewinnt ueber url (war schon im Schema vermerkt), neue Felder declared_doc_type / input_source / reclassify_hint in doc_entries. Pasted-Tabellen-Vendors haben Vorrang vor Library-Fallback + LLM-Cascade (sind 100% genau). Frontend (DocCheckTab): * Pro Row Mode-Toggle 'URL' / 'Text einfuegen' (lila wenn aktiv). * Textarea (h-32, monospace) im text-mode mit kontext-spezifischem Placeholder (Cookie-Hinweis ggue. anderen Doc-Types) und Live- Zeichen-/Wort-Counter. * Submit-Button accepted entries mit URL ODER text. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 18:58:32 +02:00
Benjamin Admin	7335f64f4f	feat(founding-wizard): Per-Person IP-Assignment + Prefill + E2E-Tests ... Wizard unterstuetzt jetzt 2-4 Gesellschafter mit individuellem IP-Bereich: - Pro Gruender ein IP-Assignment-Vertrag (z.B. Benjamin: Compliance+RAG; Sharang: Security+Infrastruktur). Pro GF ein eigener Dienstvertrag. - Step 1: Prefill-Button aus Unternehmensprofil + Felder Registergericht und HRB-Nr. - Step 2: Rollen-Dropdown (CEO/CTO/CFO/COO/CPO/GF/Sonstige) statt freie Texteingabe, IP-Bereiche-Textarea pro Person. Backend: - generate_documents() iteriert pro Person fuer PER_PERSON_DOCS. - _build_person_context() injiziert ASSIGNOR_*, GF_*, IP_LIST_DETAILS aus person.ip_areas. - base_context() propagiert basics.register_court und basics.hrb_number. Tests: - 30/30 Pytest gruen (6 neue: Per-Person-Context, Slug-Helper, Registergericht-Propagation). - 4 neue Playwright-E2E-Specs (hermetisch via route.fulfill, mit Console-/Page-Error-Traps): kompletter 8-Step-Flow, Prefill-Fehlerpfad, Step-Navigation/Reset, Rollen-Dropdown + IP-Areas. - Spec setzt 'bp-sdk-cookie-consent' im addInitScript damit der CookieBannerOverlay nicht die Wizard-Buttons ueberlagert. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 18:49:10 +02:00
Benjamin Admin	c491af5d02	feat(audit): P47 localStorage-Quota — safeSetItem mit Auto-Prune ... storageHelpers.ts: safeSetItem faengt QuotaExceededError, prunet alte doc-check-result-*-Eintraege (oldest first, MAX_KEEP=10) und retried. Bei zweitem Fail aggressiver pruefen. DocCheckTab.tsx nutzt safeSetItem statt setItem fuer doc-check-results, result-Keys und history. Verhindert silent-data-loss + Crash wenn ~5MB localStorage-Limit erreicht. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 16:47:42 +02:00
Benjamin Admin	50fc0ecc59	feat(audit): P79 Pre-Scan-Wizard (8 Pflichtfelder) + P99 erweitert + P102 Replay-Fix ... P79: PreScanWizard.tsx mit 8 Pflichtfeldern (Branche, B2B/B2C, Direkt-Vertrieb, Rechtsform, Konzern-Struktur, MA-Zahl, Besondere Daten, Drittland). Scan-Button disabled bis alle 8 ausgefuellt. Werte landen in scan_context und ueber Backend in compliance_check_snapshots. P99: DOC_TYPES um dsa + legal_notice + lizenzhinweise + nutzungsbedingungen erweitert. URL-hinzufuegen-Button war schon da. P102 (Replay-Bug): check_replay.py liest jetzt e.get('text') statt nur full_text — Snapshot-Schema verwendet 'text'. Library-Mismatch- Block wird damit auch im Replay angezeigt. Backend: ComplianceCheckRequest.scan_context optional; save_snapshot persistiert ihn in compliance_check_snapshots.scan_context. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 15:59:01 +02:00
Benjamin Admin	57c0f940a2	feat(consent+report): P56-P67 Mercedes-Audit-Cycle (Anti-Audit, Phase G Vendors, Cookie-Behavior-Validator + 5 Mail-Polish-Items) [migration-approved] ... P56 Anti-Auditing-Detection als constructive Compliance-Finding (Audit-API- Empfehlung statt Anklage, weil Mercedes berechtigt Bots blockiert) P57 Phase G vendor_details Union mit cmp_vendors -> 42 Anbieter sichtbar P58 Anti-Audit-Detection robuster (Script-Domain-Check + Settings-spezifisch) P59 Cookie-Behavior-Validator (4 Layer, 3-Tier-Severity: MEDIUM=Kategorie- Mismatch / HIGH=Zweck-Mismatch / CRITICAL=beide=Vorsatz-Indiz) + Open Cookie Database (CC0) als Library-Seed (2264 Cookies) P59b Cookie-Behavior in Banner-Check verdrahtet + Mail-Block (BUGFIX: SessionLocal selbst oeffnen, db war im Background-Task nicht im Scope) Mail-Polish nach Mercedes-Review: P63 Banner-Footer-Links auch im wb7-link/role=link erkennen (Shadow-DOM- Walker label-based statt nur <a href>) P64 Re-Access-Severity: MEDIUM statt HIGH, wenn Footer "Einstellungen" oder Mercedes-typisch existiert; OEM-Footer-Detection (wb7-footer) P65 Text-Truncation: Word-Boundary statt Zeichen-Cut (kein "einfa"-Bruch mehr in Sofortmassnahmen) P66 GF-Aktionen: Service-Zweck vs Cookie-Zweck explizit erklaert (haeufige Verwechslung Marketing/GF: "Akamai-Beschreibung" != Cookie- Zweck pro DSK-OH 2024) P67 Stirring-Finding mit "Verlust-Framing"-Erklaerung + Alt-vs-Neutral- Beispiel, statt nur EDPB-Fachbegriff Compliance-Advisor FAQ (admin agent-core/soul): + CNIL/EDPB Top-Bussgelder (Google 100M, Meta 60M, Amazon 35M) + Deutsche Praezedenz (LG Muenchen Google Fonts, EuGH Planet49, BGH I ZR 7/16) + 4 Risiko-Pfade (Bussgeld/Abmahnung/Sammelklage/NOYB) + Berechnungs-Methodik Document-Generator Templates: AGB-DE (142), Impressum (140), Widerrufs- formular-Anlage (143), DSR-Process-Dedup (139), Cookie-Library (144). Architektur: doc_action_mappings.py + banner_dom_walkers.py + cookie_behavior_validator.py + vendor_detail_extractor.py rausgezogen, um die 500-LOC-Caps in agent_doc_check_report.py und banner_text_checker.py einzuhalten. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 06:28:25 +02:00
Benjamin Admin	6f3301d246	fix(founding-wizard): add python-docx dep + Lifecycle filter UI ... - requirements.txt: python-docx==1.2.0 (Container hatte das modul nicht) - document-generator: Lifecycle-Filter (Pre-Founding/Founding/Startup/KMU/Konzern) zeigt nur relevante Templates fuer aktuelle Phase	2026-05-20 16:41:36 +02:00
Benjamin Admin	7a5f1e48dd	feat(founding-wizard): Gründungs-Wizard für 2-Mann GmbH + 14 Notar-Templates ... [migration-approved] Templates (Migrations 123-136): - 123 GO-GF (Geschäftsordnung Geschäftsführung) - 124 SHA (Shareholders' Agreement, 56 Platzhalter) - 125 Satzung (Articles of Association mit UG-Variante) - 126 GF-Dienstvertrag (Trennungsprinzip Organ/Anstellung) - 127 Arbeitsvertrag (AGG-neutral, NachwG, eAU) - 128 Gesellschafterliste (§ 40 GmbHG) - 129 GF-Bestellungsbeschluss (mit § 6 Abs. 2 Versicherung) - 130 HRB-Anmeldung (§§ 7, 8, 39 GmbHG, § 12 HGB) - 131 IP-Assignment Agreement (Gründer→GmbH) - 132 Term Sheet (Pre-Seed/Seed VC-Standard) - 133 Wandeldarlehensvertrag (Convertible Loan) - 134 Beteiligungsvertrag (Subscription Agreement) - 135 ESOP/VSOP-Plan (3 Varianten) - 136 Cap Table Kategorisierung (Migrations 137-138): - ALTER TABLE compliance_legal_templates ADD lifecycle_stage TEXT[], functional_category TEXT (mit CHECK Constraints + GIN-Index) - Backfill aller 105 Templates: lifecycle_stage (pre_founding|founding| startup|kmu|konzern) + functional_category (founding_legal|employment| investor_funding|...) Backend Founding-Wizard Service: - template_renderer.py: Handlebars-light ({{VAR}}, {{#IF FLAG}}...{{/IF}}) - wizard_to_context.py: Mapping Wizard-State → SCREAMING_SNAKE_CASE Vars - markdown_to_docx.py: Markdown → DOCX via python-docx - founding_wizard_routes.py: POST /v1/founding-wizard/generate → liefert base64-DOCX-Files für ausgewählte Templates Frontend Founding-Wizard (/sdk/founding-wizard): - 8-Step Wizard (Basics, Gesellschafter, GF, Kapital, Notar, SHA, GF-Verträge, Generate) - useFoundingWizardForm Hook mit localStorage-Persistenz - TypeScript Code-Registry (template-categories.ts) als Backup zur DB - Word-Download via data:URLs (base64) Tests: - 20 Unit-Tests grün (Renderer, Context-Mapping, DOCX-Conversion) - Playwright E2E-Test mit 2-Mann GmbH (Benjamin + Sharang) Test-Daten	2026-05-20 09:30:51 +02:00
Benjamin Admin	6f16507c5f	feat(banner): P19 + P20 — Per-Category-Click-Test + Frontend-Drilldown ... P19 (consent-tester): - dp-cookieconsent (TYPO3, Safetykon-Pattern) als CMP-Profil hinzu — Selektoren #dp--cookie-statistics/marketing + a.cc-allow Save-Button - Neues Signal provider_details_visible: nach Kategorie-Toggle prueft Playwright ob im Banner sichtbare Provider-/Cookie-Detail-Elemente erscheinen. Bei dp-cookieconsent (Banner ohne Listing) immer False -> HIGH-Violation "Kategorie zeigt keine Provider-/Cookie-Details — Nutzer kann nicht informiert einwilligen (Art. 7 Abs. 1 DSGVO)" - main.py serialisiert provider_details_visible + cookies_set pro Kategorie P20 (Frontend-Drilldown): - Backend: check_payloads-Tabelle um Spalte 'banner' (JSON) — voller banner_result persistiert (vorher nur in-memory). ALTER TABLE Migration idempotent. - Neuer Endpoint GET /api/compliance/agent/banner/<check_id> — liefert Quality-Score, Phases, Category-Tests, Banner-Checks, alle 46 structured_checks. - Frontend: BannerTab im /sdk/agent/audit/<id> mit Quality-Cards, 3-Phasen-Cookie-Tabelle, Per-Category-Listing (mit P19-Signal rot/gruen), Banner-Verstoesse + Rechtsgrundlagen, 46-Check-Drilldown filterbar nach Severity. - Tab-Switcher in page.tsx um "Cookie-Banner-Analyse" erweitert. - Bonus: 2 alte route.ts auf Next.js 15 Promise-params umgestellt (Build-Fix). Plus: Critical-Findings-Block nutzt provider_details_visible als primaeres Signal statt nur tracking_services-Anzahl. Smoke-Test Safetykon: 4 Critical Findings im Mail, banner-Endpoint liefert 46 checks + 3 phases + 2 categories mit provider_details_visible=False. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 14:31:13 +02:00
Benjamin Admin	e536247c20	feat(quaidal): backend API + frontend tab for BSI QUAIDAL data-quality controls ... Wire the 195 Clean-Room QUAIDAL controls (from breakpilot-core migration 011) into the compliance SaaS UI. Backend: - GET /api/v1/quaidal/stats - counts by kind + source provenance - GET /api/v1/quaidal/controls - list, optional kind= filter - GET /api/v1/quaidal/controls/{id} - single derived control - GET /api/v1/quaidal/criteria - 10 QKB criteria - GET /api/v1/quaidal/criteria/{id} - QKB with QB/MA/QM tree Frontend: - /sdk/quality: new "Trainingsdaten-Qualität (BSI QUAIDAL)" tab with 10 QKB cards and a drill-down modal showing the full QB→MA→QM tree plus original BSI source link and license note. - /sdk/ai-act: Art. 10 tile on each high-risk/unacceptable result, linking to /sdk/quality?category=data_quality. Pattern matches existing IACE module DIN-reference handling: own wording, source section + URL preserved for due diligence. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 13:03:54 +02:00
Benjamin Admin	479ce2225b	feat(profile): P14+P15+P16 — B2B-Heuristik + Doc-URL-Dedup + Homepage-Profile ... P14 — _detect_no_direct_sales erweitert um 3 Cluster: A) OEM-Konfigurator (BMW/Audi/Mercedes/VW/Porsche-Markennamen + Vertragshaendler-Pattern) B) B2B-Dienstleister (CE-Zertifizierung, Compliance-Beratung, Schulungen, Auditierung, TISAX, ISO-Normen, Arbeitssicherheit, ...) C) NGO/Verein/Public (Spendenkonto, Vereinsregister, gemeinnuetzig, ...) Schwelle: pos >= 2 pro Cluster UND pos > neg. Bisher: nur OEM. P15 — Doc-URL-Dedup im Worker: wenn mehrere Doc-Types DASSELBE Dokument referenzieren (Safetykon-Pattern: User gibt /datenschutz fuer dse, cookie UND widerruf), wird nur dem primaeren Doc-Type (Priority: dse > impressum > cookie > widerruf > agb > nutzungsbedingungen) der Text gegeben. Andere landen als "Nicht separat vorhanden — wird im Dokument 'X' mit-geprueft." Eliminiert die 8+8 systematischen widerruf/cookie False Positives. P16 — Profile-Detection auch Homepage-Text: Homepage-HTML wird mit kurzem Fetch (8s timeout) gezogen, getrippt und zum profile_input gemerged. Vor- her wirkte P14 nur wenn B2B-Indikatoren im DSE/Impressum-Pflichttext standen — bei Safetykon stehen sie nur im Homepage-Menue. Plus Bonus: TDM-Override-Submit-Button wird deaktiviert wenn Reason < 10 Zeichen — verhindert dass User wie heute in den Bug rein klickt. Smoke-Test Safetykon (B2B Compliance-Dienstleister): dse geprueft (kein err) impressum geprueft (kein err) cookie "Nicht separat vorhanden — wird in DSE mit-geprueft" agb "Nicht anwendbar — kein Direkt-Kaufvertrag" widerruf "Nicht anwendbar — kein Direkt-Kaufvertrag" nutzungsbedingungen "Nicht anwendbar — kein Direkt-Kaufvertrag" Vorher: 16 False Positives. Jetzt: 0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 11:46:58 +02:00
Benjamin Admin	78b27d4684	feat(compliance-check): P12 — TDM-Override mit dokumentierter Kunden-Erlaubnis ... Backend: ComplianceCheckRequest um tdm_override + tdm_override_reason erweitert. Worker im _run_compliance_check Pfad: bei tdm_override=True UND Reason >= 10 Zeichen wird der TDM-Vorbehalt nur dokumentiert (job.tdm_override.{reason, original_status}) und NICHT als Abbruch-Grund gewertet. Ohne Reason: Override ignoriert. Audit-Spur via logger.warning(reason). Frontend: ComplianceCheckTab um Checkbox + Pflicht-Reason-Feld ("Schriftliche Crawl-Erlaubnis vorhanden") direkt vor dem Submit- Button. Pflicht: Reason >= 10 Zeichen. Submit sendet die Flags ans Backend. Anwendungsfall: Safetykon-Pattern — robots.txt + ai.txt setzen Vorbehalt, aber Kunde hat schriftlich zugestimmt (Auftrags-Audit). [guardrail-change] ComplianceCheckTab.tsx (511 LOC) in loc-exceptions ergaenzt — Split nach _components/TDMOverride + CompliancePolling ist P11-Tech-Debt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 08:56:50 +02:00
Benjamin Admin	575644c9c5	feat(audit): P8 — MC-Severity raus, Email nur harte Findings, MC-Audit als Checkliste ... Email-Hardening (mc_scorecard.top_fails): Neue _is_hard_finding-Heuristik filtert konditionale MCs ohne Negativ-Beleg aus den Top-Auffaelligkeiten. matched_text leer + Label enthaelt "falls/sofern/wenn/soweit/ggf." -> raus, landet nur noch im MC-Audit als "selbst pruefen". DATA-2066-A05 (kostenfreie Abschaltung Standortdaten) ist das prototypische Beispiel. MC-Audit-Frontend (audit/[checkId]/page.tsx): Severity-Spalte (CRITICAL/HIGH/MEDIUM/LOW) entfernt — der MC-Audit ist eine Checkliste, keine Severity-Drohung. Stattdessen: - Spalte "Prioritaet" mit 3-Tier aus regulation-Mapping: Gesetz (DSGVO/ePrivacy/TDDDG/...) / Behoerden-Leitlinie (EDPB/DSK/EuGH/...) / Best-Practice (ISO/NIST/BSI) - 3-Status: erfuellt (✓) / nicht erfuellt (✗) / selbst pruefen (?) / nicht anwendbar (—). rowReviewStatus() leitet "selbst pruefen" aus matched_text-leer + konditionalem Label ab. - Filter umgebaut auf 5 Stati statt 4 - Default-Filter "Nicht erfuellt" (vorher "Nur Fail") Bonus: f.payload.risk_label TS-Cast im FindingsTab clean gemacht (unknown -> string). Effekt: - Email an die GF zeigt nur noch echte Belege ("DSB fehlt", "Gebuehr fuer Widerruf") - MC-Audit ist eine sachliche Pruefliste fuer den Compliance-Officer Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 00:30:04 +02:00
Benjamin Admin	6c223c7c9b	feat(compliance-check): exec-summary + voll-audit + TDM-respect + cookie-KB-extended + saving-scan-funnel ... P1 — Exec-Summary oben im Email-Report (4 KPIs + 2 CTAs, dunkler Gradient) P3 — no_direct_sales-Flag fuer OEM-Konfigurator-Sites; AGB/Widerruf/AGB als "NICHT ANWENDBAR" (grau) statt "NICHT GEFUNDEN" (rot) P5 — Voll-Audit Unification: alle Findings (MC + Pflichtangaben + Vendor + Redundanz) in /data/compliance_audits.db.unified_findings; neuer /api/compliance/agent/findings/<id> Endpoint + FindingsTab im Audit-UI mit Filter + CSV-Export P7 — Crawl-Hardening: TDM-Reservation-Check (robots.txt / ai.txt / Header / Meta) vor jedem Run mit 24h-Cache; HeadlessChrome-UA (Firma noch nicht gegruendet — Switch via BREAKPILOT_BRANDED_UA env); per-Domain Rate-Limit 1 req/s + max 2 concurrent P2 — Cookie-Knowledge-DB additiv erweitert (35 -> 74 Cookies): Adobe, Meta, Microsoft, LinkedIn, TikTok, HubSpot, Marketo, Salesforce, Hotjar, FullStory, Mouseflow, Intercom, Drift, Zendesk, Cloudflare, Stripe, OneTrust/Cookiebot/Usercentrics, Matomo, Pinterest, Snapchat, X/Twitter, YouTube, Vimeo, Klaviyo, Mailchimp, Mixpanel, Segment, Amplitude, Optimizely, Datadog; Wire-in in cookie_function_classifier liefert compliance_risk-Label (kritisch/hoch/mittel/gering) pro Vendor A — k-Anonymitaets-Helper (benchmark_k_anonymity) fuer P6-Vorbereitung B — Cross-Tenant-Domain-Assertion im /findings-Endpoint (expected_domain Query-Param -> 403 bei Mismatch) C — Saving-Scan-Funnel: /api/compliance/agent/saving-scan/start mit Validierung + 24h-Rate-Limit pro Domain + Lead-Persistenz in saving_scan_leads + Auto-Discovery via _run_compliance_check; 6 Tests D — Risk-Badge im Email-Vendor-Row Rechtliche Leitplanken (Memory feedback_oem_data_legal.md): nur eigene Knapp-Bewertungen + Source-Pointer, keine 1:1-Kopien fremder CMP-Texte. TDM-Opt-Out-Respect nach § 44b UrhG. KEINE Schema-Aenderungen — alles in Sidecar-SQLite. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 23:48:34 +02:00
Benjamin Admin	a616b64273	feat(iace): Customer-Standard-Reuse across customer's prior projects ... [migration-approved] Task #22. The IACE module is used by a single Maschinenhersteller, but their plants land at many different end customers. When the safety expert commissions the second or third plant at the same customer, whole classes of mitigations (company-wide PPE rules, locked-out energy isolation, customer-standard signage) are already in place there — but rediscovered from scratch every project. Migration 031: iace_projects.customer_name TEXT + partial index. The customer is stored as a plain text field rather than a normalised iace_customers table (option A from the design discussion). A proper customer-management screen can promote this to a FK later without data loss. Backend store_customer_standards.go: - ListCustomerStandardSuggestions(projectID, includeVerified) collects mitigations from all non-archived prior projects sharing the same tenant_id AND case-insensitive customer_name. Aggregates by mitigation.name (since same-named measures from different prior projects collapse into one suggestion) and surfaces: • source_project_count + source_project_names • is_customer_standard / has_verified_instances flags includeVerified=false → strictly is_customer_standard=true includeVerified=true → also status='verified' - ImportCustomerStandardSuggestion(projectID, name): for every prior (mitigation.name → hazard.name) pairing, finds matching hazards in the current project (by name) and ensures a customer-standard mitigation exists. New rows via CreateMitigation (idempotent through the UNIQUE(hazard_id, name) from migration 030); existing rows are flipped to is_relevant=true + is_customer_standard=true + status='verified' via UPDATE. Routes: GET /api/v1/iace/projects/:id/customer-standards?include_verified= POST /api/v1/iace/projects/:id/customer-standards/import body {name} Frontend: - New page /sdk/iace/[projectId]/customer-standards with: • empty-state hint pointing to Auftrag → Kundenname • per-suggestion checkbox + per-row Übernehmen button • bulk "N übernehmen" button • toggle "Auch verifizierte einbeziehen" widening the pool • per-suggestion source_project_count + status badges - Sidebar item "Kundenstandards" (building icon) placed between Verifikation and Nachweise. - Order-page now mirrors Auftraggeber.Firmenname into the top-level customer_name column on save, so the Reuse feature is fed automatically without a separate input field. The same expert effect from migration 029's is_customer_standard flag — "I already know it's covered, no evidence needed" — now becomes a cross-project asset rather than a per-project annotation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 22:31:30 +02:00
Benjamin Admin	27384aea09	feat(cra): Phase 5 — Technical Doc + DoC Generator (Annex V + VII) ... Migration 122: compliance_cra_documents with versioning + approval workflow - doc_type whitelist: doc_eu_conformity, doc_technical, doc_cvd_policy, doc_update_policy, doc_sbom_report - Status state machine: draft → reviewed → approved (+ superseded) - Snapshot generation_context for audit trail New module cra_doc_templates.py — pure-function generators (no DB access): - doc_eu_conformity: EU DoC structured per CRA Annex VII (all 7 mandatory fields) - doc_technical: Technische Dokumentation per CRA Annex V - doc_cvd_policy: ISO/IEC 29147-compliant CVD policy with SLA table - doc_update_policy: Patch/Update policy with Lifecycle + CSAF reference - doc_sbom_report: Latest SBOM summary with top-10 components Returns (title, markdown_content, requirements_coverage) — coverage tracks how many mandatory fields are filled vs placeholders. Backend endpoints: - POST /documents/generate — generates doc, supersedes previous version, increments version number atomically - GET /documents — lists all 5 doc types (also "not_generated" stubs) - GET /documents/{id} — full content_md - POST /documents/{id}/approve — set status + signed_by + signed_at Frontend: - /documents page: 5 doc-type cards with Generate/Re-Generate buttons, inline Markdown preview with .md download, 2-step approval flow (reviewed → approved with signature) - Optional params form: manufacturer, notified_body, security_contact - Dashboard: +1 button (Dokumente, 7 buttons total) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 22:10:23 +02:00
Benjamin Admin	cc80e59e5e	feat(cra): Phase 4 — Vulnerability Disclosure + Post-Market Monitoring ... Migration 121: compliance_cra_vulnerabilities table with full lifecycle tracking - Status state machine: reported → triaged → patched → disclosed (+ withdrawn) - CRA Art. 14(2) deadlines tracked: reported_to_enisa_at (24h), detailed_report_at (72h) - CVE-ID, severity, CVSS, affected_components (JSONB), embargo_until Backend endpoints in cra_routes.py: - POST /vulnerabilities — create with validation (severity, CVSS range) - GET /vulnerabilities — list with deadline-breach summary (24h/72h counters) - PATCH /vulnerabilities/{id} — update fields + auto-set lifecycle timestamps - DELETE /vulnerabilities/{id} — soft-delete (withdrawn) - GET /monitoring — combined view: CRA deadlines + vuln summary + post-market checklist Frontend: - /vuln page: intake form, vuln cards with 24h/72h-countdown buttons, status-transition flow with auto-timestamps - /monitoring page: CRA deadlines (11.06.26 / 11.09.26 / 11.12.27), breach banner if 24h/72h obligations missed, post-market checklist with deep-links - Dashboard: +2 buttons (Vulns, Monitoring) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 22:08:49 +02:00
Benjamin Admin	662327e8b4	feat(compliance-check): MC-Classification + Embedding + Vendor-Redundanz + Action-Recipes + Borlabs-Features ... Massiv-Update auf Basis BMW-Test-Iterationen (v1→v9): Core Compliance-Check - Sonnet check_type Klassifikation: text/process/review fuer alle 1874 MCs in compliance.doc_check_controls (script + Sidecar /data/mc_classification.db). rag_document_checker filtert auf check_type='text' fuer doc_check. Plus fits_doc_type-Audit (v2) + ui_only-Audit fuer DSA/E-Commerce-MCs in falscher doc_type-Schublade. - scope_requires-Filter: biometric/ai_decision/child_targeting MCs werden per business_profile gefiltert (FRT skipped fuer BMW etc.). - Embedding-Match (BGE-M3) als Phase-3 nach Regex-Match: Per-doc_type-Threshold-Override (impressum 0.50, dse/cookie 0.60), Short-Field-Rescue (15-Wort-Chunks) fuer Pflichtfelder im Impressum. Title+check_question als Embedding-Input fuer mehr Kontext. - Cookie-Text-Routing: consent-tester gibt cmp_cookie_text aus dem CMP-Reconstruct zurueck, Backend bevorzugt das gegen DOM-Extraction wenn richer (BMW 1824 vs 600 Worte). Vendor-Redundanz + EU-Alternativen + Cost-Saving - vendor_redundancy.analyze() — funktionale Kategorisierung der CMP-Vendors, Detektion von Mehrfach-Anbietern pro Kategorie, EU-Alternative-Lookup (Matomo, IONOS, HERE, Friendly Captcha, Smart AdServer, ...). - vendor_cost_estimator: Tier-Inferenz aus Cookie-Footprint (Cookie-Anzahl + Premium-Feature-Cookies + Third-Party-Quote → starter/professional/ enterprise/premier). - Self-Service-Werbung (Google/Meta/Pinterest/...) = 0 Lizenz-Kosten (nur Media-Spend, separat). DSP-Plattformen behalten enge Range. - Tier-aware Saving-Range: bei Enterprise/Premier nutzen wir den oberen 40-100%-Band der Listpreise, nicht starter→premier. - Multi-Function-Tools (Matomo Pro, SAP CX, IONOS Cloud, Userlike, Smart AdServer, HERE Maps, Vimeo Pro, LamaPoll) — ein Tool ersetzt mehrere Kategorien gleichzeitig. Cookie-Wissens-DB + Funktionale Klassifikation - cookie_knowledge_db: 50 kuratierte Top-Cookies (Google/Meta/Adobe/MS/...) mit vendor, exact_purpose, data_collected, IAB-TCF-IDs, reid_risk, schrems_ii_status, EuGH-Urteile, EU-Alternative. - cookie_function_classifier: pro Cookie funktionale Rolle (tracking_id, ad_pixel, session_id, ab_test, csrf, ...) + blocking_impact. Country-Inferenz aus Rechtsform - cookie_link_validator: Country-Field wird aus Vendor-Name abgeleitet (A/S=DK, GmbH=DE, Inc=US, B.V.=NL, ...) plus Vendor-Lookup-Table. Reduziert false-positive no_country-Flags bei eindeutig-EU-Vendors (Adform DK, Pinterest IE). Action-Recipes + Doc-Anchor-Locator - finding_action_recipes: pro Finding-Typ (no_cookies_listed, no_country, broken_opt_out, "Auftragsverarbeiter erwaehnen", "Art. 22 Profiling", ...) eine strukturierte Anweisung mit what/why/fix_text/where/example. Zum 1:1-Einfuegen in Kunden-Dokumente. - doc_anchor_locator: Embedding-basiert (BGE-M3 cosine) — sucht den passenden Absatz im existierenden Kundendokument fuer jeden Finding. Per-Run Thread-Local-Cache. Fallback: keyword-Match. - Email-Rendering integriert Recipe + Anchor pro Doc-Pruefungs-Fail + Vendor-Flag-Liste mit aufklappbarer Action-Liste. - Score-Erklaerung pro Vendor-Zeile (3/5-Untertitel + Tooltip). Migration-Pipeline (Compliance-Check -> Customer Banner/Documents) - migration_to_banner.py: Vendor-Liste -> CookieBannerConfig mit 4 Kategorien + Review-Flags. - migration_to_document.py: Vendor-Liste -> Cookie-Policy + VVT-Register + Privacy-Policy-Pre-Fills. - agent_migration_routes: 3 Preview-Endpoints (banner-preview, document-preview, summary). Persistierung der cmp_vendors in /data/compliance_audits.db check_payloads-Tabelle. Borlabs-Parity Cookie-Banner-Features - Consent-Historie im Banner: window.bpShowConsentHistory() + localStorage. - Content-Blocker: cookie-banner-content-blocker.ts — YouTube/Maps/Video Placeholder bis Einwilligung. - Google Consent Mode v2 erweitert: wait_for_update + region=EEA/CH/GB. - Consent-Log Export (CSV/JSON) per einwilligungen_export_routes. Bug-Fixes - canonical_control_routes: _jsonish-Helper fuer string-typed jsonb, similar-controls-Endpoint mit _has_embedding_col()-Cache (kein 500 mehr). - Control-Library Frontend: defensive .map-Coercer in 2 Detail-Views. - Embedding-Service-Batching (32er Batches statt 165 in einem Call). - KeyError 'control_id' in MC-Result-Aggregation (defensive .get). - Master-Controls-Klick-Through von /sdk/master-controls auf /sdk/control-library?control=<id> mit URL-Param-Auto-Open. - Dockerfile: /data pre-chowned auf appuser (Audit-DB-Schreibrecht). - Cookie-Text-Routing-Bug (cmp_reconstructed > DOM-extraction). - doc_type-aware MC-Filter (statt all-text-MCs). - Master-Contract-Dedup (60 BMW-Internal-Eintraege = 1 Adobe-Vertrag). - A3-v2-Audit hat 24 UI-Sprache-MCs als 'process' reklassifiziert. Tests - test_migration_mappers.py (9 Tests) - test_migration_endpoints.py (4 Tests) Skripte (one-shot) - classify_mc_check_type.py (v1) + _v2 (PK=control_id,doc_type) - audit_mc_doctype_fit.py (v1 fits) + _v2 (ui_only + scope_requires) BMW-Run-Bilanz v1 (broken) -> v9 (alle Fixes): DSE 7,5% -> 81-83% Impressum 4% -> 100% (6 echte MCs alle erfuellt) Cookie 0% -> 79-83% (CMP-Text-Routing + Embedding) Plus: 10 Konsolidierungs-Kategorien, geschaetzte Saving 200k-3M / Jahr Plus: Action-Recipes + Doc-Anchors fuer jeden Fail Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 18:30:08 +02:00
Benjamin Admin	52fb8b91e7	Merge branch 'main' of ssh://gitea.meghsakha.com:22222/Benjamin_Boenisch/breakpilot-compliance	2026-05-18 18:09:39 +02:00
Benjamin Admin	1cf5de1d45	feat(cra): CRA Compliance module Phase 1+2+3 (intake, scope, path, requirements, backlog, sbom, checks) ... Phase 1 — Intake + Scope + Path: - Migration 119: compliance_cra_projects table (intake + classification + path + status state machine) - Backend service cra_routes.py: CRUD + scope-check + path-select - Deterministic Annex III/IV classifier (verbatim mapping from migration 059 wiki) - Path validation per classification (CRITICAL → notified_body mandatory) - Frontend: project list, dashboard, 3-step wizard (intake/scope/path) - Sidebar entry under "CRA Compliance" (red) Phase 2 — Annex I Requirements + Priorisierungs-Backlog: - cra_annex_i_data.py: 40 Annex-I requirements (8 categories), 9 measures (M540-M548), 3 CRA deadlines - Endpoints: /requirements (40 items), /backlog (priority-sorted with deadline pressure) - Frontend: requirements table with filters + expandable details, backlog with deadline banner + score-ranked table - Dashboard KPI cards (Critical count, days to CE deadline, etc.) + top-10 backlog snippet Phase 3 — SBOM Upload + Automated Checks: - Migration 120: compliance_cra_sboms (versioned uploads, CycloneDX + SPDX) - SBOM endpoints: POST /sbom/upload (format detection, summary extraction), GET /sboms - Checks reuse compliance_evidence_checks: init creates 6 default CRA checks, run executes - Real implementations: cra_security_txt (HTTP + Contact: line) and cra_tls_cert_check (TLS handshake) - Frontend: SBOM file upload + version list, Checks page with per-check URL input + Run button Backend-Reuse: gap_projects (intake pre-population), compliance_evidence_checks/_check_results. Tenant scoping via existing X-Tenant-ID header pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 17:56:52 +02:00
Benjamin Admin	3faa312b31	feat(iace/verification): derived view on relevant mitigations + 2 actions ... Task #21. The verification page used to manage a separate VerificationItem entity that the expert had to populate by hand — disjoint from the actual mitigations list. With the is_relevant flag from migration 029, the verification step has a natural definition: confirm completion for every mitigation the expert flagged as relevant for this project. Page is now a derived view on useMitigations(): filter is_relevant=true, group by title (same dedupe as Massnahmen page), expose two actions per hazard×mitigation row: 1. "Kundenstandard" — already implemented at the customer's site, no evidence file required. Sets is_customer_standard=true and status='verified'. 2. "Verifizieren…" — opens a modal asking for a textual evidence reference (Prüfprotokoll-Nr, audit reference, etc.). Calls the existing POST /mitigations/:mid/verify with verification_result. File upload is deferred to phase 2 once an object-storage backend is in place — the modal explains this. When a row is verified, a "Zurücksetzen" link reverts status to 'implemented' for accidental confirmations. Header counters: total relevant / open / verified / Kundenstandard. Maßnahmen-page polish (same commit): - "Lösch."-column header removed — the trash icon is self-explanatory - groupByTitle now additionally deduplicates by hazard_id within a group (engine occasionally emits duplicate (name, hazard_id) pairs when Reinit is clicked twice; a follow-up migration 030 will add a UNIQUE constraint to prevent these upstream) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 14:49:56 +02:00
Benjamin Admin	8f4f59f0e3	feat(iace/mitigations): is_relevant + is_customer_standard flags ... [migration-approved] Expert-driven workflow refinement on the Massnahmen page. The engine seeds ~80 mitigations per project, but for a concrete customer site most need a relevance decision before they're meaningful in verification: status: 'planned' | 'implemented' | 'verified' (existing — verification track) is_relevant bool (new) (does this apply to *this* site?) is_customer_standard bool (new) (already in place at customer — no evidence) Decision flow on the Mitigations tab: Engine-seeded → is_relevant=false (Default, waiting for expert) Expert checks "Relevant" → is_relevant=true → surfaces in verification Expert clicks trash → DELETE (banner warns: do not click Reinit afterwards or seeds come back) In verification, customer_standard=true bypasses evidence upload is_customer_standard implies is_relevant (DB CHECK constraint). Migration 029_iace_mitigation_relevance.sql: ALTER TABLE iace_mitigations ADD COLUMN is_relevant ..., is_customer_standard ... + CHECK constraint + partial index on is_relevant for the verification page's filter. Backend (Go): - Mitigation struct gains two bool fields - CreateMitigation: defaults to false/false (engine-seeded mitigations start unbewertet) - UpdateMitigation: new case clauses for both keys; setting is_customer_standard=true auto-flips is_relevant=true to satisfy the CHECK constraint - All three SELECT statements (ListMitigations, ListMitigationsByProject, getMitigation) extended with the two new columns Frontend: - Maßnahmen-page columns: [Relev. ☑] [Lösch. 🗑] Title | #Hazards | P·I·V - Group-header checkbox shows tri-state (indeterminate when partial), flips all instances in the group at once - Banner above the table: "Markiere jede Maßnahme als Relevant oder lösche sie. Nach Löschen kein Neu initialisieren mehr drücken." - Relevant rows tinted emerald, customer-standard label visible - Legacy bulk-select state + helpers removed (the Relevant checkbox now IS the primary mass action) - useMitigations gains handleSetRelevant, handleSetCustomerStandard, handleDeleteSilent (for non-confirm bulk deletes) Future use: is_customer_standard mitigations from a prior project at the same customer can later be auto-suggested when commissioning the next plant — turning expert knowledge into reusable customer-profile data. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 14:35:56 +02:00
Benjamin Admin	df7d83134b	feat(agent): migrate compliance-check results to banner + documents (M1-M5) ... After a compliance-check run finishes, the user can now apply the extracted vendor inventory directly to their own: - CookieBanner config (admin /sdk/einwilligungen) - Cookie-Policy / VVT-Register / Privacy-Policy templates (admin /sdk/document-generator) Backend: - migration_to_banner.py: vendor list -> CookieBannerConfig with ESSENTIAL/PERFORMANCE/PERSONALIZATION/EXTERNAL_MEDIA buckets + review flags (broken opt-out URLs, missing expiry, no cookies listed) - migration_to_document.py: vendor list -> pre-fills for 3 doc templates, recipient-type aware (INTERNAL/GROUP/PROCESSOR/CONTROLLER) - agent_migration_routes.py: GET /banner-preview, /document-preview, /summary keyed on check_id - compliance_audit_log: new check_payloads table persists cmp_vendors + extracted_profile so the preview survives an app restart - tests: 9 mapper units + 4 endpoint integration tests Frontend: - MigrationPanel.tsx: modal showing banner-config diff + document pre-fills, plus links into the existing editors - ComplianceCheckTab.tsx: replaces standalone audit link with the panel; net -3 lines, stays at the 500-cap Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 14:06:28 +02:00
Benjamin Admin	f4c9cea770	feat(iace/mitigations): group measure rows by title, collapse 21x→1 row ... The "Maßnahmen" page in the Bremsscheibe project showed a flat list with heavy redundancy — e.g. "Sicherheitszeichen nach ISO 7010" appeared on 21 separate rows, one per linked hazard. Same for "Gefahrenpiktogramme", "Flucht- und Rettungswege" etc. The signal got lost in the noise. This is a presentation-only regrouping. Each Hazard×Mitigation pair stays a separate DB row with its own status, notes and edit history (option B from the discussion: instances remain independently editable). The page now collapses rows that share the same `m.title` into one group row. Group row shows: - title + ISO 12100 sub-category (if encoded in description) - count of linked hazards on the right - compact status distribution "P · I · V" (Planned/Implemented/Verified) - shared checkbox that selects all instances in the group Click expands the group and reveals the individual hazard×measure rows, each with its own StatusBadge and detail-expand for MitigationHints. State additions: - expandedGroup: Set<string> with keys `${type}:${title}` so the same title across different reduction stages stays independently togglable - groupByTitle() helper trims the title, falls back to "(ohne Titel)" - statusCounts() helper for the P·I·V breakdown Pagination semantics swapped from 50 instances/page to 50 groups/page — makes the list far easier to scan at the ~80-instance scale this project exhibits. LOC: 267 → 346 (well under the 500 hard cap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 13:50:45 +02:00
Benjamin Admin	6ed30dae5b	feat(agent): MC scorecard + audit drill-down + tenant trend (A1-A6) ... Now that all 1874 MCs run per check (Task #30 cap removal), the report was about to drown in noise. This commit adds the full aggregation / persistence / drill-down stack so each MC is actionable, not just counted. A1 mc_scorecard.py (new): build_scorecard(checks) -> per-regulation PASS/FAIL/SKIP + severity top_fails(checks, n) -> N most severe failed MCs full_audit_records(...) -> flat rows ready for sidecar SQLite A2 Email rendering: agent_doc_check_scorecard.py (new) builds an HTML scorecard table (regulation × passed/failed/HIGH/MEDIUM/score) shown at the top of the email. agent_doc_check_report._render_document now collapses the 500-MC L2 forest into 'X/Y bestanden (Z Fail)' summary plus a top-10 fails block per doc — old verbose render is gone. A3 compliance_audit_log.py (new) — sidecar SQLite at /data/compliance_audits.db (separate from compliance Postgres schema to comply with the no-new-migrations rule in CLAUDE.md): check_runs(check_id, ts, tenant_id, site_name, base_domain, doc_count, scorecard json, vvt_summary json) mc_results(check_id, doc_type, mc_id, label, passed, skipped, severity, regulation, matched_text, hint) Route persists every run after the email is sent. docker-compose.yml adds compliance-audit volume + env. A4 backfill_mc_regulation_llm.py (new) — Qwen-tagged backfill for the 1636 MCs the regex pass couldn't classify. Batches of 25, format=json, output constrained to the canonical regulation list. Run manually: docker exec bp-compliance-backend python3 \ /app/scripts/backfill_mc_regulation_llm.py [--dry-run] A5 Admin audit tab — GET /api/compliance/agent/audit/<check_id> proxied via /api/sdk/v1/agent/audit/<id>. New page /sdk/agent/audit/[checkId] renders scorecard + filterable MC table (status / doc_type / regulation, expandable rows with matched_text + hint). ComplianceCheckTab now shows 'Voll-Audit oeffnen' link. A6 Trend per tenant — GET /api/compliance/agent/audit/tenant/<id> returns recent runs. Email scorecard shows per-regulation delta badges ('(+12%)', '(-3%)') compared with the previous run for the same tenant + base_domain. Lookup is one SQLite query. Plumbing: rag_document_checker.py — SELECT now includes 'article'; MC results carry 'regulation' + 'article' through to CheckItem. agent_doc_check_routes.CheckItem schema gains regulation + article fields (defaults '') so old clients still parse. agent_compliance_check_routes — response gains 'check_id' so the frontend can build the audit link.	2026-05-17 13:45:58 +02:00
Benjamin Admin	4a5924b8c4	feat(iace): CRA / DIN EN 40000-1-2 cyber-resilience spur ... [guardrail-change] Phase 18 adds an EU Cyber Resilience Act compliance track to IACE: the engine now fires patterns that surface the manufacturer-side CRA obligations whenever a project's components carry digital elements. Patterns (HP1910-HP1918, hazard_patterns_cra.go): HP1910 Missing SBOM HP1911 Unsigned firmware/software updates HP1912 Factory-default credentials still active HP1913 No coordinated vulnerability disclosure (CVD) policy HP1914 No documented security patch SLA HP1915 Missing user-facing hardening guide HP1916 No incident-notification process to ENISA / CSIRT HP1917 No security assessment prior to placing on market HP1918 AI component without cybersecurity risk assessment Each pattern carries ClarificationQuestionsDE so the operator gets auditor-grade questions to take back to the Anlagenbauer instead of the engine inventing prose. PatternMatch carries DefaultAvoidability (P=1 for all CRA patterns), feeding the PLr graph from Phase 17. Measures (M540-M548, measures_library_cra.go): M540 SBOM (SPDX or CycloneDX) with each machine release M541 Signed updates with rollback protection M542 Forced default-password change at first boot M543 Published CVD policy (security.txt / PSIRT) M544 Documented patch SLA with CVSS-tier response times M545 User-facing hardening guide in the machine docs M546 ENISA incident-notification process (24h/72h/14d) M547 Authenticated update channel + integrity check M548 Pre-market security assessment / pen-test The library is urheberrechtlich neutral: identifiers only (Verordnung (EU) 2024/2847, DIN EN 40000-1-2 Entwurf, IEC 62443, ETSI EN 303 645, ISO/IEC 5962, ISO/IEC 29147). No normative text is reproduced — DIN/Beuth proprietary content is referenced by section number only. Category-compatibility: cyber_resilience pattern category accepts measures with HazardCategory cyber_resilience, cyber_network, or software_control. Updated in both the runtime helper (iace_handler_init_helpers.go) and its test-mirror (pattern_coverage_test.go) — both must move in lockstep. Frontend (clarifications page): When at least one clarification references "2024/2847" or "40000-1-2" in its norm_references, a blue info-banner is rendered at the top of the page: "Cyber Resilience Act (CRA) — Hinweis zur Geltung Diese Klärungsliste enthält Fragen zur Verordnung (EU) 2024/2847 (CRA). Die CRA gilt für Produkte mit digitalen Elementen, die ab dem 11.12.2027 auf dem EU-Markt bereit- gestellt werden. ..." Reminds the user that the CRA pflichten are forward-looking while still allowing the manufacturer to bake them in now. LOC exceptions: Added three pre-existing files to .claude/rules/loc-exceptions.txt (manufacturer_safety_features.go, iace_handler_clarifications.go, routes.go). All three grew across Phases 16-17 and are tagged as Phase 5+ refactor backlog. [guardrail-change] marker required. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 02:15:51 +02:00
Benjamin Admin	c4be077c5d	feat(iace): Klaerungen Phase 3 — DB-Tabelle + Multi-User + PDF-Export ... [migration-approved] Three pieces complete the Klaerungen lifecycle: 1. Migration 028: iace_clarifications + iace_clarification_comments + iace_clarification_history. Deterministic clarification_key (UNIQUE per project) so engine re-inits don't lose answers. History table logs every status/answer transition. The previous JSONB-in-metadata storage is kept as read-only fallback for pre-migration projects until a one-shot upcopy script runs. 2. Multi-User-Workflow: - assigned_to field on every clarification (free-text user kuerzel for now; an FK to users can be added in a follow-up). - Comment thread per clarification (POST .../comment, GET .../detail returns the thread). - Status-history log written by UpsertClarification when the status or answer actually changes. - Frontend Modal: Zugewiesen-an + Bearbeiter fields, comment thread with inline post, collapsible history section. 3. PDF-Export via print-friendly HTML: - GET /clarifications.html returns a standalone A4-styled document with status badges, norm references, affected hazards and a signature row at the bottom. The Bediener opens the link and uses Strg-P / Cmd-P to save as PDF. No server-side PDF dependency added. - Frontend "PDF / Druck" button next to CSV export. Backend: - internal/iace/store_clarifications.go: UpsertClarification, ListClarificationsForProject, GetClarificationByKey, AddClarificationComment, ListClarificationComments, ListClarificationHistory. - internal/api/handlers/iace_handler_clarifications.go: - AnswerClarification now writes the SQL row, falls back to legacy JSONB read on list. - PostClarificationComment, ListClarificationDetail, ExportClarificationsHTML added. Migration must be applied manually on Mac Mini and prod via psql -f /migrations/028_iace_clarifications.sql — pattern as in scripts/apply_*_migration.sh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:39:17 +02:00
Benjamin Admin	f19a75d83d	feat(iace): Klaerungen Phase 2 — Sidebar-Counter + CSV-Export + Hazard-Banner ... Three pieces complete the Klaerungen UX: 1. Sidebar-Counter: layout.tsx polls /clarifications and shows a colored open-count badge on the "Klaerungen" nav item. Refreshes whenever the user changes route. 2. CSV-Export: new backend endpoint GET /sdk/v1/iace/projects/:id/clarifications.csv produces a UTF-8- BOM-prefixed semicolon-separated CSV (Excel-friendly) with ID, Quelle, Kategorie, Frage, Status, Antwort, Begruendung, Bearbeiter, answered_at, anzahl Gefaehrdungen, Gefaehrdungs-Namen, Norm-Refs. Frontend Klaerungen-Seite bekommt einen "CSV-Export"-Button. 3. Hazard-Banner statt Fragentext im Benchmark-Detail: the previous bulleted clarification list was duplicated across 48 hazards for a single FANUC question. Phase 2 replaces it with a compact status badge — "N offene Klaerung(en) — Klaerungen-Seite oeffnen" (orange) or "Alle N Klaerungen beantwortet" (green) with a direct link. Backend cleanup: iace_handler_init.go no longer appends the "Mit Anlagenbauer zu klaeren" block to Hazard.Description. The description stays focused on the scenario; clarifications live in the dedicated endpoint and answers persist across re-inits via project.metadata. The aggregated "Referenzierte Normen" line on the hazard is kept. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:25:36 +02:00
Benjamin Admin	525038359a	feat(compliance-check): auto-discover missing doc types from homepage ... When the user leaves some doc-type rows empty, the tool now actively searches the website for them — only marks 'not found' as last resort. Flow: 1. User submits N URLs (e.g. just DSI) 2. For each canonical doc_type with no submitted URL/text, the route identifies the most-common base (scheme://netloc) from submitted URLs 3. Calls consent-tester /dsi-discovery on the homepage with max_documents=15 (180s timeout) 4. Classifies every discovered doc into a canonical doc_type via title/URL keyword rules (_DISCOVERY_RULES — covers cookie/widerruf/ social_media/agb/nutzungsbedingungen/dsb/impressum/dse) 5. Fills matching empty entries with the discovered text, marks auto_discovered=True and discovery_attempted=True Padding now differentiates: - 'Auf der Website nicht gefunden' — discovery was attempted, no doc matched. Amber badge, friendly hint to add URL manually. - 'Nicht eingereicht — Quelle nicht angegeben' — user gave NO URLs at all, nothing to crawl from. Grey badge. Email + frontend: - Status labels: NICHT GEFUNDEN (amber) vs NICHT EINGEREICHT (grey) - 'Gepruefte Quellen' table tags auto-discovered URLs with a small blue 'auto-entdeckt' badge so GF sees what tool found vs user submitted. Implementation only runs when ≥1 URL was submitted (no base to crawl from otherwise). Adds 30-90s for unsubmitted types but avoids the 'just say nicht gefunden' anti-pattern.	2026-05-17 01:14:05 +02:00
Benjamin Admin	79efa54898	feat(iace): Klaerungen MVP — Phase 1 ... New page "Klaerungen" between Massnahmen and Verifikation. Backend: - internal/iace/clarifications.go: Clarification struct + ClarificationAnswer + BuildProjectClarifications() — aggregates pattern-level + manufacturer- level questions from collectAllPatterns + GetManufacturerSafetyFeatures. Deterministic IDs ("pattern:HP1640:0", "manuf:fanuc:dual-check-safety-dcs:1") so persisted answers survive every re-init. - internal/api/handlers/iace_handler_clarifications.go: - GET /projects/:id/clarifications returns aggregated list with affected hazard names + persisted answer state, sorted (open first). - POST /projects/:id/clarifications/:cid/answer writes status/answer/ reasoning/answered_by/answered_at to project.metadata.clarification_- answers — no DB schema change. Frontend: - admin-compliance/app/sdk/iace/layout.tsx: new "Klaerungen" nav item. - app/sdk/iace/[projectId]/clarifications/page.tsx: table grouped by source (FANUC / Pattern HP1640 / …), Filter Offen/Beantwortet/Alle, search field, Antwort-Modal with status/answer/Begruendung/Bearbeiter. A clarification answered once applies to ALL referenced hazards — the operator no longer has to answer the same FANUC DCS question on 48 mechanical hazards individually. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:05:53 +02:00
Benjamin Admin	bc21480a2a	fix(compliance-check): always render 8 doc types + 4 BMW GT-gap fixes ... Always-show-8 (user-requested): - agent_compliance_check_routes.py: _pad_results_with_missing pads the results list to always include all 8 canonical doc_types in canonical order. Missing types get a placeholder DocCheckResult with error= 'Nicht eingereicht' + scenario='missing'. - agent_doc_check_report.py: NICHT EINGEREICHT status label (neutral), friendly grey body block instead of red error. - ChecklistView.tsx: 'Nicht eingereicht' chip (neutral grey, not red 'Fehler'); SCENARIO_LABELS adds missing entry + header chip counter. Impressum-Regression fix (#18): - _fetch_text(url, doc_type): cookie/dse/social_media -> max_documents=1 (CMP capture authoritative, sub-pages dilute). Other types -> =3 (Impressum needs Versicherungsvermittler, Aufsicht, Berufsrecht sub- pages). 15s networkidle bail keeps timing safe. ODR/Verbraucherstreitbeilegung filter (#19): - _apply_profile_filter: when profile.needs_odr=True (B2C), override the check's default B2B-oriented hint with action-oriented B2C guidance pointing at Art. 14 EU-VO 524/2013 + §36 VSBG. Previously the check contradicted itself: 'profile says B2C' + hint 'only relevant for B2C online vendors'. Registergericht regex (#20): - impressum_checks.py: accept colon/dot/dash between keyword and city (BMW writes 'registergericht: münchen hrb 42243'). Add 'sitz und registergericht: X' as separate pattern. Industry detection (#21): - business_profiler.py: 'automotive' keywords broadened (antriebs, motor, leasing, werkstatt, probefahrt, plus brand names BMW/Mercedes/ Audi/VW/Porsche/Opel). 'it_services' keywords narrowed — software/ cloud/hosting are mentioned in every privacy policy and were biasing the result toward IT for any tech-aware company.	2026-05-17 01:03:58 +02:00
Benjamin Admin	74f66c4c34	fix(admin/iace/benchmark): show Klaerungsfragen + Normen on Engine column ... The Go init handler appends two annotated blocks to Hazard.Description ("Mit Anlagenbauer zu klaeren: ..." and "Referenzierte Normen: ...") without changing the DB schema. The benchmark detail view only rendered hazard.scenario || hazard.description, so the appended blocks were silently hidden because scenario is always populated. Split the description into three structured pieces: 1. extractScenario() — pure scenario text, stripped of trailing blocks 2. extractClarifications() — bullet list of "Mit Anlagenbauer zu klaeren" 3. extractEngineNorms() — pipe-separated norm references Each piece is rendered as its own DetailRow. The FANUC DCS clarification that already lives in the DB (48/115 hazards on the Bremse project) is now visible in the Engine column. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 00:42:41 +02:00
Benjamin Admin	e61e9d9e2a	feat(agent): progress_pct + 6 BMW-Run Verbesserungen ... Backend (agent_compliance_check_routes.py): - progress_pct (0-100%) im Job-State, ueber alle Phasen verteilt (Laden 0-30, Profil 35-40, Pruefen 40-80, Banner 80-92, Report 95-100) - Status-Texte vereinheitlicht ("Texte laden X/N", "Pruefen X/N") - Firmenname fuer Email-Subject jetzt aus URL abgeleitet (bmw.de -> "BMW", mercedes-benz.de -> "Mercedes-Benz") statt unzuverlaessigem extracted_profile.companyName (matchte oft juris.de) - E-Mail-Report enthaelt jetzt Banner+TCF-Vendor-Liste (build_provider_list_html) Backend (agent_doc_check_extras.py — neu): - build_scanned_urls_html: gepruefte URLs als Tabelle oben im Report (transparent fuer GF, welche Quellen wirklich gezogen wurden) - Cross-Domain-Hinweis bei >1 netloc (BMW: bmw.de / bmwgroup.com / bmwgroup.jobs — Auffindbarkeit nach Art. 12 DSGVO) - build_provider_list_html: Banner-Box + TCF-Vendor-Tabelle mit Spalten Name | Kategorie | Zweck | Drittland | Rechtsgrundlage Backend (business_profiler.py): - §34d-GewO Versicherungsvermittler-Hinweise zaehlen nicht mehr als "finance"-Industrie (BMW wurde dadurch falsch als B2B/finance erkannt) - Neue Industry "automotive" (Fahrzeug/KFZ/Konfigurator/Modellpalette) - B2B-Keywords: generische Begriffe wie "unternehmen", "beratung", "consulting" entfernt (matchten in jedem Konzerntext) - B2C-Fallback: bei Verbraucher-Signalen ("widerruf", "kunde", redaktioneller Inhalt) tendiert auf b2c statt b2b Frontend (ComplianceCheckTab.tsx): - Progress-Balken mit Width-% und XX%-Anzeige rechts - liest data.progress_pct aus Polling-Response Consent-Tester (dsi_discovery.py): - Cookie-Policy-Extraktion kritisch fixt: wait_for_function bis body.innerText > 500 chars (BMW SPA-Rendering brauchte mehr Zeit) - _extract_text_robust: 3-Strategien-Extraktion (Selektoren -> Body- Cleanup -> P/LI/TD-Tags) - _extract_text_from_iframes: liest OneTrust/Sourcepoint/Usercentrics Iframe-Inhalte (manche Cookie-Policies leben dort) Adressiert alle Findings aus dem BMW-Ground-Truth-Vergleich.	2026-05-16 17:53:14 +02:00
Benjamin Admin	d45e08e25f	fix: reduce Playwright timeout 180s→60s, increase poll limit 15→25min	2026-05-16 00:47:28 +02:00
Sharang Parnerkar	3784988d00	chore: bump next 15.1.0 → 15.5.16 (CVE-2026-44578) ... Patches unauthenticated SSRF in WebSocket upgrade handler. Applies to admin-compliance, developer-portal. Compliance-SDK admin-dashboard skipped — has a pre-existing TS type mismatch that blocks the build regardless of Next version. Needs separate migration work. GHSA-c4j6-fc7j-m34r. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 18:48:36 +02:00
Benjamin Admin	3b7ab4cbd7	feat(iace): 50% display threshold — weak matches shown as separate ... Matches below 50% are now split: - GT entries → "Fehlend" tab (not matched by engine) - Engine entries → "Engine Findings" tab (additional findings) Only matches >= 50% shown in "Zugeordnet" tab. Coverage score now counts only real matches (>= 50%). "Extra" tab renamed to "Engine Findings" for clarity. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-15 10:33:29 +02:00